Gli agenti IA raramente vanno in crash. Falliscono in silenzio, e la ricerca spiega perché

Gli agenti basati su modelli linguistici di grandi dimensioni rispondono ormai alle richieste di assistenza, interrogano database e pianificano viaggi. Quando qualcosa va storto, di solito forniscono una risposta sicura e un codice di successo. Una mole crescente di ricerche spiega perché questi fallimenti siano difficili da individuare e come i team di ingegneria stiano imparando a misurarli.

Un fallimento che sembra un successo

Il software tradizionale tende a fallire in modo evidente. Una funzione genera un’eccezione, un server restituisce un codice di errore e il pannello di monitoraggio si tinge di rosso. Un agente IA si comporta diversamente. Funziona come un ciclo: un modello linguistico legge un prompt, decide di chiamare uno strumento, come un’API di ricerca o un database, legge il risultato e decide cosa fare dopo. Ogni passaggio può andare storto, anche se tutte le richieste di rete della catena vengono comunque completate correttamente.

Consideriamo un caso comune. Uno strumento per le previsioni meteorologiche non funziona e restituisce il testo «servizio non disponibile» all’interno di una risposta altrimenti normale. Il modello legge quel testo, si scusa con cortesia oppure, peggio ancora, elabora una previsione plausibile basandosi sui dati di addestramento. L’utente riceve una risposta fluida. I registri del server mostrano una richiesta completata correttamente, con una latenza normale. Nei sistemi di monitoraggio tradizionali non viene registrato nulla che indichi un problema.

I fornitori di modelli descrivono questa stessa lacuna nella propria documentazione. La guida all’API Gemini di Google precisa che il modello «non esegue la funzione autonomamente». Si limita a proporre il nome di una funzione e i relativi argomenti; è poi l’applicazione dello sviluppatore a eseguire la chiamata. L’applicazione è quindi l’unica parte del sistema a vedere il risultato effettivo. La guida tecnica di Anthropic alla creazione di agenti sottolinea un aspetto correlato: a ogni passaggio, gli agenti hanno bisogno di conoscere la «verità di riferimento» fornita dall’ambiente, per esempio tramite i risultati degli strumenti, così da valutare i propri progressi. Quando uno strumento segnala un errore sotto forma di normale testo, quella verità di riferimento è sbagliata e l’agente non ha modo di accorgersene.

Non si tratta di un problema nuovo, ma solo di una versione più evidente di un problema già noto. Nel 2015, gli ingegneri di Google guidati da D. Sculley descrissero il «debito tecnico nascosto» nei sistemi di apprendimento automatico. Sostenevano che la maggior parte dei rischi nei sistemi di apprendimento automatico in produzione si annida al di fuori del codice del modello, nelle dipendenze dai dati, nella configurazione e nel codice di integrazione. Gli agenti aggiungono un nuovo elemento a questo elenco. I prompt e le descrizioni degli strumenti sono configurazioni che possono modificare il comportamento di un sistema senza che cambi il codice.

Piccole modifiche, grandi effetti

Quanto può essere importante una piccola modifica al prompt? In uno studio presentato a ICLR 2024, Melanie Sclar dell’University of Washington e i suoi colleghi hanno modificato soltanto la formattazione dei prompt few-shot: i separatori, gli spazi e l’uso delle maiuscole. Il significato è rimasto invariato. Eppure, le prestazioni sullo stesso compito sono variate fino a 76 punti di accuratezza con LLaMA-2-13B. La sensibilità non è venuta meno con modelli più grandi, un maggior numero di esempi o l’ottimizzazione tramite istruzioni.

Gli autori raccomandano di riportare un intervallo di prestazioni relativo a formati di prompt plausibili, anziché un singolo valore. Per i team di ingegneria, la lezione pratica è più semplice: modificare un prompt equivale a modificare il codice. La modifica deve essere registrata nella cronologia delle versioni e testata prima di arrivare agli utenti.

