IA en el SOC con humano en el bucle: dónde acelera de verdad y dónde te puede meter en un lío regulatorio

La promesa suena irresistible: menos ruido, más velocidad, menos analistas mirando pantallas a las tres de la mañana. Pero en un SOC, la automatización basada en IA no falla como falla un Excel. Falla dentro del circuito que decide qué alerta se investiga, qué incidente se escala, qué activo se aísla y qué evidencia se conserva. Y ahí el problema deja de ser técnico para convertirse en operativo, regulatorio y, a ratos, bastante jurídico.

La pregunta útil ya no es si conviene meter IA en operaciones de ciberseguridad. La pregunta útil es otra: qué controles necesitas para que esa IA no te rompa el proceso que supuestamente venía a mejorar. Si trabajas con obligaciones bajo GDPR, NIS2 o DORA, ese matiz importa más de lo que parece. Mucho más.

Hay un detalle incómodo que suele quedarse fuera del discurso comercial: un SOC puede tolerar herramientas imperfectas; lo que no puede tolerar tan fácilmente es no saber cómo están fallando. Esa diferencia separa una mejora operativa razonable de una fuente nueva de riesgo interno.

El problema no es usar IA. El problema es meterla en una cadena de decisión que ya tiene obligaciones legales

Cuando un proveedor promete priorización automática, correlación inteligente, clasificación de alertas o recomendaciones de respuesta, no está vendiendo solo eficiencia. Está insertando lógica opaca —o semiópaca, con suerte— en un proceso que ya está condicionado por plazos legales, deberes de diligencia y requisitos de trazabilidad.

Si una alerta relevante se descarta mal y el incidente afecta a datos personales, aparece GDPR. El artículo 33 obliga a notificar una violación de seguridad de los datos personales a la autoridad de control sin dilación indebida y, cuando sea posible, en un plazo no superior a 72 horas desde que el responsable tiene constancia. Si la clasificación automatizada retrasa la detección interna o degrada la severidad de un evento hasta dejarlo durmiendo en una cola secundaria, el reloj no desaparece porque el modelo fuera sofisticado.

Si el incidente afecta a una entidad esencial o importante bajo NIS2, el artículo 23 impone un esquema de notificación escalonado: alerta temprana en 24 horas, notificación del incidente en 72 horas y, más adelante, informe final. Aquí tampoco hay premio por haber usado una herramienta novedosa. Lo que hay es una expectativa de gestión diligente del riesgo y capacidad real para detectar, responder y comunicar.

Y si hablamos de entidades financieras sujetas a DORA, el encaje es todavía más directo. DORA exige marcos de gestión del riesgo de las TIC, clasificación de incidentes, respuesta, recuperación, registro y gobernanza. No hace falta forzar una afirmación grandilocuente para ver el punto: si una automatización altera la detección, la clasificación o la escalada, entra de lleno en procesos que DORA regula de forma expresa, entre otros en sus artículos 5 a 17 sobre gestión del riesgo TIC e incidentes, y en el artículo 28 sobre gestión del riesgo derivado de terceros proveedores de servicios TIC cuando la capacidad depende de un proveedor externo.

Traducido al castellano llano: el modelo no responde ante el supervisor. Responde tu organización.

La falsa comodidad del “copilot” en seguridad

Durante años, el mercado de ciberseguridad vendió automatización clásica: playbooks, SOAR, correlación por reglas, scoring, orquestación. Ahora vende IA generativa, copilots, asistentes de triage y motores de priorización que “aprenden” del entorno. La diferencia comercial es enorme. La diferencia jurídica, bastante menos.

Da igual que el proveedor lo llame copiloto, agente o asistente contextual. Si esa funcionalidad influye de forma material en la identificación, análisis o respuesta a incidentes, debes tratarla como parte del sistema de control, no como una capa cosmética. Y un sistema de control exige tres cosas bastante poco glamurosas: criterios de uso, límites y evidencia.

