Bailey pone el dedo en la llaga: la banca ya necesita límites operativos para la IA, no otro discurso del G20

La banca lleva años obsesionada con el riesgo de modelo. Lo curioso es que ahora el problema no es solo que un modelo se equivoque, sino que aprenda, se conecte a medio stack tecnológico de la entidad y empiece a tocar procesos que hasta hace nada exigían controles bastante más mundanos: segregación de funciones, validación independiente, trazabilidad y capacidad real de parar algo antes de que escale. La novedad no es la palabra IA. La novedad es su combinación con dependencia operativa, terceros tecnológicos y automatización de decisiones con impacto financiero.

Ese es el ángulo que importa. No si la IA “transformará” la banca —esa frase ya no da para titular ni para café de conferencia—, sino qué ocurre cuando una entidad integra modelos en atención al cliente, fraude, cumplimiento, desarrollo de software, monitorización de pagos o gestión interna del conocimiento y descubre que el riesgo deja de caber en el cajón clásico de “IT”. Ahí empieza la parte regulatoria interesante.

La pregunta útil no es si Europa tiene una norma “de IA” y otra “de ciber”. Las tiene. La pregunta útil es otra: qué piezas regulatorias ya existentes obligan hoy a controlar la IA en servicios financieros aunque la norma no pronuncie esa palabra cada dos líneas. Y la respuesta, para disgusto de quienes esperaban una moratoria retórica, es bastante clara: varias.

No hace falta esperar a una norma milagro para que el supervisor te pregunte por la IA

Si una entidad financiera despliega un sistema basado en modelos para soportar procesos críticos, ya entra en terreno conocido para supervisores y equipos de compliance. DORA no regula “la IA” como categoría autónoma, pero sí regula la resiliencia operativa digital de funciones, sistemas y terceros que soportan servicios financieros. Si el modelo está integrado en un flujo material para el negocio, deja de ser una curiosidad de laboratorio y pasa a formar parte del perímetro de control.

El punto de partida está en DORA art. 5, que obliga a las entidades a contar con un marco interno de gobernanza y control para gestionar el riesgo relacionado con las TIC. No habla de modelos fundacionales ni de agentes autónomos. No hace falta. Si una herramienta de IA forma parte del entorno TIC y su fallo, indisponibilidad, comportamiento inesperado o dependencia externa afecta a la continuidad, integridad o disponibilidad de servicios, el régimen aplicable ya existe.

La exigencia se vuelve más concreta en DORA art. 6, sobre marco de gestión del riesgo TIC, y en art. 8, sobre identificación, clasificación y documentación adecuada de las funciones soportadas por TIC, así como de activos y dependencias. Traducido al castellano menos regulatorio: si has enchufado un modelo a un proceso relevante, deberías saber dónde está, qué hace, de qué depende, qué datos toca, qué proveedor lo sostiene y qué pasaría si empieza a fallar en producción.

Eso parece obvio hasta que uno mira cómo se están desplegando muchos casos de uso. Pilotos nacidos en áreas de negocio. Contratación rápida vía API. Integraciones con suites ofimáticas o herramientas de desarrollo. Datos internos que viajan donde no deberían. Funciones que pasan de “apoyo” a “casi decisorias” sin una revalidación seria del control. Luego llega auditoría interna o el supervisor y aparece la pregunta incómoda: tu entidad tiene inventariados estos usos con el mismo rigor que otros componentes críticos? En no pocos casos, la respuesta honesta sería mejor no verbalizarla delante del consejo.

La pieza clave no es la inteligencia del modelo, sino la criticidad de la función

Este matiz separa el análisis serio del ruido comercial. Un modelo muy sofisticado usado para resumir notas internas puede ser regulatoriamente menos problemático que un sistema bastante más simple integrado en alertas de fraude, clasificación de incidencias operativas, priorización de reclamaciones o asistencia al personal de primera línea en operaciones sensibles.

Europa ya lleva tiempo moviendo la supervisión hacia la materialidad operativa. DORA insiste en identificar funciones críticas o importantes y en gobernar el riesgo derivado de los terceros TIC que las soportan. Ahí entran de lleno proveedores cloud, plataformas SaaS, integradores y, según la arquitectura del servicio, también componentes de IA consumidos como servicio. El anclaje jurídico relevante está en DORA arts. 28 a 30, que fijan el marco para la gestión del riesgo de terceros proveedores de servicios TIC, incluidos requisitos contractuales y supervisión proporcional al riesgo.

