Cómo la IA está transformando la detección de amenazas en el SOC

El SOC tradicional ha llegado a su límite operativo

Los centros de operaciones de seguridad (SOC) se han construido durante más de una década sobre el mismo patrón: SIEM central, reglas de correlación estáticas, analistas L1 que triaje alertas, L2 que investigan y L3 que cazan amenazas de forma proactiva. El problema estructural es conocido en el sector: el volumen de telemetría de seguridad crece cada año, la escasez de analistas cualificados es crónica y la fatiga de alertas —el fenómeno por el que un volumen desproporcionado de avisos resulta ser ruido— degrada tanto el tiempo de respuesta como la retención del equipo.

El informe ENISA Threat Landscape 2025, que analiza 4.875 incidentes de ciberseguridad registrados entre julio de 2024 y junio de 2025, confirma además que la IA generativa se ha incorporado a todas las fases del ciclo de un ataque: los grupos de amenaza usan LLM comerciales, así como modelos manipulados o "jailbroken" (WormGPT, FraudGPT y similares), para automatizar ingeniería social y acelerar el desarrollo de herramientas maliciosas [1]. El phishing sigue siendo el vector de intrusión principal (en torno al 60% de los casos analizados) y la explotación de vulnerabilidades recién publicadas (21,3%) sigue siendo una vía de acceso inicial habitual [1]. En otras palabras: el atacante ya usa IA de forma sistemática. El SOC que no lo hace parte con desventaja estructural.

Este artículo describe, con la cautela que exige un terreno regulatorio todavía en construcción, dónde está aportando valor real la IA en el SOC, qué arquitectura de referencia tiene sentido, qué riesgos introduce el propio uso de estos modelos y qué exige el marco normativo europeo y español a partir de 2026.

Qué cambia realmente con la IA aplicada al SOC

Conviene separar dos generaciones de tecnología que suelen mezclarse en el discurso comercial:

1. Machine learning clásico (clasificadores supervisados, detección de anomalías no supervisada, UEBA): lleva años en producción en SIEM y EDR de mercado, y su aplicación en seguridad no es nueva.
2. LLMs ajustados o aplicados a seguridad, en producción de forma extendida desde 2023-2024: aportan una capa de lenguaje natural sobre los sistemas anteriores — resumen incidentes, generan consultas de búsqueda y asisten al analista en la redacción de hipótesis.

Ninguna de las dos sustituye el juicio humano en la toma de decisiones con impacto en producción. Lo que cambia es dónde se sitúa el cuello de botella: menos tiempo dedicado a clasificar ruido, más tiempo dedicado a investigar lo que de verdad importa.

1. Reducción de falsos positivos

Los clasificadores supervisados entrenados sobre alertas ya etiquetadas por el propio SOC pueden reducir de forma notable el volumen de alertas que llegan a un analista humano. La magnitud exacta de esa reducción depende enteramente del volumen y la calidad del histórico disponible, del ajuste del modelo al entorno específico y de la revisión continua por parte del equipo: no existe un porcentaje universal aplicable a cualquier organización, y cualquier cifra que se comunique a un cliente debe basarse en la medición de su propio entorno tras el despliegue, nunca en benchmarks genéricos de mercado.

2. Threat hunting asistido

La caza de amenazas ha sido históricamente una actividad humana, lenta y dependiente de la experiencia individual del analista. Los enfoques actuales combinan:

• Detección basada en comportamiento (UEBA) con modelos no supervisados que aprenden el patrón normal de una identidad o de un activo y señalan desviaciones.
• Graph analytics sobre logs de identidad y red para detectar movimiento lateral, una técnica que MITRE ATT&CK documenta como TA0008 y que las plataformas SIEM/XDR modernas modelan como grafos de relaciones entre entidades.
• LLMs especializados que ayudan a traducir una hipótesis del analista ("¿hay indicios de beaconing hacia este dominio?") en una consulta técnica sobre la fuente de datos correspondiente, reduciendo la barrera de entrada al lenguaje de consulta de cada herramienta.

3. Correlación multi-fuente

