Deepfakes y fraude con IA en banca: el problema ya no es la tecnología, sino tus controles

La gobernanza en DORA no se arregla poniendo al consejo en una diapositiva y llamándolo “oversight”. El reglamento va bastante más lejos: coloca la responsabilidad en el órgano de dirección y obliga a que la gestión del riesgo relacionado con las TIC esté integrada en el sistema de control interno, con responsabilidades definidas, seguimiento real y capacidad de corregir fallos. La diferencia no es semántica. Es la distancia entre un documento bonito y un expediente que resiste una inspección.

Ese matiz importa ahora porque muchas entidades siguen abordando DORA como si fuera un proyecto tecnológico con barniz normativo. No lo es. La arquitectura del reglamento deja claro que la resiliencia operativa digital es un asunto de gobierno corporativo, de gestión del riesgo y de rendición de cuentas. Si tu entidad todavía trata las incidencias TIC, los proveedores cloud y las pruebas de resiliencia como piezas separadas, el problema no es de formato. Es de diseño.

Lo que sí dice DORA sobre gobernanza, sin adornos ni artículos mal citados

La base está en el capítulo II del Reglamento (UE) 2022/2554. El art. 5 de DORA, sobre gobernanza y organización, atribuye al órgano de dirección la responsabilidad última de definir, aprobar, supervisar y responder por la aplicación de todas las disposiciones relativas al marco de gestión del riesgo relacionado con las TIC. También exige que ese órgano establezca mecanismos que garanticen una gestión eficaz y prudente del riesgo y apruebe políticas destinadas a asegurar la disponibilidad, autenticidad, integridad y confidencialidad de los datos.

Eso ya desmonta una lectura demasiado cómoda que todavía circula en el mercado: la idea de que DORA solo pide “implicación” del consejo. No. Pide responsabilidad. Y cuando un reglamento europeo usa ese verbo, lo normal es que el supervisor quiera ver trazabilidad documental, decisiones adoptadas y supervisión efectiva, no solo awareness sessions con café y croissants.

Junto a ese artículo, el art. 6 de DORA exige a las entidades financieras disponer de un marco interno sólido, exhaustivo y bien documentado para la gestión del riesgo relacionado con las TIC, como parte del sistema general de gestión del riesgo. Aquí conviene ser precisos, porque la precisión jurídica ahorra dolores de cabeza: el eje no está en discutir si una frase de mercado resume mejor el art. 5 o el art. 6, sino en entender que ambos artículos funcionan juntos. El art. 5 coloca la responsabilidad en la cúspide; el art. 6 obliga a traducir esa responsabilidad en un marco interno documentado y operativo.

Ese encaje es mucho más útil que la obsesión por citar un único artículo como si resolviera toda la gobernanza. No la resuelve. DORA reparte la obligación entre gobierno, marco de riesgo, protección, detección, respuesta, recuperación, aprendizaje, gestión de terceros y pruebas. Quien reduzca eso a una política corporativa anual está leyendo el reglamento como quien mira un plano del metro y cree que ya conoce la ciudad.

El error más habitual: confundir “responsabilidad última” con supervisión simbólica

El problema práctico no suele ser la ausencia de documentos. Suele ser otro: la entidad tiene políticas, comités, matrices RACI y un repositorio impecable, pero el órgano de dirección no puede demostrar que entiende qué riesgos TIC son materiales, qué dependencias externas concentran riesgo sistémico o qué tolerancias operativas ha aprobado realmente.

DORA no exige omnisciencia técnica al consejo. Exige algo más incómodo y bastante más razonable: que el órgano de dirección dirija y controle. El art. 5 lo conecta con la responsabilidad por la aplicación del marco de gestión del riesgo TIC. Y el resto del capítulo II despliega lo que ese marco debe cubrir. Si una entidad no puede enlazar decisiones del órgano de dirección con políticas, procedimientos, clasificación de activos, gestión de incidentes, continuidad, backups, recuperación y gestión de terceros, tiene un vacío de gobernanza aunque tenga un PowerPoint de 80 páginas diciendo lo contrario.

