L'algoritmo che ha negato la casa a donne nere — e cosa mi ha insegnato sul costruire un'IA che non può nascondersi

Ero seduto nel mio studio di casa un martedì sera, scorrendo i documenti definitivi dell'accordo transattivo in Louis et al. v. SafeRent Solutions, LLC, quando un singolo dettaglio mi ha bloccato di colpo.

Mary Louis e Monica Douglas — due donne nere titolari di voucher abitativi finanziati a livello federale — si erano viste negare gli appartamenti. Non da un padrone di casa che le aveva guardate negli occhi dicendo di no. Da un punteggio. Un numero compreso tra 200 e 800, generato da un algoritmo chiamato "Registry ScorePLUS", che aveva deciso che erano troppo rischiose per ricevere un alloggio. L'algoritmo non sapeva che erano nere. Non ne aveva bisogno. Sapeva solo che le loro storie creditizie assomigliavano alle storie creditizie di persone che erano state sistematicamente escluse dai sistemi finanziari per generazioni — e chiamava questo "rischio".

L'accordo transattivo è stato di 2,275 milioni di dollari. L'ingiunzione dura cinque anni. E la sentenza conteneva una frase che ho riletto tre volte perché non riuscivo a credere che un tribunale federale l'avesse davvero detta: se un padrone di casa si affida principalmente a un punteggio di IA di terze parti per prendere decisioni abitative, l'azienda che ha costruito il punteggio condivide la responsabilità ai sensi del Fair Housing Act.

Ho chiuso il portatile e sono rimasto lì al buio per un po'. Perché quella sentenza non ha solo cambiato il settore dello screening degli inquilini. Ha cambiato l'intero calcolo di ciò che significa costruire IA per i mercati regolamentati. E ha convalidato qualcosa che il mio team di Veriprajna sosteneva — a volte con investitori scettici, a volte fino allo sfinimento — da anni: che il modo in cui la maggior parte delle aziende impiega l'IA nelle decisioni ad alto rischio non è solo eticamente discutibile. È architetturalmente difettoso.

Cosa è andato realmente storto dentro l'algoritmo di SafeRent?

Il fallimento tecnico è ingannevolmente semplice da descrivere e maledettamente difficile da correggere senza ripensare l'intero approccio alla progettazione dei modelli.

Il sistema di scoring di SafeRent si basava pesantemente sulla storia creditizia tradizionale e sui debiti non legati alla locazione — cose come spese mediche, vecchi saldi di carte di credito, il tipo di cicatrice finanziaria che si accumula quando si passano anni a navigare nella povertà. Ciò che non considerava era il fatto più rilevante in assoluto sui suoi soggetti: i titolari di voucher per la scelta abitativa hanno un flusso di reddito garantito dal governo federale. Il loro affitto è sovvenzionato. La loro probabilità di saltare i pagamenti è, statisticamente, piuttosto diversa da ciò che suggerirebbe un punteggio di credito grezzo.

Ma il modello non lo sapeva. O più precisamente, nessuno gli aveva detto di preoccuparsene.

L'algoritmo non discriminava di proposito. Discriminava per progettazione — trattando dati storicamente distorti come verità neutra.

Ecco dove i numeri diventano schiaccianti. A ottobre 2021, il punteggio di credito mediano per i consumatori bianchi era 725. Per i consumatori ispanici, 661. Per i consumatori neri, 612. Quando costruisci un modello che tratta il punteggio di credito come predittore primario del "rischio di rendimento del contratto di locazione", non stai facendo una scelta matematica neutra. Stai codificando un secolo di redlining, prestiti predatori e disuguaglianza patrimoniale in un singolo peso di feature. L'algoritmo di SafeRent ha guardato la storia creditizia di Mary Louis e ha visto rischio. Ciò che avrebbe dovuto vedere era una donna con soldi d'affitto garantiti e un sistema che non le aveva mai dato una possibilità equa di costruirsi un credito.

