Si llevas un ecommerce, este año habrás visto pasar el titular tres o cuatro veces: Google y Shopify han sacado un protocolo para que la inteligencia artificial compre por ti. Y probablemente también te haya pasado lo siguiente: buscas qué tienes que hacer exactamente y lo único que aparece son notas de prensa repitiendo las mismas cuatro frases.
Cómo funciona el Universal Commerce Protocol por dentro, qué hay que montar para entrar, qué trabajo te cae encima que no aparece en los titulares y en qué momento conviene mover ficha.
¿Qué es el Universal Commerce Protocol?
El Universal Commerce Protocol (UCP) es un estándar abierto que define cómo un agente de inteligencia artificial descubre lo que vendes, negocia qué operaciones puede ejecutar contra tus sistemas y completa una compra sin que el usuario llegue a pisar tu web.
Lo desarrollan Google y Shopify, y la especificación es pública. Funciona sobre las mismas tecnologías que ya usa tu tienda, así que no hay nada exótico debajo.
Cinco términos imprescindibles
| Término | Qué es, en una línea |
| Agente | El programa de IA que compra en nombre del usuario. Hoy, el Modo IA de la Búsqueda de Google y Gemini |
| Perfil | Un archivo público en tu dominio donde declaras qué sabe hacer tu tienda |
| Capacidad | Cada operación que ofreces por separado: buscar producto, crear carrito, pagar, consultar pedido |
| Endpoint | La URL de tu servidor que atiende esas llamadas |
| Merchant of record | Quien responde legal y económicamente de la venta. En UCP, siempre tú |
¿Cómo funciona en cuatro pasos?
- Publicas un perfil: Un archivo legible por máquina en /.well-known/ucp, alojado en tu propio dominio. Ahí declaras qué servicios ofreces, qué capacidades admites, con qué gestores de pago trabajas y tus claves públicas para verificar firmas.
- El agente se presenta: En cada petición envía su propio perfil mediante la cabecera UCP-Agent. Sabes con quién hablas antes de contestar.
- Se negocia la intersección: Tu servidor cruza tu lista de capacidades con la del agente y se queda solo con las que están en las dos, eligiendo la versión más reciente que ambos soporten.
Nadie te obliga a soportar nada. Si no declaras carrito, no hay carrito, y el agente se adapta a lo que tú hayas expuesto.
- El transporte da igual: El mismo servicio se puede ofrecer por REST, por MCP, por A2A o de forma incrustada. Cambia el sobre, no la lógica de negocio.
Las capacidades se nombran con dominio invertido: dev.ucp.shopping.checkout, dev.ucp.shopping.cart, dev.ucp.common.identity_linking.
No hay un registro central que apruebe nada. Quien controla el dominio controla el nombre y responde de su esquema, igual que en los paquetes de Java o en los identificadores de aplicación de iOS.
Sigues siendo el dueño de la venta
En cualquier transacción tú eres el merchant of record: el responsable legal y financiero de la operación, dueño de la relación con el cliente y de sus datos.
Conviene retener ese término. Es el que sostiene casi todos los argumentos a favor del protocolo y también casi todo el trabajo que te cae encima.
Lo que cambia de verdad: tu catálogo deja de ser un escaparate
El fondo del asunto no es tecnológico. Llevamos veinte años optimizando para una persona que mira: fotografía, ficha persuasiva, prueba social, embudo.
Un agente no mira: Compara atributos y condiciones, descarta lo que no cuadra y ejecuta.
Qué pierde peso y qué lo gana
| Decidía la compra hasta ahora | Decide cuando compra un agente |
| Fotografía y diseño de la ficha | Atributos completos y bien tipados |
| Copy persuasivo y prueba social | Stock real en el momento de la consulta |
| Navegación y velocidad de la web | Coste de envío calculable por API |
| Confianza construida en la marca | Política de devoluciones legible por máquina |
Dicho de la forma más incómoda posible: las condiciones comerciales que hasta hoy vivían en la letra pequeña pasan a ser el argumento de venta, porque son lo único que el agente compara.
El feed pasa a ser un activo de posicionamiento
De ahí sale la consecuencia práctica más importante de todo el artículo: si un atributo está en el texto de la ficha pero no en el feed, para el agente no existe.
El feed de producto deja de ser un fichero técnico que alguien exporta y se convierte en un activo de posicionamiento por derecho propio, al mismo nivel que la ficha.
Quien ya lo trabaja para Shopping o para marketplaces reconocerá la tarea, porque es exactamente la misma.
¿Qué hay que montar para entrar?
Paso cero: Merchant Center
El punto de entrada no es el protocolo. Es Merchant Center.
Google exige feed de productos, políticas de devolución, activos de marca y datos de contacto completos y actualizados antes de cualquier integración.
Si ya tienes eso en orden tienes medio camino hecho, y no es una frase de consuelo: es literalmente el mismo activo.
Dos rutas de integración
| Checkout nativo | Checkout incrustado | |
| Qué es | Tres endpoints REST: crear sesión, actualizar y completar | Un iframe que renderiza tu propio proceso de pago dentro de la superficie de IA |
| Quién puede usarlo | Cualquier comercio aprobado. Es la opción por defecto | Solo comercios aprobados con marca muy personalizada o flujos de pago complejos |
| Cuándo tiene sentido | Catálogo estándar y checkout convencional | Cuando tu proceso de compra tiene lógica propia que no cabe en el flujo estándar |
El resto del trabajo técnico
Es acotado y se puede presupuestar. Son tres cosas:
- Publicar el perfil en tu dominio.
- Sincronizar los estados del pedido llamando a los webhooks de Google, que son las URL a las que avisas cuando algo cambia.
- Decidir si permites compra como invitado o vinculación de cuenta con OAuth 2.0, el estándar que usas cuando un usuario entra en un sitio con su cuenta de otro.
Pagos: dos detalles antes de presupuestar
No necesitas tener Google Pay implantado en tu web, pero tu PSP tiene que ser capaz de procesar sus tokens. La mayoría de los grandes proveedores ya lo hace.
Los dos detalles que sorprenden en la primera reunión técnica:
- En estas superficies solo se usa PAN_ONLY como método de autenticación.
- Tu configuración de Google Pay hay que declararla otra vez dentro del perfil UCP, porque no hereda la que ya tengas montada.
Una advertencia que casi nadie cuenta
Esto no es autoservicio. Hay lista de espera y aprobación previa de Google antes de salir en vivo.
No es un plugin que instalas un martes, así que tampoco es una fecha que puedas comprometer con dirección.
El trabajo que no aparece en los titulares
Ser merchant of record tiene la lectura buena, que es la que se publica: conservas el cliente, los datos y tus condiciones de venta.
Y tiene la otra, que es la que hay que presupuestar. Según la documentación de Google, actualizada el 25 de agosto de 2026, tú eres responsable de:
- Comprobar el stock en tiempo real y devolver el código out_of_stock cuando corresponda.
- Validar las direcciones de envío: Google no bloquea envíos internacionales por su cuenta: te pasa el país de destino y tu sistema tiene que rechazar lo que quede fuera de tus zonas con los códigos de error previstos.
- Marcar bien la severidad de los errores: Si un error recuperable no se etiqueta como recuperable, el usuario se encuentra una pantalla de bloqueo y no puede terminar la compra. Un campo mal puesto y pierdes el pedido.
- Mantener el endpoint disponible: Google envía comprobaciones periódicas de salud a tu API.
¿Es capaz una inteligencia artificial de leer tu catálogo?
Revisamos tu feed, tus condiciones de envío y devolución y tu medición, y te decimos qué falta, en qué orden y con qué esfuerzo.
Solicita la revisión de tu catálogoDos puntos para legal, antes que para desarrollo
- Los datos del pedido se quedan. Google conserva de forma indefinida la información que muestra al usuario en su página de pedidos, hasta que este pida borrarla.
- El consentimiento sigue siendo tu problema. La opción de que el comprador acepte tus comunicaciones comerciales dentro del proceso de compra todavía no existe: figura como función planificada. Hoy tienes que resolverlo con un usuario que quizá nunca vea tu web.
- Hay un tercer punto que suele plantear el equipo de seguridad: no puedes restringir el tráfico por país con bloqueo geográfico de IP, porque Google gestiona su tráfico de salida de forma dinámica y no garantiza el país de origen. La vía es autenticar por token OAuth 2.0.
Buena noticia: esto se puede medir desde hoy
Este es el detalle más aprovechable de toda la documentación y el que menos se ha contado. Las peticiones de agentes llegan identificadas.
| Qué llega | Cómo lo reconoces |
| Petición de un agente | Cabecera UCP-Agent:Profile |
| Origen de la petición | User-Agent que empieza por Google/UCP |
| Comprobación de salud | User-Agent Google-UCP-Prober/1.0 |
Traducido: puedes segmentar ese tráfico en analítica y en logs sin haber integrado nada. Y conviene hacerlo antes de que llegue volumen, porque la conversación difícil no es técnica.
Menos tráfico y más negocio
Llevamos años usando el tráfico como indicador de éxito. Si parte de la compra se cierra dentro de una conversación, puede darse una situación que hace unos años habría parecido absurda: las sesiones bajan y los pedidos no.
No porque lo estés haciendo peor, sino porque han desaparecido pasos intermedios.
Cualquier informe que mire sesiones sin mirar pedidos va a contar una historia falsa. Y el primero que la cuente se va a equivocar en la dirección más cara.
UCP no está solo, y por eso no hay que elegir
Hay un segundo estándar abierto resolviendo el mismo problema desde el otro lado del mercado, y conviene tenerlo en el mapa antes de apostar.
| UCP | ACP | |
| Quién lo desarrolla | Google y Shopify | Stripe y OpenAI |
| Dónde opera | Modo IA de la Búsqueda y Gemini | Pago instantáneo de ChatGPT |
| Desde cuándo | Versión de perfil 2026-01-11 en la demostración pública de Shopify | Publicado como código abierto el 29 de septiembre de 2025 |
| Transportes | REST, MCP, A2A, incrustado | REST y MCP |
| Quién responde de la venta | El comercio, como merchant of record | El comercio, como merchant of record |
Los dos comparten el planteamiento de fondo: sigues siendo el responsable de la venta, conservas la relación con el cliente y puedes seguir con tu procesador de pagos.
Y los dos exigen solicitar participación en la plataforma correspondiente. Implementar la especificación no te hace aparecer automáticamente en ningún sitio.
Un dato para comparar modelos de negocio
En su anuncio del pago instantáneo, OpenAI indicó que el vendedor paga una comisión por cada compra completada, que el servicio es gratuito para el usuario y que los resultados de producto son orgánicos, no patrocinados. Arrancó en Estados Unidos con vendedores de Etsy y compras de un solo artículo.
En la documentación de UCP que hemos consultado no aparece una comisión equivalente, así que no es posible comparar ambos modelos: no significa que no exista, sino que no está publicado ahí.
Nuestra recomendación: no elijas el estándar. Elige el trabajo que sirve para los dos, que es catálogo limpio, condiciones explícitas y capacidad de exponerlo por API. Eso rinde igual si gana uno, si gana el otro o si conviven, que es el escenario más probable.
¿Cuánto de esto está realmente terminado?
Menos de lo que parece. Y decirlo no es escepticismo: es lo que se lee en la propia especificación.
Las capacidades se versionan por fecha y muchas siguen marcadas como borrador. La demostración pública de Shopify declara la versión 2026-01-11. Las guías de implementación de Google cuelgan de una versión fechada en abril de 2026.
La hoja de ruta del estándar avisa por escrito de que no constituye un compromiso de entrega. Lo que hoy figura como próximo puede cambiar, ampliarse o desaparecer:
- Carritos de varios artículos.
- Programas de fidelización con vinculación de cuenta.
- Recogida en tienda y experiencias locales.
- Soporte posventa para seguimiento y devoluciones.
Sobre el calendario en nuestro mercado no hay nada oficial. La consultora Hiberus estima que España y Latinoamérica acelerarán su adopción entre 2026 y 2028, y así conviene leerlo: como estimación de una consultora, no como dato de mercado.
Lo importante es que ninguno de los cuatro trabajos que recomendamos más abajo depende de esa fecha. Si el protocolo tarda, los habrás hecho igual y habrán rendido por su cuenta.
¿Dónde se decide esto dentro de la empresa?
Tratar UCP como un asunto del equipo de posicionamiento es el error más caro que se puede cometer aquí. Son cuatro conversaciones distintas y ninguna se sostiene sola.
- El dato y el catálogo. Es donde se decide si te consideran: atributos completos, unidades coherentes, stock fiable y condiciones de envío y devolución sin ambigüedad. Lo que no esté en el feed, no existe. Este trabajo es el mismo que ya rinde en ecommerce y en marketplaces, así que no es presupuesto nuevo: es presupuesto que ya deberías estar gastando.
- El desarrollo. La parte acotada: perfil, endpoints, webhooks, identificación del usuario y validación con el PSP. Suele ser menos trabajo que la limpieza previa del catálogo.
- La medición. Segmentar el tráfico de agentes, separar métricas de visibilidad de métricas de acción y preparar el terreno para explicar en un comité por qué bajan las sesiones y no bajan los pedidos. Si esto no está montado antes, la primera lectura de datos será la equivocada.
- La gobernanza. Qué puede consultar un agente, qué puede ejecutar y dónde tiene que intervenir una persona. Y la pregunta previa a todas: qué parte de la relación con el cliente estás dispuesto a delegar. Un consumible recurrente de ticket bajo admite automatización casi total; una venta consultiva, no. La respuesta puede ser distinta entre líneas de producto de la misma empresa.
Si te interesa el marco estratégico completo de este cambio, más allá del ecommerce, lo desarrollamos en Del SEO al negocio agéntico.
¿Qué hacer ahora sin integrar nada?
1. Audita el catálogo como si lo fuera a leer una máquina. Empieza por las referencias que más facturan, no por el catálogo entero. Si el ejercicio no revela nada en tus cincuenta productos principales, es poco probable que lo revele en los cinco mil restantes.
2. Pon en orden Merchant Center. Es requisito previo y es trabajo que rinde en Shopping desde el primer día, pase lo que pase con el protocolo.
3. Prepara la medición. Segmenta el tráfico de agentes y cambia el indicador antes de que alguien saque conclusiones del gráfico equivocado.
4. Decide la gobernanza antes que la tecnología. Abrir todas las puertas de la empresa no es una estrategia.
Cinco errores que se van a cometer con esto
- Tratarlo como un proyecto de SEO. Sin desarrollo, sin medición y sin alguien que decida la gobernanza no hay integración posible.
- Integrar antes de limpiar el catálogo. Exponer por API un catálogo inconsistente solo consigue que el error viaje más rápido y llegue más lejos.
- Medir el éxito en sesiones. Si la compra se cierra en la conversación, tu tráfico baja y tus pedidos no.
- Dar por hecho que la aprobación es automática. Hay lista de espera y revisión previa.
- Elegir estándar en 2026. UCP y ACP se mueven los dos y ninguno ha ganado. Invertir en lo que sirve para ambos cuesta lo mismo y arriesga menos.
Preguntas frecuentes
¿Qué es el Universal Commerce Protocol?
Un estándar abierto que define cómo un agente de inteligencia artificial descubre tu catálogo, negocia qué operaciones puede ejecutar y completa una compra. Lo desarrollan Google y Shopify y la especificación es pública.
¿Pierdo el control de mis datos de cliente?
No: sigues siendo merchant of record y conservas la propiedad de la relación y de los datos. Lo que sí retiene Google de forma indefinida es la información del pedido que muestra al usuario en su página de pedidos, hasta que este pida borrarla.
¿Necesito estar en Shopify?
No. El protocolo es abierto y no depende de una plataforma. Shopify lo codesarrolla y lo trae integrado, pero cualquier comercio puede publicar su perfil e implementar los endpoints sobre su propia arquitectura.
¿Cuánto trabajo de desarrollo supone?
La integración nativa son tres endpoints REST, más la publicación del perfil, la sincronización de estados por webhooks y, si eliges cuenta vinculada en lugar de compra como invitado, OAuth 2.0. El trabajo previo de catálogo y feed suele ser mayor que el de la integración.
¿Puedo elegir a qué agentes vendo?
El perfil declara qué capacidades expones y a quién autenticas, y las peticiones llegan identificadas por cabecera. Lo que no puedes hacer es filtrar por país con bloqueo geográfico de IP.
¿Cuándo llega a España?
No hay fecha oficial. Hiberus estima que España y Latinoamérica acelerarán entre 2026 y 2028. La preparación de catálogo, feed y medición no depende de esa fecha, así que tampoco hay motivo para esperarla.