Aquí aparece una de las fricciones más serias del mercado. Muchas primeras líneas de negocio siguen viendo el riesgo TIC como una materia de CISO, de operaciones o de cumplimiento. DORA rompe esa comodidad. La resiliencia operativa digital pasa a ser una obligación transversal que toca estrategia, presupuesto, outsourcing, apetito al riesgo, continuidad de negocio y capacidad de respuesta. Traducido: si el órgano de dirección no pregunta, no prioriza y no decide, el cumplimiento cojea desde arriba.

Qué debe poder acreditar una entidad, sin prometer más de lo que el texto dice

Conviene evitar listas grandilocuentes no ancladas al reglamento. Lo que sí puede afirmarse con seguridad es que DORA exige un marco documentado de gestión del riesgo TIC y desarrolla obligaciones concretas a lo largo del capítulo II y de otras partes del reglamento. En la práctica, una entidad deberá poder acreditar, como mínimo, que ha trasladado esas obligaciones a políticas, procedimientos, funciones y controles verificables.

Por ejemplo, el art. 8 obliga a identificar, clasificar y documentar adecuadamente todas las funciones, funciones de apoyo, activos de información y activos TIC que sustenten esas funciones, así como sus funciones y dependencias. El art. 9 se centra en la protección y prevención, incluida la necesidad de mantener, actualizar y probar medidas, herramientas y políticas de seguridad TIC. El art. 10 aborda la detección de actividades anómalas. El art. 11 exige capacidades de respuesta y recuperación para minimizar el impacto de incidentes, mediante políticas y procedimientos de continuidad, restauración y recuperación. El art. 13 se ocupa de la comunicación relacionada con incidentes graves. No hace falta adornarlo: el reglamento ya es suficientemente exigente por sí solo.

La consecuencia operativa es evidente. Si el supervisor pregunta cómo se supervisa el riesgo TIC, la respuesta no puede quedarse en “tenemos una política aprobada”. Debería existir una cadena de evidencia entre el marco aprobado, la asignación de responsabilidades, la clasificación de activos y procesos críticos, los mecanismos de detección, la gestión y escalado de incidentes, las pruebas, la remediación y la revisión del marco. No hace falta inventarse una lista cerrada para entenderlo; basta con leer el reglamento como un sistema y no como una colección de PDFs.

La tentación de copiar NIST o ISO sin hacer el trabajo de traducción regulatoria

Muchísimas entidades han tomado marcos conocidos —NIST CSF, ISO/IEC 27001, COBIT, incluso esquemas internos de control de matriz— y han intentado “mapear” DORA encima. La idea no es mala. El problema llega cuando el mapeo se convierte en sustituto del análisis jurídico y operativo.

DORA dialoga bien con esos marcos, pero no se agota en ellos. Su lógica es regulatoria y supervisora. Pide resultados demostrables en un perímetro sectorial concreto, con obligaciones expresas sobre incidentes graves, pruebas de resiliencia operativa digital, riesgo derivado de terceros proveedores de servicios TIC y gobernanza reforzada. Un crosswalk bonito ayuda; no exime.

Esto se ve especialmente en la manida lista de capacidades tipo “identificar, proteger, detectar, responder, recuperar”. Esa estructura recuerda de inmediato a NIST, y de hecho sirve como brújula conceptual. Pero cuando se presenta como si fuera la formulación exacta exigida por DORA, se entra en terreno resbaladizo. Lo más honesto —y más útil para quien implementa— es explicar que el reglamento cubre esas áreas mediante obligaciones distribuidas en varios artículos, no vender una taxonomía de mercado como si fuera una cita literal del texto legal.

La ironía aquí es bastante transparente: algunas entidades están tan obsesionadas con tener un “mapping” perfecto que olvidan algo más básico, que es gobernar el riesgo de verdad. El regulador no puntúa la elegancia del Excel. Puntúa si la entidad resiste incidentes, entiende sus dependencias críticas y puede seguir prestando servicios.

Gobernanza no es solo consejo: también es estructura, roles y conflicto de prioridades

Cuando se habla de gobernanza en DORA, demasiadas conversaciones se quedan en el consejo de administración. Error parcial. Sí, el art. 5 pone la responsabilidad última en el órgano de dirección. Pero la eficacia del modelo depende de cómo se despliegan las responsabilidades por debajo: segunda línea, seguridad de la información, operaciones, continuidad, procurement, legal, compliance, auditoría interna y negocio.

