Los equipos de riesgo de modelo no necesitan una clase sobre valores SHAP. Necesitan códigos de razón, documentación estable y monitoreo que demuestre que el modelo sigue comportándose como fue validado.
Todos los bancos con los que trabajamos quieren usar machine learning para crédito, fraude y AML. Todos tienen también una función de gestión de riesgo de modelo (MRM) cuyo trabajo es decir que no hasta que se respondan tres preguntas: qué hace el modelo, por qué decidió esto y cómo sabemos que sigue funcionando.
1. Qué hace el modelo
Esto es documentación, no matemática. Una model card que describa la población, las features, la ventana de entrenamiento, las exclusiones y las limitaciones conocidas convence más a un validador que cualquier gráfico de precisión. Escribila antes de entrenar y actualizala con cada release.
2. Por qué decidió esto
Los códigos de razón son la moneda de la explicabilidad en banca. Para cada decisión, las features que más contribuyeron expresadas en lenguaje de negocio: “alta proporción de cuentas nuevas en los últimos 30 días”, no “feature_47”. SHAP y métodos similares son el mecanismo; el mapeo a lenguaje es el producto.
3. Cómo sabemos que sigue funcionando
La validación es un punto en el tiempo. El monitoreo es lo que mantiene un modelo aprobado. Estabilidad de población, drift de features, performance por segmento y métricas de fairness deberían ser dashboards que el equipo de MRM pueda abrir, con alertas dirigidas al dueño del modelo.
Cuando existen estas tres piezas, los ciclos de aprobación pasan de meses a semanas, y la conversación con el regulador se convierte en un recorrido en lugar de una negociación.
- #IA
- #Banca
- #Riesgo de modelo