No hace falta forzar la norma para verlo. Si una entidad usa un modelo externo en una función relevante, la cuestión práctica pasa a ser: ¿ese servicio crea una dependencia operativa significativa? ¿permite al banco auditar, monitorizar, rescindir o sustituir el servicio sin provocar un pequeño incendio? ¿hay claridad contractual sobre subcontratación, localización del tratamiento, acceso, registros, soporte a incidentes y pruebas? DORA no promete comodidad. Pide precisamente este tipo de respuestas.

La conversación, además, no termina en DORA. Las Directrices de la EBA sobre externalización siguen siendo muy útiles para entender cómo debe evaluarse la materialidad de un acuerdo de outsourcing, cómo se mantiene el registro de acuerdos, qué derechos de acceso y auditoría deben contemplarse y cómo se organiza la estrategia de salida cuando el proveedor deja de ser sostenible o aceptable. No convierten cada herramienta de IA en externalización material por arte de magia; pero tampoco permiten fingir que una dependencia operativa nueva deja de ser dependencia porque el contrato se llame “licencia” o “servicio inteligente”. El maquillaje contractual no impresiona mucho a un supervisor experimentado.

El riesgo de IA en finanzas no es uno; son varias capas que se pisan entre sí

Hablar de “riesgo de IA” en singular ayuda en los paneles y perjudica en la gestión real. En una entidad financiera, el problema suele aparecer por capas que interactúan: calidad y procedencia del dato, comportamiento del modelo, integridad del flujo operativo, dependencia del tercero, seguridad del entorno, tratamiento de datos personales y gobernanza interna. Separarlas es cómodo en una presentación. En producción, caen juntas.

Pensemos en un asistente para analistas o agentes internos. Puede parecer una herramienta inocua si no “decide” nada por sí sola. Pero si resume documentación de clientes, sugiere respuestas regulatorias, recupera procedimientos internos, redacta comunicaciones o ayuda a clasificar alertas, ya introduce varios frentes:

• Confidencialidad y minimización de datos: si el sistema recibe datos personales o información confidencial, GDPR obliga a tener base jurídica, limitación de finalidad, minimización y medidas técnicas y organizativas adecuadas. El anclaje básico está en GDPR art. 5 y art. 32.
• Gestión de incidentes: si el uso del sistema deriva en una violación de seguridad de datos personales, entra GDPR art. 33, con obligación de notificación a la autoridad de control sin dilación indebida y, cuando sea posible, en 72 horas.
• Seguridad de red y sistemas: si la entidad está bajo NIS2 o forma parte de sectores cubiertos en su transposición nacional, el foco se desplaza hacia medidas de gestión del riesgo y gobernanza. NIS2 art. 21 obliga a adoptar medidas técnicas, operativas y organizativas adecuadas y proporcionadas.
• Dependencia de terceros: si el servicio depende de proveedores externos, DORA vuelve a escena por la puerta principal, especialmente en arts. 28 a 30.

Nada de esto exige dramatismo. Exige mapa. El error habitual es tratar la IA como un tema de innovación, no como una combinación de activos TIC, proveedores, datos y procesos de negocio con consecuencias regulatorias muy clásicas. Cambia la interfaz. La obligación de control no cambia tanto.

Lo difícil no es redactar una política de IA; lo difícil es gobernar el uso real

Todas las entidades razonables están produciendo políticas, principios y estándares internos sobre IA. Bien. Hace falta. Pero la distancia entre esa documentación y el uso real puede ser bastante cómica, y no en el buen sentido.

Una política dirá que no deben introducirse datos sensibles en herramientas no aprobadas. Después aparece un equipo que usa un asistente generativo para preparar respuestas a clientes o revisar código porque “solo era una prueba”. Una política dirá que todo caso de uso debe pasar por validación de riesgos. Luego un área activa funcionalidades embebidas en software corporativo que ya venían “encendidas” por defecto. Una política dirá que debe haber supervisión humana. Más tarde se descubre que, en la práctica, el usuario confirma recomendaciones del sistema por pura presión de tiempo. Automatización de hecho, aunque no de derecho.

Desde el punto de vista regulatorio, esto importa más que el discurso. DORA art. 5 pone la responsabilidad última en el órgano de dirección para definir, aprobar, supervisar y responder por la implementación del marco de gestión del riesgo TIC. No basta con patrocinar una política vistosa y dar el asunto por cerrado. Si el consejo no recibe información útil sobre inventario de casos de uso, criticidad, dependencias externas, incidentes, pruebas, limitaciones conocidas y planes de salida, la gobernanza se queda en decoración.

