Negli ultimi mesi il concetto di “Agente AI” è entrato nel dibattito comune, non solo tra gli specialisti, ma anche tra quelli che si occupano a vario titolo di tecnologia. Su questo termine molto si è discusso e fantasticato, ma un messaggio sembra essere passato in maniera trasversale: “Un agente AI è un’applicazione di intelligenza artificiale che fa il lavoro al posto nostro”.
Molte discussioni sono in corso su come utilizzarli, mentre diverse applicazioni sperimentali vengono via via realizzate, alcune con risultati apprezzabili. Tuttavia, molte di queste applicazioni si limitano ad usare il termine di “Agente AI” per indicare dei chatbot inseriti sui siti aziendali senza specifica autonomia, o delle applicazioni di gestione documentale, con workflow assistiti da LLM. Sono state in qualche caso sviluppate applicazioni più complesse, ma siamo ancora lontani da una vera diffusione di questi Agenti AI, utilizzati in architetture orchestrate, con compiti complessi e ad autonomia controllata.
Il motivo di questa “prudenza”, a mio avviso più che giustificata, va ricercato in alcuni problemi ancora non pienamente risolti, uno dei quali è una esperienza non ancora sufficiente nella progettazione di architetture agentiche, mentre le sperimentazioni realizzate finora sono state spesso sviluppate con il supporto dei vendor, che propongono dei framework generalisti e forniscono supporto. Da questa carenza di esperienza deriva la prudenza a cui si accennava, nello sviluppo e nella gestione di Agenti AI dotati di un’autonomia più elevata.
E’ una impostazione che valuta attentamente sia le potenzialità, che i rischi che occorre gestire. Una prudenza consapevole. Inoltre, c’è da tener presente anche una preoccupazione di tipo sociale che accompagna la diffusione di queste applicazioni, e cioè che l’AI “ci porterà via il lavoro”, proprio perché “fa il lavoro al posto nostro”.
Indice degli argomenti
Le preoccupazioni legate all’Intelligenza Artificiale
In questo articolo ci occuperemo di un modello di progettazione che possa aiutarci a costruire delle architetture di riferimento per rispettare i principi di “AI Umano-Centrica”, posti alla base dell’AI Act dell’Unione Europea [1]. Principi espressi, in modo molto chiaro anche dal Papa, nella sua recente enciclica “Magnifica Humanitas” [2].
Un modello che realizza il paradigma “Human-in-the-Loop”, nelle applicazioni che includano modelli di AI per la gestione di processi e la formulazione di decisioni, in particolare nei sistemi ad alto rischio che possono impattare sulla vita delle persone o sulla gestione di infrastrutture critiche.
Ma prima di procedere in questa direzione, vorrei ancora soffermarmi su quella preoccupazione, molto diffusa nella società, che l’AI possa rimpiazzare il lavoro delle persone nella maggior parte delle attività, con risultati a volte superiori a quelli umani.
L’argomento classico che viene spesso utilizzato è che ogni evoluzione tecnologica, avvenuta in passato, abbia portato a degli sviluppi positivi nel mercato del lavoro, con molti mestieri che venivano rimpiazzati dalle macchine e molti che invece venivano creati. Questa argomentazione non sembra oggi sufficiente a superare la preoccupazione esistente. Perché c’è una convinzione, molto diffusa, che chi perderà il lavoro non avrà le competenze necessarie per svolgere i nuovi compiti, per occupare le nuove posizioni che saranno necessarie nel nuovo mercato delle professioni [3].
Questo potrà provocare da un lato un eccesso di forza lavoro, in quei settori che verranno completamente rivoluzionati dall’uso dell’AI, e dall’altro una carenza di competenze, con una domanda in gran parte non soddisfatta inerente alle nuove professioni.
Figura 1 – La trasformazione del lavoro
Per affrontare questo passaggio epocale, che determinerebbe un disallineamento tra domanda e offerta di lavoro, con conseguenze negative sulla vita delle persone coinvolte, occorrerà agire su diversi fronti. Uno dei più importanti potrebbe essere un intervento dello Stato per favorire una riconversione graduale, in molti casi complessa da gestire.
Perché non si tratta di far evolvere direttamente le professionalità di quei lavoratori che svolgono compiti ripetitivi, quindi esposti maggiormente al rischio della perdita del proprio posto di lavoro, verso le nuove professioni richieste, come ingegneri di sistema, progettisti di architetture agentiche, o analisti di processi complessi gestiti da AI. Questa trasformazione non sarà possibile direttamente, in molti di questi casi. Occorrerà gestire un’evoluzione graduale verso le nuove professioni, con formazione e laboratori di sperimentazione, con investimenti specifici e con programmi finalizzati. E non potrà essere, in ogni caso, un processo gestito prevalentemente dall’alto. Anche se lo Stato dovrà fare la sua parte, a partire dalla Pubblica Amministrazione, sarà un processo che ogni organizzazione e ogni azienda dovrà gestire direttamente al suo interno.
Ci sono attualmente delle tensioni notevoli che attraversano il mercato del lavoro, in tutto il mondo, con l’introduzione non pienamente condivisa dell’AI nei processi aziendali. Un caso emblematico è quello della Hyundai in Corea, dove scioperi ripetuti dei lavoratori, che contestavano, tra le altre cose, anche la pianificata introduzione di Robot umanoidi nelle linee produttive, hanno portato ad un accordo preliminare con i lavoratori. L’accordo complessivo ha riguardato le diverse istanze sollevate dai lavoratori, tra cui anche l’assunzione di nuovo personale tecnico e la condivisione dei progetti di introduzione dell’AI nelle fabbriche [4].
Il caso Hyundai non è isolato, e costituisce un esempio di come un approccio non condiviso all’utilizzo di AI nel mondo del lavoro debba trovare necessariamente una compartecipazione dei lavoratori e delle loro organizzazioni, proprio per coinvolgere l’intera organizzazione nelle innovazioni che si vanno introducendo.
Sarà un processo che richiederà del tempo, ma l’essere consapevoli di questo grande cambiamento in atto contribuirà alla gestione della transizione, dando anche una prospettiva di più lungo periodo a chi si sente oggi in difficoltà, e vede il proprio posto di lavoro a rischio.
Particolare attenzione va poi rivolta ai giovani professionisti che lasciano le università, perché faranno più fatica ad inserirsi nei ruoli di ingresso, oggi più facilmente sostituiti dall’AI [5]. Per i giovani occorreranno delle agevolazioni specifiche e dei programmi di inserimento efficaci.
La preoccupazione dell’AI che “ci porta via il lavoro” dovrà quindi necessariamente trovare delle risposte, che affrontino i problemi delle persone e che diano un impulso effettivo sia all’evoluzione professionale che allo sviluppo più ampio di questi sistemi.
La gestione del rischio e la governance
Un altro aspetto, che in qualche modo frena lo sviluppo delle applicazioni agentiche, è quello dell’estrema prudenza adottata nella loro realizzazione, laddove dettata soprattutto dalla carenza di competenze, come abbiamo detto, ma anche dalla consapevolezza dei rischi da gestire.
E’ evidente che la gestione dei rischi è parte integrante della gestione di ogni sistema complesso, in Cybersecurity come nelle infrastrutture critiche, come in economia o nelle catene di produzione industriali, ma la diffusione frequente di informazioni allarmistiche, su “Agenti AI fuori controllo”, rischia di alimentare una percezione di incertezza. Una percezione che, se non viene accompagnata dalla conoscenza di modelli adeguati di progettazione, per la gestione del rischio insieme al livello di autonomia degli Agenti, può ostacolare lo sviluppo dei progetti che li utilizzano.
La nostra posizione è stata espressa in un precedente articolo, in cui il livello di rischio è messo in correlazione con il livello di autonomia che si affida agli Agenti, limitando quest’ultimo (a livello 2 o 3, nella scala da 0 a 5 che vedremo) e tenendo costantemente sotto il controllo umano sia i risultati parziali che le decisioni finali [A3].
Sulla base di questo modello aggiornato di gestione del rischio è possibile progettare architetture anche molto complesse, in ambienti Multi-Agente governati, con delle componenti di controllo, ma anche di audit, che accompagnino il controllo umano e supportino la gestione dei processi e dei flussi di elaborazione.
Questo approccio non solo deve tendere a gestire il livello di autonomia e a bilanciarne i rischi, ma deve anche fornire degli strumenti che possano aumentare la fiducia delle organizzazioni e favorire l’intero processo evolutivo delle applicazioni agentiche.
Lo scopo di questo articolo è quello di fornire un quadro di riferimento complessivo sull’uso di queste architetture, di analizzare le principali scelte progettuali da compiere, ma anche di mostrare le potenzialità che è possibile sfruttare, limitando i rischi e mantenendo il controllo completo delle attività.
La diffusione di queste architetture non dipenderà solo dagli sviluppi tecnologici, ma anche dal modo in cui le organizzazioni e le persone coinvolte affronteranno il tema della Governance e del Controllo. E’ una questione non solo di tipo progettuale, ma anche culturale e organizzativa, che riguarda la fiducia delle persone e delle organizzazioni nei confronti dell’utilizzo concreto dell’Intelligenza Artificiale. Costruire dei Framework di riferimento, che pongano il tema della governance e della trasparenza come base progettuale, diventa un passaggio fondamentale per superare diffidenze e favorire lo sviluppo di questi sistemi.
I principi di base
I presupposti concettuali alla base di ogni applicazione che utilizzi dei modelli di AI generativa sono quelli dell’approccio “Risk Based”, del principio del controllo umano (“Human-in-the-Loop”) e del rispetto della dignità e dei diritti delle persone. Questi presupposti sono chiaramente espressi da molte normative internazionali, in particolare dall’AI Act dell’Unione Europea.
Nel modello che discuteremo ogni decisione finale che impatti sulle persone, in relazione a decisioni, attività o azioni specifiche in cui siano coinvolti modelli di AI, deve essere presa dagli operatori umani, che restano i responsabili delle decisioni che vengono assunte. Le procedure eseguite e le decisioni che vengono prese devono poter essere documentate con trasparenza, in modo da favorire le verifiche successive e la reversibilità, o il recupero, in caso di problemi.
Il primo elemento che poniamo alla base della progettazione di una architettura agentica è quello di limitare l’autonomia degli Agenti AI, controllandone il rischio attraverso una serie di controlli (Checkpoint) distribuiti lungo l’intera pipeline elaborativa, e con una Dashboard di verifica, che consenta il controllo umano e la concessione delle relative autorizzazioni.
Per la definizione del livello di autonomia degli Agenti AI il modello di riferimento più utilizzato, sia nei Framework proposti dalle aziende produttrici, sia nelle linee guida redatte da enti pubblici come AGID, prevede una classificazione secondo una scala da zero a cinque, dal livello zero, che corrisponde a nessuna autonomia, fino al livello cinque, che corrisponde ad autonomia completa [6].
E’ uno schema che ricalca anche la classificazione della “Society of Automotive Engineers (SAE)”, nello standard SAE J3016, per i veicoli a guida autonoma [7].
Nei modelli di sviluppo proposti il livello di autonomia cinque dovrebbe rimanere nel campo della ricerca, mentre per il livello quattro è consigliato l’utilizzo solo in ambienti controllati, per condurre delle sperimentazioni. E’ una prescrizione sicuramente condivisibile e da adottare.
In molte città degli USA e della Cina ci sono servizi già operativi di veicoli a guida autonoma, con livelli diversificati di autonomia secondo questa classificazione, in cui si arriva fino al livello 4. E ci sono anche applicazioni molto più semplici, come i sistemi software di segnalazione e controllo presenti nelle moderne vetture, che prevedono un livello di autonomia molto limitato secondo questa classificazione, che non coinvolgono Agenti AI.
La limitazione del livello di autonomia degli Agenti AI deve essere commisurata al tipo di applicazione e al contesto in cui è utilizzata. Ci sono casi in cui, per salvaguardare la vita delle persone, o intervenire per evitare maggiori danni, un livello di autonomia elevato risulta indispensabile. Sono quelle situazioni in cui i tempi di intervento umano risultano inadeguati a fronteggiare situazioni di emergenza.
Per applicazioni semplici, con pochi Agenti AI, questo modello di limitazione dell’autonomia è abbastanza efficace, ma laddove il numero di Agenti cresce, la complessità aumenta di conseguenza, ed è quindi necessaria una supervisione più articolata.
E’ necessario inserire nell’architettura delle componenti di supervisione e controllo che siano di supporto ai controllori umani. E’ una funzione che può essere svolta da moduli software specializzati, o anche da Agenti AI Antagonisti, con compiti di verifica del lavoro svolto dagli agenti operativi.
L’intero processo, o gruppi di processi, viene gestito da un Modulo Orchestratore che coordina le attività degli altri agenti attivandoli mediante i prompt progettati, gestisce i log e consente la reversibilità, nei casi che vedremo, per effettuare eventuali roll-back. L’Orchestratore determina inoltre la raccolta della documentazione di supporto agli audit e alle verifiche successive.
Architetture multi-agente esistenti e proposta di ampliamento
La progettazione delle architetture Multi-Agente presenta caratteristiche comuni nei diversi modelli, proposti dai principali operatori di mercato e dalle stesse aziende produttrici delle piattaforme generative.
Il modello in cui è presente un Modulo Orchestratore, che coordina le attività degli Agenti AI specializzati, è molto diffuso e costituisce di fatto un riferimento per la gran parte dei framework di mercato.
In alcuni casi sono previsti nell’architettura anche dei moduli di verifica, in un workflow di tipo orizzontale, in cui la sequenza delle operazioni gestita dall’Orchestratore si conclude con la presentazione dei risultati, le verifiche da parte degli operatori umani e l’approvazione finale.
Tra le architetture più documentate e diffuse in ambito aziendale troviamo quella proposta da Microsoft, che contiene le componenti essenziali dell’architettura: il Modulo Orchestratore, la pianificazione, la memoria, il coordinamento degli Agenti AI specialisti, il collegamento ai tool esterni e una revisione finale del lavoro svolto dagli Agenti AI [8].
Altri framework proposti dal mercato, come LangGraph, CrewAI e altri, propongono strutture analoghe, anche se più semplici. Sono tutti framework orientati al coordinamento degli Agenti AI specializzati, con una gestione del workflow operativo e una struttura orizzontale di processi elaborativi e di controlli.
La proposta architetturale definita in questo articolo prevede una struttura che si discosta, in alcuni tratti, dalla struttura prevalentemente sequenziale del workflow. Rimane invariata la struttura funzionale, che prevede il Modulo Orchestratore e il coordinamento degli Agenti AI specializzati, ma al coordinamento operativo viene affiancata una struttura gerarchica di governo, con componenti anche parallele che si occupano del controllo delle autorizzazioni, della verifica dei risultati intermedi e finali, e dell’Audit complessivo dell’intero processo. Processo che si conclude con la presentazione dei risultati agli operatori umani, a cui competono le decisioni finali e le relative responsabilità.
E’ una impostazione simile a quella del controllo dei sistemi complessi, con moduli che ricoprono mansioni specializzate e con controlli diversificati per ruolo.
Una struttura funzionale, in cui i controlli sono progettati in modo organico e trasparente, con una gestione del rischio più equilibrata e maggiormente sicura.
Rendere più strutturata la Governance dell’architettura, separando le funzioni operative da quelle di controllo e verifica, non ha lo scopo di moltiplicare ulteriormente il numero degli agenti, ma quello di separare le funzioni di coordinamento da quelle di governo del sistema. Questa impostazione guiderebbe l’utilizzo di queste architetture verso scenari più strutturati e più facilmente gestibili, aumentando, a nostro parere, anche la fiducia verso queste soluzioni.
Questa proposta di architettura, tuttavia, non intende sostituire i framework oggi disponibili sul mercato, ma prevede un’evoluzione con elementi aggiuntivi di governance, costituiti da moduli complementari che si integrano in modo non invasivo, contribuendo a una maggiore controllabilità e alla trasparenza dell’intero sistema.
Figura 2 – Architettura multi-agente orchestrata
Il progetto del modulo orchestratore
In un ambiente complesso, in cui occorre coordinare le attività di più Agenti AI, specializzati in compiti specifici, è necessario un “Orchestratore” che attivi gli Agenti AI distribuendo i task, formulando i prompt per gli LLM con le indicazioni su come svolgere le attività, e chiedendo l’approvazione dei risultati ai controllori umani, prima di procedere oltre [9].
Questo Orchestratore deve guidare la sequenza delle attivazioni dei diversi Agenti AI, deve mantenere una memoria dei risultati parziali raggiunti, deve registrare i log per assicurare la tracciabilità delle operazioni, anche ai fini degli Audit, e deve anche gestire il colloquio con l’operatore umano, tramite una interfaccia, presentando i risultati e richiedendo le autorizzazioni a procedere, quando richiesto.
Uno degli elementi caratterizzanti delle architetture agentiche è la modalità con cui il Modulo Orchestratore viene realizzato. Comunemente lo si sta definendo come un “Agente AI”, che coordina altri Agenti AI. Questa è una scelta che comporta l’assunzione di fattori aggiuntivi di rischio, in termini di possibili indeterminatezze nelle interazioni tra gli agenti, o anche la possibilità di errori o “allucinazioni”, sempre possibili in questi modelli non deterministici.
Il Modulo Orchestratore, oltre ad organizzare le attività, è anche il responsabile dell’applicazione delle Policy Aziendali, definite a livello di governance progettuale, della gestione del flusso delle operazioni e delle autorizzazioni.
Il Modulo Orchestratore è quindi uno degli elementi più importanti dell’architettura agentica e per questo motivo occorre limitare al massimo la sua possibile indeterminatezza e la possibilità di errori di valutazione nei risultati.
Per tali motivi è nostra convinzione che sarebbe opportuno realizzare il Modulo Orchestratore con un modulo deterministico, sviluppato con moduli software ordinari, in modo da controllarne strettamente le operazioni.
Questa modalità di progettazione non è oggi comunemente utilizzata poiché il modello concettuale prevalente prevede l’utilizzo di un Agente AI che faccia da Orchestratore, anche se molte ricerche recenti vanno in questa direzione.
Un approccio graduale sarebbe quindi quello di utilizzare, in prima istanza, un Modulo Orchestratore deterministico, e solo in seguito, con il consolidamento dell’architettura, la verifica delle performance e dei risultati, e anche con il progressivo bilanciamento dei parametri di rischio, si potrebbe procedere ad utilizzare un Agente AI, con autonomia limitata, come Orchestratore di altri agenti.
E’ una scelta che incide direttamente sulla gestione dell’autonomia degli agenti e sul livello di rischio che ne consegue.
La gestione dei modelli LLM e delle banche dati esterne
Il Modulo Orchestratore gestisce anche il colloquio con i modelli generativi LLM, attivati sulla base di prompt, la cui struttura dovrebbe essere precostituita, in cui le indicazioni da passare al modello LLM dovrebbero cioè essere definite preventivamente, a livello progettuale. Questa modalità operativa caratterizza l’impostazione di questa proposta architetturale, in cui non è consentito un colloquio diretto tra l’operatore umano e il modello LLM, per motivi di sicurezza e di tracciabilità.
Ogni modello LLM che viene attivato deve ricevere precise istruzioni, tramite il prompt preparato dall’Orchestratore in base agli obiettivi da raggiungere, dichiarando il ruolo, i presupposti, le richieste specifiche di inferenza e il tipo di risultato che si vuole ottenere. La preparazione del singolo prompt da passare all’LLM deve contenere, ad esempio, tre gruppi di informazioni, che comporranno il contesto da inserire nell’attivazione dell’LLM. Questa attivazione viene effettuata dall’Orchestratore tramite delle API predisposte dal gestore della piattaforma.
I tre gruppi di informazioni principali che compongono il prompt potrebbero essere:
- Il ruolo che il modello deve assumere. Ad esempio: “Sei un operatore finanziario e stai valutando una pratica di mutuo immobiliare per un cliente. Devi formulare un tuo parere in base ai dati a disposizione, in modo che l’operatore possa prendere una decisione”.
- Le regole da seguire. Vanno impostate regole e limiti di comportamento, istruzioni su come trattare i dati, l’indicazione di quali risultati ci si aspetta e in che formato.
- I dati. Vanno inseriti sia i dati necessari a formulare la valutazione, sia dati complementari, ottenuti con l’accesso a banche dati esterne, che completano il contesto. Il tipo di dato inserito va descritto, con l’indicazione di quale sia la sua funzione e di come debba essere utilizzato.
La corretta formulazione del prompt, per ogni Agente AI, pone dei limiti e dei vincoli al suo comportamento e indica, nel modo più accurato possibile, quale risultato ci si aspetta. Abbiamo indicato un esempio, ma la struttura e le modalità con cui formulare i prompt vanno definite attentamente in sede progettuale. E’ una fase preparatoria fondamentale per la gestione degli Agenti AI.
Ogni risposta restituita da un modello LLM dovrà essere poi valutata dall’Agente Verificatore, in termini di congruenza dei risultati ottenuti e di contenuti.
Per l’accesso alle risorse esterne è preferibile utilizzare accessi guidati da protocolli standard come MCP (Model Context Protocol), e delimitare in modo specifico le fonti a cui attingere, che siano verificate e attendibili, includendole in una “White List” definita a livello progettuale, con livelli di autorizzazione e di ricerca predefiniti [10]. La selezione delle fonti è uno degli elementi progettuali da predisporre in anticipo.
La sequenza delle operazioni va anche a comporre il rapporto finale sull’esito del processo, in modo da consentire la chiara documentabilità dei risultati e la spiegabilità dei processi eseguiti.
L’identità digitale degli Agenti AI
Limitare l’autonomia degli Agenti AI vuol dire anche attribuire loro delle specifiche “Identità Digitali”, che sono necessarie per poter concedere loro determinate autorizzazioni per l’accesso alle risorse aziendali necessarie allo svolgimento delle attività. E naturalmente occorre sempre limitare al massimo i privilegi accordati, per gli scopi strettamente limitati per cui vengono autorizzati, in base al principio del “Least Privilege”.
In via preliminare va in ogni caso stabilita la tipologia di agenti da impiegare e i limiti che occorre imporre alle loro autorizzazioni di accesso per l’esecuzione delle attività.
Attribuire una identità all’Agente AI consente di tracciare le operazioni effettuate e l’uso che viene fatto delle risorse aziendali, verificando poi i risultati delle operazioni eseguite. Consente anche di determinare quale agente, e per quale motivo, abbia compiuto una certa azione, entro i limiti di autonomia che gli sono stati delegati.
Figura 3 – Identità e autorizzazioni dei singoli agenti
Un Agente AI deve essere identificato e riconoscibile durante la sua attività, perché è in base alla sua identificazione che vanno concessi i privilegi e le autorizzazioni necessarie, analogamente a come si fa con un qualsiasi operatore dell’organizzazione.
Vanno quindi effettuate le operazioni di identificazione e di autenticazione, quando l’Agente AI vuole accedere ad una risorsa, e di autorizzazione con la concessione dei privilegi prestabiliti, assicurando inoltre la tracciabilità delle azioni compiute [11].
Particolare importanza assumono quindi le registrazioni di Log, non solo per la tracciabilità e gli Audit successivi, ma anche per contribuire, insieme ai meccanismi di gestione del Recovery, alla Reversibilità delle operazioni in caso di malfunzionamenti, o errori nelle approvazioni concesse. Questo della Reversibilità rappresenta uno dei principi di base che abbiamo già indicato in precedenza. Assicurare la Reversibilità delle azioni è necessario non solo per gestire malfunzionamenti e anomalie mediante operazioni di roll-back, ma anche perché in base a successive verifiche o approfondimenti, in corso di analisi o in seguito, può essere necessario rivedere il processo decisionale. Nel caso di esecuzione di azioni non reversibili, come l’inoltro di una mail al Cliente, ad esempio, vanno eseguiti degli interventi compensativi, come comunicazioni e rettifiche, o altro tipo di interventi di recupero.
L’identità dell’Agente AI dovrebbe essere gestita nell’ambito delle procedure aziendali di Identity and Access Management (IAM) invocate dal Modulo Orchestratore, che assegna i compiti e attiva gli agenti, sulla base delle autorizzazioni decise in fase di progettazione e in accordo con le policy dell’organizzazione.
L’identità digitale di un Agente AI non è quindi solo l’applicazione dei tradizionali principi di sicurezza, ma è anche uno strumento per consentire il controllo delle operazioni, per assegnare dei ruoli e per definire dei limiti, in relazione al livello di autonomia che si è deciso di concedere agli agenti.
Attraverso l’identità digitale dei diversi agenti utilizzati nei diversi task si rende trasparente la catena delle azioni e la verifica delle responsabilità che, in ogni caso, appartengono alle strutture dell’organizzazione e a chi abbia ruoli ben definiti, in termini normativi e legali.
L’agente verificatore
L’Agente Verificatore non coordina il processo, non indirizza gli altri agenti e non dialoga con sistemi esterni. Il suo compito è quello di verificare la qualità dei risultati forniti dagli Agenti AI operativi. E’ uno strumento utilizzato dal Modulo Orchestratore in corso d’opera, per analizzare congruenze tra dati, per verificare risultati rispetto alle attese e il rispetto dei vincoli prestabiliti.
Durante lo svolgimento del workflow gestito dall’Orchestratore, laddove necessario, possono essere verificate le risposte fornite dagli Agenti AI, se siano cioè coerenti o meno con le istruzioni ricevute. In base a queste verifiche le autorizzazioni concesse dal Modulo Orchestratore, o il loro diniego se necessario, possono ritenersi affidabili, perché fondate sulla coerenza e la qualità dei risultati ottenuti, oltre che sulla loro verificabilità.
Vanno anche controllati i risultati degli accessi alle banche dati esterne effettuati dagli Agenti operativi, la correttezza dei dati numerici ottenuti, la coerenza logica di alcuni risultati, la correttezza formale rispetto alle regole e ai range di valutazione stabiliti e la completezza delle informazioni ricevute in risposta alle richieste effettuate.
Altri tipi di verifiche sono da implementare in relazione al tipo di processo, al tipo di applicazione e in relazione agli scopi che si vogliono perseguire.
L’Agente Verificatore può essere un Agente AI, che utilizza un modello LLM per valutare la coerenza e la qualità dei risultati ottenuti. In questa veste, svolge il ruolo di “Agente Antagonista”, a supporto degli operatori umani, per controllare i risultati ottenuti dagli Agenti AI operativi. Non svolge quindi delle azioni direttamente operative, ma assume il ruolo di controllore del lavoro svolto dagli altri agenti.
Scelte diverse possono essere fatte, specialmente in situazioni di test o di sperimentazione, dove si possono provare soluzioni diverse per valutarne i risultati. Ad esempio, anche l’Agente Verificatore potrebbe essere all’inizio, in una fase transitoria, sostituito da un modulo software deterministico per sperimentare e verificare la correttezza del processo, per decidere successivamente se procedere o meno con l’introduzione di un Agente AI come Verificatore.
Il ruolo di questo agente è quindi quello di controllare nel merito i risultati ottenuti, in termini di qualità, congruenza e affidabilità.
Il ruolo di controllore di processo invece, per la verifica finale, viene svolto dal Modulo di Audit.
Il modulo di Audit di processo
Il Modulo di Audit è un modulo software di tipo deterministico, che non deve ripetere il lavoro svolto dagli Agenti Operativi né quello dell’Agente Verificatore, i cui risultati si danno per acquisiti. Il suo compito è quello di effettuare una verifica finale sulla corretta applicazione delle policy aziendali e delle regole di processo.
In questa fase occorre controllare che tutti gli step del workflow siano stati eseguiti secondo il processo definito, che le autorizzazioni previste dagli step di Checkpoint siano state correttamente applicate, che le azioni eseguite siano state coerenti con le autorizzazioni ricevute, che siano stati rispettati i vincoli e le soglie previste dalle policy, e infine che tutte le operazioni siano state regolarmente documentate e registrate.
Nel caso in cui il processo di Audit rilevi delle anomalie, occorre formulare precisamente il tipo di anomalia, quale sia stata l’azione non correttamente eseguita, e nel caso sia stata eseguita da un Agente AI, da quale Agente AI. Allo stesso tempo vanno segnalate anomalie di tipo procedurale, come un’autorizzazione prevista ma non richiesta, o un controllo non eseguito, o il mancato rispetto della sequenza operativa corretta.
In questo modo si dà all’operatore umano la possibilità di intervenire per correggere l’operazione effettuata, utilizzando le funzionalità previste di revisione e di riattivazione del processo. Questi interventi sono demandati, su attivazione dell’operatore umano, al Modulo Orchestratore, che procederà alle operazioni necessarie in base alle istruzioni fornite dall’operatore, a valle delle verifiche effettuate dal modulo.
Il Modulo di Audit non effettua direttamente alcuna operazione, perché il suo scopo è quello della verifica finale e della comunicazione all’operatore dei risultati. La sequenza dei controlli da effettuare può essere formalizzata in una tabella definita a livello progettuale, contenente il tipo di controllo, la fase, i vincoli e il tipo di risultato atteso.
Il risultato dell’attività del Modulo di Audit è la predisposizione del Report Finale, in cui la sequenza delle operazioni viene riepilogata, insieme con le motivazioni a supporto delle indicazioni fornite dagli Agenti Operativi in relazione alle azioni eseguite.
Il report di Audit va anch’esso registrato, per le verifiche successive o per audit esterni (parte dell’Accountability). Il Report Finale consente all’operatore umano di completare il processo, o anche di intervenire, se necessario, per eseguire delle azioni correttive sulle operazioni svolte.
Conclusioni
In questo articolo abbiamo cercato di affrontare due delle principali difficoltà che ci troviamo di fronte nell’utilizzo di architetture agentiche nelle nostre organizzazioni, due difficoltà di tipo molto diverso tra loro, che richiedono attente valutazioni e capacità di governance.
La prima difficoltà da affrontare è quella umana, una preoccupazione molto estesa, in ampi settori professionali, sul futuro del lavoro e delle professioni. Man mano che le applicazioni di Intelligenza Artificiale si vanno sviluppando, e le architetture agentiche sono oggi al centro di questo sviluppo, molte professionalità si vedono messe in discussione, perché potenzialmente sostituibili dall’AI.
Questa preoccupazione va affrontata con adeguate politiche di formazione, con una graduale evoluzione dei processi aziendali e con il coinvolgimento delle persone, come risorse preziose e come parte di un progetto complessivo di evoluzione del lavoro. C’è la necessità di agire parallelamente sulla gestione dei processi e delle risorse umane, che rappresentano un fattore essenziale di successo in questa fase di profonda trasformazione del lavoro.
Affrontare queste questioni richiederà anche una riflessione critica verso quelle soluzioni immaginifiche, dove gli Agenti AI “fanno il lavoro al posto nostro”. L’idea di fondo è che occorra concentrare l’attenzione innanzitutto sulla riprogettazione dei processi, all’interno delle organizzazioni, con adeguati modelli di governance e con il coinvolgimento delle strutture aziendali. Perché non basta introdurre l’AI in azienda se l’intera struttura, e le persone, non vengono coinvolte nella trasformazione. Il rischio è che il risultato ottenuto potrebbe essere persino un aumento dell’entropia e un rallentamento dei processi.
La seconda difficoltà che abbiamo evidenziato è quella di una non completa fiducia sull’affidabilità dei processi gestiti con l’utilizzo di architetture agentiche. E’ una difficoltà che trova giustificazione nella consapevolezza dei rischi da affrontare, legati soprattutto al livello di autonomia concessa agli Agenti AI e all’indeterminatezza dei modelli generativi.
Abbiamo cercato di esporre un quadro di governance complessivo per la progettazione e l’utilizzo di queste architetture, che può contribuire a rendere più chiari i ruoli delle diverse componenti architetturali, a separare nettamente le competenze operative da quelle di controllo e da quelle di audit di processo.
Il framework di gestione proposto riprende dei modelli architetturali presenti in molte delle soluzioni offerte dai principali operatori di mercato, ma vuole definire maggiormente i ruoli tra chi opera e chi controlla, tra chi verifica e chi autorizza. Infine, la componente finale di audit del processo seguito consente di verificare l’aderenza tra le attività svolte nell’ambito dell’architettura agentica e le policy dell’organizzazione.
Separare e rendere chiare le responsabilità contribuisce a rendere più trasparenti i processi, fornendo gli strumenti di governance necessari a gestire e a tracciare le attività, nel rispetto delle policy delle organizzazioni e delle normative applicabili, come l’AI Act dell’Unione Europea.
In questo articolo non è stato affrontato il tema della sicurezza delle architetture agentiche, che riguarda sia gli attacchi classici che possono essere condotti verso questi sistemi, sia quelli più specifici come il “prompt injection”, un attacco rivolto alle componenti LLM incluse nell’architettura, per manipolare le istruzioni fornite agli agenti operativi e influenzarne le inferenze. Non è stata affrontata neanche la problematica degli attacchi condotti utilizzando Agenti AI “malevoli”, una questione di grande rilevanza nella Cybersecurity odierna. Sono argomenti che non è possibile affrontare in questo contesto, perché sposterebbero il focus di questo lavoro, che cerca di concentrarsi sulle criticità e la governance delle architetture agentiche, verso argomenti più specifici, che sono meritevoli di essere trattati a parte.
Il tema che si è voluto sviluppare in questo articolo è che la fiducia nell’utilizzo di queste architetture non consiste solo in una adeguata valutazione del rischio e nella limitazione del livello di autonomia da concedere agli Agenti AI.
Diventa fondamentale la progettazione di un quadro complessivo di controllo e di governance, che consenta di valorizzare le componenti umane con l’utilizzo di strumenti, tecnici ed organizzativi, adeguati a gestire il livello di complessità crescente delle architetture agentiche.
E’ una proposta di architettura agentica governata, ma il tema di conciliare l’autonomia degli Agenti AI con la gestione del rischio, in uno sviluppo sempre più diffuso di queste applicazioni, è in continua evoluzione. E’ una evoluzione che riguarda sia la progettazione dei framework architetturali che la scelta del tipo di applicazioni che li utilizzano con maggiore efficacia, migliorando progressivamente i processi e le capacità gestionali delle organizzazioni.
E’ nostra convinzione che non tutto quello che è oggi tecnicamente possibile realizzare debba necessariamente essere attuato. Occorre evitare che vengano resi accettabili dei livelli di rischio elevati, che non siano proporzionali ai vantaggi ottenuti.
Si tratta, in conclusione, di ottenere un equilibrio tra vantaggi e rischi, rivedendo i processi organizzativi e tenendo conto che la motivazione e il coinvolgimento delle persone sono un fattore indispensabile di successo per ogni organizzazione.
Fonti
[1] REGOLAMENTO UE 2024/1689 del Parlamento Europeo e del Consiglio (AI Act) – 2024
https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=OJ%3AL_202401689
[2] LEONE XIV – Lettera Enciclica Magnifica Humanitas – 2026
https://www.vatican.va/content/leo-xiv/it/encyclicals/documents/20260515-magnifica-humanitas.html
[3] International Labour Organization – Generative AI and Jobs: A Refined Global Index of Occupational Exposure, ILO Working Paper 140, 20 maggio 2025.
https://www.ilo.org/publications/generative-ai-and-jobs-refined-global-index-occupational-exposure
[4] Yonhap News Agency – Hyundai Motor, labor union tentatively reach wage deal – 2026
https://en.yna.co.kr/view/AEN20260825001251320
[5] Erik Brynjolfsson, Bharat Chandar, Ruyu Chen – Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence, Stanford Digital Economy Lab, 13 novembre 2025.
[6] AGENZIA PER L’ITALIA DIGITALE (AGID) – Linee guida su IA nella PA: al via la consultazione pubblica su sviluppo e procurement – 2026
https://www.agid.gov.it/sites/agid/files/2026-03/LLGG_Sviluppo_per%20consultazione%20pubblica.pdf
[7] SAE INTERNATIONAL –SAE J3016™ – Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles – 2021.
[8] MICROSOFT – AI agent orchestration patterns – 2026
https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns
[9] Anthropic – How we built our multi-agent research system – 2025
https://www.anthropic.com/engineering/multi-agent-research-system
[10] Model Context Protocol Blog – What is the Model Context Protocol (MCP)? – 2026
https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro
[11] Harold Booth, William Fisher, Ryan Galluzzo, Joshua Roberts – Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization – NIST/NCCoE, Initial Public Draft, 5 febbraio 2026
https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd
Articoli correlati
[A1] G. FERRIGNO – Explainable ai – Come spiegare le decisioni dell’AI: tecniche di attribuzione e casi reali – 2026
[A2] G. FERRIGNO – Sovranità digitale, Big Tech e agenti AI: i limiti concreti delle regole Ue – 2026
[A3] G. FERRIGNO – Agenti AI, quali rischi crescono con il livello di autonomia – 2026
Partecipa alla community