Agenti AI: come evitare i fallimenti silenziosi

Key takeaways

• Una chiamata completata non dimostra che i dati siano completi o adeguati allo scopo.

• Nello studio, la maggior parte dei 91 fallimenti validati nasce nei livelli API o wrapper.

• Filtri, paginazione, provenienza e significato dei campi devono essere verificati lungo tutta la catena.

• I limiti di un tool devono restare visibili fino alla risposta finale dell'agente.

• Le proporzioni osservate descrivono casi selezionati e non il tasso generale di errore degli agenti AI.

Un agente AI può completare una chiamata a un tool, ricevere una risposta valida e produrre un risultato convincente. Eppure l'informazione utilizzata può essere incompleta, privata di un filtro importante o separata dal contesto necessario per interpretarla. I fallimenti silenziosi degli agenti AI sono pericolosi proprio per questo: il flusso sembra funzionare e non genera un errore evidente, ma la conclusione finale è più forte o più precisa di quanto consentano i dati.

Il preprint Silent Failures in Agent-Tool Interaction: An Audit of ToolUniverse analizza questo problema all'interno di workflow scientifici basati su agenti e strumenti esterni. Gli autori non si concentrano soltanto sulla capacità dell'agente di scegliere ed eseguire un tool. Verificano se, lungo l'intera catena, sopravvivono completezza, qualificatori, provenienza, ambito e significato dell'informazione.

Il risultato interessa anche chi costruisce automazioni aziendali. CRM, motori di ricerca, sistemi di ticketing, cataloghi, strumenti finanziari e API di terze parti possono restituire una risposta tecnicamente corretta ma parziale. Se l'agente non riconosce e comunica quel limite, una semplice omissione diventa una decisione operativa apparentemente affidabile.

Che cos'è un fallimento silenzioso

Lo studio definisce un fallimento silenzioso attraverso tre condizioni. La chiamata al tool appare riuscita; la risposta è incompleta, trasformata, ambigua o insufficiente per il compito; il limite non viene comunicato in modo adeguato all'agente o all'utente.

Un esempio intuitivo è la paginazione. Un'API può restituire i primi 1.000 record di un insieme molto più grande senza produrre errori. Se l'agente presenta quei record come il risultato completo, il problema non è l'assenza di dati in senso assoluto. Il problema è che il limite di copertura è scomparso nel passaggio dall'API alla risposta finale.

Lo stesso può accadere quando:

• un filtro disponibile nell'interfaccia web non è esposto dall'API;

• il wrapper omette un parametro o un campo restituito dall'API;

• un punteggio perde la propria definizione durante la trasformazione;

• una ricerca per corrispondenza parziale viene interpretata come una corrispondenza esatta;

• un insieme di risultati troncato viene descritto come esaustivo;

• un qualificatore, come stato, fonte, livello di evidenza o data, non arriva alla risposta finale.

Questi casi sono diversi da un timeout o da un codice di errore. Un errore esplicito interrompe il flusso e invita a intervenire. Un risultato parziale può invece continuare a circolare, alimentare altri tool e diventare la base di nuove inferenze.

La catena agente–wrapper–API–tool

Gli autori propongono di osservare l'intero percorso dell'informazione: intento dell'utente, agente, wrapper, API, strumento o database, e poi il percorso inverso fino alla dichiarazione finale. Valutare soltanto il modello o soltanto l'API non basta, perché il significato può cambiare in ogni passaggio.

Lo studio organizza le anomalie in sette punti di origine:

1. Limite del tool: lo strumento o il dato di origine non supporta pienamente il compito.

2. Gap dell'API: una funzione presente nel prodotto non è disponibile tramite API.

3. Gap parziale dell'API: l'endpoint esiste, ma mancano campi, filtri o capacità.

4. Gap del wrapper: l'API offre la funzione, ma l'integrazione non la espone.

5. Gap parziale del wrapper: alcuni parametri, formati o campi vengono persi.

6. Problema di usabilità per l'agente: l'output esiste, ma l'agente non riesce a usarlo.

7. Errore di interpretazione: l'agente riceve il dato e gli attribuisce un significato non supportato.

