El EBA convierte el AI Act en un problema operativo para banca y pagos: no choca con DORA, pero tampoco te ahorra trabajo

Lo interesante del último trabajo de la Autoridad Bancaria Europea sobre la intersección entre IA y finanzas no es una gran revelación. Es algo bastante más útil: confirma que el sector va a tener que dejar de gestionar la normativa como si cada texto legal viviera en su propio planeta. Y eso, para cualquier entidad que esté intentando cuadrar AI Act, DORA, GDPR, NIS2 y requisitos sectoriales prudenciales sin montar cinco programas paralelos, cambia la conversación.

La cuestión de fondo no es si habrá solapamientos. Los hay. La cuestión es cuáles se pueden aprovechar de verdad sin caer en la ficción del “cumplimos una vez y vale para todo”. Ahí suele empezar el autoengaño regulatorio y, poco después, la auditoría incómoda.

El documento del EBA se mueve precisamente en ese terreno: identificar puntos de contacto entre obligaciones regulatorias aplicables al uso de sistemas de IA en entidades financieras y explorar dónde puede haber coherencia operativa. No conviene exagerarlo. No estamos ante una autorización para consolidar controles sin más ni ante una bendición para fusionar marcos de cumplimiento que tienen finalidades jurídicas distintas. Pero tampoco es otro papel ornamental. Leído con calma, sirve para algo muy concreto: obliga a distinguir entre convergencia útil, compatibilidad parcial y requisitos que seguirán necesitando trazabilidad separada.

La pregunta correcta no es si AI Act y DORA se parecen, sino dónde dejan de parecerse

Durante meses, buena parte del mercado ha discutido la relación entre normas digitales europeas con un reflejo casi automático: buscar duplicidades para ahorrar trabajo. Es comprensible. Cuando una entidad tiene que revisar gestión de riesgos TIC bajo DORA, notificación de incidentes, gobernanza de terceros, controles de seguridad, protección de datos, validación de modelos, documentación técnica y supervisión humana, la promesa de “sinergias” suena a música celestial.

El problema es que las sinergias regulatorias existen, pero no hacen magia. DORA tiene una lógica de resiliencia operativa financiera. Ahí mandan, entre otros, los requisitos de gestión del riesgo de las TIC del capítulo II, la gobernanza y control de terceros del capítulo V y las pruebas de resiliencia operativa digital del capítulo IV. El AI Act, por su parte, impone obligaciones diseñadas alrededor del riesgo del sistema de IA, con requisitos específicos para sistemas de alto riesgo como gestión de riesgos, gobernanza de datos, documentación técnica, registro, transparencia, supervisión humana, exactitud, robustez y ciberseguridad. GDPR protege datos personales. NIS2 se centra en medidas de ciberseguridad y gobernanza para entidades esenciales e importantes, con obligaciones del artículo 21. Parecen primos. No son gemelos.

Aquí está el quid: una misma medida interna puede ayudar a varias normas a la vez, pero eso no significa que satisfaga íntegramente la finalidad jurídica de todas ellas. Un control de monitorización continua puede servir para DORA, ayudar bajo NIS2 y aportar evidencia útil para determinadas obligaciones del AI Act. Aun así, la base legal, el umbral de exigencia, la documentación esperada y el tipo de supervisión pueden ser distintos. Si tu programa de cumplimiento se queda en la palabra “alineado”, estás construyendo sobre una media verdad.

Lo que sí aporta el ejercicio del EBA

Conviene ser precisos. El valor del trabajo del EBA no está en ofrecer una fórmula cerrada ni una taxonomía definitiva que permita clasificar cada obligación en un Excel y dar el asunto por resuelto. Su utilidad real está en otro sitio: reconoce que existen relaciones materiales entre distintos marcos normativos y que, para las entidades financieras, esas relaciones pueden traducirse en diseño de controles, documentación y gobernanza más coherentes.

Dicho de forma menos diplomática: el regulador sabe que si cada obligación se implementa en un silo, las entidades acabarán creando una burocracia redundante que consume presupuesto sin mejorar necesariamente el riesgo. Y, como siempre en regulación financiera, cuando el coste sube demasiado, las organizaciones responden con dos estrategias igual de tentadoras y peligrosas: o trocean artificialmente los programas para satisfacer a cada función interna, o intentan unificarlo todo de manera excesiva y terminan perdiendo trazabilidad jurídica. Ninguna de las dos sale gratis.

