Guardrail agenti AI: perché vanno mantenuti (non solo installati)

Un agente AI in produzione da sei mesi non è lo stesso sistema che è andato online. Il modello sotto è stato aggiornato due volte dal fornitore, il team ha collegato tre nuovi tool, il caso d’uso si è allargato dal customer care al recupero crediti. L’unica cosa che nessuno ha toccato, in quei sei mesi, è il filtro che dovrebbe impedirgli di combinare guai.

È il punto cieco più comune nei progetti agentici: i guardrail agenti AI vengono trattati come un plug-in, si installa, si spunta la casella, si passa oltre. Ma un guardrail è una regola tarata su un momento preciso: su quel modello, con quei permessi, contro quelle tecniche di attacco. Cambiato uno dei tre, la taratura non è più quella. Il meccanismo di fondo è sempre lo stesso: le regole statiche perdono efficacia perché modelli e tattiche di attacco evolvono, mentre la configurazione resta ferma al giorno in cui è stata scritta.

Questo articolo non spiega cosa sono i guardrail, l’abbiamo già fatto altrove. Spiega cosa succede dopo l’installazione: il ciclo di vita di un guardrail, i segnali che dicono che sta scivolando, e chi se ne occupa mese per mese.

In questo articolo scoprirai:

• Perché un guardrail scade, e non lo dice a nessuno
• Cosa si installa davvero: tre livelli, tutti con una data di scadenza
• Monitoraggio: i segnali che dicono che un guardrail sta scivolando
• Taratura delle soglie: il guardrail troppo stretto viene disattivato
• Red team: un cambio di versione del modello è un cambio di sistema
• Tool authorization: l’allowlist è la parte che invecchia più in fretta
• AI Act e calendario: la manutenzione dei guardrail come obbligo

Perché un guardrail scade, e non lo dice a nessuno

Un firewall che si rompe smette di far passare traffico, e te ne accorgi in dieci minuti. Un guardrail che scivola continua a funzionare: risponde, logga, non genera errori. Il fallimento di un guardrail è silenzioso per definizione, perché il suo output normale è «tutto bene».

Le tre cause del degrado di un guardrail

Le cause del degrado sono tre, e sono tutte esterne al guardrail. La prima è il modello: gli allineamenti di sicurezza cambiano fra versioni, e non sempre migliorano nella direzione che serve a te. La letteratura sui jailbreak documenta il meccanismo in modo esplicito: una rassegna sistematica pubblicata su arXiv osserva che l’instruction tuning visivo induce un «forgetting effect» che riduce l’aderenza alle misure di sicurezza, cioè l’addestramento aggiuntivo può indebolire protezioni che prima tenevano. Lo stesso lavoro riporta che gli attacchi via fine-tuning portano i tassi di rifiuto sotto l’1% e che tecniche come I-GCG raggiungono «quasi il 100%» di successo su diversi modelli. Va detto con precisione: la letteratura misura il fenomeno su modelli riaddestrati, dove è il cliente a intervenire sui pesi, mentre sui cambi di versione lato fornitore l’effetto non è quantificato pubblicamente, ed è esattamente il motivo per cui va misurato in casa.

La seconda causa sono i tool. Ogni integrazione nuova è una superficie nuova: un connettore aggiunto a settembre non era nell’allowlist scritta a marzo, e nessuna regola lo copre. La terza è il caso d’uso, che si allarga sempre, quasi mai con un ticket che dice «rivedere i guardrail».

Il guardrail protegge un sistema che non esiste più

Il risultato è una divergenza lenta fra ciò che il guardrail protegge e ciò che l’agente fa davvero. È lo stesso ragionamento per cui il modello da solo non basta: la sicurezza di un sistema agentico non è una proprietà del componente, è una proprietà della configurazione, e le configurazioni invecchiano.

Cosa si installa davvero: tre livelli, tutti con una data di scadenza

Vale la pena guardare cosa contiene un guardrail di livello enterprise, perché la manutenzione si fa su pezzi precisi. La documentazione di Amazon Bedrock Guardrails elenca sei famiglie di filtri: content filters su categorie predefinite (odio, insulti, contenuto sessuale, violenza, misconduct e prompt attack), denied topics, word filters a match esatto, filtri per le informazioni sensibili con regex personalizzate, contextual grounding checks contro le allucinazioni e automated reasoning checks che validano la risposta contro regole logiche.

