Deepfakes y fraude con IA en banca: el control ya no es reconocer una voz, sino demostrarla

El riesgo no es que la IA se cuele en banca y seguros. Ese tren ya pasó. El riesgo real es otro: que muchas entidades siguen tratando la voz clonada, el documento sintético o el asistente conversacional como un problema de innovación, cuando en realidad ya es un problema de gobernanza, seguridad, privacidad y evidencia.

Ahí está la trampa. El mercado discute sobre casos de uso; el supervisor, sobre controles. Y entre una cosa y otra se abre un hueco bastante incómodo para cualquier entidad financiera que use IA en atención al cliente, onboarding, prevención del fraude, scoring, monitorización o soporte interno. No hace falta esperar a una norma milagrosa que lo ordene todo. Ya existe un bloque regulatorio que toca partes críticas del problema: AI Act, DORA, GDPR y NIS2. No lo cubre todo de forma perfecta, pero desde luego tampoco deja a las entidades en terreno virgen.

La pregunta útil, por tanto, no es si habrá regulación. La pregunta útil es si tu entidad ha entendido ya cómo se cruzan esas capas normativas cuando un sistema de IA altera procesos críticos, datos personales, autenticación, resiliencia operativa o respuesta a incidentes. Si no lo ha hecho, el problema no es teórico. Es de diseño, de contrato, de control interno y, llegado el caso, de responsabilidad del órgano de dirección.

El error de mirar la IA como una pieza aislada

Uno de los hábitos más persistentes en compliance tecnológico consiste en asignar cada novedad a su cajón favorito. Privacidad se ocupa de privacidad. Ciber, de ciber. Riesgo operacional, de continuidad. Legal, de contratos. Innovación, de IA. Suena ordenado. También es una buena forma de perder de vista el problema.

Con la IA, ese enfoque se queda corto muy rápido. Un motor de verificación documental apoyado en modelos generativos puede afectar a la calidad de la autenticación, a la trazabilidad de la decisión, al tratamiento de datos biométricos o identificativos, al riesgo de suplantación y a la dependencia de un proveedor tecnológico. Un asistente interno que resume incidencias puede exponer datos sensibles a un tercero. Un sistema antifraude entrenado con datos históricos puede degradar la detección si no se gobierna bien el ciclo de vida del modelo. Y un canal de atención que usa voz sintética o detección automatizada puede acabar produciendo efectos operativos bastante más serios de lo que sugería la demo comercial.

Por eso conviene abandonar cuanto antes la idea de que la IA se regula sola bajo una única norma. No es así. El AI Act introduce una capa específica para sistemas de IA y determinados usos; GDPR sigue marcando el terreno cuando hay datos personales, en especial si hablamos de base jurídica, minimización, transparencia, decisiones automatizadas y seguridad del tratamiento; DORA entra cuando esos sistemas afectan a la resiliencia operativa digital de entidades financieras; y NIS2 presiona sobre gestión de riesgos de ciberseguridad, gobernanza y notificación para entidades incluidas en su ámbito o para actores conectados a ellas en la cadena de suministro.

Leído así, el panorama parece obvio. Operarlo ya no lo es tanto.

No hay una norma única para el riesgo IA en finanzas. Hay una superposición incómoda

La tentación de muchas organizaciones será construir un “programa AI Act” y dar por resuelto el asunto. Es comprensible. Tiene nombre corto, titulares fáciles y promesa de orden. El problema es que, en una entidad financiera, la cuestión rara vez acaba en el perímetro del AI Act.

Si el sistema usa datos personales, el GDPR sigue mandando en cuestiones nada menores: principios del artículo 5, base jurídica del artículo 6, protección de datos desde el diseño y por defecto del artículo 25, seguridad del tratamiento del artículo 32, notificación de violaciones de seguridad del artículo 33 y, cuando proceda, decisiones individuales automatizadas del artículo 22. Eso no desaparece porque el proveedor venda el producto como “IA explicable”. La pegatina comercial no deroga el Reglamento.

Si además ese sistema participa en funciones relevantes para la prestación del servicio financiero, la gestión de fraude, el onboarding, la atención al cliente o cualquier proceso conectado con la continuidad operativa, aparece DORA. Y DORA no pregunta si la herramienta era innovadora o si el caso de uso parecía modesto en el comité de transformación. Pregunta por gobernanza, identificación de activos y dependencias, gestión del riesgo TIC, detección, respuesta, recuperación, aprendizaje y relación con terceros tecnológicos. Es decir: por las piezas que suelen descuidarse cuando la conversación se centra solo en precisión del modelo o productividad.

