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

El problema no es que la IA haya llegado al SOC. El problema es otro: ha llegado antes que el gobierno interno capaz de ponerla en su sitio. Y cuando una herramienta promete priorizar alertas, resumir incidentes, sugerir contenciones o correlacionar señales a una velocidad que un analista humano no puede igualar, la tentación es evidente. Activarla primero. Preguntar después.

Esa secuencia sirve para una demo comercial. Para compliance, no tanto. Si una entidad financiera, un operador esencial o una gran empresa regulada quiere usar IA en operaciones de seguridad sin comprar un problema jurídico disfrazado de eficiencia, tiene que resolver una cuestión bastante menos glamourosa que el prompting: quién decide, con qué controles, bajo qué supervisión y con qué evidencia documental.

Aquí se cruzan varias piezas que demasiadas organizaciones siguen analizando por separado. NIST CSF 2.0 ha elevado el peso del gobierno con la función Govern. El AI Act de la UE impone requisitos específicos para sistemas de alto riesgo, incluida la supervisión humana en su art. 14. GDPR no desaparece porque un proveedor le ponga la etiqueta “security AI” a su producto; si el tratamiento incluye datos personales, siguen aplicando principios del art. 5, bases jurídicas del art. 6, posibles obligaciones de evaluación de impacto del art. 35 y seguridad del art. 32. Si además hablamos de entidades financieras europeas, DORA mete presión adicional sobre gestión de riesgo TIC, terceros y respuesta a incidentes, con un lenguaje mucho menos tolerante con el “ya veremos” de lo que algunos equipos comerciales querrían.

La pregunta útil, por tanto, no es si la IA puede ayudar en un SOC. Claro que puede. La pregunta es otra: en qué tareas encaja de forma defendible, qué controles exige su uso y dónde empieza a invadir terrenos donde el regulador ya no aplaude la innovación, sino que pide explicaciones.

El cambio de fondo: la ciberseguridad ya no se evalúa solo por capacidades técnicas

Durante años, buena parte de la conversación sobre madurez en ciberseguridad se organizó alrededor de capacidades operativas: identificar activos, proteger sistemas, detectar actividad anómala, responder y recuperar. Esa estructura sigue ahí, pero NIST CSF 2.0 introduce una novedad relevante: incorpora Govern como función diferenciada. No es un retoque semántico. Es una señal bastante clara de que la discusión ya no se agota en tener herramientas, sino en cómo se dirigen, priorizan y supervisan.

Para cualquiera que esté evaluando IA en un SOC, ese cambio importa mucho más de lo que parece. Porque desplaza la pregunta desde “¿funciona?” a “¿quién asume la responsabilidad por su uso, cómo se integra en el apetito de riesgo y qué controles evitan que una recomendación automatizada se convierta, de facto, en una decisión no gobernada?”. NIST no prohíbe automatizar; sería absurdo. Lo que hace es reforzar la idea de que la ciberseguridad tiene que estar conectada con gestión de riesgo empresarial, roles, políticas, supervisión y revisión. Si tu organización quiere desplegar IA para triage, enriquecimiento o apoyo en respuesta, no basta con demostrar capacidad técnica. Tiene que demostrar gobierno.

Eso encaja, además, con una tendencia regulatoria más amplia. NIS2, en su art. 21, obliga a las entidades esenciales e importantes a adoptar medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar riesgos de ciberseguridad. La lista incluye gestión de incidentes, continuidad, seguridad de la cadena de suministro, evaluación de la eficacia de medidas y prácticas básicas de ciberhigiene. No hay una línea que diga “si usas IA en el SOC, haz X”. Pero sí hay una lógica inequívoca: si una herramienta afecta a detección, priorización, escalado o contención, entra en el perímetro de las medidas que deben ser controladas, evaluadas y gobernadas.

DORA empuja en la misma dirección. El reglamento exige un marco interno de gestión del riesgo TIC que cubra identificación, protección, prevención, detección, respuesta y recuperación, con responsabilidad del órgano de dirección. Esa obligación no se esfuma porque parte del flujo operativo esté asistido por IA. Más bien al contrario: si una capacidad automatizada influye en la gestión del riesgo operativo digital, la entidad necesita poder explicar cómo encaja dentro de ese marco, cómo se valida y qué dependencia genera frente a terceros proveedores.

