Resumen

Pagaste por el modelo más caro del mercado. Lo cambiaste tres veces. Probaste el de un proveedor, luego el de otro, volviste al primero. Y tu agente sigue fallando de maneras que no puedes explicarle a tu comité de dirección: ejecuta una acción que no debía, pierde el hilo a mitad de una tarea, o funciona perfecto en la demo y se desmorona en producción.

El modelo, casi siempre, hizo exactamente lo que le pediste. El problema es que nadie diseñó lo que lo rodea. Esa capa —contexto, herramientas, memoria, orquestación, permisos, verificación y observabilidad— se ha consolidado como término de industria en 2025–2026: el harness. Y la tesis de este artículo es incómoda pero defendible: dado un modelo de frontera
suficientemente capaz, el harness es la variable dominante en un despliegue empresarial confiable. El modelo razona.

El harness responde por lo que ese razonamiento hace en tus sistemas.

Estructura del artículo

• El problema: por qué el mismo modelo rinde distinto
  Qué es el harness (y qué no es)
• Anatomía: los componentes de un harness
• El paisaje: implementaciones gestionadas (agnóstico de nube)
• Gobernanza: el harness como plano de control
• Qué queda cuando los modelos absorban el harness
• Un caso real + recomendación 3HTP

A quién va dirigido: CTOs, arquitectos de soluciones y líderes de plataforma que están llevando IA agéntica a producción —agentes con acceso de escritura a sistemas reales— y necesitan entender por qué sus agentes brillan en la demo y fallan en operación.

Prerrequisitos asumidos: familiaridad básica con agentes de IA (un modelo que decide qué herramientas usar, en qué orden y cuándo parar) y con conceptos de arquitectura de software.

 

El problema: el mismo modelo, resultados distintos

Durante tres años la conversación fue sobre el modelo. Más parámetros, más contexto, mejores benchmarks. Y es cierto que el modelo importa —importa muchísimo—: un modelo que resuelve el 10 % de las tareas de un benchmark de ingeniería y otro que resuelve el 50 % no son intercambiables, y ningún harness compensa esa diferencia de capacidad base.
Conviene decirlo de entrada, porque la tesis de este artículo no es “el modelo da igual”. Es otra: pasado cierto umbral de capacidad, lo que separa un agente que funciona en producción de uno que no, ya no es el modelo.

La evidencia de que el rendimiento de un agente es un fenómeno de sistema, no de modelo aislado, viene del propio equipo de ingeniería de Anthropic. Al analizar su sistema multiagente de investigación sobre la evaluación BrowseComp, documentaron que tres factores explicaban el 95 % de la varianza de rendimiento; el uso de tokens por sí solo explicaba el 80 % (Anthropic, 2025). Los tres factores eran: el número de tokens gastados, el número de llamadas a herramientas y la elección de modelo.

Léelo con cuidado, sin sobreinterpretar. La elección de modelo sí está en esa ecuación; es uno de los tres factores. Lo que el dato muestra no es que el modelo no importe, sino algo más preciso: el rendimiento del agente emerge del diseño del sistema completo. Anthropic lo atribuye a la arquitectura: repartir el trabajo entre agentes con contextos separados es lo que multiplica el gasto de tokens y, con él, la capacidad de razonamiento. Esas decisiones de reparto, orquestación y herramientas pertenecen al harness, no al modelo.

 

Qué es el harness (y qué no es)

Un harness es el conjunto de herramientas, contexto, memoria, permisos, bucles de
verificación y entorno de ejecución que envuelve a un modelo de lenguaje para convertirlo en un agente capaz de hacer trabajo real. No es el modelo. Es todo lo demás.

La formulación que ha adoptado la comunidad es una ecuación simple:

Agente = Modelo + Harness

Microsoft lo define como el “andamiaje de ejecución” que convierte un modelo en un agente que realiza trabajo: dirige las llamadas al modelo y a las herramientas, administra el estado y el contexto, aplica políticas de aprobación y mantiene el progreso en tareas de varios pasos (Microsoft, s. f.).

Hay un matiz de uso. Hugging Face distingue el harness, que es el bucle de ejecución que llama al modelo y gestiona sus herramientas, del scaffolding, que son las instrucciones, herramientas y formato con los que trabaja el modelo (Hugging Face, s. f.). Aquí usamos el término en sentido amplio, como lo hacen los productos que se presentan a sí mismos como harness.

La palabra no es casual. Harness viene de la equitación: las riendas, la silla, el bocado —el equipamiento que canaliza la fuerza de un animal poderoso pero impredecible en la dirección correcta. Si prefieres una imagen mecánica: el modelo es el motor; el harness es el resto del coche. El chasis, el volante, los frenos, el parabrisas, los testigos del tablero. Un motor de Fórmula 1 sin frenos no es rápido: es peligroso.
Qué NO es un harness. No es un prompt. Un prompt es una instrucción de texto; el harness es la infraestructura que permite al modelo actuar sobre esa instrucción. Tampoco es exactamente lo mismo que un framework o un runtime de agentes, y la distinción importa. Harrison Chase

(2025), de LangChain, propuso esta taxonomía, y reconoce que no fue él quien acuñó el término “harness”:

La idea de que esto es una disciplina, y no un término de moda, tiene respaldo académico creciente. El trabajo From Model Scaling to System Scaling (Gu, 2026) sostiene que el próximo cuello de botella de la IA agéntica no es escalar el modelo, sino escalar el harness: tratar la capa estructurada que rodea al modelo como un objeto de primera clase de diseño, evaluación y optimización. Grupos de Stanford (Meta-Harness) y de Google DeepMind (AutoHarness) publican métodos para buscar y sintetizar código de harness de forma automática (Lee et al., 2026; Lou et al., 2026).

Una forma útil de ubicar esta disciplina es verla como tres fases: prompt engineering (optimizar la instrucción) → context engineering (construir dinámicamente lo que el modelo ve) → harness engineering (diseñar el entorno completo donde el agente trabaja, con restricciones, verificaciones y bucles de mejora). Cada fase resuelve lo que la anterior no podía: un agente que ignora las dependencias entre módulos no deja de hacerlo con un mejor prompt; necesita una regla determinista que lo bloquee.

Por qué ahora

Tres señales convergen para que esto deje de ser un debate de laboratorio.
Las tareas autónomas se alargan. METR documentó que la duración de las tareas que los agentes de frontera completan con 50 % de fiabilidad se duplica aproximadamente cada 7 meses (METR, 2025). Ese cálculo se publicó en marzo de 2025, con datos hasta esa fecha.
Anthropic, por su parte, midió que entre octubre de 2025 y enero de 2026 el percentil 99,9 de la duración de los turnos de Claude Code pasó de menos de 25 minutos a más de 45 minutos (Anthropic, 2026). Cuanto más larga la tarea autónoma, más depende el resultado de que el sistema sostenga ejecución, memoria y recuperación: es decir, del harness.

Los agentes se multiplican. Gartner proyecta que una empresa global promedio del Fortune 500 tendrá en uso más de 150.000 agentes para 2028, frente a menos de 15 en 2025. Gartner lo
llama agent sprawl (Gartner, 2026). Gobernar esa cantidad de agentes sin una capa común de control, permisos y observabilidad no es un problema de modelo. Es un problema de harness.

