La governance uniforme sta facendo fallire gli agenti AI aziendali
Google News ha messo in luce un netto avvertimento per le imprese: una governance uniforme può rendere gli agenti AI meno sicuri, meno utili o entrambe le cose. L'analisi alla base, pubblicata da JFrog e rilanciata da Techzine Global, si basa su una previsione di Gartner con gravi conseguenze operative.
Gartner prevede che il 40% delle imprese ridurrà di livello o dismetterà gli agenti AI autonomi entro il 2027. L'azienda si aspetta che le lacune nella governance emergano solo dopo che si saranno verificati incidenti in produzione. Questa previsione trasforma la governance da un esercizio di conformità in un rischio di deployment.
Il conflitto non è tra governance e innovazione. È tra controllo uniforme e controllo proporzionato. Un assistente di ricerca e un agente autonomo per i pagamenti non generano la stessa esposizione. Eppure molte organizzazioni continuano a sottoporre entrambi a processi di revisione, autorizzazioni e regole di monitoraggio identici.
Questo approccio produce due fallimenti opposti. Controlli eccessivi rendono gli strumenti a basso rischio troppo lenti da distribuire. Controlli generali deboli lasciano invece gli agenti ad alto impatto con più autorità di quanta le organizzazioni possano supervisionare in sicurezza.
L'alternativa emergente assegna i controlli in base all'autonomia, all'accesso e alle potenziali conseguenze. Tratta inoltre ogni modello, strumento, plugin, skill e connessione come un componente software soggetto a governance.
Cosa ha realmente cambiato la notizia di Google News
Il cambiamento importante è il collegamento esplicito di Gartner tra governance uniforme e fallimento dei deployment degli agenti AI.
Gartner ha pubblicato il suo avvertimento il 26 maggio 2026. Ha sostenuto che applicare lo stesso modello di governance a ogni agente porta al fallimento, perché gli agenti operano con livelli diversi di autorità e ambito.
Questa distinzione sembra ovvia, ma le policy aziendali spesso la ignorano. Molti programmi iniziano con una policy di utilizzo accettabile, un comitato di revisione e una checklist di sicurezza. Questi controlli in genere affrontano l'AI generativa come una categoria ampia.
Gli agenti complicano questa struttura. Un agente AI è un sistema in grado di pianificare passaggi, selezionare strumenti ed eseguire azioni verso un obiettivo. Il suo comportamento dipende quindi da qualcosa di più del modello sottostante.
Un semplice agente di sintesi potrebbe leggere documenti e produrre testo. Non può modificare un file sorgente, inviare un messaggio o eseguire codice. Il suo peggior probabile fallimento è una risposta inaccurata o fuorviante.
Un agente di assistenza clienti può leggere dati di account, aggiornare record, emettere crediti e contattare gli utenti. I suoi errori possono incidere su denaro, privacy, obblighi contrattuali e fiducia dei clienti.
Un agente per l'infrastruttura presenta un'esposizione ancora maggiore. Potrebbe modificare risorse cloud, cambiare policy di accesso, distribuire codice o rispondere ad avvisi di sicurezza. Una sola azione errata può propagarsi nei sistemi connessi.
Un'unica etichetta, “agente AI”, nasconde queste differenze. Un unico pacchetto di controlli le nasconde di nuovo.
L'avvertimento sulla governance di Gartner separa l'autonomia dell'agente dall'ambito del suo accesso. Entrambe le dimensioni sono rilevanti.
L'autonomia descrive quanto indipendentemente un agente possa scegliere ed eseguire passaggi. L'ambito descrive i sistemi, i dati e i processi aziendali che può raggiungere. Un agente può avere un punteggio elevato su una dimensione e basso sull'altra.
Per esempio, un agente altamente autonomo in un ambiente di test sacrificabile può creare un rischio aziendale limitato. Un agente meno autonomo con accesso ai pagamenti in produzione può comunque richiedere controlli rigorosi.
Il risultato di Google News è importante perché indirizza verso un modello di governance basato sull'esposizione effettiva. La domanda rilevante non è più se un'organizzazione “consente gli agenti”.
I responsabili devono chiedersi cosa ogni agente possa osservare, decidere e modificare. Devono anche stabilire se tali azioni possano essere annullate.
Queste domande avvicinano la governance all'ingegneria. I team di policy continuano a definire il rischio accettabile, ma i sistemi tecnici devono applicare tali limiti durante lo sviluppo e in produzione.
Il cambiamento è quindi strutturale. La governance aziendale dell'AI non può rimanere un documento applicato durante l'approvazione. Deve diventare un sistema di controllo continuo legato a identità, autorizzazioni, dipendenze, azioni e risultati.
Perché una sola policy crea due fallimenti diversi
La governance uniforme fallisce perché la stessa restrizione può essere eccessiva per un agente e pericolosamente debole per un altro.
Il primo fallimento è la paralisi operativa. Un assistente interno a basso rischio può affrontare lo stesso processo di approvazione di un agente autorizzato a modificare record finanziari.
Questa revisione può coinvolgere team legali, privacy, cybersecurity, rischio di modello, procurement e architettura. Ogni gruppo può richiedere prove progettate per i sistemi più sensibili dell'organizzazione.
Questo processo ha senso per deployment con conseguenze rilevanti. Diventa sproporzionato quando un agente si limita a riassumere documentazione pubblica o a redigere testo per la revisione umana.
Cicli di approvazione lunghi non fermano sempre l'adozione. Possono spostarla al di fuori dei canali approvati. I dipendenti continuano ad avere scadenze, lavoro ripetitivo e pressione a usare gli strumenti disponibili.
Il risultato è la shadow AI, ovvero sistemi non approvati utilizzati senza visibilità centrale. Una policy uniforme rigorosa può quindi ridurre il deployment formale aumentando al contempo quello sconosciuto.
Il secondo fallimento è l'esposizione sistemica. Una checklist generale può approvare un agente ad alto impatto senza testarne gli strumenti specifici, le credenziali, i percorsi di errore o il comportamento di escalation.
Un agente che può leggere fatture è diverso da uno che può approvare pagamenti. Un agente che redige una modifica cloud è diverso da uno che la distribuisce automaticamente.
Il linguaggio ampio delle policy cattura raramente questi confini. Anche termini come “supervisione umana” significano poco senza descrivere dove avviene l'approvazione e quali prove riceve il revisore.
Un umano che approva ogni azione può diventare un mero ratificatore. Un umano che esamina solo azioni eccezionali necessita di criteri affidabili per identificare le eccezioni.
Anche la tempistica conta. L'approvazione dopo un'azione irreversibile non costituisce una supervisione significativa. Un audit post-incidente può spiegare il danno, ma non può prevenirlo.
L'analisi sulla governance degli agenti di JFrog inquadra la questione come una scelta tra restrizioni generalizzate e controlli proporzionati. La sua argomentazione riflette una prospettiva di supply chain del software.
Questa prospettiva è utile perché gli agenti sono composti da molteplici componenti in evoluzione. Un team può approvare un agente oggi e aggiornare domani il suo modello, prompt, plugin o strumento.
Ogni modifica può alterare il comportamento. Un nuovo strumento può ampliare l'accesso. Un prompt rivisto può cambiare le priorità decisionali. Un aggiornamento delle dipendenze può introdurre codice vulnerabile.
La governance uniforme tratta l'agente approvato come un oggetto stabile. Nella pratica, il sistema distribuito si comporta più come uno stack software in evoluzione.
Il modello di approvazione deve quindi tenere conto del cambiamento. Un aggiornamento innocuo non dovrebbe attivare lo stesso processo di una nuova funzionalità di pagamento. Tuttavia, le modifiche significative non possono passare inosservate.
Ciò richiede soglie definite. I team devono sapere quali modifiche richiedono test automatizzati, revisione della sicurezza, approvazione aziendale o una nuova valutazione del rischio.
Il problema centrale non è l'insufficienza di documentazione. È la scarsa granularità dei controlli.
La governance ha una bassa granularità quando considera ogni agente equivalente. Acquisisce una granularità utile quando distingue tra autorità, sensibilità dei dati, reversibilità e portata operativa.
La vera divisione è tra accesso in lettura e autorità di azione
Un agente diventa materialmente più difficile da governare quando può cambiare il mondo al di fuori della sua finestra di conversazione.
I chatbot tradizionali producono principalmente contenuti. Gli utenti decidono se fidarsi di tali contenuti e se agire di conseguenza. Questa separazione crea un confine naturale per l'approvazione.
Gli agenti possono rimuovere questo confine. Possono selezionare strumenti, chiamare API, aggiornare applicazioni e continuare a lavorare senza che una persona approvi ogni passaggio.
Questa capacità crea valore perché riduce i passaggi di consegne manuali. Ma sposta anche il punto di fallimento da una risposta sullo schermo a un'azione all'interno di un processo aziendale.
Consideriamo tre scenari aziendali.
Un agente di ricerca legge documenti approvati e redige una sintesi di mercato. Non dispone di strumenti di comunicazione esterna. Una persona verifica il risultato prima della distribuzione.
Un agente commerciale legge record dei clienti, crea attività di follow-up e redige messaggi. Può scrivere su una piattaforma di gestione delle relazioni con i clienti, ma non può inviare comunicazioni esterne.
Un agente dei ricavi modifica lo stato degli abbonamenti, applica crediti e invia comunicazioni ai clienti. Può produrre conseguenze finanziarie e reputazionali dirette.
Questi sistemi possono usare lo stesso modello di base. I loro requisiti di governance dovrebbero comunque differire nettamente.
Il primo agente necessita di controlli per l'accesso alle fonti, la fuoriuscita di dati e l'accuratezza fattuale. Il secondo necessita inoltre di restrizioni di scrittura, autorizzazioni a livello di record e registri delle modifiche.
Il terzo necessita di limiti di transazione, gate di approvazione, procedure di rollback, separazione dei compiti e sospensione rapida. Potrebbe inoltre richiedere una revisione della conformità legata a giurisdizioni specifiche.
Questa è governance proporzionata. I controlli aumentano man mano che un agente attraversa confini di fiducia con conseguenze più rilevanti.
Il principio compare già in framework consolidati. Il NIST AI RMF organizza il lavoro sul rischio attraverso le funzioni govern, map, measure e manage.
NIST non presenta queste funzioni come una checklist universale. La sua guida chiede alle organizzazioni di allineare la gestione del rischio al contesto, agli obiettivi, ai requisiti legali e alla tolleranza al rischio.
La funzione di mappatura del framework è particolarmente rilevante. Un team non può scegliere controlli adeguati finché non comprende i compiti previsti dell'agente, le parti interessate coinvolte, le condizioni operative e le probabili modalità di fallimento.
L'Unione europea segue una logica correlata. Il suo AI Act stabilisce obblighi diversi in base alle categorie di rischio e ai casi d'uso.
La guida sull'AI Act distingue tra sistemi a rischio inaccettabile, alto, di trasparenza e minimo. Non regolamenta ogni applicazione AI in modo identico.
La governance aziendale necessita di una differenziazione simile a un livello più dettagliato. La classificazione normativa fornisce un confine, ma il rischio operativo interno richiede livelli aggiuntivi.
Due agenti possono rientrare al di fuori di una categoria legale ad alto rischio pur creando esposizioni alla cybersecurity molto diverse. Uno può accedere a informazioni pubbliche, mentre un altro detiene credenziali per sistemi interni.
L'identità diventa un controllo centrale. Ogni agente dovrebbe avere un'identità non umana distinta, anziché prendere in prestito l'account di uno sviluppatore o condividere una credenziale di servizio ampia.
Le autorizzazioni dovrebbero seguire il principio del privilegio minimo. Ciò significa concedere solo l'accesso necessario per un compito definito e rimuoverlo quando non è più necessario.
Le organizzazioni necessitano inoltre di policy a livello di azione. L'accesso a un'applicazione non dovrebbe autorizzare automaticamente ogni operazione al suo interno.
Un agente potrebbe aver bisogno dell'autorizzazione per leggere un ticket, aggiungere una nota interna e suggerire una modifica di stato. Potrebbe non aver bisogno dell'autorizzazione per chiudere il ticket o cancellarne la cronologia.
Questa distinzione crea una superficie di azione controllabile. Rende inoltre gli audit più utili, perché i registri mostrano quale identità ha richiesto ogni operazione.
Ogni agente è anche una supply chain del software
La governance non può fermarsi all'approvazione del modello, perché i modelli sono solo un componente nel percorso di esecuzione di un agente.
Gli agenti moderni combinano modelli con prompt, memoria, sistemi di recupero delle informazioni, strumenti, plugin, API e codice di orchestrazione. Ogni componente può modificare ciò che l’agente sa o fa.
Un modello potrebbe generare un piano ragionevole. Uno strumento compromesso può comunque eseguire qualcosa di dannoso. Anche uno strumento sicuro può diventare pericoloso se configurato con autorizzazioni eccessive.
Il Model Context Protocol, comunemente chiamato MCP, illustra questa sfida. MCP offre un modo standard per le applicazioni di IA di connettersi a fonti di dati e strumenti eseguibili.
Questa standardizzazione può ridurre il lavoro necessario per le integrazioni personalizzate. Può anche rendere semplici da aggiungere nuove capacità, talvolta tramite pacchetti o server ottenuti da fonti esterne.
La facilità di connessione cambia il problema della governance. Un team di sicurezza può approvare il modello di un agente, ma non accorgersi di un server MCP aggiunto in seguito con accesso al codice sorgente o alle credenziali.
Plugin e skill sollevano preoccupazioni simili. Possono contenere schemi, istruzioni, script, ambiti di autenticazione e catene di dipendenze. Ogni elemento amplia il comportamento del sistema.
I programmi software tradizionali seguono percorsi di codice espliciti, anche se i sistemi complessi possono comunque comportarsi in modo inatteso. Gli agenti aggiungono decisioni guidate dal modello che selezionano tra tali percorsi in fase di esecuzione.
Questo non rende gli agenti impossibili da proteggere. Rende essenziali l’inventario dei componenti e l’osservazione in fase di esecuzione.
Le organizzazioni necessitano di una distinta base per ogni agente distribuito. Tale registro dovrebbe identificare modelli, prompt, strumenti, plugin, pacchetti, container, fonti di dati e servizi esterni.
Ogni componente dovrebbe avere un proprietario e una versione. I team dovrebbero sapere chi lo ha approvato, quali test ha superato e quali sistemi può raggiungere.
I controlli sulle dipendenze sono importanti perché un aggiornamento può alterare il comportamento senza cambiare il nome pubblico dell’agente. Una versione di plugin può richiedere nuove autorizzazioni o introdurre una libreria vulnerabile.
Gli artefatti dovrebbero passare attraverso repository affidabili. I controlli di sicurezza possono così analizzare pacchetti, container e file di configurazione prima della distribuzione.
La stessa disciplina dovrebbe coprire prompt e policy. Non sono codice eseguibile nel senso tradizionale, ma le modifiche possono alterare materialmente il comportamento dell’agente.
Un aggiornamento del prompt potrebbe istruire un agente a privilegiare la velocità rispetto alla revisione. Un aggiornamento della policy potrebbe consentire l’esecuzione automatica sotto una soglia di transazione.
Entrambe le modifiche meritano una cronologia delle versioni e test. La revisione richiesta dovrebbe corrispondere al loro impatto, non al formato del file.
Le linee guida OWASP sugli agenti descrivono rischi che emergono da obiettivi, strumenti, memoria, identità e interazione multi-agente. Questi rischi vanno oltre gli output inaccurati del modello.
La manipolazione degli obiettivi può reindirizzare un agente verso il fine di un attaccante. L’uso improprio degli strumenti può trasformare funzionalità legittime in un vettore di attacco.
L’avvelenamento della memoria può influenzare decisioni successive attraverso il contesto archiviato. Un’autonomia eccessiva può consentire a un agente di intraprendere azioni oltre l’intento dell’utente.
Queste minacce richiedono controlli diversi. Il solo filtraggio degli input non può impedire una dipendenza compromessa. La sola valutazione del modello non può rilevare un account di servizio con privilegi eccessivi.
Per questo una governance proporzionata deve anche essere incentrata sugli artefatti. La classificazione del rischio determina i controlli necessari, mentre la gestione degli artefatti rende tali controlli applicabili.
Il modello determina su cosa l’agente può ragionare. I suoi strumenti e le sue credenziali determinano cosa quel ragionamento può influenzare.
Una governance proporzionata richiede evidenze, non etichette
Un livello di rischio ha scarso valore se i team non riescono a dimostrare che i relativi controlli funzionano durante l’esecuzione reale.
Le organizzazioni spesso creano categorie come rischio basso, medio e alto. L’esercizio può diventare un’altra checklist uniforme se queste etichette non dispongono di criteri misurabili.
Un livello utile parte dall’autonomia. I team dovrebbero documentare se l’agente si limita a raccomandare azioni, richiede approvazione o esegue in modo indipendente.
La dimensione successiva è l’accesso. Include sensibilità dei dati, sistemi consentiti, tipi di operazione, confini geografici e utenti interessati.
Una terza dimensione è la conseguenza. I team dovrebbero stimare il danno derivante da comportamenti errati, dannosi o indisponibili.
La reversibilità costituisce un’altra dimensione importante. Una bozza può essere scartata. Un record interno può spesso essere ripristinato. Una divulgazione pubblica o un trasferimento finanziario possono essere difficili da annullare.
Anche la velocità modifica il rischio. Un agente che esegue un’azione al giorno sottoposta a revisione presenta un problema di contenimento diverso rispetto a uno che effettua migliaia di modifiche all’ora.
Queste dimensioni dovrebbero produrre controlli concreti.
Un agente di sola lettura a basso rischio può necessitare di fonti approvate, protezioni contro la perdita di dati, revisione degli output e logging di base. Il suo processo di rilascio può restare leggero.
Un agente a rischio medio, in grado di scrivere, può richiedere credenziali circoscritte, registri delle azioni, test automatizzati, limiti di utilizzo e approvazione per le operazioni sensibili.
Un agente autonomo ad alto rischio necessita di una separazione più forte. I controlli possono includere limiti alle transazioni, autorizzazione indipendente, monitoraggio continuo, sospensione d’emergenza e procedure di rollback testate.
L’organizzazione deve quindi verificare tali controlli. Un’affermazione scritta secondo cui un agente applica il principio del privilegio minimo non dimostra cosa la sua credenziale possa effettivamente fare.
I test dovrebbero tentare operazioni proibite. Dovrebbero confermare che l’agente non può raggiungere record, strumenti o ambienti non approvati.
I team dovrebbero inoltre testare percorsi indiretti. Un agente potrebbe non avere il permesso di modificare direttamente un pagamento, ma potrebbe comunque attivare un flusso di lavoro che esegue la modifica.
La telemetria in fase di esecuzione fornisce il livello successivo di evidenza. I log dovrebbero acquisire l’identità dell’agente, lo strumento selezionato, i parametri, il risultato e lo stato di approvazione.
I dati sensibili richiedono una gestione attenta nei log. Il monitoraggio non può diventare una nuova fonte di informazioni riservate o credenziali.
Le baseline comportamentali possono aiutare a rilevare attività insolite, ma non dovrebbero sostituire policy esplicite. Un comportamento nuovo dell’agente non è sempre dannoso, e un comportamento familiare non è sempre sicuro.
I controlli deterministici dovrebbero bloccare azioni chiaramente proibite. I sistemi comportamentali dovrebbero identificare pattern inattesi che meritano indagine.
La domanda scettica è se le imprese possano mantenere questo livello di dettaglio su migliaia di agenti. Un modello proporzionato richiede inventario, proprietà e monitoraggio più ricchi di un divieto generalizzato.
Un’implementazione carente può produrre inflazione dei livelli. I team possono classificare tutto come a basso rischio per evitare ritardi, oppure tutto come ad alto rischio per evitare responsabilità personali.
I responsabili di business devono quindi partecipare. I team di sicurezza comprendono le minacce, ma i proprietari dei processi comprendono le conseguenze finanziarie, per i clienti e operative.
Un proprietario dell’agente dovrebbe restare responsabile dopo la distribuzione. La proprietà include la revisione degli incidenti, l’approvazione delle modifiche sostanziali e la conferma che l’agente continui a svolgere una funzione valida.
Anche la governance dovrebbe scadere. Le autorizzazioni e le approvazioni dovrebbero avere date di revisione invece di restare valide indefinitamente.
Il modello più solido non è il controllo privo di attrito. È l’attrito collocato dove le conseguenze lo giustificano.
Cosa dovrebbero osservare i lettori di Google News
Il prossimo test sarà verificare se le imprese trasformeranno i principi basati sul rischio in controlli operativi applicabili.
Il primo segnale è la qualità degli inventari degli agenti. Le organizzazioni non possono governare sistemi che non riescono a identificare.
Un inventario credibile dovrebbe includere agenti autorizzati, agenti dei fornitori integrati, prototipi interni e servizi esterni connessi tramite account dei dipendenti.
La scoperta deve andare oltre i registri degli acquisti. Gli agenti possono entrare tramite estensioni del browser, funzionalità SaaS, pacchetti per sviluppatori, strumenti di workflow e marketplace cloud.
Il secondo segnale è la separazione delle identità. Le distribuzioni mature assegneranno a ciascun agente di produzione un’identità distinta con autorizzazioni ristrette e ispezionabili.
Gli account condivisi rimarranno un segnale di allarme. Offuscano la responsabilità e rendono più difficile sospendere un agente senza interrompere altri servizi.
Il terzo segnale è la visibilità a livello di azione. Le imprese dovrebbero sapere quali operazioni gli agenti tentano, quali vengono bloccate dalle policy e quali vengono approvate dalle persone.
Una dashboard che mostra l’utilizzo del modello è insufficiente. Il conteggio dei token non rivela se un agente ha modificato un campo del database o avviato una transazione aziendale.
La knowledge base ATLAS di MITRE offre un utile riferimento per le tattiche avversarie contro sistemi abilitati dall’IA. Le sue tecniche in evoluzione mostrano perché i modelli di minaccia debbano seguire il comportamento effettivo del sistema.
Le organizzazioni dovrebbero inoltre monitorare gli incidenti in produzione per livello di agente. Tali evidenze possono rivelare se i controlli sono proporzionati o semplicemente convenienti.
Se gli agenti a basso rischio affrontano lunghi ritardi senza benefici significativi per la sicurezza, la governance rimane troppo restrittiva. Se gli incidenti ad alto rischio emergono dopo la distribuzione, i controlli restano troppo deboli.
Le metriche dovrebbero includere latenza di approvazione, azioni bloccate, frequenza di rollback, eccezioni alle policy, strumenti non autorizzati e proprietà irrisolta.
Questi indicatori collegano la governance alle operazioni. Aiutano inoltre i leader a determinare se un controllo riduce il rischio o crea soltanto lavoro amministrativo.
Gli sviluppi normativi forniranno un altro segnale. L’Unione europea continua a pubblicare linee guida sulla classificazione ad alto rischio, il monitoraggio, la documentazione, la supervisione umana, la cybersicurezza e la risposta agli incidenti.
Tuttavia, la conformità legale rappresenta una soglia minima, non un programma completo di sicurezza degli agenti. Molte azioni dannose ricadono al di fuori dei casi d’uso specificamente regolamentati.
Anche il comportamento dei fornitori merita attenzione. Le piattaforme aziendali incorporano sempre più agenti nei prodotti esistenti, talvolta attivando nuove capacità tramite normali aggiornamenti delle funzionalità.
I clienti dovrebbero chiedere se tali agenti ricevono identità separate. Dovrebbero inoltre chiedere quali azioni possano essere limitate e quali record restino disponibili per l’audit.
La previsione di Gartner acquisirà credibilità se le imprese inizieranno a declassare gli agenti dall’esecuzione autonoma a modalità di raccomandazione. Tale cambiamento dimostrerebbe che le organizzazioni stanno correggendo l’autorità alla luce delle lezioni apprese in produzione.
La previsione si indebolirà se le aziende scaleranno sistemi autonomi senza un aumento degli incidenti o rollback diffusi. Questo esito richiede controlli che funzionino in tutti gli ambienti di sviluppo e di esecuzione.
Google News ha amplificato un utile avvertimento, ma il titolo non dovrebbe diventare un motivo per vietare gli agenti aziendali. L’argomento sostiene una governance più granulare, non un’automazione meno ambiziosa.
I dirigenti dovrebbero porre una domanda diretta su ogni agente distribuito: cosa può cambiare questo sistema senza che una persona lo fermi?
La risposta dovrebbe determinarne l’identità, le autorizzazioni, i test, il monitoraggio, i passaggi di approvazione e il processo di arresto. Se tali controlli restano identici per ogni agente, il modello di governance continua a non cogliere il rischio.
