Protocolos de comercio agéntico: ACP, AP2 y UCP, y lo que necesita tu catálogo

TL;DR

• Los tres protocolos de comercio agéntico abiertos que importan en octubre de 2026 son ACP (OpenAI y Stripe), UCP (Google y socios del comercio minorista) y AP2 (creado por Google, ahora en la FIDO Alliance). Cubren capas distintas de una misma compra.
• ACP y UCP estandarizan el catálogo de productos y el checkout entre agente y comerciante. AP2 estandariza la prueba firmada de que un usuario autorizó una compra y un pago concretos. Visa y Mastercard tienen sus propios programas para verificar agentes y credenciales de pago.
• Los tres aceptan un GTIN en los datos de producto, pero ninguno lo exige, y ninguno menciona GS1 Digital Link. El checkout funciona con los ID de artículo propios del comerciante, que es justo donde la identidad del producto puede perderse.

Los protocolos de comercio agéntico son las especificaciones abiertas que permiten a un agente de IA encontrar un producto, añadirlo a una cesta y pagarlo en nombre de alguien sin hacer scraping de una web. A octubre de 2026, tres de ellos soportan la mayor parte del peso del sector: el Agentic Commerce Protocol (ACP), el Universal Commerce Protocol (UCP) y el Agent Payments Protocol (AP2). Funcionan como capas: ACP y UCP describen cómo habla un agente con un comerciante sobre productos, carritos y pedidos, y AP2 describe cómo todos pueden demostrar después qué autorizó realmente el usuario.

Para una marca o un importador, la pregunta práctica es más concreta. Use el protocolo que use un agente, le pregunta a tu catálogo lo mismo: qué es este artículo, cuánto cuesta, puedo comprarlo y qué ID paso al checkout. Esta guía explica quién está detrás de cada protocolo, qué estandariza, qué debe aportar un comerciante y dónde encaja la identidad del producto, a octubre de 2026.

¿Qué protocolos de comercio agéntico existen y cuándo se lanzaron?

¿Qué es el Agentic Commerce Protocol (ACP)?

ACP es una especificación abierta para el comercio entre compradores, sus agentes de IA y las empresas. OpenAI y Stripe lo publicaron el 29 de septiembre de 2025, junto con Instant Checkout en ChatGPT, bajo licencia Apache 2.0. El repositorio oficial lo describe como en beta y mantenido por OpenAI y Stripe como mantenedores fundadores; desde abril de 2026, su archivo de mantenedores también incluye a Meta como mantenedor principal. La última versión estable es la 2026-04-17.

ACP estandariza cuatro cosas:

• Checkout. El comerciante expone una API de sesiones de checkout: el agente crea una sesión a partir de artículos, la actualiza con la dirección y la opción de entrega, y la completa o la cancela. La especificación deja claro que el comerciante sigue siendo el sistema de registro de pedidos, pagos, impuestos y cumplimiento normativo, y que el pago pasa por el propio proveedor de servicios de pago del comerciante.
• Pago delegado. Un proveedor de pagos emite un token de un solo uso limitado por una «asignación» (allowance): un importe máximo, una moneda, una sesión de checkout concreta, un comerciante concreto y una hora de caducidad. El Shared Payment Token de Stripe fue la primera implementación compatible. Una API de autenticación delegada aparte cubre las verificaciones de 3-D Secure 2.
• Feed de productos. La versión 2026-04-17 añadió una Feed API. Es un modelo push: el comerciante envía su catálogo a un feed alojado por la plataforma del agente, ya sea como archivo completo o como actualizaciones parciales.
• Carrito y pedidos, además de un binding para el Model Context Protocol (MCP).

¿Qué pasó con Instant Checkout?

El 24 de marzo de 2026, OpenAI anunció que la versión inicial de Instant Checkout no había ofrecido la flexibilidad que buscaba, y que los comerciantes podrían usar su propio checkout mientras OpenAI se centraba en el descubrimiento de productos. En el mismo anuncio dijo que extendía ACP para llevar feeds de productos y promociones a ChatGPT. Así que el protocolo sigue, la especificación de checkout sigue existiendo, y en ChatGPT hoy importa más el feed que el checkout. La incorporación de feeds de productos a ChatGPT está limitada a socios aprobados, que lo solicitan a través de OpenAI.

¿Qué datos de producto necesita un feed de ACP?

En la Feed API abierta de ACP, un producto necesita un id estable y al menos una variante, y cada variante necesita un id estable y un title. Todo lo demás es opcional en el esquema: precio y precio de catálogo en unidades menores de la moneda, estado de disponibilidad, contenido multimedia, categorías, opciones de variante como color y talla, vendedor, precio unitario y una lista de barcodes, en la que cada entrada tiene un tipo, como GTIN, UPC o EAN, y un valor.

