Governare gli agenti AI in azienda: il 21% di Deloitte e la realtà della produzione

C'è un dato, nel report Deloitte "State of AI in the Enterprise 2026 - The Untapped Edge", presentato a Davos il 21 gennaio 2026 su 3.235 leader in 24 paesi, che ogni CIO dovrebbe fissare sul monitor: solo il 21% delle aziende ha un modello di governance maturo dei propri agenti autonomi (fonte: Deloitte). Letto al contrario, è ancora più netto: il 79% sta scalando, o tentando di scalare, deployment di agenti AI senza un'infrastruttura di controllo. Dietro l'hype che racconta un'azienda dopo l'altra "con gli agenti in produzione", la realtà misurata è una minoranza che ha fatto il lavoro di governance e una maggioranza che vola alla cieca. Per chi guida l'IT, questo non è un dettaglio da convegno: è la differenza tra una sperimentazione gestita e un rischio non governato in produzione.

Il 21% non è la quota di aziende che usa gli agenti AI: è la quota che li governa. La distanza tra questi due numeri è esattamente lo spazio in cui, nel 2026, sono avvenuti gli incidenti agentici, ed è lo spazio che un CIO deve chiudere prima di scalare, non dopo.

Voglio leggere questo dato con onestà, perché la lettura onesta è anche la più utile, e poi tradurlo in cosa va normato prima di mettere un agente in produzione. Non è un discorso teorico: gli incidenti agentici del 2026, dalle esfiltrazioni via prompt injection alle campagne orchestrate da AI, hanno mostrato esattamente cosa va storto quando manca il controllo, e il framework di governance segue quei fallimenti uno a uno.

Quanti agenti sono davvero in produzione, e cosa dice il dato?

La risposta, dietro gli annunci, è "meno di quanti sembri, e in modo più fragile". Lo stesso filone di ricerca lo conferma da più angoli. Sul fronte del passaggio dalla sperimentazione alla produzione, solo il 25% dei rispondenti ha portato in produzione oltre il 40% dei propri pilot: il resto resta esperimento. Sul fronte agentico, una minoranza, intorno a un quarto delle aziende, sta effettivamente scalando agenti, mentre la maggioranza è ferma alla sperimentazione. E quando si chiede cosa blocca lo scaling, la risposta dominante, per due terzi dei rispondenti, sono le preoccupazioni di sicurezza e di rischio: non la tecnologia, non i costi in prima battuta, ma la mancanza di controllo.

Questo quadro è coerente con una previsione che vale come avvertimento, e che cito perché un CIO la deve avere in mente: Gartner stima che oltre il 40% dei progetti di AI agentica verrà cancellato entro la fine del 2027, per costi in escalation, valore di business poco chiaro o controlli di rischio inadeguati. Tradotto: la maggior parte degli agenti messi in produzione senza governance non sopravvivrà, e non per ragioni tecnologiche, ma perché senza controllo del rischio non si scala, si rimane bloccati o si arretra. La governance non è il freno all'innovazione agentica, è la condizione per portarla oltre il pilota.

Se la tua azienda sta valutando o già sperimentando agenti AI e vuoi impostare la governance che permette di scalarli in sicurezza, nel mio hub dedicato all'AI per la sicurezza aziendale raccolgo gli articoli con la metodologia che applico.

L'illusione dell'agente in produzione

Vale la pena soffermarsi su perché il divario tra l'annuncio e la realtà sia così ampio, perché capirlo aiuta un CIO a non cadere nella stessa trappola. C'è una forte pressione, interna ed esterna, a dichiarare di avere "gli agenti in produzione": lo chiede il mercato, lo chiede il consiglio, lo chiedono i concorrenti che a loro volta lo dichiarano. Il risultato è una zona grigia in cui un proof of concept che gira in un ambiente controllato, su casi selezionati, con un umano che sorveglia ogni passo, viene raccontato come "agente in produzione". Tecnicamente non è una bugia; sostanzialmente lo è, perché manca tutto ciò che rende la produzione diversa da una demo: il carico reale, l'input imprevedibile, l'avversario, e soprattutto l'autonomia senza supervisione costante.