Y cuando el harness falta, se rompe algo real. En 2026 se registró el CVE-2026-27966 sobre el componente CSV Agent de Langflow. El código tenía hardcodeada una herramienta de ejecución de código (allow_dangerous_code=True), lo que exponía automáticamente un intérprete de Python. Una inyección de prompt podía entonces encadenarse hasta ejecución remota de comandos en el servidor. El aviso de seguridad (GitHub, s. f.) indica que no existía
ninguna opción de configuración para desactivar ese comportamiento. El matiz es
exactamente el punto de este artículo: el modelo no falló. El modelo ejecutó precisamente lo que el harness le permitía hacer. Fallaron dos capas a la vez: la de permisos (una herramienta de altísimo riesgo quedó habilitada por defecto, sin forma de desactivarla) y la de aislamiento (el código se ejecutaba directamente en el servidor, sin un entorno que lo contuviera). No fue un fallo de inteligencia; fue un fallo de andamiaje.

Anatomía de un harness

Si abstraemos lo que comparten los harnesses de la industria, emergen ocho componentes. Piénsalos como una lista de verificación, no como una especificación cerrada: un agente pequeño necesita pocos; uno de producción, casi todos.

1. Contexto. Qué ve el modelo. Selección, compactación y ensamblado de la información
relevante. Regla de oro: si no está en el contexto, para el modelo no existe. Meter todo el
código de golpe no ayuda —degrada la precisión—; la habilidad está en darle las
herramientas para que encuentre lo que necesita.
2. Herramientas. Cómo el agente actúa sobre el mundo: leer y escribir archivos, consultar
bases de datos, llamar APIs, ejecutar código. El estándar emergente de integración es MCP
(Model Context Protocol), que permite conectar servidores de herramientas sin
integraciones a medida.
3. Memoria y estado. Qué recuerda entre pasos y entre sesiones. Historial, resúmenes, listas de
tareas, preferencias persistidas.
4. Orquestación y bucle de control. Planificación, descomposición en subtareas, decisión de
cuándo parar, manejo de errores, coordinación de subagentes.
5. Entorno de ejecución y aislamiento. Dónde corre y actúa el agente: un sandbox, una microVM, un contenedor efímero. La segunda línea de defensa ausente en el caso Langflow: un sandbox habría contenido el daño aunque la herramienta peligrosa estuviera habilitada.
6. Guardrails y permisos. Las reglas: validación de entradas, validación de salidas,
autorización por acción, aprobación humana para lo irreversible, y la identidad del agente (qué credenciales porta, cómo se autentica ante otros sistemas, cómo se le atribuyen sus acciones). Conviene no colapsar estas sub-capas: proteger solo la entrada deja la salida expuesta, y una herramienta de alto riesgo habilitada por defecto —como en el caso Langflow— es un fallo de esta capa, el de permisos.         7. Verificación. Comprobar la calidad del trabajo antes de aceptarlo. Es la diferencia entre “el agente casi siempre pasa el linter” y “el agente siempre pasa el linter”.
8. Observabilidad y trazabilidad. Cuando una tarea de cincuenta pasos falla en el paso 37, una traza te dice qué pasó. Registra llamadas, herramientas, errores, latencia y coste.

Para el lector CTO: mapea tus agentes contra estos ocho componentes. El que esté vacío es, con alta probabilidad, tu próximo punto de falla.

 

El paisaje: harnesses gestionados

Lo bueno de que el harness sea un patrón reconocible es que ya no hay que construirlo entero a mano. Las principales plataformas ofrecen harnesses gestionados que implementan buena parte de los ocho componentes. Los presentamos lado a lado, sin preferencia de proveedor:

Nota. Descripciones basadas en la documentación oficial de cada proveedor (Amazon Web Services, s. f.; Anthropic, s. f.; LangChain, s. f.; Microsoft, s. f.).
El patrón es el mismo en todas; cambian los detalles de implementación y el ecosistema. Elegir un harness empieza a ser una decisión tan importante como —y separada de— elegir el modelo.

Gobernanza: el harness como plano de control

Aquí es donde el harness deja de ser una conveniencia de ingeniería y se vuelve el plano de control de la seguridad y la gobernanza de tus agentes. Es, además, donde se materializan tres discusiones que ya hemos abordado en esta serie —esta vez de forma deliberadamente agnóstica de nube, porque los principios del harness preceden a la elección de plataforma—:

• La autonomía graduada por acción (de copiloto a operador): decidir qué puede ejecutar el agente solo y qué requiere aprobación humana se implementa en el harness —en la capa de guardrails y permisos—, no en el modelo.
• La defensa contra prompt injection: el interceptor que evalúa el contenido antes de que el modelo lo procese es un componente del harness.
• La seguridad de agentes en general (identidad, mínimo privilegio, aislamiento): son capas del harness, no propiedades del modelo.

Nota. Esquema conceptual; no describe un producto específico. Elaboración propia.

Y aquí un matiz que un arquitecto no debe pasar por alto, y que la propia documentación de AWS hace explícito para AgentCore (Amazon Web Services, s. f.): el harness valida la estructura de la petición, pero no inspecciona el significado de los prompts ni impone restricciones de conducta al agente. En otras palabras: la plataforma te da fronteras, no te exime de diseñar la seguridad. La validación de entradas y la autorización del llamador siguen siendo tu responsabilidad.

La buena noticia es que la industria converge en cómo estructurar esos controles. Un patrón robusto es la verificación en capas, donde cada capa atrapa el error más barato posible antes de que escale :

FIGURA 2
Verificación en capas: cada nivel atrapa errores a un costo mayor

Nota: la altura de las barras y los tiempos son ilustrativos, no mediciones.
Fuente: elaboración propia.

Cuanto antes se detecta el error, más barato es corregirlo, y menos depende de la buena voluntad del modelo. Marcos de referencia distintos piden controles con lógica parecida. El Well-Architected Agentic AI Lens de AWS (Amazon Web Services, s. f.) está organizado por los seis pilares del framework, y el OWASP AISVS define requisitos verificables de seguridad para sistemas de IA (OWASP Foundation, s. f.). Que lleguen a principios similares es una señal de consenso, no de moda.

 

Lo incómodo: ¿qué queda cuando los modelos absorban
el harness?

Un lector honesto hará la pregunta difícil: si los modelos de frontera están absorbiendo capas del harness —tool use nativo, memoria integrada, contextos de un millón de tokens—, ¿no envejecerá mal todo esto?

Es una objeción válida y hay que responderla de frente. La dirección de la industria, en efecto, es que los modelos integren progresivamente capacidades que antes vivían en el harness. Hace pocos años, la recuperación de documentos (RAG) y la memoria se construían siempre fuera del modelo; hoy algunas plataformas y modelos las ofrecen de serie.

Conviene entonces distinguir dos cosas:

• El harness como producto (un tooling concreto) — sí, es parcialmente absorbible. Partes de
  él migrarán al modelo o a la plataforma. Apostar a que tu tooling específico sea tu ventaja 3HTP Cloud Services · Tu agente falla. Y no es culpa del modelo. 9
  permanente es frágil.
• El harness como disciplina (diseñar contexto, verificación, permisos y gobernanza para un propósito y un dominio concretos) — eso no lo absorbe ningún modelo.

La formulación honesta, por tanto, no es “el harness es la ventaja para siempre”. Es: en la ventana 2024–2027, mientras los modelos aún no absorben estas capas, el harness es donde se gana o se pierde la confiabilidad en producción. Y lo más importante: la disciplina de diseñar harnesses no desaparece cuando el modelo absorba las herramientas; migra hacia arriba en la pila.

