La adopción de la IA se está generalizando entre los equipos de operaciones de seguridad. La encuesta State of AI in Security Operations 2026 de Prophet Security, realizada a más de 250 CISOs, responsables de SOC y profesionales, reveló que el 40% de los equipos utiliza la IA a diario, mientras que otro 56% la está probando. Solo el 4% afirmó no tener planes de adoptar la tecnología.
Para los equipos que todavía evalúan la IA, la pregunta clave es si su SOC está preparado para implementar agentes. La preparación tiene dos dimensiones: los problemas operativos que un agente de IA podría resolver y las bases técnicas y de gobernanza necesarias para investigar las alertas con precisión.
Los agentes de IA son más útiles en los SOC que afrontan escalaciones retrasadas de servicios gestionados de detección y respuesta, falta de contexto, cobertura limitada de los proveedores, acumulación de alertas y poca visibilidad sobre las decisiones de investigación. Los equipos internos también pueden tener dificultades para responder rápidamente si están afectados por una nueva vulnerabilidad o campaña, investigar alertas de menor gravedad, ajustar detecciones ruidosas, realizar búsquedas de amenazas y mantener la cobertura fuera del horario laboral normal.
La encuesta reveló que el 60% de los encuestados había visto que una alerta ignorada o pasada por alto se convertía posteriormente en un problema grave, como una brecha o una interrupción del servicio. También informó que el 28% de las alertas nunca se investiga. Estas presiones hacen que la búsqueda proactiva y la ingeniería de detección compitan con la gestión diaria de alertas.
El modelo de madurez del SOC descrito por Prophet Security sitúa la gestión de alertas en la base, seguida por la cobertura de detección, la concienciación sobre amenazas, la búsqueda proactiva y las mejoras de la postura. Los agentes de IA generalmente comienzan con la investigación de alertas, aunque las plataformas más recientes también pueden respaldar la búsqueda de amenazas y la ingeniería de detección. El tiempo recuperado del trabajo rutinario puede entonces redirigirse a actividades situadas más arriba en el modelo.
La preparación técnica comienza con el acceso. Un agente solo puede investigar los datos que puede consultar, por lo que las integraciones relevantes pueden incluir el SIEM, el EDR, el proveedor de identidad, las plataformas en la nube, el correo electrónico y las aplicaciones SaaS importantes. También necesita contexto legible, como la criticidad de los activos, las funciones de los usuarios, las listas de VIP, las unidades de negocio y la actividad conocida como benigna. Supervisar el estado y la puntualidad de las canalizaciones de registros es igualmente importante, porque los datos ausentes o retrasados pueden hacer que una investigación parezca completa cuando falta evidencia crítica.
Una prueba práctica consiste en revisar cinco incidentes recientes y enumerar cada consulta que utilizó un analista sénior para resolverlos. Cualquier consulta que el agente propuesto no pueda ejecutar identifica una brecha de acceso o integración. También debe examinarse el tratamiento de los datos: el 44% de los encuestados citó la privacidad de los datos y el entrenamiento de modelos de IA como un obstáculo importante. Las organizaciones deberían preguntar a los proveedores si los datos de los clientes se utilizan para entrenar modelos y dónde se procesan esos datos.
Un piloto también necesita una definición escrita de lo que constituye una investigación completada. Ese estándar debería especificar la evidencia requerida para casos comunes, incluidas las alertas de phishing y de viaje imposible, y qué es suficiente para clasificar una alerta como benigna. Las organizaciones deberían registrar métricas de referencia, como el porcentaje de alertas investigadas, el tiempo medio de investigación, el tiempo hasta la primera revisión y la tasa a la que se reabren las alertas cerradas.
El informe afirma que una investigación exhaustiva tarda un promedio de 75 minutos y que las alertas suelen esperar casi una hora antes de abrirse. También indica que hasta el 40% de las organizaciones ha desactivado algunas detecciones porque no tenía capacidad para revisarlas. Una lista documentada de esas detecciones puede ayudar a identificar dónde una investigación automatizada adicional podría recuperar la cobertura.
La gobernanza debe distinguir entre investigación y respuesta. En la encuesta, el 57% de los equipos exigía una revisión humana antes de cada decisión de la IA de cerrar una alerta. Para las acciones de respuesta, el 44% utilizaba la IA para recomendar acciones que debían realizar las personas, mientras que el 30% permitía la remediación autónoma en casos de bajo riesgo. Ningún encuestado informó haber concedido autonomía total y sin supervisión.
Antes de un piloto, las organizaciones deberían definir qué acciones requieren siempre aprobación, quién puede ampliar los permisos del agente, dónde aparecerán sus hallazgos y quién será responsable de revisar los errores. Comenzar con acceso de investigación de solo lectura y ampliar los permisos gradualmente sigue el mismo enfoque cauteloso que se utiliza al incorporar a un nuevo analista humano.
La lista de preparación propuesta separa la necesidad de contar con IA de la capacidad para implementarla. Puede existir un argumento sólido para la adopción cuando las alertas llegan tarde, los proveedores carecen de contexto, las investigaciones se retrasan, se han desactivado detecciones o los casos difíciles dependen únicamente de unos pocos analistas sénior. La preparación para la implementación, por su parte, depende del acceso a API, de la disponibilidad de contexto sobre activos y usuarios, de estándares de investigación escritos, de reglas de aprobación, de la supervisión de las fuentes de registros, de datos de rendimiento de referencia, de un registro de las detecciones desactivadas y de un plan para utilizar el tiempo devuelto al equipo.
Si el SOC no está preparado, la preparación recomendada consiste principalmente en tareas de configuración y documentación. Los equipos pueden comenzar cerrando las brechas de acceso identificadas mediante la revisión de cinco incidentes, documentando estándares para sus tipos de alertas con mayor volumen y ejecutando un agente junto a los analistas durante varias semanas. Las anulaciones realizadas por los analistas deberían registrarse como información sobre contexto faltante o comportamiento incorrecto. Después, los permisos pueden ampliarse una categoría de acción a la vez.
Construir un agente interno es otra opción, pero la encuesta indica riesgos importantes. Entre los usuarios de IA, el 72% había intentado crear herramientas internas de IA, y el 46% de esos proyectos se abandonó, no llegó a producción o fue sustituido por un producto comercial. Más allá de un prototipo, los equipos deben mantener las integraciones, abordar los cambios de API y los límites de frecuencia, gestionar las obsolescencias de modelos, repetir las evaluaciones y las pruebas de inyección de instrucciones, y conservar registros de auditoría que expliquen las decisiones sobre las alertas.
Prophet Security describe su propia plataforma Prophet AI como compatible con la investigación, la búsqueda de amenazas y la ingeniería de detección. Su agente SOC Analyst consulta herramientas de seguridad y registra las preguntas, las consultas y la evidencia que respaldan las decisiones, mientras que las acciones de respuesta siguen sujetas a los permisos definidos por el cliente y a la aprobación humana predeterminada. Su componente Threat Hunter está diseñado para ejecutar búsquedas de amenazas recién divulgadas e investigaciones programadas, y su componente Detection Engineer utiliza los resultados de las investigaciones y las brechas de cobertura para proponer y probar retrospectivamente detecciones antes de su aprobación.
Según la empresa, los hallazgos de estas funciones se retroalimentan: las investigaciones pueden revelar detecciones ruidosas o ausentes, las búsquedas pueden examinar esas brechas y sus resultados pueden orientar nuevas reglas de detección. Prophet Security también afirma que los datos de los clientes no entrenan sus modelos y que su plano de datos puede ejecutarse dentro de la propia nube privada virtual de un cliente.
Fuentes: The Hacker News.