IA11 min

El agente ya está en la puerta de la caja: qué pasa en sus sistemas cuando quien compra es una máquina

Por Dorian Chávez · fundador de Hábil y arquitecto de integración ·

Los agentes de IA ya preparan compras hasta el cobro. Identidad, autorización, disputas, CFDI y fraude: qué debe resolver su empresa antes de que lleguen.

Un cliente le dice a su asistente de IA: «Cómprame los tenis negros, talla 27, y que lleguen el viernes». El asistente abre la tienda en línea, elige el producto, llena la dirección de envío y llega a la pantalla de pago. Ahí se detiene y le pregunta al cliente: «¿Confirmo?». El cliente toca un botón. La orden entra a su sistema.

Mire esa escena desde el lado de su empresa. Hasta antes del botón, quien visitó su tienda no fue una persona. Y después del botón, su operación tiene que cobrar, facturar, enviar, conciliar y, si algo sale mal, responder por una compra que ninguno de sus sistemas vio nacer como acostumbra.

Esto ya no es una hipótesis de laboratorio. Este artículo es para quien responde por ventas, finanzas, operación o tecnología en un banco, una fintech, una aseguradora, una cadena de retail o una empresa regulada. Le propone dejar a un lado la pregunta de moda —¿van a comprar solos los agentes?— y hacerse una más útil: ¿qué pasa en mis sistemas cuando lo que llega a la caja es una máquina? Según su papel, la pregunta cambia: al comercio le tocan el catálogo, el pedido, el CFDI y las devoluciones; al emisor, los límites, el consentimiento y la revocación; al adquirente o procesador de pagos, la aceptación, las señales y la disputa; a la empresa regulada, la autorización, la trazabilidad y los datos.

Lo que sí pasó, y lo que no

A finales de septiembre de 2026, Shopify documentó (28 de septiembre) que los agentes de IA que operan en un navegador pueden ahora usar cuatro herramientas sobre su pantalla de pago: ir a la tienda, leer el estado del pedido, actualizar datos de envío y entrega, y enviar la orden. Esas herramientas corren dentro del mismo checkout web que usa una persona y con el mismo estado que ve la interfaz [1].

El matiz importa: la herramienta que envía la orden lo hace después de la confirmación del comprador [1]. Según la documentación, además, el control vuelve a la persona cuando se requiere la verificación adicional de 3D Secure, el paso con el que el banco emisor comprueba que el titular de la tarjeta sí es quien paga [1].

En otras palabras: en el flujo que Shopify documentó, el agente prepara y la persona confirma; otros esquemas, como AP2, ya contemplan compras autónomas bajo autorización previa del cliente [7]. Hablar de «comprar solos» en este caso sería una exageración. Lo cierto es más incómodo y más cercano: en el flujo documentado por Shopify, el agente ya llega hasta la puerta del cobro, y sin que la tienda le abra una puerta especial: según Shopify, esas herramientas no exponen una interfaz nueva ni requieren configuración del comercio [1].

Dos datos más se han reportado, y conviene tratarlos como lo que son. Según declaraciones de un vocero recogidas por GeekWire, Amazon bloquea a Muse, el agente de compras de Meta, entre otras razones porque no se identifica cuando navega por la tienda [2]. Infobae reportó que Adidas habría hecho algo parecido, sin confirmación de la empresa [2]. Ninguno de los dos casos demuestra una tendencia de mercado.

Un dato de contexto, para no inflar la expectativa. En una encuesta de Visa y Harris Poll de mayo de 2026 en Estados Unidos (2,065 consumidores; la pregunta sobre pagos se hizo a una submuestra de unos 1,030), 23 % dijo confiar en la IA generativa para hacer pagos en su nombre [3]. Es una encuesta de un proveedor de pagos, en otro país y no mide volumen de compras. En nuestra revisión al 17 de octubre de 2026 de los sitios y comunicados de los protocolos y las redes que citamos aquí, no encontramos cifras públicas del volumen de transacciones reales hechas por agentes. Lo que sí existe es la infraestructura, y eso es lo que a usted le toca revisar.

Cinco cosas que su empresa tiene que resolver

Todas se desprenden de una sola idea: muchos flujos de comercio electrónico todavía presuponen una sesión humana, con tarjeta propia y dirección de correo. Un agente puede romper cada uno de esos supuestos por separado.

