Agenti con strumenti: come progettare permessi, memoria e recupero dagli errori senza cedere il controllo

Dal chatbot all’agente: autonomia situata, non fiducia cieca

Un agente non è semplicemente un assistente che risponde in una conversazione. In una definizione operativa utile alla progettazione, combina un modello che interpreta un’attività con uno stato di esecuzione, accesso a strumenti, una politica che delimita le decisioni consentite e un ciclo che osserva i risultati e decide il passo successivo. Può consultare un database, aprire un ticket, cercare informazioni, aggiornare un record o invocare un’API. La differenza rilevante non è che il modello “ragioni”, ma che il sistema può influire su altri sistemi oltre la finestra di chat.

Questa distinzione obbliga a spostare la domanda iniziale. Non è opportuno partire da «quale modello ottiene i risultati migliori?», bensì da «che cosa può fare questo sistema, con quale identità, su quali risorse e a quale condizione?». La capacità di un modello può aiutare a completare un’attività, ma non sostituisce limiti di autorizzazione, validazione del risultato o supervisione. Questa conclusione vale anche leggendo le analisi di GPT‑6 Astra, Claude Opus 5 o Gemini 3.8 Flash: una capacità dichiarata o misurata più elevata non elimina la necessità di controlli operativi.

Non tutte le attività richiedono un agente autonomo. Un flusso fisso, con passaggi prevedibili e poche eccezioni, può essere risolto meglio mediante automazione convenzionale o un workflow in cui il modello si limita a classificare o a redigere una proposta. L’autonomia aggiuntiva deve essere giustificata dalla variabilità dell’attività e dalla capacità di contenerne gli effetti. Come regola iniziale, un’azione esterna deve essere più limitata di una consultazione, e una modifica difficile da annullare deve richiedere più evidenze e maggiore supervisione rispetto a un’azione reversibile.

La scheda di ingresso consigliata per la pagina matrice è «Agenti: progettazione, valutazione e supervisione». Da quella pagina, questa guida deve essere presentata come un quadro di architettura e decisione, non come una ricetta universale né come un confronto fra fornitori.

Prima di collegare uno strumento: classificare l’impatto di ogni azione

Uno strumento non dovrebbe essere abilitato soltanto perché sembra utile in una dimostrazione. Deve avere una scheda dell’azione: finalità, sistemi interessati, dati ricevuti, identità utilizzata, operazioni consentite, limiti di volume, effetto reversibile o irreversibile, dipendenza esterna e responsabile umano. Questa scheda rende visibile una differenza spesso nascosta: “consultare ordini” e “annullare ordini” possono usare la stessa API, ma non rappresentano lo stesso rischio.

La classificazione può combinare quattro assi. L’impatto stima il danno nel caso in cui l’azione sia errata; la reversibilità determina se possa essere annullata in sicurezza; la portata misura quanti account, record o sistemi potrebbero essere coinvolti; la sensibilità valuta i dati o i segreti esposti. Un quinto asse pratico è l’ambiguità: se la richiesta ammette più interpretazioni ragionevoli, l’azione non dovrebbe essere eseguita in autonomia, anche se ciò è tecnicamente possibile.

Le comunicazioni esterne meritano una categoria propria. Inviare un’email a un cliente, pubblicare una risposta o creare una segnalazione può essere reversibile in senso tecnico, ma non necessariamente sul piano reputazionale, contrattuale o della privacy. Lo stesso vale per le modifiche in produzione: disporre di un’operazione di rollback non rende innocuo un rilascio errato. In questi casi, la progettazione deve prevedere revisione del contenuto, del destinatario, della portata e del momento di esecuzione.

Nel primo terzo dell’implementazione è opportuno collegare questa classificazione alla guida sulle «azioni irreversibili e approvazioni», quando sarà pubblicata. L’obiettivo è che l’approvazione non sia un generico gesto di conferma, ma una decisione informata su un’azione concreta, i suoi parametri e le sue possibili conseguenze.

Permessi di minimo privilegio: controlli che non dipendono dal testo del modello

Il minimo privilegio consiste nel concedere soltanto i permessi necessari per un’attività definita, per il tempo necessario e sulle risorse necessarie. Negli agenti, ciò richiede di andare oltre un token generale con accesso esteso. Una credenziale che permette di leggere, modificare ed eliminare tutte le risorse trasforma un output errato, un’istruzione manipolata o un errore di integrazione in un incidente di ampia portata.

