Guía de la BaFin sobre IA: gestionar los riesgos TIC en entidades financieras conforme a DORA

Origen: del discurso a la publicación

La guía la anunció Nikolas Speer, director ejecutivo de Supervisión Bancaria de la BaFin, el 4 de diciembre de 2025 en su conferencia «IT-Aufsicht im Finanzsektor: Das erste Jahr DORA» (la supervisión de TI en el sector financiero: el primer año de DORA), con la fórmula «No es un nuevo catálogo de obligaciones, sino una ayuda». El 18 de diciembre de 2025 llegó la nota informativa «Inteligencia artificial: la BaFin publica una guía sobre riesgos TIC». La edita la unidad CTF 5 del departamento de Riesgos Cibernéticos y Tecnología en el Sector Financiero. La versión alemana, «Orientierungshilfe zu IKT-Risiken beim Einsatz von KI in Finanzunternehmen» (versión del 18 de diciembre de 2025, 38 páginas), es el original; la traducción inglesa, «Guidance on ICT Risks in the Use of AI at Financial Entities» (versión del 23 de enero de 2026, 35 páginas), se publicó el 30 de enero de 2026.

Naturaleza jurídica: no vinculante, pero no un cheque en blanco

La guía se presenta como una «ayuda no obligatoria», se basa, entre otras cosas, en conversaciones con entidades financieras, «no constituye una interpretación vinculante de DORA por parte de la BaFin» y «no define expectativas supervisoras» (caps. I y I.2); también las medidas del caso práctico se presentan expresamente como ejemplos. Lo vinculante sigue siendo DORA, el RTS RMF y el RTS de subcontratación. No obstante, el informe anual 2025 de la BaFin habla de unas «expectativas actualizadas» que, según el informe, se comunicaron a través de la guía. De ello no se derivan obligaciones, pero conviene tomarse en serio la formulación como señal de la práctica supervisora.

Destinatarios y límites

Se dirige a las entidades financieras en el sentido del art. 2(2), en relación con el art. 2(1)(a) a (t), DORA, en particular entidades CRR y empresas de seguros sujetas a Solvencia II; sus destinatarias principales son las entidades supervisadas por la BaFin que deben cumplir los arts. 5 a 15 DORA. Según la guía, el marco simplificado del art. 16 DORA requiere un análisis aparte y no es objeto del documento. En cuanto al contenido, trata exclusivamente de los riesgos TIC y de su tratamiento con arreglo a DORA y a los RTS complementarios; la metodología matemática de los modelos, incluidos los datos, el desarrollo y la validación, queda fuera (cap. I.1).

La guía se concibe como un «documento vivo» (cap. I.3); actualmente es determinante la versión del 18 de diciembre de 2025 (DE) o del 23 de enero de 2026 (EN). La BaFin ya remite a ella: en «Risiken im Fokus 2026» (sus riesgos prioritarios para 2026), del 28 de enero de 2026, que cita como riesgos de la IA, entre otros, la dependencia de proveedores terceros de nube y de modelos de IA, así como el envenenamiento de datos y de modelos (data and model poisoning); y en la entrevista del BaFinJournal del 29 de julio de 2026 sobre la KI-MIG, la ley alemana que designa a las autoridades nacionales competentes con arreglo al Reglamento de IA.

Tres pasos para construir el concepto (cap. I.1)

1. 1
   Art. 3(1) Reglamento de IAAdoptar la definición legal

   Un sistema de IA es un sistema basado en una máquina diseñado para funcionar con distintos niveles de autonomía, que puede mostrar capacidad de adaptación tras el despliegue y que, para objetivos explícitos o implícitos, infiere de la información de entrada que recibe la manera de generar resultados de salida, como predicciones, contenidos, recomendaciones o decisiones, que pueden influir en entornos físicos o virtuales.

2. 2
   C(2025) 5053 final, apdo. 11Interpretar «basado en una máquina»

   Los sistemas de IA se desarrollan con ayuda de máquinas y funcionan en ellas. Según las directrices de la Comisión del 29 de julio de 2025, la máquina abarca hardware (unidades de procesamiento, memoria, unidades de red, interfaces de entrada y salida) y software (entre otros, código fuente, sistemas operativos y aplicaciones).

3. 3
   Art. 3(2) DORAEncuadrar en DORA

   Los sistemas de IA son, por tanto, un subtipo de las redes y sistemas de información. Se trata de una combinación de activos de TIC e infraestructura de TIC en la que se implementa un modelo matemático complejo; el propio modelo es un activo de TIC (software).

