Deepfakes y fraude potenciado por IA en banca: defensa técnica y obligaciones

Un director financiero recibe una videollamada de su consejero delegado. La imagen encaja, la voz también y la petición parece razonable: transferir fondos a una cuenta de un proveedor antes de que cierre una operación. El atacante no necesita entrar en el sistema bancario. Le basta con conseguir que una persona autorizada pulse el botón correcto.

Ese cambio de escenario importa más que la espectacularidad de un vídeo falso. El fraude potenciado por inteligencia artificial no siempre busca engañar a miles de clientes con una campaña masiva. A menudo busca manipular una sola decisión de alto valor: una transferencia, un cambio de cuenta bancaria, una recuperación de credenciales o una aprobación excepcional.

Para bancos, aseguradoras y proveedores financieros, la respuesta no consiste en comprar un detector de deepfakes y añadirlo a la arquitectura como quien instala otro antivirus. La defensa exige combinar identidad, contexto transaccional, controles de autorización, formación, monitorización y capacidad de respuesta. También obliga a dejar pruebas de que esos controles funcionan.

Ahí se cruzan tres obligaciones distintas. DORA exige gestionar el riesgo de tecnologías de la información y la comunicación, notificar determinados incidentes y probar la resiliencia. El Reglamento de Inteligencia Artificial de la Unión Europea introduce obligaciones de transparencia para determinados contenidos generados o manipulados artificialmente. El RGPD fija límites adicionales cuando la defensa utiliza datos biométricos, perfiles o decisiones automatizadas. La suma no es una nueva casilla de compliance. Es una revisión de cómo la entidad decide que una persona es quien dice ser y que una orden merece ser ejecutada.

El fraude cambia cuando el atacante puede fabricar confianza

La ingeniería social tradicional dependía de errores de redacción, dominios parecidos o llamadas con acento extraño. Los modelos generativos reducen esas señales. Pueden producir mensajes convincentes, clonar una voz a partir de muestras relativamente breves y generar vídeo suficiente para superar una interacción superficial. No hace falta asumir que la falsificación es perfecta. En un entorno sometido a presión, una señal plausible puede bastar.

El riesgo más serio no es que todos los empleados crean cualquier vídeo. Es que los procesos internos sigan tratando una voz o una imagen como prueba de identidad cuando nunca fueron factores de autenticación robustos. La biometría audiovisual puede aportar indicios, pero no debería convertirse por defecto en la autoridad final para autorizar una operación.

Un ataque típico puede combinar varias piezas:

• Reconocimiento: el delincuente extrae organigramas, firmas, calendarios, comunicados y grabaciones públicas para identificar quién puede ordenar pagos o aprobar excepciones.
• Preparación: genera correos, mensajes de voz o videollamadas coherentes con el estilo y el contexto del objetivo. La IA reduce el coste de personalizar cada intento.
• Manipulación del flujo: introduce urgencia, secreto o una supuesta intervención de un superior para saltarse la segregación de funciones.
• Monetización: dirige el pago a una cuenta mule, cambia los datos de un proveedor o utiliza credenciales obtenidas durante la conversación.

El control, por tanto, no debe preguntar únicamente “¿el vídeo es auténtico?”. Debe preguntar “¿por qué esta persona está solicitando esta acción, desde qué canal, con qué nivel de riesgo y mediante qué segundo factor independiente?”. Esa es la diferencia entre detectar contenido sintético y resistir un fraude.

La autenticación audiovisual no es una prueba suficiente

Los equipos de seguridad suelen recibir dos propuestas opuestas. La primera consiste en bloquear cualquier interacción que pueda incluir contenido generado por IA. Es inviable: una entidad financiera utiliza transcripción, asistentes, síntesis de voz, traducción y automatización en decenas de procesos. La segunda propone confiar en herramientas de detección de deepfakes como control principal. Es igual de problemática. Los detectores operan con probabilidades, pueden degradarse ante nuevas técnicas de generación y no resuelven el problema de autorización.

