IA en el SOC con humano en el bucle: dónde acelera de verdad y dónde dispara el riesgo regulatorio

Automatizar un SOC con IA suena estupendo hasta que llega la pregunta incómoda: ¿quién responde cuando el sistema se equivoca? No es una cuestión filosófica. Es regulatoria, operativa y bastante menos futurista de lo que algunos proveedores de “copilotos” querrían vender.

La discusión suele degradarse rápido. Unos repiten que la IA multiplicará la productividad del analista. Otros responden con el reflejo opuesto: mejor no tocar nada que pueda comprometer investigación, notificación o evidencia. Ninguno de los dos extremos sirve demasiado si trabajas en una entidad sujeta a DORA, NIS2 o GDPR. Lo que importa no es si usas IA, sino dónde la insertas, qué margen de decisión le das y cómo demuestras control cuando algo falla.

Ese es el punto que muchas organizaciones todavía no han aterrizado. El debate sobre IA en ciberseguridad sigue lleno de promesas vagas, mientras las obligaciones jurídicas ya están escritas con bastante menos romanticismo. DORA exige marcos de gestión de riesgos TIC y gobernanza clara; NIS2 obliga a medidas técnicas, operativas y organizativas apropiadas y proporcionadas; GDPR impone plazos concretos de notificación y principios de responsabilidad proactiva. Ninguna de esas normas concede una exención mágica por haber delegado parte del trabajo en un modelo.

Y ahí está la paradoja útil: cuanto más “autónoma” parece la operación, más importante se vuelve la trazabilidad humana. No porque lo diga una moda de gobernanza, sino porque las normas europeas piden algo muy simple de formular y bastante incómodo de ejecutar: que sepas qué ha pasado, quién decidió qué y con qué base.

El problema no es usar IA en el SOC. El problema es usarla como si no cambiara nada

Buena parte del discurso comercial trata la IA como una capa de eficiencia. Un acelerador. Un asistente. Un sistema que resume alertas, correlaciona eventos o sugiere respuestas. Puede serlo. Pero en términos de compliance, ese mismo sistema también puede alterar la forma en que una organización detecta, clasifica, documenta y escala incidentes. Y eso ya no es una cuestión de ergonomía; entra de lleno en obligaciones de resiliencia, seguridad y accountability.

DORA, por ejemplo, no regula la IA como tecnología separada, pero sí obliga a las entidades financieras a disponer de un marco sólido de gestión del riesgo relacionado con las TIC. El artículo 6 exige un marco interno de gobernanza y control que garantice una gestión eficaz y prudente del riesgo TIC. El artículo 8 aterriza la protección y prevención; el 10 se centra en detección; el 11, en respuesta y recuperación. Si introduces automatización en la priorización de alertas o en la recomendación de acciones de contención, esa automatización pasa a formar parte del sistema real de gestión del riesgo. Tratarla como si fuera un complemento inocuo sería, jurídicamente, una fantasía cara.

NIS2 va por la misma línea. El artículo 21 obliga a las entidades esenciales e importantes a adoptar medidas apropiadas y proporcionadas para gestionar riesgos que afecten a la seguridad de redes y sistemas de información. Ese mismo artículo enumera, entre otras, políticas de análisis de riesgos, gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, evaluación de la eficacia de medidas y prácticas básicas de ciberhigiene. Si una herramienta de IA participa en detección o respuesta, no está fuera del perímetro de esas obligaciones. Está dentro, con todas las consecuencias.

GDPR añade otra capa menos cómoda aún. Si un incidente de seguridad implica datos personales, los artículos 33 y 34 activan obligaciones de notificación a la autoridad de control y, en ciertos casos, a los interesados. El artículo 5.2 consagra la responsabilidad proactiva. El 24 obliga al responsable a aplicar medidas apropiadas y poder demostrarlo. Y el 32 exige seguridad adecuada al riesgo. Dicho sin rodeos: si una organización usa automatización en procesos que afectan a la detección, clasificación o escalado de un incidente con impacto en datos personales, luego tendrá que poder explicar cómo funcionó ese circuito y por qué era razonable.

La consecuencia práctica es sencilla de formular y menos sencilla de implantar: la IA en un SOC no puede gobernarse como una simple mejora de productividad. Debe gobernarse como un componente que influye en decisiones de seguridad y, por tanto, en obligaciones legales.

Lo que sí puede decirse con rigor sobre ENISA, sin poner palabras que no ha dicho

