IA en el SOC con humano en el bucle: dónde acelera y dónde introduce riesgo

La inteligencia artificial puede convertir una cola de 20.000 alertas en una lista manejable. También puede convertir un falso positivo en un bloqueo de producción, ocultar una señal débil entre explicaciones convincentes o cerrar un incidente antes de que alguien haya comprobado qué ha ocurrido realmente.

Ahí está el problema que muchos proyectos de IA para centros de operaciones de seguridad están tratando de esquivar con una etiqueta tranquilizadora: human-in-the-loop. Tener a una persona en algún punto del proceso no basta. La pregunta útil es otra: ¿qué puede decidir esa persona, con qué información, dentro de qué plazo y dejando qué evidencia?

ENISA sitúa la inteligencia artificial como una tecnología con aplicaciones defensivas, pero también con riesgos propios: dependencia de datos, errores de clasificación, opacidad y automatización excesiva. Para un CISO europeo, la cuestión ya no consiste en decidir si habrá IA en el SOC. Consiste en fijar el perímetro exacto de lo que la máquina puede recomendar, ejecutar o cerrar sin que el control humano se convierta en una firma decorativa.

El primer error: llamar «copiloto» a todo

En un SOC, la IA suele aparecer en cuatro funciones diferentes. Mezclarlas en una única categoría de «asistencia» es una forma rápida de perder el control.

La primera es el triage: agrupar alertas, eliminar duplicados, asignar una puntuación de riesgo y sugerir una prioridad. La segunda es la correlación: conectar señales procedentes de EDR, SIEM, identidad, correo, nube y red para construir una hipótesis de ataque. La tercera es la generación de contexto: resumir logs, consultar playbooks, explicar una alerta o proponer consultas adicionales. La cuarta es la respuesta automática: aislar un dispositivo, revocar un token, bloquear una dirección IP, deshabilitar una cuenta o ejecutar un script.

Las tres primeras pueden ahorrar tiempo si se miden bien. La cuarta cambia la naturaleza del riesgo. Un resumen incorrecto obliga a revisar trabajo; un aislamiento incorrecto puede interrumpir una planta industrial, una cámara acorazada digital o la cuenta de un operador crítico.

La distinción operativa que conviene llevar al comité de riesgo es sencilla:

• Recomendación: la IA propone una acción y una persona decide.
• Automatización reversible: la plataforma ejecuta una acción limitada, con caducidad y posibilidad de deshacerla.
• Automatización irreversible o de alto impacto: la acción necesita autorización humana explícita y, en ciertos casos, doble validación.

Un SOC maduro no pregunta si usa IA. Mantiene un inventario de decisiones asistidas por IA. Para cada una registra el activo afectado, la fuente de datos, la acción posible, el umbral de confianza, la autorización requerida, el mecanismo de reversión y el propietario del control. Sin ese inventario, el «humano en el bucle» no es una medida de control; es una intención.

Dónde aporta valor medible

El beneficio más defendible de la IA en el SOC no es que «entienda» el ataque. Es que reduce trabajo repetitivo y acelera el paso entre una señal y una hipótesis comprobable.

En el triage, un modelo puede clasificar alertas usando atributos que el analista ya consulta: criticidad del activo, identidad afectada, historial de comportamiento, exposición externa, técnicas observadas y coincidencias con inteligencia de amenazas. La mejora debería medirse con indicadores antes y después del despliegue: tiempo medio hasta la asignación, porcentaje de alertas duplicadas, proporción de alertas que requieren escalado y tasa de falsos positivos por fuente.

El tiempo medio de respuesta, por sí solo, es un indicador peligroso. Puede bajar porque la IA está cerrando alertas demasiado deprisa. Hay que leerlo junto a la tasa de incidentes reabiertos, el porcentaje de evidencias revisadas por un analista y los casos en los que la detección llegó después de la primera acción del atacante.

La correlación también puede mejorar la investigación. Un copiloto que conecte un inicio de sesión anómalo, una creación de regla de reenvío en el correo y una descarga inusual de datos puede ayudar a identificar una cadena de compromiso que tres alertas aisladas no muestran. Pero la cadena propuesta es una hipótesis, no una prueba. Los logs originales deben seguir disponibles y conservar su integridad. El SOC no puede sustituir la evidencia por el resumen del modelo.

