Bias algoritmico: tipi, rilevamento e tecniche di mitigazione

Ora che l’intelligenza artificiale viene integrata in workflow ad alto impatto, come le decisioni sul credito, l’assegnazione del rischio clinico e la selezione del personale, il bias algoritmico è diventato un rischio operativo con conseguenze legali, etiche e reputazionali. Il modello applica un pattern appreso a una decisione che incide sull’accesso, sulle opportunità o sul trattamento.

Il bias algoritmico si verifica quando questi pattern appresi producono sistematicamente risultati iniqui per determinati gruppi. I problemi spesso hanno origine nei dati di addestramento, nelle etichette, nelle variabili proxy, nelle funzioni obiettivo o nel contesto di deployment, che determinano ciò che il modello apprende e come vengono utilizzati i suoi output. Le organizzazioni hanno bisogno di governance dei dati, valutazione dei modelli, monitoraggio e responsabilità umana per comprendere dove il bias entra nel sistema e quali controlli possono ridurne l’impatto. Queste pratiche sono fondamentali per l’AI responsabile, in cui i sistemi vengono progettati, valutati e governati tenendo conto di equità, responsabilità e gestione dei rischi.

Il bias algoritmico è un errore sistematico in un sistema di AI o di machine learning (ML) che crea vantaggi o svantaggi ingiusti per determinati gruppi. Il gruppo interessato dalla distorsione può essere definito da un attributo protetto, come razza, genere, età o disabilità, ma il bias può manifestarsi anche attraverso una variabile proxy che funge da sostituto di un attributo protetto, come il codice postale, la scuola frequentata, il profilo di reddito, i costi sanitari o la storia lavorativa.

È diverso dall’errore casuale, in cui gli errori sono distribuiti in modo approssimativamente uniforme tra i gruppi. Un modello antifrode che non rileva transazioni con tassi simili in tutti i segmenti di clientela può presentare un problema di accuratezza, ma non necessariamente di equità. Un modello che produce tassi di falsi positivi più elevati per un sottogruppo, anche quando l’accuratezza complessiva sembra accettabile, solleva una preoccupazione diversa: la metrica media nasconde problemi di prestazioni legati allo specifico sottogruppo.

Il bias algoritmico è anche un concetto più ampio del bias statistico, un termine tecnico che indica generalmente la differenza tra il valore atteso di uno stimatore e il valore reale che cerca di stimare. Nell’AI applicata, il bias algoritmico comprende il contesto sociale e operativo del modello: ciò che rappresentano i dati di training, ciò che misurano le etichette, l’obiettivo ottimizzato dal modello e il modo in cui le persone utilizzano l’output.

Il bias può essere intenzionale, non intenzionale o emergente. Un modello può riflettere una regola discriminatoria intenzionale, ma più spesso apprende da dati storici plasmati da un accesso disomogeneo, misurazioni incoerenti o processi istituzionali che non sono mai stati progettati per il riutilizzo algoritmico. Ad esempio, una tabella contenente le decisioni di assunzione passate può sembrare un insieme di dati aziendali neutrali. Ma se viene utilizzata da un modello per prendere nuove decisioni di assunzione, il modello può replicare disparità derivanti da precedenti reti di recruiting, prassi di promozione o criteri di selezione che hanno favorito alcuni candidati rispetto ad altri. È un esempio di bias involontario. In altri casi, il bias può emergere anche in assenza di input distorti o regole esplicite, quando le interazioni tra variabili producono risultati sistematicamente disomogenei.

Il bias algoritmico può entrare in quasi ogni fase del ciclo di vita dell’AI, dalla raccolta dei dati fino alla distribuzione del modello. Le organizzazioni devono poter identificare non solo se il modello contiene un bias, ma anche da dove ha origine e quali controlli possono adottare.

Bias storico

