Riesgo de terceros TIC según DORA: cuándo un proveedor de IA es un proveedor TIC crítico

El riesgo de terceros TIC según DORA designa la obligación de las entidades financieras de gestionar activamente los riesgos derivados de servicios TIC externalizados. Con arreglo al Reglamento (UE) 2022/2554 (DORA, aplicable desde el 17 de enero de 2025), los proveedores de IA y de LLM pueden considerarse proveedores terceros de servicios TIC. En ese caso, la entidad financiera que los utiliza debe gestionarlos conforme a los artículos 28 a 30: registro de información, requisitos contractuales, gestión del riesgo de concentración. Si las Autoridades Europeas de Supervisión (AES: EBA, EIOPA y ESMA) califican a un proveedor como crítico, este queda sometido él mismo al marco de vigilancia de los arts. 31 y siguientes.

• ¿A quién afecta? DORA se dirige a las entidades financieras (entre otras, entidades CRR y aseguradoras sujetas a Solvencia II), no directamente a los proveedores de IA. El servicio de IA queda incluido a través de la entidad financiera.
• ¿Por qué la IA? La guía de la BaFin del 18 de diciembre de 2025 clasifica los sistemas de IA como un subtipo de los «sistemas de red y de información» según el art. 3, punto 2, de DORA y lleva así todo el catálogo de obligaciones de DORA a la gobernanza de la IA.
• Primero, la obligación central: todo servicio TIC contratado, también un servicio de LLM en uso productivo, debe figurar en el registro de información que se pone a disposición de las autoridades de supervisión.

Por qué los proveedores de IA/LLM se convierten en proveedores de servicios TIC

DORA no regula la IA como tecnología, sino la resiliencia operativa digital de las entidades financieras. La palanca decisiva es la amplia definición de servicios TIC y de sistemas de red y de información. En cuanto una entidad financiera utiliza en producción un servicio de IA, por ejemplo un modelo de lenguaje alojado, una API de scoring de fraude o un asistente documental en la nube, ese servicio forma parte de su riesgo de terceros TIC.

La guía de la BaFin sobre riesgos TIC en el uso de IA en entidades financieras del 18 de diciembre de 2025 hace explícita esta relación en la práctica supervisora alemana: los sistemas de IA son un subtipo de los «sistemas de red y de información» según el art. 3, punto 2, de DORA. Así, a las cargas de trabajo basadas en IA se les aplican las obligaciones de DORA sobre gestión del riesgo relacionado con las TIC (arts. 5–15), pruebas de resiliencia, incluidas las pruebas de penetración basadas en amenazas (arts. 24–27), y riesgo de terceros TIC (arts. 28–30). Según la propia guía, se trata de una ayuda no vinculante que no define expectativas supervisoras. Pretende ayudar a las entidades financieras a aplicar los requisitos de DORA cuando usan IA. Sus destinatarios son principalmente las entidades CRR y las aseguradoras sujetas a Solvencia II.

Consecuencia práctica: un proveedor de IA no queda sujeto a DORA «automáticamente». El servicio queda incluido a través de la entidad financiera que lo utiliza, y esta debe gestionar a su proveedor, vincularlo contractualmente y documentar la relación de forma que los requisitos de DORA puedan cumplirse.

El registro de información (Register of Information)

El instrumento central de gestión del riesgo de terceros TIC es el registro de información. Las entidades financieras deben llevar un inventario completo de todos los acuerdos contractuales sobre servicios TIC y ponerlo a disposición de las autoridades de supervisión competentes. Este registro recoge qué función respalda un servicio, si da soporte a una función crítica o importante, quién es el proveedor y qué subcontratistas intervienen.

Para la IA, esto significa que un servicio de LLM o de ML en uso productivo no es una «herramienta con cargo al presupuesto de marketing», sino un servicio TIC sujeto a registro en cuanto equivale a una externalización contractual. El registro es además la base de datos con la que las AES detectan qué proveedores están tan extendidos en el sector que deben calificarse como críticos.

Proveedores terceros críticos de servicios TIC (CTPP) y el marco de vigilancia

DORA establece un marco de vigilancia propio (Oversight Framework) para los proveedores terceros críticos de servicios TIC (Critical ICT Third-Party Providers, CTPP). Se recoge en los arts. 31 y siguientes y está, por tanto, separado del catálogo de obligaciones de las entidades financieras de los arts. 28 a 30. El 18 de noviembre de 2025, las AES designaron por primera vez a 19 CTPP, entre ellos AWS, Microsoft Azure, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix y Bloomberg (lista de las AES).