En la respuesta, el valor suele estar en preparar acciones de bajo riesgo: abrir un caso, recopilar artefactos, ejecutar una consulta de búsqueda, añadir contexto a un indicador o comprobar si un hash aparece en otros equipos. El salto desde «preparar» hasta «ejecutar» exige una evaluación distinta. No porque la IA sea especialmente misteriosa, sino porque un error operativo tiene una superficie de impacto mucho mayor.

El coste oculto: falsos negativos con buena redacción

Los falsos positivos son visibles. Llenan la cola, enfadan al equipo y consumen horas. Los falsos negativos son más peligrosos: la alerta no aparece, aparece tarde o se clasifica como ruido. Cuando la IA explica sus decisiones con fluidez, el segundo riesgo se disfraza de eficiencia.

Un modelo puede fallar por datos incompletos, cambios en el entorno, ataques diseñados para evadir su clasificación o una deriva estadística en los patrones normales. Un nuevo proveedor, una migración a la nube o un cambio en el horario de trabajo puede alterar el comportamiento legítimo que el sistema utilizaba como referencia. El rendimiento medido durante el piloto deja de describir el entorno real.

Por eso la validación no debe limitarse a la precisión global. Un modelo que acierta el 98% de las veces puede ser inaceptable si concentra sus errores en cuentas privilegiadas, sistemas de pago o activos de continuidad crítica. El CISO debería exigir, como mínimo, métricas segmentadas por:

• criticidad del activo y del proceso empresarial;
• tipo de identidad, incluyendo cuentas privilegiadas y de servicio;
• técnica de ataque o táctica de MITRE ATT&CK, cuando exista mapeo;
• fuente de telemetría y calidad de los datos;
• severidad asignada y decisión posterior del analista.

También hacen falta pruebas de evasión. No se trata de esperar que el proveedor revele todos los detalles de su modelo, sino de comprobar si pequeñas variaciones en comandos, nombres de archivos, patrones de acceso o secuencias temporales producen cambios injustificados en el resultado. Si el sistema no puede explicar sus límites, el equipo debe compensarlo con límites operativos: menos automatización y más revisión.

Human-in-the-loop no significa «un analista pulsa aceptar»

El artículo 14 del Reglamento de Inteligencia Artificial de la Unión Europea exige supervisión humana para los sistemas de alto riesgo. El precepto no convierte cualquier IA de un SOC en un sistema de alto riesgo. La clasificación depende del uso previsto y de las categorías del artículo 6 y del anexo III. Un sistema interno que prioriza alertas de seguridad no entra automáticamente en el régimen de alto riesgo por el mero hecho de utilizar IA.

Pero el artículo 14 ofrece una referencia útil incluso cuando el AI Act no resulte aplicable como obligación directa. La supervisión debe permitir que las personas comprendan las capacidades y limitaciones del sistema, interpreten correctamente sus resultados, decidan no utilizarlo o ignorarlos y detengan el sistema cuando sea necesario. Una aprobación humana que llega después de una acción irreversible no cumple esa función en términos operativos, aunque exista un botón verde en la interfaz.

La supervisión efectiva tiene cinco componentes que deberían quedar definidos en el procedimiento del SOC:

1. Momento: la persona interviene antes de la acción relevante, no solo en la revisión mensual de muestras.
2. Autoridad: puede rechazar la recomendación sin penalización automática por productividad.
3. Información: recibe las señales originales, el nivel de confianza, los factores utilizados y las incertidumbres conocidas.
4. Competencia: conoce el activo, el playbook y los efectos de la acción propuesta.
5. Interrupción: existe un mecanismo probado para detener o revertir la automatización.

La presión por reducir el número de alertas suele erosionar precisamente estos cinco elementos. Si al analista se le mide solo por casos cerrados, la IA acabará convirtiéndose en una máquina de cerrar casos. El indicador de eficiencia habrá ganado y la resiliencia habrá perdido.

El mapa regulatorio: AI Act, NIS2, DORA y NIST CSF 2.0

Para los responsables europeos, el análisis no termina en el AI Act. La misma herramienta puede activar obligaciones distintas según la entidad, el servicio y el efecto de la decisión.

AI Act: primero se clasifica el uso, después se habla de controles

