Los equipos de ingeniería de confiabilidad del sitio (SRE) y de DevOps están agotados. La dispersión de los parques informáticos, la sobrecarga de herramientas y el hecho de estar de guardia contribuyen a un problema general: la fatiga alerta.
La fatiga alerta (a veces llamada fatiga de alarmas) se refiere a "un estado de agotamiento mental y operativo causado por una cantidad abrumadora de alertas". Erosiona la capacidad de respuesta y la eficacia de DevOps, el centro de operaciones de seguridad (SOC), la ingeniería de confiabilidad del sitio (SRE) y otros equipos responsables del rendimiento y la seguridad de TI, y es un problema generalizado y con consecuencias.
El informe “2023 State of Threat Detection” de Vectra (basado en una encuesta a 2000 analistas de seguridad de TI en empresas con 1000 empleados o más) encontró que los equipos de SOC reciben un promedio de 4484 alertas por día. De ellos, el 67 % son ignorados debido al elevado volumen de falsos positivos y a la fatiga de las alertas. El informe también reveló que el 71 % de los analistas creía que su organización ya podría estar "comprometida sin su conocimiento, debido a la falta de visibilidad y confianza en las capacidades de detección de amenazas".
Si bien el informe de Vectra se centra específicamente en la seguridad, los equipos encargados de monitorear el rendimiento de las aplicaciones y la infraestructura enfrentan una sobrecarga similar. Por ejemplo, un solo error de configuración puede causar cientos o miles de alertas de rendimiento, una "tormenta de alertas" que puede distraer o desensibilizar a los equipos de TI y causar respuestas retrasadas a alertas críticas y problemas reales. Esos problemas reales pueden ser costosos.
¿Qué está impulsando este agotamiento, y puede la IA agéntica ser parte de una solución escalable?
Boletín de la industria
Manténgase al día sobre las tendencias más importantes e intrigantes de la industria sobre IA, automatización, datos y más con el boletín Think. Consulte la Declaración de privacidad de IBM.
Su suscripción se entregará en inglés. En cada boletín, encontrará un enlace para darse de baja. Puede gestionar sus suscripciones o darse de baja aquí. Consulte nuestra Declaración de privacidad de IBM para obtener más información.
Hay varios culpables, y a menudo se cita un volumen abrumador de telemetría como uno de ellos, pero un enfoque en el volumen de datos oculta específicamente un problema central: la calidad y el contexto de los datos.
Cuando los equipos se enfrentan a un montón de datos de baja calidad y contexto deficiente, alimentando docenas de diferentes fuentes de inteligencia de amenazas o rendimiento, es probable que encuentren problemas. Este es el tipo de entorno en el que proliferan los falsos positivos y las alertas redundantes, y el ruido de baja prioridad distrae la atención de las amenazas reales y los problemas de rendimiento. Estas "falsas alarmas" pueden acabar con los equipos de TI, DevOps y seguridad.
Simplemente alimentar estos flujos masivos de telemetría a un modelo de lenguaje de gran tamaño (LLM) tampoco es una solución viable. En primer lugar, es un desperdicio de recursos informáticos. También es una excelente manera de producir alucinaciones.
Una solución práctica comienza con el desarrollo de un flujo de trabajo que sintetice datos sin procesar y agregue estos datos de mayor calidad y ricos en contexto dentro de una plataforma centralizada. Allí se puede utilizar para la observabilidad en toda la empresa y el entrenamiento de modelos de IA locales.
Las empresas suelen utilizar muchas soluciones de monitoreo de rendimiento y seguridad: las grandes empresas tienen un promedio de 76 herramientas de seguridad. Estas herramientas pueden ser específicas del equipo o del producto, o específicas de un determinado entorno de TI (soluciones on premises vs. soluciones en la nube, por ejemplo).
Cada una de estas herramientas podría ser responsable de monitorear docenas o cientos de aplicaciones, interfaces de programación de aplicaciones (API) o servidores, cada uno alimentando su propia canalización de datos. Con tales silos, las herramientas separadas pueden generar múltiples alertas derivadas del mismo problema subyacente. Esta falta de integración limita la visibilidad, lo que dificulta la correlación y el análisis de la causa principal. Los SRE pierden tiempo persiguiendo cada una de estas alertas antes de identificar las redundancias.
Cuando los flujos de datos no se integran en un sistema de monitoreo integral, los equipos de TI no tienen la Observabilidad en todo el sistema necesaria para una correlación eficiente de alertas, análisis de causa principal y corrección.
Lo que es peor, esta falta de integración dificulta la eficacia de las herramientas de automatización para la gestión de alertas, como la priorización de alertas y los flujos de trabajo de correlación, configurados para ayudar en la detección y resolución y reducir el volumen de alertas. Los equipos deben conectar manualmente los puntos, una tarea ardua y que requiere mucho tiempo (si no imposible).
Una encuesta citada en el informe "Adaptive Defense: Custom Alerts for Modern Threats" de Deloitte encontró que una "falta de visibilidad o contexto de las herramientas de seguridad da como resultado que el 47 % de los ataques se pierdan en un periodo de 12 meses".
Si bien los agentes individuales no necesariamente requieren centralización, una plataforma centralizada donde se agregan los datos de los agentes facilita el análisis, el almacenamiento y la visualización de todo el sistema.
Sí…con una estrategia enfocada.
Un informe reciente del MIT desató una tormenta de fuego con la afirmación de que "el 95 % de las organizaciones obtienen un rendimiento cero" de sus inversiones en IA generativa.
Dejando de lado la estadística incendiaria y la cascada de opiniones que solicitó el informe, este destaca un tema valioso: muchos proyectos deIA fracasan debido a "flujos de trabajo frágiles, falta de aprendizaje contextual y desalineación con las operaciones diarias". Como señala Marina Danilevsky, científica investigadora sénior de IBM en un reciente podcast de Mixture of Experts, los despliegues más exitosos están"enfocados, delimitados y abordan un punto débil adecuado".
El informe del MIT refuerza el hecho de que las empresas que ven la IA como una especie de panacea o algo que se puede calzar al azar en un proceso, no es probable que vean un retorno de su inversión. Las organizaciones que pueden implementar estratégicamente herramientas de IA en sus flujos de trabajo para resolver un problema específico y reforzar estas herramientas con el tiempo, son las más adecuadas para el éxito.
Una solución de observabilidad o seguridad que pueda incorporar machine learning adaptativo, priorización contextual, IA explicable, automatización impulsada por IA y inteligencia en tiempo real en una estrategia integrada puede permitir a los equipos crear flujos de trabajo más sólidos que ayuden a correlacionar, priorizar y remediar las alertas de rendimiento o seguridad.
Los agentes de IA pueden mejorar los sistemas tradicionales que se basan en reglas estáticas y umbrales preestablecidos al incorporar factores como la importancia de los activos, las garantías de rendimiento, los perfiles de riesgo y las tendencias históricas.
Por ejemplo, considere un flujo de trabajo de detección y corrección posterior a incidentes y cómo un agente de IA podría ayudar a un equipo de ingeniería de confiabilidad de sitios (SRE).
Una notificación llega al sistema de alerta indicando un alto uso de CPU para un nodo en un clúster de Kubernetes. En un sistema tradicional, los SRes podrían necesitar analizar los datos MELT (métricas, eventos, registros, trazas) y las dependencias para identificar la causa principal.
En este flujo de trabajo agentivo hipotético, el agente utiliza el gráfico de conocimiento de la herramienta de observabilidad y la correlación consciente de la topología para extraer solo la telemetría relacionada con la alerta (como registros de los servicios que se ejecutan en ese nodo, despliegues recientes, telemetría del servidor API de Kubernetes o equilibradores de carga que enrutan el tráfico al nodo o clúster). Con esta información adicional, el agente puede enriquecer las alertas sin procesar y proporcionar telemetría rica en contexto a un modelo de IA local entrenado con los datos y puntos de referencia de rendimiento de la empresa.
El agente excluye información irrelevante, como registros de servicios no relacionados que se ejecutan en el mismo clúster. Durante esta recopilación de contexto, el agente también puede identificar señales relacionadas y correlacionar alertas que probablemente se deriven de la misma causa principal y agrupar estas alertas para investigarlas como un solo incidente.
Con esta información, el modelo puede proponer una hipótesis. El agente también puede solicitar más información (tal vez verificar las configuraciones de los contenedores o los datos de series temporales en torno al pico de uso) para verificar y refinar la hipótesis del modelo, agregando contexto adicional antes de proponer una causa principal probable.
El uso de IA y agentes explicables es una parte crucial para resolver el problema de la confianza, de "ver dentro de la caja negra" o el funcionamiento interno de una herramienta de IA.
La inteligencia artificial explicable (XAI) es un conjunto de procesos y métodos que permiten a los usuarios humanos comprender y confiar en los Resultados y resultados creados por algoritmos de machine learning.
Además de la causa principal probable, el agente puede proporcionar explicabilidad a través de su cadena de pensamiento, su proceso de razonamiento, junto con evidencia de apoyo que demuestre cómo llegó a la causa principal probable propuesta. Esta explicabilidad y evidencia de apoyo:
- Permite a los humanos ver por qué algo se ha recomendado o filtrado de cierta manera
- Proporciona la transparencia necesaria para revisar el análisis y la propuesta del agente, y juzgar si se puede confiar en él
El análisis de ingeniería de confiabilidad de sitios (SRE) y evaluación de las recomendaciones de los agentes se pueden retroalimentar en el modelo para mejorar aún más la precisión.
Hay varios caminos para llegar a una solución. Los equipos pueden decidir cuánta autonomía proporcionar a un agente o definir esta autonomía en función del tipo de incidente, la gravedad, el entorno u otros factores. Los siguientes pasos incluyen:
- Validación: un agente puede generar pasos para ayudar a los equipos de ingeniería de confiabilidad de sitios (SRE) y DevOps a validar que la causa principal que identificó el agente sea correcta. Esto ayuda a mantener la entrada humana en el sistema.
- Respuesta y ejecución: cuando se valida, el agente puede producir una guía paso a paso de los pasos de corrección (una respuesta y ejecución). Este es un script que los miembros del equipo pueden seguir para resolver el problema.
- Scripts de automatización: el agente también puede realizar las acciones sugeridas y crear flujos de trabajo (scripts de automatización). Podría convertir estos pasos de respuesta y ejecución en un Playbook de Ansible con la sintaxis del comando y los parámetros para los pasos.
- Documentación: los agentes pueden producir documentación automática, como una revisión posterior al incidente, que resume el incidente, las acciones tomadas y las razones para hacerlo. Un agente también puede elaborar un resumen en curso que ayude a los nuevos en la tarea a entender rápidamente lo que está pasando. Esta documentación se puede utilizar para el aprendizaje por refuerzo.
Todos estos pasos ayudan a optimizar la respuesta ante incidentes y reducir el tiempo medio de reparación. Para ver un video tutorial de una hipótesis similar, haga clic aquí.
Los marcos de IA se pueden utilizar para mejorar varios aspectos de la fatiga alerta, como la priorización de alertas aplicables en la práctica en todo un entorno de TI.
En un documento de 2023 titulado “Eso escaló rápidamente: un infraestructura/marco de machine learning (ML) para la priorización de alertas”, Gelman et al presentan un infraestructura/marco de machine learning diseñado para reducir la fatiga alerta con cambios mínimos en los flujos de trabajo existentes a través de un nivel de alerta y un sistema de puntuación de accionabilidad a nivel de incidente. Ejecutado con datos del mundo real, el modelo TEQ redujo el tiempo de respuesta a incidentes procesables en un 22.9 % y suprimió el 54 % de los falsos positivos (con una tasa de detección del 95.1 %). También redujo el número de alertas dentro de incidentes singulares en un 14 %.1
En “Advancing Autonomous Incident Response: Leveraging LLMs and Cyber Threat Intelligence”, Tellache et al demuestran cómo una infraestructura basada en generación aumentada por recuperación (RAG), puede mejorar la resolución de incidentes integrando datos de fuentes de inteligencia de amenazas.2 Una solución similar que utilice agentes para desarrollar el enfoque RAG podría usarse para agregar un mayor contexto a los datos de rendimiento, por ejemplo, obteniendo umbrales de rendimiento acordados de acuerdos de nivel de servicio (SLA) empresariales para ayudar a decidir qué alertas de aplicaciones deben priorizarse. .
Un equipo de TI puede utilizar varios agentes para mejorar los procesos de alerta, cada uno diseñado para abordar una faceta diferente de la fatiga alerta, como un agente de clasificación de incidentes que extrae amenazas críticas para su atención inmediata, o un agente de enrutamiento que detecta alertas priorizadas y las dirige a la dirección adecuada junto con la documentación y el análisis.
Al enrutar los datos a un centro centralizado, las empresas pueden ayudar a eliminar los puntos ciegos y presentar a los agentes una comprensión más completa del entorno en el que operan. La IA es más eficaz cuando se trabaja con datos confiables y de alta calidad, y una plataforma centralizada puede ayudar a garantizar la aplicación uniforme de los estándares de gobernanza de datos. A medida que las organizaciones escalan las soluciones de IA, esta plataforma desempeña un papel crucial en el mantenimiento de la coherencia en la gestión de datos y el despliegue de agentes en todas las unidades de negocio.
¿Puede una organización simplemente “usar IA” y eliminar el diluvio de alertas? No. ¿Pueden los modelos y agentes bien entrenados ayudar a sintetizar y analizar la telemetría y clasificar las alertas para dar un respiro a los equipos de TI? Mucho más motivo para ser optimista allí.
El éxito del uso de la IA y los agentes para aliviar la fatiga alerta depende de algunos factores clave: la orientación a un caso de uso, la aplicación estratégica y la capacidad de la IA para aprender y mejorar en entornos dinámicos. Los líderes empresariales deben comprender lo que se requiere, estar dispuestos a realizar los cambios culturales y asignar los recursos necesarios para que el sistema funcione y encontrar un proveedor cuyas herramientas puedan personalizarse para satisfacer sus necesidades.
1 “That Escalated Quickly: An ML Framework for Alert Prioritization,” Gelman, Taoufiq, Vörös, Berlin, 15 de febreror de 2023
2 “Advancing Autonomous Incident Response: Leveraging LLMs and Cyber Threat Intelligence,” Tellache, Korba, Mokhtari, Moldovan, Ghamri-Doudane, 14 de agosto de 2025