In sintesi
- Il rischio più materiale dei modelli di IA generativa è la produzione di output infedele, che il NIST definisce formalmente confabulazione e che nei team operativi va sotto il nome di allucinazione.
- L’allucinazione domina per due motivi: è il modo di guasto più segnalato negli ambienti di produzione, ed è quello che amplifica ogni altro rischio, perché un’uscita scorrevole ma falsa rende più difficile riconoscere bias, fughe di dati e violazioni di proprietà intellettuale.
- La tassonomia di riferimento difendibile è NIST AI 600-1: dodici rischi specifici dell’IA generativa o da essa aggravati, ciascuno mappato sulle quattro funzioni del NIST AI Risk Management Framework (Govern, Map, Measure, Manage).
- Nel Regolamento europeo sull’intelligenza artificiale, lo stesso rischio emerge negli articoli 9 (sistema di gestione dei rischi), 13 (trasparenza), 15 (accuratezza, robustezza, cibersicurezza), 50 (etichettatura dei contenuti sintetici) e negli articoli 53 e 55 (obblighi per i modelli di IA per finalità generali e per quelli con rischio sistemico).
- Un assetto di governance praticabile si articola in quattro strati: valutazione prima del rilascio, ancoraggio tramite recupero documentale con soglie di confidenza, mediazione delle uscite con presidio umano sui flussi a impatto elevato e sorveglianza dopo il rilascio con segnalazione degli incidenti.
Il rischio dominante: l’output infedele (allucinazione)
Se occorre una risposta sola, si tratta di allucinazione: la tendenza di un modello generativo a produrre contenuti che suonano sicuri ma risultano falsi, fabbricati o non sostenuti da alcuna fonte fornita al modello. Il NIST adopera il termine confabulazione nel proprio profilo dedicato all’IA generativa proprio per evidenziare il carattere strutturale e non incidentale del fenomeno: il modello non mente, attinge a una distribuzione di probabilità che assegna massa anche a enunciati falsi (NIST AI 600-1).
Tre ragioni rendono questo rischio il rischio dominante nel 2026.
La prima riguarda la frequenza di occorrenza in produzione. La ricerca accademica che mappa gli incidenti reali di IA generativa stabilisce che l’output infedele è il modo di guasto più segnalato nei sistemi schierati, davanti al bias, alla fuga di dati e alla prompt injection (arXiv 2505.22073). Tre precedenti modellano ormai il modo in cui i responsabili di conformità ragionano sull’IA generativa: la decisione Air Canada, nella quale un tribunale canadese ha affermato la responsabilità della compagnia per una politica di rimborso inventata dall’assistente conversazionale; la sanzione Mata contro Avianca, con la quale un giudice federale di New York ha sanzionato avvocati che avevano depositato una memoria con sei pronunce interamente fittizie prodotte da ChatGPT; e i procedimenti australiani del 2024 e 2025 nei quali avvocati sono stati deferiti all’ordine professionale per citazioni allucinate analoghe.
La seconda ragione è l’effetto di composizione. Un incidente di bias in un sistema deterministico si manifesta come uno scarto misurabile negli esiti. Lo stesso incidente in un modello che allucina può nascondersi all’interno di un paragrafo scorrevole e autorevole nel tono. Anche la riservatezza segue questa logica: una sintesi infedele di una cartella clinica può inventare una diagnosi, mescolando esposizione reale di dati ed esposizione fabbricata. L’allucinazione è il modo di guasto che rende ogni altro modo di guasto più difficile da sottoporre ad audit.
La terza ragione attiene al peso regolatorio. Il Regolamento UE non nomina la parola allucinazione, ma impone ai fornitori di sistemi di IA ad alto rischio di progettare i sistemi affinché raggiungano un livello adeguato di accuratezza, robustezza e cibersicurezza e lo mantengano lungo l’intero ciclo di vita (articolo 15). I fornitori devono inoltre rendere disponibili istruzioni per l’uso che dichiarino prestazioni e limiti del sistema (articolo 13). Per i modelli per finalità generali, gli obblighi crescono con l’articolo 53; per i modelli con rischio sistemico, il Codice di buone pratiche GPAI dell’Ufficio europeo per l’IA impone un quadro completo di sicurezza (Codice GPAI, luglio 2025).
Un rischio occupa il titolo. Dodici compongono la struttura sottostante.
Il panorama completo: la tassonomia in 12 categorie del NIST
Perché NIST AI 600-1 fa da riferimento
Gran parte degli articoli concorrenti elenca otto, dieci o dodici rischi senza una colonna vertebrale comune, il che rende le liste difficili da confrontare e ancor più difficili da rendere operative. NIST AI 600-1, pubblicato il 26 luglio 2024, colma questo divario. Sviluppato da un gruppo di lavoro pubblico con oltre 2.500 contributori, identifica 12 rischi specifici dell’IA generativa o da essa aggravati. Ogni rischio è ricondotto alle quattro funzioni del sottostante NIST AI RMF 1.0 (Govern, Map, Measure, Manage), con oltre 200 azioni raccomandate distribuite tra di esse.
I 12 rischi, mappati al Regolamento UE e al Top 10 OWASP per le LLM
| Rischio NIST AI 600-1 | Definizione sintetica | Articolo del Regolamento UE | Equivalente OWASP LLM Top 10 (2025) |
|---|---|---|---|
| CBRN | Abbassamento della soglia di accesso a capacità chimiche, biologiche, radiologiche o nucleari | Art. 51, 55 (GPAI con rischio sistemico) | (nessuno) |
| Confabulazione (allucinazione) | Generazione sicura ma infedele di fatti, citazioni o codice | Art. 13, 15 | LLM09 Disinformazione |
| Contenuti pericolosi, violenti o di odio | Uscite che incitano, istruiscono o normalizzano il danno | Art. 5, 50 | LLM05 Gestione impropria delle uscite |
| Tutela dei dati | Memorizzazione e divulgazione di dati personali o sensibili | Art. 10, 26 e GDPR | LLM02 Divulgazione di informazioni sensibili |
| Impatti ambientali | Impronta energetica, idrica e di carbonio di addestramento e inferenza | Considerando 142, art. 53(1)(d) | (nessuno) |
| Bias dannoso e omogeneizzazione | Scarto sistematico secondo attributi protetti | Art. 10, 15, 27 | (parziale, LLM09) |
| Configurazione umano-IA | Livelli di automazione non calibrati e affidamento eccessivo | Art. 14 (sorveglianza umana) | LLM06 Agenzia eccessiva |
| Integrità dell’informazione | Contenuti mediali fabbricati, deepfake, disinformazione sintetica su larga scala | Art. 50 (etichettatura dei contenuti sintetici) | LLM09 Disinformazione |
| Sicurezza dell’informazione | Superfici d’attacco specifiche dell’IA, incluse le attacchi su prompt | Art. 15(5) cibersicurezza | LLM01 Prompt Injection, LLM04 Avvelenamento di dati e modelli |
| Proprietà intellettuale | Violazioni nei dati di addestramento e nelle uscite che riproducono opere protette | Art. 53(1)(c) sintesi dei dati di addestramento | LLM03 Catena di fornitura |
| Contenuti osceni, degradanti o abusivi | CSAM, immagini intime non consensuali, materiale di abuso | Art. 5 e regolamento CSAM | LLM05 Gestione impropria delle uscite |
| Catena del valore e integrazione di componenti | Propagazione del rischio dal fornitore del modello fondazionale al deployer | Art. 25, 53 | LLM03 Catena di fornitura |
La tabella svolge due funzioni allo stesso tempo. Per un team radicato negli Stati Uniti conserva il vocabolario NIST già in uso. Per un team radicato in Europa mostra quale obbligo regolatorio si attacca a ciascun rischio. La colonna OWASP fornisce il ponte verso gli architetti di sicurezza, che adottano in genere il LLM Top 10 v2025 come lingua condivisa.
Come usare la tabella per la prioritizzazione
La tassonomia non è una lista di controllo. La prioritizzazione è il lavoro vero. Per ciascun rischio occorre porsi due domande: quanto è verosimile il guasto vista l’architettura e il contesto di rilascio, e quanto è grave la conseguenza se si manifesta. Un assistente di supporto alle decisioni cliniche dovrebbe prioritizzare confabulazione, bias dannoso e configurazione umano-IA. Un assistente alla scrittura di codice dovrebbe prioritizzare confabulazione, sicurezza dell’informazione e proprietà intellettuale. Un chatbot consumer dovrebbe prioritizzare contenuti pericolosi, integrità dell’informazione e tutela dei dati. La tassonomia consente a ciascun team di partire dallo stesso vocabolario per arrivare a ordinamenti di priorità differenti.
Cosa rende differente il profilo di rischio dell’IA generativa
Tre proprietà dell’IA generativa invalidano le ipotesi su cui poggia la gestione del rischio applicativo classica.
Scala e velocità. Un singolo prompt genera contenuti su scala internet. Un assistente clienti mal configurato può pubblicare migliaia di impegni di rimborso errati prima che qualcuno se ne accorga, come ha sperimentato Air Canada. Il raggio d’impatto di un rilascio sbagliato non è più limitato dal volume di utenti, ma dal volume di generazione.
Uscite stocastiche. Il software classico dispone di un oracolo di test deterministico: data un’input, l’output corretto è fissato e verificabile. I modelli generativi campionano da una distribuzione. Lo stesso prompt produce uscite differenti da un’esecuzione all’altra, e lo stesso modello si comporta diversamente dopo un fine-tuning di routine. La proprietà rompe i test unitari, i test di non regressione e la gran parte dei criteri di accettazione scritti per software deterministico. La valutazione deve passare da «l’uscita è uguale a X» a «l’uscita rientra in una distribuzione accettabile», domanda più difficile da strumentare.
Capacità emergenti e opacità della catena del valore. Comportamenti assenti dai dati di addestramento possono comparire su larga scala, talvolta senza preavviso tra versioni. Al contempo la responsabilità è stratificata: un fornitore di modello fondazionale lo addestra, un integratore lo affina e lo incapsula, un deployer lo porta agli utenti. Il Regolamento UE governa la catena con l’articolo 25 e con gli obblighi GPAI dell’articolo 53, ma nella pratica il deployer rimane responsabile del guasto visibile all’utente. Il Codice GPAI traccia un’ulteriore linea alla soglia di rischio sistemico di 10^25 operazioni in virgola mobile per l’addestramento, oltre la quale i fornitori devono mantenere un Safety and Security Framework che include valutazioni di modello e attività di red teaming.
Governare il rischio dominante: un assetto in quattro strati
Un’impostazione di governance difendibile per il rischio dominante coincide con le funzioni Measure e Manage del quadro NIST e con gli articoli 9, 14, 15, 17 e 72 del Regolamento UE.
Strato 1: valutazione prima del rilascio
Prima che un sistema generativo arrivi agli utenti, dovrebbe superare una suite di valutazione documentata che copra i suoi modi di guasto attesi. Per la confabulazione, ciò significa adottare benchmark dedicati (TruthfulQA, HaluEval, valutazioni di dominio costruite sulla propria verità di base), prompt di red teaming pensati per provocare citazioni fabbricate e test avversariali ispirati alle tecniche di MITRE ATLAS. Il NIST AI RMF Playbook descrive la funzione Measure in termini operativi; l’articolo 15 del Regolamento UE codifica l’obbligo richiedendo che i sistemi ad alto rischio siano progettati e sviluppati per raggiungere un livello adeguato di accuratezza, robustezza e cibersicurezza (articolo 15). In Italia, le linee guida dell’AgID sull’adozione dell’IA nella pubblica amministrazione integrano utilmente le aspettative europee per i deployer del settore pubblico.
Strato 2: ancoraggio tramite recupero documentale e soglie di confidenza
L’assetto architetturale che riduce in modo più affidabile l’allucinazione a tempo di esecuzione è la generazione aumentata dal recupero con ancoraggio rigoroso. Il modello è costretto a rispondere a partire da documenti recuperati, con citazione esplicita, e ad astenersi quando la confidenza del recupero scende sotto una soglia configurata. Il modo di guasto passa da «rispondere male» a «rifiutarsi di rispondere», transizione molto meno costosa da gestire in esercizio. La soglia di confidenza è anche uno dei pochi assetti che soddisfa il dovere di trasparenza dell’articolo 13, il quale chiede che la progettazione permetta agli utenti di interpretare correttamente l’uscita del sistema.
Strato 3: mediazione delle uscite
Per i flussi a impatto elevato, il recupero non basta. La mediazione aggiunge uno strato di validazione tra il modello e l’utente: un secondo modello verifica l’uscita del primo, un validatore basato su regole impone vincoli strutturali, oppure un operatore umano esamina l’uscita prima che venga eseguita. La scelta di dove mediare dipende dall’impatto. Decisioni cliniche, giuridiche e finanziarie richiedono un operatore umano nel ciclo. Le uscite informative possono richiedere solo controlli automatizzati. La scelta è la sostanza dell’articolo 14 (sorveglianza umana): i fornitori devono progettare i sistemi ad alto rischio affinché persone fisiche possano sorvegliarli con efficacia e prevalere sulle loro uscite. Il Garante per la protezione dei dati personali ha pubblicato nel 2024 e 2025 indicazioni operative sul trattamento automatizzato che pesano direttamente sul disegno di questi presidi.
Strato 4: sorveglianza dopo il rilascio e segnalazione degli incidenti
Gli strati da 1 a 3 non catturano la deriva che emerge solo dopo il rilascio, quando i prompt si discostano dal set di valutazione e gli utenti scoprono casi limite non previsti. L’articolo 72 del Regolamento UE codifica la sorveglianza post-mercato e l’articolo 73 stabilisce gli obblighi di segnalazione degli incidenti gravi. La definizione di lavoro dell’OCSE di incidente IA fornisce un vocabolario condiviso (OECD AI Paper No. 16), e la funzione Manage del quadro NIST elenca le pratiche operative: valutazione continua contro benchmark scorrevoli, anelli di retroazione utenti, rilevazione di anomalie sulle distribuzioni di input e un processo di risposta agli incidenti maturo, di proprietà di una funzione organizzativa nominata.
Domande frequenti
Quali sono i quattro tipi di rischio dell’IA? La suddivisione in quattro più citata si appoggia alle caratteristiche di IA affidabile del quadro NIST. Le funzioni Govern, Map, Measure e Manage descrivono il ciclo di vita, mentre le caratteristiche di affidabilità raggruppano i rischi in quattro categorie pratiche: rischi di sicurezza e protezione, rischi di equità e bias, rischi di trasparenza e responsabilità, rischi di tutela e governance dei dati. Altre tassonomie (OCSE, categorie di rischio del Regolamento UE, ISO 23894) usano partizioni differenti. Per le decisioni reali, la più fine tassonomia in 12 rischi di NIST AI 600-1 risulta più utile di qualunque modello a quattro contenitori.
Qual è la preoccupazione principale nell’uso dell’IA generativa? La preoccupazione principale è l’output infedele: il modello restituisce una risposta sicura che è falsa, fabbricata o non sostenuta da evidenza. Le conseguenze concrete vanno dalla responsabilità civile quando un assistente travisa la politica aziendale, alle sanzioni professionali quando citazioni fabbricate finiscono in atti giudiziari, al danno reputazionale quando contenuto sintetico viene scambiato per cronaca autentica, fino al danno clinico o finanziario quando una raccomandazione allucinata viene seguita. La preoccupazione non è teorica: i precedenti documentati includono ormai il caso Air Canada e la sanzione Mata contro Avianca.
Quale preoccupazione interessa specificamente l’IA generativa nello sviluppo software? La preoccupazione più acuta nello sviluppo software è la generazione di codice non sicuro. Gli assistenti di codifica producono volentieri frammenti che importano librerie obsolete, codificano credenziali in chiaro, omettono la validazione degli input o riproducono pattern vulnerabili memorizzati dai dati di addestramento. OWASP raccoglie la famiglia in LLM05 Gestione impropria delle uscite e LLM01 Prompt Injection; il NIST SP 800-218A estende il Secure Software Development Framework allo sviluppo assistito dall’IA. I controlli concreti includono revisione obbligatoria del codice generato dall’IA, scansione dei segreti, verifica delle dipendenze e schemi di rifiuto quando l’assistente viene sollecitato a produrre codice sensibile sotto il profilo della sicurezza.
Come regola specificamente il Regolamento UE l’IA generativa? Il Regolamento UE affronta l’IA generativa su tre piani. L’articolo 50 fissa obblighi di trasparenza per i contenuti sintetici (etichettatura dei deepfake, marche leggibili dalle macchine). L’articolo 53 fissa le obbligazioni di base per i fornitori di modelli per finalità generali: documentazione tecnica, politica sul diritto d’autore, sintesi dei dati di addestramento e assistenza ai fornitori a valle. L’articolo 55 aggiunge doveri per i modelli per finalità generali con rischio sistemico: valutazioni di modello, test avversariali, segnalazione degli incidenti gravi all’Ufficio europeo per l’IA e cibersicurezza. Il Codice GPAI opera gli articoli 53 e 55 per i fornitori oltre la soglia di addestramento di 10^25 FLOPs.
Che differenza c’è tra bias e allucinazione? Il bias è uno scarto sistematico delle uscite secondo attributi protetti o gruppi: il modello è più incline a raccomandare un candidato maschio, più incline a riconoscere male un volto con incarnato scuro, più incline a riprodurre uno stereotipo. L’allucinazione è la generazione infedele: il modello inventa una citazione, una politica di rimborso, una persona, una causa. Entrambi figurano nel NIST AI 600-1 come rischi distinti e richiedono rimedi differenti: il bias si tratta attraverso curatela dei dataset, valutazioni di equità e audit dei risultati; l’allucinazione si tratta attraverso ancoraggio per recupero, soglie di confidenza e mediazione delle uscite.
Esistono quadri di governance pensati specificamente per l’IA generativa? Sì. I quattro più operativi oggi sono NIST AI 600-1 (Stati Uniti, luglio 2024), il Codice di buone pratiche GPAI (Unione Europea, luglio 2025), OWASP Top 10 for LLM Applications (industria, novembre 2024) e MITRE ATLAS (industria, in evoluzione). NIST AI 600-1 è la tassonomia canonica con il catalogo delle azioni. Il Codice GPAI rende operativi il Regolamento UE per i fornitori per finalità generali. OWASP fornisce l’elenco di vulnerabilità lato sviluppatore. MITRE ATLAS cataloga le tecniche avversariali. Combinati, coprono tassonomia, operazionalizzazione regolatoria, sicurezza applicativa e modellazione delle minacce.
I modelli più grandi risolveranno l’allucinazione? Probabilmente non per sola scala. I modelli più grandi riducono certi tipi di allucinazione e ne amplificano altri, in particolare le affermazioni sicure su domini sotto-rappresentati al momento dell’addestramento. La posizione accademica seria nel 2025 è che l’allucinazione è intrinseca alla generazione autoregressiva e deve essere governata a livello di sistema, attraverso ancoraggio, mediazione e sorveglianza, non attesa al livello del modello (arXiv 2504.08526).
Conclusione
Chi ha bisogno di una sola risposta da portare in un esame, in una riunione di vertice o in una valutazione di fornitore la ottiene così: il principale rischio dei modelli di IA generativa è l’output infedele, detto anche allucinazione o confabulazione. Chi deve difendere quella risposta o renderla operativa scopre sotto di essa un panorama di dodici rischi nella tassonomia NIST AI 600-1, ciascuno ancorato a precisi articoli del Regolamento UE e governabile con un piccolo numero di pattern architetturali ben compresi. L’errore frequente è trattare i rischi uno alla volta. L’opportunità consiste nell’adottare una tassonomia, mapparla su una libreria di controlli e mandare in esecuzione l’assetto in quattro strati dentro un ciclo di miglioramento continuo.
In AI Sigil consegniamo un registro dei rischi pre-mappato su NIST AI 600-1 e sugli obblighi ad alto rischio e GPAI del Regolamento UE, con controlli per categoria e raccolta delle evidenze pronta per l’audit. Il rischio è una parte del lavoro. L’altra parte consiste nel mantenerlo sotto governo.