Leader di pensiero

Perché i dati migliori, da soli, non bastano per gli agenti IA

mm
Aggiungi Unite.AI alle tue fonti preferite su Google

Per anni, uno dei consigli più comuni per l’IA aziendale è stato quello di mettere prima a posto i dati. La logica è semplice: se un sistema deve prendere decisioni utili, ha bisogno di informazioni accurate e accessibili su cui basarsi.

Questa affermazione è ancora valida, ma sta diventando incompleta, man mano che gli agenti IA passano dal rispondere alle domande e generare contenuti all’agire per conto di dipendenti e organizzazioni. I dati possono indicare a un agente cosa è vero riguardo a un cliente, una transazione, una richiesta di risarcimento o una domanda, ma non gli dicono necessariamente cosa dovrebbe accadere dopo, né quali sarebbero le conseguenze di un’azione. Questa distinzione è importante quando un agente non si limita più a fornire una risposta, ma approva una richiesta, aggiorna un record, contatta un cliente o fa avanzare una pratica.

Ci si aspetta che i dipendenti delle aziende imparino a operare all’interno di una struttura che comprende iter di approvazione, regole aziendali, dipendenze, eccezioni e percorsi di escalation: anche gli agenti devono poter fare lo stesso. Poiché Gartner prevede che, entro la fine del 2026, il 40% delle applicazioni aziendali includerà agenti IA specializzati in attività specifiche, rispetto a meno del 5% nel 2025, sarà sempre più difficile ignorare le lacune di conoscenza degli agenti. 

Gartner prevede inoltre che, entro il 2028, l’80% del ritorno tangibile sugli investimenti derivante dall’IA agentica proverrà da agenti specializzati in ambiti specifici. La specializzazione è importante, ma risolve solo una parte del problema. Conoscere un determinato ambito non indica automaticamente a un agente dove iniziano e finiscono le sue responsabilità, come si inserisce la sua attività in un processo più ampio o chi dovrebbe subentrare quando qualcosa esula dalle sue competenze. Per diventare partecipanti affidabili alle attività aziendali, gli agenti hanno bisogno sia del contesto del flusso di lavoro sia dei dati aziendali.

I dati corretti non dicono a un agente cosa succede dopo

Si consideri una richiesta di prestito: un agente potrebbe avere accesso alla storia finanziaria del richiedente, alle informazioni sul suo impiego e ad altri documenti pertinenti. Queste informazioni possono aiutarlo a comprendere la richiesta, ma non gli dicono come l’organizzazione la gestisce.

Quali verifiche devono essere effettuate per prime? Cosa cambia se il richiedente soddisfa una condizione ma non un’altra? Quali informazioni sono obbligatorie prima che la pratica possa procedere? Quali decisioni possono essere prese automaticamente e quali devono essere sottoposte a un responsabile della valutazione del credito?

La maggior parte delle attività aziendali prevede molti percorsi condizionali di questo tipo. Un processo può avanzare automaticamente quando sono soddisfatti determinati criteri, fermarsi in attesa di ulteriori informazioni oppure seguire un percorso completamente diverso quando si verifica un’eccezione. L’azione successiva appropriata dipende non solo dalle informazioni disponibili, ma anche dallo stato corrente dell’attività e da ciò che è già avvenuto.

Questo cambia il significato di affidabilità per un agente aziendale. Una risposta accurata non basta se l’azione successiva è sbagliata. Un agente può interpretare correttamente le informazioni che ha a disposizione e comunque spostare una pratica nella fase sbagliata, saltare l’approvazione richiesta o agire prima che una dipendenza sia stata completata.

McKinseyha recentemente condiviso alcune riflessioni sul proprio lavoro con un’azienda di tecnologie mediche che aveva scoperto che la piattaforma IA in uso non era in grado di supportare diverse regole fondamentali dei suoi flussi di lavoro. Invece di posticipare la data di lancio per colmare queste lacune, l’azienda ha proseguito secondo i piani, finendo per lasciare inutilizzato un valore stimato pari al 30% di quello previsto dall’IA. Questo esempio sottolinea la necessità per le aziende di considerare il processo che circonda un’attività, non soltanto le informazioni necessarie per portarla a termine. 

Adeguare le misure di protezione alle decisioni che un agente può prendere

Man mano che gli agenti acquisiscono la capacità di agire, anche la governance deve diventare più specifica. Un agente che recupera un documento sulle politiche aziendali non comporta lo stesso livello di rischio di uno che modifica il conto di un cliente, approva un pagamento o avvia una transazione. Eppure, le organizzazioni possono facilmente cadere in uno di due estremi: lasciare agli agenti troppa libertà di agire oppure richiedere l’approvazione umana per quasi tutto.

I controlli applicati a un agente dovrebbero riflettere le decisioni che può prendere e le potenziali conseguenze. Può essere appropriato che un’azione ripetitiva e a basso rischio venga completata in autonomia. Un’altra azione potrebbe richiedere un’approvazione oltre una determinata soglia. Un caso insolito potrebbe dover essere sottoposto immediatamente a un dipendente.