El trabajo del EBA, leído en clave operativa, empuja hacia un punto intermedio más sensato: construir una arquitectura de cumplimiento donde haya controles comunes cuando la sustancia lo permita, pero manteniendo mapeo normativo específico cuando la obligación exija una justificación propia. No es un hallazgo filosófico. Es gestión seria.

Por qué este debate importa más en banca que en otros sectores

En banca y servicios financieros, la presión no viene de una sola norma nueva, sino de la colisión entre varias. Una entidad puede tener, al mismo tiempo, obligaciones por DORA como entidad financiera, posibles deberes bajo NIS2 en función de su encaje nacional, obligaciones plenas de GDPR si trata datos personales, exigencias de outsourcing y riesgo de terceros en el marco prudencial, y responsabilidades bajo el AI Act si desarrolla o despliega sistemas de IA de alto riesgo. Todo eso se suma, no se sustituye.

Además, la banca tiene un problema añadido: casi ninguna capacidad crítica se sostiene ya solo con infraestructura propia. El modelo operativo actual depende de proveedores cloud, software especializado, herramientas de ciberseguridad, modelos analíticos, motores antifraude, soluciones de onboarding digital y capas crecientes de automatización. Cuando la IA entra en la cadena, no entra limpia. Entra mezclada con TIC, terceros, datos personales, validación de modelos, gobierno de producto y controles de continuidad.

Por eso el diálogo entre normas no es un lujo doctrinal. Es una necesidad de diseño. Si un banco compra un sistema de IA para scoring, detección de fraude, monitorización AML o atención automatizada al cliente, no basta con preguntar si el proveedor firma un buen contrato. Hay que saber cómo se conectan, en la práctica, las exigencias sobre documentación, evaluación de riesgos, seguridad, supervisión humana, registro de eventos, gestión de incidencias, derechos de los interesados si hay datos personales, y dependencia tecnológica respecto del tercero. Ese cruce no cabe en una due diligence de dos páginas ni en la presentación optimista del proveedor.

El error más común: confundir sinergia con equivalencia

Muchas organizaciones están cayendo en una trampa bastante previsible. Como identifican elementos parecidos entre marcos normativos, concluyen que un mismo paquete documental servirá íntegramente para todos. Es la versión regulatoria del “copiar y pegar”, solo que más cara.

Tomemos un ejemplo obvio. DORA exige un marco interno sólido de gestión del riesgo de las TIC, con estrategias, políticas, procedimientos, protocolos y herramientas que permitan proteger, detectar, responder y recuperarse de incidentes relacionados con TIC. Eso está en el capítulo II y se articula, entre otros, en torno a la gobernanza del órgano de dirección y a medidas concretas de protección, prevención, detección, respuesta y recuperación. NIS2, en su artículo 21, también exige medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar riesgos de ciberseguridad. AI Act, para sistemas de alto riesgo, introduce requisitos sobre gestión de riesgos, robustez y ciberseguridad. Hasta aquí, uno ve convergencia.

Ahora bien, la similitud superficial no borra las diferencias. DORA mira la resiliencia operativa de la entidad financiera y la continuidad de servicios. NIS2 persigue un nivel elevado común de ciberseguridad en sectores cubiertos. AI Act no regula “ciberseguridad” en abstracto, sino como atributo del sistema de IA en relación con su seguridad y fiabilidad, dentro de un marco más amplio de riesgos sobre salud, seguridad y derechos fundamentales. Un control de hardening, registro, monitorización o gestión de vulnerabilidades puede alimentar evidencia para varios frentes, sí. Pero la explicación jurídica de por qué existe ese control y qué prueba debe generar no es la misma.

Ese matiz parece menor hasta que llega una inspección, una auditoría interna seria o una revisión legal de documentación. Entonces se descubre que el mismo control se estaba usando para sostener tres obligaciones distintas sin demostrar cómo satisface cada una. Y ahí desaparece la supuesta eficiencia.

Donde DORA sigue marcando terreno propio

Hay una tentación creciente de leer cualquier conversación sobre IA a través del AI Act y dejar DORA como una especie de reglamento de “seguridad TI”. Error. DORA tiene piezas que no se dejan absorber por el discurso general sobre IA porque responden a problemas estructurales del sector financiero.

La primera es la gobernanza directa del órgano de dirección. DORA no se limita a pedir que la entidad tenga políticas. Atribuye responsabilidades claras al management body sobre la aprobación, supervisión e implementación del marco de gestión del riesgo de las TIC. Si la IA se integra en funciones críticas o importantes, ese uso no puede tratarse como una capa experimental gestionada al margen del gobierno de resiliencia operativa.

