Protocolo de Pagos de Agentes (AP2) de Google

El Protocolo de Pagos de Agentes (AP2) de Google es un estándar abierto recientemente anunciado, diseñado para permitir transacciones seguras y confiables iniciadas por agentes de IA en nombre de los usuarios. Desarrollado en colaboración con más de 60 organizaciones de pagos y tecnología (incluyendo las principales redes de pago, bancos, fintechs y empresas Web3), AP2 establece un lenguaje común para los pagos "agéneticos", es decir, compras y transacciones financieras que un agente autónomo (como un asistente de IA o un agente basado en LLM) puede realizar para un usuario. La creación de AP2 está impulsada por un cambio fundamental: tradicionalmente, los sistemas de pago en línea asumían que un humano hacía clic directamente en "comprar", pero el auge de los agentes de IA que actúan según las instrucciones del usuario rompe esta suposición. AP2 aborda los desafíos resultantes de autorización, autenticidad y rendición de cuentas en el comercio impulsado por IA, al tiempo que sigue siendo compatible con la infraestructura de pago existente. Este informe examina la arquitectura técnica de AP2, su propósito y casos de uso, integraciones con agentes de IA y proveedores de pago, consideraciones de seguridad y cumplimiento, comparaciones con protocolos existentes, implicaciones para Web3/sistemas descentralizados, y la adopción/hoja de ruta de la industria.

Arquitectura Técnica: Cómo Funciona AP2

En su esencia, AP2 introduce un marco de transacciones criptográficamente seguro construido sobre credenciales digitales verificables (VDC), que son esencialmente objetos de datos firmados e inalterables que sirven como "contratos" digitales de lo que el usuario ha autorizado. En la terminología de AP2, estos contratos se denominan Mandatos, y forman una cadena de evidencia auditable para cada transacción. Hay tres tipos principales de mandatos en la arquitectura de AP2:

• Mandato de Intención: Captura las instrucciones o condiciones iniciales del usuario para una compra, especialmente para escenarios “sin presencia humana” (donde el agente actuará más tarde sin que el usuario esté en línea). Define el alcance de la autoridad que el usuario otorga al agente; por ejemplo, “Comprar entradas para el concierto si bajan de $200, hasta 2 entradas”. Este mandato es firmado criptográficamente por adelantado por el usuario y sirve como prueba verificable de consentimiento dentro de límites específicos.
• Mandato de Carrito: Representa los detalles finales de la transacción que el usuario ha aprobado, utilizado en escenarios “con presencia humana” o en el momento del pago. Incluye los artículos o servicios exactos, su precio y otros detalles de la compra. Cuando el agente está listo para completar la transacción (por ejemplo, después de llenar un carrito de compras), el comerciante primero firma criptográficamente el contenido del carrito (garantizando los detalles del pedido y el precio), y luego el usuario (a través de su dispositivo o interfaz de agente) aprueba para crear un Mandato de Carrito. Esto asegura lo que ves es lo que pagas, fijando el pedido final exactamente como se le presentó al usuario.
• Mandato de Pago: Una credencial separada que se envía a la red de pago (por ejemplo, red de tarjetas o banco) para indicar que un agente de IA está involucrado en la transacción. El Mandato de Pago incluye metadatos como si el usuario estuvo presente o no durante la autorización y sirve como una bandera para los sistemas de gestión de riesgos. Al proporcionar a los bancos adquirentes y emisores evidencia criptográficamente verificable de la intención del usuario, este mandato les ayuda a evaluar el contexto (por ejemplo, distinguir una compra iniciada por un agente de un fraude típico) y gestionar el cumplimiento o la responsabilidad en consecuencia.

Todos los mandatos se implementan como credenciales verificables firmadas por las claves de la parte relevante (usuario, comerciante, etc.), lo que produce una pista de auditoría no repudiable para cada transacción dirigida por un agente. En la práctica, AP2 utiliza una arquitectura basada en roles para proteger la información sensible; por ejemplo, un agente podría manejar un Mandato de Intención sin ver nunca los detalles de pago sin procesar, que solo se revelan de forma controlada cuando es necesario, preservando la privacidad. La cadena criptográfica de intención del usuario → compromiso del comerciante → autorización de pago establece la confianza entre todas las partes de que la transacción refleja las verdaderas instrucciones del usuario y de que tanto el agente como el comerciante se adhirieron a esas instrucciones.

Flujo de Transacción: Para ilustrar cómo funciona AP2 de principio a fin, considere un escenario de compra simple con un humano en el bucle:

1. Solicitud del Usuario: El usuario le pide a su agente de IA que compre un artículo o servicio en particular (por ejemplo, “Pide este par de zapatos en mi talla”).
2. Construcción del Carrito: El agente se comunica con los sistemas del comerciante (utilizando API estándar o mediante una interacción agente-a-agente) para armar un carrito de compras para el artículo especificado a un precio determinado.
3. Garantía del Comerciante: Antes de presentar el carrito al usuario, el lado del comerciante firma criptográficamente los detalles del carrito (artículo, cantidad, precio, etc.). Este paso crea una oferta firmada por el comerciante que garantiza los términos exactos (evitando cualquier cambio oculto o manipulación de precios).
4. Aprobación del Usuario: El agente muestra al usuario el carrito finalizado. El usuario confirma la compra, y esta aprobación desencadena dos firmas criptográficas del lado del usuario: una en el Mandato de Carrito (para aceptar el carrito del comerciante tal cual) y otra en el Mandato de Pago (para autorizar el pago a través del proveedor de pago elegido). Estos mandatos firmados se comparten luego con el comerciante y la red de pago, respectivamente.
5. Ejecución: Armados con el Mandato de Carrito y el Mandato de Pago, el comerciante y el proveedor de pago proceden a ejecutar la transacción de forma segura. Por ejemplo, el comerciante envía la solicitud de pago junto con la prueba de aprobación del usuario a la red de pago (red de tarjetas, banco, etc.), que puede verificar el Mandato de Pago. El resultado es una transacción de compra completada con una pista de auditoría criptográfica que vincula la intención del usuario con el pago final.

