El BIS lanza la advertencia que banca y supervisores no querían oír: la IA frontera ya puede encadenar ciberataques complejos

Lo relevante no es si un modelo concreto ha cruzado una línea simbólica en una demo más o menos espectacular. Lo relevante es algo bastante menos cinematográfico y bastante más incómodo: los modelos avanzados ya obligan a tomarse en serio la posibilidad de que aceleren tareas ofensivas de ciberseguridad que antes exigían más tiempo, más pericia o más personal. Y cuando esa posibilidad entra en el radar de supervisores y responsables de riesgo, la conversación deja de ir de marketing y pasa a ir de gobernanza, evidencia y control.

Ese cambio de marco importa mucho más de lo que parece. Durante demasiado tiempo, parte del debate sobre IA y ciberseguridad ha oscilado entre dos extremos igual de poco útiles: el alarmismo de tráiler y el negacionismo corporativo de PowerPoint. Ni una cosa ni la otra sirve a una entidad regulada. Si eres un banco, una aseguradora, un proveedor crítico o cualquier organización atrapada felizmente entre DORA, NIS2 y GDPR, necesitas otra pregunta: ¿qué controles tienes hoy para gestionar un sistema que puede asistir en reconocimiento, explotación, scripting, escalado o evasión, aunque no convierta a un novato en un operador de élite?

Ahí está el quid. El riesgo no depende solo de que un modelo sea capaz de ejecutar un ataque “de extremo a extremo” de forma autónoma. Basta con que reduzca fricción en varias fases de la cadena. En seguridad ofensiva, bajar fricción es media victoria. El regulador lo sabe. Los equipos rojos también. A veces, lo único que falta es que el comité de dirección deje de fingir sorpresa.

La señal útil: menos fetichismo del modelo, más atención al umbral operativo

El error habitual en esta discusión consiste en obsesionarse con nombres comerciales, fechas de lanzamiento y comparativas de laboratorio que envejecen en días. Ese tipo de dato tiene valor periodístico cuando está sólidamente verificado. Cuando no lo está, solo mete ruido. Lo que sí merece atención es la idea de fondo que ya aparece en evaluaciones públicas y en el debate técnico serio: algunos modelos pueden aportar ayuda material en tareas ofensivas complejas, especialmente cuando se combinan con herramientas externas, iteración y prompting especializado.

Dicho de forma menos elegante: el problema no es que la IA haga magia. El problema es que puede hacer rentable, repetible y más rápido lo que antes era más caro en tiempo humano. Para una organización madura, esa diferencia cambia cómo se evalúa la exposición, cómo se diseñan las pruebas y cómo se vigila el uso interno y externo de estos sistemas.

La cuestión práctica no es si existe un titular rotundo sobre “la primera IA que hackea”. La cuestión práctica es si tu modelo de control sigue asumiendo que la capacidad ofensiva solo crece cuando contratas más especialistas o cuando aparece una nueva botnet. Esa premisa ya huele a 2022.

Qué se puede afirmar con rigor, y qué no

Conviene poner orden porque en este terreno abunda la espuma. No es verificable, con el material aquí disponible, atribuir a una empresa concreta el anuncio de un producto específico en una fecha determinada. Tampoco lo es afirmar que otro proveedor lanzó un modelo concreto “semanas después”, ni presentar una carrera cronológica entre modelos como si estuviera probada por una fuente que no lo acredita de forma expresa.

Lo mismo vale para métricas de rendimiento muy precisas, porcentajes exactos en pruebas ofensivas, estimaciones cerradas de consumo de tokens por cadena de ataque o rangos concretos de coste en la nube asociados a un modelo determinado. Son datos que pueden existir en algún informe, benchmark o documento técnico, pero si la fuente aportada no los respalda de forma directa, lo responsable no es adornarlos. Es retirarlos o reformularlos con prudencia.

