LogoIngeniería de Software Estadístico
Buscar

Checklist Unificado: Cumplimiento Regulatorio y MLOps

Documento fuente de referencia para todos los proyectos de ingeniería estadística

Este documento es la referencia única de verificaciones de calidad, cumplimiento y despliegue. El Manual Completo y la Guía de Implementación referencian este checklist en lugar de duplicarlo.

Leyenda: [P] = Producción obligatorio, [R] = Regulatorio adicional (legaltech, finanzas, salud).

Diagrama de estructura del checklist

1. Reproducibilidad

Diagrama de flujo de la reproducibilidad

1.1 Gestión de dependencias [P]

  • Existe un lock file versionado: poetry.lock, requirements.lock o conda-lock.yml.
  • El lock file está bajo control de versiones en Git.
  • El proceso de restauración del entorno está automatizado y documentado.
  • El pipeline CI/CD restaura el entorno antes de ejecutar cualquier prueba o análisis.
  • El README.md especifica la versión del intérprete base (Python 3.11, R 4.3, etc.).

1.2 Semillas y aleatoriedad [P]

  • Existe una semilla global configurada al inicio del pipeline (random_seed=2026).
  • Los modelos MCMC incorporan un parámetro de semilla explícito.
  • Las semillas están documentadas en el README.md o en docs/decisions/.

1.3 Registro de entorno [P]

  • Un mecanismo automático genera audit/environment_snapshot.json con: SO, lenguaje, versión, paquetes instalados, fecha.
  • El snapshot está enlazado en la documentación de resultados.

1.4 Versionado de datos [P]

  • Los datasets de entrenamiento están versionados con DVC.
  • El hash del commit DVC/Git correspondiente al dataset se registra como parámetro en MLflow.
  • Es posible reproducir el entrenamiento completo a partir del run_id de MLflow.

2. Validación de Calidad de Datos

Mapa conceptual de la validación de calidad

2.1 Contrato de datos [P]

  • Existe una definición del contrato de datos en formato legible por máquina (YAML o código GE).
  • El contrato especifica: esquema de columnas, tipos, restricciones de nulidad, rangos esperados, unicidad.
  • La ingesta falla explícitamente si el contrato no se cumple.

2.2 Validación con Great Expectations [P]

  • Las expectativas están definidas en una suite nombrada (training_suite, inference_suite).
  • La validación se ejecuta automáticamente en el pipeline antes del entrenamiento.
  • Los resultados de validación se almacenan en audit/data_validation_<run_id>.json.

2.3 Auditoría de ingesta [P]

  • Cada ingesta genera una entrada estructurada en audit/data_ingestion.log con: timestamp, source_id, n_rows, hash_sha256, dvc_commit, validation_status.
  • El log es append-only (inmutable).

2.4 Trazabilidad de datos [R]

  • Existe un manifiesto de integridad audit/integrity_manifest.json con hashes MD5 y SHA256 por archivo.
  • Un script de verificación compara hashes actuales vs. almacenados en CI/CD.
  • El catálogo de datos (DataHub u OpenMetadata) tiene registrado el dataset con propietario y SLA.

3. Validación Estadística

Árbol de decisión de diagnósticos bayesianos

3.1 Diagnósticos para modelos bayesianos [P]

  • R-hat máximo < 1.01 en todos los parámetros.
  • ESS ratio > 0.1 (ESS / total_draws) para todos los parámetros.
  • Divergencias en HMC = 0.
  • Gráficos de traza archivados como artefactos en MLflow.
  • Diagnósticos guardados en audit/diagnostics_<run_id>.json.

3.2 Validación de supuestos (modelos frecuentistas) [P cuando aplique]

  • Normalidad de residuos: Shapiro-Wilk, p > 0.05.
  • Homocedasticidad: Breusch-Pagan, p > 0.05.
  • Independencia: Durbin-Watson, p > 0.05.
  • Linealidad: prueba RESET, p > 0.05.
  • Resultados guardados en audit/assumptions_<run_id>.json.
  • Si algún supuesto falla: documentada la violación y la acción correctiva.

3.3 Análisis de sensibilidad [P]

  • Se ejecutan al menos 3 variantes de especificación (diferentes variables, priors o familia).
  • La variación relativa de coeficientes clave es < 10% (o se documenta explícitamente si supera el umbral).
  • Resultados guardados en audit/sensitivity_<run_id>.json.
  • Decisión documentada en docs/decisions/.