Traducido al idioma del día a día: la IA en el SOC no es solo una compra tecnológica. Es una decisión de gobierno, riesgo y control.

Lo que sí dice el AI Act, y lo que conviene no exagerar

Con el AI Act ha pasado algo bastante europeo: se ha comentado muchísimo antes de leerse bien. El resultado es una mezcla curiosa de alarmismo, marketing y resúmenes perezosos. Conviene limpiar el terreno.

El Reglamento (UE) 2024/1689 sí está en vigor. También es cierto que no trata todos los usos de IA igual. Su enfoque es escalonado y basado en niveles de riesgo, con obligaciones especialmente intensas para sistemas de alto riesgo. Y ahí aparece una de las piezas que más interesan a cualquier equipo de seguridad: la supervisión humana.

El art. 14 del AI Act establece que los sistemas de IA de alto riesgo deben diseñarse y desarrollarse de manera que puedan ser efectivamente supervisados por personas físicas durante el periodo en que estén en uso. Esa supervisión humana no es ornamental. El propio artículo exige que se habiliten medidas adecuadas para que las personas puedan comprender las capacidades y limitaciones relevantes del sistema, vigilar su funcionamiento y decidir no utilizar o ignorar, anular o revertir sus salidas cuando proceda.

Hasta ahí, regulación con dientes. Lo que no conviene hacer es extender esa exigencia como si aplicara de forma general a cualquier uso de IA que “afecte materialmente” a derechos, seguridad o continuidad al margen de la arquitectura concreta del reglamento. El AI Act no formula esa regla general. La obligación de supervisión humana está anclada, de forma expresa, a los sistemas de alto riesgo y a otras obligaciones definidas por el propio texto en función del tipo de sistema y del rol del operador en la cadena de valor. Si un uso en ciberseguridad no entra en una categoría regulada con ese nivel de exigencia, no basta con invocar una intuición razonable. Hay que ir al artículo aplicable.

Eso no reduce la relevancia del AI Act para el SOC. La aumenta. Porque obliga a hacer una clasificación seria del caso de uso. Una plataforma que resume tickets o sugiere consultas para un analista no plantea el mismo mapa regulatorio que un sistema integrado en procesos con impacto sensible sobre personas, acceso a servicios o decisiones con relevancia legal o equivalente. Meter todo en el mismo saco sirve para vender presentaciones. Para diseñar controles, no.

Hay otra implicación práctica. Incluso cuando un caso de uso no caiga en alto riesgo, la disciplina de supervisión humana sigue siendo una muy buena idea desde el punto de vista de responsabilidad interna, seguridad operacional y defensa probatoria. No porque el reglamento lo diga para todo, sino porque cuando una recomendación automatizada sale mal, la primera pregunta posterior nunca es “¿qué modelo era?”. Suele ser bastante menos sofisticada: “¿quién autorizó esto y con qué validación?”.

El espejismo de la eficiencia instantánea

La narrativa comercial sobre IA en centros de operaciones de seguridad tiene una virtud indiscutible: simplifica. Demasiado. Promete menos fatiga de alertas, más velocidad, mejor cobertura y una plantilla de analistas casi liberada de tareas repetitivas. Hay elementos plausibles en esa promesa, claro. Si una herramienta clasifica eventos, resume contexto técnico o ayuda a un analista a navegar un volumen elevado de señales, puede aportar utilidad. Pero una cosa es utilidad potencial y otra, muy distinta, convertirla en hecho empírico universal sin demostrarlo en tu entorno.

Por eso conviene ser preciso. No hace falta afirmar resultados categóricos ni repartir porcentajes huérfanos para sostener una tesis razonable. La tesis razonable es esta: hay tareas del SOC en las que la IA puede ser útil como capa de asistencia, siempre que su uso esté delimitado, supervisado y medido con criterios operativos concretos. Si esa frase te parece menos sexy que “autonomous SOC”, bienvenida al mundo real.