No se consideran las características de autonomía y capacidad de adaptación del Reglamento de IA, ni la metodología matemática de los modelos, incluidos los datos utilizados, su desarrollo y su validación. Así pues, la guía no examina lo bien que calcula un modelo, sino lo seguro y resiliente que es el sistema en el que se ejecuta. El tipo y el alcance de un sistema de IA dependen de cada caso y deben corresponder, en particular, a la finalidad de negocio, a la situación de riesgo y al contexto.

IA oculta: cuando el software se convierte en sistema de IA sin que nadie lo advierta

El cap. III.2 describe el reto de detectar, durante las pruebas, si las aplicaciones integran modelos de IA externos, por ejemplo a través de API: un software concebido inicialmente como aplicación sin IA puede convertirse así en un sistema de IA. El cap. III.1 añade que el código generado por IA puede invocar funciones de IA desconocidas para el usuario. Según el caso práctico (variante 3), los asistentes de IA integrados en software estándar se invocan en ocasiones sin que los usuarios lo sepan; las consideraciones finales señalan que a menudo vienen incluidos en el software estándar.

La consecuencia para el inventario: la gestión de los activos de información y de TIC exige, como obligación, una política y procedimientos (art. 8(4) DORA, en relación con los arts. 4 y 5 RTS RMF). Según el cap. IV.1, también los componentes de los sistemas de IA deben identificarse, clasificarse, documentarse y supervisarse de forma continua. Quien solo inventaría «proyectos de IA» pasa por alto la IA que llega a la organización con la próxima actualización de un software estándar o a través de una API.

Nota sobre la cita: en extractos de texto del PDF alemán, la referencia a las directrices de la Comisión aparece como «Rn. 116»; se trata del apdo. 11 (Rn. 11) con la nota a pie de página 6.

Por qué el ciclo de vida es el mejor marco de ordenación

Según el cap. I.2, los riesgos TIC específicos no guardan relación con la posición de un sistema de IA en la cadena de valor; se derivan de su integración en el entorno de TIC. Por eso la guía sigue el ciclo de vida de la IA: desde la obtención de datos, pasando por el desarrollo del modelo y su puesta a disposición, hasta la operación continuada y la retirada. En cada fase ha de garantizarse la seguridad y la resiliencia del sistema de IA, y los sistemas de IA deben tenerse en cuenta en el marco de gestión del riesgo relacionado con las TIC existente. La figura 1 asigna cinco vectores de ataque: datos y modelo de IA (cap. III); entrada, salida y el propio sistema de TIC (cap. IV); la ciberseguridad y la seguridad de los datos actúan de forma transversal (cap. V).

Ámbitos de uso según el cap. I

Proporcionalidad conforme al art. 4 DORA

El art. 4 DORA obliga a aplicar la gestión del riesgo relacionado con las TIC de forma proporcionada al tamaño, al perfil de riesgo global y a la naturaleza, escala y complejidad de los servicios y actividades. La guía lo traslada a la IA: las aplicaciones integradas en funciones esenciales o importantes requieren medidas de seguridad y control más amplias que, por ejemplo, los asistentes de autoservicio basados en IA que están por completo bajo supervisión humana y no intervienen en procesos de decisión (cap. I.2). Los sistemas de IA se evalúan como los sistemas de TIC, según su perfil de riesgo, su complejidad y las funciones a las que dan soporte (cap. II.1). La guía gradúa expresamente según la criticidad en estos puntos:

• Estrategia de IA: gana peso cuando la IA da soporte a funciones esenciales o importantes (cap. II.2).
• Funciones de control y auditoría interna: su participación en la implantación depende de la criticidad del sistema de IA (cap. II.2).
• Pruebas: alcance proporcional a la criticidad (art. 16(2) RTS RMF); pruebas adversarias y pruebas de estrés «en función de la criticidad» (cap. III.2).
• Detección: registro de eventos basado en el riesgo; umbrales e indicadores de comportamiento anómalo en funciones esenciales o importantes (cap. IV.1).
• Nube: SLA, estrategia de salida, pruebas de contingencia y derechos de auditoría sin lagunas cuando se da soporte a funciones esenciales o importantes (cap. IV.2).

Estrategia de IA y hoja de ruta tecnológica

Según el cap. II.2, las entidades financieras elaboran «a menudo» una estrategia de IA alineada con la estrategia global, la estrategia de riesgos y, en su caso, la estrategia de TIC y la estrategia de resiliencia operativa digital, y la someten a la aprobación del órgano de dirección, ya sea como estrategia independiente o integrada en una estrategia de nivel superior. Su peso aumenta sobre todo cuando la IA da soporte a funciones esenciales o importantes. Puede servir de base una hoja de ruta tecnológica que fije los recursos, las capacidades y las inversiones de TIC para el uso de la IA; una gestión continua de la innovación ayuda a evaluar nuevas tecnologías de IA. Resulta conveniente cubrir y documentar en un proceso todos los pasos, desde la estrategia hasta la retirada, pasando por el desarrollo. Según la guía, es importante comprobar antes de la implantación si los procesos pertinentes están diseñados para la IA y si existe sensibilización sobre el manejo de los activos de información.

