La governance degli agenti AI aziendali passa dalle policy al controllo in runtime
La governance degli agenti AI aziendali ha superato il suo primo confine operativo: i soli documenti di policy non possono controllare software che intraprende autonomamente azioni nel mondo reale. Il modello emergente sposta l'applicazione dei controlli nel momento immediatamente precedente all'invio di dati da parte di un agente, alla modifica di un record, alla chiamata di uno strumento o a una spesa.
Questo cambiamento definisce l'argomento centrale della recente tesi del punto d'azione. La governance non riguarda più soltanto l'approvazione di un modello, la documentazione dei suoi rischi o la revisione dei suoi output dopo il deployment. Sta diventando un problema di sicurezza in runtime.
La pressione ricade sui team di sicurezza, sui provider di identità, sui responsabili delle applicazioni e su ogni fornitore che sviluppa piattaforme per agenti. Il conflitto è chiaro. Le aziende vogliono che gli agenti completino workflow più lunghi con minore supervisione, mentre i team di sicurezza devono garantire che ogni azione con conseguenze resti attribuibile e reversibile.
Non è l'ennesimo dibattito sulla necessità di regole per l'intelligenza artificiale. La domanda più urgente è dove tali regole debbano operare. Per i sistemi autonomi, la risposta si avvicina sempre più all'azione stessa.
Cosa è cambiato nella governance degli agenti AI aziendali
L'oggetto sottoposto a governance non è più soltanto un modello o un'applicazione. È un'identità operativa con strumenti, memoria, autorizzazioni e contesto mutevole.
La supervisione AI tradizionale si concentra su una sequenza relativamente stabile. Una persona invia un input, un modello genera un output e qualcuno esamina o utilizza quell'output. La governance può valutare il modello, i suoi dati di addestramento, l'uso previsto, i risultati delle valutazioni e i contenuti generati.
Un agente AI modifica questa sequenza. Può suddividere un obiettivo in passaggi, selezionare strumenti, recuperare informazioni, chiamare servizi esterni e modificare sistemi. Può inoltre ripetere questo processo finché non ritiene completato l'obiettivo.
Ogni passaggio può modificare il rischio di quello successivo. Una richiesta innocua di riassumere il feedback dei clienti diventa più sensibile quando l'agente apre un database clienti. Il rischio cambia ancora se esporta record, prepara messaggi o li invia senza revisione.
Ciò crea un divario tra l'approvazione in fase di progettazione e il comportamento in runtime. Un comitato di governance può approvare un agente per il supporto alle vendite, ma tale etichetta dice poco su una specifica query al database. Non può nemmeno stabilire se una determinata email debba essere inviata alle 2 del mattino da un account dirigenziale.
Il framework AI del NIST offre alle organizzazioni una struttura ampia per governare, mappare, misurare e gestire i rischi dell'AI. Questa struttura resta utile, ma gli agenti costringono i team a implementarne i principi a una granularità molto maggiore.
Una classificazione del rischio associata a un'intera applicazione non può rispondere a ogni domanda in runtime. Il sistema deve sapere chi ha richiesto l'attività, quale agente sta agendo, a quali dati ha avuto accesso e quale strumento ha selezionato. Deve inoltre sapere se l'azione richiesta supera l'autorità dell'utente.
Questo è il significato pratico della governance nel punto d'azione. Un controllo valuta un'azione tentata usando segnali correnti relativi a identità, autorizzazioni, dati e ambiente. Quindi consente, blocca, limita o sottopone a escalation quell'azione.
Il controllo potrebbe richiedere l'approvazione umana prima che venga trasferito denaro. Potrebbe oscurare campi sensibili prima che le informazioni raggiungano un modello. Potrebbe impedire a un agente di inviare email a un indirizzo esterno, anche quando lo stesso agente può creare una bozza interna.
Queste decisioni devono avvenire durante l'esecuzione. Una revisione trimestrale delle policy non può interrompere una pericolosa chiamata API. Un audit svolto dopo il deployment può spiegare un incidente, ma non può prevenire l'azione originaria.
Il cambiamento modifica anche ciò che conta come prova. Alle organizzazioni serve più di un record che dimostri che un agente è stato approvato. Servono log che colleghino la richiesta originaria alle decisioni del modello, alle chiamate agli strumenti, ai dati recuperati, alle approvazioni e al risultato finale.
Questa catena è importante quando un agente opera attraverso diversi servizi. Un workflow potrebbe iniziare in un'interfaccia di chat, recuperare un contratto, aggiornare un record cliente e creare una richiesta di pagamento. Ogni transizione crea un altro punto in cui l'autorità può espandersi o il contesto può andare perso.
La governance nel punto d'azione tratta queste transizioni come confini di sicurezza. L'approccio non presuppone che un agente approvato resti sicuro per tutta la durata di un workflow. Verifica se ogni azione significativa è ancora coerente con lo scopo originario e con l'autorità delegata.
Perché le policy AI statiche perdono il controllo in runtime
Una policy scritta descrive il comportamento accettabile, ma un workflow autonomo necessita di decisioni applicabili prima di ogni passaggio con conseguenze.
La governance statica è più efficace quando i sistemi si comportano in modo prevedibile. I team possono definire usi approvati, vietare input sensibili, testare un workflow fisso e formare i dipendenti. Queste misure diventano meno affidabili quando un agente sceglie autonomamente il proprio percorso attraverso strumenti connessi.
Un agente può iniziare con un obiettivo consentito e produrre comunque un'azione non ammissibile. Può fraintendere un'istruzione, seguire contenuti dannosi recuperati da un documento o combinare autorizzazioni singolarmente innocue. La capacità risultante può superare ciò che suggerisce ciascuna singola autorizzazione.
La prompt injection illustra questo problema. Un'istruzione ostile può comparire all'interno di una pagina web, di un'email, di un documento o di un ticket di assistenza recuperato dall'agente. Il contenuto indica all'agente di ignorare il suo obiettivo originario, divulgare informazioni o attivare un altro strumento.
Un filtro convenzionale può esaminare il prompt iniziale dell'utente e non rilevare nulla di pericoloso. L'istruzione dannosa entra successivamente, dopo che il workflow è già iniziato. La governance deve quindi seguire l'agente attraverso i cambiamenti del suo contesto.
La guida agentica di OWASP descrive rischi che coinvolgono autonomia eccessiva, uso improprio degli strumenti, manipolazione della memoria, guasti a cascata e interazioni tra agenti compromesse. Si tratta di rischi di esecuzione, non semplicemente di output testuali indesiderabili.
L'autonomia eccessiva si verifica quando un agente riceve più autorità di quanto richieda la sua attività. Un assistente di pianificazione può aver bisogno di leggere calendari e proporre orari per riunioni. Raramente necessita di accesso illimitato per eliminare eventi, invitare partecipanti esterni o leggere ogni allegato privato.
La distinzione sembra semplice finché i workflow non diventano dinamici. Un agente può legittimamente necessitare di accesso ampliato per un'attività, ma non per un'altra. Un'autorizzazione ampia e permanente risolve il problema operativo creando però un'esposizione di sicurezza persistente.
I controlli in runtime offrono un approccio diverso. Il sistema può rilasciare un'autorizzazione ristretta e temporanea dopo aver valutato l'attività e il suo contesto. Tale autorizzazione può scadere dopo una sola azione o richiedere approvazione quando l'ambito richiesto cambia.
Lo stesso principio si applica ai dati. Un agente che prepara un riepilogo trimestrale può aver bisogno di informazioni aggregate sui ricavi, ma non del record personale di ogni cliente. Un controllo vicino alla fonte dei dati può limitare ciò che l'agente recupera prima ancora che il modello lo veda.
Questo è importante perché le salvaguardie a livello di modello sono soltanto uno strato. A un modello si può ordinare di non rivelare informazioni sensibili, ma le istruzioni possono entrare in conflitto o fallire. La minimizzazione dei dati e l'autorizzazione degli strumenti riducono le conseguenze quando il comportamento del modello diventa inaffidabile.
L'approccio in runtime separa inoltre il ragionamento a basso rischio dall'esecuzione ad alto rischio. Un agente può analizzare opzioni, redigere una raccomandazione e simulare un'azione senza ricevere il permesso di eseguirla. L'autorità arriva solo quando il workflow raggiunge un confine controllato.
L'approvazione umana resta importante, ma non può diventare una risposta universale. Richiedere approvazione per ogni chiamata a uno strumento elimina gran parte dell'efficienza promessa dagli agenti. Può anche generare affaticamento da approvazione, per cui le persone accettano richieste senza esaminarne il contesto.
Una buona governance riserva l'intervento a soglie significative. La lettura di una pagina pubblica di un prodotto può procedere automaticamente. L'esportazione di record clienti, la modifica di codice di produzione o l'invio di fondi dovrebbero attivare controlli più rigorosi.
Il confine esatto dipende dall'organizzazione e dall'attività. Tuttavia, il meccanismo resta coerente: valutare l'azione, il suo destinatario, il suo iniziatore e il suo potenziale impatto. Quindi applicare l'autorità più ristretta che consenta al lavoro legittimo di proseguire.
Il profilo sull'AI generativa del NIST sottolinea la gestione del rischio lungo tutto il ciclo di vita dell'AI. I sistemi agentici estendono tale ciclo di vita a una catena di decisioni che possono produrre effetti immediati.
La governance diventa quindi meno simile alla pubblicazione di un regolamento e più simile alla gestione di un sistema di autorizzazione. Le policy definiscono ancora ciò che dovrebbe accadere. I controlli in runtime traducono tali policy in decisioni tecniche che avvengono prima che le conseguenze diventino reali.
L'identità diventa il piano di controllo degli agenti AI
Un agente necessita di un'identità distinta e tracciabile perché le credenziali prese in prestito dai dipendenti eliminano la responsabilità e indeboliscono ogni controllo a valle.
Molti primi agenti operano attraverso l'account esistente di un utente umano. L'agente eredita una sessione, un token API o una credenziale di servizio. Questo design facilita i prototipi, ma crea ambiguità durante le indagini e le revisioni degli accessi.
Un log di sistema può mostrare che un dipendente ha scaricato un file. Potrebbe non rivelare se la persona abbia cliccato sul download, se lo abbia recuperato un agente approvato o se un workflow compromesso abbia agito attraverso il suo account. Nel record di autorizzazione manca l'attore effettivo.
Un'identità separata per l'agente risolve parte di questo problema. Consente agli amministratori di assegnare autorizzazioni all'agente, monitorarne il comportamento e revocarne l'accesso senza disabilitare lo sponsor umano. Permette inoltre alle policy di distinguere le azioni umane da quelle automatiche.
L'identità deve comunque essere collegata a una persona responsabile o a un processo aziendale. In caso contrario, le organizzazioni creano una popolazione crescente di account macchina senza un proprietario chiaro. Gli agenti inattivi possono quindi conservare accessi molto tempo dopo la conclusione del progetto originario.
Microsoft ha presentato i controlli Agent ID come livello di identità per individuare, governare e proteggere gli agenti. Questa direzione riflette una conclusione più ampia del settore: gli agenti necessitano di una gestione del ciclo di vita comparabile a quella delle altre identità non umane.
L'individuazione viene prima di tutto, perché i team di sicurezza non possono governare agenti che non riescono a vedere. Le unità aziendali possono creare agenti all'interno di piattaforme software, sistemi low-code, framework di sviluppo e servizi cloud. Ogni percorso può produrre un'altra identità, token o integrazione.
La registrazione dovrebbe acquisire il proprietario dell'agente, lo scopo, l'ambiente, gli strumenti approvati e l'accesso ai dati previsto. Dovrebbe inoltre registrare se l'agente può agire automaticamente o richiede una conferma. Questi attributi offrono ai sistemi in runtime una base per l'autorizzazione.
L'autenticazione risponde alla domanda se il chiamante sia l'agente registrato. L'autorizzazione risponde alla domanda se quell'agente possa compiere questa azione in queste condizioni. La governance fallisce quando i team risolvono la prima domanda ma concedono un accesso ampio e persistente per la seconda.
Il contesto rende l'autorizzazione più precisa. Una policy può esaminare l'utente che effettua la richiesta, lo stato del dispositivo, la classificazione dei dati, la destinazione, il valore della transazione e il recente comportamento dell'agente. Può quindi imporre controlli diversi senza ridefinire l'intero agente.
Un assistente può leggere le note delle riunioni di un dipendente durante il normale lavoro. La stessa richiesta dovrebbe ricevere un esame più attento quando riguarda file riservati di un altro reparto. Un improvviso download massivo dovrebbe essere trattato diversamente dal recupero di un singolo documento.
La memoria introduce un ulteriore problema di identità. Gli agenti possono archiviare la cronologia delle attività, le preferenze, i fatti recuperati e le decisioni intermedie. Tale memoria può persistere dopo la fine della sessione utente originale, influenzando al contempo azioni future per un'altra richiesta.
I team devono sapere quale identità possiede la memoria e chi può modificarla. Hanno inoltre bisogno della provenienza, ovvero di una registrazione della fonte delle informazioni archiviate e di come sono cambiate. Senza provenienza, una memoria compromessa può reindirizzare silenziosamente i flussi di lavoro successivi.
I sistemi di conoscenza possono supportare un recupero più sicuro quando preservano i confini tra le fonti e i controlli di accesso. Una base di conoscenza ingegneristica è più utile quando un agente riceve solo i documenti a cui il suo attuale richiedente può accedere.
I flussi di lavoro multi-agente rendono l'identità ancora più importante. Un agente può delegare la ricerca a un altro, poi chiedere a un terzo agente di aggiornare un sistema. Il servizio destinatario deve sapere se l'autorità delegata rimane valida lungo quella catena.
La delega non dovrebbe creare nuovi privilegi per errore. Se il primo agente non può approvare un pagamento, un agente delegato non dovrebbe acquisire tale capacità. Ogni trasferimento dovrebbe preservare i limiti, lo scopo e la scadenza originali.
Questo requisito richiama concetti consolidati della sicurezza delle identità, ma gli agenti aggiungono una velocità e una scala insolite. Una persona può eseguire diverse azioni sensibili durante una sessione. Un agente automatizzato può avviare molte azioni su diversi sistemi prima che un revisore se ne accorga.
Il piano di controllo deve quindi combinare l'identità con limiti di frequenza, monitoraggio comportamentale e policy sulle transazioni. L'identità indica all'organizzazione chi ha agito. La governance in fase di esecuzione determina se quell'attore debba poter continuare.
Il Controllo al Momento dell'Azione Crea i Suoi Compromessi
L'applicazione in fase di esecuzione riduce l'autorità non controllata, ma introduce anche latenza, complessità delle policy, rischi di integrazione e nuovi punti di controllo che gli aggressori possono prendere di mira.
La versione più forte dell'argomentazione sulla governance può sembrare ingannevolmente completa. Assegnare un'identità a ogni agente, valutare ogni azione, registrare ogni decisione e richiedere l'approvazione per le operazioni pericolose. Nella pratica, ogni componente può fallire.
La qualità delle policy è la prima limitazione. Un motore di esecuzione non può applicare intenzioni che i team non hanno tradotto in regole precise. Termini come sensibile, appropriato, rilevante o affidabile richiedono spesso un giudizio aziendale che varia tra i reparti.
Regole eccessivamente ampie lasciano disponibili azioni pericolose. Regole troppo rigide interrompono il lavoro legittimo e incoraggiano i dipendenti ad aggirare il sistema. L'organizzazione deve calibrare le policy usando flussi di lavoro reali, non solo categorie di rischio astratte.
Anche il contesto può essere incompleto. Un servizio di sicurezza può vedere una richiesta API senza comprendere la conversazione che l'ha generata. Un gateway per modelli può comprendere il prompt ma non avere informazioni sulla classificazione dei dati del sistema di destinazione.
Gli aggressori possono sfruttare queste lacune. Possono suddividere un obiettivo vietato in diverse azioni consentite. Ogni passaggio sembra innocuo se esaminato singolarmente, mentre la sequenza completa produce un risultato non autorizzato.
I controlli consapevoli della sequenza possono rilevare alcuni schemi, ma richiedono uno stato più ricco e una conservazione più lunga. Ciò crea problemi di privacy e operativi. Tracce dettagliate possono contenere richieste dei dipendenti, dati dei clienti, output dei modelli e decisioni aziendali riservate.
Le organizzazioni devono proteggere la telemetria di governance con la stessa cura riservata ai sistemi che monitora. Un registro compromesso può nascondere un attacco o implicare falsamente un utente. Una traccia esposta può rivelare proprio le informazioni che i controlli erano progettati per proteggere.
Le prestazioni presentano un ulteriore compromesso. Un agente può effettuare molte piccole chiamate a strumenti durante il completamento di un'attività. Inviare ogni chiamata attraverso diversi motori di policy può aggiungere ritardo, costi e ulteriori punti di guasto.
L'applicazione basata sul rischio può ridurre questo onere. Le azioni reversibili e a basso impatto ricevono controlli leggeri. Le azioni ad alto impatto o irreversibili ricevono un'autorizzazione più rigorosa, registrazioni più ricche o una revisione umana.
Questa distinzione richiede una classificazione accurata. Inviare una bozza a una coda di revisione interna è reversibile. Pubblicare lo stesso testo per i clienti non lo è. Leggere un singolo record cliente è diverso dall'esportare un intero database.
Gli agenti possono anche comportarsi diversamente dopo gli aggiornamenti dei modelli. Un nuovo modello può selezionare gli strumenti in un ordine diverso, generare argomenti differenti o tentare più passaggi. Le policy esistenti potrebbero bloccare il nuovo comportamento o non rilevare un percorso appena introdotto.
Questo rende i test continui parte della governance. I team dovrebbero riprodurre flussi di lavoro rappresentativi rispetto a modelli, strumenti e policy aggiornati. I test dovrebbero includere documenti ostili, istruzioni ambigue, autorizzazioni revocate e servizi non disponibili.
L'interoperabilità aggiunge un'altra incertezza. Il settore sta sviluppando protocolli che aiutano gli agenti a scoprire capacità e comunicare tra sistemi. Google ha introdotto il suo protocollo Agent2Agent per supportare la collaborazione tra agenti realizzati con framework diversi.
L'interoperabilità può ridurre il lavoro di integrazione, ma amplia anche le relazioni di fiducia. Un agente locale può fare affidamento sulla descrizione, fornita da un agente remoto, delle proprie capacità, identità o del lavoro completato. Tale dichiarazione richiede una verifica tecnica.
Un protocollo condiviso non crea automaticamente una governance condivisa. Le organizzazioni hanno ancora bisogno di regole per accettare attività delegate, trasmettere contesto sensibile e convalidare i risultati restituiti. Devono decidere quali agenti remoti rientrano in ciascun confine di fiducia.
La concentrazione dei fornitori presenta un rischio correlato. Se un'unica piattaforma di identità o policy media ogni azione degli agenti, un'interruzione può bloccare flussi di lavoro critici. Un errore di configurazione può bloccare un'intera organizzazione o concedere accesso eccessivo su larga scala.
I team hanno bisogno di comportamenti di fallback prima della distribuzione. Alcune azioni dovrebbero fallire in modo chiuso, ovvero il sistema le blocca quando un controllo non è disponibile. Altre operazioni a basso rischio possono continuare con limiti più stretti e una registrazione rafforzata.
La governance al momento dell'azione dovrebbe quindi essere considerata una difesa a più livelli, non una garanzia. Funziona meglio insieme a strumenti limitati, accesso minimo ai dati, esecuzione isolata, convalida degli output, monitoraggio e risposta agli incidenti.
La conclusione scettica è semplice. Avvicinare i controlli all'esecuzione migliora la capacità dell'organizzazione di prevenire danni. Non rende prevedibile il comportamento autonomo, né elimina la necessità di una revisione in fase di progettazione.
La Pressione Si Estende Oltre i Team di Sicurezza
La governance degli agenti AI costringe i fornitori di applicazioni e i responsabili aziendali a esporre controlli che i team di sicurezza non possono aggiungere dall'esterno del flusso di lavoro.
Un team di sicurezza può gestire identità e accesso alla rete, ma non può sempre comprendere il significato aziendale di un'applicazione. Una chiamata API che modifica un campo può approvare un rimborso, pubblicare un documento o chiudere un account cliente.
I fornitori di applicazioni devono etichettare le azioni consequenziali ed esporre punti di autorizzazione attorno a esse. Devono inoltre restituire contesto sufficiente affinché i sistemi di policy distinguano un'anteprima da un impegno effettivo. Senza questo dettaglio, l'applicazione rimane grossolana.
I fornitori di piattaforme per agenti affrontano un obbligo simile. Hanno bisogno di registrazioni durevoli dei passaggi di pianificazione, delle selezioni degli strumenti, degli argomenti, delle risposte e delle approvazioni. I team di sicurezza devono poter cercare in tali registrazioni senza esporre dati di chain-of-thought senza restrizioni.
I fornitori di modelli rimangono responsabili delle salvaguardie, delle valutazioni e di un comportamento prevedibile nell'uso degli strumenti. Tuttavia, non possono decidere la policy di autorizzazione di ogni cliente. La stessa azione del modello può essere innocua in un ambiente e vietata in un altro.
I responsabili aziendali devono definire tali distinzioni. I responsabili finanziari sanno quali transazioni richiedono la separazione dei compiti. I team delle risorse umane sanno quali record dei dipendenti richiedono un accesso più rigoroso. I team legali sanno quando una bozza generata diventa una comunicazione ufficiale.
Gli sviluppatori traducono poi questi requisiti in confini tecnici. Decidono quali strumenti l'agente può chiamare, quali parametri può fornire e quali risposte può ricevere. Determinano anche cosa accade quando un controllo rifiuta un passaggio.
Questa divisione delle responsabilità crea pressione perché nessun partecipante può risolvere il problema da solo. Le piattaforme di identità non dispongono del pieno significato dell'attività. I fornitori di applicazioni non hanno il contesto organizzativo completo. I fornitori di modelli non hanno autorità sulla policy del cliente.
L'integrazione più debole può compromettere l'intera catena. Un agente può avere un'identità forte ma chiamare uno strumento tramite un account di servizio condiviso. Uno strumento può applicare le autorizzazioni ma accettare istruzioni non convalidate da un documento esterno.
I team di procurement dovrebbero aspettarsi risposte più concrete dai fornitori di agenti. Una dichiarazione generica sull'AI responsabile non è sufficiente. Gli acquirenti devono sapere come il prodotto gestisce identità, delega, approvazioni, registri, memoria e revoca.
Dovrebbero anche chiedere se i controlli rimangono efficaci tra i connettori. Un agente può rispettare le restrizioni all'interno della sua piattaforma principale ma perderle quando chiama un servizio di terze parti. L'ereditarietà delle autorizzazioni deve sopravvivere a questa transizione.
La responsabilità operativa conta dopo l'acquisto. Qualcuno deve rivedere gli accessi, indagare sulle anomalie, rimuovere gli agenti inutilizzati e aggiornare le policy quando i flussi di lavoro cambiano. Un inventario degli agenti senza un processo operativo diventa un altro elenco di asset obsoleti.
Sviluppatori e knowledge worker dovrebbero preoccuparsene perché una governance più rigorosa plasmerà l'esperienza del prodotto. Alcuni agenti si fermeranno prima di azioni sensibili. Altri offriranno anteprime, modalità vincolate o richieste di autorizzazione esplicite.
Queste interruzioni non sono sempre difetti. Un passaggio di approvazione visibile può chiarire cosa un agente intende fare e quali dati utilizzerà. Offre all'utente l'opportunità di cogliere un obiettivo frainteso prima dell'esecuzione.
Controlli progettati male produrranno il risultato opposto. Richieste vaghe e ripetute abitueranno gli utenti ad approvare automaticamente le richieste. L'interfaccia deve spiegare in linguaggio semplice l'azione specifica, il destinatario, l'ambito e la conseguenza.
La pressione del mercato favorisce quindi prodotti che combinano un'autonomia utile con confini comprensibili. Il completamento puro delle attività rimarrà importante. La delega affidabile diventerà altrettanto importante man mano che gli agenti ottengono accesso a sistemi di valore.
Tre Segnali Mostreranno se la Governance in Fase di Esecuzione Funziona
Il prossimo test non è un altro annuncio di policy. È verificare se identità, autorizzazione ed evidenze rimangono intatte nei flussi di lavoro reali e articolati in più passaggi.
Il primo segnale è l'adozione di identità di agente separate sulle principali piattaforme aziendali. Le prove importanti includeranno controlli del ciclo di vita, proprietari nominativi, autorizzazioni ristrette, scadenza e revoca.
La sola denominazione di un prodotto non sarà sufficiente. I team di sicurezza devono distinguere un agente dal dipendente che lo sponsorizza e dagli account di servizio dietro i suoi strumenti. Un supporto più ampio rafforzerebbe la tesi della governance in fase di esecuzione.
Il secondo segnale è l'applicazione ai confini delle applicazioni. I fornitori di software aziendale dovrebbero esporre policy per azioni consequenziali, inclusi messaggi esterni, modifiche ai record, distribuzione del codice e operazioni finanziarie.
Osservate se questi controlli comprendono il contesto aziendale o si limitano a filtrare il testo. Un’autorizzazione consapevole del contesto dimostrerebbe che la governance è entrata nell’esecuzione. Avvisi generici e log opzionali indicherebbero invece che la transizione resta incompleta.
Il terzo segnale è costituito dalle evidenze di fallimenti e test indipendenti. I ricercatori dovrebbero verificare prompt injection, autorità delegata, memoria avvelenata, autorizzazioni eccessive e interazioni tra agenti remoti.
Report trasparenti sugli incidenti saranno importanti quanto le dimostrazioni riuscite. Possono rivelare se i controlli hanno bloccato azioni dannose, ne hanno limitato la portata o si sono limitati a documentare i danni in seguito. Bypass ripetuti indebolirebbero le affermazioni secondo cui l’applicazione delle policy nel punto d’azione è matura.
Nei prossimi mesi, gli acquirenti dovrebbero chiedere ai fornitori di dimostrare una catena completa. Si parta da un utente identificato, si deleghi un’attività con limiti definiti, si recuperino dati protetti, si richiami uno strumento, si richieda un’approvazione e si revochi l’accesso.
Esaminate quindi le evidenze. Il fornitore può mostrare chi ha avviato l’attività, quale agente ha agito, a cosa ha avuto accesso, quale policy è stata applicata e se la delega ha modificato l’autorità?
La governance degli agenti AI in ambito enterprise avrà successo solo se queste risposte reggeranno alle implementazioni reali. Se la vostra organizzazione sta sperimentando gli agenti, individuate la prima azione irreversibile in ogni flusso di lavoro. Applicate lì il controllo più rigoroso, testate il percorso di rifiuto e confermate che ogni decisione resti attribuibile.