Il bias storico si manifesta quando i dati di training riflettono discriminazioni o trattamenti iniqui del passato. Un modello di concessione dei prestiti addestrato sui dati storici relativi all’approvazione dei mutui può apprendere pattern influenzati da precedenti pratiche discriminatorie nell’accesso al credito, dalle disparità patrimoniali o dai criteri di valutazione del merito creditizio utilizzati in passato. Anche se gli attributi protetti vengono rimossi, variabili correlate come il quartiere, la stabilità del reddito o la storia creditizia possono preservare il pattern.

Questo è importante perché una previsione storica “accurata” non equivale sempre a un processo decisionale equo per il futuro. Un modello può apprendere fedelmente il passato e produrre comunque risultati che un’organizzazione non dovrebbe ripetere.

Bias di rappresentazione

Il bias di rappresentazione si verifica quando alcuni gruppi sono sottorappresentati nei dati di training. Quando un modello vede meno esempi relativi a un sottogruppo, in genere dispone di meno informazioni per apprendere i pattern applicabili a quel sottogruppo.

I sistemi di analisi facciale offrono un esempio noto. Nello studio “Gender Shades”, le ricercatrici Joy Buolamwini e Timnit Gebru hanno rilevato che i sistemi commerciali di classificazione del genere ottenevano risultati molto migliori sugli uomini con la pelle più chiara rispetto alle donne con la pelle più scura, con i tassi di errata classificazione più elevati proprio per queste ultime.

Queste disparità di accuratezza possono diventare particolarmente dannose quando il riconoscimento facciale viene utilizzato dalle forze dell’ordine: A Detroit, Porcha Woodruff, una donna nera incinta di otto mesi, è stata arrestata dopo che la tecnologia di riconoscimento facciale l’aveva indicata come possibile corrispondenza nell’indagine su un furto d’auto; il caso è stato successivamente archiviato.

Bias di misurazione

Il bias di misurazione si verifica quando una variabile o un’etichetta non misura realmente il concetto che dovrebbe rappresentare. I tassi di arresto, ad esempio, non misurano i tassi di criminalità. Riflettono anche i modelli di previsione del rischi di reati, le pratiche di denuncia e le priorità di applicazione della legge. La spesa sanitaria non misura il bisogno di assistenza sanitaria. Riflette l’accesso alle cure, la copertura assicurativa, la capacità di pagare e il comportamento nella ricerca di assistenza.

Questa distinzione era centrale in uno studio pubblicato nel 2019 su Science da Ziad Obermeyer e coautori, che ha rilevato un bias razziale in un algoritmo di rischio sanitario ampiamente utilizzato, perché il modello impiegava i costi sanitari come indicatore indiretto del bisogno di assistenza sanitaria. A parità di punteggio di rischio, i pazienti neri erano spesso più malati dei pazienti bianchi, perché l’accesso iniquo alle cure aveva fatto sì che storicamente venisse speso meno denaro per la loro assistenza.

Bias di aggregazione

Il bias di aggregazione si manifesta quando un unico modello viene applicato a popolazioni eterogenee, anche se i diversi sottogruppi presentano pattern di base differenti. Un singolo modello clinico, ad esempio, può fornire prestazioni scarse se i biomarcatori, il rischio di base o la manifestazione della malattia differiscono tra gruppi etnici, fasce d’età o contesti assistenziali.

Il problema non è che ogni sottogruppo abbia bisogno di un modello separato. Il problema è che le organizzazioni devono verificare se il modello condiviso è adatto alla popolazione a cui viene applicato. Senza una valutazione per sottogruppi, il modello può sembrare accettabile in media, pur fallendo per le persone meno rappresentate nell’aggregato.

Bias di valutazione

Il bias di valutazione si verifica quando i benchmark o i dati di test non riflettono la popolazione di distribuzione. Un modello addestrato e testato sulla popolazione di pazienti di un singolo ospedale, sul gruppo di candidati di un singolo datore di lavoro o sui dati finanziari di una singola regione può mostrare ottimi risultati di convalida e comportarsi poi diversamente quando viene distribuito altrove.

