El BCE pone la resiliencia cibernética en primera línea: menos retórica sobre IA y más presión supervisora real a la banca

Cuando el BCE habla de “riesgos modernos”, conviene escuchar dos veces. La primera, para separar la frase de escaparate de lo que realmente cambia. La segunda, para detectar si el supervisor está preparando el terreno para pedir más pruebas, más controles y menos cuentos. Eso es exactamente lo que ha ocurrido esta semana con el discurso de Sharon Donnery, miembro del Consejo de Supervisión del BCE, sobre la necesidad de una “supervisión moderna para riesgos modernos”, y con las declaraciones paralelas de Claudia Buch y Frank Elderson sobre riesgo geopolítico, simplificación y ciberresiliencia.

Leído deprisa, parece otro ejercicio institucional de esos que mezclan modernización, eficiencia y resiliencia como si fueran condimentos inevitables. Leído con algo de oficio, el mensaje es más concreto: el BCE está diciendo a los bancos que la ciberresiliencia ya no se va a tratar como un asunto técnico confinado al CISO, sino como una cuestión supervisora ligada a continuidad operativa, dependencia de terceros, gobernanza, riesgo geopolítico y, cada vez más, uso de inteligencia artificial.

El detalle relevante no es que el BCE mencione la IA. A estas alturas la menciona hasta el portero del regulador. Lo relevante es el encaje que está haciendo entre ciberresiliencia, dependencia operativa y capacidad de supervisión. Dicho sin rodeos: el supervisor europeo quiere bancos capaces de demostrar que entienden dónde están sus puntos de fallo, quién les presta realmente los servicios críticos, qué procesos aguantarían una degradación tecnológica seria y cómo responderían si la disrupción no fuera un incidente aislado, sino una cadena de fallos amplificada por tensiones geopolíticas.

Eso importa ahora por una razón obvia y otra menos obvia. La obvia es DORA, aplicable desde el 17 de enero de 2025, que ha convertido la resiliencia operativa digital en obligación jurídica directa para entidades financieras de la UE. La menos obvia es que el BCE está afinando su práctica supervisora para no mirar la ciberseguridad como un silo. El riesgo tecnológico ya entra por varias puertas a la vez: Pilar 2, gobernanza interna, outsourcing, continuidad, gestión de incidentes y concentración en terceros TIC. Quien siga tratando cada obligación por separado se va a llevar una sorpresa desagradable. Y no hará falta un ransomware para ello.

Lo que ha dicho realmente el BCE, y por qué esta vez sí conviene prestarle atención

La pieza central es el discurso pronunciado por Sharon Donnery el 11 de junio de 2026 bajo el título Modern supervision for modern risks. El texto, tal y como lo presenta el BCE, insiste en cuatro líneas: simplificación de procesos, clarificación del marco de capital, limpieza de atrasos supervisores y fomento de una integración más profunda del sector bancario europeo. Sobre el papel, nada revolucionario. El BCE lleva tiempo defendiendo que quiere ser más ágil, más basado en riesgos y menos burocrático. Hasta ahí, lo de siempre.

Lo nuevo aparece al leerlo junto con dos entrevistas publicadas el 10 de junio de 2026. En una de ellas, Claudia Buch, presidenta del Consejo de Supervisión, afirma que el BCE sigue muy de cerca el impacto de los precios de la energía, los aranceles y las disrupciones de cadena de suministro sobre el riesgo de crédito, y añade que la ciberresiliencia es también una prioridad a medida que los modelos de IA se vuelven más avanzados. En la otra, Frank Elderson, vicepresidente del Consejo de Supervisión, explica que el BCE quiere simplificar y acelerar procesos para ser “más basado en riesgos y más efectivo”, lo que implica también cambiar la cultura supervisora y fijar prioridades claras.

Juntas, esas tres intervenciones dejan ver la dirección. El BCE no está anunciando una norma nueva. Está haciendo algo más importante para las entidades bajo supervisión significativa: está señalando qué temas van a pesar más cuando se evalúe si una entidad entiende sus riesgos y puede gobernarlos. En supervisión bancaria, la jerarquía no solo se escribe en reglamentos; también se construye con discursos, prioridades supervisoras, cartas a consejeros y preguntas recurrentes en inspecciones. Quien espere a que el cambio llegue en forma de regla flamante suele llegar tarde.