El artículo 6 y el anexo III delimitan los sistemas de alto riesgo. Entre las categorías relevantes se encuentran determinados componentes de seguridad de productos o infraestructuras críticas, así como usos en ámbitos como empleo, educación, justicia, migración y acceso a servicios esenciales. Un SOC financiero no debe etiquetar su plataforma como «alto riesgo» por reflejo, pero tampoco declarar que el AI Act es irrelevante sin revisar el propósito y el entorno de uso.

Si el sistema sí cae en alto riesgo, entran en juego obligaciones como la gestión de riesgos del artículo 9, la gobernanza de datos del artículo 10, los requisitos de registros del artículo 12, la transparencia y provisión de información del artículo 13, la supervisión humana del artículo 14 y la precisión, solidez y ciberseguridad del artículo 15. El proveedor y el responsable del despliegue pueden tener obligaciones diferentes. Esa distinción debe aparecer en el contrato y en la matriz de responsabilidades, no quedar enterrada en una presentación comercial.

Incluso fuera de alto riesgo, el artículo 50 incorpora obligaciones de transparencia para determinados sistemas que interactúan con personas o generan contenido sintético. No convierte un copiloto interno de analistas en un caso idéntico al de un chatbot público, pero recuerda que «interno» no significa «sin gobernanza». La política de uso debe indicar cuándo el texto procede de una IA, qué fuentes ha utilizado y qué parte ha sido verificada.

NIS2: la IA no altera el deber de notificar

La Directiva NIS2 exige medidas de gestión de riesgos de ciberseguridad en su artículo 21 y establece en el artículo 23 un esquema de notificación de incidentes significativos. La detección asistida por IA no cambia el reloj regulatorio. La alerta puede haber sido generada por un modelo, pero la entidad sigue necesitando determinar si existe un incidente significativo, preservar evidencia y cumplir los plazos aplicables.

El artículo 23 contempla una alerta temprana en 24 horas desde que la entidad tiene conocimiento del incidente significativo, una notificación del incidente en 72 horas y un informe final, salvo que la transposición nacional establezca detalles operativos adicionales. Un sistema que cierre automáticamente una alerta que después resultaba ser un compromiso puede retrasar no solo la respuesta técnica, sino también la evaluación del plazo de notificación.

La consecuencia práctica es clara: el registro del SOC debe conservar el momento en que la IA detectó una señal, el momento en que la persona la revisó, los datos disponibles entonces y la justificación de la decisión. No sirve reconstruir el expediente semanas después a partir de una captura de pantalla.

DORA: el proveedor de IA también puede ser un tercero ICT crítico para el proceso

Para entidades financieras sujetas al Reglamento de Resiliencia Operativa Digital, el artículo 6 exige un marco de gestión del riesgo ICT y el artículo 10 aborda la detección de actividades anómalas. Los artículos 11 y 12 cubren respuesta y recuperación, mientras que los artículos 17 a 19 regulan la gestión y notificación de incidentes relacionados con las TIC, incluidos los incidentes graves bajo el marco aplicable.

La compra de un copiloto de SOC como servicio añade una dependencia que no desaparece porque el producto se comercialice como «asistente». El artículo 28 de DORA exige gestionar el riesgo de terceros proveedores de servicios ICT. La entidad debe saber dónde se procesan los logs, si se reutilizan para entrenar modelos, qué subencargados intervienen, cómo se controla el acceso del proveedor, qué ocurre ante una indisponibilidad y cómo se recuperan los datos y las configuraciones.

Si la herramienta recibe telemetría de clientes, empleados, cuentas privilegiadas o sistemas de pago, la evaluación de privacidad tampoco puede quedar fuera. El RGPD exige una base jurídica y una finalidad definida; el artículo 28 regula al encargado del tratamiento y el artículo 32 obliga a aplicar medidas técnicas y organizativas apropiadas. Si una alerta contiene datos personales, enviarla a un modelo externo puede ser una transferencia o una comunicación con consecuencias que el equipo de seguridad no puede resolver con una casilla de «acepto».

NIST CSF 2.0: el control no es solo Detect y Respond

El NIST Cybersecurity Framework 2.0 organiza los resultados en seis funciones: Govern, Identify, Protect, Detect, Respond y Recover. La IA en el SOC se suele vender como una historia de Detect y Respond. El error está en olvidar Govern.

