Governance Verificabile per IA Agentica: Da Principi Consultivi a Watchdog in Runtime

Il gap di governance nell'IA agentica è strutturale, non filosofico. La maggior parte della governance di IA — principi, codici etici, model card, framework consultivi — descrive come l'IA dovrebbe comportarsi. Niente di tutto ciò impedisce all'IA di fare qualcos'altro quando nessuno guarda. Per modelli predittivi senza effetti collaterali nel mondo reale, quel gap è tollerabile. Per agenti che agiscono tramite tool call — inviando email, eseguendo trade, modificando dati di produzione, spendendo denaro — non lo è.

Il recente paper Verifiable Governance Architecture (VGA) for Organisations and Teams with Human and AI Employees (Fradelos, gennaio 2026) nomina questo gap direttamente: "molti principi di governance sono consultivi, mentre gli agenti moderni agiscono tramite tool call con conseguenze nel mondo reale." Poi propone un pattern di ingegneria per chiuderlo: un Watchdog runtime che media le tool call con semantica fail-close (default-deny), governance codificata come policy-as-code (OPA/Rego), e un evidence store immutabile che impedisce all'IA di allucinare la propria conformità.

Questo è il pattern di design che il campo aspetta da un po'. Vale la pena capirlo in dettaglio perché le scelte sono non ovvie e i modi di fallimento delle alternative più deboli sono reali.

L'Idea Centrale: Confini di Azione, Non Comportamento Medio

Tre approcci di governance dominano la pratica corrente:

1. Guardrail di prompt: aggiungere istruzioni di sicurezza al system prompt.
2. Supervisione di reward model: addestrare modelli a rifiutare certe azioni.
3. Supervisione di processo: inserire revisori umani nei punti di decisione.

Tutti e tre migliorano il comportamento medio. Nessuno di essi, da solo, fornisce garanzie di confine d'azione per strumenti irreversibili.

Questa è l'idea che fa seguire il resto del pattern. Un agente che è stato addestrato a "non esfiltrare dati cliente" non esfiltrerà dati cliente in media. Può esfiltrare dati cliente in condizioni avversariali, in distribuzioni di prompt insolite, in sequenze di tool call che nessuno ha anticipato, o semplicemente perché la distribuzione di addestramento non copriva lo scenario specifico. I miglioramenti medi non sono garanzie di sicurezza per azioni irreversibili.

Il pattern VGA parte dalla postura opposta: non cercare di rendere l'agente affidabilmente buono. Fai in modo che le azioni che l'agente può prendere siano vincolate da qualcosa che l'agente non può aggirare.

Il Watchdog

Il Watchdog è lo strato runtime che media ogni tool call prima che raggiunga lo strumento. Ogni azione che l'agente vuole compiere ci passa. Il Watchdog ha tre proprietà che lo distinguono da alternative più lasche:

Fail-close (default-deny)

Se il Watchdog non può verificare positivamente che un'azione sia permessa, l'azione è negata. Questo è l'opposto della maggior parte dei pattern di guardrail in produzione, che sono fail-open di default — se la regola non fa match, l'azione procede.

Fail-close non è negoziabile per IA agentica specificamente perché il modo di fallimento di fail-open è "l'agente ha fatto qualcosa che nessuno ha autorizzato quando la policy non anticipava il caso". Fail-close significa che il modo di fallimento è "l'agente si è fermato e ha chiesto", che è recuperabile.

Media la superficie di strumenti, non la superficie del modello

Il Watchdog non si siede tra l'utente e il modello. Si siede tra il modello e gli strumenti. Questo conta perché il ragionamento del modello, il contenuto del prompt e gli output intermedi sono tutti in scope per la moderazione di contenuto, ma non sono il confine d'azione. Il confine d'azione è la tool call. Mettere il Watchdog alla superficie degli strumenti significa che la policy applicata è la policy che davvero conta.

Autorizzazione multi-parte per azioni sensibili

