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

La fase de enamoramiento con la IA generativa ha terminado. Ahora empieza la parte incómoda: justificarla ante auditoría, ante el DPO, ante el CISO, ante compras, ante el supervisor y, si las cosas se tuercen, ante el consejo. En banca, seguros y fintech, el piloto simpático en un sandbox deja de ser simpático en cuanto toca datos personales, influye en una decisión relevante o se apoya en un proveedor que nadie ha metido de verdad en el perímetro de terceros críticos.

Aquí está el quid: la gobernanza útil de IA generativa no consiste en redactar una política elegante de veinte páginas. Consiste en poder responder, con evidencias, a cinco preguntas muy concretas. Qué casos de uso existen. Qué categoría regulatoria tiene cada uno. Qué controles de aprobación se aplicaron antes de ponerlo en producción. Qué trazabilidad hay sobre modelo, datos, prompts, resultados y cambios. Y quién puede parar el sistema sin pedir permiso a media organización.

El AI Act obliga a tomarse esto en serio, pero no actúa solo. Si la entidad financiera opera en la UE, la gobernanza de IA generativa se cruza, como mínimo, con GDPR para la base jurídica, minimización y derechos; con DORA para gestión del riesgo TIC, incidentes y terceros; y con NIS2 para medidas de gestión del riesgo de ciberseguridad y gobernanza. La trampa habitual es tratar la IA como un asunto exclusivo de innovación o de legal. No lo es. La IA generativa es un problema de arquitectura de control.

Este análisis no va de repetir definiciones. Va de cómo pasar del “tenemos varios pilotos” al “podemos defender este despliegue ante un supervisor europeo en 2026 sin improvisar”.

Primero, deja de gobernar herramientas y empieza a gobernar casos de uso

El error más caro que estoy viendo en entidades reguladas es inventariar productos en vez de inventariar usos. “Usamos Copilot”, “usamos un LLM privado”, “tenemos un chatbot”. Eso no sirve para gobernar nada. Un mismo modelo puede usarse para resumir documentación interna, asistir a analistas de fraude, redactar comunicaciones comerciales o ayudar en la evaluación de siniestros. Reguladoramente, no es la misma película.

El inventario útil debe tener como unidad mínima el caso de uso. No la licencia ni el proveedor. Para cada caso de uso, la entidad debería registrar al menos ocho campos operativos:

• finalidad concreta y proceso de negocio afectado;
• línea de defensa propietaria del uso;
• tipo de usuarios y grado de autonomía del sistema;
• datos de entrada, con identificación expresa de datos personales, datos sensibles y secretos empresariales;
• modelo o servicio utilizado, versión y proveedor;
• salida generada y efecto real de esa salida en decisiones, comunicaciones o controles;
• clasificación regulatoria inicial bajo AI Act, GDPR, DORA y NIS2;
• evidencias de aprobación, pruebas, monitorización y kill switch.

Si este inventario no existe, el resto es teatro corporativo. Y el supervisor huele el teatro enseguida.

La lógica del AI Act obliga precisamente a ese enfoque basado en uso. La norma clasifica sistemas en función del riesgo y prohíbe algunos usos por considerarlos de riesgo inaceptable. La Comisión Europea resume el esquema regulatorio en cuatro niveles: riesgo inaceptable, alto riesgo, riesgo limitado y riesgo mínimo. La clasificación no depende de si el modelo suena muy futurista, sino del contexto en que se usa y del impacto potencial.

Para una entidad financiera, la pregunta correcta no es “¿nuestro modelo fundacional es de alto riesgo?”. La pregunta correcta es “¿este sistema de IA, tal y como está integrado en un proceso de negocio concreto, entra en un supuesto de alto riesgo o activa otras obligaciones?”. Ese matiz cambia por completo la gobernanza.

Clasificar bien el riesgo bajo el AI Act: donde se gana o se pierde el control

El AI Act introduce obligaciones específicas para sistemas de alto riesgo y otras de transparencia para determinados usos. Además, desde 2026 ya no basta con una lectura superficial del texto. Las organizaciones tienen que aterrizarlo en su taxonomía interna.

Un punto operativo clave es diferenciar tres escenarios que a menudo se mezclan:

1. IA generativa como productividad interna sin efecto material directo