Aquí hay una lección que los equipos de ciber y compliance conocen bien: los riesgos más serios no siempre llegan por grandes proyectos aprobados con fanfarria, sino por adopción incremental. Un copiloto aquí, una API allá, un conector con documentación interna, una herramienta de terceros que incorpora nuevas funciones sin mucho aviso. Cuando la organización quiere darse cuenta, tiene media docena de flujos materialmente distintos bajo la misma etiqueta genérica de “IA”. Y cada uno debería tener un tratamiento de riesgo distinto.

La frontera entre riesgo tecnológico y riesgo prudencial se estrecha

En finanzas, un fallo tecnológico rara vez se queda en tecnología. Esa es la razón por la que la conversación no debe limitarse a privacidad o ciberseguridad. Dependiendo del caso de uso, un comportamiento defectuoso del modelo puede afectar a continuidad operativa, controles internos, calidad de la información, atención a clientes, prevención del fraude o ejecución de procesos sujetos a supervisión.

Conviene ser precisos. No todo error de un sistema de IA tendrá relevancia prudencial. Pero algunos sí pueden adquirirla por su posición en el proceso. Si una herramienta influye en priorización de alertas, revisión documental, soporte a decisiones operativas o generación de código que luego pasa a producción, el problema ya no es solo de exactitud abstracta. Es de control interno, resiliencia y capacidad de detectar fallos antes de que se conviertan en incidente operativo.

DORA vuelve a ofrecer un encaje más útil de lo que muchos admiten. Art. 10 exige capacidades de detección de actividades anómalas, incluidas cuestiones de rendimiento de red, incidentes relacionados con las TIC y vulnerabilidades. Si una entidad integra herramientas de IA en su stack, ese entorno debe entrar en la lógica de monitorización. No por fetichismo regulatorio, sino porque los modelos también fallan de formas poco intuitivas: respuestas incorrectas convincentes, salidas inconsistentes ante cambios menores, exposición inadvertida de información o degradaciones ligadas a cambios del proveedor.

La consecuencia práctica es incómoda: los marcos clásicos de monitorización de sistemas no bastan por sí solos. Hace falta unir telemetría técnica, controles de acceso, revisión de salidas, gestión de cambios y evaluación de impacto por caso de uso. No es un problema exclusivamente de MLOps ni exclusivamente de compliance. Es transversal. Y cuando algo es transversal, todos creen que es de otro. Hasta que deja de serlo.

AI Act: menos bálsamo del que algunos esperaban, más pieza de un puzle complejo

Conviene pinchar una burbuja. El AI Act no sustituye a DORA, GDPR, NIS2 ni a las exigencias sectoriales financieras. Los complementa. Esa diferencia importa mucho porque parte del mercado ha vendido la idea de que bastará con “clasificar” sistemas y aplicar el marco de IA como si el resto del edificio normativo se tomara vacaciones.

No va a ocurrir. Si un sistema encaja en categorías de riesgo específicas bajo el AI Act, habrá obligaciones propias. Pero aunque un caso de uso no active la parte más exigente del reglamento, eso no neutraliza obligaciones ya existentes sobre gobernanza TIC, terceros, seguridad, datos personales o continuidad operativa. En banca y seguros, la regulación rara vez funciona por sustitución. Funciona por acumulación.

Ese solapamiento es menos elegante de lo que les gustaría a los departamentos jurídicos, pero bastante realista. Un mismo asistente o motor analítico puede plantear a la vez preguntas de GDPR art. 5 y art. 32, de DORA arts. 5, 6 y 28, y de requisitos del AI Act según el uso concreto. La lectura madura no es preguntar qué norma “manda”, sino qué obligación añade cada una y quién se encarga de ejecutarla dentro de la entidad.

También conviene bajar el volumen a cierta narrativa de alivio: “si el proveedor me asegura cumplimiento del AI Act, yo ya estoy cubierto”. No. Un proveedor puede facilitar documentación, controles o compromisos contractuales. La entidad regulada sigue teniendo su propio deber de diligencia sobre el servicio que integra en su operativa. Esa lógica ya estaba en outsourcing y terceros TIC mucho antes del último entusiasmo generativo.

Lo que sí puede hacer una entidad ahora, sin esperar a que el mercado madure por arte de magia

