Credit scoring e decisioni automatizzate

Per anni l’analisi normativa di un modello di scoring si esauriva nella protezione dei dati. Oggi ci sono tre regimi che si sovrappongono sulla stessa decisione — concedere o rifiutare un credito a una persona — e ciascuno guarda una cosa diversa:

• La Direttiva (UE) 2023/2225, la CCD2, guarda al risultato per il consumatore: quali diritti ha quando la decisione lo riguarda, quali dati non si possono usare e che cosa va valutato.
• Il Regolamento (UE) 2024/1689, il Regolamento sull’IA, guarda al sistema: come è stato costruito, con quali dati è stato addestrato, come è documentato e chi lo sorveglia.
• Il GDPR guarda al trattamento: la base giuridica, l’informativa all’interessato e i limiti alle decisioni basate unicamente sul trattamento automatizzato.

La conseguenza pratica è che un progetto che abbia lavorato solo su uno dei tre fronti ha, quasi di certo, lacune negli altri due. E la lacuna più comune è sempre la stessa: il modello funziona, ma non si può spiegare. Può prevedere bene ed essere comunque incapace di dire a un cliente perché gli è stato rifiutato il credito in termini che capisca, o di dimostrare a un’autorità di vigilanza come è stato costruito.

Conviene inoltre fissare un’idea che ordina tutto il resto. Nessuna delle tre norme vieta di automatizzare. Quello che fanno è esigere che l’automazione sia reversibile, spiegabile e sorvegliata. Un modello che decide da solo, senza possibilità di riesame umano e senza capacità di spiegare il proprio output, non è un modello efficiente: è un modello non conforme.

I tre diritti si leggono in fretta e si attuano lentamente, perché ciascuno tocca uno strato diverso del sistema. Quello all’intervento umano è organizzativo: richiede persone, formazione e una definizione chiara di fin dove arrivi il loro potere di scavalcare il modello. Quello alla spiegazione è tecnico: obbliga il modello a produrre ragioni, non solo un numero, e questo nella pratica condiziona quali architetture siano praticabili. E quello al riesame è procedurale: bisogna raccogliere ciò che il cliente sostiene, dare atto di averlo valutato e motivare la nuova decisione.

Il secondo è quello che costringe più progetti a ripensarsi. Un modello molto preciso ma opaco — un ensemble profondo, per esempio — può diventare inutilizzabile non per le sue prestazioni, ma perché il suo output non si può tradurre in una spiegazione significativa. È una decisione di architettura da prendere in fase di progettazione, non quando arriva il primo reclamo.

E c’è un collegamento da non perdere di vista: la direttiva sui servizi finanziari a distanza stabilisce in parallelo il diritto di ottenere un intervento umano nella fase precontrattuale quando si usano strumenti automatizzati. Sono due norme diverse che puntano allo stesso punto — prima di contrarre e al momento di decidere la concessione — per cui il percorso di escalation deve coprire entrambi i momenti.

La CCD2 delimita quali informazioni possono sostenere la valutazione del merito creditizio ed esclude espressamente due fonti che finora comparivano nei modelli alternativi di scoring:

• Le categorie particolari di dati del GDPR, con espressa menzione dei dati sanitari.
• I dati provenienti dai social network.

Il primo divieto è coerente con il regime generale di protezione dei dati e sorprende poco. Il secondo è quello che cambia i progetti: per anni l’uso di segnali di comportamento digitale e dell’impronta sociale è stato presentato come la via per concedere credito a profili senza storico. Quella via si chiude per la valutazione del merito creditizio nel credito ai consumatori.

Ma la conseguenza che richiede davvero lavoro tecnico è un’altra, e non è scritta: le variabili proxy. Un modello può non usare dati sanitari e tuttavia includere variabili che li prevedono con alta correlazione — schemi di spesa in farmacia, tipo di esercizio, frequenza di determinate categorie —. Formalmente il dato vietato non viene usato; nella sostanza entra nella decisione. Depurare un modello da questi proxy non è una verifica documentale: è un esercizio statistico da svolgere sulle variabili reali e da documentare.

Quell’analisi, inoltre, serve due volte. È ciò che la CCD2 richiede in materia di dati ed è anche, in buona misura, ciò che il Regolamento sull’IA chiede sotto il titolo di governance dei dati per i sistemi ad alto rischio. Conviene farla una volta sola e sfruttarla per entrambi i fascicoli.

La classificazione non ammette discussioni: la valutazione del merito creditizio delle persone fisiche è espressamente nell’allegato III, nella categoria dell’accesso ai servizi essenziali. Un finanziatore che usi un sistema di intelligenza artificiale per decidere le concessioni sta operando un sistema ad alto rischio, con tutto ciò che questo comporta.