El reglamento no permite que la entidad trate el riesgo TIC como un silo. El art. 6 lo integra en el sistema general de gestión del riesgo. Ese detalle tiene consecuencias políticas dentro de la organización, no solo documentales. Significa que las decisiones sobre arquitectura tecnológica, dependencia de un proveedor, tolerancia a interrupciones, backlog de remediación o priorización presupuestaria dejan de ser meros debates operativos. Se convierten en cuestiones de riesgo empresarial con impacto regulatorio.

Y aquí aflora una tensión muy concreta. Negocio quiere velocidad. Seguridad quiere control. Compras quiere eficiencia. Legal quiere contratos blindados. Compliance quiere evidencia. Tecnología quiere que no le cambien las prioridades cada quince días. DORA no elimina ese conflicto; lo institucionaliza y obliga a gobernarlo. Si la entidad no tiene un foro claro para decidir qué riesgo acepta, quién escala qué problema y cómo se resuelven las excepciones, el marco existe en papel, pero no en la práctica.

La pieza incómoda: terceros TIC y la ficción de que el riesgo acaba en el contrato

Una gobernanza DORA creíble se rompe enseguida si la gestión de terceros sigue anclada en la lógica clásica de outsourcing: due diligence inicial, cláusulas contractuales, revisión anual y a otra cosa. El reglamento aprieta mucho más. El art. 28 establece los principios clave para una gestión sólida del riesgo derivado de terceros proveedores de servicios TIC, y exige que ese riesgo forme parte integrante del marco de gestión del riesgo relacionado con las TIC de la entidad.

Eso no es una nota a pie de página. Es un cambio de diseño. Si una entidad depende de un proveedor cloud, de un procesador de pagos, de un MSSP o de un proveedor SaaS para funciones críticas o importantes, esa dependencia no puede quedarse en procurement. Debe entrar en la gobernanza del riesgo, con inventario, clasificación, evaluación y supervisión acordes con la criticidad del servicio.

La parte irritante —porque lo es, seamos honestos— es que muchas entidades no controlan del todo sus cadenas de subcontratación, ni tienen visibilidad madura sobre concentraciones de riesgo, salidas ordenadas o pruebas realistas de contingencia. DORA no inventa ese problema. Lo hace imposible de seguir ignorando.

Y no, no basta con decir que el contrato cumple. El contrato es una herramienta, no una prueba automática de resiliencia. Si la entidad no sabe qué función crítica depende de qué tercero, qué datos circulan por ahí, cómo se activa una sustitución o cómo se coordina un incidente grave con ese proveedor, la gobernanza está coja por definición.

El vínculo con incidentes: donde la gobernanza deja de ser teórica

La mejor forma de distinguir entre gobernanza real y gobernanza decorativa es mirar qué pasa cuando algo falla. El capítulo III de DORA sobre gestión, clasificación y notificación de incidentes relacionados con las TIC convierte la teoría en práctica forense. Una entidad que ha gobernado bien su riesgo debería saber detectar incidentes, clasificarlos, escalar internamente, preservar evidencia, coordinar comunicación y aprender de lo ocurrido.

El art. 17 exige a las entidades definir, establecer y aplicar un proceso de gestión de incidentes relacionados con las TIC para detectar, gestionar y notificar esos incidentes. El art. 18 entra en la clasificación de incidentes y ciberamenazas significativas con base en criterios y umbrales. Si la gobernanza previa era superficial, aquí se nota enseguida: equipos que no saben quién decide la severidad, funciones de negocio que tardan en reconocer impacto, dependencias externas mal mapeadas y órganos de dirección informados tarde y mal.

La ironía regulatoria es deliciosa en el peor sentido: muchas entidades dedican meses a perfeccionar la taxonomía del riesgo y luego descubren, en un incidente real, que nadie había acordado quién puede parar un servicio, quién informa al supervisor o quién decide si un proveedor debe ser escalado contractualmente. El incidente funciona como una auditoría brutal y sin cita previa.