La especificación de feed propia de OpenAI para ChatGPT es más estricta. Exige ID de artículo, título, descripción, URL del producto, marca, nombre del vendedor, URL de la imagen principal, disponibilidad y precio. El campo gtin es opcional, debe tener 8, 12, 13 o 14 dígitos con un dígito de control válido, y debe omitirse si el producto no tiene. El campo mpn debe enviarse junto con la marca, y la especificación indica a los comerciantes que no inventen un número de pieza para sustituir un GTIN que falta.

La propuesta de feed de ACP también zanja una cuestión importante: los datos del feed son informativos, y la respuesta del checkout es la que manda en precio, stock, impuestos y entrega. Si el ID de variante del feed no es el ID que acepta el checkout del comerciante, el comerciante debe proporcionar una correspondencia.

¿Qué es el Universal Commerce Protocol (UCP)?

UCP es un estándar abierto que cubre todo el recorrido de compra: descubrimiento, carrito, checkout, vinculación de cuentas y pedidos. Google lo lanzó el 11 de enero de 2026, desarrollado en colaboración con Shopify, Etsy, Wayfair, Target y Walmart y publicado en ucp.dev bajo licencia Apache 2.0. La gobernanza ha crecido desde entonces: en abril de 2026 Stripe se unió a Google y Shopify como miembro permanente del Governing Council, y durante el verano se formaron comités técnicos de pagos, alojamiento y alimentación. La versión actual es la v2026-08-25.

Una empresa que admite UCP publica un perfil en /.well-known/ucp con las capacidades que ofrece, para que un agente pueda descubrirlas sin una integración a medida. Entre esas capacidades están:

• Búsqueda y consulta de catálogo, añadidas en la v2026-04-08.
• Carrito y checkout, con impuestos y precios calculados por la empresa.
• Vinculación de identidad mediante OAuth 2.0, para que un agente pueda actuar dentro de la cuenta de un cliente sin tener su contraseña.
• Pedidos, con actualizaciones de estado, envío y devolución por webhook.
• Gestores de pago (payment handlers), que separan el instrumento de pago del proveedor que lo procesa y que usan AP2 para los mandatos de pago.

UCP puede ofrecerse sobre REST, MCP o Agent2Agent (A2A). La primera implementación de Google permite comprar a comerciantes elegibles en el Modo IA de la Búsqueda y en la app de Gemini. Funciona desde una cuenta de Google Merchant Center y los feeds de shopping existentes, el acceso es mediante lista de espera y el comerciante sigue siendo el comerciante de registro (merchant of record).

¿Qué datos de producto necesita UCP?

Una variante de UCP debe tener un id, un title, una description y un price. El id de la variante es el que se usa como ID de artículo en el checkout. Entre los campos opcionales están el sku del comerciante, una URL canónica, la disponibilidad, el contenido multimedia, el precio unitario y barcodes, cuyos tipos reconocidos son UPC, EAN, ISBN, GTIN y JAN.

Las reglas de consulta son reveladoras. Un catálogo UCP debe admitir la consulta por ID de producto y por ID de variante. Puede admitir identificadores secundarios como el SKU. Una consulta por GTIN no es algo con lo que un agente pueda contar.

En la implementación propia de Google siguen aplicándose las reglas de feed de Merchant Center. Google recomienda un GTIN para todos los productos que tengan uno asignado por el fabricante, y advierte de que omitir un GTIN asignado puede hacer que el producto sea rechazado.

¿Qué es el Agent Payments Protocol (AP2)?

AP2 resuelve un problema distinto. Cuando paga un agente, ni el comerciante, ni el emisor de la tarjeta, ni la red de pagos estaban mirando cuando el usuario pulsó «comprar». AP2 les da pruebas firmadas de lo que autorizó el usuario, para que puedan aceptar la transacción y resolver disputas. Google lo anunció el 16 de septiembre de 2025. El 28 de abril de 2026 Google publicó la versión 0.2 y anunció que donaba AP2 a la FIDO Alliance, donde la estandarización continúa en los grupos de trabajo de FIDO. El sitio de la especificación de AP2 y su repositorio se publican bajo licencia Apache 2.0.

Las dos versiones describen la misma idea de forma distinta:

• La versión 0.1 (septiembre de 2025) usaba tres mandatos: un Intent Mandate que recogía lo que pidió el usuario, un Cart Mandate que registraba los artículos y el precio exactos que el usuario aprobó, y un Payment Mandate.
• La versión 0.2 (abril de 2026) usa un Checkout Mandate, que asegura qué se compra, y un Payment Mandate vinculado, que asegura el pago. Cada uno existe en una forma abierta, que contiene las restricciones del usuario antes de que la cesta sea definitiva, y una forma cerrada, ligada a un único checkout finalizado. Los mandatos son credenciales firmadas con divulgación selectiva, de modo que cada parte ve solo lo que necesita.