La reacción útil no es prohibirlo todo ni abrazarlo todo. Es distinguir. Si el uso de IA se queda en tareas de productividad personal con datos no sensibles y sin impacto material en procesos críticos, el nivel de control no será el mismo que en un sistema conectado a operaciones, cumplimiento o atención al cliente. El problema es que muchas organizaciones todavía no tienen un método consistente para hacer esa distinción.

Un enfoque serio debería empezar por un inventario operativo, no por una declaración grandilocuente. ¿Qué herramientas se usan? ¿Quién las aprueba? ¿Qué datos consumen? ¿Qué proveedor está detrás? ¿Hay transferencia a terceros países? ¿El servicio aprende de los prompts o entradas? ¿Existe posibilidad de desactivar entrenamiento con datos del cliente? ¿Se integra con sistemas internos? ¿Produce salidas que se archivan, ejecutan o comunican a clientes? Sin ese mapa, el debate regulatorio se convierte en literatura.

Después toca clasificar por criticidad. Aquí DORA da una pista metodológica suficiente: mirar la relevancia del servicio para funciones críticas o importantes, la dependencia operativa y el impacto potencial sobre continuidad y seguridad. No hace falta inventar una taxonomía barroca para cada piloto. Hace falta decidir si ese caso de uso cae en uno de tres grupos prácticos: bajo impacto, impacto relevante o impacto material para funciones críticas. A partir de ahí, cambian los controles exigibles.

En los usos de mayor impacto, hay varias preguntas que deberían resolverse antes de escalar:

• ¿Existe revisión humana real o solo aprobación rutinaria?
• ¿Puede trazarse qué entrada generó qué salida y quién la utilizó?
• ¿Se han definido casos de fallo previsibles y umbrales de retirada?
• ¿El proveedor ofrece soporte suficiente para auditoría, incidentes y cambios materiales del servicio?
• ¿Hay plan de salida o sustitución si el servicio deja de ser aceptable?

Estas no son manías de segunda línea. Son la diferencia entre un uso controlado y una dependencia opaca con ínfulas de innovación.

Privacidad: el frente más subestimado cuando la IA “solo ayuda”

Uno de los autoengaños favoritos del mercado consiste en pensar que, si el sistema no toma decisiones finales sobre personas, el riesgo de privacidad baja mucho. A veces baja. Otras veces no tanto. Todo depende de los datos que entran, del destino de esos datos, del proveedor, de la posibilidad de reutilización y del papel del sistema en el flujo operativo.

GDPR no necesita que un modelo deniegue un crédito para activarse. Basta con que haya tratamiento de datos personales. Si además el tratamiento implica nuevas finalidades, perfiles, retención no prevista o transferencias internacionales complejas, el cuadro se complica deprisa. GDPR art. 25 sobre protección de datos desde el diseño y por defecto es especialmente relevante en integraciones tempranas. También lo es art. 35 sobre evaluaciones de impacto cuando el tratamiento pueda entrañar un alto riesgo para los derechos y libertades de las personas.

Lo que muchas entidades están descubriendo es que el mayor problema no siempre es el modelo, sino la gobernanza de entradas y salidas. Un asistente puede recibir fragmentos de expedientes, correos, identificadores, reclamaciones o comunicaciones internas sin que el usuario perciba del todo la sensibilidad del contenido. Después, esas entradas quedan expuestas a reglas contractuales y técnicas del proveedor que no siempre han sido comprendidas por quienes lanzaron el proyecto. Cuando privacidad llega tarde, suele llegar con mala cara.

Esto enlaza con DORA de forma bastante directa. Un mal diseño de privacidad no es solo un riesgo de protección de datos. También puede convertirse en incidente TIC o en vulnerabilidad operativa si compromete integridad, disponibilidad o confidencialidad de información y servicios. La fragmentación interna entre legal, privacy, ciber e innovación sigue siendo uno de los mayores riesgos no escritos del momento.

NIS2 añade una presión extra: gobernanza real, no postureo

Para entidades y grupos afectados por su ámbito de aplicación nacional, NIS2 endurece la conversación sobre responsabilidad de gestión y medidas de ciberseguridad. Art. 20 pone responsabilidades en los órganos de dirección. Art. 21 detalla medidas de gestión del riesgo de ciberseguridad, entre ellas políticas de análisis de riesgos, gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, seguridad en adquisición, desarrollo y mantenimiento de redes y sistemas, y uso de criptografía y autenticación cuando proceda.