Hay, además, una paradoja interesante. El BCE habla de simplificación justo cuando el perímetro de obligaciones tecnológicas y cibernéticas es más denso que nunca. DORA no ha simplificado nada para las entidades; ha ordenado, sí, pero también ha multiplicado la necesidad de evidencias, inventarios, pruebas y trazabilidad. NIS2, transpuesta a nivel nacional con calendarios desiguales, añade exigencias de gestión de riesgos y reporting para sectores esenciales y importantes. El AI Act incorpora deberes específicos para sistemas de alto riesgo y obligaciones transversales de alfabetización en IA. Y el GDPR sigue ahí recordando, con su artículo 33, que una brecha de datos personales no espera a que el comité de riesgos termine de debatir.

Cuando el BCE habla de simplificar, no está prometiendo menos exigencia. Está diciendo que quiere menos fricción en su maquinaria interna para centrarse más rápido en lo que considera material. Para los bancos, eso no equivale a menos trabajo. Equivale a menos excusas.

La ciberresiliencia ya no es una función de soporte: es una variable de solvencia operativa

Durante años, muchas entidades trataron la ciberseguridad como una disciplina de control técnico: firewalls, parches, SOC, phishing y, si había presupuesto, algún ejercicio de crisis. Ese enfoque se ha quedado corto. No porque esas capas ya no importen, sino porque el supervisor ha empezado a mirar el fallo tecnológico como evento con capacidad de afectar liquidez, prestación de servicios críticos, confianza de clientes, reporting regulatorio y, en casos extremos, viabilidad operativa.

DORA lo cristaliza con bastante claridad. El artículo 5 exige que el órgano de dirección defina, apruebe, supervise y asuma la responsabilidad de todas las disposiciones relativas al marco de gestión del riesgo relacionado con las TIC. No es una delegación elegante al departamento de tecnología. Es responsabilidad del management body. El artículo 6 obliga a contar con un marco interno de gobernanza y control que garantice una gestión del riesgo TIC eficaz y prudente. El artículo 11 entra en la respuesta y recuperación. El artículo 17 regula la gestión, clasificación y notificación de incidentes relacionados con las TIC. Los artículos 28 a 30 se meten de lleno en la gestión del riesgo de terceros prestadores de servicios TIC.

El BCE, por su parte, lleva años integrando el riesgo TIC en su práctica supervisora. Sus guías previas sobre riesgo TIC y ciberseguridad ya apuntaban a que las deficiencias en gobernanza, inventario de activos, gestión de cambios, continuidad y terceros tenían relevancia prudencial. Con DORA en vigor, esa intuición ha pasado a tener una estructura legal mucho más afilada. Y cuando Buch enlaza ciberresiliencia con modelos de IA “más avanzados”, lo que está haciendo es ampliar el foco: ya no basta con proteger la infraestructura tradicional; hay que entender cómo nuevas capas de automatización pueden introducir opacidad, dependencia de proveedores, exposición a manipulación de datos o degradación de procesos críticos.

Aquí está el quid. La IA en banca no es solo un riesgo de modelo. También es un riesgo operacional y de seguridad. Si una entidad integra modelos externos en scoring, atención al cliente, detección de fraude, priorización de alertas o asistencia a desarrolladores, la superficie de riesgo cambia. Pueden aparecer problemas de fuga de datos, acceso no autorizado, contaminación de prompts, dependencia contractual difusa, errores de trazabilidad o decisiones automatizadas mal gobernadas. No hace falta sobreactuar ni fingir el apocalipsis algorítmico. Basta con admitir que muchas implantaciones empresariales de IA han avanzado más rápido que la disciplina de control que las rodea.

El BCE lo sabe. Y por eso la frase sobre ciberresiliencia e IA merece atención aunque no venga con una circular de 30 páginas. Es un aviso de supervisión temprana.

La geopolítica deja de ser fondo de pantalla y entra en el expediente supervisor

