Cuando el tráfico de bots es mayoría, la pregunta cambia
La seguridad web se apoyó durante mucho tiempo en una suposición silenciosa: detrás de la solicitud entrante hay, en su mayoría, un humano. Sobre esta suposición se construyeron la gestión de sesiones, la prevención del fraude, el rate limiting, la seguridad de login, la protección de contenido y las políticas WAF. Existían bots; pero la mayoría de los sistemas los trataban como una excepción. El tráfico humano se consideraba normal y el tráfico de bots se veía como una desviación que había que separar.
Al entrar en 2026, este equilibrio cambió. El tráfico de bots ya no es un pequeño problema que se sitúa al margen del tráfico web. Los rastreadores de motores de búsqueda, las herramientas SEO, los scrapers de precios, los bots de credential stuffing, las redes de click fraud, las infraestructuras de proxy residencial y los agentes de IA acceden a la misma superficie de aplicación con intenciones distintas.
Por eso, en la gestión de bots moderna, la pregunta ya no es solo: ¿es esta solicitud un bot? La pregunta más importante es: ¿qué tipo de bot es y qué intenta hacer?
Porque no todos los bots son adversarios. Googlebot necesita acceder a su sitio. Las herramientas de monitorización autorizadas necesitan comprobar sus servicios. Un agente de IA que actúa en nombre de un cliente puede constituir un modelo de acceso completamente nuevo. En cambio, hay que detener a los bots que hacen credential stuffing, roban sus datos de precios, agotan el stock o hacen scraping de contenido. Una defensa construida sin esta distinción produce dos malos resultados: bloquea a los bots buenos y deja pasar a los malos.
Por eso, la gestión de bots moderna no consiste en una única decisión de bloqueo. Evalúa en conjunto las señales conductuales, las huellas de protocolo, el flujo de sesión, el contexto de IP y ASN, el volumen de solicitudes y los indicadores de intención. Y luego aplica una política distinta a cada categoría.
La era del 51 % en cifras
Los bots superaron por primera vez el umbral humano/no humano en 2025
Imperva Bad Bot Report 2025La Gestión de Bots de TR7 utiliza en conjunto señales conductuales, de protocolo, de identidad y de reputación
Producto TR7La detección debe funcionar en el flujo de solicitud sin afectar a los usuarios legítimos
Ingeniería TR7Necesario (permitir), tolerable (limitar), adversario (bloquear) — una sola decisión no basta
OWASP OATLos CAPTCHA fueron durante mucho tiempo el control por defecto de la defensa contra bots. La idea básica era simple: crear una tarea que un humano resolviera fácilmente y que un bot no pudiera resolver. Esa idea ha perdido su antigua fuerza. Los modelos modernos de IA visual pueden resolver los CAPTCHA de imagen con alta precisión. Los sistemas de speech-to-text neutralizan los CAPTCHA de audio. Las preguntas simples de matemáticas o lógica no suponen un obstáculo para los LLM. Y los CAPTCHA conductuales de tipo arrastrar y soltar o puzzle pueden superarse con bibliotecas de automatización que imitan el movimiento humano. Más importante aún, el bot ni siquiera necesita resolver el CAPTCHA por sí mismo. Los servicios de resolución de CAPTCHA funcionan como una cadena de suministro global — el bot recibe el challenge, lo reenvía a un servicio de resolución de bajo coste y utiliza la respuesta en tiempo real. Mientras tanto, el usuario legítimo pierde unos segundos, sufre problemas de accesibilidad o cae de la sesión. El equilibrio de costes se invirtió: el CAPTCHA añade fricción al usuario legítimo, pero no puede detener al atacante motivado. El enfoque más correcto es recopilar señales en segundo plano sin pedir al usuario que se demuestre — por eso la huella conductual, el análisis de protocolo y la clasificación de intención se sitúan en el centro de la gestión de bots moderna.
La gestión de bots moderna no se apoya en una sola señal
El periodo en que una sola señal bastaba para la detección de bots quedó atrás. La reputación de IP por sí sola no basta; las redes de proxy residencial pueden generar tráfico desde conexiones domésticas reales. El user-agent no es fiable. La detección de navegador headless es débil por sí sola. La resolución de CAPTCHA no es fiable. Una gestión de bots eficaz evalúa en conjunto muchas señales débiles — cada una superable por sí sola, pero es difícil que el atacante las imite todas a la vez, de forma coherente y a bajo coste.
Huella conductual
Los usuarios reales interactúan con la aplicación de formas irregulares, contextuales y biológicamente inconsistentes — los movimientos del ratón no trazan curvas perfectas, el ritmo de escritura no es constante, la velocidad de desplazamiento varía con el contenido, y los eventos de foco, los tiempos de espera, los retrocesos y las pequeñas vacilaciones forman un patrón natural a lo largo de la sesión. Los bots caen en uno de dos extremos: demasiado regulares (tiempos perfectos, movimientos lineales, solicitudes a intervalos iguales) o una imitación humana inconsistente. La huella conductual evalúa estas microseñales en conjunto — al usuario legítimo no se le muestra ningún challenge visible.
Huella TLS (JA4)
Los bots a menudo intentan presentarse como un navegador moderno — el user-agent puede ajustarse a Chrome, las cabeceras pueden editarse, el entorno JS puede imitarse parcialmente. Sin embargo, en las capas inferiores permanece la huella real de la biblioteca cliente. La lista de cipher suites dentro del TLS Client Hello, el orden de las extensiones, los grupos soportados y los detalles del handshake producen señales fuertes sobre la identidad del cliente. Aunque Python requests, un Chrome real, un navegador headless o una herramienta de automatización personalizada intenten parecer iguales, dejan huellas distintas a nivel de TLS.
Huella HTTP/2
HTTP/2 también produce señales valiosas de forma similar — los ajustes de frame, el orden de las pseudo-cabeceras, el comportamiento de codificación HPACK, las preferencias de priorización y los detalles de gestión de conexión reflejan la naturaleza real de la biblioteca cliente. El comportamiento HTTP/2 de los navegadores reales y el de las bibliotecas de automatización a menudo no es exactamente el mismo. Aunque en la capa superior se imiten las cabeceras, los detalles de protocolo permanecen distintos — esta diferencia es valiosa para detectar bots avanzados que parecen muy próximos a un navegador real.
Análisis del flujo de sesión
Una de las señales más valiosas es la forma de la sesión. Las solicitudes individuales pueden parecer limpias — las cabeceras son correctas, la IP no es sospechosa, el perfil TLS es aceptable. Pero al examinar la sesión completa, la intención aparece. El comportamiento de los usuarios reales sigue un recorrido: llegan a la página de inicio, exploran contenido, pasan a una categoría, revisan un producto, esperan. Los bots saltan la fase de descubrimiento — van directamente al endpoint objetivo, repiten la misma operación, se lanzan al formulario de login con credenciales distintas, extraen las páginas de precios a intervalos regulares, ejecutan el flujo de pago sin revisar el producto.
Reputación de IP y ASN
Las redes de proxy residencial debilitaron seriamente las defensas basadas en la reputación de IP. Los atacantes ya no provienen solo de IP de centros de datos. A pesar de ello, la reputación de IP y ASN no carece por completo de valor. Si de una IP residencial llegan miles de solicitudes por minuto, sigue siendo sospechoso. Un ASN que realiza muchos intentos de cuenta en poco tiempo sigue siendo importante. Las redes vistas anteriormente en abusos deben contribuir a la puntuación de riesgo. El enfoque correcto: la IP no debe decidir por sí sola — pero debe aportar peso a la decisión.
Clasificación de intención
El verdadero punto de inflexión es la clasificación de intención. 'Tráfico automático' no es por sí solo una categoría suficiente — un motor de búsqueda también es automático, y un bot de credential stuffing también. La clasificación de intención observa estas preguntas: qué endpoints se atacan, en qué orden llegan las solicitudes, cómo varían los payloads, cómo varían las credenciales en los intentos de login, con qué cadencia se extraen las páginas de precios o inventario. A un credential stuffer no se le trata igual que a un scraper de precios. La gestión de bots deja de ser una decisión de 'bloquear/permitir'; se transforma en un sistema que aplica política según la categoría.
Tres categorías: permitir, limitar, bloquear
En la gestión de bots moderna, el objetivo no es eliminar todos los bots. Esto ni es posible ni es deseable. Algunos bots son necesarios para su negocio. Algunos son tolerables. Y algunos deben bloquearse directamente. En la práctica, conviene dividir el tráfico de bots en tres categorías principales.
Bots necesarios — Permitir
Su acceso es valioso para su negocio u operativamente necesario. Los rastreadores de motores de búsqueda indexan sus páginas y aportan tráfico orgánico. Los bots de previsualización de redes sociales hacen que los enlaces se vean correctamente. Las herramientas de monitorización autorizadas comprueban la disponibilidad del servicio. Sus propias pruebas sintéticas miden la salud de la aplicación. Los agentes de IA — autenticados, autorizados, que actúan en nombre del usuario — se sitúan aquí; no deben tratarse como un bot malicioso anónimo. La política correcta no es el bloqueo, sino la verificación y el permiso controlado.
Bots tolerables — Limitar
No son directamente necesarios, pero tampoco deben bloquearse en todos los casos. Los scrapers lentos, los lectores de RSS, las herramientas de archivado, los generadores de previsualización de redes sociales y los rastreadores de análisis de nivel medio entran en este grupo. Son tolerables dentro de ciertos límites — pero no debe permitírseles consumir recursos de la aplicación, extraer datos de forma agresiva ni afectar a la experiencia del usuario. La política correcta: rate limiting, baja prioridad, aplicación de challenge, restricción a ciertos endpoints. Las sesiones inciertas también pueden incluirse en esta categoría — se prueban con fricción de bajo coste.
Bots adversarios — Bloquear
Bots cuyo objetivo es causar daño directo. Los bots de credential stuffing prueban contraseñas filtradas en los endpoints de login. Los ataques de account takeover intentan apoderarse de cuentas. Los scrapers competitivos roban datos de precios e inventario. Los bots de click fraud consumen el presupuesto publicitario. Los bots de inventario agotan el stock de forma artificial. Los scrapers de contenido no autorizados se llevan sus datos para otros modelos, competidores o brokers de datos. La política correcta es clara: bloquear, registrar, generar alarma y, si es necesario, activar procesos de seguridad adicionales. Cada solicitud exitosa genera un coste — aquí se necesita una detención directa, no fricción.
La capa de política: separar la detección de la acción
Un error frecuente en la gestión de bots es tratar la detección y la política como si fueran lo mismo.
La detección responde a esta pregunta: ¿qué es este tráfico?
La política responde a una pregunta distinta: ¿qué haremos con este tráfico?
Cuando estas dos decisiones no se separan, el sistema se vuelve frágil. Una regla simple como 'si es un bot, bloquear' coloca a Googlebot, al lector de RSS, al agente de IA y al credential stuffer en el mismo saco. Esto aumenta los falsos positivos y corta el tráfico valioso para el negocio.
El enfoque más robusto es este: la capa de detección determina el tipo y la intención del bot; la capa de política aplica una acción según la categoría.
Por ejemplo: permitir para Googlebot, permitir para el uptime monitor, aplicar rate limiting para el lector de RSS, aplicar un challenge de bajo coste para la automatización incierta, limitar o bloquear para el scraper de precios, bloquear y generar alarma para el credential stuffing, bloquear e informar para el click fraud.
Esta separación aporta flexibilidad operativa. Cuando surge una nueva categoría de agente de IA, la política puede actualizarse sin reescribir desde cero el motor de detección. Cuando se aumenta la sensibilidad de detección, los motores de búsqueda no se bloquean por error. Las distintas categorías de bots pueden gestionarse a velocidades distintas.
¿Cómo medir si su gestión de bots funciona?
La gestión de bots no es una configuración de una sola vez. A medida que cambian los atacantes, también cambian las señales. Por eso el éxito del sistema debe medirse de forma continua a través de seis métricas prácticas.
Proporción bot-humano por endpoint
La media de todo el sitio no basta por sí sola. Los endpoints de login, registro, pago, búsqueda, precios, inventario, API y contenido deben monitorizarse por separado. El problema de bots suele concentrarse en endpoints concretos. La proporción de bots en un endpoint de pago no tiene el mismo nivel de riesgo que la de una página de blog. Una vista por endpoint le permite ver el problema en el lugar correcto.
Distribución de categorías de bots
La información 'hay un X % de tráfico de bots' no genera acción por sí sola. Lo que importa es la distribución: cuánto es de motores de búsqueda, cuánto de herramientas de monitorización, cuánto de scrapers, cuánto de credential stuffing, cuánto de agentes de IA, cuánto de automatización incierta. Si la mayor parte de su tráfico de bots proviene de motores de búsqueda, tiene un problema de seguridad distinto que si proviene de tráfico de credential stuffing — completamente distinto.
Latencia de detección
Las decisiones de detección de bots deben tomarse con rapidez. El usuario no debe esperar a que el sistema decida en flujos críticos como login, pago o búsqueda. Incluso latencias del orden de milisegundos pueden afectar a la experiencia del usuario en aplicaciones de alto volumen. El objetivo práctico es que el mecanismo de decisión funcione tan rápido que el usuario no lo perciba. La Gestión de Bots de TR7 está diseñada para tomar esta decisión con una latencia inferior a 5 ms.
Señales de falsos positivos
Los falsos positivos no se detectan solo desde el panel de seguridad. Las señales reales suelen aparecer en los tickets de soporte, las quejas de usuarios, las caídas del embudo de conversión, el aumento de logins fallidos o las tasas de abandono del pago. El seguimiento de los falsos positivos no debe dejarse solo en manos de las puntuaciones internas del motor de detección — debe monitorizarse junto con la experiencia del usuario y las métricas de negocio. Si una defensa de bots detiene al atacante pero también detiene al cliente real, no es exitosa.
Tasa de evasión
Una de las métricas más importantes que muestra la salud a largo plazo del sistema. Debe monitorizarse la proporción de sesiones de bots adversarios verificados que alcanzan las acciones protegidas — intentos de login, creación de cuentas, compras, llamadas a API sensibles, descarga de contenido. La tendencia importa más que la cifra absoluta. Si la tasa de evasión es estable, la defensa puede estar siguiendo el ritmo del atacante. Si aumenta, significa que los atacantes han empezado a superar las señales actuales — se necesitan nuevas señales, ajustes de política o controles más fuertes.
Coste por bloqueo
No toda defensa tiene el mismo coste. Los controles basados en firmas y las señales de IP/ASN pueden funcionar a gran volumen con bajo coste. El análisis conductual requiere más contexto. La inferencia ML pesada o el análisis profundo de sesión deben usarse no para cada solicitud, sino para los puntos de decisión de alto valor. La defensa de bots debe construirse por capas — señales baratas en el tráfico amplio, análisis más caros en login, pago, creación de cuentas, API sensibles y acciones de alto riesgo. La métrica correcta no es solo '¿cuántos bots se bloquearon?'. Una mejor pregunta es: ¿el valor del ataque que bloqueamos es mayor que el coste de la defensa?
Uno de los nuevos temas que complican la gestión de bots en 2026 son los agentes de IA. La distinción de bots tradicional se hacía sobre todo entre bot bueno y bot malo. El motor de búsqueda es bueno, el credential stuffer es malo. Pero los agentes de IA difuminan esa línea. Un agente de IA puede rellenar un formulario en nombre del usuario, investigar productos, hacer una reserva, comparar precios o completar un flujo de trabajo corporativo. En ese caso, que sea tráfico automático no significa por sí solo mala intención. Aquí lo crítico es la identidad y la autorización. Un agente de IA autorizado debe tratarse no como un bot anónimo, sino como un cliente que actúa en nombre del usuario. Esto combina la gestión de bots con el control de acceso. Debe determinarse con claridad en nombre de quién opera, qué permisos tiene, qué acciones puede realizar y a qué límites de velocidad está sujeto. A causa de los agentes de IA, la gestión de bots ya no es solo una capa de seguridad — se convierte en un modelo de acceso que debe pensarse junto con la identidad, la política y la experiencia de la aplicación.
Conclusión: señal en lugar de CAPTCHA, clasificación en lugar de bloqueo
En 2026, la gestión de bots no puede llevarse a cabo con los reflejos antiguos.
Los CAPTCHA perdieron su eficacia como control primario. Las redes de proxy residencial dejaron la reputación de IP insuficiente por sí sola. Los navegadores headless pueden superar los controles simples de huella. Y los agentes de IA hacen imposible explicar el tráfico automático únicamente con la categoría de bot malicioso.
En este entorno, el enfoque correcto se compone de tres partes: detección con señales conductuales y basadas en protocolo; clasificación de intención con análisis de flujo de sesión y de payload; política diferenciada según la categoría del bot.
Así, al usuario legítimo no se le muestra CAPTCHA. Se permite a los bots necesarios. Se limita a los bots tolerables. Se bloquea a los bots adversarios. Y los agentes de IA se gestionan en el contexto de la identidad y la autorización.
El objetivo de la gestión de bots moderna no es 'eliminar todos los bots'. El objetivo es aplicar el trato correcto a cada tipo de tráfico automático.
Referencias y fuentes
Medición anual del sector que documenta que la cuota de bots superó el 51 % en 2025. https://www.imperva.com/resources/resource-library/reports/bad-bot-report/
Catálogo exhaustivo de amenazas automatizadas, incluido el credential stuffing (OAT-008), el scraping (OAT-011) y el abuso de creación de cuentas (OAT-019). https://owasp.org/www-project-automated-threats-to-web-applications/
El paquete moderno de huella TLS de FoxIO, que sustituye al antiguo JA3 con funciones de codificación más fuertes. https://github.com/FoxIO-LLC/ja4
Informes trimestrales de inteligencia de amenazas sobre patrones de tráfico de bots y tendencias de detección. https://www.akamai.com/security-research/the-state-of-the-internet
Artículos técnicos sobre detección de proxy residencial, análisis conductual y técnicas de huella. https://blog.cloudflare.com/tag/bots/
La huella conductual es más fuerte que los CAPTCHA
La Gestión de Bots de TR7 utiliza en conjunto 11 factores de detección ponderados, incluidos el análisis de patrones conductuales, la huella TLS y HTTP/2, el contexto de IP/ASN, el flujo de sesión y la clasificación de intención. Las decisiones están diseñadas para tomarse por debajo de 5 ms. No genera fricción de CAPTCHA para los usuarios legítimos. Y para los bots adversarios aumenta el coste, refuerza la detección y hace posible una intervención basada en políticas.
Descubra la Gestión de Bots de TR7