Perché un tribunale ha stabilito che il fornitore del software è responsabile?

Questa è la parte che dovrebbe tenere sveglio la notte ogni fondatore di un'azienda di IA.

SafeRent ha provato la difesa ovvia: siamo un fornitore di tecnologia, non un padrone di casa. Non prendiamo decisioni abitative. Forniamo solo informazioni. Il tribunale ha respinto categoricamente questo argomento. Il Dipartimento di Giustizia ha depositato una Dichiarazione di Interesse sostenendo che quando un padrone di casa esternalizza il proprio processo decisionale a un algoritmo, lo sviluppatore di quell'algoritmo è funzionalmente parte della catena decisionale.

Pensate per un momento a cosa significa. Ogni azienda che vende scoring, screening, sottoscrizione o valutazione del rischio basati sull'IA in un mercato regolamentato ha appena perso la possibilità di dire "abbiamo solo costruito lo strumento".

Ricordo la conversazione con il mio co-fondatore la settimana dopo l'emissione della sentenza. Eravamo al telefono, presumibilmente per rivedere un deliverable per un cliente, e invece abbiamo passato quarantacinque minuti a mappare ogni settore in cui questo precedente poteva applicarsi. Scoring creditizio. Sottoscrizione assicurativa. Screening occupazionale. Triage sanitario. La lista continuava a crescere. A un certo punto uno di noi ha detto: "Questo non è un caso abitativo. Questo è l'inizio del diritto della responsabilità da prodotto per l'IA". Non stavamo festeggiando — avevamo messo in guardia proprio da questo scenario — ma c'era una cupa soddisfazione nel vedere il sistema giuridico finalmente mettersi in pari con ciò che la tecnologia stava facendo senza controllo.

L'accordo transattivo non è costato a SafeRent solo 2,275 milioni di dollari. Ha imposto un'ingiunzione quinquennale con i denti:

SafeRent non può più emettere raccomandazioni automatiche di approvazione o rifiuto per i titolari di voucher a meno che il modello non sia validato per l'equità da esperti indipendenti di diritti civili. Senza tale validazione, il sistema può fornire solo informazioni di background grezze — private del loro scoring predittivo. L'azienda deve inoltre formare i propri clienti sui limiti dei modelli di scoring per le popolazioni sovvenzionate. E questi termini si applicano a livello nazionale, non solo nel Massachusetts.

Per uno sguardo più approfondito sulla struttura dell'accordo e sulle sue implicazioni normative, ho scritto un'analisi interattiva del caso completo.

La trappola del wrapper LLM

Circa un anno prima che l'accordo SafeRent fosse finalizzato, ho avuto un incontro con un potenziale cliente — una società di gestione immobiliare di medie dimensioni che gestiva circa 12.000 unità in tutto il Sud-Est. Erano stati contattati da un fornitore che offriva una "soluzione di screening degli inquilini basata sull'IA" costruita su un large language model. La presentazione era accattivante: elaborazione del linguaggio naturale, riepiloghi istantanei del rischio, bellissime dashboard. Il fornitore aveva raccolto un round Series A. Avevano loghi sul loro sito web.

Ho fatto una sola domanda: "Il sistema può spiegare, per uno specifico candidato, quali feature hanno determinato la decisione di rifiuto in un modo che soddisfi i requisiti di notifica di azione avversa del Fair Credit Reporting Act?"

Silenzio. Poi: "Possiamo generare una spiegazione in linguaggio naturale della decisione".

"Generata dall'LLM?"

"Sì."

"Quindi la spiegazione è una narrazione plausibile del perché la persona è stata rifiutata, non una traccia causale verificata dell'effettivo calcolo del modello?"

Altro silenzio.