Un SOC moderno integra EDR, firewall, IAM y logs de proveedores cloud, cada uno con su propio esquema y lenguaje de consulta. Usar un esquema común de normalización —Open Cybersecurity Schema Framework (OCSF) o Elastic Common Schema (ECS)— antes de aplicar cualquier capa de IA es una condición previa, no opcional: sin normalización, el modelo aprende ruido específico de cada fuente en lugar de patrones de ataque.

4. Respuesta asistida (SOAR)

Los playbooks de respuesta automatizada evolucionan desde árboles de decisión estáticos hacia flujos donde un modelo propone el siguiente paso en función del contexto del incidente. La recomendación operativa —alineada con el principio de "human-in-the-loop" que recoge el propio marco NIST AI RMF [8]— es que cualquier acción con efecto en producción (aislar un host, revocar credenciales, bloquear tráfico) mantenga aprobación humana explícita, salvo en escenarios de contención predefinidos y de bajo riesgo, acordados de antemano con el cliente.

Arquitectura de referencia recomendada

Una arquitectura híbrida razonable combina capas deterministas y capas de aprendizaje, con el humano siempre en el bucle de decisión:

1. Ingesta y normalización: esquemas comunes (OCSF, ECS) para evitar que el modelo dependa de la sintaxis particular de cada fuente.
2. Capa de detección determinista: reglas Sigma y correlación tradicional, que siguen siendo la base auditable e inmediatamente explicable de cualquier SOC.
3. Capa de machine learning: clasificadores específicos por caso de uso (dominios generados algorítmicamente/DGA, beaconing, phishing), entrenados y reentrenados sobre datos propios del cliente.
4. Capa de asistencia con LLM: resumen de incidentes, generación de consultas, redacción de informes — siempre como apoyo, nunca como decisor autónomo sobre acciones de contención.
5. Capa de validación humana: cualquier acción que afecte a producción pasa por un analista, con trazabilidad de quién aprobó qué y cuándo — un requisito que además exige el ENS para la gestión continuada de la seguridad [4].

Sobre el mito del "SOC sin humanos": ningún organismo serio recomienda eliminar al analista de la ecuación. Los modelos tienen sesgos, pueden alucinar y no comprenden el contexto de negocio de una organización concreta. El rol del analista se desplaza de "clasificador de alertas" a "supervisor del sistema de IA": valida decisiones, corrige errores, alimenta el reentrenamiento y cierra el bucle de mejora continua.

Riesgos que introduce el propio uso de IA en el SOC

Adoptar IA en el SOC no es neutro desde el punto de vista de seguridad: añade una superficie de ataque nueva que el propio SOC debe vigilar.

Envenenamiento de datos y manipulación del modelo (model poisoning)

Si un atacante conoce que una organización usa clasificadores de ML para triaje, puede intentar contaminar el conjunto de entrenamiento inyectando patrones diseñados para pasar desapercibidos como "normales". MITRE ATLAS —el equivalente de ATT&CK para sistemas de inteligencia artificial— documenta de forma estructurada estas técnicas (envenenamiento de datos, evasión de modelo, extracción de modelo, inyección de prompts) y sus mitigaciones asociadas [6]. Cualquier despliegue de ML en el SOC debería incorporar ATLAS a su modelado de amenazas, exactamente igual que se incorpora ATT&CK para TTPs convencionales.

Privacidad y residencia de los datos

Enviar logs de seguridad —que con frecuencia contienen datos personales o información sensible del negocio— a APIs de LLM públicas y externas plantea un riesgo de exfiltración y de incumplimiento normativo (RGPD, y en el caso de proveedores de servicios esenciales, también ENS/NIS2). El uso de modelos desplegados en infraestructura propia, en cloud privada, o de proveedores con residencia de datos garantizada en la UE, es la opción por defecto recomendada, particularmente en entornos regulados. En el caso de Hodeitek, esto es consistente con alojar los datos de clientes en OVHcloud, en territorio de la Unión Europea.

Explicabilidad y trazabilidad

Cualquier decisión automática que escale hacia una acción de bloqueo o contención debe poder explicarse y auditarse a posteriori. Los modelos de caja negra sin capacidad de justificar su salida no son aceptables en entornos sujetos a supervisión regulatoria: el ENS exige trazabilidad de las medidas de seguridad aplicadas [4], y el propio marco NIST AI RMF recoge la explicabilidad como una de las características centrales de un sistema de IA digno de confianza [8].