La segunda es el régimen de terceros proveedores de servicios TIC. El artículo 28 de DORA y los artículos siguientes no hablan de terceros de forma decorativa: obligan a gestionar el riesgo derivado de dependencias tecnológicas, mantener registros de información sobre acuerdos contractuales, realizar evaluaciones previas y vigilar la concentración de riesgo. Si el componente de IA se consume como servicio, se entrena en infraestructura ajena o forma parte de una función crítica soportada por un proveedor TIC, DORA entra de lleno. Y entra con una mala noticia para quien pensaba resolverlo con procurement: el asunto no es solo contractual, es estructural.

La tercera pieza propia de DORA es la resiliencia probada, no solo declarada. El reglamento exige pruebas apropiadas del marco de resiliencia operativa digital y, para determinadas entidades, pruebas avanzadas basadas en amenazas. Esa cultura de test, validación y evidencia de resistencia no se reemplaza con documentación de proveedor ni con evaluaciones genéricas de seguridad del sistema de IA. Si el despliegue de IA afecta a procesos esenciales, la entidad tendrá que preguntarse cómo se comporta ese sistema en escenarios de degradación, fallo de proveedor, manipulación de datos, errores de salida o incidentes de disponibilidad. No basta con que el algoritmo parezca brillante en demo.

AI Act complica la gobernanza porque obliga a mirar dentro del sistema

Si DORA obliga a mirar la resiliencia de la entidad y su cadena TIC, el AI Act obliga a mirar dentro del sistema de IA con un nivel de detalle que muchas estructuras de compliance financiero no tienen todavía integrado. Ahí aparece un choque cultural interesante.

Las funciones de riesgo y cumplimiento del sector financiero llevan años trabajando con marcos de control robustos, pero a menudo orientados a procesos, outsourcing, seguridad, continuidad, modelo de riesgo o protección de datos. El AI Act mete el bisturí en elementos más específicos del propio sistema: su gestión de riesgos, su documentación técnica, la calidad y gobernanza de los datos cuando proceda, la supervisión humana, los registros automáticos, y atributos como exactitud, robustez y ciberseguridad. Es decir, no basta con demostrar que la organización tiene buen gobierno. Hay que demostrar también cómo el sistema está diseñado, validado, monitorizado y utilizado.

Ese desplazamiento importa mucho porque desmonta otra ilusión habitual: pensar que el programa de IA puede resolverse solo desde Legal, Compliance o Seguridad. No. Va a requerir una conversación incómoda, pero inevitable, entre ingeniería, arquitectura, riesgo no financiero, procurement, privacidad, validación de modelos, negocio y consejo. Y cuanto más crítica sea la función soportada por la IA, menos margen hay para el teatro documental.

GDPR sigue siendo el regulador silencioso que arruina muchos diseños apresurados

En medio del entusiasmo por encajar AI Act con DORA, a veces se trata GDPR como un actor secundario. Mala idea. Cuando el sistema de IA utiliza datos personales, GDPR no desaparece porque haya una norma más nueva y más vistosa sobre IA. Sigue poniendo límites reales de base jurídica, minimización, limitación de la finalidad, exactitud, seguridad del tratamiento y gobernanza de encargados y responsables.

Y si el uso de IA implica tratamiento susceptible de entrañar alto riesgo para los derechos y libertades de las personas físicas, el artículo 35 de GDPR obliga a valorar una evaluación de impacto relativa a la protección de datos. Si además se produce una violación de seguridad de los datos personales, el artículo 33 activa la notificación a la autoridad de control sin dilación indebida y, cuando sea posible, en un plazo no superior a 72 horas. Ese calendario convive con otros plazos y otros criterios de notificación en marcos como DORA. No son intercambiables.

Esto tiene una consecuencia operativa concreta: si tu entidad quiere racionalizar controles, no lo haga a costa de mezclar gatillos jurídicos distintos en un único procedimiento mal definido. Un incidente que afecte a un sistema de IA puede activar análisis bajo DORA por su impacto operativo, bajo GDPR por afectación a datos personales y bajo compromisos contractuales por terceros TIC. La eficiencia no consiste en hacer un formulario único bonito. Consiste en tener una capa común de intake y clasificación, y luego rutas de escalado diferenciadas según obligación jurídica.

NIS2 añade presión de gobernanza, aunque no resuelva tus solapamientos

NIS2 también aparece una y otra vez en este debate, a veces con más entusiasmo del necesario. Su artículo 21 establece medidas de gestión de riesgos de ciberseguridad que incluyen análisis de riesgos, gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas, evaluación de la eficacia de medidas, prácticas básicas de ciberhigiene y formación, entre otras. Sobre el papel, hay bastante material reutilizable para entidades financieras.

