La advertencia de Canadá sobre Claude Mythos deja una lección incómoda para la banca europea: la IA ofensiva ya es un problema de resiliencia

La banca lleva años hablando de resiliencia como si fuera un asunto de procesos, comités y cuadros de mando. Hasta que aparece una tecnología que comprime el tiempo de ataque y deja una pregunta bastante menos cómoda: ¿sigue sirviendo el ritmo de gobierno, priorización y remediación que hoy dan por bueno los marcos internos? Ahí es donde la discusión sobre inteligencia artificial deja de ser un debate de laboratorio y se convierte en un problema regulatorio de primer orden.

Ese es el punto de fondo. No hace falta adornarlo con reuniones misteriosas ni con anécdotas de pasillo para entender su alcance. Si la capacidad ofensiva se acelera, la distancia entre identificar una debilidad y explotarla puede reducirse. Y cuando ese margen se estrecha, las entidades reguladas no solo tienen un problema técnico: tienen un problema de gobernanza, de terceros, de priorización y, en algunos casos, de notificación.

La cuestión no es si la IA “cambiará todo”, esa frase ya se ha convertido en ruido. La cuestión útil es otra: qué parte del edificio regulatorio actual aguanta bien esta presión y qué parte empieza a enseñar costuras. DORA, NIS2 y GDPR no fueron redactados como normas “sobre IA ofensiva”. Pero sí contienen obligaciones suficientemente concretas como para obligar a las entidades a revisar cómo gobiernan el riesgo, cómo gestionan vulnerabilidades, cómo controlan a sus proveedores y cómo responden a incidentes cuando la velocidad del ataque deja de jugar a su favor.

El verdadero problema no es la IA; es el tiempo

Buena parte de la conversación pública sobre IA aplicada a ciberseguridad se queda en una obviedad: también servirá para defender. Cierto. Y también irrelevante si lo que uno necesita decidir hoy es si su modelo de control soporta una reducción drástica del tiempo entre exposición, descubrimiento y explotación. Ahí está el quid.

La mayoría de las grandes entidades financieras ya dispone de procesos de gestión de vulnerabilidades, inventarios de activos, programas de pruebas, segmentación y mecanismos de escalado. Sobre el papel, el edificio existe. El problema aparece cuando esos controles se han diseñado para un entorno en el que la fricción operativa del atacante era mayor y en el que el volumen de superficie expuesta podía absorberse con ciclos de revisión relativamente estables.

Si cambian la velocidad y la escala, el defecto deja de estar en la existencia formal del control y pasa a estar en su cadencia. Un comité mensual puede seguir siendo impecable desde el punto de vista administrativo y resultar tácticamente lento. Un criterio de priorización construido casi exclusivamente sobre puntuaciones de severidad puede seguir siendo ordenado y, al mismo tiempo, insuficiente para decidir qué corregir primero cuando lo decisivo no es solo la gravedad abstracta, sino la exposición real del activo, la facilidad de explotación, la dependencia de terceros y el impacto operativo sobre funciones críticas.

Eso no exige inventar plazos mágicos ni dogmas técnicos nuevos. Exige reconocer algo más prosaico: cuando una entidad tarda demasiado en pasar de la identificación a la remediación o a la contención, el riesgo no se queda quieto esperando al siguiente comité.

DORA no habla de IA ofensiva, pero sí habla de responsabilidad real

Conviene limpiar una confusión habitual. DORA no necesita mencionar una tecnología concreta para ser relevante aquí. Su lógica regulatoria es otra: obligar a las entidades financieras a tratar el riesgo de TIC como un asunto de negocio y de órgano de dirección, no como un problema delegable al CISO con copia al comité de riesgos.