El marco regulatorio que hay que tener en cuenta en 2026

Reglamento de IA (UE) 2024/1689

El Reglamento (UE) 2024/1689 del Parlamento Europeo y del Consejo, de 13 de junio de 2024, establece un marco de obligaciones graduado por nivel de riesgo del sistema de IA (inaceptable, alto, limitado, mínimo), con un calendario de aplicación escalonado entre 2024 y 2027 [2][3]. No cualquier sistema de IA usado en un SOC es automáticamente "de alto riesgo": la clasificación de riesgo depende de la finalidad prevista y del contexto de despliegue, evaluándose caso por caso según si el sistema encaja en alguna de las categorías del Anexo III del Reglamento. Las obligaciones concretas de cada organización dependen de si actúa como proveedor o como responsable del despliegue (implementador) de cada sistema, algo que conviene analizar con asesoría jurídica específica [2][3].

NIS2 y su transposición en España

La Directiva (UE) 2022/2555 (NIS2) debía transponerse al ordenamiento español antes del 17 de octubre de 2024, siendo España uno de los Estados miembros que incumplió este plazo [5]. La norma española de transposición se ha tramitado como Anteproyecto/Proyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad, y la Comisión Europea mantiene un procedimiento de infracción abierto contra España. A fecha de esta publicación no se ha podido confirmar contra fuente oficial en vivo el estado exacto de tramitación de la ley en el BOE; puede consultarse en boe.es y en el buscador de iniciativas de congreso.es. Hasta la publicación definitiva de la ley, el marco de referencia aplicable en el sector público español sigue siendo el Esquema Nacional de Seguridad.

Esquema Nacional de Seguridad (ENS)

El Real Decreto 311/2022, de 3 de mayo, por el que se regula el ENS, sigue vigente y exige gestión continuada de riesgos, diferenciación de responsabilidades y trazabilidad de las medidas de seguridad aplicadas, con independencia de la tecnología subyacente [4]. Incorporar IA en el SOC no exime de estos requisitos: los refuerza, porque añade una superficie de riesgo adicional que debe documentarse y auditarse igual que cualquier otro componente del sistema de información.

DORA (entidades financieras)

Para clientes del sector financiero sujetos al Reglamento (UE) 2022/2554 (DORA), cualquier proveedor externo de servicios de detección y respuesta basados en IA se convierte en un proveedor de servicios TIC sujeto a las obligaciones de registro, gestión de riesgo de terceros y, en su caso, supervisión directa de proveedores críticos previstas en el Reglamento. Las Normas Técnicas de Regulación (RTS) sobre clasificación de incidentes (2024/1772) y herramientas de gestión de riesgo TIC (2024/1774) fueron adoptadas el 25 de junio de 2024. Las Normas de Implementación (ITS) sobre plantillas del Registro de Información (2024/2956) fueron adoptadas el 29 de noviembre de 2024 y publicadas en el DOUE el 2 de diciembre de 2024. Los detalles de aplicación de estas normas y de futuras RTS/ITS deben verificarse en la versión vigente publicada por las autoridades europeas de supervisión (EBA, ESMA, EIOPA) en el momento de cada despliegue [9].

Pasos prácticos para incorporar IA en un SOC de forma responsable

1. Empezar por el dato, no por el modelo. Antes de evaluar cualquier producto de IA, auditar la calidad, cobertura y normalización de las fuentes de log disponibles. Un modelo entrenado sobre datos inconsistentes produce decisiones inconsistentes.
2. Mantener una línea base determinista. Las reglas de correlación y detección basadas en firmas (Sigma, YARA, IOC conocidos) no desaparecen: siguen siendo la capa explicable y auditable sobre la que se apoya cualquier capa de ML.
3. Definir el perímetro de decisión autónoma. Documentar por escrito qué acciones puede ejecutar un sistema de IA sin aprobación humana (normalmente ninguna con impacto en producción) y cuáles requieren validación explícita de un analista.
4. Incorporar MITRE ATLAS al modelado de amenazas. El propio pipeline de IA del SOC es un activo que hay que proteger, no solo una herramienta de defensa [6].
5. Evaluar la clasificación de riesgo bajo el Reglamento de IA para cada sistema concreto, con asesoría jurídica, antes de asumir compromisos contractuales sobre su funcionamiento [2][3].
6. Mantener residencia y control de los datos. Priorizar despliegues en infraestructura propia o en proveedores con residencia de datos garantizada en la UE, evitando el envío de logs sensibles a APIs públicas sin control contractual sobre su uso.
7. Medir el impacto en el propio entorno, no en benchmarks de mercado. Cualquier mejora de MTTD, MTTR o reducción de falsos positivos debe medirse antes y después del despliegue en la organización concreta, con metodología documentada.
8. Revisar y reentrenar de forma periódica y auditada. Un pipeline de reentrenamiento sin supervisión es, en sí mismo, un vector de manipulación del sistema.

