Cumplimiento de la Ley de IA de la UE para la banca y los servicios financieros
Cumplimiento bancario de la Ley de IA de la UE: IA de solvencia (Anexo III, 5, letra b)), seguros de vida/salud (5, letra c)), exclusión por fraude, DORA, EIDF. Plazo: 2 de diciembre de 2027.
La mayor parte de la cartera de IA de un banco no es de alto riesgo con arreglo a la Ley de IA de la UE. Esa es la conclusión que los profesionales rara vez escuchan — e importa, porque al sector se le ha dicho repetidamente que su exposición a la IA es enorme. No lo es: la superficie de alto riesgo en la banca es estrecha, está bien definida y se limita a dos subpuntos del Anexo III. Alcanzar el cumplimiento significa identificar esos sistemas con precisión, no aplicar todo el régimen de alto riesgo a cada modelo del inventario.
El Reglamento (UE) 2024/1689 — la Ley de IA de la UE — se sitúa junto al Reglamento de Resiliencia Operativa Digital (DORA), MiFID II, Solvencia II, el artículo 22 del RGPD y las directrices de la ABE sobre la gestión del riesgo de modelo. Ninguno de esos marcos desaparece. Pero la Ley de IA añade su propia lógica de clasificación, y las entidades financieras que comprenden esa lógica pueden acotar su programa de cumplimiento con exactitud en lugar de sobredimensionarlo.
La estrecha superficie de alto riesgo: dos subpuntos del Anexo III
El Anexo III de la Ley de IA de la UE enumera los ocho ámbitos en los que se presume que los sistemas de IA son de alto riesgo. Los servicios financieros aparecen en el ámbito 5 — «acceso a servicios privados y públicos esenciales» — con dos subpuntos directamente pertinentes para los bancos.
Anexo III, punto 5, letra b): solvencia y calificación crediticia de personas físicas. Los sistemas de IA utilizados para evaluar si una persona física obtiene crédito, a qué precio y en qué condiciones son de alto riesgo. Esto abarca los modelos de calificación crediticia minorista, la IA de suscripción de préstamos, los algoritmos de admisibilidad a descubiertos y los sistemas de verificación de ingresos cuyo resultado influye materialmente en la decisión de crédito. El matiz «personas físicas» importa: la IA de riesgo de crédito B2B que evalúa contrapartes corporativas queda fuera del punto 5, letra b).
La exclusión explícita por detección de fraude se aplica aquí. El texto del Anexo III excluye de la definición de solvencia los sistemas de IA utilizados para la detección de fraude. Un modelo que detecta patrones de pago anómalos para marcar un posible fraude no es de alto riesgo por este motivo, aunque opere sobre datos de transacciones de personas físicas. El límite es la finalidad: evaluación de la solvencia frente a detección de fraude. Las entidades deben documentar esta distinción con cuidado para cada modelo de la zona gris.
Anexo III, punto 5, letra c): evaluación de riesgos y fijación de precios de seguros de vida y de salud. La IA utilizada para evaluar el riesgo individual y fijar las primas en los productos de seguro de vida, seguro de salud y enfermedades graves es de alto riesgo. Los bancos con operaciones de bancaseguros que ofrecen estos productos entran en el ámbito. La categoría no se extiende al seguro de automóvil ni al seguro de hogar — esos ramos quedan excluidos. Un banco regional cuya rama de seguros suscribe pólizas de automóvil y de hogar, pero no de vida ni de salud, no está expuesto con arreglo al punto 5, letra c).
Todo lo demás del inventario estándar de IA bancaria — la PBC y el seguimiento de transacciones, la negociación algorítmica, el roboasesoramiento, los chatbots de atención al cliente, los modelos internos de riesgo de mercado o de liquidez, el cribado de CSC — no es de alto riesgo sobre la base del Anexo III. Los chatbots quedan comprendidos en las obligaciones de transparencia de riesgo limitado del artículo 50: a los usuarios debe decírseles que están interactuando con un sistema de IA. Los modelos de PBC son una función de cumplimiento, no una aplicación de garantía del cumplimiento del Derecho en el sentido del artículo 6, apartado 2. La negociación algorítmica no es un caso de uso del Anexo III.
El filtro del artículo 6, apartado 3, ofrece una válvula de escape adicional. Un sistema que entra dentro de un ámbito del Anexo III no es, sin embargo, de alto riesgo si no plantea un riesgo significativo de perjuicio — por ejemplo, si desempeña una tarea procedimental limitada o mejora una actividad humana previamente realizada. Todo proveedor que reclame esta exención debe documentar la evaluación y registrarla (artículo 49).
Obligaciones del proveedor y del responsable del despliegue en la banca
Las grandes entidades financieras ocupan ambas posiciones dentro de la misma entidad — a veces dentro del mismo equipo.
Un banco que construye internamente su propio modelo de calificación crediticia, o que ajusta un modelo de un tercero con sus propios datos, o que modifica sustancialmente la tarjeta de puntuación de un proveedor, soporta las obligaciones del proveedor con arreglo a los artículos 9 a 17: un sistema de gestión de riesgos (artículo 9), gobernanza de datos (artículo 10), documentación técnica del Anexo IV (artículo 11), registro (artículo 12), transparencia hacia los responsables del despliegue (artículo 13), diseño de la supervisión humana (artículo 14) y requisitos de exactitud y robustez (artículo 15). Antes de que el sistema entre en servicio requiere una evaluación de la conformidad con arreglo al artículo 43 — para las categorías del Anexo III distintas de la biometría, esta es la vía de autoevaluación interna (Anexo VI). También debe registrarse en la base de datos de la UE con arreglo al artículo 49.
Un banco que licencia un sistema de calificación crediticia a un proveedor tercero es un responsable del despliegue con arreglo al artículo 26. Las obligaciones del responsable del despliegue son más ligeras: utilizar el sistema dentro de su finalidad prevista, aplicar los protocolos de supervisión descritos en la documentación del proveedor, conservar los registros durante al menos seis meses (artículo 26) y vigilar el rendimiento. Cuando el responsable del despliegue utiliza un modelo de solvencia (Anexo III, 5, letra b)) o un modelo de fijación de precios de seguros de vida y de salud (5, letra c)), el artículo 27 exige una evaluación de impacto relativa a los derechos fundamentales (EIDF) antes del despliegue.
El artículo 25, apartado 1, fija el umbral para la conversión de rol. Un responsable del despliegue que modifique sustancialmente un sistema de IA de alto riesgo — reentrenándolo con datos protegidos, desplazando materialmente sus umbrales de decisión o desplegándolo para una finalidad ajena al uso previsto original del proveedor — pasa a ser el proveedor de ese sistema. Una recalibración anual que actualice los pesos del modelo es muy probablemente suficiente para activar esto. Las entidades que recalibran de forma rutinaria las tarjetas de puntuación de terceros deben evaluar cada ciclo de recalibración frente a este umbral.
En la práctica, un gran banco puede ser el proveedor de quince sistemas de IA y el responsable del despliegue de treinta y cinco. El programa de cumplimiento debe abordar ambos regímenes, con una documentación estructurada de forma distinta para cada uno.
La obligación de EIDF para los responsables del despliegue de crédito y seguros
El artículo 27 no se aplica a todos los responsables del despliegue. Se aplica específicamente a los responsables del despliegue que son organismos públicos y a los responsables del despliegue privados que utilizan sistemas de IA de solvencia (Anexo III, 5, letra b)) o de seguros de vida y de salud (Anexo III, 5, letra c)). Para la mayoría de las entidades financieras, los sistemas de crédito y de seguros son precisamente donde recae la obligación de EIDF.
La EIDF abarca la finalidad y el uso previsto del sistema, a quién afecta, qué derechos fundamentales están en riesgo (no discriminación, acceso a los servicios financieros, protección de datos), qué medidas de mitigación están vigentes, cómo se diseña la supervisión humana y qué mecanismos de reparación existen para las personas afectadas por el resultado de la IA.
Para los sistemas de crédito, la sección de no discriminación requiere el mayor cuidado. Los indicadores indirectos incorporados en los modelos de crédito — el código postal, la categoría de ocupación, el comportamiento de compra — pueden codificar disparidades demográficas sin tratar directamente características protegidas. La EIDF debe abordar cómo la entidad prueba y mitiga estos efectos. El artículo 27, apartado 4, permite que una EIDF se apoye en una evaluación de impacto relativa a la protección de datos (EIPD) existente con arreglo al artículo 35 del RGPD cuando las dos evaluaciones se solapen — merece la pena hacerlo para reducir la duplicación.
Los bancos de titularidad estatal, los bancos de desarrollo (KfW, BPI France), las cajas de ahorros con mandatos de servicio universal y las entidades financieras que operan bajo regímenes de interés público están claramente dentro del ámbito de la EIDF. Los bancos plenamente comerciales que operan modelos de crédito en condiciones puramente de mercado deberían evaluar igualmente su posición respecto de la EIDF — el texto del artículo 27 no limita el ámbito a los bancos del sector público.
El artículo 22 del RGPD y el artículo 14 de la Ley de IA: dos requisitos de supervisión humana
El artículo 22 del RGPD prohíbe las decisiones individuales automatizadas con efectos jurídicos o de modo similar significativos, salvo que se aplique una base jurídica específica. Para las decisiones de crédito, la base jurídica suele ser el artículo 22, apartado 2, letra a) — la necesidad para un contrato. Esa base no elimina la obligación del artículo 22, apartado 3, de aplicar «medidas adecuadas», incluido el derecho a obtener la intervención humana, expresar un punto de vista e impugnar la decisión.
El requisito de supervisión humana del artículo 14 de la Ley de IA cubre el mismo terreno funcional desde un ángulo jurídico distinto. El artículo 14 exige que los sistemas de IA de alto riesgo se diseñen y desplieguen de modo que las personas físicas puedan supervisarlos eficazmente, comprender sus resultados e intervenir o anular.
El requisito práctico es el mismo para ambos: un agente de crédito con verdadera facultad de anulación, acceso a la información necesaria para formarse una opinión independiente y un proceso documentado para consignar y actuar sobre esa anulación. Los supervisores de varios Estados miembros han indicado que un humano en el bucle meramente nominal — una persona que revisa el resultado de la IA pero no tiene capacidad práctica para cuestionarlo — no satisface ninguna de las dos obligaciones. La documentación debe abordar tanto el artículo 14 como el artículo 22, apartado 3, en un único procedimiento unificado de revisión humana.
Dónde se cruza DORA
DORA (Reglamento 2022/2554, aplicable desde enero de 2025) crea obligaciones paralelas de riesgo relacionado con las TIC que se aplican directamente a los sistemas de IA. El marco de gestión del riesgo relacionado con las TIC de DORA (artículos 5 a 10) exige a las entidades financieras que identifiquen, clasifiquen y gestionen los riesgos relacionados con las TIC; los sistemas de IA son sistemas de TIC.
El solapamiento más significativo se da en el riesgo de terceros. Los artículos 28 a 44 de DORA exigen la diligencia debida sobre los proveedores terceros de TIC, con disposiciones contractuales sobre derechos de auditoría, estrategias de salida y notificación de incidentes. Cuando el tercero es un proveedor de un sistema de IA, la diligencia debida debe satisfacer tanto los requisitos de riesgo de terceros de DORA como las obligaciones del responsable del despliegue del artículo 26 de la Ley de IA — incluida la verificación de que el proveedor ha elaborado la documentación técnica del artículo 11. Las entidades que construyen procesos unificados de evaluación de proveedores que cubren ambos regímenes evitan el coste y el riesgo de incoherencia de mantener vías de documentación paralelas.
Los requisitos de pruebas de penetración basadas en amenazas (TLPT) de DORA para los sistemas de TIC significativos y los requisitos de robustez y ciberseguridad del artículo 15 de la Ley de IA se solapan en su alcance para la IA de alto riesgo. Las pruebas producidas para DORA a menudo pueden estructurarse para servir a ambos marcos.
La gestión del riesgo de modelo de la ABE y las expectativas supervisoras del BCE
Las directrices revisadas de gobernanza interna de la ABE (EBA/GL/2021/05) exigen un inventario de modelos, una validación independiente para los modelos materiales, un seguimiento del rendimiento con umbrales definidos y procedimientos de escalado en caso de degradación del modelo. Estos requisitos se asignan directamente al sistema de gestión de riesgos del artículo 9 y a los requisitos de exactitud del artículo 15 de la Ley de IA — pero la profundidad de validación de la ABE suele ser más prescriptiva desde el punto de vista operativo que el texto de la Ley de IA por sí solo.
Las entidades que ya mantienen un marco de gestión del riesgo de modelo conforme con la ABE disponen de la mayor parte de la infraestructura técnica que la Ley de IA exige. La laguna suele estar en los ámbitos específicos de la Ley de IA: el formato de documentación del artículo 11 / Anexo IV, la realización de la EIDF, el registro en la base de datos de la UE (artículo 49) y los registros de vigilancia poscomercialización con arreglo al artículo 72.
El BCE espera una comprensión a nivel de consejo de administración de los sistemas de IA relevantes para el perfil de riesgo de una entidad. Para las entidades bajo supervisión directa del BCE, esto significa que la gobernanza de la IA debe ser un tema del comité de riesgos del consejo, no una función puramente técnica. Los requisitos de supervisión humana del artículo 14 y la expectativa de supervisión sustantiva del BCE están alineados: ambos rechazan el cumplimiento nominal.
Cómo ayuda Confir
Confir clasifica cada sistema de IA de su inventario con arreglo a los artículos 5 y 6 utilizando la lógica del Anexo III, mediante una admisión en lenguaje sencillo. Para un modelo de calificación crediticia, la lista de comprobación de clasificación recorre si el sistema evalúa la solvencia de personas físicas, si se aplica la exclusión por detección de fraude, si la exención por tarea limitada del artículo 6, apartado 3, es sostenible y qué rol ocupa la entidad. El resultado es un nivel de riesgo y una derivación de rol documentados, no una opinión consultiva.
Para los sistemas confirmados como de alto riesgo, Confir ejecuta una evaluación estructurada a través de cuatro áreas de cumplimiento — gestión de riesgos (artículo 9), gobernanza de datos y robustez técnica (artículos 10, 11, 15), transparencia y supervisión humana (artículos 13, 14, 27) y gobernanza y vigilancia poscomercialización (artículos 9, 72, 73) — y genera el paquete de documentación técnica del Anexo IV y la EIDF del artículo 27. El motor es determinista y basado en reglas: la misma admisión, la misma conclusión, con la regla que se activó visible y defendible en auditoría.
Plazos de cumplimiento
Las obligaciones de alto riesgo del Anexo III se aplican desde el 2 de diciembre de 2027 para los sistemas de IA autónomos — incluida la IA de crédito y de seguros — en virtud del Ómnibus Digital (acuerdo político alcanzado el 7 de mayo de 2026). La fecha original de agosto de 2026 se aplicaba al despliegue general; las obligaciones de alto riesgo del Anexo III siempre estuvieron previstas para más adelante, y el Ómnibus las prorrogó aún más. Las obligaciones de transparencia de riesgo limitado del artículo 50 (chatbots, información sobre contenidos sintéticos) se aplican desde el 2 de agosto de 2026.
El techo de las multas por incumplimiento para la mayoría de las obligaciones es de 15 000 000 EUR o el 3 % del volumen de negocios anual mundial total, si esta última cifra es mayor (artículo 99, apartado 4). Ese techo se aplica por igual a los fallos en las obligaciones del proveedor y del responsable del despliegue. La fecha del 2 de diciembre de 2027 es un respiro, no un indulto: solo la documentación del Anexo IV tarda meses en ensamblarse, y la realización de la EIDF requiere datos que pueden no estar fácilmente accesibles.
Preguntas frecuentes
¿Se aplica la Ley de IA de la UE a todos los sistemas de IA que utiliza un banco?
No. La clasificación determina las obligaciones. La mayor parte de la IA bancaria — el seguimiento de transacciones para la PBC, la negociación algorítmica, el roboasesoramiento, los chatbots de atención al cliente, los modelos internos de riesgo — es de riesgo mínimo o limitado con arreglo a la Ley. Las categorías de alto riesgo en la banca son estrechas: la IA que evalúa la solvencia de personas físicas (Anexo III, punto 5, letra b), con la exclusión por detección de fraude) y la IA utilizada para la evaluación de riesgos y la fijación de precios de seguros de vida o de salud (5, letra c)). Todo lo demás queda fuera del régimen de alto riesgo sobre esa base, aunque pueda tener obligaciones de transparencia de riesgo limitado con arreglo al artículo 50.
¿Es el seguimiento de transacciones para la PBC de alto riesgo con arreglo a la Ley de IA de la UE?
Generalmente no. El seguimiento de transacciones para la PBC es una función de cumplimiento: genera alertas que los analistas revisan, no decisiones de garantía del cumplimiento del Derecho. El Anexo III, punto 6 (IA para la garantía del cumplimiento del Derecho), se aplica cuando un sistema se utiliza para realizar evaluaciones de riesgo con fines de garantía del cumplimiento del Derecho — no a los procesos internos de generación de comunicaciones de operaciones sospechosas (SAR). La exclusión por detección de fraude del Anexo III, punto 5, letra b), también deja claro que los modelos de fraude no son sistemas de solvencia de alto riesgo. Las entidades deben documentar la finalidad de su sistema de PBC para respaldar esta posición.
¿Se aplica la exclusión por detección de fraude a todos los modelos de fraude?
La exclusión del Anexo III, punto 5, letra b), excluye de la definición de solvencia los sistemas de IA utilizados para la detección de fraude. Se aplica cuando la detección de fraude es la finalidad genuina — detección de anomalías, análisis de patrones de transacciones, prevención de la apropiación de cuentas. No se aplica a un modelo que evalúa la solvencia y produce además una puntuación de fraude como resultado secundario. El factor determinante es la finalidad prevista principal del sistema, que debe documentarse.
Si un banco recalibra anualmente la tarjeta de puntuación crediticia de un tercero, ¿es el proveedor con arreglo a la Ley de IA?
Probablemente sí. El artículo 25, apartado 1, convierte a un responsable del despliegue en proveedor cuando modifica sustancialmente un sistema de IA de alto riesgo. Una recalibración anual que actualiza los pesos del modelo o desplaza materialmente los umbrales de decisión es probablemente suficiente para activar esto. La consecuencia práctica es que el banco hereda la pila de obligaciones del proveedor — artículos 9 a 15, documentación del Anexo IV, evaluación de la conformidad, registro del artículo 49 — en lugar de las obligaciones más ligeras del responsable del despliegue del artículo 26. Cada ciclo de recalibración debe evaluarse frente a la definición de modificación sustancial del artículo 3, punto 23.
¿Cuándo se aplica la EIDF a un banco que despliega un modelo de crédito de un proveedor?
El artículo 27 exige una evaluación de impacto relativa a los derechos fundamentales antes de desplegar un sistema de IA de alto riesgo con fines de solvencia (Anexo III, 5, letra b)) o de seguros de vida y de salud (5, letra c)). La obligación se aplica al responsable del despliegue — es decir, el banco que utiliza el modelo del proveedor. La EIDF debe abordar el riesgo de no discriminación, los impactos sobre el acceso a los servicios financieros, el diseño de la supervisión y la reparación individual. Puede apoyarse en una EIPD existente con arreglo al artículo 35 del RGPD cuando las dos se solapen (artículo 27, apartado 4). La EIDF se completa antes del despliegue, no como una actividad poscomercialización.
¿Cuál es la sanción por incumplimiento en la IA bancaria?
El techo estándar con arreglo al artículo 99, apartado 4, es de 15 000 000 EUR o el 3 % del volumen de negocios anual mundial total, si esta última cifra es mayor. Esto se aplica a los fallos en las obligaciones del proveedor (artículos 9 a 17), las obligaciones del responsable del despliegue (artículo 26) y el requisito de EIDF (artículo 27). Para las entidades más pequeñas, el artículo 99, apartado 6, limita las multas al menor de los dos importes, el porcentaje o la cantidad fija — una protección de proporcionalidad. Estas cifras se aplican desde el 2 de agosto de 2025 (cuando entraron en vigor las disposiciones sancionadoras), aunque las propias obligaciones de alto riesgo se aplican desde el 2 de diciembre de 2027.
¿Cómo se relaciona la Ley de IA con el artículo 22 del RGPD para las decisiones de crédito?
Los dos instrumentos operan en paralelo y ambos deben satisfacerse. El artículo 22 del RGPD restringe las decisiones individuales automatizadas con efectos jurídicos o significativos, exigiendo una base jurídica y — cuando se aplica el artículo 22, apartado 2, letra a) — medidas adecuadas, incluidos los derechos de intervención humana. El requisito de supervisión humana del artículo 14 de la Ley de IA cubre el mismo terreno funcional: una persona física debe poder comprender, supervisar y anular el resultado de la IA. En la práctica, el banco debe documentar un procedimiento unificado de revisión humana que satisfaga simultáneamente el artículo 14 y el artículo 22, apartado 3, especificando la facultad de anulación, el acceso a la información, el registro de las anulaciones y el derecho de la persona a impugnar.
Guías relacionadas
- Cumplimiento de DORA para los sistemas de IA fintech
- IA de seguros de alto riesgo del Anexo III
- requisitos de resiliencia operativa de la IA en la sanidad
- obligaciones de la IA en el sector público del Anexo III
- reglamento de máquinas e IA de alto riesgo
- alineación de DORA y la Ley de IA en la tecnología jurídica
Gestiona el cumplimiento de la Ley de IA de la UE en un solo lugar
Confir automatiza la clasificación de riesgo, la documentación técnica y los registros de auditoría para cualquier empresa. Sin consultores. Sin proyectos de seis meses. Prueba gratuita de 7 días.
Empieza la prueba gratuita →