Governance agenti AI in azienda: policy, audit e partner

Chi ha già portato agenti AI in produzione scopre presto che la domanda difficile non è “siamo conformi?”, ma “chi risponde se l’agente sbaglia domani mattina?”. Sono due problemi distinti, e confonderli è il modo più rapido per ritrovarsi con una policy firmata e nessun controllo reale. La governance degli agenti AI in azienda è la disciplina operativa quotidiana: chi possiede un agente, cosa può toccare, cosa viene registrato, quando si ferma e chi decide. La compliance normativa è il perimetro legale entro cui quella disciplina deve stare. Questo articolo tratta la prima, non la seconda: se cerchi obblighi e scadenze del regolamento europeo, il posto giusto è il nostro pezzo su AI Act e agenti AI in azienda.

In questo articolo scoprirai:

• Governance degli agenti AI in azienda: perché la compliance non basta
• La matrice di responsabilità: owner, reviewer, auditor
• Il registro degli agenti: l’antidoto all’agent sprawl
• Policy di accesso: identità dedicata e privilegio minimo
• Log obbligatori e audit trail: cosa tracciare e per quanto tempo
• Revisione umana: progettare l’escalation, non l’alibi
• Impostare la governance in onboarding e mantenerla nel tempo

Governance degli agenti AI in azienda: perché la compliance non basta

L’AI Act diventa applicabile ai sistemi ad alto rischio dal 2 agosto 2026 e impone la registrazione automatica degli eventi lungo tutto il ciclo di vita (Articolo 12), con conservazione dei log per almeno sei mesi (Articolo 19), il quadro completo di obblighi e date è nella nostra guida su AI Act Italia: obblighi e scadenze 2026. Sono requisiti di risultato: dicono cosa devi poter dimostrare, non come organizzare il lavoro. Lo stesso vale per i framework volontari: il NIST AI Risk Management Framework, quattro funzioni core (Govern, Map, Measure, Manage), è espressamente “intended for voluntary use”, una bussola metodologica, non un manuale operativo. E anche lo standard certificabile ISO/IEC 42001 definisce un sistema di gestione, non le regole del singolo agente.

La compliance è una fotografia, la governance degli agenti AI è un processo

Il divario si misura. Secondo dati Gartner ripresi da Cyberhaven, le aziende Fortune 500 gestiranno oltre 150.000 agenti AI entro il 2028, ma solo il 13% ritiene di avere una governance adeguata. Il paper accademico Governing the Agentic Enterprise (AAGMM) arriva a numeri simili: appena il 21% delle organizzazioni ha un modello di governance maturo, e il 40% dei progetti agentici è atteso al fallimento entro il 2027.

La differenza pratica è questa: un audit di compliance si supera una volta l’anno, mentre un agente che ha accesso al CRM prende decisioni ogni ora. Un processo di governance risponde a domande che la norma non pone, chi ha approvato l’ultimo cambio di permessi, quale versione del prompt era in produzione la settimana scorsa, chi si accorge se l’agente inizia a comportarsi in modo diverso. È lo stesso salto di prospettiva che descriviamo parlando di organizzazione agentica: cambiano i processi, non solo gli strumenti.

La matrice di responsabilità: owner, reviewer, auditor

Il punto di partenza concreto è assegnare tre ruoli distinti per ogni agente. Non tre persone necessariamente, ma tre responsabilità che non devono coincidere nella stessa firma. Il dato che giustifica questa insistenza arriva dal white paper del Cloud Security Alliance: il 51% delle organizzazioni non ha una proprietà chiara delle identità AI e il 78% non ha policy documentate per creare o rimuovere quelle identità.

Perché tre ruoli e non uno solo

Microsoft è esplicita nel Cloud Adoption Framework: la responsabilità della governance degli agenti va assegnata agli stessi leader che già rispondono di cloud, sicurezza e compliance, evitando modelli di governance paralleli. La raccomandazione è netta anche sul dimensionamento: se gli agenti restano confinati in un’unica funzione, i forum di governance esistenti possono bastare; quando attraversano più business unit serve un’accountability formalizzata con poteri decisionali definiti.

Se owner e reviewer sono la stessa persona, la revisione diventa autoconferma. Se l’auditor dipende dall’owner, il log serve a giustificare, non a verificare. Per una PMI la matrice si compila in mezz’ora: due nomi e un revisore esterno periodico, spesso il partner tecnologico, sono già una separazione dei poteri sufficiente. È uno dei temi che affrontiamo nella consulenza sugli agenti AI per PMI.

