Las ESAs ponen nombre al elefante: la frontier AI ya es un riesgo ICT supervisable para banca y seguros

La inteligencia artificial ya no es solo una herramienta de productividad. También se está convirtiendo en una palanca de riesgo operativo, ciberseguridad y concentración tecnológica para la banca europea. Y ahí está el detalle que realmente importa: no hace falta esperar a una norma nueva para que supervisores y equipos de compliance empiecen a moverse. Con lo que ya está en vigor —o ya aprobado— hay trabajo de sobra.

Ese es el punto que muchas entidades siguen subestimando. Cuando aparece la etiqueta “IA”, demasiadas organizaciones reaccionan como si todo dependiera exclusivamente del AI Act. No. Para bancos, aseguradoras, proveedores de servicios financieros y sus terceros tecnológicos, el mapa regulatorio es bastante más incómodo. La discusión no va solo de sesgos, explicabilidad o gobernanza algorítmica. Va también de resiliencia operativa, dependencia de terceros, gestión de incidentes, continuidad, ciberhigiene y responsabilidad del órgano de dirección.

Traducido al castellano de comité de riesgos: si tu entidad integra IA en procesos críticos, o depende de terceros que la integran, el problema ya no es experimental. Es supervisable.

El error de enfoque: tratar la IA como un asunto aislado

La primera trampa consiste en meter la IA en un cajón separado, como si fuera un tema exclusivo de innovación, ética o estrategia digital. Es una comodidad organizativa. También una mala idea. Si un modelo influye en autenticación, antifraude, detección de anomalías, priorización de alertas, atención automatizada o soporte a decisiones internas con impacto material, entonces entra de lleno en el perímetro de control operativo.

Y ese perímetro, en el sector financiero europeo, ya tiene dueño regulatorio. DORA obliga a las entidades financieras a gestionar el riesgo de las TIC con un marco interno de gobernanza y control que cubra prevención, detección, respuesta, recuperación, aprendizaje y comunicación. Eso no depende de si la tecnología usada es tradicional o se vende con una capa de marketing generativo por encima. El reglamento es tecnológicamente neutro. La obligación, en cambio, es muy concreta.

Ahí está una de las ironías del momento regulatorio: la industria discute la “novedad” de la IA mientras el supervisor puede mirar problemas muy viejos con nombres bastante menos glamourosos. Inventario deficiente. Dependencia opaca de proveedores. Fallos de logging. Incapacidad para reconstruir decisiones automatizadas. Controles de cambios improvisados. Planes de continuidad pensados para sistemas estáticos aplicados a componentes que cambian deprisa. No hace falta un manifiesto político para concluir que eso huele mal.

Lo que sí puede decirse con base regulatoria sólida

Sin acudir a documentos no acreditados o a declaraciones difíciles de verificar, el marco jurídico europeo ya ofrece varias anclas claras para entender por dónde irán las exigencias prácticas.

La primera es DORA. El reglamento exige que las entidades financieras dispongan de un marco sólido, integral y bien documentado de gestión del riesgo relacionado con las TIC bajo la responsabilidad del órgano de dirección. Eso está en el artículo 5 sobre gobernanza y organización y en el artículo 6 sobre el marco de gestión del riesgo relacionado con las TIC. No es una cláusula decorativa. Obliga a que la gestión del riesgo tecnológico deje de ser un apéndice técnico y se convierta en un asunto de dirección, presupuesto, control y rendición de cuentas.

La segunda ancla es la gestión operativa del ciclo de vida de los activos y sistemas. DORA dedica varios preceptos a la identificación, protección, prevención, detección, respuesta, recuperación, aprendizaje posterior y comunicación. Conviene decirlo sin jugar a la ruleta con la numeración exacta cuando no hace falta: el reglamento estructura esas capacidades como funciones obligatorias del marco de resiliencia operativa, y exige que la entidad pueda mantener, reanudar y restaurar servicios críticos tras disrupciones relacionadas con TIC. Para el lector práctico, la conclusión no cambia: si la IA toca funciones relevantes, esos controles también la alcanzan.