La arquitectura más resistente combina controles independientes. Para una orden de pago de riesgo elevado, la voz del director no debería ser el único elemento; tampoco el vídeo, el reconocimiento facial o una conversación aparentemente natural. El proceso puede exigir una aprobación en el canal corporativo registrado, una confirmación fuera de banda y una validación de la cuenta beneficiaria. Si el canal utilizado para la petición y el de confirmación comparten las mismas credenciales comprometidas, la independencia es una ilusión.

Controles técnicos que sí cambian el resultado

Identidad verificable. La entidad debe distinguir entre autenticación, identificación y autorización. La primera demuestra, con un nivel de confianza determinado, que alguien controla un factor. La segunda vincula ese factor a una identidad. La tercera decide qué acciones puede ejecutar. Una videollamada puede ayudar en la identificación, pero no sustituye necesariamente a una autenticación fuerte ni a una autorización basada en riesgo.

Para empleados con capacidad de ordenar pagos, los controles deberían incluir credenciales resistentes al phishing, como claves de seguridad compatibles con FIDO2 o passkeys gestionadas corporativamente, junto con políticas de acceso condicional. Un código enviado por SMS añade fricción, pero no ofrece la misma resistencia que un factor criptográfico vinculado al dominio o al dispositivo. La elección debe documentarse según el riesgo del proceso, no según la comodidad del usuario.

Vinculación de la transacción. La aprobación debe mostrar al usuario los datos que realmente autoriza: beneficiario, importe, divisa, cuenta de destino y fecha de ejecución. El mecanismo de autenticación debe vincularse a esos datos cuando sea técnicamente posible. Aprobar “la operación urgente” sin ver el IBAN o el importe permite que un atacante cambie el objeto de la autorización mientras conserva la apariencia de legitimidad.

Separación de canales. La confirmación de una instrucción recibida por videollamada no debería volver al mismo chat o a la misma llamada. Una práctica más sólida es devolver la llamada a un número obtenido del directorio interno, utilizar el sistema de pagos corporativo o exigir la aprobación de un segundo firmante. El procedimiento debe prohibir expresamente que la persona que recibe una petición urgente pueda desactivar por sí sola los controles ordinarios.

Análisis de comportamiento. Los motores de detección de fraude pueden evaluar velocidad, horario, dispositivo, geografía, relación histórica con el beneficiario, cambios recientes en los datos maestros y desviaciones respecto al patrón del usuario. La IA puede ser útil aquí, pero su salida debe tratarse como una señal de riesgo, no como una decisión incuestionable. Un resultado “bajo riesgo” no convierte una transferencia anómala en legítima.

Detección de contenido sintético. Las herramientas de análisis de voz y vídeo pueden buscar inconsistencias acústicas, artefactos de compresión, movimientos faciales atípicos o desajustes entre audio e imagen. Su valor aumenta cuando se utilizan para elevar el nivel de verificación, retrasar una operación o activar revisión humana. Su valor disminuye cuando se presentan como un oráculo binario con una tasa de acierto que nadie ha validado en los canales, idiomas y dispositivos de la entidad.

Proveniencia y marcado. Los metadatos, las firmas de contenido y los estándares de procedencia pueden ayudar a determinar cómo se creó o modificó un archivo. No son una solución completa: pueden eliminarse al convertir el formato, no siempre están presentes en una captura de pantalla y no prueban por sí solos que la persona que aparece en el contenido autorizó una orden. Funcionan mejor como una capa de evidencia junto a la identidad y el contexto.

DORA convierte el deepfake en un asunto de resiliencia operativa

DORA, el Reglamento (UE) 2022/2554, se aplica desde el 17 de enero de 2025. En 2026, para las entidades dentro de su ámbito, la discusión ya no debería ser si la IA generativa “es una tendencia”, sino si un fraude que explota canales digitales revela una deficiencia en los controles de riesgo ICT, en el proceso de incidentes o en la gestión de terceros tecnológicos.

