OECD AI Incidents Monitor — Il Catasto Mondiale degli Incidenti AI

Cos'è: L'AI Incidents Monitor (AIM) è un database pubblico mantenuto dall'OECD Working Party on AI Governance, lanciato a novembre 2023. Raccoglie e cataloga eventi reali di danno o malfunzionamento di sistemi AI sulla base di una tassonomia standardizzata, con l'obiettivo di costruire una base empirica condivisa per il risk management. A fine 2024 il monitor aveva superato i 7000 incidenti registrati, dai deepfake elettorali ai bias dei sistemi HR fino agli errori di diagnosi medica. È pensato come equivalente AI del National Transportation Safety Board statunitense — un registro pubblico che permette analisi sistemiche dei pattern di fallimento.

Perché serve un NTSB per l'AI

L'analogia con il National Transportation Safety Board non è retorica. Il NTSB è l'agenzia federale americana indipendente che investiga ogni incidente aviazione, ferroviario, marittimo o di trasporto stradale di rilevanza pubblica negli USA. Pubblica report dettagliati con root cause analysis, raccomandazioni di safety, e statistiche aggregate accessibili a chiunque. Il valore istituzionale del NTSB sta nel produrre conoscenza condivisa sui fallimenti — non per attribuire colpa ma per migliorare sistematicamente la safety del settore.

Nel settore AI questo tipo di infrastruttura informativa non esisteva fino al 2023. Esistevano database parziali — il celebre AI Incident Database mantenuto dalla Partnership on AI dal 2018, la Awful AI list su GitHub, raccolte giornalistiche di episodi isolati — ma nessuno con la copertura sistematica, la tassonomia formalizzata, e l'autorità istituzionale di un registro ufficiale. L'OECD ha colmato questo vuoto sfruttando la propria posizione: 38 paesi membri, autorità riconosciuta nella governance economica, e una rete di policy network già attiva sull'AI dal 2018 con l'adozione degli AI Principles.

L'AI Incidents Monitor è strutturato esplicitamente come public good per il risk management. Non emette giudizi di responsabilità, non irroga sanzioni, non determina liability. Si limita a documentare ciò che è accaduto in forma comparabile, lasciando ai regolatori, agli assicuratori, agli sviluppatori e ai ricercatori il compito di trarne conclusioni operative. Questa neutralità è il prezzo necessario per ottenere cooperazione internazionale — paesi e aziende contribuiscono dati e segnalazioni solo se il monitor non viene usato contro di loro.

La tassonomia: cosa conta come "incidente AI"

Il problema definitorio più difficile per qualsiasi registro di incidenti è stabilire cosa qualifichi come "incidente". L'OECD ha lavorato due anni con un working group multistakeholder per articolare una tassonomia operativa, pubblicata nel 2023 e iterata nel 2024. La definizione di base: un AI incident è un evento in cui lo sviluppo, dispiegamento o utilizzo di un sistema AI ha causato o concorso a causare danno reale, includendo danni a persone, a proprietà, all'ambiente, o ai diritti fondamentali (privacy, non discriminazione, accesso a servizi).

La tassonomia distingue tre categorie principali. Primo: AI incidents propriamente detti — eventi in cui un danno è effettivamente avvenuto. Secondo: AI hazards — situazioni in cui il danno è potenziale ma non ancora materializzato, ad esempio un bias scoperto in fase di audit prima del deployment. Terzo: AI disruptions — eventi in cui un sistema AI ha causato interruzioni significative di servizi o operazioni anche senza danno diretto a persone.

Per ciascun incidente registrato il monitor cattura attributi standardizzati: settore applicativo (sanità, finanza, sicurezza pubblica, media, ecc.), tecnologia coinvolta (computer vision, NLP, sistemi di raccomandazione, generative AI), tipologia di danno (fisico, economico, reputazionale, ai diritti), gruppi colpiti (con attenzione a fasce demografiche vulnerabili), area geografica, severità stimata, e link a fonti pubbliche verificabili. Questo livello di strutturazione consente analisi quantitative impossibili sui database precedenti.

Cosa emerge dai 7000+ eventi tracciati

L'analisi aggregata dei dati al dicembre 2024 produce pattern leggibili. Il settore più colpito in termini assoluti è quello dei media e dell'informazione — guidato dall'esplosione dei deepfake nel ciclo elettorale 2024, particolarmente intenso in India, Stati Uniti, Indonesia, Brasile e Unione Europea. Solo i deepfake politici tracciati rappresentano circa il 18% degli incidenti totali del 2024, con concentrazione nei mesi pre-elettorali e con un pattern di diffusione che dimostra come le piattaforme social rimangano il vettore di propagazione principale.