Pruebas: el momento en que los relatos corporativos se encuentran con la realidad

DORA tampoco confía en la fe. Exige pruebas. El capítulo IV regula la prueba de resiliencia operativa digital. El art. 24 obliga a establecer, mantener y revisar un programa de pruebas sólido y exhaustivo como parte integrante del marco de gestión del riesgo relacionado con las TIC. La idea es simple: una resiliencia que no se prueba es, en el mejor de los casos, una hipótesis cara.

Este punto es clave para corregir otra deriva común: asumir que la gobernanza se demuestra solo con aprobación de políticas y reporting periódico. No. También se demuestra verificando si los controles funcionan, si los escenarios son realistas y si la organización aprende de los resultados. El reglamento no premia el teatro corporativo de “ejercicio completado con éxito” cuando el escenario ha sido tan amable que hasta el Wi‑Fi sobrevivía con dignidad.

Además, para determinadas entidades, DORA prevé threat-led penetration testing en el art. 26. Eso eleva la conversación. Ya no se trata solo de revisar documentos o hacer tabletop exercises educados. Se trata de someter capacidades críticas a pruebas más exigentes, con una lógica de amenaza realista. Para cualquier órgano de dirección serio, ese tipo de resultados debería pesar más que diez presentaciones con semáforos en verde.

La conexión con GDPR y NIS2: el mismo incendio, tres brigadas distintas

Las entidades sujetas a DORA rara vez viven en un universo normativo aislado. Si manejan datos personales, también conviven con el GDPR. Si prestan determinados servicios esenciales o importantes, o forman parte de sectores cubiertos, puede entrar en juego NIS2. La dificultad no está en memorizar siglas. Está en evitar que cada régimen genere su propio circuito paralelo de gobernanza e incidentes.

Con GDPR, el cruce más visible está en la gestión de brechas. El art. 33 del GDPR obliga a notificar violaciones de seguridad de los datos personales a la autoridad de control competente sin dilación indebida y, cuando sea posible, a más tardar 72 horas después de haber tenido constancia de ellas. DORA, por su parte, tiene su propia lógica de clasificación y notificación de incidentes TIC graves en los arts. 17 a 23. No son lo mismo. Tampoco conviene tratarlos como compartimentos estancos. Un incidente puede activar ambos regímenes y exigir criterios distintos, plazos distintos y destinatarios distintos.

Con NIS2 sucede algo parecido. El art. 21 de la Directiva (UE) 2022/2555 obliga a adoptar medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar riesgos de seguridad de redes y sistemas de información. La convergencia material con DORA es evidente en varios frentes: gestión del riesgo, continuidad, cadena de suministro, respuesta a incidentes, seguridad de la cadena de suministro y uso de criptografía, entre otros. Pero la coexistencia no elimina la necesidad de articular un modelo de gobierno único dentro de la entidad. Si no lo haces, acabarás con tres comités hablando del mismo incidente en tres dialectos regulatorios diferentes. Muy europeo todo. Muy eficiente, no tanto.

Qué debe revisar ahora una entidad si no quiere descubrir tarde que su marco era una ficción

A estas alturas, la pregunta útil no es si el consejo “está involucrado”. Esa frase ya no dice nada. La pregunta útil es si la entidad puede demostrar, con evidencia y trazabilidad, que ha conectado la responsabilidad del órgano de dirección del art. 5 con el marco documentado del art. 6 y con las obligaciones operativas repartidas por el resto del reglamento.

Hay cinco comprobaciones especialmente reveladoras.

• Primera: si existe un inventario actualizado de funciones, activos, dependencias y terceros TIC conforme a la lógica del art. 8, y si ese inventario sirve para decidir prioridades de negocio y control, no solo para pasar auditoría.
• Segunda: si las políticas de protección, detección, respuesta y recuperación exigidas por los arts. 9 a 12 están enlazadas con responsables concretos, métricas y decisiones de escalado.
• Tercera: si el proceso de incidentes de los arts. 17 y 18 está ensayado con negocio, legal, comunicación, seguridad y proveedores, o si sigue siendo una secuencia teórica que solo conoce el equipo de ciberseguridad.
• Cuarta: si el programa de pruebas del art. 24 genera hallazgos que suben al nivel adecuado y provocan remediación real, incluida reasignación presupuestaria cuando hace falta.
• Quinta: si la gestión de terceros TIC bajo el art. 28 está integrada en el marco de riesgo y no aparcada en procurement con una revisión contractual estandarizada.