La tercera es el capítulo de terceros tecnológicos. DORA, en sus artículos 28 y siguientes, convierte el riesgo de proveedores de servicios TIC en una disciplina de primera línea. Eso es especialmente delicado en IA por una razón evidente: muchas entidades no desarrollan modelos desde cero, sino que consumen infraestructura, APIs, motores de análisis, herramientas de ciberseguridad aumentadas con IA y servicios gestionados de terceros. Si no sabes qué proveedor presta qué, con qué subcontratistas, sobre qué datos y con qué dependencia de continuidad, tienes un problema regulatorio antes incluso de tener uno técnico.

La cuarta ancla es el régimen de incidentes. DORA exige procesos para gestionar, clasificar y notificar incidentes graves relacionados con las TIC. Aunque aquí conviene evitar citas de artículos concretos no verificadas en el texto de partida, la lógica normativa es clara: si un componente basado en IA contribuye a una indisponibilidad, a una degradación operativa relevante, a una alteración de integridad o a un incidente de seguridad, la entidad no puede escudarse en la complejidad del modelo para relajar sus obligaciones de registro, escalado y notificación.

La quinta es el GDPR, cuando la IA procesa datos personales. El artículo 5 impone principios de licitud, minimización, exactitud e integridad y confidencialidad; el artículo 25 exige protección de datos desde el diseño y por defecto; el artículo 32 obliga a aplicar medidas técnicas y organizativas apropiadas para garantizar la seguridad del tratamiento; y el artículo 33 regula la notificación de violaciones de seguridad de los datos personales a la autoridad de control sin dilación indebida y, de ser posible, dentro de las 72 horas. Otra vez: la IA no suspende estas obligaciones. Si acaso, las vuelve más difíciles de ejecutar bien.

El AI Act no sustituye a DORA. Le añade presión

Aquí conviene separar dos planos que a menudo se mezclan. El AI Act introduce obligaciones específicas para determinados sistemas de IA y para ciertos actores de la cadena de valor. Pero para una entidad financiera ya sometida a DORA, PSD2, GDPR, EBA Guidelines o requisitos prudenciales, la nueva norma no borra nada. Superpone capas.

Eso tiene una consecuencia muy práctica. Si una organización está diseñando su programa de cumplimiento de IA como si partiera de una hoja en blanco, va tarde y va mal. Lo sensato es construirlo sobre los controles ya existentes: inventario de activos, clasificación de servicios críticos, due diligence de terceros, gestión de cambios, validación de modelos, control de accesos, logging, continuidad de negocio, respuesta a incidentes y gobierno de datos. No porque suene elegante, sino porque es la única forma realista de no multiplicar marcos paralelos que luego nadie sabe operar.

También conviene ser rigurosos con lo que el AI Act sí hace y lo que no. Puede afirmarse con seguridad que el reglamento contempla un tratamiento específico para los modelos de IA de propósito general y una categoría reforzada para los que presentan riesgo sistémico. Lo que no conviene hacer, sin apoyo textual concreto a mano, es convertir esa referencia en una lista cerrada de obligaciones detalladas no citadas en la fuente original. La lección útil para el sector financiero es más simple y suficiente: si tu entidad depende de modelos generalistas integrados por terceros, el análisis regulatorio no termina en el proveedor ni en el contrato comercial. Tendrás que entender la cadena de dependencia y cómo encaja con tus propias obligaciones de resiliencia, seguridad y supervisión.

La verdadera pregunta: ¿dónde se rompe el control?

La conversación seria sobre IA y ciberseguridad en banca no empieza en la fascinación tecnológica. Empieza en los puntos de fallo. Y hay varios.

Uno es la opacidad operativa. Muchas entidades saben que usan “IA” en algún sitio, pero no pueden responder con precisión a preguntas bastante básicas: qué modelos están en producción, qué versiones corren, qué datos consumen, qué decisiones influyen, qué proveedor los mantiene, cómo se monitoriza su rendimiento, qué controles limitan sus salidas y qué pasa si fallan. Si no puedes contestar eso en una reunión de riesgos sin mirar siete equipos distintos, no tienes gobernanza; tienes esperanza coordinada.