La distinzione che propongo a chi guida l'IT è netta: un agente è "in produzione" quando opera su dati e processi reali, con un grado di autonomia che non richiede un umano a guardare ogni azione, e quando il sistema che lo contiene è progettato per reggere il fatto che prima o poi l'agente sbaglierà o verrà manipolato. Tutto il resto è sperimentazione, per quanto avanzata, ed è legittimo chiamarla così. Il problema nasce quando un'azienda si convince di essere nel primo gruppo mentre è nel secondo, e di conseguenza salta il lavoro di governance pensando di averlo già fatto. È esattamente la dinamica che il dato Deloitte mette a nudo: molti dichiarano la produzione, pochi hanno l'infrastruttura che la produzione richiede.

Per un decisore, riconoscere onestamente dove si trova è il primo atto di governance, e il più scomodo. È più facile raccontare al consiglio "siamo in produzione con l'AI agentica" che ammettere "stiamo sperimentando, e prima di scalare dobbiamo costruire i controlli". Ma è la seconda affermazione, non la prima, che porta dentro il 21% che scalerà davvero.

Cosa va normato prima di mettere un agente in produzione

Il framework che applico ha quattro pilastri, e non sono burocrazia: ognuno corrisponde a una classe di incidente reale del 2026, ed è la contromisura che lo previene. Li mappo qui, perché il legame tra il controllo e il fallimento che evita è ciò che li rende non negoziabili.

Il primo pilastro è la policy: prima di tecnologia, serve una decisione scritta su cosa un agente è autorizzato a fare, chi approva le azioni con conseguenze, quali confini di dato non può attraversare. Senza questa, ogni team che adotta un agente decide da sé, e le decisioni incoerenti sono la radice del rischio. Il secondo è il perimetro operativo: il least-privilege portato al livello dei tool e degli scope dell'agente, con la separazione netta tra lettura e scrittura. È la contromisura diretta alle esfiltrazioni via prompt injection che hanno colpito assistant enterprise nel 2026, e al privilege escalation che ho analizzato in MCP e over-broad token scoping; il modo di disegnare quel perimetro l'ho descritto in threat modeling dei sistemi ad agenti autonomi.

Il terzo pilastro è l'audit trail: ogni azione che un agente compie sui sistemi deve lasciare una traccia di chi, cosa e quando, idealmente a prova di manomissione. Serve per ricostruire un incidente, ma serve soprattutto per rilevarlo, perché la sequenza delle azioni di un agente è dove si vede un abuso in corso. Il quarto è il sandboxing: un agente che esegue codice deve girare in un ambiente isolato che non vede i segreti reali né la rete di produzione, così che anche un'esecuzione indotta da contenuto ostile cada nel vuoto. È la difesa contro la classe di attacco più grave, quella in cui un agente viene usato come orchestratore, e la pratica concreta l'ho raccolta in sandboxing di un agente che esegue codice arbitrario. Questi quattro pilastri non sono una checklist di conformità da spuntare: sono l'infrastruttura che distingue il 21% dal 79%.

Dove sei tu: le domande che separano i due gruppi

Prima di costruire il framework, un CIO deve sapere onestamente da dove parte, e bastano poche domande per scoprirlo. Non sono domande tecniche, sono domande di governance, e la qualità delle risposte dice immediatamente se sei nel 21% o nel 79%. La prima: esiste una policy scritta che dice cosa i vostri agenti possono e non possono fare, e chi l'ha approvata? Se la risposta è "ogni team decide", sei nel 79%. La seconda: se un agente compisse un'azione dannosa domani, sapreste ricostruire cosa ha fatto, attraverso quali tool, su istruzione di cosa? Se non esiste un audit trail che lo permetta, sei nel 79%. La terza: gli agenti che possono eseguire codice o azioni con conseguenze girano in un ambiente che non vede i segreti di produzione? Se vedono le credenziali reali, sei nel 79%.