Questa tassonomia sposta l'attenzione dalla domanda “il tool ha risposto?” a una domanda più utile: “la risposta conserva tutto ciò che serve per sostenere la conclusione?”.

Cosa ha trovato l'audit

L'ambiente sperimentale è ToolUniverse, una piattaforma che integra strumenti scientifici. I ricercatori hanno campionato 63 risorse principali, collegate a più di 285 strumenti, e ne hanno selezionate 15 per un'analisi approfondita. Su queste hanno esaminato 198 casi candidati, combinando scoperta assistita da LLM, test automatizzati e verifica manuale degli esiti riportati.

L'audit ha identificato 91 fallimenti validati. Secondo il riepilogo dello studio, 51 si collocano al livello API e 25 al livello wrapper. Il dato suggerisce che molti problemi nascono prima dell'interpretazione del modello: l'agente può comportarsi correttamente rispetto all'output ricevuto, mentre quell'output ha già perso campi, filtri, copertura o semantica.

I 91 casi hanno prodotto 134 occorrenze distribuite su più dimensioni, perché un singolo errore può danneggiare contemporaneamente completezza, affidabilità e attribuzione. Le dimensioni più frequenti sono state:

• completezza, con 28 occorrenze;

• ranking e rilevanza, con 21;

• appropriatezza del risultato, con 20;

• fonte e attribuzione dei dati, con 18;

• variabilità di interpretazione e affidabilità, entrambe con 13;

• coerenza, con 11.

Tra le tipologie osservate, i dati o campi mancanti ricorrono 38 volte. I problemi di ricerca, filtro e ordinamento compaiono 20 volte. Sono presenti anche funzionalità mancanti, ambiguità o incoerenze nei dati, interpretazioni errate e dichiarazioni di falso successo.

Questi numeri non misurano il tasso generale di errore degli agenti AI. I casi sono stati costruiti a partire da possibili anomalie e l'analisi approfondita riguarda un insieme limitato di strumenti. Servono a mostrare meccanismi concreti e ripetibili, non a concludere che una certa percentuale di tutte le chiamate fallisca.

Dall'omissione all'amplificazione silenziosa

Il passaggio più importante è ciò che gli autori chiamano silent amplification. Una limitazione relativamente piccola a monte diventa una conclusione più netta a valle.

Un'API che applica un limite non dichiarato può produrre un elenco parziale. Il wrapper può presentarlo senza informazioni sulla paginazione. L'agente può poi descriverlo come “tutti i risultati”. Ogni componente ha continuato a funzionare, ma la conclusione finale ha acquisito una completezza che la fonte non possedeva.

In un altro scenario, l'assenza di un filtro può includere record fuori ambito. Se il limite non viene esposto, l'agente non ha gli elementi necessari per distinguere i record pertinenti. Un problema di interfaccia diventa così un errore di selezione.

Per un'azienda, lo stesso schema può influenzare attività quotidiane: una lista incompleta di clienti da ricontattare, un catalogo senza tutte le disponibilità, ticket esclusi da un filtro, una ricerca documentale che perde allegati o una dashboard che tratta dati provvisori come definitivi. Il rischio cresce quando l'output alimenta un'altra automazione senza revisione umana.

Affidabilità contestuale: oltre il semplice successo

Lo studio propone il concetto di affidabilità contestuale. Un'interazione è affidabile quando conserva e comunica le informazioni, i qualificatori, la provenienza, l'ambito e il significato necessari per sostenere la conclusione richiesta.

Questo criterio è più esigente del controllo binario “successo o errore”. Una risposta HTTP valida o un JSON ben formato dimostrano che il collegamento tecnico funziona. Non dimostrano che il risultato sia completo, adatto allo scopo o correttamente interpretabile.

L'affidabilità contestuale dipende anche dall'intento. Un endpoint che restituisce i primi risultati può essere sufficiente per suggerire alcuni esempi. Lo stesso endpoint è inadeguato se l'utente chiede un inventario completo, un conteggio o una verifica di conformità. Il sistema deve conoscere non soltanto il formato della risposta, ma anche ciò che la risposta può legittimamente dimostrare.

