Scraping

Agentes de IA en la Web: La Nueva Forma del Tráfico

Los agentes de IA que usan navegadores son un tipo de visitante diferente: ráfagas de actividad, flujos multietapa, sensibles a la latencia y geográficamente específicos. La cuestión de la infraestructura.

Chris Collins

Chris Collins

14 de mayo de 2026 · 9 min de lectura

Hasta hace poco, el tráfico en la web abierta tenía dos formas generales. La navegación humana, episódica, limitada por la atención, con un techo marcado por cuántas páginas puede leer una persona en una sesión. Y el scraping programático, de alto volumen, en abanico, mayormente sin estado, mayormente invisible para el usuario.

Una tercera forma está emergiendo rápidamente. Los agentes de IA que usan navegadores, Computer Use de Anthropic, Operator de OpenAI, los distintos agentes autónomos de código abierto, controlan un navegador real a través de una secuencia de páginas en nombre de un usuario. El tráfico que generan no se parece a ninguno de los dos anteriores. Los sitios que se defendieron con éxito contra el scraping aún no saben qué hacer al respecto. Los proveedores de infraestructura que dan soporte a esos agentes todavía están definiendo los primitivos adecuados.

Este artículo es una instantánea de cómo se ve realmente el tráfico de agentes de IA en producción hoy y cómo ha dado forma a la pila de infraestructura que lo sustenta.

Cómo se ve el tráfico a nivel de red

Un flujo canónico de agente de IA hoy: el usuario le pide al agente que “encuentre el vuelo directo más barato de Nueva York a Tokio a finales de agosto”. El agente lanza un Chromium headless, navega a Google Flights, rellena el formulario, lo envía, analiza los resultados, sigue el más barato hasta el sitio de la aerolínea, navega a la página de reserva, confirma disponibilidad y devuelve la respuesta.

Eso son entre 8 y 15 peticiones HTTP en 30-90 segundos, con las siguientes propiedades:

En ráfagas. O cero peticiones o una secuencia sostenida, sin estado estable entre medias. El agente está inactivo hasta que el usuario pregunta, y entonces trabaja intensamente durante un minuto.

Con estado dentro de la ráfaga. El flujo del agente tiene cookies, una sesión y un User-Agent. La petición N+1 debe parecer una continuación de la petición N desde la perspectiva del sitio de destino. Un cambio de IP a mitad del flujo rompe la sesión.

Endpoints heterogéneos. Cada ejecución del agente visita múltiples sitios distintos: motor de búsqueda, aerolínea 1, aerolínea 2, posiblemente un agregador de comparación. Cada sitio tiene su propia postura anti-bot.

Geografía anclada al usuario. El usuario quiere vuelos desde JFK, no desde un datacenter aleatorio. El tráfico del agente debería geolocalizarse de forma plausible en el lugar desde donde el usuario está consultando, o al menos en el lugar desde donde quiere aparentar que está reservando.

Sensible a la latencia. El usuario está esperando. Una latencia por petición de 800ms en lugar de 200ms, multiplicada por 12 peticiones, marca la diferencia entre “el agente respondió en 30 segundos” y “el agente respondió en 1,5 minutos”.

Esta forma no encaja ni con el modelo de navegación humana (demasiado rápido, demasiado con estado a velocidad de máquina) ni con el modelo de scraping (demasiado pocas peticiones por sesión, demasiado ligado a la sesión, demasiado anclado al usuario).

Por qué falla la infraestructura naive

Algunos patrones que los equipos de datos con experiencia usan con éxito no se trasladan bien:

Rotación por petición de un gran pool residencial. El patrón de scraping por defecto. Incorrecto para agentes porque la sesión necesita coherencia de IP, cookies de inicio de sesión, estado de búsqueda y vinculación de fingerprint. La rotación por petición rompe la sesión en la petición 2.

Proxies de datacenter por velocidad. Tentador por el perfil de latencia. Incorrecto porque los destinos que visita el agente (Google, aerolíneas, e-commerce, bancos) se defienden agresivamente contra el tráfico de datacenter. La mitad de las ejecuciones del agente fallan con CAPTCHAs.

Una única IP residencial estática. Tentador porque es coherente. Incorrecto porque la IP se quema rápidamente entre agentes; una IP sirviendo miles de flujos de agentes parece un scraper después de las primeras 100 ejecuciones.

La forma que funciona se parece más a sesiones sticky en residencial, con una sesión nueva por ejecución del agente, con targeting geográfico que coincide con la intención del usuario, y con la sesión acotada al tiempo de vida natural de la ejecución.

El patrón que funciona

La arquitectura a la que convergen la mayoría de los despliegues de agentes en producción:

user_request →
agent.spawn(
proxy_session_id=hash(user_id, request_id), # unique per user-run pair
proxy_country=user_geo_or_intent,
proxy_ttl=longer_than_expected_run, # don't expire mid-flow
) →
browser navigates target sites through that session →
agent returns result →
proxy session expires naturally

La abstracción del proxy es por ejecución, no por petición. Dentro de una ejecución, el agente tiene una IP residencial consistente. Entre ejecuciones, cada flujo de agente obtiene una IP nueva de un ISP nuevo de (generalmente) una ciudad nueva. La diversidad del pool protege contra que cualquier IP individual se queme por el tráfico repetido del agente; la coherencia de sesión protege contra que el sitio de destino marque al agente como sospechoso a mitad del flujo.