Esto no debilita el argumento. Al contrario. Lo fortalece. La dependencia de cifras muy llamativas y mal ancladas suele ser una forma elegante de ocultar que no se ha entendido el riesgo estructural. El riesgo estructural aquí es claro incluso sin fuegos artificiales numéricos: los modelos de frontera pueden contribuir a tareas ofensivas relevantes y, por tanto, deben entrar en el perímetro de gestión de riesgo tecnológico, de terceros, de seguridad de la información y de respuesta a incidentes.

Por qué esto ya es un problema de compliance, no solo de seguridad técnica

En Europa, la tentación de tratar la IA ofensiva como un asunto exclusivo del CISO choca de frente con la realidad regulatoria. Si una entidad financiera utiliza o depende de sistemas de IA en procesos de desarrollo, soporte, detección, análisis o automatización, esa dependencia toca varias capas normativas a la vez.

DORA obliga a gestionar el riesgo relacionado con las TIC como un problema de negocio y de gobernanza, no solo de infraestructura. El núcleo está en los artículos 5 a 16 sobre marco de gestión del riesgo TIC, protección y prevención, detección, respuesta y recuperación, aprendizaje y comunicación. Si un modelo generativo puede alterar la superficie de ataque, facilitar errores de configuración, acelerar scripting o introducir dependencias opacas de proveedores, ese riesgo entra de lleno en el marco de DORA. Y si el modelo o sus componentes llegan vía proveedor externo, el foco pasa además a DORA art. 28 y siguientes sobre gestión del riesgo de terceros prestadores de servicios TIC.

NIS2 aprieta en una dirección parecida pero con alcance más amplio para entidades esenciales e importantes. El art. 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar riesgos para la seguridad de redes y sistemas de información. No menciona “modelos frontier” porque la ley no está para hacer publicidad a nadie, pero sí cubre gobernanza, gestión de incidentes, continuidad, seguridad de la cadena de suministro, desarrollo y mantenimiento seguro, evaluación de eficacia y prácticas de higiene cibernética. Si introduces IA en tu ciclo técnico, no puedes actuar como si hubiera aparecido por generación espontánea y quedara fuera del sistema de control.

GDPR entra por otra puerta que muchos equipos técnicos siguen subestimando: la exposición de datos personales en prompts, logs, afinado, monitorización y outputs. Aquí no hace falta invocar teorías grandiosas. Basta leer el art. 5 sobre principios de minimización e integridad y confidencialidad, el art. 25 sobre protección de datos desde el diseño y por defecto, el art. 32 sobre seguridad del tratamiento, y el art. 33 sobre notificación de violaciones de seguridad de los datos personales. Si un uso inseguro del modelo deriva en fuga, reexposición o tratamiento no autorizado, el problema deja de ser “experimental” en cuestión de minutos.

En otras palabras: quien siga tratando la IA ofensiva o de doble uso como un juguete del laboratorio está leyendo las normas como quien mira una previsión meteorológica y decide salir sin paraguas porque aún no llueve.

El debate serio no va de autonomía total; va de amplificación

La pregunta más útil para un comité de riesgos no es si un modelo puede completar sin ayuda una intrusión compleja contra un objetivo endurecido. La pregunta útil es si amplifica la productividad ofensiva en etapas concretas. Reconocimiento. Priorización de vectores. Generación y depuración de scripts. Explicación de errores. Adaptación de payloads. Automatización de tareas repetitivas. Traducción entre lenguajes o entornos. Resumen de documentación técnica. Todo eso cuenta.

En la práctica, la IA no necesita ser un atacante autónomo para cambiar el equilibrio operativo. Le basta con reducir el tiempo de búsqueda, bajar el coste cognitivo o ensanchar la base de actores capaces de ejecutar tareas antes menos accesibles. No convierte necesariamente a un inexperto en un operador sofisticado. Pero puede convertir a un equipo mediocre en uno más eficiente. Y un equipo eficiente, aunque no sea brillante, puede causar bastante daño si la víctima acumula deuda técnica, credenciales expuestas o mala segmentación.

