Gobernanza de IA generativa en entidades reguladas: del piloto al control efectivo

La fase del "vamos a probar Copilot, ChatGPT o un modelo open source en un sandbox" ya ha terminado. En banca, seguros y fintech, el problema serio empieza ahora: convertir el experimento útil en un sistema gobernado, trazable y defendible ante auditoría, supervisor y consejo. Y ahí es donde muchas organizaciones descubren algo incómodo: tenían casos de uso, pero no tenían control.

La IA generativa ha entrado por la puerta grande de productividad, atención al cliente, desarrollo de software, KYC, análisis documental y soporte interno. También ha entrado por la puerta lateral: equipos de negocio contratando herramientas SaaS con tarjeta corporativa, desarrolladores conectando APIs a datos reales y áreas jurídicas recibiendo respuestas "razonables" de un sistema que no sabe lo que no sabe. El regulador europeo no ha prohibido ese entusiasmo. Lo ha condicionado. Mucho.

Si eres CISO, responsable de cumplimiento, DPO o segunda línea de riesgo, aquí está el quid: la gobernanza efectiva de IA generativa no empieza clasificando herramientas por marca, sino identificando decisiones, datos y dependencias. El AI Act no te pregunta si usas un modelo famoso. Te obliga a entender si el caso de uso entra en una práctica prohibida, en un sistema de alto riesgo, en una obligación de transparencia o en una capa de deberes más transversal. Y, si además operas en servicios financieros, ese análisis no vive solo. Se cruza con DORA sobre riesgo TIC y terceros, con NIS2 sobre medidas de gestión de riesgos y gobernanza, y con GDPR sobre base jurídica, minimización, transferencias y decisiones automatizadas.

La tentación habitual es montar un "comité de IA" y declararse satisfechos. Mala idea. Un supervisor no te va a felicitar por tener PowerPoint. Te va a pedir inventario, criterios de clasificación, evidencias de aprobación, controles sobre proveedores, trazabilidad de entradas y salidas, gestión de incidencias y revisión continua. Es decir, gobierno real.

No toda IA generativa es de alto riesgo. Pero bastante más de la que parece puede acabar siéndolo

Conviene empezar por una aclaración que evita dos errores caros. Primero: usar IA generativa no significa automáticamente estar en "alto riesgo" bajo el AI Act. Segundo: tampoco significa estar fuera. Todo depende del uso concreto, no del marketing del proveedor.

El marco europeo clasifica los sistemas por niveles de riesgo. Las prácticas prohibidas aparecen en el artículo 5 del AI Act. Los sistemas de alto riesgo se delimitan por el artículo 6 y por los anexos I y III. Además, el reglamento impone obligaciones específicas a determinados modelos de propósito general y, dentro de ellos, a los modelos con riesgo sistémico. Para una entidad financiera, la clave práctica está menos en el laboratorio del proveedor y más en cómo aterriza la herramienta en un proceso regulado.

Ejemplos rápidos. Un asistente generativo interno para redactar borradores de políticas no suele ser alto riesgo por sí mismo. Un sistema que prioriza alertas AML para revisión humana tampoco encaja automáticamente en alto riesgo por el mero hecho de ser importante; habrá que analizar si entra en alguna categoría del anexo III o si afecta de forma material a decisiones reguladas. En cambio, un sistema usado para evaluar solvencia o determinar acceso a productos financieros puede rozar o entrar de lleno en categorías sensibles cuando la IA influye de forma sustancial en el resultado. Ahí el análisis deja de ser académico.

El error común es tratar la IA generativa como una capa neutra encima de un proceso ya existente. No lo es. Si el modelo redacta, resume, puntúa, recomienda o prioriza en un flujo de onboarding, fraude, siniestros o reclamaciones, está alterando el perfil de riesgo del proceso. Y ese cambio exige reclasificación.

Para evitar discusiones estériles, yo usaría una pregunta brutalmente simple en el inventario: si el modelo falla de forma plausible, ¿qué decisión cambia, qué derecho se afecta, qué dato se expone y quién responde? Si nadie sabe contestar, todavía no tienes un caso de uso aprobado; tienes una demo con presupuesto.