Una pratica solida consiste nel separare le identità per strumento, ambiente e finalità. L’agente di assistenza non dovrebbe usare la stessa identità del processo di rilascio, e un’identità di test non dovrebbe avere accesso alla produzione. Le credenziali a breve durata riducono la finestra di esposizione, ma non correggono da sole un’autorizzazione eccessiva: servono anche ambiti di accesso specifici, quote, restrizioni di rete e validazione lato server.

Lo strumento deve verificare l’autorizzazione in modo deterministico. È preferibile un’interfaccia che esponga operazioni concrete — per esempio, creare una bozza di risposta per un caso assegnato — rispetto a un’interfaccia generica che consenta di eseguire query o comandi arbitrari. Quando il sistema usa elenchi di risorse consentite, importi massimi o ruoli, tali limiti devono essere applicati fuori dal contesto che il modello può modificare. Le istruzioni nel prompt possono orientare; non costituiscono un confine di sicurezza sufficiente.

I connettori devono trattare tutti i contenuti ricevuti da pagine, documenti, email, ticket e risposte degli strumenti come dati potenzialmente non affidabili. Il fatto che un testo contenga un ordine non gli conferisce autorità. La politica delle azioni, l’identità di servizio e il validatore dei parametri devono prevalere su qualsiasi istruzione trovata durante l’attività.

Questa sezione deve collegarsi, quando disponibile, a «dati sensibili e credenziali». Per i team che trattano dati personali, la minimizzazione implica anche evitare di fornire allo strumento più attributi di quelli necessari per completare l’azione e definire chi possa accedere ai registri risultanti.

Quando richiedere un umano nel circuito

La revisione umana è più utile quando è integrata in un punto decisionale definito. Richiedere conferma per ogni consultazione a basso rischio rallenta il lavoro e favorisce approvazioni meccaniche; non richiederla per azioni rilevanti trasferisce l’onere di rilevare l’errore a chi ne subisce gli effetti. La progettazione deve fissare soglie esplicite e mostrare al revisore le informazioni necessarie per decidere.

Un’approvazione dovrebbe mostrare l’azione prevista, i parametri finali, i sistemi interessati, l’identità che la eseguirà, la giustificazione generata dall’agente e l’effetto dell’approvazione o del rifiuto. Se l’azione dipende da fatti incerti, l’interfaccia deve mostrare anche questa incertezza invece di presentare una raccomandazione come se fosse una verifica. Approvare un intento astratto, come “risolvere il caso”, è meno sicuro che approvare un’operazione delimitata, come “inviare questa bozza a questo destinatario”.

Dovrebbero passare per revisione umana, come punto di partenza, le cancellazioni, i pagamenti o gli impegni economici, le modifiche in produzione, le comunicazioni esterne, le modifiche ai permessi, il trattamento di categorie particolarmente sensibili e le operazioni la cui richiesta sia ambigua. L’organizzazione può aggiungere soglie di importo, numero di record o gravità operativa. Tali soglie sono decisioni di politica interna: non esiste una cifra universale che renda sicura un’azione.

La supervisione umana non deve neppure essere intesa come una scusa per disinteressarsi del sistema. Il revisore deve avere un’autorità effettiva per rifiutare, correggere ed effettuare escalation; formazione sul processo; e un carico di lavoro che consenta di esaminare davvero le richieste. Se riceve centinaia di richieste quasi identiche, il controllo può trasformarsi in una formalità.

Memoria utile senza conservazione indefinita

La memoria può migliorare la continuità di un’attività, ma aumenta anche la superficie di privacy, il rischio di usare informazioni obsolete e la difficoltà di correggere gli errori. È opportuno distinguere almeno tra contesto di sessione, stato operativo di un’attività, preferenze persistenti autorizzate, conoscenza recuperata da fonti documentali e registri di audit. Queste categorie perseguono finalità diverse e non dovrebbero condividere automaticamente gli stessi tempi di conservazione né gli stessi permessi.

Il contesto di sessione serve a mantenere coerenza durante un’interazione e di solito scade al suo termine o dopo un periodo breve. Lo stato operativo conserva le informazioni necessarie per riprendere un lavoro, come un riferimento al caso o un checkpoint. Le preferenze persistenti richiedono una finalità chiara, una provenienza nota e un meccanismo di consultazione e correzione. La conoscenza recuperata deve conservare origine, versione e data, affinché il sistema possa rilevare se la fonte è stata sostituita o invalidata.