Obligación y práctica de un vistazo

Según el cap. II.2, resulta útil formular directrices generales en consonancia con la estrategia de resiliencia operativa digital y con las políticas y normas de seguridad de la información. Las reglas específicas para los proveedores terceros de servicios TIC y sus servicios deberían tener en cuenta, idealmente, una evaluación de riesgos, las indicaciones del proveedor y medidas propias de reducción del riesgo. Los requisitos generales deberían concretarse para cada caso de uso, comprobando a la vez si hacen falta medidas adicionales específicas de la IA.

Anclaje de las competencias: la guía basa los requisitos de competencia en el art. 5(4) y el art. 13(6) DORA, no en el art. 4 del Reglamento de IA. La regla de alfabetización en materia de IA del Reglamento de IA se aplica en paralelo desde el 2 de febrero de 2025; el Reglamento (UE) 2026/1744 la ha suavizado: en lugar de garantizar, en la mayor medida posible, un nivel suficiente de alfabetización en materia de IA, deben adoptarse medidas para apoyar el desarrollo de dicha alfabetización.

El art. 6(1) DORA exige un marco de gestión del riesgo relacionado con las TIC sólido, completo y bien documentado, como parte del sistema global de gestión de riesgos. La guía destaca esta norma en un recuadro de cita y enumera como componentes del marco, entre otros: identificación, protección y prevención, detección, respuesta y recuperación, aprendizaje y evolución, y comunicación (arts. 8 a 11, 13 y 14 DORA). Según la guía, la integración de los sistemas de IA comprende la identificación de vulnerabilidades, por ejemplo en el entrenamiento de modelos, en los pipelines de datos o en la inferencia, así como la evaluación de criterios de riesgo cuantitativos y cualitativos (cap. II.3).

Lo que la guía deriva para cada componente de DORA

Importante para la delimitación: el caso práctico considera que las alucinaciones no son directamente relevantes desde el punto de vista de las TIC (fase 4). De los aspectos de la calidad de los datos, solo la integridad es un objetivo de protección de DORA; para los demás, el Reglamento no contiene disposiciones (cap. V.2). La supervisión de la deriva del modelo aparece como medida de tratamiento que debe documentarse, no como un riesgo TIC propio. La guía sitúa los requisitos de calidad de los datos como componente típico de las estructuras de gobernanza de la IA; una alta calidad de los datos, sobre todo de los de entrenamiento, sigue siendo un requisito esencial para el uso de la IA.

Revisión anual e informe

Es obligatorio revisar el marco de gestión del riesgo relacionado con las TIC al menos una vez al año, así como tras incidentes graves relacionados con las TIC, instrucciones supervisoras o conclusiones derivadas de pruebas y auditorías (art. 6(5) DORA). A petición de la autoridad competente debe presentarse un informe sobre la revisión; el art. 27 RTS RMF exige para ello un formato electrónico que permita búsquedas. Entre los contenidos obligatorios según el art. 27(2) RTS RMF figuran, entre otros, un resumen del perfil de riesgo TIC actual y a corto plazo y del panorama de amenazas, la fecha de aprobación por el órgano de dirección, los hallazgos con su nivel de gravedad y las medidas correctoras con plazos y responsables. La guía añade que, si es necesario, el informe puede enriquecerse con información específica sobre los sistemas de IA.

Competencias: quién debe saber qué

Según el cap. III.1, el personal con tareas de IA se enfrenta al reto de adquirir competencias sobre el funcionamiento de los sistemas de IA, sus riesgos y las particularidades de la operación en la nube y on-premise; cuanto más técnica sea la tarea, más específico ha de ser el conocimiento. Dado el rápido progreso, la guía considera necesarias una formación periódica y una observación continua de la dinámica de desarrollo. Para el órgano de dirección y los mandos directivos remite al art. 5(4) y al art. 13(6) DORA. Cuando las áreas de negocio crean sus propias aplicaciones con ayuda de asistentes de IA, cita el art. 16(9) RTS RMF: esta norma sustenta el tratamiento equivalente del end-user computing (EUC), mientras que las obligaciones de competencia derivan del propio DORA.

Obligación y práctica en el proceso de desarrollo