La entrevista de Claudia Buch añade otro elemento que no debería pasar desapercibido: el BCE está conectando energía, aranceles y cadenas de suministro con riesgo de crédito. Eso ya sería bastante. Pero el añadido de ciberresiliencia sugiere una visión más integrada del riesgo geopolítico. La tesis implícita es sencilla: una perturbación geopolítica seria no afecta solo al balance por la vía macroeconómica; también puede afectar la operativa mediante proveedores críticos, infraestructuras, telecomunicaciones, software, servicios cloud o amenazas cibernéticas con motivación estatal o paraestatal.

En otras palabras, el supervisor se aleja de la visión escolar que separa “riesgo financiero” y “riesgo cibernético” como si vivieran en países distintos. No viven. Un incidente grave sobre un proveedor tecnológico, un ataque de denegación de servicio a una infraestructura de pagos, una campaña de intrusión sobre datos sensibles o una alteración prolongada del servicio de un tercero cloud puede escalar rápidamente desde el área técnica a la función de tesorería, al cumplimiento normativo y a la reputación de la entidad.

NIS2 encaja aquí con precisión quirúrgica. El artículo 21 obliga a las entidades esenciales e importantes a adoptar medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar los riesgos que amenacen la seguridad de las redes y sistemas de información. Entre esas medidas están la gestión de incidentes, la continuidad de negocio, la seguridad de la cadena de suministro, la seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas, las políticas de evaluación de la eficacia de la gestión de riesgos y prácticas básicas de ciberhigiene. Si una entidad financiera o parte de su grupo cae también bajo NIS2 a través de actividades cubiertas en su jurisdicción, el mapa de exigencias se vuelve todavía más entrelazado.

La consecuencia operativa es bastante menos abstracta de lo que parece. Los bancos ya no pueden evaluar sus dependencias críticas con listas de proveedores bonitas pero incompletas. Necesitan saber qué servicio soporta qué proceso crítico, qué subcontratistas intervienen, qué concentración existe por jurisdicción, qué salida real hay si el proveedor falla, cuál es el RTO efectivo y no el que figura en el PowerPoint, y qué capacidad de sustitución existe si el problema es sistémico y no individual. DORA insiste en esto al exigir una estrategia sobre riesgo de terceros TIC y un registro de información sobre acuerdos contractuales relacionados con el uso de servicios TIC prestados por terceros. Las entidades que todavía no tienen mapeado el cuarto nivel de su cadena tecnológica van tarde, aunque el dashboard diga verde.

DORA cambia el juego porque obliga a demostrar, no solo a prometer

Si hay una palabra que define el salto cualitativo de DORA es “demostrabilidad”. Antes, muchas entidades podían apoyarse en marcos internos razonables, políticas genéricas y cierta benevolencia interpretativa. Desde el 17 de enero de 2025, el margen para la ambigüedad se ha estrechado. El Reglamento (UE) 2022/2554 no pide simplemente buenas intenciones. Pide un marco integral de gestión del riesgo TIC, pruebas de resiliencia operacional digital, notificación de incidentes graves, gobernanza de terceros y capacidad de aprendizaje posterior a incidentes.

El artículo 15 exige que las entidades dispongan de capacidades y personal adecuados para recopilar información sobre vulnerabilidades y ciberamenazas, incidentes relacionados con las TIC, en particular ciberataques, y analizar el impacto probable de dichos eventos sobre la resiliencia operativa digital. El artículo 24 establece que las entidades, salvo algunas microempresas sujetas a un régimen simplificado, deben contar con un programa sólido y exhaustivo de pruebas de resiliencia operativa digital. El artículo 25 va más allá con pruebas avanzadas basadas en amenazas para determinadas entidades. La lógica es clara: si no pruebas, no sabes. Y si no sabes, al supervisor no le impresiona demasiado tu política corporativa de 42 páginas.

Esto enlaza con la retórica del BCE sobre modernización supervisora. Un supervisor “más basado en riesgos” no va a dedicar tiempo infinito a leer documentos que no aterrizan en capacidades medibles. Va a pedir evidencias más directas: resultados de pruebas, tiempos reales de recuperación, mapas de dependencias, decisiones del órgano de dirección, indicadores de tolerancia al impacto, incidentes clasificados y lecciones aplicadas. La época de confundir madurez documental con resiliencia efectiva empieza a agotarse.

