¿Por qué los sitios bloquean a los agentes de compra con IA?

Cuando un usuario le dice a un asistente de IA «búscame unas botas de montaña impermeables de la talla 42 que encajen en mi presupuesto y añádelas al carrito», el asistente intenta hacerlo como lo haría una persona: busca, abre tiendas, compara páginas de producto, elige la talla y avanza hacia el pago. Y muy a menudo se detiene en algún punto. En lugar de la página del producto aparece una pantalla de verificación, se rechaza la petición de añadir al carrito o la página de pago marca una transacción sospechosa. A ojos del usuario, el asistente ha fallado; a ojos de la tienda, se ha detenido a un bot.

En este artículo explicamos qué es un agente de compra con IA, por qué los sitios bloquean a estos agentes y el núcleo del problema: por qué a un sitio le cuesta distinguir entre una persona, un bot malicioso y un agente que actúa con la autorización del usuario. Después vemos las soluciones que están surgiendo (agentes firmados, Web Bot Auth y nuevos protocolos en el lado del pago) y la vía correcta para comerciantes y desarrolladores de agentes. Este artículo no explica cómo hacer que los agentes esquiven la protección de bots; se centra en que el tráfico de agentes se identifique correctamente.

¿Qué es un agente de compra con IA?#

Un agente de compra con IA es un sistema de IA que toma el objetivo de compra de un usuario y lo lleva a cabo actuando él mismo en sitios web. El mecanismo general es el bucle percibir-planificar-actuar-evaluar que describimos en Agentes de IA: planificación, herramientas y memoria; en un agente de compra, las herramientas del bucle son los sitios de las tiendas y los sistemas de pago.

Lo que hace un agente de compra se divide en tres niveles:

1. Investigación: buscar productos, comparar precios y características, leer reseñas.
2. Preparación: elegir talla, color y cantidad, añadir al carrito, valorar las opciones de envío.
3. Transacción: completar el pedido usando los datos de pago.

Cada nivel supone un riesgo distinto para el sitio. La investigación se parece a lo que hace un scraper. Añadir al carrito afecta a los sistemas de stock y de sesión del sitio. El pago implica dinero y riesgo de fraude. Los sitios reaccionan de forma distinta a los agentes en cada nivel.

¿Por qué los sitios bloquean a los agentes?#

Cuando una tienda online detiene el tráfico de agentes, no suele ser por una postura especial contra los agentes, sino porque unas defensas que existen desde hace años también los atrapan.

Protección de bots. Las tiendas online usan sistemas de gestión de bots contra la extracción de precios, el acaparamiento de inventario (añadir productos limitados a carritos para que otros no puedan comprarlos), el robo de cuentas y los ataques de prueba de tarjetas. Estos sistemas puntúan las peticiones con señales como la velocidad, la reputación de la IP, la huella del navegador y el comportamiento. Un agente de compra suele funcionar desde un centro de datos, con un navegador headless, y abre páginas mucho más rápido que una persona; es decir, reúne casi todas las señales que buscan los sistemas de protección de bots. Para un ejemplo de cómo se evalúan estas señales, consulta Cloudflare Precursor.

Riesgo de fraude en el pago. Los sistemas de pago verifican con distintas señales que una tarjeta la usa su titular: dispositivo, ubicación, hábitos y pasos de verificación adicionales como 3-D Secure. Cuando un agente intenta pagar con datos de tarjeta, la mayoría de estas señales no coinciden con el perfil normal del titular. Desde el punto de vista del sistema de pago, la imagen se parece a una compra automatizada con una tarjeta robada.

Condiciones de uso. Las condiciones de uso de muchas tiendas online restringen el acceso automatizado, los pedidos automáticos o la recogida de contenido del sitio con herramientas automatizadas. Según las propias reglas del sitio, un agente es una herramienta de automatización no autorizada aunque actúe en nombre del usuario.

Relación con el cliente y datos. Para el comerciante, el agente es un intermediario que se interpone entre el cliente y él. Buena parte de la experiencia de venta, como la página del producto, las recomendaciones, las campañas y los programas de fidelidad, se salta cuando el agente muestra al usuario solo un resumen. Algunos comerciantes son prudentes con el tráfico de agentes por este motivo.