Un asistente para resumir políticas internas, redactar borradores de informes o traducir documentación técnica puede quedar fuera de alto riesgo y moverse en un espacio de riesgo limitado o mínimo, dependiendo del diseño y del impacto. Eso no significa barra libre. Si el sistema procesa datos personales, GDPR sigue plenamente vigente. Si es un servicio TIC prestado por un tercero, DORA art. 28 y siguientes sobre gestión del riesgo de terceros ICT entran en juego. Y si el uso se integra en una función crítica, la conversación deja de ser inocente.

2. IA generativa que influye en decisiones sobre clientes, empleados o contrapartes

Aquí empieza lo serio. Si la IA generativa interviene en procesos como admisión de clientes, priorización de alertas AML, gestión de siniestros, evaluación de solvencia, atención de reclamaciones con efectos prácticos o cribado de candidaturas, la entidad debe analizar si el sistema cae en categorías de alto riesgo del AI Act. El anexo III del reglamento es la referencia obligada para esa clasificación, porque enumera áreas de alto riesgo por caso de uso, no por marketing del proveedor.

No toda automatización en finanzas será automáticamente “alto riesgo” por usar IA generativa. Pero muchas entidades están infraevaluando algo esencial: un sistema que “solo asiste” puede ser materialmente decisivo si el usuario humano se limita a validar lo que la máquina propone. Ese fenómeno de automatización encubierta no desaparece por poner un cartel de “human in the loop”. Si el humano no tiene criterio, tiempo ni incentivos para discrepar, el control es decorativo.

3. IA generativa embebida en productos de terceros o en servicios compartidos

Este es el agujero favorito del riesgo operativo. La entidad compra una herramienta de productividad, un CRM, una solución de contact center o una plataforma antifraude. Meses después, el proveedor activa funciones generativas, conectores externos, entrenamiento opcional con datos del cliente o nuevos subprocesadores. Si compras no obliga a un proceso formal de reevaluación, la organización descubre el cambio cuando ya hay datos circulando por donde no debían.

El AI Act impone obligaciones a distintos actores de la cadena, incluidos proveedores y desplegadores. La traducción práctica para una entidad regulada es simple: no puedes esconderte detrás de la etiqueta “lo hace el proveedor”. Si despliegas el sistema y lo integras en un proceso sujeto a regulación, tu carga de control sigue ahí.

Hay además una obligación que muchas empresas trataron al principio como algo menor y que en 2026 ya no debería pasar desapercibida: la alfabetización en IA. El AI Act exige que quienes operen o utilicen sistemas de IA cuenten con un nivel suficiente de alfabetización en IA, adaptado a su función. No es un webinar anual con una encuesta de cinco preguntas. Para una entidad regulada, significa poder demostrar que el analista de fraude, el gestor de siniestros, el equipo de atención al cliente y el comité de aprobación entienden limitaciones, sesgos, alucinaciones, uso permitido y escalado de incidencias. Si no, el “supervisor humano” del que todos presumen es poco más que un sello de goma.

La matriz que sí funciona: impacto regulatorio, autonomía y criticidad del proceso

La mayoría de matrices internas de IA fallan por exceso de simplicidad. Solo preguntan si hay datos personales, si hay decisión automatizada o si el proveedor es externo. Con eso no basta. Lo que funciona mejor en entidades reguladas es una matriz de tres ejes.

Primer eje: impacto regulatorio del uso. No es lo mismo generar borradores internos que producir una recomendación que afecte a la relación contractual con un cliente o a la respuesta de una función de control.

Segundo eje: grado de autonomía. Una IA que propone textos revisables no es lo mismo que una IA que ordena alertas, resume expedientes o puntúa casos de forma que condiciona de hecho la decisión humana posterior.

Tercer eje: criticidad del proceso y dependencia TIC. Si el sistema está dentro de una función importante o crítica, o si su indisponibilidad compromete operación, cumplimiento o servicio al cliente, DORA obliga a tratarlo como algo más que una utilidad de oficina.

Con esos tres ejes, la entidad puede definir niveles internos de aprobación. Por ejemplo:

• nivel 1: uso interno de bajo impacto, datos no sensibles, sin decisiones materiales;
• nivel 2: uso con datos personales o salida externa, pero sin efecto decisorio significativo;
• nivel 3: uso en procesos regulados, de control o con posible impacto sobre derechos, acceso a servicios o tratamiento diferenciado;
• nivel 4: uso potencialmente de alto riesgo, en función crítica, con fuerte dependencia de terceros o con necesidad de evaluación reforzada.

La ventaja de esta aproximación es que permite casar AI Act con los marcos que ya conoce la organización. Nivel 3 y 4 deberían activar, como mínimo, revisión de privacidad, seguridad, resiliencia, contratación y continuidad; trazabilidad reforzada; criterios de salida; y reporting periódico a un comité con autoridad real. Sin autoridad real, ya se sabe lo que pasa: se discute mucho, se decide poco y producción va por libre.

GDPR no desaparece porque el proveedor jure que no entrena con tus datos

La conversación sobre IA generativa y privacidad se ha llenado de medias verdades. Una de las más comunes: “no hay problema porque el proveedor no usa nuestros prompts para entrenar el modelo”. Bien. Eso resuelve una parte del riesgo, no el conjunto.

Si en los prompts o en los documentos adjuntos hay datos personales, el tratamiento existe igual. Y entonces aparecen las obligaciones conocidas, solo que más fáciles de incumplir a gran velocidad.

La primera es la base jurídica del tratamiento, conforme al GDPR art. 6. Si hay categorías especiales de datos, también art. 9. La segunda es la transparencia, conforme a los arts. 13 y 14, cuando proceda. La tercera es la minimización del art. 5.1.c. Y la cuarta, que suele explotar tarde, es la capacidad de atender derechos. Si un interesado ejerce acceso, rectificación u oposición, la entidad necesita saber si su dato personal pasó por una interacción generativa, con qué proveedor, en qué logs y con qué periodo de retención.

El GDPR art. 25 sobre protección de datos desde el diseño encaja aquí de forma casi quirúrgica. Un caso de uso de IA generativa no debería aprobarse sin decisiones explícitas sobre redacción de prompts, mascarado o seudonimización, retención de logs, restricción de conectores, limitación de contexto recuperable y revisión humana de salidas. No porque quede elegante en una política, sino porque sin eso luego no puedes explicar por qué un dato de salud acabó resumido en una herramienta de propósito general para resolver una reclamación menor.

Dos errores operativos se repiten demasiado:

• permitir prompts libres con datos de clientes cuando el caso de uso puede resolverse con datos sintéticos, plantillas o variables tokenizadas;
• guardar por defecto historiales completos de conversaciones y salidas sin una política de conservación alineada con finalidad y necesidad.

Si, además, el proveedor o alguno de sus subencargados opera fuera del EEE, el capítulo V del GDPR sobre transferencias internacionales vuelve a la mesa. No desaparece por el simple hecho de que el producto tenga una bonita consola de administración en Europa. Lo relevante es el flujo real de datos, no el color del folleto comercial.

Y luego está el art. 33 del GDPR: notificación de violaciones de seguridad en 72 horas. Cuando una fuga, exposición indebida o uso no autorizado afecte a datos personales tratados a través de una herramienta de IA generativa, el reloj corre igual. La diferencia es que, sin trazabilidad, la entidad tardará más en entender qué pasó, qué datos se vieron afectados y si el incidente exige notificación a la autoridad y comunicación a interesados. Mala combinación: incidente rápido, investigación lenta.

DORA convierte la IA generativa en un problema de riesgo TIC y de terceros, no solo de innovación

Si tu entidad sigue tratando la IA generativa como una iniciativa de negocio con revisión legal al final, DORA ya te está diciendo que vas tarde. El reglamento exige un marco de gestión del riesgo TIC sólido y documentado. La IA generativa, cuando se apoya en servicios cloud, APIs, modelos externos, plugins o conectores corporativos, forma parte de ese paisaje.

DORA art. 5 obliga al órgano de dirección a definir, aprobar, supervisar y asumir la responsabilidad del marco de gestión del riesgo TIC. No hay escapatoria elegante para delegarlo todo en tecnología o cumplimiento. Si la entidad aprueba usos generativos que pueden afectar a operaciones críticas, atención al cliente o funciones de control, el consejo tiene que entender al menos qué dependencias está comprando, qué escenarios de fallo existen y cómo se ejerce supervisión.