Un modelo podrá traer memoria, recuperación y ejecución de serie; nunca traerá de
fábrica el criterio de qué es irreversible en tu negocio, qué datos no pueden cruzarse entre tus clientes, ni qué significa “aprobación” en tu organización. Eso siempre habrá que diseñarlo.

Un caso real: nuestro propio harness (y la cicatriz que lo
formó)

Lo justo, después de todo lo anterior, es mostrar un harness real en lugar de describirlo en abstracto. Usamos el nuestro —el framework de desarrollo con el que 3HTP opera sus propios proyectos— no como “el harness ideal”, sino como un ejemplo de cómo estos principios se encarnan. Y empezamos por una cicatriz, porque un caso sin fallo no enseña nada.

La cicatriz. En una de sus primeras versiones, la capa de conocimiento del framework —la memoria que evita que el agente redescubra lo que ya sabe— se guardó entera en un directorio local no versionado. El resultado: cada miembro del equipo acumulaba memoria en su propia máquina, rompiendo justo el propósito de tener memoria de equipo.

No fue un fallo del modelo; fue un fallo de diseño del harness. Se corrigió separando el conocimiento compartido (versionado, revisable por pull request) de los índices regenerables (locales), y quedó registrado como decisión de arquitectura. El harness, literalmente, aprendió de su propio error, que es exactamente la definición de harness engineering: cada vez que algo falla, rediseñas para que no vuelva a pasar.

La anatomía, en cinco capas. El framework implementa los ocho componentes en cinco capas, y es multi-plataforma por diseño —una sola fuente que se construye para distintos entornos de agente—, lo que demuestra en la práctica que un harness bien diseñado no tiene por qué casarse con un solo proveedor:

Componentes del harness frente a capas del framework 3HTP

Seis de los ocho componentes del harness tienen capa propia en el framework

Nota. Elaboración propia a partir de la estructura de capas del framework.

Un ejemplo concreto de verificación en capas: la revisión de código del framework separa a quien encuentra un hallazgo de seguridad de quien lo aprueba. Cada hallazgo bloqueante pasa por un verificador independiente, con contexto fresco, cuyo único trabajo es intentar refutarlo. Ese patrón reduce el riesgo de aprobar hallazgos falsos por inercia. Es verificación como componente de primera clase del harness, no como paso opcional.

Honestidad de alcance. Este es el harness de trabajo de una consultora, no una plataforma de hiperescala; su valor como caso está en el diseño, no en un volumen que no vamos a inflar. Y hay componentes que delega deliberadamente a la plataforma anfitriona (el aislamiento de ejecución, por ejemplo, lo provee el entorno donde corre). Un mapeo perfecto sin huecos sería sospechoso; este los tiene y los declara.

Conclusión

El modelo es una pieza extraordinaria, y sí, elegir uno capaz es la condición de entrada. Pero el modelo razona; el harness es quien responde por lo que ese razonamiento hace en tus sistemas. 

Es la capa que decide qué ve el agente, qué puede tocar, qué recuerda, dónde se
ejecuta y cómo se le verifica. A medida que las tareas se alargan y los agentes se multiplican, esa capa deja de ser un detalle de implementación y pasa a ser la superficie primaria de control, seguridad y confiabilidad.

Antes de escalar tu stack de agentes, haz un ejercicio simple: mapea tus agentes contra los ocho componentes del harness. El que esté vacío es tu próximo incidente.

Diseñar y operar harnesses confiables —agnósticos de modelo, plataforma y nube— es nuestro oficio en 3HTP. Contáctenos para una sesión de arquitectura sin costo 

y evaluemos juntos la madurez del harness de sus agentes, componente por componente, antes de llevarlos a producción.

 

Sobre el autor

Sebastian De La Vega es Cloud Engineer en 3HTP Cloud Services. Tiene la certificación AWS Certified Solutions Architect y formación fundamental en Anthropic. Lidera iniciativas de inteligencia artificial y diseñó el framework de desarrollo de 3HTP, el harness con el que la organización opera sus propios proyectos y que sirve de caso en este artículo.
Escribe para cerrar la brecha entre la velocidad con que los equipos adoptan agentes y las prácticas que deberían acompañarlos. Contacto: LinkedIn.

Referencias

Amazon Web Services. (s. f.). AWS Well-Architected Agentic AI Lens.
https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentic-ai-lens.html
Amazon Web Services. (s. f.). Security and access controls: Amazon Bedrock AgentCore harness.

Documentación de AWS. https://docs.aws.amazon.com/bedrock-
agentcore/latest/devguide/harness-security.html

Anthropic. (s. f.). Agent SDK overview. Claude Code Docs. https://code.claude.com/docs/en/agent-
sdk/overview

3HTP Cloud Services · Tu agente falla. Y no es culpa del modelo. 12
Anthropic. (s. f.). Claude Managed Agents overview. Claude Platform Docs.
https://platform.claude.com/docs/en/managed-agents/overview
Anthropic. (2025). How we built our multi-agent research system. Anthropic Engineering.
https://www.anthropic.com/engineering/multi-agent-research-system
Anthropic. (2026). Measuring AI agent autonomy in practice.
https://www.anthropic.com/news/measuring-agent-autonomy
Chase, H. (2025). Agent frameworks, runtimes, and harnesses: Oh my! LangChain Blog.
https://www.langchain.com/blog/agent-frameworks-runtimes-and-harnesses-oh-my
Gartner. (2026). Gartner identifies six steps to manage AI agent sprawl [Comunicado de prensa].

https://www.gartner.com/en/newsroom/press-releases/2026-04-28-gartner-identifies-six-steps-to-
manage-artificial-intelligence-agent-sprawl

GitHub. (s. f.). Langflow has remote code execution in CSV Agent (CVE-2026-27966; GHSA-3645-fxcv-hqr4)
[Aviso de seguridad]. GitHub Advisory Database. https://github.com/advisories/GHSA-3645-fxcv-hqr4
Gu, S. (2026). From model scaling to system scaling: Scaling the harness in agentic AI (arXiv:2605.26112).
arXiv. https://doi.org/10.48550/arXiv.2605.26112
Hugging Face. (s. f.). Harness, scaffold, and the AI agent terms worth getting right. Hugging Face Blog.
https://huggingface.co/blog/agent-glossary
LangChain. (s. f.). Deep Agents overview. LangChain Docs.
https://docs.langchain.com/oss/python/deepagents/overview
Lee, Y., et al. (2026). Meta-Harness: End-to-end optimization of model harnesses (arXiv:2603.28052). arXiv.
https://doi.org/10.48550/arXiv.2603.28052
Lou, X., et al. (2026). AutoHarness: Improving LLM agents by automatically synthesizing a code harness
(arXiv:2603.03329). arXiv. https://doi.org/10.48550/arXiv.2603.03329
METR. (2025). Measuring AI ability to complete long software tasks. https://metr.org/blog/2025-03-19-
measuring-ai-ability-to-complete-long-tasks/

Microsoft. (s. f.). Agent harness. Microsoft Learn. https://learn.microsoft.com/en-us/agent-
framework/concepts/harness

OWASP Foundation. (s. f.). Artificial Intelligence Security Verification Standard (AISVS).
https://owasp.org/www-project-artificial-intelligence-security-verification-standard-aisvs-docs/

 

 

Durante el análisis de logs de acceso de un sistema de recuperación de información documental desplegado sobre AWS, se identificó un patrón de saturación que no correspondía a ningún vector de ataque conocido. El servidor registraba alarmas de CPU en CloudWatch, los usuarios reportaban lentitud y, sin embargo, la revisión del Web ACL de WAF no mostraba bloqueos relevantes, patrones de ataque ni IPs marcadas como maliciosas. El tráfico era, desde todos los ángulos de la seguridad convencional, completamente válido La apertura de los logs de