Otro punto de ruptura es la dependencia de terceros. DORA art. 28 obliga a gestionar el riesgo derivado de terceros proveedores de servicios TIC como parte integrante del marco de riesgo. No basta con tener una política de outsourcing heredada de otra era. En servicios basados en IA, la subcontratación en cascada es especialmente problemática: proveedor principal, proveedor de nube, proveedor de modelo fundacional, proveedor de etiquetado, proveedor de observabilidad, proveedor de seguridad gestionada. El banco compra una solución; el riesgo llega con familia numerosa.

Un tercer punto es la trazabilidad. Cuando una herramienta basada en IA participa en detección de fraude, priorización de alertas, triage de incidencias o apoyo a analistas, la organización necesita registros suficientes para reconstruir qué ocurrió, por qué ocurrió y quién validó la actuación posterior. Esto no es una exigencia académica. Es la diferencia entre poder investigar un incidente y limitarse a encogerse de hombros mientras el auditor toma notas.

El cuarto es la degradación silenciosa. Un sistema no tiene que caerse del todo para convertirse en un riesgo. Puede seguir funcionando y hacerlo peor, o hacerlo de forma inestable, o generar una tasa de falsos positivos que erosione al equipo, o una tasa de falsos negativos que deje pasar eventos que sí importaban. Desde la óptica de resiliencia operativa, eso obliga a definir umbrales, métricas, procedimientos de escalado y criterios de fallback. Si el modelo pierde fiabilidad, ¿la entidad puede volver a un proceso manual o a una lógica determinista sin interrumpir un servicio crítico? Si la respuesta es no, no estás automatizando; estás apostando.

DORA no te pide amar la IA. Te pide controlarla

Uno de los errores más frecuentes en la lectura empresarial de DORA es asumir que el reglamento exige una especie de “estado ideal” tecnológicamente perfecto. No. Lo que exige es algo más ingrato y más terrenal: control efectivo, responsabilidades claras, documentación, pruebas y capacidad de recuperación.

El artículo 5 coloca al órgano de dirección en el centro de la responsabilidad sobre el riesgo relacionado con TIC. Eso incluye aprobar, supervisar y ser responsable de la aplicación del marco de gestión. Si la entidad despliega herramientas de IA en procesos relevantes, el consejo y la alta dirección no pueden tratarlas como un artefacto experimental reservado a innovación o a IT. Tienen que entender, al menos en términos de riesgo y dependencia, qué función cumplen y qué pasaría si fallan, son manipuladas o producen resultados erráticos.

El artículo 6 exige un marco de gestión del riesgo relacionado con las TIC sólido, integral y bien documentado. La palabra decisiva aquí es “integral”. Si la IA entra por la puerta de procurement, por laboratorios de negocio o por pruebas de concepto eternamente “piloto”, pero no se integra en el inventario de riesgos, en la clasificación de activos, en los escenarios de continuidad y en los controles de seguridad, la entidad incumple la lógica de DORA aunque cada equipo individual crea estar haciendo algo razonable.

Y luego está la parte menos glamurosa: pruebas, revisiones y aprendizaje. La resiliencia no se demuestra con presentaciones; se demuestra cuando un sistema falla y la organización sabe responder. DORA obliga a poner a prueba la resiliencia operativa digital de forma proporcionada y periódica. Si una herramienta basada en IA sostiene funciones materiales —o altera significativamente la forma en que se detectan, priorizan o responden incidentes— debería entrar en ese perímetro de pruebas. No porque exista una línea mágica que diga “IA = test adicional”, sino porque cualquier componente relevante del servicio debe poder resistir, fallar de forma controlada y recuperarse.

Lo que cambia cuando el proveedor mete IA en un servicio que ya tenías contratado

Hay una escena regulatoria muy actual y bastante incómoda. La entidad no “compra IA” como proyecto independiente. Lo que ocurre es que un proveedor existente empieza a integrar capacidades de IA en una plataforma de monitorización, un servicio antifraude, una suite de atención al cliente o una herramienta de seguridad. El contrato base sigue pareciendo el mismo. El perfil de riesgo, no necesariamente.