Due dettagli in quella pagina contano più degli altri. Il primo: per ogni categoria di content filter si configura la «filter strength», cioè esiste una manopola, e una manopola tarata è una manopola che si può stonare. Il secondo: AWS raccomanda esplicitamente di sperimentare e fare benchmark con configurazioni diverse usando la finestra di test, e struttura il tutto come working draft più versioni pubblicate. Il versionamento non è un vezzo da DevOps: è l’ammissione, nel design del prodotto, che quella configurazione cambierà.

Validazione dell’output: il guardrail che dipende dalle fonti

Il livello di validazione dell’output ha una sua fragilità specifica quando l’agente lavora su documenti aziendali. Il contextual grounding check confronta la risposta con le fonti recuperate: se la base di conoscenza cambia, nuovi documenti, nuovo chunking, nuovo indice, la soglia di grounding che funzionava prima produce un tasso di blocchi diverso. Chi gestisce un sistema RAG in evoluzione lo sperimenta ogni volta che reindicizza.

Autorizzazione dei tool: il guardrail che scatta a ogni chiamata

Il terzo livello è l’autorizzazione dei tool, e nell’Agents SDK di OpenAI è dove la meccanica si vede meglio: i guardrail di input girano solo per il primo agente della catena, quelli di output solo per l’agente finale, mentre i tool guardrail scattano a ogni singola invocazione di function tool, prima dell’esecuzione e dopo. Quando si attiva, il tripwire solleva un’eccezione e ferma l’esecuzione. Nessuna via di mezzo: o passa o si blocca. Che è esattamente il motivo per cui la taratura conta.

Monitoraggio: i segnali che dicono che un guardrail sta scivolando

Se il fallimento è silenzioso, l’unico modo di accorgersene è misurare. E il dato interessante non è quante volte il guardrail ha bloccato: è come si distribuiscono i blocchi nel tempo.

Tre serie temporali che dicono se i guardrail tengono

Tre serie temporali valgono più di una dashboard intera. La prima è il tasso di intervento per categoria: se i blocchi su «prompt attack» crollano da un mese all’altro senza che sia cambiato nulla nel traffico, l’ipotesi più probabile non è che gli attacchi siano finiti. La seconda sono le near-denials, cioè le richieste che passano appena sotto la soglia: sono il preavviso della prima che passerà sopra. La terza è la distribuzione dei tool invocati, dove compaiono le combinazioni che nessuno aveva previsto.

Strumenti di osservabilità per i guardrail in produzione

Gli strumenti per farlo esistono e sono maturati parecchio. La documentazione di Datadog LLM Observability descrive scansione automatica dei dati sensibili e rilevamento dei prompt injection fra le valutazioni disponibili, e una outlier detection che lavora su nomi degli span, tipi di workflow e topic di input/output per «rilevare proattivamente regressioni, drift di performance o comportamenti inattesi». Il drift non è una metafora: è una metrica che si può mettere su un grafico, e questa è la differenza fra manutenzione e speranza.

C’è un vincolo di conservazione che aiuta a dimensionare la cosa. L’Articolo 26 dell’AI Act impone ai deployer di sistemi ad alto rischio di conservare i log generati automaticamente per un periodo adeguato e comunque non inferiore a sei mesi. Sei mesi di log sono anche la finestra minima per vedere una tendenza: sotto quella soglia si osservano rumori, non derive. Su quali metriche mettere sotto controllo abbiamo un pezzo dedicato al monitoraggio di un agente AI e uno sull’osservabilità in produzione.

Taratura delle soglie: il guardrail troppo stretto viene disattivato

Qui sta il conflitto che rende la manutenzione dei guardrail un lavoro di giudizio e non di configurazione. Un guardrail ha due modi di fallire, e sono opposti. Se è troppo permissivo passa quello che non deve passare. Se è troppo severo blocca il lavoro legittimo, e allora accade la cosa peggiore di tutte: qualcuno lo allenta, o lo aggira, e la protezione esce dal perimetro senza che nessuno abbia deciso di rimuoverla.

Falsi positivi: il numero da misurare prima di alzare l’autonomia

La regola operativa emersa nel mondo della sicurezza è di stabilire una baseline di falsi positivi prima di concedere più autonomia all’agente: l’analisi di UnderDefense sui guardrail nei SOC lo pone come precondizione, non come misura successiva. Tradotto: l’autonomia si guadagna con un numero, non con una riunione. E quel numero va rimisurato quando cambia il modello, perché il tasso di falsi positivi di un filtro dipende da come il modello sottostante formula le risposte.

