
Documentar un modelo de scoring para que lo entienda quien no lo construyó
El Reglamento (UE) 2024/1689, el Reglamento de Inteligencia Artificial, se publicó en el Diario Oficial de la Unión Europea el 12 de julio de 2024. Su anexo III incluye entre los sistemas de alto riesgo los destinados a evaluar la solvencia de personas físicas o a establecer su calificación crediticia, con la única excepción de los que se usan para detectar fraude financiero. Para un banco mediano eso no describe un proyecto futuro de inteligencia artificial: describe el modelo de scoring que lleva años aprobando y denegando operaciones. Y ese modelo tiene casi siempre un documento de desarrollo. Lo que no suele tener es la respuesta a una pregunta sencilla: si mañana se perdiera todo salvo ese documento, ¿podría alguien de fuera del equipo reconstruir el modelo y obtener las mismas puntuaciones que hoy salen en producción?
La respuesta honesta, en muchas entidades, es que no, y no por descuido. El documento describe el modelo que se aprobó. Desde entonces ha habido una recalibración, una variable sustituida porque la fuente dejó de actualizarse, un filtro nuevo sobre las solicitudes incompletas y, en los últimos años, un canal digital que trae clientes con un perfil que el modelo original apenas vio. Cada cambio fue razonable y está registrado en algún sitio: un correo, una incidencia, un acta, la memoria de quien lo hizo. El modelo funciona. Lo que se ha perdido por el camino es la capacidad de explicar, a alguien que no estaba, por qué puntúa lo que puntúa, y esa es exactamente la capacidad que se va a pedir.
Lo que se pide, leído desde el que lo va a revisar
El artículo 11 obliga a disponer de documentación técnica antes de poner el sistema en servicio y a mantenerla actualizada, y el anexo IV enumera su contenido: la descripción del sistema y de su finalidad, el proceso de desarrollo y las decisiones de diseño, los datos y cómo se obtuvieron y prepararon, las métricas de rendimiento y por qué son las adecuadas para ese sistema, el sistema de gestión de riesgos, los cambios introducidos a lo largo de su ciclo de vida y el plan de seguimiento una vez en uso. El artículo 10 añade la gobernanza de los datos, incluido el examen de posibles sesgos. Leída como lista, parece una plantilla que se rellena. Leída desde quien la va a revisar, es otra cosa: cada punto es una pregunta que esa persona hará sin tener delante a quien construyó el modelo.
Para las entidades de crédito hay un matiz que conviene no perder. El propio Reglamento prevé, en su artículo 17.4, que la obligación de tener un sistema de gestión de la calidad se considere cumplida a través de las normas de gobierno interno que ya exige la normativa financiera, salvo en tres puntos: la gestión de riesgos, el seguimiento posterior a la puesta en servicio y la notificación de incidentes graves. Es decir, buena parte del andamiaje organizativo ya existe en un banco supervisado. Lo que no viene dado por ese gobierno interno es el contenido técnico del expediente del modelo concreto, y ahí la experiencia con la validación interna ayuda, pero no basta: la validación comprueba que el modelo funciona; el expediente tiene que permitir que otro lo compruebe sin preguntar.
La confusión de fondo
La lectura habitual es que se trata de un problema de cumplimiento y que se resuelve con un buen documento. La confusión, que compartimos quienes hemos construido modelos de riesgo, es creer que documentar un modelo es describirlo. El equipo de desarrollo documenta lo que hizo; validación documenta lo que comprobó; negocio documenta para qué se usa. Las tres piezas son correctas y ninguna responde a lo que preguntará alguien de fuera: qué ocurrió entre la aprobación y hoy, y por qué. Un buen expediente de modelo se parece más al libro de mantenimiento de un avión que a su manual. El manual explica cómo vuela ese tipo de avión. El libro registra qué se le ha hecho a este avión, cuándo, quién y por qué, de modo que un mecánico que no lo ha visto nunca pueda decidir si está en condiciones de despegar.
Dónde suele estar el hueco
Hay cuatro sitios donde un expediente de scoring se rompe con más frecuencia, y ninguno es la descripción del algoritmo. El primero es la trazabilidad del dato: de qué tabla sale cada variable, con qué filtros y, sobre todo, qué solicitudes se excluyeron, porque las exclusiones son el lugar donde la población del modelo cambia sin que nadie lo decida explícitamente. El segundo son las alternativas descartadas: la variable que se retiró porque podía actuar como aproximación de una característica protegida, o la segmentación que se probó y no mejoró nada; la primera pregunta de cualquier revisor es por qué no se hizo de otra manera. El tercero es el rendimiento por segmento y a lo largo del tiempo, no solo el global, porque un modelo puede mantener su capacidad discriminante agregada mientras se degrada precisamente en el segmento que la entidad está haciendo crecer. El cuarto son los límites de uso escritos por quien lo construyó: en qué población o en qué tipo de operación no debería aplicarse.
Preparar ese expediente y validarlo son trabajos distintos, y conviene que los hagan personas distintas. Preparar es reconstruir la historia del modelo, ordenar la trazabilidad, rehacer los análisis por segmento que falten y escribir las limitaciones con la precisión suficiente para que un tercero pueda contrastarlas. Validar es juzgar si el modelo y su documentación son adecuados, y esa función corresponde a quien la entidad y el supervisor hayan designado para ello. Quien prepara no debería dictaminar sobre lo que ha preparado, del mismo modo que quien escribe el libro de mantenimiento no firma la aptitud para el vuelo. Mezclar los dos papeles ahorra semanas al principio y resta credibilidad al final, que es cuando se necesita.
Una prueba que se puede hacer esta semana
La definición que ordena todo lo anterior es breve: la documentación de un modelo no demuestra que funciona; demuestra que otro puede comprobarlo. Y se puede poner a prueba sin esperar a ningún requerimiento. Se elige un modelo de scoring en producción, se entrega su documentación completa a alguien de la entidad que no participó en su desarrollo ni en su validación, y se le pide que responda por escrito, sin preguntar a nadie, tres cosas: de qué datos y con qué exclusiones sale cada variable, qué ha cambiado en el modelo desde que se aprobó y por qué, y en qué población no debería usarse. Lo que esa persona no pueda responder es el hueco del expediente. Encontrarlo así cuesta una semana de trabajo interno; encontrarlo en una revisión externa cuesta bastante más que eso.
PISA: todos señalan a un culpable, los datos no se lo dan a ninguno
La caída de PISA tiene dos culpables de moda: la reforma educativa y el dinero. Llevados a los datos, el dinero queda descartado, Finlandia tiene coartada y España deja una pista que no llega a condena.
Prever ventas y producción con los datos de la cooperativa: qué se puede anticipar y qué no
Una cooperativa ya tiene en su facturación y en sus básculas lo necesario para prever parte de la campaña. La otra parte, empezando por el precio, no se prevé: se prepara. Dónde está la frontera.

¿Necesitas resolver algo parecido?
Modelización cuantitativa, validación de modelos y data leadership. Trabajo bajo NDA si lo pides.
Háblame de tu proyecto →