L'autonomia degli agenti AI è la variabile di cui nessuno parla in fase di acquisto e che decide tutto in fase di esercizio. Un agente non è rischioso perché è intelligente: è rischioso perché agisce. Scrive su un file, manda una mail, aggiorna un record nel gestionale, chiama un'API a pagamento. La domanda giusta quindi non è "quanto è bravo", ma "cosa succede quando sbaglia".
In Studiollice costruiamo una flotta di agenti verticali che ogni giorno pubblicano, rispondono e sorvegliano sistemi senza che nessuno prema un pulsante. La parte difficile non è concedere autonomia: è disegnarne i confini in modo che siano imposti dal sistema e non semplicemente dichiarati in un documento.
Autonomia degli agenti AI: il rischio ha un nome tecnico
Il settore lo chiama excessive agency, eccesso di delega. È la voce LLM06 della classifica OWASP dei rischi dei sistemi basati su modelli linguistici, e descrive esattamente questo: un sistema a cui è stata data più capacità, più permessi o più autonomia di quanti gliene servano per fare il suo lavoro. Il danno arriva quando l'agente compie un'azione dannosa in risposta a un output inatteso, allucinato o manipolato.
Il punto chiave è che OWASP non lo classifica come un problema di accuratezza del modello, ma come un difetto di privilegi e di controllo. Cambia tutto: non lo risolvi aspettando un modello migliore, lo risolvi progettando meglio l'accesso. Inoltre l'eccesso di delega è il moltiplicatore di ogni altro rischio, a partire dalla prompt injection: chi riesce a dirottare le istruzioni di un agente eredita tutti i permessi che quell'agente possiede. Se ne ha pochi, l'attacco è un fastidio. Se ne ha troppi, è un incidente.
Le tre domande che delimitano un agente
OWASP scompone l'eccesso di delega in tre cause distinte, e ognuna corrisponde a una domanda molto concreta da fare a chi vi propone un'automazione.
- Funzioni in eccesso. L'agente ha strumenti che non gli servono. Domanda: quali strumenti può usare, uno per uno? Un agente che deve leggere le mail e classificarle non ha bisogno della funzione "invia". Un agente che scrive articoli non ha bisogno di cancellarli.
- Permessi in eccesso. L'agente usa credenziali più larghe del necessario. Domanda: con quale utenza si collega ai vostri sistemi? Troppo spesso la risposta è "con quella di un amministratore", perché così funziona subito. È la scorciatoia che trasforma un errore banale in un danno esteso.
- Autonomia in eccesso. L'agente compie azioni ad alto impatto senza che nessuno confermi. Domanda: quali azioni fa senza chiedere? Questa è la lista che va scritta, letta e approvata prima di andare in produzione.
Tre domande, tre risposte scritte. Se un fornitore risponde "ci pensa l'AI", non avete un agente: avete una delega in bianco.
Un permesso si scrive nel sistema, non si chiede al modello
C'è un equivoco che vediamo ripetersi spesso: pensare che scrivere nelle istruzioni "non cancellare niente" equivalga a impedirgli di cancellare. Non è la stessa cosa. Le istruzioni orientano il comportamento; i permessi lo limitano. La documentazione di Claude Code lo dice in modo netto: le regole di permesso sono applicate dal programma, non dal modello, e le istruzioni scritte nel prompt influenzano ciò che l'agente prova a fare, non ciò che gli è consentito.
Il modello di riferimento è semplice ed è replicabile su qualsiasi automazione, non solo su quelle Anthropic. Ogni azione passa per tre liste valutate in ordine: prima nega, poi chiedi, infine consenti. Il primo riscontro decide. Una regola di divieto ampia batte sempre un'autorizzazione più specifica, quindi non esistono eccezioni nascoste dentro un divieto. Inoltre, negare un intero strumento non si limita a bloccarlo: lo rimuove dalla vista dell'agente, che quindi non prova nemmeno a usarlo.
Tradotto per un'azienda: l'elenco di ciò che il vostro agente può fare deve esistere come file di configurazione, versionato e leggibile, non come paragrafo in un preventivo. È la differenza tra una promessa e un vincolo.
Dove mettere la persona: la scala della reversibilità
La supervisione umana non va messa ovunque, altrimenti l'automazione non fa risparmiare niente e le conferme diventano clic automatici. Va messa dove serve. Il criterio più solido che abbiamo trovato è ordinare le azioni per quanto costa tornare indietro.
- Reversibili e interne (classificare una mail, preparare una bozza, aggiornare un campo di lavoro): autonomia piena, nessuna conferma. Qui l'agente deve correre.
- Reversibili ma visibili all'esterno (pubblicare un contenuto, aggiornare una scheda prodotto): autonomia con registro delle azioni e possibilità di ripristino rapido.
- Irreversibili o con effetto su terzi (inviare una comunicazione a un cliente, emettere un documento contabile, disporre un pagamento, cancellare dati): conferma umana obbligatoria, sempre.
Anche Anthropic, nella sua guida alla costruzione di agenti efficaci, mette due paletti che valgono per chiunque: gli agenti vanno collaudati a fondo in ambienti isolati prima della produzione, e devono fermarsi per un riscontro umano ai punti di controllo o quando incontrano un ostacolo. Un agente autonomo che non sa fermarsi non è più autonomo: è solo più difficile da correggere.
Tuttavia la conferma umana funziona solo se la persona vede davvero cosa sta approvando. Per questo la supervisione va insieme al monitoraggio dell'automazione: senza un registro leggibile di ciò che l'agente ha fatto ieri, l'approvazione diventa un rituale.
Cosa chiede la legge: l'articolo 14 dell'AI Act
Per i sistemi classificati ad alto rischio, la supervisione umana non è più una scelta di progetto ma un obbligo. L'articolo 14 dell'AI Act europeo richiede che i sistemi siano progettati per poter essere «effettivamente supervisionati da persone fisiche» durante l'uso. E specifica cosa deve poter fare chi supervisiona: comprendere capacità e limiti del sistema, accorgersi delle anomalie, interpretarne correttamente gli esiti, decidere di non usarlo o di ribaltarne il risultato, e disporre di un pulsante di arresto che porti il sistema a fermarsi in condizioni di sicurezza.
C'è un punto che merita attenzione anche fuori dai casi ad alto rischio: la norma chiede che il supervisore resti consapevole della «tendenza a fare automaticamente affidamento» sugli esiti prodotti dal sistema. È il pregiudizio di automazione, e nella pratica è il vero nemico della supervisione: dopo trenta approvazioni identiche, la trentunesima non la legge più nessuno. Per questo conviene tenere corta la lista delle azioni che richiedono conferma: poche, importanti, davvero lette.
Da dove parte un'azienda
Non serve un progetto di governance da manuale. Servono tre passi, nell'ordine.
Primo: scrivete l'elenco delle azioni che il vostro agente può compiere, con il verbo esatto — legge, scrive, invia, cancella, paga. Se l'elenco non sta in una pagina, l'ambito è troppo largo. Secondo: date all'agente un'utenza dedicata con i soli permessi di quell'elenco, mai le credenziali di un amministratore. Terzo: marcate le azioni irreversibili e mettete lì la conferma umana, lasciando correre tutto il resto.
Fatto questo, l'autonomia degli agenti AI smette di essere un atto di fiducia e diventa una scelta progettuale, misurabile e modificabile. È la stessa disciplina che applichiamo alla nostra flotta: ogni agente ha un perimetro scritto, un registro delle azioni e un punto in cui si ferma e chiede.
Studiollice progetta agenti e automazioni su misura, con permessi definiti processo per processo. Se state valutando la prima automazione, il confine si disegna prima di scrivere il codice: è la parte che costa meno oggi e vale di più domani.