La supervisione umana è più utile quando è intenzionale. Se una persona deve approvare ogni passaggio di routine, gran parte dei vantaggi dell’introduzione di un agente svanisce. Ma eliminare i controlli intermedi per decisioni che richiedono davvero giudizio o responsabilità crea un problema diverso.

IBM Research ha sostenuto la necessità di stabilire regole esplicite sulle azioni che gli agenti sono autorizzati a compiere e sui momenti in cui è necessaria la supervisione umana. Questi controlli devono anche tenere conto del processo a cui partecipa l’agente. L’autorità di un agente non rimane necessariamente invariata dall’inizio alla fine di un caso. Ciò che può fare in sicurezza può dipendere dalla fase del processo, dalle informazioni già verificate, dalle decisioni già prese e dalle conseguenze dell’azione successiva.

Ciò significa che le organizzazioni devono integrare la governance nel flusso di lavoro stesso. Invece di assegnare a un agente un ampio insieme di autorizzazioni e fare affidamento su di esso in ogni situazione, possono definire dove gli è consentito agire in autonomia, dove è necessario soddisfare ulteriori condizioni e dove la responsabilità deve passare a una persona. La questione, quindi, non è tanto se un agente sia autonomo, quanto piuttosto in quali punti di un processo abbia senso concedergli autonomia.

Gli agenti devono integrarsi con la realtà aziendale esistente

Il contesto dei processi diventa ancora più importante quando un agente deve interagire con il resto dell’azienda. Le organizzazioni non partono da zero. Una singola richiesta di un cliente potrebbe già passare tra un sistema CRM, un archivio di documenti, una piattaforma di gestione dei casi e un sistema ERP, coinvolgendo al contempo dipendenti di diversi reparti.

Inserire un agente in una parte di questo ambiente non rende automaticamente più efficiente l’intero processo. Un agente potrebbe svolgere alla perfezione il proprio compito, ma se poi un dipendente deve copiare il risultato in un’altra applicazione, stabilire a chi debba essere trasmesso o riavviare manualmente il processo altrove, il collo di bottiglia si sarà semplicemente spostato.

Per questo le aziende devono considerare gli agenti come partecipanti a un processo più ampio, anziché come strumenti isolati. Che cosa attiva l’agente? Quali informazioni riceve? Di che cosa è responsabile? Dove viene indirizzato il lavoro una volta che ha terminato? E che cosa succede quando non riesce a portare a termine il compito?

Queste domande diventano ancora più importanti quando le organizzazioni introducono più agenti specializzati. Deloitteha individuato nell’orchestrazione un requisito fondamentale per le aziende che si orientano verso sistemi multiagente, in cui agenti diversi possono assumere ruoli distinti e coordinare il lavoro. L’orchestrazione aziendale deve comprendere anche il modo in cui gli agenti comunicano e si coordinano tra loro, non soltanto il modo in cui operano singolarmente. Senza tale supervisione, gli agenti rischiano di agire sulla base di un contesto incompleto, avviare azioni in conflitto o aggirare le regole aziendali e le procedure di approvazione vigenti. Gli agenti operano comunque all’interno di organizzazioni ricche di applicazioni, dipendenti, regole aziendali e processi esistenti, che possono durare giorni, settimane o mesi.

Si parta dal processo da portare a termine e si stabilisca quale ruolo vi svolgano gli agenti, le persone e i sistemi esistenti. Un agente potrebbe gestire autonomamente una fase, un altro agente eseguire un controllo specializzato, un dipendente formulare una valutazione e un sistema esistente effettuare la transazione finale. L’importante è che il lavoro possa passare da un partecipante all’altro senza perdere il contesto lungo il percorso.

L’autonomia richiede una struttura

Fornire agli agenti una maggiore struttura non significa che ogni azione debba essere soggetta a un ulteriore livello di restrizioni. Anzi, può essere vero il contrario. Processi chiari possono dare alle organizzazioni maggiore fiducia nel definire dove gli agenti possano operare autonomamente, perché limiti, eccezioni e punti di escalation sono già stati stabiliti. Un agente non ha bisogno di libertà illimitata per offrire un valore concreto. Gli serve una responsabilità sufficiente per far avanzare il lavoro, un contesto adeguato per capire che cosa fare in seguito e una chiara consapevolezza dei casi in cui la responsabilità spetta a qualcun altro.

Dati migliori continueranno a rendere gli agenti più capaci. Ma la sola capacità non basta a rendere utile un agente all’interno di un’azienda. La vera prova è la sua capacità di compiere l’azione giusta, al momento giusto di un processo e nel rispetto dei limiti stabiliti dall’azienda.

Joram è uno sviluppatore chiave di Flowable, con molti anni di esperienza nel software open source e nella creazione di motori di processo scalabili. Ha cofondato il progetto Activiti (su cui si basa Flowable) ed è stato uno sviluppatore chiave per oltre sei anni. In precedenza ha lavorato per JBoss/RedHat come membro del team jBPM.