Proceso de entrenamiento: cuatro enfoques que, según la guía, han resultado útiles

• Los datos de entrenamiento y de prueba proceden de fuentes fiables.
• Las bibliotecas (de código abierto) y los paquetes de software utilizados en el entrenamiento no contienen vulnerabilidades conocidas.
• Todo el proceso de entrenamiento se documenta y se versiona.
• Los análisis de seguridad detectan manipulaciones ocultas en el modelo o en los datos de entrenamiento.

Según el cap. III.1, las bibliotecas de código abierto —en el caso extremo, un modelo de código abierto implementado, entrenado y operado en hardware propio— entrañan dos riesgos adicionales: la introducción de código malicioso y bibliotecas que dejan de mantenerse al cabo de unos años y arrastran vulnerabilidades identificadas pero no corregidas. Al código generado por IA se le aplican las mismas reglas que al escrito por personas. El reto consiste en comprobar si invoca funciones de IA desconocidas para el usuario; esto puede determinarse, entre otros medios, mediante análisis estático de código (art. 16(3) RTS RMF). Los análisis más profundos del código fuente pueden aportar una seguridad adicional, y una documentación adecuada ha demostrado ser recomendable para las pruebas posteriores.

Lo que el RTS RMF regula con carácter vinculante

Las entidades financieras deben desarrollar, documentar e implementar pruebas. El alcance de las pruebas debe ser proporcional a la criticidad de los procesos de negocio y activos de TIC afectados y comprobar si los nuevos sistemas de TIC —y, por tanto, los sistemas de IA— son adecuados para su finalidad prevista (art. 16(2) RTS RMF). Antes de su uso en producción, el código fuente debe revisarse en busca de anomalías con métodos estáticos y dinámicos, incluidas pruebas de seguridad de los sistemas expuestos a internet (art. 16(3) RTS RMF). El software propietario y, cuando sea posible, el código fuente de proveedores terceros de servicios TIC y de proyectos de código abierto deben analizarse y probarse antes de su puesta en producción (art. 16(8) RTS RMF).

Tres retos específicos de la IA (cap. III.2)

Componentes de prueba según la criticidad

Los procesos de operación han de cubrir todo el ciclo de vida —desarrollo, instalación, operación y desinstalación— y documentar todas las actividades de operación, por ejemplo los logs de los procesos de inferencia del modelo (art. 8 RTS RMF). Los activos de información y de TIC, incluidos los componentes de IA, deben identificarse, clasificarse, documentarse y supervisarse de forma continua (art. 8(4) DORA, en relación con los arts. 4 y 5 RTS RMF; véase el capítulo 2). La guía califica los derechos de acceso basados en roles a los modelos de IA y a los datos de entrenamiento como una herramienta eficaz que debe revisarse y documentarse periódicamente; el art. 21 RTS RMF exige el principio de mínimo privilegio y una revisión de los derechos al menos una vez al año, y al menos cada seis meses en los sistemas que dan soporte a funciones esenciales o importantes.

Los componentes de la operación de un vistazo

La redacción muestra qué es obligación y qué es práctica: los planes «deben» probarse al menos una vez al año (art. 11(6)(a) DORA), y el art. 10 RTS RMF exige análisis automatizados de vulnerabilidades al menos semanales para los activos que dan soporte a funciones esenciales o importantes. En cambio, la guía describe la supervisión continua, el registro exhaustivo de las decisiones de IA y los umbrales de comportamiento anómalo específicos de la IA como útiles, recomendables o ventajosos; la obligación general de contar con mecanismos de detección con umbrales de alerta (art. 10(1) y (2) DORA) no se ve afectada. Para la operación y el mantenimiento de un asistente de IA (fases 4 y 5), el caso práctico añade una supervisión de las interacciones con la IA adaptada a cada situación, actualizaciones automatizadas, un plan de respuesta a incidentes de seguridad (SIRP) y un panel de cumplimiento con la versión del modelo, las evaluaciones de riesgos y las responsabilidades. La desinstalación se trata en el capítulo 9.

Evidencias que puede presentar (VamiSec)

• Inventario de IA con componentes, criticidad, propietario, origen de los datos y fechas de fin de soporte de los proveedores, incluidas las fechas de obsolescencia de las versiones de modelo
• Planificación de capacidad y análisis de la monitorización de la infraestructura de IA
• Diseño del registro de eventos con umbrales y evidencia de la verificación de su eficacia
• Recertificación de los derechos de acceso a modelos y datos de entrenamiento
• Actas de las pruebas de los planes de continuidad de la actividad con escenarios de caída de la IA