1. Identidad: ¿abre la puerta o la bloquea?

Muchos filtros contra tráfico automatizado no distinguen entre el raspado de precios y un cliente asistido por un agente: tratan a ambos como un bot. Eso protege su sitio de raspado de precios y de ataques, pero también puede estar rechazando, sin que usted lo sepa, a clientes reales que compran a través de un asistente.

Visa y Mastercard ya documentan mecanismos para identificar agentes. El protocolo de agente confiable de Visa permite que un comercio distinga a un agente legítimo de un bot mediante firmas criptográficas ligadas al comercio y al propósito de la visita, de vigencia corta y no reutilizables [4]. Se apoya en un estándar abierto de firma de mensajes HTTP, el RFC 9421 [5]. Mastercard, por su parte, anunció que su marco de aceptación de Agent Pay requiere registrar y verificar al agente antes de cualquier transacción [6].

Lo que ninguna de esas piezas decide por usted es la política: qué agentes entran, con qué límites de consulta y de monto, y quién mantiene la lista. Y las dos opciones tienen costo. Bloquear a todos puede perder ventas que ya estaban hechas. Abrir sin criterio expone su catálogo, sus precios y su inventario a consultas masivas. Identifique quién es dueño de esa decisión en su organización.

2. Autorización: ¿quién dijo que sí a este pago?

Cuando compra una persona, la autorización está en la pantalla: teclea, confirma, el banco la valida. Con un agente, eso depende del esquema. Hay flujos en los que el comprador sigue confirmando en el checkout, como el de Shopify y el del protocolo de OpenAI y Stripe [1][9]. Pero en los esquemas delegados o preautorizados, el permiso se dio antes, en otro lugar, y su empresa necesita evidencia de que se dio.

Los protocolos atacan este problema con ideas parecidas. AP2, de Google, usa «mandatos» firmados: un permiso del cliente con reglas —tope de precio, vigencia— y un carrito aprobado, que buscan dejar un rastro verificable de lo autorizado [7]. Visa combina un token de pago hecho para agentes con verificación reforzada del titular mediante llave de acceso [8]. El protocolo de OpenAI y Stripe usa un token de pago acotado que no expone la tarjeta del cliente y deja al comercio como responsable de la venta [9].

Para una empresa, aparece un tercer tipo de credencial que no es ni la tarjeta del cliente ni su billetera: un token con monto, comercio y vigencia limitados, en manos de un programa. En los flujos que usan credenciales acotadas, confirme con su procesador de pagos o adquirente cómo se reciben, validan y reportan; el mecanismo depende del protocolo y de la ruta de pago. Para un banco emisor, la pregunta es otra: cómo le presenta al cliente lo que su agente puede gastar, y cómo se lo revoca.

3. Disputas: ¿quién responde cuando el agente se equivoca?

Piense en un contracargo con un motivo nuevo: «yo no pedí esto; mi agente se equivocó». ¿Fue error del cliente, del comercio, de la plataforma del agente o del emisor? Los protocolos buscan conservar la evidencia de la instrucción original: AP2 con sus mandatos [7] y Visa con lo que llama «señales comerciales» para resolver disputas [8].

Pero evidencia no es criterio. En nuestra revisión al 17 de octubre de 2026 de las publicaciones de la CNBV, Banxico y la CONDUSEF, no encontramos una regla mexicana que asigne expresamente la responsabilidad por un error de un agente; no es una revisión jurídica exhaustiva. Revise contratos de red y de adquirencia y las obligaciones aplicables antes de fijar una política. Mientras tanto, la protección de su empresa depende de lo que usted pueda demostrar: qué instrucción recibió, de qué agente, con qué permiso y qué mostró su tienda en ese momento. Conviene decidir hoy qué evidencia se guarda y por cuánto tiempo, según la política de retención aplicable, porque reconstruirla después de la primera disputa puede no ser posible.

4. Datos fiscales: ¿a quién se le factura?

Aquí está el problema más local y el más fácil de pasar por alto. En México, el CFDI 4.0 exige datos del receptor: su RFC, su nombre o razón social, su régimen fiscal y el código postal de su domicilio fiscal [10]. Una persona los captura en un formulario, o su cuenta ya los tiene. Un agente puede no llevarlos.

