Deepfakes y fraude con IA en banca: el problema ya no es si parecen reales, sino si tus controles siguen siendo humanos

La IA generativa ha entrado en el fraude corporativo por la puerta menos glamourosa y más eficaz: la suplantación convincente. No hace falta tumbar sistemas, cifrar servidores ni dejar un rastro técnico espectacular. A veces basta con una voz creíble, una videollamada verosímil o un mensaje que parece venir de quien manda para mover dinero, extraer información o forzar una excepción de control. Y ahí empieza un problema incómodo para compliance, para ciberseguridad y para las entidades financieras sujetas a DORA: no todo lo que parece “fraude” está fuera del perímetro de resiliencia operativa digital.

Ese es el punto que muchas organizaciones todavía no han resuelto. Siguen separando por reflejo el fraude del incidente TIC, como si fueran departamentos estancos, taxonomías limpias y mundos con fronteras claras. No lo son. Cuando una suplantación asistida por IA se apoya en canales digitales, debilidades de autenticación, fallos de monitorización o dependencias con terceros TIC, la discusión deja de ser semántica. Pasa a ser operativa, regulatoria y, en algunos casos, notificable.

La cuestión no es si la IA “cambiará” el fraude. Eso ya es una obviedad un poco cansina. La cuestión útil es otra: dónde se cruza con las obligaciones ya vigentes en DORA, qué exige revisar en controles de detección y respuesta, y por qué el viejo argumento de “esto lo llevaba fraude, no seguridad” puede quedarse peligrosamente corto.

La comodidad del silo se acaba cuando el ataque viaja por un canal digital

La literatura regulatoria europea sobre IA y ciberseguridad ya deja claro algo básico: la IA no solo plantea cuestiones de innovación o gobernanza algorítmica, también afecta al riesgo. La página temática de ENISA sobre inteligencia artificial va precisamente por ahí, aunque conviene no atribuirle frases que no dice ni cronologías grandilocuentes que la fuente no sostiene. Lo relevante, sin adornos, es que el debate europeo ya trata la IA como una variable de ciberseguridad y resiliencia, no como una curiosidad de laboratorio.

En la práctica, eso significa que una entidad no debería analizar un caso de suplantación hiperrealista solo como evento de fraude interno o externo si el vector de materialización fue digital. Piensa en el patrón operativo más incómodo: una instrucción urgente que aparenta venir de un alto directivo, recibida por un canal corporativo o semicorpora­tivo, que desencadena una acción sensible fuera del circuito habitual. No hace falta afirmar de forma categórica qué “ve” o “deja de ver” un SOC en todos los casos; eso sería vender certeza donde solo hay escenarios. Lo que sí puede afirmarse con seguridad es algo menos vistoso y más útil: muchos controles de seguridad tradicionales están diseñados para detectar malware, intrusión, exfiltración o abuso de credenciales, no necesariamente manipulación persuasiva a través de interacciones aparentemente legítimas.

Ese matiz importa. Porque si la organización sigue midiendo su madurez de detección solo con telemetría técnica clásica, puede pasar por alto eventos donde el activo comprometido no es el endpoint, sino el proceso de decisión.

DORA no regula “deepfakes”. Regula algo más incómodo: tu obligación de gestionar el riesgo aunque cambie el disfraz

Aquí conviene limpiar el terreno de referencias mal ancladas. La gestión, clasificación y notificación de incidentes relacionados con las TIC en DORA no “empieza” en el artículo 17 como a veces se ha escrito de forma imprecisa. Esa materia se encuadra en el Capítulo III del Reglamento (UE) 2022/2554, dedicado a la gestión, clasificación e información sobre incidentes relacionados con las TIC. El artículo 17 se refiere a la clasificación de incidentes relacionados con las TIC y de ciberamenazas significativas; no resume por sí solo todo el régimen de gestión y notificación. Si vas a construir una decisión interna sobre si algo puede ser notificable, más vale empezar por el anclaje correcto y no por una cita aproximada.

