Para un CFO, la idea de un agente autónomo autorizando pagos genera una desconfianza justificada. No se trata de un miedo infundado: permitir que un modelo de lenguaje gestione tesorería parece una temeridad cuando estos sistemas aún arrastran alucinaciones. La cuestión no es si la IA realizará compras por cuenta de tu empresa, pues eso es inevitable, sino si habrás levantado las salvaguardas necesarias antes de que la autonomía se desboque. El 16 de septiembre de 2025, Google presentó el Agent Payments Protocol (AP2), un estándar abierto para resolver este dilema. Su objetivo es habilitar transacciones mediante mandatos criptográficos, garantizando trazabilidad y límites financieros sin ceder el control. Más allá del ruido comercial, estamos ante una arquitectura que definirá el gobierno de la IA en 2026. En NextAI advertimos que la autonomía sin supervisión es solo deuda técnica acumulada. El AP2 permite mitigar este riesgo, pero su despliegue exige un Cerebro Empresarial capaz de certificar qué modelo, qué prompt y qué contexto ejecutaron cada operación. Desglosamos el protocolo para convertir esta complejidad técnica en decisiones ejecutivas asumibles.

El problema real: agentes con tarjeta de crédito y sin freno de mano

La promesa comercial de los agentes de compras es seductora: reaprovisionamiento automático, renovación de suscripciones SaaS, gestión de reservas y microtransacciones de API sin que ningún humano tenga que aprobar cada línea. La proyección de BCG recogida por Oscilar apunta a que más del 50% del gasto en comercio electrónico —una cifra que superaría el billón de dólares— podría estar asistido o ejecutado por agentes de IA en los próximos años [Oscilar]. Ese volumen no es una curiosidad de laboratorio, es un cambio de categoría en cómo se mueve el dinero corporativo.

El obstáculo nunca ha sido técnico en el sentido estricto: un LLM puede generar una orden de compra en segundos. El obstáculo es la confianza. ¿Quién responde si el agente compra 500 licencias en vez de 5 porque interpretó mal una instrucción? ¿Cómo demuestras ante un auditor, un banco o un regulador que esa transacción fue autorizada y no una alucinación con consecuencias fiscales? Sin una capa de autorización verificable, cualquier despliegue de agentes con acceso a pagos es una apuesta, no una estrategia. Ya lo tratamos con detalle en nuestro análisis sobre seguridad de agentes de IA: permisos, límites y auditoría: sin permisos granulares y límites duros, la autonomía se convierte en superficie de riesgo, no en eficiencia.

AP2 nace exactamente para cerrar ese hueco. No sustituye los rieles de pago existentes —tarjetas, transferencias SEPA, Bizum, Redsys— sino que se monta encima de ellos como una capa de autorización y prueba. La pregunta que debe hacerse un directivo no es "¿debo usar AP2?", sino "¿tengo ya la infraestructura de gobierno que este tipo de protocolo exige como requisito previo?".

Qué es realmente el protocolo AP2

AP2 se diseñó como una extensión de dos protocolos que ya circulan en el ecosistema de agentes: Agent2Agent (A2A), que permite que agentes de compra y agentes de venta dialoguen entre sí, y Model Context Protocol (MCP), que da a un agente acceso a herramientas y APIs externas. AP2 no compite con ninguno de los dos: formaliza la pieza que faltaba, la capa de autorización criptográfica y no repudio que convierte una conversación entre agentes en una transacción legalmente atribuible.

La gobernanza del estándar, además, no ha quedado en manos de Google en solitario. Se ha donado a la FIDO Alliance —la misma organización que impulsa WebAuthn y las passkeys— precisamente para garantizar neutralidad de mercado y facilitar la adopción bancaria. Esa cesión no es un detalle simbólico: es la señal de que el protocolo aspira a convertirse en infraestructura, no en un producto propietario de un solo proveedor.

Los mandatos: Intent Mandate y Cart Mandate