Las tareas donde esa utilidad suele ser más defendible comparten una característica: la salida del sistema no debería ejecutar por sí sola una acción irreversible o desproporcionada. Pensemos en enriquecimiento de alertas, normalización de información dispersa, propuestas de clasificación inicial, apoyo a búsqueda de patrones o síntesis de información técnica para acelerar el trabajo humano. Ahí la IA puede funcionar como acelerador cognitivo. No sustituye el criterio del analista; le evita perder tiempo montando a mano el rompecabezas más obvio.

La frontera se vuelve más delicada cuando el sistema pasa de asistir a decidir. Si la herramienta recomienda aislar un activo, bloquear una cuenta, elevar un incidente a una autoridad, despriorizar un evento que parecía menor o cerrar una investigación por falso positivo, el riesgo cambia de categoría práctica aunque la etiqueta comercial siga siendo la misma. Ya no estamos hablando solo de productividad. Estamos hablando de impacto operacional, continuidad de negocio, posible afectación a usuarios y, en algunos sectores, activación de obligaciones regulatorias de notificación o escalado.

Ese es el punto que demasiadas organizaciones subestiman: el valor de la IA en el SOC no depende solo de cuántas alertas toca, sino de cuánta autoridad real se le concede sobre el flujo de decisión.

Gobernar un copiloto no es lo mismo que gobernar un decisor

Una de las distinciones más útiles para ordenar esta conversación es separar tres niveles de uso. No hace falta fingir que son categorías legales cerradas; no lo son. Pero como herramienta de gobierno interno funcionan sorprendentemente bien.

Primer nivel: IA como apoyo documental y analítico. Resume logs, explica técnicas ATT&CK, sugiere consultas, traduce inteligencia técnica en lenguaje más legible, redacta borradores de informes. Aquí el riesgo principal suele estar en precisión, fuga de datos, dependencia del proveedor y exceso de confianza del analista. Se gobierna con controles de acceso, reglas claras de uso de datos, revisión humana obligatoria antes de cualquier salida externa y validación periódica de calidad.

Segundo nivel: IA como apoyo a priorización y triage. Clasifica alertas, agrupa incidentes similares, propone severidad inicial o destaca relaciones que merecen revisión. El beneficio potencial es claro, pero también lo es el peligro: que la sugerencia de la herramienta se convierta en una verdad tácita porque el equipo tiene prisa. Aquí hacen falta umbrales, revisión por muestreo, métricas de desviación, criterios de override y trazabilidad sobre cuándo el analista sigue o corrige la recomendación.

Tercer nivel: IA con influencia operativa relevante sobre contención, escalado o cierre. Aunque formalmente haya una persona “en el bucle”, el riesgo real aumenta si esa persona se limita a pulsar aceptar porque el proceso está diseñado para ello. En este nivel entran de lleno las preguntas de accountability, validación ex ante y supervisión continua. También es donde un regulador, un auditor interno o un consejo de administración empezarán a hacer preguntas menos teóricas.

La ironía aquí es bastante evidente: muchas organizaciones dedican más tiempo a revisar la redacción del aviso legal de su web que a definir cuándo un analista puede aceptar una recomendación automatizada de contención. Luego llega un incidente serio y nadie entiende por qué el post-mortem resulta incómodo.

GDPR no se aparta del escenario solo porque el caso de uso sea ciberseguridad

Hay una coartada frecuente en proyectos de seguridad: como la finalidad es legítima y el objetivo es proteger sistemas, algunos equipos asumen que privacidad queda resuelta por aclamación. No funciona así.

Si una solución de IA para el SOC trata datos personales, aunque sea de forma incidental o derivada, GDPR sigue plenamente en juego. Y en operaciones de seguridad eso ocurre más de lo que a veces se admite: direcciones IP, identificadores de usuario, registros de autenticación, correos, nombres de equipo asociados a empleados, contenidos de tickets o incluso fragmentos de comunicaciones internas pueden entrar en el circuito.