En Detect, la organización debe definir qué fuentes son fiables, cómo se detectan anomalías y cómo se valida el rendimiento. En Respond, debe establecer qué acciones puede ejecutar la herramienta, cómo se comunica el incidente y cómo se contiene el daño. En Govern se decide quién acepta el riesgo del modelo, quién aprueba los cambios, qué proveedor responde por qué componente y qué evidencias se conservan. Sin Govern, Detect y Respond solo automatizan decisiones sin propietario.

La función Identify también importa: un sistema no puede priorizar correctamente un activo cuya criticidad no está actualizada. Y Recover obliga a probar que la reversión funciona. El playbook que permite aislar un servidor debe incluir la restauración de conectividad, la verificación de integridad y el criterio para declarar resuelto el incidente. Automatizar el primer paso sin probar el último es una forma bastante sofisticada de quedarse a mitad de camino.

La arquitectura de control que necesita un SOC con IA

La seguridad de la herramienta empieza por la separación entre inferencia y ejecución. El modelo puede generar una recomendación, pero el motor de políticas debe decidir si esa recomendación puede producir una acción. No conviene que un modelo de lenguaje tenga acceso directo a credenciales con privilegios para cambiar controles de producción.

Una arquitectura prudente mantiene, al menos, estas barreras:

• Acceso de mínimo privilegio: identidades separadas para leer telemetría, proponer acciones y ejecutarlas. Las credenciales de ejecución deben estar limitadas por ámbito, tiempo y tipo de comando.
• Allowlist de acciones: la automatización solo puede invocar operaciones previamente aprobadas. «Ejecutar cualquier script recomendado» no es una política, es una invitación.
• Entorno de prueba: los playbooks nuevos deben validarse con datos controlados y escenarios de fallo antes de entrar en producción.
• Caducidad y reversión: un bloqueo temporal debe expirar si nadie lo confirma; una modificación de identidad debe poder revertirse con un procedimiento independiente.
• Registro inmutable: se conserva la entrada, la salida del modelo, la versión, las fuentes consultadas, la identidad del aprobador y la acción efectivamente ejecutada.
• Controles contra manipulación: los datos de entrada y las instrucciones recuperadas desde tickets, correos o páginas web no deben poder reprogramar al agente.

El último punto merece más atención. Un copiloto que lee un ticket comprometido puede tratar texto malicioso como una instrucción legítima. Es un caso de prompt injection aplicado al SOC: el atacante no necesita romper el modelo; le basta con introducir contenido que altere su interpretación. Los datos no confiables deben estar claramente delimitados, filtrados y tratados como evidencia, no como órdenes.

Qué documentar para una auditoría que no se limite a enseñar una demo

Una demo muestra que la IA puede resumir una alerta. Una auditoría necesita demostrar que la organización controla sus límites. Para cada caso de uso, el expediente debería incluir:

• propósito previsto y decisiones que quedan fuera del alcance;
• diagrama del flujo de datos, incluyendo logs enviados a proveedores externos;
• clasificación regulatoria razonada bajo el AI Act, cuando proceda;
• inventario de datos personales y análisis de roles RGPD;
• criterios de aceptación y métricas segmentadas por criticidad;
• pruebas de falsos positivos, falsos negativos, deriva y evasión;
• matriz de acciones permitidas, autorizadores y mecanismos de reversión;
• versiones del modelo, del prompt, de las reglas y de las fuentes de conocimiento;
• registro de revisiones humanas, rechazos, anulaciones y reaperturas;
• evidencia de ejercicios de continuidad e indisponibilidad del proveedor.

También hay que registrar los momentos negativos: cuándo el analista no siguió la recomendación y por qué. Si solo se guardan las decisiones coincidentes con la IA, la organización no puede aprender de los desacuerdos ni detectar una falsa sensación de fiabilidad.

La trazabilidad debe ser suficientemente granular para responder a una pregunta incómoda: «¿Por qué se bloqueó esta cuenta?». La respuesta no puede ser «porque el modelo le dio una puntuación de 0,91». Debe explicar qué señales contribuyeron, qué política convirtió la puntuación en una acción, quién autorizó el bloqueo, cuánto duró y qué comprobación permitió levantarlo.

El gobierno del modelo pertenece al CISO, pero no solo al CISO