Apache reveló lo siguiente:

 

En treinta y cuatro segundos, el agente meta-webindexer ejecutó más de 25 búsquedas con parámetros únicos desde múltiples rangos de IP. En ese mismo intervalo, un operador humano catalogaba registros desde Chrome en la misma instancia, sin ningún mecanismo de diferenciación de prioridad entre ambos flujos.

Este artículo examina ese patrón: un agente legítimo que genera carga computacional equivalente a un ataque volumétrico, que los sistemas de defensa convencionales en AWS no pueden mitigar sin incurrir en un costo de negocio, y para el que el ecosistema recién comienza a construir respuestas.

 

1. El contexto: los números ya no son abstractos

Los logs descritos no son una anomalía. Son consistentes con una tendencia documentada por múltiples fuentes de infraestructura.

En 2024, el tráfico automatizado superó por primera vez en una década el 51% del tráfico web global, según el Bad Bot Report 2025 de Imperva . En 2025, ese porcentaje subió al 53% . En junio de 2026, Cloudflare Radar registró 57.4% de tráfico automatizado en su red, un cruce que el CEO de la compañía describió como ocurrido “años antes de lo esperado” .

Dentro de ese volumen, los crawlers de IA muestran el crecimiento más acelerado. Según datos de su propia red (que cubre aproximadamente una quinta parte de los sitios de internet), Cloudflare reportó que GPTBot aumentó un 305% su actividad entre mayo de 2024 y mayo de 2025 . Meta-WebIndexer generó 9,100 millones de solicitudes en Q2 2026, más de la mitad de los 17,700 millones de AI agent requests totales observados en la red de DataDome durante ese trimestre. DataDome es una firma de detección de bots con interés comercial en visibilizar el problema, lo que debe considerarse al interpretar la cifra . PromptWatch reporta que Meta-WebIndexer pasó de representar el 2.2% al 37.8% del tráfico de AI crawlers en su panel en menos de treinta días. Dado lo extraordinario del incremento, y dado que PromptWatch no publica metodología ni tamaño de muestra, el dato se presenta como indicador de tendencia, no como medición verificable .

El administrador de kernel.org publicó en agosto de 2026 un análisis técnico de su propia infraestructura: de 90 CPUs distribuidos en cinco nodos, entre 14 y 16 se dedicaban de forma permanente a servir páginas a AI scrapers, más que todos los git clones y la navegación legítima combinados . Se trata de un caso único, pero la fuente es el administrador de un repositorio de referencia global y el relato es técnicamente verificable.

La consistencia de dirección entre fuentes de distintos niveles de rigor sugiere que el fenómeno es real, aunque la magnitud exacta varíe según quién lo mida.

2. Por qué esto no es un DDoS, y por qué esa diferencia es el problema

La confusión entre este patrón y un ataque de denegación de servicio distribuido (DDoS) es frecuente porque los síntomas observables a nivel de métricas son los mismos: CPU elevada, latencia alta, instancias bajo presión. La causa estructural, sin embargo, es radicalmente diferente.

Tabla 1. Comparación entre ataques DDoS volumétricos y el patrón descrito

La distinción central está en la última fila. AWS WAF Bot Control identifica correctamente a meta-webindexer mediante análisis estático del User-Agent. Lo clasifica como bot de categoría social media o content fetcher y aplica los labels correspondientes. El problema no es la detección. El problema es que las acciones disponibles tras esa identificación son bloquear o permitir, y ninguna de las dos resuelve la tensión de capacidad:

• • Bloquear elimina la presencia del sistema en Meta AI Search. Para sistemas cuyo modelo de valor depende de ser descubiertos, ese costo puede superar al de infraestructura.
  • Permitir implica que cada solicitud consume los mismos recursos computacionales que una consulta de usuario real, sin ningún mecanismo de diferenciación de prioridad.

No existe en el modelo de WAF una acción que redirija el tráfico del bot hacia una capa de caché de forma automática e integrada con CloudFront. WAF sí permite configurar respuestas personalizadas en acciones Block: se puede devolver un 429 con Retry-After para señalar throttling, o un 302 con header Location apuntando a otra URL. Sin embargo, estas respuestas las recibe el bot cliente, no CloudFront: WAF termina la conexión y le indica al bot que vaya a otra URL, pero no enruta la solicitud internamente hacia CloudFront ni hacia un origen alternativo. Para que el bot sea servido desde caché sin que tenga que hacer una segunda solicitud, la integración con CloudFront requiere lógica adicional fuera de WAF.

Adicionalmente, la indiferenciación semántica a nivel de procesamiento produce una categoría de problema que los marcos convencionales de gestión de amenazas no contemplan, precisamente porque el agente no actúa como amenaza.

3. Por qué el escalamiento reactivo amplifica el problema

La respuesta operacional más común ante saturación en AWS es el escalamiento. El auto-scaling de EC2 responde al incremento de métricas capturadas por CloudWatch: CPU, tasa de solicitudes, latencia. Cuando la carga sube, se levantan instancias adicionales.

El problema es que el auto-scaling no distingue la fuente de esa carga. Cuando un agente de indexación genera la mayor parte del tráfico, el escalamiento asigna capacidad adicional a servirlo. El tráfico de usuarios reales sigue compitiendo con el bot por los mismos recursos, ahora en más instancias. El costo operacional aumenta sin que la experiencia del usuario mejore.

Existe una razón estructural por la que esto ocurre: los labels aplicados por WAF a las solicitudes no se propagan como señales a CloudWatch ni a las políticas de auto-scaling. WAF puede etiquetar una solicitud como awswaf:managed:aws:bot-control:bot:category:social_media, pero esa etiqueta no existe para el sistema de escalamiento. CloudWatch observa CPU alta y auto-scaling escala, sin importar quién generó la carga.

4. La paradoja de la indexabilidad

El problema adquiere su dimensión más difícil en sistemas cuyo contenido depende de ser accesible públicamente: catálogos, repositorios, plataformas de ecommerce con productos indexados, bases de conocimiento abiertas. En estos casos, la indexabilidad por parte de los crawlers de IA no es optativa sino constitutiva del valor del sistema.

Wix reportó en junio de 2026 que las plataformas de IA ya generaban tráfico de referencia hacia cerca de 700,000 de sus sitios cada mes, con 2.2 millones de sesiones solo en marzo, aunque ese tráfico seguía representando menos del 1% del total de visitas a esos sitios . Cloudflare reporta que menos del 1% de los sitios en su red bloquea los bots de búsqueda de IA, frente a un 17% que ya restringe el tráfico de entrenamiento . Esa asimetría es consistente con una lectura operacional: el costo de la invisibilidad en el ecosistema de IA supera, para la mayoría de los operadores, el costo de la carga de infraestructura.

La paradoja se puede expresar de forma directa: bloquear el crawler resuelve el problema de capacidad a expensas de la visibilidad; permitirlo mantiene la visibilidad a expensas de la capacidad. La arquitectura de AWS ofrece una salida parcial a esta tensión mediante la combinación de WAF, CloudFront y CloudFront Functions, pero requiere implementación explícita. No existe una configuración nativa que lo resuelva de forma automática. AWS ha reconocido parcialmente esta brecha con el lanzamiento de AI Traffic Monetization en junio de 2026 y con los dashboards de tráfico de IA para WAF, aunque ninguno de esos mecanismos resuelve la priorización de cómputo entre usuarios y bots.

