Qué es UCP y qué no es
UCP no es un framework de API de propósito general. Es un protocolo específico de dominio para el recorrido completo de compra agéntica: descubrimiento de productos, verificación de inventario, pago a través de AP2 y gestión post-compra. Define no solo el transporte y el formato (REST + JSON-RPC), sino también las convenciones semánticas, qué campos son obligatorios, qué valores son válidos, qué modelo de autenticación se aplica.
Una API REST general puede, en teoría, exponer todas las mismas capacidades, pero sin la semántica estandarizada, cada agente de IA necesitaría una integración personalizada con la API de cada comerciante. El valor de UCP es precisamente su estandarización: un agente que soporta UCP puede realizar transacciones con cualquier comerciante compatible con UCP sin desarrollo personalizado.
UCP vs APIs REST personalizadas
| Dimensión | API REST personalizada | UCP |
|---|---|---|
| Estandarización | Proprietary por comerciante | Estándar universal |
| Soporte de agente de IA | Requiere integración personalizada por agente | Cualquier agente compatible con UCP funciona de forma nativa |
| Autenticación | Varía (claves API, OAuth, etc.) | AP2 estandarizado + certificados de agente |
| Gestión de pagos | No incluido (API de pago separada) | Integrado mediante tokenización AP2 |
| Descubrimiento | Documentación manual | Registro UCP + llms.txt |
| Tiempo de integración | Días a semanas por agente | Minutos para cualquier agente compatible con UCP |
Si ya tienes una API REST, UCP no es un reemplazo, es una capa estandarizada adicional que expone tus capacidades al ecosistema agéntico. Mantienes tu API REST para las integraciones existentes; UCP abre un nuevo canal.
UCP vs GraphQL
GraphQL es un lenguaje de consulta que otorga a los consumidores de API un control flexible sobre los datos que recuperan. Es excelente para aplicaciones cliente que necesitan diferentes formas de datos para diferentes vistas. UCP, por el contrario, define un esquema fijo con campos específicos obligatorios y opcionales.
Para el comercio agéntico, la flexibilidad de GraphQL es en realidad una desventaja: los agentes de IA se benefician de estructuras de datos predecibles y consistentes que pueden aprender una vez y aplicar universalmente. Un endpoint GraphQL requiere que los agentes conozcan tu esquema específico; un endpoint UCP se ajusta a un esquema universal que ya entienden.
Dicho esto, algunos comerciantes implementan UCP sobre una capa interna de GraphQL, utilizando GraphQL para un acceso flexible a datos internos y UCP como interfaz externa estandarizada. Esta es una arquitectura sólida.
UCP vs punchout (cXML/OCI) para B2B
Los protocolos punchout (cXML de Ariba, OCI de SAP) han sido el estándar de e-procurement B2B desde finales de los años 90. Permiten a los compradores empresariales "salir" de su sistema de compras al catálogo de un proveedor, llenar un carrito y devolver los datos del pedido al sistema del comprador.
El modo B2B de UCP aborda un problema similar pero con diferencias significativas: el punchout requiere que un humano navegue por el sitio web del proveedor; UCP permite que un agente de IA interactúe con el catálogo del proveedor de forma programática. UCP también soporta AP2 para el pago, mientras que el punchout típicamente utiliza órdenes de compra y facturación.
Para los proveedores que ya soportan punchout, UCP no es un reemplazo a corto plazo, los sistemas de adquisición empresarial tardan en cambiar. UCP abre un nuevo canal para las herramientas de adquisición emergentes impulsadas por IA, mientras que el punchout continúa sirviendo a los flujos de trabajo ERP heredados.
Estrategia de migración: añadir UCP a la infraestructura existente
El enfoque recomendado para comerciantes con APIs existentes:
- Auditar los endpoints existentes: ¿cuáles de tus endpoints API actuales cubren el catálogo, el inventario, el pago y la gestión de pedidos? Estos se asignan a las cuatro categorías de endpoints principales de UCP.
- Construir una capa adaptadora UCP: crea endpoints compatibles con UCP que traduzcan las solicitudes a tu formato API existente y traduzcan las respuestas al esquema requerido por UCP. No reescribes tu backend; añades una capa de traducción.
- Añadir soporte AP2: la capa de pago es la parte que probablemente requerirá una nueva implementación. Contacta a tu procesador de pagos (Stripe, Adyen, etc.) para obtener su guía de integración AP2.
- Registrarse en el directorio UCP: envía la URL base de tu endpoint al registro de comerciantes UCP en ucp.dev.
- Probar y certificar: ejecuta el conjunto de pruebas oficial y busca la certificación UCP.
Lo que no necesitas cambiar
UCP no requiere que cambies tu: procesador de pagos (solo añade la capacidad AP2), sistema de gestión de pedidos (los datos de pedidos UCP pueden alimentar tu OMS existente a través de un adaptador), gestión de información de productos (las exportaciones PIM se convierten en la fuente para el catálogo UCP) o herramientas de servicio al cliente (los pedidos UCP aparecen en tu gestión de pedidos estándar, no por separado).