Aquí conviene pisar terreno firme. ENISA ha trabajado sobre inteligencia artificial y ciberseguridad y mantiene recursos específicos sobre el tema. Eso permite una conclusión prudente y verificable: la agencia considera la intersección entre IA y ciberseguridad un ámbito relevante de análisis técnico y de gestión de riesgos. Lo que no conviene hacer es atribuirle eslóganes que no aparecen en la fuente o convertir una página temática en una toma de posición concreta sobre cómo debe desplegarse IA en un SOC.

La distinción importa. No por purismo académico, sino porque en regulación la precisión paga facturas y evita problemas. Si una empresa quiere justificar un diseño operativo o una arquitectura de control, necesitará apoyarse en textos normativos, guías técnicas o políticas internas verificables. “ENISA viene diciendo” sirve para una tertulia; para una auditoría, bastante menos.

Lo útil de ENISA en este terreno no es inventarle una consigna, sino leer la señal correcta: la IA no debe tratarse como objeto publicitario, sino como tecnología que introduce nuevas superficies de riesgo y nuevas exigencias de aseguramiento. Esa lectura es coherente con el enfoque europeo general sobre seguridad, resiliencia y gobernanza.

La pregunta correcta no es si la IA decide sola, sino qué parte del flujo condiciona

Muchas discusiones sobre “autonomía” están mal planteadas. Se centran en si la máquina toma la decisión final, cuando el verdadero problema operativo suele estar antes. Un sistema puede no cerrar un incidente por sí mismo y, aun así, influir de forma decisiva en qué alertas se investigan primero, cuáles se agrupan como ruido, qué activos se consideran más críticos o qué respuesta aparece como recomendación por defecto.

Ese tipo de influencia importa porque los marcos regulatorios no se activan solo por la decisión terminal, sino por la eficacia global del proceso. DORA no te pedirá una medalla por conservar un clic humano al final de una cadena mal diseñada. NIS2 tampoco distingue entre un error “manual” y un error inducido por automatización si el resultado es una gestión deficiente del riesgo. Y GDPR no reduce la responsabilidad porque el analista haya aceptado una sugerencia errónea generada por una herramienta si la organización no había establecido salvaguardas suficientes.

Por eso la gobernanza seria de IA en un SOC empieza mapeando puntos de intervención, no redactando manifiestos sobre innovación responsable. ¿Dónde resume? ¿Dónde prioriza? ¿Dónde clasifica? ¿Dónde recomienda? ¿Dónde ejecuta? ¿Dónde documenta? En cada uno de esos puntos cambia algo distinto: la calidad del dato, la velocidad de análisis, la consistencia, el riesgo de sesgo, la explicabilidad o la capacidad de reconstrucción posterior.

Si tu entidad no tiene ese mapa, ya tienes el primer problema. No porque lo exija una palabra de moda, sino porque sin ese mapa no podrás enlazar controles técnicos con obligaciones de DORA, NIS2 o GDPR.

Del riesgo abstracto al expediente real: qué debe poder demostrar una entidad

La mejor forma de aterrizar el debate es preguntarse qué te pedirán cuando haya un incidente serio, una revisión supervisora o una auditoría interna bien hecha. La respuesta, simplificando poco, suele girar alrededor de cinco pruebas documentales.

Primero, una explicación clara del rol de la herramienta dentro del proceso de seguridad. No una ficha comercial, sino una descripción operativa: entradas, salidas, umbrales, dependencia de datos, casos de uso autorizados y decisiones que apoya o no apoya.

Segundo, una asignación de responsabilidades. DORA insiste en la responsabilidad del órgano de dirección en materia de riesgo TIC, especialmente en los artículos 5 y 6. Si la organización ha desplegado IA en funciones sensibles, debe quedar claro qué primera línea la usa, qué segunda línea la valida, quién aprueba cambios materiales y quién interviene cuando el sistema se desvía.

Tercero, evidencia de evaluación y revisión. NIS2 art. 21 no se satisface comprando tecnología; exige medidas apropiadas y proporcionadas, además de evaluar su eficacia. Si el sistema genera recomendaciones de triage o respuesta, la entidad necesita verificar si su rendimiento y sus errores siguen siendo aceptables en relación con el riesgo que gestiona.

Cuarto, trazabilidad suficiente para reconstruir decisiones. Esto conecta con DORA en detección y respuesta, con los deberes de registro y documentación operativa que las entidades ya conocen, y con GDPR cuando hay datos personales comprometidos. Si después de un incidente nadie puede explicar por qué una alerta quedó en cola o por qué una acción de contención se recomendó como prioritaria, lo que falla no es solo la herramienta; falla el control interno.

