La banca europea ya tiene otro frente abierto: los supervisores avisan que la frontier AI entra por la puerta de ICT, no por la de marketing

La inteligencia artificial más potente ha entrado en el radar supervisor financiero europeo por la puerta que mejor conocen los reguladores: la del riesgo operativo, la dependencia tecnológica y la concentración en proveedores. Lo relevante no es una frase grandilocuente ni una fecha sin documento a la vista. Lo relevante es esto: cuando los supervisores europeos hablan de IA avanzada en clave de riesgo tecnológico, las entidades no deberían leerlo como debate filosófico, sino como anticipo de preguntas de supervisión sobre gobernanza, terceros, incidentes, pruebas y continuidad.

Ese matiz importa. Mucho. Porque el sector financiero lleva meses discutiendo la IA generativa como si el problema principal fuera el uso aceptable por parte de empleados o el riesgo reputacional de un chatbot desbocado. Eso existe, claro. Pero el ángulo supervisor europeo apunta a algo más incómodo: qué ocurre cuando procesos críticos dependen de modelos complejos, opacos y suministrados por un puñado de proveedores con capacidad real de arrastrar a medio mercado si fallan, cambian condiciones o introducen vulnerabilidades.

Sin el documento primario que permita atribuir literalmente determinadas fórmulas a las Autoridades Europeas de Supervisión, conviene no sobreactuar con comillas ni convertir una señal supervisora en una pseudo-norma. Aun así, el sentido regulatorio de fondo sí puede analizarse con rigor: buena parte de los riesgos asociados al uso de IA avanzada en finanzas ya encajan, total o parcialmente, en obligaciones vigentes sobre riesgo ICT, gestión de terceros, seguridad, resiliencia e incidentes. Y eso sitúa a DORA en el centro de la conversación, con GDPR, NIS2 y, en menor medida según el caso de uso, el AI Act orbitando alrededor.

La pregunta correcta no es si la IA tiene regulación propia, sino dónde cae hoy dentro de los marcos ya aplicables

La obsesión de muchas entidades sigue siendo la misma: esperar a que llegue una regla específica que lo deje todo ordenado en un solo texto y con una checklist limpia. Mala suerte. El derecho digital europeo no funciona así. Funciona por capas. Si usas un sistema de IA en una función crítica, el análisis no empieza en una hipotética norma especialísima para “frontier models”. Empieza en tu marco de riesgos, en tus contratos, en tus dependencias tecnológicas, en tus controles de seguridad y en tu capacidad de seguir operando cuando el proveedor falla.

Por eso DORA tiene tanta tracción aquí, aunque no use la expresión de moda en cada párrafo. El Reglamento (UE) 2022/2554 construye obligaciones muy concretas sobre gestión del riesgo relacionado con las TIC, gobernanza, clasificación y notificación de incidentes, pruebas de resiliencia digital y gestión del riesgo de terceros proveedores de servicios TIC. Si una entidad financiera integra IA avanzada en procesos de negocio o de control y esa integración introduce dependencia tecnológica, exposición a incidentes, problemas de integridad de datos o fragilidad operativa, el supervisor no necesita esperar a una “ley de frontier AI” para empezar a mirar.

El anclaje jurídico está ahí. DORA art. 5 exige un marco interno de gobernanza y control que garantice una gestión eficaz y prudente del riesgo relacionado con las TIC. DORA art. 6 obliga a disponer de un marco sólido, completo y bien documentado de gestión del riesgo TIC. DORA art. 11 se mete ya en continuidad del negocio y respuesta y recuperación TIC. Y DORA arts. 28 a 30 aterrizan una de las piezas más espinosas para la IA avanzada: la gestión del riesgo asociado a terceros proveedores de servicios TIC, incluidos requisitos contractuales concretos.

Aquí está el quid. Muchas implementaciones de IA generativa o de modelos avanzados no son “tecnología propia” en sentido material. Son una cadena de dependencias: proveedor de modelo, proveedor cloud, integrador, capa de observabilidad, plugin externo, repositorio vectorial, proveedor de etiquetado, incluso APIs adicionales para moderación o detección de abuso. Eso no es solo arquitectura técnica. Es un mapa de concentración y de riesgo contractual esperando a que auditoría interna pregunte dos cosas demoledoras: quién responde si falla el servicio y cómo seguimos operando sin él.

