La gobernanza de IA en banca no puede reducirse a una lista de modelos aprobados. El mismo proveedor puede sostener un asistente interno, un motor antifraude, una función de scoring o un agente conectado a sistemas críticos. Cada uso necesita una finalidad, datos, versión, integración y responsabilidad propias. Después se conectan las capas regulatorias: AI Act para el sistema y su uso; DORA para el riesgo ICT y terceros dentro de su ámbito; RGPD, normativa prudencial, conducta y seguridad cuando corresponda.
Ideas clave
- Clasifica por finalidad y efecto, no por marca de proveedor.
- No toda IA bancaria es de alto riesgo; determinados usos sobre solvencia y seguros sí requieren análisis específico.
- DORA exige gobernar el servicio ICT y la relación con terceros, no sustituye la clasificación AI Act.
- Un cambio de modelo o integración debe poder reabrir los controles afectados sin reconstruir todo el expediente.
1. Construye un mapa de casos de uso financieros
Separa, como mínimo, usos en crédito y solvencia, fraude, atención, asesoramiento, operaciones internas, desarrollo de software, ciberseguridad y agentes. La EBA señala que la adopción de IA se extiende por eficiencia, automatización, gestión de riesgos, asesoramiento, atención y fraude, al mismo tiempo que eleva preocupaciones operacionales, de ciberseguridad, datos y terceros.
2. Identifica qué usos activan análisis reforzado del AI Act
El anexo III del AI Act contempla, entre otros, sistemas destinados a evaluar la solvencia o establecer la puntuación crediticia de personas físicas y determinados sistemas de evaluación de riesgo y fijación de precios en seguros de vida y salud. Esto no permite etiquetar toda IA financiera como alto riesgo: hay que comprobar la finalidad, el sujeto y las condiciones concretas.
- Registra la decisión afectada y el grado de influencia del sistema.
- Distingue un apoyo documental de una puntuación o recomendación usada para decidir sobre una persona.
- Documenta revisión humana, límites y posibilidad de corregir o detener el uso.
3. Conecta el proveedor de IA con la gestión de terceros DORA
DORA exige a las entidades financieras dentro de su ámbito mantener un registro de los acuerdos contractuales para el uso de servicios ICT de terceros. La ficha de IA no tiene que duplicarlo: debería enlazar proveedor, servicio, contrato, función soportada, criticidad, integraciones y evidencias de evaluación, de forma que el cambio de una dependencia pueda verse desde ambos marcos.
| AI governance | DORA / riesgo ICT | Dato común |
|---|---|---|
| Sistema, finalidad y clasificación | Servicio ICT y función soportada | Proveedor / servicio |
| Modelo, versión y capacidades | Dependencia y cambios del tercero | Versión / cambio |
| Datos, usuarios y personas afectadas | Accesos, continuidad y seguridad | Integración / acceso |
| Supervisión y decisiones | Incidentes y respuesta | Responsable / incidente |
4. Trata los modelos avanzados como amplificadores de riesgo, no como excepción al control
El informe de riesgos de la EBA de junio de 2026 advierte del incremento de riesgo cibernético asociado a modelos altamente capaces y de la dependencia de proveedores ICT. La respuesta práctica es reforzar mínimo privilegio, segmentación, pruebas, monitorización, capacidad de revocación y preparación ante incidentes, especialmente cuando los sistemas pueden utilizar herramientas o ejecutar acciones.
5. Define la evidencia que debe conservar cada función
- Negocio: finalidad, necesidad, alcance y condiciones de uso.
- Riesgos/compliance: clasificación, controles y criterios de aceptación.
- DPO: datos personales, finalidad, base, derechos, EIPD cuando proceda y medidas.
- IT/seguridad: arquitectura, identidades, permisos, logs, pruebas e incidentes.
- Compras: contrato, proveedor, subservicios, salida y cambios relevantes.
Fuentes y referencias
Se priorizan fuentes oficiales para el marco normativo. La aplicación a un caso concreto puede exigir revisar normativa sectorial, guías, jurisprudencia y documentación técnica adicional.