Este es funcionalmente el mismo patrón que usaría un bot de comparación de precios: sesión residencial sticky por sesión, atribución por cliente a un sid estable. El matiz para los agentes de IA es que el volumen es dramáticamente mayor (cada consulta de usuario que activa una ejecución del agente es una sesión) y la duración es más corta (la mayoría de los flujos de agentes duran menos de 2 minutos).

La infraestructura residencial con precio por ancho de banda encaja naturalmente con esto: las ejecuciones de agentes son transacciones acotadas por ancho de banda, no por concurrencia. Se paga por GB que mueven los agentes; la concurrencia es problema del runtime del agente, no del proxy.

Lo que están haciendo los sitios de destino

Mayormente nada, por ahora. La mayoría de los sitios importantes siguen tratando el tráfico de agentes de IA igual que el tráfico de scraping: mismas reglas anti-bot, mismo bloqueo. Esto va a cambiar rápidamente, en dos direcciones:

Los sitios que se benefician del tráfico de agentes lo acomodarán. Flujos de reserva, checkout de e-commerce, comparación de compras. El agente es un usuario real atendido por una capa de automatización; la conversión sigue siendo real. Los sitios inteligentes están empezando a publicar endpoints amigables para agentes, declaraciones al estilo robots que dicen “trata el tráfico con este user-agent y este header como un agente mediado por humanos, no bloquees, sí limita la velocidad”.

Los sitios que pierden con el tráfico de agentes se endurecerán. Todo lo que depende de publicidad tiene un problema real: los agentes no ven anuncios, no hacen clic en anuncios, no convierten anunciantes. Los sitios de noticias, los sitios de contenido gratuito, todo lo monetizado a través de impresiones tiene incentivos para detectar y bloquear específicamente el tráfico de agentes. Esta va a ser la próxima fase de la carrera armamentística anti-bot, y será más disputada que el scraping porque la capa de agentes tiene poderosos respaldos corporativos que pierden si sus agentes son bloqueados.

La capa de infraestructura en el medio, nosotros y nuestros pares en redes de proxies residenciales, ocupa una posición interesante. Somos la capa de acceso que permite a los agentes llegar a sitios que aún no los acogen. A medida que se desarrolle la negociación entre sitios y proveedores de agentes (probablemente a través de una combinación de contratos, relaciones de pago y protocolos revisados al estilo robots.txt), el papel de los proveedores de infraestructura pura se reducirá en el camino “permitido” y se ampliará en el camino “necesita diversidad a nivel de IP”.

Qué vigilar en 2026

Algunas señales que vale la pena seguir si estás construyendo sobre agentes:

La fracción de ejecuciones de agentes que necesitan re-autenticación a mitad del flujo. Hoy es casi cero con sesiones sticky adecuadas. Si empieza a subir, los sitios de destino han aprendido a detectar fingerprints de agentes y están desafiando la sesión a mitad del flujo. La mitigación requiere o bien un mejor fingerprinting del navegador en el lado del agente o diferentes estrategias de proxy.

La latencia p99 en flujos de agentes de múltiples pasos. Hoy es principalmente tiempo de red y tiempo de respuesta del sitio de destino. Si los gateways de proxy se convierten en un cuello de botella bajo carga concurrente de agentes, la capa de infraestructura necesita escalar.

Distribución geográfica del tráfico de agentes. Hoy la mayor parte del tráfico de agentes se geolocaliza donde está alojado el runtime del agente (principalmente US-East). A medida que los agentes empiecen a mediar transacciones reales de usuarios (compras, reservas, banca), el tráfico necesita geolocalizarse en la ubicación del usuario para que la lógica del sitio funcione correctamente. Este es el argumento alcista para que la infraestructura residencial precisa por ciudad/ASN se convierta en el estándar.

Declaraciones de sitios amigables con agentes. Hay que estar atentos a la aparición de un análogo de agents.txt o una declaración estructurada de “acepto tráfico de agentes con estas restricciones”. Si ocurre, el papel de la capa de proxy se reduce; si no ocurre, la capa de proxy sigue siendo el mediador de acceso.

La conclusión

Los agentes de IA son una nueva forma de tráfico real. No es scraping, no es navegación, no es recuperación RAG; comparten características con cada uno pero no encajan limpiamente con ninguno. La infraestructura subyacente tiene que ser flexible para soportar sesiones sticky por ejecución con concurrencia a volumen de scraping, geografía anclada al usuario y objetivos de latencia un tercio de lo que tolera el scraping.

La buena noticia para los proveedores de infraestructura: las redes de proxies residenciales bien construidas ya soportan exactamente esta forma. Sesiones sticky por ejecución de agente, IPs nuevas por sesión, precisión geográfica, precios por ancho de banda que escalan con el uso. Los primitivos que maduraron sirviendo a scrapers y bots de comparación son los mismos primitivos que necesitan los agentes.

La pregunta de producto para los próximos dos años no es si el tráfico de agentes será una categoría real, ya lo es. Es con qué claridad la pila de infraestructura y el ecosistema de sitios de destino convergerán en términos con los que ambos puedan vivir. Tendremos una imagen más nítida para el artículo de lanzamiento del año que viene.

Etiquetas: ai agents browser agents scraping industry

¿Listo para empezar?

Prueba los proxies residenciales de Shifter, más de 205M IPs, más de 195 países, desde 1,00 $/GB.

Comenzar