Los asistentes ya pueden buscar, comparar y recomendar productos. El siguiente paso consiste en permitirles preparar o ejecutar ciertas etapas de la compra. En 2026, el término comercio agénico designa estos recorridos en los que un agente actúa a partir de la intención de un usuario, dialoga con sistemas comerciales y mantiene el contexto hasta el pedido.
Google presentó Universal Commerce Protocol, o UCP, como un estándar abierto destinado a describir capacidades de comercio de manera coherente entre plataformas y comerciantes. Las integraciones de referencia apuntan especialmente a experiencias conversacionales. Al 17 de agosto de 2026, algunas funciones siguen estando en piloto o sujetas a elegibilidad: la preparación técnica debe distinguirse de la disponibilidad comercial.
Las versiones, esquemas, controladores y condiciones de acceso evolucionan; deben ser confirmados en la documentación oficial antes de cualquier integración.
Lo que cambia un comprador de software
Un visitante humano puede interpretar una página imperfecta, abrir varias pestañas, comprender una promoción ambigua o llamar al soporte. Un agente necesita contratos más explícitos:
- identificadores estables;
- atributos estructurados;
- precios y disponibilidad con fechas;
- políticas legibles;
- pasos transaccionales documentados;
- errores tipados;
- acciones reversibles;
- prueba del consentimiento.
El comercio agénico impulsa por lo tanto el comercio electrónico hacia una arquitectura más API-first. No reemplaza al sitio: crea una superficie adicional que debe compartir la misma verdad sobre productos y transacciones.
UCP en pocas palabras
UCP describe capacidades del ciclo de compra y permite a un comerciante publicar un perfil indicando las versiones y funciones compatibles. En la integración documentada por Google, este perfil se expone en una dirección conocida, y luego las API pueden gestionar el descubrimiento, el pago y otros pasos según el modo elegido.
El principio importante no es solo el formato. Se trata de separar:
- la superficie donde el usuario expresa su necesidad;
- el agente que orquesta;
- el servidor comerciante que sigue siendo dueño de sus reglas;
- los proveedores de identidad y de pago;
- los sistemas de control y de ejecución.
El comerciante conserva la responsabilidad de sus precios, políticas, pedidos y relación con el cliente según el modelo de integración.
Comenzar por la verdad produce
Un agente no puede recomendar correctamente un artículo cuyos datos son escasos. La base es el PIM, el catálogo o la base de producto:
- identificador global y SKU;
- variantes ;
- atributos normalizados;
- compatibilidades ;
- imágenes ;
- disponibilidad;
- precio ;
- promociones ;
- restricciones ;
- plazos;
- vendedores si mercado
- condiciones de devolución.
Las descripciones de marketing no son suficientes. Los criterios discriminantes deben estar estructurados: dimensiones, material, uso, consumo, tamaño, normas, piezas compatibles o zona de entrega.
La frescura es esencial. Un dato extraído el día anterior puede ser falso en el momento del checkout.
Las nueve capacidades para hacer explícito
1. Descubrimiento
Buscar y filtrar con criterios de negocio, no solo palabras clave. El resultado especifica la correspondencia, las variantes y los límites.
2. Precio
Calcular un precio determinista según la moneda, el cliente, la cantidad, la promoción, el impuesto y la fecha. El agente debe conocer la duración de la validez.
3. Acciones
Distinguir información de disponibilidad y reserva. Los conflictos concurrentes deben producir un error aprovechable.
4. Entrega
Calcular opciones, plazos, costes, puntos de recogida, restricciones y huella si está disponible, a partir de una dirección validada.
5. Identidad
Gestionar invitado, cuenta existente, consentimientos, fidelidad y preferencias sin exponer más datos de los necesarios.
6. Pago
Crear una sesión versionada que contenga líneas, precios, impuestos, envíos, políticas y expiración. Cualquier modificación debe ser visible.
7. Pago
Usar tokenización, autenticación y confirmación adecuadas. El agente no recibe datos de tarjeta en crudo.
8. Pedido
Confirmar una sola vez, proporcionar un identificador, exponer el estado y gestionar la cancelación o modificación según las reglas.
9. Postventa
Hacer accesibles el soporte, las devoluciones, el reembolso, la garantía, el litigio y el comprobante de compra.
Arquitectura que conecta un agente y un servidor de comercio con los sistemas de catálogo, precios, stock, checkout, pago, pedido y servicio al cliente.
Diseñar un checkout idempotente
Los agentes y redes pueden reintentar. Una solicitud repetida no debe crear dos órdenes. Cada operación de escritura utiliza una clave de idempotencia, una versión de sesión y un estado explícito.
Ejemplo de ciclo:
- creación de sesión ;
- adición o validación de las líneas;
- cálculo del precio ;
- selección de entrega ;
- confirmación de las políticas ;
- autorización de pago;
- validación final;
- creación de pedido ;
- emisión de la confirmación.
Si el precio o el stock cambian, el servidor devuelve una diferencia estructurada. El agente solicita una nueva confirmación en lugar de continuar en silencio.
Mantener al humano en las decisiones sensibles
Un mandato « cómprame el más barato » es insuficiente si existen restricciones importantes. La interfaz debe aclarar:
- presupuesto máximo;
- producto exacto o sustituible;
- cantidad;
- dirección ;
- plazo;
- vendedor ;
- garantías ;
- condiciones de devolución;
- frecuencia para una suscripción.
Se necesita una confirmación final cuando el mandato no es lo suficientemente preciso, cuando el precio cambia o cuando la transacción presenta un riesgo. Las acciones autónomas siguen limitadas a políticas explícitas.
Gestionar la identidad sin crear un perfil opaco
La vinculación de identidad puede enlazar una cuenta de usuario con el comerciante a través de mecanismos como OAuth. Los permisos deben ser mínimos y revocables. El usuario sabe qué información se comparte y con qué propósito.
Evitar transformar al agente en un agregador incontrolado de preferencias. La personalización debe distinguir entre los datos necesarios para el pedido y el perfilado opcional.
Para el B2B, la identidad incluye empresa, rol, derechos de compra, centro de costo, límite, aprobador y condiciones contractuales.
Pago y mandato verificable
La seguridad del pago se basa en el PSP y los mecanismos regulatorios existentes. Los protocolos agénticos pueden añadir una prueba de la intención: monto, comerciante, alcance, duración y productos autorizados.
El sistema guarda:
- solicitud inicial ;
- opciones presentadas;
- consentimiento;
- versión de las condiciones ;
- autorización ;
- resultado;
- posible cancelación.
Esta trazabilidad protege al usuario y al comerciante sin registrar innecesariamente los datos sensibles del medio de pago.
Asegurar la interfaz agénica
Los riesgos incluyen:
- falsa identidad de comerciante;
- manipulación del catálogo;
- inyección de prompt en una ficha de producto;
- secuestro de redirección;
- doble pedido;
- modificación de precio ;
- fraude en la devolución;
- fuga de datos ;
- abuso de promoción;
- saturación de las API.
Los controles incluyen firma, TLS, autenticación mutua según el contexto, límites, validación de esquema, aislamiento del contenido no confiable, lista de capacidades, registros, detección de fraude y confirmación humana.
Una descripción del producto nunca debe interpretarse como una instrucción del sistema por el agente.
Preparar el soporte y los comentarios
El comercio no se detiene en el pago. Un agente debe poder encontrar el pedido con la autorización del usuario, explicar su estado, iniciar una devolución conforme y remitirlo al soporte.
Las políticas deben estar estructuradas y ser coherentes con el texto legal mostrado. El comerciante debe permanecer accesible mediante medios claros. Una automatización no debe ocultar un derecho de recurso humano.
Medir algo diferente a la conversión
Seguir :
- tasa de descubrimiento relevante;
- errores de precio o de stock;
- creación de sesión ;
- solicitudes de reconfirmación;
- llamadas dobles evitadas;
- fallos de pago;
- cancelaciones ;
- devoluciones;
- litigios;
- tiempo hasta asistencia humana ;
- margen ;
- satisfacción.
Un aumento de conversión acompañado de una alta tasa de devolución puede indicar que el agente elige mal.
Una hoja de ruta realista
Paso 1: asegurar la fiabilidad de los datos
Identificadores, atributos, precios, stock, políticas y calidad de los flujos.
Paso 2: desacoplar las capacidades
Crear APIs de lectura estables antes de las operaciones de escritura.
Paso 3: industrializar la sesión de pago
Versión, expiración, idempotencia, errores y recálculo.
Paso 4: integrar identidad y pago
Permisos, consentimiento, confirmación, fraude y auditoría.
Paso 5: exponer pedido y posventa
Estatutos, soporte, devoluciones y reversibilidad.
Paso 6: agregar un protocolo
Implementar UCP u otra interfaz cuando el canal y las condiciones lo justifiquen, sin acoplar el núcleo del negocio a una sola interfaz.
Una preparación útil incluso sin canal inmediato
La actualización requerida para el comercio de agentes ya mejora el sitio, las aplicaciones, los marketplaces y los socios: catálogo propio, precios deterministas, pago robusto, APIs idempotentes y servicio al cliente conectado.
Partitech puede auditar el catálogo y el túnel, diseñar las APIs, integrar los sistemas de pago y de pedido, luego añadir las interfaces agénticas. El objetivo es hacer que el comercio sea interpretable y seguro para nuevos canales sin perder el control de la transacción ni de la relación con el cliente.
Hablemos de su proyecto
Evaluar la preparación de su plataforma de comercio electrónico para el comercio agente con Partitech. Contacte a Partitech.