Per questo la valutazione del modello deve includere segmentazioni specifiche del contesto di deployment. Un modello antifrode addestrato su una sola linea di prodotti, ad esempio, non dovrebbe essere valutato esclusivamente in base a precision e recall globali se verrà utilizzato in regioni, segmenti di clientela e canali di transazione diversi, caratterizzati da pattern comportamentali differenti.

Bias di distribuzione

Il bias di distribuzione si verifica quando un modello viene utilizzato in un contesto diverso da quelli per cui è stato progettato. Un punteggio di rischio clinico sviluppato per supportare il workflow di allocazione delle risorse di un ospedale potrebbe non funzionare allo stesso modo in un altro ospedale con dati demografici dei pazienti, pratiche di codifica o percorsi assistenziali differenti.

L’output del modello può essere tecnicamente corretto nel contesto originale, ma fuorviante in uno nuovo. Per questo le decisioni sulla distribuzione richiedono una documentazione che specifichi: uso previsto, usi esclusi, popolazione di training, popolazione di convalida, limitazioni note e revisione umana obbligatoria.

Bias del ciclo di feedback

Il bias del ciclo di feedback si verifica quando gli output del modello influenzano i dati utilizzati per addestrare o aggiornare i modelli futuri. Il predictive policing è l’esempio classico: se un modello invia più agenti di polizia in un quartiere, è possibile che vi vengano registrati più incidenti, rafforzando la convinzione del modello che l’area presenti un rischio maggiore.

Lo stesso pattern può comparire nella prevenzione delle frodi, nella concessione dei prestiti, nelle assunzioni e nell’assistenza sanitaria. Un modello che indirizza un numero inferiore di candidati, clienti o pazienti verso un processo può ridurre i dati futuri disponibili su questi gruppi, rendendo la versione successiva del sistema ancora meno affidabile per loro.

Il rilevamento del bias parte dai dati e prosegue con la valutazione del modello, il monitoraggio della distribuzione e l’audit. Un modello può superare i test standard delle prestazioni e creare comunque un impatto disomogeneo se i team non misurano i risultati tra i gruppi rilevanti.

L’analisi delle prestazioni per sottogruppo è la base di partenza. I team confrontano accuratezza, precision, recall, tassi di falsi positivi, tassi di falsi negativi e calibrazione tra segmentazioni demografiche o altri segmenti rilevanti. Per un modello di selezione del personale, potrebbe significare confrontare i tassi di selezione in base a genere, etnia e fascia d’età. Per un modello clinico, potrebbe significare misurare il recall tra ospedali, tipologie di assicurazione, gruppi linguistici o sottotipi di malattia.

Si usano comunemente diverse metriche di equità dell’AI:

• Parità demografica: Un modello soddisfa il criterio della parità demografica quando i tassi di previsione positiva sono simili tra i gruppi. In una selezione del personale, ciò significa che i diversi gruppi avanzano nelle fasi del processo a tassi simili. Questa metrica può essere utile per rilevare un impatto differenziato, ma non considera le differenze nella distribuzione sottostante delle qualifiche o del rischio.
• Pari opportunità ed equalized odds: Il criterio delle pari opportunità si concentra sull’uguaglianza dei tassi di veri positivi tra i gruppi. Il criterio degli equalized odds estende questo principio ai tassi di veri positivi e di falsi positivi. Queste metriche sono spesso utili quando il costo di un vero positivo mancato o di un falso allarme varia tra i gruppi.
• Calibrazione all’interno dei gruppi: Un modello è calibrato all’interno dei gruppi quando una probabilità prevista ha lo stesso significato per ciascun gruppo. Se a due persone candidate viene assegnata una probabilità di rimborso pari a 0,8, il tasso di rimborso osservato dovrebbe essere simile tra i gruppi. La calibrazione è particolarmente importante nel calcolo del rischio, in cui l’output viene utilizzato come probabilità anziché come semplice decisione sì/no.
• Equità controfattuale: l’equità controfattuale valuta se la previsione del modello cambierebbe qualora cambiasse un attributo protetto e la struttura causale rilevante rimanesse invariata. Questo approccio è concettualmente potente, ma richiede ipotesi causali formulate con attenzione e non può essere ridotto a una semplice metrica di dashboard.

