La IA agentica ya ha llegado a finanzas. El supervisor global acaba de admitir que los controles se han quedado viejos

La IA agéntica no encaja bien en los cajones regulatorios clásicos. Ese es el problema de fondo. No porque la ley europea no diga nada útil, sino porque reparte las piezas entre varias normas y varias funciones internas: riesgo operativo, terceros TIC, ciberseguridad, protección de datos, gobierno corporativo y, en algunos casos, regulación de IA. Quien espere un artículo único que lo resuelva todo va tarde. Y quien crea que basta con pasar el caso de uso por el comité de modelos también.

El debate se ha acelerado porque los agentes no son solo otro chatbot con mejor marketing. Pueden encadenar tareas, invocar herramientas, consultar sistemas internos y externos, tomar decisiones dentro de límites predefinidos y generar acciones con efectos operativos reales. Ahí cambia la conversación regulatoria. Ya no hablamos solo de exactitud de respuestas o de sesgo. Hablamos de permisos, trazabilidad, dependencia de terceros, validación de resultados, gestión de incidentes y capacidad de cortar el servicio sin dejar una ruina detrás.

Eso obliga a leer el problema con varias gafas a la vez. DORA no regula la IA como tal, pero sí regula una parte decisiva del riesgo que suele acompañarla cuando se despliega en entidades financieras: la dependencia tecnológica, la resiliencia operativa y la gestión de proveedores TIC. El GDPR tampoco va de agentes, pero entra de lleno si el sistema trata datos personales, y su art. 5 sobre principios, el art. 25 sobre protección de datos desde el diseño y por defecto, el art. 32 sobre seguridad del tratamiento y, llegado el caso, los arts. 33 y 34 sobre brechas, dejan poco margen para la improvisación. Si además el caso de uso cae dentro del AI Act, aparecen obligaciones adicionales de gobernanza, documentación, supervisión humana y gestión del riesgo. No es un paisaje simple. Tampoco es una selva sin mapa.

El error más común: tratar un agente como si fuera solo software

La discusión se enreda cuando una entidad analiza un agente con marcos pensados para aplicaciones más estáticas. Ese enfoque se queda corto. Un agente puede cambiar de contexto, llamar a otros servicios, usar herramientas conectadas por API y producir salidas que disparan actos internos o externos. No hace falta antropomorfizarlo ni bautizarlo con ocurrencias sobre “empleados sintéticos”, una fórmula que no conviene atribuir al FSB sin una base documental clara. Basta con describir lo relevante: es un componente con autonomía funcional limitada, conectado a procesos, datos y proveedores, y por tanto con capacidad para amplificar fallos técnicos, errores de configuración y decisiones mal gobernadas.

A efectos de control interno, la pregunta útil no es si “piensa”. La pregunta útil es otra: qué puede hacer, con qué datos, en qué sistemas, bajo qué límites, con qué supervisión y con qué salida de emergencia. Si tu entidad no puede responder eso por escrito, el problema no es filosófico. Es de gobierno.

Aquí aparece una ironía regulatoria bastante europea: la pieza más crítica no siempre está en la norma que menciona “IA”, sino en la norma que obliga a saber de qué dependes cuando algo falla. DORA es un buen ejemplo.

DORA no te pide amar a tus proveedores; te pide no perder el control

Conviene afinar. Decir que “DORA artículo 28 exige a la entidad saber exactamente qué dependencia ha creado, qué funciones son críticas o importantes y qué cláusulas contractuales necesita” es impreciso si se atribuye todo al mismo precepto. DORA distribuye esas obligaciones entre varios artículos, y esa precisión importa porque de ella depende cómo aterrizas el control.

El art. 28 establece principios clave para la gestión del riesgo derivado de terceros proveedores de servicios TIC. Ahí se deja claro que las entidades siguen siendo plenamente responsables del cumplimiento de sus obligaciones, también cuando externalizan. No hay escapatoria contractual elegante. El proveedor puede prestar el servicio; la responsabilidad regulatoria no viaja con la factura.