La ironía del momento es esta: muchas organizaciones exigen trazabilidad férrea a un analista junior cuando cierra una alerta, pero aceptan con alegría salidas algorítmicas difíciles de auditar porque llegan en una interfaz bonita. Es una forma cara de comprar opacidad.

Un SOC serio puede convivir con recomendaciones automatizadas. Lo que no debería hacer es asumir que “recomendación” equivale siempre a “bajo riesgo”. En operaciones reales, una recomendación persistente acaba moldeando conducta humana. El analista deja de revisar con la misma intensidad lo que la máquina etiqueta como benigno, probable falso positivo o baja prioridad. No hace falta invocar ciencia ficción. Basta con haber visto cómo funciona cualquier equipo con presión de tiempo y volumen.

Qué exige de verdad la regulación: gobernanza, trazabilidad y capacidad de demostrar control

La parte menos sexy de esta discusión es precisamente la más decisiva. Los marcos regulatorios relevantes no te piden “innovar con prudencia” en abstracto. Te piden control operativo demostrable.

Bajo NIS2, el artículo 21 obliga a las entidades esenciales e importantes a adoptar medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar los riesgos que afecten a la seguridad de las redes y sistemas de información. Ese mismo artículo enumera áreas concretas: gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas, políticas para evaluar la eficacia de las medidas de gestión de riesgos y prácticas básicas de ciberhigiene, entre otras.

Si introduces IA en triage, investigación o respuesta, la pregunta regulatoria no será si la herramienta era innovadora. Será si encaja en esas medidas de gestión del riesgo y si puedes evaluar su eficacia de forma continuada. Ahí está el quid. No basta con validar la herramienta en una demo o en un piloto cerrado.

En GDPR la lógica es parecida, aunque con otra puerta de entrada. El artículo 32 obliga a aplicar medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo, teniendo en cuenta el estado de la técnica, los costes de aplicación, la naturaleza, el alcance, el contexto y los fines del tratamiento, así como los riesgos para los derechos y libertades de las personas físicas. Si la IA participa en la detección o gestión de incidentes de seguridad con impacto potencial sobre datos personales, su rendimiento y su gobernanza forman parte de esa ecuación.

Además, el artículo 5, apartado 2, del GDPR consagra el principio de responsabilidad proactiva: el responsable no solo debe cumplir, sino poder demostrar que cumple. Esa frase parece inocente hasta que aterriza en un SOC. Porque demostrar control sobre una decisión apoyada por IA exige registros, criterios de revisión, asignación de responsabilidades y capacidad de reconstruir por qué una alerta acabó en una bandeja y no en otra.

DORA aprieta todavía más las tuercas en el sector financiero. 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 se centra en identificación, clasificación y documentación de funciones, funciones respaldadas por TIC, activos de información y dependencias TIC. El artículo 10 aborda detección de actividades anómalas. Los artículos 17 y siguientes entran en gestión, clasificación y notificación de incidentes relacionados con las TIC. Y el artículo 28 abre el frente de terceros proveedores TIC, que es exactamente donde caerán muchas capacidades de IA consumidas como servicio.

No es un detalle menor. Si tu “inteligencia” está encapsulada en un producto de un tercero, el problema no es solo técnico. También es contractual: acceso a registros, transparencia suficiente, derechos de auditoría, dependencia, subcontratación en cadena y condiciones de salida. Todo eso ya estaba en el radar regulatorio antes de que alguien decidiera añadir un chat al producto.

El riesgo operativo real: cuando la automatización desplaza criterio sin que nadie lo admita

La defensa típica del proveedor es conocida: “la decisión final siempre la toma un humano”. Bien. A efectos de control, eso solo vale si ese humano puede revisar de manera efectiva la recomendación y si la organización ha diseñado el proceso para que esa revisión exista de verdad. Si no, la supervisión humana se convierte en teatro documental.

Esto ocurre de varias maneras.

La primera es el sesgo de delegación. Si el sistema prioriza miles de alertas y marca un subconjunto como irrelevante o repetitivo, el equipo acaba aceptando ese filtrado como presupuesto operativo. No por negligencia, sino porque ningún SOC tiene recursos infinitos. La máquina no “decide” formalmente, pero estrecha el campo de visión humano. El resultado práctico puede ser muy parecido.