Esto enlaza con una verdad incómoda del compliance tecnológico: muchas organizaciones siguen midiendo la amenaza con categorías demasiado binarias. “Capaz / no capaz”. “Permitido / prohibido”. “Interno / externo”. La IA desordena ese esquema porque su impacto real suele estar en la zona gris de la asistencia parcial. Ahí es donde más fallan los controles, precisamente porque no hay un botón rojo evidente.

La gobernanza que exige DORA si metes IA en la ecuación

Si aterrizamos en DORA, la lectura útil no es buscar una mención mágica a la IA. La lectura útil es preguntarse qué piezas del reglamento ya obligan a controlar este riesgo aunque el texto use categorías tecnológicamente neutras. Varias.

El art. 5 sitúa la responsabilidad final en el órgano de dirección respecto al marco de gestión del riesgo relacionado con las TIC. Traducción al castellano de oficina: no basta con que el equipo técnico “esté mirando el tema”. El consejo o su equivalente debe aprobar, supervisar y revisar el marco. Si la entidad adopta herramientas generativas para desarrollo, soporte SOC, análisis de vulnerabilidades o automatización, tiene que poder explicar qué riesgos añadió, qué límites impuso y cómo mide su eficacia.

El art. 8 obliga a identificar, clasificar y documentar funciones, activos, roles y dependencias TIC. Si tu dependencia operativa de un proveedor de IA no aparece con claridad en inventarios, arquitectura, flujos de datos y mapa de servicios críticos o importantes, vas tarde. Muy tarde.

El art. 9 sobre protección y prevención y el art. 10 sobre detección obligan a diseñar controles ex ante y capacidades de monitorización. Para IA esto se traduce, como mínimo, en restricciones de acceso, registros de uso, segregación de entornos, validación de outputs en casos críticos, políticas de datos de entrada y mecanismos para detectar comportamientos anómalos o inseguros.

Los arts. 11 a 13 empujan además a que respuesta, recuperación, aprendizaje y comunicación no se queden en un PDF bonito. Si un modelo participa en un flujo crítico y falla, o si una interacción con él desencadena un incidente, necesitas playbooks que contemplen esa dependencia. No improvises cuando el incidente ya está en prensa.

Y luego está la parte que muchas entidades querrían dejar para septiembre pero no deberían: DORA art. 28 y siguientes. La gestión del riesgo de terceros prestadores de servicios TIC exige una estrategia sobre terceros, registro de acuerdos contractuales, evaluación previa y contractualización de derechos, incluidos acceso, auditoría e información. Si usas un proveedor de IA mediante API, plataforma integrada o software embebido, la conversación contractual no puede quedarse en el precio por token o por licencia. Importan subencargados, localización del tratamiento, logs, uso de datos para entrenamiento, continuidad, notificación de incidentes y posibilidad real de salida.

NIS2 tampoco te deja esconderlo en el laboratorio

Para entidades sujetas a NIS2, el espejo es igual de incómodo. El art. 20 refuerza la responsabilidad de los órganos de dirección en la aprobación y supervisión de las medidas de gestión del riesgo. El art. 21 enumera medidas que encajan de lleno con el uso de IA: políticas de análisis de riesgos y seguridad de sistemas, gestión de incidentes, continuidad, seguridad de la cadena de suministro, seguridad en adquisición, desarrollo y mantenimiento, evaluación de eficacia de medidas, prácticas de ciberhigiene y formación, criptografía cuando proceda, y seguridad de recursos humanos y control de accesos.