AP2 define cinco roles (agente de compra, proveedor de credenciales, comerciante, procesador de pagos del comerciante y una superficie de confianza donde el usuario da su consentimiento) y dos modos. En las compras «con persona presente», el usuario aprueba la cesta final. En las compras «sin persona presente», la principal novedad de la v0.2, el usuario firma restricciones por adelantado y el agente completa una compra que las cumple.

AP2 deja deliberadamente fuera de su alcance las API de catálogo y de checkout. Está diseñado para funcionar con UCP: cuando se usa con UCP, el checkout firmado por el comerciante dentro de un Checkout Mandate debe ser el objeto checkout de UCP. Su tipo de artículo solo lleva un id (descrito como a menudo el SKU), un title, un price y una URL de imagen opcional.

¿Dónde encajan Visa y Mastercard?

Las dos redes de tarjetas tienen programas que se sitúan junto a estos protocolos en lugar de sustituirlos. Se ocupan de la identidad de los agentes y de las credenciales de pago, no de los datos de producto.

• Visa Trusted Agent Protocol (14 de octubre de 2025, desarrollado con Cloudflare) permite que un agente aprobado firme sus solicitudes a un comerciante, para que el comerciante pueda distinguir un agente de compra legítimo de un bot malicioso. Puede transportar la intención del agente, el reconocimiento del consumidor e información de pago opcional, y está publicado en el Visa Developer Center y en GitHub.
• Mastercard Agent Pay (29 de abril de 2025) introdujo los Agentic Tokens y exige que los agentes estén registrados y verificados antes de realizar transacciones. Verifiable Intent, presentado por Mastercard y Google el 5 de marzo de 2026, es una especificación abierta para un registro a prueba de manipulaciones de lo que autorizó un usuario, alineada con AP2 y UCP. El anuncio de Google de abril de 2026 indica que Verifiable Intent también se está donando a la FIDO Alliance.

Un comerciante suele encontrarse con estos programas a través de su proveedor de pagos, y no cambian lo que tiene que contener tu catálogo.

¿Cómo se comparan ACP, UCP y AP2?

¿Dónde encaja la identidad del producto y en qué callan los protocolos?

Leídas en paralelo, las tres especificaciones identifican un producto en el checkout con un ID elegido por el comerciante. ACP usa el ID de variante del feed, UCP usa su ID de variante y los mandatos de AP2 enumeran los ID de artículo aceptables del comerciante. Eso es razonable para completar un pedido en una tienda. Es el punto débil que describió Paula Rivero en el taller del W3C y GS1 en Zúrich: un agente puede ejecutar el checkout sin fallos y aun así comprar el producto equivocado, porque el ID interno de un comerciante no dice nada sobre qué producto físico es fuera de esa tienda.

El GTIN es el campo que cruza esa frontera. ACP y UCP tienen un sitio para él, y la especificación de feed de OpenAI valida su dígito de control. Ninguno de los tres protocolos lo hace obligatorio, ninguno dice cómo debe comparar un agente el mismo GTIN entre comerciantes, y ninguno menciona GS1 Digital Link, el Pasaporte Digital de Producto ni ninguna otra forma de resolver un producto a información de la propia marca.

Nuestra lectura de cómo encajan, que no figura en ninguna de las especificaciones:

• El GTIN del feed es el puente entre comerciantes. Si dos tiendas venden el mismo champú con el mismo GTIN, un agente puede reconocerlos como el mismo producto y comparar ofertas en lugar de adivinar a partir de los títulos. Si falta el GTIN, el agente recurre a comparar nombres.
• Un mandato abierto de AP2 es tan preciso como sus ID de artículo. Un usuario que autoriza «vuelve a pedir exactamente este producto» está autorizando, en la v0.2, una lista de ID de artículo del comerciante. Un GTIN detrás de esos ID es lo que hace que la instrucción signifique lo mismo en una segunda tienda.
• GS1 Digital Link es donde vive la versión de la verdad de la marca. Una URI de GS1 Digital Link se construye a partir del mismo GTIN, así que un agente que ya tiene el GTIN puede construirla y resolverla a información que controla la marca: especificaciones, instrucciones, información de seguridad y, en la UE, datos del pasaporte. Ninguno de los protocolos exige a un agente que lo haga. Tampoco hay nada en ellos que lo impida.

Donde un código QR no ayuda: no interviene en el checkout, el pago ni los mandatos, y un feed conforme a los protocolos no lo necesita. Su valor aquí es el identificador que hay detrás.

