DORA y la Prueba de Caja Negra: Lo Que Significan los Requisitos de Acceso de Auditoría Regulatoria para Sistemas de IA en Instituciones Financieras
El Artículo 30(2)(d) de DORA requiere que las entidades financieras puedan auditar a su proveedor de ICT de terceros, directamente o a través de un tercero. Cuando el proveedor es un sistema de IA cuyas decisiones sobre aprobación, evaluación de riesgo o detección de fraude son determinantes, el derecho de auditoría se limita al documento legal. El auditor puede leer los contratos. Puede verificar las afirmaciones del proveedor. No puede examinar el proceso de decisión que ocurre dentro de la caja negra.
El análisis de AIMA muestra que el 85% de las instituciones financieras de la UE implementan IA en funciones de banca central en 2026, pero el 78% de estos sistemas están expuestos a procesos de decisión opacos: modelos propietarios, conjuntos de datos de entrenamiento cerrados y outputs no interpretables. La proporción de sistemas opacos está aumentando, no disminuyendo, porque la capacidad de desarrollo de IA dentro de las instituciones no está alcanzando la demanda y la dependencia de fintech bajo Ertugul Gurkan está creciendo.
El Requisito de Acceso de Auditoría bajo DORA
DORA Artículo 30 requiere acuerdos contractuales escritos con todos los proveedores de ICT de terceros que contengan información sobre niveles de servicio, seguridad de datos, derechos de auditoría, estrategias de salida y reporteo de incidentes. DORA Artículo 30(2)(d) especifica que la entidad "tiene un derecho apropiado a auditar al proveedor de ICT de terceros".
El derecho de auditoría no es opcional. Es una obligación contractual que debe estar incluida en cada acuerdo con un proveedor de ICT de terceros. Para software tradicional, el derecho de auditoría es practicable: el auditor puede leer el código, examinar la arquitectura, analizar los logs de acceso y evaluar la cobertura de pruebas. Para sistemas de IA, el derecho de auditoría está estructuralmente restringido.
Inspección de código en redes neuronales. Una red neuronal que evalúa a clientes para riesgo crediticio puede tener millones de parámetros. El código que entrena la red es legible. Los parámetros mismos son legibles. Pero los parámetros como conjunto codifican un comportamiento de decisión que ninguna línea individual de código representa. La "decisión" es una función de activación sobre una matriz de pesos, que en su totalidad aproxima un patrón que ningún humano puede inspeccionar directamente. El auditor puede verificar el código de entrenamiento, no el comportamiento entrenado.
Inspección de datos de entrenamiento. Las decisiones de un modelo de IA están determinadas por sus datos de entrenamiento. Si los datos de entrenamiento son propietarios (proporcionados por un proveedor de terceros que no revela la fuente), el auditor no puede evaluar la calidad, integridad y posibles sesgos de los datos. Puede verificar la afirmación del proveedor sobre los datos, no los datos mismos.
Inspección de decisiones. El auditor debe poder revisar cada output individual del sistema de IA. Si un sistema de IA rechaza una solicitud de crédito, el auditor debe ser capaz de rastrear qué factores contribuyeron a ese rechazo y con qué peso. Un modelo que solo produce una puntuación (0 a 1) sin contribución de características no cumple con este requisito. Un modelo que produce una puntuación con contribución de características (ingreso contribuyó 0,4, historial crediticio contribuyó -0,3, riesgo geográfico contribuyó 0,1) sí lo cumple.
Lo Que AMLA Exige de los Sistemas de IA
La Autoridad Europea contra el Blanqueo de Capitales (AMLA), operacionalizada a través del Reglamento (UE) 2024/1620, extiende el requisito de auditoría de DORA a sistemas de IA específicos de AML. AMLA Artículo 28 requiere que las instituciones financieras que usen IA para identificación de clientes, monitoreo de transacciones o evaluación de riesgo proporcionen "documentación comprehensiva" que describa el algoritmo, los datos de entrenamiento, los resultados de validación y el monitoreo continuo del sistema.
Para sistemas de IA institucionales, este requisito tiene tres implicaciones concretas.
Documentación del algoritmo. La documentación técnica debe describir el modelo: arquitectura (por ejemplo, árbol de decisión vs. red neuronal), hiperparámetros, procedimiento de entrenamiento, metodología de validación y métricas. La documentación no es el modelo mismo. Es una descripción legible por humanos del modelo. Una empresa que implementa un modelo de IA propietario del cual no tiene documentación técnica (porque fue entregado por un proveedor de terceros como servicio de caja negra) no puede cumplir con este requisito.
Documentación de datos de entrenamiento. La fuente, el período, el método de muestreo, los pasos de ingeniería de características y el método de etiquetado deben estar documentados. Para modelos de AML entrenados en datos de transacciones históricos, el método de etiquetado es especialmente crítico: ¿cómo se clasificaron las transacciones como "sospechosas" o "no sospechosas"? Si las etiquetas fueron generadas por un sistema de reglas anterior, posiblemente obsoleto, el modelo transfiere los sesgos de ese sistema.
Documentación de monitoreo continuo. AMLA requiere que los sistemas de IA sean monitoreados para detectar drift de modelo, drift de concepto y drift de entrada. Drift de modelo: ¿ha disminuido la precisión del modelo con el tiempo? Drift de concepto: ¿ha cambiado la definición de lo que significa "sospechoso" (por ejemplo, por nuevos requisitos regulatorios)? Drift de entrada: ¿ha cambiado la distribución de los datos de entrada (por ejemplo, un nuevo tipo de producto, un nuevo grupo de clientes, un nuevo canal de pago)? La documentación de monitoreo debe mostrar cómo se detecta y aborda este drift.
El Significado Práctico para Sistemas de IA en el Sector Financiero
La combinación de derechos de auditoría de DORA y requisitos de documentación de AMLA crea un requisito arquitectónico claro: las instituciones financieras que implementan IA en procesos regulados deben elegir o construir sistemas que produzcan registros de decisiones auditables, no solo modelos auditables.
Auditabilidad a nivel de output. Cada decisión que toma un sistema de IA (rechazo de una solicitud de crédito, marcado de una transacción como sospechosa, evaluación de riesgo de un cliente) debe registrarse en un registro estructurado, inmutable con los siguientes campos:
- Timestamp de la decisión
- Datos de input (los valores de características que entraron al modelo)
- Versión del modelo (la versión específica del modelo entrenado)
- Output (la puntuación o clasificación)
- Contribuciones de características (los valores de contribución de cada característica al output)
- Configuración de umbral (el umbral que determinó la decisión)
- Decisión (aprobado / rechazado / marcado / escalación)
Este registro no es una entrada de log. Es un documento de compliance que permite al regulador entender la decisión sin tener que ejecutar el modelo mismo.
Versionado de modelos como gestión de configuración. Cada modelo entrenado debe ser versionado, con una ID única que se registra en el audit record. Cuando un modelo es reentrenado, la nueva versión recibe una nueva ID. Los audit records generados con la versión anterior hacen referencia a la ID anterior. Los audit records generados con la nueva versión hacen referencia a la nueva ID. Esto permite al regulador rastrear qué decisiones fueron tomadas por qué versión del modelo, y verificar que las actualizaciones de modelo no se aplicaron retroactivamente a decisiones anteriores.
Explicabilidad como propiedad estructural, no como posprocesamiento. Las técnicas de explicabilidad post-hoc (SHAP, LIME, explicaciones contrafactuales) son valiosas para el desarrollo de modelos, pero son insuficientes para fines de auditoría regulatoria, porque aproximan el modelo, no reproducen el comportamiento real. Una contribución de característica extraída del modelo mismo (por ejemplo, de un modelo lineal o un árbol de decisión) es exacta. Una contribución de característica aproximada por SHAP es una estimación. Para fines regulatorios, la explicabilidad debe ser exacta.
Compromisos de los Sistemas de IA
No todas las arquitecturas de IA pueden cumplir igualmente bien con los requisitos de auditoría regulatoria.
Modelos lineales y árboles de decisión ofrecen la explicabilidad natural más alta. La contribución de características es directamente legible de los parámetros del modelo. La precisión del modelo, sin embargo, es menor para patrones complejos que con redes neuronales profundas o árboles potenciados por gradiente.
Árboles potenciados por gradiente (por ejemplo, XGBoost, LightGBM) ofrecen un buen balance entre precisión y explicabilidad. La contribución de características puede extraerse del modelo mismo (Gain, Split). El tamaño del modelo, sin embargo, a menudo es grande (miles de árboles), lo que dificulta la interpretación humana.
Redes neuronales ofrecen la mayor precisión para patrones complejos, pero la explicabilidad natural más baja. Las contribuciones de características no son directamente legibles de los pesos. Las técnicas post-hoc son necesarias, pero como se señaló en la sección anterior, son regulatoriamente insuficientes.
Métodos de conjunto, que combinan múltiples tipos de modelos, aumentan la precisión pero disminuyen la explicabilidad. Si un conjunto consiste en una red neuronal y un árbol de decisión, el audit record debe mostrar qué tipo de modelo fue responsable de la decisión y cómo se ponderó la combinación.
Fernel Context
El motor de compliance de Fernel almacena cada puntuación de riesgo con un desglose completo de contribución de características: qué características fueron evaluadas, qué valores tenían, cuánto contribuyó cada una a la puntuación, y qué versión de política estaba en vigor en el momento de la evaluación. La puntuación se almacena junto con su registro de auditoría en un journal inmutable. Ninguna decisión puede existir sin su registro. Ningún registro puede ser modificado después de su creación. El examen de AMLA de cualquier decisión de compliance es una única consulta, no una reconstrucción forense.
Leer más: Infraestructura de Compliance | Automatización de Debida Diligencia del Cliente | Seguridad y Compliance
Fuentes:
- Análisis de AIMA 2026: 85% de las instituciones financieras de la UE implementan IA en funciones de banca central, 78% procesos de decisión opacos
- DORA, Reglamento (UE) 2022/2554, Art. 30 (Acuerdos contractuales con proveedores de ICT de terceros), Art. 30(2)(d) (Derecho de auditoría)
- AMLA, Reglamento (UE) 2024/1620, Art. 28 (Requisitos de documentación para sistemas de IA en contexto AML)
- Ley de IA de la UE, Reglamento (UE) 2024/1689, Anexo III (Sistemas de IA de alto riesgo), Art. 11 (Documentación técnica), Art. 13 (Transparencia y provisión de información a usuarios)
- GDPR, Reglamento 2016/679, Art. 22 (Decisiones individuales automatizadas incluyendo elaboración de perfiles)
- EBA, Guía sobre el uso de Machine Learning para modelos internos (borrador 2025-2026)