Hay una derivada operativa que conviene subrayar. Si la IA se usa para escribir código, generar configuraciones, resumir tickets, clasificar alertas o asistir a administradores, no basta con evaluar el proveedor. Hay que evaluar el caso de uso. NIS2 no premia la pereza semántica de llamar “copiloto” a una función que en realidad interviene en decisiones sensibles. Si el sistema toca producción, credenciales, secretos, configuraciones, pipelines o respuesta a incidentes, entra en una zona que exige controles reforzados aunque comercialmente lo vendan como una ayuda inocente.

La ironía aquí es que muchas empresas han dedicado años a predicar “secure by design” mientras introducen asistentes generativos en el SDLC con controles que, siendo generosos, caben en una servilleta. Luego se sorprenden de que el auditor pregunte por validación de código, segregación de datos, revisiones humanas y evidencias de eficacia. Qué misterio.

La pieza olvidada: privacidad y secreto empresarial

La discusión pública suele centrarse en la posibilidad de que un modelo ayude a atacar. Bien. Pero en la empresa real aparece antes otro riesgo más prosaico: que tus propios empleados vuelquen información sensible en sistemas que no controlas lo suficiente. No hace falta una intrusión de película. Basta un prompt mal pensado.

Desde GDPR, el problema es doble. Primero, si hay datos personales en entradas, contexto o documentación asociada, aplican los principios del art. 5 y las obligaciones de seguridad del art. 32. Segundo, si el proveedor actúa como encargado, el art. 28 exige un contrato con garantías adecuadas sobre instrucciones, confidencialidad, subencargados, asistencia y borrado o devolución de datos. Si no tienes claro el papel del proveedor, los fines del tratamiento, la reutilización de datos y la ubicación de procesamiento, no estás “innovando”: estás acumulando riesgo jurídico sin necesidad.

Y no todo acaba en GDPR. También está el secreto empresarial, la información estratégica, la propiedad intelectual interna y la trazabilidad de decisiones. En sectores regulados, una filtración de lógica de detección, reglas antifraude, playbooks internos o documentación de arquitectura puede ser tan delicada como ciertos datos personales. A veces más. Lo notable es que muchas políticas corporativas sobre IA siguen redactadas como si el único problema fuera “no introducir datos confidenciales”. Eso es una instrucción, no un control.

Qué deberían hacer ya las entidades reguladas

Sin convertir esto en una lista de supermercado, hay cinco frentes que sí merecen acción inmediata porque conectan directamente con obligaciones regulatorias existentes y con exposición real.

1. Inventario real de usos, no inventario decorativo

Empieza por identificar dónde se usa IA generativa o modelos fundacionales en desarrollo, operaciones, seguridad, atención, fraude, soporte y proveedores. Si no sabes qué equipos los usan ni para qué, cualquier análisis posterior es teatro. DORA art. 8 y NIS2 art. 21 empujan justo en esta dirección: conocer activos, dependencias y casos de uso.

Ese inventario debe distinguir entre uso directo por empleados, uso embebido en herramientas de terceros y uso por proveedores que procesan o transforman información de tu organización. La diferencia importa porque cambia el vector contractual, el control de logs, la visibilidad y la capacidad de salida.

2. Clasificación por criticidad y tipo de dato

No todos los usos merecen el mismo tratamiento. Un asistente para redactar comunicaciones internas no plantea el mismo riesgo que una herramienta integrada en pipelines de desarrollo o en análisis de incidentes. Clasifica por impacto operativo, acceso a datos sensibles, proximidad a sistemas críticos y capacidad de producir acciones o recomendaciones que acaben en producción.

Si el caso de uso toca datos personales, secretos, credenciales, configuraciones, código propietario o decisiones operativas de alto impacto, exige validación humana reforzada, minimización de datos y restricciones técnicas de entrada y salida. Aquí convergen GDPR arts. 5, 25 y 32 con las medidas de protección de DORA y NIS2.

3. Controles contractuales y de terceros que aguanten una auditoría