Este flujo demuestra cómo AP2 construye confianza en cada paso de una compra impulsada por IA. El comerciante tiene prueba criptográfica de exactamente lo que el usuario acordó comprar y a qué precio, y el emisor/banco tiene prueba de que el usuario autorizó ese pago, aunque un agente de IA facilitó el proceso. En caso de disputas o errores, los mandatos firmados actúan como evidencia clara, ayudando a determinar la responsabilidad (por ejemplo, si el agente se desvió de las instrucciones o si un cargo no fue lo que el usuario aprobó). En esencia, la arquitectura de AP2 asegura que la intención verificable del usuario – en lugar de la confianza en el comportamiento del agente – sea la base de la transacción, reduciendo en gran medida la ambigüedad.

Propósito y Casos de Uso para AP2

Por qué se necesita AP2: El propósito principal de AP2 es resolver los problemas emergentes de confianza y seguridad que surgen cuando los agentes de IA pueden gastar dinero en nombre de los usuarios. Google y sus socios identificaron varias preguntas clave que la infraestructura de pago actual no puede responder adecuadamente cuando un agente autónomo está involucrado:

• Autorización: ¿Cómo probar que un usuario realmente le dio permiso al agente para realizar una compra específica? (En otras palabras, asegurar que el agente no esté comprando cosas sin el consentimiento informado del usuario).
• Autenticidad: ¿Cómo puede un comerciante saber que la solicitud de compra de un agente es genuina y refleja la verdadera intención del usuario, en lugar de un error o una alucinación de la IA?
• Rendición de Cuentas: Si ocurre una transacción fraudulenta o incorrecta a través de un agente, ¿quién es el responsable: el usuario, el comerciante, el proveedor de pago o el creador del agente de IA?

Sin una solución, estas incertidumbres crean una "crisis de confianza" en torno al comercio dirigido por agentes. La misión de AP2 es proporcionar esa solución estableciendo un protocolo uniforme para transacciones seguras de agentes. Al introducir mandatos estandarizados y pruebas de intención, AP2 evita un ecosistema fragmentado donde cada empresa inventa sus propios métodos de pago de agentes ad-hoc. En cambio, cualquier agente de IA compatible puede interactuar con cualquier comerciante/proveedor de pago compatible bajo un conjunto común de reglas y verificaciones. Esta consistencia no solo evita la confusión del usuario y del comerciante, sino que también brinda a las instituciones financieras una forma clara de gestionar el riesgo para los pagos iniciados por agentes, en lugar de lidiar con un mosaico de enfoques propietarios. En resumen, el propósito de AP2 es ser una capa de confianza fundamental que permita que la "economía de agentes" crezca sin romper el ecosistema de pagos.

Casos de Uso Previstos: Al resolver los problemas anteriores, AP2 abre la puerta a nuevas experiencias comerciales y casos de uso que van más allá de lo que es posible con un humano haciendo clic manualmente en las compras. Algunos ejemplos de comercio habilitado por agentes que AP2 admite incluyen:

• Compras más Inteligentes: Un cliente puede instruir a su agente: “Quiero esta chaqueta de invierno en verde, y estoy dispuesto a pagar hasta un 20% por encima del precio actual por ella”. Armado con un Mandato de Intención que codifica estas condiciones, el agente monitoreará continuamente los sitios web o bases de datos de los minoristas. En el momento en que la chaqueta esté disponible en verde (y dentro del umbral de precio), el agente ejecuta automáticamente una compra con una transacción segura y firmada, capturando una venta que de otro modo se habría perdido. Toda la interacción, desde la solicitud inicial del usuario hasta el pago automatizado, se rige por los mandatos de AP2, lo que garantiza que el agente solo compre exactamente lo que se autorizó.
• Ofertas Personalizadas: Un usuario le dice a su agente que está buscando un producto específico (por ejemplo, una bicicleta nueva) de un comerciante en particular para un próximo viaje. El agente puede compartir este interés (dentro de los límites de un Mandato de Intención) con el propio agente de IA del comerciante, incluyendo el contexto relevante como la fecha del viaje. El agente del comerciante, conociendo la intención y el contexto del usuario, podría responder con un paquete o descuento personalizado, por ejemplo, “bicicleta + casco + portaequipajes con un 15% de descuento, disponible durante las próximas 48 horas”. Usando AP2, el agente del usuario puede aceptar y completar esta oferta personalizada de forma segura, convirtiendo una simple consulta en una venta más valiosa para el comerciante.
• Tareas Coordinadas: Un usuario que planifica una tarea compleja (por ejemplo, un viaje de fin de semana) la delega por completo: “Resérvame un vuelo y un hotel para estas fechas con un presupuesto total de $700”. El agente puede interactuar con los agentes de múltiples proveedores de servicios (aerolíneas, hoteles, plataformas de viaje) para encontrar una combinación que se ajuste al presupuesto. Una vez que se identifica un paquete de vuelo y hotel adecuado, el agente utiliza AP2 para ejecutar múltiples reservas de una sola vez, cada una firmada criptográficamente (por ejemplo, emitiendo Mandatos de Carrito separados para la aerolínea y el hotel, ambos autorizados bajo el Mandato de Intención del usuario). AP2 garantiza que todas las partes de esta transacción coordinada ocurran según lo aprobado, e incluso permite la ejecución simultánea para que los boletos y las reservas se realicen juntos sin riesgo de que una parte falle a mitad de camino.

Estos escenarios ilustran solo algunos de los casos de uso previstos de AP2. De manera más amplia, el diseño flexible de AP2 admite tanto los flujos de comercio electrónico convencionales como modelos de comercio completamente nuevos. Por ejemplo, AP2 puede facilitar servicios tipo suscripción (un agente te mantiene abastecido de elementos esenciales comprando cuando se cumplen las condiciones), compras impulsadas por eventos (comprar entradas o artículos en el instante en que ocurre un evento desencadenante), negociaciones de agentes grupales (agentes de múltiples usuarios agrupando mandatos para negociar un acuerdo grupal), y muchos otros patrones emergentes. En cada caso, el hilo conductor es que AP2 proporciona el marco de confianza – autorización clara del usuario y auditabilidad criptográfica – que permite que estas transacciones impulsadas por agentes se realicen de forma segura. Al manejar la capa de confianza y verificación, AP2 permite a los desarrolladores y empresas centrarse en innovar nuevas experiencias de comercio de IA sin reinventar la seguridad de los pagos desde cero.

