Agenti IA: troppe conferme indeboliscono l’approvazione

Ferma un agente IA per l’approvazione umana subito prima di un’azione che può avere conseguenze rilevanti, non a ogni passaggio. Le linee guida AWS sulle decisioni critiche avvertono che la revisione indiscriminata affatica chi approva e favorisce conferme automatiche. Il criterio è graduare la supervisione in base all’effetto dell’azione e dare al revisore il contesto necessario per decidere.

Quando serve una decisione, sospendi l’esecuzione prima della chiamata allo strumento e conserva lo stato dell’agente. Mostra la chiamata concreta a una persona autorizzata; alla risposta, verifica identità, permessi e validità della richiesta, registra la decisione e riprendi dallo stato salvato. L’approvazione riguarda i parametri presentati al revisore, non un generico permesso di continuare la conversazione.

Una matrice per decidere dove fermarsi

Classifica ogni chiamata per effetto, reversibilità, risorsa coinvolta e destinatario. La documentazione di Microsoft Agent Framework prevede per i singoli strumenti approvazione sempre richiesta, mai richiesta o condizionale. La matrice seguente traduce queste possibilità in una politica operativa: le soglie vanno definite in base ai permessi e alle conseguenze del servizio.

Sola lettura. Una consultazione autorizzata può procedere senza pausa se non modifica dati e non li invia a nuovi destinatari. Restano necessari i normali controlli di accesso: chiamare uno strumento «di lettura» non autorizza l’agente a consultare qualunque risorsa.
Scrittura reversibile. Per una bozza o un record ripristinabile, usa una condizione verificabile, come la modifica di dati condivisi, per richiedere un revisore. La reversibilità deve essere reale: una cronologia delle versioni aiuta a correggere una bozza, ma non annulla gli effetti che altri sistemi hanno già prodotto.
Azione esterna. Ferma l’agente prima dell’invio di un’email o della pubblicazione di un contenuto. Il revisore deve vedere destinatari e contenuto finale: una correzione successiva non ritira necessariamente ciò che è già stato comunicato.
Operazione critica. Per pagamenti, cancellazioni definitive o modifiche estese, prevedi un revisore con ruolo adeguato e, quando la politica lo richiede, una seconda approvazione o un canale separato. Il controllo deve precedere l’effetto dello strumento.

La categoria dipende dalla chiamata concreta, non soltanto dal nome della funzione. Salvare una bozza privata e pubblicarla possono passare dallo stesso sistema ma avere conseguenze diverse. Per rendere stabile la classificazione, combina tipo di operazione, risorsa, importo quando pertinente, destinatario e segnali anomali con regole verificabili; rivedile quando cambiano strumenti o permessi.

Il contesto minimo per una decisione utile

Una richiesta di approvazione deve mostrare quale strumento sarà eseguito, con quali parametri, su quale risorsa, per conto di chi e con quale effetto atteso. Per un’email servono almeno destinatari e contenuto definitivo; per una modifica ai dati, i valori interessati e la possibilità di ripristinarli. Una domanda come «Consenti all’agente di continuare?» lascia invece indeterminato ciò che la persona sta autorizzando.

Mostra anche gli elementi pertinenti che hanno portato alla proposta, distinguendo le affermazioni dell’agente dai dati verificati dal sistema. Il revisore deve poter accedere al contesto necessario senza ricevere segreti o informazioni estranee alla decisione. Se destinatario, importo o altri parametri cambiano durante l’attesa, la decisione precedente non copre la nuova chiamata: occorre sottoporla di nuovo alla regola di rischio.

Sospendere l’agente e riprendere dallo stato salvato

La guida dell’OpenAI Agents SDK descrive una pausa prima della chiamata soggetta ad approvazione: l’esecuzione restituisce le richieste pendenti e può riprendere dallo stesso RunState dopo approve o reject. Lo stato è serializzabile per attese prolungate. Il controllo su chi può decidere e sulla validità della risposta spetta però all’applicazione che gestisce la richiesta.

Prima che lo strumento agisca, salva lo stato dell’esecuzione insieme all’identificativo della chiamata, ai parametri proposti e alla versione della regola applicata. Associa la richiesta alla persona o al ruolo autorizzato a decidere.
Mostra al revisore solo il contesto che può consultare e un identificativo opaco della decisione. Conserva lo stato completo in un archivio controllato dal server: la risposta del client deve esprimere approvazione o rifiuto, senza sostituire parametri o stato dell’agente.
Alla risposta, ricava l’identità dal sistema di autenticazione, verifica i permessi e accerta che la richiesta sia ancora pendente e valida. Consuma la decisione con un’operazione atomica, così risposte ripetute o concorrenti non avviano due riprese dello stesso stato.
Applica la decisione alla chiamata pendente e riprendi l’agente dallo stato conservato. Se un guasto lascia incerto l’esito di uno strumento, accerta l’effetto già prodotto prima di ritentare: impedire il riuso della richiesta non garantisce, da solo, che l’azione esterna sia eseguita una sola volta.

Scadenza, rifiuto e registro delle decisioni

Ogni richiesta pendente ha bisogno di una scadenza e di un esito previsto se nessuno risponde. Per un’operazione critica, una politica prudente blocca l’azione oppure la inoltra a un revisore sostitutivo. Se nel frattempo cambia il contesto da cui dipende la decisione, annulla la richiesta e presentane una nuova con i parametri aggiornati.

Il rifiuto è una decisione sulla chiamata proposta: l’agente non dovrebbe aggirarlo ripresentando la stessa azione come se fosse nuova. Registra identificativi dell’esecuzione e della chiamata, parametri rilevanti, identità del revisore ricavata dall’autenticazione, orari, esito, motivazione quando prevista ed eventuale escalation. Il registro permette di ricostruire ciò che è stato autorizzato e di individuare richieste che si accumulano o ricevono conferme troppo rapide per una valutazione utile.

Se le conferme diventano meccaniche, rivedi le soglie. Per un’azione davvero ripetitiva puoi delimitare un’autorizzazione a comando, parametri e risorsa precisi, con durata e revoca definite. Le operazioni il cui effetto richiede ogni volta un giudizio sul caso concreto devono invece restare soggette a una nuova decisione.