Revisa contratos con proveedores de IA y con proveedores que incorporan IA. No sirve una referencia vaga a “medidas de seguridad estándar del sector”. Necesitas claridad sobre uso de datos, subprocesadores o subcontratistas, retención, entrenamiento, notificación de incidentes, localización, continuidad, terminación y derechos de auditoría o, como mínimo, de información suficiente. DORA art. 30 detalla elementos contractuales clave para servicios TIC que apoyen funciones críticas o importantes; si el servicio cae en esa categoría, la exigencia sube bastante.

Si el proveedor rehúye toda transparencia alegando secreto comercial absoluto, ya tienes una señal. No demuestra automáticamente que el servicio sea inaceptable, pero sí que tu apetito de riesgo debe ser muy consciente. La opacidad puede ser un modelo de negocio; rara vez es un control.

4. Monitorización y logging orientados a uso inseguro

Si dejas usar estos sistemas, registra quién los usa, desde dónde, con qué conectores y en qué contextos. No para montar un panóptico corporativo innecesario, sino para poder investigar incidentes, detectar abusos y demostrar diligencia. DORA arts. 10 y 15, junto con la lógica de NIS2 art. 21, apuntan a capacidades de detección y evaluación de eficacia. Sin trazabilidad, la revisión postincidente se convierte en arqueología emocional.

La monitorización debe incluir, cuando sea técnicamente viable y jurídicamente proporcionado, alertas sobre patrones de uso de alto riesgo: grandes cargas de código o documentación sensible, prompts que contengan credenciales o secretos, conexiones con repositorios críticos o automatizaciones no autorizadas.

5. Pruebas y ejercicios que incluyan la variable IA

Si tus red teams, tabletop exercises y simulaciones siguen modelando al atacante como si trabajara sin asistencia avanzada, quizá estés practicando contra una versión ya desactualizada del problema. DORA dedica los arts. 24 a 27 a las pruebas de resiliencia operativa digital, y aunque el marco más exigente se reserva a determinadas entidades, la lógica de probar escenarios realistas vale para todas.

No hace falta caer en fantasías de ciencia ficción. Basta con introducir escenarios donde el atacante usa automatización y asistencia generativa para acelerar reconocimiento, phishing adaptado, scripting, explotación de configuraciones débiles o movimiento lateral asistido. Si tu defensa depende de que el atacante se canse antes que tus controles fallen, quizá no tienes defensa; tienes esperanza.

La objeción razonable: “todavía no hay evidencia concluyente de autonomía ofensiva plena”

Correcto. Y conviene decirlo así, sin teatro. La evidencia pública sobre capacidad ofensiva avanzada de modelos cambia deprisa, depende mucho de metodología, acceso a herramientas, configuración, grado de intervención humana y diseño de tareas. Convertir cualquier experimento en una verdad total sería tan poco serio como negar todo riesgo porque no se haya demostrado autonomía plena en todos los contextos.

Pero esa objeción no exime de actuar. Las obligaciones regulatorias relevantes no exigen esperar a una prueba definitiva de catástrofe para implantar controles. DORA no dice “gestione el riesgo TIC solo cuando el mercado académico alcance consenso metafísico”. NIS2 tampoco. Ambos regímenes trabajan con gestión prudente del riesgo, proporcionalidad, gobernanza y capacidad de respuesta. Ese lenguaje existe precisamente para lidiar con incertidumbre tecnológica sin quedarse congelado.

En otras palabras: la ausencia de certeza absoluta no es una defensa regulatoria. Es, como mucho, una razón para diseñar medidas proporcionales, revisables y basadas en evidencia. Que es justo lo que muchas entidades deberían haber hecho ya.

El error de perseguir titulares y olvidar el modelo de control

Hay otro problema más mundano. Parte de la conversación empresarial sobre IA sigue secuestrada por el ciclo mediático: nuevo modelo, nueva demo, nueva promesa, nuevo susto. Eso empuja a los equipos de compliance y riesgo a responder a titulares en lugar de responder a exposiciones concretas. Mala idea.