La guía ya identifica el riesgo en el cap. II.1: la reutilización incontrolada o la eliminación insegura de aplicaciones de IA pone en peligro datos sensibles del modelo o de la empresa. El caso práctico es más concreto: los datos y modelos históricos pueden utilizarse de forma indebida o quedar expuestos públicamente sin querer. De ahí concluye que la retirada de los LLM y de las fuentes de datos asociadas debe planificarse «como en todos los activos de TIC». Ya el cap. II.2 sugiere cubrir y documentar en un único proceso todos los pasos relevantes para la IA, desde la estrategia hasta la retirada.

Obligación, práctica, recomendación: claramente separadas

Un sistema de IA deja tras de sí algo más que una aplicación. Entre los activos de información y de TIC, la guía incluye, entre otros, los conjuntos de datos de entrenamiento, las implementaciones de modelos, las bibliotecas de software, el hardware y el software de desarrollo propio y de terceros (cap. IV.1); para el borrado, el caso práctico añade las interacciones históricas con la IA. Según nuestra experiencia, las bases de conocimiento RAG, las copias de modelos en los backups y las claves de API y cuentas de servicio pertenecen a la misma lista.

Runbook de retirada (recomendación de VamiSec)

1. 1
   Definir el desencadenante y el alcance

   La retirada, el cambio de versión y el cambio de proveedor activan el mismo proceso. Derivar del inventario de IA todos los artefactos: versiones de modelos, datos de entrenamiento, bases de conocimiento, logs, interfaces y cuentas.

2. 2
   Cortar las dependencias

   Desactivar interfaces, cuentas de servicio y claves de API; bloquear los accesos de los usuarios (art. 21 RTS RMF). Desactivar de forma expresa las versiones obsoletas de los modelos, no limitarse a sacarlas del enrutamiento.

3. 3
   Ponderar conservación frente a borrado

   A los registros se aplican los plazos de conservación fijados conforme al art. 12 RTS RMF; a las interacciones con datos personales, el RGPD. Resolver el conflicto antes del borrado y dejarlo documentado.

4. 4
   Borrar de forma irrecuperable

   Borrar modelos, datos y copias, también en los backups y en el proveedor; cuando sea posible, mediante borrado criptográfico por destrucción de las claves (art. 7 RTS RMF).

5. 5
   Acreditar y cerrar el inventario

   Archivar el registro de borrado y la confirmación del proveedor, cambiar el estado en el inventario a «retirado» e incorporar las conclusiones a la evaluación de riesgos TIC.

Las medidas del caso práctico son ilustrativas; lo vinculante es el requisito de desinstalación del RTS RMF. En la IA en la nube, el borrado en el proveedor forma parte, a nuestro juicio, de la planificación de la salida (capítulo 10).

El modelo estructural es la comunicación supervisora sobre externalizaciones a proveedores de servicios en la nube (Aufsichtsmitteilung): la evaluación conjunta de la BaFin y el Deutsche Bundesbank, versión revisada de la orientación sobre la nube de noviembre de 2018. Algunos de sus aspectos «también pueden trasladarse […] a los sistemas de IA» (cap. IV.2). Persiste una diferencia terminológica: la comunicación supervisora razona en términos de externalizaciones (significativas); DORA, en términos de funciones esenciales o importantes.

Dónde empieza la obligación

Lo vinculante es el propio DORA: antes de celebrar cualquier acuerdo sobre servicios TIC deben evaluarse los riesgos y cumplirse las obligaciones de diligencia debida (art. 28(4) DORA); los contenidos mínimos del art. 30(2) DORA se aplican a todos los contratos. Los contenidos contractuales adicionales (art. 30(3)), las estrategias de salida (art. 28(8)) y el RTS de subcontratación solo entran en juego en funciones esenciales o importantes. Por ello, a nuestro juicio, un asistente de redacción que no interviene en decisiones necesita un conjunto contractual más ligero que un modelo de scoring en una función esencial o importante; aun así, la clasificación debe documentarse (art. 8(1) DORA).

Tres matices en las citas

• El art. 3(6) ITS del registro de información regula el identificador de los subcontratistas (LEI o EUID); la obligación de registrarlos figura en el art. 3(2)(b).
• El art. 28(8), párrafo tercero, DORA se refiere a las pruebas de los planes de salida; las pruebas de contingencia de funciones esenciales o importantes externalizadas se apoyan con más precisión en el art. 11(4) DORA, citado en el cap. IV.1 (interpretación de VamiSec).
• Para la devolución de los datos y su formato, la base más precisa es el art. 30(2)(d) DORA; la BaFin no lo cita (interpretación de VamiSec).