Integración con Agentes, LLMs y Proveedores de Pago

AP2 está explícitamente diseñado para integrarse sin problemas con los frameworks de agentes de IA y con los sistemas de pago existentes, actuando como un puente entre ambos. Google ha posicionado AP2 como una extensión de sus estándares de protocolo Agent2Agent (A2A) y Model Context Protocol (MCP). En otras palabras, si A2A proporciona un lenguaje genérico para que los agentes comuniquen tareas y MCP estandariza cómo los modelos de IA incorporan contexto/herramientas, entonces AP2 añade una capa de transacciones encima para el comercio. Los protocolos son complementarios: A2A maneja la comunicación agente-a-agente (permitiendo, por ejemplo, que un agente de compras hable con el agente de un comerciante), mientras que AP2 maneja la autorización de pago agente-a-comerciante dentro de esas interacciones. Debido a que AP2 es abierto y no propietario, está diseñado para ser agnóstico al framework: los desarrolladores pueden usarlo con el propio Kit de Desarrollo de Agentes (ADK) de Google o cualquier biblioteca de agentes de IA, y de manera similar puede funcionar con varios modelos de IA, incluyendo LLMs. Un agente basado en LLM, por ejemplo, podría usar AP2 generando e intercambiando las cargas útiles de mandato requeridas (guiado por la especificación AP2) en lugar de solo texto de forma libre. Al imponer un protocolo estructurado, AP2 ayuda a transformar la intención de alto nivel de un agente de IA (que podría provenir del razonamiento de un LLM) en transacciones concretas y seguras.

En el lado de los pagos, AP2 fue construido en concierto con los proveedores y estándares de pago tradicionales, en lugar de como un sistema de reemplazo. El protocolo es agnóstico al método de pago, lo que significa que puede admitir una variedad de rieles de pago – desde redes de tarjetas de crédito/débito hasta transferencias bancarias y billeteras digitales – como método subyacente para mover fondos. En su versión inicial, AP2 enfatiza la compatibilidad con pagos con tarjeta, ya que son los más comunes en el comercio en línea. El Mandato de Pago de AP2 está diseñado para conectarse al flujo de procesamiento de tarjetas existente: proporciona datos adicionales a la red de pago (por ejemplo, Visa, Mastercard, Amex) y al banco emisor de que un agente de IA está involucrado y si el usuario estuvo presente, complementando así los controles de detección de fraude y autorización existentes. Esencialmente, AP2 no procesa el pago en sí; aumenta la solicitud de pago con prueba criptográfica de la intención del usuario. Esto permite a los proveedores de pago tratar las transacciones iniciadas por agentes con la precaución o velocidad adecuadas (por ejemplo, un emisor podría aprobar una compra de aspecto inusual si ve un mandato AP2 válido que demuestre que el usuario la pre-aprobó). En particular, Google y sus socios planean evolucionar AP2 para admitir también métodos de pago "push" – como transferencias bancarias en tiempo real (como los sistemas UPI de India o PIX de Brasil) – y otros tipos de pagos digitales emergentes. Esto indica que la integración de AP2 se expandirá más allá de las tarjetas, alineándose con las tendencias de pago modernas en todo el mundo.

Para los comerciantes y procesadores de pagos, integrar AP2 significaría admitir los mensajes de protocolo adicionales (mandatos) y verificar las firmas. Muchas grandes plataformas de pago ya están involucradas en la configuración de AP2, por lo que podemos esperar que desarrollen soporte para ello. Por ejemplo, empresas como Adyen, Worldpay, Paypal, Stripe (no mencionadas explícitamente en el blog pero probablemente interesadas) y otras podrían incorporar AP2 en sus API o SDK de pago, permitiendo que un agente inicie un pago de manera estandarizada. Debido a que AP2 es una especificación abierta en GitHub con implementaciones de referencia, los proveedores de pago y las plataformas tecnológicas pueden comenzar a experimentar con ella de inmediato. Google también ha mencionado un Mercado de Agentes de IA donde se pueden listar agentes de terceros; se espera que estos agentes admitan AP2 para cualquier capacidad transaccional. En la práctica, una empresa que construye un asistente de ventas de IA o un agente de adquisiciones podría listarlo en este mercado, y gracias a AP2, ese agente puede realizar compras u pedidos de manera confiable.

Finalmente, la historia de integración de AP2 se beneficia de su amplio respaldo de la industria. Al codesarrollar el protocolo con las principales instituciones financieras y empresas tecnológicas, Google se aseguró de que AP2 se alinee con las reglas y requisitos de cumplimiento existentes de la industria. La colaboración con redes de pago (por ejemplo, Mastercard, UnionPay), emisores (por ejemplo, American Express), fintechs (por ejemplo, Revolut, Paypal), actores de comercio electrónico (por ejemplo, Etsy) e incluso proveedores de identidad/seguridad (por ejemplo, Okta, Cloudflare) sugiere que AP2 está siendo diseñado para encajar en sistemas del mundo real con una fricción mínima. Estos stakeholders aportan experiencia en áreas como KYC (regulaciones Conozca a su Cliente), prevención de fraude y privacidad de datos, lo que ayuda a AP2 a abordar esas necesidades de forma predeterminada. En resumen, AP2 está construido para ser amigable para agentes y amigable para proveedores de pago: extiende los protocolos de agentes de IA existentes para manejar transacciones, y se superpone a las redes de pago existentes para utilizar su infraestructura mientras agrega las garantías de confianza necesarias.

Consideraciones de Seguridad, Cumplimiento e Interoperabilidad