Quinto, integración con terceros. Si la capacidad de IA llega vía proveedor —SaaS, MDR, XDR, SIEM gestionado o plugin de un hyperscaler— entra de lleno la disciplina sobre terceros TIC. DORA dedica el capítulo V a la gestión del riesgo de terceros prestadores de servicios TIC y el artículo 28 fija principios clave sobre esa gestión. Traducido: no basta con confiar en que el proveedor “ya lo tiene cubierto”. Tendrás que saber qué hace exactamente, con qué dependencias, bajo qué condiciones contractuales y con qué derechos de acceso, auditoría o información.

No hace falta exagerar los efectos para entender el riesgo regulatorio

Se ha dicho muchas veces que la IA puede trastocar un proceso de incidente. A veces es verdad; otras, es dramatización decorativa. Lo que puede afirmarse con prudencia es algo más sólido: cuando una organización introduce automatización en detección, clasificación, análisis o respuesta, debe revisar si esa automatización afecta a sus procesos de gestión de incidentes, documentación, escalado y comunicación. Y debe hacerlo antes de presumir de eficiencia.

Esa revisión no es opcional por una razón bastante pedestre. Los plazos y obligaciones regulatorias no esperan a que el equipo descubra, en mitad de una crisis, que llevaba meses apoyándose en una lógica de priorización que nadie había validado de forma seria. Bajo GDPR art. 33, la notificación a la autoridad debe hacerse sin dilación indebida y, cuando sea posible, no más tarde de 72 horas desde que el responsable tenga constancia de la violación de seguridad de los datos personales. Ese reloj no se detiene porque el flujo interno dependa de automatizaciones mal calibradas.

Con NIS2 ocurre algo parecido, aunque el régimen concreto depende de la transposición y de cómo cada Estado articule obligaciones de notificación conforme al artículo 23. En cualquier caso, el mensaje es el mismo: si la organización automatiza partes del proceso, luego tendrá que convivir con las consecuencias regulatorias de haberlas automatizado. No con las consecuencias imaginadas por marketing, sino con las reales.

Qué usos de IA en un SOC merecen atención de compliance, aunque no prometamos milagros

No hace falta inventarse una lista universal de “tres casos de uso con valor mensurable” para identificar dónde está el riesgo. Basta con mirar dónde se está desplegando IA con más frecuencia o, al menos, dónde su aplicación resulta técnicamente plausible y operativamente atractiva.

Un primer grupo aparece en el tratamiento inicial de alertas: agrupación, resumen, clasificación preliminar o asistencia para reducir carga analítica. Un segundo grupo se mueve en correlación y enriquecimiento: vincular eventos, proponer contexto adicional, sugerir hipótesis de ataque o generar resúmenes para investigación. Un tercer grupo entra en apoyo a la respuesta: recomendaciones de contención, generación de consultas, automatización asistida en playbooks o ayuda a la documentación del incidente.

La cuestión de compliance no depende de que esos usos “funcionen bien” en abstracto, sino de su proximidad a decisiones con impacto jurídico u operativo. Un sistema que resume logs para ahorrar tiempo plantea un riesgo distinto al que recomienda aislar un activo crítico, elevar un caso a incidente grave o cerrar una alerta como falso positivo. Meterlos en el mismo saco es una forma muy sofisticada de no gobernar nada.

Aquí conviene que el lector haga un ejercicio incómodo: inventariar no solo herramientas, sino microdecisiones. La mayoría de las organizaciones saben qué productos tienen desplegados. Menos saben qué decisiones están mediadas por ellos. Esa ceguera es un problema bastante más serio que la ausencia de un comité con nombre rimbombante.

El “humano en el bucle” no es un eslogan; es un diseño de control

Se invoca mucho y se concreta poco. “Humano en el bucle” puede significar desde supervisión real hasta simple teatro administrativo. Si todo lo que hace el analista es pulsar aceptar sobre una recomendación difícil de cuestionar, con plazos apretados y sin visibilidad sobre la lógica usada, el control humano existe en organigrama, no necesariamente en sustancia.

