Una risposta sbagliata è il sintomo visibile, non la diagnosi. Per capire perché un sistema di intelligenza artificiale ha fallito bisogna guardare l’intero percorso: il compito assegnato, le prove disponibili, il modello, le fonti o gli strumenti collegati e il modo in cui persone e processi usano il risultato.
Prima il sintomo, poi la causa
L’intelligenza artificiale può sbagliare perché non osserva automaticamente la realtà, non possiede tutto il contesto di un’organizzazione e non verifica ogni risultato prima di restituirlo.
Lavora dentro un sistema che seleziona dati, istruzioni, fonti e strumenti. L’errore può quindi entrare in cinque punti:
- il compito o il contesto sono definiti male;
- le prove o i dati sono incompleti, non rappresentativi o non aggiornati;
- il modello classifica, prevede o genera un risultato errato;
- il recupero delle fonti o uno strumento collegato restituisce o usa l’elemento sbagliato;
- il workflow non prevede controlli, limiti e responsabilità adeguati.
“L’AI ha sbagliato” descrive ciò che è successo. Non identifica ancora la causa.
Cinque punti da controllare prima di attribuire automaticamente il problema al modello.
Compito e contesto
Esempio di erroreRichiesta ambigua o uso fuori ambito
Controlla primaIl sistema ha ricevuto compito, vincoli e significato corretti?
Prove e dati
Esempio di erroreProcedura obsoleta o dati incompleti
Controlla primaLe fonti sono aggiornate, complete e adatte alla decisione?
Modello e generazione
Esempio di erroreAffermazione falsa ma plausibile (allucinazione)
Controlla primaLa risposta va oltre ciò che le prove disponibili sostengono?
Recupero e strumenti
Esempio di errorePassaggio, strumento o parametro errato
Controlla primaChe cosa è stato recuperato, chiamato e restituito?
Workflow e uso umano
Esempio di erroreRisposta non verificata o passaggio mancante
Controlla primaErano presenti controlli, limiti e responsabilità chiare?
Sintesi esplicativa M4TIC · i livelli possono sovrapporsi · non ogni errore rientra in una sola categoria
“L’AI ha sbagliato” non è una diagnosi
Intelligenza artificiale è un termine ampio. Un classificatore che assegna una categoria, un modello predittivo che stima una probabilità, un sistema generativo che produce testo e un agente che usa strumenti possono fallire in modi diversi.
La prima domanda non è quindi “perché l’AI sbaglia in generale?”, ma: quale sistema doveva svolgere quale compito, in quali condizioni?
Il NIST AI Risk Management Framework lega validità e affidabilità all’uso previsto e alle condizioni in cui il sistema opera. Un risultato può essere accettabile in un’attività a basso impatto e inadeguato in un’altra. Un sistema può anche funzionare bene sui casi per cui è stato progettato e degradare quando il contesto cambia.
Questo è il motivo per cui un output errato non basta a stabilire se il problema sia nel modello. La causa può essere entrata prima o dopo.
Errore 1: il compito o il contesto sono sbagliati
Un sistema non può recuperare un significato operativo che non gli è stato fornito e che non può osservare.
Una richiesta può essere ambigua. Può mancare lo stato aggiornato del cliente, il limite di autorità, la definizione di “urgente” o la politica applicabile a quel caso. Il sistema può anche essere usato fuori dal perimetro per cui è stato progettato.
Un prompt migliore aiuta quando mancano istruzioni. Non può però inventare in modo affidabile un dato aziendale assente o scegliere una regola che l’organizzazione non ha definito.
Controlla la richiesta originale e le istruzioni di sistema, il risultato osservabile atteso, i vincoli e le assunzioni note e il perimetro autorizzato del compito.
Se un sistema deve scegliere tra strumenti o azioni mentre le condizioni cambiano, non stai valutando soltanto una risposta. Stai valutando il comportamento di un sistema più ampio. La distinzione è approfondita in Agenti AI: cosa sono e quando usarli in azienda.
Errore 2: le prove o i dati sono deboli
Un modello può elaborare correttamente informazioni che non descrivono più la realtà.
Un archivio può contenere una politica superata. Un dataset può rappresentare male un gruppo o una condizione rara. Un record può essere incompleto o errato. Una previsione può incontrare una situazione diversa da quelle osservate durante sviluppo e valutazione.
Il NIST AI RMF Playbook tratta qualità, rappresentatività e provenienza dei dati come parti della misurazione del rischio. Non significa che esista un dataset perfetto. Significa che l’affidabilità dipende anche da ciò che il sistema ha potuto vedere e da quanto quel materiale resta adatto al caso corrente.
Verifica da dove provengono dati e documenti, quando sono stati aggiornati, quali casi o gruppi potrebbero mancare, se esistono prove in conflitto e se il caso corrente è diverso dalle condizioni valutate.
Cambiare il modello lasciando invariata una fonte errata può produrre una risposta più fluida allo stesso problema.
Errore 3: il modello produce il risultato sbagliato
Anche con un compito chiaro e dati pertinenti, il modello può sbagliare. Un classificatore può assegnare la categoria errata. Un modello predittivo può generalizzare male. Un sistema generativo può commettere un errore di ragionamento o produrre una frase plausibile che non è sostenuta dalle prove.
Per i modelli linguistici generativi, questo ultimo caso viene spesso chiamato allucinazione o confabulazione. È una forma importante di errore, ma non spiega ogni risposta sbagliata e non riguarda allo stesso modo ogni sistema di AI. Allucinazioni dell’IA: cosa sono e come verificare una risposta affronta questa domanda più circoscritta.
Una formulazione sicura non è una prova di correttezza. La ricerca di OpenAI sulle cause delle allucinazioni discute il rapporto tra previsione, incertezza e incentivi a tentare una risposta anziché astenersi. È una spiegazione riferita ai modelli linguistici, non una regola universale per tutta l’intelligenza artificiale.
Al livello del modello, osserva l’output, il comportamento di astensione o incertezza e la ripetibilità su input equivalenti. Evita però di dedurre la causa soltanto dallo stile della risposta.
Errore 4: il recupero o gli strumenti falliscono
Collegare un modello a documenti, database o API non garantisce che userà la prova giusta nel modo giusto.
Il sistema può recuperare un passaggio irrilevante, omettere il documento necessario, interrogare un indice non aggiornato o applicare un filtro sbagliato. Può ricevere il contesto corretto e non utilizzarlo bene. Un tool può fallire, restituire un risultato parziale o essere chiamato con parametri errati.
La ricerca Google su sufficienza del contesto nei sistemi RAG distingue tra risposte errate dovute a contesto insufficiente e fallimenti che avvengono nonostante la presenza di informazioni sufficienti. Gli studi sul contesto lungo, tra cui Lost in the Middle, mostrano inoltre che la disponibilità di informazioni non equivale automaticamente al loro uso robusto nei modelli e nei compiti studiati. Le prestazioni evolvono per modello e attività: il punto operativo è ispezionare ciò che è stato effettivamente recuperato e usato.
Controlla i passaggi o record recuperati, query e filtri, chiamata e parametri dello strumento e stato finale del sistema, non soltanto il messaggio prodotto. Se un agente afferma di avere aggiornato una prenotazione, la prova non è la frase. È la prenotazione corretta nello stato previsto.
Errore 5: il workflow trasforma un limite in un danno
Non tutti gli errori dell’AI diventano automaticamente errori operativi. Il workflow decide se l’output viene verificato, contenuto, corretto o applicato senza controllo.
Un sistema può non mostrare la fonte, non segnalare l’incertezza, non richiedere approvazione prima di un’azione o non assegnare un proprietario alle eccezioni. Una persona può accettare una risposta convincente perché il processo la presenta come definitiva. Il NIST Generative AI Profile tratta la configurazione umano–AI, l’integrità dell’informazione e la confabulazione come rischi collegati al sistema socio-tecnico, non soltanto al modello.
Il controllo umano non è una formula magica. Deve avere tempo, competenza, prove accessibili e autorità per fermare o correggere il risultato. Altrimenti aggiunge un passaggio formale senza ridurre il rischio.
Valuta chi può accettare, modificare o bloccare l’output; quali risultati richiedono una verifica indipendente; come vengono mostrati fonti, limiti e stato degli strumenti; cosa accade quando le informazioni mancano; e chi risponde delle eccezioni e del miglioramento successivo.
L’affidabilità va misurata dentro il lavoro reale, non attraverso il numero di persone che usano lo strumento. Questo è il punto centrale di L’adozione dell’AI non è un obiettivo.
Gli errori possono propagarsi e sommarsi
Le cinque categorie sono una mappa diagnostica, non compartimenti isolati.
Immagina un assistente che deve rispondere su una politica di rimborso. La richiesta non identifica il tipo di contratto. Il database contiene una versione superata della politica. Il recupero seleziona un passaggio generico. Il modello colma il vuoto con una risposta plausibile. Il workflow la invia senza mostrare la fonte né richiedere revisione.
Il messaggio finale è errato, ma attribuirlo soltanto a un’allucinazione nasconde quattro possibilità di prevenzione precedenti.
La domanda più utile è: qual è il primo punto in cui le prove disponibili hanno smesso di corrispondere al compito reale? Correggere quel punto riduce il rischio a monte; correggere soltanto la formulazione finale può mascherarlo.
Dove controllare per prima cosa
Non esiste un ordine che identifica con certezza ogni causa. Questa sequenza riduce però il rischio di saltare direttamente alla spiegazione più visibile:
- Definisci il risultato atteso. Quale compito e quale stato finale dovevano essere soddisfatti?
- Controlla contesto e prove. Le informazioni erano corrette, aggiornate e sufficienti?
- Ispeziona recupero e strumenti. Quali documenti, record, chiamate e parametri sono stati realmente usati?
- Esamina il comportamento del modello. Ha inferito oltre le prove, classificato male o ignorato un contesto disponibile?
- Valuta il workflow. Perché l’errore non è stato segnalato, contenuto o corretto prima di produrre una conseguenza?
La quantità di verifica dovrebbe crescere con la conseguenza, l’irreversibilità e la difficoltà di rilevare l’errore. Per decisioni mediche, legali, finanziarie, occupazionali o che incidono sui diritti serve una revisione professionale qualificata: questa mappa non sostituisce la competenza di dominio.
Non esiste un tasso universale di errore che dica quando “l’AI” sia affidabile. La domanda deve restare legata a un sistema, un compito, una versione e condizioni definite.
Dalla diagnosi alla prova
Una volta individuato il livello probabile, trasforma il problema in un caso ripetibile: input, fonti disponibili, strumenti, risultato atteso, limite di autorità e conseguenza del fallimento.
Se il sistema è un agente che usa strumenti o modifica stati, il passo successivo è Come testare un agente AI prima del lancio. La guida mostra come raccogliere prove su risultato, fonti, azioni, escalation e recupero dagli errori senza affidarsi a una demo riuscita o a un punteggio universale.
Fonti e approfondimenti
Indicazioni primarie dietro questo articolo.
- AI Risks and TrustworthinessNIST
Definisce validità e affidabilità rispetto all’uso previsto e alle condizioni operative.
- AI RMF CoreNIST
Collega validità, sicurezza, generalizzazione e interpretazione degli output al contesto d’uso.
- AI RMF Playbook — MeasureNIST
Indicazioni su dati, rappresentatività, provenienza, drift e valutazione dei sistemi socio-tecnici.
- Generative Artificial Intelligence ProfileNIST
Profilo del luglio 2024 su confabulazione, qualità dei dati, configurazione umano–AI e integrità dell’informazione.
- Sufficient Context: A New Lens on Retrieval Augmented Generation SystemsGoogle Research
Ricerca ICLR 2025 che distingue contesto recuperato insufficiente e fallimento nell’uso di contesto sufficiente.
- Lost in the MiddleLiu et al., TACL
Evidenza sperimentale, riferita ai modelli e compiti studiati, sui limiti nell’uso di informazioni in contesti lunghi.
- Why language models hallucinateOpenAI
Spiegazione di ricerca del 2025 su previsione, incertezza, astensione e incentivi a tentare una risposta.
- A Survey on Hallucination in Large Language ModelsZhang et al., Computational Linguistics
Rassegna sulla definizione e sulle cause delle allucinazioni nei modelli linguistici; il tema dettagliato resta riservato a INS-0007.