Latenza: il costo che nessuno mette nel business case

Ogni controllo aggiunge tempo, e i tempi si sommano. La rassegna delle soluzioni pubblicata da Galileo quantifica: circa mezzo secondo di latenza di base per NVIDIA NeMo Guardrails, con effetto cumulativo quando si impilano più tipi di rail, e 100, 500 ms per richiesta su Azure AI Content Safety. Un agente che fa cinque chiamate a tool con controlli in ingresso e in uscita paga quel conto dieci volte. La stessa analisi distingue i guardrail a regole statiche, che «richiedono aggiornamenti manuali mentre le minacce evolvono», da quelli eval-driven, che convertono le metriche di valutazione offline in policy di produzione. È una scelta architetturale che decide quanto lavoro manuale ti resta ogni mese.

Red team: un cambio di versione del modello è un cambio di sistema

Se c’è un momento in cui i test vanno ripetuti per intero, è l’aggiornamento del modello. Microsoft lo mette nero su bianco nella pagina dell’AI Red Teaming Agent di Foundry, che elenca «l’upgrade dei modelli dentro la tua applicazione» come uno dei momenti in cui far girare le scansioni automatiche, e raccomanda per il post-deployment «scheduled continuous red teaming runs» su dati avversariali sintetici. Continuo e schedulato: non una volta.

Cosa si testa su un agente, che su un modello non c’era

Le categorie di rischio agentiche di Foundry sono la lista della spesa di chiunque debba tarare i guardrail di un agente: prohibited actions (azioni vietate, ad alto rischio o irreversibili), sensitive data leakage (fuga di dati sensibili da knowledge base e chiamate a tool) e task adherence (l’agente ha fatto il compito rispettando regole e procedure, senza azioni non autorizzate). A queste si aggiunge la XPIA, l’iniezione indiretta di istruzioni nascoste nei dati che l’agente recupera, email, documenti, output di tool. È la variante che rende il prompt injection, prima voce della OWASP Top 10 per le applicazioni LLM, un problema di architettura e non di prompt.

La metrica è l’Attack Success Rate, la percentuale di attacchi riusciti sul totale tentato, e le strategie applicate sono decine, da Base64 e ROT13 all’inversione dei caratteri, fino a Crescendo e agli attacchi multi-turno che accumulano contesto per aggirare le difese. Microsoft avverte che l’ASR è valutato da modelli generativi e quindi è non deterministico: i risultati vanno letti prima di agire, e vanno confrontati con la campagna precedente più che con una soglia assoluta. La cadenza suggerita dalla checklist di conformità di Atlan è trimestrale, con esercizi mirati ai confini di contesto dell’agente. Trimestrale come pavimento, e comunque a ogni cambio di versione: è la regola più difendibile che i documenti primari supportano oggi.

Tool authorization: l’allowlist è la parte che invecchia più in fretta

Fra i tre livelli, l’autorizzazione dei tool è quella che degrada al ritmo del backlog di integrazione, cioè settimane. Ed è anche quella dove il danno possibile è maggiore, perché un filtro sull’output produce una frase sbagliata, mentre un tool autorizzato di troppo produce un’azione: un pagamento, una cancellazione, una mail a un cliente.

Allowlist per singolo agente: il principio che regge i guardrail sui tool

La checklist di Atlan è netta sul principio: bisogna enumerare esplicitamente quali tool ogni agente può invocare, mantenendo un’allowlist per singolo agente e non un permesso «allow all» di default, con rate limiting sulle invocazioni e sandboxing dei tool che scrivono. UnderDefense aggiunge la gradazione: quattro livelli di autonomia, dalla sola lettura con logging completo fino allo zero trust con umano sul loop per le azioni irreversibili, e una tabella in cui la scrittura in produzione resta semplicemente «blocked, never auto». Non è pessimismo: è la constatazione che alcune azioni non hanno rollback.

La manutenzione qui ha una forma molto concreta: ogni volta che si collega un nuovo tool, e con la diffusione dei server MCP capita in continuazione, bisogna rispondere a tre domande prima di aprire. Quale agente lo può chiamare. Con quali parametri, e con quale limite di frequenza. Cosa accade se il tool viene invocato con input generati da contenuto non fidato. Se la risposta alla terza è «non lo sappiamo», il tool va in sola lettura finché non si sa.