Si dos o tres de esas piezas no encajan, el problema no es cosmético. Es estructural. Y suele aflorar cuando llega una inspección temática, una auditoría interna seria o, peor aún, un incidente que obliga a improvisar bajo presión.

La objeción habitual: “esto ya lo hacíamos antes”

Es verdad a medias. Muchas entidades financieras ya tenían exigencias robustas de gestión del riesgo TIC antes de DORA, procedentes de guías supervisoras, marcos nacionales, requisitos sectoriales y prácticas maduras de seguridad. Decir que todo empieza con DORA sería una exageración perezosa. Pero de ahí no se sigue que DORA sea más de lo mismo.

Lo que cambia es la densidad normativa, la armonización europea, la articulación entre gobernanza, terceros, incidentes y pruebas, y el salto desde la expectativa supervisora dispersa a un reglamento directamente aplicable. Esa combinación endurece la conversación interna. Ya no basta con demostrar buena voluntad o madurez técnica desigual. Hay que demostrar alineación con obligaciones concretas del texto.

La objeción, en el fondo, suele esconder otra cosa: cansancio regulatorio. Comprensible, por cierto. Pero confundir cansancio con irrelevancia es una mala idea. Los reguladores europeos llevan años diciendo que el riesgo digital es riesgo financiero. DORA convierte esa tesis en una estructura jurídica más cerrada y más verificable.

Mi lectura: el valor de DORA está menos en la teoría y más en obligar a elegir

La parte más interesante de DORA no es que describa algo radicalmente nuevo. Es que obliga a las entidades a dejar de vivir en la ambigüedad organizada. Obliga a elegir qué servicios son críticos, qué tolerancias son aceptables, qué dependencias externas son asumibles, qué controles se prueban de verdad, qué hallazgos se escalan al órgano de dirección y qué riesgos no se van a seguir tolerando por pura inercia.

Por eso la discusión sobre si tal frase exacta está en el art. 5 o en el art. 6, siendo jurídicamente relevante, no debería tapar el mensaje de fondo. El reglamento combina dos exigencias inseparables: responsabilidad de la dirección y marco interno documentado de gestión del riesgo TIC. Lo demás —protección, detección, respuesta, recuperación, incidentes, terceros, pruebas— son las piezas que obligan a que esa gobernanza exista fuera del organigrama.

Si eres consejero, esto te afecta aunque no quieras entrar en detalles técnicos. Si lideras seguridad o riesgo, también: ya no vale presentar la resiliencia como un programa aislado del negocio. Si estás en compliance, el reto no es producir más política, sino asegurar que la evidencia encaja con el texto legal y con la realidad operativa. Y si sigues pensando que DORA es un proyecto de TI con logo regulatorio, conviene revisar el reglamento otra vez, esta vez sin anestesia.

La llamada a la acción que sí tiene sentido

Lo urgente no es redactar otra nota interna sobre el compromiso del consejo. Lo urgente es hacer una revisión fría del modelo de gobernanza frente a los arts. 5 y 6 de DORA y comprobar si esa arquitectura aterriza de verdad en los bloques operativos del reglamento: arts. 8 a 13 para el marco de gestión del riesgo TIC, arts. 17 a 23 para incidentes, arts. 24 a 27 para pruebas y arts. 28 y siguientes para terceros TIC.

Hazte una pregunta simple, casi brutal por su sencillez: si mañana el supervisor pidiera evidencia de cómo el órgano de dirección responde por la aplicación del marco de riesgo TIC, ¿tu entidad entregaría una historia coherente o una carpeta con documentos correctos pero desconectados?

Ahí está el quid. DORA no pide perfección técnica absoluta. Pide gobernanza real, marco documentado y capacidad de demostrar que la entidad sabe qué protege, de quién depende, cómo responde y quién decide. Parece obvio. Precisamente por eso sigue fallando en tantas casas.