¿Dónde encaja la IA? No como palabra mágica, sino como componente de sistemas, cadena de suministro, desarrollo y operación. Si una organización incorpora herramientas generativas en el ciclo de desarrollo, por ejemplo, la cuestión ya no es si “mejora productividad”. La cuestión es cómo cambia el perfil de riesgo del software producido, qué controles existen sobre repositorios, secretos, librerías y revisiones, y cómo se integra eso en el marco de seguridad exigible. NIS2 no bendice experimentos por el hecho de que ahorren tiempo al equipo.

También hay una consecuencia menos obvia. Cuanto más dependa una organización de proveedores externos con lógica opaca o con actualizaciones frecuentes, más relevante se vuelve la seguridad de la cadena de suministro. Y ahí NIS2 y DORA convergen de forma bastante incómoda para quien haya comprado IA como servicio con un cuestionario de procurement estándar y poco más.

La gobernanza de terceros va a separar a las entidades serias de las entusiastas

Hay una razón por la que DORA dedica tanto espacio a terceros TIC. Europa ha entendido, por fin y tras varios avisos bastante caros, que el riesgo tecnológico no desaparece cuando sale del balance y se convierte en contrato. Solo cambia de dirección postal.

Con IA esto se multiplica. No siempre contratas un solo proveedor. Contratas una aplicación que depende de un modelo, alojado sobre infraestructura de otro, con conectores adicionales y, a veces, subencargados o subcontratistas cuya visibilidad es limitada. Si algo falla, la cadena de responsabilidad puede volverse deliciosamente confusa para todos menos para el regulador, que seguirá mirando a la entidad regulada.

DORA art. 28 exige una estrategia sobre riesgo derivado de terceros TIC. Art. 30 entra en el contenido contractual clave, incluyendo descripciones claras de funciones y servicios, lugares de prestación, acceso, disponibilidad, integridad, protección de datos, asistencia ante incidentes, cooperación con autoridades competentes y derechos de terminación. Para servicios con peso operativo real, estas cláusulas dejan de ser papel y se convierten en capacidad de supervivencia.

La pregunta incómoda para muchas entidades es simple: tu contrato de IA te deja auditar algo de verdad o solo te deja aceptar un PDF comercial con promesas vaporosas? Si no sabes qué cambios materiales puede introducir el proveedor, con qué preaviso, bajo qué subprocesadores y con qué soporte ante incidentes, la dependencia es mayor de lo que parece. Y, de nuevo, no por culpa metafísica de la IA, sino por una externalización poco madura disfrazada de innovación ágil.

El error de compliance más común: tratar todos los casos de uso como si fueran iguales

Uno de los motivos por los que muchas políticas internas fracasan es su falsa universalidad. Se redactan para cubrir desde un chatbot interno de baja sensibilidad hasta un sistema que participa en flujos operativos relevantes. Resultado: controles demasiado duros para usos triviales, demasiado blandos para los críticos y frustración generalizada en negocio, tecnología y control.

La salida no pasa por producir 40 páginas más de principios etéreos. Pasa por segmentar. Una entidad puede establecer umbrales basados en criterios verificables: tipo de datos tratados, conexión con sistemas internos, intervención en funciones críticas o importantes, dependencia de terceros, grado de autonomía de la salida y posibilidad de impacto sobre clientes o cumplimiento regulatorio. Eso sí cambia la gestión.

En la práctica, el mejor marco es el que fuerza decisiones operativas. Por ejemplo: un caso de uso con datos personales y proveedor externo no puede activarse sin revisión de privacidad y condiciones contractuales mínimas. Uno conectado a una función crítica debe entrar en el inventario DORA, con evaluación de dependencia y requisitos reforzados de monitorización, incidentes y salida. Uno de desarrollo de software debe coordinarse con seguridad de aplicaciones y control de cambios. Suena menos épico que “estrategia de IA responsable”. También sirve bastante más.

La trampa del “human in the loop” cuando nadie tiene tiempo de disentir

Pocas expresiones han envejecido tan rápido en compliance tecnológico como “hay un humano en el circuito”. Muy bien. ¿Qué humano? ¿Con qué formación? ¿Con qué tiempo? ¿Con qué visibilidad sobre las limitaciones del sistema? ¿Y con qué incentivo para llevar la contraria a una salida que llega envuelta en apariencia de autoridad técnica?