NIS2 añade otra presión que a menudo se subestima. Su artículo 21 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 lista incluye gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, seguridad en adquisición, desarrollo y mantenimiento, políticas para evaluar la eficacia de medidas y prácticas básicas de ciberhigiene, entre otras. Si una entidad o un proveedor relevante entra en ese radio, la IA deja de ser una cuestión de laboratorio y pasa a ser un componente más del mapa de exposición.

Lo interesante aquí es la fricción entre normas. No porque se contradigan de forma frontal, sino porque obligan a mirar el mismo sistema desde ángulos distintos. Un responsable de privacidad preguntará qué datos entran, con qué base y con qué garantías. Un responsable de resiliencia preguntará qué pasa si el sistema falla, deriva o queda indisponible. Seguridad preguntará si el modelo puede ser manipulado, inducido a fuga de información o utilizado como vector de acceso. Compras preguntará qué poder real tiene la entidad frente al proveedor. El consejo, si hace bien su trabajo, debería preguntar quién responde cuando todo eso se mezcla en un incidente de verdad.

Lo que sí cambia con el AI Act, y lo que no conviene exagerar

Con la IA suele ocurrir una cosa curiosa: algunos departamentos la presentan como si no hubiera reglas; otros, como si la nueva regulación fuera a resolver por sí sola cada ángulo del problema. Ninguna de las dos posturas aguanta mucho análisis.

Lo que sí puede afirmarse con seguridad es que el AI Act introduce obligaciones específicas para ciertos sistemas de IA y reglas de transparencia para determinados supuestos de interacción o generación de contenido. También establece un régimen más exigente para los sistemas de alto riesgo, con obligaciones de gobernanza de datos, documentación, supervisión humana, robustez y gestión del riesgo dentro del propio marco del Reglamento. Esa capa importa, y mucho, para entidades financieras que desarrollen, integren o usen sistemas encuadrables en esos supuestos.

Ahora bien, conviene no atribuir al texto más precisión de la que aquí puede sostenerse con la fuente disponible. Cuando se habla de contenidos generados o manipulados por IA, la idea jurídicamente relevante es la existencia de obligaciones de transparencia en determinados casos. Ese punto sí forma parte del debate regulatorio y es operativo para sectores donde la confianza del cliente y la autenticidad de la interacción importan tanto como en finanzas. Lo que no conviene hacer es convertir esa idea en una cita milimétrica no respaldada por la fuente declarada. En otras palabras: hay deberes de transparencia para ciertos contenidos generados o manipulados por IA, pero el análisis interno de la entidad debe descansar en la letra exacta aplicable y en validación jurídica propia antes de traducirlo a controles o mensajes al cliente.

Esta cautela no rebaja la relevancia del asunto. La aumenta. Porque obliga a las entidades a trabajar con precisión documental, no con presentaciones comerciales. Si un banco usa herramientas capaces de generar voz, imagen o texto que puedan inducir a error sobre la naturaleza de la interacción, el debate no es solo reputacional. También afecta a cómo diseña avisos, cómo documenta el uso, cómo mitiga fraude por suplantación y cómo conserva evidencias para auditoría o revisión supervisora.

DORA no va de “ciber” en abstracto. Va de disciplina operativa

En muchas entidades, DORA se sigue leyendo como una norma de ciberseguridad con otro nombre. Es una lectura cómoda. También insuficiente.

El núcleo de DORA, en lo que interesa a la IA, está en la exigencia de un marco de gestión del riesgo relacionado con las TIC bajo responsabilidad del órgano de dirección y con integración real en gobierno, procesos, detección, respuesta y continuidad. La fuente disponible menciona expresamente los artículos 5 y 6, que son un buen recordatorio de dónde empieza la conversación: gobernanza y marco de gestión del riesgo TIC. A partir de ahí, la lógica de DORA alcanza también la gestión y notificación de incidentes, aunque aquí conviene mantener la referencia en términos generales si la fuente no detalla un mapa completo por rangos de artículos.

¿Qué significa eso en la práctica cuando hablamos de IA? Significa que una entidad no debería limitarse a evaluar si el modelo “funciona”. Tiene que evaluar si la dependencia tecnológica asociada al modelo compromete tolerancias operativas, si existen vías de degradación segura, si hay capacidad de detección de salidas anómalas, si la integración con procesos críticos genera puntos únicos de fallo y si los equipos de respuesta sabrían gestionar un incidente donde la causa raíz mezcla proveedor externo, configuración deficiente y comportamiento no previsto del sistema.