Supervisione umana: il complemento che i guardrail non sostituiscono

Sul versante opposto c’è la supervisione umana, che non è un guardrail ma il suo complemento: il guardrail decide da solo secondo una regola scritta prima, la persona decide caso per caso quando la regola non basta. Abbiamo raccontato altrove perché la supervisione umana in produzione resta indispensabile, e perché gli agenti sappiano essere opachi sui propri obiettivi.

AI Act e calendario: la manutenzione dei guardrail come obbligo

Finora abbiamo parlato di buone pratiche. Per una parte dei sistemi, però, mantenere i guardrail non è una scelta di qualità: è un adempimento con una carta intestata sopra.

Cosa chiede la norma a chi usa e a chi fornisce

L’Articolo 26 impone al deployer di un sistema ad alto rischio di monitorarne il funzionamento secondo le istruzioni per l’uso, di affidare la sorveglianza umana a persone con competenza, formazione e autorità per esercitarla, e, se ha motivo di ritenere che il sistema presenti un rischio, di informare fornitore e autorità senza indebito ritardo e sospenderne l’uso. Sul lato fornitore, l’Articolo 72 richiede un sistema documentato di monitoraggio post-commercializzazione attivo per tutto il ciclo di vita, con il piano incluso nella documentazione tecnica dell’Allegato IV. L’analisi di KLA Digital sull’applicazione dell’Articolo 72 agli agenti traduce l’obbligo in oggetti misurabili: esecuzioni di tool fallite, retry, tentativi non autorizzati, dinieghi e quasi-dinieghi, code di approvazione, giustificazioni degli override. E fissa il punto che dovrebbe stare scritto sopra ogni progetto: «una dashboard non è un piano». Il piano dice quali rischi si seguono, quali soglie fanno scattare l’escalation, chi rivede cosa e come si registrano le azioni correttive, perché da lì partono i termini dell’Articolo 73, fino a due giorni per gli incidenti che toccano i diritti fondamentali. Il quadro completo di scadenze e platee è nella nostra guida all’AI Act e nel pezzo su AI Act e agenti AI in azienda.

Il ciclo mensile: chi lo fa, in concreto

Messo tutto in fila, il ciclo di vita di un guardrail è un calendario, non un progetto: ogni mese la revisione dei log e delle soglie con i falsi positivi ricontati; a ogni nuovo tool la revisione dell’allowlist; a ogni cambio di versione del modello la ripetizione della campagna di red team; ogni trimestre l’esercizio avversariale completo e l’aggiornamento del piano di monitoraggio. È lavoro ricorrente e specialistico, e qui sta il motivo per cui in MIMIR l’agente non lo vendiamo come prodotto da consegnare e salutare: l’onboarding assistito e la manutenzione continua sono parte del servizio, perché sono la parte che decide se i guardrail installati il primo giorno funzioneranno ancora al centottantesimo. Ne abbiamo scritto parlando di manutenzione post-deployment e di governance, policy e audit.

Se state valutando un agente AI per la vostra azienda, o ne avete già uno in produzione con guardrail che nessuno rivede da qualche mese, quella revisione è il primo posto dove guardare, e non serve affrontarla da soli. Su mimir.bot potete richiedere un confronto sul vostro caso: partiamo da come è configurato oggi il sistema e da cosa è cambiato intorno, prima di parlare di tecnologia.

Fonti:

• Amazon Bedrock Guardrails — documentazione ufficiale AWS
• OpenAI Agents SDK — Guardrails
• AI Act, Articolo 26 — obblighi dei deployer di sistemi ad alto rischio
• NVIDIA NeMo Guardrails — documentazione ufficiale
• KLA Digital — piano di monitoraggio post-commercializzazione per agenti AI (Art. 72)
• arXiv 2601.03594 — rassegna sistematica sui jailbreak e sul degrado dell’allineamento
• Galileo — rassegna delle soluzioni di guardrail per agenti AI
• Atlan — checklist enterprise per i guardrail degli agenti AI
• Microsoft Azure AI Foundry — AI Red Teaming Agent
• Datadog LLM Observability — documentazione ufficiale
• OWASP — LLM01:2025 Prompt Injection
• UnderDefense — guardrail e livelli di autonomia nei SOC con AI