Dibuja el customer journey de automoción y casi siempre obtienes la misma diapositiva: descubrimient…
Comercio agéntico: construir la arquitectura que los agentes de IA realmente necesitan
En algún momento de las primeras semanas de 2026, lo teórico se volvió práctico. OpenAI y Stripe publicaron conjuntamente el Agentic Commerce Protocol. Google lanzó su Universal Commerce Protocol. Microsoft Copilot Checkout se lanzó con Shopify y PayPal como socios desde el primer día. En cuestión de pocos meses, la infraestructura para un nuevo modo de comercio pasó de los whitepapers a las implementaciones en producción.
La premisa es sencilla: los agentes de IA, actuando en nombre de los consumidores, ahora pueden descubrir productos, comparar opciones, negociar condiciones y completar compras sin que el consumidor toque un solo botón. Esto no es una mejora marginal del embudo de compra. Es un cambio estructural en quién realiza la compra.
Para los CTOs y tech leads que hoy construyen sistemas de comercio, la pregunta clave no es si el comercio agéntico va a importar. Va a importar, y antes de lo que sugieren la mayoría de las previsiones. La pregunta es si vuestra arquitectura actual es capaz de dar servicio a estos agentes y, si no lo es, qué debe cambiar exactamente.
Entender primero el lado de la demanda
Antes de entrar en la arquitectura, vale la pena anclar las decisiones técnicas en datos reales de adopción. Según investigaciones de mercado recientes, el 73% de los consumidores ya utiliza IA en alguna parte de su proceso de compra. El 70% afirma sentirse cómodo dejando que un agente de IA realice compras en su nombre. Las proyecciones de McKinsey sitúan la oportunidad global del comercio agéntico entre 3 y 5 billones de dólares para 2030.
Estas cifras representan un desplazamiento de dónde se toman las decisiones de compra. Cuando un consumidor le pide a un asistente de IA que "le busque una maleta de cabina que cumpla los requisitos de Lufthansa, cueste menos de 200 € y se envíe en un plazo de dos días", no está escribiendo una consulta de búsqueda. Está delegando una tarea. El agente que gestiona esta tarea consultará APIs, analizará datos de producto estructurados, comprobará el inventario en tiempo real y completará una transacción, todo ello sin cargar una sola página web.
O vuestra plataforma de comercio habla el idioma de este agente, o queda ignorada.
La capa de protocolos: qué estándares están emergiendo
El ecosistema del comercio agéntico todavía es joven, pero la consolidación de protocolos está ocurriendo más rápido de lo esperado. Entender el panorama actual de estándares es esencial para cualquier planificación de arquitectura en 2026.
El Agentic Commerce Protocol (ACP) de OpenAI define cómo los agentes de IA interactúan con los comercios para coordinar pedidos, pagos y cumplimiento. Publicado conjuntamente con Stripe, especifica esquemas JSON para los endpoints de producto, la gestión del carrito, los flujos de checkout y el estado de los pedidos. Fundamentalmente, incluye modelos de delegación que permiten a los consumidores conceder a los agentes una autoridad de compra limitada.
El Universal Commerce Protocol (UCP) de Google adopta un enfoque ligeramente distinto, centrado en el descubrimiento y la comparación de productos a gran escala. Pone el énfasis en representaciones canónicas de producto y en precios y disponibilidad en tiempo real, optimizados para agentes que necesitan evaluar de forma eficiente grandes catálogos de productos.
Microsoft Copilot Checkout es menos un protocolo y más una capa de integración de plataforma, pero su rápida adopción por parte de las principales plataformas de comercio indica hacia dónde se están moviendo los compradores enterprise. Si vuestros clientes B2B utilizan los copilots de Microsoft 365, querréis contar con compatibilidad de checkout.
Todavía ningún estándar se ha impuesto. De forma pragmática, construir en torno a APIs REST limpias, bien documentadas y con esquemas estables os posiciona para adaptaros a cualquier protocolo que acabe dominando, en lugar de apostar por uno solo desde el principio.
Los requisitos arquitectónicos fundamentales
El comercio agéntico no requiere una pila completamente nueva. Requiere una pila que ya era buena. En concreto, amplifica el valor de las arquitecturas API-first y headless, y expone las debilidades de los sistemas monolíticos con superficies de API deficientes. Esto es lo que los agentes realmente necesitan de vuestra infraestructura:
Datos de producto en tiempo real mediante APIs limpias
Un agente que toma una decisión de compra necesita datos de producto precisos y completos en el momento exacto de la consulta. Esto significa que vuestras APIs de producto deben devolver el estado del inventario en tiempo real, no valores en caché que podrían tener horas de antigüedad. Significa que las APIs de precios deben reflejar las promociones vigentes y los precios específicos por cliente, no precios estáticos de catálogo. Significa que los datos de atributos deben estar completos: dimensiones, materiales, información de compatibilidad, certificaciones de sostenibilidad y cualquier otra propiedad estructurada que un consumidor pueda especificar como criterio de filtrado.
Suena obvio, pero es precisamente ahí donde la mayoría de los sistemas de comercio fallan. Los datos de producto que eran adecuados para la indexación en buscadores suelen ser inadecuados para el consumo por parte de agentes. Taxonomías inconsistentes, atributos ausentes y unidades no normalizadas (mezclando "L" con "Large" con "52" en un campo de talla) generan fallos posteriores cuando los agentes intentan filtrar de forma programática.
Autenticación basada en tokens, sin sesión
La autenticación tradicional en comercio se basa fuertemente en la sesión, pensada para navegadores que mantienen cookies entre cargas de página. Los agentes son clientes stateless. Se autentican por cada petición mediante tokens y requieren scopes de autorización granulares que reflejen los permisos que el consumidor ha concedido.
El patrón emergente es OAuth 2.0 con scopes específicos de comercio: read:products, write:cart, execute:checkout, read:orders. Los consumidores conceden estos scopes a los agentes con límites definidos (importes máximos de transacción, comercios aprobados, categorías de producto). Vuestra arquitectura de autenticación debe soportar este modelo de delegación, no solo para los consumidores finales sino también para los compradores B2B que conceden a los agentes acceso a los flujos de procurement corporativos.
Flujos de checkout deterministas
El checkout es el punto donde el comercio agéntico se complica. Una persona que navega un checkout puede gestionar la ambigüedad: puede resolver errores de validación de dirección, seleccionar opciones de envío desde un desplegable o responder a notificaciones de falta de stock. Un agente necesita un flujo de checkout completamente determinista y navegable de forma programática.
Esto significa: una API de checkout de una sola llamada o con pasos mínimos, códigos de error explícitos con rutas de resolución legibles por máquinas, payloads de confirmación claros con IDs de pedido y referencias de seguimiento, y soporte de webhooks para actualizaciones de estado asíncronas. Los flujos de checkout construidos para el renderizado en el navegador, con formularios multipaso cargados de JavaScript, son en la práctica incompatibles con el comercio impulsado por agentes sin una adaptación significativa.
Gestión estructurada de errores e idempotencia
Los agentes pueden reintentar las peticiones. Las redes fallan. Se producen race conditions. Vuestras APIs de comercio deben soportar operaciones idempotentes, en particular para las mutaciones del carrito y la creación de pedidos, de modo que los reintentos de los agentes no generen pedidos duplicados ni estados de carrito corruptos. Se trata de higiene estándar de API, pero sorprendentemente suele faltar en sistemas de comercio que nunca se diseñaron para clientes programáticos a gran escala.
Arquitectura MACH: el encaje natural
Si habéis invertido en una arquitectura MACH (Microservices, API-first, Cloud-native, Headless), estáis en una posición significativamente mejor que las organizaciones que operan pilas monolíticas. Los sistemas MACH están, por diseño, compuestos por servicios desplegables de forma independiente y expuestos mediante APIs. Cada capacidad, catálogo de productos, motor de precios, gestión del carrito, checkout, gestión de pedidos, inventario, es un servicio independiente que puede ser consumido por los agentes con la misma facilidad que por un storefront basado en navegador.
La ventaja más profunda es la flexibilidad composicional. Un agente podría prescindir por completo del storefront y encadenar llamadas a vuestra API de producto, API de precios, API de carrito y API de checkout en una secuencia optimizada para su tarea específica. Las arquitecturas MACH soportan esto de forma nativa. Los sistemas monolíticos normalmente no, porque sus límites de servicio internos nunca se diseñaron para exponerse externamente de esta manera.
Para los equipos MACH, el trabajo por delante consiste menos en reconstruir y más en ampliar: reforzar los esquemas de API para el cumplimiento de protocolos, mejorar la calidad de los datos para satisfacer los requisitos de parsing de los agentes e implementar los patrones de delegación de autenticación descritos anteriormente.
El problema de la información de producto
Uno de los desafíos más subestimados a la hora de prepararse para el comercio agéntico es el estado de la información de producto. Las plataformas de comercio que han evolucionado de forma orgánica tienden a acumular una deuda de datos considerable: atributos de producto añadidos de manera inconsistente entre las secciones del catálogo, descripciones escritas para copy de marketing en lugar de para el parsing automático, y estructuras de taxonomía que tenían sentido hace cinco años pero que no se corresponden de forma limpia con los filtros de atributos que aplicarán los agentes.
Un sistema PIM (Product Information Management) se convierte en infraestructura crítica en un mundo de comercio agéntico, no porque organice el contenido de producto para los merchandisers, sino porque establece las garantías de calidad de datos de las que dependen los agentes. Sin una única fuente de verdad fiable para los atributos de producto, las pipelines de datos en tiempo real hacia las APIs de comercio propagarán inconsistencias en cascada.
Si vuestra organización no cuenta con una implementación de PIM madura, el camino hacia la preparación para el comercio agéntico probablemente pase por ahí. No es una solución rápida, pero es un trabajo fundacional que rinde beneficios mucho más allá del caso de uso agéntico.
Answer Engine Optimization: el SEO del comercio agéntico
La optimización tradicional para motores de búsqueda se centra en señales de ranking: backlinks, autoridad de página, posicionamiento de palabras clave. En el comercio agéntico, la visibilidad requiere un tipo distinto de optimización. Cuando un consumidor delega el descubrimiento de productos en un agente de IA, el agente no está comprobando los rankings de búsqueda. Está evaluando la calidad de vuestros datos de producto, la completitud de las respuestas de la API y el cumplimiento de los protocolos.
El Answer Engine Optimization (AEO) es la disciplina emergente que aborda esto. En términos prácticos, significa garantizar que vuestro catálogo de productos sea lo bastante rico semánticamente para que los agentes puedan asociar productos con la intención del consumidor con confianza. Significa exponer atributos de sostenibilidad sobre los que los agentes puedan filtrar cuando un consumidor especifica criterios de compra ética. Significa contar con datos de disponibilidad precisos, de modo que los agentes no recomienden productos que no puedan enviarse dentro del plazo solicitado.
Se trata de una nueva capacidad que hay que integrar en vuestras operaciones de comercio. La gobernanza de los datos de producto, la puntuación de completitud de atributos y la monitorización en tiempo real de la calidad de las APIs no forman parte tradicionalmente del ámbito de un equipo de tecnología de e-commerce. En la era agéntica, sí lo hacen.
Qué priorizar en 2026
Para los líderes técnicos que planifican sus roadmaps, la preparación para el comercio agéntico no es un único proyecto. Es una capacidad que emerge de una serie de inversiones específicas. Sobre la base de nuestro trabajo con arquitecturas de comercio composable en la región DACH y más allá, priorizaríamos lo siguiente:
Empezad con una auditoría de APIs. Mapead cada capacidad de comercio con su superficie de API actual. Identificad dónde faltan APIs, están incompletas o dependen del estado de sesión. Esta evaluación define la brecha entre vuestra arquitectura actual y la preparación para agentes.
Realizad una evaluación de la calidad de los datos sobre vuestro catálogo de productos. Definid umbrales de completitud para los atributos críticos. Medid el cumplimiento actual. Es probable que la brecha sea mayor de lo esperado, y entenderla cuanto antes es esencial para una planificación realista.
Implementad OAuth 2.0 con permisos de comercio delimitados por scopes, si todavía no lo habéis hecho. Es el prerrequisito para cualquier modelo de delegación a agentes y resulta útil mucho más allá del caso de uso agéntico.
Rediseñad vuestro flujo de checkout como una API de primera clase, no como un flujo de interfaz que casualmente cuenta con una interfaz programática. Definid máquinas de estados claras, códigos de error y garantías de idempotencia.
Incorporad la simulación de agentes en vuestra suite de tests. Escribid tests de integración que reproduzcan cómo un agente recorrería vuestras APIs de descubrimiento de productos, carrito y checkout. Estos tests sacarán a la luz los fallos de integración antes de que los agentes reales los encuentren en producción.
La realidad competitiva
Las organizaciones que actúan sobre la preparación para el comercio agéntico en 2026 no son early adopters en el sentido tradicional. Los protocolos ya están activos. Los agentes ya están operando. Los consumidores ya están delegando sus compras. La ventana para ir por delante se está cerrando.
Lo que queda es la brecha de ejecución entre las organizaciones que han construido sistemas de comercio API-first, headless y con conciencia de la calidad de los datos, y las que no lo han hecho. Esa brecha se traducirá directamente en visibilidad ante los agentes, volumen de transacciones y, en última instancia, en ingresos de aquí a 2027 y 2028.
Las decisiones arquitectónicas que tomáis hoy son los resultados de ingresos que veréis dentro de dos años. No hay mejor momento para empezar.
Más de la Plataforma Laioutr
Lecturas relacionadas: Comercio agéntico: construir la arquitectura con la que los agentes de IA realmente pueden comprar y Orquestación agéntica en el e-commerce: por qué los agentes de IA necesitan una capa por encima de vuestra pila de proveedores.