El artículo que muchas entidades están infravalorando: alfabetización en IA

Hay una disposición del AI Act que algunos han tratado como un detalle menor y no lo es: la obligación de adoptar medidas para garantizar un nivel suficiente de alfabetización en IA entre el personal y otras personas que operen o usen sistemas de IA por cuenta de la organización. Está en el artículo 4. No suena épico. Precisamente por eso puede pasar desapercibido hasta que llega una inspección o una revisión interna y alguien pregunta algo muy simple: ¿qué formación recibió el equipo que aprobó este uso, con qué alcance y con qué prueba documental?

La alfabetización en IA no es un curso genérico sobre "qué es un LLM" ni una sesión inspiracional del proveedor. Para una entidad regulada, debería cubrir como mínimo cinco bloques: límites del sistema y riesgo de alucinación; datos permitidos y prohibidos; criterios de escalado a revisión humana; sesgo y errores de salida; y obligaciones regulatorias por función. El desarrollador necesita una formación distinta del agente de atención al cliente. El equipo de compras necesita otra distinta. Y el consejo, sí, también necesita la suya, aunque no vaya a hacer prompts.

Esto conecta directamente con NIS2. La directiva exige a los órganos de dirección aprobar y supervisar las medidas de gestión de riesgos de ciberseguridad y seguir formación adecuada; esa exigencia aparece en el artículo 20. Y las medidas mínimas de gestión de riesgos están en el artículo 21. Traducido: si el uso de IA generativa crea nuevas dependencias, nuevos canales de fuga de información o nuevas superficies de manipulación, la formación ya no es un nice to have. Es un control de gobernanza.

La ironía aquí es evidente. Muchas compañías han invertido antes en licencias de IA que en enseñar a su gente cuándo no usarla. Luego llega el incidente de fuga de datos en un prompt y todos descubren que la política decía "usar con prudencia". Magnífico. Una frase tan útil como un paraguas de papel.

El inventario correcto no es una lista de herramientas; es un mapa de decisiones, datos y terceros

Si tuviera que elegir un único control fundacional, sería este: un inventario vivo de casos de uso de IA. No un Excel cosmético, sino un registro operativo que permita clasificar, aprobar, revisar y, si hace falta, apagar.

El inventario útil debería registrar al menos estos campos:

• Función de negocio afectada y dueño del proceso.
• Descripción exacta del caso de uso, no del producto.
• Tipo de modelo: proveedor externo, modelo open source, modelo afinado internamente, agente conectado a herramientas, sistema RAG.
• Datos de entrada: personales, especiales del artículo 9 GDPR, confidenciales, secretos empresariales, datos de clientes, datos de empleados, datos anonimizados o sintéticos.
• Origen de los datos y base jurídica si hay tratamiento de datos personales.
• Salida esperada y decisiones que puede influir.
• Grado de autonomía y puntos de revisión humana.
• Conectores y terceros implicados: API, nube, integrador, proveedor de embeddings, vector DB, herramientas de logging.
• Clasificación regulatoria preliminar: prohibido, alto riesgo, transparencia, uso interno de bajo riesgo, pendiente de análisis.
• Controles aplicados: filtrado, DLP, pseudonimización, rate limits, logging, red teaming, aprobaciones.
• Evidencias documentales y fecha de revisión.

¿Por qué tanta obsesión con el tercero? Porque DORA no perdona la ceguera contractual. Los artículos 28 a 30 del Reglamento (UE) 2022/2554 obligan a gestionar el riesgo derivado de terceros prestadores de servicios TIC, con registro de acuerdos contractuales, evaluación previa, derechos de acceso, auditoría y terminación, entre otros. Si tu caso de uso de IA depende de una API externa, de un proveedor cloud, de un integrador y de un servicio adicional de moderación, tienes una cadena de terceros. Si no la ves, DORA la verá por ti.