El art. 5 del GDPR obliga a respetar principios como minimización, limitación de la finalidad y exactitud. El art. 6 exige una base jurídica para el tratamiento. El art. 32 impone medidas técnicas y organizativas apropiadas para garantizar la seguridad. Y el art. 35 puede activar una evaluación de impacto si el uso presenta un alto riesgo para los derechos y libertades de las personas, algo que no debería descartarse de entrada si la herramienta realiza perfiles, correlaciones complejas o análisis a escala con capacidad de influir en decisiones internas sobre usuarios o empleados.

Además está el problema menos glamuroso y más frecuente: qué hace el proveedor con los datos que le envías. Si el modelo se presta como servicio, hay que revisar con lupa el reparto de roles, las instrucciones contractuales, la localización del tratamiento, las subcontrataciones posteriores y la posibilidad de que inputs o outputs se utilicen para entrenamiento, mejora del servicio o fines propios. Aquí no sirve el reflejo condicionado de firmar un DPA y seguir adelante. Hay que leerlo de verdad.

Para entidades sujetas a DORA, esto conecta directamente con la gestión de terceros TIC. El capítulo V del reglamento y, en particular, las disposiciones sobre riesgo asociado a proveedores exigen inventario, evaluación previa, cláusulas contractuales concretas y seguimiento. Si el supuesto “copiloto de seguridad” depende de un tercero que procesa telemetría sensible y participa materialmente en un proceso de detección o respuesta, no es una compra menor. Es una relación de riesgo TIC que debe estar tratada como tal.

DORA complica la conversación de una forma muy sana

Si hubiera que resumir el efecto de DORA sobre la adopción de IA en ciberseguridad en una sola frase, sería esta: obliga a aterrizar. Y eso, francamente, le viene bien a un mercado demasiado acostumbrado a vender automatización como si el control interno fuera un obstáculo administrativo en vez de una condición de resiliencia.

El reglamento exige a las entidades financieras un marco sólido de gestión del riesgo TIC, con responsabilidades claras del órgano de dirección, identificación de funciones críticas o importantes, gestión de incidentes, pruebas de resiliencia y control de terceros. No menciona “IA generativa en el SOC” porque no necesita hacerlo. Su lógica es tecnológicamente neutra, y precisamente por eso alcanza de lleno a estas herramientas.

Si una capacidad de IA se usa para detectar incidentes, priorizarlos, apoyar decisiones de contención o generar información que alimenta notificaciones internas o externas, la entidad tiene que responder al menos a cinco preguntas bastante concretas.

• Qué función cumple realmente. No en la diapositiva del proveedor, sino en el flujo operativo real. ¿Asiste? ¿Recomienda? ¿Decide de facto?
• Qué datos consume y produce. Incluidos datos personales, secretos empresariales, telemetría sensible o información de clientes.
• Qué dependencia crea del proveedor. DORA, en sus disposiciones sobre terceros TIC, no distingue entre dependencia elegante y dependencia torpe. Si la herramienta se vuelve crítica, hay que tratarla como tal.
• Cómo se valida. Qué pruebas internas se han hecho, con qué escenarios, qué límites se han detectado y qué controles compensatorios existen.
• Cómo se integra en respuesta a incidentes y continuidad. Porque una recomendación automatizada mal calibrada no solo puede fallar; puede degradar la capacidad de respuesta en un momento crítico.

Aquí aparece una consecuencia operativa que muchas entidades todavía no han interiorizado: si el uso de la IA en el SOC no está documentado dentro del sistema de control interno, el problema no es solo técnico. Es de gobernanza. Y bajo DORA, la gobernanza del riesgo TIC no se delega mágicamente al fabricante ni al equipo de seguridad. Recae en la entidad y, en última instancia, en su órgano de dirección.

El caso ENISA: menos consignas, más cautela metodológica