El punto de partida está en el artículo 5 de DORA, que atribuye al órgano de dirección la responsabilidad última de gestionar el riesgo de TIC de la entidad. La arquitectura más detallada del marco de gestión del riesgo de TIC se desarrolla después, en particular en los artículos 6 y siguientes. La precisión importa porque demasiadas organizaciones citan el artículo 5 como si fuera una consigna genérica de “tone from the top”, cuando en realidad su efecto combinado con el resto del capítulo es mucho más incómodo: obliga a demostrar que la dirección aprueba, supervisa y asume de verdad decisiones que afectan a la resiliencia operativa.

Traducido a un escenario de mayor automatización ofensiva, la pregunta regulatoria ya no es si el equipo técnico “está encima”. La pregunta es si el órgano de dirección puede acreditar que entiende qué funciones críticas dependen de qué activos, qué concentraciones con terceros elevan el riesgo, qué debilidades exigen una respuesta acelerada y qué tolerancias de interrupción son aceptables para la entidad. Si no puede, DORA deja de ser un texto bonito en la intranet y se convierte en un problema de gobernanza.

El artículo 6 exige un marco interno de gobernanza y control que garantice una gestión eficaz y prudente del riesgo de TIC. El artículo 8 obliga a identificar, clasificar y documentar adecuadamente todas las funciones respaldadas por TIC, así como los activos de TIC y sus interdependencias. El artículo 9 entra en protección y prevención. El 10 se centra en detección. El 11 y el 12 en respuesta, recuperación y continuidad. Leído en conjunto, el mensaje es bastante menos burocrático de lo que muchos quisieran: si no sabes con precisión qué soporta tus servicios críticos, no puedes priorizar bien; si no priorizas bien, tu resiliencia es más declarativa que real.

Hay además una ironía regulatoria interesante. Durante años, algunas entidades han tratado la resiliencia como un ejercicio de documentación orientado a satisfacer supervisores. DORA premia justo lo contrario: trazabilidad operativa. No pide presentaciones más elegantes. Pide que puedas enlazar funciones críticas, activos, terceros, escenarios de fallo y decisiones de remediación con una lógica defendible.

La gestión de vulnerabilidades ya no puede vivirse como un proceso aislado

Muchos programas de vulnerabilidades siguen funcionando como una cadena lineal: identificar, puntuar, asignar, corregir, cerrar. Ordenado, sí. Suficiente, no siempre. El problema es pensar que ese flujo puede operar de forma separada del contexto operacional y regulatorio.

Ni DORA ni NIS2 te dicen que uses un sistema concreto de scoring. Tampoco bendicen la comodidad de una única métrica abstracta como criterio suficiente. Lo que sí exigen, cada una a su manera, es una gestión del riesgo basada en impacto, proporcionalidad y medidas apropiadas. NIS2, en su 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 se planteen para la seguridad de las redes y sistemas de información. Entre esas medidas, el propio artículo 21 menciona 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, y la evaluación de la eficacia de las medidas de gestión del riesgo.

Eso importa por una razón muy concreta: un programa de parcheo o mitigación no puede justificarse ya solo con una taxonomía interna de criticidad despegada del servicio afectado. Si una vulnerabilidad afecta a un activo expuesto, vinculado a una función crítica o integrado con un proveedor cuya sustitución es compleja, el análisis de prioridad cambia. Y debe cambiar antes de que lo haga el supervisor por ti.

No hace falta sostener que cualquier ventana de remediación concreta sea “una invitación abierta” para entender el punto. Basta con algo más sobrio y más defendible: los plazos internos de corrección deben revisarse a la luz de la exposición real, la criticidad del servicio, la explotabilidad conocida y la capacidad de contención disponible. Un SLA uniforme puede ser cómodo para el cuadro de mando. No necesariamente para la resiliencia.

Aquí tropiezan muchas entidades maduras. Tienen métricas. Tienen excepciones. Tienen reportes. Pero siguen sin integrar bien cuatro variables que deberían convivir en la misma decisión: criticidad del negocio, exposición técnica, dependencia de terceros y capacidad operativa para aislar o compensar el riesgo. Cuando esas piezas viven en equipos distintos, la organización reacciona tarde aunque cada equipo cumpla su parte. El resultado es un fallo de sistema, no de personas.