La quarta domanda è la più rivelatrice: quanti dei vostri agenti hanno uno scope di accesso definito sul principio del minimo privilegio, e quanti hanno ricevuto accesso largo "per comodità"? La risposta a questa domanda, nella mia esperienza, predice quasi da sola il livello di maturità, perché lo scope largo concesso per comodità è la radice della maggior parte degli incidenti agentici. Un'azienda che sa rispondere "ogni agente ha solo gli scope che il suo compito richiede" ha già fatto il lavoro più importante; una che risponde "non lo so" o "abbiamo dato accesso ampio per non bloccare lo sviluppo" ha davanti il lavoro, e farebbe bene a farlo prima di scalare, non dopo il primo incidente.

Queste quattro domande sono anche il modo più rapido per comunicare la posta in gioco a un consiglio di amministrazione che vede solo l'opportunità e non il rischio. Non servono slide sull'AI agentica: serve chiedere "se domani un nostro agente esfiltrasse dati o eseguisse un'azione distruttiva, cosa sapremmo e cosa potremmo fare?". Il silenzio che spesso segue è la misura più onesta della distanza dal 21%.

Perché la minoranza matura è quella che scalerà

Qui sta il ribaltamento che un CIO dovrebbe portare in consiglio, perché capovolge la percezione comune che la governance rallenti. È vero l'opposto: il 21% che ha fatto il lavoro di governance è esattamente la minoranza che potrà mettere più agenti in produzione, e più in fretta, perché ha l'infrastruttura di controllo che rende sicuro farlo. Senza policy, perimetro, audit e sandboxing, ogni nuovo agente è un nuovo rischio non gestito, e prima o poi uno di quei rischi si materializza in un incidente che congela tutto il programma. Con quell'infrastruttura, aggiungere un agente è un'operazione governata, ripetibile, scalabile.

È la stessa logica per cui un'azienda con una buona CI/CD rilascia più spesso e più sicura di una che fa deploy a mano: il controllo non rallenta, abilita la velocità sostenibile. La previsione di Gartner sulla cancellazione di oltre il 40% dei progetti agentici è il prezzo che pagherà chi ha scambiato la governance per un ostacolo, scalando senza controllo fino al primo incidente o al primo conto dei costi fuori controllo. La minoranza matura non è quella che ha rinunciato a innovare per fare burocrazia: è quella che ha costruito le fondamenta perché l'innovazione regga il peso della produzione. Il dato Deloitte, letto bene, non racconta un ritardo della governance, racconta un vantaggio competitivo di chi l'ha fatta.

Per il mercato italiano il quadro è, se possibile, ancora più severo, e va detto a un decisore nazionale perché lo riguarda da vicino. La ricerca dell'Osservatorio Artificial Intelligence del Politecnico di Milano presentata il 5 febbraio 2026 misura che il 71% delle grandi imprese italiane ha avviato almeno un progetto AI, ma solo il 9% ha una governance strutturata dell'AI con responsabilità delineate. Il 21% globale di Deloitte e il 9% italiano del PoliMI raccontano lo stesso fenomeno con due lenti diverse: quasi tutti sperimentano, pochissimi governano, e in Italia il divario tra l'adozione e il controllo è perfino più ampio della media internazionale. Per un CIO italiano questo significa che la finestra per costruire un vantaggio è larga proprio perché la concorrenza, nella stragrande maggioranza, sta scalando senza fondamenta. Chi entra ora nel piccolo gruppo che governa davvero non insegue, anticipa. E la buona notizia, per chi decide di farlo, è che il framework non richiede un reparto di compliance né mesi di carta: richiede quattro pilastri concreti, costruiti con criterio ingegneristico, e la disciplina di non scalare un agente finché quei quattro pilastri non reggono il suo peso. È meno spettacolare di un annuncio sull'AI agentica, e infinitamente più solido. Se vuoi portare la tua azienda dentro quel 21%, costruendo il framework di governance che trasforma la sperimentazione con gli agenti in un sistema gestito e scalabile, puoi usare il modulo di preventivo gratuito: sette domande, due minuti, e ti dico se il tuo caso rientra nel mio perimetro o se ti conviene un'altra figura.