Ese es el punto que a menudo se escapa. La IA introduce riesgo técnico, sí, pero sobre todo redistribuye riesgo organizativo. Cambia quién entiende el proceso, quién puede auditarlo, quién controla el dato de entrada, quién valida la salida y quién tiene la palanca contractual si el proveedor falla. DORA, leído con un mínimo de atención, obliga precisamente a ordenar esas dependencias.

Además, cuando la herramienta de IA está conectada a funciones significativas, el problema deja de ser puramente tecnológico y pasa a ser de resiliencia del negocio. Si una entidad usa automatización basada en IA para priorizar alertas de fraude, clasificar tickets críticos, asistir decisiones de soporte o verificar documentación de clientes, un fallo sostenido puede producir retrasos, errores de clasificación, cuellos de botella o decisiones defectuosas. Ninguna de esas consecuencias necesita ciencia ficción para materializarse. Basta una integración mal gobernada y una confianza excesiva en la herramienta.

El ángulo de terceros: donde muchas estrategias brillantes se vuelven terrenalmente vulnerables

La mayor parte de las iniciativas de IA en finanzas no se construyen desde cero. Se compran, se integran, se personalizan o se consumen como servicio. Ahí entra una verdad bastante menos glamurosa que las demos: la exposición de la entidad depende de un tercero, o de varios, más de lo que a veces se admite en el comité.

La fuente de referencia sí apunta a la supervisión de terceros TIC en DORA, y con eso basta para extraer una conclusión sólida: cualquier uso relevante de IA en una entidad financiera exige revisar la dependencia del proveedor como un asunto de resiliencia y control, no solo de procurement. Si el sistema se presta desde infraestructura ajena, si el modelo se actualiza por decisión del proveedor, si la monitorización la hace un tercero o si ciertos datos salen del perímetro habitual de la entidad, hay una dependencia material que debe gobernarse.

No conviene aquí fingir una precisión contractual no respaldada por la fuente concreta. Pero sí puede decirse algo que toda entidad debería tomar en serio: el análisis de terceros no se agota en la firma del contrato ni en un cuestionario de seguridad previo al alta. Requiere entender qué servicio exacto se presta, qué parte del proceso soporta, qué evidencias entregará el proveedor, cómo se gestionarán incidentes, qué visibilidad conservará la entidad y qué margen tendrá para exigir cambios, limitar usos o interrumpir el servicio sin provocar un problema mayor.

La ironía es conocida. Muchas organizaciones hablan de “IA propia” cuando en realidad operan una cadena bastante compleja de dependencias externas: modelos de base, APIs, herramientas de observabilidad, alojamiento cloud, componentes de identidad, librerías de terceros y soporte especializado. Luego llega la revisión de riesgo y aparece la pregunta incómoda: ¿quién controla de verdad el comportamiento del sistema cuando algo sale mal? Si la respuesta es difusa, no hay estrategia de IA; hay delegación con esperanza.

GDPR sigue siendo el regulador silencioso de casi todo esto

En los proyectos de IA financiera, el GDPR a veces se presenta como una fase documental: inventario de datos, cláusulas, DPIA si toca, y a seguir. Ese enfoque es demasiado estrecho para el tipo de riesgos que hoy plantean modelos generativos, sistemas de verificación o automatización intensiva.

El artículo 5 del GDPR no es retórica. Obliga a trabajar con limitación de finalidad, minimización, exactitud, integridad y confidencialidad. Si una entidad reutiliza datos recogidos para una finalidad concreta en un sistema de IA distinto, la pregunta sobre compatibilidad de finalidades no desaparece por arte de magia. Si el sistema requiere grandes volúmenes de datos “por si acaso”, la minimización sigue aplicando. Si los resultados del modelo pueden generar errores materiales sobre personas, la exactitud importa. Mucho.

El artículo 25, sobre protección de datos desde el diseño y por defecto, tiene una consecuencia práctica bastante menos decorativa de lo que algunos querrían: obliga a incorporar límites y salvaguardas antes del despliegue, no después del incidente. Eso afecta a configuraciones por defecto, control de acceso, filtrado de datos de entrada, separación de entornos, registro de actividad y revisión de prompts o instrucciones cuando el sistema interactúa con datos personales.

El artículo 32, sobre seguridad del tratamiento, también merece leerse sin automatismos. Porque el riesgo no se limita a la intrusión clásica. En IA pueden aparecer exposiciones por fuga en prompts, respuestas que revelan información sensible, entrenamiento o ajuste sobre datos inadecuadamente gobernados, o integraciones con herramientas externas que multiplican la superficie de ataque. Si además se produce una violación de seguridad de datos personales, el artículo 33 activa la notificación a la autoridad de control en los supuestos previstos por el Reglamento. Y si la incidencia genera un alto riesgo para los derechos y libertades de las personas, el artículo 34 entra en juego respecto de la comunicación a los interesados.