Lo stesso vale per le descrizioni degli strumenti, che il modello legge come parte del prompt. La guida di Anthropic raccomanda di dedicare alle definizioni degli strumenti «la stessa attenzione all’ingegneria dei prompt» riservata al prompt principale. Descrive un agente di programmazione che continuava a commettere errori con i percorsi relativi dei file. Quando lo strumento è stato modificato in modo da richiedere percorsi assoluti, il modello ha iniziato a usarlo senza errori. Il modello non è cambiato: è cambiata soltanto la descrizione che leggeva.

Un successo non dimostra molto

Una seconda linea di ricerca esamina la coerenza. Il test τ-bench, pubblicato da Shunyu Yao e dai suoi colleghi di Sierra e presentato a ICLR 2025, simula conversazioni con il servizio clienti in cui un agente deve usare strumenti e rispettare le regole aziendali. Gli autori hanno introdotto una metrica chiamata pass^k: la probabilità che un agente risolva correttamente lo stesso compito in tutti e k i tentativi.

I risultati sono stati poco incoraggianti. Un agente GPT-4o ha risolto circa il 61% dei compiti di vendita al dettaglio al primo tentativo. Quando gli è stato richiesto di riuscire nello stesso compito otto volte di seguito, la percentuale è scesa a circa il 25%. Una dimostrazione che funziona una volta dice ben poco su come si comporterà un sistema alla millesima esecuzione.

Dove si inceppano i sistemi multiagente

Molti team collegano ormai più agenti in sequenza: uno pianifica, un altro esegue e un terzo verifica il lavoro. Uno studio del 2025 dell’UC Berkeley, «Perché falliscono i sistemi LLM multiagente?», ha analizzato oltre 1.600 tracce di esecuzione annotate, provenienti da sette diffusi framework multiagente. Gli autori, guidati da Mert Cemri, hanno elaborato una tassonomia chiamata MAST, che comprende 14 modalità di fallimento suddivise in tre gruppi: problemi di progettazione del sistema, disallineamento tra gli agenti e verifica dei compiti.

La loro conclusione principale è che molti fallimenti dipendono dalla progettazione del sistema, non soltanto dai limiti del modello sottostante. Gli agenti ignorano il ruolo assegnato, perdono il filo della conversazione oppure dichiarano concluso un compito senza verificarne il risultato. Questi fallimenti non lasciano traccia di errori. Sono visibili solo se qualcuno può leggere ciò che ciascun agente ha effettivamente fatto. L’analisi di Unite.AI sul paradosso multiagente sottolinea un aspetto correlato dal punto di vista architetturale: aggiungere agenti può amplificare un errore iniziale, anziché compensarlo.

Rendere visibile l’invisibile

La risposta ingegneristica riprende un approccio dei sistemi distribuiti, nei quali da tempo si seguono le richieste attraverso numerosi servizi usando una tecnica chiamata tracciamento. Applicato agli agenti, ogni richiesta dell’utente diventa una traccia e ogni chiamata al modello o a uno strumento diventa uno «span» al suo interno. Uno span registra l’input, l’output, i token utilizzati e il tempo impiegato. L’organismo che definisce gli standard di settore per questo ambito, OpenTelemetry, sta elaborando convenzioni condivise per gli span dell’IA generativa. Nel 2026, tali convenzioni sono ancora indicate come in fase di sviluppo, quindi i nomi degli attributi potrebbero cambiare.

Diversi progetti open source, come Langfuse, Arize Phoenix e AcruxCore, applicano già questa idea. Il loro codice sorgente è pubblico, quindi i team possono esaminare come viene archiviata una traccia ed eseguire il software sui propri server. Registrano le chiamate ai modelli e agli strumenti come span di un’unica traccia e consentono ai team di associarvi punteggi di qualità. La scelta dello strumento conta meno di un dettaglio: uno span relativo a uno strumento deve registrare ciò che lo strumento ha effettivamente restituito, non soltanto se la richiesta di rete è andata a buon fine. Altrimenti, il malfunzionamento dello strumento meteo descritto sopra rimane invisibile.