Questo principio completa due temi già affrontati nel blog Quixxt: la necessità di [verificare le spiegazioni degli LLM](/blog/spiegazioni-llm-affidabilita-evidenza-comportamentale) e di trattare la [memoria degli agenti come un componente versionato](/blog/memoria-agenti-ai-cambio-modello). In tutti e tre i casi, un output plausibile non sostituisce una verifica del comportamento reale del sistema.

Come ridurre i fallimenti silenziosi in azienda

Le indicazioni dello studio possono diventare una checklist operativa per agenti e automazioni.

1. Definire il contratto informativo: per ogni tool, documentare campi obbligatori, filtri, ordinamento, paginazione, copertura e significato dei valori. Non limitarsi allo schema tecnico.

2. Testare la completezza: confrontare periodicamente interfaccia, API, wrapper e risposta dell'agente. Verificare conteggi, cursori, pagine successive e limiti massimi.

3. Preservare la provenienza: mantenere identificatori, fonte, versione, timestamp e riferimenti necessari a ricostruire ogni affermazione.

4. Propagare i limiti: se un filtro non è disponibile o il risultato è parziale, l'informazione deve accompagnare il dato fino alla risposta finale.

5. Separare dati e inferenze: distinguere ciò che il tool ha restituito da ciò che l'agente deduce. Questa separazione rende più semplice individuare dove nasce una conclusione errata.

6. Usare controlli semantici: verificare che nomi dei campi, punteggi e stati mantengano lo stesso significato attraverso le trasformazioni.

7. Monitorare le dipendenze: API e wrapper cambiano. Test di regressione programmati possono rilevare campi rimossi, nuovi default o filtri modificati.

8. Introdurre soglie di revisione: per pagamenti, compliance, salute, contratti o decisioni ad alto impatto, un risultato parziale o poco tracciabile deve richiedere una verifica umana.

9. Misurare più del tasso di successo: oltre alle chiamate completate, registrare copertura, risultati troncati, fallback, campi mancanti e discrepanze rispetto alla fonte.

10. Provare casi avversi realistici: includere query senza risultati, insiemi molto grandi, identificatori obsoleti, filtri combinati e risposte ambigue.

Il monitoraggio deve inoltre evitare un'altra trappola: il retry automatico non corregge una risposta strutturalmente incompleta. Ripetere la stessa richiesta può produrre lo stesso risultato parziale con maggiore apparente certezza.

I limiti dello studio

La ricerca è un preprint e riguarda un ambiente specifico, con strumenti prevalentemente scientifici e biologici. L'analisi approfondita copre 15 risorse, non l'intero ecosistema ToolUniverse. La generazione dei casi candidati e la prima valutazione impiegano LLM, mentre la validazione manuale riguarda il sottoinsieme descritto dagli autori.

La selezione orientata ai potenziali problemi influenza inevitabilmente le proporzioni osservate. Per questo i 91 fallimenti non rappresentano una frequenza attesa in qualunque sistema. Inoltre, API, wrapper e documentazione evolvono: un'anomalia verificata oggi può essere corretta, mentre nuovi cambiamenti possono introdurne altre.

La trasferibilità ai processi aziendali è quindi un'interpretazione operativa, non un risultato misurato direttamente dallo studio. Tuttavia, i meccanismi analizzati — paginazione, campi mancanti, filtri non esposti, perdita di provenienza e ambiguità semantica — sono comuni a molte integrazioni software.

La lezione per gli agenti AI operativi

Un agente affidabile non deve soltanto completare il compito. Deve conoscere i confini delle informazioni ricevute e mantenerli visibili. Il successo tecnico di una chiamata è il punto di partenza della verifica, non la prova che la decisione finale sia corretta.

Per progettare agenti AI destinati a processi reali, conviene trattare ogni integrazione come una catena di evidenze. Campi, filtri, fonti e limitazioni devono attraversare quella catena insieme ai dati. Quando qualcosa viene perso, il sistema deve segnalarlo prima che una risposta incompleta diventi un'azione automatica.

Fonte originale: Shreya Gopalan, Devansh Singh e Sundaraparipurnan Narayanan, Silent Failures in Agent-Tool Interaction: An Audit of ToolUniverse, arXiv:2609.26836v1 [cs.AI], 21 settembre 2026. https://arxiv.org/abs/2609.26836