La consecuencia práctica es bastante menos elegante que un titular grandilocuente: una entidad no puede descartar de entrada un evento solo porque el resultado visible haya sido fraude. Tiene que preguntarse si, además, hubo un incidente relacionado con las TIC en el sentido operativo de DORA y de su marco de gestión del riesgo.

DORA, en su artículo 6, obliga a las entidades financieras a contar con un marco interno de gestión del riesgo relacionado con las TIC que sea sólido, exhaustivo y bien documentado. No distingue entre amenazas “clásicas” y amenazas con barniz algorítmico. El artículo 8 exige identificar, clasificar y documentar adecuadamente todas las funciones empresariales soportadas por TIC, los roles y responsabilidades, los activos de información y los activos TIC que respaldan esas funciones, así como sus dependencias e interdependencias. No dice, de forma específica, que haya que “mapear verificación por voz o vídeo” en esos términos literales; decir eso sería sobreinterpretar el texto. Pero la lógica regulatoria sí empuja a algo muy parecido: si un proceso crítico depende de interacciones digitales o de mecanismos de autenticación que pueden ser objeto de suplantación, esa dependencia forma parte del paisaje de riesgo que la entidad debe conocer y documentar.

Aquí está el quid. DORA no necesita escribir la palabra deepfake para que el riesgo entre en el perímetro. Le basta con exigir que entiendas qué procesos dependen de qué activos, qué canales, qué terceros y qué controles. Si una aprobación urgente de pagos, una modificación de datos bancarios, una reconfiguración de límites o una liberación de información sensible descansa en una cadena digital débilmente verificada, el problema no desaparece porque el ataque tenga aspecto de “engaño” y no de “hackeo”.

El error habitual: tratar la IA como tema de política corporativa y no como variable de arquitectura de control

En muchas entidades, la conversación sobre IA se ha desplazado demasiado rápido hacia principios éticos, casos de uso internos y gobernanza de herramientas generativas. Todo eso tiene sentido. Pero deja un hueco peligroso si no se conecta con la arquitectura de control existente. El fraude asistido por IA no espera a que el comité de innovación termine su taxonomía.

La pregunta útil para primera línea, segunda línea y seguridad es mucho más prosaica: ¿qué controles de verificación siguen confiando en señales humanas que pueden imitarse de manera convincente? ¿Dónde hay autorizaciones excepcionales fuera de flujo? ¿Qué dependencias con proveedores de comunicaciones, plataformas de colaboración o contact center participan en procesos sensibles? ¿Qué evidencias queda­n cuando una instrucción aparentemente legítima mueve una decisión crítica?

No hace falta sostener con falsa precisión que “con unas pocas muestras” o con determinado material público un atacante logrará siempre recrear la identidad de un consejero o un CFO. Eso dependerá de la tecnología, del contexto y del caso. Lo que sí es razonable afirmar es que la capacidad de generar contenidos sintéticos convincentes —voz, imagen, texto o combinaciones de varios— reduce el valor probatorio de ciertas señales informales que muchas organizaciones seguían tratando como suficientes en momentos de urgencia. Y la urgencia, por cierto, sigue siendo el lubricante favorito del fraude de toda la vida. La IA solo le da mejores decorados.

Qué parte de DORA sí entra en juego cuando la suplantación toca procesos críticos

Si una entidad quiere analizar con rigor un episodio de fraude asistido por IA, no necesita forzar el Reglamento hasta inventar obligaciones textuales que no existen. Necesita leer bien los artículos que sí importan.