Sin los datos del receptor, no podrá emitirse un CFDI nominativo durante el checkout. Entonces su equipo tiene tres caminos, y los tres cuestan: pedirle los datos al cliente después, con la fricción y el desfase que eso trae; aplicar una política de factura posterior; o incluir la operación en la factura global, que procede para operaciones con el público en general y bajo las condiciones de la regla 2.7.1.21 de la Resolución Miscelánea Fiscal [14], y que no sustituye al CFDI nominativo cuando el cliente lo pide. Ninguna de las fuentes que consultamos resuelve quién es el receptor fiscal de una compra hecha a través de un agente. Es una pregunta abierta y conviene contestarla antes de que se multipliquen los casos.

5. Fraude: ¿cómo distingue una compra legítima de una robada?

Los modelos de riesgo que protegen a un comercio se alimentan, en buena parte, de señales de una persona: el dispositivo, el patrón de navegación, la hora, el ritmo al teclear. Cuando interviene un agente, esas señales pueden faltar: el tráfico llega de un programa, y los modelos calibrados para tráfico humano pueden requerir revalidación.

Eso obliga a revisar reglas, a decidir cuándo se pide una confirmación humana adicional y a incorporar las señales nuevas que ofrecen las redes. Y obliga a algo más básico: saber que el pedido vino de un agente. Si ese dato no queda guardado en el pedido junto con quién autorizó, la conciliación y la defensa ante un contracargo se vuelven trabajo manual. Lo mismo vale para las devoluciones: defina con su adquirente la ruta por la que regresan.

Los protocolos, por capa

Los nombres se multiplican —ACP, UCP, AP2, Visa, Mastercard— y es fácil creer que hay que escoger uno. No compiten por lo mismo: cada uno resuelve una capa distinta. Y están en etapas diferentes de madurez, que conviene no confundir.

Los protocolos, por capa
CapaPregunta que resuelvePiezasLo que se verificó
Comercio¿Qué se compra y cómo se pide?UCP (con Google y Shopify entre sus participantes) y ACP (OpenAI y Stripe)UCP: especificación en expansión: compras con especificación publicada; hospedaje en borrador; comida anunciada, aún sin especificación [11]. ACP: estándar abierto que sus mantenedores aún no declaran terminado; versión estable más reciente del 17 de abril de 2026 [9]
Autorización¿Quién dio permiso para esta compra?AP2 (Google)Versión 0.2; Google lo transfirió a la FIDO Alliance el 28 de abril de 2026 [7]
Credencial y red¿Con qué instrumento se paga?Visa Intelligent Commerce y Mastercard Agent PayVisa (según el proveedor): su documentación pide la aprobación de Visa en cada etapa de la integración, desde el entorno de pruebas; en marzo de 2026 completó con Santander pruebas controladas en México y otros cuatro países de la región [8][12]. Mastercard (según el proveedor): anunció Agent Pay para América Latina y el Caribe desde 2026; en junio de 2026 reportó, con Getnet y Neivor, la primera operación doméstica iniciada por un agente en México. Confirme con su adquirente la disponibilidad para su comercio [6][13]
Identidad del agente¿Es un agente legítimo?Protocolo de agente confiable de Visa (RFC 9421)Implementación de referencia publicada por Visa; confirme con su adquirente si se usa en México [4][5]

Una empresa podría terminar hablando varios de estos protocolos a la vez. De ahí que la pregunta útil no sea «¿cuál adoptamos?», sino «¿qué tienen que tener resuelto mis sistemas para hablar cualquiera de ellos?».

Lo que tienen en común es lo que le toca a usted: un catálogo, precios e inventario que una máquina pueda consultar por interfaz y sin una persona de por medio; un pedido que registre su origen; y un expediente de quién autorizó qué.

Escenario: una tienda en línea con 10,000 pedidos al mes

Escenario ilustrativo, con cifras inventadas para mostrar el efecto. No describe a ninguna empresa.

Una tienda en línea recibe 10,000 pedidos al mes. Suponga que 3 % empieza a llegar por agentes: 300 pedidos. Hasta aquí, una cifra pequeña. Ahora suponga que una quinta parte de esos clientes pide factura y que el agente no llevó el régimen fiscal ni el uso del comprobante: son 60 facturas que no se pueden timbrar en el momento.