Tras la designación, estos proveedores quedan sometidos a supervisión directa a escala de la UE. Para cada CTPP, una de las tres AES (EBA, EIOPA o ESMA) actúa como supervisor principal o Lead Overseer (art. 31, apartado 1, letra b). Cuenta con el apoyo de un equipo de examen conjunto (Joint Examination Team, art. 40) y puede emitir recomendaciones (art. 35). Estas recomendaciones no son jurídicamente vinculantes. Pero el proveedor debe comunicar en un plazo de 60 días naturales si las sigue o justificar por qué no lo hace. Si no responde o la justificación es insuficiente, el supervisor principal lo hace público. Como último recurso, las autoridades nacionales de supervisión pueden obligar a las entidades financieras a suspender el uso del servicio (art. 42).

Importante para el debate sobre la IA: la mayoría de las cargas de trabajo productivas de IA/LLM se ejecutan hoy en hiperescaladores designados como AWS, Microsoft Azure o Google Cloud. Aunque una startup de IA no esté (todavía) designada como CTPP, técnicamente suele apoyarse en un proveedor designado. La supervisión del hiperescalador subyacente no cambia en nada la responsabilidad propia de la entidad financiera en materia de externalización, capacidad de salida y riesgo de concentración.

Cuándo se considera crítico a un proveedor

Las AES designan según cuatro criterios del art. 31, apartado 2, de DORA: el impacto sistémico de una interrupción a gran escala sobre los servicios financieros, la importancia sistémica de las entidades financieras dependientes (por ejemplo, entidades de importancia sistémica mundial y otras entidades de importancia sistémica, EISM y OEIS), la dependencia de funciones críticas o importantes respecto al proveedor y la sustituibilidad. El Reglamento Delegado (UE) 2024/1502 convierte esto en un procedimiento en dos fases. En la fase 1, un proveedor debe alcanzar todos los umbrales cuantitativos. Uno de ellos: da soporte a funciones críticas o importantes de al menos el 10 % de las entidades financieras de una categoría, y estas poseen en conjunto al menos el 10 % de los activos de esa categoría. Solo quien alcanza todos los umbrales pasa a la evaluación cualitativa de la fase 2. La base de datos son los registros de información de las entidades financieras.

En la primera lista no figura ningún proveedor cuyo negocio principal sean los modelos de IA, como OpenAI, Anthropic o Mistral. Nuestra valoración: los proveedores puros de IA y LLM rara vez alcanzan hoy los umbrales, porque sus servicios todavía dan soporte a pocas funciones críticas o importantes en bancos y aseguradoras y a menudo se contratan a través de las plataformas de los hiperescaladores. Un proveedor que no figura en la lista puede solicitar por iniciativa propia, conforme al art. 31, apartado 11, ser designado como crítico. No se designan los proveedores de servicios TIC intragrupo ni los proveedores que solo operan en un Estado miembro para entidades financieras que actúan exclusivamente en él (art. 31, apartado 8).

Riesgo de concentración y estrategia de salida

El riesgo de concentración es especialmente marcado en el contexto de la IA. Si casi todos los bancos de la UE dependen, para sus cargas de trabajo de IA, de uno de los pocos hiperescaladores designados o de soluciones centralizadas de su red de entidades, se genera una concentración sistémica. Por eso DORA exige que las entidades financieras gestionen activamente su dependencia. Antes de celebrar un contrato de servicios TIC para funciones críticas o importantes, comprueban si el proveedor es difícil de sustituir o si se acumulan contratos con el mismo proveedor (art. 29). Para esos servicios necesitan estrategias de salida. Los planes de salida deben ser exhaustivos y estar documentados, y someterse a pruebas suficientes y revisarse periódicamente (art. 28, apartado 8). DORA no fija para ello una periodicidad concreta, a diferencia de los planes de continuidad de negocio en materia de TIC, que deben probarse al menos una vez al año (art. 11, apartado 6).

En la práctica, una arquitectura de IA multicloud sistemática sigue siendo en 2026 exigente desde el punto de vista técnico y comercial. Por eso, entre un plan de salida sobre el papel y un cambio de proveedor realmente viable suele haber una brecha.

Requisitos de externalización y contractuales (art. 30)

El art. 30 de DORA define un catálogo obligatorio de cláusulas contractuales para servicios TIC. Con ello, para estos servicios, los arts. 28–30 de DORA prevalecen sobre las Directrices de la EBA sobre externalización (EBA/GL/2019/02) y las directrices correspondientes de la ESMA. Elementos clave de las cláusulas:

• Descripción del servicio con las condiciones para recurrir a subcontratistas (subencargados) (apartado 2, letra a)
• Lugares de prestación del servicio y de tratamiento de datos, incluida la ubicación del almacenamiento, e información previa en caso de cambios previstos (apartado 2, letra b)
• Descripciones de los niveles de servicio (apartado 2, letra e), con objetivos de rendimiento cuantitativos y cualitativos precisos en el caso de funciones críticas o importantes (apartado 3, letra a)
• Derechos de rescisión (apartado 2, letra h) y, en el caso de funciones críticas o importantes, además estrategias de salida con un periodo de transición obligatorio (apartado 3, letra f)
• En el caso de funciones críticas o importantes, derechos ilimitados de acceso, inspección y auditoría para las entidades financieras y la autoridad de supervisión (apartado 3, letra e)

DORA no exige expresamente compromisos de latencia o de capacidad de cálculo. Si los necesitas se desprende de los objetivos de rendimiento de cada función.

En nuestra opinión, con los hiperescaladores estas cláusulas son en gran medida texto estándar, mientras que con las startups de IA son un obstáculo frecuente en el proceso de compras. Para los proveedores de IA sin derechos de auditoría sólidos, sin transparencia sobre subencargados y sin lugares de tratamiento documentados, el proceso de selección en las entidades financieras de la UE suele terminar antes de la ronda final.

Resumen: obligación, a quién afecta, base jurídica

Caso práctico: asistente basado en LLM en un banco regional

Un banco mediano implanta un asistente interno de conocimiento basado en LLM que funciona mediante la API de un proveedor de IA, que a su vez aloja su servicio en Microsoft Azure. Pasos relevantes para DORA:

1. Clasificar: ¿da soporte el asistente a una función crítica o importante? Si es así, los requisitos se endurecen.
2. Registrar: el contrato y el servicio se inscriben en el registro de información, incluido el subcontratista Azure (CTPP designado).
3. Blindar el contrato (art. 30): derechos de auditoría, estrategia de salida con periodo de transición, condiciones para subcontratistas, lugares definidos de prestación del servicio y de tratamiento de datos (aquí el banco elige la UE) y SLA con objetivos de rendimiento cuantitativos.
4. Evaluar el riesgo de concentración: ¿depende una función crítica de un único hiperescalador? Documentar el plan de salida y probarlo periódicamente.
5. Proceso de incidentes: los incidentes graves relacionados con las TIC que afecten al servicio, por ejemplo citas regulatorias alucinadas que constituyan un evento material de riesgo operacional, deben notificarse según DORA.

Pseudocódigo de la lógica de gobernanza:

```
si servicio_IA.es_externalizacion_contractual:
Registro.inscribir(servicio_IA, subencargados=[Hiperescalador])
si servicio_IA.soporta_funcion_critica:
Contrato.revisar(clausulas_Art30) # auditoría, salida, SLA, subencargados
PlanSalida.probar(intervalo="periódico")
RiesgoConcentracion.evaluar(proveedor, funcion)
Incidente.activar_via_notificacion(gravedad="grave")
```

Las referencias a artículos remiten al texto del Reglamento DORA; el estado de CTPP, a la lista de las AES del 18 de noviembre de 2025. Este artículo no constituye asesoramiento jurídico; si DORA es aplicable a un servicio de IA concreto, y de qué manera, requiere un análisis caso por caso a cargo de asesores jurídicos y regulatorios especializados.

Para agencias y responsables de decisión B2B

Para las agencias de marketing y los proveedores que suministran funciones de IA a bancos, aseguradoras u otras entidades financieras, DORA es un criterio de venta decisivo, no un detalle accesorio. Si quieres vender soluciones basadas en LLM al sector financiero regulado, contempla desde el principio la capacidad de auditoría, la transparencia sobre subencargados, la residencia de datos en la UE y una vía de salida sólida; de lo contrario, el proyecto no fracasará por la calidad del modelo, sino en el proceso de compras. Blck Alpaca te ayuda a diseñar flujos de trabajo de IA conformes con DORA y a integrarlos en los procesos de externalización y de gestión de proveedores, para que tu iniciativa de IA en el sector financiero pueda llegar a la ronda final de selección. El análisis jurídico caso por caso lo obtienes, de forma complementaria, de asesores especializados.