El artículo 5 de DORA sitúa la responsabilidad del órgano de dirección sobre el marco de gestión del riesgo ICT. El artículo 6 exige un marco documentado y adecuado al perfil de riesgo. En la práctica, si la entidad utiliza clonación de voz, análisis biométrico, detección de fraude basada en modelos o servicios de identidad operados por terceros, el riesgo de manipulación de esos componentes debe aparecer en el inventario y en la evaluación del riesgo, no escondido bajo la etiqueta genérica de “ciberseguridad”.

El artículo 9 exige medidas de protección y prevención. La aplicación concreta al fraude por suplantación pasa por controles de acceso, autenticación, protección de datos, integridad de registros y segregación de funciones. El artículo 11 aborda la respuesta y recuperación: el procedimiento debe contemplar qué ocurre cuando la entidad sospecha que una instrucción fue inducida mediante una identidad sintética, no solo cuando un malware cifra un servidor.

La clasificación de incidentes de DORA añade una segunda capa. El artículo 17 exige un proceso de gestión de incidentes relacionados con ICT y el artículo 18 establece criterios de clasificación. El artículo 19 regula la notificación de incidentes mayores relacionados con ICT a la autoridad competente. No todo intento de deepfake será notificable. Un correo bloqueado por un filtro no equivale a un incidente mayor. Pero una campaña que comprometa una cuenta privilegiada, provoque una transferencia material, interrumpa un servicio o afecte a clientes puede activar un análisis de clasificación que debe quedar documentado.

El error habitual es registrar el asunto como “fraude” y cerrar el expediente fuera del sistema de incidentes tecnológicos. Esa separación puede ser administrativamente cómoda y operativamente falsa. Si el ataque explotó el proveedor de identidad, el canal de atención, el sistema de pagos, un modelo antifraude o un servicio de telecomunicaciones, existe una dimensión ICT que debe investigarse con el nivel de trazabilidad de DORA.

Los artículos 24 a 27, sobre pruebas de resiliencia operativa digital, ofrecen una pista práctica. Las pruebas no deberían limitarse a escaneos de vulnerabilidades y ejercicios de recuperación de centros de datos. Una entidad madura prueba si sus empleados y controles detectan una petición generada sintéticamente, si una orden puede detenerse a tiempo, si los logs permiten reconstruir la cadena de decisión y si los proveedores responden durante una investigación. Los escenarios de threat-led penetration testing tienen requisitos específicos, pero incluso las pruebas más rutinarias pueden incorporar escenarios de ingeniería social y abuso de identidad.

La gestión de terceros es otro punto débil. DORA, en sus artículos 28 a 44, regula el riesgo derivado de proveedores terceros de servicios ICT. Un banco puede no desarrollar su propio sistema de verificación de identidad: puede depender de una plataforma de onboarding, un proveedor de voz, un motor antifraude o una nube que almacena evidencias. El contrato y la supervisión deben permitir conocer qué datos procesa el proveedor, cómo valida el rendimiento del modelo, qué logs conserva, cómo notifica incidentes y cómo facilita la salida o sustitución del servicio.

El artículo 30 exige que los contratos sobre servicios ICT incluyan elementos concretos, entre ellos descripciones claras del servicio, ubicaciones de tratamiento, niveles de servicio, asistencia en incidentes, derechos de auditoría y terminación. En un servicio de detección de deepfakes, una cláusula de disponibilidad del 99,9 % es insuficiente si no se define también cómo se mide la precisión, qué ocurre ante una degradación del modelo y qué evidencias recibirá la entidad cuando el proveedor cambie su sistema.

El AI Act no convierte todo deepfake en ilegal, pero sí impone transparencia

El Reglamento (UE) 2024/1689, conocido como AI Act, introduce una obligación especialmente relevante para los contenidos sintéticos. Su artículo 50 establece obligaciones de transparencia para determinados proveedores y usuarios de sistemas de IA. Entre ellas figura informar de que una salida de audio, imagen, vídeo o texto ha sido generada o manipulada artificialmente cuando el contenido pueda parecer auténtico o representar hechos o personas reales.

