La inteligencia artificial (IA) se está incorporando rápidamente a las operaciones de seguridad, pero muchos profesionales siguen esforzándose por convertir la experimentación temprana en un valor operativo constante. Esto se debe a que los SoC están adoptando la IA sin un enfoque intencional de la integración operativa. Algunos equipos lo tratan como un atajo para los procesos interrumpidos. Otros intentan aplicar el aprendizaje automático a problemas que no están bien definidos.

Hallazgos de nuestra encuesta SANS SOC de 2025 refuerce esa desconexión. Una parte importante de las organizaciones ya está experimentando con la IA, pero el 40 por ciento de los SoC utilizan herramientas de IA o aprendizaje automático sin convertirlas en una parte definida de las operaciones, y el 42 por ciento confía en herramientas de inteligencia artificial y aprendizaje automático «listas para usar», sin ningún tipo de personalización. El resultado es un patrón conocido. La IA está presente en el SOC, pero no está operativa. Los analistas la utilizan de manera informal, a menudo con una fiabilidad desigual, mientras que los directivos aún no han establecido un modelo coherente sobre el lugar en el que se encuentra la IA, cómo deben validarse sus resultados o qué flujos de trabajo son lo suficientemente maduros como para beneficiarse del aumento.

La IA puede mejorar de manera realista la capacidad, la madurez y la repetibilidad de los procesos del SOC, 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 los resultados 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 y permitir las pruebas, el desarrollo y la experimentación para ampliar 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 útil.

Estas son cinco áreas en las que la IA puede brindar un 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 se pueda colocar en un SIEM, una canalización de MDR u otro sistema operativo. Para que sea viable, la lógica debe desarrollarse, probarse, refinarse y operacionalizarse con un nivel de confianza que deje poco margen para la ambigüedad. Aquí es donde la IA tiende a aplicarse de manera ineficaz.

A menos que sea el resultado objetivo, no dé por sentado que la IA solucionará las deficiencias en DevSecOps ni resolverá los problemas en la canalización de alertas. La IA puede resultar útil cuando se aplica a un problema bien definido que puede respaldar la validación y el ajuste operativos continuos. Un ejemplo claro del SANS SEC595: ciencia de datos aplicada e AI/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 el DNS, el sistema emite una alerta de alta fidelidad. El valor proviene de la precisión de la tarea y de la calidad del proceso de formación, no de una automatización generalizada. La implementación prevista consiste en inspeccionar todos los flujos en el UDP/53 (y TCP/53) y evaluar las pérdidas de reconstrucción con un codificador automático optimizado para el aprendizaje automático. Las transmisiones que infringen el umbral se marcan como anómalas.

Este ejemplo granular demuestra una detección implementable diseñada por IA. Al examinar los ocho primeros bytes de un flujo de paquetes y comprobar si se reconstruyen como DNS en función de los 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 emite una alerta. La IA ayuda en este sentido porque el alcance es limitado y los criterios de evaluación son objetivos. Puede ser más eficaz que una detección heurística basada en reglas porque aprende a codificar y decodificar lo que le resulta familiar. Lo que no es familiar (en este caso, el DNS) no se puede codificar ni decodificar correctamente. Lo que la IA no puede hacer es solucionar los problemas de alerta vagamente definidos o compensar la falta de una disciplina de ingeniería.

2. Caza de amenazas

La búsqueda de amenazas se suele describir como un lugar en el que 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, en la que los analistas exploren ideas, comprueben suposiciones y evalúen las señales que aún no son lo suficientemente potentes como para poder detectarlas de manera 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 la garantía de la información.

La IA encaja aquí porque el trabajo es exploratorio. Los analistas pueden utilizarla 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 qué es lo que importa. El modelo es una herramienta útil, no la autoridad final.

La caza también contribuye directamente a la ingeniería de detección. La IA puede ayudar a generar la lógica de los candidatos o a 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 ni explicar por qué algo es importante, es posible que la búsqueda no produzca nada útil. La ventaja de la IA reside en la velocidad y la amplitud de la exploración, más que en la certeza o el juicio. Le recomendamos que utilice la seguridad operativa (OpSec) y la protección de la información. Proporcione únicamente información relevante para la caza a los sistemas autorizados, a la IA o a otros sistemas.

3. Desarrollo y análisis de software

Los SoC modernos funcionan con código. Los analistas escriben Python para automatizar las investigaciones, crear herramientas de PowerShell para interrogar a los anfitriones y crear consultas de SIEM adaptadas a su entorno. Esta necesidad constante de programación convierte a la IA en una opción natural para el desarrollo y el análisis de software. Puede producir borradores de código, refinar fragmentos existentes o acelerar la construcción lógica que los analistas construían previamente a mano.