DORA ya da a los supervisores una caja de herramientas bastante menos ambigua de lo que muchos querrían

Hay un reflejo muy humano —y muy corporativo— de tratar la IA como una excepción que merece gobernanza aparte, comités aparte y PowerPoints aparte. A veces tiene sentido. Otras veces sirve para esconder que los controles normales no están maduros. Si una entidad usa IA en un proceso relevante, lo primero no es inventar un universo paralelo de gobernanza. Lo primero es comprobar si los controles exigidos por DORA están realmente operativos para ese caso de uso.

Empieza por la identificación de funciones críticas o importantes. DORA art. 3, apartado 22, define “función crítica o importante” con un criterio que el sector financiero conoce de sobra por otras normas: si un fallo afectaría materialmente al cumplimiento normativo, al rendimiento financiero, a la solidez de los servicios o a la continuidad de actividades. Tradúcelo a lenguaje llano: si tu modelo ayuda a prevenir fraude, a monitorizar AML, a asistir decisiones de atención al cliente en gran escala, a priorizar incidentes cibernéticos o a sostener operaciones de mercado, ya no estás jugando en el laboratorio de innovación.

Después viene la gobernanza real, no la cosmética. DORA art. 5 pone la responsabilidad en el órgano de dirección respecto del marco de gestión del riesgo TIC. No habla de “dejar que lo vea tecnología” mientras cumplimiento toma notas. Si la entidad adopta herramientas de IA avanzada que cambian su perfil de dependencia o su superficie de ataque, el órgano de dirección debe poder entender, al menos en términos ejecutivos, qué riesgo se asume, qué controles existen, qué tolerancias se han fijado y qué planes de salida son viables. Viables, no decorativos.

La parte de terceros es todavía más clara. DORA art. 28 exige gestionar el riesgo derivado de terceros proveedores de servicios TIC como parte integrante del marco de riesgo TIC. DORA art. 30 enumera elementos contractuales que, en la práctica, deberían obsesionar a cualquiera que consuma IA avanzada vía terceros: descripción completa de funciones y servicios, lugares de prestación, disponibilidad, integridad, acceso, recuperación y devolución de datos, niveles de servicio, obligaciones de asistencia en caso de incidentes, derechos de acceso e inspección y condiciones de terminación. Si tu proveedor de IA no permite una visibilidad razonable sobre subcontratistas, localización de tratamiento, soporte en incidente o salida ordenada, no tienes una innovación puntera. Tienes una dependencia mal documentada.

Y sí, el problema de concentración asoma solo con pronunciarlo. DORA no prohíbe depender de grandes proveedores, pero el capítulo V fue diseñado precisamente porque el sistema financiero europeo ya había aceptado un nivel de concentración tecnológica que quita el sueño a cualquier supervisor mínimamente despierto. Si además encima de la infraestructura cloud colocas una segunda capa concentrada de modelos fundacionales, el riesgo no disminuye por arte de magia. Se compone.

La IA no sustituye a los incidentes TIC; a veces solo les da una forma nueva

Otra tentación frecuente consiste en tratar los problemas de IA como una categoría aislada, casi literaria: alucinaciones, sesgos, prompts maliciosos, outputs extraños. Todo eso puede ser relevante, pero desde el punto de vista operativo muchas incidencias acabarán traduciéndose en categorías que el mundo regulatorio ya reconoce. Pérdida de disponibilidad. Compromiso de integridad. Acceso no autorizado. Exposición de datos. Error de configuración. Dependencia crítica de un tercero. Interrupción de servicio.

