El UCP de Google añade cuatro cabeceras a cada pago. Tres existen para la discusión posterior

El 11 de enero de 2026, Google publicó el Universal Commerce Protocol: un estándar de código abierto que permite a los agentes de IA comprar, desarrollado junto a Shopify y respaldado por más de 20 socios, entre ellos Etsy, Wayfair, Target, Walmart, Adyen, American Express, Mastercard, Stripe, Visa y Zalando.

La cobertura que vino después hablaba de compras. Agentes que buscan por ti, agentes que pagan por ti, el fin del carrito, etcétera.

Entonces lees la especificación y descubres que comprar es lo menos interesante que hay dentro. Lo que el UCP normaliza con un cuidado inusual no es la compra. Es la prueba de que la compra ocurrió tal y como ambas partes dicen.

En resumen:

• Cada petición UCP que modifica estado lleva cuatro cabeceras, y tres de ellas —request-signature, idempotency-key, request-id— no aportan nada a la transacción en sí. Existen para que después alguien pueda probar qué se pidió, que se pidió una sola vez y dónde volver a encontrarlo.
• El no repudio es una función con nombre propio. En la extensión opcional de mandatos AP2 (dev.ucp.shopping.ap2_mandate), el comercio firma criptográficamente las condiciones del pago mientras la plataforma aporta mandatos criptográficos que prueban que el usuario las autorizó. El propósito declarado en la especificación: «reducir significativamente los riesgos de manipulación y disputa».
• El número de respaldos no es un número de integraciones. «Más de 20 socios globales» es la fórmula que publicó Google, y describe respaldo. Al cierre de este artículo no encontramos ninguna fuente primaria que dé un recuento de comercios con UCP en producción.

El conjunto de cabeceras procede del tutorial que Google publicó el día del lanzamiento. Fuentes al final.

Qué es el UCP, con las menos palabras que siguen siendo ciertas

Antes del argumento, los hechos comprobables. Proceden de la especificación publicada en ucp.dev y del blog para desarrolladores de Google, ambos consultados el 5 de septiembre de 2026.

Dos filas de esa tabla merecen una pausa, porque la mayoría de los artículos se saltan ambas.

La primera es la de los transportes. El UCP no es una cosa de MCP ni una cosa de REST. Los mismos datos declarados se ofrecen por REST, MCP, A2A y un binding embebido, y elige el comercio. Es una negativa deliberada a apostar por qué fontanería de agentes acabará ganando.

La segunda es el versionado por fecha. 2026-04-08 no es una versión semántica, es un día. La razón que da la especificación es el orden cronológico y la comparación inequívoca, pero el efecto práctico es otro: cada sesión negociada registra la fecha de las reglas bajo las que se celebró. Es una decisión de archivo disfrazada de decisión de versionado, y marca el tono de todo el documento.

El cuello de botella que vino a matar

El planteamiento de Google es un problema N×N. Cada empresa que quiera aparecer dentro de una superficie conversacional tiene que construir una conexión a medida para cada una; cada superficie tiene que incorporar a cada empresa por separado; al final no se lanza nada.

El artículo de ingeniería de Shopify, publicado el mismo día por el ingeniero distinguido Ilya Grigorik, ataca el mismo problema desde abajo. Tras más de 20 años, miles de millones de transacciones y millones de comerciantes, la lección es que el comercio se niega a normalizarse: «las opciones y reglas de pago difieren según las propiedades del carrito, el comprador y el mercado; los descuentos tienen reglas de acumulación y combinación que rivalizan con el código tributario; las opciones de envío explotan en permutaciones desbocadas». Y luego llega la frase que conviene guardar: «Esta complejidad no es un fallo, es una propiedad emergente de la diversidad de los minoristas.»

Esa sola línea explica toda la arquitectura. Si aceptas que los comerciantes son irreductiblemente distintos, no puedes normalizar el comportamiento. Solo puedes normalizar cómo un comerciante declara su comportamiento, y cómo un agente averigua a qué acaba de acceder.

La estructura que una empresa publica en /.well-known/ucp. Fuente: especificación UCP 2026-04-08, Overview.

El descubrimiento ocurre antes de que empiece la conversación

Este es el flujo, tal y como lo describen la especificación y el tutorial de Google. Merece la pena seguirlo literalmente, porque el orden es el argumento.

