La inteligencia artificial (IA) se está abriendo camino rápidamente en las operaciones de seguridad, pero muchos profesionales todavía están luchando por convertir la experimentación temprana en un valor operativo consistente. Esto se debe a que los SOC están adoptando la IA sin un enfoque intencional de integración operativa. Algunos equipos lo tratan como un atajo para procesos rotos. Otros intentan aplicar el aprendizaje automático a problemas que no están bien definidos.
Hallazgos de nuestra encuesta SANS SOC 2025 reforzar esa desconexión. Una parte importante de las organizaciones ya está experimentando con IA, sin embargo, el 40 por ciento de los SOC utilizan herramientas de IA o ML sin convertirlas en una parte definida de las operaciones, y el 42 por ciento depende de herramientas de IA/ML «listas para usar» sin ninguna personalización. El resultado es un patrón familiar. La IA está presente dentro del SOC pero no operativa. Los analistas lo utilizan de manera informal, a menudo con confiabilidad mixta, mientras que el liderazgo aún no ha establecido un modelo consistente sobre dónde pertenece la IA, cómo se debe validar su producción o qué flujos de trabajo son lo suficientemente maduros para beneficiarse del aumento.
La IA puede mejorar de manera realista la capacidad del SOC, la madurez, la repetibilidad de los procesos, así como la capacidad y la satisfacción del personal. Solo funciona cuando los equipos reducen el alcance del problema, validan su lógica y tratan el resultado con el mismo rigor que esperan de cualquier esfuerzo de ingeniería. La oportunidad no está en crear nuevas categorías de trabajo, sino en perfeccionar las que ya existen y permitir pruebas, desarrollo y experimentación para expandir las capacidades existentes. Cuando la IA se aplica a una tarea específica y bien delimitada y se combina con un proceso de revisión claro, su impacto se vuelve más predecible y más útil.
Aquí hay cinco áreas donde la IA puede brindar soporte confiable para su SOC.
1. Ingeniería de detección
La ingeniería de detección consiste fundamentalmente en crear una alerta de alta calidad que pueda colocarse en un SIEM, un canal MDR u otro sistema operativo. Para que sea viable, la lógica debe desarrollarse, probarse, perfeccionarse y ponerse en práctica con un nivel de confianza que deje poco lugar a la ambigüedad. Aquí es donde la IA tiende a aplicarse de manera ineficaz.
A menos que sea el resultado deseado, no asuma que la IA solucionará las deficiencias en DevSecOps o resolverá problemas en el proceso de alertas. La IA puede resultar útil cuando se aplica a un problema bien definido que pueda respaldar la validación y el ajuste operativos continuos. Un claro ejemplo de la SANS SEC595: Ciencia de datos aplicada e IA/ML para la ciberseguridad El curso es un ejercicio de aprendizaje automático que examina los primeros ocho bytes del flujo de un paquete para determinar si el tráfico se reconstruye como DNS. Si la reconstrucción no coincide con nada visto anteriormente para DNS, el sistema genera una alerta de alta fidelidad. El valor proviene de la precisión de la tarea y la calidad del proceso de formación, no de una amplia automatización. La implementación prevista es inspeccionar todos los flujos en UDP/53 (y TCP/53) y evaluar la pérdida de reconstrucción de un codificador automático sintonizado con aprendizaje automático. Las corrientes que violan el umbral se marcan como anómalas.
Este ejemplo granular demuestra una detección implementable diseñada por IA. Al examinar los primeros ocho bytes de un flujo de paquetes y verificar si se reconstruyen como DNS basándose en patrones aprendidos en el tráfico histórico, creamos un problema de clasificación claro y comprobable. Cuando esos bytes no coinciden con el aspecto normal del DNS, el sistema alerta. La IA ayuda aquí porque el alcance es limitado y los criterios de evaluación objetivos. Puede ser más eficaz que una detección heurística basada en reglas porque aprende a codificar/decodificar lo que le resulta familiar. Las cosas que no son familiares (en este caso, DNS) no se pueden codificar/decodificar correctamente. Lo que la IA no puede hacer es solucionar problemas de alerta vagamente definidos o compensar una disciplina de ingeniería faltante.
2. Caza de amenazas
La búsqueda de amenazas a menudo se presenta como un lugar donde la IA podría «descubrir» amenazas automáticamente, pero eso no cumple con el propósito del flujo de trabajo. La caza no es ingeniería de detección de producción. Debería ser una capacidad de investigación y desarrollo del SOC, donde los analistas exploren ideas, prueben suposiciones y evalúen señales que aún no son lo suficientemente fuertes para una detección operativa. Esto es necesario porque el panorama de vulnerabilidades y amenazas está cambiando rápidamente y las operaciones de seguridad deben adaptarse constantemente a la volatilidad e incertidumbre del universo de aseguramiento de la información.
La IA encaja aquí porque el trabajo es exploratorio. Los analistas pueden utilizarlo para poner a prueba un enfoque, comparar patrones o comprobar si vale la pena investigar una hipótesis. Acelera las primeras etapas del análisis, pero no decide lo que importa. El modelo es una herramienta útil, no la autoridad final.
La caza también influye directamente en la ingeniería de detección. La IA puede ayudar a generar lógica candidata o resaltar patrones inusuales, pero los analistas siguen siendo responsables de interpretar el entorno y decidir qué significa una señal. Si no pueden evaluar los resultados de la IA o explicar por qué algo es importante, es posible que la caza no produzca nada útil. El beneficio de la IA aquí es la velocidad y la amplitud de la exploración, más que la certeza o el juicio. Le advertimos que utilice seguridad operativa (OpSec) y protección de la información. Proporcione únicamente información relevante para la caza a sistemas autorizados, IA u otros.
3. Desarrollo y análisis de software
Los SOC modernos se ejecutan con código. Los analistas escriben Python para automatizar investigaciones, crear herramientas PowerShell para interrogar al host y elaborar consultas SIEM adaptadas a su entorno. Esta necesidad constante de programación hace que la IA sea una opción natural para el desarrollo y análisis de software. Puede producir borradores de código, refinar fragmentos existentes o acelerar la construcción lógica que los analistas previamente construyeron a mano.
Pero la IA no comprende el problema subyacente. Los analistas deben interpretar y validar todo lo que genera el modelo. Si un analista carece de profundidad en un dominio, el resultado de la IA puede parecer correcto incluso cuando es incorrecto, y es posible que el analista no tenga forma de notar la diferencia. Esto crea un riesgo único: los analistas pueden enviar o confiar en un código que no comprenden completamente y que no ha sido probado adecuadamente.
La IA es más eficaz aquí cuando reduce los gastos mecánicos. Ayuda a los equipos a llegar más rápido a un punto de partida utilizable. Admite la creación de código en lenguajes de consulta Python, PowerShell o SIEM. Pero la responsabilidad de la corrección recae en el ser humano que comprende el sistema, los datos y las consecuencias operativas de ejecutar ese código en producción.
El autor sugiere que el equipo desarrolle pautas de estilo apropiadas para el código y utilice únicamente bibliotecas y paquetes autorizados (es decir, probados y aprobados). Incluya las pautas y los requisitos de dependencia como parte de cada mensaje, o utilice una herramienta de desarrollo de IA/ML que permita la configuración de estas especificaciones.
4. Automatización y orquestación
La automatización ha sido durante mucho tiempo parte de las operaciones de SOC, pero la IA está cambiando la forma en que los equipos diseñan estos flujos de trabajo. En lugar de unir manualmente secuencias de acción o traducir runbooks a lógica de automatización, los analistas ahora pueden usar IA para redactar el andamiaje. La IA puede delinear los pasos, proponer una lógica de ramificación e incluso convertir una descripción en lenguaje sencillo al formato estructurado que requieren las plataformas de orquestación.
Sin embargo, la IA no puede decidir cuándo debe ejecutarse la automatización. La pregunta central en la orquestación permanece sin cambios: ¿la acción automatizada debería ejecutarse inmediatamente o debería presentar información para que un analista la revise primero? Esa elección depende de la tolerancia al riesgo de la organización, la sensibilidad del entorno y la acción específica que se esté considerando.
Ya sea que la plataforma sea un SOAR, MCP o cualquier otro sistema de orquestación, la responsabilidad de iniciar una acción debe recaer en las personas, no en el modelo. La IA puede ayudar a construir y perfeccionar el flujo de trabajo, pero nunca debería ser la autoridad la que lo active. Los límites claros mantienen la automatización predecible, explicable y alineada con la postura de riesgo del SOC.
Habrá un umbral en el que el nivel de comodidad de la organización con las automatizaciones permitirá tomar medidas rápidas de forma automatizada. Ese nivel de comodidad proviene de pruebas exhaustivas y de personas que responden a las acciones tomadas por el sistema de automatización de manera oportuna.
5. Informes y comunicación
La presentación de informes es uno de los desafíos más persistentes en las operaciones de seguridad, no porque los equipos carezcan de habilidades técnicas, sino porque traducir esa habilidad en una comunicación clara y procesable es difícil de escalar. El Encuesta SANS SOC 2025 pone de relieve lo rezagada que sigue esta zona: El 69 por ciento de los SOC todavía dependen de procesos manuales o mayoritariamente manuales para informar métricas.. Esta brecha importa. Cuando los informes son inconsistentes, el liderazgo pierde visibilidad, el contexto se diluye y las decisiones operativas se ralentizan.
La IA proporciona una forma inmediata y de bajo riesgo de mejorar el rendimiento de los informes del SOC. Puede suavizar las partes mecánicas de los informes al estandarizar la estructura, mejorar la claridad y ayudar a los analistas a pasar de notas sin formato a resúmenes bien formados. En lugar de que cada analista escriba en un estilo diferente o entierre el liderazgo en detalles técnicos, la IA ayuda a producir resultados consistentes y legibles que los líderes pueden interpretar rápidamente. Incluir promedios móviles, límites de desviación estándar y resaltar la coherencia general del SOC es una historia que vale la pena contarle a su gerencia.
El valor no está en hacer que los informes suenen pulidos. esta en hacerlos coherente y comparable. Cuando cada resumen de incidentes, resumen semanal o informe de métricas sigue una estructura predecible, los líderes pueden reconocer las tendencias más rápido y priorizar de manera más efectiva. Los analistas también recuperan el tiempo que habrían dedicado a luchar con la redacción, el formato o las explicaciones repetitivas.
¿Es usted un tomador, un moldeador o un creador? Hablemos en SANS Security Central 2026
A medida que los equipos comienzan a experimentar con la IA en estos flujos de trabajo, es importante reconocer que no existe un camino único para la adopción. La utilización de SOC AI se puede describir mediante tres categorías convenientes. A tomador utiliza herramientas de IA tal como se entregan. A moldeador ajusta o personaliza esas herramientas para adaptarse al flujo de trabajo. A fabricante construye algo nuevo, como el ejemplo de detección de aprendizaje automático de alcance estricto descrito anteriormente.
Todos estos casos de uso de ejemplo pueden estar en una o más categorías. Puede ser tanto un tomador como un creador en ingeniería de detección, implementando las reglas de IA de su proveedor SIEM, además de crear sus propias detecciones. La mayoría de los equipos hacen y toman manuales (simplemente utilizan informes del sistema de emisión de tickets listos para usar) en la generación de informes. Podría ser un moldeador en automatización, personalizando parcialmente los runbooks SOAR proporcionados por los proveedores. Con suerte, al menos estás utilizando búsquedas impulsadas por el COI proporcionadas por los proveedores; eso es algo que todo SOC debe hacer. Aspirar a la caza impulsada internamente te lleva a esa categoría de creador.
Lo que importa es que cada flujo de trabajo tenga expectativas claras sobre dónde se puede utilizar la IA, cómo se validan los resultados, que las actualizaciones se realizan de forma continua y que, en última instancia, los analistas siguen siendo responsables de la protección de los sistemas de información.
Exploraré estos temas con más profundidad durante mi sesión magistral en Central de seguridad SANS 2026 en Nueva Orleans. Aprenderá cómo evaluar dónde se encuentra su SOC hoy y diseñar un modelo de adopción de IA que fortalezca la experiencia de su equipo. Espero verte allí!
Regístrese para SANS Security Central 2026 aquí.
Nota: Este artículo fue escrito y contribuido de manera experta por Christopher Crowley, instructor senior de SANS.