Además, ese inventario no puede vivir aislado en innovación o en IT. Tiene que enlazar con el registro de actividades de tratamiento del artículo 30 GDPR, con el inventario de activos y servicios críticos, y con el registro de terceros críticos de DORA. Cuando esos repositorios no se hablan, la organización empieza a tropezar con sus propias siglas.

Clasificar riesgo bajo el AI Act: lo que de verdad debería preguntar un comité de aprobación

Los comités de aprobación suelen hacer preguntas demasiado abstractas o demasiado técnicas. Ni "¿es seguro?" ni "¿qué modelo base usa?" bastan. Las preguntas buenas son las que convierten la ambigüedad regulatoria en decisiones binarias y evidencias trazables.

Un circuito serio de aprobación debería exigir respuestas documentadas a estas cuestiones:

1. ¿El caso de uso puede entrar en una práctica prohibida?

El artículo 5 del AI Act veta ciertos usos, incluidos determinados supuestos de manipulación, explotación de vulnerabilidades, evaluación social y algunas formas de identificación biométrica remota en tiempo real para fines policiales, con matices y excepciones. La mayoría de entidades financieras no está cerca de ese núcleo duro, pero cuidado con herramientas de inferencia emocional, perfilado agresivo o sistemas que explotan vulnerabilidades de colectivos concretos en ventas o recobro. El hecho de que un proveedor lo ofrezca como "engagement optimisation" no lo vuelve mágicamente aceptable.

2. ¿Influye materialmente en una decisión regulada o en el acceso a un servicio esencial?

Esta pregunta aterriza el artículo 6 y el anexo III. Si la IA puntúa, recomienda, prioriza o descarta solicitudes relacionadas con acceso a productos financieros, empleo, educación, servicios esenciales o evaluación de personas, el análisis de alto riesgo es obligado. No importa que haya un humano al final si ese humano valida de forma rutinaria la salida del sistema. La supervisión humana decorativa no arregla una mala clasificación.

3. ¿El sistema trata datos personales? ¿Cuáles y con qué base?

Si hay datos personales, la conversación cambia de idioma y entra GDPR. Artículo 5 para los principios; artículo 6 para la base jurídica; artículo 9 si aparecen categorías especiales; artículo 25 para privacidad desde el diseño; artículo 30 para el registro; artículo 32 para seguridad; artículos 44 y siguientes si hay transferencias internacionales. Si el caso puede implicar decisiones individuales automatizadas con efectos jurídicos o similares, aparece el artículo 22. No todos los copilotos llegan ahí. Algunos sí. Y cuando lo hacen, la frase "siempre hay un humano en el proceso" debe demostrarse con diseño, no con fe.

4. ¿Qué proveedor, qué modelo y qué régimen contractual sostienen el caso?

Aquí se cruzan DORA, outsourcing y seguridad. ¿El proveedor reutiliza prompts o inputs para entrenamiento? ¿Dónde se procesan los datos? ¿Qué subencargados intervienen? ¿Qué logs se conservan? ¿Permite desactivar retención? ¿Ofrece segregación lógica? ¿Hay derecho de auditoría suficiente o al menos evidencias equivalentes? Si la respuesta a varias de estas preguntas es "no lo sabemos", no estás aprobando tecnología; estás comprando incertidumbre.

5. ¿Qué evidencia quedará si dentro de doce meses alguien cuestiona una salida?

Esta es la pregunta favorita de cualquier auditor competente. ¿Se conservará el prompt, la versión del modelo, el contexto recuperado, el usuario que ejecutó la acción, la decisión final, la revisión humana y el resultado? ¿Durante cuánto tiempo? ¿Con qué controles de integridad? Sin trazabilidad, no hay defensa creíble.

La trazabilidad es el punto donde la mayoría de los pilotos se desmorona

En entornos regulados, la IA generativa no fracasa solo por sesgo o por precisión. Fracasa porque nadie puede reconstruir qué pasó. El modelo cambió de versión, el proveedor actualizó la capa de seguridad, el prompt se alteró en una integración, el contexto del RAG venía de una base documental contaminada y la decisión final se tomó fuera de flujo. Resultado: una salida material, pero sin cadena de custodia.