Cuando se habla de IA aplicada a ciberseguridad, a veces se invoca a ENISA como si hubiera emitido una bendición general a la automatización inteligente. Esa lectura simplifica demasiado. Con la base disponible, lo prudente es decir otra cosa: ENISA mantiene trabajo y recursos temáticos sobre IA y su relación con la ciberseguridad, lo que refleja que el asunto está en la agenda regulatoria y técnica europea. A partir de ahí, conviene no atribuirle fórmulas cerradas que la fuente concreta no sostenga.

Esto no es un tecnicismo de fact-checking. Tiene una utilidad práctica. Si una organización quiere apoyarse en referencias públicas para justificar un despliegue de IA en el SOC, necesita distinguir entre tres niveles de respaldo: lo que una norma exige, lo que una autoridad recomienda de forma expresa y lo que el mercado interpreta como buena práctica sin apoyo documental directo. Mezclar esas capas genera textos bonitos y defensas débiles.

En términos de compliance, la prudencia metodológica gana por goleada. Si ENISA ofrece marcos, informes o materiales temáticos sobre IA, úsalos como contexto o como apoyo para análisis de riesgo. Pero no conviertas esa existencia en un endoso regulatorio de una arquitectura concreta que nadie ha aprobado formalmente. El regulador no premia la creatividad narrativa cuando llega una inspección.

Dónde puede encajar la IA sin disparar el riesgo regulatorio

Si quitas el humo, quedan varios casos de uso razonables para un SOC regulado. No son necesariamente los más espectaculares, pero sí los más defendibles.

Uno es la síntesis y contextualización. Un analista recibe señales de distintas herramientas, indicadores técnicos, referencias cruzadas, información de activos y notas de incidentes previos. Convertir ese material disperso en un resumen coherente consume tiempo y atención. Una herramienta de IA puede ayudar a compactar y estructurar la información para que la revisión humana empiece más arriba en la cadena de valor.

Otro es el apoyo a investigación inicial. Sugerencias de consultas, hipótesis de correlación, explicaciones de técnicas observadas o mapeo preliminar a marcos como MITRE ATT&CK pueden servir como aceleradores de trabajo, siempre con validación humana. La utilidad aquí no depende de tratar a la IA como oráculo, sino como asistente que reduce fricción.

Un tercer terreno razonable es la producción de borradores: informes internos, handover entre turnos, cronologías preliminares, resúmenes ejecutivos para responsables no técnicos o tickets con campos completados a partir de evidencias ya recopiladas. Otra vez, el matiz decisivo es la revisión. El borrador puede automatizarse. La responsabilidad, no.

Lo que une estos casos es sencillo: la salida de la IA se usa como insumo revisable, no como decisión final encubierta. Ese diseño reduce riesgo legal, limita impacto de errores y facilita una defensa sólida ante auditoría: la herramienta asiste, el equipo decide.

Donde empiezan los problemas serios

La conversación cambia cuando la IA interviene en puntos donde una decisión errónea puede producir consecuencias operativas, legales o incluso laborales de forma inmediata.

Pensemos en el cierre automatizado de alertas supuestamente benignas. Si el sistema se equivoca, el coste puede no ser visible hasta bastante después. Pensemos en recomendaciones de aislamiento de endpoints o bloqueo de cuentas con validación humana puramente ritual. El riesgo ya no es solo perder un evento; también es interrumpir negocio, afectar a usuarios legítimos o escalar un incidente inexistente. Y si la herramienta participa en la preparación de reportes regulatorios o en la clasificación de un evento como notificable, el problema puede saltar del SOC al departamento jurídico en cuestión de minutos.

En entornos laborales aparece además una capa incómoda: la posible monitorización intensiva de empleados. Dependiendo del diseño del caso de uso, una plataforma de seguridad asistida por IA podría inferir patrones de comportamiento, atribuir sospechas o priorizar revisiones sobre personas concretas. Ahí GDPR, normativa laboral aplicable y principios de proporcionalidad dejan de ser un apéndice.

También hay un riesgo de “automation bias” que no necesita estadísticas grandilocuentes para ser real. Cuando una herramienta ofrece una salida con apariencia de precisión y lenguaje convincente, muchos usuarios tienden a seguirla más de lo debido, sobre todo bajo presión temporal. Ese sesgo no desaparece por añadir una casilla de aprobación humana al final del flujo. Si el proceso, los SLA o la carga de trabajo empujan a aceptar por defecto, la supervisión humana existe en papel y se evapora en la práctica.