¿Qué deberían hacer ahora las marcas y los importadores?

Los protocolos seguirán cambiando; el trabajo de catálogo no depende de cuál gane.

1. Asegúrate de que cada producto que tiene GTIN lo lleve en tus propios sistemas, en tu feed de Google Merchant Center y en cualquier feed de ACP, y de que el dígito de control sea válido. No inventes identificadores para productos que no los tienen.
2. Mantén un ID estable por variante, y comprueba que el ID de tu feed es el que acepta tu checkout. Tanto ACP como UCP dependen de ello.
3. Asigna explícitamente cada GTIN a un ID de variante. Un GTIN debe apuntar a una única variante vendible de tu catálogo, incluidos el tamaño del envase y la formulación.
4. Envía los campos que usan los agentes para elegir: título, descripción, marca, precio, disponibilidad, imágenes y una URL canónica del producto. En ACP y UCP es lo que ve un agente antes del checkout.
5. Mantén actualizados el precio y el stock. Ambas especificaciones tratan el feed como informativo y el checkout como el que manda, así que un feed desactualizado lleva a los agentes a checkouts fallidos.
6. Pregunta a tu proveedor de pagos qué flujos agénticos admite: el Shared Payment Token de Stripe para ACP, los gestores de pago de UCP, los mandatos de AP2 y los programas para agentes de Visa y Mastercard. Rara vez los implementarás tú mismo.
7. Dale al GTIN un hogar resoluble. Un resolver de GS1 Digital Link en tu propio dominio permite a cualquier agente, con cualquier protocolo, contrastar el producto con tus propios datos. También es la vía en la que se apoyará el Pasaporte Digital de Producto de la UE.

Digital Link es solution partner de GS1, y nuestra plataforma da a cada producto un GS1 Digital Link construido sobre su GTIN, con páginas controladas por la marca y datos estructurados detrás que pueden leer personas y máquinas. Para el comercio agéntico, esa es la capa de identidad que los protocolos dejan abierta: un identificador por producto que se resuelve a tus datos, sea cual sea el agente o el protocolo que pregunte. Si quieres comprobar lo preparado que está tu catálogo para la compra mediante agentes, escríbenos y nuestro equipo revisará contigo tus datos de producto.

Preguntas frecuentes

¿Qué diferencia hay entre ACP y AP2?

ACP es un protocolo de comercio: estandariza el feed de productos, la sesión de checkout y un token de pago delegado entre un agente de IA y un comerciante. AP2 es un protocolo de confianza en los pagos: estandariza mandatos firmados que prueban lo que autorizó un usuario, y deja el catálogo y el checkout a otros protocolos. La especificación de AP2 nombra a UCP como el protocolo de comercio con el que está diseñado para funcionar.

¿ACP es lo mismo que Instant Checkout en ChatGPT?

No. Instant Checkout era el producto de OpenAI construido sobre ACP. En marzo de 2026, OpenAI se alejó del Instant Checkout independiente para que los comerciantes pudieran usar su propio checkout, y extendió ACP para transportar feeds de productos y promociones para el descubrimiento en ChatGPT. La especificación de ACP en sí sigue siendo abierta y en beta.

¿Los protocolos de comercio agéntico exigen un GTIN?

No. ACP y UCP ofrecen un campo opcional de código de barras que acepta un GTIN, y la especificación de feed de ChatGPT de OpenAI recoge gtin como opcional. Google Merchant Center recomienda un GTIN para cada producto que tenga uno y puede rechazar productos a los que les falte un GTIN asignado.

¿Alguno de estos protocolos usa GS1 Digital Link?

No a octubre de 2026. Ninguna de las especificaciones de ACP, UCP o AP2 menciona GS1 Digital Link. Como una URI de GS1 Digital Link se construye a partir del GTIN, cualquier agente que reciba un GTIN a través de estos protocolos puede resolverla, pero esa es nuestra lectura de cómo se combinan, no un requisito de los protocolos.

¿Quién es ahora el propietario de AP2?

Google creó AP2 y anunció su donación a la FIDO Alliance el 28 de abril de 2026, junto con la publicación de la versión 0.2. La especificación y el SDK siguen siendo públicos en GitHub, y la estandarización continúa en los grupos de trabajo de FIDO.

¿Pueden los comerciantes de la UE usar estos protocolos?

Las especificaciones son abiertas y pueden implementarse en cualquier lugar. Los primeros productos de consumo construidos sobre ellas se lanzaron en Estados Unidos, y las plataformas deciden país por país dónde pueden participar los comerciantes, así que comprueba los requisitos de elegibilidad actuales de cada plataforma antes de contar con ello.