La obligación no significa que cada uso interno de una herramienta generativa requiera una etiqueta visible en cada correo corporativo. La aplicación depende del tipo de sistema, del uso y de las excepciones previstas. El artículo 50 contempla, entre otros supuestos, el marcado y detección de contenido generado o manipulado artificialmente y establece matices para determinados usos, como la aplicación de la ley o la libertad de expresión. La evaluación debe hacerse sobre el caso concreto, no mediante una regla simplista de “IA igual a etiqueta”.

La fecha también importa. El artículo 113 fija la aplicación general del reglamento el 2 de agosto de 2026, aunque varias obligaciones tienen calendarios distintos. Este año, las entidades financieras deben haber separado ya tres cuestiones que a menudo aparecen mezcladas: si utilizan un sistema de IA, si son proveedoras o desplegadoras a efectos del reglamento y si el contenido sintético utilizado en una interacción entra en las obligaciones de transparencia del artículo 50.

Para una entidad financiera, el problema se presenta en dos direcciones. Primero, puede utilizar IA para generar simulaciones de formación, avatares de atención o mensajes de servicio. Si esos contenidos pueden confundirse con personas o acontecimientos reales, debe establecerse cómo se marcan y cómo se conserva la información sobre su origen. Segundo, la entidad puede recibir contenido sintético de un cliente, empleado, proveedor o atacante. En ese caso, la obligación de transparencia del emisor no elimina la necesidad de que el banco mantenga controles propios de autenticación y fraude.

La transparencia tampoco debe confundirse con seguridad. Una etiqueta que diga “generado por IA” permite al destinatario interpretar el contenido, pero no demuestra que la instrucción sea fraudulenta. Del mismo modo, la ausencia de una etiqueta no prueba que el contenido sea auténtico. El control decisivo sigue siendo la autorización por un canal independiente y la evaluación del contexto.

Cuando el sistema utilizado para detectar fraude toma decisiones con efectos significativos sobre una persona, aparecen obligaciones adicionales. El AI Act clasifica como sistemas de alto riesgo determinados usos incluidos en el anexo III, entre ellos algunos relacionados con la evaluación de la solvencia o el acceso a servicios esenciales. No todo motor antifraude bancario encaja automáticamente en esa categoría; la finalidad, la arquitectura y el efecto de la decisión son determinantes. Pero una entidad no debería esperar a la clasificación final para exigir documentación sobre datos, supervisión humana, precisión, robustez, ciberseguridad y gestión de cambios.

El artículo 10 del AI Act, aplicable a sistemas de alto riesgo, regula la gobernanza de datos. El artículo 14 exige supervisión humana. El artículo 15 aborda precisión, robustez y ciberseguridad. El artículo 12 exige conservación de logs generados automáticamente durante un periodo adecuado al propósito y a las obligaciones aplicables. Si un modelo bloquea una transferencia o rechaza una interacción porque la voz parece sintética, el equipo de cumplimiento debe poder reconstruir qué señal utilizó, qué umbral se aplicó, quién revisó la alerta y qué ocurrió después.

El RGPD añade límites que los equipos de fraude suelen descubrir tarde

La defensa contra deepfakes puede implicar grabaciones de voz, vídeo de clientes, análisis facial, huellas de dispositivo, comportamiento, geolocalización y perfiles de riesgo. No todos esos datos tienen la misma categoría jurídica, pero tratarlos como simples telemetría técnica es una forma rápida de crear un problema de privacidad.

El artículo 5 del RGPD exige licitud, lealtad, transparencia, limitación de la finalidad, minimización y exactitud, entre otros principios. El artículo 6 exige una base jurídica para el tratamiento. Si se procesan datos biométricos con el fin de identificar de manera unívoca a una persona, el artículo 9 establece una prohibición general con excepciones específicas. La organización debe determinar si realmente está realizando identificación biométrica o si utiliza características técnicas para detectar manipulación, porque la distinción cambia el análisis jurídico y las garantías necesarias.