Aquí DORA vuelve a ser menos abstracto de lo que algunos desearían. Los artículos 28 a 30 sobre terceros proveedores de servicios TIC y contenido esencial de los acuerdos contractuales obligan a saber qué servicio se presta, cómo se apoya en subcontratación, qué niveles de servicio existen, qué derechos de acceso, auditoría e inspección conserva la entidad, cómo se gestiona la terminación y cómo se asegura la disponibilidad, autenticidad, integridad y confidencialidad de los datos.

En otras palabras: cuando el proveedor añade IA, la pregunta no es solo si la funcionalidad nueva “mejora” el servicio. La pregunta correcta es si altera el tratamiento de datos, el perfil de dependencia, la explicabilidad operativa, la superficie de ataque, la continuidad o la posibilidad real de supervisión por parte de la entidad. Si el contrato y la due diligence no capturan eso, el banco puede acabar asumiendo un riesgo nuevo con controles viejos. Suele salir regular.

También hay un matiz que muchas áreas de compras siguen dejando pasar. El riesgo no nace únicamente del proveedor principal. Si la funcionalidad depende materialmente de otro actor aguas arriba —por ejemplo, infraestructura cloud, modelos de propósito general o componentes críticos integrados— la entidad necesita visibilidad suficiente sobre esa cadena. DORA no exige omnisciencia, pero sí una gestión seria de dependencias y concentración.

Privacidad: el viejo problema con disfraz nuevo

Cuando la IA entra en procesos financieros, la conversación sobre ciberseguridad suele comerse a la de privacidad. Error clásico. Si el sistema trata datos personales, el GDPR sigue plenamente operativo y plantea exigencias que, en muchos casos, son más concretas y ejecutables que el debate abstracto sobre “IA responsable”.

El artículo 25, protección de datos desde el diseño y por defecto, obliga a incorporar salvaguardas desde la configuración inicial del sistema. Eso afecta a minimización de datos, limitación de acceso, retención, segregación de entornos, pseudonimización cuando proceda y mecanismos para evitar usos secundarios no previstos. Si una entidad vuelca grandes volúmenes de datos en una herramienta de terceros para “probar” capacidades, tendrá que justificar mucho más que entusiasmo.

El artículo 32 exige medidas apropiadas para garantizar la confidencialidad, integridad, disponibilidad y resiliencia permanentes de los sistemas y servicios de tratamiento. La frase relevante aquí no es “medidas apropiadas”, que cada cual interpreta a su gusto, sino la combinación de seguridad y resiliencia. El GDPR, igual que DORA desde otra lógica, no se limita a pedir secreto; pide capacidad de seguir operando y restaurar disponibilidad y acceso a los datos personales de forma oportuna en caso de incidente físico o técnico.

Y si hay una violación de seguridad de datos personales, el artículo 33 activa la obligación de notificación a la autoridad de control sin dilación indebida y, cuando sea posible, en 72 horas. En una arquitectura donde intervienen varios proveedores y componentes de IA, identificar rápido si el incidente afecta a datos personales puede ser mucho más difícil. Pero la dificultad operativa no suspende el reloj regulatorio. Solo lo vuelve más desagradable.

La tentación del “ya lo resolverá seguridad”

Otra comodidad organizativa muy extendida: pensar que todo esto se arregla reforzando al CISO. No exactamente. Seguridad tiene un papel central, claro, pero el riesgo asociado a IA en servicios financieros es transversal por diseño.

Legal necesita revisar base jurídica, usos permitidos, transferencias, cláusulas contractuales, auditoría y responsabilidad. Procurement debe elevar su nivel de due diligence tecnológica. Riesgos operacionales tiene que decidir qué procesos son críticos o importantes y cómo cambia su mapa de dependencias. Compliance debe cruzar DORA, GDPR, normas sectoriales internas y futuras exigencias del AI Act. Auditoría interna tiene que ajustar programas de revisión para no seguir auditando un parque tecnológico que ya no existe. Negocio, por su parte, debe dejar de esconder decisiones materiales bajo el paraguas amable de “herramienta de apoyo”.

