Qué dice exactamente la carta del BCE
El Consejo de Supervisión del BCE ha calificado la situación de "cambio estructural en el panorama de amenazas": los modelos de IA generativa —tanto en manos de atacantes como usados legítimamente para análisis de código— identifican vulnerabilidades de software a una velocidad que comprime drásticamente el tiempo entre el descubrimiento de un fallo y su explotación a escala. La carta pide a los 113 bancos significativos tres cosas concretas: seguridad por diseño en el desarrollo y despliegue de sistemas, parcheo de vulnerabilidades críticas en cuestión de días —no de meses, como sigue siendo habitual en buena parte del sector— y capacidad demostrable de aislamiento y recuperación rápida ante un incidente.
Para liberar capacidad de las entidades y del propio supervisor, el BCE aplaza a febrero de 2027 el cuestionario anual de riesgo tecnológico. No es una concesión gratuita: es una señal de que el supervisor considera este plan más urgente que el ejercicio recurrente de reporting, y que prefiere sustancia a papeleo en los próximos meses.
Por qué el destinatario de la carta importa más que el contenido
La carta no va dirigida al CISO ni al CTO. Va dirigida al CEO, y a través de él, al consejo de administración. Esto no es un matiz formal: convierte la ciberseguridad frente a riesgos amplificados por IA en una responsabilidad de gobierno corporativo, exigible en los mismos términos que la solvencia o la gestión de capital. El precedente inmediato es DORA, que ya obliga al órgano de dirección a aprobar y revisar la estrategia de resiliencia digital — pero la carta de Buch va un paso más allá al señalar explícitamente la IA como vector de riesgo diferenciado, no como una categoría más dentro del riesgo tecnológico genérico.
Para un CISO, esto es una palanca: la carta convierte en mandato del consejo lo que hasta ahora era, en la mayoría de entidades, una prioridad defendida cuesta abajo en el comité de riesgos. Úsala para conseguir presupuesto y prioridad, no solo para redactar el plan.
La ventana CVE-explotación ya no se mide en semanas
El argumento técnico del BCE no es retórica regulatoria. Lo vimos de forma directa con el gusano Miasma, que comprometió 73 repositorios de Microsoft en GitHub explotando un punto de entrada en una cadena de suministro de software que muchas organizaciones seguían tratando como entorno de confianza implícita. La combinación de herramientas de IA capaces de analizar código a gran velocidad —tanto para defensa como para ataque— y un ecosistema de dependencias cada vez más interconectado reduce el tiempo disponible entre la publicación de un CVE y su explotación masiva a un margen que un ciclo de parcheo trimestral no puede cubrir.
El test real que el BCE está pidiendo: si mañana se publica un CVE crítico en un componente que usas en producción, ¿sabes en cuántos sistemas está desplegado sin consultar una hoja de cálculo, y puedes parchearlo en días? Si la respuesta requiere una reunión de coordinación entre tres equipos, tu ciclo de parcheo no está a la altura de lo que el supervisor va a exigir por escrito en octubre.
Los tres bloques que debería tener el plan — y el orden en que construirlos
Automatización de la respuesta: la pieza que ya está madurando
El aislamiento automático de sistemas comprometidos sin intervención humana inicial —una capacidad que Microsoft Defender for Endpoint está llevando a producción este mismo año— es precisamente el tipo de control que convierte "capacidad de aislamiento y recuperación rápida" de frase de la carta del BCE en métrica operativa medible. El tiempo de contención, que en muchas organizaciones sigue siendo de horas o días, es el indicador que un supervisor exigente va a pedir ver con datos, no con narrativa. En los programas de dimensionamiento de SOC con Microsoft Sentinel en los que hemos trabajado, reducir el MTTD de 72 horas a menos de 4 no fue una mejora incremental — fue rediseñar la priorización de reglas por táctica MITRE ATT&CK y automatizar la respuesta de primer nivel sin perder el juicio humano en las decisiones de mayor impacto.
Calendario práctico hasta el 31 de octubre
El error más caro: redactar un plan bonito para el 31 de octubre sin cambiar el proceso subyacente. Un supervisor que ya ha visto docenas de planes de contingencia de DORA sabe distinguir un documento de un proceso operativo. Si el plan describe un ciclo de parcheo de días pero tu histórico de los últimos seis meses muestra semanas, esa discrepancia es exactamente lo que un inspector va a buscar primero.