Anche le metriche di equità comportano compromessi. Gli studi di Alexandra Chouldechova e Jon Kleinberg et al. hanno dimostrato che i criteri di equità comuni non possono essere soddisfatti tutti contemporaneamente, se non in condizioni limitate, soprattutto quando i tassi di base differiscono tra i gruppi. Ciò significa che il rilevamento del bias non è soltanto un esercizio di valutazione tecnica: le organizzazioni devono decidere quali criteri di equità siano adeguati al contesto decisionale, ai requisiti legali e ai danni che intendono ridurre.

Gli strumenti possono rendere ripetibile questo lavoro. AI Fairness 360 (AIF360) è un toolkit open source, sviluppato inizialmente dalla divisione di ricerca IBM, per esaminare, documentare e mitigare il bias durante l’intero ciclo di vita del machine learning. Fairlearn aiuta chi sviluppa e gestisce sistemi di AI a valutare e mitigare i problemi di equità, anche mediante metriche e algoritmi di mitigazione. What-If Tool di Google e PAIR consente ai team di testare il comportamento dei modelli su input, sottoinsiemi e metriche di equità diversi. Gli strumenti di attribuzione delle variabili, come SHAP, aiutano inoltre a esaminare quali variabili influenzano le previsioni, anche se l’importanza delle feature, da sola, non dimostra l’equità.

La mitigazione dipende dal punto in cui il bias entra nel sistema. Alcuni problemi richiedono modifiche ai dati, altri modifiche al modello, altri ancora modifiche alle soglie o alle policy, mentre in alcuni casi serve una valutazione organizzativa prima di poter utilizzare il modello.

Interventi di pre-processing

Le tecniche di pre-processing modificano i dati di training prima del training del modello. I team possono riassegnare i pesi agli esempi affinché i gruppi sottorappresentati abbiano maggiore influenza, ricampionare i dati per bilanciare la rappresentazione dei sottogruppi, utilizzare la data augmentation per aggiungere esempi dei gruppi sottorappresentati o apprendere rappresentazioni più eque che riducano la capacità del modello di codificare attributi protetti.

Queste tecniche sono utili quando il data set è sbilanciato o alcuni gruppi sono scarsamente rappresentati, ma non risolvono ogni problema. Se l’etichetta è di per sé distorta, ricampionare la tabella non corregge il significato della variabile target.

Interventi di in-processing

Le tecniche di in-processing modificano il training del modello. Un team può aggiungere vincoli di equità alla funzione di perdita, utilizzare il debiasing avversario per ridurre il segnale degli attributi protetti nelle rappresentazioni apprese oppure adottare un approccio basato sulle reductions, che trasforma l’apprendimento vincolato all’equità in una sequenza di problemi di classificazione sensibili ai costi.

Questi metodi sono utili quando l’equità deve essere ottimizzata insieme all’accuratezza durante il training. Richiedono inoltre che i team scelgano esplicitamente un vincolo di equità, perché ottimizzare la parità demografica può produrre un comportamento diverso rispetto all’ottimizzazione delle pari opportunità.

Interventi di post-processing

Le tecniche di post-processing modificano gli output del modello dopo il training. Un team può regolare la soglia per ciascun gruppo per uniformare determinati tassi di errore oppure applicare una tecnica di post-processing basata sulle calibrated equalized odds, modificando le previsioni senza compromettere alcuni aspetti della calibrazione.

Questi metodi sono pratici quando un modello è già stato addestrato o quando i team non hanno accesso all’intera pipeline di training. Richiedono inoltre un’attenta governance, perché soglie diverse per ciascun gruppo possono sollevare questioni giuridiche, etiche e di comunicazione a seconda del settore.

Interventi sulla pipeline di dati