El AI Act exige, para sistemas de alto riesgo, obligaciones robustas sobre gestión de riesgos, gobernanza de datos, documentación técnica, registro automático de eventos, transparencia, supervisión humana, precisión, robustez y ciberseguridad. Esas obligaciones aparecen, entre otros, en los artículos 9 a 15. Para entidades usuarias o desplegadoras de sistemas de alto riesgo, las obligaciones relevantes incluyen el uso conforme a instrucciones, supervisión humana y conservación de logs cuando estén bajo su control, así como la vigilancia del funcionamiento y cooperación con autoridades, con artículos específicos dedicados a deployers y otros actores en la cadena. El mensaje práctico es inequívoco: si el modelo interviene en algo serio, debes poder reconstruir el contexto técnico y de negocio.

¿Qué significa eso en términos operativos? Como mínimo, cuatro capas de trazabilidad:

• Trazabilidad del modelo: versión, proveedor, fecha de cambio, parámetros relevantes, políticas activadas, región de procesamiento, dependencias.
• Trazabilidad del dato: fuente del contexto, fecha de extracción, clasificación, controles de acceso, reglas de retención, indicadores de calidad.
• Trazabilidad del uso: quién lanzó la consulta, con qué rol, desde qué sistema, con qué propósito declarado y bajo qué autorización.
• Trazabilidad de la decisión: salida generada, revisión humana, modificación posterior, decisión adoptada y justificación final.

Sin estas cuatro capas, la organización se queda en una posición muy débil ante tres escenarios muy reales: reclamación de cliente, investigación de protección de datos o revisión del supervisor financiero.

Y hay un detalle técnico que suele olvidarse: un sistema RAG mal gobernado puede ser peor que un modelo cerrado. Si el repositorio documental incluye políticas obsoletas, contratos no vigentes, expedientes con datos excesivos o documentos sin control de versiones, la IA no está "inventando"; está amplificando desorden interno con gran fluidez verbal. No es magia. Es desorganización asistida.

DORA cambia la conversación: ya no hablas solo de IA, hablas de riesgo TIC y dependencia de terceros

Desde el 17 de enero de 2025, DORA es plenamente aplicable. Esa fecha importa porque pone fin a la ficción de que la IA generativa es solo una cuestión de innovación o privacidad. Para entidades financieras cubiertas por DORA, cualquier despliegue serio de IA generativa pasa a ser también una cuestión de gestión de riesgo TIC, continuidad, terceros y, en ciertos casos, pruebas.

El reglamento exige un marco interno sólido de gestión del riesgo TIC en los artículos 5 a 16. Si un servicio de IA generativa se integra en procesos críticos o importantes, debe entrar en ese marco: identificación de activos, protección, prevención, detección, respuesta, recuperación y aprendizaje posterior. No basta con que el proveedor diga que su plataforma es segura. La entidad debe demostrar que entiende cómo falla el servicio y qué impacto tendría ese fallo en la continuidad operativa.

El capítulo sobre riesgo de terceros TIC es todavía más relevante para IA. El artículo 28 obliga a gestionar el riesgo asociado a proveedores TIC como parte integrante del marco general. El artículo 30 fija elementos contractuales clave. Y si el servicio soporta una función crítica o importante, el nivel de escrutinio sube. Aquí aparecen preguntas incómodas que muchas negociaciones comerciales han tratado de esquivar: salida ordenada, portabilidad, localización de datos, subcontratación en cadena, monitorización continua, derechos de acceso e inspección.

La novedad práctica es esta: el proveedor de IA deja de ser un simple SaaS simpático y pasa a ser un tercero TIC cuya falla puede convertirse en incidente operativo. Si el modelo se usa para soporte a analistas SOC, clasificación de fraude o automatización de cumplimiento, un corte del servicio, una degradación silenciosa o un cambio unilateral del modelo puede afectar a operaciones críticas. Y eso debe estar contemplado en el marco DORA, incluidos escenarios de contingencia.

