La IA Agéntica: El Nuevo Rostro del Fraude Digital a Escala Industrial

El fraude digital no necesitaba volverse más listo para seguir siendo rentable. Pero lo está haciendo. Y eso cambia menos el catálogo de amenazas que la escala, la velocidad y la capacidad de personalización con la que se ejecutan. Ahí está el verdadero problema para compliance, ciberseguridad y riesgo operativo: no tanto una categoría jurídica nueva, sino una aceleración muy seria de amenazas que las normas ya obligan a gobernar.

La expresión IA agéntica se ha colado en informes, presentaciones comerciales y debates regulatorios con una facilidad sospechosa. Suele aparecer envuelta en una mezcla de fascinación y humo. Conviene limpiar el terreno. Si hablamos de fraude, lo relevante no es bautizar una tecnología con una etiqueta elegante, sino entender qué efectos operativos produce: campañas más precisas, automatización de tareas fraudulentas, mayor volumen de intentos y una reducción del coste de lanzar ataques convincentes. Eso sí tiene consecuencias reales para los equipos que tienen que prevenir, detectar, responder y, después, explicárselo al regulador.

La pregunta, por tanto, no es si hace falta una norma específica para cada nueva variante de IA aplicada al fraude. La pregunta útil es otra: con el marco actual de DORA, NIS2, GDPR, AI Act y controles de gobernanza internos, ¿están las organizaciones cubriendo de verdad el aumento de sofisticación y volumen que ya tienen delante? En demasiados casos, la respuesta honesta es no.

El problema no es una definición brillante; es una capacidad operativa más barata y escalable

Conviene ser precisos. Sin una definición legal consolidada en la fuente de partida, atribuir a la llamada IA agéntica capacidades cerradas y uniformes es arriesgado. Lo que sí puede sostenerse con prudencia es que el uso de herramientas de IA en fraude digital permite automatizar procesos, ajustar mensajes, segmentar objetivos y aumentar la eficacia de ciertas campañas engañosas. Dicho en román paladino: el delincuente necesita menos esfuerzo para producir más ruido útil.

Eso tiene un efecto directo sobre los controles clásicos. Los filtros basados en patrones conocidos envejecen peor cuando el contenido fraudulento puede variarse con facilidad. Los equipos de atención al cliente reciben incidentes más ambiguos. Las funciones de segunda línea, que durante años han convivido con catálogos de riesgos bastante estables, empiezan a ver que el mismo riesgo descrito en la matriz produce incidentes distintos, más rápidos y a veces más difíciles de escalar internamente.

El matiz importa. No hace falta afirmar que estas herramientas “aprenden y se adaptan a las defensas de cada víctima” para reconocer el riesgo. Basta con observar que mejoran la personalización, la consistencia y el volumen de determinados intentos de fraude. Eso ya es suficiente para tensionar procesos de verificación, autenticación, respuesta a incidentes y supervisión de terceros.

El marco regulatorio ya llega, pero no de la forma que algunos venden

Una de las tentaciones más habituales en este debate es forzar las normas para que parezca que ya mencionan expresamente la amenaza de moda. No hace falta. De hecho, hacerlo mal debilita el argumento. NIS2 no habla de “IA agéntica” como tal. Lo que hace es imponer medidas de gestión de riesgos de ciberseguridad en términos suficientemente amplios como para abarcar amenazas emergentes, aunque no las nombre una por una.

El anclaje correcto está en el art. 21 de la Directiva (UE) 2022/2555, que exige medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar los riesgos que amenacen la seguridad de los sistemas de red y de información. Ese mismo artículo enumera, entre otros elementos, la gestión de incidentes, la continuidad de actividad, la seguridad de la cadena de suministro, la seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas, las políticas para evaluar la eficacia de las medidas de gestión de riesgos y la formación en ciberhigiene. No hace falta retorcer el texto: si una organización sabe que el fraude asistido por IA aumenta la presión sobre esos controles, el deber regulatorio ya está ahí.

Con DORA pasa algo parecido. El error común consiste en citar el art. 28 para hablar del marco general de gestión del riesgo TIC. No. El art. 28 del Reglamento (UE) 2022/2554 trata el riesgo derivado de terceros proveedores de servicios TIC. El marco general está antes: el art. 5 establece que las entidades financieras contarán con un marco interno de gobernanza y control que garantice una gestión eficaz y prudente del riesgo TIC, y los artículos 6 y siguientes desarrollan ese sistema de gestión del riesgo TIC, incluida la protección y prevención, la detección, la respuesta y recuperación, y el aprendizaje y evolución.

La consecuencia práctica es bastante clara. Si la amenaza se materializa a través de canales, herramientas o servicios soportados por terceros, entra de lleno el art. 28 y siguientes sobre gestión del riesgo de proveedores TIC. Si el problema es la capacidad interna de la entidad para prevenir, detectar y responder a intentos de fraude digital más sofisticados, el anclaje está en los artículos 5 a 15, no en el 28. Parece una sutileza. No lo es. Una referencia legal mal colocada en una política o en un informe al consejo es la clase de error tonto que un supervisor detecta en cinco minutos.