Más útil que fijar una receta cerrada es definir qué atributos mínimos debe tener ese control para ser creíble. Primero, la persona que revisa debe disponer de información suficiente para entender la recomendación y, en su caso, apartarse de ella con fundamento. Segundo, el proceso debe permitir documentar discrepancias y excepciones, porque sin ese rastro no hay aprendizaje ni defensa posterior. Tercero, la intervención humana debe situarse en puntos de decisión material, no solo al final de una secuencia donde el sesgo de automatización ya ha hecho su trabajo. Cuarto, el personal necesita capacitación específica sobre límites y fallos esperables de la herramienta; de lo contrario, la supervisión se degrada en fe asistida por interfaz.

No hace falta presentar estos elementos como dogma legal textual para entender su relevancia regulatoria. Encajan de forma natural con la lógica de DORA sobre gobernanza y control interno, con NIS2 art. 21 sobre adecuación y proporcionalidad de medidas, y con el principio de responsabilidad proactiva de GDPR. Si una entidad quiere demostrar que mantiene control sobre un proceso apoyado en IA, tendrá que enseñar algo muy parecido a esto, aunque lo llame de otra manera.

El sesgo más peligroso en el SOC no es del modelo. Es organizativo

Hay un error recurrente en el discurso de cumplimiento: presentar el riesgo de IA como si se redujera a alucinaciones, bias o falta de explicabilidad. Todo eso existe, sí. Pero en operaciones de seguridad hay un sesgo quizá más dañino y mucho menos glamuroso: la tendencia de la organización a suponer que, si una herramienta acelera trabajo, también conserva intacta la calidad del juicio.

No siempre ocurre. Y cuando deja de ocurrir, el deterioro puede ser silencioso. El equipo empieza a fiarse de resúmenes en lugar de revisar artefactos originales. Las recomendaciones del sistema definen la agenda analítica del turno. Las excepciones se vuelven raras no porque no existan, sino porque cuestan más tiempo que aceptar la sugerencia. El resultado no tiene por qué ser un desastre inmediato; a veces es peor: una erosión gradual de la capacidad de cuestionar.

Desde el punto de vista regulatorio, ese deterioro es relevante porque vacía de contenido controles que sobre el papel siguen existiendo. Puedes tener política, matriz RACI, playbook y comité. Si en la práctica la operación depende de recomendaciones opacas no sometidas a revisión útil, el control formal sirve sobre todo para decorar auditorías.

La respuesta no pasa por prohibir. Pasa por medir. ¿Qué porcentaje de recomendaciones se acepta sin cambios? ¿Qué tipos de error son más frecuentes? ¿Dónde se concentran las correcciones humanas? ¿Qué decisiones no deberían ser automatizadas ni siquiera de forma asistida? Sin ese nivel de observación, hablar de “adopción responsable” es poco más que literatura corporativa.

DORA cambia una cosa de fondo: ya no vale separar innovación y resiliencia

Durante años, muchas entidades han gestionado herramientas de seguridad avanzadas como si su mera finalidad defensiva las colocara en una categoría más o menos benigna. Si protege, se despliega; los matices vendrán después. DORA complica —con razón— esa comodidad mental.

El reglamento obliga a tratar la resiliencia operativa digital como una disciplina integrada: gobernanza, protección, detección, respuesta, recuperación, pruebas, terceros y aprendizaje. No hay compartimentos estancos especialmente amables para tecnologías “de seguridad”. Si una capacidad basada en IA influye en monitorización, detección o respuesta, su gestión debe alinearse con ese marco general.

El artículo 13, por ejemplo, exige que las entidades dispongan de políticas y procedimientos para gestionar incidentes relacionados con las TIC, incluyendo mecanismos de respuesta, recuperación y comunicación. El artículo 15 se centra en aprender de los incidentes y evolucionar. Eso implica que, si una automatización contribuye a una clasificación errónea, a una priorización defectuosa o a una contención ineficaz, el análisis posterior no puede limitarse al fallo técnico inmediato; debe revisar también diseño, supervisión, datos de entrada y dependencia del proveedor.

La implicación práctica es incómoda para quien compre “IA para SOC” como si fuera una simple licencia adicional. No es una feature más. Es una pieza del sistema de resiliencia. Y esa pieza tendrá que entrar en inventarios, validaciones, controles de cambio, revisión de incidentes y disciplina de terceros.

NIS2 mete presión donde más duele: gestión de incidentes y continuidad

NIS2 tiene una virtud regulatoria peculiar: evita parte del fetichismo tecnológico y devuelve la atención a resultados de gestión. El artículo 21 no pregunta si tu stack es vistoso; pregunta si las medidas son apropiadas y proporcionadas para gestionar riesgos y prevenir o minimizar el impacto de incidentes.

