En los últimos 18 meses se ha consolidado un patrón. Los sistemas de IA interesantes, los que hacen trabajo útil en producción, no se limitan a consultar un modelo y devolver lo que dice. Recuperan información de una fuente de datos en tiempo real durante la inferencia, entregan los resultados al modelo como contexto y dejan que el modelo razone sobre la información más reciente disponible.
El patrón tiene nombres. RAG es el más común. También se habla de uso de herramientas, llamadas a funciones, generación con búsqueda web. Las etiquetas varían; la arquitectura es la misma. Un modelo por sí solo conoce aquello con lo que fue entrenado. Un modelo con recuperación puede responder preguntas que la fecha de corte del entrenamiento no cubre.
Lo que nadie escribe es sobre la recuperación. Concretamente, qué determina si el sitio de destino realmente sirve al sistema de IA la página que necesita.
El modo de fallo en la recuperación
Imaginemos un agente de IA en producción que necesita responder “¿cuál es el precio actual de este producto en amazon.com?”. El agente construye una búsqueda, consulta un índice, obtiene URLs, descarga una, analiza el HTML, encuentra el precio y lo devuelve.
Esa secuencia tiene seis pasos y cualquiera de ellos puede fallar. El que falla con más frecuencia, y al que se le presta menos atención de ingeniería, es la descarga. El sitio de destino recibe una solicitud, decide si sirve la página real, una versión degradada o ninguna página, y responde. La decisión se basa en gran medida en lo que el sitio cree que es la IP de origen.
Si la solicitud proviene de una IP de salida de AWS, GCP o Azure, el sitio tiene una alta probabilidad a priori de que sea un bot. Los sitios más importantes, Amazon, Google, Reddit, X, todos los grandes medios de comunicación, tienen defensas agresivas contra el tráfico de centros de datos. La página que devuelven suele estar en blanco, ser un desafío CAPTCHA, un 403 o, lo más insidioso, una versión reducida sin precios, sin inventario, sin contenido real.
El sistema de IA, aguas abajo, no sabe que la página recibida está degradada. Analiza lo que obtuvo, no encuentra nada útil y o bien inventa una respuesta o devuelve “No tengo información actual sobre eso”. Ambos modos de fallo son peores que no recuperar nada.
Por qué los proxies residenciales cambian el cálculo
Una IP residencial es, por construcción, una IP que un ISP de consumo real asignó a un hogar real. Tiene años de tráfico normal detrás: streaming, navegación, videollamadas, uso de aplicaciones móviles. Desde la perspectiva del sitio de destino, las solicitudes que provienen de esa IP son indistinguibles de las de un visitante doméstico, porque provienen de la red de un visitante doméstico.
La capa defensiva que se activa con el tráfico de centros de datos en su mayor parte no se activa con el tráfico residencial. La página que devuelve es la que ve un visitante doméstico. El sistema de IA que está aguas abajo de la descarga obtiene el contenido real de la página real.
Esta es la razón por la que las redes de proxies residenciales existen como categoría de producto. Es también la razón por la que los sistemas de IA en producción que necesitan datos web frescos, y ahora hay miles de ellos, pagan discretamente por infraestructura de proxies residenciales aunque sus diagramas de arquitectura públicos no lo mencionen.
Tres clases de carga de trabajo de IA, tres formas distintas
El patrón de recuperación parece similar en la superficie, pero los requisitos de proxy divergen notablemente según la clase de carga de trabajo.
Chat con grounding en búsqueda. Un usuario hace una pregunta, el modelo lanza búsquedas web en paralelo, descarga los 3-10 primeros resultados, resume. La rotación por solicitud en un gran pool residencial es el primitivo adecuado: IP nueva por descarga, sin necesidad de sesión, máxima diversidad geográfica y de ISP. La carga de trabajo es irregular e impredecible. Los planes con precio por ancho de banda encajan porque el ancho de banda total escala con el volumen de preguntas.
Agentes de comparación de precios. Un agente ayuda a un usuario a comparar precios entre proveedores. Cada visita a un proveedor puede requerir varias páginas: resultados de búsqueda, detalle del producto, reseñas, a veces una simulación de compra. Las sesiones persistentes son el primitivo adecuado: una IP residencial por sesión de proveedor durante unos 5 minutos, para que el sitio del proveedor vea a un comprador coherente y no a mil scrapers. La precisión geográfica importa porque los precios de los proveedores varían por ciudad. La latencia importa porque el usuario está esperando.
Pipelines de datos continuos. Un sistema de monitorización recupera precios, noticias, expedientes regulatorios y menciones en redes sociales cada N minutos. Alto volumen, predecible, mayormente en paralelo. Rotación por solicitud, grandes pools de sid por trabajo cuando se necesitan sesiones coherentes con el sitio, presupuesto de ancho de banda ajustado. La carga de trabajo más parecida al scraping tradicional; la más madura en la pila de proxies.
Si tu sistema de IA tiene recuperación y no estás pensando conscientemente en cuál de estas formas estás operando, el comportamiento por defecto probablemente es incorrecto para al menos una de ellas.
Cómo se ve esto en código
Un wrapper mínimo de descarga con grounding sobre un proxy residencial tiene este aspecto:
import os, requestsfrom urllib.parse import urlparse
SHIFTER_USER = os.environ["SHIFTER_USER"]SHIFTER_PASS = os.environ["SHIFTER_PASS"]
def grounded_fetch(url, country="us", session_id=None, timeout=20): """Fetch a URL through a residential IP. Returns response.text or raises.""" auth_user = f"customer-{SHIFTER_USER}-country-{country}" if session_id: auth_user += f"-sid-{session_id}" proxy = f"http://{auth_user}:{SHIFTER_PASS}@p.shifter.io:443" resp = requests.get( url, proxies={"http": proxy, "https": proxy}, timeout=timeout, headers={"User-Agent": "Mozilla/5.0 (Macintosh) AppleWebKit/537.36"}, ) resp.raise_for_status() return resp.text
# Use case 1: search-grounded chat, fresh IP per fetchfor url in search_results: html = grounded_fetch(url, country="us") # ... parse and feed to LLM
# Use case 2: comparative shopping, sticky IP per vendorfor vendor_url in vendors: domain = urlparse(vendor_url).netloc session = f"agent-{user_id}-{domain}" html = grounded_fetch(vendor_url, country="us", session_id=session) # ... navigate within session
# Use case 3: continuous pipeline, per-request rotation, country fan-outfor country in ["us", "uk", "de", "jp"]: for url in monitoring_urls: html = grounded_fetch(url, country=country) # ... feed to indexerLos tres patrones se diferencian en un solo parámetro. El sistema de grounding no necesita conocer los detalles del proxy; simplemente llama a grounded_fetch con la semántica de persistencia de sesión adecuada para su clase de carga de trabajo.
Aspectos a vigilar
Si estás construyendo grounding de IA sobre una red de proxies residenciales, tres modos de fallo explican la mayoría de los incidentes en producción:
Degradación silenciosa del contenido. El sitio de destino devuelve un 200 con una página reducida. Tu pipeline no genera un error, simplemente alimenta al modelo con basura. Mitigación: valida la forma de la respuesta antes de pasarla al LLM. Si la página tiene un 80% menos de contenido que la mediana de páginas de ese dominio, trátalo como un fallo leve y reintenta con una IP diferente.
Deriva geográfica. Una solicitud con country=us enrutada a través de una IP residencial de EE. UU., pero la consulta de geolocalización del sitio de destino situó esa IP específica en Canadá. La página volvió en CAD con inventario canadiense. Mitigación: usa targeting a nivel de ciudad cuando la geolocalización importa, y verifica que la respuesta coincide con el idioma y la región solicitados antes de consumirla.
Expiración de sesión a mitad del flujo. Un flujo de agente de varios pasos comienza en la IP residencial A, el TTL de la sesión expira, la siguiente solicitud llega a la IP residencial B, el sitio de destino lo detecta y lanza un desafío de reautenticación. Mitigación: amplía el TTL de la sesión para cubrir el flujo más largo esperado, o detecta los desafíos de reautenticación y rota de forma consciente.
El punto más importante
Los sistemas de IA son ahora una de las mayores categorías de clientes de infraestructura de proxies residenciales. La razón no es que la IA sea especial, sino que la IA multiplica el coste de una mala recuperación. Un precio incorrecto en la respuesta de un chatbot es una mala respuesta. Un millón de precios incorrectos en un millón de respuestas de chatbot es un problema de confianza del cliente.
La capa de infraestructura ya existía. Se construyó para scraping, para verificación de anuncios, para inteligencia de precios. El grounding de IA es la clase de carga de trabajo más reciente y más grande sobre ella, pero los requisitos son los mismos que cualquier equipo de datos serio ha tenido durante una década. IPs residenciales reales, distribución geográfica real, control de sesión real, coste predecible.
Si tu sistema de IA está anclado en la web en tiempo real, lo que realmente estás comprando cuando adquieres un plan de proxies residenciales es la garantía básica de que la página que el sitio de destino muestra a tu sistema es la misma que mostraría a un usuario real. Esa es la base. Todo lo que está por encima, embeddings, recuperación, prompting, fine-tuning, solo funciona si la base funciona.