1. La empresa publica un perfil en /.well-known/ucp. Declara una versión de protocolo, uno o más servicios (dev.ucp.shopping), las capacidades que contienen, los transportes y endpoints, los manejadores de pago disponibles y —esto importará luego— sus signing_keys públicas.
2. El agente anuncia su propio perfil en cada petición, mediante una cabecera UCP-Agent con sintaxis de diccionario RFC 8941: UCP-Agent: profile="https://agent.example/profiles/shopping-agent.json". En transporte MCP, la misma información viaja en un objeto meta.
3. La empresa calcula la intersección. De sus capacidades conserva las que la plataforma también declara; para cada superviviente elige la versión más alta presente en ambos arrays; si no hay versión común, la capacidad desaparece por completo.
4. Las extensiones huérfanas se podan. Una extensión que declara extends: "dev.ucp.shopping.checkout" desaparece si checkout no sobrevivió. La poda se repite hasta que no cae nada más, lo que resuelve las cadenas transitivas.
5. Elige la empresa. El UCP usa una arquitectura en la que selecciona el servidor: es el comerciante, no el agente, quien decide qué está activo en la sesión, y devuelve el registro de capacidades activas en la respuesta.

El nombrado no es convención, es gobernanza. Toda capacidad se escribe {dominio-invertido}.{servicio}.{capacidad}: dev.ucp.shopping.checkout para la estándar, com.example.payments.installments para la propia de un comercio. Un minorista puede inventar una capacidad que nadie más tiene sin pedir permiso y sin chocar con nadie, porque el dominio invertido es la autoridad.

El fallo también tiene su taxonomía, y la separación es reveladora. La especificación distingue los fallos de descubrimiento (errores de transporte: invalid_profile_url devuelve 400, profile_unreachable devuelve 424, profile_malformed devuelve 422) de los fallos de negociación, que son resultados de negocio y vuelven como un 200 normal con capabilities_incompatible en el cuerpo. «No pude alcanzarte» y «no tenemos nada en común» son sucesos distintos, y el UCP se niega a fundirlos en un único 400.

Cuatro cabeceras viajan en cada petición que modifica estado

Veamos una llamada real. Es el propio ejemplo de Google del día del lanzamiento: crear una sesión de pago contra una floristería de muestra.

POST /checkout-sessions
UCP-Agent: profile="https://agent.example/profile"
request-signature: test
idempotency-key: 0b50cc6b-19b2-42cd-afee-6a98e71eea87
request-id: 6d08ae4b-e7ea-44f4-846f-d7381919d4f2
Content-Type: application/json

Cuatro cabeceras. Pregunta para qué sirve cada una y aparece un patrón.

Tres de las cuatro no son para la transacción. Son para el desacuerdo sobre la transacción.

No es un accidente de buena higiene de API. Las claves de idempotencia y los identificadores de petición son práctica corriente en pagos, sí, pero la especificación va bastante más lejos, y cuanto más lejos va, más clara queda la intención.

El no repudio es un objetivo de diseño, no un añadido de cumplimiento

El UCP enumera cuatro mecanismos de autenticación que una empresa puede aceptar: claves de API, OAuth 2.0, mTLS y firmas de mensaje HTTP según RFC 9421. Tres son corrientes. El cuarto hace algo concreto.

Con las firmas de mensaje, ambas partes publican sus claves públicas en el array signing_keys del mismísimo documento de perfil que declara sus capacidades. El verificador extrae el keyid de la cabecera Signature-Input, lo empareja con un kid del conjunto de claves publicado por el firmante y comprueba la firma. Sin secreto compartido, sin registro, sin cuenta. La especificación llama a ese resultado onboarding sin permisos: «cualquier plataforma con un perfil descubrible puede interactuar con cualquier empresa sin registro previo».

El agujero evidente lo cierra la vinculación de identidad. Sea cual sea el mecanismo, los verificadores deben confirmar que el principal autenticado está realmente autorizado a actuar por el perfil que aparece en UCP-Agent, y rechazar la petición cuando ambos entren en conflicto. No puedes autenticarte como tú mismo y luego decir que eres el agente de otro.

Y los webhooks que van de la empresa a la plataforma deben ir firmados. No «deberían»: deben. Las actualizaciones del ciclo de vida del pedido —envío, entrega, devoluciones— son el único punto del protocolo donde el requisito es absoluto, porque son los mensajes que llegan después de que el dinero se haya movido y que nadie está mirando en tiempo real.

Fuente: especificación UCP 2026-04-08, secciones Identity & Authentication y Transaction Integrity.

Y luego está lo alto de la escalera. Para agentes autónomos y transacciones de alto valor, el UCP define una extensión opcional, dev.ucp.shopping.ap2_mandate. Cuando ambas partes la negocian:

• la empresa aporta una firma criptográfica sobre las condiciones del pago, y
• la plataforma aporta mandatos criptográficos que prueban que el usuario las autorizó.