Ahí la IA puede ayudar, estorbar o hacer ambas cosas a la vez. Lo que no debería permitirse es que se despliegue sin encajarla en la lógica de gestión de incidentes, continuidad y cadena de suministro. Si una herramienta acelera análisis pero introduce dependencia fuerte de un proveedor, de conectividad externa o de un flujo opaco de tratamiento de datos, esa dependencia pasa a formar parte del riesgo a gestionar.

También conviene recordar que la seguridad bajo NIS2 no se reduce a confidencialidad. La directiva trabaja sobre la seguridad de redes y sistemas de información en un sentido más amplio, que incluye capacidad de resistir eventos que comprometan disponibilidad, autenticidad, integridad o confidencialidad de datos y servicios. Esa formulación está en la propia definición del artículo 6. Por eso, una decisión de contención o un patrón operativo apoyado por automatización no debe evaluarse solo por su potencial para “parar el ataque”, sino también por sus efectos sobre servicios críticos y continuidad.

La ironía aquí es conocida por cualquiera que haya vivido una respuesta a incidentes mal calibrada: a veces el remedio interrumpe más negocio que la infección inicial. No hace falta adornarlo con bravatas. Basta con diseñar controles que obliguen a ponderar impacto técnico y operativo antes de ejecutar ciertas acciones.

GDPR no desaparece porque el incidente nazca en el SOC

Esto parece obvio, pero conviene repetirlo porque se olvida justo cuando más estorba recordarlo. Si el evento tratado por el SOC afecta a datos personales, el circuito de seguridad y el de privacidad dejan de ser conversaciones paralelas. Se solapan, y rápido.

GDPR art. 33 obliga a notificar violaciones de seguridad de los datos personales a la autoridad de control sin dilación indebida y, cuando sea posible, dentro de las 72 horas. El artículo 34 añade la comunicación a los interesados cuando sea probable que la violación entrañe un alto riesgo para sus derechos y libertades. Para llegar a esas conclusiones hacen falta hechos: naturaleza de los datos, volumen, categorías de interesados, consecuencias probables, medidas adoptadas. Si parte del análisis inicial se apoya en IA, la organización tendrá que asegurarse de que ese apoyo no degrada la obtención o documentación de los hechos relevantes.

Hay otra cuestión menos discutida. Las herramientas de IA desplegadas en operaciones de seguridad pueden implicar tratamiento de datos personales en logs, tickets, telemetría, correos sospechosos o artefactos analizados. Eso activa las obligaciones habituales de base jurídica, minimización, limitación de finalidad, seguridad y, cuando proceda, relaciones con encargados del tratamiento conforme al artículo 28 GDPR. No porque la finalidad sea defensiva queda mágicamente suspendida la disciplina de protección de datos.

Una organización madura no separa estas piezas. Las conecta. Si el SOC usa IA para resumir o correlacionar información potencialmente personal, el diseño debe hablar con privacidad desde el principio. Si no, el primer incidente serio servirá como sesión práctica acelerada. Bastante cara, normalmente.

El proveedor no absorbe tu responsabilidad, aunque absorba buena parte de tu presupuesto

La expansión de IA en ciberseguridad está llegando sobre todo a través de terceros: plataformas cloud, suites de seguridad, servicios gestionados, fabricantes de SIEM/XDR, herramientas de ticketing con funciones generativas. Eso complica la vida al compliance por una razón muy concreta: cuanto más potente parece la capacidad comprada, más fácil es olvidar que la responsabilidad regulatoria sigue en casa.

DORA es especialmente claro en esto. El artículo 28 exige gestionar el riesgo derivado de terceros prestadores de servicios TIC como parte integrante del marco de riesgo TIC de la entidad. Los artículos siguientes desarrollan requisitos sobre estrategia, registro de información, evaluaciones previas a contratar, contenido contractual y vigilancia continuada. Si la función de IA del proveedor participa en monitorización, análisis o respuesta, su opacidad técnica no elimina la obligación de due diligence. La convierte en más difícil.

También hay una derivada práctica que pocas veces se aborda con honestidad. Muchas capacidades “inteligentes” se actualizan de forma continua, cambian de comportamiento, heredan dependencias de modelos subyacentes o reconfiguran flujos de datos sin que el cliente tenga visibilidad granular. Eso obliga a reforzar cláusulas de información sobre cambios materiales, ubicación de tratamiento, subprocesadores, retención de datos, auditoría y soporte en incidentes. Si no está en contrato o en anexos operativos, luego aparecerá en forma de sorpresa. Y las sorpresas en un incidente crítico no suelen ser memorables por buenas razones.