La seguridad y la confianza son el corazón del diseño de AP2. El uso de criptografía por parte del protocolo (firmas digitales en los mandatos) garantiza que cada acción crítica en una transacción agénetica sea verificable y rastreable. Este no repudio es crucial: ni el usuario ni el comerciante pueden negar posteriormente lo que se autorizó y acordó, ya que los mandatos sirven como registros seguros. Un beneficio directo es la prevención de fraude y la resolución de disputas: con AP2, si un agente malicioso o con errores intenta una compra no autorizada, la falta de un mandato válido firmado por el usuario sería evidente, y la transacción puede ser rechazada o revertida. Por el contrario, si un usuario afirma "Nunca aprobé esta compra", pero existe un Mandato de Carrito con su firma criptográfica, el comerciante y el emisor tienen pruebas sólidas para respaldar el cargo. Esta claridad de responsabilidad responde a una importante preocupación de cumplimiento para la industria de pagos.

Autorización y Privacidad: AP2 impone un paso (o pasos) de autorización explícita del usuario para las transacciones dirigidas por agentes, lo que se alinea con las tendencias regulatorias como la autenticación fuerte del cliente. El principio de Control del Usuario incorporado en AP2 significa que un agente no puede gastar fondos a menos que el usuario (o alguien delegado por el usuario) haya proporcionado una instrucción verificable para hacerlo. Incluso en escenarios totalmente autónomos, el usuario predefine las reglas a través de un Mandato de Intención. Este enfoque puede verse como análogo a otorgar un poder notarial al agente para transacciones específicas, pero de una manera digitalmente firmada y granular. Desde una perspectiva de privacidad, AP2 es consciente del intercambio de datos: el protocolo utiliza una arquitectura de datos basada en roles para garantizar que la información sensible (como credenciales de pago o detalles personales) solo se comparta con las partes que la necesitan absolutamente. Por ejemplo, un agente podría enviar un Mandato de Carrito a un comerciante que contenga información de artículos y precios, pero el número de tarjeta real del usuario solo podría compartirse a través del Mandato de Pago con el procesador de pagos, no con el agente o el comerciante. Esto minimiza la exposición innecesaria de datos, lo que ayuda al cumplimiento de las leyes de privacidad y las reglas PCI-DSS para el manejo de datos de pago.

Cumplimiento y Estándares: Debido a que AP2 se desarrolló con la aportación de entidades financieras establecidas, ha sido diseñado para cumplir o complementar los estándares de cumplimiento existentes en los pagos. El protocolo no elude los flujos de autorización de pago habituales; en cambio, los aumenta con evidencia y banderas adicionales. Esto significa que las transacciones de AP2 aún pueden aprovechar los sistemas de detección de fraude, los controles 3-D Secure o cualquier control regulatorio requerido, con los mandatos de AP2 actuando como factores de autenticación adicionales o señales de contexto. Por ejemplo, un banco podría tratar un Mandato de Pago como una firma digital del cliente en una transacción, lo que podría agilizar el cumplimiento de los requisitos de consentimiento del usuario. Además, los diseñadores de AP2 mencionan explícitamente trabajar "en concierto con las reglas y estándares de la industria". Podemos inferir que, a medida que AP2 evolucione, podría ser llevado a organismos de estándares formales (como el W3C, EMVCo o ISO) para garantizar que se alinee con los estándares financieros globales. Google ha declarado su compromiso con una evolución abierta y colaborativa de AP2, posiblemente a través de organizaciones de estándares. Este proceso abierto ayudará a resolver cualquier preocupación regulatoria y a lograr una amplia aceptación, de manera similar a cómo los estándares de pago anteriores (tarjetas con chip EMV, 3-D Secure, etc.) se sometieron a una colaboración a nivel de la industria.

Interoperabilidad: Evitar la fragmentación es un objetivo clave de AP2. Para ello, el protocolo se publica abiertamente y está disponible para que cualquiera lo implemente o integre. No está vinculado a los servicios de Google Cloud; de hecho, AP2 es de código abierto (licencia Apache-2) y la especificación más el código de referencia están en un repositorio público de GitHub. Esto fomenta la interoperabilidad porque múltiples proveedores pueden adoptar AP2 y aún así hacer que sus sistemas funcionen juntos. Ya se destaca el principio de interoperabilidad: AP2 es una extensión de protocolos abiertos existentes (A2A, MCP) y no es propietario, lo que significa que fomenta un ecosistema competitivo de implementaciones en lugar de una solución de un solo proveedor. En términos prácticos, un agente de IA construido por la Compañía A podría iniciar una transacción con un sistema de comerciante de la Compañía B si ambos siguen AP2; ninguna de las partes está bloqueada en una sola plataforma.

Una posible preocupación es asegurar una adopción consistente: si algunos actores importantes eligieran un protocolo diferente o un enfoque cerrado, la fragmentación aún podría ocurrir. Sin embargo, dada la amplia coalición detrás de AP2, parece estar preparado para convertirse en un estándar de facto. La inclusión de muchas empresas centradas en la identidad y la seguridad (por ejemplo, Okta, Cloudflare, Ping Identity) en el ecosistema de AP2 Figura: Más de 60 empresas de finanzas, tecnología y cripto están colaborando en AP2 (lista parcial de socios). sugiere que la interoperabilidad y la seguridad se están abordando conjuntamente. Estos socios pueden ayudar a integrar AP2 en los flujos de trabajo de verificación de identidad y las herramientas de prevención de fraude, asegurando que una transacción de AP2 pueda ser confiable en todos los sistemas.

Desde el punto de vista tecnológico, el uso de técnicas criptográficas ampliamente aceptadas por AP2 (probablemente credenciales verificables basadas en JSON-LD o JWT, firmas de clave pública, etc.) lo hace compatible con la infraestructura de seguridad existente. Las organizaciones pueden usar su PKI (Infraestructura de Clave Pública) existente para administrar claves para firmar mandatos. AP2 también parece anticipar la integración con sistemas de identidad descentralizada: Google menciona que AP2 crea oportunidades para innovar en áreas como la identidad descentralizada para la autorización de agentes. Esto significa que, en el futuro, AP2 podría aprovechar los estándares DID (Identificador Descentralizado) o la verificación de identificadores descentralizados para identificar agentes y usuarios de manera confiable. Tal enfoque mejoraría aún más la interoperabilidad al no depender de ningún proveedor de identidad único. En resumen, AP2 enfatiza la seguridad a través de la criptografía y la responsabilidad clara, tiene como objetivo estar listo para el cumplimiento por diseño y promueve la interoperabilidad a través de su naturaleza de estándar abierto y el amplio apoyo de la industria.