Un segundo efecto agrava la situación. Cuando se intenta controlar el tráfico de bots endureciendo las reglas de WAF (por ejemplo, activando la regla NoUserAgent_HEADER del Common Rule Set para bloquear requests sin User-Agent), se corre el riesgo de afectar integraciones legítimas. Las APIs server-to-server, los webhooks de pasarelas de pago y los callbacks de servicios externos frecuentemente omiten el header User-Agent, un comportamiento protocolariamente correcto que esa regla penaliza. En el entorno analizado, al pasar esa regla de COUNT a BLOCK, se bloquearon los webhooks de una pasarela de pago durante cuatro minutos. La documentación de AWS advierte que cambios en patrones de tráfico pueden aumentar la tasa de falsos positivos incluso en reglas con historial de baja incidencia .

5. Por qué algunos sistemas sienten el impacto más que otros

No todos los sistemas son igualmente susceptibles. La magnitud del impacto de un AI crawler sobre un servidor depende en buena medida de las características arquitectónicas de la aplicación, no solo de su popularidad.

Un blog estático y un sistema de recuperación de información con búsqueda facetada pueden tener volúmenes de tráfico humano similares, pero el costo computacional de cada solicitud de un crawler es radicalmente diferente entre ambos.

Cuando el bot accede a una página estática:

 

El servidor devuelve un archivo HTML. CloudFront puede servir esa respuesta desde caché indefinidamente: el origen no recibe el request.

Cuando accede a un sistema con búsqueda facetada:

 

El servidor ejecuta una consulta contra la base de datos con joins, filtros combinados, ordenamiento y paginación. El costo computacional es equivalente al de una búsqueda ejecutada por un usuario real.

5.1 Por qué el tipo de arquitectura importa

La observación de campo lleva a una pregunta directa: ¿todos los sistemas sienten el mismo nivel de impacto de un AI crawler, o hay algo en el diseño de ciertos sistemas que los hace más vulnerables?

La evidencia disponible apunta hacia el segundo caso. No es que los sistemas de búsqueda facetada sean más populares o tengan más contenido. Es que el costo computacional de cada solicitud del bot es estructuralmente diferente: cuando el agente llega a un sistema con búsqueda por filtros combinados, cada request obliga al servidor a ejecutar una consulta real contra la base de datos. No hay forma de responder desde memoria o desde un archivo ya generado.

Esta observación es consistente con evidencia documentada de forma independiente, antes de la publicación de este análisis: COAR (2025) reportó acceso de bots las 24 horas en sus repositorios de acceso abierto , Library Journal (2025) documentó caídas e interrupciones específicamente en sistemas de este tipo , y el proyecto DSpace tiene un issue activo desde 2025 donde sus usuarios documentan que, al intentar bloquear bots agresivos, terminan bloqueando accidentalmente a Google Scholar . Esa observación ilustra el problema: el diseño del sistema dificulta distinguir un crawler legítimo de uno que satura, porque ambos consultan el mismo endpoint con los mismos parámetros.

Lo que este análisis agrega es una explicación técnica de por qué ocurre, y una clasificación provisional de qué tipos de arquitectura tienen mayor probabilidad de experimentarlo. Esa clasificación no está validada con mediciones comparadas entre tipos: es un marco para orientar el diagnóstico, no una taxonomía empírica, y queda abierta a revisión con datos adicionales.

5.2 Factores propuestos como amplificadores

Se proponen cuatro factores que, en combinación, amplificarían la vulnerabilidad. Los factores 1 y 4 están documentados directamente en los logs; los factores 2 y 3 se derivan del análisis técnico de la arquitectura.

Factor 1. Búsqueda facetada con parámetros en la URL

Cada combinación de filtros genera una URL única que activa una consulta independiente contra la base de datos. En los logs analizados, las solicitudes del agente incluían hasta seis parámetros de filtrado simultáneos: categoría temática, autoría, colección, sucursal, disponibilidad y serie documental.

Factor 2. Espacio combinatorio de URLs

Con cuatro o más dimensiones de filtrado independientes, el número de combinaciones válidas crece factorialmente. Una estrategia de caché basada en URL completa tiene una tasa de aciertos estructuralmente baja ante ese espacio de variación.

Factor 3. Ausencia de Cache-Control apropiado para contenido de búsqueda (análisis técnico)

Si la aplicación no emite headers Cache-Control con TTL positivo para sus resultados de búsqueda, CloudFront trata ese contenido como dinámico no cacheable y pasa cada solicitud al origen. En sistemas que priorizan la actualización inmediata del catálogo, esta es la configuración habitual.

Factor 4. Endpoints de descubrimiento automático (observado en logs)

El agente consultaba feeds RSS y descriptores OpenSearch expuestos por la aplicación:

 

Un feed RSS de una búsqueda devuelve un listado de registros con sus URLs, lo que multiplica la superficie de rastreo a partir de un número reducido de solicitudes iniciales.

5.3 Marco analítico provisional por tipo de sistema

La tabla siguiente es una hipótesis de trabajo, no una taxonomía empírica. El único tipo con evidencia directa de logs en este análisis es el de sistemas de recuperación de información; la extrapolación a los demás tipos es analítica y se ofrece como punto de partida para discusión, no como conclusión cerrada.

6. AWS WAF bajo la lupa: una revisión mecanismo por mecanismo

Esta sección examina AWS WAF desde cada ángulo relevante para el problema: dónde se posiciona en la red, cómo evalúa cada solicitud, qué puede detectar, qué acciones tiene disponibles contra un bot ya identificado, y dónde termina su alcance. El objetivo no es describir WAF en general, sino recorrer mecanismo por mecanismo (posición en la red, pipeline de evaluación, Bot Control, rate limiting, las funciones más recientes) para precisar, en cada uno, qué resuelve y qué no. La brecha que aparece al final no es un defecto de configuración: es un límite del paradigma bajo el cual la herramienta fue diseñada, y solo se vuelve visible al revisarla pieza por pieza.

6.1 La posición de WAF en la pila de red

AWS WAF no es un servidor independiente sino un motor de evaluación de reglas que se inserta como capa de inspección entre internet y el recurso protegido. Los recursos que puede proteger son: Application Load Balancer (ALB), distribuciones de Amazon CloudFront, Amazon API Gateway, AWS AppSync, Amazon Cognito user pools, AWS App Runner y AWS Verified Access.

El scope de asociación determina dónde en la red actúa la inspección:

Un WAF REGIONAL asociado a un ALB no inspecciona la solicitud hasta que esta ya cruzó internet y llegó a la región AWS. En el momento del bloqueo, el ancho de banda entrante ya fue consumido. Un WAF CLOUDFRONT actúa en el edge, antes de que la solicitud atraviese hacia la región, lo que lo hace más eficiente para el problema de AI crawlers.

6.2 El motor de evaluación: pipeline de procesamiento

Cada solicitud que llega al recurso protegido se somete al siguiente pipeline de evaluación secuencial:

 

BLOCK y ALLOW son acciones terminantes: detienen la evaluación inmediatamente. Si la regla de prioridad 0 hace match con BLOCK, las reglas 1, 2, 3… nunca se evalúan. COUNT es no terminante: registra el match, aplica etiquetas (labels) a la solicitud y continúa evaluando el resto del Web ACL.