El mecanismo de confianza de AP2 se apoya en "mandatos" digitales firmados criptográficamente mediante Credenciales Verificables (Verifiable Credentials, VC). Son, en esencia, contratos de dos fases:

• Intent Mandate: autoriza la búsqueda y la intención de compra. Aquí es donde se fijan los límites de presupuesto, la ventana temporal y las categorías de proveedor permitidas. Es la correa corta que impide que el agente decida por su cuenta qué comprar sin restricciones.
• Cart Mandate: aprueba la compra concreta, vinculada criptográficamente a una cesta de productos específica, con precio y condiciones cerradas. No hay margen de interpretación: o el carrito coincide exactamente con lo autorizado, o la transacción no se ejecuta.

Esta separación en dos fases resuelve un problema muy concreto que atormenta a cualquier responsable de sistemas: desacopla la lógica de pago del propio modelo de lenguaje. El LLM puede alucinar un producto, un precio o un proveedor, pero la transacción solo se consuma si existe un mandato firmado que la respalde. La alucinación deja de ser un riesgo financiero directo para convertirse en un fallo de proceso detectable antes de que el dinero se mueva.

Rieles tradicionales y la extensión Web3

AP2 incluye soporte nativo para rieles de pago tradicionales —tarjetas, transferencias bancarias en tiempo real— y, mediante la extensión A2A x402 desarrollada con Coinbase, MetaMask y la Fundación Ethereum, también para transacciones en criptomonedas. En su fase inicial de lanzamiento, el protocolo contó con el respaldo de más de 60 comercios y entidades tecnológicas y financieras, entre ellas Mastercard, American Express, PayPal, EigenCloud, Forter y Fiuu. Es un ecosistema de arranque notable para un estándar recién nacido, y explica por qué empieza a aparecer en las conversaciones de los departamentos de riesgo financiero antes incluso de tener versión estable.

Cuánto hay de estándar maduro y cuánto de fase experimental

Aquí es donde conviene bajar el entusiasmo un par de grados. Las notas de prensa —las de Google incluidas— presentan AP2 como un protocolo listo para producción. Las fuentes técnicas y de seguridad dicen otra cosa: el estándar sigue en fases tempranas de especificación, con versiones preestables como la v0.2, y la recomendación generalizada es limitarse a pruebas de concepto en entornos controlados, no a infraestructura crítica de tesorería.

Hay además una confusión conceptual que conviene desmontar: AP2 no es una red de pago alternativa ni una pasarela que sustituya a las existentes. Es una capa de transporte de credenciales, delegación y mandatos criptográficos que se asienta sobre los rieles bancarios y protocolos que ya usas. Quien te venda AP2 como "la nueva Visa de los agentes" no ha leído la especificación.

Esta tabla no es un matiz académico. Es la diferencia entre conectar AP2 a tu cuenta bancaria principal el mes que viene o dedicar 2026 a una fase de sandbox bien diseñada mientras el estándar termina de asentarse bajo la gobernanza de FIDO Alliance.

Los cuatro ángulos que todo CFO debe entender

Técnica e interoperabilidad

Ya lo hemos dicho: AP2 no compite con MCP ni con A2A, los completa. MCP da al agente las manos —acceso a herramientas y APIs—; A2A le da la voz —el diálogo entre agente comprador y agente vendedor—; AP2 le da la firma —la autorización criptográfica que convierte esa conversación en una transacción atribuible y no repudiable. Quien evalúe proveedores de agentes de compras en 2026 debe preguntar explícitamente por cuál de las tres capas cubre cada uno, porque la mayoría de los pitches comerciales las mezclan sin distinguirlas.

Económica: coste total y retorno

Aquí conviene gestionar expectativas. El retorno a corto plazo no llegará de abrir la mano y dejar que los agentes paguen sin supervisión. Llegará de reducir la fricción en escenarios "human-in-the-loop": el agente prepara el Cart Mandate completo —proveedor, precio, condiciones— y un humano lo aprueba con un clic y credenciales reforzadas, en lugar de rellenar un formulario de compra desde cero. Ese ahorro de tiempo administrativo es real y medible hoy. Donde el impacto económico se vuelve más contundente es en la automatización B2B recurrente: aprovisionamiento de suministros, microtransacciones de consumo de API y renovación de suscripciones SaaS de bajo riesgo. Ahí el volumen de operaciones repetitivas hace que cada segundo de fricción eliminado se multiplique.

