AP2 (Agent Payments Protocol): cómo pagan los agentes de IA sin romper la confianza en fintech
Cuando un agente de IA compra en tu nombre, ¿cómo sabe el comercio que esa orden refleja tu voluntad real y no una alucinación del modelo? El Agent Payments Protocol (AP2) es la respuesta abierta que impulsan Google y la industria de pagos a esa pregunta. Es un protocolo diseñado para que un agente autónomo pueda ejecutar un pago dejando una prueba criptográfica, verificable y no repudiable de la intención del usuario. Para cualquier equipo de fintech, insurtech o comercio que se plantee la web agéntica, entender AP2 hoy es entender cómo será la capa de confianza del comercio autónomo mañana.
Respuesta directa: qué es AP2 y qué problema resuelve
AP2 es un protocolo abierto, presentado por Google el 16 de septiembre de 2025 y cuya gobernanza se ha donado a la FIDO Alliance, que define cómo un agente de IA autoriza y ejecuta pagos en nombre de una persona. No sustituye a las redes de pago existentes: se apoya en ellas y añade una capa de confianza.
El problema que ataca es estructural. Los sistemas de pago actuales asumen que hay un humano haciendo clic en "comprar" en un sitio de confianza. Cuando quien inicia el pago es un agente autónomo, esa asunción se rompe y aparecen tres preguntas sin respuesta:
- Autenticidad: ¿cómo garantiza el comercio que la petición del agente refleja la intención real del usuario, sin errores ni alucinaciones?
- Autorización: ¿autorizó realmente el usuario esta compra concreta, con estas condiciones?
- Responsabilidad: si algo sale mal, ¿quién responde —el usuario, el desarrollador del agente, el comercio, el emisor de la tarjeta?
AP2 nace para que la respuesta no sea un mosaico de soluciones propietarias incompatibles, sino un estándar común. Extiende los protocolos A2A (Agent2Agent) y MCP, que ya cubren la comunicación entre agentes y con herramientas, añadiendo la pieza que faltaba: el pago con confianza.
El concepto central: credenciales verificables y "mandates"
La confianza en AP2 no se basa en inferir lo que el agente cree que quieres, sino en pruebas firmadas de lo que has autorizado. La herramienta para ello son las Verifiable Digital Credentials (VDCs): credenciales digitales a prueba de manipulación, firmadas criptográficamente, que encadenan la responsabilidad a lo largo de toda la transacción.
Sobre esa base, AP2 define mandates (mandatos), que son las autorizaciones concretas que viajan por el sistema. Los dos principales:
- Cart Mandate (mandato de carrito): captura los artículos y detalles concretos de la compra negociados entre el agente y el comercio. Se comparte con el comercio y fija exactamente qué se está comprando y en qué condiciones.
- Payment Mandate (mandato de pago): autoriza un pago contra un instrumento concreto (una tarjeta, por ejemplo). Se comparte con el proveedor de credenciales, las redes de pago y el procesador del comercio.
Estos mandatos existen en dos modalidades según haya o no una persona delante en el momento del pago:
- Human-present (humano presente): el usuario confirma la operación en el momento. El mandato de intención se concreta en un carrito específico que el usuario aprueba.
- Human-not-present (humano no presente): el agente actúa de forma autónoma dentro de restricciones que el usuario definió de antemano (por ejemplo, "compra estas entradas si el precio baja de X"). Aquí el mandato "abierto" captura esas restricciones —presupuesto, condiciones— y el agente solo puede ejecutar dentro de ellas.
El encadenamiento de VDCs produce un rastro de auditoría completo y verificable tanto si el humano estaba presente como si no. Para un sector regulado, ese rastro no repudiable es exactamente lo que exigen el cumplimiento y la resolución de disputas.
Por qué esto importa especialmente en fintech e insurtech
El comercio agéntico no es un experimento de laboratorio: es una extensión natural de lo que ya está pasando con asistentes que comparan, recomiendan y reservan. En verticales como comparadores de seguros, banca o viajes de negocio, el salto de "el agente te muestra opciones" a "el agente ejecuta la compra" es cuestión de resolver la capa de confianza y cumplimiento. AP2 es un candidato serio para esa capa por tres razones:
- Neutralidad de método de pago. La primera versión soporta pagos "pull" habituales (tarjetas de crédito y débito), y la hoja de ruta incluye e-wallets y pagos "push" como transferencias bancarias en tiempo real. Incluso contempla pagos con stablecoins mediante el protocolo x402.
- Gobernanza abierta. Al donarse a la FIDO Alliance —la misma organización detrás de los passkeys y estándares de autenticación que ya usan los bancos—, AP2 gana credibilidad y una vía de estandarización real, no un formato controlado por un solo actor.
- Encaje regulatorio. El énfasis en intención verificable y rastro de auditoría conecta directamente con las exigencias que ya afectan a las apps financieras europeas. Si estás lidiando con DORA, PSD3 y el AI Act, la trazabilidad no repudiable de AP2 juega a favor, no en contra.
Cómo encaja AP2 con MCP y A2A
Es fácil confundir la sopa de siglas. Una forma limpia de ordenarlos:
| Protocolo | Qué resuelve | Analogía |
|---|---|---|
| MCP | Conectar un agente con herramientas y datos | El agente "usa" aplicaciones |
| A2A | Comunicación y delegación entre agentes | Los agentes "hablan" entre sí |
| AP2 | Autorizar y ejecutar pagos con confianza | El agente "paga" de forma verificable |
Los tres son complementarios. Un flujo agéntico realista puede usar MCP para consultar el catálogo de un comercio, A2A para que el agente del usuario negocie con el agente del comercio, y AP2 para cerrar el pago con los mandatos firmados. Si quieres el fundamento de los dos primeros, lo desarrollamos en A2A vs MCP y en MCP en producción: cuándo usarlo.
Cuándo NO adoptar AP2 (todavía)
Aquí toca la dosis de realidad, porque el hype del comercio agéntico corre más rápido que su madurez.
- Si no tienes un caso de uso agéntico real, no integres AP2. Es una capa de confianza para pagos iniciados por agentes. Si tu app la inicia un humano con un botón, AP2 no te aporta nada hoy.
- Es un estándar joven. Está en versiones tempranas (v0.2 en el momento de escribir) y su especificación evoluciona. Construir producto crítico sobre una spec que aún se mueve exige aislar bien esa dependencia y asumir cambios.
- El ecosistema de partners aún se está formando. Que Google, redes de pago y FIDO estén detrás es una señal fuerte, pero la disponibilidad real dependerá de que tu emisor, procesador y pasarela lo soporten. Verifica el soporte antes de prometer nada al negocio.
- No sustituye tu diligencia en fraude y cumplimiento. AP2 aporta trazabilidad de intención; no exime de KYC, antifraude ni de las obligaciones de PSD3. Es una pieza más, no una bala de plata.
Nuestra recomendación pragmática: si operas en fintech, insurtech o retail, merece la pena montar una prueba de concepto ahora —los samples de referencia incluyen implementaciones en Python, Go y Android— para entender el modelo de mandatos y dónde encajaría en tu arquitectura. Pero mantenlo en el terreno de la exploración hasta que la especificación y el soporte de tus partners se estabilicen.
Cómo lo vemos en Dribba
Llevamos desde 2011 construyendo producto en sectores regulados y, más recientemente, ayudando a equipos a diseñar su estrategia de web agéntica sin caer en el hype. Protocolos como AP2 son justamente el tipo de infraestructura que conviene entender pronto y adoptar con criterio: temprano en la comprensión, prudente en la puesta en producción.
Somos Flutter Partner oficial de Google desde 2017, la única agencia española en el directorio, con equipo senior in-house en Barcelona y Andorra y más de 300 proyectos a la espalda. Si quieres evaluar qué significa el comercio agéntico para tu producto financiero —y qué NO deberías construir todavía—, hablemos.
