El tráfico de IA hacia sitios de comercio minorista en EE. UU. creció un 693% interanual durante la temporada navideña de 2025 (Adobe Digital Insights, enero de 2026). Todos los grandes asistentes de IA ya tienen una ruta de compra. Y la mayoría de los merchants enterprise no están preparados para lo que eso implica legalmente.
La pregunta de infraestructura no es si habilitar el Agentic Commerce. La pregunta es quién asume la responsabilidad cuando una máquina se equivoca. Esa pregunta es la que los anuncios de la competencia esta semana han evitado conspicuamente. Este artículo no la evita. La IA en orquestación de pagos es donde vive la respuesta.
Puntos clave
- El merchant of record y el merchant of decision se están separando en el Agentic Commerce. Los merchants mantienen la responsabilidad del pago incluso cuando una plataforma de IA controla el proceso de compra.
- La mayoría de los anuncios de Agentic Commerce omiten la responsabilidad por chargebacks, la portabilidad de tokens y la autenticación de agentes. Estas son las tres brechas que generan riesgo enterprise.
- La IA en orquestación de pagos resuelve el problema de responsabilidad manteniendo las reglas de autorización definidas por el merchant en la capa de infraestructura, no en la del PSP.
- Un setup de un solo PSP no puede gestionar pagos iniciados por agentes. El enrutamiento multi-PSP, el token vaulting neutral y la lógica de fallback son requisitos previos, no complementos opcionales.
- El producto Agentic Commerce de Yuno conecta los catálogos de merchants con ChatGPT, Claude, Gemini, Perplexity y Copilot a través de una sola integración, con controles de autorización que el merchant define.
¿Cuál es el problema del merchant of record en el Agentic Commerce?
El merchant of record es la entidad legalmente responsable de una transacción de pago, incluyendo chargebacks, reembolsos y obligaciones de protección al consumidor. En el Agentic Commerce, este rol no se transfiere a la plataforma de IA, aunque haya controlado la decisión de compra.
Esta es la separación que los equipos de compras están planteando en cada evaluación enterprise que vemos. La plataforma de IA decide a qué merchant redirigir al consumidor. El checkout del merchant se activa. El merchant asume la responsabilidad. Esos dos hechos coexisten sin contradicción en todos los protocolos de Agentic Commerce anunciados hasta ahora.
Como lo planteó un análisis: el merchant of record no es el merchant of decision (Agentic Landmark, junio de 2026). Cada protocolo de Agentic Commerce fue diseñado para tranquilizar a los merchants manteniendo la marca como merchant of record. Esa tranquilidad es real e incompleta al mismo tiempo. La decisión migra a la capa de plataforma antes de que tu checkout se active.
¿Por qué los anuncios de la competencia evitan esta pregunta?
Los procesadores de un solo PSP y los proveedores de soluciones puntuales evitan la pregunta de responsabilidad del merchant of record porque su infraestructura no puede resolverla. Responderla honestamente les exigiría exponer brechas en portabilidad de tokens, enrutamiento multi-PSP y autenticación de agentes que sus productos no cubren.
Hemos visto este patrón directamente. Cuando los merchants enterprise inician evaluaciones de Agentic Commerce, las tres primeras preguntas de los equipos legal y de compras no son sobre tasas de conversión. Son sobre la titularidad de chargebacks, la delegación de autenticación y qué pasa cuando el agente compra algo que el consumidor disputa. Los proveedores que publican solo contenido sobre "cómo activar la IA como canal de ventas" no han respondido esas preguntas. Las han diferido.
- Titularidad de chargebacks: ¿quién es responsable cuando un consumidor disputa una compra iniciada por un agente?
- Delegación de autenticación: ¿cómo se verifica y documenta la autoridad del agente para actuar en nombre del consumidor?
- Resolución de disputas: ¿qué ocurre cuando el agente compra algo que el consumidor impugna como no autorizado?
Diferir estas preguntas tiene un coste elevado. Un merchant que habilita el Agentic Commerce sin resolver estas tres brechas está aceptando una responsabilidad que no puede cuantificar ni gestionar.
Las tres brechas de responsabilidad que la IA en orquestación de pagos debe cerrar
El Agentic Commerce crea tres brechas de responsabilidad específicas que la infraestructura de pagos estándar no fue diseñada para gestionar. Cerrar las tres requiere una capa de orquestación neutral, no un setup de un solo proveedor.
Brecha uno: titularidad de chargebacks cuando el agente se equivoca
La infraestructura de pagos estándar asume dos partes humanas: un comprador que inicia y un vendedor que cumple. El Agentic Commerce introduce una tercera parte. Un agente de IA investiga, compara y completa una compra de forma autónoma. Cuando un consumidor disputa esa compra como no autorizada, el chargeback recae en el merchant of record, no en la plataforma de IA que tomó la decisión.
El marco legal para esto no está resuelto. La legislación de protección al consumidor en EE. UU., Reino Unido y la UE fue redactada para el comercio entre personas. Las transacciones iniciadas por agentes encajan de forma incómoda en las definiciones de "transacción no autorizada" en torno a las que se construyeron las reglas de las redes de tarjetas y la Directiva de Servicios de Pago. Hasta que esos marcos se actualicen, los merchants absorben la ambigüedad en sus balances.
La respuesta de infraestructura es hacer la autorización explícita y auditable. Las reglas de autorización definidas por el merchant, almacenadas en la capa de orquestación, crean un registro de lo que el agente tenía permitido comprar en nombre del consumidor. Ese registro es la principal defensa del merchant en una disputa. Una regla a nivel de PSP no viaja con la transacción si el PSP cambia. Una regla a nivel de orquestación, sí.
Brecha dos: portabilidad de tokens en el stack del agente
Las transacciones iniciadas por agentes dependen de credenciales de pago almacenadas. El consumidor autoriza al agente una vez. El agente completa compras con el tiempo, usando un token en el vault. Si ese token vive dentro del vault de un solo PSP, el merchant tiene dos problemas.
Primero, el token no sobrevive a un cambio de PSP. Si el PSP tiene un rendimiento bajo y el merchant re-enruta, el agente pierde su credencial almacenada. La siguiente compra falla. Segundo, si la transacción del agente llega a una ruta fallida y el PSP de respaldo no puede leer el token, la transacción cae por completo. No hay ruta de reintento. El ingreso desaparece sin ningún intento de recuperación.
En nuestras integraciones con catálogos enterprise, la portabilidad de tokens es la brecha que aparece al final en las conversaciones con proveedores y la que más cuesta en producción. Un vault neutral, donde los tokens no están vinculados a ningún proveedor, significa que la credencial almacenada del agente puede ser leída por cualquier PSP en la ruta de enrutamiento. El merchant conserva la relación con el token. El PSP es intercambiable.
Brecha tres: delegación de autenticación para compradores no humanos
Los marcos de 3DS y de autenticación reforzada de clientes fueron diseñados para compradores humanos en un navegador o aplicación. Asumen que el titular de la tarjeta está presente y puede completar un desafío. Los agentes de IA no están presentes en ese sentido. No pueden completar un CAPTCHA ni un proceso biométrico. Actúan con delegación preautorizada del consumidor.
Esto crea una brecha de autenticación real. El merchant necesita señalar al emisor que se trata de una transacción delegada y preautorizada, no de una transacción sin tarjeta presente que justifique un desafío 3DS completo. Sin esa señal, los emisores aplican reglas de fricción estándar a las transacciones de agentes. Las tasas de aprobación caen. Los consumidores culpan al merchant, no al agente.
La IA en orquestación de pagos resuelve esto permitiendo a los merchants establecer parámetros de autenticación a nivel de infraestructura. La regla viaja con la transacción independientemente del PSP que la procese. El emisor recibe la señal correcta. La transacción del agente se aprueba sin fricción innecesaria.
¿Cómo resuelve la infraestructura de Yuno estas brechas?
El enfoque de Yuno mantiene las reglas de autorización definidas por el merchant en la capa de orquestación, no dentro del sistema de ningún proveedor. Esa arquitectura es lo que hace que las reglas sean portables, auditables y aplicables en todo el stack de Agentic Commerce.
El producto Agentic Commerce de Yuno conecta los catálogos de merchants con ChatGPT, Claude, Gemini, Perplexity y Copilot a través de una sola integración. El merchant define qué puede comprar el agente, bajo qué condiciones y dentro de qué parámetros. Esas reglas no se almacenan en un PSP. Viven en la capa de orquestación. Cuando un PSP cambia, las reglas no cambian con él.
El token vault funciona de la misma manera. Los network tokens se almacenan de forma neutral, no dentro del sistema de ningún proveedor. Pueden ser leídos por cualquier PSP en la ruta de enrutamiento. Si el Smart Routing redirige la transacción del agente a un proveedor de respaldo, el token lo acompaña. El incremento promedio del 8% en la tasa de autorización del merchant (datos de la plataforma Yuno, 2026) no desaparece porque un agente haya iniciado la compra en lugar de un humano.
Como Yuno no posee ningún rail ni vende adquirencia, las decisiones de enrutamiento para transacciones iniciadas por agentes no tienen conflicto de interés. El sistema enruta hacia el proveedor con más probabilidades de aprobar la transacción, no hacia el que genera más margen para el proveedor de infraestructura. Esa neutralidad importa más en el Agentic Commerce que en el e-commerce estándar, porque el agente no puede reintentar manualmente. La primera decisión de enrutamiento tiene que ser la correcta.
¿Qué necesitan ver realmente los equipos de compras enterprise?
Los equipos de compras enterprise que evalúan infraestructura de Agentic Commerce hacen cuatro preguntas que la mayoría de los briefings de proveedores no responden. Obtener estas respuestas antes de firmar un contrato es la diferencia entre un despliegue controlado y una exposición a responsabilidades.
- ¿Quién asume la responsabilidad por chargebacks en disputas iniciadas por agentes y qué documentación respalda la defensa del merchant?
- ¿Dónde se almacenan los tokens de pago y sobreviven a un cambio de PSP o a un cambio de ruta?
- ¿Cómo señala la infraestructura la autorización delegada a los emisores y qué marco de autenticación rige esa señal?
- ¿Puede el merchant establecer y actualizar parámetros de autorización sin una nueva integración o un nuevo contrato con el proveedor?
Estas no son preguntas de casos extremos. Son la base para cualquier empresa enterprise con un equipo legal que haya revisado lo que el Agentic Commerce realmente hace a la relación comprador-vendedor. En nuestro trabajo con marketplaces enterprise y operadores de e-commerce a gran escala, los equipos de compras bloquean más despliegues de Agentic Commerce por estos cuatro puntos que por cualquier pregunta de integración técnica.
- Documentación de responsabilidad por chargebacks: ¿qué registro crea la infraestructura para respaldar la defensa del merchant en una disputa?
- Portabilidad de tokens: dónde se almacenan y si sobreviven a un cambio de PSP o de ruta.
- Marco de autenticación: cómo se señala la autorización delegada a los emisores y qué estándar rige esa señal.
- Control de parámetros de autorización: si el merchant puede establecer y actualizar reglas sin una nueva integración o contrato.
El 53% de los consumidores ya ha realizado una compra basándose en una recomendación de IA generativa (Capgemini Research Institute, 2025). El comportamiento del consumidor está por delante de la conversación sobre infraestructura en la mayoría de las empresas. Los merchants que resuelven estas brechas ahora activan el canal antes que la competencia. Los que las difieren activan el canal y absorben la responsabilidad en silencio hasta que una disputa fuerza la pregunta.
¿Qué deben hacer los CPOs y CTOs antes de habilitar el Agentic Commerce?
Deben realizarse tres auditorías de infraestructura antes de poner en marcha cualquier integración de Agentic Commerce. Cada una corresponde a una brecha de responsabilidad descrita anteriormente.
- Audita tu token vault. Si los tokens se almacenan dentro de un solo PSP, mapea la exposición. Identifica qué flujos de transacciones de agentes fallarían si esa ruta de PSP cambiara. Calcula el ingreso en riesgo por cada transacción de agente fallida antes de tener un incidente en producción.
- Audita tus reglas de autenticación. Verifica que tu configuración de 3DS pueda distinguir las transacciones de agentes delegadas de las transacciones estándar sin tarjeta presente. Si la configuración está a nivel del PSP, confirma qué ocurre con esa regla cuando el PSP cambia.
- Audita tu documentación de defensa ante chargebacks. Identifica qué registro crea tu infraestructura cuando un agente completa una compra. Si los parámetros de autorización no están almacenados y son consultables, tu equipo legal no tiene documentación que presentar en una disputa.
Si alguna de estas auditorías revela una brecha, la solución es a nivel de infraestructura, no a nivel de PSP. Añadir una regla dentro del dashboard de un solo proveedor resuelve el problema solo hasta que cambia el enrutamiento. Gartner proyecta que el 20% de las transacciones de comercio digital se ejecutarán a través de plataformas de IA para 2030 (Gartner). Los merchants que construyan la infraestructura correctamente ahora no tendrán que reconstruirla cuando se llegue al 20%.
Para profundizar en cómo funciona el ecosistema de protocolos y qué significa realmente una integración única en la práctica, la mecánica de compra de los agentes de IA se explica en detalle por separado. Y para comparar qué enfoques de orquestación realmente soportan el stack completo de protocolos, la comparación de orquestadores recoge los criterios que los equipos de compras están usando ahora mismo.
El auge más rápido en una sola semana de contenido de la competencia sobre Agentic Commerce ocurrió esta semana. Ninguno respondió la pregunta del merchant of record. Esa brecha no es accidental. Es la brecha que la infraestructura neutral resuelve y que la infraestructura con conflictos de interés no puede resolver.