Qué debería revisar ahora una entidad antes de dejar a la IA tocar decisiones sensibles

No hace falta paralizar proyectos. Sí hace falta ordenar prioridades. Si una entidad financiera o una organización sujeta a NIS2 ya está usando o va a usar IA en el SOC, hay un conjunto de revisiones mínimas que conviene hacer antes de ampliar su radio de acción.

• Mapa de casos de uso y puntos de decisión: identifica en qué pasos del flujo la herramienta resume, clasifica, recomienda o ejecuta, y si ese paso puede influir en una obligación de detección, respuesta, escalado o notificación.
• Clasificación por criticidad: no todos los usos tienen el mismo impacto. Separar apoyo documental de recomendación de contención evita gobernar todo con la misma brocha gorda.
• Controles de supervisión humana: define dónde la revisión humana es obligatoria, qué información debe ver el analista y cómo se documentan aceptación, rechazo o modificación de recomendaciones.
• Validación y revisión periódica: establece pruebas operativas y criterios de revisión ligados al riesgo del caso de uso, coherentes con DORA art. 6 y NIS2 art. 21 en materia de eficacia del control.
• Trazabilidad y logging: conserva rastro suficiente de entradas, salidas, prompts o configuraciones relevantes, decisiones humanas y cambios de versión cuando sean materialmente relevantes para reconstruir incidentes.
• Encaje contractual y de terceros: revisa si el proveedor aporta información suficiente para cumplir con DORA capítulo V y con GDPR art. 28 cuando actúe como encargado o subencargado.
• Conexión con privacidad y notificación: asegúrate de que el circuito del SOC puede producir, con fiabilidad, la información necesaria para valorar obligaciones bajo GDPR arts. 33 y 34 y, en su caso, bajo el régimen aplicable de NIS2.

Esto no garantiza éxito. Sí evita uno de los fracasos más previsibles del momento: desplegar IA para ganar velocidad y descubrir tarde que has debilitado la capacidad de justificar decisiones críticas.

La objeción habitual: “si esperamos certeza regulatoria, no desplegaremos nunca”

Es una objeción razonable y, a medias, correcta. Ni DORA ni NIS2 ni GDPR fueron redactados para resolver cada detalle de una herramienta concreta de IA en un SOC. Quien espere una guía perfecta, con casillas exactas para cada modelo y cada playbook, puede ir pidiendo silla cómoda.

Pero de esa falta de detalle no se deduce barra libre. Se deduce justo lo contrario: que las organizaciones deben traducir principios regulatorios ya vigentes a decisiones operativas concretas. Gobernanza, proporcionalidad, trazabilidad, seguridad, documentación, gestión de terceros y capacidad de demostrar control. No es un vacío. Es trabajo.

Además, esa supuesta falta de certeza a veces se usa como excusa para no hacer lo obvio. No necesitas una circular específica para saber que una recomendación automática de aislamiento sobre un activo crítico requiere controles distintos de un resumen automático de tickets. Tampoco hace falta un pronunciamiento épico para entender que, si un proveedor modifica silenciosamente el comportamiento de una función de análisis, eso merece un tratamiento formal de cambios.

La regulación europea no te está pidiendo inmovilidad. Te está pidiendo madurez. Sé que suena menos sexy que “transformación”, pero suele salir más barato en supervisión y en crisis reales.

La conclusión incómoda: el SOC con IA necesita menos fe y más disciplina

No hay nada inherentemente problemático en usar IA en operaciones de seguridad. El problema aparece cuando la organización la introduce como si fuera solo una palanca de productividad y no una tecnología que puede influir en detección, escalado, respuesta, documentación y gestión de terceros.

DORA, NIS2 y GDPR no ofrecen una teoría unificada sobre IA en el SOC. Ofrecen algo más útil: un conjunto de obligaciones bastante concretas que fuerzan a hacerse las preguntas correctas. ¿Quién controla el riesgo? ¿Qué parte del proceso depende del sistema? ¿Cómo se valida? ¿Qué rastro queda? ¿Qué ocurre si el proveedor cambia algo material? ¿Puedes reconstruir una decisión crítica horas o meses después? ¿Puedes notificar a tiempo con hechos fiables?

Si la respuesta a varias de esas preguntas es “ya lo veremos”, entonces la IA no está acelerando tu resiliencia. Está acelerando tu exposición.

Y esa, por mucho que la demo del proveedor venga con gráficos impecables, sigue siendo una mala idea.