El artículo 10 de DORA obliga a implantar mecanismos para detectar actividades anómalas, de acuerdo con el artículo 17, incluidos problemas de rendimiento de la red relacionados con incidentes y la identificación de posibles puntos únicos de fallo. También exige detectar incidentes relacionados con las TIC y establecer alertas tempranas. Lo que no hace ese artículo es imponer expresamente la ampliación de telemetría a telefonía, videoconferencia o interacciones con contact center en esos términos concretos. Afirmarlo así sería incorrecto. Ahora bien, una vez que el artículo 10 te obliga a tener capacidades eficaces de detección, la entidad debe preguntarse con honestidad si sus canales sensibles generan evidencia suficiente para detectar uso anómalo, abuso de privilegios, instrucciones excepcionales o patrones incompatibles con el proceso normal. No es una obligación literal de “monitoriza llamadas”; es una consecuencia de diseño de control si esos canales participan en funciones críticas.

El artículo 11, sobre respuesta y recuperación relacionadas con las TIC, exige a las entidades disponer de una política integral de continuidad de la actividad TIC, planes de respuesta y recuperación, comunicación y análisis posteriores al incidente, entre otros elementos. Tampoco menciona de forma específica “identidad sintética” o “suplantación audiovisual” en el playbook. Pero si tus planes de respuesta no contemplan escenarios en los que una acción legítima en apariencia haya sido inducida mediante engaño digital creíble, el problema no es que DORA te lo dicte palabra por palabra. El problema es que tu capacidad de respuesta estará modelada para otro tipo de incidente y llegará tarde justo cuando la narrativa del atacante sea más persuasiva.

El artículo 17, ya bien ubicado, importa para la clasificación de incidentes relacionados con las TIC y de ciberamenazas significativas. Por tanto, sí es relevante al analizar si un evento que produce fraude puede tener además dimensión de incidente TIC clasificable. Lo que no debe hacerse es presentar el artículo 17 como si fuera, en solitario, la norma total sobre gestión y notificación o como si ofreciera una respuesta automática para cualquier fraude con IA. La calificación dependerá de los criterios aplicables, del impacto y del modo en que el evento afecte a redes y sistemas de información, servicios, operaciones o datos.

La frontera entre fraude e incidente TIC ya no se puede dibujar con rotulador grueso

La tentación organizativa es conocida: si hubo engaño a una persona y no un compromiso técnico evidente, entonces lo gestiona fraude; si hubo malware o acceso no autorizado, entonces lo gestiona ciberseguridad. Esa división, cómoda sobre el organigrama, se vuelve bastante menos útil cuando un ataque combina ingeniería social sofisticada, canales digitales corporativos, terceros tecnológicos y decisiones operativas con impacto financiero o reputacional.

Lo prudente aquí no es afirmar cómo reaccionará “el supervisor” en abstracto ni anticipar que “difícilmente aceptará” una determinada narrativa defensiva. Eso sería aventurar una conclusión que depende de hechos, contexto y jurisdicción supervisora. La formulación seria es otra: si el evento afectó a funciones soportadas por TIC, explotó debilidades en controles digitales o reveló fallos en la capacidad de detección, clasificación, respuesta o gobernanza de dependencias tecnológicas, la entidad debería evaluarlo también bajo el marco DORA y documentar por qué lo considera —o no— un incidente relacionado con las TIC, una ciberamenaza significativa, un evento de fraude o una combinación de varios planos de riesgo.

Ese ejercicio de documentación importa más de lo que parece. En supervisión, a menudo el problema no es solo la decisión final, sino la calidad del razonamiento que lleva a ella. Si tu comité de incidentes puede demostrar que aplicó criterios, revisó dependencias, valoró impacto, contrastó evidencias y decidió con base en el marco normativo correcto, estás en terreno defendible. Si la decisión fue “esto no era ciber porque parecía una llamada del director financiero”, estás regalando munición.

AI Act: no convierte el fraude sintético en un problema nuevo, pero sí endurece el contexto de gobernanza

