Reglamento DORA: IA en el sector financiero

¿Qué es DORA y por qué afecta a la IA en el sector financiero?

El Reglamento de Resiliencia Operativa Digital (Digital Operational Resilience Act, DORA), formalmente el Reglamento (UE) 2022/2554, es directamente aplicable desde el 17 de enero de 2025 y crea por primera vez un marco uniforme en toda la UE para la resiliencia operativa digital del sector financiero. Según el art. 2 de DORA, el Reglamento se aplica a 20 categorías de entidades financieras, desde entidades de crédito y aseguradoras hasta empresas de servicios de inversión, entidades de pago y proveedores de servicios de criptoactivos. DORA agrupa cinco pilares que antes estaban dispersos entre distintos requisitos de supervisión: gestión del riesgo relacionado con las TIC (arts. 5-16), notificación de incidentes graves relacionados con las TIC (arts. 17-23), pruebas de resiliencia operativa digital, incluidas las pruebas de penetración basadas en amenazas (TLPT, arts. 24-27), gestión del riesgo de terceros proveedores de TIC con la supervisión de los proveedores esenciales (arts. 28-44) e intercambio de información (art. 45). El intercambio de información es voluntario. Para los sistemas de IA cuentan sobre todo los cuatro primeros pilares.

La palanca decisiva para la IA es la guía de orientación de la BaFin sobre los riesgos TIC en el uso de IA en entidades financieras, del 18 de diciembre de 2025, que encuadra expresamente los sistemas de IA como un subtipo de los «sistemas de red y de información» del art. 3, punto 2, de DORA. Con ello, el catálogo completo de obligaciones de DORA se aplica también a las cargas de trabajo de IA y de agentes de IA, desde la obtención de datos, el desarrollo del modelo y el despliegue hasta la operación continua con monitorización de la deriva y la retirada. Quien pone en producción un agente de IA en un banco o en una aseguradora está construyendo, por tanto, un sistema TIC regulado con todas las obligaciones de resiliencia, pruebas y gestión de terceros.

Los cuatro pilares obligatorios de DORA aplicados a los agentes de IA

Gestión del riesgo TIC (arts. 5-16). Los sistemas de IA deben integrarse en la gestión del riesgo TIC de toda la entidad. La guía de la BaFin formula el enfoque de ciclo de vida como expectativa supervisora: obtención de datos → desarrollo del modelo → despliegue → operación continua con monitorización de la deriva → retirada. Se esperan expresamente el entrenamiento adversarial y la monitorización de la deriva del modelo. La guía no es vinculante desde el punto de vista formal, pero en la práctica supervisora invierte de hecho la carga de la prueba: la entidad que no la sigue debe documentar en las inspecciones de la BaFin que sus medidas alternativas son equivalentes.

Pruebas de resiliencia (arts. 24-27). Los sistemas basados en IA están sujetos a la obligación de probar periódicamente la resiliencia operativa digital, hasta llegar a las pruebas de penetración basadas en amenazas (TLPT) en las entidades significativas. Con agentes estocásticos basados en LLM esto es exigente desde el punto de vista metodológico, porque los procedimientos de prueba clásicos están pensados para sistemas deterministas.

Notificación de incidentes (arts. 17-23). Los riesgos de IA específicos de cada proveedor, como citas regulatorias alucinadas, datos de carteras de clientes alucinados o la deriva del modelo en sistemas de scoring en producción, se consideran en el contexto BFSI riesgos operativos materiales. Sin embargo, solo deben notificarse si, como incidente relacionado con las TIC, cumplen los criterios del art. 18 de DORA y se consideran por tanto graves (art. 19 de DORA). La magnitud es considerable: en los tres primeros trimestres de 2025 se notificaron a la BaFin 525 incidentes graves relacionados con las TIC, alrededor del 70 % de ellos por entidades de crédito.

Riesgo de terceros proveedores de TIC (arts. 28-44). Para la IA, esta es la palanca más contundente y el tema de la siguiente sección.

Riesgo de terceros proveedores de TIC y la designación de CTPP