Para los equipos de compliance esto tiene una implicación práctica incómoda: DORA no se puede cumplir solo desde compliance. Y para los equipos de seguridad hay otra igual de incómoda: tampoco se puede cumplir solo desde seguridad. El reglamento obliga a cruzar tecnología, negocio, legal, compras, continuidad, auditoría interna, gestión de riesgos y consejo. Si la entidad sigue organizada en feudos, la fricción no es un efecto secundario; es el riesgo.

IA, Mythos y el problema que nadie quiere admitir: muchas entidades la están adoptando con controles prestados

El BCE ya había deslizado en su Supervision Newsletter del 13 de mayo de 2026 una referencia a “urgentes preocupaciones de ciberseguridad” alrededor de desarrollos de IA como “Mythos”. Aunque el material aportado no detalla el caso, el mero hecho de que el BCE subraye una preocupación cibernética ligada a IA en su comunicación pública no es casual. Está construyendo narrativa supervisora.

La mayoría de bancos europeos no están desplegando modelos fundacionales propios a escala industrial. Están consumiendo servicios de terceros, ajustando modelos, integrando copilotos, automatizando funciones concretas o probando soluciones empaquetadas por grandes proveedores. Eso significa que los riesgos reales no siempre vienen del algoritmo como tal, sino del ensamblaje: quién aloja el modelo, dónde residen los datos, qué logging existe, qué restricciones de uso se aplican, si hay segregación entre tenants, cómo se gestionan prompts sensibles, si la salida del modelo se usa para decisiones críticas o meramente auxiliares, y qué ocurre cuando la herramienta falla o alucina en un proceso operativo relevante.

El AI Act no regula la ciberseguridad bancaria como tal, pero sí introduce piezas que los equipos financieros no pueden ignorar. El artículo 4 obliga a proveedores y responsables del despliegue de sistemas de IA a garantizar, en la medida de lo posible, un nivel suficiente de alfabetización en IA de su personal y otras personas que operen o utilicen sistemas de IA. Para sistemas de alto riesgo, los requisitos se endurecen con obligaciones de gestión de riesgos, gobernanza de datos, documentación técnica, trazabilidad, supervisión humana, precisión, robustez y ciberseguridad. Si un banco utiliza IA en contextos que puedan caer dentro de usos de alto riesgo o relevantes para funciones críticas, la conversación ya no es futurista. Es regulatoria.

El BCE, por tanto, no necesita convertirse en regulador de IA para supervisar sus implicaciones. Le basta con preguntar algo muy simple: ¿cómo afecta este despliegue de IA a la resiliencia, seguridad, continuidad y gobernanza de la entidad? Y ahí muchos bancos todavía van con controles heredados de un mundo pre-LLM. El resultado suele ser una combinación poco elegante de entusiasmo comercial, contratos opacos, excepciones de seguridad, inventarios incompletos y auditoría intentando reconstruir los hechos a posteriori. Una delicia para cualquier JST. Una pesadilla para quien tenga que responderla.

Simplificación supervisora no significa indulgencia: significa menos paciencia con procesos torpes

Frank Elderson habla de acelerar y simplificar procesos supervisores para ser más eficaz. Es fácil leer esa frase como música ambiental. Sería un error. Cuando un supervisor grande y complejo promete simplificación, normalmente no está pensando en aliviar a los supervisados; está pensando en mejorar su propia capacidad de escalar, priorizar y cerrar expedientes.

Traducido al terreno práctico, esto puede significar varias cosas para las entidades significativas bajo el Mecanismo Único de Supervisión. Primera: menos tolerancia a respuestas vagas o inconexas cuando el supervisor pregunta por una misma materia desde varias funciones. Segunda: mayor uso de información estructurada y comparable para detectar entidades outlier. Tercera: aceleración en el paso desde observación supervisora a medida concreta cuando las deficiencias persisten. Cuarta: más presión para que la dirección de la entidad entienda temas técnicos que antes podía amortiguar delegándolos por capas.