Responsabilidad poco clara. Cuando el agente añade al carrito la talla equivocada, compra un producto que el usuario no aprobó o lee mal el precio, ¿quién se ocupa de la devolución y de la disputa? Mientras estas preguntas no tengan respuestas claras, comerciantes y empresas de pago pueden preferir bloquear para reducir el riesgo.

¿Por qué cuesta distinguir personas, bots y agentes autorizados?#

Históricamente, la protección de bots de un sitio trabaja con dos categorías: persona y bot. Un agente de compra es una tercera categoría que no encaja en esa división.

El problema es que en las cuatro primeras filas de la tabla el agente se parece a un bot malicioso, y en las dos últimas a una persona. Como los sistemas de protección de bots solo pueden mirar el comportamiento y las señales de red, la información que necesitarían para distinguir al agente de un bot, es decir, «quién está detrás de esta automatización y qué autoridad tiene», no está en la petición HTTP.

Esta carencia no se puede cubrir con la cabecera User-Agent, porque esa cabecera es texto plano y cualquiera puede escribir cualquier valor. Para que un sitio crea que una petición que dice «KnownShoppingAgent/1.0» viene realmente del agente de esa empresa, necesita una prueba verificable. Las listas de direcciones IP ayudan hasta cierto punto, pero en la infraestructura en la nube las direcciones se comparten y cambian.

Por eso que el agente se oculte o intente parecer humano no resuelve el problema; lo empeora. Un agente que falsifica la huella de su navegador y cambia de IP con pools de proxies se convierte exactamente en el tipo de tráfico que los sistemas de protección de bots están diseñados para bloquear. La solución va en la dirección contraria: que el agente se identifique de forma verificable.

Agentes firmados y Web Bot Auth#

El enfoque principal que está surgiendo en esa dirección es que el agente firme criptográficamente cada petición HTTP. Por debajo está el estándar HTTP Message Signatures (RFC 9421) del IETF. El estándar define cómo firmar con una clave privada componentes seleccionados de un mensaje HTTP (método, dirección, ciertas cabeceras) y cómo el receptor verifica la firma con la clave pública.

Web Bot Auth es el nombre del enfoque que usa este estándar para autenticar bots y agentes. Según la documentación de Web Bot Auth de Cloudflare, funciona así:

1. El operador del agente crea un par de claves y publica la clave pública como directorio de claves en su propio dominio, en /.well-known/http-message-signatures-directory.
2. El agente añade tres cabeceras a cada petición: Signature-Input (los componentes que cubre la firma, el ID de la clave, las horas de creación y caducidad y un nonce), Signature (la propia firma) y Signature-Agent (la dirección del directorio de claves).
3. El sitio, o la CDN que tiene delante, verifica la firma: lee el directorio de claves, comprueba la firma con la clave pública y se asegura de que no ha caducado.
4. La petición verificada se atribuye a un agente conocido. A partir de ahí, el sitio puede permitir la petición, limitar su velocidad o restringir su acceso a ciertas rutas.

Una característica importante de este enfoque es que la verificación no depende de la dirección IP: desde el servidor que funcione el agente, la firma apunta al mismo operador. El propio directorio de claves también va firmado, lo que dificulta que otro suplante al operador con un directorio falso.

Desde el 1 de julio de 2026, Cloudflare trata a los agentes que se identifican criptográficamente de esta forma dentro de su clasificación de bots verificados. En la práctica, esto significa que los propietarios de sitios pueden abrir una vía aparte para los agentes verificados en sus reglas de protección de bots.

Nuevos protocolos en el lado del pago#

Que un agente pueda llegar a un sitio es la mitad del problema. La otra mitad es verificar su autoridad para pagar. Desde 2025 han aparecido varios protocolos en este ámbito. Más que competidores, son protocolos centrados en distintos pasos del proceso:

• Visa Trusted Agent Protocol: según el anuncio de Visa, el protocolo que Visa presentó en octubre de 2025 se basa en el estándar HTTP Message Signatures, está alineado con Web Bot Auth y se desarrolló junto con Cloudflare. Su objetivo es que los comerciantes puedan distinguir a los agentes reconocidos por Visa y con intención de compra de la automatización maliciosa.
• Agentic Commerce Protocol (ACP): una especificación abierta mantenida por OpenAI y Stripe. Según la página del proyecto, estandariza el flujo de compra entre comprador, agente, comerciante y proveedor de pagos; el agente muestra al usuario la interfaz de pago, mientras el comerciante mantiene su propia infraestructura y el procesamiento de pagos.
• Agent Payments Protocol (AP2): el protocolo que Google anunció con sus socios pretende transmitir la autoridad de un agente para pagar en nombre del usuario con documentos de autorización firmados criptográficamente. Así, el comerciante y la empresa de pagos pueden verificar que la transacción está dentro de los límites que aprobó el usuario.

Algunos de estos protocolos siguen en beta y su alcance cambia rápido. Si planeas una integración, consulta la documentación vigente del protocolo correspondiente.

¿Quién resuelve qué?#

¿Qué pueden hacer los comerciantes?#

Bloquear por completo el tráfico de agentes o dejarlo totalmente abierto puede no ser lo correcto para un comerciante. Un enfoque por pasos es más sano:

1. Mide el tráfico. Mira qué parte del tráfico automatizado que llega a tu sitio son buscadores, crawlers de IA conocidos y automatización de identidad desconocida.
2. Escribe tu política. Decide qué agentes pueden llegar a qué páginas (catálogo, carrito, pago). Mantener abiertas las páginas del catálogo y vincular el pago a protocolos verificados es un punto de partida habitual.
3. Actualiza robots.txt y tus condiciones. Indica tus preferencias sobre agentes tanto en formato legible por máquina como con claridad en tus condiciones de uso. Explicamos cómo se escribe el archivo en Qué es robots.txt y cómo leerlo.
4. Reconoce a los agentes firmados. Usa los ajustes que ofrece tu servicio de gestión de bots para agentes verificados; evalúa el tráfico de agentes con identidad verificada por separado del de identidad desconocida.
5. Ofrece datos estructurados. Los datos schema.org de las páginas de producto y, si los tienes, los feeds oficiales de productos permiten a los agentes llegar a información correcta sin tener que extraer la página.
6. Sigue los protocolos de agentes de tus socios de pago. Si tu proveedor de pagos admite estos protocolos, es posible gestionar las transacciones originadas por agentes en un flujo separado de las reglas de fraude.

Para trabajos como vigilar el tráfico de agentes y bots en tu propio sitio y verificar cómo se ven los anuncios y los precios desde distintos países, consulta los escenarios de nuestras páginas de solución de proxy para e-commerce y solución de verificación de anuncios.

La vía correcta para los desarrolladores de agentes#

Si desarrollas un agente de compra, la respuesta equivocada ante los bloqueos es ocultar mejor el agente. Falsificar la huella del navegador, hacer que se resuelvan las pantallas de verificación o repartir el tráfico entre pools de proxies para esquivar la protección de bots va contra las reglas de los sitios y coloca a tu agente exactamente en la clase de tráfico que hay que bloquear. Explicamos cómo funciona la huella del navegador en Browser fingerprinting.

La vía correcta pasa por estos pasos:

• Identifica a tu agente. Usa un User-Agent con un token de producto definido y una dirección de contacto; si es posible, firma tus peticiones con Web Bot Auth.
• Prioriza las integraciones oficiales. Si el comerciante tiene una API, un feed de productos o un protocolo de compra compatible, úsalos en lugar de extraer páginas.
• Sigue robots.txt y las condiciones. No fuerces rutas que un sitio ha cerrado a los agentes, ni siquiera en nombre de un usuario.
• Haz que la aprobación del usuario forme parte del proceso. Pide la aprobación explícita del usuario antes de pasos irreversibles como el pago; que los límites de gasto los fije el usuario, no el agente.
• Limita la velocidad. Para la compra de un usuario no necesitas abrir decenas de páginas en segundos.
• Acepta el fallo. Si un sitio bloquea a tu agente, díselo claramente al usuario y ofrécele una alternativa; no intentes esquivar el bloqueo.

