El BCE pone fecha al miedo útil: qué deben entregar los bancos antes del 31 de octubre por los ciberataques con IA

Esta vez el BCE no ha enviado una carta para decorar la carpeta de compliance. Ha puesto una fecha concreta —31 de octubre de 2026— y un mensaje bastante menos burocrático de lo habitual: las entidades significativas tienen que presentar un plan de acción específico frente a amenazas cibernéticas habilitadas por inteligencia artificial. La comunicación salió de Supervisión Bancaria del BCE el 7 de julio de 2026 y, por el tono y el contenido, merece leerse como algo más que una extensión de DORA con otro membrete.

La clave no es que el supervisor haya descubierto la IA en 2026. La clave es otra: el BCE está diciendo que el problema no es una categoría nueva de riesgo, sino la velocidad. Y cuando un supervisor europeo cambia el eje desde “qué riesgo existe” a “a qué velocidad se materializa”, el impacto operativo es inmediato. La ventana entre descubrimiento de una vulnerabilidad y explotación ya no se mide con la comodidad de antes. En algunos casos, se mide en horas. Eso desordena la priorización de parches, la monitorización, la gestión de terceros, las pruebas de resiliencia y, sí, también el gobierno interno.

Si diriges ciberseguridad, riesgo operacional, continuidad o compliance en un banco supervisado directamente por el BCE, aquí está el quid: no te están pidiendo una presentación elegante sobre IA. Te están pidiendo un plan accionable, con prioridades, responsables, plazos y dependencia clara de hallazgos abiertos. Y lo están encajando sobre un suelo regulatorio que ya existe: DORA, la supervisión prudencial, los hallazgos de inspección y el recuerdo nada lejano del stress test de resiliencia cibernética de 2024.

Eso cambia la conversación dentro del banco. Ya no vale decir que el programa de transformación de seguridad “está en marcha”. La pregunta ahora es mucho más incómoda: ¿qué debilidades concretas siguen abiertas hoy y cómo empeoran cuando un atacante usa IA para acelerar reconocimiento, explotación, phishing, movimiento lateral o abuso de credenciales?

Lo que realmente ha dicho el BCE el 7 de julio de 2026

La carta de Supervisión Bancaria del BCE a las entidades significativas, fechada el 7 de julio de 2026, pide la presentación antes del 31 de octubre de 2026 de un plan de acción para abordar amenazas de ciberseguridad habilitadas por IA. No es un ejercicio abstracto de “sensibilización”. El supervisor estructura la respuesta esperada en seis áreas de foco y, además, exige una secuencia: primero deben abordarse los hallazgos supervisores abiertos, incluyendo los derivados de inspecciones y del ejercicio de resiliencia cibernética de 2024.

Esa secuenciación merece más atención de la que parece. Muchos bancos querrían presentar algo llamativo sobre copilots defensivos, automatización del SOC o análisis avanzado de telemetría. El BCE, en cambio, viene a decir: estupendo, pero antes cierre usted lo básico que sigue mal. Si tienes findings abiertos sobre gestión de vulnerabilidades, segmentación, inventario de activos, privilegios excesivos o capacidad de recuperación, la IA no reduce su gravedad; la multiplica.

Hay una sutileza supervisora interesante. El BCE no está creando, al menos por ahora, un régimen jurídico autónomo para “riesgo de IA en ciber”. No está diciendo que haya una séptima familia de riesgo que requiera otra taxonomía, otro comité y otra capa de presentaciones en PowerPoint. Lo que está haciendo es peor —o mejor, según tu tolerancia al realismo regulatorio—: reinterpreta controles ya exigibles bajo una premisa de ataque acelerado. Eso hace más difícil refugiarse en la excusa clásica de “estamos esperando claridad normativa”. Claridad hay bastante.

Desde enero de 2025, DORA es plenamente aplicable en la UE. Sus obligaciones sobre marco de gestión de riesgo TIC, gestión de incidentes, pruebas de resiliencia, terceros TIC y gobernanza no son opcionales ni experimentales. El BCE se apoya precisamente en ese ancla. En otras palabras: el supervisor no te está pidiendo un programa paralelo a DORA, sino una capa de adaptación urgente de tus capacidades DORA a un entorno donde el atacante automatiza más, aprende más rápido y escala más barato.

