Agenti AI: servono permessi, non accesso totale

Gli agenti AI hanno bisogno di permessi sui tool, non di accesso totale. Questa è la tesi. Quando un agente interno può cercare documenti, aggiornare record, inviare messaggi, creare ticket, leggere dati cliente e attivare workflow, il rischio non sta solo nel modello. Sta nel perimetro operativo che gli abbiamo consegnato senza decidere quali azioni meritano quali limiti.

La spinta ad aprire tutto è comprensibile. Product e operations vogliono ridurre passaggi manuali, colli di bottiglia e attese tra sistemi. Un agente con più integrazioni sembra più autonomo. Recupera contesto, sceglie il passo successivo, chiama un servizio e restituisce un esito. Ma in produzione più accesso non significa automaticamente più automazione. Spesso significa solo un raggio d’impatto più ampio.

La conversazione di governance non dovrebbe partire dal vendor, dal modello o dal framework di orchestrazione. Dovrebbe partire da una matrice dei permessi: tool, azione, perimetro dei dati, livello di rischio, modalità di approvazione, requisito di logging e owner di fallback. Prima di aggiungere una nuova integrazione, conviene auditare una toolchain già attiva.

L’accesso ai tool non è un dettaglio tecnico

Un agente collegato ai tool non è una chat con qualche plugin. È un attore dentro un sistema operativo aziendale. Può trasformare informazioni in azioni, spesso più velocemente di quanto il team riesca a controllare ogni passaggio. La domanda quindi cambia: non più “può farlo?”, ma “in quali condizioni deve poterlo fare?”

Il Model Context Protocol aiuta a rendere esplicita questa distinzione perché separa tool, risorse, prompt, client, host e server. La specifica MCP descrive i tool come funzioni che il modello può eseguire e richiama principi come consenso dell’utente, controllo, privacy dei dati e sicurezza dei tool. La lezione operativa è chiara: esporre una capacità non equivale a governarne l’uso.

Nelle implementazioni interne, la scorciatoia pericolosa è approvare un’integrazione nel suo complesso. “L’agente di supporto ha accesso a Zendesk” è una frase troppo generica. Può solo leggere ticket? Può aggiungere note interne? Può rispondere al cliente? Può cambiare priorità? Può avviare un rimborso? Ognuna di queste azioni ha un profilo di rischio diverso.

Per questo il design degli agenti deve collegarsi al design delle code operative. In Agenti AI: servono code operative, non solo prompt, il punto è che il lavoro va messo in fila, instradato e assegnato. I permessi sui tool sono lo strato di accesso dello stesso principio. La coda decide quale lavoro arriva all’agente. La matrice dei permessi decide cosa può fare l’agente quando quel lavoro arriva.

Cosa deve contenere una matrice dei permessi?

Una matrice dei permessi non deve diventare un documento pesante. Deve essere abbastanza concreta da far vedere lo stesso sistema a product, operations, security ed engineering. Il formato più utile è una riga per ogni azione del tool, non una riga generica per ogni tool.

Le colonne minime sono queste:

1. Tool: il sistema chiamato, per esempio CRM, ticketing, billing, warehouse, email, analytics o ricerca documentale.
2. Azione: l’operazione precisa, come leggere, sintetizzare, scrivere una bozza, commentare, aggiornare, cancellare, inviare, rimborsare, escalare o creare.
3. Perimetro dei dati: record, campi, account, segmenti, intervalli temporali o repository accessibili.
4. Livello di rischio: basso, medio, alto o critico, valutando reversibilità, impatto sul cliente, esposizione privacy, impatto economico e dipendenza operativa.
5. Modalità di approvazione: automatica, review umana prima dell’esecuzione, review dopo l’esecuzione, doppia approvazione o azione bloccata.
6. Requisito di logging: cosa va registrato, inclusi input, contesto recuperato, tool call, output, identità dell’approvatore, timestamp e stato finale del sistema.
7. Owner di fallback: team o ruolo responsabile quando l’agente non può procedere in sicurezza.

La mossa importante è separare “preparare una bozza” da “inviare”, “leggere” da “scrivere” e “suggerire” da “eseguire”. Un agente di sales operations può proporre aggiornamenti CRM a partire dalle note di una call, ma non dovrebbe cambiare lo stage di un’opportunità senza controllo. Un agente di supporto può sintetizzare l’idoneità a un rimborso, ma non emettere rimborsi oltre una soglia. Un agente finance può riconciliare metadati di fattura, ma non modificare istruzioni di pagamento.