No es una especulación extravagante. El BCE lleva tiempo insistiendo en backlog, eficiencia y priorización. Y la experiencia reciente en otros ámbitos muestra que, cuando los supervisores detectan cuellos de botella internos, intentan resolverlos no reduciendo exigencias, sino acortando el tiempo entre hallazgo y consecuencia. Para los bancos, eso sube el valor de tener una línea argumental coherente que una DORA, outsourcing, gestión de incidentes, continuidad, cloud y riesgos emergentes como IA.

También cambia la economía interna de la evidencia. Si antes una entidad podía vivir con documentación repartida entre áreas, controles duplicados y ownership difuso, una supervisión más ágil castiga precisamente esa dispersión. El banco que sabe localizar en horas su inventario de servicios críticos, sus evaluaciones de terceros, sus pruebas de recuperación, sus incidentes materiales, sus decisiones de comité y sus excepciones aprobadas parte con ventaja. El que necesita tres semanas para cuadrar versiones de un mismo dato entre Riesgos, Tecnología y Compras está regalando una conclusión supervisora que nadie quiere leer por escrito.

Qué deberían estar revisando ya los bancos, aunque el BCE no haya emitido una nueva guía

El error clásico ante mensajes como este es esperar a que llegue una obligación adicional “formal”. Mala idea. La utilidad de los pronunciamientos del BCE está precisamente en que permiten anticipar dónde se concentrará el escrutinio. Si la ciberresiliencia, la geopolítica y la IA suben en prioridad, hay varios frentes que merecen revisión inmediata.

El primero es la gobernanza del riesgo TIC a nivel de órgano de dirección. DORA art. 5 no pide una aprobación ritual de políticas; pide implicación efectiva. ¿Recibe el consejo métricas que conecten tecnología con impacto de negocio? ¿Se revisan tolerancias al impacto por servicio crítico? ¿Existen decisiones registradas sobre aceptación de riesgos asociados a terceros o a implantaciones de IA? ¿Se discuten escenarios de degradación prolongada y no solo incidentes de una hora? Si las actas no cuentan esa historia, el supervisor tampoco la verá.

El segundo frente es el inventario de activos, procesos y dependencias. Parece básico porque lo es. Y aun así sigue siendo uno de los puntos más frágiles en muchas entidades. Sin un mapa fiable de servicios críticos, aplicaciones, flujos de datos y terceros implicados, no hay clasificación seria de incidentes, no hay pruebas creíbles y no hay continuidad real. DORA exige mantener registros de acuerdos con terceros TIC; NIS2 aprieta sobre seguridad de la cadena de suministro; el BCE mira la resiliencia como capacidad operativa. Todo converge ahí.

El tercero es la gestión de terceros TIC y concentración. DORA art. 28 obliga a adoptar y revisar una estrategia sobre el riesgo derivado de terceros prestadores de servicios TIC. Los artículos 30 y siguientes detallan requisitos contractuales y de supervisión. La pregunta incómoda no es si existe una política. Es si la entidad puede demostrar qué servicios no podría reemplazar en un plazo razonable, qué dependencias están concentradas en uno o dos hyperscalers, qué subprocesadores participan y qué derechos reales de auditoría, acceso, notificación e información conserva. Aquí suele aparecer la ironía regulatoria favorita de la década: bancos muy sofisticados en capital, pero sorprendentemente confusos cuando se les pregunta quién procesa exactamente una función crítica y bajo qué condiciones.

El cuarto frente es la capacidad de notificación y coordinación entre regímenes. Un incidente grave puede activar DORA por el lado operativo, GDPR art. 33 por el lado de datos personales y, dependiendo de la estructura nacional y del tipo de entidad, también obligaciones NIS2. Si la clasificación inicial del incidente depende de discusiones interminables entre Legal, Privacidad, Ciber y Negocio, el reloj regulatorio no se detiene para mostrar empatía. La entidad necesita criterios de escalado, ownership y rutas de decisión previamente ensayadas.