DORA arts. 17 a 23 regulan la gestión, clasificación y notificación de incidentes relacionados con las TIC. El lenguaje no fue escrito pensando solo en ransomware clásico o caída de CPDs. Fue escrito para eventos que afecten a la seguridad de redes y sistemas de información y comprometan disponibilidad, autenticidad, integridad o confidencialidad de datos o servicios. Si un sistema basado en IA genera una degradación material de un proceso clave, incorpora datos indebidos a una salida crítica o provoca una interrupción operativa relevante por fallo del proveedor o de la integración, la conversación regulatoria será, con toda probabilidad, una conversación sobre incidente TIC, no sobre creatividad algorítmica.

Esto tiene una consecuencia práctica muy simple y muy incómoda: los equipos que gobiernan IA no pueden vivir separados de quienes gestionan incidentes, continuidad, crisis y terceros. Si siguen separados, la entidad reaccionará tarde, clasificará mal y documentará peor. Y eso se paga en supervisión, aunque a veces se pague antes en operaciones.

También conviene mirar el problema desde GDPR, sin exagerar y sin usarlo como comodín. Si el uso de IA implica tratamiento de datos personales, el Reglamento General de Protección de Datos entra por su propia puerta. GDPR art. 5 exige principios de minimización, exactitud, limitación de finalidad e integridad y confidencialidad. GDPR art. 25 obliga a protección de datos desde el diseño y por defecto. GDPR art. 32 exige medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo. Si, además, se produce una violación de seguridad de los datos personales, GDPR arts. 33 y 34 fijan la lógica de notificación a la autoridad y, en ciertos casos, a los interesados.

La fricción entre IA avanzada y protección de datos no es teórica. Aparece cuando se reutilizan prompts con información sensible, cuando se emplean datasets de ajuste fino mal gobernados, cuando no queda claro si el proveedor utiliza datos del cliente para entrenar o mejorar el servicio, o cuando la explicación interna del modelo es tan pobre que ni siquiera permite defender una evaluación de impacto seria. No hace falta inventar una doctrina nueva para ver el problema. Basta leer el contrato y seguir el dato.

NIS2 y AI Act importan, pero no por la caricatura habitual

Hay dos errores simétricos que conviene evitar. El primero: decir que NIS2 y el AI Act lo cambian todo de inmediato para cualquier entidad financiera que use IA. El segundo: fingir que no importan porque DORA ya ocupa el escenario. Ninguno de los dos aguanta un análisis serio.

NIS2, en la Directiva (UE) 2022/2555, impone medidas de gestión de riesgos de ciberseguridad y obligaciones de notificación a determinadas entidades esenciales e importantes. Su art. 21 enumera medidas que incluyen políticas de análisis de riesgos y seguridad de sistemas, gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, seguridad en adquisición, desarrollo y mantenimiento, evaluación de la eficacia de medidas y formación básica de ciberhigiene. ¿Te suena? Debería. No porque sea una copia de DORA, sino porque los dos marcos comparten una intuición regulatoria básica: la seguridad no se delega a una slide ni a un vendor assessment superficial.

Para entidades financieras, DORA actúa en buena medida como lex specialis respecto de requisitos de resiliencia operativa digital del sector. Aun así, grupos con actividades mixtas, proveedores tecnológicos y estructuras corporativas complejas pueden verse obligados a coordinar ambos marcos. La IA avanzada añade una capa de dificultad, sobre todo en cadena de suministro y dependencia de servicios externos. Si una organización ya está peleándose por identificar qué cae en NIS2 y qué en DORA, añadir modelos avanzados a procesos sensibles sin inventario, sin clasificación y sin mapa de terceros es una invitación a duplicar el caos.

En cuanto al AI Act, la tentación de convertirlo en respuesta automática a todo problema de IA es comprensible y algo perezosa. El Reglamento de IA de la UE se centra en riesgos de sistemas de IA en función de su uso y categoría. No sustituye las obligaciones sectoriales de resiliencia, seguridad, outsourcing o protección de datos. Las complementa cuando el caso de uso entra en su perímetro. Dicho de otro modo: si un sistema de IA utilizado por una entidad financiera entra en categorías de alto riesgo o activa obligaciones específicas del AI Act, habrá que cumplirlas. Pero eso no desplaza DORA art. 28 sobre terceros ni GDPR art. 32 sobre seguridad ni, en su caso, los deberes internos de control ya existentes. La regulación europea no está montando una línea recta. Está montando un cruce.