Pero el detalle operativo se reparte. El art. 29 exige una estrategia sobre riesgo de terceros TIC y una política sobre el uso de servicios TIC para apoyar funciones de negocio, incluido el uso respecto de funciones críticas o importantes. El art. 30 entra en el contenido mínimo de los acuerdos contractuales, con elementos como la descripción completa de funciones y servicios, lugares de prestación, disposiciones sobre disponibilidad, autenticidad, integridad y confidencialidad, acceso, recuperación y devolución de datos, niveles de servicio, asistencia en incidentes, cooperación con autoridades competentes y derechos de acceso, inspección y auditoría. El art. 31 añade exigencias adicionales cuando se trata de servicios TIC que apoyan funciones críticas o importantes, y el art. 28 también conecta con la necesidad de mantener un registro de información en relación con todos los acuerdos contractuales sobre servicios TIC.

Traducido al castellano de trinchera: si un agente depende de modelo, infraestructura, herramientas externas, observabilidad, almacenamiento vectorial o cualquier otra capa TIC prestada por terceros, la entidad necesita mapear esas dependencias de forma suficientemente granular para poder clasificarlas, contratarlas y supervisarlas con arreglo a DORA. No hace falta afirmar nada que el artículo no diga. Hace falta leer el reglamento completo sin recortarlo a conveniencia.

Y aquí está el quid: muchas organizaciones todavía inventarian “el proveedor de IA” como si fuera una sola caja. En la práctica, el riesgo puede estar fragmentado entre varias capas técnicas y contractuales. DORA no usa el lenguaje de moda de Silicon Valley, pero su lógica va justo contra esa pereza documental.

La cadena de dependencia importa aunque el regulador no te haga una lista cerrada

No hace falta sostener con cifras no verificadas que “muchas implementaciones” del mercado dependen de pocos proveedores para llegar a una conclusión útil. Basta con una constatación operativa: un despliegue de IA agéntica puede incorporar varios terceros TIC distintos, y cada uno introduce un vector de dependencia, indisponibilidad, cambio técnico o restricción contractual. Ese simple hecho ya activa obligaciones claras de identificación, supervisión y control bajo DORA.

La entidad debe preguntarse, como mínimo, qué servicio presta cada tercero, si ese servicio soporta una función crítica o importante, qué subcontrataciones existen, qué derechos de auditoría tiene, qué pasa con los datos al terminar el contrato y cuál es el plan de salida. DORA aprieta justo ahí porque el fallo de resiliencia no suele venir envuelto en una etiqueta académica. Llega como interrupción, degradación, pérdida de integridad, opacidad contractual o imposibilidad de migrar a tiempo.

Un agente puede parecer un producto compacto en la demo y una sopa de dependencias en producción. El regulador, por desgracia para los equipos de ventas, mira más la segunda foto que la primera.

No es solo IA. Es también seguridad, datos y capacidad de intervención

Si el agente trata datos personales, el GDPR entra sin pedir permiso. El art. 5 obliga a respetar principios como minimización de datos, limitación de la finalidad e integridad y confidencialidad. El art. 25 exige protección de datos desde el diseño y por defecto. El art. 32 impone medidas técnicas y organizativas apropiadas al riesgo. Si el agente genera una brecha de seguridad que afecte a datos personales, el art. 33 obliga a notificarla a la autoridad de control sin dilación indebida y, cuando sea posible, en un plazo máximo de 72 horas desde que el responsable tenga constancia; el art. 34 puede obligar además a comunicarla a los interesados.

Esto tiene consecuencias prácticas muy poco glamourosas y muy concretas. Si un agente consulta más datos de los necesarios para completar una tarea, el problema no es solo de arquitectura. Puede ser un problema de minimización. Si la entidad no puede reconstruir qué instrucción se dio, qué herramienta se llamó y qué datos se expusieron, el problema no es solo de observabilidad. Puede ser un problema de accountability. Si el proveedor impide o dificulta auditorías razonables, el choque no es solo comercial. Puede convertirse en un choque regulatorio.

La ciberseguridad añade otra capa. En el sector financiero, DORA exige un marco interno de gestión del riesgo TIC con capacidades de identificación, protección, detección, respuesta y recuperación, articuladas en su capítulo II. Para un agente, eso obliga a algo muy sencillo de decir y bastante menos sencillo de implantar: registrar acciones, controlar privilegios, limitar herramientas, segmentar accesos, probar escenarios de abuso y asegurar que existe una forma fiable de desactivar, aislar o degradar el servicio sin comprometer el proceso de negocio completo.