Hoy en día, la IA en el sector financiero funciona casi siempre sobre infraestructura externa: nubes de hiperescaladores, proveedores externos de modelos y LLM o centros de datos de los grupos bancarios. Ahí es exactamente donde actúa DORA: los arts. 28-30 regulan cómo gestionan las entidades financieras su riesgo de terceros proveedores de TIC, y los arts. 31-44, la supervisión directa de los proveedores esenciales. El 18 de noviembre de 2025, las Autoridades Europeas de Supervisión (AES) designaron por primera vez a 19 proveedores terceros esenciales de servicios TIC (Critical ICT Third-Party Providers, CTPP), entre ellos, según la lista de las AES, AWS, Microsoft, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix y Bloomberg. Para cada uno de estos proveedores, una de las tres autoridades asume el papel principal (supervisor principal o Lead Overseer: EBA, EIOPA o ESMA). Esta autoridad puede solicitar información, realizar investigaciones e inspecciones y formular recomendaciones (art. 35 de DORA). Estas recomendaciones no son vinculantes: el proveedor debe comunicar en un plazo de 60 días naturales si las va a seguir o justificar por qué no lo hará (art. 42, apdo. 1, de DORA). Si no responde en plazo o el supervisor principal considera insuficiente la justificación, este lo hace público (art. 42, apdo. 2, de DORA). Como último recurso, las autoridades competentes pueden obligar a las entidades financieras a suspender temporalmente el uso del servicio y, si es necesario, a rescindir el contrato (art. 42, apdo. 6, de DORA).

Para los bancos y las aseguradoras que actúan como responsables del despliegue, esto tiene consecuencias concretas:

• Los planes de salida para funciones esenciales o importantes deben probarse suficientemente y revisarse con regularidad, no solo documentarse (art. 28, apdo. 8, de DORA).
• Los riesgos de concentración deben evaluarse antes de celebrar el contrato (art. 29 de DORA, para funciones esenciales o importantes); por eso ganan peso las arquitecturas multicloud y preparadas para una salida.
• Las cargas de trabajo de agentes de IA en hiperescaladores siguen bajo una observación supervisora adicional.

El riesgo de concentración es especialmente visible en la región DACH (Alemania, Austria y Suiza): para sus cargas de trabajo de IA, casi todos los bancos dependen o bien de uno de los hiperescaladores designados o bien de soluciones de su grupo bancario. En Alemania, Finanz Informatik (FI), para las cajas de ahorros (Sparkassen), y Atruvia AG, para los Volksbanken y Raiffeisenbanken, operan deliberadamente stacks de IA on-premise y soberanos (entre otros, modelos de código abierto como Mixtral/Llama en centros de datos propios). El S-KIPilot de FI se desplegó en 2025, en su versión 6, en unos 60.000 puestos de trabajo de las Sparkassen. La lógica CTPP de DORA refuerza estructuralmente estos modelos de grupo mientras la designación y la guía de la BaFin mantengan su rigor actual.

Art. 30 de DORA: el catálogo de cláusulas contractuales como filtro de compras

El art. 30 de DORA establece contenidos contractuales obligatorios para los terceros proveedores de TIC y convierte así la selección de proveedores de IA en un filtro de cumplimiento estricto. Son obligatorios, entre otros, los derechos de auditoría, las cláusulas de salida, los controles de subcontratistas, las descripciones de servicio con objetivos de rendimiento cuantitativos y cualitativos y la indicación de los lugares donde se tratan los datos (art. 30, apdo. 2, letra b, y apdo. 3, letra a, de DORA). El art. 30, apdo. 3, exige derechos de auditoría, estrategias de salida y objetivos de rendimiento precisos para los servicios TIC que soportan funciones esenciales o importantes. En los hiperescaladores consolidados, estas cláusulas forman parte hoy del texto estándar; en las startups jóvenes de IA son un obstáculo frecuente en los procesos de compra.

Pero el art. 30 de DORA no está solo. En las licitaciones de IA de bancos y aseguradoras se suman otros criterios de evaluación:

El BSI Test Criteria Catalogue for AI Systems in Finance (versión provisional de junio de 2025, versión completa 2.0 de junio de 2026) incluye casi 100 criterios de evaluación en diez áreas temáticas, entre ellas seguridad y robustez, transparencia, equidad, calidad de los datos y gobernanza. La experiencia muestra que las acreditaciones conforme a BSI AIC4, ISO 42001, SOC 2 o ISO 27001 mejoran las posibilidades de los proveedores de IA en las licitaciones BFSI.

Obligaciones de DORA para agentes de IA en bancos y aseguradoras

Para los agentes de IA en el sector financiero hay que tener en cuenta seis áreas de riesgo específicas del sector que van más allá de DORA; en el cumplimiento horizontal de IA solo aparecen de forma marginal:

1. Gestión del riesgo de modelos. Desde las revisiones de 2023/2024, MaRisk AT 4.3.5 se aplica expresamente también a los modelos de IA/ML y exige documentación del ciclo de vida, validación independiente, backtesting y revisión periódica. La guía de la BaFin espera, además, documentación del entrenamiento adversarial y monitorización de la deriva del modelo.
2. Explicabilidad en las decisiones de crédito. Según el art. 22 del RGPD, las decisiones de crédito con efectos jurídicos solo pueden basarse exclusivamente en un tratamiento automatizado en casos excepcionales; en ese caso, los interesados tienen derecho a la intervención de una persona, a expresar su punto de vista y a impugnar la decisión (art. 22, apdo. 3, del RGPD). A ello se suma la clasificación del scoring crediticio como IA de alto riesgo según el anexo III, punto 5, letra b, del Reglamento de IA, cuyas obligaciones se aplican, según el Ómnibus Digital, a partir del 2 de diciembre de 2027. En Alemania, los § 505a y § 505b BGB exigen además una evaluación de la solvencia antes de conceder préstamos al consumo. En conjunto, el RGPD y el Reglamento de IA llevan a que una persona responsable tenga que poder nombrar los factores determinantes. El scoring crediticio end-to-end con LLM queda así prácticamente descartado; la IA se mantiene en funciones de triaje y explicación.
3. Pista de auditoría completa. Para las inspecciones especiales de supervisión (inspección especial de la BaFin, control in situ de la FINMA, inspección del OeNB), cada inferencia debe quedar registrada de forma inalterable y auditable, incluidos el prompt, el contexto, las fuentes recuperadas, la versión del modelo y el output.
4. Requisitos de latencia. El compliance en trading exige <10 ms; la detección de fraude, <1 s. Los agentes LLM en el hot path rara vez son viables.
5. Residencia de datos. En Alemania y Austria, los supervisores insisten cada vez más en la residencia en la UE o nacional de los datos de entrenamiento e inferencia de IA; en Suiza, el secreto bancario (art. 47 BankG) obliga en la práctica a almacenar en Suiza los datos de clientes.
6. Riesgo de concentración derivado de la designación de CTPP (véase más arriba).

Como consecuencia, en 2026 las decisiones de crédito totalmente autónomas y los flujos de trabajo de trading multiagente totalmente autónomos no están en producción. Lo habitual, en cambio, son los agentes de atención al cliente de nivel 1, la detección de fraude, el triaje AML/KYC y el reporting regulatorio, siempre con human-in-the-loop cuando las decisiones tienen efectos jurídicos.

Contexto DACH: tres vías en lugar de una sola línea

DORA se aplica directamente en Alemania y Austria como parte del acervo de la UE; Suiza adopta estas normas de forma autónoma y sector por sector. El resultado es un cumplimiento en tres vías que deben tener en cuenta las entidades que operan en toda la región DACH:

Una encuesta de la FINMA de abril de 2025 realizada entre unas 400 entidades muestra el nivel de adopción: alrededor del 50 % de los bancos y aseguradoras suizos ya utiliza IA o desarrolla aplicaciones, y otro 25 % prevé implantarla en un plazo de tres años; de media hay unas 5 aplicaciones en producción y unas 9 en desarrollo. El 91 % de las entidades que usan IA emplea IA generativa. La comunicación de supervisión de la FINMA precedió exactamente en doce meses a la guía de la BaFin, pero no coincide plenamente con ella: la FINMA exige, por ejemplo, inventarios centrales de IA con clasificación de riesgos y soluciones de respaldo.

La laguna regulatoria austriaca es ambivalente: da margen de maniobra, pero aumenta la incertidumbre en los controles in situ, porque las expectativas no están codificadas de antemano. En 2024 se creó en RTR-GmbH un servicio central de IA, orientado al asesoramiento y no a la supervisión sectorial.

Perspectivas y recomendación práctica

Las reglas del juego regulatorias se están moviendo: habrá que seguir de cerca nuevas versiones de la guía de la BaFin y su interpretación en las inspecciones especiales, posibles concreciones de la FINMA más allá de la comunicación 08/2024 y la guía formal sobre IA que se espera de la FMA austriaca. También está por ver si las primeras recomendaciones de los supervisores principales a los CTPP llevarán de verdad a las entidades de la región DACH a un multicloud efectivo o si todo quedará en planes de salida simbólicos.

En la práctica: si en 2026 pones IA en producción en el sector financiero, deberías tratar la guía de la BaFin como norma interna (también allí donde la FMA aún no tiene una guía propia), operativizar el canal de notificación de incidentes de DORA y las TLPT, usar el BSI Test Criteria Catalogue Finance como filtro de proveedores y concebir la IA desde el principio como un sistema TIC con gestión completa del ciclo de vida. Según la experiencia, el cumplimiento normativo supone en los sectores regulados de la región DACH un 30-50 % del esfuerzo de implementación, lo que es a la vez un riesgo y una ventaja competitiva.

Con fines informativos, no constituye asesoramiento jurídico. Fecha de las fuentes utilizadas: mayo de 2026, con algunos datos actualizados en octubre de 2026; los plazos provisionales y las guías anunciadas deben considerarse sujetos a cambios.