Pero NIS2 no viene a ordenar el puzle entre normas. Añade otra capa de exigencia y gobernanza. Además, su aplicación práctica depende de la transposición nacional y del encaje concreto de cada entidad en los regímenes internos. En otras palabras: puede ayudar a reforzar una arquitectura de controles ya seria, pero no conviene venderla como solución unificadora. Si alguien en tu organización está diciendo que con el programa NIS2 “ya cubrimos” AI Act o DORA, toca parar la reunión y volver a empezar.

Lo útil para las entidades: construir un mapa de obligaciones, no una presentación de colores

La respuesta madura a este cruce normativo no es conceptual, es operativa. Las entidades necesitan un mapeo de obligaciones que baje al nivel de requisito, evidencia, propietario del control y artefacto documental. Sin eso, la conversación sobre sinergias se queda en PowerPoint.

Ese mapa debería partir, como mínimo, de cuatro columnas reales. Primera: obligación jurídica concreta, citando artículo o bloque normativo relevante. Segunda: control interno o proceso que puede satisfacerla total o parcialmente. Tercera: evidencia verificable disponible o a generar. Cuarta: huecos, es decir, qué parte de la obligación no queda cubierta por el control común y exige tratamiento específico.

Un ejemplo sencillo. Si la entidad tiene un proceso consolidado de gestión de incidentes de seguridad, ese proceso puede aportar valor para DORA, para NIS2 y para GDPR. Pero el mapa debe dejar claro qué elemento del proceso cubre la clasificación del incidente, cuál documenta impacto operacional, cuál evalúa afectación a datos personales, cuál decide escalado regulatorio y cuál conserva trazabilidad del plazo aplicable. Si no se descompone así, el “proceso único” se convierte en una zona gris donde nadie sabe realmente qué obligación se ha cumplido y cuál no.

Lo mismo con terceros. Un marco de due diligence tecnológica puede ser útil, pero no basta con llamarlo “integrado”. Tiene que demostrar, por un lado, evaluación del riesgo del proveedor TIC y del servicio soportado en línea con DORA, y por otro, si procede, elementos ligados al sistema de IA, a los datos tratados y a los controles de uso y supervisión. Un cuestionario genérico de proveedor con cien preguntas no impresiona a nadie si no conecta con requisitos jurídicos concretos.

La gobernanza interna será el verdadero campo de batalla

La parte técnica del cruce normativo es difícil. La política interna lo es más. En muchas entidades, DORA vive en riesgo operativo, ciberseguridad, resiliencia o supervisión prudencial. GDPR está en privacidad y legal. AI Act, según la casa, puede acabar en innovación, riesgo de modelos, compliance, tecnología o en una mezcla bastante caótica de todos. Ese reparto funcional tiene un efecto perverso: cada equipo interpreta la convergencia regulatoria como una oportunidad para liderar el tema.

El resultado suele ser previsible. Se crean comités, subcomités, grupos de trabajo y repositorios compartidos. Se producen documentos. Se reparten RACI como si fueran confeti. Y aun así nadie decide una cuestión básica: quién tiene autoridad para afirmar que un control común satisface obligaciones distintas sin vaciar su trazabilidad legal.

La respuesta seria pasa por un modelo de gobernanza con dos niveles. Uno horizontal, para inventario, taxonomía, metodología y estándares de evidencia. Otro vertical, por obligación jurídica, donde cada función competente valide el encaje final. No es glamuroso. Funciona. Además, evita el problema clásico del compliance cosmético: un programa aparentemente integrado que se viene abajo en cuanto el supervisor pregunta por la cadena de justificación.

Qué no dice el EBA, y por eso mismo conviene leerlo bien

Tan relevante como lo que el EBA identifica es lo que no conviene poner en su boca. El documento sirve para abrir una conversación útil sobre relaciones entre marcos regulatorios y posibles eficiencias de implementación. No debería utilizarse como si cerrara definitivamente la discusión sobre equivalencias, ni como si convirtiera ciertos controles en universalmente válidos para toda obligación vinculada con IA, TIC o datos.

Tampoco hace falta atribuirle conclusiones más tajantes de las que realmente puede sostener. Si algo ha demostrado la cascada regulatoria digital europea es que los reguladores comparten vocabulario más rápido de lo que armonizan expectativas de supervisión. “Gobernanza”, “riesgo”, “monitorización”, “ciberseguridad”, “documentación” o “supervisión” suenan parecido en varios textos. El contenido exigible detrás de esas palabras no siempre coincide. Quien lea solo por palabras clave acabará sobreestimando las sinergias y subestimando las obligaciones residuales.

