Monitorización y ciclo de vida de modelos de IA en la administración pública

La puesta en producción de modelos de IA es sólo el comienzo: sin monitorización y gestión del ciclo de vida, los modelos pueden degradarse, generar decisiones sesgadas o incumplir obligaciones legales. Este post explica, con pasos prácticos, cómo diseñar un sistema de vigilancia y gobernanza para modelos de IA en entidades públicas, compatible con ENS (RD 311/2022), RGPD y las obligaciones del EU AI Act.

¿Por qué no basta con evaluar un modelo una sola vez?

Cambios en los datos de entrada (data drift) o en la relación entre entradas y resultados (concept drift) degradan la precisión con el tiempo.
La degradación puede traducirse en errores administrativos, denegaciones indebidas de servicios o desigualdades territoriales.
Marco regulatorio: el EU AI Act exige sistemas de vigilancia post-comercialización proporcional al riesgo; RGPD requiere control de perfiles automatizados y trazabilidad; ENS exige controles de seguridad continuos. La monitorización ayuda a cumplir estas obligaciones y a mantener la confianza pública.

Métricas operativas y de rendimiento que hay que medir

Define un catálogo de métricas mínimo y aplicable desde el primer día:

Rendimiento predictivo: precisión, recall, AUC, error medio, según el tipo de modelo.
Calibración y confianza: distribución de scores de probabilidad y relación con resultados reales.
Drift de datos: distancia entre distribución actual y distribución de entrenamiento (p. ej. KS, PSI).
Drift de concepto: descenso sostenido en métricas de negocio (por ejemplo, tasa de apelaciones en ayudas).
Equidad: métricas por segmentos relevantes (género, edad, territorio) para detectar sesgos.
Robustez operativa: latencia, tasa de errores, disponibilidad.
Trazabilidad: porcentaje de inferencias con registro completo (input, output, versión de modelo, metadatos).

Umbrales y alertas

Asigna umbrales claros para cada métrica (por ejemplo, caída de precisión >5% sostenida 7 días) y define niveles de alerta (informativa, crítica). Las alertas deben integrarse con el sistema ITSM para seguimiento y escalado.

Qué registrar: mínimos imprescindibles para trazabilidad y auditoría

Para cada inferencia guarde al menos:

Identificador anónimo del caso (evitar datos personales si no son necesarios).
Versión del modelo y artefactos (semilla, librerías).
Input y output (o histogramas/representaciones si el input es sensible).
Score de confianza y umbral aplicado.
Timestamp y servicio/endpoint.
Resultado real cuando esté disponible (ground truth) para evaluación.

Esto facilita auditorías internas, respuesta a reclamaciones ciudadanas y evidencias frente a la autoridad competente.

Estrategias prácticas de validación continua

Shadow mode: ejecutar el nuevo modelo en paralelo sin afectar decisiones para comparar salidas en producción.
Canary deployments: desplegar a una fracción limitada de tráfico.
Evaluaciones periódicas: pruebas mensuales o trimestrales con conjuntos de validación actualizados.
Tests de regresión: automatizar pruebas que reproduzcan escenarios críticos y reglas legales (p. ej. prioridad en determinadas subvenciones).

Automatizar estas tareas con pipelines MLOps reduce riesgos y acelera reincorporaciones.

Gobernanza: cuándo retrenar, cuándo retirar

Establece reglas operativas claras:

Triggers de retraining: umbrales de drift, caída de métricas de negocio, cambios en regulación o en datos de entrada.
Validación previa al despliegue: pruebas de fairness, comparación con baseline y revisión por equipo legal/funcional.
Versionado y rollback: cada retraining debe generar una versión única y un plan de rollback probado.
Documentación obligatoria: model cards, risk assessment, y registro en inventario de algoritmos (obligatorio para transparencia).

Estas prácticas facilitan cumplimiento con el EU AI Act y la obligación de mantener documentación técnica accesible.

Plan de respuesta a incidentes

Un incidente es cualquier degradación que afecte derechos de la ciudadanía o seguridad del servicio. El plan debería incluir:

Equipo de respuesta: responsables técnicos, jurídico, de protección de datos y comunicación.
Procedimientos de contención: desconexión del modelo, fallback a proceso manual, activación de canary/rollback.
Notificación interna y, si procede, administrativa (según EU AI Act y RGPD) y a la ciudadanía.
Post-mortem y medidas correctoras: root cause analysis, actualización de pipelines, formación.

Integrar este plan con las políticas ENS (RD 311/2022) y con los registros exigidos por RGPD reduce riesgo legal.

Integración con procesos IT y capacidades mínimas

Inventario obligatorio de modelos y clasificación por riesgo.
Integración de logs con SIEM/observability y con la CMDB municipal.
Pipelines MLOps que automatizan pruebas, despliegues y retraining.
Roles mínimos: propietario del modelo (funcional), responsable técnico (DevOps/MLOps), delegado de protección de datos, auditor interno.

Estas piezas permiten que la monitorización sea operativa, reproducible y verificable.

Checklist de 30–90 días para empezar

Mapear modelos y clasificarlos por riesgo (alto/medio/bajo).
Definir métricas clave y umbrales iniciales por modelo.
Implementar logging mínimo (input/output/version/timestamp).
Establecer alertas en ITSM y responsable de escalado.
Programar evaluaciones periódicas y establecer política de retraining.

OptimGov Ready puede ayudar a traducir esta checklist a un plan operativo adaptado a su entidad.

Tomaaway: primera acción prioritaria

Empiece por inventariar y clasificar sus modelos y, sin demora, active logs básicos (input/output/version/timestamp). Con esos datos podrá detectar degradaciones tempranas y cumplir exigencias regulatorias.

La monitorización continua no elimina riesgos, pero permite gestionarlos: convierta la observabilidad en una práctica operativa y no en una tarea puntual.