La sicurezza degli agenti di intelligenza artificiale utilizzati in azienda non può essere affidata esclusivamente ai filtri applicati ai contenuti o ai controlli destinati a impedire output pericolosi. Questi sistemi possono verificare che una risposta non contenga informazioni sensibili, bloccare determinate operazioni o limitare l’accesso agli strumenti, ma non stabiliscono automaticamente se un agente sia realmente autorizzato dall’organizzazione a emettere un rimborso, modificare dati in produzione, accettare condizioni contrattuali o assumere un impegno verso un cliente o un fornitore. Un’azione può essere tecnicamente corretta, coerente con le istruzioni ricevute e priva di problemi di sicurezza immediati, ma allo stesso tempo superare l’autorità che l’azienda avrebbe voluto delegare al sistema.
Il problema diventa particolarmente evidente nei flussi di lavoro commerciali. Un agente dedicato all’assistenza clienti può calcolare correttamente il rimborso spettante ma, in assenza di una soglia esplicita, potrebbe accreditare autonomamente una cifra superiore al limite previsto dall’azienda. Un sistema incaricato di modificare gli ordini può applicare esattamente la richiesta del cliente senza considerare una condizione finanziaria o logistica collegata all’evasione dell’ordine. Un agente utilizzato negli acquisti può individuare il fornitore più conveniente senza sapere se possiede l’autorità per accettarne le condizioni contrattuali oppure se il suo compito debba limitarsi alla formulazione di una raccomandazione. In tutti questi casi il sistema continua apparentemente a funzionare correttamente e l’errore può emergere soltanto quando produce conseguenze a valle.
Non si tratta quindi necessariamente di un problema di ragionamento del modello. Il punto critico è la mancata separazione tra capacità tecnica e autorità aziendale. Con il passaggio dagli assistenti virtuali, che si limitano prevalentemente a generare risposte o suggerimenti, agli agenti capaci di utilizzare strumenti, modificare sistemi e attivare flussi di lavoro, diventa necessario stabilire per ogni sistema quali operazioni possa eseguire autonomamente, quali richiedano un’approvazione, quali debbano rimanere semplici raccomandazioni e quali siano completamente escluse.
I tradizionali controlli di sicurezza restano indispensabili, ma risolvono un problema differente. Controllare contenuti dannosi, proteggere dati sensibili, verificare le risposte e limitare l’impiego di determinati strumenti serve a circoscrivere il comportamento tecnico dell’agente. I diritti decisionali devono invece rispondere a una domanda organizzativa: anche se un’azione è sicura e tecnicamente valida, quel particolare agente possiede l’autorità per compierla per conto dell’impresa?
La crescente difficoltà nel mantenere sotto controllo questi sistemi emerge anche dai dati raccolti nel 2026 dalla Cloud Security Alliance. Un’indagine pubblicata ad aprile e realizzata su 418 professionisti IT e della sicurezza ha rilevato che il 65% degli intervistati aveva registrato almeno un incidente collegato ad agenti AI nei dodici mesi precedenti, mentre l’82% aveva individuato nei propri ambienti agenti precedentemente sconosciuti. La diffusione dei cosiddetti agenti ombra mostra quanto velocemente l’introduzione di sistemi autonomi possa superare i tradizionali meccanismi di inventario, supervisione e attribuzione delle responsabilità.
Anche il World Economic Forum ha affrontato direttamente il problema introducendo, nel maggio 2026, l’Agent Capability and Authorization Profile, ACAP, un modello pensato per associare alle implementazioni agentiche un profilo esplicito di capacità e autorizzazioni. L’obiettivo è rendere le azioni delegate verificabili, applicabili e rendicontabili lungo l’intero ciclo di vita del sistema, collegando in un unico modello le politiche di delega, la progettazione tecnica e la supervisione operativa. Il punto centrale è che i vincoli applicati a un agente stabiliscono cosa il sistema riesce materialmente a fare, mentre un profilo di autorizzazione stabilisce cosa l’organizzazione gli consente legittimamente di fare.
Una possibile applicazione operativa di questo principio consiste nell’assegnare a ogni agente utilizzato in produzione un vero e proprio contratto di autorizzazione, cioè una registrazione formalizzata e verificabile automaticamente che descriva l’autorità delegata dall’impresa. Il documento dovrebbe identificare innanzitutto un responsabile umano o organizzativo del risultato prodotto dall’agente e precisare la tipologia di operazioni autorizzate, distinguendo per esempio tra lettura delle informazioni, formulazione di raccomandazioni, modifica dei dati e assunzione di impegni verso l’esterno.
Lo stesso contratto dovrebbe indicare i sistemi e i dati accessibili, insieme ai limiti di materialità entro i quali l’agente può operare autonomamente. Questi limiti possono riguardare importi economici, numero di record modificabili, categorie di clienti, informazioni sensibili oppure potenziale impatto operativo. È inoltre necessario definire le condizioni che impongono un’escalation, come un livello elevato di incertezza, la presenza di anomalie, l’utilizzo di dati particolarmente delicati o il superamento di determinate soglie di rischio. Devono essere specificati anche la reversibilità delle operazioni, il soggetto autorizzato ad annullarle, la durata dell’autorizzazione e le modalità attraverso cui essa può essere revocata.
Il controllo degli accessi e il controllo dell’autorità restano quindi due verifiche distinte. Un sistema IAM può stabilire se l’agente possiede le credenziali necessarie per raggiungere un database o utilizzare un’applicazione, ma questa informazione non è sufficiente a determinare se sia autorizzato a compiere una determinata azione in uno specifico contesto commerciale. Il framework aggiornato di Singapore per la governance dell’AI agentica segue una distinzione simile, trattando separatamente i controlli di accesso, i vincoli comportamentali e le approvazioni umane e collegando il livello di supervisione all’ampiezza dell’azione, alla sua reversibilità e al possibile impatto.
Per rendere questi principi applicabili in produzione, ogni azione rilevante può essere associata a quattro possibili risultati: esecuzione autonoma, approvazione, raccomandazione oppure negazione. Le operazioni a basso rischio, circoscritte e facilmente reversibili possono essere eseguite direttamente. Rientrano in questa categoria, per esempio, il recupero di informazioni già autorizzate, la classificazione di una richiesta in entrata o l’aggiornamento di un campo non critico, purché l’impatto potenziale rimanga limitato e l’azione possa essere annullata.
Le operazioni più rilevanti possono invece essere preparate dall’agente ma mantenute in attesa dell’autorizzazione di una persona o di un servizio di policy deterministico. Pagamenti, modifiche ai sistemi di produzione o azioni capaci di incidere significativamente su clienti, dipendenti o soggetti terzi appartengono normalmente a questa categoria. In altri casi l’agente può elaborare dati, classificare informazioni o proporre una scelta, lasciando però la decisione definitiva a un responsabile identificato. Questo modello è indicato quando il giudizio contestuale rimane essenziale oppure quando le conseguenze legali, finanziarie o personali rendono inappropriata l’esecuzione completamente automatica.
Esiste infine una categoria di operazioni che deve rimanere completamente fuori dall’autorità dell’agente indipendentemente dal livello di affidabilità attribuito al suo ragionamento. La cancellazione di dati critici in produzione, l’assunzione di una decisione definitiva riguardante una persona oppure il superamento di un controllo obbligatorio di conformità sono esempi di operazioni che possono essere negate a priori. È importante che questo divieto venga applicato anche a livello tecnico: un’istruzione in linguaggio naturale che comunica all’agente di non eseguire una determinata operazione non costituisce infatti un vincolo infrastrutturale e non può sostituire una policy effettivamente applicata dal sistema.
Anche le autorizzazioni non dovrebbero essere considerate necessariamente statiche. La stessa operazione può infatti essere consentita in una situazione e richiedere un’approvazione in un’altra. Un piccolo accredito commerciale può essere eseguito automaticamente in condizioni normali ma richiedere un intervento umano se supera una soglia prestabilita, riguarda un account sottoposto a verifica oppure coinvolge un cliente soggetto a particolari obblighi regolamentari.
In un’architettura di questo tipo l’agente propone innanzitutto l’azione da compiere. Un livello separato di policy valuta quindi l’identità dell’agente, il soggetto per conto del quale sta agendo, lo strumento richiesto, i dati coinvolti, il contesto della transazione e il possibile impatto. Sulla base di queste informazioni il sistema restituisce una decisione, permettendo l’esecuzione autonoma, richiedendo un’approvazione, trasformando l’azione in una raccomandazione oppure negandola. La decisione dell’autorità, l’operazione eventualmente eseguita e il relativo risultato devono essere registrati, in modo che la telemetria raccolta nel tempo possa essere utilizzata per ampliare, restringere o revocare le autorizzazioni concesse.
Questo meccanismo è particolarmente importante nei processi commerciali, dove un errore dell’agente non coincide necessariamente con una risposta sbagliata. Un rimborso può essere calcolato correttamente ma superare la soglia autorizzata. Una modifica a un ordine può corrispondere esattamente alla richiesta del cliente ma invalidare una condizione di finanziamento. Una data di consegna può risultare compatibile con le giacenze di magazzino ma non tenere conto di un nuovo vincolo comunicato dal vettore. In questi casi il problema non nasce necessariamente da un ragionamento errato del sistema, ma dall’assenza di confini sufficientemente precisi sull’autorità che gli è stata delegata.
Anche l’intervento umano deve essere calibrato. Richiedere l’approvazione di un operatore per ogni singola operazione può sembrare il metodo più prudente, ma su larga scala rischia di trasformarsi in un processo puramente formale. Se le persone devono autorizzare continuamente migliaia di operazioni ordinarie, la capacità di individuare le vere eccezioni tende a diminuire. Il modello di governance di Singapore riconosce questo problema e prevede una supervisione concentrata soprattutto sui passaggi critici, sulle operazioni ad alto rischio e sulle azioni irreversibili, invece di mantenere necessariamente un controllo umano costante sull’intero flusso agentico.
Un modello proporzionato consente quindi l’esecuzione autonoma delle attività a rischio contenuto entro limiti chiaramente definiti, mantiene invece l’approvazione obbligatoria per le azioni ad alto impatto o difficilmente reversibili e utilizza comportamenti anomali o imprevisti come trigger per l’escalation. Quando un’azione rilevante non dispone ancora di una politica di autorizzazione definita, il comportamento più prudente consiste nella negazione predefinita. L’obiettivo non è concedere all’agente il massimo livello possibile di autonomia, ma individuare il massimo livello di autonomia che l’organizzazione riesce effettivamente a osservare, controllare ed eventualmente annullare.
Quando questi sistemi entrano stabilmente in produzione, anche le metriche di valutazione devono andare oltre la semplice accuratezza delle risposte. Un indicatore importante è il tasso di override, cioè la frequenza con cui gli operatori umani rifiutano o modificano in maniera significativa le decisioni formulate dall’agente. È altrettanto utile misurare la precisione dell’escalation, verificando se il sistema riesca a intercettare realmente le operazioni rischiose senza trasferire inutilmente agli operatori attività ordinarie che potrebbero essere automatizzate.
Dovrebbero essere registrati anche i tentativi di azione non autorizzata, in modo da individuare quanto frequentemente un agente cerchi di oltrepassare i propri limiti relativi a sistemi, dati o operazioni. A queste informazioni si aggiungono il tasso di errori con effettivo impatto aziendale, valutando conseguenze economiche, operative, di conformità o sui clienti, e la latenza decisionale introdotta dai processi di approvazione. Quest’ultimo parametro permette di capire se i controlli stiano effettivamente gestendo un rischio concreto oppure stiano rallentando un processo che potrebbe operare in sicurezza con maggiore autonomia.
L’autorità concessa agli agenti può così diventare una variabile operativa sottoposta a misurazione e revisione. Prestazioni affidabili e costanti possono giustificare un ampliamento progressivo dell’autonomia entro limiti prestabiliti, mentre ripetuti tentativi di superamento delle autorizzazioni, errori nelle procedure di escalation o violazioni delle policy possono determinare una riduzione dei privilegi o la loro revoca.
La governance degli agenti AI non coincide quindi con la sola sicurezza del modello, con il controllo dei contenuti generati o con la protezione degli strumenti utilizzati. Questi elementi rimangono fondamentali, ma non definiscono chi abbia delegato un determinato potere all’agente, quanta autorità sia stata effettivamente trasferita, in quali condizioni possa essere esercitata e chi rimanga responsabile quando un’azione produce conseguenze indesiderate.
L’utilizzo operativo degli agenti richiede per questo una separazione esplicita tra ciò che un sistema è tecnicamente capace di fare e ciò che l’azienda è disposta ad autorizzarlo a fare. Accessi, limiti economici, sistemi utilizzabili, condizioni di escalation, reversibilità, durata delle autorizzazioni e responsabilità devono diventare elementi verificabili dell’architettura. Con agenti sempre più capaci di intervenire direttamente sui processi aziendali, il problema non è più soltanto dimostrare che un sistema sappia eseguire un’attività, ma stabilire con precisione entro quali confini possa farlo autonomamente per conto dell’organizzazione.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)