4. Arquitectura y Código

Diagrama de capas

4.1 Estructura [P]

  • Separación clara de capas: core, adapters, services, interfaces.
  • Sin dependencias circulares entre capas.
  • core no importa de adapters, services o interfaces.
  • El frontend se comunica solo con interfaces/api, no con capas internas.

4.2 Calidad de código [P]

  • Linting automatizado (Ruff/Flake8 para Python).
  • Formateo automático (Black para Python).
  • Sin warnings de linting en el pipeline CI.

4.3 Pruebas [P]

  • Pruebas unitarias con cobertura ≥ 80% en módulos críticos (core, services).
  • Pruebas de integración para flujos end-to-end con datos de muestra.
  • Las pruebas no usan datos reales sensibles; usan semillas fijas y datos simulados.
  • Todas las pruebas pasan en CI antes de cualquier despliegue.

5. MLOps y Registro de Modelos

Flujo de promoción de modelos (champion/challenger)

5.1 Experiment tracking [P]

  • MLflow configurado con servidor remoto (no solo modo local).
  • Cada ejecución registra: parámetros, métricas, artefactos, hash DVC, hash Git.
  • El nombre del experimento sigue una convención documentada.

5.2 Model Registry [P]

  • El modelo está registrado en el MLflow Model Registry con nombre semántico.
  • El flujo de promoción es: None → staging → production → archived.
  • La promoción a production requiere un gate de calidad automático (métricas mínimas).
  • Cada promoción queda registrada con quién y cuándo.

5.3 Reproducibilidad del modelo [P]

  • Dado el run_id de MLflow, es posible reproducir exactamente el entrenamiento (datos + código + entorno).
  • El modelo en production tiene un run_id asociado con todos los artefactos.

6. Seguridad

Capas de seguridad en profundidad

6.1 Gestión de secretos [P]

  • Sin credenciales en el código fuente ni en el historial de Git.
  • Las credenciales se inyectan desde variables de entorno o HashiCorp Vault.
  • El archivo .env está en .gitignore.
  • El pipeline valida que las variables de entorno requeridas existen antes de ejecutar.

6.2 Cifrado de artefactos [P]

  • Los modelos serializados en reposo están cifrados (S3 con SSE-KMS o equivalente).
  • Los backups también están cifrados.

6.3 Control de acceso [P]

  • RBAC implementado: roles diferenciados para ver, predecir y promover modelos.
  • Autenticación JWT o API keys para todos los endpoints que acceden a datos sensibles.

6.4 Registro de accesos [P]

  • Todo acceso a la API de predicción genera una entrada de auditoría (middleware).
  • El log incluye: timestamp, endpoint, método, usuario/clave, status_code, duración.
  • Los logs de acceso a datos sensibles (PII, financieros, sanitarios) se almacenan en audit/data_access.log. [R]

6.5 Rotación de secretos [R]

  • Las claves de API y los tokens tienen expiración configurada.
  • La rotación de secretos está automatizada mediante Vault o el gestor de secretos equivalente.

6.6 Protección contra ataques de inferencia [R]

  • Rate limiting estricto por usuario/IP en la API de predicción.
  • Monitoreo de patrones de consulta inusuales (posible model stealing).
  • Documentado en docs/decisions/ si se añade ruido a las predicciones.

7. Documentación

Jerarquía de documentación

7.1 Documentación técnica [P]

  • README.md con instrucciones de instalación, configuración y uso.
  • CHANGELOG.md siguiendo Keep a Changelog con versionado semántico.
  • Docstrings en todas las funciones públicas con parámetros, retorno y referencias a decisiones.

7.2 Decisiones analíticas [P]

  • Existe al menos un archivo de decisión en docs/decisions/ por cada modelo o análisis significativo.
  • Cada decisión documenta: contexto, opciones consideradas, decisión tomada, consecuencias.
  • Las decisiones están referenciadas en el código mediante comentarios o metadatos.

7.3 Metodología [R]

  • docs/metodologia.md existe y contiene: fuente de datos, tratamiento, modelo, validación, interpretación, limitaciones.
  • Las decisiones analíticas tienen justificación explícita (no solo "se hizo así").
  • Incluye referencias a literatura metodológica.

8. Despliegue y CI/CD

Secuencia del pipeline CI/CD

