Lo que un auditor pide ver
Un auditor de cumplimiento, ya sea del Banco de España, de la AEPD o de un organismo certificador de ISO 42001, no pide código. Pide evidencia. La diferencia entre un sistema que sobrevive una auditoría y otro que la suspende está en cuatro capas de evidencia que se diseñan al inicio, no se reconstruyen al final.
Capa 1: políticas y dueños
El auditor empieza preguntando quién decidió qué. Política de IA aprobada por el órgano de gobierno. Roles definidos: dueño del modelo, dueño de los datos, supervisor humano, responsable de incidentes. Procedimientos firmados. Si la política existe en un PowerPoint pero no en una norma interna versionada, no cuenta. Esta capa se construye con el departamento legal y con cumplimiento, no con ingeniería.
Capa 2: trazabilidad de datos y modelos
El sistema debe poder responder, para cualquier predicción de cualquier día, qué versión del modelo la generó, con qué versión de los datos, con qué prompt y qué herramientas. Esto exige tres cosas. Un registro de versiones del modelo con fecha, métricas y diff de cambios. Un linaje de datos que documente origen, transformaciones y residencia. Un registro automático de cada inferencia que pueda reconstruir la cadena hasta la decisión.
El error común es confiar en logs de aplicación. Los logs sirven para depurar; no sirven como evidencia regulatoria sin estructura ni retención garantizada. La retención mínima de seis meses del artículo 12 de la Ley de IA es indicativa; sectores como banca y sanidad piden plazos mucho más largos.
Capa 3: validación y monitorización
El auditor pide pruebas de que el sistema fue validado antes del despliegue y que se monitoriza después. La validación previa es el harness de evaluación con conjunto dorado anotado por expertos. La monitorización post-despliegue mide deriva de datos, deriva de calidad y rendimiento operativo (latencia, coste, errores). Sin estas dos piezas, el sistema entra en producción sin red de seguridad y sale sin justificación.
La regla práctica: si el equipo no puede mostrar un cuadro comparativo entre dos versiones del modelo con métricas cuantitativas, el sistema no está listo para auditoría. Si no puede mostrar la deriva del último trimestre, no está listo para producción.
Capa 4: gestión de incidentes
Todo sistema falla. La diferencia es si el equipo lo detecta antes que el cliente y lo gestiona con un procedimiento documentado o si lo descubre tarde y reacciona ad hoc. El procedimiento incluye umbrales que disparan alertas, escalado a un humano nominado, plantilla de notificación a la autoridad competente cuando corresponde, y plan de mitigación con tiempos comprometidos. Las obligaciones de notificación de la Ley de IA, DORA y RGPD se solapan: una sola política bien diseñada las cubre las tres.
Lo que separa lo bueno de lo presentable
Un sistema bueno produce las cuatro capas porque están diseñadas en la arquitectura desde el día uno. Un sistema solo presentable las improvisa la semana antes de la auditoría. La diferencia se nota al primer día de revisión: el equipo presenta un dossier completo o pasa la semana buscando documentos. La metodología TRACE existe precisamente para que la primera situación sea la norma.