La Inteligencia Artificial (IA) está penetrando rápidamente en las operaciones de seguridad, pero muchos profesionales aún luchan por convertir la experimentación inicial en valor operacional consistente. Esto se debe a que los SOCs están adoptando IA sin un enfoque intencional de integración operacional.
El problema: Adopción sin operacionalización
Los hallazgos de la SANS SOC Survey 2025 refuerzan esta desconexión:
- 40% de los SOCs usan herramientas de IA/ML sin hacerlas parte definida de las operaciones
- 42% confían en herramientas de IA/ML “out of the box” sin personalización alguna
- 69% de los SOCs aún dependen de procesos manuales o mayormente manuales para reportar métricas
El resultado es un patrón familiar: la IA está presente dentro del SOC pero no operacionalizada. Los analistas la usan informalmente, a menudo con fiabilidad mixta, mientras que el liderazgo no ha establecido aún un modelo consistente sobre dónde pertenece la IA, cómo validar su output, o qué flujos de trabajo son lo suficientemente maduros para beneficiarse de la automatización.
La clave: Alcance estrecho y validación rigurosa
La IA puede mejorar realísticamente la capacidad del SOC, su madurez, repetibilidad de procesos, así como la capacidad y satisfacción del personal. Solo funciona cuando los equipos estrechan el alcance del problema, validan su lógica y tratan el output 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 refinar las que ya existen. Cuando la IA se aplica a una tarea específica y bien acotada, emparejada con un proceso claro de revisión, su impacto se vuelve más predecible y útil.
5 áreas donde la IA puede proporcionar soporte confiable
1. Ingeniería de Detección (Detection Engineering)
La ingeniería de detección trata fundamentalmente de construir alertas de alta calidad que puedan colocarse en un SIEM, pipeline MDR u otro sistema operacional. Para ser viable, la lógica necesita ser desarrollada, probada, refinada y operacionalizada con un nivel de confianza que deje poco espacio para la ambigüedad.
❌ No esperes que la IA arregle deficiencias en DevSecOps o resuelva problemas en el pipeline de alertas.
✅ La IA es útil cuando se aplica a un problema bien definido que puede soportar validación y ajuste operacional continuo.
Ejemplo práctico del curso SANS SEC595: Un ejercicio de machine learning que examina los primeros 8 bytes del stream de un paquete para determinar si el tráfico se reconstruye como DNS. Si la reconstrucción no coincide con nada visto previamente para DNS, el sistema genera una alerta de alta fidelidad.
Este ejemplo granular demuestra una detección implementable e ingenierizada con IA. Al examinar los primeros 8 bytes de un stream de paquetes y verificar si se reconstruyen como DNS basándose en patrones aprendidos en tráfico histórico, creamos un problema de clasificación claro y testeable.
La IA ayuda aquí porque el alcance es estrecho y los criterios de evaluación son objetivos. Lo que la IA no puede hacer es arreglar problemas de alertas vagamente definidos o compensar una disciplina de ingeniería faltante.
2. Threat Hunting (Caza de Amenazas)
La caza de amenazas a menudo se retrata como un lugar donde la IA podría “descubrir” amenazas automáticamente, pero eso pierde el propósito del flujo de trabajo. El hunting no es ingeniería de detección en producción. Debe ser una capacidad de investigación y desarrollo del SOC, donde los analistas exploran ideas, prueban suposiciones y evalúan señales que aún no son lo suficientemente fuertes para una detección operacionalizada.
La IA encaja aquí porque el trabajo es exploratorio. Los analistas pueden usarla para pilotar un enfoque, comparar patrones o verificar si una hipótesis vale la pena investigar. Acelera las primeras etapas del análisis, pero no decide qué importa. El modelo es una herramienta útil, no la autoridad final.
El hunting también alimenta directamente a 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.
⚠️ Precaución: Usa seguridad operacional (OpSec) y protección de información. Solo proporciona información relevante para hunting a sistemas autorizados, IA u otros.
3. Desarrollo y Análisis de Software
Los SOCs modernos funcionan con código. Los analistas escriben Python para automatizar investigaciones, construyen tooling de PowerShell para interrogación de hosts y crean queries de SIEM adaptadas a su entorno. Esta necesidad constante de programación hace que la IA sea un ajuste natural para desarrollo y análisis de software.
✅ La IA puede:
- Producir borradores de código
- Refinar snippets existentes
- Acelerar la construcción de lógica que los analistas previamente construían a mano
❌ Riesgos:
- La IA no entiende el problema subyacente
- Los analistas deben interpretar y validar todo lo que el modelo genera
- Si un analista carece de profundidad en un dominio, el output de IA puede sonar correcto incluso cuando está mal
- Los analistas pueden enviar o confiar en código que no entienden completamente y no ha sido probado adecuadamente
La IA es más efectiva aquí cuando reduce la sobrecarga mecánica. Ayuda a los equipos a llegar a un punto de partida utilizable más rápido. Soporta creación de código en Python, PowerShell o lenguajes de query de SIEM. Pero la responsabilidad de corrección permanece con el humano que entiende el sistema, los datos y las consecuencias operacionales de ejecutar ese código en producción.
💡 Recomendación: Desarrolla guías de estilo apropiadas para código y usa solo bibliotecas y paquetes autorizados (probados y aprobados). Incluye las directrices y requisitos de dependencias como parte de cada prompt, o usa una herramienta de desarrollo de IA/ML que permita configurar estas especificaciones.
4. Automatización y Orquestación
La automatización ha sido parte de las operaciones del SOC durante mucho tiempo, pero la IA está remodelando cómo los equipos diseñan estos flujos de trabajo. En lugar de unir manualmente secuencias de acciones o traducir runbooks en lógica de automatización, los analistas ahora pueden usar IA para redactar el andamiaje.
✅ La IA puede:
- Delinear los pasos
- Proponer lógica de ramificación
- Convertir una descripción en lenguaje natural al formato estructurado que requieren las plataformas de orquestación
❌ Lo que la IA NO puede decidir:
- Cuándo debe ejecutarse la automatización
- Si la acción automatizada debe ejecutarse inmediatamente o presentar información para revisión de un analista primero
Esa elección depende de:
- Tolerancia al riesgo organizacional
- Sensibilidad del entorno
- Acción específica bajo consideración
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 personas, no en el modelo. La IA puede ayudar a construir y refinar el flujo de trabajo, pero nunca debe ser la autoridad que lo activa. Los límites claros mantienen la automatización predecible, explicable y alineada con la postura de riesgo del SOC.
💡 Nota: Habrá un umbral donde el nivel de comodidad de la organización con las automatizaciones permita acción rápida tomada de manera automatizada. Ese nivel de comodidad viene de pruebas extensivas y personas respondiendo a las acciones tomadas por el sistema de automatización de manera oportuna.
5. Reportes y Comunicación
El reporte es uno de los desafíos más persistentes en operaciones de seguridad, no porque los equipos carezcan de habilidad técnica, sino porque traducir esa habilidad en comunicación clara y accionable es difícil de escalar.
El problema:
- 69% de los SOCs aún confían en procesos manuales o mayormente manuales para reportar métricas
- Cuando el reporte es inconsistente, el liderazgo pierde visibilidad
- El contexto se diluye
- Las decisiones operacionales se ralentizan
✅ La IA proporciona una forma inmediata y de bajo riesgo de mejorar el rendimiento de reportes del SOC:
- Estandariza la estructura
- Mejora la claridad
- Ayuda a los analistas a moverse de notas crudas a resúmenes bien formados
- Produce outputs consistentes y legibles que el liderazgo puede interpretar rápidamente
El valor no está en hacer que los reportes suenen pulidos. Está en hacerlos coherentes y comparables. Cuando cada resumen de incidente, reporte semanal o reporte de métricas sigue una estructura predecible, los líderes pueden reconocer tendencias más rápido y priorizar más efectivamente.
Los analistas también recuperan el tiempo que habrían gastado luchando con redacción, formato o explicaciones repetitivas.
Tres tipos de adopción: Taker, Shaper o Maker
A medida que los equipos comienzan a experimentar con IA a través de estos flujos de trabajo, es importante reconocer que no hay un único camino para la adopción. La utilización de IA en SOC puede describirse a través de tres categorías convenientes:
🔹 Taker (Tomador)
Usa herramientas de IA tal como se entregan.
🔹 Shaper (Moldeador)
Ajusta o personaliza esas herramientas para ajustarse al flujo de trabajo.
🔹 Maker (Creador)
Construye algo nuevo, como el ejemplo de detección de machine learning estrechamente acotado descrito anteriormente.
Ejemplos en la práctica:
- Podrías ser Taker y Maker en ingeniería de detección: implementando las reglas de IA de tu proveedor de SIEM, además de crear tus propias detecciones
- La mayoría de equipos son Makers manuales y Takers en reportes (solo usando reportes del sistema de ticketing fuera de caja)
- Podrías ser Shaper en automatización, personalizando parcialmente los runbooks SOAR provistos por el proveedor
- Todos los SOCs deberían estar usando al menos hunts impulsados por IOC provistos por proveedores (eso es ser Taker). Aspirar a hunting impulsado internamente te mueve a la categoría Maker
Conclusión
Lo que importa es que cada flujo de trabajo tenga expectativas claras sobre:
- ✅ Dónde puede usarse la IA
- ✅ Cómo se valida el output
- ✅ Que las actualizaciones se hacen de manera continua
- ✅ Que los analistas siguen siendo responsables de la protección de los sistemas de información
La IA puede mejorar realísticamente la capacidad del SOC cuando se aplica con alcance estrecho, validación rigurosa y responsabilidad humana clara. La oportunidad está en refinar los flujos de trabajo existentes, no en crear nuevas categorías de trabajo que la IA deba resolver automáticamente.
Referencias
- Artículo original: How to Integrate AI into Modern SOC Workflows - The Hacker News
- Autor original: Christopher Crowley, SANS Senior Instructor
- Fuente de datos: SANS SOC Survey 2025
- Curso relacionado: SANS SEC595: Applied Data Science and AI/ML for Cybersecurity
- Evento: SANS Security Central 2026 en Nueva Orleans