Questo è il problema centrale di ciò che io chiamo "wrapper LLM" — ed è il problema che il caso SafeRent ha illuminato in dettaglio brutale e costoso. Un Large Language Model può riassumere un contratto di locazione. Può redigere una lettera. Può persino produrre una spiegazione dal suono convincente del perché un candidato è stato respinto. Ma non può certificare che il suo ragionamento sia causalmente connesso all'effettivo percorso decisionale. Non può dimostrare che una caratteristica protetta non abbia influenzato l'esito. Non può cercare alternative meno discriminatorie. Allucina le spiegazioni nello stesso modo in cui allucina tutto il resto — predicendo il token successivo statisticamente più probabile.

Nelle decisioni ad alto rischio, la capacità di generare una risposta plausibile non vale nulla. La capacità di dimostrarne una equa vale tutto.

Ho avuto investitori che mi hanno detto: "Usa semplicemente GPT e aggiungici sopra uno strato di compliance". Uno me lo ha detto in faccia a un evento di pitch, come se fosse ovvio, come se stessimo complicando le cose. Avrei voluto porgergli i documenti dell'accordo SafeRent e chiedergli quale strato di compliance avrebbe intercettato un modello che ignorava sistematicamente il reddito da voucher. La risposta è nessuno. Perché il bias non era nella formattazione dell'output o nell'interfaccia utente. Era nei pesi delle feature. Era nei dati di addestramento. Era nell'architettura fondamentale di ciò che il modello era ottimizzato a predire.

In che modo le linee guida 2024 dell'HUD cambiano le carte in tavola?

A maggio 2024, l'HUD ha emesso linee guida che di fatto hanno codificato le lezioni del caso SafeRent in aspettative normative per l'intero settore abitativo. Lo standard è l'"impatto disparato" — il che significa che un sistema può essere illegale anche se nessuno intendeva discriminare, purché produca effetti negativi sproporzionati su una classe protetta che non possono essere giustificati da un interesse legittimo e non discriminatorio.

Spiccano tre requisiti:

La rilevanza delle feature deve essere causale, non solo correlazionale. Ogni dato in un modello di screening ha bisogno di un collegamento difendibile all'effettivo rendimento del contratto di locazione. "Il punteggio di credito predice l'insolvenza" non è sufficiente se il punteggio di credito è un proxy della razza e non hai verificato se il reddito corretto per il voucher sia un predittore migliore.

I candidati devono avere un percorso significativo per contestare i risultati dell'IA. Ciò significa che la revisione con l'essere umano nel ciclo non è opzionale — è obbligatoria. Un sistema che produce un punteggio senza meccanismo di ricorso è un sistema in attesa di essere citato in giudizio.

Gli sviluppatori devono cercare Alternative Meno Discriminatorie. Questa è la disposizione che cambia tutto. Non basta costruire un modello che funziona. Devi dimostrare di aver cercato modelli che funzionano altrettanto bene con un impatto discriminatorio minore — e o averli adottati o poter dimostrare che non ne esistono.

Quell'ultimo requisito — l'Alternativa Meno Discriminatoria, o LDA — è il punto in cui la maggior parte delle aziende di IA che ho visto crolla. Non perché la matematica sia impossibilmente difficile, ma perché non sono mai state costrette a farlo. Ottimizzano per l'accuratezza. Rilasciano. Vanno avanti. L'idea che si possa aver bisogno di cercare tra migliaia di configurazioni alternative del modello per trovarne una che mantenga le prestazioni massimizzando al contempo l'equità tra i gruppi demografici? Non è una richiesta di feature che la maggior parte dei product manager abbia mai ricevuto.

Cosa costruiamo realmente al suo posto

Devo essere onesto su una cosa: quando abbiamo iniziato a costruire sistemi consapevoli dell'equità in Veriprajna, abbiamo sbagliato.

Il nostro approccio iniziale era l'auditing a posteriori. Costruisci il modello, testalo per il bias, aggiusta le soglie se qualcosa sembrava sbagliato. Sembrava responsabile. Sembrava sufficiente. Non lo era.

