Incidenti AI nel 2025: cosa insegnano su controlli, dati e responsabilità

Gli incidenti di intelligenza artificiale nel 2025 mostrano una regola semplice: capacità e diffusione crescono più velocemente dei controlli. Il problema raramente coincide con un singolo modello “impazzito”; nasce dall’interazione tra dati, software, persone, permessi e processi decisionali.

Analizzare un incidente serve a individuare condizioni ripetibili, non a trovare un colpevole conveniente. Un buon post-mortem trasforma l’evento in modifiche verificabili.

Che cosa si intende per incidente AI?

È un evento nel quale un sistema basato su AI produce o contribuisce a un impatto inatteso: perdita economica, esposizione di dati, discriminazione, informazione falsa, decisione errata, interruzione di servizio o danno reputazionale.

La gravità dipende da persone coinvolte, durata, reversibilità e possibilità di rilevare l’errore. Un output inesatto corretto prima dell’uso non ha lo stesso impatto della stessa risposta inserita automaticamente in un processo operativo.

Perché gli incidenti documentati aumentano

Il capitolo Responsible AI dello Stanford AI Index 2025 riporta 233 incidenti AI nel 2024, il valore più alto della serie e un aumento del 56,4% rispetto al 2023.

L’aumento può riflettere maggiore diffusione, capacità più ampie e migliore attenzione alla segnalazione. Non dimostra da solo che ogni sistema sia diventato meno sicuro, ma indica che l’esposizione complessiva richiede controlli più maturi.

Sei categorie di incidente

1. Output falso o fuorviante

Il modello genera contenuti plausibili ma inesatti e l’utente li usa senza verifica. L’impatto cresce quando la risposta contiene nomi, cifre, riferimenti o istruzioni operative.

2. Dati e privacy

Informazioni riservate possono entrare in prompt, log, sistemi di retrieval o dataset di adattamento. Il rischio riguarda raccolta eccessiva, accessi impropri e conservazione non prevista.

3. Sicurezza e prompt injection

Contenuti ostili tentano di alterare le istruzioni, estrarre dati o indurre l’uso improprio di strumenti. La guida sulla prompt injection spiega perché l’input non deve attraversare senza separazione il confine tra dato e comando.

4. Bias e impatto sulle persone

Un sistema può trattare gruppi o individui in modo ingiustificato, specialmente quando dati storici e variabili proxy influenzano selezione, priorità o accesso a opportunità.

5. Automazione eccessiva

Un modello con strumenti può inviare messaggi, modificare record o avviare operazioni. Se permessi e soglie non sono proporzionati, un errore locale diventa rapidamente un incidente esteso.

6. Dipendenze e supply chain

Modelli, librerie, dataset, plugin e provider esterni possono cambiare o essere compromessi. L’organizzazione deve conoscere componenti, versioni e piano alternativo.

Dall’errore individuale alla causa di sistema

Attribuire tutto a chi ha scritto il prompt non è sufficiente. Bisogna chiedere perché una singola azione abbia potuto superare tutte le difese.

Le cause ricorrenti includono:

• caso d’uso non definito e confini vaghi;
• assenza di test prima del rilascio;
• dati non classificati;
• permessi superiori al necessario;
• output non validati;
• operatore non formato o sovraccarico;
• monitoraggio senza soglie e responsabilità;
• dipendenza da un solo fornitore;
• assenza di rollback e procedure di emergenza.

Controlli prima del rilascio

Un sistema AI dovrebbe essere valutato sul proprio contesto, non soltanto sui benchmark generali. Il test include richieste normali, casi limite, input ostili e condizioni di errore.

• Definire output consentiti e vietati;
• creare un set di valutazione rappresentativo;
• misurare errori e falsi positivi;
• verificare accessi a dati e strumenti;
• impostare limiti di spesa e frequenza;
• testare interruzione e rollback;
• documentare chi approva il rilascio.

Per applicazioni ad alto impatto, la revisione umana deve avere tempo, informazioni e potere reale di fermare la decisione.

Monitoraggio dopo il rilascio

Le prestazioni possono cambiare per aggiornamenti, nuovi dati, comportamenti degli utenti o variazioni del contesto. Il monitoraggio dovrebbe coprire:

• qualità e tasso di errore per segmento;
• input anomali e tentativi di abuso;
• azioni eseguite dagli strumenti;
• accessi e trasferimenti di dati;
• latenza, costi e interruzioni;
• feedback, contestazioni e override;
• cambi di modello, prompt e dipendenze.

Il NIST AI Risk Management Framework include monitoraggio post-deployment, risposta, recupero, comunicazione e gestione delle modifiche tra le pratiche operative.

Come reagire a un incidente AI

1. Contenere: sospendere automazioni o ridurre i permessi;
2. preservare: salvare log, versioni, input e configurazioni;
3. valutare: identificare dati, persone e sistemi coinvolti;
4. correggere: rimuovere la causa immediata con una modifica controllata;
5. comunicare: informare i soggetti pertinenti con fatti verificati;
6. recuperare: ripristinare il servizio in modo graduale;
7. apprendere: completare il post-mortem e monitorare le azioni.

La priorità è ridurre l’impatto. Modifiche affrettate senza conservare le evidenze possono impedire di comprendere l’evento.

Template di post-mortem

Un documento utile dovrebbe includere:

• data, durata e modalità di rilevazione;
• descrizione verificata dell’impatto;
• timeline tecnica e decisionale;
• versioni di modello, prompt e componenti;
• causa immediata e fattori contribuenti;
• controlli presenti e motivo del loro fallimento;
• azioni immediate, strutturali e responsabili;
• scadenze e criteri di chiusura;
• test aggiunto per evitare la regressione.

Il documento non dovrebbe ridursi a “errore umano”. Se una persona può causare un danno rilevante con un solo passaggio, progettazione e processo hanno contribuito.

Quanto deve essere autonoma l’AI?

Autonomia e controllo devono crescere insieme. Un sistema che propone una bozza richiede difese diverse da uno che invia messaggi o modifica ordini.

La matrice tra agenti AI e workflow aiuta a decidere quando usare passaggi deterministici, approvazione umana o capacità agentiche.

Per azioni irreversibili sono utili conferma esplicita, doppia approvazione, limiti quantitativi e ambiente isolato.

Gestire fornitori e modelli esterni

Il contratto e l’architettura dovrebbero chiarire disponibilità, uso dei dati, notifica degli incidenti, aggiornamenti e possibilità di esportare configurazioni e registri.

Occorre inventariare:

• modelli e versioni in produzione;
• API, plugin e server collegati;
• dataset e basi documentali;
• proprietario di ogni componente;
• data dell’ultima valutazione;
• procedura di sostituzione o spegnimento.

KPI di sicurezza operativa

• tempo medio di rilevazione;
• tempo di contenimento e recupero;
• incidenti per tipologia e gravità;
• percentuale di azioni con approvazione;
• errori intercettati prima dell’impatto;
• copertura dei test e regressioni;
• azioni post-mortem completate nei tempi;
• utenti e team formati.

L’assenza di segnalazioni non dimostra assenza di problemi. Può indicare che utenti e operatori non sanno come riconoscerli o comunicarli.

Errori nella gestione degli incidenti

• Nascondere l’evento per proteggere la reputazione;
• correggere il prompt senza analizzare il processo;
• non coinvolgere sicurezza, legale e proprietari del servizio;
• riattivare tutto senza un test controllato;
• conservare log insufficienti o dati eccessivi;
• chiudere le azioni senza verifica;
• ignorare eventi mancati per poco.

Domande frequenti

Un’allucinazione è sempre un incidente?

No. Diventa un incidente quando produce o contribuisce a un impatto. Rimane comunque un segnale da misurare.

Chi dovrebbe gestire la risposta?

Un responsabile definito coordina prodotto, IT, sicurezza, privacy, legale e comunicazione in base alla gravità.

Serve registrare tutti i prompt?

Bisogna bilanciare capacità investigativa e minimizzazione dei dati. Contenuto, accessi e tempi di conservazione devono essere progettati.

Quando sospendere il sistema?

Quando l’impatto può continuare, i confini non sono chiari o i controlli disponibili non riducono il rischio a un livello accettabile.

Dagli incidenti a controlli migliori

Gli incidenti di intelligenza artificiale nel 2025 non richiedono paura, ma disciplina operativa. Inventario, test, monitoraggio, permessi minimi e post-mortem trasformano gli errori in conoscenza. La maturità non consiste nel promettere zero incidenti, ma nel prevenirli, rilevarli e gestirli con responsabilità.