El artículo 25 obliga a aplicar protección de datos desde el diseño y por defecto. En una solución antifraude, eso puede traducirse en conservar una puntuación de riesgo y señales derivadas en lugar de almacenar indefinidamente el vídeo completo; restringir el acceso a las grabaciones; separar los datos usados para investigación de los utilizados para entrenar modelos; y definir plazos de conservación coherentes con la gestión de reclamaciones, litigios y obligaciones sectoriales.

El artículo 32 exige medidas técnicas y organizativas adecuadas al riesgo. El cifrado es solo una parte. También importan el control de accesos, la resiliencia, la capacidad de restauración, las pruebas periódicas y la confidencialidad de los datos utilizados para evaluar identidad. Un repositorio con miles de muestras de voz de clientes es un objetivo especialmente atractivo: si se filtra, esas voces no pueden “cambiarse” como una contraseña.

El artículo 22 limita determinadas decisiones basadas únicamente en tratamiento automatizado cuando producen efectos jurídicos o afectan significativamente a la persona. Una puntuación automática puede bloquear una operación, suspender una cuenta o rechazar una recuperación de acceso. La entidad debe analizar cuándo existe decisión exclusivamente automatizada, qué excepción aplica y cómo se ofrece intervención humana significativa. Pulsar un botón después de mirar superficialmente la puntuación no convierte una decisión automática en revisión humana.

Si una brecha afecta a grabaciones, credenciales o datos de clientes, el artículo 33 del RGPD establece la obligación de notificar a la autoridad de control sin dilación indebida y, cuando sea posible, dentro de las 72 horas desde que el responsable tenga constancia de ella, salvo que sea improbable que entrañe un riesgo para los derechos y libertades. Cuando el riesgo sea alto, el artículo 34 puede exigir comunicación a las personas afectadas. DORA y el RGPD no tienen el mismo concepto de incidente ni el mismo destinatario. La coordinación debe estar diseñada antes del ataque.

La métrica que importa no es cuántos deepfakes detecta el sistema

Los proveedores suelen presentar tasas de detección que parecen tranquilizadoras hasta que se pregunta en qué condiciones se obtuvieron. Un modelo entrenado con vídeos de alta calidad puede rendir peor en una videollamada comprimida, con poca luz, distintos idiomas o una conexión móvil. La precisión media también puede ocultar un coste desigual: demasiados falsos positivos bloquean a clientes legítimos; demasiados falsos negativos dejan pasar ataques dirigidos.

El CISO y el responsable de fraude deberían medir el control con indicadores conectados al proceso de negocio. Entre ellos:

• Tasa de falsos negativos: cuántos intentos confirmados de suplantación superan la capa de detección.
• Tasa de falsos positivos: cuántas interacciones legítimas se derivan a revisión o se bloquean.
• Tiempo de detección y contención: cuánto transcurre entre la petición fraudulenta, la alerta, el bloqueo de fondos y la recuperación.
• Porcentaje de operaciones de alto riesgo con verificación independiente: mide si el control está realmente implantado o solo descrito en una política.
• Completitud de evidencias: proporción de casos en los que existen logs de identidad, decisión, aprobación, cambios de datos y respuesta.
• Deriva del modelo: cambios en el rendimiento después de nuevas técnicas de generación, modificaciones del proveedor o alteraciones en los canales.

El umbral no puede fijarse únicamente para maximizar la detección. Hay que calcular el coste de cada error. Un falso positivo en una consulta informativa no tiene el mismo impacto que en una transferencia de millones de euros. La política debe elevar la fricción de forma proporcional al riesgo y ofrecer una vía segura de recuperación para el cliente legítimo.

También conviene medir el factor humano. Una campaña interna puede registrar cuántos empleados intentan validar una orden por un canal alternativo, cuántos aceptan una urgencia no justificada y cuánto tarda la primera escalada. El objetivo no es humillar a quien cae en una simulación. Es descubrir si el procedimiento permite que una sola persona, bajo presión, pueda saltarse controles críticos.