Alcune azioni richiedono più di un approvatore. Il Watchdog può esprimerlo naturalmente: una tool call per "trasferire >10k$" richiede un evidence packet firmato sia dall'agente sia da un approvatore umano prima che la chiamata proceda. Una tool call per "modificare lo schema del database di produzione" richiede una pipeline CI/CD che ha eseguito i controlli di sicurezza della migrazione. L'architettura è la stessa; la policy varia per sensibilità.

La Matrice MVV: Legare Leggi ad Artefatti Verificabili

La seconda idea centrale è la matrice di Verifica Minima Vitale (MVV). Lega ogni regola di governance a un artefatto specifico verificabile e a una cadenza specifica a cui quell'artefatto deve essere prodotto.

Senza MVV, le regole di governance diventano aspirazionali. "Il sistema deve essere auditabile" suona bene e non verifica nulla. Con MVV, "il sistema deve essere auditabile" si traduce in artefatti specifici:

• Un log immutabile di ogni tool call con la decisione di policy allegata.
• Un evidence packet firmato che lega intento → tool call → esito.
• Un report di attestazione settimanale da un auditor designato.
• Una revisione esterna trimestrale con scenari red-team.

Ogni artefatto ha un produttore, formato e cadenza definiti. La verifica della conformità si riduce a "l'artefatto è stato prodotto in tempo, nel formato giusto, con firme valide?" — che è qualcosa che una pipeline CI/CD può controllare.

Questo è ciò che "governance-as-code" significa davvero in pratica. Non sono solo policy in Rego. È l'evidenza verificabile dell'applicazione delle policy, prodotta dal runtime, su un calendario, in formati che un regolatore potrebbe auditare.

Perché l'Evidence Store Deve Essere Immutabile

La scelta di design più sottile è l'evidence store immutabile. Il Watchdog produce un record di ogni decisione; quel record va in uno store che l'agente stesso non può modificare o retrodatare.

Il motivo è ciò che il paper chiama allucinazioni di governance: il modo di fallimento dove l'agente produce un report di conformità di apparenza plausibile che non corrisponde a ciò che è realmente accaduto. Se l'evidence store è modificabile da qualsiasi cosa alla portata dell'agente, l'agente (deliberatamente o come comportamento emergente) può produrre evidenza di conformità che non riflette le azioni prese.

La correzione è strutturale: la conformità dipende dall'evidence store, l'evidence store è modificabile solo dal Watchdog, il Watchdog è fuori dalla superficie di strumenti dell'agente. Anche se l'agente produce un perfetto riassunto di conformità, l'audit può confrontarlo con lo store immutabile e rilevare la divergenza.

Questo è lo stesso principio di separare l'autorità di scrittura del database dal codice applicativo in qualsiasi sistema serio di produzione. La novità è applicarlo all'evidenza di governance di IA.

Diritti di Decisione Dipendenti dall'Anzianità

La quarta idea è operativamente importante: gli agenti hanno anzianità. Un agente "junior" ha accesso agli strumenti ristretto e richiede autorizzazione multi-parte per la maggior parte delle azioni non banali. Un agente "professionista" ha accesso più ampio. Un agente "senior" può autorizzare azioni di scope più ristretto in nome di altri.

Questo suona come il controllo accessi aziendale perché lo è. Il punto è applicarlo specificamente agli agenti IA, con lo stesso rigore e la stessa auditabilità del controllo accessi basato su ruoli umani. In pratica questo significa:

• I nuovi agenti partono come junior con accesso agli strumenti vincolato. Guadagnano (o sono configurati a) scope più ampio solo dopo aver passato una verifica specifica.
• L'accesso agli strumenti è il confine, non "l'addestramento del modello" o "il system prompt". Due agenti che usano lo stesso modello possono avere diritti di decisione molto diversi in base alle loro policy di accesso.
• Le promozioni sono esplicite e auditate. Quando un agente passa da scope professionista a senior, il cambiamento è registrato, l'evidenza è conservata, il rollback è diretto.

