Un agente AI che scrive una bozza di email commerciale e un agente AI che invia quella email sono due cose radicalmente diverse. Il primo sbaglia? Correggi. Il secondo sbaglia? Hai già spedito a tremila clienti un messaggio con un prezzo errato, un tono sbagliato o, peggio, informazioni riservate.
Questa distinzione sembra ovvia. Eppure la maggior parte delle aziende che oggi integra agenti AI nei propri processi non la presidia in modo esplicito. Si lavora per casi d'uso, si testa la qualità dell'output, si misura la velocità. Ma raramente ci si siede e si disegna una mappa: quale agente può solo osservare e generare, e quale può toccare il mondo reale.
La linea che separa due categorie di agente
Gli agenti di sola generazione, che chiameremo agenti passivi, operano all'interno di un ciclo chiuso. Leggono dati, analizzano documenti, producono testo, codice, sintesi, proposte. Il loro output è sempre mediato da un essere umano prima di produrre effetti nel mondo. Puoi lasciare che girino in autonomia completa perché il peggio che possono fare è sprecare token e produrre un output inutile.
Gli agenti con capacità di azione, che chiameremo agenti attivi, hanno accesso a strumenti con effetti reali: inviano email, modificano database, eseguono chiamate API verso sistemi esterni, spostano file, pubblicano contenuti, avviano pagamenti. Ogni loro azione produce una conseguenza che può essere difficile o impossibile da annullare. Il rischio non è nella qualità dell'output: è nell'effetto collaterale dell'esecuzione.
Anthropomorphic Research ha formalizzato questa distinzione nella documentazione tecnica di Claude, parlando di "read-only tools" contrapposti a "write tools" nel contesto degli agenti. La differenza di superficie è banale. Le implicazioni operative non lo sono.
Tre criteri per classificare un agente prima di metterlo in produzione
Prima di assegnare autonomia a qualsiasi agente, vale la pena rispondere a tre domande precise.
La prima: l'azione è reversibile? Pubblicare un post su un canale social con 50.000 follower è molto meno reversibile che salvare una bozza in un CMS. Inviare un'email è irreversibile. Aggiornare un record su un CRM è tecnicamente reversibile ma richiede intervento manuale e lascia tracce. Mappa ogni azione dello strumento sul grado di reversibilità: da zero a dieci. Se stai sotto il cinque, inserisci un checkpoint umano obbligatorio.
La seconda: chi è l'entità ricevente? Un agente che scrive su un sistema interno ha un impatto limitato al perimetro aziendale. Un agente che interagisce con clienti, fornitori o partner esterni amplifica il rischio in modo non lineare, perché le conseguenze sfuggono al tuo controllo diretto e possono generare danni reputazionali o legali.
La terza: esiste un tetto naturale al danno? Alcuni agenti operano su dataset o risorse limitate per natura. Un agente che gestisce le risposte ai ticket di supporto su un canale specifico ha un perimetro definito. Un agente con accesso alle API di un account pubblicitario con budget illimitato può, in caso di allucinazione o loop erroneo, bruciare migliaia di euro in poche ore. Questo è successo, in casi documentati nel settore.
Come si costruisce un sistema di guardrail pratico
I guardrail non sono vincoli burocratici. Sono l'architettura che ti permette di delegare di più con meno ansia. Se li costruisci bene, puoi dare più autonomia agli agenti, non meno.
Il principio base è quello del privilegio minimo, mutuato dalla sicurezza informatica classica: ogni agente deve avere accesso solo agli strumenti strettamente necessari per il suo compito. Un agente che analizza i dati di vendita non ha bisogno di poter scrivere nel database: gli basta leggerlo. Non dargli quel permesso, anche se tecnicamente sarebbe comodo.
Il secondo livello è il checkpoint umano differenziato. Non tutti i checkpoint devono essere uguali. Per azioni a basso impatto e alta reversibilità puoi usare un sistema di notifica passiva: l'agente agisce e ti avvisa dopo. Per azioni a medio impatto puoi usare un'approvazione asincrona, dove l'agente mette in coda l'azione e attende il via libera entro un tempo definito. Per azioni ad alto impatto o bassa reversibilità il checkpoint deve essere sincrono e bloccante.
Il terzo livello è il limite quantitativo automatico. Definisci soglie oltre le quali l'agente si ferma e chiede conferma, indipendentemente dalla logica del compito. Esempi concreti:
- Budget pubblicitario: l'agente non può modificare la spesa giornaliera oltre una certa percentuale senza approvazione
- Email: l'agente non può inviare a più di N destinatari in una singola sessione
- Database: l'agente non può modificare più di N record in una singola operazione
- API esterne: l'agente ha un rate limit interno più conservativo di quello del provider
Queste soglie sembrano arbitrarie. In realtà sono il tuo primo segnale di anomalia: se l'agente le raggiunge, qualcosa di inaspettato sta accadendo.
Il problema dell'autonomia progressiva e come gestirlo
Molte implementazioni partono caute e poi, man mano che l'agente dimostra affidabilità, allargano i permessi. Questo ha senso, ma nasconde un rischio sottile: i casi rari e ad alto impatto emergono solo quando il volume di operazioni è già alto.
Un agente che gestisce 10 operazioni al giorno potrebbe non incappare mai in un edge case critico nelle prime settimane. Lo stesso agente a 500 operazioni al giorno potrebbe incontrarlo alla terza settimana. La trappola è pensare che la performance storica a basso volume garantisca affidabilità ad alto volume.
L'approccio corretto è separare le due variabili: puoi aumentare il volume mantenendo i guardrail costanti, oppure puoi allargare i guardrail mantenendo il volume controllato. Fare entrambe le cose insieme è l'errore più comune nelle fasi di scaling.
Il modello che consiglio ai clienti in DD Agency è quello della "zona di comfort documentata": per ogni agente attivo, si scrive esplicitamente quale insieme di scenari è stato testato, quali soglie sono state validate, e quale categoria di input non è mai stata osservata in produzione. Questa documentazione non è per l'auditor: è per il team che gestisce l'agente e deve decidere in tempo reale se alzare o abbassare l'autonomia.
La governance non è un freno alla velocità
C'è una narrativa diffusa che oppone governance e velocità di adozione. Chi vuole muoversi rapido tende a vedere i controlli come ostacoli. È una visione miope.
Le aziende che hanno integrato agenti AI con le maggiori difficoltà operative sono quasi sempre quelle che hanno saltato la fase di classificazione e si sono trovate a fare triage su problemi in produzione. Riprogettare i permessi di un agente già integrato in più sistemi è molto più costoso che farlo prima del rilascio.
La distinzione tra agenti passivi e agenti attivi non è un dettaglio tecnico da lasciare agli sviluppatori. È una decisione di business che riguarda direttamente il rischio operativo, la reputazione e, in certi settori, la compliance normativa. Il GDPR, per esempio, ha implicazioni precise su chi può accedere e modificare dati personali, e "è stato l'agente AI" non è una risposta che regge davanti a un'autorità di controllo.
La mossa concreta per domani mattina
Prendi carta e penna (o un foglio condiviso) e mappa tutti gli agenti AI attivi nella tua azienda in una matrice 2x2: asse verticale "reversibilità dell'azione" (da alta a bassa), asse orizzontale "impatto esterno" (da interno a esterno). Per ogni agente nel quadrante bassa reversibilità e alto impatto esterno, verifica che esista un checkpoint umano bloccante prima di ogni azione. Se non c'è, fermati prima di ampliare l'autonomia di quel sistema. Quella mezz'ora di lavoro vale più di qualsiasi ottimizzazione del prompt.