Donde de verdad aprieta: identidad, verificación y canales de confianza

El fraude digital mejorado por IA no exige imaginar escenarios de ciencia ficción. Basta con mirar tres puntos de fricción muy concretos. Primero, la identidad. Segundo, la verificación de instrucciones o comunicaciones. Tercero, la confianza depositada en canales que la organización da por buenos hasta que dejan de serlo.

En identidad, el choque regulatorio no se limita a ciberseguridad. También roza privacidad, control interno y, en determinados casos, firma electrónica y servicios de confianza. Cuando una organización revisa sus procesos de autenticación para frenar fraudes más convincentes, no puede olvidar que GDPR exige diseñar medidas apropiadas al riesgo en el tratamiento de datos personales. El art. 32 del Reglamento (UE) 2016/679 obliga al responsable y al encargado a aplicar medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo. Si el nuevo patrón de fraude incrementa el riesgo de suplantación o acceso indebido, el análisis de seguridad no puede quedarse congelado en el año en que se aprobó la política.

Y si el incidente termina comprometiendo datos personales, aparecen los plazos incómodos de siempre. El art. 33 GDPR exige notificar la violación de seguridad a la autoridad de control sin dilación indebida y, de ser posible, a más tardar 72 horas después de haber tenido constancia de ella. El art. 34 obliga a comunicarla a los interesados cuando sea probable que entrañe un alto riesgo para sus derechos y libertades. El fraude no siempre deriva en una brecha notificable, pero a veces sí. Ahí el truco retórico de separar “fraude” de “seguridad” deja de funcionar.

En verificación de instrucciones, el problema es más pedestre, y precisamente por eso más serio. Muchas compañías han reforzado controles de acceso, pero siguen manteniendo procesos de aprobación vulnerables a comunicaciones persuasivas, urgentes o muy bien contextualizadas. No hace falta sostener que una IA reproduzca “perfectamente” el estilo de una organización legítima para ver el riesgo. Basta con que mejore la plausibilidad del mensaje lo suficiente como para superar un filtro humano cansado, un proveedor con prisas o un empleado que trabaja en remoto con demasiadas ventanas abiertas y demasiado café encima.

El problema de fondo es que muchas matrices de riesgo siguen tratando el fraude como un bloque homogéneo. Eso ya no ayuda demasiado. Una cosa es un intento masivo y torpe. Otra, una campaña afinada contra procesos concretos de validación, proveedores concretos o colectivos internos con privilegios operativos. El riesgo base puede ser el mismo; la respuesta de control no debería serlo.

La cadena de suministro es un punto ciego demasiado cómodo

Si una organización depende de terceros para comunicaciones con clientes, verificación documental, soporte, analítica o detección de fraude, no puede analizar esta amenaza como si fuera exclusivamente interna. Y aquí DORA sí aprieta donde duele: en la pereza contractual.

Los artículos 28 a 30 de DORA obligan a gestionar el riesgo asociado a terceros proveedores de servicios TIC, mantener un registro de información sobre esos acuerdos y asegurar que los contratos cubren elementos concretos, incluidos derechos de acceso, inspección y auditoría, condiciones de rescisión y requisitos sobre disponibilidad, autenticidad, integridad y confidencialidad. Si un proveedor utiliza herramientas de IA dentro de un servicio crítico o importante, la entidad financiera no puede refugiarse en un “eso lo lleva el vendor”. Esa frase, tan popular en comités internos, no tiene ningún valor ante un supervisor.

NIS2, por su parte, también apunta a la cadena de suministro en el art. 21.2.d. No de forma ornamental, sino como una de las medidas mínimas de gestión de riesgos. La derivada es obvia: si tus controles antifraude dependen de terceros, tu diligencia no puede limitarse a pedir una ISO, archivar un cuestionario y dormir tranquilo. Necesitas entender qué hace ese proveedor, cómo valida resultados, qué dependencias arrastra y qué se activa cuando falla.

Aquí aparece una contradicción bastante europea. Se exige resiliencia operativa, pero en la práctica muchas organizaciones siguen comprando capacidades críticas como si fueran funciones periféricas. Luego llega el incidente, y todos descubren a la vez que nadie había definido con claridad quién validaba las decisiones automatizadas, quién revisaba las salidas anómalas o quién podía cortar el servicio sin paralizar media operación.

Gobernanza: el consejo no necesita una clase de IA, necesita un mapa de decisiones

Cuando se habla de nuevas amenazas, la gobernanza suele degradarse rápido en dos extremos igual de inútiles: o una sesión pedagógica llena de jerga técnica, o una presentación tranquilizadora que viene a decir que “se está monitorizando”. Ninguna de las dos resuelve gran cosa.