Comparación con Protocolos Existentes

AP2 es un protocolo novedoso que aborda una brecha que los marcos de pago y agentes existentes no han cubierto: permitir que los agentes autónomos realicen pagos de manera segura y estandarizada. En términos de protocolos de comunicación de agentes, AP2 se basa en trabajos anteriores como el protocolo Agent2Agent (A2A). A2A (de código abierto a principios de 2025) permite que diferentes agentes de IA se comuniquen entre sí, independientemente de sus marcos subyacentes. Sin embargo, A2A por sí solo no define cómo los agentes deben realizar transacciones o pagos; se trata más de la negociación de tareas y el intercambio de datos. AP2 amplía este panorama al agregar una capa de transacción que cualquier agente puede usar cuando una conversación conduce a una compra. En esencia, AP2 puede verse como complementario a A2A y MCP, en lugar de superponerse: A2A cubre los aspectos de comunicación y colaboración, MCP cubre el uso de herramientas/API externas, y AP2 cubre pagos y comercio. Juntos, forman una pila de estándares para una futura "economía de agentes". Este enfoque modular es algo análogo a los protocolos de internet: por ejemplo, HTTP para la comunicación de datos y SSL/TLS para la seguridad; aquí A2A podría ser como el HTTP de los agentes, y AP2 la capa transaccional segura encima para el comercio.

Al comparar AP2 con los protocolos y estándares de pago tradicionales, existen tanto paralelismos como diferencias. Los pagos en línea tradicionales (pagos con tarjeta de crédito, transacciones de PayPal, etc.) suelen implicar protocolos como HTTPS para una transmisión segura, y estándares como PCI DSS para el manejo de datos de tarjetas, además de posiblemente 3-D Secure para una autenticación de usuario adicional. Estos asumen un flujo impulsado por el usuario (el usuario hace clic y quizás ingresa un código de un solo uso). AP2, por el contrario, introduce una forma para que un tercero (el agente) participe en el flujo sin socavar la seguridad. Se podría comparar el concepto de mandato de AP2 con una extensión de la autoridad delegada al estilo OAuth, pero aplicada a los pagos. En OAuth, un usuario puede otorgar a una aplicación acceso limitado a una cuenta a través de tokens; de manera similar en AP2, un usuario otorga a un agente autoridad para gastar bajo ciertas condiciones a través de mandatos. La diferencia clave es que los "tokens" de AP2 (mandatos) son instrucciones específicas y firmadas para transacciones financieras, lo que es más granular que las autorizaciones de pago existentes.

Otro punto de comparación es cómo AP2 se relaciona con los flujos de pago de comercio electrónico existentes. Por ejemplo, muchos sitios de comercio electrónico utilizan protocolos como la API de Solicitud de Pago de W3C o SDK específicos de la plataforma para agilizar los pagos. Estos principalmente estandarizan cómo los navegadores o aplicaciones recopilan información de pago de un usuario, mientras que AP2 estandariza cómo un agente probaría la intención del usuario a un comerciante y procesador de pagos. El enfoque de AP2 en la intención verificable y el no repudio lo distingue de las API de pago más simples. Está agregando una capa adicional de confianza sobre las redes de pago. Se podría decir que AP2 no está reemplazando las redes de pago (Visa, ACH, blockchain, etc.), sino que las está aumentando. El protocolo admite explícitamente todo tipo de métodos de pago (incluso cripto), por lo que se trata más de estandarizar la interacción del agente con estos sistemas, no de crear un nuevo riel de pago desde cero.

En el ámbito de los protocolos de seguridad y autenticación, AP2 comparte cierto espíritu con elementos como las firmas digitales en las tarjetas con chip EMV o la notarización en los contratos digitales. Por ejemplo, las transacciones con tarjeta con chip EMV generan criptogramas para probar que la tarjeta estuvo presente; AP2 genera pruebas criptográficas de que el agente del usuario fue autorizado. Ambos tienen como objetivo prevenir el fraude, pero el alcance de AP2 es la relación agente-usuario y la mensajería agente-comerciante, que ningún estándar de pago existente aborda. Otra comparación emergente es con la abstracción de cuentas en cripto (por ejemplo, ERC-4337), donde los usuarios pueden autorizar acciones de billetera preprogramadas. Las billeteras criptográficas se pueden configurar para permitir ciertas transacciones automatizadas (como el pago automático de una suscripción a través de un contrato inteligente), pero estas suelen estar confinadas a un entorno de blockchain. AP2, por otro lado, aspira a ser multiplataforma: puede aprovechar blockchain para algunos pagos (a través de sus extensiones) pero también funciona con bancos tradicionales.

Todavía no existe un protocolo "competidor" directo de AP2 en la industria de pagos convencional; parece ser el primer esfuerzo concertado para un estándar abierto para pagos de agentes de IA. Pueden surgir intentos propietarios (o ya pueden estar en curso dentro de empresas individuales), pero el amplio apoyo de AP2 le da una ventaja para convertirse en el estándar. Vale la pena señalar que IBM y otros tienen un Protocolo de Comunicación de Agentes (ACP) e iniciativas similares para la interoperabilidad de agentes, pero estas no abarcan el aspecto de pago de la manera integral en que lo hace AP2. En todo caso, AP2 podría integrarse o aprovechar esos esfuerzos (por ejemplo, los frameworks de agentes de IBM podrían implementar AP2 para cualquier tarea comercial).

En resumen, AP2 se distingue por apuntar a la intersección única de la IA y los pagos: donde los protocolos de pago más antiguos asumían un usuario humano, AP2 asume un intermediario de IA y llena la brecha de confianza que resulta. Extiende, en lugar de entrar en conflicto con, los procesos de pago existentes, y complementa los protocolos de agentes existentes como A2A. En el futuro, se podría ver a AP2 utilizándose junto con estándares establecidos; por ejemplo, un Mandato de Carrito de AP2 podría funcionar en conjunto con una llamada a la API de una pasarela de pago tradicional, o un Mandato de Pago de AP2 podría adjuntarse a un mensaje ISO 8583 en la banca. La naturaleza abierta de AP2 también significa que si surgen enfoques alternativos, AP2 podría potencialmente absorberlos o alinearse con ellos a través de la colaboración comunitaria. En esta etapa, AP2 está estableciendo una base que no existía antes, siendo efectivamente pionero en una nueva capa de protocolo en la pila de IA y pagos.