La segunda es la erosión gradual del criterio experto. Cuando el analista se acostumbra a recibir resúmenes, etiquetas, hipótesis y pasos sugeridos, parte del trabajo cognitivo se externaliza. Eso no siempre es malo. De hecho, puede acelerar tareas rutinarias. El problema aparece cuando la organización no distingue entre automatización de tareas y automatización de juicio. Son dos cosas distintas, aunque en muchas demos se vendan juntas.

La tercera es la asimetría de explicabilidad. El proveedor sí sabe, o debería saber, qué señales alimentan la salida; el cliente a menudo solo ve la recomendación final y un puñado de campos visuales. Cuando un incidente serio obliga a reconstruir decisiones, esa asimetría pesa. Y pesa especialmente si necesitas explicar ante auditoría interna, autoridad competente, autoridad de protección de datos o consejo de administración por qué una alerta no se elevó antes.

Aquí conviene bajar el tono épico y subir el tono práctico. No hace falta afirmar que toda automatización generará un incidente por sí sola. Basta con algo más preciso y más verificable: si una entidad integra automatización en procesos de detección, clasificación o escalada, debe gobernar esa automatización con el mismo rigor que aplica al resto de controles que soportan su gestión de incidentes. Bajo DORA, NIS2 o GDPR, el foco regulatorio está en la eficacia del control y en la capacidad de demostrarlo, no en lo atractivo de la capa de IA.

La palabra olvidada es “drift”, aunque no haga falta convertirla en fetiche

Uno de los errores más comunes en compras de seguridad con IA es tratar el rendimiento inicial como si fuese una propiedad estable. No lo es. Un modelo o sistema de clasificación puede comportarse de una manera aceptable en un entorno concreto y dejar de hacerlo cuando cambian las condiciones operativas. Eso no es una conjetura extravagante; es precisamente la razón por la que los controles requieren validación continua y no una bendición única al inicio del proyecto.

No hace falta casarse con un término de moda para entenderlo. Si cambias fuentes de logs, cambias arquitectura, incorporas nuevas integraciones, alteras reglas de retención, migras cargas a otro entorno o modificas patrones de autenticación, también cambias el contexto en el que la automatización opera. Y cuando cambia el contexto, una herramienta que antes ayudaba puede empezar a clasificar peor, resumir peor o recomendar peor. Lo relevante, desde el punto de vista de control, no es discutir semántica sobre deriva del modelo. Lo relevante es que el rendimiento debe revisarse frente a cambios materiales del entorno y no darse por supuesto.

Esto tiene una traducción muy concreta en compliance. Si la organización no define disparadores de revalidación —por ejemplo, cambios de arquitectura, cambios de proveedor, incorporación de nuevas fuentes críticas o incidentes relevantes mal clasificados— la supervisión se queda coja. Y una supervisión coja no suele impresionar a nadie en auditoría.

NIS2 vuelve a ser útil aquí porque el artículo 21 no se limita a pedir medidas; también apunta a políticas y procedimientos para evaluar la eficacia de las medidas de gestión de riesgos de ciberseguridad. La expresión es menos vistosa que cualquier brochazo de marketing sobre IA autónoma, pero jurídicamente vale bastante más.

Qué mirar en un SOC con IA si no quieres descubrir el problema durante una notificación

La forma más sensata de evaluar estas herramientas no es preguntar si “funcionan”, como si eso resolviera algo. La pregunta correcta es: en qué parte exacta del flujo influyen y qué evidencia genera esa influencia.

Empieza por delimitar el alcance operativo real. Hay una diferencia sustancial entre una IA que resume contexto para ahorrar tiempo al analista y una IA que reduce automáticamente severidad, descarta duplicados o sugiere cerrar alertas. En el primer caso hablamos, a menudo, de asistencia documental. En el segundo hablamos de intervención en el proceso de control. La gobernanza no puede ser la misma.