También conviene afinar la referencia al AI Act. El Reglamento (UE) 2024/1689 es efectivamente el AI Act. Lo que debe evitarse es una formulación ambigua sobre su “publicación” si no se distingue entre la fecha del acto y su publicación en el Diario Oficial. El acto es de 13 de junio de 2024, y su publicación en el Diario Oficial de la Unión Europea se produjo el 12 de julio de 2024. Si se menciona esa cronología, hay que hacerlo con precisión, no a medias.

Dicho eso, el AI Act no resuelve por sí solo el problema operativo del fraude asistido por IA en entidades financieras. Su centro de gravedad está en la regulación de sistemas de IA y en obligaciones para proveedores, desplegadores y otros actores según el nivel de riesgo. Para esta discusión, su valor está más en el contexto de gobernanza que en una receta táctica de detección de fraude.

Hay, eso sí, un efecto político-regulatorio claro: la UE ya ha dejado de tratar la IA como terreno voluntarista. Entre DORA, el AI Act, GDPR, NIS2 y el resto del ecosistema, la dirección es inequívoca: las organizaciones tendrán que demostrar no solo que innovan, sino que entienden el riesgo técnico, operacional y de derechos asociado a las tecnologías que despliegan o padecen. Y “padecer” aquí no es una broma. Muchas empresas no usan IA de forma intensa en sus procesos, pero ya la están sufriendo en los ataques.

Qué revisar de inmediato si gestionas riesgo operacional, fraude o seguridad

La peor respuesta ante esta clase de amenazas es abrir un grupo de trabajo infinito sobre “riesgos emergentes”. El segundo peor error es pensar que basta con una campaña de concienciación sobre deepfakes. Ni una cosa ni la otra arreglan el problema de control.

Lo primero es revisar los procesos donde una instrucción extraordinaria puede desencadenar una acción irreversible o de alto impacto. Pagos urgentes, cambios de cuentas beneficiarias, reseteo de credenciales privilegiadas, modificaciones de parámetros sensibles, acceso excepcional a información de clientes, desbloqueos por escalado, validación de incidencias con terceros. Si esos procesos admiten atajos basados en autoridad aparente, la IA solo agrava una debilidad previa.

Lo segundo es analizar qué evidencia queda en cada canal usado para decisiones sensibles. No porque DORA enumere canal por canal, que no lo hace, sino porque sin trazabilidad suficiente la clasificación posterior del evento será pobre y la respuesta, aún peor. Hay entidades que registran con enorme detalle eventos de red y apenas conservan contexto operativo útil sobre aprobaciones excepcionales. Luego llega el incidente y descubren que tienen gigabytes de logs irrelevantes y casi ninguna respuesta a la pregunta esencial: quién pidió qué, por qué canal, con qué validación y contra qué regla se autorizó la excepción.

Lo tercero es revisar la separación entre equipos. Fraude, seguridad, operaciones, cumplimiento normativo y riesgo operacional deben compartir criterios mínimos de escalado. No hace falta fusionarlos en una sola torre de mando para que hablen entre sí como adultos. Sí hace falta acordar cuándo un evento de fraude entra también en circuito de incidente TIC; quién hace la primera calificación; qué evidencias son necesarias; y cómo se preserva la trazabilidad de la decisión.

Lo cuarto es probar escenarios. DORA dedica su Capítulo IV a las pruebas de resiliencia operativa digital. Si tu programa de pruebas sigue centrado solo en indisponibilidad técnica, recuperación de backups o phishing clásico, se está quedando viejo a velocidad de crucero. Sin exagerar lo que dice la norma, hay una conclusión práctica difícil de rebatir: una estrategia de pruebas madura debería incorporar escenarios donde la manipulación de identidad y la persuasión por canales digitales tensionen controles humanos y operativos. No porque el Reglamento mencione la videollamada falsa en un anexo perdido, sino porque eso ya forma parte del riesgo plausible sobre funciones críticas.

La lección incómoda: muchas debilidades no están en la IA, sino en procesos que llevaban años mal diseñados