¿Tu entidad ha definido condiciones de failover, umbrales de degradación aceptables y procedimientos para desactivar el uso en procesos críticos? Si no, todavía estás tratando la IA como una herramienta de oficina. El supervisor no.

NIS2 aporta algo que muchas políticas de IA olvidan: responsabilidad del órgano de dirección

La transposición de NIS2 ha sufrido retrasos en varios Estados miembros, pero el contenido material de la directiva ya marca el listón europeo. Para entidades incluidas en su ámbito, el artículo 21 obliga a adoptar medidas técnicas, operativas y organizativas apropiadas y proporcionadas. Entre ellas: políticas de análisis de riesgos y seguridad de los sistemas de información, gestión de incidentes, continuidad del negocio, seguridad en 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 higiene y formación.

Para gobernanza de IA generativa, el valor de NIS2 no está en que mencione LLMs. No lo necesita. Lo relevante es que obliga a tratar los nuevos patrones de riesgo como problemas de ciberseguridad y gobernanza, no solo de productividad. Prompt injection, exfiltración vía plugins o conectores, model poisoning en componentes open source, fuga de credenciales a través de asistentes de código, abuso interno de herramientas generativas y dependencia excesiva de un único proveedor: todo eso cabe razonablemente dentro de un enfoque NIS2 serio.

El artículo 20 añade otra pieza incómoda: el órgano de dirección debe aprobar las medidas de gestión de riesgos y supervisar su aplicación. Dicho sin diplomacia: el consejo no puede refugiarse en que la IA es "cosa de tecnología". Si un despliegue de IA generativa afecta a procesos críticos, la supervisión debe subir de nivel. No para que los consejeros se conviertan en ingenieros, sino para que haya apetito de riesgo explícito, métricas, escalado y rendición de cuentas.

GDPR sigue siendo el lugar donde más despliegues de IA se complican de verdad

El entusiasmo por el AI Act ha hecho que algunas entidades olviden algo elemental: hoy, el terreno donde más rápido puede tropezar un proyecto de IA generativa sigue siendo GDPR. No por teoría, sino por operaciones.

El primer frente es la base jurídica. Si usas datos personales en prompts, afinado, evaluación, monitorización o trazabilidad, necesitas una base del artículo 6. Si se cuelan categorías especiales, entra el artículo 9. La promesa de que "el proveedor no entrena con tus datos" no resuelve por sí sola la licitud del tratamiento. Solo reduce una parte del riesgo.

El segundo frente es la minimización. Artículo 5.1.c. Muchos pilotos fracasan aquí por una razón absurda: la forma más fácil de probar el sistema fue darle acceso a demasiado. Expedientes completos, correos, historiales de incidencias, contratos enteros, CVs, notas internas. Luego llega la revisión y nadie puede explicar por qué el caso de uso necesitaba tanto. Si tu arquitectura de IA no fuerza segmentación de datos, redacción automática o filtros previos, estás confiando la minimización a la disciplina del usuario final. Mala apuesta.

El tercero es privacidad desde el diseño y por defecto, artículo 25. Una implantación seria debería decidir desde el principio qué datos no pueden entrar nunca en prompts, qué patrones activan bloqueo automático, qué salidas se registran, quién puede revisar esos logs y cómo se evita que la monitorización de uso cree otro problema de privacidad. Sí, gobernar la IA implica gobernar también el control sobre quienes la usan.

El cuarto frente es la seguridad del artículo 32. Aquí se enlaza con DORA y NIS2: cifrado, control de acceso, segregación, logging, pruebas, resiliencia, restauración y evaluación periódica. Si el proveedor ofrece región UE pero replica metadatos fuera del EEE, o si no puedes desactivar almacenamiento de prompts, toca analizar transferencias internacionales bajo los artículos 44 y siguientes. No es un detalle contractual menor. Es el tipo de detalle que explota después, cuando ya has escalado el uso.