El punto de partida es el art. 9(2) DORA: las entidades financieras diseñan, adquieren e implantan políticas, procedimientos, protocolos y herramientas de seguridad de las TIC. Según la guía, los sistemas de IA deberían tenerse debidamente en cuenta en ellos, con medidas de seguridad de la red, de transmisión de datos (art. 2(1) RTS RMF) y de protección frente al uso indebido de los datos. Para la IA, esto significa que, además de los accesos a los modelos, hay que proteger el intercambio de datos entre los datos de entrenamiento, los componentes del modelo y los usuarios finales.

Cinco buenas prácticas para sistemas de IA

• Supervisión continua en tiempo real para detectar comportamientos anómalos, p. ej., patrones de decisión inesperados
• Mecanismos de protección frente a entradas adversarias, como los mecanismos de filtrado
• Registro de las salidas relevantes y de las llamadas a la API para análisis posteriores
• Actualizaciones periódicas del sistema de IA frente a nuevas amenazas
• Plan de emergencia para incidentes de seguridad en el sistema de IA

Importante para la acreditación: la guía presenta estas cinco medidas como buenas prácticas a continuación de la referencia a los arts. 24 y 25 DORA, pero no las fundamenta en esos artículos. La obligación es el programa de pruebas; cómo se configura para la IA es práctica. Las frecuencias estrictas figuran en el texto jurídico:

La guía contempla la IA, sobre todo, como objetivo de ataque. Con el aviso ESRB/2026/3 de la Junta Europea de Riesgo Sistémico (JERS), del 25 de junio de 2026, y la carta del BCE del 7 de julio de 2026, la IA pasa a considerarse además una herramienta de ataque: la JERS describe modelos de frontera que encuentran vulnerabilidades y generan exploits funcionales; el BCE ha pedido a las entidades significativas que presenten un plan de acción a su Equipo Conjunto de Supervisión (JST) a más tardar el 31 de octubre de 2026. A nuestro juicio, ambos apuntan sobre todo a un ámbito que el art. 10 RTS RMF ya regula: la gestión de vulnerabilidades y parches, solo que a un ritmo mucho mayor.

Según la guía, la clasificación por confidencialidad, integridad y disponibilidad es la «base más importante» para un tratamiento y un almacenamiento seguros: determina cómo y dónde pueden tratarse y almacenarse los datos; según el cap. V.2, es un complemento útil para operar IA en la nube. Se citan el art. 5(2)(b) y el art. 11(2)(k) RTS RMF. En sentido estricto, la letra b) regula criterios para evaluar la criticidad de los activos y la letra k), requisitos para los activos operados por proveedores terceros de servicios TIC; la obligación general de clasificar los activos de información y de TIC figura, según nuestra lectura, en el art. 8(1) DORA.

Buenas prácticas, adaptables a cada entidad

• Cifrado y firma de los modelos frente a modificaciones no autorizadas
• Operación en entornos seguros, p. ej., contenedores
• Modelo de confianza cero para el acceso a los servicios de IA
• Protección frente a ataques de inyección; limitación de tasa (rate limiting) frente a la denegación de servicio

Para los asistentes LLM, el caso práctico sitúa la protección ya en el origen: detección automatizada de datos confidenciales, privacidad diferencial (differential privacy) frente a inferencias a partir de consultas múltiples, tokenización de los datos sensibles antes de su tratamiento y, para la variante 3, un nivel de autorización de datos más bajo que los usuarios no puedan rebasar por su cuenta (caso práctico, fase 1 y variante 3).

Calidad de los datos: solo la integridad es objetivo de protección de DORA

Según la guía, la calidad de los datos abarca normalmente la exhaustividad, la exactitud, la validez, la coherencia, la adecuación o representatividad y la integridad. Solo la integridad es un objetivo de protección de DORA; para los demás aspectos, el Reglamento no contiene normas. Aun así, la exactitud, la fiabilidad y el rendimiento de la IA dependen de ellos, sobre todo en los datos de entrenamiento; por eso, las pautas sobre calidad de los datos suelen tener su lugar en la gobernanza de la IA. En consonancia, el caso práctico incluye las alucinaciones entre los retos que no son directamente relevantes para las TIC.

El cap. V.2 se apoya exclusivamente en el RTS RMF (arts. 5, 6, 7, 11 y 14); en esta sección, la guía no cita ningún artículo de DORA.

Las cifras proceden del análisis de la BaFin sobre los incidentes TIC de 2025 notificados en el marco de DORA y del artículo del BaFinJournal «Vernetzung vervielfacht IT-Risiken» («La interconexión multiplica los riesgos de TI»), del 16 de julio de 2026, que presenta ese análisis. Abarcan todos los incidentes TIC notificados; la BaFin no publica cifras específicas de la IA. Aun así, la proporción atribuible a terceros es instructiva: a nuestro juicio, quien obtiene un modelo a través de una API depende también de la situación de incidentes de su proveedor.