Molti problemi di bias sono problemi della pipeline di dati. I team possono dover correggere le etichette, migliorare le pratiche di raccolta, documentare il data lineage, verificare le variabili proxy oppure aggiungere gli attributi mancanti dei sottogruppi per eseguire test con accesso controllato. Una tabella utilizzata per il training del modello dovrebbe indicare l’origine dell’etichetta, le trasformazioni applicate per ottenere ogni variabile, le modalità di monitoraggio dell’aggiornamento dei dati e i responsabili della gestione delle eccezioni relative alla qualità.

Se i team non possono risalire dalla variabile alla sua origine, stabilire se è stato utilizzato un attributo protetto o una variabile proxy oppure riprodurre i dati di training utilizzati per una versione del modello, non possono spiegare o mitigare il bias in modo affidabile.

Interventi organizzativi

La mitigazione del bias dipende anche dal coinvolgimento delle persone. Team di revisione diversificati, consultazione degli stakeholder, revisione etica dell’AI, dichiarazioni sull’impatto del bias e percorsi di escalation aiutano le organizzazioni a valutare danni che non emergono dalle sole metriche del modello.

Per i sistemi ad alto impatto, i team dovrebbero documentare l’uso previsto, le popolazioni interessate, i limiti noti, i criteri di equità, le decisioni di mitigazione e il piano di monitoraggio. L’obiettivo non è sostenere che il bias sia stato eliminato. L’obiettivo è dimostrare che l’organizzazione ha identificato rischi plausibili, li ha sottoposti a test, ha scelto controlli appropriati e ha conservato le evidenze necessarie per la revisione.

Le autorità di regolamentazione si aspettano sempre più che le organizzazioni dimostrino come testano, documentano e sottopongono a governance le decisioni algoritmiche, soprattutto nei settori dell’del lavoro, del credito, degli alloggi, dell’assistenza sanitaria, dell’istruzione e in altri ambiti ad alto impatto.

L’AI Act dell’Unione europea richiede che i sistemi di AI ad alto rischio che utilizzano dati di training, convalida e test rispettino i requisiti di governance e qualità dei dati. L’articolo 10 disciplina la raccolta e la preparazione dei dati, la loro pertinenza e rappresentatività, gli errori, la completezza, il bias e la finalità prevista del sistema.

Negli Stati Uniti, le leggi antidiscriminazione esistenti continuano ad applicarsi quando una decisione è algoritmica. L’Equal Credit Opportunity Act, Titolo VII e il Fair Housing Act possono applicarsi quando i sistemi automatizzati influenzano decisioni relative al credito, all’occupazione o agli alloggi. L’Equal Credit Opportunity Act, Titolo VII e il Fair Housing Act possono applicarsi quando i sistemi automatizzati incidono sulle decisioni relative al credito, all’occupazione o agli alloggi.

Le normative statali e locali più recenti introducono requisiti più espliciti di governance dell’AI. La Local Law 144 della città di New York vieta a datori di lavoro e agenzie per l’impiego di utilizzare strumenti automatizzati per le decisioni relative all’occupazione, a meno che lo strumento non sia stato sottoposto a un audit del bias entro un anno, le informazioni sull’audit non siano disponibili al pubblico e siano state fornite le comunicazioni richieste a candidate, candidati o dipendenti. In Italia, le indicazioni di AgID sull’AI richiamano esplicitamente la necessità di individuare e mitigare i bias nei sistemi, valutando le possibili distorsioni nei dati di input, nel modello e negli output, nonché la rappresentatività dei dati utilizzati. Il quadro italiano rafforza inoltre l’attenzione verso il rischio di discriminazione algoritmica e la necessità di garantire sistemi di AI affidabili e soggetti a un’adeguata governance. L’AI Act del Colorado richiede a sviluppatori e deployer di sistemi di AI ad alto rischio di adottare una diligenza ragionevole per proteggere i consumatori dai rischi noti o ragionevolmente prevedibili di discriminazione algoritmica, con requisiti in vigore dal 1° febbraio 2026.

