El 13 de julio de 2026, Cloudflare comenzó a implementar para todos los clientes Precursor, un motor de cliente que evalúa no una solicitud individual ni el paso de un captcha, sino el comportamiento dentro de toda la sesión. La formulación del CTO de Cloudflare, Dane Knecht, es breve y precisa: «En lugar de solo verificar una identificación en la entrada, estamos observando el comportamiento durante toda la visita».
Para aquellos que automatizan navegadores —scrapers, multi-cuentas, automatización SMM, agentes de IA— esto representa un cambio en la unidad de medida del riesgo. Antes, la unidad era la solicitud: pasaste el desafío, obtuviste cf_clearance, y trabajas. Ahora la unidad es la sesión, y vive, acumula evaluación y puede "estropearse" en cualquier momento después de que ya hayas pasado la verificación.
¿Qué exactamente lanzó Cloudflare?
Precursor es un script que Cloudflare inserta en las páginas a través de su red. Se activa mediante un interruptor en el panel (Security → Settings → Precursor), no requiere modificaciones en el código del sitio, y funciona en toda la zona a la vez; el comportamiento se ajusta puntualmente a través de Precursor Rules. Se posiciona no como un reemplazo de Turnstile, sino como un complemento: Turnstile es una verificación única, Precursor es continua.
Lo que el script recopila, según la descripción de Cloudflare:
- movimiento del puntero — trayectorias, velocidad, carácter de los arcos;
- ritmo de desplazamiento;
- cadencia de escritura — tempos y ritmo, pero no las teclas presionadas;
- actividad del portapapeles;
- cambio de enfoque de los elementos y visibilidad de la página/pestaña.
A partir de aquí, comienza lo interesante. Cloudflare describe directamente que busca en estos datos no una "huella", sino la física y fisiología del ser humano: arcos de movimiento del ratón, limitados por la rotación de la muñeca, en lugar de movimientos lineales de automatización; retrasos cognitivos medibles entre la aparición de un estímulo en la pantalla y la reacción; micro-oscilaciones de la mano — temblor — como ruido natural en la trayectoria.
La segunda capa — verificaciones cruzadas de contradicciones internas. ¿El puntero se mueve mientras la página está oculta? ¿Llegan eventos del teclado, pero ningún campo de texto está enfocado? Cada señal por separado parece normal, pero juntas no forman una imagen coherente de un ser humano vivo — y esto se captura más barato que cualquier análisis de un clic individual.
El tercer y más desagradable momento para la automatización: la evaluación se acumula por sesión y no se restablece con la recarga de la página. El clásico truco de "recibí un bloqueo — F5 / nueva pestaña" deja de ser un restablecimiento de estado. Los resultados de la verificación continua actualizan ese mismo cf_clearance, y Cloudflare afirma directamente que la confirmación de clearance ya emitida puede ser reducida o anulada en medio de la sesión, así como provocar un desafío adicional.
Dos modos — y por qué es importante saberlo de antemano
- Minimize Friction (por defecto) — verificación en segundo plano sin intersticiales. El usuario no ve nada, pero la garantía de "la sesión es válida" es más débil.
- Maximize Security (recomendado por Cloudflare) — un ligero desafío intersticial que establece una sesión válida, con un deterioro consciente de la experiencia del usuario.
Conclusión práctica: el comportamiento de protección en un sitio específico ahora depende de la configuración que no ves desde afuera. El mismo script, el mismo proxy y el mismo sitio pueden comportarse de manera diferente antes y después de que el propietario cambie el modo. Las activaciones son visibles para el propietario del sitio en Security → Analytics → Traffic → Bot analysis — en la misma fila que la distribución del bot score y los emparejamientos WAF.
Escala: por qué esto no es "otro anti-bot"
El contexto que hace que la noticia sea más importante que un lanzamiento habitual. Cloudflare procesa más de 1 billón de solicitudes al día, Turnstile opera casi 3 mil millones de veces al día. Según la estimación de la empresa, el tráfico automatizado ha superado por primera vez al humano y representa alrededor del 57% de todas las solicitudes web. Activar la capa de comportamiento con un solo interruptor en tal base significa que la parte de internet donde opera la detección de comportamiento por sesión puede aumentar drásticamente — sin un solo compromiso del lado de los sitios.
Y el objetivo declarado es precisamente lo que se utiliza hoy: "automatización avanzada que ejecuta JavaScript, opera en un entorno de navegador real y pasa captchas individuales sin levantar sospechas". Es decir, Playwright/Puppeteer con parches stealth, navegadores anti-detección y navegadores de agentes — exactamente el objetivo que Precursor describe abiertamente.
Para ser justos: Cloudflare no ha publicado datos cuantitativos — ni de precisión, ni de tasa de falsos positivos, ni de sobrecarga por monitoreo continuo en el navegador. Hasta ahora, son capacidades declaradas, no medidas de manera independiente. Tampoco se ha visto una ola pública de quejas sobre bloqueos masivos falsos en las dos semanas de implementación.
¿Qué significa esto en la práctica?
1. La calidad de IP ya no es "una condición suficiente" — pero sigue siendo necesaria
La conclusión tentadora de "ya que la detección es de comportamiento, los proxies ya no importan" es incorrecta. Precursor funciona encima de las capas anteriores: reputación de IP, huellas digitales TLS/HTTP, bot score. Una IP de centro de datos de un rango expuesto obtiene un alto bot score y un modo estricto de desafíos incluso antes de que se analice el movimiento del ratón. El comportamiento es un examen adicional, no un reemplazo del filtro de entrada: proxies residenciales o móviles con ASN vivo simplemente dan la oportunidad de llegar al segundo examen.
2. La sesión — un nuevo objeto de higiene
Antes, el error típico sonaba como "demasiadas solicitudes desde una IP". Ahora se le añade "demasiada actividad no humana dentro de una sola sesión". De aquí la práctica:
- No reutilices un contexto de navegador para cientos de tareas. Una sesión larga es una larga cadena de comportamiento, donde cualquier anomalía tiene tiempo de acumularse. Una sesión más corta significa menos material para puntuar.
- Mantén la combinación "sesión ↔ IP" estable. Cambiar la IP de salida en medio de una sesión es una contradicción notable; para escenarios con inicio de sesión se necesitan sesiones pegajosas con un tiempo de vida adecuado para la tarea, no una rotación agresiva en cada solicitud.
- No mezcles perfiles. Una cuenta — un conjunto estable: perfil de navegador, IP, zona horaria, idioma, patrón de comportamiento.
3. El comportamiento sintético tendrá que hacerse más honesto — o no hacerse en absoluto
Las ingenuas "emulaciones humanas" (movimiento lineal hacia el centro del botón, pausas uniformes de 100 ms, clic instantáneo después de la carga) bajo verificaciones cruzadas trabajan en tu contra: añaden señal, en lugar de eliminarla. Si el escenario no requiere imitar a un humano, es más seguro no generar comportamiento en absoluto que generar uno malo. Hablamos más a fondo sobre esta capa en el material sobre biometría conductual y proxies.
4. Los puntos finales de API y los clientes no navegadores — una historia aparte
Precursor requiere la ejecución de JavaScript. Los clientes sin navegador — curl, backend móviles — y las solicitudes XHR/fetch a puntos finales protegidos deben llevar correctamente las credenciales de la sesión, es decir, cf_clearance. Prácticamente, esto significa: primero el navegador establece una sesión válida, y luego las solicitudes "rápidas" van con sus cookies y en el mismo contexto de red (la misma IP, perfil TLS acordado). La discrepancia entre la sesión del navegador y el cliente HTTP es esa contradicción interna que están buscando.
5. Los puntos de captura de datos se desplazan
Donde el sitio active Maximize Security, la recolección sin cabeza barata se volverá notablemente más cara. La respuesta razonable no es escalar la "emulación inteligente" a cualquier costo, sino revisar la fuente: API oficial de la plataforma, feed de socios, puntos finales móviles, conjuntos de datos públicos. El camino completamente basado en navegador tiene sentido dejarlo donde los datos de otro modo no se pueden obtener.
¿Hacia dónde se dirige esto?
Precursor se integra lógicamente en la línea de Cloudflare del último año: bloqueo de crawlers de IA por defecto, AI Crawl Control con reglas granulares, Pay Per Crawl como un intento de hacer que el acceso al contenido sea de pago, y desde el 15 de septiembre de 2026, bloqueo de crawlers de IA de uso mixto en páginas con publicidad por defecto. La dirección general: el sitio quiere saber no "si eres humano en el momento de la entrada", sino "quién eres durante la visita y por qué viniste".
Para el mercado de automatización, esto significa un cambio lento pero unidireccional: el costo de una sesión "humanoide" está aumentando, el costo de una solicitud deja de ser la métrica principal. Ganan aquellos que recogen menos, pero con mayor precisión: sesiones cuidadosas, IP limpias para la tarea, huellas digitales acordadas — y una evaluación clara de qué datos realmente valen la pena el camino del navegador.
En resumen
- Desde el 13 de julio de 2026, Cloudflare implementa Precursor — detección de comportamiento por sesión, activada con un solo interruptor sin modificaciones en el código del lado del sitio.
- Señales: puntero, desplazamiento, ritmo de escritura (sin contenido), portapapeles, enfoque y visibilidad; además, verificaciones cruzadas de contradicciones.
- La evaluación se acumula por sesión; la recarga de la página no restablece la firma, el clearance puede ser anulado en medio de la visita.
- Los proxies no "han desaparecido": la capa de IP sigue siendo un filtro de entrada, el comportamiento es un segundo examen.
- Cloudflare aún no ha publicado datos cuantitativos sobre precisión y falsos positivos — es prematuro hacer conclusiones sobre la rigidez real.