Si a cada una le dedica 15 minutos un analista, son 15 horas al mes de trabajo manual que antes no existían. Si el porcentaje de agentes sube al 10 %, esas horas pasan a 50. Y no hemos contado un solo contracargo, una sola devolución por un pedido mal entendido por el agente, ni una sola conciliación que no encuentra de qué agente vino el cobro.

La lección del ejemplo no es la cifra: el escenario permite estimar horas, retrasos de cierre y evidencia faltante.

Qué conviene hacer esta semana

No necesita un proyecto para empezar. Necesita contestar cinco preguntas con las personas correctas en la misma mesa:

  1. Tráfico. ¿Cuánto de lo que su sitio rechaza como bot podría ser un agente de un cliente? Si hoy no lo mide, esa es la primera respuesta.
  2. Política de puertas. ¿Quién decide qué agentes entran, con qué límites, y cuál es el costo de cada decisión?
  3. Evidencia. Cuando un pedido venga de un agente, ¿qué queda guardado: quién autorizó, qué se mostró, qué se cobró?
  4. Facturación. ¿Qué hace su área fiscal con un pedido sin datos del receptor, y quién le avisa al cliente?
  5. Responsabilidad. Si el agente se equivoca, ¿quién absorbe el costo, el cliente, usted, el emisor o la plataforma, y dónde está escrito?

Para que las respuestas dejen de ser opinión, conviene medir tres cosas que su equipo puede levantar hoy, sin cifras de nadie más:

  • Tráfico rechazado como bot. ¿Qué porcentaje de las visitas que su sitio bloquea o reta corresponde a patrones que podrían ser un agente de un cliente? ¿Quién lo revisa y con qué frecuencia?
  • Costo de reconstruir una factura. ¿Cuánto tiempo y cuántas personas toma hoy rehacer una factura cuando el pedido llegó sin datos fiscales completos? Multiplíquelo por el número de pedidos que podrían llegar así.
  • Costo de un contracargo. ¿Cuánto le cuesta hoy atender un contracargo de punta a punta —tiempo, comisión, mercancía y evidencia— y cuánto más costaría si el motivo fuera «mi agente se equivocó»?

Si dos o más de las respuestas son «no lo sé» o «depende de quién conteste», no es un fallo de su equipo: son preguntas que hasta hace unos meses nadie tenía por qué hacerse. Lo que cambió es que el ritmo ya no lo marca solo su agenda interna: lo está marcando el ecosistema.

Hay además una parte técnica que ya tiene guía. Que un agente pueda consultar su catálogo, reintentar sin duplicar un pedido y recibir errores que entienda no es un tema del checkout solamente: es una propiedad de sus interfaces. La desarrollamos en el artículo APIs listas para agentes de IA.

Qué hace Hábil

Los problemas de arriba tienen algo en común: ocurren en la unión entre sistemas. El pedido nace en un canal, el cobro en otro, la factura en un tercero y la conciliación en un cuarto, y a ninguno le corresponde saber que quien compró fue un agente. Hábil se dedica a esa unión: integrar sistemas existentes con el objetivo de que las operaciones dejen rastro de quién las autorizó y de que un canal nuevo no obligue a reescribir los anteriores.

Si su empresa está pensando cómo recibir —o cómo acotar— a los agentes de IA, la página Hábil AI explica qué hacemos con ellos, y el artículo APIs listas para agentes de IA detalla qué necesita su sistema para que un agente lo use con control.

El siguiente paso es sencillo: escríbanos por WhatsApp. En una primera conversación, sin costo, le decimos dónde probablemente se pierde dinero, tiempo o evidencia en las interfaces de su operación y si vale la pena un diagnóstico a fondo, con alcance acordado.