Per le organizzazioni, i requisiti di conformità all’AI indicano lo stesso modello operativo: valutazioni d’impatto, audit del bias, evidenze delle azioni sfavorevoli, documentazione dei modelli, monitoraggio e responsabilità chiare per le decisioni che influenzano le persone.

La mitigazione del bias algoritmico e la gestione del rischio dipendono da una data foundation governata per dati e AI. I team devono sapere quali dati sono stati utilizzati per il training, quali colonne possono contenere attributi protetti o variabili proxy, quali trasformazioni sono state applicate per ottenere le variabili del modello, quale versione del modello ha prodotto un determinato output e quali controlli limitano l’esposizione ai dati sensibili.

Snowflake offre funzionalità che supportano questo flusso di lavoro all’interno dell’AI Data Cloud. Snowflake Horizon Catalog aiuta le organizzazioni a classificare i dati sensibili, applicare tag, applicare il controllo degli accessi, proteggere i campi sensibili con il mascheramento dinamico dei dati e applicare policy di accesso righe. Questi controlli sono utili per i flussi di lavoro di audit del bias, perché gli attributi protetti spesso devono essere disponibili per test controllati, pur rimanendo soggetti a restrizioni per lo sviluppo generale dei modelli o per l’uso aziendale.

Snowpark ML e Cortex AI supportano i flussi di lavoro di rilevamento del bias direttamente sui dati di training, convalida e inferenza in Snowflake, inclusi, ove appropriato, i flussi di lavoro che utilizzano librerie open source come Fairlearn o AIF360. Mantenere queste attività vicino ai dati governati aiuta a ridurre lo spostamento non necessario di attributi sensibili, previsioni e output di valutazione.

Snowflake Model Registry consente ai team di gestire modelli e metadati associati in Snowflake, mentre la relativa API supporta metriche collegate alle versioni dei modelli. I team possono registrare nei log le metriche dei sottogruppi insieme alle metriche standard delle prestazioni, così una versione del modello non viene valutata solo in base all’accuratezza aggregata o al punteggio F1. Snowflake ML Observability supporta inoltre il monitoraggio dei modelli in produzione lungo dimensioni come prestazioni, drift e volume.

La cronologia degli accessi, le policy di mascheramento e le policy di mascheramento basato su tag possono contribuire a preservare l’auditabilità limitando al contempo l’esposizione. Snowflake Access History registra operazioni come gli aggiornamenti delle policy e le modifiche ai tag, mentre le policy di mascheramento basato su tag possono proteggere automaticamente le colonne contrassegnate con tag che contengono dati sensibili. Per la governance del bias, ciò significa che i team possono applicare controlli agli oggetti di dati utilizzati nei flussi di lavoro di AI, tracciare chi ha avuto accesso agli attributi sensibili e conservare le prove per le revisioni dei modelli, gli audit e le richieste delle autorità di regolamentazione.

Il bias algoritmico viene spesso rilevato negli output del modello, ma di solito ha origine molto prima: nella tabella selezionata per il training, nell’etichetta scelta come ground truth, in una variabile proxy apparentemente adeguata, in un benchmark che non include un determinato sottogruppo o nel contesto di utilizzo, se questo cambia dopo la convalida. Affrontare questi rischi richiede accountability algoritmica, che consenta alle organizzazioni di risalire dalle decisioni ai dati, ai modelli e ai processi e di dimostrare come sono stati prodotti e governati i risultati.

Ridurre il bias richiede dati governati, data lineage documentato, accesso controllato agli attributi protetti, valutazione dei sottogruppi, evidenze relative alle versioni dei modelli, monitoraggio e un processo di revisione in grado di collegare i risultati tecnici alle decisioni legali, etiche e operative. In questo senso, la mitigazione del bias algoritmico non consiste in una correzione una tantum del modello. È una pratica di governance dell’AI che segue il sistema dalla raccolta dei dati fino al deployment e all’audit.