Il problema con il post-processing è che stai cercando di correggere gli esiti senza comprenderne le cause. Puoi aggiustare una soglia decisionale in modo che i tassi di approvazione appaiano simili tra i gruppi — una tecnica chiamata "Equalized Odds" — ma se il modello sottostante ha appreso una rappresentazione distorta del rischio, stai solo mettendo del trucco su un problema strutturale. Il modello continua a pensare che certe persone siano più rischiose. Lo stai solo scavalcando all'ultimo miglio. E la prima volta che qualcuno controlla le importanze delle feature, il bias è proprio lì, che ti guarda.

La svolta — e uso quella parola con cautela, perché è sembrata più un lento e frustrante accumulo di fallimenti che un momento eureka — è arrivata quando abbiamo iniziato a trattare l'equità come un vincolo di ottimizzazione piuttosto che come un audit post-deployment.

Ecco cosa significa in pratica. Durante l'addestramento del modello, non ci limitiamo a minimizzare l'errore di predizione. Penalizziamo simultaneamente il modello se una rete "avversaria" secondaria può predire un attributo protetto (come razza o genere) a partire dagli output del modello primario. Se l'avversario ha successo — se può guardare le predizioni del modello e indovinare chi è nero e chi è bianco — il modello primario viene penalizzato e riaddestrato. Il risultato è un modello che è stato costretto ad apprendere feature genuinamente indipendenti dalle caratteristiche protette.

Abbiniamo questo a ciò che i ricercatori chiamano "test controfattuale". Per ogni candidato che il modello valuta, ci chiediamo: se la razza di questa persona fosse diversa ma tutto il resto rimanesse uguale, la decisione cambierebbe? Se la risposta è sì, il modello fallisce. Non "segnala per revisione". Fallisce.

L'equità controfattuale pone la domanda che ogni avvocato per i diritti civili prima o poi porrà: questa persona sarebbe stata approvata se fosse stata bianca? È meglio che il tuo modello abbia la stessa risposta.

C'è stata una notte — credo fosse intorno alle 2 di notte — in cui abbiamo eseguito il nostro primo audit controfattuale completo su un modello di screening prototipo che avevamo costruito usando un dataset di edilizia popolare. Ci aspettavamo forse una discrepanza del 3-4%. Il numero effettivo era più vicino all'11%. L'undici percento delle decisioni si sarebbe ribaltato se avessimo cambiato nient'altro che il gruppo demografico. Il mio ingegnere mi ha inviato un messaggio Slack che diceva solo: "Abbiamo un problema". Abbiamo passato le tre settimane successive a ricostruire da zero la pipeline delle feature, sostituendo il punteggio di credito con un indicatore composito che ponderava il reddito da voucher, la storia dei pagamenti diretti dell'affitto e la stabilità occupazionale. Il divario controfattuale è sceso sotto l'1%.

Questa è la differenza tra ciò che io chiamo "Deep AI" e un wrapper LLM. Non si tratta di avere prompt migliori o un'interfaccia più bella. Si tratta di se l'equità sia una proprietà dell'architettura del sistema o un adesivo che metti sulla scatola.

Per l'analisi tecnica completa del nostro approccio all'ingegneria dell'equità — inclusa la metodologia di debiasing avversariale e la formalizzazione matematica delle metriche che utilizziamo — vedi il nostro paper di ricerca sull'integrità algoritmica e il rischio d'impresa.

Perché non puoi semplicemente fare l'audit dopo il deployment?

La gente me lo chiede continuamente, e ne capisco l'attrattiva. L'auditing sembra più economico. Sembra meno dirompente. Costruisci in fretta, rilasci in fretta, controlli dopo, aggiusti ciò che si rompe.

Il problema è che nei mercati regolamentati, "ciò che si rompe" sono le vite delle persone.