Donde más se nota el cambio: en los permisos y en el radio de acción

Un ejemplo hipotético sirve para entender el problema, siempre que lo tratemos como eso, un ejemplo. Imagina un agente desplegado para apoyar operaciones de fraude o atención al cliente. Podría integrarse con sistemas como correo corporativo, CRM, repositorios documentales, plataformas de tickets o herramientas de pagos, si la entidad decidiera diseñarlo así. En ese supuesto, el riesgo no reside solo en la calidad de la respuesta. Reside en el perímetro de acción que la entidad le conceda y en la capacidad de demostrar, ex post, por qué hizo lo que hizo.

Ese tipo de arquitectura abre preguntas regulatoriamente serias:

• Acceso: ¿el agente opera con privilegios propios, delegados o heredados del usuario?
• Trazabilidad: ¿queda constancia de las instrucciones, datos consultados, herramientas invocadas y acciones ejecutadas?
• Supervisión humana: ¿hay revisión previa para actos sensibles o revisión posterior basada en umbrales de riesgo?
• Limitación funcional: ¿puede iniciar acciones irreversibles o solo proponerlas?
• Contención: ¿existe un mecanismo de parada y una degradación segura?

No hace falta dramatizar diciendo que esto “activa a medio organigrama regulatorio”. Lo verificable es suficiente: obliga, al menos, a coordinar funciones que suelen vivir en marcos distintos, porque las decisiones sobre permisos, datos, terceros TIC, continuidad, incidentes y cumplimiento no se resuelven dentro de un único equipo.

El AI Act complica menos de lo que parece y más de lo que se admite

Mucho ruido con el AI Act, sí, pero conviene situarlo bien. El reglamento europeo de IA no convierte cualquier agente en sistema de alto riesgo por arte de magia. La calificación depende del uso y del contexto, especialmente de los casos recogidos en su anexo III o de si el sistema funciona como componente de seguridad de un producto regulado. Aun así, incluso cuando un caso no sea de alto riesgo, la entidad no queda libre de obligaciones si usa modelos de propósito general sujetos a las reglas específicas del reglamento o si el despliegue interactúa con datos personales, decisiones operativas y terceros TIC bajo otros marcos normativos.

Además, el AI Act introduce una lógica de gobernanza que encaja incómodamente bien con los agentes: documentación técnica, instrucciones de uso, supervisión humana, gestión del riesgo y calidad de los datos donde proceda. Lo incómodo no es el texto. Lo incómodo es que desmonta la ficción de que basta con aprobar un principio ético y dejar que ingeniería ya vaya viendo.

Durante años, una parte de la gobernanza de IA en servicios financieros se ha concentrado en marcos de riesgo de modelo, validación, explicabilidad o sesgo cuando el caso de uso lo requería. Esa aproximación sigue siendo útil, pero no agota el problema de un sistema que además ejecuta tareas, consume servicios de terceros y opera dentro de flujos empresariales. No hace falta afirmar que “la mayoría” de los programas del sector nacieron así para ver la limitación. Se observa caso por caso: un control pensado para evaluar la calidad de un modelo no sustituye a un control de privilegios, ni a una cláusula contractual de auditoría, ni a un plan de salida bajo DORA.

Lo que sí cambia con un agente: el objeto de control se vuelve híbrido

La novedad relevante no es que distintas funciones internas “miren el mismo objeto por primera vez”. Esa formulación es demasiado categórica. Lo que sí puede afirmarse con prudencia es algo más útil: un agente combina elementos que suelen repartirse entre marcos de control distintos. Tiene rasgos de sistema de IA, de servicio TIC, de componente de proceso operativo y, a menudo, de tratamiento de datos personales. Por eso un análisis fragmentado suele fallar.