Terceros ICT: la parte de DORA que muchos siguen subestimando

Si hay una zona del reglamento que todavía se trata con una mezcla de resignación y autoengaño, es la de terceros ICT. El razonamiento perezoso suele ser este: “sí, dependemos mucho de proveedores, pero tenemos contratos, due diligence y un registro”. Bien. Ahora viene la parte incómoda.

DORA dedica su capítulo V a la gestión del riesgo asociado a terceros prestadores de servicios de TIC. El artículo 28 obliga a gestionar ese riesgo como parte integrante del marco de riesgo de TIC y sobre la base del principio de proporcionalidad, teniendo en cuenta la naturaleza, escala, complejidad e importancia de las dependencias. El artículo 30 detalla elementos contractuales clave. El 31 exige mantener un registro de información sobre todos los acuerdos contractuales relativos al uso de servicios de TIC prestados por terceros. Y el 35 abre la puerta al marco de supervisión de proveedores críticos.

¿Por qué pesa tanto esto en un debate sobre capacidades ofensivas aceleradas? Porque una parte material de la superficie que puede ser explorada, explotada o interrumpida no reside ya exclusivamente en infraestructura propia. Está repartida entre proveedores cloud, software empresarial, servicios gestionados, componentes de código, plataformas de autenticación, herramientas de observabilidad y un largo etcétera que nadie menciona en los comités estratégicos con el detalle que merecen.

Si una entidad no puede responder con rapidez a preguntas básicas sobre sus terceros —qué servicios soportan, qué activos tocan, qué subcontrataciones existen, qué dependencia funcional generan y qué alternativas reales hay— no tiene un problema de procurement. Tiene un problema de resiliencia regulada.

Y aquí DORA es menos amable de lo que a veces se vende. No basta con exigir “cumplimiento normativo” en el contrato. Hay que alinear el control contractual con la criticidad del servicio, los derechos de acceso, auditoría e inspección, los requisitos de notificación, las condiciones de terminación y las estrategias de salida. Si el riesgo se acelera, la pregunta práctica es brutalmente simple: ¿puedes actuar con suficiente rapidez cuando el punto débil está en una capa que no operas tú? Si la respuesta depende de abrir un ticket y esperar, ya tienes parte del diagnóstico.

Notificación de incidentes: cuando el reloj regulatorio corre a la vez que el técnico

La aceleración del riesgo no afecta solo a la prevención. También tensiona el modelo de detección, clasificación y notificación. DORA, en sus artículos 17 a 23, construye un régimen armonizado de gestión, clasificación y notificación de incidentes graves relacionados con las TIC. El detalle técnico se completa mediante normas técnicas de regulación y de ejecución, pero la lógica central ya está en el reglamento: la entidad debe detectar, gestionar, registrar, clasificar y notificar incidentes significativos con criterios consistentes.

GDPR añade otra capa cuando el incidente afecta a datos personales. El artículo 33 obliga al responsable del tratamiento a notificar a la autoridad de control una violación de seguridad de los datos personales sin dilación indebida y, de ser posible, a más tardar 72 horas después de haber tenido constancia de ella, salvo que sea improbable que la violación entrañe un riesgo para los derechos y libertades de las personas físicas. El artículo 34 regula la comunicación al interesado cuando ese riesgo sea alto.

La fricción real está en la intersección. Un mismo incidente puede activar, según su naturaleza y efectos, obligaciones bajo DORA, GDPR y, para determinadas entidades, NIS2. Sobre el papel, todo el mundo sabe esto. En la práctica, muchas organizaciones siguen separando los circuitos de ciberincidente, incidente operativo, brecha de datos y comunicación regulatoria como si fueran compartimentos estancos. Esa fragmentación sale cara cuando el tiempo aprieta.

El debate serio no es si conviene tener más plantillas de notificación. El debate serio es si la entidad ha resuelto tres cuestiones previas:

• Clasificación coherente: que el equipo técnico, el jurídico, privacidad, continuidad y negocio compartan criterios mínimos para decidir cuándo un evento pasa de anomalía a incidente relevante.
• Trazabilidad de impacto: que pueda enlazarse el evento con funciones críticas, datos afectados, terceros implicados y alcance geográfico sin reconstruir media arquitectura a mano.
• Gobierno de decisión: que esté claro quién decide, con qué umbral y con qué respaldo documental.

Cuando eso falta, el problema no es solo llegar tarde al supervisor. Es tomar decisiones inconsistentes en las primeras horas, que son precisamente las más caras de corregir después.

NIS2 endurece la conversación: menos voluntarismo, más responsabilidad

NIS2 ha elevado el listón de gobernanza de ciberseguridad para un conjunto amplio de sectores, incluido el financiero en ámbitos que no quedan absorbidos por lex specialis. El artículo 20 atribuye a los órganos de dirección la aprobación y supervisión de las medidas de gestión del riesgo de ciberseguridad, así como la responsabilidad por su incumplimiento. No es una cláusula decorativa. Es un recordatorio de que el regulador europeo se ha cansado del “esto lo lleva IT”.

El artículo 21, además, no se limita a pedir controles genéricos. Exige medidas apropiadas y proporcionadas que incluyan análisis de riesgos, gestión de incidentes, continuidad, seguridad de la cadena de suministro y prácticas básicas de ciberhigiene, entre otras. Leído junto con DORA, el mensaje para las entidades es bastante claro: el consejo no necesita saber explotar una vulnerabilidad, pero sí debe entender las decisiones estructurales que determinan si la entidad puede resistir, responder y recuperarse.

Hay una tentación muy extendida en compliance: tratar DORA y NIS2 como programas paralelos porque tienen equipos patrocinadores distintos. Error. Aunque sus ámbitos y mecanismos no sean idénticos, ambos empujan hacia el mismo destino: gobierno demostrable, gestión basada en riesgo, control de terceros y responsabilidad real del órgano de dirección. Si tu organización ha montado dos trenes documentales para llegar a esa misma estación, seguramente está gastando energía donde no toca.

La lectura útil es convergente. Usa DORA para estructurar el modelo operativo y NIS2 para reforzar la disciplina transversal de ciberseguridad allí donde el perímetro y la organización lo exijan. Lo contrario produce el clásico monstruo regulatorio: doble inventario, doble comité, doble reporting y media capacidad operativa.

La obsesión por la severidad puede esconder el riesgo que de verdad importa

Durante años, la industria ha buscado consuelo en sistemas de puntuación que permiten ordenar miles de hallazgos con apariencia de objetividad. Tiene lógica. Cuando el volumen desborda, una cifra simplifica. El problema aparece cuando esa cifra se convierte en sustituto del juicio.

Una puntuación de severidad puede ser una entrada útil. No una decisión acabada. El regulador, por cierto, nunca te ha dicho que confundas una con la otra. DORA habla de riesgo de TIC, funciones críticas, activos, protección, detección, respuesta y recuperación. NIS2 habla de medidas apropiadas y proporcionadas. Ninguna de las dos normas dice que el riesgo pueda reducirse a una taxonomía descontextualizada.

Por eso el debate práctico no debería centrarse en defender una métrica concreta como si fuera ortodoxia. Debería centrarse en si la entidad es capaz de combinar, al menos, estos elementos en una sola priorización operativa: exposición del activo, criticidad del proceso o servicio afectado, disponibilidad de mitigaciones, dependencia de terceros, facilidad de despliegue de la corrección y consecuencias de negocio si el activo se aísla o falla.

Suena menos elegante que enseñar un panel lleno de colores. También sirve más.

La señal de madurez no es tener una matriz perfecta. Es poder justificar por qué una debilidad aparentemente menos severa recibe atención antes que otra teóricamente más alta. Si tu entidad no puede explicar esa decisión sin refugiarse en una puntuación automática, todavía está gestionando inventario, no riesgo.