Implicaciones para Web3 y Sistemas Descentralizados

Desde el principio, AP2 ha sido diseñado para ser inclusivo de los pagos basados en Web3 y criptomonedas. El protocolo reconoce que el comercio futuro abarcará tanto los canales fiduciarios tradicionales como las redes blockchain descentralizadas. Como se señaló anteriormente, AP2 admite tipos de pago que van desde tarjetas de crédito y transferencias bancarias hasta stablecoins y criptomonedas. De hecho, junto con el lanzamiento de AP2, Google anunció una extensión específica para pagos criptográficos llamada A2A x402. Esta extensión, desarrollada en colaboración con actores de la industria cripto como Coinbase, la Ethereum Foundation y MetaMask, es una "solución lista para producción para pagos criptográficos basados en agentes". El nombre "x402" es un homenaje al código de estado HTTP 402 "Pago Requerido", que nunca fue ampliamente utilizado en la Web; la extensión criptográfica de AP2 efectivamente revive el espíritu de HTTP 402 para agentes descentralizados que desean cobrarse o pagarse entre sí en la cadena. En términos prácticos, la extensión x402 adapta el concepto de mandato de AP2 a las transacciones de blockchain. Por ejemplo, un agente podría tener un Mandato de Intención firmado por un usuario y luego ejecutar un pago en cadena (por ejemplo, enviar una stablecoin) una vez que se cumplan las condiciones, adjuntando la prueba del mandato a esa transacción en cadena. Esto une el marco de confianza fuera de la cadena de AP2 con la naturaleza sin confianza de blockchain, ofreciendo lo mejor de ambos mundos: un pago en cadena que las partes fuera de la cadena (usuarios, comerciantes) pueden confiar que fue autorizado por el usuario.

La sinergia entre AP2 y Web3 es evidente en la lista de colaboradores. Intercambios de criptomonedas (Coinbase), fundaciones de blockchain (Ethereum Foundation), billeteras criptográficas (MetaMask) y startups de Web3 (por ejemplo, Mysten Labs de Sui, Lightspark para Lightning Network) están involucrados en el desarrollo de AP2. Su participación sugiere que AP2 se considera complementario a las finanzas descentralizadas en lugar de competitivo. Al crear una forma estándar para que los agentes de IA interactúen con los pagos criptográficos, AP2 podría impulsar un mayor uso de las criptomonedas en aplicaciones impulsadas por IA. Por ejemplo, un agente de IA podría usar AP2 para cambiar sin problemas entre pagar con tarjeta de crédito o pagar con una stablecoin, dependiendo de la preferencia del usuario o la aceptación del comerciante. La extensión A2A x402 permite específicamente a los agentes monetizar o pagar servicios a través de medios en cadena, lo que podría ser crucial en los mercados descentralizados del futuro. Sugiere que los agentes que posiblemente operen como actores económicos autónomos en blockchain (un concepto al que algunos se refieren como DACs o DAOs) podrán manejar los pagos requeridos para los servicios (como pagar una pequeña tarifa a otro agente por información). AP2 podría proporcionar la lengua franca para tales transacciones, asegurando que incluso en una red descentralizada, el agente tenga un mandato comprobable de lo que está haciendo.

En términos de competencia, uno podría preguntar: ¿las soluciones puramente descentralizadas hacen que AP2 sea innecesario, o viceversa? Es probable que AP2 coexista con las soluciones Web3 en un enfoque por capas. Las finanzas descentralizadas ofrecen ejecución sin confianza (contratos inteligentes, etc.), pero no resuelven inherentemente el problema de "¿Un IA tuvo permiso de un humano para hacer esto?". AP2 aborda ese vínculo de confianza humano-a-IA, que sigue siendo importante incluso si el pago en sí está en la cadena. En lugar de competir con los protocolos de blockchain, AP2 puede verse como un puente entre ellos y el mundo fuera de la cadena. Por ejemplo, un contrato inteligente podría aceptar una determinada transacción solo si incluye una referencia a una firma de mandato AP2 válida, algo que podría implementarse para combinar la prueba de intención fuera de la cadena con la aplicación en cadena. Por el contrario, si existen marcos de agentes cripto-nativos (algunos proyectos de blockchain exploran agentes autónomos que operan con fondos criptográficos), podrían desarrollar sus propios métodos de autorización. Sin embargo, el amplio apoyo de la industria de AP2 podría llevar incluso a esos proyectos a adoptar o integrarse con AP2 para mantener la coherencia.

Otro ángulo es la identidad y credenciales descentralizadas. El uso de credenciales verificables por parte de AP2 está muy en línea con el enfoque de Web3 hacia la identidad (por ejemplo, DIDs y VCs estandarizados por el W3C). Esto significa que AP2 podría conectarse a sistemas de identidad descentralizada; por ejemplo, el DID de un usuario podría usarse para firmar un mandato AP2, que un comerciante podría verificar contra una blockchain o un hub de identidad. La mención de explorar la identidad descentralizada para la autorización de agentes refuerza que AP2 puede aprovechar las innovaciones de identidad de Web3 para verificar las identidades de agentes y usuarios de manera descentralizada, en lugar de depender únicamente de autoridades centralizadas. Este es un punto de sinergia, ya que tanto AP2 como Web3 tienen como objetivo dar a los usuarios más control y pruebas criptográficas de sus acciones.