Qui la governance dell’autonomia diventa concreta. In Agenti AI: governare per livello di autonomia, l’autonomia è trattata come una scelta di prodotto. La matrice dei permessi trasforma quella scelta in regole operative. Evita che un team dica “l’agente è supervisionato” mentre gli concede scritture non supervisionate su sistemi sensibili.

Dove devono stare approvazione e logging?

L’approvazione deve stare nel punto in cui cambia il rischio. Il logging deve stare in ogni punto in cui, dopo un’anomalia, il team avrebbe bisogno di prove.

Sembra ovvio finché non succede il primo incidente. Se un agente legge un articolo di help center e prepara una risposta, può bastare un logging leggero. Se invia quella risposta al cliente, servono testo finale, fonti usate, tool call e identità dell’attore o approvatore. Se modifica un’impostazione dell’account, serve lo stato prima e dopo. Se tocca dati personali o regolati, servono tracce ancora più chiare di accesso e finalità.

L’osservabilità non serve solo a guardare la latenza. La documentazione Langfuse descrive il tracing per applicazioni LLM, incluse chiamate LLM e non LLM come retrieval e API call, sessioni per workflow multi-step e grafi degli agenti. Questo conta perché i problemi degli agenti spesso si nascondono nella sequenza, non in una singola risposta. Il modello può scegliere un’azione plausibile, recuperare contesto obsoleto, chiamare il tool sbagliato o riuscire tecnicamente creando però un’eccezione operativa.

Un buon log deve rispondere a sei domande: cosa ha visto l’agente, cosa ha deciso, cosa ha chiamato, cosa è cambiato, chi ha approvato e chi deve rimediare se qualcosa non torna. Se non puoi rispondere, l’agente sta operando oltre la tua capacità di governo.

L’approvazione non dovrebbe essere un pop-up generico che le persone imparano a cliccare senza leggere. Deve seguire il rischio. Le azioni di lettura a basso rischio possono essere automatiche. Le scritture a rischio medio possono richiedere review prima dell’esecuzione. Le azioni ad alto rischio possono richiedere doppio controllo, soglie o passaggio obbligatorio a una coda umana. Le azioni critiche possono restare escluse finché l’organizzazione non ha controlli più solidi.

Parti dal tool più rischioso

Non serve mappare tutto in una volta. Scegli un agente già attivo e individua il tool che potrebbe creare il danno maggiore se usato male. In molte aziende sarà billing, CRM, identity, messaggistica cliente, operations di produzione o qualunque sistema con dati personali sensibili.

Poi elenca le azioni che l’agente può davvero eseguire. Se la risposta è “non lo sappiamo”, hai già trovato il primo problema. Se la risposta è “dipende dal prompt”, non hai un modello di permessi. I prompt possono guidare il comportamento, ma non dovrebbero essere l’unico confine tra un modello e un’operazione rischiosa.

Classifica ogni azione. Leggere una knowledge base pubblica non è come leggere note private sui clienti. Preparare una bozza non è come inviarla. Creare un task non è come chiudere un incidente. Aggiornare un campo usato per reporting non è come aggiornare un campo usato per fatturazione.

Poi decidi il controllo. Alcuni permessi possono essere rimossi subito. Alcuni possono essere ristretti per perimetro dati. Alcuni possono restare automatici perché l’azione è reversibile e a basso impatto. Alcuni richiedono approvazione umana. Alcuni richiedono logging migliore prima di restare in produzione.

Questo si collega al design degli errori. L’automazione AI ha bisogno di classi di errore sostiene che non ogni fallimento merita lo stesso retry. I permessi seguono la stessa logica. Non ogni azione merita lo stesso accesso.

Audita prima di integrare

La call to action è volutamente piccola: audita una toolchain di un agente prima di aggiungere un’altra integrazione.

Apri un foglio. Inserisci le colonne tool, azione, perimetro dati, rischio, approvazione, logging e owner di fallback. Compilalo con le capacità reali di un agente. Non descrivere solo il percorso felice. Includi edge case: dati mancanti, record in conflitto, intenzione ambigua del cliente, retrieval obsoleto, errori di permesso e istruzioni avversarie dentro contenuti forniti dagli utenti.

Di solito emergeranno tre tipi di lavoro. Primo, permessi troppo ampi da ridurre. Secondo, azioni che richiedono approvazione umana perché il costo operativo di un errore è alto. Terzo, log insufficienti per debugging, accountability o recupero verso il cliente.

Non è burocrazia. È il modo in cui l’automazione diventa sostenibile. L’agente non diventa meno utile perché ha confini. Diventa utile nei contesti in cui l’organizzazione può fidarsi dell’esito, ispezionare il percorso e rimediare quando il percorso è sbagliato.

L’accesso totale è una scorciatoia. I permessi sui tool sono un modello operativo.