No todo incidente relacionado con las TIC en un sistema de IA debe notificarse, pero todos deben registrarse (art. 17 DORA). La gravedad de un incidente se determina con los criterios de clasificación del art. 18 DORA, que la propia guía no cita. Las ciberamenazas importantes pueden notificarse de forma voluntaria (art. 19 DORA).

Buenas prácticas según la guía

1. 1
   Identificar amenazas específicas de la IA

   Identificar de forma específica las amenazas propias de la IA, p. ej., la manipulación de los datos de entrenamiento.

2. 2
   Detectar incidentes de IA

   Detectar errores del modelo, pérdidas de datos o problemas de rendimiento de modo que se pueda actuar de inmediato.

3. 3
   Analizar el impacto y clasificar la gravedad

   Análisis del impacto, por ejemplo en cuanto a pérdida de datos, y clasificación de los niveles de gravedad.

4. 4
   Integrar en la respuesta a incidentes

   Integrar los incidentes de los sistemas de IA en el plan general de respuesta a incidentes, con los roles y las vías de comunicación y escalado que el art. 17 DORA ya prescribe.

5. 5
   Analizar las causas y aprender

   Análisis detallado de las causas raíz para corregir vulnerabilidades sistemáticas en modelos y procesos y evitar de forma duradera que se repitan.

Para la IA en la nube, la guía recomienda además acuerdos sobre la notificación de los incidentes TIC que se originen en sistemas de IA, así como recursos internos suficientes y cualificados para la evaluación y la respuesta. Para los asistentes de IA, el caso práctico añade un plan de respuesta a incidentes de seguridad (SIRP) y ciberataques simulados que ponen a prueba los tiempos de respuesta (fase 5).

Perspectiva: la propuesta Ómnibus Digital de la Comisión del 19 de noviembre de 2025 (COM(2025) 837 final) —que no debe confundirse con el Reglamento Ómnibus Digital sobre la IA, ya en vigor, Reglamento (UE) 2026/1744— prevé, entre otras cosas, canalizar las notificaciones del art. 19(1) DORA a través de un punto de entrada único. Se trata de una propuesta; sigue siendo determinante el art. 19 DORA en su versión vigente.

Se analizan tres variantes de infraestructura (figura 2): on-premise, nube con la aplicación de IA en el tenant propio y nube con la aplicación de IA fuera del tenant propio. Las formas mixtas son expresamente posibles; en ese caso, habrá que adaptar el análisis de riesgos. El caso práctico no considera los costes de inversión ni los costes corrientes. Las entidades financieras deberían aplicar las medidas más adecuadas para su situación de riesgo específica.

Seis fases: riesgos presentes en todas las variantes

Tres variantes, tres perfiles de riesgo

Ni el caso práctico ni el cap. VI contienen referencias a DORA. Quien vincula las medidas del caso práctico con anclajes normativos realiza una asignación propia: las obligaciones en sí derivan de DORA y del RTS RMF.

Reglamento de IA y KI-MIG: dónde se ven afectados en concreto bancos y aseguradoras

Según el anexo III, punto 5(b), del Reglamento de IA, son de alto riesgo los sistemas destinados a evaluar la solvencia de personas físicas o a establecer su calificación crediticia —salvo los utilizados para detectar fraudes financieros— y, según el punto 5(c), los sistemas destinados a la evaluación de riesgos y la fijación de precios en relación con personas físicas en los seguros de vida y de salud. Conforme al Reglamento Ómnibus Digital sobre la IA (Reglamento (UE) 2026/1744), las obligaciones para sistemas de alto riesgo (capítulo III, secciones 1 a 3, del Reglamento de IA) se aplican a estos sistemas a partir del 2 de diciembre de 2027, en lugar del 2 de agosto de 2026 previsto inicialmente.

Conforme al § 2(3) KI-MIG, la BaFin vigila los sistemas de IA que guardan relación directa con una actividad financiera regulada y que las entidades supervisadas introducen en el mercado, ponen en servicio o utilizan; según la BaFin, por ejemplo, los chatbots de atención al cliente, la evaluación de la solvencia y la evaluación de riesgos en los seguros de vida y de salud. La IA en el ámbito de recursos humanos sigue correspondiendo a la Bundesnetzagentur. La BaFin pone el foco en las prácticas prohibidas (art. 5), las obligaciones de transparencia (art. 50) y la alfabetización en materia de IA (art. 4 del Reglamento de IA); a partir del 2 de diciembre de 2027 se suman los sistemas de alto riesgo del anexo III, punto 5(b) y (c). En la entrevista del BaFinJournal sobre la KI-MIG del 29 de julio de 2026, la BaFin remite expresamente a la guía.