Explicamos cómo hacer seguro el acceso web de los agentes con límites de velocidad, listas de permitidos y registros en Acceso web seguro para LLM: límites y permisos. En ese esquema, un proxy no se usa para ocultar al agente, sino para controlar y registrar desde qué dirección y ubicación sale el tráfico del agente.

Errores comunes#

• Intentar que el agente parezca humano. Una huella falsa y la rotación de IP colocan al agente en la misma clase que los bots maliciosos.
• Como comerciante, tratar todo el tráfico automatizado como una sola categoría. No separar a los agentes verificados de los bots de identidad desconocida puede cerrar canales de venta legítimos.
• Tratar la cabecera User-Agent como autenticación. Cualquiera puede escribir la cabecera; la verificación necesita una firma.
• Pagar sin aprobación del usuario. Activa las reglas de fraude y crea un problema de confianza serio con el usuario.
• Planificar una integración sin comprobar el estado del protocolo. La mayoría de los protocolos de este ámbito cambian rápido.
• Tratar un bloqueo como un error técnico. Normalmente es una política deliberada del sitio.

Guía de decisión#

Preguntas frecuentes#

¿Por qué los agentes de compra con IA se topan con pantallas de verificación?#

Los sistemas de protección de bots evalúan el tráfico de agentes con señales como la velocidad, las características del navegador y el origen de la IP. Como en estas señales los agentes se parecen a la automatización maliciosa, se encuentran con pantallas de verificación o bloqueos. Mientras la petición no lleve información verificable sobre quién hay detrás, el sitio no puede distinguir ambos casos.

¿Qué es Web Bot Auth?#

Es un enfoque que permite a bots y agentes demostrar su identidad firmando criptográficamente sus peticiones HTTP. Usa el estándar RFC 9421 HTTP Message Signatures. El agente publica su clave pública en su propio dominio, y el sitio o la CDN verifica la firma de cada petición con esa clave.

¿Un agente firmado funciona en cualquier sitio?#

No. Una firma solo demuestra quién es el agente; no concede acceso al sitio. Cada sitio decide cuánto permite a los agentes firmados. En los sitios que no verifican firmas, la firma no tiene ningún efecto.

¿Puede mi agente saltarse un bloqueo usando un proxy?#

Intentar esquivar la protección de bots cambiando de IP a través de un proxy significa ignorar una preferencia explícita del sitio y coloca a tu agente en la misma categoría que la automatización maliciosa. El uso legítimo de un proxy aquí es controlar y registrar la salida del tráfico del agente y aparecer desde una ubicación concreta cuando haga falta.

¿Deben los comerciantes bloquear por completo el tráfico de agentes?#

Es una decisión de negocio. Bloquear por completo reduce el riesgo de fraude, pero puede hacer perder clientes que usan agentes. Para muchos comerciantes, la vía equilibrada es mantener abiertas las páginas del catálogo, gestionar a los agentes verificados con reglas propias y vincular el pago a protocolos compatibles.

¿Se usan estos protocolos en Türkiye?#

La mayoría de estos protocolos son nuevos, y su alcance y soporte regional cambian rápido. Como comerciante o desarrollador en Türkiye, la forma más fiable es preguntar directamente a tu proveedor de pagos y a tu CDN qué protocolos de verificación de agentes y de pago admiten.

En resumen#

Los sitios bloquean a los agentes de compra con IA porque los sistemas de protección de bots no pueden distinguir a un agente que trabaja para un usuario de la automatización maliciosa, y los sistemas de pago no pueden verificar que el agente actúa con la autoridad del titular de la tarjeta. La solución no es ocultar al agente, sino que se identifique de forma verificable: las peticiones firmadas con Web Bot Auth basado en RFC 9421, los marcos de agentes reconocidos como Visa Trusted Agent Protocol y los protocolos de compra y autorización de pago como ACP y AP2 van en esa dirección. Los comerciantes deberían medir el tráfico de agentes y fijar una política, y los desarrolladores de agentes, apoyarse en integraciones oficiales y en la aprobación del usuario. Para verificar dentro de las reglas cómo se ven precios y contenidos desde distintas ubicaciones, echa un vistazo a nuestra página de solución de seguimiento de precios.