Por qué la IA cambia el cálculo del supervisor: no inventa riesgos, comprime el tiempo

La mejor frase de fondo de esta iniciativa es también la más incómoda para los bancos: la IA actúa como amplificador. No cambia necesariamente la naturaleza del riesgo; cambia su ritmo, su volumen y su coste de ejecución. Para los equipos defensivos, esa diferencia lo altera todo.

Hasta hace poco, muchos programas de ciberseguridad toleraban cierta latencia. Inventarios incompletos, ciclos de parcheo con excepciones largas, revisiones trimestrales de privilegios, dependencias manuales entre equipos, análisis forense pesado, detección afinada pero lenta. Nada de eso era ideal, pero funcionaba razonablemente en un entorno donde muchos atacantes también sufrían fricción. La IA reduce buena parte de esa fricción del lado ofensivo.

¿Qué significa eso en la práctica? Cuatro cosas muy concretas.

Primero, el reconocimiento externo se abarata. Enumerar superficies expuestas, detectar patrones de versiones, relacionar subdominios, clasificar tecnologías o inferir rutas de ataque ya no requiere el mismo esfuerzo artesanal. Segundo, el phishing y la ingeniería social ganan calidad y personalización. Ya no hablamos solo de correos torpes con faltas de ortografía; hablamos de campañas lingüísticamente correctas, contextuales y escalables. Tercero, el abuso de credenciales y secretos encuentra más caminos cuando proliferan cuentas técnicas, tokens, APIs y automatizaciones mal gobernadas. Cuarto, el ciclo de explotación puede acelerarse lo suficiente como para volver irrelevantes ciertos SLA internos que en 2024 parecían aceptables.

Aquí conviene cruzar el mensaje del BCE con obligaciones normativas ya vigentes. DORA exige un marco sólido de gestión del riesgo TIC en sus artículos 5 a 16, incluyendo identificación, protección, detección, respuesta y recuperación. El artículo 8 se centra en identificación, clasificación y documentación de funciones, activos de información y dependencias TIC. Si una entidad no tiene un inventario fiable de activos y dependencias, no puede priorizar una superficie de ataque que cambia deprisa. El artículo 10 exige capacidades de detección de actividades anómalas, problemas de rendimiento de red e incidentes relacionados con TIC. En un entorno de ataques asistidos por IA, esa detección tiene que trabajar con menos margen temporal y mejor telemetría.

La ironía regulatoria es evidente: durante años, media industria vendió “transformación digital” acelerando integraciones, APIs y automatización. Ahora el supervisor viene a pasar la factura de esa velocidad. Y no le falta razón.

Las seis áreas de foco del BCE, traducidas a decisiones operativas reales

La carta del BCE organiza el plan en seis áreas. Sobre el papel parecen familiares. La novedad está en cómo se combinan y en el orden implícito de ejecución.

1. Priorizar superficies de ataque: sin inventario útil no hay plan serio

El BCE pide inventario completo de activos, incluidos componentes de terceros y de código abierto, con prioridad para perímetro y sistemas expuestos a internet. Esto conecta directamente con DORA art. 8 y con una realidad operacional poco glamurosa: demasiadas entidades siguen teniendo CMDBs que describen un banco idealizado, no el banco real.

Un plan creíble para el BCE debería distinguir al menos entre activos internet-facing, activos críticos de negocio, activos con dependencias de autenticación, componentes EOL o legacy y activos soportados por terceros críticos. También debería mapear librerías open source con exposición relevante y no limitarse al inventario de infraestructura tradicional. Quien llegue a octubre con una lista bonita pero sin trazabilidad a owners, criticidad y exposición, llegará cojo.

La parte delicada es la cadena de suministro. El BCE menciona terceros y open source porque sabe que el perímetro bancario ya no acaba en el CPD ni en la VPC. DORA art. 28 y siguientes, sobre gestión del riesgo de terceros prestadores de servicios TIC, ya obligan a una gobernanza exigente. La novedad en 2026 es que el supervisor espera que esa gobernanza responda a escenarios de explotación más rápidos. Si tu proveedor tarda 15 días en confirmar exposición a una librería vulnerable, tu riesgo no es contractual: es operativo.