El quinto frente es la disciplina de pruebas. No solo pruebas técnicas aisladas, sino ejercicios que midan capacidad de recuperación real de servicios importantes, coordinación ejecutiva, comunicación externa y resiliencia de dependencias. DORA art. 24 no se satisface con un pentest reciclado y una presentación alegre del SOC. El supervisor querrá entender qué se probó, qué falló, cuánto tardó la recuperación, qué decisiones se tomaron y qué se corrigió después.

Implicaciones para entidades financieras españolas

Para bancos españoles significativos bajo supervisión directa del BCE, el mensaje tiene una traducción inmediata: la conversación sobre ciberresiliencia va a seguir subiendo de rango dentro del diálogo supervisor europeo. No porque España sea un caso aparte, sino porque las entidades españolas están plenamente dentro del perímetro donde confluyen DORA, el Mecanismo Único de Supervisión y, en muchos casos, arquitecturas tecnológicas extensas, ecosistemas de proveedores globales y operaciones transfronterizas.

Hay, además, dos particularidades que conviene tener presentes. La primera es la elevada externalización tecnológica y el uso intensivo de proveedores globales de infraestructura y software. Eso no distingue a España de otros mercados europeos, pero sí amplifica un riesgo de concentración que DORA y el futuro marco de supervisión de terceros TIC críticos quieren atacar. La segunda es la convivencia de grandes grupos con filiales, negocios aseguradores, servicios de pago y, en ocasiones, presencia relevante en América Latina. Ese perímetro mixto complica inventarios, reporting, flujos de datos, gestión contractual y respuesta coordinada a incidentes.

Para las fintech españolas y entidades de pago, el reto es distinto pero no menor. Muchas no están bajo supervisión bancaria significativa del BCE, pero sí bajo DORA por su condición de entidades financieras cubiertas. Su problema suele ser de escala: menos capas de defensa, menos músculo contractual frente a grandes proveedores y menos separación entre equipos de producto, ingeniería y riesgo. Justo el entorno donde es más fácil que una implantación apresurada de IA o una dependencia cloud mal documentada se conviertan en un problema regulatorio antes incluso de convertirse en incidente público.

Las aseguradoras, aunque no estén en el ámbito del BCE bancario, deberían tomar nota por una razón práctica: la lógica supervisora europea se contagia. Cuando Bruselas, las ESAs y el BCE alinean lenguaje sobre resiliencia, terceros e incidentes, el resto del ecosistema regulado acaba recibiendo señales parecidas. No siempre al mismo ritmo, pero sí en la misma dirección.

El cruce con GDPR y NIS2: donde muchas respuestas regulatorias se rompen por falta de coordinación

Una de las debilidades más persistentes en las entidades es responder a cada norma con un proyecto distinto, un comité distinto y, si nos ponemos creativos, un repositorio distinto. Después llega un incidente real y todo el mundo descubre que las taxonomías no coinciden, los umbrales no encajan y las responsabilidades se pisan. Regulación por silos, respuesta por silos, desastre por silos.

GDPR art. 33 obliga a notificar a la autoridad de control una violación de seguridad de los datos personales sin dilación indebida y, cuando sea posible, a más tardar 72 horas después de haber tenido constancia de ella, salvo que sea improbable que dicha violación constituya un riesgo para los derechos y libertades de las personas físicas. DORA establece su propia lógica de clasificación y notificación de incidentes graves relacionados con las TIC. NIS2, en su artículo 23, impone alertas tempranas y notificaciones de incidentes significativos con plazos escalonados. Si una entidad no ha mapeado antes cómo conviven esas obligaciones, el incidente se convierte en un laboratorio de improvisación. Y la improvisación bajo reloj regulatorio suele producir documentos peores que el incidente.

La solución no es crear un “mega-procedimiento” monstruoso que nadie entiende. Es definir una arquitectura de respuesta con puntos comunes y bifurcaciones claras: una taxonomía única de incidentes, criterios de severidad vinculados a impacto operativo y datos personales, un comité de decisión con autoridad real, un registro maestro de incidentes y playbooks que indiquen cuándo salta cada obligación, ante qué autoridad y con qué evidencias mínimas. Parece de sentido común. Lo es. Precisamente por eso sigue faltando en demasiadas organizaciones.