El SOC conoce el ataque. Compras conoce el contrato. Privacidad conoce los datos. Legal conoce el ámbito regulatorio. Riesgos conoce el apetito de pérdida. Si cualquiera de estas funciones queda fuera, el proyecto puede ser técnicamente brillante y organizativamente defectuoso.

El propietario del caso de uso debe tener autoridad para suspenderlo. El responsable del modelo debe revisar cambios y rendimiento. El equipo de ingeniería debe controlar integraciones y privilegios. El delegado de protección de datos debe intervenir cuando se traten datos personales o se modifique la finalidad. Auditoría interna debe poder acceder a los registros sin depender del proveedor que está siendo revisado.

El contrato debería cubrir, como mínimo, notificación de incidentes, acceso a evidencias, cambios materiales del modelo, subcontratación, uso de datos para entrenamiento, ubicación del tratamiento, borrado, continuidad, pruebas de seguridad y asistencia durante auditorías. En una entidad DORA, estas cuestiones deben alinearse con el inventario de terceros ICT y con la estrategia de salida exigida por el riesgo de concentración y dependencia.

La formación tampoco consiste en enseñar a escribir mejores prompts. Los analistas deben conocer la tasa de error del sistema, los casos en los que no debe utilizarse, la forma de detectar respuestas inventadas y el procedimiento para escalar una recomendación dudosa. Una interfaz que oculta la incertidumbre entrena al usuario para confiar demasiado.

La métrica que falta: cuánto daño evita la IA y cuánto introduce

Los proveedores suelen presentar reducción de tiempo, número de alertas procesadas y productividad por analista. Son datos útiles, pero incompletos. El consejo de administración necesita saber si la automatización mejora el riesgo residual.

Un cuadro de mando razonable combina eficiencia, calidad y daño potencial:

Conviene medir por cohorte y no solo por promedio. Un 1% de errores repartido entre activos corrientes puede ser tolerable; el mismo 1% concentrado en infraestructura crítica, cuentas privilegiadas o transacciones de alto valor exige otro umbral. La estadística media tiene una costumbre irritante: esconder los casos que más importan.

La respuesta prudente: automatizar primero lo reversible

El camino sensato no es prohibir la IA ni entregarle las llaves del SOC. Es graduar la autonomía según el impacto y la reversibilidad.

La generación de consultas, el enriquecimiento de indicadores y la agrupación de alertas suelen ser buenos primeros casos porque el analista puede verificar el resultado y el daño de un error es limitado. La recopilación de evidencias también puede automatizarse si se controla la integridad y el acceso.

El aislamiento temporal de un equipo puede entrar en una segunda categoría cuando existe una exclusión para sistemas críticos, una duración máxima y una confirmación posterior. Revocar credenciales privilegiadas, modificar reglas de red de producción o borrar artefactos debería requerir autorización explícita y, según el impacto, doble control.

La regla debería estar escrita en términos de consecuencias, no de tecnología: cuanto más irreversible sea la acción, mayor debe ser el nivel de supervisión. Un modelo pequeño con acceso para borrar buzones es más peligroso que un modelo sofisticado que solo prepara un resumen. El riesgo está en la combinación de capacidad, permisos y contexto.

Conclusión: el humano debe conservar el mando, no solo la culpa

La IA puede hacer que un SOC llegue antes a la señal correcta. También puede acelerar una mala decisión, ampliar un error a cientos de activos y ofrecer una explicación convincente cuando ya no queda tiempo para comprobarla.

La supervisión humana útil se diseña como un control: autoridad real, información suficiente, límites de acción, registro verificable y capacidad de interrupción. El AI Act aporta un lenguaje exigente para esa supervisión mediante el artículo 14 cuando el sistema entra en alto riesgo; NIS2 obliga a proteger la detección y la notificación bajo sus artículos 21 y 23; DORA lleva la discusión al riesgo ICT, los incidentes y los proveedores conforme a sus artículos 6, 10, 11, 17-19 y 28; NIST CSF 2.0 ayuda a unir gobernanza, detección, respuesta y recuperación.

La pregunta que debe responder cada organización no es si tiene un analista revisando una salida de IA. Es si ese analista puede entenderla, discutirla, detenerla y demostrar después qué ocurrió. Si la respuesta es no, el humano sigue en el bucle, pero el control ya está fuera de él.