2. Acelerar vulnerabilidades y parcheo: el viejo SLA trimestral ya no impresiona a nadie

El BCE quiere escaneo priorizado y parcheo más rápido, con uso de herramientas de IA bajo supervisión humana. Ese último matiz importa. No está bendiciendo la automatización ciega. Está aceptando que la IA puede ayudar en priorización, correlación y remediación, pero sin soltar el volante.

Esto obliga a revisar cómo se priorizan las vulnerabilidades. El mero CVSS ya era insuficiente antes; en 2026 es claramente pobre. Un plan sólido debe combinar severidad técnica, exposición real, explotabilidad observada, criticidad de negocio, existencia de controles compensatorios y dependencia de credenciales privilegiadas. Si una entidad sigue tratando igual una vulnerabilidad alta en un activo segmentado que una media en un sistema expuesto con credenciales heredadas, el BCE no verá sofisticación; verá desorden.

También hay una implicación documental. Si la IA se usa para triage o recomendación de parcheo, conviene evidenciar supervisión humana, criterios de validación y límites de uso. No por fetichismo documental, sino porque enlaza con dos frentes regulatorios: gobernanza tecnológica bajo DORA y, cuando proceda, obligaciones derivadas del AI Act para ciertos sistemas de IA según su caso de uso y clasificación. No todo uso interno defensivo de IA quedará dentro del ámbito más duro del AI Act, pero la gobernanza de modelos, datos y supervisión humana ya no es una discusión teórica.

3. Reforzar monitorización y defensa habilitada por IA: más logs no equivale a más seguridad

El BCE menciona análisis de logs de aplicaciones, accesos y tráfico de red. Parece obvio, pero tiene trampa. El problema de muchas entidades no es la falta de telemetría; es la incapacidad para correlacionarla con contexto de identidad, criticidad y comportamiento esperado.

El salto relevante aquí no es “comprar más SIEM”, sino enriquecer la detección con contexto. Un acceso anómalo desde una cuenta de servicio con privilegios heredados y uso infrecuente puede ser más preocupante que cien alertas genéricas de endpoint. Y eso conecta con una verdad incómoda: muchas estrategias de monitorización bancaria siguen centradas en identidades humanas, cuando el mayor crecimiento está en identidades no humanas.

La fuente citada alude a un dato de KPMG según el cual las identidades no humanas podrían superar a las humanas entre 25 y 50 veces. Ese rango conviene manejarlo con prudencia porque dependerá de la arquitectura de cada entidad, pero la dirección es verosímil: cuentas de servicio, secretos, certificados, bots, APIs, procesos automatizados y agentes autónomos crecen mucho más deprisa que la plantilla. Si el BCE te pide prepararte para amenazas aceleradas por IA y tu monitorización sigue pensando casi solo en usuarios empleados, vas tarde.

4. Reforzar gobernanza, financiación y supply chain: el presupuesto también es un control

El BCE pide métricas específicas de IA en el marco de apetito de riesgo, formación de concienciación y una gestión más dura del riesgo de terceros. Traducido: el consejo y la alta dirección no pueden tratar este asunto como un anexo técnico del CISO.

DORA art. 5 deja claro que el órgano de dirección tiene responsabilidad última sobre la gestión del riesgo TIC. No basta con aprobar una política anual y hacerse una foto. Si el plan frente a amenazas habilitadas por IA no aterriza en métricas, tolerancias, ownership y decisiones de inversión, fallará en la primera revisión seria. El supervisor querrá ver cómo se decide qué se remedia antes, qué dependencias de terceros son críticas, qué riesgos se aceptan temporalmente y quién firma esa aceptación.

La cadena de suministro merece capítulo propio. NIS2 ya endureció el enfoque sobre seguridad de la cadena de suministro en su artículo 21, aunque su transposición y aplicación práctica varían por Estado miembro. DORA, por su parte, lo aterriza con más detalle para el sector financiero. El BCE ahora superpone la variable IA: no se trata solo de saber si el proveedor tiene controles, sino de si esos controles responden con la rapidez adecuada. Un proveedor con buena documentación pero lentitud sistémica en remediación puede convertirse en el eslabón más caro de tu programa de resiliencia.