Vale la pena soffermarsi su due degli obblighi, perché sono quelli più spesso fraintesi. La sorveglianza umana non si soddisfa con un pulsante di annullamento che nessuno usa: la norma richiede una progettazione che consenta una sorveglianza effettiva, il che implica che chi sorveglia capisca l’output, abbia il tempo materiale per valutarlo e la capacità reale di discostarsene. E la conservazione delle registrazioni non è il log dell’applicazione: sono le tracce che permettono di ricostruire perché il sistema ha deciso ciò che ha deciso, in una specifica operazione, mesi dopo.

La buona notizia è che c’è una sovrapposizione con ciò che la CCD2 già richiede. Il percorso di intervento umano richiesto dalla direttiva sul credito è, in buona parte, la sorveglianza umana richiesta dal Regolamento sull’IA; e la tracciabilità che permette di spiegare un rifiuto è quella che permette di conservare le registrazioni. Progettarli separatamente raddoppia il lavoro. Se stai già lavorando sul Regolamento sull’IA per altra via, conviene incrociarlo con l’analisi del Regolamento sull’IA.

L’articolo 22 del GDPR riconosce all’interessato il diritto di non essere sottoposto a una decisione basata unicamente sul trattamento automatizzato che produca effetti giuridici che lo riguardano o che incida in modo analogo significativamente sulla sua persona. Rifiutare un credito rientra pienamente in questa ipotesi, ed è per questo che la maggior parte degli operatori ha già una posizione su questo tema.

Quello che cambia ora è che quella posizione va riesaminata alla luce delle altre due norme, perché lo standard si è alzato. Molti modelli si appoggiavano all’idea che la decisione non fosse «unicamente» automatizzata perché esisteva un riesame umano nominale. La CCD2 e il Regolamento sull’IA irrigidiscono quella lettura da due angolazioni: la prima riconosce un diritto espresso all’intervento umano, alla spiegazione e al riesame; il secondo richiede che la sorveglianza umana sia effettiva fin dalla progettazione. Un riesame puramente formale non regge più l’argomento.

Il risultato è che le tre norme convergono sullo stesso prodotto pratico, e conviene costruirlo una volta sola: un fascicolo della decisione per ogni operazione che raccolga quali dati sono entrati, quale output ha prodotto il sistema, chi lo ha riesaminato, che cosa ha sostenuto il cliente (se ha sostenuto qualcosa) e come è stata motivata la decisione finale. Quel fascicolo è allo stesso tempo la prova della conformità al GDPR, l’evidenza dell’intervento umano della CCD2 e la registrazione richiesta dal Regolamento sull’IA.

Due passaggi di quella tabella meritano attenzione perché sono quelli che generano più lavoro. Il primo è «l’adeguata considerazione degli obblighi in essere»: non basta conoscere i redditi, bisogna incorporare l’onere finanziario che il cliente già sostiene. Questo obbliga a stabilire da dove arriva quel dato — consultazione di banche dati, informazioni fornite, aggregazione di conti — e a documentare la scelta.

Il secondo è «in modo adeguato al volume delle operazioni». È una clausola di proporzionalità e conviene leggerla nelle sue due direzioni. Per un finanziatore piccolo significa che non gli verrà richiesta la macchina organizzativa di un grande operatore. Per uno grande significa esattamente il contrario: lo standard atteso cresce con il volume, per cui una procedura artigianale smette di essere difendibile oltre una certa dimensione. La proporzionalità non è sempre un sollievo.

Immagina la scena, perché è quella da risolvere: un cliente a cui è stato rifiutato il credito telefona e chiede perché. La risposta «non ha superato il nostro sistema di valutazione» non basta più. La direttiva riconosce il diritto a una spiegazione significativa e comprensibile, e quei due aggettivi hanno un contenuto preciso.

Significativa vuol dire che la spiegazione deve riferirsi ai fattori che hanno effettivamente pesato su quella decisione concreta, non a una descrizione generica del modello. Comprensibile vuol dire che deve essere nel linguaggio del cliente, non in quello del team rischi: parlare di «percentile della variabile anzianità lavorativa» non spiega nulla.

Questo richiede tre cose da costruire prima di ricevere la prima richiesta:

• Capacità tecnica di attribuzione. Il sistema deve poter dire quali fattori hanno spostato la decisione in quella operazione, non in media. Condiziona l’architettura del modello.
• Un catalogo di ragioni in linguaggio semplice. Traduzioni predisposte e verificate di ciascun fattore in una frase che un consumatore capisca, perché la spiegazione non dipenda da chi risponde alla telefonata.
• Un percorso di osservazioni e riesame. Dove entra ciò che il cliente porta, chi lo valuta e come si motiva la nuova decisione.

Conviene inoltre curare un limite: spiegare non è rivelare il modello. C’è un equilibrio tra il diritto del consumatore di capire la decisione e il legittimo interesse dell’operatore a non esporre il proprio sistema di valutazione al reverse engineering né alle frodi. Quell’equilibrio si risolve nella progettazione del catalogo di ragioni — abbastanza concrete da essere utili, abbastanza aggregate da non diventare un manuale su come ingannare il modello — e conviene motivarlo per iscritto.