El quinto frente es el artículo 22 sobre decisiones automatizadas. No toda salida generativa entra ahí. Pero si la IA determina o influye decisivamente en una decisión con efectos jurídicos o de impacto similar sobre una persona, no basta con que un empleado haga clic en "aprobar". La intervención humana debe ser significativa, con capacidad real de revisar y alterar el resultado, y la organización debe poder demostrarlo. En crédito, fraude, siniestros, selección de personal o cierre de cuentas, el margen para el autoengaño se reduce mucho.

Y sí, en bastantes casos habrá que valorar una evaluación de impacto relativa a la protección de datos bajo el artículo 35. No porque la IA sea una palabra de moda, sino porque el tratamiento puede entrañar alto riesgo por volumen, sensibilidad, perfilado, observación sistemática o impacto sobre derechos. Si el DPIA se hace al final, solo sirve para documentar que llegaste tarde.

Qué debería exigir un supervisor, y qué evidencias conviene tener preparadas antes de que las pida

Un supervisor financiero, una autoridad de protección de datos o auditoría interna no van a pedirte una definición brillante de IA generativa. Van a pedirte pruebas. No una promesa de que hay control, sino rastro documental.

Estas son las evidencias más útiles porque conectan obligación con operación:

La tabla no es burocracia. Es una vacuna contra el caos. Cada fila representa una pregunta que llegará tarde o temprano.

Un consejo práctico: no mezcles en una única política de IA todas las obligaciones y esperes que eso resuelva el problema. Es mejor un paquete documental corto pero conectado: política marco, estándar de clasificación de casos de uso, procedimiento de aprobación, estándar de datos permitidos, estándar de terceros, y procedimiento de incidentes. Cada uno con propietario, versión y evidencia de aplicación. Menos manifiesto; más control operativo.

Errores comunes que delatan una gobernanza inmadura

Hay señales bastante claras de que una organización sigue en fase piloto aunque ya esté procesando actividades serias.

La primera es confundir aprobación de herramienta con aprobación de caso de uso. Autorizar Microsoft Copilot, Azure OpenAI, Gemini o un modelo local no significa autorizar cualquier uso sobre cualquier dato. El riesgo no está solo en la marca; está en la combinación concreta de dato, contexto, autonomía y decisión.

La segunda es depender de controles declarativos del proveedor. "No entrenamos con tus datos" ayuda. Pero no sustituye el análisis de retención, subprocesadores, telemetría, transferencias ni logging interno. Hay demasiadas implementaciones donde la empresa ha revisado la web comercial del proveedor con más atención que el flujo real de datos.

La tercera es no separar entornos. Si el mismo tenant, workspace o gateway sirve para prototipos, pruebas y producción con datos sensibles, la probabilidad de mezcla indebida se dispara. Aquí no hace falta dramatizar: basta con recordar cuántos errores nacen de un simple copiar y pegar en el entorno equivocado.

La cuarta es no gobernar los conectores. Un copiloto con acceso a correo, SharePoint, CRM, repositorio documental y tickets tiene tanto riesgo como permisos tenga. El principio de mínimo privilegio sigue siendo válido, aunque ahora llegue envuelto en una interfaz conversacional muy elegante.

La quinta es registrar demasiado poco o demasiado. Si no registras prompts y salidas relevantes, no podrás investigar. Si registras todo sin criterios ni control de acceso, crearás un nuevo depósito de datos sensibles. Gobernar IA también consiste en decidir qué trazabilidad hace falta y cuál se convierte en lastre regulatorio.

La sexta es ignorar el software libre y los modelos abiertos. Muchas áreas técnicas asumen que, por ejecutar un modelo en infraestructura propia, desaparece el riesgo de terceros. No exactamente. Persisten dependencias de repositorios, librerías, embeddings, vectores, herramientas de orquestación y datasets. Y si hay componentes vulnerables o sin mantenimiento, el problema pasa a ser tuyo con una rapidez admirable.

Cómo diseñar un circuito de control que no mate la innovación ni regale el riesgo

La gobernanza útil no bloquea todo ni aprueba todo. Segmenta. Para eso conviene establecer niveles de exigencia en función del impacto.