Esa superposición, que irrita a quien soñaba con una regla única, tiene lógica supervisora. La resiliencia operativa pregunta si puedes seguir funcionando y controlar dependencias. La protección de datos pregunta qué haces con la información personal y con qué garantías. La normativa de IA pregunta qué tipo de sistema despliegas, para qué y con qué salvaguardas. Son preguntas distintas sobre el mismo objeto. Pretender que una respuesta cubre todas suele acabar en agujeros.

Lo que probablemente leerá un supervisor no es “tenemos IA”, sino “tenemos esto controlado”

La discusión más útil para las entidades no es semántica, sino probatoria. ¿Qué evidencias puede enseñar una organización si el supervisor pregunta por su uso de IA avanzada en funciones relevantes? No bastará con una política corporativa genérica sobre uso responsable, dos formaciones y una prohibición solemne de introducir datos confidenciales en herramientas públicas. Eso ya se ha convertido en el equivalente normativo del cartel de “por favor, no tocar”. Nadie serio cree que baste.

Lo que sí empieza a parecer defendible ante supervisión es algo más prosaico y más difícil:

• Inventario real de casos de uso, enlazado a procesos, aplicaciones, propietarios, datos empleados y proveedores implicados.
• Clasificación del impacto sobre funciones críticas o importantes con criterio homologable al marco de riesgo TIC.
• Evaluación de terceros que no se limite a un cuestionario comercial, sino que conecte con DORA arts. 28 a 30: subcontratación, soporte en incidente, localización, salida, auditoría, niveles de servicio y tratamiento de datos.
• Controles de seguridad y acceso adaptados al caso de uso: segregación, registro, validación de entradas y salidas cuando proceda, y restricciones efectivas para evitar usos no aprobados.
• Escenarios de continuidad que respondan a la pregunta más desagradable de todas: si este servicio deja de estar disponible mañana, ¿qué se rompe y cuánto tardamos en operar de forma segura por otra vía?

No hace falta convertir esto en una liturgia burocrática de 200 páginas. De hecho, sería contraproducente. Hace falta que exista de verdad. Y hace falta, además, que tecnología, seguridad, cumplimiento, compras, continuidad y negocio estén trabajando sobre el mismo mapa. Si cada uno tiene su inventario, su taxonomía y su verdad revelada, la entidad no tiene gobernanza. Tiene departamentos.

La gobernanza reforzada no consiste en crear otro comité con siglas memorables

En muchos bancos y aseguradoras la respuesta instintiva a la IA ha sido crear un “AI council”, un “AI review board” o cualquier variante con nombre anglosajón y vocación de posteridad. No es necesariamente mala idea. Puede incluso ser útil. El problema llega cuando ese órgano existe para compensar la debilidad de los controles estructurales y no para coordinarlos.

DORA no exige un comité mágico específico para IA. Exige algo más molesto: que el órgano de dirección apruebe, supervise y sea responsable del marco de gestión del riesgo TIC, y que existan funciones, responsabilidades y mecanismos de control claros. Si la entidad decide que la IA avanzada merece una capa adicional de revisión, perfecto. Pero esa capa tiene que integrarse con outsourcing, seguridad, continuidad, gestión de incidentes, validación de modelos cuando aplique y protección de datos. Si no, se convierte en teatro corporativo. Y el teatro corporativo aguanta hasta que llega el primer incidente serio.

Aquí aparece una contradicción curiosa. Cuanto más “innovadora” presume ser una organización, más probable es que multiplique excepciones al proceso normal de compras y tecnología para acelerar pilotos. Luego, cuando el piloto crece y toca datos, clientes o procesos críticos, nadie sabe muy bien bajo qué paraguas entró, qué due diligence se hizo ni qué limitaciones contractuales aceptó el negocio para llegar antes. Esa cultura de bypass puede ser tolerable en una demo. En una entidad supervisada, no debería sobrevivir al paso a producción.