Qué puede venir después: más foco en terceros críticos, pruebas avanzadas y responsabilidad de la alta dirección

Conviene no sobrerreaccionar. El BCE no ha anunciado una ofensiva formal nueva ni un paquete sancionador específico sobre IA. Pero sería ingenuo no ver la trayectoria. La combinación de DORA ya aplicable, un discurso supervisor que enlaza ciberresiliencia con IA y geopolítica, y la obsesión del BCE por hacer su supervisión más rápida y basada en riesgos apunta a tres movimientos probables.

Primero, mayor atención a la concentración y dependencia de terceros TIC. DORA dedica una parte sustantiva de su arquitectura a este punto porque el problema es estructural: demasiadas funciones críticas apoyadas en demasiado pocos proveedores. No se resuelve con una cláusula contractual bien redactada. Requiere estrategia, inventario, pruebas y planes de salida creíbles, aunque sean parciales.

Segundo, más exigencia sobre la calidad de las pruebas de resiliencia. No bastará con enseñar un calendario de ejercicios. Habrá que demostrar que las pruebas reflejan escenarios plausibles, incluyen dependencias reales y generan remediación. Las pruebas avanzadas basadas en amenazas previstas por DORA art. 26 y el marco asociado para entidades relevantes no son un adorno regulatorio; son una forma de obligar a la banca a enfrentarse a sus fallos antes de que lo haga un adversario.

Tercero, más presión sobre la alta dirección. DORA ya la impone jurídicamente. El BCE está ayudando a normalizarla supervisoriamente. El mensaje de fondo es incómodo para muchos consejos: si la resiliencia digital falla, no será aceptable responder que el tema estaba “en manos del equipo técnico”. Estaba, sí. Pero bajo vuestra responsabilidad.

La lectura incómoda para la banca: el BCE ya no está hablando de tecnología, sino de disciplina institucional

Lo fácil sería leer todo esto como otra ronda de advertencias tecnológicas. Sería una lectura superficial. El BCE no está lanzando una tesis sobre herramientas concretas ni sobre una amenaza puntual. Está planteando algo más serio: que la capacidad de una entidad para gobernar su complejidad tecnológica forma parte de su calidad institucional como banco supervisado.

Eso explica por qué la conversación junta simplificación, backlog, riesgo geopolítico, integración del sector y ciberresiliencia. No son piezas sueltas. Son la misma pregunta formulada desde distintos ángulos: ¿puede este banco seguir prestando servicios críticos de forma segura, gobernada y recuperable en un entorno donde la tecnología, los proveedores y el contexto geopolítico son más inestables que hace cinco años?

Si la respuesta depende de heroicidades individuales, la entidad tiene un problema. Si depende de que nadie toque cierta aplicación heredada porque “nadie sabe bien qué rompe”, tiene dos problemas. Si además está desplegando IA sin inventario consolidado, sin reglas de uso vinculantes y sin evaluar dependencia contractual y operativa, ya no estamos ante innovación ágil. Estamos ante riesgo supervisor con marketing encima.

La parte casi irónica de esta historia es que el BCE presenta su agenda como modernización y simplificación. Y, sin embargo, lo que exige a las entidades es una disciplina bastante menos glamurosa: inventariar mejor, probar más, gobernar de verdad, escalar antes, documentar con precisión y entender que la resiliencia no se delega por completo. No suena épico. Pero eso es exactamente lo que separa a una entidad preparada de otra que solo parece preparada en las presentaciones.

El sector haría bien en no despreciar estas señales por falta de “novedad normativa”. En banca europea, muchas de las obligaciones que más pesan no llegan como sorpresa; llegan como insistencia. Y cuando el BCE insiste en modernizar la supervisión frente a riesgos modernos, lo que está diciendo en realidad es bastante simple: el supervisor quiere ver si tu banco opera como una institución del presente o como una colección de parches heredados. La respuesta, esta vez, no la dará un discurso. La dará la próxima revisión supervisora, el próximo incidente serio o la próxima vez que el BCE pregunte por IA, terceros críticos y tiempos reales de recuperación en la misma reunión.