Y ahí aparece una ironía bastante europea: la retórica de simplificación puede terminar complicando más las cosas si se traduce en programas internos mal diseñados. Cuando todos hablan de convergencia, el riesgo real es que la organización baje la guardia justo donde más detalle hace falta.

La objeción razonable: quizá estamos exagerando el solapamiento

Hay una objeción seria a todo este enfoque, y merece atención. Algunos juristas y responsables de cumplimiento sostienen que el mercado se está obsesionando con los solapamientos y que eso lleva a infravalorar la especificidad de cada régimen. No les falta razón. Muchas obligaciones no son reducibles a un control común elegante. El intento de integrarlo todo puede terminar produciendo controles demasiado abstractos, dueños difusos y evidencias de mala calidad.

Ese riesgo existe. De hecho, en ciertas materias es preferible duplicar parte del trabajo antes que perder claridad jurídica. La documentación técnica de un sistema de IA, por ejemplo, no puede diluirse en una política general de tecnología responsable. Del mismo modo, la gestión contractual y el registro de terceros TIC exigidos por DORA tienen un nivel de concreción que no se reemplaza con un inventario amplio de proveedores digitales. Y una evaluación de impacto bajo GDPR no se sustituye con un assessment interno de ética algorítmica, por muy impecable que quede en la intranet.

Ahora bien, reconocer eso no invalida la utilidad del ejercicio. Solo obliga a utilizarlo con disciplina. La pregunta no es “¿podemos unificarlo todo?”. La pregunta madura es “¿qué parte merece estandarización y qué parte necesita piezas separadas por diseño?”. Esa diferencia separa a los programas de cumplimiento robustos de los programas vistosos.

Una forma práctica de aterrizarlo en 90 días

Si una entidad quiere convertir esta discusión en trabajo útil, no necesita esperar a una epifanía regulatoria. Puede empezar con cuatro movimientos bastante concretos.

• Inventario de casos de uso de IA: no un catálogo comercial, sino un registro operativo con finalidad, propietario, dependencia de terceros, datos utilizados, criticidad del proceso soportado y si existe potencial encaje como sistema de alto riesgo.
• Mapa normativo por caso de uso: AI Act cuando proceda, DORA si hay soporte a funciones financieras y dependencia TIC, GDPR si hay datos personales, NIS2 según encaje nacional y sectorial, además de reglas prudenciales y contractuales internas.
• Matriz de controles y evidencias: identificar controles comunes reutilizables y, al lado, los elementos no reutilizables que exigen documentación o validación específica.
• Gobernanza de decisiones: fijar qué foro aprueba el mapeo, quién valida las equivalencias parciales y quién asume la responsabilidad de las obligaciones residuales. Si eso no está escrito, no existe.

No parece revolucionario. Precisamente por eso suele funcionar. El sector lleva años tropezando no por falta de teoría, sino por falta de traducción operativa entre norma y control.

La lección de fondo: menos discursos sobre “alineación”, más pruebas de cobertura real

Lo más valioso del debate abierto por el EBA es que empuja a las entidades a abandonar dos hábitos bastante dañinos. El primero es hablar de alineación normativa como si fuera un fin en sí mismo. El segundo es medir la madurez de cumplimiento por la cantidad de políticas aprobadas, en lugar de por la capacidad de demostrar cobertura real requisito por requisito.

La próxima fase de este debate no se decidirá en documentos de posicionamiento, sino en auditorías internas, revisiones de control de segundo nivel, evaluaciones de terceros, pruebas de resiliencia y, llegado el caso, conversaciones supervisoras donde alguien pedirá evidencias concretas. Ahí no servirá decir que varios textos legales comparten espíritu. Habrá que enseñar qué control cubre qué obligación, con qué límites y bajo qué responsable.

Ese es el mensaje que las entidades harían bien en extraer ahora: sí, hay espacio para construir programas más integrados. No, eso no equivale a comprimir cinco marcos regulatorios en un único paquete de cumplimiento genérico. La diferencia entre una cosa y otra es, literalmente, la diferencia entre eficiencia regulatoria y desorden caro.

Si tu entidad está todavía en la fase de “ya veremos cómo encaja IA con DORA”, la ventana cómoda se está cerrando. No porque un documento aislado lo diga todo, sino porque la dirección del viaje regulatorio ya no admite una gestión por compartimentos estancos. Y cuando el regulador te obliga a dejar de fingir que los silos funcionan, suele ser porque llevaban tiempo sin funcionar.