Desde una perspectiva de control, la supervisión humana solo vale si es sustantiva. Si el usuario se limita a validar recomendaciones porque el flujo operativo empuja a hacerlo, la autonomía efectiva del sistema aumenta, aunque el procedimiento formal mantenga una casilla de aprobación manual. Esa ficción tranquiliza a quienes redactan governance decks. No tanto a quienes tengan que explicar un incidente.

Aquí confluyen varias normas sin necesidad de fuegos artificiales doctrinales. Si la salida del sistema influye en operaciones, decisiones internas o comunicaciones y la organización no puede demostrar revisión adecuada, trazabilidad y capacidad de rectificación, se debilitan tanto la gobernanza interna de DORA arts. 5 y 6 como los principios de responsabilidad proactiva bajo GDPR. El problema no es filosófico. Es probatorio.

Lo que no conviene prometer al consejo ni al supervisor

Hay tres promesas especialmente peligrosas en esta fase del mercado.

La primera: “el proveedor garantiza el cumplimiento”. No existe tal atajo. Un proveedor puede ayudar, documentar, certificar ciertos controles o asumir obligaciones contractuales. La responsabilidad de integrar el servicio en una operativa regulada sigue recayendo en la entidad.

La segunda: “el uso es solo asistencial”. A veces sí. Otras veces el sistema acaba determinando qué se mira, qué se ignora y qué se escala. Y eso, en términos de riesgo, ya no es accesorio.

La tercera: “si surge un problema, lo apagamos”. Tal vez. Pero desactivar un servicio embebido en procesos, equipos y flujos de datos no siempre es trivial. Por eso la estrategia de salida importa tanto en outsourcing y terceros TIC. El regulador no pide planes de salida por deporte. Los pide porque la dependencia tecnológica tiene la mala costumbre de revelarse justo cuando el proveedor cambia condiciones, el servicio degrada o el incidente ya está encima de la mesa.

Entonces, ¿qué debería hacer ahora una entidad financiera?

No necesita esperar a un manifiesto europeo adicional ni a la próxima moda terminológica. Puede empezar hoy con una agenda bastante concreta y plenamente alineada con obligaciones que ya existen.

• Inventariar casos de uso reales, incluidos pilotos, funciones embebidas y herramientas no centralizadas. Si no está en el mapa, no está gobernado.
• Clasificar por criticidad operativa y sensibilidad de datos, usando criterios vinculados a funciones críticas o importantes, dependencia de terceros y posible impacto sobre clientes o cumplimiento.
• Revisar contratos y cadena de suministro para servicios externos con apoyo en DORA arts. 28 a 30 y en las directrices de externalización aplicables.
• Integrar privacidad, seguridad y continuidad desde diseño, con referencia explícita a GDPR arts. 25, 32, 33 y 35 cuando proceda.
• Definir monitorización y retirada: quién supervisa el rendimiento del caso de uso, qué eventos disparan revisión, cómo se registran incidentes y cómo se suspende el servicio sin improvisación.
• Elevar información útil al órgano de dirección, porque DORA art. 5 y NIS2 art. 20 no colocan la responsabilidad en una esquina técnica de la organización.

Esto no resuelve todos los dilemas jurídicos ni técnicos. Pero sí evita el error más caro: tratar la IA como una cuestión estética de innovación cuando ya es una cuestión de control operativo, datos, terceros y responsabilidad de gestión.

La conclusión incómoda

La regulación europea todavía tiene zonas grises, solapes y alguna tendencia burocrática que no sorprenderá a nadie. Pero en una cosa el mensaje es bastante nítido: si una entidad financiera incorpora sistemas de IA a procesos relevantes, no parte de cero ni opera en un vacío normativo. DORA, GDPR, NIS2 y las reglas de outsourcing ya ofrecen un armazón suficientemente serio para exigir inventario, evaluación de riesgo, gobernanza, control contractual, monitorización e intervención.

Quien espere una norma futura que venga a decirle, con nombres más modernos, lo que ya debería estar haciendo, probablemente está perdiendo un tiempo precioso. Y quien siga llamando “experimental” a una dependencia operativa conectada a datos, terceros y funciones sensibles está describiendo menos la tecnología que su propio nivel de negación.

Aquí está el quid: la discusión madura sobre IA en finanzas ya no va de fascinación tecnológica. Va de control. Y en regulación financiera, cuando algo va de control, deja de ser una tendencia y empieza a ser trabajo de verdad.