8.1 Containerización [P]

  • Dockerfile produce imagen reproducible con dependencias fijas.
  • La imagen se escanea con Trivy o equivalente; sin vulnerabilidades críticas.
  • El contenedor ejecuta como usuario no root.
  • Los health checks están implementados y probados.

8.2 Pipeline CI/CD [P]

El pipeline ejecuta en orden: restauración de entorno → linting → pruebas unitarias → pruebas de integración → validación de contrato de datos → entrenamiento → gate de calidad → build Docker → escaneo de vulnerabilidades → despliegue a staging → smoke tests → despliegue a producción.

  • El pipeline falla en cualquier paso sin continuar al siguiente.

Definición de prueba de humo (smoke test) en staging — Verifica: health endpoint responde en < 5s, modelo carga y predice 10 registros en < 200ms, predicciones en formato válido.

python
  • Los secretos se pasan al pipeline como variables cifradas (GitHub Secrets, Vault).
  • Las aprobaciones manuales para producción están configuradas cuando aplica.

9. Monitoreo en Producción

Mapa de señales de monitoreo

9.1 Métricas operacionales [P]

  • Latencia de inferencia (p50, p95, p99) monitoreada con Prometheus.
  • Tasa de error < 0.1% de las solicitudes.
  • Alertas configuradas para degradación de latencia o tasa de error.

9.2 Monitoreo de drift [P]

  • Estadísticas de referencia capturadas durante el entrenamiento (media, desviación, percentiles).
  • Comparación continua de datos entrantes con referencia (Evidently AI, Hellinger Distance).
  • Alerta automática cuando el drift supera el umbral configurado.
  • Política de reentrenamiento definida (basada en tiempo, drift o métricas de negocio).

9.3 Calidad de predicciones [P cuando hay etiquetas]

  • Métricas de rendimiento calculadas cuando lleguen etiquetas (AUC, F1, RMSE según el tipo de modelo).
  • Para modelos bayesianos: cobertura de intervalos de credibilidad monitoreada.
  • Alertas cuando las métricas caen por debajo de los umbrales acordados en el SLA.

10. Gobernanza y Compliance Regulatorio

10.1 Principios de protección de datos [R]

  • Minimización: solo se procesan datos estrictamente necesarios para la finalidad declarada.
  • Finalidad: los datos no se usan para propósitos no declarados en el contrato.
  • Política de retención documentada en data_retention_policy.yaml.
  • Proceso de eliminación automática de datos fuera de TTL implementado.

10.2 Integridad de registros [R]

  • Los logs de auditoría son append-only y encadenados con hashes (ver Manual Completo, sección de auditoría).
  • Los registros se exportan periódicamente a un sistema externo inmutable.
  • Existe un proceso de verificación de integridad del audit trail.

10.3 Derechos de los interesados [R]

  • Existe un proceso documentado para responder solicitudes ARCO (Acceso, Rectificación, Cancelación, Oposición).
  • Los endpoints de gestión de derechos están implementados y probados.

11. Script de Verificación Automatizada

bash

Referencia Rápida de Artefactos

CategoríaArtefactoUbicaciónContenido mínimo
ReproducibilidadLock de dependenciasRaízVersiones exactas
ReproducibilidadSnapshot de entornoaudit/environment_snapshot.jsonSO, lenguaje, paquetes, fecha
DatosContrato de calidadcontracts/<dataset>.yamlExpectativas GE
DatosLog de ingestaaudit/data_ingestion.logTimestamp, hash, DVC commit
DatosManifiesto de integridadaudit/integrity_manifest.jsonHashes SHA256
ValidaciónDiagnósticos bayesianosaudit/diagnostics_<run_id>.jsonR-hat, ESS, divergencias
ValidaciónTests de supuestosaudit/assumptions_<run_id>.jsonP-valores, passed/failed
ValidaciónSensibilidadaudit/sensitivity_<run_id>.jsonVariación de coeficientes
MLOpsParámetros MLflowMLflow UI / APIhash DVC, semilla, fórmula
DecisionesDocumento de decisióndocs/decisions/NNN-titulo.mdContexto, opciones, decisión
DocumentaciónMetodologíadocs/metodologia.md8 secciones estándar [R]
SeguridadLog de accesosaudit/data_access.logUsuario, dato, timestamp [R]
CI/CDPipeline.github/workflows/Stages completos

Documentos relacionados