Posibles conflictos podrían surgir solo si se concibe un ecosistema de comercio totalmente descentralizado sin ningún papel para los grandes intermediarios; en ese escenario, ¿podría AP2 (inicialmente impulsado por Google y sus socios) ser demasiado centralizado o gobernado por actores tradicionales? Es importante señalar que AP2 es de código abierto y está destinado a ser estandarizable, por lo que no es propietario de Google. Esto lo hace más aceptable para la comunidad Web3, que valora los protocolos abiertos. Si AP2 se adopta ampliamente, podría reducir la necesidad de protocolos de pago separados específicos de Web3 para agentes, unificando así los esfuerzos. Por otro lado, algunos proyectos de blockchain podrían preferir mecanismos de autorización puramente en cadena (como billeteras multifirma o lógica de custodia en cadena) para transacciones de agentes, especialmente en entornos sin confianza y sin autoridades centralizadas. Esos podrían verse como enfoques alternativos, pero probablemente seguirían siendo un nicho a menos que puedan interactuar con sistemas fuera de la cadena. AP2, al cubrir ambos mundos, podría en realidad acelerar la adopción de Web3 al hacer de las criptomonedas solo otro método de pago que un agente de IA puede usar sin problemas. De hecho, un socio señaló que “las stablecoins proporcionan una solución obvia a los desafíos de escalado [para] sistemas agéneticos con infraestructura heredada”, destacando que las criptomonedas pueden complementar a AP2 en el manejo de la escala o escenarios transfronterizos. Mientras tanto, el líder de ingeniería de Coinbase comentó que llevar la extensión criptográfica x402 a AP2 “tenía sentido: es un campo de juego natural para los agentes... es emocionante ver que los agentes que se pagan entre sí resuenan en la comunidad de IA”. Esto implica una visión en la que los agentes de IA que realizan transacciones a través de redes criptográficas no es solo una idea teórica, sino un resultado esperado, con AP2 actuando como catalizador.

En resumen, AP2 es muy relevante para Web3: incorpora los pagos criptográficos como un ciudadano de primera clase y se alinea con los estándares de identidad y credenciales descentralizadas. En lugar de competir directamente con los protocolos de pago descentralizados, AP2 probablemente interoperará con ellos, proporcionando la capa de autorización mientras los sistemas descentralizados manejan la transferencia de valor. A medida que la línea entre las finanzas tradicionales y las criptomonedas se difumina (con stablecoins, CBDCs, etc.), un protocolo unificado como AP2 podría servir como un adaptador universal entre agentes de IA y cualquier forma de dinero, centralizada o descentralizada.

Adopción en la Industria, Asociaciones y Hoja de Ruta

Una de las mayores fortalezas de AP2 es el amplio respaldo de la industria que tiene, incluso en esta etapa temprana. Google Cloud anunció que está “colaborando con un grupo diverso de más de 60 organizaciones” en AP2. Estas incluyen las principales redes de tarjetas de crédito (por ejemplo, Mastercard, American Express, JCB, UnionPay), líderes en fintech y procesadores de pagos (PayPal, Worldpay, Adyen, Checkout.com, competidores de Stripe), comercio electrónico y mercados en línea (Etsy, Shopify (a través de socios como Stripe u otros), Lazada, Zalora), empresas de tecnología empresarial (Salesforce, ServiceNow, Oracle posiblemente a través de socios, Dell, Red Hat), empresas de identidad y seguridad (Okta, Ping Identity, Cloudflare), firmas de consultoría (Deloitte, Accenture), y organizaciones de cripto/Web3 (Coinbase, Ethereum Foundation, MetaMask, Mysten Labs, Lightspark), entre otras. Una gama tan amplia de participantes es un fuerte indicador del interés de la industria y la probable adopción. Muchos de estos socios han expresado públicamente su apoyo. Por ejemplo, el Co-CEO de Adyen destacó la necesidad de un "libro de reglas común" para el comercio agénetico y ve a AP2 como una extensión natural de su misión de apoyar a los comerciantes con nuevos bloques de construcción de pago. El vicepresidente ejecutivo de American Express declaró que AP2 es importante para “la próxima generación de pagos digitales” donde la confianza y la rendición de cuentas son primordiales. El equipo de Coinbase, como se señaló, está entusiasmado con la integración de pagos criptográficos en AP2. Este coro de apoyo muestra que muchos en la industria ven a AP2 como el estándar probable para los pagos impulsados por IA, y están ansiosos por darle forma para asegurar que cumpla con sus requisitos.

Desde el punto de vista de la adopción, AP2 se encuentra actualmente en la etapa de especificación e implementación temprana (anunciado en septiembre de 2025). La especificación técnica completa, la documentación y algunas implementaciones de referencia (en lenguajes como Python) están disponibles en el GitHub del proyecto para que los desarrolladores experimenten con ellas. Google también ha indicado que AP2 se incorporará a sus productos y servicios para agentes. Un ejemplo notable es el Mercado de Agentes de IA mencionado anteriormente: esta es una plataforma donde se pueden ofrecer agentes de IA de terceros a los usuarios (probablemente parte del ecosistema de IA generativa de Google). Google dice que muchos socios que construyen agentes los pondrán a disposición en el mercado con "nuevas experiencias transaccionales habilitadas por AP2". Esto implica que a medida que el mercado se lance o crezca, AP2 será la columna vertebral para cualquier agente que necesite realizar una transacción, ya sea comprando software del Google Cloud Marketplace de forma autónoma o un agente comprando bienes/servicios para un usuario. Casos de uso empresariales como la adquisición autónoma (un agente comprando a otro en nombre de una empresa) y el escalado automático de licencias se han mencionado específicamente como áreas que AP2 podría facilitar pronto.

En cuanto a la hoja de ruta, la documentación de AP2 y el anuncio de Google dan algunas indicaciones claras:

• Corto plazo: Continuar el desarrollo abierto del protocolo con la aportación de la comunidad. El repositorio de GitHub se actualizará con implementaciones de referencia adicionales y mejoras a medida que se realicen pruebas en el mundo real. Podemos esperar que surjan bibliotecas/SDK, lo que facilitará la integración de AP2 en aplicaciones de agentes. Además, las empresas asociadas podrían llevar a cabo programas piloto iniciales o pruebas de concepto. Dado que muchas grandes empresas de pago están involucradas, podrían probar AP2 en entornos controlados (por ejemplo, una opción de pago habilitada para AP2 en una pequeña beta de usuarios).
• Estándares y Gobernanza: Google ha expresado su compromiso de mover AP2 a un modelo de gobernanza abierta, posiblemente a través de organismos de estándares. Esto podría significar enviar AP2 a organizaciones como la Linux Foundation (como se hizo con el protocolo A2A) o formar un consorcio para mantenerlo. La Linux Foundation, el W3C o incluso organismos como ISO/TC68 (servicios financieros) podrían estar en los planes para formalizar AP2. Una gobernanza abierta tranquilizaría a la industria de que AP2 no está bajo el control de una sola empresa y seguirá siendo neutral e inclusivo.
• Expansión de Funcionalidades: Técnicamente, la hoja de ruta incluye la expansión del soporte a más tipos de pago y casos de uso. Como se señaló en la especificación, después de las tarjetas, el enfoque se desplazará a los pagos "push" como transferencias bancarias y esquemas de pago locales en tiempo real, y monedas digitales. Esto significa que AP2 describirá cómo funciona un Mandato de Intención/Carrito/Pago para, por ejemplo, una transferencia bancaria directa o una transferencia de billetera criptográfica, donde el flujo es un poco diferente al de los retiros con tarjeta. La extensión A2A x402 es una de esas expansiones para cripto; de manera similar, podríamos ver una extensión para API de banca abierta o una para escenarios de facturación B2B.
• Mejoras de Seguridad y Cumplimiento: A medida que las transacciones reales comiencen a fluir a través de AP2, habrá un escrutinio por parte de los reguladores e investigadores de seguridad. El proceso abierto probablemente iterará para hacer los mandatos aún más robustos (por ejemplo, asegurando que los formatos de mandato estén estandarizados, posiblemente usando el formato de Credenciales Verificables del W3C, etc.). La integración con soluciones de identidad (quizás aprovechando la biometría para la firma de mandatos por parte del usuario, o vinculando mandatos a billeteras de identidad digital) podría ser parte de la hoja de ruta para mejorar la confianza.
• Herramientas del Ecosistema: Es probable que surja un ecosistema. Ya, las startups están notando lagunas; por ejemplo, el análisis de Vellum.ai menciona una startup llamada Autumn que está construyendo una "infraestructura de facturación para IA", esencialmente herramientas sobre Stripe para manejar precios complejos para servicios de IA. A medida que AP2 gane tracción, podemos esperar que aparezcan más herramientas como pasarelas de pago centradas en agentes, paneles de control de gestión de mandatos, servicios de verificación de identidad de agentes, etc. La participación de Google significa que AP2 también podría integrarse en sus productos de Cloud; imagine el soporte de AP2 en las herramientas de Dialogflow o Vertex AI Agents, lo que permitiría con un solo clic que un agente maneje transacciones (con todas las claves y certificados necesarios administrados en Google Cloud).

En general, la trayectoria de AP2 recuerda a otros estándares importantes de la industria: un lanzamiento inicial con un patrocinador fuerte (Google), una amplia coalición industrial, código de referencia de código abierto, seguido de mejoras iterativas y adopción gradual en productos reales. El hecho de que AP2 invite a todos los actores "a construir este futuro con nosotros" subraya que la hoja de ruta se trata de colaboración. Si el impulso continúa, AP2 podría volverse tan común en unos años como lo son hoy protocolos como OAuth u OpenID Connect en sus dominios: una capa invisible pero crítica que permite la funcionalidad en todos los servicios.

Conclusión

AP2 (Protocolo de Pagos de Agentes/Agentes) representa un paso significativo hacia un futuro donde los agentes de IA puedan realizar transacciones de manera tan confiable y segura como los humanos. Técnicamente, introduce un mecanismo inteligente de mandatos y credenciales verificables que infunden confianza en las transacciones dirigidas por agentes, asegurando que la intención del usuario sea explícita y aplicable. Su arquitectura abierta y extensible le permite integrarse tanto con los florecientes frameworks de agentes de IA como con la infraestructura financiera establecida. Al abordar las preocupaciones centrales de autorización, autenticidad y rendición de cuentas, AP2 sienta las bases para que el comercio impulsado por IA prospere sin sacrificar la seguridad ni el control del usuario.

La introducción de AP2 puede verse como el establecimiento de una nueva base – al igual que los primeros protocolos de internet habilitaron la web – para lo que algunos llaman la "economía de agentes". Abre el camino a innumerables innovaciones: agentes de compras personales, bots de búsqueda automática de ofertas, agentes autónomos de la cadena de suministro y más, todos operando bajo un marco de confianza común. Es importante destacar que el diseño inclusivo de AP2 (que abarca desde tarjetas de crédito hasta criptomonedas) lo posiciona en la intersección de las finanzas tradicionales y Web3, lo que podría unir estos mundos a través de un protocolo común mediado por agentes.

La respuesta de la industria hasta ahora ha sido muy positiva, con una amplia coalición que señala que AP2 probablemente se convertirá en un estándar ampliamente adoptado. El éxito de AP2 dependerá de la colaboración continua y las pruebas en el mundo real, pero sus perspectivas son sólidas dada la clara necesidad que aborda. En un sentido más amplio, AP2 ejemplifica cómo evoluciona la tecnología: surgió una nueva capacidad (agentes de IA) que rompió viejas suposiciones, y la solución fue desarrollar un nuevo estándar abierto para acomodar esa capacidad. Al invertir ahora en un protocolo abierto y centrado en la seguridad, Google y sus socios están construyendo efectivamente la arquitectura de confianza necesaria para la próxima era del comercio. Como dice el dicho, "la mejor manera de predecir el futuro es construirlo"; AP2 es una apuesta por un futuro en el que los agentes de IA gestionen transacciones por nosotros sin problemas, y está construyendo activamente la confianza y las reglas necesarias para que ese futuro sea viable.

Fuentes:

• Blog de Google Cloud – “Impulsando el comercio de IA con el nuevo Protocolo de Pagos de Agentes (AP2)” (16 de septiembre de 2025)
• Documentación de AP2 en GitHub – “Especificación y Resumen del Protocolo de Pagos de Agentes”
• Blog de Vellum AI – “AP2 de Google: Un nuevo protocolo para pagos de agentes de IA” (Análisis)
• Artículo de Medium – “Protocolo de Pagos de Agentes (AP2) de Google” (Resumen de Tahir, septiembre de 2025)
• Citas de Socios sobre AP2 (Blog de Google Cloud)
• Extensión A2A x402 (extensión de pagos criptográficos de AP2) – README de GitHub