La provenienza è importante quanto il contenuto. Se una memoria proviene da un utente, da un sistema aziendale o da un’inferenza dell’agente stesso, il sistema dovrebbe distinguerlo. Un’inferenza non verificata — per esempio una priorità o una preferenza dedotta — non deve essere trattata come un dato confermato. Inoltre, una memoria persistente non dovrebbe diventare una via per conservare segreti, dati irrilevanti o istruzioni introdotte da contenuti esterni.

Prima di memorizzare, occorre rispondere a quattro domande: quale finalità concreta copre, chi può leggerla, quando scade e come viene invalidata. La futura guida su «memoria, conservazione e scadenza» potrà sviluppare queste politiche. In ambito europeo, se la memoria contiene dati personali, la sua progettazione deve essere valutata nel quadro degli obblighi applicabili in materia di protezione dei dati; questa guida non sostituisce l’analisi giuridica né determina da sola la base di liceità di un trattamento.

Progettare per il fallimento: fermare, verificare e recuperare

I guasti degli strumenti, delle reti e delle dipendenze esterne sono normali. Lo sono anche le risposte incomplete, i timeout e gli stati ambigui: una chiamata può essere arrivata al sistema ricevente anche se l’agente non ha ricevuto conferma. Una progettazione robusta non presuppone che “riprovare” sia sempre sicuro. Deve prima sapere quale operazione sia stata tentata, quale risultato sia stato confermato e quali operazioni possano essere ripetute senza modificare l’effetto finale.

La semantica HTTP distingue le operazioni idempotenti, il cui effetto previsto è lo stesso dopo una o più richieste identiche, da quelle che non lo sono. Questa distinzione aiuta a progettare i tentativi ripetuti, ma non elimina la necessità di controllare lo stato aziendale. Una richiesta tecnicamente idempotente può comunque avere conseguenze non previste se i suoi parametri sono errati. Per operazioni di creazione, pagamento o invio, una chiave di idempotenza e una verifica dello stato prima di riprovare sono in genere controlli più appropriati che ripetere ciecamente la chiamata.

L’agente necessita di condizioni di arresto. Occorre fissare un numero limitato di tentativi, timeout, un budget di chiamate e criteri di escalation. Dopo il superamento di una soglia, il caso deve entrare in una coda di revisione con il contesto minimo necessario: azione prevista, identificatore di correlazione, risposte ricevute e passaggi già compiuti. Riprovare indefinitamente può amplificare un incidente esterno o generare azioni duplicate.

Ogni azione rilevante dovrebbe avere un checkpoint prima del suo effetto irreversibile e, quando praticabile, un piano di compensazione. Una compensazione non equivale sempre a un rollback perfetto: rimborsare un importo non cancella una comunicazione già inviata, e ripristinare un record non elimina una possibile divulgazione. La documentazione del recupero deve dichiarare esplicitamente questi limiti.

Osservabilità e audit senza raccogliere dati non necessari

L’osservabilità consente di ricostruire ciò che è accaduto; non richiede di conservare senza limiti ogni dato scambiato. Per un’azione rilevante, il registro dovrebbe associare la richiesta iniziale, la politica applicata, gli strumenti selezionati, i parametri autorizzati o una loro rappresentazione protetta, l’identità di esecuzione, il risultato, i tentativi ripetuti e l’intervento umano. Gli identificatori di correlazione permettono di seguire un caso tra componenti diversi senza dover copiare il contenuto completo in tutti i registri.

I registri devono essere protetti come una risorsa sensibile. Se includono prompt, risposte, documenti o parametri, possono contenere informazioni personali, segreti o istruzioni non affidabili. Per questo richiedono controlli di accesso, tempi di conservazione definiti, separazione degli ambienti e meccanismi che impediscano modifiche silenziose. È inoltre utile distinguere il registro operativo, destinato a rilevare i guasti, dal registro di audit, orientato a indagare una decisione; possono richiedere livelli di dettaglio e di accesso differenti.

Una buona ricostruzione separa i fatti dall’interpretazione. Deve essere possibile sapere quale dato abbia restituito uno strumento, quale regola abbia bloccato o consentito un’operazione e quale raccomandazione abbia formulato il modello. Non è ragionevole promettere una spiegazione completa di ogni comportamento del modello, ma è possibile registrare la catena delle decisioni programmatiche e gli artefatti operativi che determinano se un’azione sia stata eseguita.

La minimizzazione non è soltanto un obbligo di privacy; migliora la sicurezza e l’utilità dei registri. Un log eccessivo rende più difficile trovare segnali rilevanti e amplia l’insieme di dati esposti in caso di accesso indebito.

Valutare prima del rilascio: attività, permessi e recupero

