Prima di lasciar agire un AI agent da solo, verifica nove guardrail. I primi quattro associano ogni azione che l'agent può compiere a una valutazione del rischio, così quelle irreversibili, sensibili e costose si fermano sempre in attesa di una persona. I cinque successivi confermano l'ambiente che contiene l'agent quando un filtro viene ingannato: un'identità univoca dell'agent, permessi a privilegio minimo, una sandbox, traffico di rete in uscita limitato e log di audit a livello di azione. La mappa delle azioni ti dice cosa è sicuro automatizzare. L'ambiente è ciò che regge davvero la linea, perché i filtri sui contenuti su cui si appoggiano la maggior parte delle checklist sono proprio lo strato che fallisce esattamente quando conta. Esegui tutti e nove come domande sì o no, e se una qualsiasi risposta è no o "non ne siamo sicuri", l'agent non è pronto a operare senza supervisione.
Questo è l'audit pre-lancio che eseguiamo prima di lasciar agire da solo un agent che abbiamo costruito dentro un'altra azienda, scritto in modo che possa eseguirlo anche un titolare non tecnico, sul proprio agent o su quello di un fornitore. Se preferisci che lo facciamo noi al posto tuo, scopri come gestiamo la governance e il rischio dell'AI responsabile. Tutto ciò che segue è a tua disposizione.
Come dovrei usare questa checklist?
Trattala come un controllo pre-volo, non come una filosofia. Prendi l'agent che stai per mettere in produzione (o quello che un fornitore ti sta vendendo) e rispondi a ciascuno dei nove punti con un sì o un no netto. Un "in gran parte" è un no. L'obiettivo è far emergere le lacune prima che l'agent tocchi qualcosa di reale.
I nove si dividono in due gruppi che svolgono compiti diversi:
- Punti da 1 a 4 (la mappa delle azioni). Decidono cosa l'agent può fare senza chiedere, e cosa deve fermarsi per una persona. Questo è giudizio sul rischio, ed è la parte che la maggior parte delle guide copre.
- Punti da 5 a 9 (l'ambiente). Limitano cosa l'agent può raggiungere e fare in assoluto, indipendentemente da ciò che gli è stato detto di fare. Questa è la parte che la maggior parte delle checklist salta, ed è la parte che contiene un agent quando un filtro viene ingannato.
Entrambi i gruppi contano, ma falliscono in modi diversi. La mappa delle azioni riguarda il decidere correttamente. L'ambiente riguarda il sopravvivere a una decisione sbagliata. Hai bisogno di entrambi, perché nessun filtro cattura tutto: il classificatore in modalità automatica in produzione di Anthropic, uno dei migliori che esistano, manca comunque circa il 17% delle azioni troppo zelanti degli agent anche quando è regolato per non bloccare quasi mai un comando legittimo. Un tasso di mancato rilevamento del 17% va bene con un altro strato dietro ed è temerario quando è l'unica cosa tra l'agent e il tuo denaro.
Punti da 1 a 4: hai mappato ogni azione a una valutazione del rischio?
Non puoi bloccare ciò che non hai elencato. Inizia annotando ogni azione che l'agent può compiere, poi valuta ciascuna. La guida agli agent di OpenAI offre il metodo di valutazione più pulito: assegna a ogni azione un punteggio basso, medio o alto su quattro fattori.
| Fattore | Domanda | Segnale di alto rischio |
|---|---|---|
| Accesso in scrittura | Legge soltanto, o modifica qualcosa? | Scrive, invia o cancella |
| Reversibilità | Il risultato può essere annullato? | Non può essere ripristinato |
| Permessi dell'account | Quale accesso le serve per farlo? | Ambito admin, finanziario o dati dei clienti |
| Impatto economico | Quanto costa se va male? | Denaro reale, o fiducia persa |
Guardrail 1: hai elencato ogni azione e l'hai valutata come bassa, media o alta? Se c'è un'azione nella lista che nessuno ha valutato, è quella che ti farà male. La valutazione smista quasi tutto in tre categorie:
| Rischio | Esempi | Regola |
|---|---|---|
| Basso (sola lettura, reversibile) | Cercare un ordine, riassumere un ticket, bozza di una risposta | Lascia che venga eseguita. Registrala. Rivedi a posteriori. |
| Medio (scrive, ma recuperabile) | Aggiornare un record, pubblicare una nota interna, creare una bozza | Consenti entro limiti stretti. Avvisa una persona. |
| Alto (irreversibile, sensibile, costoso) | Rimborso o pagamento, eliminare record, concedere accessi, inviare un messaggio esterno | Richiedi l'approvazione umana prima dell'esecuzione. Sempre. |
Guardrail 2: ogni azione ad alto rischio si ferma per un'approvazione umana esplicita prima di essere eseguita? Questa è l'unica regola che previene gli esiti peggiori. OpenAI indica proprio queste come le azioni che meritano l'approvazione umana: annullare ordini, autorizzare rimborsi consistenti ed effettuare pagamenti. Aggiungi le eliminazioni, le concessioni di accesso e qualsiasi messaggio che esce dall'azienda. Un agent dei rimborsi può leggere tutti gli ordini che vuole, ma non deve mai muovere denaro oltre una piccola soglia senza che una persona clicchi su approva.
Guardrail 3: il gate di approvazione è abbastanza raro perché le persone lo leggano ancora? La trappola è far chiedere all'agent il permesso per tutto. Se lo fai, hai costruito un sistema peggiore, non più sicuro. Anthropic ha misurato che gli utenti approvano circa il 93% delle richieste di autorizzazione, quindi un gate che scatta quaranta volte al giorno è una farsa: la persona è nominalmente nel loop ma ha smesso di guardare. Verifica tre cose: che l'agent chieda solo per azioni davvero rischiose, che la richiesta indichi la conseguenza in linguaggio semplice ("Rimborsa 1.000 $ all'account X") e che il silenzio significhi "no" come impostazione predefinita, mai "sì".
Guardrail 4: l'agent si ferma e chiede aiuto quando continua a fallire? Un agent confuso che entra in loop sui tentativi è di per sé un tipo di rischio. Imposta una soglia di fallimento, così che dopo un numero stabilito di tentativi falliti l'agent si fermi e faccia escalation invece di agitarsi a vuoto. OpenAI elenca esattamente due trigger per l'intervento umano: il superamento delle soglie di fallimento e le azioni ad alto rischio. Li hai appena coperti entrambi.
Punti da 5 a 9: hai verificato l'ambiente che lo contiene?
Ecco la parte che le checklist generiche saltano, ed è la parte che fa il lavoro pesante. I punti da 1 a 4 presumono che l'agent decida correttamente. I punti da 5 a 9 presumono che a volte non lo farà, e limitano il danno quando accade.
Il motivo per cui questo gruppo conta è il dato più trascurato nella sicurezza degli agent: i filtri sui contenuti falliscono proprio quando l'istruzione dannosa sembra legittima. Anthropic ha condotto un test in cui un dipendente è stato vittima di phishing, così l'istruzione malevola è arrivata dall'utente fidato a cui l'agent era stato costruito per servire. Su 25 tentativi l'agent ha completato il furto di credenziali 24 volte, perché, con le loro parole, quando l'utente digita l'istruzione non c'è nulla di anomalo che un classificatore possa cogliere. L'unica cosa che lo ha fermato in modo affidabile era ambientale: bloccare il traffico di rete in uscita dell'agent così che i dati rubati non avessero un posto dove andare. I filtri tirano a indovinare sull'intento. L'ambiente rimuove le capacità. Le capacità sono ciò che puoi davvero controllare.
Guardrail 5: l'agent ha una propria identità, non una chiave admin condivisa? Ogni agent dovrebbe operare con un'identità univoca, mai una credenziale condivisa e mai il login admin di una persona. Una chiave condivisa significa che non puoi sapere quale agent ha fatto cosa, e una compromissione si diffonde ovunque quella chiave arrivi. Un'identità univoca è anche ciò che rende significativo il log di audit del guardrail 9.
Guardrail 6: quell'identità è limitata al privilegio minimo? L'agent riceve l'insieme più ristretto di permessi di cui il suo compito ha effettivamente bisogno, e nulla di più. Un agent di supporto che emette rimborsi non dovrebbe essere in grado anche di esportare il database dei clienti o di modificare le buste paga. Se viene ingannato, il danno è limitato da ciò che gli è stato concesso, non dal fatto che un filtro abbia colto l'inganno. Usa l'accesso meno potente che funzioni: la sola lettura batte la lettura-scrittura, e la lettura-scrittura-senza-eliminazione batte l'accesso completo.
Guardrail 7: l'agent gira in una sandbox? L'agent dovrebbe operare dentro un ambiente isolato costruito su un isolamento affermato e collaudato (gli stessi container e sandbox usati per eseguire codice non fidato), non qualcosa di artigianale. Come nota Anthropic, quei primitivi hanno resistito a un'attenzione avversaria molto maggiore di qualsiasi cosa tu possa costruire da solo. Adatta il contenimento anche all'utente: uno sviluppatore che può leggere ed eseguire codice e un addetto al supporto che non può non sono lo stesso modello di minaccia, e più potenti sono gli strumenti, più stretta dev'essere la scatola.
Guardrail 8: il traffico di rete in uscita dell'agent è limitato e definito per capacità? Questo è il controllo che ha fermato l'attacco di phishing di cui sopra. Ma una semplice lista di "domini consentiti" non basta da sola. Anthropic ha imparato a sue spese che gli attaccanti hanno esfiltrato file attraverso un dominio consentito instradandoli verso il proprio account su di esso, quindi pensa alle regole sul traffico in uscita come a concessioni di capacità (cosa l'agent è autorizzato a fare) piuttosto che a una semplice lista di indirizzi che può raggiungere.
Guardrail 9: ogni azione è registrata a livello di azione per l'audit? Non puoi governare ciò che non puoi vedere. Ogni azione che l'agent compie, soprattutto quelle ad alto rischio, dovrebbe essere registrata con sufficiente dettaglio da ricostruire cosa è successo, chi o cosa l'ha innescata e cosa ha toccato. I log a livello di azione sono il modo in cui cogli un problema lento prima che diventi un titolo di giornale, e il modo in cui affini gli altri otto guardrail nel tempo.
Che aspetto ha la checklist completa?
Ecco i nove in un unico posto, ciascuno formulato come un sì o un no che puoi verificare. Un no è una lacuna da chiudere prima del lancio, non una nota a piè di pagina.
| # | Guardrail | Puoi lanciare quando |
|---|---|---|
| 1 | Inventario delle azioni e valutazione del rischio | Ogni azione è elencata e valutata come bassa, media o alta |
| 2 | Gate umano sulle azioni ad alto rischio | Ogni azione irreversibile o costosa si ferma per l'approvazione |
| 3 | Approvazioni rare, in linguaggio semplice | Il gate scatta solo su rischio reale e ha "no" come impostazione predefinita |
| 4 | Escalation su soglia di fallimento | L'agent si ferma e chiede aiuto dopo ripetuti fallimenti |
| 5 | Identità univoca dell'agent | L'agent ha una propria identità, niente chiavi admin condivise |
| 6 | Permessi a privilegio minimo | Può raggiungere solo ciò di cui il suo compito ha bisogno |
| 7 | Sandbox | Gira in un'infrastruttura affermata e isolata |
| 8 | Traffico in uscita limitato e definito per capacità | L'accesso alla rete è recintato, non una lista aperta di domini consentiti |
| 9 | Log di audit a livello di azione | Ogni azione è registrata e consultabile |
Nota la forma. I primi quattro sono decisioni che prendi sul rischio; gli ultimi cinque sono controlli che integri nell'ambiente. I primi quattro possono essere ingannati. Gli ultimi cinque non possono essere convinti a non fare il loro lavoro, ed è per questo che sono irrinunciabili anche quando il modello è eccellente.
Come eseguo questo audit sull'agent di un fornitore?
Le stesse nove domande funzionano altrettanto bene sull'agent di qualcun altro, e sono il modo più rapido per distinguere un prodotto contenuto da una demo sicura di sé. Una demo dimostra che l'agent funziona in una buona giornata. La checklist dimostra cosa succede in una cattiva.
Chiedi al fornitore di rispondere a queste domande in linguaggio semplice:
- Quali delle mie azioni richiedono l'approvazione umana prima di essere eseguite? Un fornitore che non sa nominarle non le ha valutate.
- L'agent ottiene una propria identità con accesso a privilegio minimo, o usa una chiave condivisa nei miei sistemi? La seconda risposta è un campanello d'allarme.
- È in una sandbox, e cosa può raggiungere sulla rete? "Può raggiungere internet" non è una risposta.
- Ogni azione è registrata, e posso vedere quei log? Se non puoi farne l'audit, non puoi governarlo.
- Qual è il raggio d'azione del danno se l'agent viene ingannato? La risposta onesta è una lista di ciò che può toccare, non la promessa che non lo farà mai.
Se le risposte sono vaghe, o si basano interamente sul "il modello si comporta bene", l'agent non è contenuto, per quanto buona sia sembrata la demo. Un buon fornitore avrà le risposte pronte, perché queste sono le stesse domande che avrebbe dovuto porsi.
Perché conta adesso?
Perché il divario tra i team che superano questo audit e quelli che lo saltano sta per emergere nei numeri. Gartner prevede che oltre il 40% dei progetti di AI agentica verrà cancellato entro la fine del 2027, con controlli del rischio inadeguati tra le cause, e prevede che entro il 2028 il 25% delle applicazioni di AI generativa aziendali subirà almeno cinque incidenti di sicurezza minori all'anno, in crescita rispetto al 9% del 2025. I guardrail stanno passando da un'impostazione di configurazione a un piano di controllo con un proprio budget, e l'audit qui sopra è il modo in cui resti dalla parte giusta di questo cambiamento.
La parte incoraggiante è che nulla di tutto questo è esotico. Mappa ogni azione a una valutazione del rischio e blocca quelle irreversibili. Dai all'agent una propria identità con il minor accesso di cui ha bisogno, in una sandbox, con la rete recintata e ogni azione registrata. Mantieni il gate umano abbastanza raro perché le persone lo leggano ancora. Fai questo, e un attaccante che supera il tuo filtro si scontra comunque con un muro di capacità che non gli sono mai state concesse.
Se vuoi che questi nove guardrail vengano costruiti, verificati e gestiti per te prima che il tuo primo agent vada in produzione, è esattamente il lavoro che svolgiamo dentro gli stack di altre aziende. Prenota una consulenza gratuita qui sotto e eseguiremo insieme questa checklist sul tuo agent.