Después, identifica el tipo de dependencia del proveedor. Si la capacidad depende de modelos alojados fuera, APIs de terceros, servicios gestionados o actualizaciones no transparentes, el riesgo se desplaza también hacia la cadena de suministro. Para entidades financieras, DORA art. 28 y siguientes no dejan mucho margen para mirar hacia otro lado: la gestión del riesgo de terceros proveedores TIC exige estrategia, registro de acuerdos, evaluación previa, elementos contractuales mínimos y supervisión continua. Si la funcionalidad de IA forma parte del servicio crítico o importante, la discusión contractual deja de ser una nota al pie.

El tercer punto es la trazabilidad. Necesitas saber, para cada salida relevante, qué datos o eventos la sustentaron, qué acción desencadenó, quién la revisó y si quedó evidencia del override humano cuando lo hubo. Si esa información no existe o no es recuperable en plazo razonable, tu capacidad de defensa se debilita justo cuando más la necesitas.

El cuarto es la taxonomía de error. No todos los fallos pesan igual. Un resumen mediocre puede ser molesto; una despriorización sistemática de eventos de identidad ya es otra conversación. Un consejo práctico: clasifica los fallos de la automatización por impacto operativo y regulatorio, no solo por exactitud estadística. La métrica relevante en un SOC no siempre es la que mejor luce en la ficha comercial.

El quinto es la disciplina de cambio. Si el proveedor actualiza modelos, prompts del sistema, reglas de orquestación o conectores, tu organización debería saber qué cambia y cómo se valida antes o después del cambio, según el riesgo. Sin esa disciplina, la herramienta puede mutar en producción sin que el control interno se entere. Y eso, para un entorno regulado, es una idea bastante peor de lo que suena en una reunión de compras.

No confundas productividad con control

Hay un argumento que aparece en casi todas las conversaciones: el volumen de alertas obliga a automatizar. Cierto. Negarlo sería absurdo. Pero de esa necesidad no se deduce que cualquier automatización incremente control. A veces incrementa solo productividad aparente.

Productividad aparente es cerrar más tickets sin saber mejor qué está pasando. Es generar resúmenes elegantes que comprimen contexto crítico. Es reducir tiempos medios en paneles ejecutivos mientras se degradan decisiones en el frente operativo. Y es, también, medir el éxito con un único indicador agregado que esconde más de lo que enseña.

En lugar de confiar en un KPI totalizador, conviene separar métricas por función y por tipo de riesgo. No es lo mismo evaluar asistencia a investigación que priorización automática o recomendaciones de respuesta. Tampoco es lo mismo medir resultados sobre malware commodity que sobre compromisos de identidad, abuso interno o movimientos laterales discretos. Cuando se mezcla todo en una sola cifra de “eficiencia” o “reducción de ruido”, la organización compra tranquilidad estadística, no control real.

Un panel serio debería, como mínimo, diferenciar entre: alertas correctamente elevadas por la automatización, alertas erróneamente rebajadas, casos reabiertos tras cierre sugerido, tiempos de revisión humana por categoría, y discrepancias entre la clasificación automática y la decisión final del analista. No hace falta convertir esto en liturgia de métricas. Hace falta evitar el autoengaño.

La zona legal gris no está donde muchos creen

Al hablar de IA en seguridad, mucha gente salta enseguida a protección de datos, perfilado o decisiones automatizadas en el sentido del artículo 22 del GDPR. A veces procede; muchas otras, no es el primer problema. El riesgo más inmediato suele estar antes: en la integridad del proceso interno de seguridad y en la capacidad de cumplir obligaciones de detección, documentación, respuesta y notificación.

Eso no significa que GDPR quede fuera. Ni mucho menos. Si el sistema procesa datos personales en logs, credenciales, identificadores de dispositivo, metadatos de actividad o contenidos asociados a incidentes, siguen aplicando los principios del artículo 5, la base jurídica correspondiente, la minimización, la limitación de finalidad, la seguridad del artículo 32 y, en su caso, las obligaciones de gestión de violaciones de seguridad de los artículos 33 y 34.