DORA es bastante más exigente de lo que algunos consejos querrían admitir. El art. 5 atribuye al órgano de dirección la responsabilidad última de definir, aprobar, supervisar y ser responsable de la aplicación del marco de gestión del riesgo TIC. No es una delegación decorativa al CISO ni un asunto que se salde con recibir un dashboard trimestral. Si la entidad identifica un aumento de fraude digital asistido por herramientas de IA, el consejo necesita decidir al menos cuatro cosas: el apetito de riesgo operativo aplicable, los procesos cuya verificación debe reforzarse, los terceros que exigen revisión prioritaria y el umbral a partir del cual un incidente se eleva por posible impacto regulatorio, operativo o reputacional.

Eso exige una gobernanza menos teatral y más concreta. ¿Qué escenarios se han ensayado? ¿Qué controles dependen todavía de aprobaciones manuales vulnerables a engaño? ¿Qué equipos pueden bloquear una transacción, una instrucción o una comunicación cuando detectan una anomalía? ¿Qué proveedor tiene capacidad real de afectar a la autenticidad o integridad de procesos críticos? Si esas preguntas no tienen respuesta clara, la organización no tiene un problema de terminología sobre IA. Tiene un problema de gobierno.

Ni alarmismo ni complacencia: lo que sí deberías estar haciendo ya

La respuesta razonable no pasa por sobrerregular cada novedad ni por fingir que nada cambia porque la norma no menciona la palabra de moda. Pasa por traducir un aumento de sofisticación del fraude en controles verificables. Algunos frentes son bastante evidentes.

• Revisar procesos de autenticación y verificación en operaciones sensibles, altas de cuentas, cambios de instrucciones de pago, reseteo de credenciales y comunicaciones con proveedores.
• Actualizar escenarios de riesgo e inteligencia de amenazas para reflejar campañas más personalizadas y automatizadas, en lugar de seguir modelando solo intentos genéricos.
• Reforzar controles sobre terceros cuando participen en onboarding, soporte, mensajería, analítica o detección de fraude, con base en DORA art. 28 y siguientes o, fuera del sector financiero, bajo la lógica de cadena de suministro de NIS2 art. 21.
• Conectar fraude, ciberseguridad y privacidad para que un incidente no quede mal clasificado entre silos internos y se pierdan plazos de análisis, contención o notificación.
• Elevar el asunto al consejo con decisiones, no con jerga: qué procesos se endurecen, qué riesgos se aceptan y qué dependencias tecnológicas exigen revisión inmediata.

No hace falta atribuir a NIST CSF 2.0 obligaciones textuales que aquí no están respaldadas para justificar este enfoque. Como marco, sigue siendo útil para ordenar gobierno, identificación, protección, detección, respuesta y recuperación. Pero si vas a citarlo en una política, cítalo bien y con la función o categoría exacta. Inventarse una prescripción detallada donde el marco habla en términos de resultados es una mala costumbre, y bastante extendida.

El sectorialismo también confunde

Otra tentación frecuente es adornar el debate con ejemplos sectoriales muy concretos que suenan plausibles pero no están respaldados por la fuente. Conviene evitarlo. No hace falta especular con registros médicos falsos, ni con escenarios particularmente cinematográficos, para demostrar el impacto. La cuestión transversal ya es suficientemente seria: cuando aumenta la capacidad de producir comunicaciones engañosas, automatizar intentos y explotar debilidades de proceso, sube la presión sobre controles de identidad, acceso, verificación, trazabilidad y gestión de incidentes en cualquier sector regulado.

En finanzas, además, el debate conecta con resiliencia operativa y terceros TIC bajo DORA. En servicios esenciales y entidades sujetas a NIS2, conecta con medidas de gestión de riesgos y cadena de suministro del art. 21. Si hay datos personales en juego, conecta con GDPR art. 32, y potencialmente con los arts. 33 y 34 si hay brecha de seguridad. No hace falta inflar el argumento. La intersección regulatoria ya es bastante densa por sí sola.

La conclusión incómoda

El uso de IA en fraude digital no obliga a reescribir desde cero el mapa regulatorio. Obliga a dejar de usarlo como decorado. Las normas europeas más relevantes ya exigen gestión del riesgo, seguridad de procesos, supervisión de terceros, gobernanza y respuesta a incidentes. El fallo habitual no está en la ausencia de base legal, sino en la distancia entre esa base legal y los controles reales de la organización.

Si tu entidad sigue tratando el fraude avanzado como una variante menor del phishing de siempre, vas tarde. Si tu consejo recibe presentaciones sobre IA pero no ha decidido qué procesos endurecer ni qué terceros revisar, también vas tarde. Y si tu equipo jurídico o de compliance sigue citando artículos incorrectos para dar apariencia de solidez, peor aún: vas tarde y mal.

Aquí el quid no es si el término IA agéntica acabará consolidándose o será reemplazado por la siguiente expresión de moda. El quid es que el fraude digital se está volviendo más escalable, más barato de ejecutar y más exigente para controles pensados para un ritmo anterior. La regulación ya te pide reaccionar. La pregunta de verdad es si lo estás haciendo antes del incidente o después.