Conclusión

La IA no sustituye al SOC: bien aplicada, lo hace más eficiente al reducir el ruido que llega al analista y acelerar la investigación de lo que de verdad importa. Pero introduce una superficie de riesgo propia —envenenamiento de modelos, fuga de datos, decisiones opacas— que exige gobernanza explícita, y su despliegue en España y la UE debe leerse bajo un marco regulatorio todavía en movimiento: el Reglamento de IA con calendario de aplicación escalonado hasta 2027, una ley de transposición de NIS2 en España aún pendiente de publicación en el BOE en el momento de escribir este artículo, y un Esquema Nacional de Seguridad que sigue exigiendo trazabilidad y gestión continuada de riesgos con independencia de la tecnología usada. Cualquier cifra de mejora concreta —reducción de falsos positivos, MTTD, MTTR— debe medirse en el entorno real del cliente, no citarse como benchmark genérico.

Fuentes

1. ENISA Threat Landscape 2025 (octubre 2025) — https://www.enisa.europa.eu/publications/enisa-threat-landscape-2025
2. Reglamento (UE) 2024/1689 del Parlamento Europeo y del Consejo, de 13 de junio de 2024 (Reglamento de IA), EUR-Lex — https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=es
3. BOE — DOUE-L-2024-81079, Reglamento de Inteligencia Artificial — https://www.boe.es/buscar/doc.php?id=DOUE-L-2024-81079
4. Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad, BOE-A-2022-7191 — https://www.boe.es/buscar/act.php?id=BOE-A-2022-7191
5. Directiva (UE) 2022/2555 (NIS2), EUR-Lex — https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32022L2555
6. MITRE ATLAS — Adversarial Threat Landscape for Artificial-Intelligence Systems — https://atlas.mitre.org/ ; repositorio de referencia: https://github.com/mitre/advmlthreatmatrix
7. INCIBE — Inteligencia Artificial (IA) y ciberseguridad — https://www.incibe.es/ciudadania/tematicas/inteligencia-artificial
8. NIST AI Risk Management Framework (AI RMF 1.0) — https://www.nist.gov/itl/ai-risk-management-framework
9. Reglamento (UE) 2022/2554 (DORA), EUR-Lex — https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32022R2554

Fuentes

• Reglamento (UE) 2024/1689 del Parlamento Europeo y del Consejo, de 13 de junio de 2024, por el que se establecen normas armonizadas en materia de inteligencia artificial — https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=es
• BOE — DOUE-L-2024-81079, Reglamento de Inteligencia Artificial — https://www.boe.es/buscar/doc.php?id=DOUE-L-2024-81079
• Directiva (UE) 2022/2555 (NIS2), EUR-Lex — https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32022L2555
• Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad — BOE-A-2022-7191 — https://www.boe.es/buscar/act.php?id=BOE-A-2022-7191
• ENISA Threat Landscape 2025 (octubre 2025) — https://www.enisa.europa.eu/publications/enisa-threat-landscape-2025
• MITRE ATLAS — Adversarial Threat Landscape for Artificial-Intelligence Systems — https://atlas.mitre.org/ y repositorio https://github.com/mitre/advmlthreatmatrix
• INCIBE — Inteligencia Artificial (IA) y ciberseguridad — https://www.incibe.es/ciudadania/tematicas/inteligencia-artificial
• NIST AI Risk Management Framework (AI RMF 1.0) — https://www.nist.gov/itl/ai-risk-management-framework