Si el área de IA evalúa el rendimiento del sistema pero no sus dependencias contractuales, falta una pieza. Si compras negocia el proveedor sin entender el caso de uso y sus límites de supervisión, falta otra. Si seguridad revisa autenticación y logs pero no el alcance funcional de las acciones permitidas, también. El regulador no necesita redactar una metáfora brillante para que el mensaje sea claro: el control debe ser integral porque el riesgo también lo es.

Y aquí aparece una verdad poco heroica: la coordinación interna vale menos por el discurso y más por la evidencia documental. Quién aprueba el caso de uso, quién acepta el riesgo residual, qué umbrales disparan revisión humana, qué proveedor soporta qué función, qué plan de reversión existe y qué incidentes obligan a escalar. Si eso no está escrito, gobernado y probado, la alineación interfuncional es solo una reunión recurrente con diapositivas bonitas.

Cómo aterrizarlo sin convertir el proyecto en una tesis doctoral

La forma sensata de gobernar IA agéntica en entidades financieras no empieza con un comité nuevo. Empieza con un inventario serio y una clasificación útil. Cuatro preguntas ordenan bastante bien el trabajo inicial.

1. Qué hace exactamente el agente

No “para qué sirve” en una frase comercial, sino qué acciones puede ejecutar, qué recomendaciones emite, qué herramientas invoca y qué decisiones quedan automatizadas o semiautomatizadas. Si la descripción funcional no soporta un análisis de permisos, no está terminada.

2. Qué datos toca y con qué base

Aquí entran categorías de datos, fuentes, retención, minimización, segregación y, si procede, bases jurídicas bajo GDPR. No es lo mismo consultar una base documental interna anonimizada que operar sobre datos identificables de clientes. Tampoco es lo mismo resumir que accionar.

3. De qué terceros TIC depende

La respuesta correcta rara vez es un solo nombre comercial. Hay que identificar proveedor principal, subcontrataciones conocidas, hosting, APIs externas, herramientas de observabilidad, repositorios de logs y componentes necesarios para continuidad y salida. Este mapeo conecta de forma directa con DORA arts. 28 a 31.

4. Cómo se detiene o se degrada

Si un sistema falla, alucina, se queda sin proveedor o empieza a comportarse de forma anómala, la entidad necesita una forma de aislarlo, retirar permisos, pasar a modo manual o limitar sus funciones. Esa capacidad no es ornamental. Es parte de la resiliencia operativa.

Eso no resuelve todo, pero separa los proyectos gobernables de los proyectos que acabarán explicándose a posteriori ante auditoría, compliance o el supervisor. Y explicar a posteriori siempre sale más caro.

DORA obliga a pensar en salida antes de enamorarse de la herramienta

Uno de los puntos más infravalorados en proyectos de IA es la estrategia de salida. DORA insiste en ello por una razón simple: la dependencia crítica de un proveedor no se arregla con optimismo. El marco contractual y de gestión de terceros TIC debe permitir a la entidad mantener continuidad, acceder a datos y migrar o sustituir el servicio cuando sea necesario, especialmente si soporta funciones críticas o importantes.

En entornos agénticos, la salida puede ser más difícil de lo que parece porque no afecta solo al modelo o al proveedor principal. Puede afectar a prompts operativos, herramientas conectadas, esquemas de autorización, pipelines de observabilidad, métricas de rendimiento y conocimiento tácito acumulado por los equipos. Nada de eso invalida el uso del servicio. Lo que invalida es no haber previsto cómo cambiarlo sin romper el negocio.

Por eso el análisis serio no pregunta únicamente “¿funciona?”. Pregunta también “¿cómo dejamos de usarlo si deja de funcionar, si cambia sus condiciones o si el regulador nos exige más control del que el proveedor quiere conceder?”. Bajo DORA, esa pregunta ya no es paranoia. Es higiene básica.

Incidentes: el día que el problema deja de ser teórico

Cuando un agente falla, el incidente puede manifestarse de varias formas a la vez: indisponibilidad del servicio, decisiones erróneas, exposición indebida de datos, uso no autorizado de herramientas o dependencia súbita de un tercero que cambia condiciones o interrumpe servicio. DORA estructura la gestión de incidentes TIC en su capítulo III y exige procesos para detectar, clasificar y notificar incidentes graves. No todo incidente de IA será un incidente grave bajo DORA, pero esperar a clasificarlo cuando ya ha ocurrido es una forma bastante cara de descubrir lagunas de gobierno.