Después viene la parte menos glamourosa y más decisiva: terceros. DORA art. 28 y siguientes establecen obligaciones sobre gestión del riesgo de terceros proveedores de servicios TIC. Para IA generativa, eso implica revisar mucho más que el SLA y el precio por token. Hay que mirar subcontratación en cadena, localización del tratamiento, condiciones de acceso a datos, derecho de auditoría, soporte forense, notificación de incidentes, reversibilidad, salida y dependencia operativa.

La ironía aquí es conocida: muchas entidades dedican meses a negociar cláusulas robustas con su core banking provider y luego activan funciones generativas en herramientas “de productividad” con un nivel de escrutinio que no pasaría ni una auditoría universitaria. Sin embargo, por ahí se filtran datos, decisiones y dependencias muy reales.

DORA art. 11, sobre respuesta y recuperación, también importa. Si el uso generativo soporta un proceso de negocio relevante, la entidad necesita escenarios de degradación: qué pasa si el modelo no responde, devuelve resultados erráticos, sufre una caída regional, queda suspendido por el proveedor o debe desconectarse por un incidente de seguridad. “Volvemos al proceso manual” solo es una respuesta válida si el proceso manual existe, está documentado y alguien lo ha probado este año. Si no, es literatura.

No olvidemos el reporting de incidentes. DORA establece un régimen específico para incidentes graves relacionados con TIC. No todo problema con una IA generativa será reportable, pero algunos sí pueden llegar a serlo si comprometen disponibilidad, integridad, confidencialidad o continuidad de servicios relevantes. La entidad debe definir criterios previos para distinguir entre un error de calidad del modelo, un incidente de seguridad y un incidente TIC potencialmente clasificable bajo DORA. Esperar a decidirlo en caliente no suele salir bien.

NIS2 añade una capa de gobernanza que muchas entidades subestiman

NIS2 no compite con DORA; la complementa. Donde DORA entra con precisión quirúrgica en el sector financiero, NIS2 refuerza la obligación de gestión del riesgo de ciberseguridad y la responsabilidad de la dirección en entidades esenciales e importantes dentro de su ámbito. El art. 21 de NIS2 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar riesgos. Entre ellas figuran políticas de análisis de riesgos, gestión de incidentes, continuidad, seguridad de la cadena de suministro, seguridad en adquisición y mantenimiento de sistemas, y evaluación de la eficacia de medidas.

Traducido a IA generativa: si la entidad despliega asistentes conectados a repositorios internos, integra modelos en workflows corporativos o habilita generación automática de respuestas a clientes, está introduciendo nuevas superficies de ataque y nuevas rutas de error. La pregunta de NIS2 no es si la herramienta tiene funciones inteligentes. La pregunta es si la entidad ha actualizado sus controles de acceso, segmentación, logging, validación de salidas, gestión de secretos, revisión de integraciones y monitorización de anomalías para ese caso concreto.

Hay un punto especialmente incómodo. NIS2 insiste en seguridad de la cadena de suministro. La IA generativa moderna rara vez depende de un único actor. Tienes proveedor principal, cloud subyacente, modelos de terceros, embeddings, herramientas de observabilidad, conectores, bibliotecas open source y, a veces, retrieval sobre fuentes internas o externas. Esa cadena es bastante más larga de lo que aparece en la factura. Si no la cartografías, no la controlas.

Lo que un supervisor querrá ver: evidencias, no intenciones

Cuando un supervisor, auditor interno o inspección temática revise la gobernanza de IA generativa, no va a preguntar primero por tu manifiesto ético. Va a pedir rastros verificables. Quiere ver si el control existe antes del incidente, no después.

La evidencia mínima razonable para un caso de uso material incluye, como poco, estos artefactos:

• registro del caso de uso con propietario, finalidad, clasificación de riesgo y fecha de aprobación;
• evaluación de riesgo regulatorio que cite expresamente AI Act, GDPR, DORA y, si aplica, NIS2;
• decisión documentada sobre si el sistema entra o no en una categoría de alto riesgo, con referencia al anexo III del AI Act cuando proceda;
• DPIA o análisis equivalente cuando el tratamiento de datos personales lo exija, conforme al GDPR art. 35;
• arquitectura de datos y flujos de integración, incluyendo logs, retención y transferencias;
• evidencia de due diligence del proveedor y de revisión contractual de terceros conforme a DORA;
• pruebas de seguridad y de comportamiento: prompt injection, data leakage, access control, toxicidad, alucinación material y bypass de restricciones;
• criterios de aceptación antes de producción y métricas de monitorización posterior;
• registros de formación específica de usuarios y aprobadores, enlazados con la obligación de alfabetización en IA;
• procedimiento de escalado, desactivación y reversión del uso.

Si falta la mitad de esto, no pasa nada el día que todo va bien. El problema llega cuando hay una reclamación, un hallazgo de auditoría o una investigación interna. Entonces la organización descubre que sabía mucho de prompts y poco de pruebas.

De la política al control: cinco puertas de aprobación que sí cambian el riesgo

Las entidades que están madurando bien este asunto no aprueban la IA generativa con una única firma. La someten a cinco puertas de control distintas, cada una con derecho real a bloquear.

Puerta 1: negocio y justificación de uso

El área promotora debe explicar qué problema resuelve el caso de uso, qué alternativa no generativa existe y por qué la IA es necesaria. Esto parece burocracia, pero evita muchos despliegues absurdos. Si el supuesto valor es “ahorrar tiempo” y nadie ha medido tiempo, probablemente estás financiando una demo prolongada.

Puerta 2: clasificación regulatoria y de privacidad

Aquí se decide si hay datos personales, si se requiere DPIA, si hay transferencias, si la salida afecta a derechos o acceso a servicios, y si el uso puede acercarse a alto riesgo bajo AI Act. Sin esta puerta, la entidad descubre demasiado tarde que un chatbot “informativo” estaba orientando de facto decisiones de contratación o tratamiento de reclamaciones.

Puerta 3: seguridad y arquitectura

Revisión de identidades, privilegios, segmentación, conectores, secretos, cifrado, logging, sandboxing y controles frente a prompt injection, data exfiltration y over-permissioning. La mayoría de incidentes internos serios con IA generativa no llegan por una sofisticación de película; llegan por permisos excesivos y conectores mal gobernados.

Puerta 4: terceros y resiliencia

Evaluación contractual y operativa conforme a DORA. Quién es el proveedor real, qué subprocesadores usa, qué dependencia tecnológica crea, qué auditorías admite, qué notificación de incidentes ofrece, cómo se sale del servicio y en qué plazo. Si el proveedor no puede responder con precisión a estas preguntas, la entidad no debería compensar esa opacidad con fe.

Puerta 5: operación, monitorización y salida

Ningún caso de uso debería ir a producción sin umbrales claros de error, revisiones periódicas, métricas de calidad y seguridad, responsable de seguimiento y kill switch operativo. Kill switch de verdad: persona designada, pasos documentados, reversión probada y alternativa disponible.

Estas puertas funcionan mejor cuando se integran en el ciclo de cambio existente de la entidad, no como comité paralelo de innovación. Si la IA generativa se cuela por una “fast lane” al margen del gobierno TIC y de riesgos, la organización está creando una excepción permanente. Eso, tarde o temprano, termina mal.

Trazabilidad: la palabra menos sexy y más decisiva del despliegue

La trazabilidad es la diferencia entre gobernar y cruzar los dedos. En IA generativa, trazabilidad significa poder reconstruir qué modelo se usó, con qué configuración, qué datos entraron, qué conectores estaban activos, qué salida se produjo, qué usuario la aceptó y qué cambio se introdujo después.

No hace falta registrar todos los prompts de todos los usuarios en bruto e indefinidamente. De hecho, desde privacidad, eso puede ser una mala idea. Pero sí hace falta diseñar un esquema de logging proporcional que permita investigación, auditoría y mejora de control. Para usos materiales, la entidad debería conservar al menos metadatos suficientes sobre versión del modelo, fecha y hora, fuente documental usada por el sistema, identidad del usuario, decisión final humana y excepciones detectadas.