Si todo descansa en seguridad, el resultado suele ser previsible: controles técnicos razonables en un gobierno corporativo desalineado. Y el supervisor rara vez compra esa excusa. La pregunta que flotará en cualquier revisión seria no es si tu equipo de seguridad hizo lo que pudo, sino si la entidad organizó de forma adecuada la gestión del riesgo derivado de una tecnología que estaba desplegando o consumiendo.

Qué sí deberían hacer ya las entidades

No hace falta inventar nuevas doctrinas para aterrizar este asunto. Hace falta disciplina. Si tu entidad quiere reducir exposición regulatoria y operativa, hay cinco frentes inmediatos donde la utilidad supera al powerpoint.

• Inventario real de casos de uso y dependencias. No un catálogo aspiracional. Un inventario con sistemas en producción, proveedores implicados, función de negocio, criticidad, datos tratados, responsables internos y mecanismos de fallback.
• Mapeo al marco DORA existente. Cada caso de uso relevante debería vincularse a controles de gobernanza, gestión del riesgo TIC, continuidad, respuesta a incidentes, gestión de cambios, pruebas y supervisión de terceros. Si no encaja en ningún control, el problema no es el Excel: es el despliegue.
• Revisión contractual de terceros TIC. DORA art. 30 exige contenido mínimo en acuerdos contractuales. Si el proveedor añade capacidades de IA, revisa subcontratación, derechos de auditoría, localización y tratamiento de datos, métricas de servicio, soporte en incidentes y condiciones de terminación o transición.
• Trazabilidad y logging suficientes. La entidad debe poder reconstruir entradas relevantes, cambios de versión, intervención humana, alertas generadas, decisiones derivadas y respuesta adoptada. Sin eso, ni DORA ni GDPR se gestionan con seriedad.
• Escenarios de continuidad y degradación. No basta con preguntar si el sistema “funciona”. Hay que definir qué ocurre si se degrada, se vuelve indisponible, produce resultados inestables o deja de ser utilizable por razones jurídicas o contractuales.

Ninguno de estos pasos es futurista. Todos caben en marcos ya exigibles. La cuestión incómoda es otra: ¿tu entidad puede completarlos sin descubrir que lleva meses usando servicios que no estaban del todo bajo control?

Donde conviene ser prudentes

Hay una tentación periodística —y a veces corporativa— de adornar este debate con grandes anuncios, advertencias espectaculares y citas de supervisores sobre “frontier AI” como si todo dependiera de una nueva cruzada institucional. Conviene contenerse cuando no hay texto verificable delante. Se puede sostener un análisis sólido sin apoyarse en fechas, planes o declaraciones no acreditadas.

De hecho, la prudencia aquí mejora el diagnóstico. Porque el reto no depende de una pieza aislada de comunicación pública. Depende de algo bastante más estable: la convergencia entre resiliencia operativa, protección de datos, supervisión de terceros y gobernanza tecnológica. Ese cruce normativo ya existe. Ya obliga. Y ya permite a supervisores formular preguntas muy concretas a las entidades.

También conviene evitar otra exageración frecuente: presentar la IA como un riesgo radicalmente distinto a todo lo anterior. A veces sí introduce vectores nuevos. Pero muchas de las debilidades más serias que aflora son viejas conocidas del control interno: inventarios incompletos, clasificación pobre, exceso de confianza en terceros, documentación floja, pruebas insuficientes y escasa capacidad de recuperación. El disfraz cambia. El desorden, no tanto.

El debate sobre monitorización continua es real, aunque no haga falta adjudicarlo a una cita dudosa

En seguridad y resiliencia hay una deriva evidente hacia capacidades más continuas, más instrumentadas y menos dependientes de revisiones puntuales. No hace falta atribuir esa formulación exacta a una fuente concreta no acreditada para ver la tendencia de fondo. Cualquier entidad que use o consuma sistemas basados en IA en procesos críticos necesitará acortar el tiempo entre cambio técnico, detección de anomalía y respuesta operativa.

