Nessuno ti giudicherà sulla lista di rischi che sai recitare, ma su quali hai reso visibili e limitati prima che diventassero un incidente. La documentazione Anthropic non pubblica un catalogo unico dei modi di fallimento: pubblica pezzi sparsi che, messi in fila, danno una tassonomia difendibile e un punto preciso dove innestare l’intervento umano.

Quattro famiglie di fallimento, contromisure diverse

Allucinazione. La guida sulla riduzione delle allucinazioni propone tecniche di base — dare al modello il permesso esplicito di dichiarare di non sapere, estrarre citazioni testuali prima di elaborare documenti lunghi, far verificare ogni affermazione con una citazione a sostegno e ritirarla se la citazione non esiste — e tecniche avanzate: verifica passo passo del ragionamento, best-of-N su esecuzioni ripetute della stessa richiesta, divieto esplicito di usare conoscenza esterna ai documenti forniti. La chiusa è la frase da portare in riunione: queste tecniche riducono molto le allucinazioni ma «they don’t eliminate them entirely».

Degrado da contesto lungo. «as the number of tokens in the context window increases, the model’s ability to accurately recall information from that context decreases». Il contesto va trattato come risorsa finita a rendimenti marginali decrescenti: un sistema che brilla in demo a cinque turni e sbaglia al sessantesimo non è rotto, sta consumando il proprio budget di attenzione.

Errori che si compongono. In un agente lo sbaglio non resta locale: «mistakes can propagate and compound» attraverso chiamate a strumenti e modifiche di stato dell’ambiente. È il motivo per cui valutare un agente non equivale a valutare un prompt.

Contenuto ostile. La ricerca Anthropic sulle difese dall’iniezione di prompt somma addestramento del modello, classificatori che analizzano il contenuto non fidato e red teaming umano su larga scala, e resta esplicita sul residuo: «No browser agent is immune to prompt injection». Un tasso di successo degli attacchi dell’1 per cento è insieme un miglioramento significativo e un rischio concreto.

A queste si aggiunge la categoria che l’API dichiara da sola. Il campo stop_reason distingue fallimenti che un cliente distratto tratterebbe tutti come successi:

end_turn                        risposta conclusa naturalmente
max_tokens                      output troncato dal tuo limite
tool_use                        attesa dell'esecuzione di uno strumento
pause_turn                      ciclo di server tool al limite di iterazioni
refusal                         il modello ha declinato
model_context_window_exceeded   finestra piena: risposta da trattare come troncata

Il rifiuto va progettato, non subito: i classificatori di sicurezza lo restituiscono come normale risposta HTTP 200, non come errore, e chi monitora solo i codici di stato lo conterà fra i successi.

Le quattro domande che rendono il rischio leggibile

La guida per CISO sull’AI agentica riduce la valutazione a quattro domande che funzionano bene anche come ordine del giorno di un comitato: «What untrusted content does it ingest?», «What actions can it take, and on whose behalf?», «What is the blast radius if it is misaligned?», «What observability do I have?». La posizione che rende la conversazione possibile con chi finanzia è la stessa guida a enunciarla: «Zero risk isn’t the job». L’obiettivo è rendere il rischio agentico leggibile e limitato, perché l’alternativa a un rischio accettato consapevolmente non è l’assenza di rischio, è l’adozione ombra.

L’umano si mette sul gate dell’azione, non sulla revisione finale

Sulla Managed Agents API il controllo è una politica per strumento, con due valori: always_allow esegue senza conferma, always_ask mette la sessione in pausa. I default dicono già una filosofia: il toolset dell’agente parte da always_allow, i toolset MCP da always_ask, così che un nuovo strumento aggiunto a un server MCP non esegua nulla senza approvazione. Il flusso è osservabile e senza scadenza:

agent.tool_use            -> lo strumento sta per essere invocato
session.status_idle       -> stop_reason.type = requires_action, attesa indefinita
user.tool_confirmation    -> result "allow" oppure "deny" con deny_message

Un diniego non è un vicolo cieco: l’agente riceve un risultato che dichiara il rifiuto, incluso il tuo deny_message, e può cambiare strada. Nell’Agent SDK lo stesso schema passa dal callback canUseTool, che consente cinque risposte utili — approvare, approvare modificando l’input, approvare e ricordare la regola, rifiutare spiegando il perché, suggerire un’alternativa — e che può restare pendente a tempo indeterminato. Se l’approvazione umana può durare più del processo, la documentazione indica la via corretta: un hook PreToolUse che restituisce la decisione defer, così il processo esce e la sessione persistita riprende dopo.

Calibrare l’autonomia invece di concederla

Il controllo umano costa attenzione, e l’attenzione è la risorsa che si esaurisce per prima. Le pratiche riportate dai team che lavorano con agenti lunghi vanno nella direzione opposta all’intuizione: «The best long-running agents have many different ways to verify their work before a human looks at it», con un secondo agente che verifica il lavoro del primo, domande accorpate in un unico passaggio e un tetto a quante cose ogni persona vede. L’autonomia si estende per tipo di attività dopo successi ripetuti, non si concede in blocco. Il principio che tiene insieme il tutto è nel quadro Anthropic sugli agenti sicuri: «Humans should retain control over how their goals are pursued, particularly before high-stakes decisions are made». Difendilo con dati: venti-cinquanta compiti costruiti sui fallimenti realmente osservati sono un ottimo inizio, e nessuno saprà se i giudici automatici funzionano senza leggere le trascrizioni.