Qué debería exigir un CISO antes de aprobar un caso de uso

Si el objetivo es usar IA en el SOC sin regalarle a auditoría una mina de hallazgos, la autorización interna no debería depender de una demo vistosa ni de una urgencia presupuestaria. Debería pasar por un filtro bastante más prosaico y bastante más útil.

Primero, una definición exacta del caso de uso. Nada de “mejorar detección con IA”. Eso no significa nada. Hay que describir la tarea, la entrada, la salida, el punto del flujo donde se integra y la decisión humana asociada. Si no puedes dibujarlo en un proceso, aún no lo entiendes.

Segundo, una clasificación de impacto. ¿La salida informa, recomienda o activa? ¿Puede afectar a continuidad, clientes, empleados, terceros o reportes regulatorios? ¿Podría modificar prioridades de respuesta de forma material? Esta clasificación no reemplaza el análisis jurídico, pero lo ordena.

Tercero, revisión de datos. Qué conjuntos se usarán, si incluyen datos personales, si hay transferencia a terceros, si existe retención para mejora del servicio y qué medidas técnicas reducen exposición. Aquí privacidad y seguridad tienen que hablar entre sí, cosa menos frecuente de lo deseable.

Cuarto, validación previa con escenarios adversos. No solo aciertos esperados, también errores previsibles: alucinaciones, omisiones, correlaciones engañosas, respuestas excesivamente seguras, tratamiento defectuoso de señales ambiguas. Si el proveedor solo enseña casos bonitos, ya ha contestado una parte importante de la evaluación.

Quinto, reglas de supervisión humana reales. Quién revisa, cuándo revisa, qué autoridad tiene para corregir, qué umbrales obligan a intervención adicional y cómo queda registro de esa revisión. Si no queda rastro, luego nadie aprenderá del error.

Sexto, gobierno de terceros. Contrato, subprocesadores, seguridad, resiliencia, derechos de auditoría cuando procedan, estrategia de salida y dependencia operativa. DORA aquí no es decoración jurídica; es disciplina elemental.

Séptimo, métricas internas. No para prometer milagros al consejo, sino para saber si el caso de uso merece seguir vivo. Calidad de las recomendaciones, tasa de corrección humana, impacto en tiempos de análisis, incidentes asociados al uso de la herramienta y cualquier desviación relevante del proceso previsto. Sin medición, el proyecto se convierte en fe con presupuesto.

La supervisión humana útil no consiste en “hacer clic para continuar”

Una de las trampas más comunes en este terreno es confundir intervención formal con supervisión efectiva. El AI Act, en su art. 14 para sistemas de alto riesgo, va precisamente contra esa ficción: la supervisión debe permitir entender límites y funcionamiento relevante del sistema y posibilitar que una persona decida no utilizar, ignorar, anular o revertir salidas cuando proceda.

Esa lógica es perfectamente trasladable, como buena práctica interna, a usos en ciberseguridad aunque no todos caigan en alto riesgo. Una revisión humana útil exige al menos cuatro cosas.

• Contexto suficiente. El analista debe ver de dónde sale la recomendación o el resumen, no solo el resultado final.
• Tiempo real para revisar. Si el proceso obliga a resolver en segundos sin información adicional, la revisión es una ficción administrativa.
• Capacidad de disentir sin castigo implícito. Si los KPI penalizan sistemáticamente a quien no sigue la recomendación automatizada, la herramienta ya manda aunque nadie lo admita.
• Registro de override y aprendizaje. Corregir una salida del sistema debería alimentar calibración, no perderse en el vacío.

Tu SOC tiene esto resuelto o solo tiene una pantalla nueva con un botón azul muy convincente. Esa es la pregunta incómoda.

Cómo alinear NIST, DORA, GDPR y AI Act sin construir una catedral burocrática