Il registro degli agenti: l’antidoto all’agent sprawl

“Non puoi governare agenti di cui ignori l’esistenza”: la formula di Microsoft è la sintesi migliore del problema che il mercato anglosassone chiama agent sprawl e che in italiano non ha ancora un nome diffuso. Okta lo definisce come la proliferazione incontrollata di agenti senza inventario né governance centralizzata, e riporta la previsione Gartner per cui il 40% delle applicazioni enterprise integrerà agenti task-specific entro fine 2026, da meno del 5% nel 2025. Il dato più scomodo è del Cloud Security Alliance: l’82% delle organizzazioni ha scoperto agenti di cui non conosceva l’esistenza, pur avendo dichiarato in precedenza (68%) piena fiducia nella propria visibilità.

Attenzione a non confondere i due fenomeni: sprawl è un fallimento di inventario, shadow AI è il fallimento di sicurezza che ne consegue. Lo stesso paper AAGMM classifica cinque pattern ricorrenti, duplicazione funzionale, agenti shadow, agenti orfani, permission creep e catene di delega non monitorate, e sono tutti diagnosticabili solo con un registro. La checklist di governance per CISO di Zenity mette la scoperta continua degli agenti al primo posto proprio per questo.

Campi minimi del registro agenti

Un foglio di calcolo condiviso è un registro accettabile per cinque agenti; a venti serve un sistema con controlli automatici. Il criterio non è lo strumento, è l’aggiornamento continuo.

Policy di accesso: identità dedicata e privilegio minimo

Ogni agente deve operare sotto un’identità propria e distinta, non con le credenziali di un utente o di un service account condiviso: è l’unico modo per rendere le azioni attribuibili. La scala del problema è nei numeri del Cloud Security Alliance: le identità non umane superano quelle umane con un rapporto medio di 45 a 1, che arriva a 144 a 1 negli ambienti cloud; il 47% non viene modificato da oltre un anno e una su venti dispone di privilegi amministrativi completi nonostante l’inattività. La raccomandazione operativa è lo zero standing privilege: accesso just-in-time, limitato al compito, con scadenza automatica. È la stessa linea della guida Microsoft su come governare e mettere in sicurezza gli agenti AI.

Dai guardrail tecnici ai livelli di autonomia

Flowable elenca quattro guardrail concreti: schemi di input/output strutturati, accesso soltanto a dati approvati via RAG, gestione esplicita di workflow e stato, livelli di autonomia configurabili. Quest’ultimo punto è il cuore della questione: l’autonomia va graduata, non concessa in blocco, da un regime in cui ogni passo è sottoposto a revisione umana fino alla modalità “autopilota” con monitoraggio continuo. Si alza la soglia man mano che cresce la fiducia misurata, non l’entusiasmo.

Sullo stesso asse, DataRobot definisce come componente autonoma il decision scope: stabilire in anticipo quali azioni l’agente esegue da solo e quali richiedono escalation, così l’autonomia resta possibile nei casi a basso rischio senza slittamenti di perimetro. Le implicazioni su dati personali e minimizzazione le abbiamo trattate nell’articolo su sicurezza, GDPR e AI.

Log obbligatori e audit trail: cosa tracciare e per quanto tempo

Il minimo normativo lo abbiamo visto: registrazione automatica degli eventi e sei mesi di conservazione per i sistemi ad alto rischio. Il minimo operativo è più esigente, perché un log che dice solo “l’agente ha inviato un’email” non serve a ricostruire nulla. Per ogni azione rilevante vanno tracciati identificativo e versione dell’agente, identità sotto cui ha operato, permessi delegati in quel momento, strumento o API invocati, esito e, dove il sistema lo consente, il passaggio di ragionamento che ha preceduto l’azione. La differenza è tra sapere che un agente ha cancellato un file e capire perché riteneva corretto cancellarlo.

Retention e monitoraggio: sei mesi sono un minimo, non un obiettivo

Microsoft raccomanda di verificare che la policy di retention copra l’attività degli agenti per tutta la durata richiesta dal proprio framework di compliance, e di monitorare i log di audit per un elenco preciso di eventi: modifiche ai blueprint degli agenti, aggiunte di credenziali, concessioni di permessi e assegnazioni di ruoli, con alert su qualsiasi variazione avvenuta fuori dalle pipeline di deploy normali. È il segnale che distingue un aggiornamento legittimo da un’anomalia.

