13  Gobernanza y Aprobación MRM (SR 11-7)

13.1 Aprobación de Model Risk Management

La diferencia editorial clave entre CRPTO y los métodos decision-focused puros (SPO+, end-to-end DFL) es que CRPTO está construido para pasar una auditoría de Model Risk Management según el marco SR 11-7 de la Reserva Federal y las expectativas equivalentes del BCE/EBA. Esta página documenta los gates aplicados al champion oficial y muestra los cuatro subsistemas pasando simultáneamente — la firma operativa de un sistema desplegable, no un modelo de paper aislado.

13.1.1 Resumen ejecutivo: 4/4 subsistemas PASS

13.1.2 Política de gobernanza aplicada

El reporte MRM se rige por la política de gobernanza congelada en reports/mrm/mrm_validation_report.json::governance_policy y ::retraining_triggers:

NotaCómo se conectan estos triggers con el cierre del proyecto

El bound conformal que vive en el LP robusto (cobertura 90% nominal) no es estático: si en producción la cobertura realizada cayera más de 2 puntos porcentuales (coverage_degradation_threshold = 0.02), el sistema activa retraining. Eso convierte la garantía conformal teórica en un mecanismo operativo de mantenimiento y conecta directamente con el future work de online conformal (UP-OCP, ACI) que se discute en Sección 6.0.8.

13.1.3 Criterios de challenger: cuándo se permite reemplazar al champion

Una pieza menos visible pero metodológicamente importante del MRM es el set de criterios que un nuevo modelo (challenger) debería pasar para promoverse a champion. El champion actual fue promovido bajo estos criterios congelados:

TipLectura editorial

Tres cosas que esta tabla deja por escrito y que un revisor riguroso querrá ver:

  1. Sin SMOTE. El proyecto no permite oversampling sintético porque rompe la garantía conformal de intercambiabilidad y deja al modelo sensible a artefactos de generación.
  2. Restricciones monotónicas obligatorias. El champion CatBoost tiene installment:+1, annual_inc:-1, dti:+1, loan_to_income:+1 codificadas; un challenger debe respetar al menos esas restricciones.
  3. Promoción condicional a tres gates simultáneos. Conformal + fairness + governance deben pasar al mismo tiempo. Esa es la firma de un MRM serio: ningún subsistema vetable individualmente.

13.1.4 Métricas snapshot del champion en el reporte

(Este snapshot es el agregado operativo que el MRM auditó; el champion paper-grade y los retornos de portafolio se reportan desde final_project_promotion.json y no se mezclan con esta tabla, por la regla canónica de no mezclar familias.)

13.1.5 Por qué la auditoría MRM importa para el argumento del paper

Un revisor que viene del lado de operations research tiende a leer “auditabilidad” como un soft claim. La diferencia operativa, sin embargo, es muy concreta. SPO+ entrenado end-to-end produce una red neuronal cuya decisión es un input no-lineal de los costos predichos: para auditar la decisión, hay que auditar la red. Esa auditoría es difícil porque:

  • No hay garantía de que un cambio pequeño en el costo verdadero produzca un cambio pequeño en la decisión (la red puede tener regiones de decisión irregulares).
  • No hay forma de separar “el modelo aprendió la distribución de costos” de “el modelo aprendió un atajo correlacional” sin tests adversariales costosos.
  • Las restricciones monotónicas, fairness y triggers de retraining tienen que reaplicarse manualmente, porque la red no las preserva por construcción.

CRPTO, en cambio, expone cada pieza al auditor por separado: la PD calibrada se auditea con los tests de calibración (KS/Kuiper/ECE), la cobertura conformal se verifica empíricamente, el LP robusto es un programa lineal cuya factibilidad se puede inspeccionar fila por fila, y el funded set se audita por fairness directamente. Cada subsistema es individualmente vetable y individualmente reproducible. Eso es lo que compliance_summary.n_passing = 4 significa operativamente.

13.1.6 Reproducibilidad

uv run python scripts/generate_mrm_report.py
uv run pytest tests/test_evaluation/ -k "mrm or governance"

Artefactos:

  • models/mrm_report_status.json — estado del reporte (overall pass + subsystems).
  • reports/mrm/mrm_validation_report.json — reporte detallado por subsistema (governance, conformal, pipeline, fairness, challenger criteria).
  • reports/mrm/corepd_model_card.json, corepd_model_card.html — model card pública con metadata, versionado, owners.
  • reports/mrm/skops/ — modelo serializado en formato auditable (skops, no pickle).