Supervisión europea: misma dirección, acentos propios

• EIOPA, dictamen (Opinion) del 6 de agosto de 2025 (EIOPA-BoS-25-360): explica a las autoridades nacionales de supervisión, con un enfoque basado en el riesgo y proporcionado, cómo aplicar la IDD, Solvencia II y DORA a la IA en las aseguradoras, sin nuevos requisitos; excluye la IA prohibida y la de alto riesgo según el Reglamento de IA.
• EBA, ficha informativa (factsheet) del 21 de noviembre de 2025: contraste de los requisitos de alto riesgo del Reglamento de IA (con foco en la solvencia) con la CRD/el CRR, DORA y el resto de la normativa de supervisión bancaria: sin contradicciones sustanciales; la EBA no considera necesarias nuevas directrices propias.
• ESMA, declaración pública (Public Statement) del 30 de mayo de 2024: la IA en servicios de inversión para clientes minoristas debe cumplir las obligaciones de MiFID II; la responsabilidad sigue recayendo en el órgano de dirección.
• EBA, EIOPA y ESMA, declaración JC 2026 25 del 31 de julio de 2026: DORA y el Reglamento de IA constituyen una base sólida frente a los riesgos TIC derivados de los modelos de IA de frontera; la prevención incluye un inventario completo de activos que abarque los componentes de IA/ML.

El requisito de explicabilidad de los modelos de IA no es una novedad de la 9.ª modificación de las MaRisk; ya figuraba con idéntico contenido en el AT 4.3.5 de la 7.ª modificación (circular 05/2023 (BA)).

1. 1
   Fase 0 · Mes 1Aclarar mandato y régimen aplicable

   El órgano de dirección confirma su responsabilidad última (art. 5(2)(a) DORA) y asigna presupuesto; comprobar si se aplican los arts. 5 a 15 o el marco simplificado del art. 16 DORA; designar por función a los responsables de los resultados de la IA.

2. 2
   Fase 1 · Meses 1–3Crear transparencia

   Elaborar el inventario de IA, incluida la IA vía API y la integrada en software estándar (art. 8(4) DORA en relación con los arts. 4 y 5 RTS RMF); registrar para cada sistema la criticidad, la variante de infraestructura, las clases de datos y el propietario.

3. 3
   Fase 2 · Meses 3–6Adaptar el marco

   Estrategia de IA o sección de IA en la estrategia de resiliencia operativa digital; anclar la IA en el marco de gestión del riesgo relacionado con las TIC, las políticas de seguridad (art. 9(2) DORA), la política de incidentes (art. 22 RTS RMF) y los contratos con terceros (arts. 28 a 30 DORA).

4. 4
   Fase 3 · Meses 6–9Reforzar y probar

   Pruebas antes del paso a producción con un alcance acorde con la criticidad (art. 16(2) RTS RMF), complementadas con pruebas adversarias (adversarial testing) para la IA en funciones esenciales o importantes; umbrales de comportamiento anómalo de la IA en funciones esenciales o importantes (art. 10(1), párrafo segundo, en relación con el art. 10(2) DORA); Governance Shield para la variante 3; probar los planes de continuidad de la actividad (art. 11(6)(a) DORA, art. 25 RTS RMF).

5. 5
   Fase 4 · Meses 9–12Demostrar la eficacia

   Revisión anual del marco de gestión del riesgo relacionado con las TIC (art. 6(5) DORA) con una sección de IA en el informe del art. 27 RTS RMF; incorporar las lecciones aprendidas (art. 13(3) DORA); probar los planes de salida (art. 28(8) DORA); acreditar la formación (art. 5(4), art. 13(6) DORA).

Indicadores que entiende el consejo

La proporcionalidad también se aplica a la hoja de ruta: un asistente de autoservicio basado en IA que está totalmente bajo supervisión humana y no interviene en procesos de decisión no necesita la misma intensidad de control que la IA en una función esencial o importante (art. 4 DORA, cap. I.2). Quien empieza por el inventario puede escalonar esa intensidad de forma fundamentada y documentar la justificación.

La guía es una ayuda no obligatoria y no una interpretación vinculante de DORA por parte de la BaFin. Lo vinculante son DORA, el RTS RMF y el RTS de subcontratación. La hoja de ruta es una recomendación de VamiSec y no constituye asesoramiento jurídico.