La trazabilidad también protege frente a un riesgo organizativo muy concreto: la deriva silenciosa. Un caso de uso aprobado para resumir expedientes internos acaba meses después generando borradores que se envían a clientes; luego alguien conecta una base adicional; luego cambia el proveedor de modelo subyacente. Nadie “lanza un proyecto”. Simplemente ocurre. Sin control de cambios y revisión periódica, esa deriva convierte un uso aceptable en otro que exigiría evaluación totalmente distinta.

A efectos de AI Act, esta capacidad de documentación y supervisión encaja con el espíritu de las obligaciones sobre gestión del riesgo, documentación técnica, registro y supervisión humana aplicables a sistemas regulados. A efectos de DORA y NIS2, es pura higiene de operación y seguridad. A efectos de GDPR, facilita rendición de cuentas del art. 5.2. No es un capricho de compliance. Es infraestructura probatoria.

Escenarios sectoriales: dónde se rompe antes en banca, seguros y fintech

Banca: copilotos en operaciones y atención al cliente

En bancos, el foco inicial suele estar en productividad interna, atención al cliente, soporte al empleado y análisis documental. El riesgo real aparece cuando un copiloto resume alertas de fraude, prioriza expedientes, propone respuestas regulatorias o asiste en decisiones comerciales sobre clientes vulnerables. Aunque la salida no sea “la decisión final”, puede sesgarla materialmente. Si además consume historiales de interacción y documentación contractual, el frente de GDPR se ensancha rápido.

Un supervisor probablemente preguntará: qué controles impiden que el asistente ofrezca información no autorizada, cómo se valida la exactitud en comunicaciones externas, qué datos puede consultar, qué registros deja y qué proceso existe para revisar errores sistemáticos. “Tenemos un disclaimer” no es una respuesta técnica ni jurídica.

Seguros: siniestros, suscripción y reclamaciones

En seguros, la tentación es automatizar redacción de comunicaciones, resumen de documentación pericial y asistencia al tramitador. Todo razonable, hasta que la herramienta empieza a influir de hecho en la valoración del expediente, en la priorización de casos o en el lenguaje usado para aceptar o rechazar coberturas. Aquí la combinación entre explicabilidad práctica, documentación del razonamiento y revisión humana es crítica.

Si el sistema utiliza datos de salud, incluso de forma indirecta, el listón de privacidad sube de inmediato. Y si el proveedor retiene trazas de interacciones más allá de lo necesario o las usa para mejorar servicios, el problema no se arregla con una cláusula genérica de confidencialidad.

Fintech: velocidad, APIs y dependencia extrema de terceros

La fintech europea tiene una ventaja y un problema. La ventaja es que suele integrar controles modernos con más rapidez. El problema es que vive conectada a terceros. Herramientas de onboarding, KYC, scoring, CRM, analítica, soporte y cloud. Añadir capas generativas en ese tejido multiplica el riesgo de propagación: un cambio en una API, en un modelo subyacente o en una política de retención puede afectar a varios procesos a la vez.

En fintech, el control más infravalorado sigue siendo el de arquitectura de permisos. Muchas organizaciones limitan muy bien el acceso humano directo a ciertos datos, pero luego conceden a un asistente integrado permisos amplios “porque así funciona mejor”. Funciona mejor hasta que no.

Errores comunes que delatan una gobernanza inmadura

Hay patrones que se repiten tanto que casi sirven de test diagnóstico.

Uno: la política corporativa prohíbe introducir datos sensibles en herramientas públicas, pero la entidad no ofrece una alternativa aprobada para necesidades reales. Resultado previsible: shadow AI. El usuario no deja de tener prisa porque cumplimiento redacte un PDF.

Dos: se evalúa al proveedor en abstracto, no el caso de uso concreto. Un proveedor puede ser razonable para asistencia interna y totalmente inapropiado para un flujo con decisiones materiales o datos especialmente delicados.

Tres: se confunde revisión humana con supervisión humana. Revisar de vez en cuando muestras de salida no equivale a supervisar un sistema que influye en miles de interacciones.

Cuatro: se aprueba el despliegue sin definir indicadores de fallo. Si no has decidido qué tasa de error, qué tipo de alucinación o qué desvío operacional obliga a pausar el servicio, el sistema solo se detendrá cuando el daño ya sea visible.