5. Defense-in-depth de verdad: segmentación, mínimo privilegio y zero trust sin eslóganes

La quinta área mezcla segmentación, verificación continua de usuarios, aplicaciones, APIs y cuentas de servicio, mínimo privilegio, MFA y sustitución de legacy. Aquí el BCE está tocando la fibra del problema real: demasiados bancos aún tienen arquitecturas donde un compromiso inicial puede escalar más de la cuenta por confianza heredada y privilegios sobrantes.

Si buscas la traducción regulatoria, DORA art. 9 sobre protección y prevención exige políticas, procedimientos, protocolos y herramientas que limiten el impacto de incidentes TIC, impidan pérdida de datos y eviten accesos no autorizados. La exigencia del BCE encaja plenamente ahí, pero añade un matiz práctico: en un escenario con IA ofensiva, el atacante encuentra más deprisa dónde están los privilegios excesivos y las relaciones de confianza blandas.

La parte más madura del análisis es incluir APIs y service accounts al mismo nivel que usuarios humanos. Eso no siempre ocurre ni en bancos grandes. Muchas entidades han invertido años en recertificaciones de accesos de empleados mientras dejan cuentas técnicas con permisos amplios, propietarios dudosos y rotación mejorable de secretos. Luego llega un incidente y todos descubren, con gran teatralidad, que el problema no fue un empleado malicioso sino una identidad técnica olvidada. Qué sorpresa.

6. Resiliencia operativa: probar recuperación contra oleadas zero-day y ataques destructivos

La sexta área exige gestión de crisis y recuperación probadas, ejercicios frente a oleadas de zero-days y ataques destructivos, además de intercambio seguro de información. Esta parte enlaza con el corazón de DORA: no se trata solo de prevenir, sino de resistir, responder y recuperarse.

DORA art. 11 obliga a poner en marcha una respuesta y recuperación TIC integral, con planes, procedimientos y métodos para restaurar funciones y minimizar daños. El BCE ahora afina el escenario: no valen únicamente tabletop genéricos o simulaciones demasiado cómodas. Quiere ejercicios que asuman velocidad, simultaneidad y potencial destrucción. En otras palabras, no preguntes solo si puedes restaurar un servidor; pregunta si puedes sostener funciones críticas mientras varios vectores se mueven a la vez y parte de tus supuestos de confianza se derrumban.

También hay una dimensión de cooperación. El intercambio seguro de información no es un adorno; es una capacidad que puede reducir tiempo de detección y reacción. Para entidades que operan en varios Estados miembros, esto requiere además ordenar la convivencia entre secreto bancario, requisitos de notificación, acuerdos con proveedores y coordinación con autoridades competentes.

Lo que el BCE no dice explícitamente, pero claramente espera ver

Las cartas supervisoras suelen ser más educadas que ingenuas. El BCE no detalla cada evidencia, pero cualquiera que haya pasado por inspecciones sabe qué distingue un plan serio de un documento cosmético.

Primero, trazabilidad entre hallazgos previos y medidas nuevas. Si el banco ya tenía findings de 2024 o 2025 sobre vulnerabilidades, IAM, segmentación o continuidad, el nuevo plan tiene que mostrar cómo la hipótesis de amenaza acelerada por IA cambia la prioridad, el plazo o el control compensatorio. Segundo, ownership nominal. No “el área de ciberseguridad”. Nombres de funciones responsables, con soporte de tecnología, operaciones, negocio y riesgo. Tercero, hitos fechados antes y después del 31 de octubre. El BCE ha puesto esa fecha para la entrega, no para que empiece el trabajo.

Cuarto, criterios de materialidad. Un plan creíble debe decir qué superficies o procesos se abordan primero y por qué. Quinto, dependencia de terceros. El supervisor querrá ver si el banco conoce qué medidas dependen de proveedores TIC, MSPs, cloud, software crítico o integradores. Sexto, evidencia de prueba. Si afirmas que mejoras detección o recuperación, necesitas resultados de ejercicios, tiempos observados, coverage real o gap documentado.

