Scoring crediticio y decisiones automatizadas

Durante años, el análisis regulatorio de un modelo de scoring se agotaba en protección de datos. Hoy hay tres regímenes que se solapan sobre la misma decisión —conceder o denegar un crédito a una persona— y cada uno mira una cosa distinta:

• La Directiva (UE) 2023/2225, la CCD2, mira el resultado frente al consumidor: qué derechos tiene cuando la decisión le afecta, qué datos no pueden usarse y qué debe evaluarse.
• El Reglamento (UE) 2024/1689, el Reglamento de IA, mira el sistema: cómo se ha construido, con qué datos se ha entrenado, cómo se documenta y quién lo supervisa.
• El RGPD mira el tratamiento: la base jurídica, la información al interesado y los límites a las decisiones basadas únicamente en tratamiento automatizado.

La consecuencia práctica es que un proyecto que solo haya trabajado uno de los tres frentes tiene, casi con seguridad, brechas en los otros dos. Y la brecha más común es la misma en todos los casos: el modelo funciona, pero no se puede explicar. Se puede predecir bien y a la vez ser incapaz de decirle a un cliente por qué se le denegó en términos que entienda, o de demostrar a un supervisor cómo se construyó.

Conviene además fijar una idea que ordena todo lo demás. Ninguna de las tres normas prohíbe automatizar. Lo que hacen es exigir que la automatización sea reversible, explicable y supervisada. Un modelo que decide solo, sin posibilidad de revisión humana y sin capacidad de explicar su salida, no es un modelo eficiente: es un modelo que no cumple.

Los tres derechos se leen rápido y se implantan despacio, porque cada uno toca una capa distinta del sistema. El de intervención humana es organizativo: exige personas, formación y una definición clara de hasta dónde llega su capacidad de anular al modelo. El de explicación es técnico: obliga a que el modelo produzca razones, no solo un número, lo que en la práctica condiciona qué arquitecturas son viables. Y el de revisión es procedimental: hay que recoger lo que el cliente alega, dejar constancia de que se ha valorado y motivar la decisión nueva.

El segundo es el que más proyectos obliga a replantear. Un modelo muy preciso pero opaco —un ensamblado profundo, por ejemplo— puede quedar inutilizable no por su rendimiento, sino porque su salida no se puede traducir a una explicación significativa. Esa es una decisión de arquitectura que conviene tomar al diseñar, no cuando llega la primera reclamación.

Y hay una conexión que conviene no perder de vista: la directiva de servicios financieros a distancia establece en paralelo el derecho a obtener intervención humana en fase precontractual cuando se usan herramientas automatizadas. Son dos normas distintas apuntando al mismo sitio — antes de contratar y al decidir la concesión — de modo que el circuito de escalado debe cubrir ambos momentos.

La CCD2 delimita qué información puede sustentar la evaluación de solvencia y excluye expresamente dos fuentes que hasta ahora aparecían en modelos alternativos de scoring:

• Las categorías especiales de datos del RGPD, mencionando expresamente los datos sanitarios.
• Los datos procedentes de redes sociales.

La primera prohibición es coherente con el régimen general de protección de datos y sorprende poco. La segunda es la que cambia proyectos: durante años, el uso de señales de comportamiento digital y de huella social se ha presentado como la vía para dar crédito a perfiles sin historial. Esa vía queda cerrada para la evaluación de solvencia en crédito al consumo.

Pero la consecuencia que de verdad exige trabajo técnico es otra, y no está escrita: las variables aproximadas. Un modelo puede no usar datos de salud y sin embargo incorporar variables que los predicen con alta correlación —patrones de gasto en farmacia, tipo de establecimiento, frecuencia de determinadas categorías—. Formalmente no se usa el dato prohibido; materialmente, sí entra en la decisión. Depurar un modelo de estas aproximaciones no es una revisión documental: es un ejercicio estadístico que hay que hacer sobre las variables reales y dejar documentado.

Ese análisis, además, sirve dos veces. Es lo que exige la CCD2 en materia de datos y es también, en buena medida, lo que pide el Reglamento de IA bajo el epígrafe de gobernanza de datos para los sistemas de alto riesgo. Conviene hacerlo una vez y aprovecharlo para los dos expedientes.

La clasificación no admite discusión: la evaluación de la solvencia crediticia de personas físicas está expresamente en el anexo III, dentro de la categoría de acceso a servicios esenciales. Un prestamista que use un sistema de inteligencia artificial para decidir concesiones está operando un sistema de alto riesgo, con todo lo que eso arrastra.