Quando l'algoritmo di SafeRent è stato contestato in tribunale, era in funzione da anni. Quante Mary Louis c'erano che non hanno mai intentato una causa? Quante famiglie con voucher si sono viste negare un alloggio da un algoritmo che non riusciva a vedere oltre il loro punteggio di credito? Quei rifiuti non vengono annullati da un accordo transattivo. Quegli appartamenti sono andati a qualcun altro. Quelle famiglie hanno trovato un posto peggiore in cui vivere, o non hanno trovato nulla del tutto.

Gli audit statici mancano anche qualcosa di critico: il data drift. I pattern socioeconomici che un modello ha appreso durante l'addestramento cambiano nel tempo. I tassi di utilizzo dei voucher cambiano. Le metodologie di scoring creditizio evolvono. I mercati degli affitti si irrigidiscono o si allentano. Un modello che era "abbastanza equo" nel 2022 potrebbe essere discriminatorio nel 2024 — non perché qualcuno abbia cambiato il codice, ma perché il mondo è cambiato attorno ad esso.

Ecco perché ci siamo spostati verso il monitoraggio continuo con trigger di riaddestramento automatizzati. Il modello non viene semplicemente sottoposto ad audit una volta all'anno. Viene sottoposto ad audit ogni volta che prende una decisione, rispetto a una batteria di metriche di equità — Statistical Parity Difference, Disparate Impact Ratio, Equalized Odds — eseguite in tempo reale. Quando una qualsiasi metrica deriva oltre una soglia, il sistema la segnala prima ancora che un essere umano veda l'output.

La penso così: non costruiresti un ponte, lo ispezioneresti una volta e poi non lo controlleresti mai più. Lo monitoreresti continuamente per stress, fatica, cambiamenti ambientali. I sistemi di IA che prendono decisioni sull'alloggio, il credito e l'occupazione delle persone meritano almeno lo stesso rigore ingegneristico che dedichiamo al cemento e all'acciaio.

Cosa significa l'EU AI Act per le aziende americane?

Se l'accordo SafeRent e le linee guida dell'HUD rappresentano l'attuale pavimento normativo, l'EU AI Act — che avvia l'applicazione graduale nel 2025-2026 — rappresenta dove è diretto il soffitto.

L'Act classifica i sistemi di IA usati per lo scoring creditizio, lo screening degli inquilini e le decisioni occupazionali come "Ad Alto Rischio", sottoponendoli a valutazioni di conformità obbligatorie, requisiti di trasparenza e obblighi di supervisione umana. Le aziende americane che servono i mercati europei, o che servono i mercati americani in modi di cui i regolatori europei decidano di occuparsi, dovranno conformarsi.

Ma ecco cosa trovo più interessante dei requisiti specifici: l'EU Act rende operativi i quattro pilastri del NIST AI Risk Management Framework — Govern, Map, Measure, Manage — trasformandoli in obblighi giuridicamente vincolanti. Ciò che era linea guida volontaria diventa pratica obbligatoria. Le aziende che hanno allineato le loro architetture a questi principi in anticipo troveranno la conformità semplice. Le aziende che hanno trattato l'equità come una rivendicazione di marketing la troveranno costosa.

Ho visto questo pattern manifestarsi nella privacy dei dati (GDPR), nella rendicontazione finanziaria (SOX), e ora nella governance dell'IA. La traiettoria normativa si muove solo in una direzione. Costruire oggi per i requisiti di domani non è idealismo. È gestione del rischio.

Il problema della molteplicità dei modelli di cui nessuno parla

C'è un concetto nella ricerca sul machine learning chiamato "molteplicità dei modelli" — l'osservazione che per qualsiasi dataset dato, ci sono potenzialmente milioni di modelli che raggiungono un'accuratezza quasi identica ma hanno profili di equità radicalmente diversi. Alcuni di quei modelli sono profondamente distorti. Alcuni sono notevolmente equi. E senza una ricerca esplicita e sistematica di quelli equi, gli sviluppatori finiranno quasi sempre su qualunque modello l'ottimizzatore trovi per primo.