Los labels son el mecanismo de comunicación entre reglas. Una regla puede etiquetar una solicitud sin bloquearla, y reglas posteriores pueden condicionar su comportamiento según esos labels:

 

 

Este patrón label-acción condicional es la base para cualquier control sofisticado de AI crawlers dentro de WAF.

6.3 Los componentes inspeccionables de cada solicitud

WAF tiene acceso a los siguientes elementos de la solicitud HTTP/HTTPS para definir condiciones de match:

 

El JA3 Fingerprint merece atención especial. Es un hash derivado de los parámetros del TLS Client Hello: versión TLS, cipher suites, extensiones, curvas elípticas y formatos de punto. A diferencia del User-Agent, que cualquier bot puede falsificar de forma trivial, el JA3 fingerprint refleja la implementación TLS del cliente y es significativamente más costoso de modificar. CloudFront lo expone mediante el header CloudFront-Viewer-JA3-Fingerprint. Para AI crawlers declarados como meta-webindexer, sin embargo, el JA3 no añade valor diferencial: el bot ya se identifica voluntariamente.

6.4 Bot Control Common: funcionamiento interno

Bot Control es un Managed Rule Group, una colección de reglas preconfiguradas y mantenidas por AWS que se agrega al Web ACL como una unidad. El nivel Common realiza análisis estático de cada solicitud de forma independiente: no analiza sesiones ni correlaciona solicitudes en el tiempo. Por cada request:

1. Compara el User-Agent contra una base de datos de bots conocidos. meta-webindexer, GPTBot, ClaudeBot, SemrushBot, Googlebot y Bingbot están catalogados.
2. Aplica expresiones regulares para detectar firmas de herramientas (python-requests, curl, wget, scrapy).
3. Verifica la ausencia de headers que los navegadores siempre incluyen (Accept-Language, Accept-Encoding).
4. Para bots verificables (Googlebot, Bingbot), realiza verificación DNS inversa de la IP de origen.

El resultado son labels con el esquema awswaf:managed:aws:bot-control:<tipo>:<subtipo>:

 

Comportamiento por defecto: los bots verificados por DNS (Googlebot, Bingbot) reciben acción ALLOW; los labels se aplican, pero el bot pasa. Los bots no verificables reciben acción BLOCK en la regla específica, aunque el operador puede sobrescribirla a COUNT.

Una observación operacional recurrente: muchos equipos configuran Bot Control en modo COUNT durante la fase inicial para evitar interrupciones, monitorean el tráfico identificado, y no completan la transición a BLOCK porque el bot no activa alertas de seguridad evidentes. El costo computacional del bot no es visible en las métricas del Web ACL; solo aparece en la CPU de la instancia.

 

6.5 Bot Control Targeted: para qué sirve y para qué no

El nivel Targeted agrega desafíos JavaScript silenciosos a los requests. El flujo es el siguiente: WAF devuelve JavaScript que el cliente debe ejecutar, el script genera un token criptográfico, y las solicitudes posteriores deben incluirlo.

Es efectivo contra bots que no ejecutan JavaScript. Resulta inadecuado para el problema descrito en este artículo: meta-webindexer no intenta parecerse a un humano, se declara abiertamente. Aplicar desafíos JavaScript a un bot que ya se identificó genera latencia y falsos positivos sin ningún beneficio para la gestión de capacidad .

 

6.6 WBA: verificación criptográfica de identidad

Web Bot Authentication (WBA), disponible en Bot Control desde noviembre de 2025, implementa verificación criptográfica basada en criptografía asimétrica, siguiendo dos borradores activos del IETF . Está disponible únicamente para WAF en scope CLOUDFRONT: no aplica si el WAF protege un ALB en scope REGIONAL, la configuración más común en arquitecturas que no usan CloudFront como entrada.

El flujo es el siguiente:

Nota: El nombre de los headers del diagrama anteriór son referenciales

WBA resuelve la suplantación de identidad: no es posible falsificar ser meta-webindexer si la solicitud no está firmada con la clave privada de Meta. No resuelve el problema de capacidad: un bot verificado criptográficamente que genera 50,000 búsquedas facetadas por hora sigue generando 50,000 búsquedas facetadas por hora. La adopción de WBA está en etapas iniciales y no todos los crawlers de IA lo han implementado.

6.7 Las reglas del Common Rule Set relevantes para este problema

El AWSManagedRulesCommonRuleSet (CRS) contiene reglas cuya interacción con el problema de AI crawlers merece análisis específico:

La regla NoUserAgent_HEADER es la fuente más frecuente de falsos positivos en entornos con integraciones externas. Este fue el mecanismo del incidente documentado en la sección 4: al pasar esa regla de COUNT a BLOCK, se bloquearon los webhooks de una pasarela de pago que operaba sin User-Agent, un comportamiento protocolariamente correcto en comunicaciones server-to-server.

6.8 Rate-Based Rules con LABEL_NAMESPACE

Las reglas de limitación de tasa son la herramienta más cercana a un control de capacidad dentro de WAF. Hay varios criterios de agregación disponibles:

La combinación LABEL_NAMESPACE con labels de Bot Control permite expresar lógica del tipo:

“Si la solicitud tiene label bot:category:social_media y la URI contiene /search, bloquea si supera 100 solicitudes por minuto.”

Dos limitaciones no son superables dentro de WAF:

Primera: el rate limiting no redirige hacia caché de forma integrada. Cuando se supera el umbral, la acción disponible es bloquear la solicitud con una respuesta personalizada. WAF admite devolver un 429 con Retry-After o un 302 con Location apuntando a una URL alternativa, lo cual resulta útil para señalar throttling a un bot que respeta esas señales. Sin embargo, esa respuesta la recibe el cliente bot: WAF termina la conexión y le indica a dónde ir. No existe un mecanismo nativo que dirija la solicitud internamente hacia una respuesta cacheada en CloudFront sin que el bot tenga que hacer una segunda solicitud. Ese comportamiento requiere lógica adicional fuera de WAF, descrita en la sección de soluciones.

Segunda: los crawlers rotan IPs. Meta publica sus rangos de origen a través del registro de rutas RADb bajo el AS32934, que incluye bloques IPv6 amplios dentro de 2a03:2880::/32; la propia documentación de Meta advierte que esas direcciones cambian con frecuencia. Cloudflare Community documenta que el rate limiting basado en IP resulta “mostly ineffective” contra este agente precisamente por esa razón . LABEL_NAMESPACE mitiga este problema porque el label se deriva del User-Agent, no de la IP de origen.

 

6.9 El paradigma de WAF y por qué no encaja con este problema

La raíz de las limitaciones descritas es conceptual: AWS WAF fue diseñado como un sistema de control de acceso basado en seguridad, no como un sistema de gestión de capacidad.

Su modelo mental es binario: una solicitud es legítima o es maliciosa. Las acciones disponibles reflejan ese modelo: Allow, Block, Count, Challenge, CAPTCHA, y la reciente acción Monetize. Los sistemas de gestión de capacidad trabajan con conceptos ausentes en WAF:

• Priorización de tráfico: asignar mayor proporción de recursos a un tipo de solicitud sobre otro.
• Throttling con degradación gradual: reducir progresivamente la calidad del servicio en lugar de bloquear abruptamente.
• Routing condicional: enviar ciertos tipos de solicitudes a una capa de menor costo en lugar del origen.
• Gestión de colas: limitar la tasa de procesamiento sin rechazar las solicitudes, sino difiriendo su atención.

