Hay una forma rápida de hacer que un agente de defensa se equivoque: pedirle que "bloquee ataques". Suena a instrucción. En la práctica es una pregunta demasiado amplia, y el modelo la responde como responde cualquier pregunta amplia: con una opinión plausible, segura y difícil de auditar.
El problema no es que el modelo sea débil. Es que la pregunta es ancha. "¿Esto es un ataque?" le exige saber, al mismo tiempo, qué es una inyección SQL, qué es XSS, qué es un path traversal, el credential stuffing, el scraping, un bot de monitoreo legítimo y un cliente con un plugin viejo. Cada uno tiene señales distintas, falsos positivos distintos y consecuencias distintas si la decisión sale mal. Metidos en la misma bolsa se convierten en un promedio, y un promedio no bloquea bien nada.
Pregunta estrecha, mejor respuesta
Lo que funciona es lo contrario: dividir por categoría y hacer una pregunta a la vez. En lugar de "¿esto es un ataque?", el agente recibe "¿esto es inyección SQL?", con un prompt escrito para inyección SQL, ejemplos de inyección SQL, ejemplos de lo que no lo es y el umbral de confianza que la operación acepta para inyección SQL. Luego lo mismo para XSS, para traversal, para cada categoría que la organización decidió tratar.
La diferencia aparece en tres lugares:
- Precisión. El modelo acierta más cuando el espacio de respuesta es pequeño y los ejemplos son de la misma familia.
- Calibración. Cada categoría tiene su propio umbral. La confianza suficiente para bloquear un traversal evidente no es la misma que para un patrón de credential stuffing, donde bloquear a un cliente legítimo cuesta caro.
- Corrección. Cuando la IA se equivoca, sabes en qué categoría se equivocó y ajustas ese prompt, esos ejemplos o ese umbral sin tocar el resto. El falso positivo se vuelve un bug localizado, no un motivo para apagar el motor.
Cómo se ve esto en Cyberbot
El caso Cyberbot, que corre en producción, hace exactamente esto, y así llegó a menos de un minuto del log al bloqueo sin tumbar clientes. La categoría sale de una lista cerrada; el modelo no inventa categorías nuevas. Severidad y confianza las valida el código. Reglas simples detectan de antemano a los sospechosos evidentes (traversal, SQLi, .env expuesto, web shell) y le entregan a la IA solo lo que necesita juicio contextual. Y la acción automática se habilita por categoría y severidad, con lista y TTL definidos, nunca en bloque.
Si el modelo se sale del contrato y devuelve algo fuera de la lista, la solicitud cae en un fallback. No pasa nada. Esa es la parte que más importa: la pregunta estrecha no es un truco de prompt, es lo que permite poner un contrato verificable entre el modelo y la acción.
Qué cambiar en tu playbook
Si estás diseñando un agente que puede actuar, la regla cabe en una línea: ninguna acción se autoriza para "ataque". Las acciones se autorizan por categoría, y cada categoría tiene su propio prompt, sus ejemplos y su umbral, revisados por separado.
El generador de playbooks de esta guía ya incluye eso en su lista de guardrails. No es un detalle de implementación. Es la diferencia entre un agente en el que la operación confía y uno que la operación apaga en la primera semana.