Merece la pena detenerse en dos de las obligaciones, porque son las que más se malinterpretan. La supervisión humana no se satisface con un botón de anulación que nadie usa: la norma exige un diseño que permita una supervisión efectiva, lo que implica que la persona que supervisa entienda la salida, tenga tiempo material para valorarla y capacidad real de apartarse de ella. Y la conservación de registros no es el log de la aplicación: son las trazas que permiten reconstruir por qué el sistema decidió lo que decidió, en una operación concreta, meses después.

La buena noticia es que hay solapamiento con lo que ya exige la CCD2. El circuito de intervención humana que pide la directiva de crédito es, en buena parte, la supervisión humana que pide el Reglamento de IA; y la trazabilidad que permite explicar una denegación es la que permite conservar registros. Diseñarlos por separado duplica trabajo. Si ya estás trabajando el Reglamento de IA por otra vía, conviene cruzarlo con el análisis del Reglamento de IA.

El artículo 22 del RGPD reconoce al interesado el derecho a no ser objeto de una decisión basada únicamente en el tratamiento automatizado que produzca efectos jurídicos en él o le afecte significativamente de modo similar. Denegar un crédito encaja de lleno en ese supuesto, y por eso la mayoría de las entidades tienen ya una posición tomada sobre esta cuestión.

Lo que cambia ahora es que esa posición hay que reexaminarla a la luz de las otras dos normas, porque el estándar ha subido. Muchos modelos se apoyaban en la idea de que la decisión no era «únicamente» automatizada porque existía una revisión humana nominal. La CCD2 y el Reglamento de IA endurecen esa lectura desde dos ángulos: la primera reconoce un derecho expreso a intervención humana, a explicación y a revisión; el segundo exige que la supervisión humana sea efectiva por diseño. Una revisión meramente formal deja de sostener el argumento.

El resultado es que las tres normas convergen en el mismo entregable práctico, y conviene construirlo una sola vez: un expediente de decisión por operación que recoja qué datos entraron, qué salida produjo el sistema, quién la revisó, qué alegó el cliente si alegó algo y cómo se motivó la decisión final. Ese expediente es a la vez la prueba del cumplimiento del RGPD, la evidencia de la intervención humana de la CCD2 y el registro que pide el Reglamento de IA.

Dos incisos de esa tabla merecen atención porque son los que más trabajo generan. El primero es «la adecuada consideración de las obligaciones actuales»: no basta con conocer los ingresos, hay que incorporar la carga financiera que el cliente ya soporta. Eso obliga a resolver de dónde sale ese dato —consulta a ficheros, información aportada, agregación de cuentas— y a documentar la elección.

El segundo es «de modo adecuado al volumen de operaciones». Es una cláusula de proporcionalidad, y conviene leerla en sus dos direcciones. Para un prestamista pequeño significa que no se le exigirá la maquinaria de una entidad grande. Para uno grande significa exactamente lo contrario: el estándar esperado crece con el volumen, de modo que un procedimiento artesanal deja de ser defendible a partir de cierto tamaño. La proporcionalidad no es siempre un alivio.

Imagina la escena, porque es la que hay que resolver: un cliente al que se le ha denegado el crédito llama y pregunta por qué. La respuesta «no ha superado nuestro sistema de evaluación» ya no sirve. La directiva reconoce el derecho a una explicación significativa y comprensible, y esos dos adjetivos tienen contenido.

Significativa quiere decir que la explicación tiene que referirse a los factores que efectivamente pesaron en esa decisión concreta, no a una descripción genérica del modelo. Comprensible quiere decir que tiene que estar en el lenguaje del cliente, no en el del equipo de riesgos: hablar de «percentil de la variable de antigüedad laboral» no es explicar nada.

Eso exige tres cosas que hay que construir antes de recibir la primera petición:

• Capacidad técnica de atribución. El sistema tiene que poder decir qué factores movieron la decisión en esa operación, no en promedio. Condiciona la arquitectura del modelo.
• Un catálogo de razones en lenguaje claro. Traducciones preescritas y revisadas de cada factor a una frase que un consumidor entienda, para que la explicación no dependa de quién atienda la llamada.
• Un circuito de alegación y revisión. Dónde entra lo que el cliente aporta, quién lo valora y cómo se motiva la nueva decisión.

Conviene además cuidar un límite: explicar no es revelar el modelo. Hay un equilibrio entre el derecho del consumidor a entender la decisión y el interés legítimo de la entidad en no exponer su sistema de evaluación a la ingeniería inversa ni al fraude. Ese equilibrio se resuelve en el diseño del catálogo de razones —suficientemente concretas para ser útiles, suficientemente agregadas para no ser un manual de cómo engañar al modelo—, y conviene dejarlo razonado por escrito.