Hay un detalle casi irritante en todo este debate. La IA parece el gran villano nuevo, pero en muchos casos solo expone con más crudeza fallos viejos: exceso de confianza en la jerarquía, excepciones sin doble control, autenticación laxa, canales alternativos sin trazabilidad, outsourcing mal gobernado y una cultura operativa donde “era urgente” funciona como llave maestra.

Eso cambia también cómo debe contarse internamente el riesgo. Si una entidad presenta estos incidentes solo como “amenaza emergente de IA”, puede terminar comprando herramientas llamativas sin arreglar los defectos estructurales. A veces el control más eficaz no será un detector milagroso de contenido sintético, sino una regla muy poco sexy: ninguna instrucción extraordinaria ejecuta un pago o altera un dato crítico sin validación fuera de banda definida, trazable y resistente a suplantación. La tecnología ayuda, claro. Pero el control de proceso sigue mandando.

En términos de DORA, esta lectura encaja mejor con la lógica del Reglamento que el fetichismo tecnológico. El marco gira alrededor de gobernanza, identificación de activos y funciones, protección y prevención, detección, respuesta, recuperación, aprendizaje y supervisión de terceros TIC. Es resiliencia operativa digital, no magia perimetral.

Qué ocurre con terceros TIC cuando el canal de engaño no es “propio”

Otro punto que suele quedar infravalorado aparece cuando la interacción pasa por plataformas de comunicación, herramientas de colaboración o proveedores externos que facilitan o soportan el canal usado en la suplantación. DORA no convierte automáticamente a cualquier proveedor de comunicaciones en origen del problema, pero sí exige un marco serio de gestión del riesgo de terceros TIC.

Los artículos 28 y siguientes de DORA son el anclaje correcto. El artículo 28 establece los principios clave para una gestión sólida del riesgo relacionado con terceros proveedores de servicios TIC, integrada en el marco general de gestión del riesgo relacionado con las TIC. Si un proceso crítico depende de un tercero para autenticar, enrutar, grabar, registrar o sostener interacciones operativas relevantes, esa dependencia no puede tratarse como detalle administrativo. Forma parte del mapa de exposición.

La pregunta incómoda para muchas entidades es sencilla: ¿sabes qué capacidad contractual, técnica y forense tienes sobre esos canales cuando una decisión sensible se tomó a través de ellos? Si no puedes reconstruir la secuencia, si no tienes retención adecuada, si no puedes obtener evidencias a tiempo o si el proveedor no encaja bien en tu inventario de terceros críticos, el incidente revelará una debilidad de gobernanza mucho antes de que el departamento jurídico termine de discutir su taxonomía.

Y GDPR no desaparece porque el problema huela a fraude

Cuando un evento de suplantación desemboca en acceso, divulgación o alteración indebida de datos personales, la conversación deja de ser exclusivamente DORA. GDPR entra en escena por su propia puerta. El artículo 33 del Reglamento General de Protección de Datos obliga a notificar a la autoridad de control las violaciones 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 ellas, salvo que sea improbable que dicha violación constituya un riesgo para los derechos y libertades de las personas físicas.

La interacción entre DORA y GDPR es justo el tipo de fricción que castiga a las organizaciones con silos. Puede haber un mismo hecho con varias lecturas regulatorias simultáneas: fraude, incidente TIC, violación de seguridad de datos personales, evento de continuidad o fallo de tercero. Quien busque una etiqueta única antes de movilizar a los equipos va tarde. Primero se contiene, se preservan evidencias, se clasifica con criterios paralelos y se documenta. Luego ya llegará la liturgia terminológica.

También aquí conviene evitar el automatismo. No toda suplantación con IA implicará una violación de datos personales notificable, ni todo incidente TIC bajo DORA activará GDPR. Pero si el ataque logró acceso a datos, generó divulgación no autorizada o desencadenó alteración de información personal, el análisis bajo el artículo 33 no es opcional.

El ángulo de NIS2: gobernanza y medidas, no solo notificación