Un punto adicional que muchas entidades subestimarán: la gobernanza de identidades no humanas. No aparece como categoría aislada en la carta, pero atraviesa varias áreas. Si el banco usa automatización extensiva, integración por API, procesos robotizados o agentes internos, debería mapear propietarios, fines, privilegios, secretos, ciclo de vida y controles de revocación. No es un capricho técnico; es superficie de ataque pura.

DORA, NIS2, GDPR y AI Act: dónde encaja esta exigencia y dónde no conviene mezclarlo todo

La tentación habitual en compliance europeo es convertir cualquier novedad en una sopa de siglas. Conviene resistirse. La iniciativa del BCE tiene ancla principal en supervisión bancaria y resiliencia operacional, no en protección de datos. Aun así, la interacción con varios marcos es real.

Con DORA, el encaje es directo. Ya hemos visto los artículos 5, 8, 9, 10, 11 y 28 como columnas del asunto. Además, DORA art. 17 y siguientes regulan la gestión, clasificación y notificación de incidentes relacionados con TIC. Si las amenazas aceleradas por IA incrementan frecuencia o severidad de ciertos incidentes, las entidades deben revisar si sus mecanismos internos de clasificación y escalado siguen siendo adecuados. Un playbook pensado para incidentes graduales puede fallar cuando el tiempo de propagación se reduce.

Con NIS2, la relación es complementaria, sobre todo para entidades y proveedores que queden dentro de su ámbito o convivan con exigencias nacionales derivadas de su transposición. El artículo 21 de NIS2 exige medidas técnicas, operativas y organizativas apropiadas, incluyendo seguridad de la cadena de suministro, gestión de vulnerabilidades, higiene básica y formación. La dirección es la misma. La diferencia es que el BCE habla desde la lupa supervisora financiera y con una urgencia temporal específica.

Con GDPR, el vínculo aparece cuando un incidente de ciberseguridad implica violación de seguridad de datos personales. El artículo 33 del RGPD obliga a notificar a la autoridad de control sin dilación indebida y, cuando sea posible, dentro de las 72 horas siguientes a tener constancia de la brecha. La aceleración del ataque por IA no cambia ese plazo, pero puede dificultar saber antes si existe afectación a datos personales y cuál es su alcance. Eso exige mejor coordinación entre ciberseguridad, legal y privacidad. No porque el BCE lo haya dicho en la carta, sino porque los relojes regulatorios no esperan a que el SOC termine de entender el incidente.

Con el AI Act, el encaje es más matizado. No todo uso de IA en defensa o seguridad implicará obligaciones duras bajo el Reglamento de IA, y muchas implementaciones internas requerirán análisis de caso concreto. Lo que sí cabe afirmar con seguridad prudente es que la supervisión humana, la gobernanza del sistema, la calidad de datos y la trazabilidad de decisiones ganan peso cuando la entidad usa IA en procesos defensivos relevantes. El BCE, con su referencia al uso de IA solo bajo supervisión humana en parcheo y priorización, está marcando una línea de buen gobierno aunque no cite el AI Act.

Qué debería contener un plan que no haga perder el tiempo al supervisor

Una mala noticia para quienes viven del PowerPoint táctico: el BCE no necesita más diapositivas sobre “journeys” ni más pirámides de madurez. Necesita un plan ejecutable. Y eso, a estas alturas de 2026, tiene una anatomía bastante reconocible.

Debe empezar por una base de exposición actual. No una visión ideal, sino una fotografía defendible de activos expuestos, rutas críticas, cuentas privilegiadas, dependencias de terceros, activos legacy y vulnerabilidades abiertas por criticidad. Esa base tiene que ligar con hallazgos supervisores previos. Si el stress test de resiliencia cibernética de 2024 dejó observaciones sobre recuperación, segmentación o gobernanza, el nuevo plan debe mostrar continuidad, no amnesia corporativa.

Después necesita un modelo de priorización. Qué se aborda primero, en qué plazo, con qué recursos y bajo qué criterio de riesgo residual. Sin eso, cualquier plan es una lista de deseos. También necesita decisiones de arquitectura, no solo de proceso. Segmentación adicional, reducción de privilegios, endurecimiento de autenticación, sustitución de componentes legacy, control de service accounts, ampliación de cobertura EDR/NDR o fortalecimiento de backups inmutables son ejemplos de medidas que el BCE puede esperar ver justificadas según el perfil de la entidad.