El gran problema silencioso es la concentración, y no hace falta una cita heroica para verlo

Hay una razón por la que el debate supervisor sobre IA avanzada en finanzas tiende a volver una y otra vez a proveedores, infraestructuras y dependencias. Porque ahí está el riesgo sistémico de verdad. No en el empleado que le pide a un asistente que resuma un PDF, sino en la posibilidad de que una parte creciente de funciones de análisis, soporte, automatización o decisión dependa de muy pocos actores tecnológicos, con capas de opacidad que el sector financiero no suele tolerar bien cuando el proveedor se llama “core banking”, pero extrañamente tolera mejor cuando se llama “modelo fundacional”.

DORA ya introdujo un régimen específico para la supervisión de terceros proveedores críticos de servicios TIC a escala de la UE, precisamente porque la concentración era demasiado evidente para seguir fingiendo sorpresa. El hecho de que la IA avanzada tienda a consumirse como servicio, a menudo sobre grandes nubes y con integración en cadena, hace que esa preocupación no se reduzca, sino que se expanda. No hace falta afirmar que los supervisores hayan calificado formalmente todos los riesgos de frontier AI de una determinada manera para entender la dirección del viaje. Basta seguir la lógica normativa existente.

Si una entidad no sabe si puede sustituir un proveedor de IA en plazos razonables, si no ha evaluado dependencia de subprocesadores o subcontratistas, si carece de derechos de auditoría útiles o si desconoce cómo recuperará datos y configuraciones al terminar el servicio, el problema no es “la IA”. El problema es una gestión débil del riesgo de terceros en un entorno especialmente sensible.

Y eso enlaza con una ironía regulatoria deliciosa: el sector financiero lleva años hablando de “exit plans” en outsourcing, pero cuando la conversación gira hacia herramientas de IA muchos equipos vuelven a comportarse como si el proveedor fuese irremplazable por definición y como si la dependencia fuese el precio natural de la innovación. No. La dependencia puede ser una decisión de negocio. Lo que no puede ser es una sorpresa retrospectiva.

Qué deberían hacer ahora las entidades, sin esperar a que llegue otro documento con más adjetivos que obligaciones

La respuesta sensata no es congelar la adopción de IA ni lanzarse a un festival de controles improvisados. Es usar los marcos ya aplicables para ordenar el terreno y cerrar las lagunas más evidentes. Si una entidad espera a tener una pieza regulatoria perfectamente específica para cada modalidad tecnológica, llegará tarde. El supervisor preguntará antes. Y, en algunos casos, el incidente también.

Un enfoque operativo razonable pasa por cinco movimientos muy concretos.

1. Reabrir el inventario y distinguir entre experimento, uso interno y función relevante

Meter todo en la categoría de “piloto” es cómodo, pero cada vez cuela menos. Hay que identificar qué sistemas o servicios de IA están en pruebas, cuáles se usan internamente con datos reales y cuáles influyen en funciones críticas o importantes. Ese corte define la intensidad de la gobernanza, de la revisión contractual y de los escenarios de continuidad. Sin clasificación, no hay proporcionalidad; hay niebla.

2. Conectar IA con el marco DORA, no gestionarla como planeta aparte

La entidad debería mapear cada caso de uso relevante contra obligaciones internas ya existentes bajo DORA: riesgo TIC, terceros, continuidad, incidentes, pruebas, acceso y registro. Si el caso de uso no encaja en ningún control existente, la pregunta no es “qué interesante”. La pregunta es “qué agujero tenemos”.

3. Revisar contratos con mala leche profesional

En IA avanzada, las condiciones contractuales importan tanto como la funcionalidad. Hay que revisar qué promete realmente el proveedor sobre disponibilidad, soporte en incidente, retención y uso de datos, subcontratación, cambios materiales del servicio, terminación, portabilidad y auditoría. DORA art. 30 no es literatura opcional. Es una guía bastante directa de dónde se van a fijar supervisión, auditoría interna y segunda línea si surge un problema serio.

4. Probar fallos plausibles, no solo escenarios cómodos