El agente firma los objetos de mandato con la clave privada del usuario en una superficie no agéntica: es decir, la persona autoriza en una pantalla que controla, no dentro del bucle de agente que está a punto de gastar su dinero. La declaración de propósito de la propia especificación merece cita literal, porque no es una frase de seguridad de relleno: el mecanismo «proporciona garantías criptográficas sólidas y de extremo a extremo sobre los detalles de la transacción y el consentimiento de los participantes, reduciendo significativamente los riesgos de manipulación y disputa».

Y aquí está el punto. Un protocolo diseñado solo para que los agentes compren no necesitaría nada de esto. Condiciones firmadas del lado del comercio y mandatos firmados del lado del usuario no son funciones de comprar. Son funciones de discutir sobre la compra, seis semanas después, ante alguien que tiene que decidir quién tenía razón.

Dónde el relato adelanta a las pruebas

Hay tres cosas que se repiten sobre el UCP y que las fuentes primarias no respaldan tal cual.

«Más de 20 socios» es un recuento de respaldos. La formulación de Google es que el UCP fue «codesarrollado y respaldado por más de 20 socios». Un respaldo es una declaración pública de apoyo. No es una integración entregada, y desde luego no es un comercio en producción. Buscamos una fuente primaria con el número de comercios transaccionando sobre UCP y no la encontramos.

«Estándar abierto» y «estándar de Google» son ambas verdad, y la tensión es real. La especificación es de código abierto, el repositorio de GitHub acepta pull requests y la convención de nombres deja deliberadamente que cualquiera reclame su propio espacio de nombres. También: Google construyó la primera implementación de referencia, y para participar en esa, una empresa necesita una cuenta activa de Google Merchant Center con productos aptos para pago. Protocolo neutral, primer escenario con puerta.

El UCP no elimina al comercio. Esto se tergiversa lo suficiente como para decirlo claro: bajo UCP, la empresa conserva su propia lógica de negocio y sigue siendo Merchant of Record. El Embedded Checkout Protocol de Shopify hace el mismo compromiso en sentido contrario: cuando un flujo necesita a una persona, el agente carga una continue_url y el pago real del comercio se renderiza dentro de la superficie del agente sobre un canal JSON-RPC 2.0, y es el comercio quien finaliza la transacción. El agente es una superficie, no un sustituto.

Cuatro cosas que no pudimos verificar, señaladas como tales

La especificación publicada en ucp.dev en el momento de la consulta es la versión 2026-04-08, y su lista de capacidades estándar —Cart, Checkout, Identity Linking, Order— difiere del tutorial del 11 de enero, cuyos ejemplos corren sobre la versión 2026-01-11 y muestran checkout, discount y fulfillment. Algo se añadió entre esas dos fechas. No encontramos un registro de cambios primario que identifique cuándo, ni una nota de versión fechada para las versiones intermedias, así que informamos de la diferencia, no de un evento de publicación.

No encontramos ningún recuento publicado de comercios en producción sobre UCP, ni de Google, ni de Shopify, ni de ninguno de los socios que lo respaldan. La ausencia de una cifra no prueba que la cifra sea pequeña, pero es la razón por la que no imprimimos ninguna.

Google afirma haber construido la primera implementación de referencia que impulsa compras dentro del AI Mode de la Búsqueda y de la app Gemini. No hemos verificado de forma independiente la disponibilidad, la geografía ni la escala de ese despliegue.

Si el UCP se convertirá en el estándar del comercio agéntico es, al cierre de este texto, imposible de saber, y cualquier artículo que diga lo contrario está adivinando. La lectura honesta es más estrecha: existe una especificación, es pública, es inusualmente cuidadosa con la prueba, y varias empresas muy grandes firmaron el anuncio.

La mitad sin firmar

Apartémonos del comercio, porque la parte interesante se generaliza.

El UCP describe un mundo en el que una máquina actúa en tu nombre y cada paso de esa acción deja algo atrás: quién lo pidió, firmado; qué condiciones, firmadas; cuántas veces, con clave; en qué orden, correlacionado. Seis semanas después, cuando el cargo se disputa, hay un artefacto. Nadie tiene que recordar.

Ahora piensa de dónde viene realmente la autoridad para esas acciones. Un agente compra 400 unidades porque se tomó una decisión de compra. Un contrato se renueva porque alguien aceptó una cláusula. Un alcance cambia porque dos personas lo hablaron un jueves y una de ellas dijo que sí.

Esas conversaciones son la mitad sin firmar del mismo flujo de trabajo. La mitad de la máquina se está construyendo con recibos criptográficos y una especificación que trata las disputas como escenario de primera clase. La mitad humana, en la mayoría de las organizaciones, es la memoria de alguien, la memoria distinta de otro alguien, y un resumen escrito a partir de ambas.