Otro elemento esencial es el diseño de pruebas. No basta con declarar que la recuperación está contemplada. Hay que probarla en escenarios duros: explotación rápida de vulnerabilidad expuesta, secuencia phishing más abuso de identidad, compromiso de cuenta técnica, propagación lateral con impacto en funciones críticas, indisponibilidad de un proveedor clave o corrupción de ciertos sistemas de soporte. El supervisor no espera omnisciencia, pero sí realismo.

Por último, el plan debe ser gobernable. Eso significa comité o estructura de seguimiento, reporting periódico a la alta dirección, decisiones documentadas de aceptación de riesgo y alineamiento entre primera línea, segunda línea y auditoría interna. Si auditoría interna no está ya revisando la calidad de algunas de estas capacidades, llegará tarde a la película.

Implicaciones para entidades financieras españolas: menos margen para la comodidad local

Para bancos españoles significativos bajo supervisión directa del BCE, el mensaje es inmediato y sin traducción posible: la entrega del 31 de octubre de 2026 no es opcional. Pero también afecta, de forma indirecta, a entidades menos significativas, filiales, proveedores críticos, aseguradoras con ecosistemas complejos y fintechs integradas en cadenas de suministro bancarias.

En España hay tres implicaciones prácticas adicionales.

La primera es la convivencia regulatoria. Muchas entidades ya están ocupadas aterrizando DORA de forma madura, afinando reportes de incidentes, marcos de terceros TIC y programas de pruebas. La carta del BCE no sustituye ese trabajo; lo tensiona. Obliga a identificar qué partes del despliegue DORA estaban diseñadas con ritmos demasiado lentos para amenazas habilitadas por IA.

La segunda es el problema del legacy. La banca española ha invertido mucho en digitalización, pero sigue arrastrando arquitecturas heredadas, integraciones complejas y capas de autorización que no siempre se llevan bien con el mínimo privilegio real. El BCE no lo menciona por cortesía; sí menciona “legacy replacement” como parte del enfoque defensivo. Eso es casi una confesión supervisora de que el riesgo no se resuelve solo con tooling encima de sistemas antiguos.

La tercera es el papel de proveedores. Un banco puede tener gobierno impecable sobre el papel y, aun así, depender de terceros con ciclos de parcheo, transparencia de SBOM o capacidad de respuesta muy desiguales. Para entidades españolas con ecosistemas extensos de outsourcing tecnológico, esta será una de las zonas más difíciles de demostrar con evidencia sólida antes del 31 de octubre.

Si además la entidad procesa grandes volúmenes de datos personales o presta servicios críticos apoyados en APIs y automatizaciones, la coordinación entre seguridad, resiliencia, privacidad y continuidad se vuelve ineludible. Una brecha no espera a que los equipos acuerden quién lidera la call.

La capa de identidad: el punto ciego que más rápidamente se convierte en incidente

La fuente original de Nexis empuja con claridad la dimensión de identidad, y aunque el texto tenga obvio interés comercial, en este punto no va desencaminado. Identidad no es un subtema; es una de las formas más prácticas de leer la carta del BCE.

Piensa en las seis áreas: inventario de superficie, parcheo priorizado, monitorización, gobernanza, zero trust, resiliencia. Todas mejoran o empeoran según entiendas quién puede acceder a qué, con qué privilegios, mediante qué credencial, desde qué canal y bajo qué condiciones. Si no tienes esa visibilidad, la defensa se vuelve una colección de controles parciales.

Para usuarios humanos, el terreno es conocido: recertificaciones, MFA, segregación de funciones, revisiones de privilegios, análisis de cuentas huérfanas. El problema es que buena parte del crecimiento del riesgo está en identidades no humanas: cuentas de servicio, integraciones, claves API, certificados, robots, jobs automatizados y, cada vez más, agentes o servicios con capacidad de actuar de forma semiautónoma. Muchas entidades las administran con herramientas separadas, ownership ambiguo y poca disciplina de ciclo de vida.

Eso choca de frente con la lógica del BCE. Un atacante asistido por IA buscará rutas de menor fricción. Las identidades técnicas mal gobernadas suelen ofrecerlas. Pueden tener privilegios amplios, credenciales persistentes, escasa supervisión y dependencias críticas de negocio. Son excelentes para movimiento lateral, persistencia o abuso discreto.

