Cosa fa un agente di IA quando non sa la risposta (e cosa fa il tuo oggi)
Un agente progettato bene fa tre cose, in questo ordine: rileva che non sa grazie a un segnale misurabile, si astiene dal rispondere o dall'agire, e passa il caso a una persona con il contesto già raccolto. Uno progettato male ne fa una sola: risponde comunque. In fretta, scritto bene e con sicurezza, che è esattamente ciò che rende caro il guasto, perché così nessuno lo guarda due volte.
Da qui la tesi di questa guida, che sembra un'esagerazione e non lo è: un agente che non dubita mai è il più pericoloso che tu possa avere. Un dubbio che si vede — «questo non lo so, ti passo chi lo sa» — costa un trasferimento. Un dubbio che non si vede — una risposta plausibile e falsa, un campo riempito a occhio, un rimborso approvato senza base — costa l'errore più il tempo per trovarlo, e il secondo addendo è quasi sempre più grande del primo. Per questo un agente non si giudica dal suo caso migliore: si giudica da cosa fa nel peggiore.
Quel che segue non parla di tarare il modello. Abbassare l'invenzione a livello di risposta — grounding, citazioni, un recupero decente — è un altro lavoro e va fatto: sta in ridurre le allucinazioni dell'IA in produzione. Questa guida parla di ciò che circonda il momento del dubbio, che si progetta nel tuo sistema e vale uguale per un agente di supporto, uno che legge fatture e uno che prepara un report. I criteri concreti di passaggio a un umano in un chatbot stanno in creare un chatbot di IA; qui c'è il pezzo generale.
Il tuo agente è addestrato a non stare mai zitto
Prima di progettare qualsiasi cosa bisogna accettare il punto di partenza, ed è scomodo: il modello sotto arriva con un bias di fabbrica contro il silenzio. Non è l'opinione di un consulente bastian contrario. Il lavoro di Kalai, Nachum, Vempala e Zhang lo dice senza giri di parole: i modelli linguistici allucinano perché le procedure di addestramento e valutazione premiano tirare a indovinare più che riconoscere l'incertezza, e il problema resiste per come viene corretta la maggior parte delle valutazioni — i modelli sono ottimizzati per essere bravi esaminandi, e un bravo esaminando, quando non sa, risponde lo stesso. Fonte: Why Language Models Hallucinate, Kalai, Nachum, Vempala e Zhang (OpenAI), 4 settembre 2025, consultato il 13 settembre 2026.
Il corollario operativo è quello che conta: l'astensione non è un comportamento latente che svegli con una frase nel prompt. «Se non lo sai, dillo» aiuta al margine e cede proprio dove fa male, perché stai chiedendo prudenza a un sistema addestrato al contrario. Il dubbio va fabbricato fuori dal modello: segnali che calcola il sistema, verifiche che girano prima di agire e un'uscita verso una persona che esiste davvero.
C'è una seconda trappola, ancora più popolare: chiedere al modello quanta fiducia ha. Non funziona, ed è misurato. La valutazione di Xiong e colleghi sull'elicitazione della confidenza ha trovato che i modelli sono molto sovra-sicuri quando verbalizzano la propria confidenza, con valori concentrati in modo schiacciante tra l'80 % e il 100 %. Fonte: Can LLMs Express Their Uncertainty?, Xiong et al., ICLR 2024, consultato il 13 settembre 2026. Un numero che dice quasi sempre novanta non è un segnale: è un ornamento.
I segnali di dubbio che servono, e quello che usano tutti
Il dubbio utile non esce dal modello: esce dal sistema che lo circonda. Sono segnali calcolabili, ognuno con il suo innesco, e nessuno ha bisogno che il modello sia sincero.
| Segnale | Da dove esce | Cosa lo innesca |
|---|---|---|
| Copertura della fonte | Il passo di recupero, non il modello | Nessun passaggio sopra la soglia, o quello che arriva non contiene il dato richiesto |
| Disaccordo con sé stesso | Due passate sullo stesso input | Le due risposte non coincidono sul dato che conta |
| Contratto di output rotto | La validazione, prima che si scriva qualcosa | Manca un campo obbligatorio, un importo non è un numero, una data non esiste |
| Regola dura di business | La tua policy, non il modello | Importo sopra il limite, cliente senza storico, dato regolato, paese fuori copertura |
| Contatore di fallimento | L'orchestratore | N tentativi o N turni senza avanzare |
| Richiesta esplicita | La persona dall'altra parte | «voglio parlare con qualcuno» |
I primi tre si montano in giornata e sono quelli che prendono di più. Quello della copertura è il più redditizio per euro investito: se l'agente risponde sui tuoi documenti e il recupero non ha portato nulla di rilevante, sai già che quel che viene dopo è invenzione, senza doverlo leggere. Binario, economico e precedente alla risposta.
Una sfumatura che evita l'errore di progettazione più comune: questi segnali non si sommano in un numero magico. Ognuno chiede un trattamento diverso. La copertura vuota si risolve dicendo «questo non ce l'ho documentato» e passando il caso. Il contratto rotto si risolve con un tentativo limitato e, se si rompe di nuovo, coda. La regola dura non negozia con nessun altro segnale: se l'importo supera il limite, passa a una persona anche se l'agente è sicurissimo. Un punteggio globale di confidenza mescola cose che non si somigliano e finisce per nascondere i primi tre.
Verificare prima di agire: dubitare di una risposta non è dubitare di un'azione
L'astensione ha due versioni e confonderle costa caro. Astenersi dal rispondere è economico: se stai zitto di troppo, qualcuno risponde dopo. Astenersi dall'agire è un altro campionato, perché un'azione sbagliata lascia traccia in un sistema e disfarla costa più che farla. L'asticella non può essere la stessa nei due posti.
La guida di OpenAI per costruire agenti lo ordina per strumento, non per conversazione: raccomanda di valutare il rischio di ogni strumento dell'agente e di dargli un giudizio — basso, medio o alto — in base a sola lettura o scrittura, reversibilità dell'azione, permessi richiesti e impatto economico; e di usare quel giudizio per innescare azioni automatiche, come fermarsi per controlli prima di eseguire funzioni ad alto rischio o escalare a una persona. Sull'intervento umano è altrettanto concreta: i due inneschi abituali sono il superamento di soglie di fallimento — limiti di tentativi, o non capire l'intenzione dell'utente dopo più prove — e le azioni ad alto rischio, sensibili, irreversibili o con molto in gioco, come annullare ordini, autorizzare rimborsi grandi o effettuare pagamenti. Fonte: A practical guide to building agents, OpenAI, consultato il 13 settembre 2026.
- Controllare prima di scrivere. Se l'agente sta per toccare un sistema, il dato si verifica contro la fonte che comanda — l'anagrafica, l'ERP, il contratto — e non contro quello che il modello ricorda. Sulle azioni la verifica non è un miglioramento: è il passo.
- Se non è reversibile, non c'è soglia che tenga. Nessuna misura di confidenza autorizza un'azione che non si può disfare. Quella si conferma sempre, anche se l'agente è da sei mesi senza errori.
- Se il controllo non si può fare, quello è già il dubbio. Il sistema che doveva confermare è giù, il documento non si apre, l'identificativo non esiste. Non è un caso raro da risolvere per analogia: è un caso che si ferma.
Questo si aggancia a due decisioni che si prendono a parte e che conviene non mescolare: cosa può toccare l'agente sta in quali permessi dare a un agente di IA, e quanto può fare da solo, in i livelli di autonomia di un agente. Il comportamento del dubbio è la terza gamba: cosa succede quando, con quei permessi e su quel gradino, il caso concreto non regge.
Dove mettere la soglia senza far collassare la squadra
La soglia non è un numero che si sceglie leggendo un articolo: è la conseguenza di due cose tue, il costo dell'errore e la capacità della coda. Se l'errore è economico e visibile, la soglia può essere larga. Se è caro e silenzioso, si stringe. E se il numero di casi che manda in revisione non entra nelle ore che ha la tua squadra, quella soglia non è prudente: in tre settimane verrà approvata in blocco senza leggere, che è peggio che non averla, perché per di più produce un registro che dice che qualcuno ha guardato.
- Raggruppa i compiti dell'agente in tre secchi per costo dell'errore: economico e visibile, caro e visibile, caro e invisibile. Comanda il terzo: lì la soglia si mette dove serve anche se fa male.
- Parti deliberatamente pessimista. È più facile difendere una soglia che si allenta con i dati che una che si stringe dopo un incidente.
- Misura due settimane e guarda le astensioni, non i successi. Per ogni caso finito in coda, segna se la persona lo ha risolto diversamente — l'astensione era giusta — o esattamente come avrebbe fatto l'agente — era rumore. È questa ripartizione che muove la soglia, non la sensazione.
- Regola per segmento, mai in globale: cliente nuovo contro cliente da dieci anni, importo piccolo contro grande, lingua in cui hai documentazione contro lingua in cui non ne hai.
- Metti la capacità come tetto duro. Se con la soglia giusta la coda non entra, la conclusione non è abbassare la soglia: è che quel compito non dovrebbe ancora stare in produzione senza più mani.
Quando il volume cresce, questa smette di essere una configurazione e diventa una funzione con turni, copertura e metriche proprie: è la supervisione umana dell'IA su larga scala, e conviene montarla prima di averne bisogno.
Cosa deve viaggiare nel passaggio di consegne perché la persona non riparta da zero
Un passaggio senza contesto è un dubbio rilevato bene e risolto male. L'agente ha fatto la sua parte — si è fermato in tempo — e il cliente racconta comunque il suo problema una seconda volta, che è esattamente quello che fa arrabbiare di un chatbot. In un passaggio interno succede lo stesso senza che nessuno protesti: la persona ricostruisce a mano quello che il sistema aveva già.
La meccanica è risolta nelle due guide di riferimento. Nel pattern decentralizzato descritto da OpenAI, il passaggio tra agenti trasferisce il controllo e anche l'ultimo stato della conversazione; e un agente, per definizione, può fermare l'esecuzione e restituire il controllo all'utente quando fallisce. Anthropic lo imposta come punti di arresto: gli agenti possono mettersi in pausa per un intervento umano ai checkpoint o quando incontrano un blocco, e conviene fissare condizioni di arresto — un massimo di iterazioni — per non perdere il controllo. Fonti: A practical guide to building agents, OpenAI, e Building effective agents, Anthropic, 19 dicembre 2024; entrambe consultate il 13 settembre 2026.
Quello che la documentazione non ti dà è il contenuto del pacchetto. Questi sono i sei campi che fanno sì che un passaggio faccia risparmiare tempo invece di costarlo:
- Cosa chiedeva il caso, in una riga e con le parole di chi ha chiesto.
- Cosa ha fatto l'agente prima di fermarsi: cosa ha consultato, cosa ha trovato, cosa ha scritto se ha scritto qualcosa.
- Perché si è fermato: il segnale concreto che è scattato, non «bassa confidenza». «Nessun documento copre la domanda» e «l'importo supera il limite» chiedono due cose diverse alla persona.
- Cosa ha già raccolto: identificativi, allegati, dati verificati. Se la persona deve richiederli, il passaggio è fallito.
- Cosa NON ha fatto, quando conta: «non è stato mandato niente al cliente», «l'ordine non è stato toccato». Evita l'azione doppia, l'incidente classico dell'escalation.
- Cosa ci si aspetta dalla persona: decidere, scrivere, autorizzare. Un caso che arriva senza verbo resta in coda.
E manca il tratto di ritorno, che quasi nessuno monta: la decisione della persona deve tornare nel registro con il suo motivo. Senza, ogni astensione è un caso perso; con, la coda di revisione diventa la batteria di casi con cui misuri l'agente il mese dopo. È la differenza tra un sistema che escala e uno che impara anche da quello che escala.
Come si misura un agente che dubita bene (e perché la tua eval oggi lo penalizza)
Se la tua unica metrica è la percentuale di successo, stai riproducendo in casa il problema che descrivono Kalai e soci: quando «non lo so» vale quanto una risposta sbagliata, tirare a indovinare è razionale. Loro la chiamano un'epidemia di penalizzazione delle risposte incerte, e la loro proposta non è aggiungere un'altra eval sulle allucinazioni, ma cambiare come si punteggiano le eval che già si usano. Nella tua azienda è la stessa operazione, e sta in tre numeri.
- Tasso di astensione. Che percentuale di casi ferma l'agente. Non ha un valore buono universale: ha un valore atteso che fissi tu e una tendenza che sorvegli. Se cala da solo da un mese all'altro senza che tu abbia toccato niente, qualcosa si è rotto nel segnale.
- Precisione dell'astensione. Di quello che ha mandato in coda, quanta parte la persona ha risolto diversamente da come avrebbe fatto l'agente. È la metrica che distingue un agente prudente da uno codardo.
- Errore con sicurezza. Casi andati male senza che l'agente segnalasse nulla. È l'unica delle tre con un obiettivo chiaro, ed è zero. Ognuno si apre e diventa un segnale nuovo o una regola dura.
Con quei tre numeri la conversazione cambia posto: smette di essere «è bravo l'agente?» e diventa «in cosa sbaglia, e lo sa?». Che è l'unica versione della domanda a cui si può rispondere con i dati.
Noi montiamo questo comportamento prima dell'agente: segnali calcolati, verifica obbligatoria su tutto quello che scrive, soglia legata alla capacità reale e un passaggio di consegne con i sei campi. È quello che sta sotto il supporto con IA 24/7 e sotto qualsiasi agente che lasciamo parlare con un tuo cliente, ed è quello che si sorveglia a volume ne la supervisione umana dell'IA su larga scala. Il resto del montaggio — permessi, autonomia, memoria, eval — sta in creare un agente di IA che regga la produzione.