La pieza más delicada, en ciertos usos, es el artículo 22 sobre decisiones individuales automatizadas. No todo sistema de IA lo activa. Pero cuando una decisión produce efectos jurídicos o afecta significativamente de modo similar a una persona, la entidad no debería tratar el análisis como una casilla más. Debería preguntarse si la automatización es real, qué margen de intervención humana existe, si esa intervención es sustantiva o meramente decorativa y cómo se explica la lógica aplicada de forma comprensible. Muchas organizaciones aseguran que “siempre hay un humano en el proceso”. La experiencia demuestra que a veces ese humano solo confirma lo que la máquina ya decidió. El regulador, previsiblemente, sabrá distinguir una supervisión real de una firma al final del flujo.

Biometría, suplantación y confianza: menos marketing, más control

Cuando la IA entra en procesos de onboarding, autenticación asistida, detección de fraude o atención remota, el discurso comercial tiende a prometer fricción cero y confianza reforzada. Luego aparecen los deepfakes, la clonación de voz, los documentos sintéticos y las campañas de ingeniería social apoyadas en automatización. Y la fricción vuelve, pero esta vez con abogados, equipos de fraude y responsables de continuidad en la misma sala.

Sin recurrir a afirmaciones no respaldadas sobre otros marcos, basta con mirar GDPR y NIS2 para entender que la cuestión ya es seria. Si el tratamiento implica datos personales —y en estos procesos casi siempre ocurre— el GDPR empuja a justificar finalidades, limitar datos, reforzar seguridad y documentar decisiones de diseño. Si la autenticación, la prevención de suplantación o la detección de anomalías forman parte del sistema de seguridad de una entidad o de un proveedor cubierto, NIS2 obliga a tratar esos riesgos dentro de una política más amplia de gestión de seguridad, incidentes y cadena de suministro, conforme a su artículo 21.

La consecuencia operativa es bastante prosaica: no basta con comprar una solución de verificación o una capa antifraude con “detección de deepfakes” en la ficha comercial. Hay que probarla, integrarla en procesos de escalado, definir umbrales, conservar evidencias y entender qué ocurre cuando la herramienta falla en un pico de demanda o genera falsos positivos que bloquean clientes legítimos. El equilibrio entre seguridad y experiencia de cliente sigue siendo necesario; lo que ha cambiado es que la IA añade una nueva clase de fallo, a veces difícil de explicar y bastante fácil de subestimar.

El consejo de administración ya no puede fingir que esto es un asunto de especialistas

Uno de los cambios más interesantes del momento regulatorio europeo es que varias normas empujan la responsabilidad hacia arriba. Ya no basta con que el tema quede encerrado entre tecnología, seguridad y legal. Cuando una herramienta de IA toca operaciones esenciales, clientes, fraude, continuidad o datos personales, la conversación llega al órgano de dirección sí o sí.

DORA es especialmente clara en esa lógica de responsabilidad de gobierno a través del marco de gestión del riesgo TIC mencionado en la fuente y articulado desde sus disposiciones iniciales sobre gobernanza. NIS2 también eleva el listón al exigir implicación de los órganos de dirección en la aprobación y supervisión de medidas de gestión del riesgo de ciberseguridad. Y el GDPR lleva años dejando claro que la responsabilidad proactiva no es una teoría estética, sino una obligación demostrable.

Traducido al idioma que entiende un consejo: si la entidad despliega o consume IA en procesos relevantes, debe poder explicar qué inventario existe, qué casos de uso están autorizados, qué riesgos se han evaluado, qué límites se han impuesto, quién aprueba excepciones, qué proveedores son críticos, qué plan hay si el sistema falla y cómo se detecta una salida anómala antes de que se convierta en un problema para clientes o supervisores.

Si no puede responder a eso con documentos, responsables y evidencias, el problema no es que falte una política bonita. El problema es que falta gobierno real.

Qué debería revisar ahora una entidad financiera

No hace falta inventar un programa mastodóntico para empezar a corregir el rumbo. Hace falta priorizar bien. El orden lógico no arranca en la herramienta, sino en el proceso que esa herramienta altera.

Primero, inventario de casos de uso con clasificación de criticidad. No una lista de proyectos de innovación, sino un mapa que conecte cada sistema de IA con proceso de negocio, datos implicados, proveedor, grado de automatización, posibilidad de impacto en clientes y dependencia operativa. Si la entidad no tiene ese mapa, cualquier debate regulatorio posterior será parcialmente ficticio.