Ninguno de estos conceptos tiene representación en el modelo de datos de AWS WAF v2. La consecuencia práctica es que WAF es la capa de identificación adecuada para el problema, pero no es la capa de solución. La solución requiere WAF como componente dentro de una postura arquitectónica más amplia.

 

6.10 Tabla completa: capacidades y límites

La última fila corresponde a un lanzamiento de junio de 2026 que merece explicación específica. AWS añadió a Bot Control la acción Monetize, que implementa el protocolo x402: cuando un bot solicita un recurso protegido sin autorización de pago, WAF devuelve un HTTP 402 con el precio configurado y las redes de pago aceptadas (entre ellas, USDC sobre la red Base). El bot puede completar el pago y reenviar la solicitud con la autorización incluida; WAF verifica el pago en el edge y sirve el contenido si es válido .

Esto constituye, técnicamente, una tercera opción respecto al binario bloquear/permitir, pero opera sobre un problema diferente. Monetize resuelve el desequilibrio económico: el operador puede cobrar por el acceso en lugar de absorber el costo de infraestructura sin compensación. No resuelve el problema de capacidad: un bot que paga por cada solicitud genera exactamente la misma carga computacional en el servidor que uno que no paga. La latencia del proceso de pago se añade a cada request, pero el volumen de consultas contra la base de datos no cambia.

 

7. Estado del arte: lo que ofrece cada actor del ecosistema

Si la sección anterior recorrió los límites de una sola herramienta, esta sección cambia de escala: documenta el estado del arte a octubre de 2026, proveedor por proveedor: qué ofrece AWS más allá de WAF, qué ofrece Cloudflare, qué resuelven los proveedores de pre-rendering de terceros, y qué sigue aportando el estándar abierto de robots.txt. Son respuestas parciales desde ángulos distintos del ecosistema; ninguna es completa por sí sola, pero juntas forman el mapa más cercano a una respuesta que existe hoy.

Desde AWS: WAF + CloudFront + CloudFront Functions

En octubre de 2022, AWS publicó una guía técnica sobre cómo usar Bot Control para identificar search engines y Lambda@Edge para dirigirlos a una versión optimizada del contenido, maximizando el uso de la caché de CloudFront (AWS Networking Blog, oct 2022). El patrón es directamente aplicable al problema de AI crawlers.

El mecanismo requiere tres piezas:

Pieza 1. Inyección de header desde WAF

WAF aplica labels internamente, pero CloudFront no puede leer esos labels de forma nativa para condicionar el caché. Se requiere una Custom Rule en WAF que, al detectar el bot, inyecte un header en la solicitud. La documentación oficial de WAF sobre inserción de headers personalizados está disponible en: https://docs.aws.amazon.com/waf/latest/developerguide/customizing-the-incoming-request.html

 

Pieza 2. Cache Policy en CloudFront

CloudFront necesita una Cache Policy que incluya X-Client-Type como dimensión de la cache key. Esto permite que CloudFront trate de forma distinta al bot y al usuario humano sin que ambos compartan caché. Documentación de Cache Policies: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/controlling-the-cache-key.html

Pieza 3. Cache-Control headers desde la aplicación

Para que CloudFront sirva resultados al bot desde caché, la aplicación debe emitir Cache-Control: public, max-age=3600 (o el TTL apropiado) para sus rutas de búsqueda. Sin este header, CloudFront no cachea, independientemente de la configuración del CDN. En sistemas que emiten Cache-Control: no-store para garantizar actualización inmediata, esto requiere lógica diferenciada por tipo de cliente mediante CloudFront Functions. Documentación de CloudFront Functions: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html

 

Desde Cloudflare: separación entre search y training crawlers

En julio de 2026, Cloudflare anunció que, a partir del 15 de septiembre, los dominios nuevos bloquearían por defecto el tráfico de entrenamiento y de agentes de IA en páginas con publicidad, dejando permitida la categoría de búsqueda . Ese mismo 15 de septiembre, junto con la entrada en vigor de ese cambio, lanzó también la configuración Disallow AI Training, que permite mantener la visibilidad para búsqueda de IA mientras bloquea el uso del contenido para entrenamiento de modelos. Apple, Google y Microsoft se comprometieron a respetar esta directiva .

Esta granularidad no existe de forma nativa en AWS WAF a la fecha de este artículo.

 

Desde terceros: pre-rendering dedicado para bots

Botify SpeedWorkers entrega páginas pre-renderizadas a search engines y AI bots. La implementación recomendada actual usa una CloudFront Function adjunta al evento viewer-request que detecta el tipo de cliente y redirige el tráfico de bots al origen de pre-rendering, sin tocar el servidor de aplicaciones. Es más simple y más económica que la implementación anterior con Lambda@Edge. Guía de implementación: https://support.botify.com/en/articles/16112380-deploying-speedworkers-with-cloudfront-recommended-implementation

Adobe Experience documenta un patrón equivalente para sus servicios de AI optimization sobre CloudFront, con enrutamiento de agentes de IA hacia un backend especializado mientras los usuarios humanos continúan en el origen habitual: https://experienceleague.adobe.com/en/docs/llm-optimizer/using/resources/optimize-at-edge/cloudfront-byocdn

 

Desde el estándar: robots.txt y crawl-delay

crawl-delay en robots.txt sigue siendo el mecanismo más simple para señalar la tasa de rastreo aceptable, pero no es parte formal del protocolo de exclusión de robots: cada crawler decide si lo respeta. El soporte es desigual: Bing lo respeta, Google no lo soporta en absoluto. meta-webindexer declara respetar robots.txt en su propia documentación (Meta Web Crawlers), pero no hay evidencia pública independiente sobre su tasa real de cumplimiento con crawl-delay específicamente: es una afirmación del propio operador, no una medición de terceros.

aplicaciones. Es más simple y más económica que la implementación anterior con Lambda@Edge. Guía de implementación: https://support.botify.com/en/articles/16112380-deploying-speedworkers-with-cloudfront-recommended-implementation

Adobe Experience documenta un patrón equivalente para sus servicios de AI optimization sobre CloudFront, con enrutamiento de agentes de IA hacia un backend especializado mientras los usuarios humanos continúan en el origen habitual: https://experienceleague.adobe.com/en/docs/llm-optimizer/using/resources/optimize-at-edge/cloudfront-byocdn

Desde el estándar: robots.txt y crawl-delay

8. Lo que AWS lanzó en 2025-2026

AWS ha producido varias respuestas al problema en los últimos doce meses:

• Noviembre de 2025: WBA para verificación criptográfica de bots en Bot Control, limitada a scope CLOUDFRONT. Documentación: https://aws.amazon.com/blogs/security/authenticate-legitimate-ai-agent-traffic-with-aws-waf-bot-control/
• 2026: AI Traffic Analysis Dashboards para WAF, con visibilidad de bots por organización y estado de verificación. Anuncio: https://aws.amazon.com/jp/blogs/security/introducing-ai-traffic-analysis-dashboards-for-aws-waf/
• Junio de 2026: AI Traffic Monetization, acción que permite cobrar a bots por acceso mediante HTTP 402 y el protocolo x402. Anuncio: https://aws.amazon.com/blogs/aws/aws-waf-adds-ai-traffic-monetization-capability-to-help-content-owners-charge-ai-bots-for-content-access/ | Documentación técnica: https://docs.aws.amazon.com/waf/latest/developerguide/waf-ai-traffic-monetization.html