Un modelo de control sensato no debería depender de si un proveedor anuncia una novedad con nombre grandilocuente ni de si otra compañía replica semanas después con su propia versión. Debería depender de preguntas bastante menos glamurosas: qué acceso tiene el sistema, qué datos toca, qué decisiones influye, qué dependencias genera, qué registros deja, qué límites contractuales existen y qué plan de salida tienes si algo sale mal o el supervisor pregunta.

Ese enfoque, además, envejece mejor. Los nombres cambian. Las capacidades suben y bajan según la tarea. El control de acceso, la segmentación, la validación humana, la minimización de datos, el inventario de terceros y la trazabilidad siguen siendo útiles después de que el hype haya encontrado otro juguete.

Qué le preguntará un supervisor competente

Si este riesgo llega a una inspección o revisión seria, la conversación no se va a quedar en “¿usan ustedes IA?”. Eso sería demasiado fácil. Las preguntas incómodas serán otras.

• Qué casos de uso tienen identificados y cómo distinguen los experimentales de los integrados en procesos críticos.
• Qué datos entran y salen, con qué base jurídica cuando hay datos personales y con qué controles de minimización y retención.
• Qué proveedores intervienen, qué subcontratación existe y cómo se cumple DORA art. 28 y siguientes o GDPR art. 28 si procede.
• Qué validación humana existe cuando el sistema influye en código, configuraciones, decisiones de seguridad o tratamiento de clientes.
• Qué monitorización y evidencias guardan para detectar uso indebido, investigar incidentes y medir eficacia de controles.
• Qué escenarios han probado en ejercicios de resiliencia, respuesta a incidentes o pruebas técnicas.

Si tu respuesta a varias de esas preguntas es “lo estamos viendo”, la traducción regulatoria suele ser menos amable: no está maduro, no está gobernado o no está bajo control suficiente.

Mi lectura: el listón ya no es demostrar una amenaza apocalíptica, sino justificar tu diligencia

Ese es el cambio real. Antes, muchas organizaciones podían permitirse tratar el riesgo de IA ofensiva como una hipótesis lejana, casi académica. Ahora resulta más difícil sostener esa comodidad. No porque haya una cifra milagrosa o un modelo concreto que resuelva por sí solo toda la cadena de ataque. Eso, hoy por hoy, requiere mucha más cautela en cómo se afirma. El motivo es más prosaico y más sólido: ya existe suficiente base para considerar que estos sistemas pueden alterar de forma material perfiles de riesgo, procesos de control y dependencias de terceros.

Y cuando esa base existe, la carga cambia de lado. Ya no recae en demostrar una catástrofe perfecta para justificar la gestión del riesgo. Recae en la entidad que adopta la tecnología y debe probar que la ha inventariado, acotado, contractualizado, monitorizado y sometido a pruebas con criterio.

Si quieres una formulación brutalmente honesta, aquí va: para una entidad regulada, el mayor riesgo no es que la IA sea demasiado poderosa. El mayor riesgo es introducirla deprisa, documentarla mal y descubrir tarde que nadie decidió realmente quién era responsable de controlarla. Eso sí que tiene un historial regulatorio bastante peor que cualquier keynote.

Conclusión accionable

No hace falta inflar fechas, nombres de productos, porcentajes espectaculares ni costes supuestamente exactos para entender lo esencial. La tesis robusta es otra: la IA avanzada ya merece tratamiento formal dentro del marco de riesgo TIC, terceros, privacidad y resiliencia. DORA, NIS2 y GDPR ofrecen base suficiente para exigir inventario, clasificación, controles técnicos, disciplina contractual, trazabilidad y pruebas realistas.

Si tu organización todavía discute esto como si fuera una moda de innovación y no un asunto de control interno, la pregunta no es si vais tarde. La pregunta es cuánto tardará alguien —auditor, supervisor o atacante— en demostrártelo.