Qué debe quedar preparado para una auditoría o una investigación

Una política que diga “se verificará la identidad por videollamada” no demuestra control. La evidencia debe mostrar que el procedimiento existía, se aplicó, fue supervisado y produjo una respuesta razonable. Para incidentes de suplantación y fraude sintético, el expediente debería poder reconstruir cinco momentos: la solicitud original, las señales de riesgo, la decisión de autorización, la intervención posterior y la revisión del control.

La documentación mínima debería incluir el inventario de casos de uso de IA, la clasificación de riesgos, los responsables del modelo o servicio, los datos utilizados, la fecha de cada cambio y los resultados de las pruebas. Si el sistema es de un tercero, deben conservarse el contrato, los niveles de servicio, los informes de evaluación, las notificaciones de cambios y la información necesaria para investigar un incidente.

Los logs necesitan especial atención. Registrar solo “aprobado” o “rechazado” es insuficiente. Deben permitir saber qué usuario inició la acción, desde qué dispositivo y canal, qué datos de la transacción se presentaron, qué reglas o modelos intervinieron, qué versión estaba desplegada, qué alerta se generó, quién la revisó y cuándo se liberaron los fondos. La conservación debe equilibrar DORA, RGPD, requisitos sectoriales y necesidades de litigación; guardar todo indefinidamente no es una política de retención, es una renuncia a gobernar los datos.

Un ejercicio de mesa útil puede plantear una videollamada falsa del director de operaciones, seguida de un cambio urgente de cuenta beneficiaria y una alerta del proveedor de identidad. El escenario debe obligar a decidir quién puede detener el pago, quién clasifica el incidente, quién informa al órgano de dirección, qué proveedor debe ser contactado, qué datos se preservan y cuándo se evalúa la notificación al supervisor y a los afectados. Si el ejercicio termina con “el equipo de fraude lo gestionará”, todavía no se ha probado la resiliencia.

El registro de decisiones también tiene valor. Si la entidad decide no utilizar reconocimiento facial, debe documentar por qué. Si adopta detección de voz, debe explicar sus límites y controles compensatorios. Si permite una excepción manual en una transferencia urgente, debe definir quién la autoriza, durante cuánto tiempo y con qué revisión posterior. La gobernanza creíble no consiste en prometer que el modelo nunca fallará; consiste en demostrar que la entidad sabe qué hará cuando falle.

La respuesta correcta es menos cinematográfica y más disciplinada

Los deepfakes llaman la atención porque parecen una demostración de magia tecnológica. Para el sector financiero, sin embargo, el riesgo no reside en si una cara parpadea de forma extraña. Reside en que un proceso de autorización confunda familiaridad con identidad y urgencia con legitimidad.

La defensa más eficaz combina autenticación resistente al phishing, confirmación fuera de banda, vinculación de la transacción, segregación de funciones, análisis de comportamiento y revisión humana proporcionada al riesgo. La detección de contenido sintético puede reforzar ese conjunto, pero no debe cargar con una responsabilidad que corresponde al diseño del proceso.

DORA obliga a tratar el problema como riesgo operativo digital, gestión de incidentes, pruebas y control de terceros. El artículo 50 del AI Act obliga a examinar cómo se marca y comunica determinado contenido generado o manipulado. El RGPD obliga a justificar el tratamiento de voz, vídeo, biometría y perfiles, y a preservar derechos cuando una decisión automatizada tiene consecuencias relevantes. Ninguna de estas normas ofrece un botón de “cumplimiento”. Todas exigen que la entidad pueda explicar qué hizo, por qué lo hizo y qué evidencia conserva.

La pregunta para un CISO no es si su organización puede detectar un vídeo falso en una pantalla. Es si una persona que solo dispone de una voz convincente puede ordenar un pago, cambiar un proveedor o recuperar una cuenta sin superar un control independiente. Si la respuesta es sí, el problema no es el deepfake. Es el proceso.