Due avvertenze pratiche. La prima: configurare il logging per non conservare contenuto sensibile inutile, un audit trail non deve diventare un archivio parallelo di dati personali. La seconda: i log servono a qualcosa solo se qualcuno li guarda con una cadenza definita. Un audit trail perfetto senza un auditor nominato è archeologia post-incidente.

Revisione umana: progettare l’escalation, non l’alibi

L’errore più comune è trattare la revisione umana come rete di sicurezza universale. DataRobot lo dice chiaramente: l’intervento umano va applicato dove serve giudizio, non come fallback predefinito. Flowable individua i quattro trigger che lo rendono obbligatorio: quando la decisione dell’agente impatta compliance regolamentare, esiti finanziari, fiducia del cliente o responsabilità legale. Fuori da quei casi, un’approvazione umana su ogni output produce due danni: annulla il beneficio dell’automazione e, soprattutto, abitua il revisore a cliccare “approva” senza leggere.

Un’approvazione umana ha valore solo se chi la dà ha informazioni, tempo e motivo per usarli. Da qui due indicazioni operative. La prima: usare la revisione a campione o basata su soglie di rischio invece che sistematica, e trattare la frequenza con cui l’intervento umano è necessario come una metrica da monitorare, se scende stabilmente, la soglia di autonomia può salire; se risale, qualcosa è cambiato nei dati o nel processo. La seconda: definire in anticipo come si spegne un agente. Microsoft insiste sul punto, decidere prima come disabilitare rapidamente un agente che malfunziona, come comunicare l’incidente, come preservare i log per l’analisi forense. Il “kill switch” documentato e provato vale più di dieci pagine di policy. E poiché a premere il pulsante sono persone, la governance regge solo se accompagnata da change management e formazione del team.

Governance agenti AI in azienda: impostarla in onboarding, mantenerla nel tempo

La governance non è un documento da allegare al collaudo: è una configurazione iniziale più una manutenzione. Microsoft suggerisce un approccio graduale, partire da un modello basato su audit e osservazione, poi introdurre controlli più stretti, perché policy troppo rigide al primo giorno bloccano l’adozione. E il ritorno si misura: il paper AAGMM, su 750 simulazioni, rileva che i livelli di maturità 4-5 rispetto al livello 1 mostrano indici di sprawl inferiori del 94,3%, incidenti di rischio ridotti del 96,4% e task completion effettivo superiore del 32,6% (p < 0,001).

Cosa succede nell’onboarding con un partner

È esattamente il punto in cui, con Mimír, il servizio conta più del software. Durante l’onboarding non consegniamo solo agenti configurati: compiliamo il registro, assegniamo owner, reviewer e auditor per ogni agente, definiamo con il cliente i livelli di autonomia e le soglie di escalation, e verifichiamo che i log necessari vengano prodotti e conservati. Poi quella struttura va rivista con il tempo, perché i processi cambiano, i permessi si accumulano e gli agenti dismessi vanno chiusi davvero: è la parte che le piattaforme self-service lasciano al cliente. Se non sai da dove partire, il primo passo è una valutazione di AI agent readiness.

Se in azienda avete già agenti in produzione, o state per attivarne i primi, e la matrice di responsabilità non è ancora scritta da nessuna parte, vale la pena affrontarla prima che il numero di agenti la renda un problema di archeologia. Parlane con noi: guardiamo insieme cosa c’è oggi, cosa manca e in che ordine sistemarlo.

Fonti:

• AI Act — Articolo 12: registrazione degli eventi
• AI Act — Articolo 19: conservazione dei log
• NIST AI Risk Management Framework
• ISO/IEC 42001 — AI management systems
• Cyberhaven — AI agent sprawl
• Governing the Agentic Enterprise (AAGMM, arXiv)
• Cloud Security Alliance — Non-Human Identity & Agentic AI Governance
• Microsoft CAF — Governance e sicurezza degli agenti in azienda
• Microsoft CAF — Govern and secure AI agents
• Okta — What is agent sprawl
• Flowable — Governing enterprise AI agents
• Flowable — AI agent governance in enterprises
• DataRobot — Agentic AI governance framework
• Zenity — AI agent governance checklist for enterprise CISOs