Referencias

  1. Shopify, WebMCP support for checkout, registro de cambios para desarrolladores (finales de septiembre de 2026). https://shopify.dev/changelog/posts/webmcp-support-for-checkout
  2. GeekWire, «Amazon blocks Meta's Muse AI assistant in new standoff over agentic shopping», 20-sep-2026 (nota de prensa con la declaración de un vocero de Amazon). https://www.geekwire.com/2026/amazon-blocks-metas-muse-ai-assistant-in-new-standoff-over-agentic-shopping/ · Infobae, «Shopify abre sus tiendas a agentes de IA de compra mientras Amazon y Adidas los bloquean», 29-sep-2026 (nota de prensa; reporta lo de Adidas sin confirmación de la empresa). https://www.infobae.com/tecno/2026/09/29/shopify-abre-sus-tiendas-a-agentes-de-ia-de-compra-mientras-amazon-y-adidas-los-bloquean/ · Apoyo: PPC Land, nota del 8-oct-2026 que retoma la de GeekWire. https://ppc.land/amazon-blocks-metas-muse-ai-agent-from-shopping-on-its-site/
  3. Visa y Harris Poll, encuesta a 2,065 consumidores de Estados Unidos (26–28 de mayo de 2026), comunicado de Visa del 9-sep-2026 (encuesta de un proveedor de pagos). https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.22736.html
  4. Visa, Trusted Agent Protocol (documentación para desarrolladores y repositorio). https://developer.visa.com/capabilities/trusted-agent-protocol/overview · https://github.com/visa/trusted-agent-protocol
  5. IETF, RFC 9421, HTTP Message Signatures. https://www.rfc-editor.org/rfc/rfc9421
  6. Mastercard, «Mastercard unveils Agent Pay in Latin America and the Caribbean», comunicado del 3-dic-2025 (el marco de aceptación de Agent Pay requiere registrar y verificar al agente), y Agent Pay (documentación para desarrolladores). https://newsroom.mastercard.com/news/latin-america/en/newsroom/press-releases/pr-en/2025/december/mastercard-unveils-agent-pay-in-latin-america-and-the-caribbean/ · https://developer.mastercard.com/product/agent-pay/
  7. Google, Agent Payments Protocol (AP2): anuncio del 16-sep-2025 y especificación; FIDO Alliance, anuncio de la donación de AP2 a la FIDO Alliance y de la versión 0.2 (28-abr-2026). https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol · https://ap2-protocol.org/ · https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/
  8. Visa, Visa Intelligent Commerce (documentación para desarrolladores). https://developer.visa.com/capabilities/visa-intelligent-commerce
  9. Agentic Commerce Protocol (OpenAI y Stripe), especificación y repositorio; Stripe, Developing an open standard for agentic commerce. https://www.agenticcommerce.dev · https://github.com/agentic-commerce-protocol/agentic-commerce-protocol · https://stripe.com/blog/developing-an-open-standard-for-agentic-commerce
  10. SAT, información sobre el CFDI versión 4.0 (datos mínimos del receptor: RFC, nombre o razón social, régimen fiscal y código postal del domicilio fiscal). https://wwwmat.sat.gob.mx/cs/Satellite?c=ConsultaInfo&childpagename=SatTyR/ConsultaInfo/SAT_LandingConsultaInformacion&cid=1462241943074&packedargs=d%3DTouch&pagename=TySWrapper
  11. Universal Commerce Protocol, sitio y repositorio oficial (licencia Apache 2.0). https://ucp.dev · https://github.com/Universal-Commerce-Protocol/ucp
  12. Santander, comunicado de prensa de marzo de 2026 sobre las primeras pruebas de pagos de punta a punta con agentes de IA en América Latina, junto con Visa. https://www.santander.com/en/press-room/press-releases/2026/03/santander-and-visa-deliver-latin-americas-first-end-to-end-payments-powered-by-ai-agents
  13. Mastercard, «Paso sin precedentes: Getnet, Mastercard y Neivor realizan en México la primera operación de comercio agéntico», comunicado de junio de 2026. https://newsroom.mastercard.com/news/latin-america/es/sala-de-prensa/comunicados-de-prensa/pr-es/2026/junio/getnet-mastercard-y-neivor-realizan-en-mexico-la-primera-operacion-de-comercio-agentico/
  14. SAT, regla 2.7.1.21 de la Resolución Miscelánea Fiscal, «Expedición de comprobantes en operaciones con el público en general» (CFDI global; la misma numeración en la RMF para 2026, DOF del 28-dic-2025). https://wwwmat.sat.gob.mx/articulo/90959/regla-2.7.1.24