En un nivel básico entrarían usos internos sin datos personales ni decisiones materiales: apoyo a redacción, ideación, documentación técnica con corpus controlado. Aquí bastan políticas claras, formación, herramientas aprobadas y controles de logging proporcionados.

En un nivel intermedio entrarían usos con datos corporativos no públicos, soporte a operaciones o generación de contenido con revisión humana obligatoria. Aquí ya hacen falta evaluación de proveedor, restricción de datos, aprobación formal del caso de uso, registros de uso y pruebas de seguridad específicas.

En el nivel alto colocarías usos con datos personales sensibles, procesos críticos, impacto sobre clientes o dependencia significativa de terceros. En ese nivel la aprobación debería requerir análisis legal completo, revisión de riesgo TIC, DPO, arquitectura, seguridad, plan de contingencia, reglas de supervisión humana y evidencia de pruebas antes de producción.

Esto no es teoría. Es la manera de evitar dos patologías empresariales muy conocidas. La primera: el cuello de botella donde todo caso de uso acaba atascado en el mismo comité mensual. La segunda: la selva donde nadie revisa nada y luego todos fingen sorpresa cuando aparece el primer incidente.

Si quieres un criterio operativo sencillo, úsalo así: más autonomía + más sensibilidad del dato + más impacto en derechos o procesos críticos = más control ex ante y más monitorización ex post. Lo demás son adornos.

Implicaciones para entidades financieras españolas

Para bancos, aseguradoras, establecimientos de pago, EDEs, gestoras y fintech con actividad en España, la gobernanza de IA generativa no se evaluará en un vacío. Se leerá junto a marcos ya supervisados por Banco de España, CNMV y DGSFP, además de la Agencia Española de Protección de Datos cuando entren datos personales o decisiones sobre individuos.

La consecuencia práctica es que conviene integrar la gobernanza de IA en estructuras ya existentes: comités de riesgo no financiero, outsourcing, seguridad de la información, protección de datos y continuidad. Crear un comité paralelo puede sonar moderno, pero a menudo solo consigue que nadie sepa quién decide qué. Mejor un modelo federado con dueños claros y un registro común.

Para entidades sujetas a DORA, el foco del supervisor probablemente caerá en tres sitios: identificación de funciones críticas o importantes afectadas por IA; gestión de terceros TIC implicados; y capacidad de respuesta ante incidentes o degradación del servicio. Para GDPR, el escrutinio irá a base jurídica, minimización, transferencias y decisiones automatizadas. Para NIS2, a gobernanza, formación y medidas efectivas.

Y hay una peculiaridad española que no conviene perder de vista: las organizaciones financieras llevan años produciendo políticas impecables sobre papel y sufriendo después en la evidencia de ejecución. La IA generativa castiga especialmente esa distancia entre norma interna y operación real. Porque deja rastro. O debería dejarlo.

La pregunta final no es si usar IA generativa, sino si puedes defender su uso bajo presión

La mayoría de entidades reguladas europeas va a usar IA generativa. Algunas ya la están usando más de lo que sus responsables de cumplimiento creen. El debate serio, por tanto, no es adopción sí o no. Es si la adopción puede sostenerse cuando un cliente reclama, cuando un auditor reconstruye una decisión, cuando se descubre un tercero no declarado o cuando el supervisor pregunta qué controles se aplicaron antes de poner el sistema en producción.

El AI Act añade un marco nuevo y exigente. DORA convierte buena parte del problema en gestión de riesgo TIC y terceros. NIS2 empuja la responsabilidad hacia la dirección. GDPR sigue siendo la mina antipersona operativa donde más fácil es meter la pata. Vistas juntas, estas normas dibujan una conclusión bastante clara: gobernar IA generativa en finanzas no consiste en redactar una política amable. Consiste en construir evidencia de control.

Si tu organización no puede responder hoy, con documentos y registros, a estas cinco preguntas —qué casos de uso existen, cómo se clasificaron, qué datos tocan, qué terceros intervienen y qué trazabilidad queda— todavía no ha pasado del piloto al control efectivo. Y en una entidad regulada, seguir en piloto cuando ya estás en producción no es agilidad. Es exposición.