Questa è la parte che la maggior parte dei sistemi agentici in produzione nel 2026 ancora sbagliano. Hanno un solo ruolo di agente con tutti gli strumenti, e il confine è un system prompt. Il pattern di anzianità è una rappresentazione più onesta di ciò che è effettivamente necessario.

Mappatura su Regimi di Conformità Reali

Il pattern è esplicitamente progettato per mappare sugli obblighi di conservazione registri e robustezza dell'EU AI Act. L'evidence store soddisfa la conservazione dei registri. Il Watchdog fail-close soddisfa la robustezza. La matrice MVV soddisfa i requisiti di auditabilità. L'autorizzazione multi-parte soddisfa i requisiti di supervisione umana per sistemi ad alto rischio.

Questo non è accidentale. L'architettura è progettata in modo che la conformità diventi una proprietà degli artefatti prodotti, non una questione di "l'agente si è comportato bene". Questo è l'unico modo durevole di conformarsi a regolamenti che richiedono evidenza piuttosto che fiducia.

Cosa Significa Se Stai Costruendo Sistemi Agentici Ora

Azioni pratiche per qualsiasi team che rilascia IA agentica nel 2026:

1. Sposta l'applicazione delle policy alla superficie di strumenti. Se i tuoi guardrail vivono nel system prompt, hai governance consultiva. Metti un mediatore fail-close tra il modello e gli strumenti.

2. Adotta policy-as-code. OPA/Rego è la scelta più matura; lo strumento specifico conta meno della disciplina. Le policy in codice possono essere riviste, versionate, testate in CI e auditate. Le policy nei prompt no.

3. Costruisci l'evidence store prima di scalare. Un log immutabile e firmato di azioni di agente è molto più difficile da retrofittare che progettare dall'inizio. Anche se non hai ancora bisogno dell'audit, il valore di debugging operativo da solo giustifica il costo.

4. Applica anzianità agli agenti. I nuovi agenti ottengono scope ristretto. L'espansione di scope è esplicita, auditata e reversibile. Non eseguire tutti i tuoi agenti allo stesso livello di autorizzazione.

5. Esegui autorizzazione multi-parte su azioni irreversibili. Qualsiasi cosa finanziaria, qualsiasi cosa che tocchi dati cliente, qualsiasi cosa che modifichi la produzione. Il costo di performance dell'autorizzazione multi-parte è molto minore del costo di una cattiva azione.

Cosa Non Fa VGA

Due limiti onesti vale la pena nominare.

Non rende il modello migliore. VGA limita cosa l'agente può fare; non cambia quanto bene l'agente ragiona dentro quei limiti. Migliorare il comportamento del modello è ancora importante — ma ora è un problema di ottimizzazione dentro limiti di sicurezza noti, non il meccanismo di sicurezza in sé.

Costa latenza. Ogni tool call passa per la valutazione della policy. Con bundle OPA ben sintonizzati questo è millisecondi, ma non è zero. Per percorsi sensibili alla latenza, dovrai ingegnerizzare con cura — tipicamente con decisioni in cache per percorsi caldi e valutazione per richiesta per quelli sensibili.

Il costo è reale. Il costo di non averlo è molto più alto, e si presenta come titoli di testa.

Lo spostamento dalla governance consultiva a quella verificabile per IA agentica sta avvenendo; l'unica domanda è se la tua organizzazione è davanti o dietro la curva. Il pattern architetturale è qui. Adottarlo non è più un progetto di ricerca.

---

Fonte: Fradelos, G. Verifiable Governance Architecture (VGA) for Organisations and Teams with Human and AI Employees (Ginevra, 9 gennaio 2026). SSRN 6306840.

Stai costruendo sistemi agentici e hai bisogno di capacità di ingegneria che già costruisce con policy-as-code, watchdog fail-close ed evidence store immutabili? Parla con un CTO sul dispiegamento di uno squad nearshore con la giusta disciplina per governance di IA verificabile.