El BCE exige a los bancos bajo su supervisión directa —las entidades denominadas «significativas»— un plan de acción frente a los ciberataques impulsados por IA. Sin embargo, no pide un documento estratégico, sino la demostración de una capacidad operativa. Este artículo explica qué se exige exactamente, dónde surgen las dificultades en la práctica y cómo aprovechar las semanas restantes.
El 7 de julio, la supervisión bancaria del BCE envió una carta a cerca de 110 entidades significativas. La consigna: presentar, antes del 31 de octubre, un plan de acción específico contra los ciberataques impulsados por IA. Que el BCE se ocupe del tema no sorprende a nadie. Lo que llama la atención es el grado de precisión alcanzado. Un simple documento estratégico ya no basta; lo que se exige es la demostración de una capacidad operativa. El ritmo de corrección de vulnerabilidades es el ejemplo más claro: donde antes tres meses parecían defendibles para cerrar una brecha, hoy se impone una respuesta en cuestión de horas. Y la responsabilidad recae en el consejo de administración.
La carta se dirigió deliberadamente a la dirección general, y no al departamento de informática. A ello se suma una advertencia de la JERS, fechada el 25 de junio, sobre los riesgos cibernéticos sistémicos vinculados a los modelos de IA; al mismo tiempo, el supervisor ha aplazado el cuestionario anual sobre riesgos informáticos. La señal es inequívoca: este tema debe figurar en la agenda del consejo de administración.
Fundamentos del plan de acción
El plan de acción no crea un nuevo corpus normativo. Precisa lo que ya exige DORA, pero con una demanda significativamente mayor de rapidez y verificabilidad. El Reglamento (UE) 2022/2554 sobre la resiliencia operativa digital es plenamente aplicable desde el 17 de enero de 2025. Estructura la resiliencia del sector financiero en torno a cinco pilares: la gestión del riesgo relacionado con las TIC, el tratamiento y la notificación de los incidentes relacionados con las TIC, las pruebas de resiliencia digital, la gestión del riesgo relacionado con terceros y el intercambio de información.
El plan de acción de ciberseguridad frente a la IA no introduce nada nuevo en este marco. Exige, eso sí, afinar tres de estos pilares bajo la presión de los ataques impulsados por IA: la gestión del riesgo TIC (¿sé exactamente qué debo proteger? ¿con qué rapidez puedo reaccionar?), las pruebas de resiliencia (¿resisten mis hipótesis bajo una carga real?) y el riesgo relacionado con terceros (¿de quién y de qué dependo?). Las entidades que ya se han tomado en serio DORA no parten de cero; las que lo han tratado como un mero ejercicio documental descubrirán ahora dónde están las carencias.
Cómo evaluará el supervisor la aplicación práctica
El equipo conjunto de supervisión (JST) competente no se limitará a leer el documento: examinará su contenido. Cuatro elementos distinguen un plan sólido de una simple declaración de intenciones:
- Medidas concretas, no principios: el plan debe indicar qué sistemas están afectados, en qué orden se abordarán y qué objetivos se aplican. Las intenciones vagas de mejora no bastan.
- Personas designadas, no solo comités: es necesario nombrar a una persona responsable del plan, con mandato real y no meramente nominal.
- Recursos asignados: presupuesto y personal comprometidos de forma visible, no solo prometidos de manera vaga.
El cuarto elemento es, a la vez, la pregunta decisiva: ¿puede demostrar lo que afirma? Aquí, demostrar significa poder aportar, a petición, tres pruebas:
- Sobre el ritmo de corrección: un análisis que muestre, para las últimas vulnerabilidades críticas publicadas, cuántas horas o días transcurrieron entre la publicación y el despliegue del parche en todo el parque. Debe presentar las cifras como una distribución y a lo largo del tiempo, con marca temporal. Una media redondeada no satisfará al supervisor. Por ejemplo: el 95 % de las CVE críticas se corrigieron en menos de 72 horas.
- Sobre la transparencia de los activos: una conciliación entre el inventario realmente detectado y su CMDB, que haga visible la diferencia. Debe mostrar cuántos terminales, servidores y cargas de trabajo en la nube existen sin figurar en ninguna lista oficial, y por qué medios se detectan estos sistemas no gestionados y obsoletos. La propia diferencia es la prueba más elocuente.
- Sobre el avance: un informe que pueda generar en poco tiempo —es decir, en minutos y a partir de una única fuente de datos—, fechado y trazable. Si el supervisor pregunta hoy, la respuesta debe estar lista, y no reunida manualmente a partir de sistemas distintos.
El denominador común: cifras con marca temporal, procedentes de una fuente fiable y reproducibles en cualquier momento.
Dónde se encuentran las dificultades en la práctica
Las exigencias parecen evidentes. Que muchas entidades corran el riesgo de tropezar no es una cuestión de voluntad, sino de estructuras asentadas con el tiempo. Se repiten cinco patrones:
- Un panorama de herramientas fragmentado: inventario, vulnerabilidades, parches e informes están repartidos entre soluciones distintas. Cada pregunta del supervisor obliga a recopilar datos cruzando fronteras entre sistemas.
- Una CMDB rezagada: la base de configuración refleja el estado objetivo, no el real. Se abre una brecha entre la realidad y la base que nadie puede cerrar en tiempo real.
- Puntos ciegos: dispositivos no gestionados, TI en la sombra y sistemas obsoletos no figuran en ninguna lista. Son, precisamente, los puntos de entrada que buscan los atacantes.
- Mundos separados entre TI y seguridad: quien detecta una vulnerabilidad no suele ser quien la corrige. Cada traspaso cuesta un tiempo que hoy escasea.
- Dependencia de la ventana de mantenimiento: cuando la IA genera exploits en cuestión de horas, los ciclos de parcheo reactivos y periódicos ya no bastan.
Además, muchas organizaciones siguen preparando manualmente las pruebas para el supervisor, con hojas de cálculo que alguien ensambla durante la noche. Esto no es repetible ni sólido, y no escala si el supervisor pregunta con poca antelación.
Tendrán éxito las organizaciones que vean este plazo no como un tedioso ejercicio de cumplimiento, sino como un catalizador para implementar la automatización y los cambios operativos pendientes desde hace tiempo.
Su hoja de ruta para las próximas semanas
En el poco tiempo que queda hasta el 31 de octubre, lo decisivo es la base operativa del plan. Estas cuatro tareas se entrelazan:
- Establezca un inventario completo. Obtenga una visión integral y en tiempo real de todos los terminales, servidores y cargas de trabajo en la nube, incluidos los sistemas no gestionados y obsoletos. Concilie el resultado con su CMDB: la diferencia es el riesgo. Solo si sabe qué opera podrá priorizar con criterio.
- Haga que la velocidad sea medible. Defina como indicador el tiempo entre la publicación de una vulnerabilidad crítica y el despliegue del parche en todo el parque (tiempo medio de corrección) y empiece a medirlo. Desvincule la medición de la ventana de mantenimiento; de lo contrario, estará midiendo su calendario, no su capacidad de reacción.
- Ponga en marcha las pruebas. Asegúrese de que el avance pueda demostrarse con un clic, a partir de una única fuente de datos, con marca temporal y listo para entregar a la JST. Un informe generado en minutos convence más que uno recopilado durante varios días.
- Ancle la responsabilidad. Designe a un responsable con mandato y presupuesto, e incluya el tema en una cadencia regular del consejo de administración, sobre la base de los mismos indicadores que utiliza el supervisor.
En la práctica, el orden es: primero, transparencia e indicadores; después, automatización y pruebas construidas sobre ellos, con la gobernanza en paralelo desde el principio. Las organizaciones que sigan este esquema llegarán al 31 de octubre con un plan y, sobre todo, con las pruebas que lo respalden.
Del plan a una realidad demostrable
Como plataforma de TI autónoma, Tanium integra inventario, vulnerabilidades, parches y pruebas en una base de datos común, siempre actualizada. Así, un agente ligero reemplaza el mosaico de herramientas fragmentadas. El resultado: visibilidad en tiempo real de todos los terminales, despliegue automatizado de parches y capacidad de respuesta autónoma. De este modo, un plan de acción creíble se traduce en una realidad operativa demostrable, capaz de superar el escrutinio del supervisor.
El plazo está fijado. La pregunta no es si puede presentar un plan, sino si es lo bastante sólido.