Le indagini di settore suggeriscono che il tracciamento sia ormai diffuso, ma i test sono rimasti indietro. Il rapporto sullo stato dell’ingegneria degli agenti di LangChain ha coinvolto 1.340 professionisti alla fine del 2025. La qualità è stata l’ostacolo più citato all’introduzione degli agenti in produzione: l’ha indicata il 32% degli intervistati. L’89% delle organizzazioni ha dichiarato di adottare una qualche forma di osservabilità per i propri agenti e il 62% di effettuare un tracciamento dettagliato dei singoli passaggi e delle chiamate agli strumenti. Solo il 52,4% ha condotto valutazioni offline su insiemi di test e il 37,3% ha valutato il traffico in tempo reale. La maggior parte dei team riesce a vedere cosa hanno fatto i propri agenti. Sono meno quelli che verificano se lo hanno fatto correttamente.

Valutare le risposte su larga scala

Le tracce mostrano cosa è successo. Non indicano se la risposta fosse valida. Leggere a mano ogni conversazione non è praticabile su larga scala, quindi i team ricorrono sempre più spesso a un secondo modello come valutatore, con un approccio noto come LLM-as-a-judge. Un articolo di NeurIPS 2023 di Lianmin Zheng e colleghi ha rilevato che i modelli più potenti, come GPT-4, concordavano con le preferenze umane in oltre l’80% dei casi, una percentuale all’incirca pari a quella con cui le persone concordano tra loro.

Lo stesso articolo documentava i punti deboli del metodo. I modelli usati come valutatori preferiscono la prima risposta mostrata, prediligono le risposte più lunghe e possono favorire i testi scritti da loro stessi. I punteggi assegnati dai modelli sono quindi stime. Sono utili quando si devono valutare grandi volumi, ma vanno verificati confrontandoli con un piccolo insieme di esempi etichettati da esseri umani, presentati in ordine casuale.

Dalla pratica alle politiche

Questo lavoro di misurazione sta diventando anche un requisito di governance. Il National Institute of Standards and Technology statunitense ha pubblicato il proprio AI Risk Management Framework nel gennaio 2023. Una delle sue quattro funzioni fondamentali, «Misurare», chiede alle organizzazioni di quantificare, monitorare e documentare nel tempo i rischi legati all’IA. Per un agente, le tracce e i punteggi delle valutazioni costituiscono le prove richieste da questa funzione.

Cosa possono fare ora i team

Questo riflette l’argomentazione presentata su questa piattaforma: la vera prova dell’IA agentica è l’affidabilità. Le ricerche citate aggiungono un aspetto importante sul piano della misurazione: l’affidabilità non è una proprietà da osservare una sola volta, ma un intervallo che occorre misurare costantemente.

Le ricerche indicano una serie di semplici abitudini, molte delle quali sono raccomandate anche dai principali fornitori di modelli. La guida pratica di OpenAI per creare agenti consiglia ai team di «impostare valutazioni per stabilire un livello di prestazioni di riferimento» prima di ottimizzare e di trasferire il controllo a una persona quando un agente supera un numero prestabilito di tentativi non riusciti o si trova di fronte a un’azione ad alto rischio. Anthropic raccomanda «test approfonditi in ambienti isolati» prima di lasciare che gli agenti agiscano autonomamente.

In pratica, questo si traduce in alcuni passaggi concreti. Gestite i prompt e le descrizioni degli strumenti con il controllo delle versioni, proprio come il codice. Testate ogni modifica ai prompt su un insieme di dati fisso e aspettatevi una gamma di risultati, non un unico valore. Eseguite ogni caso di test più volte, perché una sola esecuzione non mette in luce le incoerenze. Registrate gli output degli strumenti nelle tracce, così un malfunzionamento non può passare inosservato dietro un codice di esito positivo. Considerate stime i punteggi assegnati automaticamente dai modelli e verificateli con le persone.

Nessuna di queste abitudini richiede una svolta nelle capacità dei modelli. Richiedono di considerare un agente di IA per quello che è: un sistema probabilistico che deve essere misurato, perché raramente segnala da sé i propri malfunzionamenti.