Eso tiene implicaciones directas. Los controles anuales de proveedor se quedan cortos si el servicio cambia materialmente cada pocas semanas. Las aprobaciones de cambio pensadas para software estático se tensan cuando el comportamiento del sistema depende de componentes externos, ajustes frecuentes o configuraciones evolutivas. Y los cuadros de mando tradicionales no bastan si no capturan degradaciones operativas que no encajan en la lógica binaria de “caído/no caído”.

La buena noticia es que este problema puede traducirse a lenguaje de control. Umbrales, evidencias, segregación de funciones, procedimientos de rollback, ventanas de cambio, monitorización de rendimiento, validación humana en puntos críticos y criterios de escalado. Nada de eso suena revolucionario. Precisamente por eso debería estar ya en marcha.

¿Y qué pasa con la responsabilidad del consejo?

Pasa que deja de ser teórica. DORA art. 5 no permite al órgano de dirección desentenderse del riesgo TIC. El consejo debe definir, aprobar, supervisar y ser responsable del marco de gestión del riesgo relacionado con TIC. Si una entidad integra IA en servicios críticos o importantes, o depende de terceros que lo hacen, la conversación de consejo tiene que subir de nivel.

No hace falta que los consejeros entiendan arquitectura de modelos. Sí hace falta que entiendan exposición material. Qué procesos dependen de estas herramientas. Qué proveedores concentran riesgo. Qué escenarios de fallo pondrían en riesgo la continuidad o la integridad del servicio. Qué controles compensatorios existen. Qué indicadores recibe la dirección. Qué incidentes o near misses se han producido. Y quién firma que todo eso está razonablemente gobernado.

Si ese diálogo no existe, el consejo corre un riesgo doble. Operativo, porque decide sin visibilidad suficiente. Y regulatorio, porque DORA no sitúa la responsabilidad en una nube filosófica. La aterriza en obligaciones de gobernanza muy concretas.

No todo es amenaza: también hay una oportunidad regulatoria, pero sin romanticismo

La IA puede mejorar la defensa. Puede acelerar análisis, ayudar a priorizar alertas, automatizar tareas repetitivas y reforzar algunas capacidades de detección. Todo eso es cierto. El problema empieza cuando se usa esa promesa para rebajar el umbral de control. Un sistema que mejora productividad pero introduce opacidad, dependencia inasumible o imposibilidad práctica de auditoría no reduce riesgo. Lo redistribuye, normalmente hacia lugares menos visibles.

Aquí el enfoque maduro no consiste en frenar toda adopción. Consiste en exigir una disciplina proporcional al impacto. Si el caso de uso es marginal, los controles pueden ser más ligeros. Si toca procesos críticos, datos sensibles o decisiones con impacto material, la gobernanza tiene que endurecerse. Parece de sentido común. En la práctica, no siempre gana el sentido común cuando el proveedor promete eficiencias y el presupuesto aprieta.

La conclusión incómoda

El sector financiero europeo no necesita esperar a un titular grandilocuente sobre IA para tomarse este riesgo en serio. Ya tiene base regulatoria suficiente para actuar. DORA art. 5 y 6 colocan gobernanza y gestión del riesgo TIC en el centro. DORA art. 28 y siguientes obligan a tratar a los terceros tecnológicos como una fuente de riesgo estructural, no como una nota al pie de procurement. El GDPR, con sus artículos 25, 32 y 33, mantiene intacta la presión sobre diseño, seguridad y respuesta cuando hay datos personales de por medio. Y el AI Act, lejos de simplificar el panorama, añadirá exigencias y escrutinio sobre usos y dependencias concretas.

La pregunta ya no es si la IA merece una política interna. La pregunta seria es otra: ¿tu entidad puede demostrar, con evidencias y controles operativos, que sabe dónde está la IA, qué hace, de quién depende, qué riesgo introduce y cómo seguiría prestando el servicio si ese componente falla o se vuelve problemático?

Si la respuesta es dudosa, no necesitas más entusiasmo regulatorio. Necesitas un inventario, una revisión contractual y una conversación honesta con el órgano de dirección. Lo demás —incluido el discurso grandilocuente sobre innovación segura— viene después.