La rendición de cuentas continua de Cloudflare para bots verificados convierte la identidad en una prueba permanente
Cloudflare introdujo la rendición de cuentas continua para bots verificados el 16 de octubre, añadiendo una prueba de comportamiento sostenido a un programa que antes se centraba en la identidad. El cambio aborda un conflicto básico: un rastreador puede demostrar quién lo opera y aun así ignorar las reglas de un sitio web.
El nuevo sistema observa si la automatización verificada respeta las preferencias publicadas y responde cuando un sitio le pide reducir la velocidad. Cloudflare convierte después esas observaciones en una banda de confianza explicable, en lugar de tratar la verificación como un sello de aprobación permanente.
La distinción cobra importancia después de que Cloudflare eliminara a Perplexity de su lista de Verified Bots en 2025. Cloudflare alegó que Perplexity accedió a contenido restringido y modificó sus tácticas de rastreo al ser bloqueada. Perplexity cuestionó esa caracterización. El episodio expuso la debilidad que Cloudflare quiere abordar ahora: la autenticación puede identificar a un bot, pero la identidad por sí sola no garantiza una buena conducta.
La rendición de cuentas continua para bots verificados añade una capa de comportamiento
Cloudflare está transformando la verificación de una decisión puntual sobre identidad en una evaluación continua de conducta.
El programa Verified Bots de Cloudflare ha ayudado históricamente a los sitios web a distinguir la automatización reconocida del tráfico desconocido o potencialmente malicioso. Los rastreadores de búsqueda, servicios de monitorización, herramientas de accesibilidad y agentes dirigidos por usuarios pueden solicitar el estado de verificado.
Un bot debe identificarse mediante un método aceptado. Estos métodos incluyen firmas criptográficas, rangos de IP publicados junto con agentes de usuario estables y comprobaciones de DNS inverso.
La política de bots verificados de Cloudflare también exige un comportamiento no abusivo. Los servicios verificados deben respetar las instrucciones de robots.txt, mantener tasas de solicitudes razonables y evitar eludir las preferencias de los sitios web.
El problema es temporal. Un operador puede cumplir esas condiciones durante la inscripción y después desplegar una actualización que cambia el comportamiento de su rastreador. Un error de configuración también puede generar tráfico perjudicial sin intención maliciosa.
El nuevo sistema de Cloudflare vigila esa brecha. Mide con qué consistencia un rastreador sigue las preferencias de los sitios a lo largo del tiempo y registra el comportamiento que sustenta su evaluación.
El resultado es una banda de confianza explicable. Cloudflare la describe como un rango que refleja un comportamiento sostenido, no como un juicio permanente sobre una empresa u operador.
Este enfoque separa el riesgo de la confianza. El riesgo se refiere al daño potencial asociado a una solicitud o momento concreto. La confianza refleja un patrón repetido a lo largo de muchas interacciones.
Un rastreador verificado podría generar una infracción accidental de política sin convertirse automáticamente en alguien no fiable. A la inversa, un bot que ignora restricciones de forma repetida no debería conservar un trato especial porque superó antes una comprobación de identidad.
Cloudflare afirma que sus primeras señales de evaluación plantean dos preguntas. ¿Respetó el bot las instrucciones publicadas y respondió a la retroalimentación directa del sitio web?
Estas señales se centran en el comportamiento observable de la red. No requieren que Cloudflare infiera las intenciones privadas del operador de un rastreador.
Este enfoque también ofrece a los operadores una vía para recuperarse. Una banda de confianza puede mejorar cuando un bot cambia sistemáticamente su comportamiento tras recibir instrucciones o respuestas de límite de tasa.
Cloudflare ya utiliza el sistema internamente. La compañía afirma que planea exponer la evaluación a sus clientes después de acumular suficiente historial de comportamiento y perfeccionar sus directrices.
Con el tiempo, los clientes podrán elegir un umbral de confianza para gestionar el tráfico de Verified Bots. Cloudflare no ha anunciado una fecha de disponibilidad general ni ha revelado la fórmula exacta de puntuación.
Estas omisiones son importantes. El anuncio define la idea rectora y las señales iniciales, pero todavía no proporciona una especificación completa del producto.
Aun así, la dirección es clara. El estado de verificado significará cada vez más que un bot sigue siendo identificable y continúa comportándose dentro de los límites aceptados.
Por qué la identidad ya no podía sostener por sí sola toda la decisión de confianza
Una identidad criptográfica responde quién envió una solicitud, pero no responde si esa solicitud debe ser bienvenida.
Cloudflare ha dedicado varios años a reforzar la identificación de bots. Las señales tradicionales, como las cadenas de agente de usuario y las direcciones IP, presentan limitaciones importantes.
Un agente de usuario es simplemente una etiqueta enviada con una solicitud HTTP. Puede ser copiada por otro programa. Los rangos de IP pueden cambiar, servir a varios sistemas o verse comprometidos.
Web Bot Auth mejora esa capa de identidad. Permite que un bot firme solicitudes mediante HTTP Message Signatures, que proporcionan evidencia criptográfica de que un operador autorizado creó la solicitud.
Cloudflare valida la firma y asocia el tráfico con una entrada en BotBase, su directorio público de bots y agentes. Esto reduce la dependencia de identificadores fáciles de falsificar.
El formato de firma subyacente no es únicamente una invención de Cloudflare. HTTP Message Signatures se estandarizó mediante RFC 9421, mientras las especificaciones de Web Bot Auth continúan desarrollándose abiertamente.
La validación de firmas aún resuelve solo la autenticación. Una firma válida puede establecer que una solicitud procede de un operador conocido. No puede establecer que el operador respetó las restricciones de un editor.
Pensemos en un bot de monitorización que firma correctamente cada solicitud, pero comienza a solicitar páginas cientos de veces más rápido tras un despliegue defectuoso. Su identidad sigue siendo válida incluso cuando su conducta genera costes operativos.
El mismo problema se aplica a los rastreadores de IA. Un rastreador puede identificarse correctamente mientras solicita contenido que el sitio ha marcado como no disponible para su propósito.
Esta brecha se vuelve más importante a medida que la automatización asume más funciones. Cloudflare ahora clasifica sistemas verificados en búsqueda, entrenamiento de modelos, agentes dirigidos por usuarios, transacciones, pruebas de seguridad, recopilación de datos y otras actividades.
Algunos bots también actúan como intermediarios. Su infraestructura pertenece a una empresa, pero muchos usuarios pueden iniciar acciones a través de ella.
Esto crea lo que Cloudflare denomina confianza transitiva. Un sitio podría confiar en el operador de la plataforma sin confiar en todos los usuarios que dirigen el agente de la plataforma.
La rendición de cuentas continua para bots verificados no resuelve por completo este problema de delegación. Sin embargo, ofrece a Cloudflare una forma de evaluar el tráfico resultante en vez de depender por completo de la identidad del operador.
El cambio también presiona a los operadores de bots para que incorporen el cumplimiento en los sistemas de producción. El buen comportamiento ya no puede limitarse a una promesa registrada durante la inscripción.
Los operadores necesitan una recuperación fiable de robots.txt, selección de URL consciente de las políticas, identidades específicas para cada propósito y control adaptativo de la tasa. También necesitan una monitorización que detecte regresiones antes de que una CDN registre un patrón perjudicial.
Esto eleva el estándar de ingeniería para la automatización verificada. La autenticación se convierte en el requisito de entrada, mientras que el cumplimiento observable determina si la confianza resultante perdura.
Robots.txt y HTTP 429 se convierten en evidencia, no en sugerencias
El mecanismo de Cloudflare convierte dos señales web conocidas en evidencia del nivel de confianza continuo de un rastreador.
La primera señal es robots.txt, un archivo de texto situado en la ruta de nivel superior de un sitio web. Publica instrucciones de acceso para rastreadores automatizados.
El protocolo organiza las reglas por agente de usuario y utiliza las directivas Allow o Disallow para identificar rutas accesibles. Según RFC 9309, un rastreador que descarga correctamente el archivo debe seguir sus reglas analizables.
Robots.txt tiene limitaciones prácticas. Comunica preferencias, pero no las aplica como una puerta de autenticación o una regla de firewall.
También dice poco sobre por qué un rastreador busca contenido específico. Un operador puede utilizar bots separados para búsqueda, entrenamiento de modelos y recuperación solicitada por usuarios. Otro puede combinar esos propósitos.
Cloudflare evalúa si el tráfico observado sigue siendo coherente con las reglas publicadas por el sitio. El sistema hace hincapié en patrones repetidos en lugar de considerar decisivo cada desajuste aislado.
Esta distinción reduce la probabilidad de que un error temporal destruya automáticamente la reputación de un bot. También hace más difícil descartar un incumplimiento persistente como una anomalía.
Cloudflare advierte que robots.txt representa un límite mínimo, no un permiso general para todo lo que no prohíbe. Un sitio web puede comunicar que el acceso continuado no es bienvenido mediante otras respuestas.
HTTP 429 es la segunda señal inicial. Un servidor utiliza este código de estado para indicar que un cliente ha enviado demasiadas solicitudes durante un periodo determinado.
La respuesta puede incluir una cabecera Retry-After, que indica al cliente cuánto tiempo debe esperar. Sin embargo, esta indicación es opcional.
El estándar HTTP pertinente deja a los servidores flexibilidad sobre cómo identifican el tráfico excesivo y cuentan las solicitudes. Los servidores pueden aplicar límites por recurso, credenciales u otras medidas.
Cloudflare observa qué hace el bot después. Un bot que reduce la velocidad o se pausa tras recibir respuestas 429 repetidas demuestra capacidad de adaptación. Uno que continúa al mismo ritmo pierde confianza.
Esto convierte la gestión de límites de tasa en parte de la rendición de cuentas de los bots verificados. También cierra una laguna importante, porque un rastreador puede mantenerse completamente dentro de las rutas permitidas mientras abruma al origen.
El mecanismo combinado crea un ciclo de retroalimentación conductual. Un editor declara sus preferencias de acceso, el origen proporciona retroalimentación en tiempo real y Cloudflare observa la respuesta del rastreador.
Bot Preference Sync respalda el lado de publicación de ese ciclo. Traduce las preferencias configuradas de un cliente para el tráfico de IA en entradas correspondientes de robots.txt.
Las herramientas Bot Management de Cloudflare proporcionan el lado de aplicación. Los clientes pueden utilizar categorías reconocidas y otras señales para permitir, bloquear, desafiar o limitar la tasa del tráfico.
La evaluación continua se sitúa entre esos componentes. Pregunta si un bot conocido realmente se comporta como se espera después de encontrarse con las políticas publicadas y aplicadas.
Por tanto, el sistema mide el cumplimiento en dos escalas temporales distintas. Robots.txt refleja una política de sitio relativamente duradera, mientras que HTTP 429 comunica presión inmediata.
Un rastreador fiable debe manejar ambas. Debe planificar las solicitudes teniendo en cuenta las restricciones vigentes y ajustar su comportamiento cuando cambian las condiciones actuales.
Perplexity muestra por qué la rendición de cuentas de los bots verificados es polémica
La disputa sobre Perplexity muestra tanto el valor de la evidencia conductual como el riesgo de dejar que un proveedor de infraestructura defina la confianza.
Cloudflare afirmó que comenzó a investigar después de que los clientes informaran de que Perplexity seguía accediendo a sitios cuyos operadores habían intentado bloquear rastreadores de IA.
La empresa creó dominios de prueba nuevos, no indexados y protegidos por restricciones de robots.txt. Cloudflare envió después a Perplexity prompts que requerían información de esos dominios.
Según Cloudflare, Perplexity recuperó información detallada pese a esas restricciones. Cloudflare también alegó que el rastreo pasó a infraestructura no declarada e identidades genéricas de navegador cuando los agentes declarados encontraban bloqueos.
Cloudflare comparó ese comportamiento con pruebas que involucraban a OpenAI. Afirmó que ChatGPT se detuvo cuando robots.txt prohibía el acceso y también cuando encontró un bloqueo de red.
Cloudflare eliminó posteriormente el bot de Perplexity de su lista de bots verificados. También añadió reglas de detección gestionadas destinadas a bloquear el supuesto rastreo sigiloso.
Perplexity rechazó la acusación. Según se informó, la empresa describió el relato de Cloudflare como un argumento de venta y sostuvo que el tráfico identificado por Cloudflare no pertenecía a Perplexity.
Ese desacuerdo no ha desaparecido simplemente porque Cloudflare ofrezca ahora una banda de confianza. Cualquier calificación de comportamiento sigue dependiendo de la atribución, el diseño de las mediciones y la interpretación de las políticas.
La atribución es especialmente difícil cuando un servicio de IA utiliza varias capas de recuperación. Una respuesta puede basarse en un rastreador declarado, un índice de terceros, un navegador dirigido por el usuario o infraestructura operada por otro proveedor.
Una CDN puede observar patrones de solicitudes en muchos sitios web, pero no siempre puede conocer la relación comercial o la intención del usuario detrás de cada solicitud.
Del mismo modo, un operador puede considerar de forma distinta una obtención dirigida por el usuario frente a un rastreo autónomo a gran escala. Un editor puede rechazar esa distinción cuando ambas acciones copian la misma página restringida.
La banda de confianza propuesta por Cloudflare se adapta mejor a estas disputas que una etiqueta binaria. Puede representar patrones e identificar qué comportamientos influyeron en la evaluación.
Sin embargo, la explicabilidad debe ir más allá de una etiqueta breve. Los operadores necesitan detalles suficientes para identificar las solicitudes, políticas, periodos de tiempo y medidas correctivas que motivaron una calificación inferior.
También será importante contar con un proceso de apelación. Una atribución errónea podría perjudicar a un bot legítimo al hacer que los clientes lo bloqueen en muchos sitios protegidos por Cloudflare.
La concentración de autoridad genera otra preocupación. Cloudflare proporciona las herramientas de preferencias, observa el tráfico, calcula la evaluación de confianza y ofrece el producto de aplicación.
Esa integración hace práctico el ciclo de rendición de cuentas. También otorga a Cloudflare una influencia considerable sobre qué servicios automatizados pueden acceder a una gran parte de la web.
Por tanto, la empresa debería explicar cómo gestiona los casos ambiguos, los agentes con fines mixtos, la infraestructura compartida y las interrupciones temporales. Una puntuación sin salvaguardas procedimentales podría convertirse en un sistema opaco de reputación.
La rendición de cuentas de los bots verificados también exige claridad simétrica por parte de los operadores. Las empresas deberían documentar sus agentes de usuario, fines, rangos de IP, claves de firma y respuestas a las restricciones de los sitios.
Identidades separadas para búsqueda, entrenamiento y recuperación dirigida por el usuario pueden reducir la ambigüedad. Permiten a los editores autorizar un descubrimiento útil sin conceder el mismo acceso a todos los fines automatizados.
El caso de Perplexity sigue siendo una advertencia, no un veredicto universal. Cloudflare presentó observaciones técnicas, mientras que Perplexity cuestionó la titularidad y la interpretación del tráfico.
Ese conflicto sin resolver es precisamente la razón por la que el nuevo sistema necesita pruebas transparentes. La medición continua solo es valiosa cuando las partes afectadas pueden examinar y cuestionar sus conclusiones.
La banda de confianza aún deja preguntas críticas sin responder
Cloudflare ha descrito qué quiere medir, pero no ha detallado lo suficiente cómo funcionarán los juicios resultantes.
La empresa no ha publicado reglas de ponderación para infracciones de robots.txt, respuestas 429 ignoradas u otras señales futuras. Tampoco ha definido los límites entre sus bandas de confianza.
Sin esos detalles, los clientes no pueden predecir de forma independiente cómo el comportamiento de un rastreador se traducirá en una calificación. Los operadores de bots también carecen de un objetivo técnico completo para cumplir con las normas.
Cloudflare afirma que evaluará patrones sostenidos en lugar de incidentes aislados. Es una salvaguarda sensata, pero “sostenido” requiere una ventana medible.
Un rastreador que envía millones de solicitudes puede generar muchas infracciones accidentales con una tasa porcentual mínima. Un rastreador más pequeño puede causar daños graves con muchas menos solicitudes contra un único origen.
Los recuentos brutos distorsionarían esos casos. Los porcentajes también pueden ocultar ráfagas graves que saturan temporalmente un sitio vulnerable.
Un modelo de puntuación creíble necesita contexto. Esto incluye volumen de solicitudes, capacidad del origen, vigencia de la política, instrucciones Retry-After, coherencia de las respuestas y pruebas de que el rastreador recibió la señal.
Robots.txt introduce otra fuente de ambigüedad. Los archivos pueden no estar disponibles, estar mal configurados, ser contradictorios, cambiar durante un rastreo o ser modificados por un intermediario.
Bot Preference Sync de Cloudflare reduce parte de la deriva de configuración al alinear los ajustes del panel con las preferencias publicadas. No puede eliminar todos los conflictos con reglas personalizadas o el comportamiento del origen.
HTTP 429 es igualmente imperfecto. Algunos sitios web generan esa respuesta debido a configuraciones de seguridad amplias, infraestructura compartida o tráfico identificado erróneamente.
La especificación HTTP no exige que los servidores utilicen 429 bajo una carga elevada. Un sitio puede descartar conexiones o aplicar otros controles, lo que deja al rastreador con comentarios menos explícitos.
Por tanto, Cloudflare necesita salvaguardas para evitar tratar cada 429 como prueba de mala conducta. La evidencia importante es no adaptarse de forma repetida en condiciones donde la señal sea atribuible y comprensible.
Los umbrales seleccionados por el cliente añaden más complejidad. Dos sitios web podrían tratar la misma banda de confianza de forma diferente, lo que respalda el control local pero complica las expectativas de los operadores.
Ese diseño probablemente sea preferible a una decisión universal de permitir o bloquear. Los editores tienen distintos modelos de negocio, límites de infraestructura y actitudes hacia el descubrimiento mediante IA.
Un minorista puede recibir con agrado visitas frecuentes de agentes que respaldan recomendaciones de productos. Un editor financiado por publicidad puede restringir los rastreadores de entrenamiento y permitir sistemas de búsqueda que envían referencias medibles.
Cloudflare debería preservar esas distinciones en lugar de condensar todo comportamiento en una única clasificación moral global. Una confianza específica por propósito ofrecería un control más útil que una puntuación combinada única.
La empresa también debe explicar la recuperación. Un operador de bots debería saber con qué rapidez un comportamiento corregido mejora su evaluación y si los incidentes históricos pierden peso con el tiempo.
De lo contrario, la rendición de cuentas continua puede convertirse en un castigo permanente con otro nombre. Eso contradice la descripción de Cloudflare de la confianza como algo que se construye mediante comportamientos repetidos.
Los informes públicos serán la prueba decisiva. Cloudflare dice que planea compartir puntuaciones mediante Radar, pero el anuncio no especifica la presentación ni las pruebas disponibles allí.
Un sistema público creíble debería distinguir las observaciones de las conclusiones. Debería mostrar los periodos relevantes, los niveles de confianza, las señales medidas y los cambios materiales en el comportamiento.
También debería etiquetar las atribuciones cuestionadas. La visibilidad de Cloudflare es amplia, pero la visibilidad no elimina la incertidumbre.
Lo que los propietarios de sitios web y operadores de bots deberían vigilar a continuación
La siguiente prueba será si Cloudflare convierte su principio de rendición de cuentas en un sistema operativo transparente y susceptible de impugnación.
La primera señal que debe vigilarse es el lanzamiento público de Radar. Cloudflare afirma que planea publicar información de confianza, haciendo visible la puntuación más allá de sus sistemas internos.
La cuestión útil no es si Radar añade otra insignia. Los lectores deberían examinar si cada banda de confianza incluye comportamientos específicos, periodos de tiempo y pruebas suficientes para explicar los cambios.
Los informes detallados reforzarían la afirmación central de Cloudflare. Una simple etiqueta la debilitaría al pedir al mercado que confíe en quien puntúa sin ver la lógica de puntuación.
La segunda señal es la disponibilidad para los clientes. Cloudflare planea permitir que los clientes elijan el umbral que determina cómo se gestiona el tráfico de Verified Bot.
Ese lanzamiento revelará si la confianza funciona como un campo informativo, una entrada para crear reglas o un mecanismo automático de aplicación. Esas opciones conllevan distintos riesgos operativos.
Un campo visible respalda la revisión humana, pero añade trabajo. La aplicación automatizada escala mejor, aunque los errores podrían bloquear la indexación de búsquedas, la monitorización, los servicios de accesibilidad o los agentes dirigidos por el usuario.
Los clientes también deberían vigilar cómo interactúa el sistema con las listas de permitidos existentes. Históricamente, los bots verificados han recibido un trato favorable porque Cloudflare ya los reconocía.
Un umbral dinámico de confianza puede limitar ese privilegio cuando cambia el comportamiento. También puede dificultar la gestión de políticas si los administradores asumen que “verificado” sigue significando seguro en todos los casos.
La tercera señal es la respuesta de los operadores. Los grandes proveedores de rastreadores pueden validar el modelo de Cloudflare adoptando identidades firmadas, separando propósitos y publicando prácticas de cumplimiento más claras.
También pueden cuestionar el modelo con evidencia técnica. Las disputas sobre la atribución de solicitudes, la interpretación de robots.txt y la gestión de límites de velocidad expondrán debilidades en la metodología.
Preste atención a la documentación que describa el comportamiento de espera progresiva tras respuestas 429. También busque identificadores separados que cubran la búsqueda, el entrenamiento y la recuperación dirigida por el usuario.
Estas prácticas reforzarían la idea de que la automatización responsable puede operar mediante estándares web compartidos. La ambigüedad continua reforzaría el argumento a favor de una aplicación más estricta a nivel de red.
Para los propietarios de sitios web, la rendición de cuentas continua de los bots verificados ofrece un modelo de confianza más realista que la verificación permanente. Reconoce que los cambios de software y los errores operativos ocurren después de la aprobación.
No debería reemplazar los controles directos. Los editores aún necesitan preferencias claras, límites de velocidad adecuados, registros de tráfico y reglas de aplicación alineadas con sus objetivos comerciales.
Para los desarrolladores de bots, el mensaje es igual de directo. La identidad criptográfica puede obtener reconocimiento, pero la conducta continua determina si ese reconocimiento sigue siendo útil.
Los equipos que crean agentes deberían tratar las políticas de acceso web como requisitos de producción. Deberían probar el análisis de robots.txt, respetar las restricciones de acceso, implementar una espera progresiva adaptativa y supervisar los cambios entre implementaciones.
Los desarrolladores también necesitan registros duraderos que expliquen por qué un agente accedió a un recurso. Esto se vuelve esencial cuando plataformas, editores e intermediarios discrepan sobre el propósito de una solicitud.
Los trabajadores del conocimiento afrontan una cuestión relacionada. Las respuestas generadas por agentes dependen cada vez más de sistemas de recuperación que operan fuera de la vista del usuario.
Una mejor capa de rendición de cuentas puede ayudar a los usuarios a entender si esos sistemas acceden a las fuentes de forma transparente. También puede revelar cuándo la conveniencia depende de comportamientos que los editores rechazaron explícitamente.
La web necesita ahora más que identificación de bots. Necesita una forma de conectar la identidad, el propósito declarado, la conducta observada y consecuencias proporcionales.
Cloudflare ha propuesto uno de esos sistemas, pero su legitimidad dependerá de las pruebas y el debido proceso. La empresa debe demostrar que las bandas de confianza son precisas, comprensibles y abiertas a corrección.
Durante los próximos meses, vigile las puntuaciones públicas, los controles para clientes y las respuestas de los operadores de rastreadores. En conjunto, mostrarán si la rendición de cuentas continua se convierte en un estándar compartido o en otra capa privada de control de acceso.
Los propietarios de sitios web deberían comparar las futuras calificaciones de Cloudflare con sus propios registros antes de automatizar la aplicación. Los operadores de bots deberían auditar ahora su respuesta tanto a robots.txt como a HTTP 429.
La cuestión central ya no es si un bot puede demostrar su identidad. Es si esa identidad sigue siendo responsable tras miles de solicitudes, políticas cambiantes e inevitables actualizaciones de software.