Lo que conviene evitar es un error de enfoque bastante habitual: pensar que el debate jurídico empieza y termina en si la IA “toma decisiones automatizadas” sobre personas. En un SOC, la pregunta más urgente suele ser otra: si ese sistema altera un control de seguridad material, ¿puedes demostrar que sigue siendo eficaz, revisable y coherente con tus obligaciones regulatorias? Si la respuesta es tibia, tienes trabajo pendiente aunque el artículo 22 no pinte nada en tu caso concreto.

El consejo de administración no necesita una clase de IA. Necesita una explicación de riesgo

Otro fallo frecuente es relegar este asunto al equipo técnico y tratarlo como si fuera una mera cuestión de tooling. Esa comodidad choca con la dirección regulatoria de los últimos años: la gobernanza de ciberseguridad ya no es un hobby del CISO.

NIS2 refuerza la responsabilidad de los órganos de dirección en su artículo 20. DORA también eleva la expectativa sobre el papel del órgano de dirección en la definición, aprobación, supervisión y responsabilidad del marco de gestión del riesgo TIC. Si la automatización con IA modifica la forma en que la organización detecta y gestiona incidentes, el mensaje al consejo no debería ser “hemos comprado una herramienta avanzada”, sino algo más sobrio y útil: qué función cumple, qué riesgo reduce, qué riesgo introduce, cómo se supervisa y qué umbrales obligan a revisión.

El consejo no necesita debatir embeddings, ventanas de contexto ni arquitectura de modelos. Necesita saber dónde hay dependencia crítica de proveedor, qué controles compensatorios existen, qué evidencia se conserva, y qué ocurriría si la herramienta degrada su rendimiento o deja de estar disponible. Ahí se ve si la gobernanza es real o decorativa.

Qué cláusulas y controles contractuales merecen más atención de la habitual

Si compras IA para un SOC como parte de un servicio o plataforma de un tercero, hay varias preguntas contractuales que deberían formularse antes de la firma y no después del primer susto.

• Transparencia funcional mínima: qué componentes realizan clasificación, priorización, resumen o recomendación, y con qué grado de autonomía operativa.
• Gestión de cambios: cómo notifica el proveedor actualizaciones relevantes del sistema, cambios de comportamiento esperados y modificaciones en dependencias externas.
• Registro y acceso a evidencias: qué logs, trazas o artefactos quedan disponibles para reconstruir decisiones y durante cuánto tiempo.
• Subcontratación: qué terceros intervienen en el servicio y qué impacto tiene esa cadena sobre confidencialidad, disponibilidad y auditoría.
• Uso de datos del cliente: si los datos se usan para entrenamiento, ajuste, mejora del servicio o solo para inferencia operacional, y bajo qué condiciones.
• Derechos de auditoría y prueba: hasta dónde puede el cliente validar controles, pedir información o revisar el desempeño en escenarios acordados.

Para entidades bajo DORA, parte de esto no es una preferencia negociadora, sino una necesidad de encaje con los requisitos sobre terceros proveedores TIC y contenido contractual. La fantasía de “comprar rápido y ya veremos” sale especialmente cara en entornos regulados.

La objeción razonable: sin IA, muchos SOC no dan abasto

Conviene conceder algo al argumento contrario, porque tiene base. Muchos equipos de seguridad están saturados, arrastran deuda operativa y viven expuestos a volúmenes de señal imposibles de tratar manualmente. En ese escenario, la automatización no es un lujo; a veces es la única manera de mantener el servicio respirando.

Esa objeción es válida. Lo que no valida es la ausencia de control. Precisamente porque el SOC no da abasto, la organización tiene más incentivos para convertir recomendaciones automáticas en atajos permanentes. Y cuanto más estructural es esa dependencia, mayor debería ser la exigencia de gobernanza, no menor.

Dicho de otra forma: la IA puede ser necesaria. Lo que no es aceptable es tratar esa necesidad como excusa para rebajar validación, trazabilidad o supervisión. Si una función es tan crítica que no puedes operar sin ella, entonces es suficientemente crítica como para someterla a más control, no a menos.

