Il dibattito sugli AI Agent nelle organizzazioni si è concentrato quasi esclusivamente sulla maturità dei modelli, sulla scelta delle piattaforme e sull’affidabilità delle infrastrutture. Sono domande legittime, ma rischiano di spostare l’attenzione da un altro aspetto critico, più sottovalutato: la mancanza di governance adeguata a sistemi che non si limitano a rispondere a domande, ma prendono decisioni e agiscono in autonomia su processi reali.
Un agente AI può oggi inviare comunicazioni, modificare configurazioni, attivare flussi di approvazione, interagire con sistemi ERP o CRM. Quando un’azione va nel verso sbagliato, le conseguenze non si esauriscono in un testo da correggere: si propagano su sistemi e processi, e nel caso della pubblica amministrazione sugli obblighi degli enti e i diritti dei cittadini. La maggior parte delle organizzazioni che stanno adottando agenti AI non ha ancora definito chi è responsabile di quello che l’agente fa.
Indice degli argomenti
Il primo passo verso una governance concreta di queste tecnologie è la definizione esplicita dei livelli di autonomia. Non tutti gli agenti sono uguali, dal momento che alcuni inviano semplicemente un primo messaggio all’utente o gli propongono azioni che quest’ultimo deve vagliare, mentre altri eseguono in modo autonomo più azioni all’interno di flussi complessi, come il processo di risposta autonoma a un attacco informatico all’interno di un istituto finanziario o in un’infrastruttura critica.
La distinzione non è tecnica, è organizzativa e dipende dal tipo di impatto che le azioni producono. In questa direzione è importante separare le azioni reversibili da quelle irreversibili e quelle ad alto impatto. Un agente che categorizza documenti o suggerisce priorità in una coda di lavoro può operare con autonomia elevata visto che l’errore è correggibile. Diversamente un agente che autorizza pagamenti di sussidi o modifica permessi nella catena di fornitura di una grande impresa manifatturiera richiede un diverso livello di autonomia.
Va da sé che il perimetro delle azioni consentite va definito prima del deployment, non una volta che si sono scoperte le falle, quindi a posteriori. Nelle pubbliche amministrazioni, dove molte azioni producono effetti su posizioni giuridiche di soggetti terzi, questa precisione è una condizione per la legittimità stessa del sistema.
Un altro driver centrale della governance degli agenti AI è ovviamente la supervisione umana attraverso due approcci, spesso confusi. Il primo è l’“human-in-the-loop”: l’agente non può procedere senza una validazione umana esplicita su determinati passaggi. Si tratta quindi di un presidio forte da prevedere in primis per azioni ad alto rischio, ma introduce latenza e non è scalabile se applicato indiscriminatamente. Il secondo è l’“human-on-the-loop”, framework operativo in cui l’agente agisce in autonomia, ma un supervisore umano monitora in tempo reale o a campione le sue azioni intervenendo per fermare o correggere un’azione non corretta.
La scelta di approccio dipende dal contesto e dal profilo di rischio ritenuto accettabile. Dove l’errore non è correggibile o le conseguenze di un eventuale errore sono importanti oppure la responsabilità legale non può essere delegata, il modello human-in-the-loop è l’opzione adeguata. In processi operativi a bassa criticità e ad alto volume, il modello human-on-the-loop assicura efficienza senza rinunciare al controllo.
Ma c’è un altro equivoco da evitare: pensare che la supervisione si risolva in un cruscotto di monitoraggio, perché avere visibilità sulle azioni degli agenti AI non equivale a poter intervenire nei tempi utili. La supervisione va quindi progettata con ruoli, frequenze e autorità di intervento anch’essi da definire prima dell’entrata in produzione.
La conformità normativa degli agenti AI è ancora trattata da molte organizzazioni come una questione futura. Il regolamento europeo sull’intelligenza artificiale è invece già in vigore. I sistemi agentici impiegati in processi che riguardano occupazione, istruzione, servizi pubblici essenziali, accesso al credito o sicurezza rientrano nelle categorie ad alto rischio e sono soggetti a obblighi specifici.
Tra questi obblighi, due sono direttamente correlati alla questione della governance: la tracciabilità e la spiegabilità, in altre parole, il sistema agentico deve essere in grado di documentare le proprie azioni e le basi su cui ha preso le sue decisioni. Questo non significa che l’agente debba produrre una motivazione esplicita per ogni singola azione, ma che il sistema nel suo complesso, incluso il layer di orchestrazione e i log generati, deve consentire una ricostruzione verificabile di ciò che è avvenuto. Per i sistemi ad alto rischio è richiesta anche la registrazione automatica degli eventi rilevanti per tutta la durata del ciclo di vita del sistema.
Nella pratica, ciò si traduce in alcune scelte progettuali precise, per cominciare il logging delle azioni non deve essere un’aggiunta posticcia, va integrato nell’architettura dell’agente fin dall’inizio. I log devono essere strutturati, leggibili da sistemi di audit e conservati per il tempo richiesto dalla normativa applicabile. Devono coprire non solo le azioni eseguite, ma anche i prompt ricevuti, i tool chiamati, le fonti consultate e gli eventuali errori o comportamenti anomali. Questo livello di granularità è necessario non solo per la compliance, ma per poter condurre analisi post-incidente quando qualcosa va storto. Inoltre, nelle catene agentiche multi-step, la tracciabilità deve attraversare tutti i nodi del sistema; la conformità garantita solo al livello superficiale non regge a un audit.
Quando un agente produce un danno o un risultato inatteso, la domanda “chi ne risponde?” non può ricevere come risposta “l’algoritmo”. La responsabilità è sempre umana e va assegnata prima che il sistema sia in produzione definendo chi autorizza il deployment, chi approva le modifiche al perimetro di azione e chi è il referente in caso di anomalia. Tuttora in molte organizzazioni queste responsabilità non sono assegnate, dando vita, in caso di anomalie, meramente a una catena di rimpalli tra i diversi soggetti.
In questa prospettiva, le procedure di escalation vanno incorporate nel design in modo che l’agente sappia quando fermarsi, quando chiedere conferma, quando segnalare qualcosa al supervisore. Nelle pubbliche amministrazioni o in settori come quello assicurativo, il tema è ancora più stringente, dal momento che i processi amministrativi producono atti con valore giuridico. Le procedure devono includere criteri per la sospensione temporanea in caso di comportamenti anomali reiterati, e definire come un incidente viene classificato, documentato e comunicato alle parti interessate.
La centralità della governance degli agenti AI è quindi evidente, eppure la tendenza nelle imprese e negli enti è ancora quella di trattarla al più come un passaggio successivo, da definire dopo che il sistema è in funzione.
È una visione che sottovaluta la natura di questi sistemi, perché un agente che agisce su processi reali produce effetti reali e lo fa dal primo momento in cui è attivo. Senza sottovalutare che l’implementazione di una governance retroattiva è più costosa e meno efficace di quella progettata in anticipo.
La definizione dei livelli di autonomia, i meccanismi di supervisione, la tracciabilità delle azioni e l’assegnazione delle responsabilità non sono elementi accessori, devono essere parte integrante del progetto, consapevoli che un agente AI privo di governance è un sistema che accumula rischio non visibile. La governance di queste tecnologie va approcciata e trattata con la stessa serietà con cui si sceglie la piattaforma e si costruiscono i modelli, e non solo perché lo richiedono delle norme.