Cinco: el inventario de terceros no refleja la cadena completa. Solo aparece el proveedor de front-end, no el modelo subyacente, el cloud, los conectores ni servicios auxiliares.

Seis: nadie es dueño del caso de uso una vez en producción. Innovación lo lanza, tecnología lo conecta, negocio lo usa, cumplimiento lo revisó una vez y el riesgo se queda huérfano. Ese vacío de propiedad es una invitación al incidente.

Tabla comparativa: obligación, responsable y evidencia que deberías tener ya

Checklist de evidencias para auditoría

Si mañana tuvieras una revisión interna o una inspección temática sobre IA generativa, esta es la documentación que debería estar disponible sin montar una expedición arqueológica por SharePoint:

• inventario vivo de casos de uso, con fecha de alta, propietario y estado;
• taxonomía interna de riesgo que conecte AI Act, GDPR, DORA y NIS2;
• criterios escritos para distinguir usos prohibidos, de alto riesgo, de transparencia y de bajo impacto;
• procedimiento de aprobación con firmas o validaciones trazables de negocio, seguridad, privacidad y terceros;
• plantilla de evaluación de proveedor específica para IA generativa, no reciclada de SaaS genérico;
• política de uso aceptable con ejemplos permitidos y prohibidos por función;
• controles técnicos de DLP, logging, identidad, retención y gestión de conectores;
• pruebas de funcionamiento y de seguridad previas a producción, con defectos y remediación;
• métricas periódicas de calidad, incidencias, excepciones y revisiones de deriva del caso de uso;
• registro de formación por colectivos expuestos y responsables de supervisión;
• mecanismo probado de parada y reversión.

Lo relevante no es tener una carpeta enorme. Lo relevante es que las piezas encajen entre sí. Si el inventario dice una cosa, el contrato otra, y los logs no permiten verificar ninguna, la organización tiene documentos, no control.

Implicaciones para entidades financieras españolas

Para entidades españolas, el reto no es solo europeo; es también de coherencia supervisora local. Banco de España, CNMV y DGSFP llevan años elevando el tono sobre gobierno del riesgo tecnológico, externalización, continuidad y control interno. La IA generativa aterriza justo en ese cruce. No hace falta imaginar una circular milagrosamente nueva para entender lo que te van a pedir: inventario, gobierno, evidencia, proporcionalidad y capacidad de intervención.

Las entidades significativas, las aseguradoras con procesos intensivos en datos y las fintech con estructuras ligeras tienen un problema común: la presión comercial por desplegar rápido. Pero el supervisor español rara vez premia la velocidad mal documentada. La combinación europea de AI Act, GDPR, DORA y NIS2 empuja a una conclusión bastante poco romántica y muy práctica: quien no integre la IA generativa en su marco de control existente acabará gestionándola como una excepción perpetua. Y una excepción perpetua es, en términos de auditoría, una debilidad estructural con buen branding.

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

En 2026 ya no tiene mucho sentido discutir si la banca, los seguros o la fintech van a usar IA generativa. La respuesta es sí. La cuestión seria es otra: cuando llegue una incidencia, una reclamación, una auditoría o una revisión supervisora, ¿podrás explicar con precisión qué sistema se usó, para qué, con qué datos, con qué controles, con qué base legal, con qué dependencia de terceros y con qué criterio de parada?

Si la respuesta es vaga, tu gobernanza no está madura. Aunque tengas comité, política y proveedor premium.

La buena noticia es que no hace falta inventar un marco paralelo. Las piezas ya existen. El AI Act aporta la lógica de clasificación, obligaciones y alfabetización. GDPR fija la disciplina sobre datos y rendición de cuentas. DORA obliga a tratar la IA como parte del riesgo TIC y de terceros. NIS2 recuerda que la cadena de suministro y las medidas de seguridad no son opcionales. Lo que falta en muchas organizaciones no es normativa. Es ensamblaje.

Empieza por el inventario de casos de uso. Obliga a clasificar cada despliegue de forma verificable. Define puertas de aprobación con veto real. Diseña trazabilidad proporcionada. Revisa contratos y permisos con más rigor del que el entusiasmo comercial considera educado. Y prueba la desconexión antes de necesitarla. Lo demás, por duro que suene, es seguir jugando a los pilotos cuando el regulador ya está pidiendo controles de producción.