Una entidad que usa IA en operaciones relevantes debería preguntarse qué pasa si el servicio deja de responder, devuelve resultados degradados, restringe funcionalidades, introduce cambios no previstos o sufre un incidente de seguridad en el proveedor. DORA arts. 24 a 27, sobre pruebas de resiliencia operativa digital, no fueron diseñados para que el sector hiciera simulacros de ciencia ficción, sino para validar capacidad real de soportar disrupciones. Si el uso de IA es relevante, debería entrar en escenarios de prueba proporcionados al riesgo.

5. Alinear protección de datos desde el principio

Si hay datos personales, la revisión no puede llegar al final como quien añade una firma decorativa. GDPR art. 25 y art. 32 exigen que diseño y seguridad formen parte del sistema desde el arranque. En algunos casos habrá que valorar también si procede una evaluación de impacto, según GDPR art. 35, cuando el tratamiento pueda entrañar un alto riesgo para los derechos y libertades de las personas físicas. No siempre aplicará, pero cuando aplique no conviene descubrirlo después del despliegue.

La objeción habitual: “pero la norma no habla exactamente de frontier AI”

Correcto. Y esa objeción, formulada así, describe la realidad pero no la invalida. Muchas normas tecnológicas no enumeran cada tecnología de moda para ser aplicables. Describen obligaciones por tipos de riesgo, funciones, procesos y dependencias. DORA no necesita nombrar un modelo fundacional concreto para activar obligaciones de gobernanza, terceros, continuidad o incidente cuando una entidad lo integra en una función relevante. GDPR no necesita escribir “prompt injection” para exigir seguridad adecuada al riesgo. NIS2 no necesita listar todos los servicios digitales imaginables para imponer medidas sobre cadena de suministro y gestión de incidentes.

La mejor defensa frente a un supervisor no será decir “esta tecnología aún no tiene su capítulo propio”, sino demostrar que la entidad ha identificado el riesgo, lo ha situado en los marcos existentes y ha ajustado controles allí donde las particularidades técnicas lo exigían. Eso es mucho más creíble. También más trabajoso, claro. El compliance útil rara vez sale gratis.

La otra objeción habitual es que endurecer la gobernanza de IA frenará la innovación. Puede ocurrir si la organización responde con prohibiciones amplias, procesos absurdos o revisiones interminables de casos menores. Pero no es lo que exigen las normas bien leídas. DORA está construido sobre proporcionalidad y gestión del riesgo, no sobre alergia a la tecnología. El problema no es innovar. El problema es innovar con funciones críticas, datos sensibles y terceros opacos sin saber exactamente qué dependencia estás comprando.

La lectura sensata para 2026 y más allá

Sin apoyarse en frases cuya fuente primaria no puede verificarse aquí, la conclusión sigue siendo bastante nítida. La IA avanzada se está consolidando como asunto supervisor financiero no solo por su potencial de negocio, sino por su capacidad de alterar el perfil de riesgo operativo y tecnológico de las entidades. Quien lo lea únicamente como un debate ético o de productividad se está perdiendo la mitad incómoda de la película.

La mitad incómoda habla de DORA art. 5 sobre responsabilidad del órgano de dirección, de DORA art. 6 sobre marco de riesgo TIC, de DORA arts. 17 a 23 sobre incidentes, de DORA arts. 28 a 30 sobre terceros, de GDPR arts. 25, 32, 33 y 35 cuando hay datos personales y alto riesgo, y de NIS2 art. 21 cuando la organización también cae en su ámbito. No suena tan futurista, lo sé. Pero precisamente por eso importa: porque permite supervisar ya, sin esperar al próximo eslogan regulatorio.

Si tu entidad está desplegando IA avanzada en procesos que importan, la pregunta no es si vendrá regulación. Ya tienes bastante sobre la mesa. La pregunta es otra: cuando te pidan demostrar control, ¿vas a enseñar un catálogo de pilotos y una política bonita, o un sistema de gobernanza que aguanta una inspección y, llegado el caso, una crisis real?

Ese examen no lo corrige un chatbot.