Rodrigo Jorge · Publicado el 9 de octubre de 2026 a las 00:05 (hora de Brasilia, UTC-3).
Si el ataque avanza mientras la defensa espera autorización, la espera se vuelve parte del riesgo. IA×IA nació para investigar cómo reducir esa distancia.
Una alerta puede llegar en segundos y la respuesta tardar horas. Entre una y otra, alguien debe reunir información, evaluar el impacto, encontrar al responsable y obtener autorización para actuar. Cada paso puede tener sentido. El problema es el tiempo que suman.
El atacante no necesita esperar a que termine ese proceso.
Los scripts, bots y herramientas de explotación llevan años automatizando ataques. Los agentes de IA pueden añadir la capacidad de interpretar el contexto, probar hipótesis y ajustar el enfoque durante la ejecución. Eso no vuelve autónomo a todo ataque ni competente a todo atacante. Pero sí amplía el trabajo que una persona puede poner en marcha.
Como CISO, me interesa una pregunta operativa: si el ataque puede avanzar entre dos decisiones nuestras, ¿qué debe cambiar en la defensa?
El tiempo disponible para responder importa
Cloudflare reportó un ataque DDoS de 31,4 Tbps que duró 35 segundos en 2025. La detección y la mitigación fueron automáticas. En ese intervalo, un equipo no podría investigar cada evento, abrir un ticket y autorizar la respuesta.
El caso muestra por qué ciertas acciones deben ejecutarse automáticamente. No demuestra que la mitigación haya utilizado agentes basados en modelos de lenguaje. La distinción importa: hay que elegir la tecnología según la tarea, el tiempo disponible y el riesgo de error.
Una regla puede bloquear un patrón conocido. Un sistema especializado puede absorber un DDoS. Un agente puede investigar señales dispersas cuando la decisión requiere contexto. El reto es identificar dónde funciona cada recurso y verificar el resultado.
Autorizar antes, dar seguimiento durante
Para que una respuesta automática funcione, algunas decisiones deben tomarse antes del incidente: qué señales justifican actuar, qué objetivos están protegidos, cuál es el alcance permitido y cuándo detenerse o pedir ayuda.
Bloquear temporalmente una IP y deshabilitar una cuenta privilegiada requieren permisos distintos. Incluso una acción reversible puede causar daños antes de deshacerse. Por eso, la velocidad debe ir acompañada de límites y de una forma de recuperar el servicio.
Las personas siguen siendo responsables de esas decisiones y de las excepciones. La aprobación caso por caso corresponde cuando el impacto o la incertidumbre la exigen. En las acciones delegadas, el equipo necesita revisar errores y evidencias, y poder reducir la autonomía.
Cyberbot muestra un flujo concreto. Analiza el tráfico que pasó por el WAF y puede bloquearlo en el edge después de aplicar filtros y controles determinísticos. El caso reporta menos de un minuto desde el log hasta el bloqueo. Es una implementación para estudiar, con límites propios, no una promesa de desempeño en cualquier entorno.
Ver el diagrama: autorizar antes, responder durante. Flujo conceptual, sin tiempos medidos.
Por qué existe IA×IA
El proyecto comenzó como una charla. Una persona asistió, puso la idea en práctica y construyó Cyberbot. Esa experiencia me motivó a convertir la charla en una guía: documentar el diseño, los controles y las dudas para que otros equipos puedan evaluar qué les conviene adaptar.
Quiero que IA×IA sea útil para quienes deben tomar decisiones al frente de una operación real. Que ayude a identificar una tarea, entender qué datos necesita, acotar la acción y medir si el cambio mejoró la respuesta. Que también permita concluir que basta con una regla simple, o que todavía falta evidencia para delegar.
Por eso la guía es pública, gratuita y no tiene vínculos comerciales con ningún proveedor de soluciones. Los casos describen implementaciones reportadas; los playbooks presentan propuestas para poner a prueba. Las etiquetas mantienen esa diferencia.
El nombre IA×IA expresa la pregunta que orienta el proyecto: ¿cómo usar IA en la defensa frente a lo que permite hacer en el ataque? La respuesta debe verse en la operación: menos espera donde aumenta el riesgo, decisiones verificables y capacidad de recuperar el servicio cuando algo sale mal.
Referencias
- Cloudflare: DDoS threat report, Q4 2025, publicado el 5 de febrero de 2026.
- IA×IA: Cyberbot, implementación y controles reportados por el proyecto.