Guía de la BaFin sobre IA: lo que bancos y aseguradoras deberían implantar ya en materia de riesgos TIC bajo DORA
6 de octubre de 2026
Qué ha publicado la BaFin
El 18 de diciembre de 2025, la BaFin publicó la «Orientierungshilfe zu IKT-Risiken beim Einsatz von KI in Finanzunternehmen» (guía sobre los riesgos TIC en el uso de la IA en entidades financieras): 38 páginas, editadas por la unidad CTF 5 del departamento de Riesgos Cibernéticos y Tecnología en el Sector Financiero. La versión inglesa, «Guidance on ICT Risks in the Use of AI at Financial Entities» (fecha de versión 23/01/2026), llegó el 30 de enero de 2026. La guía se presenta expresamente como una ayuda no obligatoria: no define expectativas supervisoras ni constituye una interpretación vinculante de DORA. Se dirige sobre todo a las entidades CRR y a las aseguradoras sujetas a Solvencia II que aplican la gestión del riesgo TIC de los arts. 5 a 15 DORA; el marco simplificado del art. 16 DORA queda fuera de su objeto. Se estructura en seis capítulos y un caso práctico sobre la operación de un asistente de IA basado en LLM.
Por qué importa precisamente ahora
DORA es aplicable desde el 17 de enero de 2025; desde entonces, las KAIT, VAIT y ZAIT están derogadas, y las BAIT ya no se aplican a las entidades sujetas a DORA: quedarán derogadas por completo al término del 31 de diciembre de 2026. El marco de referencia para las TI de estas entidades es, por tanto, DORA, también en lo que respecta a la IA. Paralelamente, desde el 29 de julio de 2026 la BaFin es, en virtud de la KI-MIG —la ley alemana que designa a las autoridades competentes con arreglo al Reglamento de IA—, autoridad de vigilancia del mercado para los sistemas de IA directamente vinculados a actividades financieras reguladas (§ 2(3) KI-MIG); las obligaciones de alto riesgo del anexo III del Reglamento de IA —por ejemplo, para la evaluación de la solvencia de personas físicas— se aplican a partir del 2 de diciembre de 2027, tras el aplazamiento introducido por el Reglamento (UE) 2026/1744. Ahora bien, la guía no trata las obligaciones del Reglamento de IA, sino exclusivamente los riesgos TIC bajo DORA: muestra cómo pueden aplicarse los requisitos vigentes de DORA a los sistemas de IA que, según la BaFin, las entidades financieras ya utilizan hoy a lo largo de toda la cadena de valor.
Lo esencial: un sistema de IA es TIC, a lo largo de todo su ciclo de vida
La BaFin adopta la definición de sistema de IA del art. 3(1) del Reglamento de IA y clasifica los sistemas de IA como un subtipo de las redes y sistemas de información del art. 3(2) DORA; el propio modelo se considera un activo de TIC. De ello se deduce que los sistemas de IA forman parte del marco de gestión del riesgo TIC existente (art. 6 DORA), del inventario de activos (art. 8(4) DORA) y, cuando los facilitan terceros, de la gestión del riesgo TIC derivado de terceros (art. 28 DORA). Los riesgos no se analizan a lo largo de la cadena de valor, sino del ciclo de vida de la IA, porque surgen de su integración en el entorno TIC. El principio rector es la proporcionalidad del art. 4 DORA: la IA en funciones esenciales o importantes requiere más medidas de seguridad y control que un asistente de autoservicio bajo plena supervisión humana y sin intervención en las decisiones. Una indicación práctica del capítulo III: si una aplicación integra modelos de IA externos a través de una API, puede convertirse ella misma en un sistema de IA.
Gobernanza, marco de gestión del riesgo, desarrollo y pruebas
La responsabilidad última de los riesgos TIC recae en el órgano de dirección (art. 5(2)(a) DORA); sus miembros mantienen activamente actualizados unos conocimientos y capacidades suficientes (art. 5(4) DORA), y el personal recibe una formación acorde con sus funciones (art. 13(6) DORA). Como práctica extendida, la BaFin describe una estrategia de IA aprobada por el órgano de dirección. Las vulnerabilidades específicas de la IA en el entrenamiento, los pipelines de datos y la inferencia forman parte de la identificación de riesgos (art. 8 DORA), y el marco debe revisarse al menos una vez al año (art. 6(5) DORA). Para el desarrollo y las pruebas, la guía se apoya casi por completo en el RTS RMF: gestión de proyectos, especificaciones protegidas frente a la manipulación, gestión de cambios y pruebas antes de la puesta en producción cuyo alcance se corresponda con la criticidad (arts. 15 a 17 RTS RMF). Al end-user computing (EUC) se le aplican igualmente los requisitos, con un enfoque basado en el riesgo (art. 16(9) RTS RMF), y, según la BaFin, el código generado por IA sigue las mismas reglas que el escrito por personas. En función de la criticidad, la BaFin menciona el adversarial testing, las pruebas de penetración adversarias y las pruebas de estrés como práctica conveniente, y señala los cambios no anunciados en los modelos obtenidos de terceros como un reto particular para las pruebas.
Operación, nube y terceros
En la operación, DORA exige una política y procedimientos para la gestión de los activos de TIC (art. 8(4) DORA, en relación con los arts. 4 y 5 RTS RMF); la guía incluye expresamente los datos de entrenamiento, las implementaciones de modelos, las bibliotecas y el hardware. El art. 10 RTS RMF obliga a realizar escaneos automatizados de vulnerabilidades y a fijar plazos de aplicación de parches; para las funciones esenciales o importantes, la BaFin recomienda umbrales e indicadores de comportamiento anómalo. Como los sistemas de IA se operan a menudo en la nube, el capítulo IV.2 traslada a la IA aspectos de la comunicación supervisora sobre la externalización a proveedores de servicios en la nube del 1 de febrero de 2024: evaluación del riesgo y diligencia debida antes de celebrar el contrato (art. 28(4) DORA) —incluidos los cambios en el modelo realizados por el proveedor—, transparencia sobre subcontratistas como granjas de GPU o bibliotecas de ML (arts. 29 y 30 DORA), SLA de latencia y capacidad de cómputo, y una estrategia de salida con modelos, datos de entrenamiento y configuraciones exportables. Para la retirada, la BaFin considera conveniente establecer requisitos para eliminar los modelos de forma irrecuperable y desactivar las versiones obsoletas.
Ciberseguridad, seguridad de los datos y notificación de incidentes
Los sistemas de IA deben integrarse en las políticas de seguridad de las TIC (art. 9(2) DORA). Son obligatorias, entre otras cosas, una arquitectura de red segmentada según la criticidad (art. 13 RTS RMF), así como el cifrado y la gestión de claves sobre la base de la clasificación de los datos (arts. 6 y 7 RTS RMF). Como práctica consolidada, la BaFin cita además los cortafuegos de aplicaciones web (WAF) y las pasarelas de API, la confianza cero (zero trust) en el acceso a los servicios de IA, la prevención de pérdida de datos (DLP), la firma de modelos y la protección frente a ataques de inyección y de sobrecarga. Según la BaFin, la base más importante para un tratamiento seguro de los datos es su clasificación por confidencialidad, integridad y disponibilidad. Los incidentes en sistemas de IA deben registrarse como incidentes relacionados con las TIC y sus causas deben determinarse (art. 17 DORA); los incidentes graves deben notificarse (art. 19 DORA). La BaFin recomienda, además, marcar los incidentes relacionados con la IA y, tras ellos, realizar un análisis detallado de causas raíz para corregir vulnerabilidades sistemáticas en los modelos y procesos de IA. El análisis de la BaFin sobre las notificaciones DORA muestra lo relevantes que son los terceros en general: alrededor de la mitad de los 733 incidentes TIC notificados en 2025 se debió a problemas en terceros; no hay cifras específicas de IA.
El caso práctico: un asistente de IA, tres variantes de infraestructura
El caso práctico analiza un asistente de IA basado en LLM para textos, correos electrónicos y presentaciones, en seis fases, desde la obtención de datos hasta la retirada, y en tres variantes: on-premise, con control total pero con todos los riesgos de desarrollo, operación y mantenimiento; nube dentro del propio tenant, cuyo riesgo principal es la dependencia del operador del modelo, salvo que se utilice un modelo de código abierto; y nube fuera del tenant, por ejemplo un LLM a través de API o un asistente de IA integrado en software estándar. En la tercera variante, los datos salen del tenant y fluyen hacia el proveedor del modelo; según el caso práctico, esto debe contrarrestarse con medidas contractuales y técnicas, por ejemplo restricciones a la carga de archivos, un Governance Shield que analiza las entradas en busca de contenido confidencial o un nivel de autorización de datos inferior. Importante: las medidas del caso práctico son expresamente ilustrativas y no constituyen expectativas supervisoras. Nuestra recomendación: inventariar primero las funciones de IA del software estándar, como Microsoft 365 Copilot, porque, según el caso práctico, estos asistentes se invocan a veces sin que los usuarios lo sepan; la propia guía no menciona productos.
Lo que hemos publicado al respecto
Nuestra nueva página de conocimiento hace operativas esas 38 páginas y distingue en todo momento entre obligación de DORA y los RTS, práctica según la guía y recomendación de VamiSec. La comprobación de alcance muestra qué intensidad de control es adecuada para su sistema de IA. El navegador del ciclo de vida recorre seis fases y dos temas transversales con riesgos, anclajes normativos, preguntas de auditoría y evidencias. El laboratorio de variantes representa las tres variantes de infraestructura como flujos de datos y muestra con un semáforo cómo valoramos cada variante según la clase de datos. El navegador de referencias recoge las 97 referencias normativas según nuestro recuento. La autoevaluación de resiliencia de la IA determina, con hasta 31 preguntas en siete ámbitos de actuación, su nivel objetivo según su perfil, y muestra sus mayores brechas y una hoja de ruta de 30/90/180 días. Además, está disponible el whitepaper de 50 páginas «KI unter DORA für CISOs» («La IA bajo DORA, para CISO»; en alemán), con 30 preguntas de auditoría, matriz de evidencias y hoja de ruta de 12 meses.
Todos los enlaces
Página de conocimiento sobre la guía de la BaFin: https://vamisec.com/es/wissen/grc/bafin-orientierungshilfe-ki-ikt-risiken · Autoevaluación de resiliencia de la IA: https://vamisec.com/es/wissen/grc/bafin-orientierungshilfe-ki-ikt-risiken#ki-check · Solicitar el whitepaper «KI unter DORA für CISOs»: https://vamisec.com/es/wissen/grc/bafin-orientierungshilfe-ki-ikt-risiken#whitepaper · Página de conocimiento sobre DORA: https://vamisec.com/es/wissen/grc/dora · Nota informativa de la BaFin del 18 de diciembre de 2025: https://www.bafin.de/SharedDocs/Veroeffentlichungen/DE/Meldung/2025/meldung_2025_12_18_orientierungshilfe_ikt_risiken.html · Guía (original en alemán): https://www.bafin.de/SharedDocs/Downloads/DE/Anlage/dl_Anlage_orientierungshilfe_IKT_Risiken_bei_KI.html
¿Tiene preguntas sobre la seguridad TI de su empresa?
Consulta inicial gratuita →