Un enfoque más maduro: clasificar la IA del SOC por criticidad de control

Gran parte del ruido se resolvería si las organizaciones dejaran de hablar de “IA en ciberseguridad” como categoría única. No sirve. Necesitas una clasificación interna más concreta, basada en el efecto sobre el control.

Una taxonomía útil podría separar, al menos, cuatro niveles:

• Asistencia documental: resumen de casos, generación de borradores, búsqueda contextual. Riesgo moderado si no altera decisiones por defecto.
• Apoyo analítico: enriquecimiento, correlación, sugerencia de hipótesis. Riesgo mayor si influye en priorización.
• Intervención en triage: clasificación, desduplicación, reducción de severidad, cierre sugerido. Riesgo alto porque afecta directamente al flujo de incidentes.
• Acción orquestada: aislamiento, bloqueo, deshabilitación o cambios de configuración ejecutados en cadena. Riesgo muy alto por impacto operativo inmediato.

Esta clasificación no sustituye un análisis formal, pero ayuda a decidir algo esencial: dónde poner revisión humana obligatoria, con qué frecuencia revalidar, qué evidencias conservar y qué tipo de aprobación requiere cada cambio. También ayuda a hablar con legal, compliance, procurement y auditoría en un lenguaje menos nebuloso.

Lo que deberías pedir mañana mismo a tu equipo

Si ya usas IA en operaciones de seguridad, hay cuatro preguntas que merecen respuesta documentada, no verbal.

Primera: ¿qué decisiones o predecisiones está influyendo exactamente la herramienta? Si nadie puede dibujar el punto preciso del flujo donde interviene, ya tienes un problema básico de gobernanza.

Segunda: ¿qué evidencia queda de sus salidas y de la revisión humana posterior? Si no puedes reconstruir casos relevantes sin depender del proveedor, la trazabilidad es insuficiente.

Tercera: ¿qué eventos obligan a revalidar rendimiento y configuración? Si la respuesta es “cuando tengamos tiempo” o “en la renovación”, eso no es un criterio de control.

Cuarta: ¿qué obligación regulatoria podría verse afectada si la herramienta falla de una forma concreta? Aquí hay que mapear por proceso: detección, clasificación, respuesta, notificación, documentación, cadena de suministro, protección de datos. No para dramatizar, sino para priorizar controles donde el impacto es real.

Este ejercicio tiene una ventaja poco comentada: ordena la conversación interna. Obliga a salir del lenguaje promocional y entrar en algo bastante más útil, que es el lenguaje del riesgo operacional.

La conclusión incómoda: el verdadero producto no es la IA, sino la disciplina que la rodea

La industria seguirá vendiendo magia. Está en su naturaleza. Los reguladores, por su parte, seguirán recordando —a veces con prosa adormecedora, otras con bastante más colmillo— que la responsabilidad no se delega a una interfaz elegante. Entre una cosa y la otra, el trabajo serio toca hacerlo dentro de casa.

Usar IA en un SOC no es, por sí mismo, ni una imprudencia ni una garantía de madurez. Es una decisión de diseño operativo. Y como toda decisión de diseño en un entorno regulado, solo se sostiene si puedes responder con claridad a preguntas bastante terrenales: qué hace, dónde interviene, cómo falla, quién la supervisa, qué evidencia deja y qué cambia cuando el proveedor toca el sistema.

Si esa disciplina existe, la IA puede aportar valor real. Si no existe, la herramienta quizá acelere tareas, pero también puede empaquetar riesgo en una forma más difícil de ver. Y ese tipo de riesgo tiene una costumbre desagradable: suele revelarse cuando ya estás calculando plazos de notificación, recopilando logs a contrarreloj y explicando a dirección por qué nadie vio venir lo que, sobre el papel, una herramienta “inteligente” estaba allí para detectar.

No hace falta demonizar la automatización. Hace falta dejar de confundir novedad con control.