Prácticas de IA en banca: la calificación crediticia es de alto riesgo, la detección de fraude no
Prácticas de IA en banca: la calificación crediticia (anexo III 5(b)) es de alto riesgo; el fraude/PBC no. Riesgo de modelos BCE/EBA, DORA y plazo 2027.
El conjunto de IA de un banco es amplio —decisión crediticia, monitorización de transacciones para PBC, chatbots de clientes, previsión de la red de oficinas, procesamiento de documentos— y el Reglamento de IA de la UE no trata igual a dos cualesquiera de ellos. El error que cometen la mayoría de los bancos en su primera pasada de prácticas es meter todo en una única «política de IA» y suponer que las reglas más estrictas se aplican a todo. No es así.
Las «prácticas de IA» son, en sí, una práctica de gestión, no una cláusula del Reglamento (UE) 2024/1689. El Reglamento impone deberes —cribar el uso prohibido, clasificar por uso, gestionar el riesgo en los sistemas de alto riesgo, divulgar cuando aplica el artículo 50— y deja la organización a tu criterio. La labor de un modelo de prácticas de nivel bancario es enrutar cada uno de esos deberes a un propietario nombrado, y hacerlo sin atornillar una estructura paralela sobre la maquinaria de gestión de riesgo de modelos que un banco regulado ya opera. Esta guía mapea el Reglamento de IA sobre esa maquinaria existente.
Qué es de alto riesgo en un banco y qué no
La única clasificación que más importa para un banco está en el anexo III, punto 5(b): la IA usada para evaluar la solvencia de personas físicas o establecer su calificación crediticia. Decisiones de préstamo al consumo, aprobaciones de tarjetas de crédito, scoring de hipotecas minoristas, decisiones de descubierto y de límites: si un sistema de IA configura materialmente si una persona obtiene crédito y en qué condiciones, es de alto riesgo. No necesita tomar la decisión a solas; una puntuación en la que se apoya un analista de crédito sigue estando en el ámbito.
Dos exclusiones cambian el panorama de forma drástica:
- La detección de fraude está expresamente excluida del anexo III, punto 5(b). Un modelo de monitorización de transacciones, de anomalías de pago o de toma de control de cuentas no es de alto riesgo por esta vía, por sofisticado que sea. El legislador trazó la línea de forma deliberada: los modelos de fraude protegen a los clientes y al sistema; no condicionan el acceso al crédito.
- El cribado de PBC y de sanciones tampoco es de alto riesgo conforme al anexo III. Se sitúa bajo el marco de PBC de la UE y, cuando toma decisiones exclusivamente automatizadas sobre una persona, bajo el artículo 22 del RGPD, pero no bajo el bloque de alto riesgo del Reglamento de IA.
Los modelos de riesgo y precio de los seguros de vida y de salud son de alto riesgo conforme al anexo III, punto 5(c) —relevante para los brazos de bancaseguros, menos para un banco puro de depósito y préstamo—.
| Caso de uso de IA bancaria | Clasificación | Por qué |
|---|---|---|
| Scoring de crédito minorista / decisión hipotecaria | Alto riesgo — anexo III 5(b) | Determina el acceso al crédito de personas físicas |
| Detección de fraude / anomalías de pago | No es de alto riesgo | Exclusión de fraude en 5(b) |
| Monitorización de transacciones PBC / sanciones | No es de alto riesgo (PBC + art. 22 RGPD) | No es un uso del anexo III |
| Chatbot de atención al cliente | Limitado — transparencia del artículo 50 | Hay que decir al usuario que trata con una IA |
| Trading algorítmico / previsión de tesorería | Mínimo | No es un uso del anexo III; aplica MiFID II por separado |
| Clasificación interna de documentos / OCR | Mínimo | Sin condicionar derechos fundamentales |
Acertar este mapa es el primer entregable del modelo de prácticas. Etiquetar mal un modelo de fraude como de alto riesgo no es prudencia inofensiva: le dice a un examinador que tu método de clasificación es poco fiable y derrocha el presupuesto que el modelo de crédito sí necesita.
El chatbot de clientes: artículo 50, no anexo III
Los bancos minoristas operan chatbots y asistentes de voz en servicio y onboarding. Son de riesgo limitado: el artículo 50 exige que se diga a la persona, con claridad, que interactúa con un sistema de IA, salvo que sea obvio. Es una obligación de transparencia —un banner, una frase de apertura, un aviso de voz—, no una evaluación de la conformidad. El artículo 50 se aplica desde el 2 de agosto de 2026: el Ómnibus Digital no lo aplazó. El deber de diseño recae en el proveedor del chatbot; el banco que licencia la herramienta debe comprobar que el aviso está activo en su implantación. Un incumplimiento entra en el tramo de sanción de 15 M€/3% (artículo 99(4)), el mismo tramo que la mayoría de los incumplimientos de alto riesgo, así que la comunicación es barata de hacer y cara de omitir.
Proveedor, responsable del despliegue, o ambos
La mayoría de los bancos son responsables del despliegue conforme al artículo 26 de los modelos de crédito que licencian de un proveedor: incrustan la puntuación en la originación y usan el resultado. Un banco que construye su propio modelo de crédito internamente es también proveedor conforme al artículo 16 y carga con todo el bloque del proveedor. Y el artículo 25 significa que la línea puede moverse: un banco que pone su propia marca en un modelo de proveedor, lo modifica sustancialmente o lo reentrena sobre su cartera propia probablemente se ha convertido en proveedor de ese sistema.
La regla práctica de prácticas: el registro de casos de uso anota, para cada sistema, tanto su clasificación como su papel, porque el papel decide la lista de obligaciones.
Mapear los deberes del Reglamento de IA sobre la gestión de riesgo de modelos
Un banco regulado ya opera gestión de riesgo de modelos —la disciplina que el ejercicio TRIM del BCE, la Guía del BCE sobre modelos internos y las directrices de la EBA sobre gobernanza interna y sobre concesión de préstamos (EBA/GL/2020/06) han moldeado durante años—. El Reglamento de IA no pide a un banco que construya un segundo aparato paralelo. Le pide que extienda el que ya tiene para cubrir los requisitos concretos del Reglamento de IA, y que lo demuestre.
Mapeo de los deberes de proveedor/responsable del despliegue de alto riesgo sobre las funciones existentes:
| Deber del Reglamento de IA | Artículo | Hogar existente en un banco |
|---|---|---|
| Sistema de gestión de riesgos | Artículo 9 | Gestión de riesgo de modelos / validación de modelos |
| Gobernanza de datos | Artículo 10 | Gestión de datos + controles de calidad de datos BCBS 239 |
| Documentación técnica | Artículo 11 / anexo IV | Estándar de documentación de modelos |
| Supervisión humana | Artículo 14 | Anulación del analista de crédito; política de «revisión humana» |
| Precisión, solidez, ciberseguridad | Artículo 15 | Monitorización del rendimiento del modelo + seguridad TIC |
| Evaluación de la conformidad | Artículo 43 | Nuevo — vía de control interno (anexo VI) para modelos de crédito |
| Registro en la base de datos de la UE | Artículo 49 | Nuevo — sin análogo bancario |
| Vigilancia poscomercialización | Artículo 72 | Monitorización continua del modelo / back-testing |
| Notificación de incidentes graves | Artículo 73 | Extiende la gestión de incidentes a una nueva autoridad |
Las brechas genuinamente nuevas —y que por tanto necesitan un propietario nombrado desde el primer día— son la evaluación de la conformidad del artículo 43, el registro en la base de datos de la UE del artículo 49, la EIDF del artículo 27 para los responsables del despliegue de calificación crediticia y la notificación del artículo 73 a la autoridad de vigilancia del mercado. Todo lo demás es una extensión de un control existente, no una construcción desde cero. La evidencia de riesgo de modelos del BCE/EBA es reutilizable; no es, por sí sola, conformidad con el Reglamento de IA.
La interacción con DORA
DORA (el Reglamento de Resiliencia Operativa Digital, aplicable desde el 17 de enero de 2025) regula el riesgo TIC y la supervisión de terceros para las entidades financieras. Un modelo de crédito de proveedor es a la vez un tercero TIC bajo DORA (sujeto al registro de información y a los requisitos contractuales de los artículos 28 a 30 de DORA) y un sistema de alto riesgo del Reglamento de IA que el banco despliega. La documentación es distinta, pero el proceso de diligencia debida del proveedor puede ejecutarse una vez y alimentar ambos: una única admisión que capte los campos del registro de terceros de DORA y la evidencia del proveedor del Reglamento de IA (las instrucciones del artículo 13, la declaración de conformidad del artículo 47) es el diseño eficiente. Los modelos de prácticas que mantienen el onboarding de proveedores de DORA y del Reglamento de IA en silos separados duplican trabajo y se pierden los sistemas que disparan ambos.
Ejemplo práctico: el modelo de prácticas de un banco regional
Donaubank AG —~750 empleados, ~210 M€ de facturación, banca minorista y a pymes en Alemania y Austria— opera cuatro sistemas de IA materiales: un modelo interno de scoring de crédito al consumo, un motor de detección de fraude licenciado, un chatbot de atención al cliente y una herramienta interna de clasificación de documentos.
Su modelo de prácticas, en concentrador y radios:
- Directivo responsable: el CRO, que ya asume el riesgo de modelos, incorpora el riesgo de IA al mapa de riesgos y aprueba las decisiones sí/no de alto riesgo.
- Responsable de prácticas de IA: una función de segunda línea que asume el registro de casos de uso y el método de clasificación de los artículos 5/6, junto a la validación de modelos.
- Resultado de la clasificación: el modelo de crédito es de alto riesgo (anexo III 5(b)); como el banco lo construyó y lo usa, Donaubank es proveedor y responsable del despliegue. El motor de fraude y la herramienta de documentos son mínimos; el chatbot es limitado del artículo 50.
- El trabajo de alto riesgo, para el 2 de diciembre de 2027 (fecha fijada por el Ómnibus Digital, Reglamento (UE) 2026/1744): extender la documentación de modelos existente al paquete del artículo 11 / anexo IV, formalizar el sistema de gestión de riesgos del artículo 9 contra el marco de riesgo de modelos, completar la evaluación de la conformidad de control interno del artículo 43, firmar la declaración del artículo 47 y registrar conforme al artículo 49, ejecutar la EIDF del artículo 27 (obligatoria para los responsables del despliegue de solvencia) y confirmar que la anulación del analista de crédito del artículo 14 está documentada.
- Los deberes vivos ya: la alfabetización en IA del artículo 4 (medidas para apoyar la alfabetización del personal, exigibles desde el 2 de febrero de 2025) y el cribado de uso prohibido del artículo 5 en la admisión, ambos asumidos hoy, no en 2027. La transparencia del artículo 50 del chatbot es obligatoria desde el 2 de agosto de 2026.
Donaubank no parte de cero. Mapea el Reglamento sobre la maquinaria de riesgo de modelos que ya opera y rellena cuatro brechas genuinamente nuevas: evaluación de la conformidad, registro, EIDF y notificación de incidentes.
El plazo tras el Ómnibus Digital
Para los sistemas autónomos de alto riesgo, como el modelo de crédito de un banco, la fecha de aplicación original era el 2 de agosto de 2026. El Ómnibus Digital —propuesto por la Comisión en noviembre de 2025 y adoptado como Reglamento (UE) 2026/1744, publicado en el DOUE el 24 de julio de 2026 y en vigor desde el 27 de julio de 2026— la trasladó al 2 de diciembre de 2027 (y al 2 de agosto de 2028 para la IA de alto riesgo integrada en productos del anexo I).
Ya no hay dos fechas que conciliar: el texto modificado del Reglamento fija el 2 de diciembre de 2027 como fecha única para el modelo de crédito. Un banco prudente planifica sobre ella sin tratarla como un respiro. Ensamblar el paquete del anexo IV y generar un rastro de evidencia del artículo 9 a lo largo del ciclo de vida de un modelo lleva entre 12 y 18 meses, incluso desde una base madura de riesgo de modelos.
Sanciones
Para un banco, los tramos relevantes conforme al artículo 99:
- Prácticas prohibidas del artículo 5 — 35 M€ o el 7% de la facturación anual mundial (art. 99(3)).
- Obligaciones de alto riesgo (artículos 9, 10, 11, 13, 14, 15, 43, 49) y transparencia del artículo 50 — 15 M€ o el 3% (art. 99(4)).
- Facilitar información incorrecta o engañosa a una autoridad u organismo notificado — 7,5 M€ o el 1% (art. 99(5)).
El tercer tramo es el 1%, no el 1,5%. Para los grupos que cumplen la definición de pyme/empresa emergente, el artículo 99(6) limita la multa a la menor de la cifra porcentual o la fija; desde el Ómnibus Digital, el nuevo artículo 99(6 bis) aplica ese mismo límite a las pequeñas empresas de mediana capitalización para las multas de los artículos 99(4) y 99(5) —relevante para entidades más pequeñas, menos para un gran grupo bancario cuya facturación empequeñece las sumas fijas—.
Cómo ayuda Confir
Confir recorre la admisión de un banco por los puntos del anexo III en listas de comprobación en lenguaje llano, confirma el modelo de crédito como anexo III 5(b) dejando correctamente los motores de fraude y PBC fuera del alto riesgo, deriva el papel del artículo 16/26 y enruta la lista de obligaciones a un propietario. La clasificación es determinista y basada en reglas —la misma entrada siempre produce el mismo hallazgo, y la regla que se activó queda registrada—, que es lo que quieren tanto una función de riesgo de modelos como un examinador. Genera el paquete del artículo 11 / anexo IV, la declaración del artículo 47 y la EIDF del artículo 27 como salidas estructuradas.
Guías relacionadas
- Modelo operativo de prácticas de IA
- El Reglamento de IA para fintech
- Sistema de gestión de riesgos del artículo 9
- IA de calificación crediticia del anexo III
- La EIDF del artículo 27 y la intersección con el RGPD
- Gestión de proveedores para la IA
- Plazos y calendario del Reglamento de IA
Gestiona el cumplimiento de la Ley de IA en un solo lugar
Confir automatiza la clasificación de riesgos, la documentación técnica y los registros de auditoría para tu empresa. Sin consultores. Sin proyectos de seis meses. Prueba gratuita de 14 días.
Prueba gratis 14 días →