La valutazione deve riprodurre l’ambiente decisionale, non limitarsi a misurare la qualità di una risposta testuale. Un piano minimo combina attività rappresentative, casi limite, errori degli strumenti, richieste ambigue, tentativi di introdurre istruzioni attraverso contenuti esterni e verifiche di autorizzazione. Il criterio di successo deve comprendere sia il completamento corretto di un’attività consentita, sia il rifiuto di un’azione vietata, l’arresto in presenza di incertezza e l’escalation quando appropriata.

I benchmark sono utili per confrontare determinate capacità in condizioni definite. Terminal-Bench valuta la risoluzione di attività in ambienti di terminale isolati, mentre OSWorld raccoglie attività su applicazioni web e desktop in ambienti reali di valutazione. Queste misurazioni possono fornire segnali sulle prestazioni di un agente in tali attività, ma non certificano che la sua identità disponga di permessi corretti, che protegga i dati di un’organizzazione o che si riprenda in modo sicuro in una specifica integrazione.

Per questo, quando disponibili, occorre includere collegamenti a Terminal-Bench e OSWorld con un testo che chiarisca che i benchmark non sostituiscono i test nel proprio ambiente. I test interni necessitano di account di prova, dati sintetici o adeguatamente controllati, simulazione delle dipendenze e casi di recupero. Devono anche verificare che un rifiuto di autorizzazione non attivi percorsi alternativi più permissivi.

Un quadro di gestione dei rischi può aiutare ad assegnare responsabili, documentare decisioni e riesaminare i controlli lungo il ciclo di vita. Non sostituisce la specifica tecnica di ogni permesso. Le evidenze dei test, gli incidenti e le modifiche agli strumenti devono alimentare revisioni periodiche della matrice di autonomia.

Modello finale: decidere il livello di autonomia

La decisione sull’autonomia deve poter essere riesaminata come una politica, non rimanere implicita in un prompt. Per ogni strumento e azione, documentare la categoria di rischio, i dati coinvolti, il permesso concreto, l’identità, i limiti, la necessità di approvazione, la strategia di recupero, i registri e il proprietario. Se uno di questi elementi non è definito, l’autonomia assegnata è probabilmente prematura.

Un punto di partenza ragionevole è usare quattro livelli. Il livello di sola lettura consente di consultare risorse autorizzate. Il livello di proposta con approvazione consente di indagare e preparare un’azione, ma riserva l’esecuzione a una persona. Il livello di esecuzione limitata abilita operazioni reversibili e circoscritte secondo regole deterministiche. Il livello di esecuzione autonoma è riservato ad azioni a basso impatto, di portata ridotta, con rollback o compensazione noti, supervisione disponibile ed evidenze di test sufficienti.

La matrice non deve essere permanente. Un incidente, un cambio di fornitore, un nuovo strumento, un ampliamento dei dati accessibili o una modifica della politica aziendale giustificano una revisione. Allo stesso modo, un agente può iniziare in modalità proposta e acquisire autonomia soltanto dopo aver dimostrato un comportamento affidabile entro un perimetro misurato. Ridurre l’autonomia dopo un’anomalia è una risposta di controllo, non un fallimento del progetto.

Come passaggio editoriale successivo, la chiusura può collegarsi a «decidere se automatizzare un flusso». La domanda decisiva non è se un agente possa eseguire un’attività, ma se l’organizzazione possa delimitarne, osservarne e recuperarne gli effetti con un livello di rischio accettabile.

Ambito e incertezze

Questa guida presenta un quadro tecnico e operativo basato su fonti istituzionali, documentazione tecnica e guide alla costruzione di agenti fornite. Le sue raccomandazioni architetturali non garantiscono di per sé la sicurezza di un caso d’uso né sostituiscono test, analisi delle minacce, revisione della privacy, controlli settoriali o consulenza legale.

L’applicazione del Regolamento generale sulla protezione dei dati dipende dalle circostanze del trattamento, dai ruoli delle parti e da altri requisiti applicabili. In particolare, la guida non stabilisce se un caso concreto rientri nelle regole sulle decisioni individuali basate unicamente su un trattamento automatizzato, né quali salvaguardie aggiuntive siano necessarie. Non copre neppure obblighi nazionali, del lavoro, finanziari, sanitari o contrattuali che possano essere rilevanti.

Le caratteristiche di strumenti, modelli, API e benchmark cambiano rapidamente. Prima del rilascio, il team deve confermare la versione valutata, il comportamento delle integrazioni, i permessi effettivi e le condizioni di esecuzione. Le evidenze di un ambiente di test non devono essere estrapolate automaticamente alla produzione.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.