Qué deberían revisar ahora los bancos y otras entidades financieras

No se trata de rehacer desde cero el programa de resiliencia. Se trata de examinar si algunos supuestos operativos han caducado. Para una entidad sujeta a DORA, las preguntas útiles son bastante concretas y nada glamourosas.

1. Inventario y mapeo de dependencias

El artículo 8 de DORA no está para decorar auditorías. Si la entidad no puede mapear con precisión funciones, activos, flujos y terceros, cualquier priorización posterior será parcial. La prueba no es si existe CMDB. La prueba es si sirve para decidir.

2. Criterios de priorización de vulnerabilidades y exposiciones

Revisar no significa cambiar de herramienta cada trimestre. Significa verificar si los criterios incorporan exposición externa, criticidad de negocio, compensating controls, dependencia de terceros y facilidad de explotación conocida. Si la priorización descansa casi por completo en una severidad abstracta, toca corregir el modelo.

3. Escalado al órgano de dirección

El artículo 5 de DORA y el artículo 20 de NIS2 empujan en la misma dirección: el órgano de dirección debe supervisar y asumir responsabilidad. Eso obliga a rediseñar la información que recibe. Menos catálogo técnico, más decisiones de riesgo: qué servicios están más expuestos, qué concentraciones con terceros preocupan, qué excepciones siguen abiertas y qué impacto tendría un fallo relevante.

4. Preparación contractual y operativa con terceros

El capítulo V de DORA exige mucho más que una due diligence inicial. La entidad debería poder identificar qué servicios de terceros soportan funciones críticas o importantes, qué derechos contractuales tiene en caso de incidente, qué plazos de notificación se han pactado y qué estrategia de salida existe si la relación deja de ser viable.

5. Integración entre ciber, privacidad, continuidad y cumplimiento

Si la organización sigue tratando un incidente técnico, una interrupción operativa y una posible brecha de datos como eventos separados hasta fases tardías, corre con lastre. GDPR artículo 33 no espera a que la casa termine de ordenar sus carpetas internas. DORA tampoco.

La objeción razonable: no todo cambia, y no conviene caer en el pánico regulatorio

Conviene poner un freno a la retórica apocalíptica. No, la aparición de nuevas capacidades técnicas no invalida automáticamente todos los programas de seguridad existentes. Tampoco convierte cualquier vulnerabilidad en una catástrofe inminente. Las organizaciones maduras ya cuentan con segmentación, hardening, gestión de accesos, detección, copias de seguridad, pruebas de continuidad y procedimientos de crisis que siguen siendo decisivos.

Además, ni DORA ni NIS2 piden omnisciencia. Piden proporcionalidad, gobernanza y medidas adecuadas. Eso deja espacio para decisiones razonadas, para enfoques basados en riesgo y para priorizar recursos donde más impacto produce hacerlo.

La objeción, sin embargo, tiene un límite. No puede usarse como coartada para conservar ritmos internos heredados sin reexaminar si siguen encajando con el entorno de amenaza y con la dependencia creciente de terceros. El supervisor no exige perfección. Sí exigirá, cada vez más, que la entidad pueda demostrar por qué su modelo era razonable, qué supuestos utilizó y cómo adaptó sus controles cuando esos supuestos cambiaron.

Ese matiz es crucial. La cuestión no es prometer invulnerabilidad. La cuestión es demostrar diligencia defendible.

Mi lectura: el regulador europeo ya ha dejado el terreno preparado, pero muchas entidades siguen leyendo en modo burocrático

La gran paradoja es que buena parte de las respuestas regulatorias necesarias ya están escritas. No como una “ley sobre IA ofensiva”, que sería un titular estupendo y probablemente una norma regular. Están escritas en obligaciones mucho más terrenales: gobierno del riesgo de TIC, identificación de activos y funciones, pruebas, respuesta, continuidad, gestión de terceros, clasificación de incidentes y responsabilidad del órgano de dirección.

