Articolo
Agenti AI: governare per livello di autonomia
Quando un team parla di agenti, la conversazione finisce quasi sempre sul modello o sul vendor. Ha senso solo in superficie. Lo stesso modello può restare confinato a leggere e sintetizzare, oppure avere il permesso di toccare dati, aprire ticket, inviare messaggi, cambiare stati o avviare flussi. Il problema vero non è quale motore c’è sotto. È quanta autonomia gli stai dando.
Il 26 maggio 2026 Gartner ha scritto che applicare la stessa governance a tutti gli agenti, senza distinguere tra capacità di azione e perimetro di accesso, porta facilmente al fallimento. È una distinzione utile anche per team piccoli. Un agente non si governa in base al nome del modello, ma in base a cosa può vedere, cosa può cambiare e quanto costa un errore.
Il modello non è il confine
Il modello è solo una parte del sistema. Il confine vero è la superficie dei permessi: che cosa può leggere, che cosa può scrivere, che cosa può inviare, che cosa può cancellare, che cosa può avviare. Un agente che legge documenti interni non ha lo stesso impatto di un agente che può modificare record, inviare email ai clienti o far partire un workflow di pagamento.
Qui entra un altro concetto che vale più del nome del vendor: blast radius. Se l’agente sbaglia, quanto si allarga il danno? Un errore su un riassunto interno è fastidioso. Un errore su un permesso, su un importo o su uno stato operativo può diventare costoso in pochi minuti.
La governance utile parte da qui. Non da “questo modello è più bravo”. Da “questo agente può fare solo lettura”, oppure “può proporre un’azione”, oppure “può eseguirla solo dopo approvazione”, oppure “può agire da solo entro un perimetro stretto e reversibile”.
È la stessa logica operativa dietro le code per agenti e il model routing per l’AI coding: l’autonomia va assegnata a una classe di task, non all’entusiasmo intorno a un modello.
Quattro livelli di autonomia
Io terrei il framework semplice. Quattro livelli bastano per decidere quasi tutto.
| Livello | Cosa fa | Controllo richiesto |
|---|---|---|
| Osserva | legge, classifica, riassume | review minima |
| Suggerisce | propone azioni o decisioni | approvazione umana |
| Agisce con approvazione | prepara un’azione e chiede conferma | approvazione per ogni step |
| Agisce da solo | esegue compiti reversibili in un perimetro stretto | logging, limiti, fallback |
La cosa importante è che il livello non dipende solo dal modello. Dipende dal contesto operativo. Lo stesso agente può stare a livello 1 in un flusso finance e a livello 4 in un flusso di reportistica interna, se il perimetro cambia e il danno massimo resta contenuto.
Per questo parlare solo di “agenti sì” o “agenti no” serve a poco. La decisione vera è molto più concreta: questo agente deve leggere, consigliare o agire?
Le domande giuste prima di attivarlo
Prima di dare autonomia a un agente, io chiederei quattro cose.
- Cosa può vedere?
- Cosa può cambiare?
- Cosa succede se sbaglia?
- Chi lo ferma, e come?
Se la risposta a una di queste domande è vaga, l’agente non dovrebbe uscire da osserva o suggerisce. Non perché l’AI sia per definizione pericolosa, ma perché il team non ha ancora definito il suo perimetro.
Qui la differenza tra un team maturo e uno che sta improvvisando è molto semplice. Il primo scrive le regole prima di aumentare l’autonomia. Il secondo le scrive dopo il primo incidente.
Stesso modello, rischi diversi
Questo è il punto che spesso si perde quando si discute di vendor. Il modello non determina da solo il rischio. Lo determinano accesso, contesto, integrazioni e reversibilità delle azioni. Un assistente che riscrive una bozza email non ha lo stesso peso di un agente che può toccare un CRM, un sistema di fatturazione o un workflow di approvazione.
Per questo la domanda utile non è “quale modello usiamo?”. È “quale livello di autonomia siamo disposti a concedere, su quale sistema, per quale task, con quale fallback?”. Una volta che il team sa rispondere, la scelta del modello diventa un dettaglio importante, ma non il centro della decisione.
Il bello di questo approccio è che funziona sia per founder piccoli sia per organizzazioni più strutturate. Non richiede un comitato. Richiede chiarezza su permessi, conseguenze e responsabilità.
Cosa fare in pratica
Se un team vuole introdurre agenti senza creare caos, io partirei da tre mosse.
- Mappare i task per livello di autonomia, non per tipo di modello.
- Definire per ogni task la superficie dei permessi e il blast radius massimo accettabile.
- Tenere un livello di review umano finché l’agente non ha dimostrato di fallire in modo leggibile e reversibile.
Questa è la parte meno glamour del lavoro, ma è quella che tiene in piedi il sistema. Gli agenti diventano utili quando smettiamo di trattarli come demo e cominciamo a trattarli come parti di un processo.
Se non sai spiegare il livello di autonomia di un agente in una frase, non hai ancora una governance. Hai solo un nome più elegante per un’automazione.