Un agente AI segue le istruzioni con alta probabilità, non con certezza. Le regole che non devono mai saltare vanno messe in un controllo sul percorso dell'azione, con un contratto per quando si rompe e qualcuno che si accorga di quando non gira. La formazione serve al resto.
Il 10 ottobre ho pubblicato uno studio sui gate deterministici del sistema con cui lavoro: come impedisco agli agenti AI di fare azioni che non voglio, cosa succede quando i controlli negano, quando lasciano passare e quando sono loro a rompersi. È un technical report, con i dati e gli script che li generano, scritto per chi costruisce questi sistemi.
Questo articolo parla d'altro. È per chi in azienda deve decidere come far lavorare gli agenti AI senza costruirli: chi si occupa di persone e di formazione, chi coordina un team che ha appena ricevuto le licenze, chi deve scrivere le regole d'uso e poi rispondere di quello che succede. La domanda che lo studio pone a loro è semplice da dire e scomoda da applicare: quando scrivi una regola per un agente, chi la fa rispettare nel momento in cui serve?
La mia risposta è che un'istruzione descrive cosa vorresti che succedesse, mentre un controllo deterministico decide cosa succede. La formazione serve, ma a un'altra cosa. Il resto dell'articolo spiega la differenza e cosa farne quando si porta l'AI nel lavoro di un team.
Un'istruzione è un'aspettativa, anche quando è scritta bene
Quando un'azienda introduce un assistente AI che agisce, e non si limita a rispondere, la prima mossa è quasi sempre scrivere regole. Un documento di policy, le istruzioni di progetto, un prompt di sistema con l'elenco di cosa non fare. È la mossa giusta, e da sola non basta.
Un modello linguistico segue un'istruzione con una probabilità alta, non con certezza. Quella probabilità cambia con la lunghezza della conversazione, con la distanza fra il punto in cui la regola è scritta e il momento in cui serve, con quanto il compito spinge da un'altra parte. Riscrivere la regola in maiuscolo o in grassetto sposta la probabilità. Non la porta a uno.
Per molte regole il residuo non conta: se l'agente ogni tanto sbaglia il tono di una bozza, la bozza si corregge. Per altre basta una volta. Pubblicare una cifra senza fonte, leggere un file con le credenziali, cancellare una cartella intera: lì la differenza fra «quasi sempre» e «sempre» è tutto il problema.
Nel mio sistema, fino al 23 agosto, tre regole dichiarate bloccanti vivevano solo in prosa. Erano giuste: ogni cifra in un contenuto pubblicato porta la sua fonte; niente salvataggi in blocco nell'archivio del codice che più sessioni condividono; nessuna lettura dei file con le credenziali. Quel giorno sono passate dalle istruzioni al codice [fonte: projects/studio-gate/report.md, sezione 1]. Fino ad allora a farle rispettare era l'agente stesso, quando le aveva presenti. La regola c'era. Mancava un esecutore.
Lo stesso vale per una policy aziendale data in pasto a un agente. Se l'unico posto in cui la regola vive è il testo che l'agente legge all'inizio, la regola è un'aspettativa: ragionevole, spesso rispettata, mai garantita.
Cosa trasforma un controllo in un gate
Lo strumento tecnico si chiama hook: uno script che l'ambiente in cui lavora l'agente esegue in un momento preciso, per esempio subito prima di un comando o di una scrittura su file. Claude Code e Codex lo permettono entrambi (documentazione degli hook di Claude Code, documentazione degli hook di Codex, consultate il 2026-10-13). Lo script riceve cosa l'agente sta per fare e risponde: va bene, oppure no, con un motivo. Se dice no, l'azione non parte e l'agente legge il motivo.
Uno script del genere diventa un gate quando ha quattro proprietà. Le elenco perché sono anche le domande da fare a chiunque proponga di mettere un agente al lavoro nella tua azienda.
È deterministico. Stesso input, stessa decisione, sempre. Dentro non c'è un modello che valuta: ci sono regole che si possono leggere e provare, come si prova una funzione. Un controllo affidato a un secondo modello può essere utile, ma ha lo stesso limite del primo: decide con una probabilità.
Sta sul percorso. Gira dove passa l'azione, non accanto. Non serve che l'agente se ne ricordi e non serve che sia d'accordo.
Il suo no dice cosa fare invece. Un blocco senza alternativa lascia l'agente a cercare un'altra strada da solo, e la strada che trova di solito è peggiore. Nel mio sistema ogni negazione del controllo sulla shell indica l'alternativa: l'agente non deve indovinare, deve solo rifare l'azione nella forma ammessa.
Ha un contratto per quando si rompe. Prima o poi il controllo riceve un input che non sa leggere, non trova un file che gli serve, va in errore. In quel momento deve essere già deciso se l'azione passa o si ferma. Ci torno più avanti, perché è la parte che riguarda di più chi decide e meno chi scrive codice.
Nessuna di queste proprietà richiede che il controllo sia complicato. Dentro i controlli del mio sistema ci sono espressioni regolari, un parser dei comandi, un programma che conta le etichette accanto alle cifre. La parte difficile non è scriverli. È decidere quali regole meritano un controllo e cosa succede intorno.
Cosa ho misurato
Lo studio ha quattro tipi di dati, e nessuno è una decisione di produzione: sono casi di prova, test di guasto e serie storiche lette dai file del sistema. Il registro delle decisioni reali è partito con la pubblicazione dello studio, e le frequenze vere arriveranno quando avrà accumulato abbastanza giorni. Intanto i dati dicono quattro cose, ognuna utile anche fuori da questo sistema.
Un controllo è definito dai suoi casi di prova. Ogni comando che il controllo sulla shell deve negare o lasciar passare è scritto in un elenco, con la decisione attesa, e un test li esegue tutti sullo script vero. Per lo studio li ho rieseguiti: su 140 casi, la decisione coincide con quella attesa in tutti e 140. Ne ho pubblicati 136, perché quattro nominano file riservati; dei 136, 79 sono negazioni e 57 sono permessi [misurato su N=140 casi di prova, periodo: 10 ottobre 2026, fonte: projects/studio-gate/data/replay-bash-guard.json].
Quasi metà dei casi, cioè, non dice cosa bloccare: dice cosa il controllo deve lasciar passare anche quando somiglia a qualcosa di vietato. Non è un dettaglio. Un controllo che blocca troppo viene aggirato o spento, e da quel momento non protegge niente. Ogni falso positivo trovato nel lavoro vero è diventato un caso dell'elenco, così nessuna modifica futura può reintrodurlo senza far fallire il test.
Il modo in cui un controllo si rompe è una scelta. Ho passato ai tre controlli che decidono prima dell'azione una serie di input rotti: testo che non è nel formato atteso, richieste vuote, argomenti del tipo sbagliato. Gli esiti osservati dal vivo sono 22, a cui si aggiungono 10 rami di errore letti nel codice perché dall'esterno non si provocano [misurato su N=32 righe di test di guasto, periodo: 10 ottobre 2026, fonte: projects/studio-gate/data/fail-modes.json]. Due controlli, quello sulla shell e quello sulle scritture di file, lasciano passare quando non capiscono l'input. Il terzo, quello che controlla le cifre prima di una scrittura sul CMS del sito, nega. È un'asimmetria voluta, e la spiego nella prossima sezione.
Anche una correzione si prova con i casi. Quando il controllo del CMS ha rifiutato una forma di input legittima che non conosceva, la correzione ha aggiunto quella forma e i suoi casi di prova. La suite dell'hook passa 39 casi su 39 sulla versione corretta e 18 su 39 sulla versione precedente [misurato su N=39 casi di prova, periodo: 5 ottobre 2026, fonte: projects/studio-gate/report.md, sezione 4]. Senza quei casi, dire che la correzione funziona sarebbe stata una speranza.
I gate hanno a loro volta un controllo. Una suite di casi di prova sorveglia i gate che giudicano i contenuti: voce, titoli, cifre. Dal 30 luglio al 10 ottobre ha girato 294 volte, con 287 run verdi e 7 rossi [misurato su N=294 run, periodo: dal 30 luglio al 10 ottobre 2026, fonte: projects/studio-gate/data/gate-evals.json]. Una parte dei rossi non segnalava un gate scritto male nel codice: segnalava due criteri scritti in modo ambiguo, che sono stati riscritti. Anche questo è un risultato: un criterio ambiguo è un difetto del gate anche quando il codice è giusto.
Aperto o chiuso: la decisione che non è tecnica
Quando un controllo va in errore può fare due cose: lasciar passare l'azione, e allora si dice fail-open, oppure fermarla, fail-closed. Sembra un dettaglio da sviluppatori. È una decisione su chi paga il guasto.
Nel mio sistema la regola è questa: chiuso dove l'azione è rara, pubblica e non ha altri controlli dopo; aperto dove l'azione è frequente e c'è un'altra rete a valle. La scrittura sul sito è rara e, una volta pubblicata, una cifra inventata viene letta, citata e indicizzata prima che qualcuno se ne accorga: lì il controllo nega anche quando è lui a non capire. I comandi sulla shell sono continui: un controllo rotto in chiusura fermerebbe tutto, compreso il comando che serve a ripararlo. Lì il controllo lascia passare, e la protezione ricade su una rete a valle che va verificata macchina per macchina, non data per scontata [fonte: projects/studio-gate/report.md, sezione 4].
Il chiuso ha un prezzo, e lo studio lo dichiara: quando il gate del sito ha ricevuto una forma di input che non conosceva, ha negato un aggiornamento legittimo, e il costo è stato un aggiornamento saltato. Preferisco quell'errore all'altro. Un controllo chiuso che non riconosce qualcosa lo dice; uno aperto lo lascia passare, e nessuno lo vede.
Per un'azienda la traduzione è diretta. Per ogni regola affidata a un controllo, qualcuno deve aver deciso cosa succede il giorno in cui il controllo non funziona. Il lavoro si ferma o va avanti senza protezione? Se si ferma, chi se ne accorge e chi lo sblocca? Se va avanti, cosa lo protegge nel frattempo? Sono domande da responsabile del processo, non da reparto IT. L'IT sa dirti come si configura un controllo; il costo di un'attività ferma, messo accanto a quello di un errore uscito verso un cliente, lo conosce chi ne risponde.
Un controllo copre una strada, non un'azione
«Scrivere un file» sembra un'azione sola. Per un agente sono molte strade: lo strumento di scrittura, quello di modifica, un comando dalla shell, uno script, una chiamata diretta a un servizio. Un controllo agganciato a uno strumento copre quello strumento, e basta.
Quando una strada si chiude, l'agente prova la successiva. Non lo fa per malizia: trovare un'altra strada quando la prima è bloccata è esattamente il motivo per cui si usa un agente. Per questo nel mio sistema il controllo sui file con le credenziali guarda anche i comandi della shell, e non solo lo strumento che legge i file. E per questo ogni controllo ha accanto l'elenco delle strade che non vede: nello studio quell'elenco occupa una sezione intera, e comprende anche le scritture sul sito fatte con una chiamata diretta, che dal gate non passano [fonte: projects/studio-gate/report.md, sezione 8].
Quando un fornitore, un collega o un consulente ti dice che l'agente «non può» fare una certa cosa, la domanda utile è: da quale strada? Con quale strumento è bloccato, e cosa succede se ci arriva dalla shell, da un altro connettore, da uno script che scrive lui stesso? Una risposta onesta contiene sempre un elenco di strade non coperte. Se l'elenco è vuoto, vuol dire che nessuno l'ha ancora cercato.
Il giorno in cui il controllo non gira
C'è un guasto peggiore di un controllo che sbaglia: un controllo che non gira. Non produce nessun segnale. Un controllo che lascia passare non scrive niente, per costruzione. Uno che non è partito non scrive niente lo stesso. Da fuori le due situazioni sono identiche.
Nel mio sistema, a fine agosto, ogni allarme scattava su un errore, e un controllo che non gira non produce errori. Un audit sui guasti di quei giorni ha misurato quanto pesa questa differenza: su sette guasti analizzati, cinque li aveva notati una persona che si era accorta di qualcosa che mancava, non un allarme [misurato su N=7 guasti, periodo: agosto 2026, fonte: reports/audit-guasti-silenziosi-2026-08-31.md]. Da questa misura viene il registro delle decisioni: ogni controllo scrive una riga per ogni decisione, e un secondo script segnala il giorno in cui un controllo che di solito scrive resta muto. È un allarme su un'assenza. Decidere se quel silenzio è un guasto o un computer spento resta un lavoro da fare con il calendario accanto.
Per chi introduce agenti in azienda la domanda è una sola, e conviene farla prima dell'avvio: come fate a sapere che oggi il controllo ha girato? Se la risposta è «se ci fosse un problema lo vedremmo», il controllo non è sorvegliato.
Cosa porto in un percorso di formazione aziendale
Niente di tutto questo rende inutile la formazione. La sposta.
Un controllo deterministico copre poche regole: quelle che non devono mai saltare e che si possono descrivere in modo meccanico. Tutto il resto, cioè quasi tutto il lavoro con l'AI, resta affidato al giudizio delle persone e alle istruzioni che scrivono per gli agenti: cosa chiedere, cosa verificare, quando fermarsi. La formazione alza la probabilità che quel giudizio sia buono. Il controllo decide sulle poche cose in cui una probabilità alta non basta.
E nessuno dei due controlla la sostanza. Un gate verde dice che il testo non ha i difetti che il gate sa riconoscere, non che il testo sia buono. Quello lo verifica una persona che il gate non lo conosce e che guarda il risultato per quello che è. È il punto in cui il rischio opposto, fidarsi troppo di ciò che passa i controlli, diventa concreto, e ne ho scritto in un articolo sull'automation bias.
Da qui viene un esercizio che si può fare con qualsiasi team, prima ancora di toccare uno strumento. È un esercizio, non un caso raccontato: si prendono le regole d'uso dell'AI che il team ha già, e se non ne ha una policy d'uso dell'AI è il punto di partenza. Per ogni regola si risponde a quattro domande.
Chi la fa rispettare nel momento in cui serve? Una persona che se ne ricorda, l'agente che l'ha letta nelle istruzioni, oppure un controllo che sta sul percorso dell'azione. Se la risposta è «chi se ne ricorda», la regola è un'aspettativa. Va bene, purché sia una scelta e non una svista.
Cosa succede se il controllo manca o si rompe? Il lavoro si ferma o va avanti senza protezione, e chi lo ha deciso. Se nessuno lo ha deciso, lo decide il caso il giorno del guasto.
Quali strade portano allo stesso risultato senza passare da lì? La shell, un altro strumento, un connettore diverso, una persona che copia e incolla il testo da una finestra all'altra.
Come ve ne accorgete il giorno in cui non gira? Un registro, un conteggio, un nome a cui arriva l'avviso. Se non c'è una risposta, il controllo non è sorvegliato.
Alla fine ogni regola cade in uno di tre gruppi. Le regole che chiedono giudizio restano nella formazione e nelle istruzioni, con il loro perché scritto accanto. Le regole che non devono mai saltare e si possono descrivere in modo meccanico diventano candidate a un controllo, da progettare con chi gestisce gli strumenti. Le regole sulla sostanza, cioè se una risposta è giusta o se un testo regge, restano a una persona, con un tempo e un nome.
Il terzo gruppo è quello che si dimentica più spesso, perché sembra coperto dagli altri due. Non lo è: una regola come «i testi che escono verso i clienti devono essere corretti» non diventa un controllo automatico e non migliora solo perché il team ha seguito un corso. Richiede qualcuno che li legga, e qualcuno che abbia deciso chi.
Nel programma indicativo del percorso di formazione per le aziende che propongo, l'ultima parte serve a questo: definire responsabilità, verifica umana e condizioni per fermarsi, prima di portare il lavoro con l'AI nel quotidiano del team. Le quattro domande sono un modo per arrivarci con le regole già ordinate.
I limiti di quello che ho misurato
Lo studio dichiara i suoi limiti, e li ripeto qui perché valgono anche per chi legge questo articolo cercando un modello da copiare.
I casi di prova non sono produzione. Dicono come il controllo tratta i comandi che conosco, non quante volte un agente prova un comando vietato né quanti falsi positivi incontra in una giornata normale. Quelle frequenze arriveranno dal registro delle decisioni; fino ad allora sono sconosciute, e non ne cito.
I casi li scrive chi scrive il controllo. Coprono le forme che conosco. Una forma nuova passa finché qualcuno non la vede, e per questo ogni forma sfuggita diventa un caso.
Un controllo sulla shell legge stringhe. Un comando abbastanza indiretto non contiene la stringa che il controllo cerca. Lo studio elenca le forme note che passano, invece di nasconderle.
Il controllo sulle cifre verifica la forma, non la sostanza. Controlla che un'etichetta ci sia e, con la verifica dei link attiva, che la fonte risponda. Non controlla che il ragionamento intorno al dato sia giusto.
È un solo sistema. Costruito e usato da una persona, con scelte di progetto discutibili e dichiarate. Le misure valgono per questo sistema. Il metodo, cioè chiedersi per ogni regola chi la fa rispettare, si porta altrove senza bisogno di copiare il codice.
Da dove partire
Se state introducendo agenti AI nel lavoro del team, non serve partire dal codice. Serve partire dall'elenco delle regole e dalla domanda su chi le fa rispettare. Per quasi tutte la risposta giusta è la formazione, con istruzioni chiare e una persona che verifica. Per poche la risposta giusta è un controllo sul percorso, con un contratto per quando si rompe e qualcuno che conta i giorni in cui tace.
Chi vuole il dettaglio tecnico trova nello studio completo i dati, il metodo, la versione interattiva in cui si cercano i casi di prova e l'elenco dei limiti.
Un'istruzione resta utile: spiega il perché. La regola che non può saltare, però, va messa dove passa l'azione.