Segundo, análisis cruzado de obligaciones. Para cada caso de uso relevante, conviene identificar qué capa normativa entra de forma más evidente: AI Act si procede por la naturaleza del sistema o del uso; GDPR si hay tratamiento de datos personales; DORA si afecta a resiliencia operativa digital en una entidad financiera; NIS2 si el caso encaja en el régimen de ciberseguridad aplicable a la organización o a proveedores críticos. Aquí el error más común es hacer evaluaciones separadas que nunca se reconcilian. Luego llega una incidencia y cada equipo descubre una versión distinta del mismo sistema.

Tercero, revisión de terceros. No solo del proveedor principal, también de subprocesadores, integradores, componentes de modelo, infraestructura y herramientas de monitorización si resultan materialmente relevantes. La pregunta no es si todos parecen solventes en un Excel. La pregunta es qué dependencia real crean y qué capacidad conserva la entidad para supervisar, exigir evidencias, reaccionar ante incidentes y sustituir el servicio si hace falta.

Cuarto, controles técnicos y operativos adaptados al caso. Eso puede incluir segregación de entornos, restricciones de uso de datos, validación humana real en decisiones sensibles, monitorización de resultados anómalos, pruebas de resiliencia, registros suficientes para investigación y protocolos de escalado cuando se detectan errores sistemáticos, fuga de información o posible manipulación.

Quinto, plan de respuesta. Si un sistema de IA genera un incidente de seguridad, privacidad, continuidad o fraude, ¿quién lo detecta?, ¿quién decide si se aísla?, ¿qué evidencias se preservan?, ¿qué proveedor debe intervenir?, ¿hay obligación de notificación bajo GDPR o bajo otros marcos sectoriales?, ¿cómo se evita que el equipo tarde horas en decidir si el problema es “de datos”, “de ciber” o “de negocio”? Ese tiempo muerto es carísimo, aunque no siempre figure en el presupuesto.

La objeción habitual: “esto frenará la innovación”

La frase aparece siempre, como las alergias en primavera. Tiene parte de verdad y bastante de pereza intelectual.

Sí, exigir inventario, gobierno, evaluación jurídica y control de terceros ralentiza ciertos despliegues. También evita que una entidad meta en producción herramientas que nadie entiende del todo, sobre procesos que nadie ha mapeado bien, con proveedores que nadie sabe cómo supervisar. Llamarlo “freno a la innovación” es una forma elegante de no llamar a las cosas por su nombre: disciplina mínima.

Además, la innovación útil en servicios financieros no depende solo de lanzar antes. Depende de sostener el servicio, defenderlo frente a fraude y justificarlo ante supervisores y clientes. Un caso de uso que reduce tiempos de atención pero dispara exposición de datos, degrada controles antifraude o crea dependencia ciega de un tercero no es innovación madura. Es deuda operativa con branding.

La buena noticia es que las entidades que hagan este trabajo en serio no solo estarán mejor colocadas para cumplir. También estarán mejor preparadas para escalar. Porque entenderán sus dependencias, sabrán qué casos de uso soportan mayor escrutinio y tendrán una base probatoria más sólida cuando el supervisor pregunte cómo gobiernan la IA en procesos relevantes. Y preguntará.

Lo que viene no es una pelea entre normas, sino una prueba de madurez

Conviene resistirse a una lectura simplona del momento regulatorio. No estamos ante una competición entre AI Act, DORA, GDPR y NIS2 para ver cuál manda más. Estamos ante una prueba de madurez para organizaciones que ya operan con sistemas complejos, proveedores múltiples y presión creciente sobre seguridad, resiliencia y confianza.

La IA ha hecho más visible una verdad incómoda que el sector financiero conoce desde hace años: cuando una tecnología toca procesos críticos, datos sensibles y experiencia del cliente, el riesgo nunca viene en un solo paquete. Llega mezclado. Y obliga a responder con una gobernanza igual de mezclada.

Ese es el criterio útil para los próximos meses. Menos fascinación por la herramienta. Más atención al proceso, al dato, al tercero y a la evidencia. Menos discursos de “adopción responsable” redactados por marketing. Más decisiones incómodas sobre qué usos no deben escalar todavía, qué proveedores exigen un control más severo y qué equipos tienen que sentarse juntos aunque no les entusiasme la idea.

Porque, al final, la cuestión no es si la IA entrará en el perímetro regulatorio financiero. Ya está dentro, por varias puertas a la vez. La cuestión es si las entidades van a gobernarla como una capacidad crítica o como un experimento prolongado. Y esa diferencia, cuando aparece un incidente de verdad, se nota enseguida.