Lo que sigue faltando es una integración nativa entre los labels de Bot Control y las políticas de caché de CloudFront, y un mecanismo de priorización de tráfico que diferencie el cómputo asignado a usuarios reales del asignado a agentes de indexación. Esa integración es posible, pero debe construirse manualmente con Lambda@Edge o CloudFront Functions.

 

9. El estado de la situación en números

Como referencia cuantitativa del contexto, con la calificación de fuente que cada dato merece:

Fuentes primarias o institucionales:

• 51% del tráfico web fue automatizado en 2024. Imperva, Bad Bot Report 2025
• 53% en 2025. Thales/Imperva, Bad Bot Report 2026
• 57.4% de requests automatizados en la red de Cloudflare, junio 2026. Dato circunscrito a la red de Cloudflare; verificable en radar.cloudflare.com
• 14-16 CPUs de 90 en kernel.org dedicadas permanentemente a AI scrapers. Ryabitsev, administrador de kernel.org, agosto 2026. Caso único, verificable por nombre e institución
• 305% de crecimiento en GPTBot entre mayo 2024 y mayo 2025, sobre la red de Cloudflare (~20% de los sitios de internet)
• Library Journal documentó en julio de 2025 que sistemas de repositorios y patrimonio cultural experimentan caídas y ralentizaciones por AI bots
• COAR encuestó sus repositorios de acceso abierto en junio de 2025: acceso de bots de IA las 24 horas como patrón generalizado
• DSpace tiene un issue abierto desde 2025 que documenta que, al intentar bloquear bots agresivos, algunos sitios bloquean accidentalmente a Google Scholar

Fuentes con reservas de metodología o conflicto de interés:

• 9,100 millones de requests de Meta en Q2 2026. DataDome, press release corporativo. DataDome tiene interés comercial en amplificar la percepción del problema
• Incremento de aproximadamente 17x en el share de Meta-WebIndexer en menos de treinta días. PromptWatch. Panel de nicho sin metodología publicada; se presenta como indicador de tendencia, no como medición precisa
• 72% de sitios del Reino Unido con violaciones de robots.txt por AI crawlers. 365i, muestra de 47 sitios con metodología declarada, basada en la herramienta de seguimiento de cumplimiento de robots.txt que Cloudflare lanzó en octubre de 2025

Lo que falta en este mapa es evidencia comparativa: cuánto mejora cada una de estas piezas cuando se mide contra una arquitectura sin diferenciación, en condiciones reales de producción. Esa validación empírica queda como una pregunta abierta: para quien quiera tomarla, sea desde este equipo, desde otro operador que atraviese el mismo problema, o desde el campo de infraestructura en general. Documentar con precisión qué existe hoy y por qué ninguna pieza por sí sola resuelve el problema es ya un punto de partida útil: evita que cada operador tenga que redescubrir estas limitaciones por su cuenta, como ocurrió en el caso descrito en este artículo. Quien tenga datos propios de antes y después de aplicar alguna de estas medidas, o una perspectiva distinta sobre por qué el campo de los firewalls no ha resuelto esto todavía, está invitado a contrastarla con lo documentado aquí.

Sobre la autora

Melany Salcedo trabaja como arquitecta cloud en 3HTP Cloud Services, con experiencia en infraestructuras AWS.

Por qué se escribe sobre esto: el interés por este tema nace del trabajo con distintos clientes que llegaron al equipo con problemas de saturación que no encajaban en ningún diagnóstico de seguridad convencional. Al revisar esos casos en profundidad, se hizo evidente que el problema, aunque real y recurrente, no está ampliamente documentado ni forma parte todavía del diagnóstico habitual en la industria. Esa fue la motivación para exponerlo junto con las soluciones revisadas en los distintos proyectos donde apareció: darle visibilidad, e invitar a la comunidad técnica a profundizar en el tema para aportar, entre todos, a una respuesta más enfocada de la que existe hoy.

Certificación: AWS Solutions Architect Associate.

Los logs incluidos en este artículo son datos sintéticos que reproducen fielmente la estructura técnica del tráfico observado en producción. Los tipos de endpoints, patrones de parámetros, User-Agents y códigos de respuesta corresponden al patrón real; todos los identificadores del sistema fuente han sido sustituidos para proteger la confidencialidad del operador.

Imperva. (2025). 2025 Bad Bot Report. https://www.imperva.com/resources/resource-library/reports/2025-bad-bot-report/. 51% del tráfico web fue automatizado en 2024.

Thales / Imperva. (2026). Bad Bot Report 2026: Bots in the Agentic Age. https://www.imperva.com/blog/bad-bot-report-2026-bots-agentic-age/. 53% en 2025.

Cloudflare Radar. CEO Matthew Prince, 3 de junio de 2026. Ventana de 7 días terminada el 5 de junio: 57.4% automatizado, 42.6% humano. Cobertura: https://letsdatascience.com/news/cloudflare-reports-bots-generate-majority-of-web-traffic-715b63a5. Dato circunscrito a la red de Cloudflare.

Cloudflare. (2025). From Googlebot to GPTBot: who’s crawling your site in 2025. https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/. GPTBot +305% mayo 2024-mayo 2025, Googlebot +96% en el mismo período, medido sobre la red de Cloudflare.

DataDome. (2026, julio). AI Agent Traffic Surged 45% in Q2. BusinessWire. https://www.businesswire.com/news/home/20260716617247/en/DataDome-Report-AI-Agent-Traffic-Surged-45-in-Q2-Driving-a-Wave-of-Agent-Trust-Policy-Adoption. 17.7 mil millones de AI agent requests en Q2 2026 en la red de DataDome; Meta +163% trimestre contra trimestre. Nota: DataDome tiene interés comercial en visibilizar el problema.

PromptWatch. (2026). Meta Web Indexer: Meta’s Crawling Surge in AI Crawler Logs. https://promptwatch.com/data/meta-web-indexer. De 2.2% a 37.8% en menos de 30 días. Limitación: panel de nicho sin metodología ni tamaño de muestra publicados. Indicador de tendencia, no medición precisa.

Ryabitsev, K. (2026, agosto 29). Análisis de AI scrapers en git.kernel.org. Cobertura: https://linuxiac.com/kernel-org-battles-ai-crawlers-generating-millions-of-daily-requests/. 14-16 CPUs de 90 dedicadas permanentemente a scrapers. Fuente primaria de primera mano; caso único.

Wix. (2026, junio). State of Websites Report. Cobertura: https://www.shopifreaks.com/wixs-first-state-of-websites-report-finds-ai-halved-site-build-time-to-four-days-though-llms-still-drive-under-1-of-traffic/. AI platforms generan tráfico de referencia hacia ~700,000 sitios de Wix al mes (~2.2M sesiones en marzo de 2026), aunque ese tráfico sigue siendo menos del 1% del total de visitas.

Wix. (2026, junio). State of Websites Report. Cobertura: https://www.shopifreaks.com/wixs-first-state-of-websites-report-finds-ai-halved-site-build-time-to-four-days-though-llms-still-drive-under-1-of-traffic/. AI platforms generan tráfico de referencia hacia ~700,000 sitios de Wix al mes (~2.2M sesiones en marzo de 2026), aunque ese tráfico sigue siendo menos del 1% del total de visitas.

AWS. (2024). AWS WAF Bot Control: Managing false positives. https://docs.aws.amazon.com/waf/latest/developerguide/waf-bot-control-false-positives.html

COAR. (2025). Report of the COAR Survey on AI Bots: June 2025. https://coar-repositories.org/wp-content/uploads/2025/06/Report-of-the-COAR-Survey-on-AI-Bots-June-2025-1.pdf