El problema: cuando algo se rompe y nadie sabe por qué
Las empresas que adoptan IA en su operación ganan velocidad, pero también ganan complejidad. Un agente de IA que responde correos, un chatbot que atiende clientes, un sistema de conciliación bancaria automatizado: cada uno de estos sistemas puede fallar, y cuando falla, el diagnóstico no es trivial.
El escenario típico: a las 3 de la mañana, el monitor de tu infraestructura detecta que el servicio de pagos dejó de responder. El equipo de on-call se despierta, abre el dashboard, ve métricas, logs, alertas. Tiene que correlacionar eventos, identificar la causa raíz, decidir si escalar, parchear o revertir. Todo bajo presión, con poco contexto y con la certeza de que cada minuto de downtime cuesta dinero.
La IA puede ayudar en este proceso, pero no de la forma en que muchos la usan: no como un chatbot al que le preguntas "¿qué pasó?" y espera una respuesta mágica. La ayuda real viene de un agente que lee los logs, junta evidencia, propone hipótesis y deja que el humano decida.
Lo que dicen los datos
Anthropic Project Glasswing (mayo 2026): Claude Mythos Preview encontró más de 10.000 vulnerabilidades de severidad alta o crítica en software crítico. La IA ahora puede construir exploits (por ejemplo, falsificación de certificados para sitios web de bancos). El cuello de botella ya no es encontrar vulnerabilidades, sino verificar, divulgar y parchear. La misma lógica aplica a incidentes: la IA puede encontrar la causa, pero el humano debe decidir qué hacer.
SEK "Think Ahead" (2025): Chile enfrentó 8,8 billones de intentos de ciberataque en 2025. De ese total, 5 billones fueron escaneos activos (no ataques exitosos). La fuente primaria es SEK (Security Ecosystem Knowledge), reporte "Think Ahead" (datos 2025), publicado en rga.cl (Pulso/La Tercera) el 1 de julio de 2026. También atribuido a FortiGuard Labs/Fortinet.
Columna de opinión, BioBioChile (21 julio 2026): Un 16% de las brechas de seguridad involucran delincuentes que usan IA. Esta cifra proviene de una columna de opinión y no se pudo verificar la metodología ni la fuente primaria. Se trata como estimación no verificada.
La conclusión es que los incidentes son cada vez más frecuentes y más sofisticados, y la respuesta manual ya no escala.
Por qué la respuesta manual no escala
El problema no es la falta de herramientas. Las empresas tienen monitores, dashboards, logs, alertas. El problema es la correlación: unir los puntos entre lo que dicen las métricas, lo que dicen los logs y lo que dicen las alertas, en tiempo real, bajo presión.
Tres razones por las que la respuesta manual no escala:
1. Volumen de datos
Un sistema en producción genera miles de líneas de log por minuto. Durante un incidente, el volumen se multiplica. Un humano no puede leer todo; tiene que filtrar, buscar patrones, correlacionar. Eso toma tiempo que no tienes.
2. Contexto distribuido
La causa de un incidente rara vez está en un solo lugar. Está en la interacción entre el servicio de pagos, la base de datos, el caché, el balanceador de carga y el proveedor de nube. Cada uno tiene su propio dashboard, sus propios logs, su propia nomenclatura. Unir todo requiere conocimiento del sistema que no siempre está disponible a las 3 de la mañana.
3. Presión y fatiga
La respuesta a incidentes es un trabajo de alta presión. Las decisiones se toman rápido, con información incompleta y con la certeza de que un error puede empeorar las cosas. La fatiga cognitiva aumenta el riesgo de decisiones incorrectas.
Cómo la IA ayuda (y cómo no)
La IA no reemplaza al ingeniero de on-call. Lo que hace es acelerar la parte más lenta del proceso: la recolección y correlación de evidencia.
Lo que la IA puede hacer
Leer logs a escala: Un agente de IA puede procesar miles de líneas de log en segundos e identificar patrones que un humano tardaría minutos en encontrar. No es magia: es procesamiento de texto a velocidad de máquina.
Correlacionar eventos: El agente puede cruzar eventos de diferentes fuentes (métricas, logs, alertas, deploys recientes) y proponer una línea de tiempo del incidente. "A las 02:47 se desplegó la versión 2.3.1. A las 02:52 el servicio de pagos empezó a responder con latencia. A las 02:55 la base de datos mostró picos de CPU."
Proponer hipótesis: Basado en la evidencia, el agente puede proponer causas probables: "El deploy de la 2.3.1 introdujo una consulta N+1 que satura la base de datos. Recomendación: revertir el deploy y monitorear."
Documentar el incidente: El agente puede generar un post-mortem inicial con la línea de tiempo, la evidencia y las hipótesis, listo para que el equipo lo revise y complete.
Lo que la IA no debe hacer
Decidir por ti: La IA propone, el humano decide. Un agente que reinicia servicios, revierte deploys o modifica configuraciones sin aprobación humana es un riesgo mayor que el incidente que intenta resolver.
Actuar sin contexto: La IA no tiene el contexto completo del negocio. No sabe que el servicio de pagos es crítico para un cliente enterprise que paga $50.000 al mes. No sabe que revertir el deploy romperá otra funcionalidad que se lanzó ayer.
Reemplazar el juicio humano: La IA es una herramienta de aceleración, no de automatización total. El ingeniero de on-call sigue siendo responsable de la decisión final.
El modelo War Room: agente que lee, junta evidencia y propone; humano decide
Personnn tiene un producto llamado War Room que implementa este modelo. Es un agente que:
- Lee: Se conecta a tus fuentes de datos (logs, métricas, alertas, deploys) y lee la información en tiempo real.
- Junta evidencia: Correlaciona eventos de diferentes fuentes y construye una línea de tiempo del incidente.
- Propone: Genera hipótesis sobre la causa raíz y recomienda acciones (revertir deploy, escalar servicio, contactar proveedor).
- El humano decide: El ingeniero de on-call revisa la propuesta, la valida o la rechaza, y ejecuta la acción.
War Room está en producción pero en etapa temprana. No es un producto terminado: es un motor que funciona y se está refinando con casos reales. Si tienes infraestructura que quieres monitorear, escríbenos.
Checklist: cómo preparar tu infraestructura para respuesta a incidentes con IA
Si quieres que la IA te ayude a responder incidentes, primero necesitas que tu infraestructura sea "legible" para un agente:
- Logs estructurados: Tus logs deben estar en formato JSON o similar, con campos consistentes (timestamp, servicio, nivel, mensaje). Logs en texto plano son difíciles de procesar automáticamente.
- Métricas centralizadas: Todas las métricas deben estar en un solo lugar (Prometheus, Datadog, Grafana). Si cada servicio tiene su propio dashboard, el agente no puede correlacionar.
- Alertas con contexto: Las alertas deben incluir qué servicio, qué métrica, qué umbral y desde cuándo. Una alerta que dice "CPU alto" no es útil; una que dice "CPU > 90% en servicio de pagos desde 02:47" sí.
- Deploys trazables: Cada deploy debe registrarse con timestamp, versión, cambios y quién lo ejecutó. Sin trazabilidad de deploys, el agente no puede correlacionar cambios con incidentes.
- Runbooks documentados: Documenta los pasos para los incidentes más comunes. El agente puede seguir un runbook y proponer las acciones documentadas.
- Acceso de solo lectura: El agente debe tener acceso de solo lectura a logs, métricas y alertas. Nunca dar acceso de escritura a un agente automatizado.
- Escalación definida: Define cuándo el agente debe escalar a un humano y cómo. No todos los incidentes requieren intervención humana inmediata, pero los críticos sí.
Fuentes
- Anthropic (mayo 2026). Project Glasswing: actualización inicial. Fuente: anthropic.com/research/glasswing-initial-update. Verificado por web_fetch.
- SEK (2025). Reporte "Think Ahead" (datos 2025). Fuente primaria: SEK (Security Ecosystem Knowledge). Publicado en rga.cl (Pulso/La Tercera) el 1 de julio de 2026. También atribuido a FortiGuard Labs/Fortinet. Verificado por web_fetch (vuelta 16).
- BioBioChile (21 julio 2026). Columna de opinión sobre brechas de seguridad con IA. La cifra del 16% se trata como estimación no verificada. Verificado por web search (vuelta 16).
Las cifras de SEK provienen de la fuente primaria verificada. La cifra del 16% proviene de una columna de opinión y se trata como estimación no verificada. La cifra de Anthropic (10.000+ vulnerabilidades) proviene del blog oficial de Anthropic.