Por eso el debate interesante no es qué nueva regulación hace falta mañana, sino qué entidades están interpretando DORA, NIS2 y GDPR con suficiente densidad operativa hoy. Algunas lo están haciendo. Otras siguen confundiendo cumplimiento con producción documental. Y eso funciona hasta que aparece un incidente serio, un supervisor incisivo o ambas cosas a la vez, que es la combinación favorita de este sector.

La lectura burocrática de DORA dice: hay que tener políticas, registros, marcos y evidencias. Correcto, pero insuficiente. La lectura inteligente dice algo más exigente: hay que ser capaz de tomar mejores decisiones más deprisa, con mejor información y con responsabilidad clara. Lo demás son carpetas.

También conviene abandonar una comodidad semántica bastante instalada. Cuando muchas entidades dicen que tienen “visibilidad”, en realidad quieren decir que tienen herramientas. No es lo mismo. Visibilidad útil, a efectos de resiliencia regulada, es poder conectar señal técnica, servicio afectado, dueño de negocio, terceros implicados, impacto potencial y obligación normativa. Si no puedes hacer esa unión sin varias reuniones de emergencia, lo que tienes es telemetría dispersa.

Qué hacer el lunes, no el año que viene

La tentación natural es mandar este asunto a un programa estratégico con horizonte de varios trimestres. Mala idea si eso sirve para retrasar decisiones sencillas. Hay al menos cuatro movimientos inmediatos que una entidad puede ejecutar sin esperar a una gran transformación.

• Revisar los criterios de prioridad para que no dependan solo de una severidad genérica y recojan exposición, criticidad de servicio, terceros y capacidad de mitigación.
• Escalar al órgano de dirección un mapa reducido de dependencias críticas, con especial foco en servicios de terceros que soportan funciones importantes y en excepciones abiertas con impacto relevante.
• Probar el circuito de clasificación y notificación entre ciber, legal, privacidad, continuidad y negocio, usando un escenario que combine interrupción operativa y posible afectación de datos personales.
• Comprobar si los contratos clave permiten actuar con acceso, auditoría, notificación y salida razonables cuando el problema nace o se materializa en un proveedor de TIC.

No hace falta convertir esto en una epopeya metodológica. Hace falta someter el modelo actual a una pregunta bastante básica: si mañana una debilidad relevante afectara a un servicio crítico con dependencia de terceros, ¿la entidad sabría decidir con rapidez qué aislar, qué corregir, a quién informar y cómo justificarlo ante supervisor y consejo? Si la respuesta es “depende”, ya sabes por dónde empezar.

La conclusión incómoda

La conversación sobre IA en ciberseguridad suele desviarse hacia dos extremos igual de estériles: el entusiasmo publicitario y el alarmismo teatral. Ninguno ayuda a una entidad regulada que necesita priorizar trabajo real. Lo útil es reconocer que la presión sobre el tiempo de respuesta, la calidad del inventario, la gobernanza de terceros y la capacidad de decisión transversal ya no es un asunto secundario.

DORA, NIS2 y GDPR no ofrecen una receta mágica. Ofrecen algo más serio: un marco para exigir disciplina donde antes cabía bastante folclore corporativo. El órgano de dirección tiene responsabilidad última sobre la gestión del riesgo de TIC bajo DORA artículo 5, desarrollada operativamente en los artículos 6 y siguientes. NIS2 artículos 20 y 21 endurecen la rendición de cuentas y las medidas mínimas de gestión del riesgo. GDPR artículos 33 y 34 recuerdan que, cuando hay datos personales de por medio, el reloj regulatorio corre de verdad.

La pregunta final no es si la IA hará a los atacantes más eficaces en términos generales. La pregunta útil para una entidad financiera es mucho más terrenal y, por eso, mucho más peligrosa: ¿tu modelo de resiliencia está diseñado para decidir a la velocidad que exige tu dependencia tecnológica real? Si no, el problema no es futurista. Ya es de cumplimiento. Y bastante prosaico, por cierto.