El miedo habitual de los equipos técnicos es que cualquier conversación regulatoria acabe produciendo un monstruo documental que mate el proyecto antes de nacer. El riesgo existe. También se puede evitar.

La clave es diseñar un paquete de control único que sirva a varias exigencias a la vez. No cuatro evaluaciones paralelas para contentar a cuatro funciones internas distintas. Un mismo expediente de caso de uso puede cubrir, si se hace bien, gobierno y riesgo, privacidad, gestión de terceros, validación técnica y supervisión humana.

Ese expediente debería incluir una descripción funcional del uso, mapa de datos, análisis de impacto, clasificación regulatoria preliminar, controles de supervisión, resultados de pruebas, límites de uso y responsable ejecutivo. Con eso, NIST CSF 2.0 encuentra sustancia en la función Govern; DORA obtiene trazabilidad sobre riesgo TIC y terceros; GDPR ve finalidad, minimización, seguridad y necesidad de análisis adicional; y el AI Act, cuando aplique, encuentra base para acreditar medidas de supervisión humana y control.

Lo interesante es que este enfoque no frena necesariamente la adopción. La acelera de forma inteligente. Porque separa muy pronto los casos de uso razonables de los que son demasiado opacos, demasiado intrusivos o demasiado dependientes de promesas del proveedor. Y eso ahorra un tipo de coste muy concreto: el de desplegar deprisa algo que luego hay que congelar cuando legal, auditoría o el regulador empiezan a hacer preguntas serias.

La pregunta que casi nadie quiere hacer al proveedor

Hay una pregunta devastadoramente simple que convendría poner sobre la mesa en cualquier negociación: “Enséñame un caso en el que vuestra herramienta se equivoque de forma peligrosa y explícame cómo lo detecto antes de que afecte a una decisión”.

Si la respuesta es evasiva, ya tienes información útil. Mucha. Porque la calidad de una herramienta para entornos regulados no se mide solo por su rendimiento en condiciones ideales, sino por la transparencia de sus límites, la facilidad para gobernarla y la capacidad de integrarla en un proceso donde el error no se esconda bajo una capa de lenguaje fluido.

El mercado de la IA aplicada a seguridad está lleno de promesas sobre autonomía. El regulador, en cambio, se mueve en otra dirección: responsabilidad, control, documentación y capacidad de intervención humana cuando el impacto lo exige. Esa tensión no va a desaparecer. Y quizá mejor así.

La conclusión incómoda: la IA útil en el SOC será la que acepte vivir con límites

La idea de un SOC plenamente automatizado tiene algo de fantasía corporativa recurrente. Reaparece con cada ola tecnológica, cambia de nombre y vuelve a prometer que esta vez sí. La IA ha renovado esa promesa con mejores interfaces y más potencia, pero no ha abolido las reglas básicas del riesgo operativo.

Lo que sí puede hacer, y ya justifica atención seria, es mejorar partes concretas del trabajo de seguridad: ordenar información, acelerar análisis iniciales, reducir fricción cognitiva y ayudar a producir documentación operativa con más rapidez. Ahí hay valor potencial. Valor defendible, además, si se diseña bien.

El precio de ese valor es aceptar límites. Límites de datos, de autoridad, de autonomía, de dependencia del proveedor y de confianza ciega. NIST CSF 2.0 empuja a gobernar. DORA obliga a tomarse en serio el riesgo TIC y los terceros. GDPR recuerda que la finalidad de seguridad no da patente de corso sobre los datos. Y el AI Act, cuando entra de lleno por la puerta del alto riesgo, exige supervisión humana real, no decorativa, en su art. 14.

La moraleja no es abstenerse de usar IA en el SOC. Sería una lectura pobre y, probablemente, poco realista. La moraleja es más exigente: úsala donde puedas explicar de forma creíble qué hace, qué no hace, quién responde por ella y cómo la detienes cuando se equivoca. Todo lo demás se parece demasiado a delegar criterio en una caja rápida con buena narrativa comercial.

Y eso, tarde o temprano, suele acabar mal. A veces en producción. A veces en auditoría. A veces en ambas, que siempre es la versión más cara.