Para entidades o grupos con presencia en sectores cubiertos, NIS2 añade otra capa que merece atención. El artículo 21 de la Directiva (UE) 2022/2555 obliga a adoptar medidas técnicas, operativas y de organización adecuadas y proporcionadas para gestionar los riesgos que se planteen para la seguridad de las redes y sistemas de información. Entre esas medidas figuran políticas de análisis de riesgos y seguridad de los sistemas de información, gestión de incidentes, continuidad de las actividades, seguridad de la cadena de suministro, políticas y procedimientos para evaluar la eficacia de las medidas de gestión de riesgos y prácticas básicas de ciberhigiene y formación, entre otras.

La clave aquí no es inventar que NIS2 regula los deepfakes. No lo hace en esos términos. La clave es que su enfoque refuerza la misma dirección que DORA: el riesgo debe gobernarse como capacidad organizativa, no como catálogo fijo de amenazas. Si una técnica de suplantación digital compromete tus procesos o la seguridad de tus sistemas de información, lo que se examinará no es si el atacante usó una palabra de moda. Se examinará si tus medidas eran adecuadas y proporcionadas.

Cómo escribir una conclusión defendible cuando el caso llegue al comité de incidentes

Muchas entidades fallan no en la detección inicial, sino al redactar la conclusión. O se quedan cortas y llaman “intento de fraude” a algo que reveló una debilidad material de control digital, o se pasan de frenada y etiquetan como ciberincidente cualquier interacción engañosa, diluyendo criterio y saturando la gobernanza. El equilibrio está en formular bien las preguntas.

Una conclusión defendible debería cubrir al menos cinco puntos. Primero, qué función empresarial y qué activos o servicios soportados por TIC estuvieron implicados. Segundo, qué canal o canales participaron y qué trazabilidad existía. Tercero, qué controles de autenticación, validación, segregación o supervisión fallaron, se eludieron o se activaron correctamente. Cuarto, qué impacto real o potencial se produjo sobre operaciones, datos, clientes, disponibilidad, integridad, confidencialidad o posición financiera. Quinto, por qué el evento se clasifica de una manera u otra bajo DORA, y si además activa análisis bajo GDPR, marcos de fraude, continuidad u otras obligaciones sectoriales.

Eso exige más trabajo que decir “era una estafa sofisticada”. También evita muchas tonterías a posteriori.

La tesis de fondo: si el proceso crítico depende de una señal que la IA puede falsificar, el riesgo ya es tuyo

La discusión no debería girar alrededor de si la IA generativa es sorprendente. Lo es, y cada semana menos. La discusión seria es si tu modelo de control sigue otorgando confianza operativa a señales que ya no la merecen por sí solas. Ahí es donde DORA aprieta de verdad, aunque no use el lenguaje de moda de LinkedIn.

El Reglamento obliga a construir resiliencia, no a admirar amenazas emergentes desde una presentación de riesgos. Eso implica inventariar funciones y dependencias, reforzar detección, preparar respuesta, probar escenarios, gobernar terceros y documentar decisiones de clasificación con precisión jurídica y operativa. Si un ataque de suplantación asistido por IA toca cualquiera de esas piezas, no basta con pasarlo al equipo de fraude y seguir adelante como si el perímetro TIC hubiera salido ileso.

La ironía final es bastante europea: hemos dedicado años a sofisticar controles técnicos para detener intrusiones mientras muchos procesos seguían aceptando excepciones por una voz convincente, un mensaje urgente o una apariencia de autoridad. La IA no ha inventado esa debilidad. Solo la ha hecho más barata, escalable y creíble.

Y eso, para una entidad sujeta a DORA, ya no es una curiosidad. Es un problema de gobernanza, de arquitectura de control y, según el caso, de clasificación regulatoria. Si tu organización todavía cree que fraude y resiliencia digital viven en edificios distintos, quizá ha llegado la hora de revisar el plano.