Il secondo settore per volume di incidenti è quello dell'occupazione — sistemi automatizzati di screening dei CV, di scoring per assunzioni, di monitoraggio della produttività dei lavoratori. Casi paradigmatici inclusi nel monitor includono l'algoritmo di selezione di Amazon poi ritirato per bias di genere, lo scandalo dei sistemi HR olandesi che hanno discriminato cittadini con doppia cittadinanza, le contestazioni sui sistemi di workforce management nel settore delivery e logistica. Il pattern emerge: i sistemi HR vengono dispiegati su scala prima che siano validati su gruppi demografici eterogenei, e i bias vengono scoperti retroattivamente attraverso class action o investigation giornalistiche.

Il terzo settore è la sanità, con un pattern qualitativamente diverso. Gli incidenti sanitari sono numericamente meno frequenti ma individualmente più severi: errori di diagnosi assistita dall'AI, sistemi di triage che hanno deprioritizzato pazienti afroamericani, modelli predittivi di sepsi con tassi di falso negativo problematici. Il caso Epic Sepsis Model, ampiamente documentato in letteratura scientifica e nel monitor, è diventato il riferimento canonico per come un sistema AI con buone metriche di accuracy aggregate possa avere performance pratiche molto peggiori in deployment reale.

Integrazione con l'AI Risk Repository del MIT

Nel 2024, l'OECD ha annunciato una integrazione tecnica e metodologica tra AI Incidents Monitor e l'AI Risk Repository sviluppato dal MIT Sloan e dal MIT Computer Science and Artificial Intelligence Laboratory. Il Risk Repository è un'iniziativa parallela che ha tentato di consolidare la letteratura accademica sui rischi AI in una tassonomia unificata, a partire dall'analisi di oltre 40 framework di risk classification precedenti.

L'integrazione funziona così: la tassonomia tecnica dei rischi del MIT — strutturata in sette categorie principali (Discrimination, Privacy, Misinformation, Malicious Use, Human-Computer Interaction, Socioeconomic, AI System Safety) e oltre sessanta sottocategorie — viene usata come backend di classificazione per gli incidenti registrati nel monitor OECD. Quando un nuovo incidente viene inserito, viene mappato non solo alle categorie OECD (settore, tecnologia, danno) ma anche alle categorie di rischio MIT, producendo una vista incrociata utilizzabile per analisi epidemiologiche.

Il valore di questa integrazione è metodologico. Permette di rispondere a domande del tipo: "Quale categoria di rischio identificata dalla letteratura accademica si sta materializzando con maggiore frequenza nel mondo reale?", o "Quali rischi documentati teoricamente non hanno ancora prodotto incidenti osservabili (e quindi sono ancora ipotetici o sono sotto-osservati)?". La triangolazione tra letteratura tecnica, monitoring empirico, e response regolatoria è precisamente ciò che permette al policy work di passare da reattivo a proattivo.

I limiti: sotto-segnalazione, definizione, applicabilità aziendale

Il monitor ha limiti strutturali significativi che ne condizionano l'uso. Il primo è la sotto-segnalazione sistemica. La maggior parte degli incidenti AI non viene scoperta o non viene riportata pubblicamente. Aziende che usano sistemi AI internamente raramente pubblicizzano i casi in cui il sistema ha sbagliato — sia per ragioni reputazionali sia perché spesso l'errore non viene neppure ricondotto al sistema AI specifico, restando nelle statistiche generali di operational error. Il monitor copre principalmente eventi che hanno raggiunto la stampa o sono stati oggetto di investigation pubblica, con un bias verso paesi anglofoni e verso settori ad alta visibilità.

Il secondo limite è definitorio. La distinzione tra "il sistema AI ha causato il danno" e "il sistema AI ha concorso al danno insieme a fattori organizzativi e umani" è raramente netta. Un sistema HR biased viene usato da un manager umano che approva o respinge candidati: la responsabilità è del sistema, del manager, del processo di validazione che non ha intercettato il bias, o di tutti questi attori insieme? L'AIM cataloga l'incidente ma non risolve l'attribuzione — la lascia agli investigatori e ai giuristi del caso specifico.

Il terzo limite riguarda l'applicabilità aziendale. Per un'azienda che dispiega AI, l'AIM è utile come fonte di awareness e benchmarking, ma non sostituisce un risk management process interno. Le statistiche aggregate possono informare la priorizzazione dei controlli — se i bias HR sono diffusi nel settore, mettere risorse sull'audit dei sistemi di selezione è ragionevole — ma le decisioni operative richiedono analisi specifiche del proprio caso d'uso, dei propri dati di training, e dei propri utenti. Il monitor è infrastruttura informativa di settore, non strumento di compliance individuale. Per i risk officer aziendali la lettura più utile è probabilmente quella longitudinale: osservare quali categorie di incidenti stanno crescendo nel tempo per anticipare le aree dove arriveranno prima i regolatori e gli assicuratori.

---