Agentes de IA que navegan la web: por qué se topan con CAPTCHAs y bloqueos por IP

Un agente de IA que abre páginas, rellena formularios y recoge datos suele funcionar bien en la demo. El problema aparece cuando lo pones en producción: de repente las páginas devuelven 403, el agente se queda atrapado en un CAPTCHA o recibe una versión vacía del sitio. El modelo no ha cambiado. Lo que ha cambiado es desde dónde se conecta y cómo se comporta.

Este artículo explica qué ve el servidor cuando llega tu agente, por qué lo bloquea y qué hacen los equipos que ya tienen agentes funcionando a diario.

Qué ve el servidor cuando llega tu agente

Para un sitio web, tu agente no es «un asistente inteligente». Es una petición HTTP con unos cuantos datos que se pueden comprobar en milisegundos:

• La IP de salida y su ASN. Si la petición sale de un servidor en la nube, el ASN pertenece a un proveedor de hosting. Muchos sistemas antibots tratan ese tráfico con más sospecha que el de una conexión doméstica o móvil.
• La frecuencia. Un humano abre unas pocas páginas por minuto. Un agente puede abrir decenas en paralelo. Ese patrón se detecta sin necesidad de mirar nada más.
• La huella del navegador. Los navegadores headless dejan rastros: cabeceras incompletas, propiedades de JavaScript que delatan automatización, tamaños de ventana poco habituales, ausencia de fuentes del sistema.
• La coherencia. Una IP de un país, una zona horaria de otro y un idioma del navegador de un tercero es una combinación que pocos usuarios reales tienen.

Ninguna de estas señales por sí sola suele provocar un bloqueo. Juntas, sí.

Cómo se ve un bloqueo en la práctica

Los bloqueos no siempre son evidentes. Conviene distinguir los síntomas, porque cada uno apunta a una causa distinta:

1. 403 o 429 directos. El servidor ha decidido que no quiere tu tráfico o que vas demasiado rápido. Suele estar ligado a la IP o al ritmo de peticiones.
2. Bucles de verificación. El agente resuelve un reto, recarga y vuelve a aparecer otro. Normalmente la IP tiene mala reputación o la huella del navegador no cuadra.
3. Bloqueos «suaves». La página carga con código 200, pero sin precios, sin resultados o con contenido genérico. Es el caso más peligroso, porque el agente cree que ha funcionado y guarda datos incompletos.
4. Bloqueos que llegan tarde. Todo funciona durante una hora y después empieza a fallar. Aquí el problema suele ser el volumen acumulado desde la misma IP.

Si tu agente no registra el código de respuesta y un resumen del contenido recibido, vas a tardar mucho en ver cualquiera de estos casos.

Primero, comprueba desde dónde sale tu agente

Antes de cambiar el código, confirma la IP de salida real. En un servidor o contenedor basta con:

curl -s https://ipinfo.io/json

La respuesta incluye la IP, el país y la organización. Si en org aparece un proveedor de nube, ya sabes que los sitios ven tu agente como tráfico de centro de datos. Muchos equipos se llevan una sorpresa en este paso: el agente sale por un NAT compartido o por una región distinta de la que creían.

Qué tipo de proxy usan los equipos en producción

No hay un tipo de proxy que sirva para todo. La elección depende del sitio y de la tarea:

• Proxies de centro de datos. Rápidos y baratos. Funcionan bien con APIs públicas, sitios sin protección antibots y tareas internas. Fallan pronto con tiendas online grandes, buscadores y redes sociales.
• Proxies residenciales. Usan IPs asignadas a conexiones domésticas, así que el sitio ve tráfico parecido al de un usuario normal. Son la opción habitual cuando el agente necesita navegar sitios con protección o ver contenido por país. Si quieres comparar opciones, en https://top-proxy.com/es/residential hay un listado de proveedores residenciales con sus características.
• Proxies móviles. IPs de operadores móviles. Son los que menos bloqueos sufren, porque muchas personas reales comparten la misma IP móvil, pero también son los más caros. Tienen sentido para tareas concretas, no para todo el tráfico.

Una regla práctica: empieza con lo más barato que funcione para cada sitio y sube de nivel solo donde haga falta.

Buenas prácticas que reducen los bloqueos

Cambiar de IP no arregla un agente que se comporta como un robot. Lo que mejor funciona es combinar varias cosas:

Limita el ritmo. Pon un máximo de peticiones por dominio y por minuto, y añade pausas aleatorias. Si el sitio responde con 429, reduce el ritmo en lugar de reintentar de inmediato.

Usa sesiones sticky cuando haya login o carrito. Si el agente inicia sesión, añade productos o pasa por varios pasos de un formulario, necesita mantener la misma IP durante toda la tarea. Cambiar de IP a mitad de una sesión es una de las formas más rápidas de acabar en un reto.

Rota cuando la tarea es independiente. Para consultas sueltas (una página de producto, un resultado de búsqueda) rotar la IP en cada petición reparte la carga y evita acumular volumen en una sola dirección.

Haz que la huella sea coherente. Si la IP es de México, que el idioma del navegador y la zona horaria también lo sean. Usa un navegador real en modo headless con un perfil completo, no una librería HTTP que solo imita cabeceras.

Comprueba la IP antes de escalar. Antes de lanzar mil tareas, lanza una y verifica que la IP de salida es la esperada, que el país coincide y que la página devuelve contenido real.

Registra todo. Código de respuesta, tamaño de la página, IP usada y si apareció un reto. Con esos cuatro datos puedes ver en qué sitio y con qué tipo de IP empieza a fallar el agente.

Lo que no conviene hacer

Hay prácticas que funcionan un día y te cuestan caro después:

• Ignorar los términos de uso del sitio o el archivo robots.txt cuando el contenido no es público.
• Recoger datos personales sin base legal.
• Lanzar el máximo de peticiones posible «porque el proxy lo permite». Lo único que consigues es quemar IPs más rápido.

Un agente que respeta límites razonables recibe menos bloqueos y da menos problemas legales.

Conclusión

La mayoría de los fallos de los agentes de IA en la web no vienen del modelo, sino de la red y del comportamiento. Antes de reescribir prompts o cambiar de framework, mira desde qué IP sale tu agente, a qué ritmo hace peticiones y si su huella es coherente. Con un tipo de proxy adecuado para cada sitio, sesiones sticky donde haga falta y un buen registro de errores, la mayoría de los CAPTCHAs y bloqueos dejan de ser un misterio.