Nella vostra organizzazione, qualcuno sa esattamente quanti agenti AI sono attivi oggi e con quali permessi operano?
Non stiamo parlando di quanti strumenti AI avete acquistato o installato ma di quanti sistemi stanno in questo momento agendo in autonomia su processi reali (quindi leggendo, scrivendo, inviando, modificando) mentre il team lavora ad altro.
Per la maggior parte delle aziende, la risposta non è immediata.
Nel numero di marzo di questa rubrica abbiamo esplorato cosa significa governare l'AI in senso progettuale: chi approva un sistema, su quali dati opera e a chi risponde quando produce un output sbagliato. Quel ragionamento partiva dall'AI come strumento che produce risultati.
Questo numero parte da un passo successivo: l'AI che non aspetta istruzioni ma le esegue da sola. La differenza è, anche in questo caso, una questione di governance e, nella maggior parte delle organizzazioni, in molte aziende non è ancora stata affrontata come tale.
Buona lettura!
Quando si parla di AI in azienda, l'immagine mentale più diffusa è ancora quella di uno strumento che risponde: fai una domanda, ottieni un output, decidi cosa farne. Un modello generativo in effetti funziona così: scrive un testo, crea una sintesi, produce analisi; ogni volta c'è una persona che guarda il risultato e sceglie se e come usarlo.
Un agente autonomo funziona in modo strutturalmente diverso. Non risponde più ad una domanda(o meglio, prompt) ma esegue. Qualche esempio:
Legge la posta in arrivo e classifica le priorità.
Accede a un repository documentale e genera bozze.
Monitora un sistema e propone - o compie - azioni correttive.
Invia comunicazioni e aggiorna record
Avvia dei flussi spesso in sequenza e mentre nessun essere umano supervisiona ogni singolo passaggio.
È utile però essere più precisi, perché non tutti i sistemi AI che "fanno cose" sono uguali.
Esistono almeno tre forme distinte, con profili di rischio diversi: i copiloti, gli agenti autonomi e le automazione AI.
Capire in quale categoria rientra ciascun sistema attivo in azienda non è un esercizio classificatorio fine a sé stesso. Ci serve per determinare il livello di supervisione e quali permessi sono necessari.
Da quello che vediamo nelle aziende, questa distinzione non è ancora recepita nelle policy interne della maggior parte delle organizzazioni. Gli agenti vengono adottati con le stesse logiche dei copiloti: installati, configurati, attivati. Ma il profilo di rischio è radicalmente diverso, perché la catena di effetti che un agente può innescare non si ferma a un output su schermo.
Quando si configura un agente AI, la domanda pratica che si pone quasi sempre è: di cosa ha bisogno per funzionare?
E la risposta più comoda è: accesso a tutto quello che potrebbe servirgli ossia: calendario, email, repository documentali, sistemi gestionali. Un accesso ampio garantisce che l'agente non si blocchi a metà di un task. È la soluzione più semplice e, quasi sempre, quella adottata.
Il principio del minimo privilegio - uno dei fondamenti della cybersecurity da almeno trent'anni - però, stabilisce il contrario:
ogni componente di un sistema dovrebbe operare con il livello minimo di accesso necessario per svolgere la sua funzione specifica.
Non "tutto quello che potrebbe servirgli" ma "esattamente quello che gli serve per questo compito, in questo contesto e in questo momento". Nei sistemi tradizionali questo principio viene applicato sistematicamente. Agli agenti AI, nella maggior parte delle organizzazioni, non ancora.
Come possiamo spostare il principio del minimo privilegio agli agenti? Per farlo dobbiamo articolare i permessi lungo sei dimensioni operative.
|
Accessi per ruolo: |
Accessi per livello di dato: |
Accessi per azione: |
|
Log delle attività: |
Controlli su sistemi collegati: |
Revoche e revisioni: |
Il problema principale da tenere a mente quando si lavora con gli agenti, è la perdita di tracciabilità: quando un agente opera con permessi estesi e senza log strutturati, non è più possibile rispondere con certezza alle domande elementari della governance. Chi ha fatto cosa? In base a quale istruzione? In quale momento? Se qualcosa va storto - un documento modificato in modo errato, un'email inviata a destinatari sbagliati o un record aggiornato con dati inconsistenti - la catena di causalità diventa opaca.
Questo è esattamente lo scenario che il numero di marzo di questa rubrica descriveva per i sistemi AI in generale: la metafora del consulente esterno molto competente che lavora senza mandato scritto. Con gli agenti il problema si amplifica, perché il consulente non si limita a produrre un report che qualcuno leggerà e valuterà, agisce direttamente nei processi, spesso in modo automatico e continuativo.
La governance degli agenti AI, quindi, non è qualcosa che si aggiunge dopo che l'agente è in produzione ma è qualcosa che si costruisce prima, come parte integrante del processo di adozione.
Dire "definiremo le regole quando vedremo come funziona" è esattamente il tipo di postura che, per i sistemi AI in generale, ha già prodotto le situazioni che il numero di marzo descriveva: sistemi attivi senza approvazione formale, output che influenzano decisioni senza che nessuno ne risponda.
Per gli agenti, questa postura è ancora più rischiosa perché gli effetti sono diretti e spesso irreversibili.
Vi proponiamo qui di seguito una struttura di accountability che ogni organizzazione dovrebbe essere in grado di mantenere nel tempo, aggiornando le risposte ogni volta che un agente viene modificato, ampliato o connesso a nuovi sistemi.
Le quattro domande chiave da cui partire sono le seguenti.
1.Cosa può fare? La risposta non deve essere generica. Deve specificare esattamente quali azioni l'agente è autorizzato a compiere, su quali sistemi, in quali condizioni e con quali limiti. Se la risposta è "dipende dal task", il perimetro non è stato definito.
2.Chi lo ha autorizzato? Non chi lo ha installato o configurato dal punto di vista tecnico, ma chi ha assunto la responsabilità formale della sua attivazione, con una valutazione documentata del rischio associato.
3. Come viene monitorato? Il monitoraggio non è opzionale. Significa log strutturati, alert su comportamenti anomali, revisioni periodiche delle azioni compiute. Un agente che non viene monitorato è un agente che non si governa.
4.Chi risponde se produce un errore? Questa è spesso la domanda più difficile, perché richiede una conversazione che attraversa IT, legal e linee di business. Ma è anche la domanda più importante: senza una risposta chiara, qualsiasi struttura di governance è formale nella sostanza e vuota nella pratica.
A queste quattro domande si affianca uno strumento operativo che molte organizzazioni non hanno ancora prodotto: una policy AI che sia effettivamente utilizzabile dalle persone che lavorano con questi sistemi ogni giorno. Non un documento di principi generali, ma un vademecum che chiarisca in modo specifico quali strumenti AI sono autorizzati, quali dati possono essere caricati nei prompt, quali casi d'uso sono ammessi, quali output richiedono una verifica umana prima dell'uso, quando serve escalation verso IT, compliance o il responsabile di funzione e come documentare decisioni e controlli. Una policy che nessuno sa applicare è solo burocrazia. Una policy che entra nel comportamento quotidiano delle persone è parte dell'architettura di governance.
Costruire questa struttura prima di un incidente non è burocrazia. È la condizione per poter dimostrare a un auditor, a un assicuratore o a un cliente che i sistemi AI in uso sono effettivamente governati - non solo installati.
Nei prossimi numeri torneremo ancora sul tema AI con un angolo diverso: non più cosa fanno gli agenti, ma se l'organizzazione ha internamente le competenze per valutarli, presidiarli e riconoscere quando qualcosa non funziona come dichiarato dai vendor. Perché la governance degli agenti - come quella di qualsiasi sistema AI - dipende anche dalla capacità di non delegare interamente al fornitore la capacità di giudicare.