Sin embargo, la IA no entiende el problema subyacente. Los analistas deben interpretar y validar todo lo que genera el modelo. Si un analista carece de profundidad en un dominio, los resultados de la IA pueden parecer correctos incluso cuando son incorrectos, y es posible que el analista no tenga forma de notar la diferencia. Esto crea un riesgo único: los analistas pueden utilizar código que no comprenden del todo y que no se han probado adecuadamente o utilizar ese código.

La IA es más eficaz en este caso cuando reduce la sobrecarga mecánica. Ayuda a los equipos a llegar más rápido a un punto de partida utilizable. Admite la creación de código en los lenguajes de consulta Python, PowerShell o SIEM. Sin embargo, la responsabilidad de la corrección recae en la persona que entiende 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 solo use bibliotecas y paquetes autorizados (es decir, probados y aprobados). Incluya las directrices y los requisitos de dependencia como parte de cada solicitud, o utilice una herramienta de desarrollo de inteligencia artificial y aprendizaje automático que permita configurar estas especificaciones.

4. Automatización y orquestación

La automatización forma parte desde hace mucho tiempo de las operaciones del SOC, pero la IA está cambiando la forma en que los equipos diseñan estos flujos de trabajo. En lugar de unir manualmente las secuencias de acción o traducir los manuales de ejecución a la lógica de automatización, los analistas ahora pueden usar la IA para diseñar el andamiaje. La IA puede delinear los pasos, proponer una lógica ramificada 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 de la orquestación permanece inalterada: ¿la acción automatizada debe ejecutarse de inmediato o debe presentar información para que un analista la revise primero? Esa elección depende de la tolerancia al riesgo de la organización, de la sensibilidad del entorno y de la acción específica que se esté considerando.

Ya sea que la plataforma sea un SOAR, un 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 crear y refinar el flujo de trabajo, pero nunca debe ser la autoridad la que lo active. Los límites claros hacen que la automatización sea 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 permita tomar medidas rápidas de forma automatizada. Ese nivel de comodidad proviene de pruebas exhaustivas y de que las personas responden a las acciones emprendidas 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 de 2025 pone de relieve lo mucho que queda por detrás de esta área: El 69 por ciento de los SoC aún dependen de procesos manuales o en su mayoría manuales para informar sobre las 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 la presentación de informes al estandarizar la estructura, mejorar la claridad y ayudar a los analistas a pasar de las notas sin procesar a los resúmenes bien estructurados. En lugar de que cada analista escriba con un estilo diferente o oculte los detalles técnicos, la IA ayuda a producir resultados coherentes y legibles que los directivos pueden interpretar rápidamente. Incluir las medias móviles, los límites de la desviación estándar y destacar la coherencia general del SOC es una historia que vale la pena contar a la dirección.

El valor no está en hacer que los informes suenen refinados. Está 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 con mayor rapidez y priorizar con mayor eficacia. Los analistas también recuperan el tiempo que habrían dedicado a lidiar con la redacción, el formato o las explicaciones repetitivas.

¿Eres 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 una ruta única para la adopción. La utilización de la IA en el SOC se puede describir mediante tres categorías prácticas. A tomador utiliza las herramientas de IA tal como se entregan. UN moldeador ajusta o personaliza esas herramientas para que se ajusten al flujo de trabajo. A fabricante crea algo nuevo, como el ejemplo de detección de aprendizaje automático con un alcance estricto descrito anteriormente.

Todos estos ejemplos de casos de uso pueden estar en una o más de las categorías. Puede que seas tanto un experto en ingeniería de detección como un creador, implementar las reglas de inteligencia artificial de tu proveedor de SIEM y crear tus propias detecciones. La mayoría de los equipos se dedican tanto a la elaboración manual como a la elaboración de informes (solo utilizan los informes listos para usar del sistema de venta de entradas) a la hora de elaborar informes. Es posible que le guste modelar la automatización y personalizar parcialmente los libros de ejecución de SOAR proporcionados por el proveedor. Es de esperar que al menos estés utilizando cacerías impulsadas por el IOC proporcionadas por el proveedor; eso es algo que todo SOC debe hacer. Si aspiras a una cacería impulsada internamente, entrarás en esa categoría de creadores.

Lo que importa es que cada flujo de trabajo tenga expectativas claras sobre dónde se puede usar la IA, cómo se validan los resultados, que las actualizaciones se realizan de forma continua y que los analistas, en última instancia, sigan siendo responsables de la protección de los sistemas de información.

Exploraré estos temas con más profundidad durante mi sesión principal en Central de seguridad SANS 2026 en Nueva Orleans. Aprenderás a evaluar la situación actual de tu SOC y a diseñar un modelo de adopción de la IA que refuerce la experiencia de tu equipo. ¡Espero verte allí!

Regístrese en SANS Security Central 2026 aquí.

Nota: Este artículo fue escrito y contribuido de manera experta por Christopher Crowley, instructor sénior de SANS.

¿Te ha parecido interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en Noticias de Google , Twitter y LinkedIn para leer más contenido exclusivo que publicamos.