Questo è il fondamento tecnico del requisito dell'Alternativa Meno Discriminatoria, ed è il motivo per cui credo che la ricerca dell'LDA diventerà la singola capacità più importante nello sviluppo dell'IA regolamentata nel prossimo decennio.

Quando conduciamo una ricerca LDA, non stiamo addestrando un solo modello. Ne stiamo addestrando centinaia, variando gli insiemi di feature, le architetture, gli iperparametri e i vincoli di equità, per poi mappare l'intero panorama dei compromessi accuratezza-equità. L'obiettivo è trovare il modello che raggiunge l'obiettivo aziendale — predire il rendimento del contratto di locazione, valutare il rischio di credito, qualunque sia il compito — con il minimo impatto discriminatorio possibile.

A volte quella ricerca rivela qualcosa di scomodo: il modello "più accurato" è anche il più distorto, perché l'accuratezza e il bias storico sono correlati nei dati di addestramento. Il modello secondo per accuratezza potrebbe sacrificare mezzo punto percentuale di potere predittivo tagliando al contempo del 40% il divario del Disparate Impact Ratio. Vale la pena quel compromesso?

Se il tuo modello è lo 0,5% meno accurato ma il 40% meno discriminatorio, e hai scelto l'accuratezza — buona fortuna a spiegarlo a un giudice.

Nel caso SafeRent, la domanda fondamentale era se un modello avrebbe potuto predire il rendimento del contratto di locazione altrettanto bene senza penalizzare i titolari di voucher. La risposta, sulla base di tutto ciò che sappiamo sui dati, è quasi certamente sì. SafeRent semplicemente non ha mai cercato.

La notte in cui ho quasi accettato di costruire un wrapper

Voglio chiudere con una storia che non ho mai raccontato pubblicamente prima.

Circa diciotto mesi fa, siamo stati contattati da un'azienda — non la nominerò — che voleva che costruissimo uno strumento di screening di compliance per un importante cliente dei servizi finanziari. Il budget era considerevole. La tempistica era aggressiva. E la specifica che ci hanno consegnato era, in sostanza, un wrapper LLM: prendi un foundation model, mettilo a punto su documenti normativi, aggiungi uno strato di scoring, rilascialo.

Il mio team era diviso. Metà di loro vedeva il fatturato. L'altra metà vedeva il caso SafeRent al rallentatore. Abbiamo avuto una chiamata durata quasi tre ore. Uno dei miei ingegneri — qualcuno di cui mi fido profondamente — ha detto una cosa che mi è rimasta impressa: "Possiamo costruire ciò che chiedono in otto settimane. Possiamo costruire ciò di cui hanno bisogno in otto mesi. Se costruiamo ciò che chiedono, diventiamo il prossimo caso di studio sul perché questo approccio fallisce".

Ci siamo tirati indietro dall'accordo. È stata la decisione più costosa che abbia preso come fondatore. L'ho messa in dubbio per settimane.

Non la metto più in dubbio.

L'accordo SafeRent ha dimostrato che il mercato dell'IA nei settori regolamentati non è una corsa a rilasciare più velocemente. È una corsa a rilasciare nel modo più sicuro — dove "sicuro" significa architetturalmente equo, legalmente difendibile e progettato per resistere al tipo di scrutinio forense che un tribunale federale prima o poi applicherà. Le aziende che lo capiscono costruiranno i sistemi che durano. Le aziende che non lo capiscono costruiranno il prossimo monito da 2,275 milioni di dollari.

L'era della scatola nera è finita. Non perché i regolatori l'abbiano uccisa, ma perché non è mai stata costruita per sopravvivere al contatto con la realtà. La domanda non è se la tua IA possa prendere una decisione. È se la tua IA possa difenderne una.