Riesgo, seguridad y gobierno

Un agente que ejecuta pagos deja de ser una curiosidad técnica y pasa a ser, bajo el AI Act, un sistema de potencial alto impacto operacional si influye en decisiones financieras corporativas directas. La directiva DORA de resiliencia operativa digital y el futuro marco PSD3 exigen que toda transacción sea auditable y atribuible a un responsable identificable; la firma mediante Credenciales Verificables de AP2 aporta precisamente ese log forense no repudiable que un supervisor bancario puede exigir. Desde el RGPD, el Intent Mandate debe minimizar los datos personales que viajan hacia el comercio y evitar que se infieran perfiles financieros no autorizados a partir del histórico de compras. Si tu empresa ya se ha planteado qué obligaciones concretas le tocan bajo el reglamento europeo, conviene repasar antes qué exige realmente el AI Act a las empresas: la clasificación de riesgo de un agente de pagos no es opcional, es un ejercicio de cumplimiento con fecha límite.

Operación real en empresas españolas

La mayoría de las medianas empresas españolas corre sobre SAP Business One, Navision o Sage. Ninguno de estos ERP procesa de forma nativa transacciones autónomas iniciadas por un agente de IA. La adopción realista de AP2 no es "conectar el agente al banco": es construir una pasarela intermedia conectada al Cerebro Empresarial donde se fijen límites duros de gasto, centros de coste aprobados y reglas de conciliación automática antes de que ningún mandato llegue a Bizum, Redsys o una transferencia SEPA. Sin esa capa intermedia, AP2 es una especificación interesante que no toca tu operación diaria.

Bloque de datos: dónde está realmente el estándar hoy

Leyenda: cada bloque █ representa progreso relativo dentro de su propia métrica; no son magnitudes comparables entre filas. Fuente de cifras: Oscilar (proyección BCG) e ITNow/Dribba (ecosistema y versión del estándar).

De la especificación a tu gobierno de IA

Delegar presupuesto a una máquina no es un acto de confianza ciega, es un acto de ingeniería: solo puedes autorizar lo que puedes auditar.

Esa frase resume por qué AP2 nos interesa más como excusa de gobierno que como novedad técnica. En NextAI llamamos Cerebro Empresarial a la memoria corporativa auditable —construida con RAG y grafos de conocimiento— que permite reconstruir, para cualquier decisión automatizada, qué modelo, qué prompt y qué contexto la generaron. Sin ese Cerebro, ningún mandato firmado sirve de nada: puedes tener la firma criptográfica perfecta y seguir sin saber por qué el agente decidió comprar lo que compró.

Un Superagente —un agente que se hace cargo de un proceso completo, no de una tarea suelta— es exactamente el tipo de sistema que necesitaría acceso a AP2 para ejecutar aprovisionamiento de principio a fin. Y aquí entra una métrica que usamos para decidir cuánta autonomía real conceder: el RAO, o Ratio de Autonomía Operativa, que mide de cada 100 ejecuciones de un proceso cuántas terminan sin intervención humana. Para procesos de pago, un RAO alto no es necesariamente el objetivo deseable en 2026: el objetivo es un RAO calibrado, donde el Cart Mandate se prepara solo y la aprobación humana sigue existiendo para los importes que de verdad importan. El eje de gobierno del IMAN —nuestro Índice de Madurez AI-Native— mide precisamente si una empresa tiene la trazabilidad necesaria para subir ese RAO sin perder el control.

Pasos concretos para llegar a ese punto sin exponerte:

1. Audita tu ERP actual y confirma si soporta o no la recepción de mandatos externos antes de prometer nada a dirección.
2. Define el Intent Mandate por categoría de gasto: topes monetarios estrictos, listas blancas de proveedores, ventanas temporales cerradas.
3. Crea o actualiza tu registro de agentes con permisos y límites documentados, no en un Excel disperso entre departamentos.
4. Despliega AP2 en modo sandbox durante 2026, limitado a microservicios de bajo riesgo: suscripciones SaaS menores, consumo de API.
5. Revisa con tu asesoría legal qué obligaciones de DORA y AI Act aplican antes de conectar cualquier mandato a tesorería principal.

Qué significa para tu empresa

No todas las empresas deben moverse al mismo ritmo. Los criterios de decisión dependen de tres factores: tu nivel actual en el eje de gobierno del IMAN, el RAO objetivo realista para cada proceso de gasto y el tipo de partida que estás dispuesto a delegar.

Antes de decidir cuánta autonomía conceder a un agente en concreto, conviene aplicar el marco de 4 niveles de supervisión humana: un agente que prepara Cart Mandates no necesita el mismo nivel de vigilancia que uno que los ejecuta sin revisión. Y antes de habilitar cualquier mandato hacia un banco o pasarela, asegúrate de que tu empresa mantiene un registro de agentes de IA actualizado y auditable, porque ese registro es lo primero que va a pedir cualquier auditor de DORA o cualquier banco antes de aceptar transacciones firmadas por una máquina.

Metodología y fuentes

El laboratorio de NextAI ha contrastado el anuncio oficial de Google con análisis técnicos de seguridad y con proyecciones de mercado independientes, separando en cada caso lo que es especificación verificada de lo que es interpretación comercial todavía prematura. Para la arquitectura de mandatos y la extensión Web3 nos apoyamos en el anuncio de Google Cloud Blog; para el encaje con MCP, A2A y el estado real de la especificación, en el análisis de Dribba; para el marco de seguridad y verificación de identidad agéntica, en Cloud Security Alliance; y para las proyecciones de mercado, en Oscilar.

Preguntas frecuentes

¿Qué es el protocolo AP2?

Es un estándar abierto anunciado por Google en septiembre de 2025 que permite a los agentes de IA ejecutar transacciones de pago de forma segura, mediante mandatos digitales firmados criptográficamente. No sustituye tarjetas ni transferencias bancarias: añade una capa de autorización verificable sobre los rieles de pago existentes.

¿Es seguro dar acceso a pagos a un agente de IA ya?

En su estado actual, con la especificación en versión preestable v0.2, la recomendación técnica es limitarse a pruebas de concepto en entornos no críticos, como suscripciones SaaS menores o consumo de API. Conectar AP2 directamente a tesorería principal en 2026 sería prematuro según las propias fuentes de seguridad del ecosistema.

¿Cómo se relaciona AP2 con el AI Act europeo?

Un agente que ejecuta pagos puede clasificarse como sistema de alto impacto operacional si influye en decisiones financieras corporativas directas. AP2 no exime de esa clasificación: aporta el log forense no repudiable que exigen el AI Act, DORA y el futuro marco PSD3 para atribuir responsabilidad ante un error.

¿Qué diferencia hay entre AP2, MCP y A2A?

MCP da al agente acceso a herramientas y APIs; A2A permite el diálogo entre agentes compradores y vendedores; AP2 formaliza la autorización criptográfica y el no repudio de la transacción final. Son capas complementarias, no protocolos competidores, y un despliegue serio de agentes de compra necesita las tres.

Qué hacer con esto

La implementación exige rigor. Clasifica tus procesos de gasto según el RAO real y no según la capacidad técnica de la herramienta. Antes de cualquier integración, verifica si tu infraestructura bancaria y tu ERP soportan mandatos externos. Asegura la trazabilidad integral de tus agentes, ya que sin el registro de modelos y contextos, la criptografía es inútil ante el error. Limita el uso a entornos sandbox durante 2026 y reevalúa tu perfil de riesgo bajo el AI Act antes de escalar a producción. Pide tu Auditoría Digital — 45 minutos, sin presentación comercial.