La asimetría va a empeorar antes de mejorar, porque la mitad de la máquina mejora al ritmo de una especificación y la mitad humana no mejora en absoluto. Y el modo de fallo es concreto: no es que la gente mienta. Es que un artefacto derivado —un resumen, un acta, una lista de tareas— pasa a tratarse como el registro en cuanto desaparece aquello de lo que se derivó. Los resúmenes son, por construcción, con pérdida. Eso es lo que los hace útiles. Y eso mismo los hace mala fuente primaria: una vez descartado el original, no hay forma de distinguir un resumen con pérdidas de uno exacto.

Los diseñadores del UCP entendieron esto en la capa de protocolo y lo escribieron: conserva el original firmado, deriva de él lo que quieras y asegúrate de que la derivación siempre se pueda contrastar con algo que no se ha movido. Es una disciplina, no una tecnología, y se aplica igual de bien a una hora de gente hablando que a un POST /checkout-sessions.

En el fondo: el comercio agéntico es un estándar de justificantes disfrazado de compras

El Universal Commerce Protocol suele describirse como una forma de que los agentes de IA compren cosas. Leído de principio a fin, se describe mejor como un intento de responder a una pregunta con la que todo lo agéntico va a toparse constantemente: cuando una máquina actuó por mí, ¿qué se puede probar exactamente sobre aquello a lo que accedí?

La respuesta del UCP es buena: declara tus capacidades en público, firma las condiciones, firma el consentimiento, pon clave al reintento, correlaciona la llamada y firma el webhook que informa después de lo que pasó. Que el protocolo gane está genuinamente abierto. La pregunta sobre la que está construido no se va a ir, gane quien gane.

Queda una pregunta con la que conviene sentarse. Tus agentes están a punto de tener mejores registros de aquello a lo que accedieron que los que tú tienes de aquello a lo que accediste. ¿Dónde acaba eso?

---

Dónde encaja Telli.sh: nosotros construimos la mitad sin firmar. Telli.sh graba la conversación, separa a los interlocutores, traduce en directo entre 15 idiomas y conserva la grabación original y la transcripción completa junto a cada resumen que genera, para que el artefacto derivado nunca sea el único artefacto. Telli.sh no implementa UCP ni pretende hacerlo; abordamos el otro extremo del mismo problema: las decisiones que autorizan el comportamiento de los agentes suelen tomarse en voz alta y no se guardan en ninguna parte.

Graba tu próxima reunión de decisión

Fuentes

• Especificación Universal Commerce Protocol, Overview, versión 2026-04-08 — modelo de servicios, capacidades y extensiones, convención de nombres, versionado por fecha, algoritmo de intersección de capacidades, códigos de error de negociación y firma, capacidades estándar (Cart, Checkout, Identity Linking, Order), transportes, cabecera UCP-Agent y sintaxis RFC 8941, mecanismos de autenticación y onboarding sin permisos, descubrimiento de claves vía signing_keys, vinculación de identidad, firma obligatoria de webhooks y la sección Transaction Integrity and Non-Repudiation; consultado el 5 de septiembre de 2026
• Google Developers Blog, «Under the Hood: Universal Commerce Protocol (UCP)», 11 de enero de 2026 — lista de socios y la cifra de más de 20 respaldos, compatibilidad con AP2, A2A y MCP, el planteamiento N×N, el manifiesto /.well-known/ucp, el tutorial en cinco pasos y el conjunto de cabeceras de POST /checkout-sessions, Merchant of Record y la opción embebida, la implementación de referencia de Google en AI Mode y Gemini, y el requisito de Merchant Center; consultado el 5 de septiembre de 2026
• Shopify Engineering, Ilya Grigorik, «Building the Universal Commerce Protocol», 11 de enero de 2026 — el marco de 20+ años, miles de millones de transacciones y millones de comerciantes, el argumento de «no es un fallo, es una propiedad emergente», los cuatro principios de diseño y el traspaso del Embedded Checkout Protocol sobre JSON-RPC 2.0 vía continue_url; consultado el 5 de septiembre de 2026
• Agent Payments Protocol (AP2) — el protocolo de pagos con el que el UCP declara compatibilidad
• Universal Commerce Protocol en GitHub — el repositorio de código abierto citado en ambos anuncios
• Nuestra lectura de GPT-6 Astra y de lo que la capa de captura sigue decidiendo — el mismo argumento desde el lado del modelo: la calidad del razonamiento tiene su techo en lo que produjo el registro sobre el que razona