Desde un punto de vista de evidencias para el supervisor, una entidad gana mucha credibilidad si puede demostrar cuatro cosas: inventario razonable de identidades no humanas; propietario asignado y finalidad definida; privilegios revisados y reducidos cuando sea posible; y controles de autenticación, rotación y monitorización acordes al riesgo. No necesitas convertir esto en una religión del IAM. Necesitas impedir que se convierta en la explicación del incidente.

Lo que probablemente preguntará el supervisor después de recibir los planes

La entrega del 31 de octubre no cerrará nada. Abrirá preguntas. Y conviene anticiparlas.

Una: ¿cómo ha cambiado el banco sus prioridades a la luz de la amenaza habilitada por IA? Si el plan es idéntico al roadmap que ya existía, con algunos párrafos nuevos sobre IA, el supervisor lo verá enseguida. Dos: ¿qué hallazgos abiertos siguen pendientes y por qué? Tres: ¿qué dependencias críticas tiene el banco de terceros TIC y cómo valida su capacidad de respuesta? Cuatro: ¿qué métricas usa para demostrar avance real? Cinco: ¿qué escenarios de prueba ha ejecutado o ejecutará y con qué lecciones? Seis: ¿cómo se integra todo esto en gobierno, presupuesto y apetito de riesgo?

También puede aparecer una pregunta bastante menos cómoda: ¿qué ha decidido el banco no hacer todavía? Los supervisores experimentados saben que ningún plan serio cubre todo de golpe. A veces valoran más una renuncia explícita y bien justificada que una ambición increíble. Si una entidad reconoce que no llegará a sustituir cierto legacy en el corto plazo pero implanta segmentación, hardening, control de privilegios y compensaciones monitorizadas, la conversación puede ser más madura que la de otra entidad que promete modernizar medio banco en seis meses. Ya se sabe: el optimismo powerpointiano resiste mal el primer requerimiento de evidencias.

Mi lectura: el BCE está usando la IA para acelerar algo más grande que la IA

La tesis de fondo es sencilla. El BCE está aprovechando la presión narrativa de la IA para forzar a los bancos a corregir debilidades estructurales que ya eran conocidas: inventario deficiente, deuda técnica, mala higiene de identidades, excesiva confianza interna, parches lentos, dependencia opaca de terceros y recuperación poco ensayada. No es cinismo regulatorio; es oportunismo inteligente.

Si el supervisor hubiera enviado otra carta genérica sobre “ciberresiliencia”, muchos la habrían tratado como continuidad administrativa. Al colocar la IA como acelerador del riesgo, convierte problemas viejos en urgencias nuevas. Y hace algo políticamente hábil: no necesita esperar un nuevo reglamento para endurecer la presión. Le basta con reinterpretar expectativas supervisoras sobre controles ya exigibles.

Eso no significa que todo banco deba correr a comprar “IA defensiva” por reflejo. Sería una lectura torpe. La carta del BCE no glorifica la automatización ciega; de hecho insiste en supervisión humana. Lo que sí exige es reducir el tiempo entre visibilidad, decisión y acción. A veces eso requerirá herramientas nuevas. Otras veces requerirá algo menos excitante y mucho más útil: cerrar findings, limpiar privilegios, segmentar mejor, documentar dependencias y ensayar recuperación con escenarios que no parezcan diseñados por el departamento de comunicación.

El reloj corre hasta el 31 de octubre de 2026. Parece tiempo. No lo es tanto si el banco todavía no sabe con precisión qué expone a internet, qué cuentas técnicas concentran privilegios, qué terceros condicionan la remediación o qué hallazgos antiguos siguen sin dueño claro. La IA, en ese sentido, tiene un mérito regulatorio inesperado: ha dejado sin coartada a la lentitud organizada.

La pregunta útil para cualquier entidad significativa no es si este requerimiento del BCE es duro. Lo es. La pregunta es otra: ¿tu plan demostrará que entiendes cómo cambia la economía del ataque, o solo que sabes escribir documentos con el logo correcto? El supervisor distinguirá perfectamente entre ambas cosas.