Si hay datos personales comprometidos, el reloj del GDPR art. 33 empieza a correr cuando el responsable tiene constancia de la brecha. Y ese reloj no se impresiona con explicaciones sobre la complejidad del stack agéntico. Tampoco con la frase “estamos investigando con el proveedor”. Investigar está muy bien. Notificar a tiempo, también.

La preparación útil pasa por escenarios. Qué ocurre si el agente llama a una herramienta no prevista. Qué ocurre si un proveedor externo deja de responder. Qué ocurre si una actualización altera el comportamiento del sistema. Qué ocurre si los registros no bastan para reconstruir una acción sensible. Si esas hipótesis no se prueban, la organización no tiene resiliencia; tiene fe.

Qué debería pedir hoy un consejo de administración o un comité de riesgo

No un discurso futurista. Un paquete concreto de evidencias. Si la entidad ya tiene o planea desplegar agentes, el órgano de dirección debería pedir, como mínimo, cinco cosas.

• Inventario de casos de uso con clasificación por impacto operativo, uso de datos personales y dependencia de terceros TIC.
• Mapa de proveedores y subservicios enlazado a DORA arts. 28 a 31, incluyendo funciones críticas o importantes cuando proceda.
• Matriz de permisos y acciones para saber qué puede ejecutar cada agente y con qué controles previos o posteriores.
• Plan de monitorización e incidentes alineado con el marco TIC de DORA y, si hay datos personales, con obligaciones de GDPR arts. 33 y 34.
• Estrategia de salida y reversión probada, no solo redactada.

Si falta cualquiera de esas piezas, el despliegue puede seguir siendo técnicamente brillante, pero regulatoriamente cojo. Y un proyecto cojo suele correr mucho hasta que se cae.

La objeción habitual: “ya tenemos gobierno de modelos”

Bien. Ayuda. No basta.

El gobierno de modelos puede cubrir validación, documentación, seguimiento de rendimiento, ciertas pruebas de sesgo o explicabilidad y mecanismos de aprobación. Todo eso sigue importando. El problema es que un agente no se agota en el modelo. También importa la herramienta que invoca, el dato que consulta, el permiso que hereda, el proveedor que lo hospeda, el contrato que limita la auditoría y el proceso en el que actúa.

Ese desajuste explica por qué una entidad puede tener un marco maduro de model risk y, aun así, estar floja en cuestiones que DORA considera centrales: dependencia de terceros TIC, registros de acuerdos contractuales, derechos de acceso y auditoría, continuidad, salida y gestión integral del riesgo operacional digital. No es una contradicción. Es un recordatorio incómodo de que “IA” y “resiliencia operativa” no son silos regulatorios intercambiables.

La lección menos vistosa es la más útil

Durante años se ha repetido, con más o menos solemnidad, que las organizaciones debían romper silos internos. No hace falta adornarlo con bromas sobre PowerPoint para decir algo más preciso: la IA agéntica castiga la fragmentación documental y decisoria. Si el inventario de terceros no habla con el de casos de uso, si el DPIA va por un lado y el análisis de continuidad por otro, si seguridad registra eventos que negocio no sabe interpretar, la entidad no tiene una visión gobernable del sistema.

La buena noticia es que el derecho europeo ya ofrece piezas suficientes para ordenar ese caos. DORA aporta disciplina sobre terceros TIC, resiliencia e incidentes. GDPR aporta límites claros sobre datos, seguridad y notificación. El AI Act, cuando aplique, añade obligaciones específicas sobre riesgo, documentación y supervisión humana. Lo difícil no es encontrar normas. Lo difícil es dejar de tratarlas como bibliotecas separadas.

La conclusión práctica es menos grandilocuente y más urgente: antes de aprobar un agente, la entidad debe poder demostrar qué hace, qué toca, de quién depende, cómo se supervisa y cómo se apaga. Si no puede, todavía no tiene un caso de uso listo para producción. Tiene una promesa tecnológica con exposición regulatoria.

Y el supervisor, por regla general, prefiere bastante más las evidencias que las promesas.