Con gli Agenti AI sempre più intelligenti e autonomi, le aziende di ogni tipo cercano in modo frenetico casi studio ed esempi che aiutino a fare chiarezza, fornire spunti di utilizzo e implementare questo tipo di strumenti.
Ma quando leggiamo di un “esempi di agenti AI”, che cosa stiamo guardando davvero? Potrebbe essere un sistema già usato ogni giorno, un pilot ancora da validare oppure un’automazione a cui il marketing ha assegnato un’etichetta più attraente.
In questo articolo vogliamo parlare di tutte queste situazioni (sì, anche dell’automazione, perché non sempre per ottenere ottimi risultati serve la complessità agentica).
I tre casi italiani analizzati qui si trovano su gradini diversi di complessità, di produzione e di tipologia. Parleremo di RA-Copilot della Regione Abruzzo, un ottimo esempio di agente AI per la PA (Pubblica Amministrazione). LEVI, sviluppato per AXPO, e Ubi di uBroker sono risposte tecnologiche a esigenze di aziende private, invece, e ci permetteranno di analizzare diversi stadi e soluzioni.
Per ogni progetto vedremo il problema di partenza, l’architettura, il ruolo delle persone, lo status effettivo e i risultati disponibili.
Prima degli esempi: cosa rende davvero agentico un sistema?
Un agente AI ha due caratteristiche fondamentali:
- riceve un obiettivo e decide come raggiungerlo;
- gestisce le eccezioni e usa più strumenti in una sequenza che può cambiare in base al contesto.
È questo comportamento, non la presenza di una chat o di un modello linguistico, a renderlo agentico. Occorre infatti fare molta attenzione a non confondere semplici automazioni o RPA con gli Agenti AI: sono soluzioni altrettanto valide per certi tipi di problemi, ma alcuni provider potrebbero approfittarsene e presentare soluzioni non agentiche come tali.
Chi vuole fare massima chiarezza su definizioni e differenze può approfondire cosa sono gli agenti AI in questo articolo dedicato.
Qui dobbiamo distinguere due dimensioni che nelle presentazioni commerciali vengono spesso sovrapposte: l’agenticità del sistema e la maturità del progetto. “Automazione” e “agente” descrivono il modo in cui il sistema opera; “pilot” e “produzione” indicano invece quanto il progetto sia avanzato e quanto sia stato esposto alla realtà operativa.
- Pilot: è il primo stadio del progetto, quello per fare test, raccogliere dati, migliorare l’MVP in ottica di espansione sul mercato. Serve a verificare un’ipotesi su un perimetro controllato; non si dovrebbe presentare un pilot come un caso di successo, perché non ha ancora passato la prova suprema: quella della realtà.
- Automazione intelligente: integra dati, sistemi e regole per eseguire un processo in modo più ordinato. Può incorporare componenti AI, ma non per questo decide autonomamente il percorso da seguire. Spesso si tratta di uno stadio intermedio, come vedremo, tra la definizione delle necessità di automazione e l’automazione stessa. A volte, con la sola automazione intelligente, si coprono le necessità identificate e può terminare così. Altre volte, è il test iniziale per passare alla progettazione di un processo agentico.
- Agente AI in produzione: opera su utenti e processi reali, entro confini definiti. Ha regole di escalation, un presidio operativo e metriche con cui valutarne il comportamento.
Un sistema può quindi essere agentico e trovarsi ancora in pilot, essere già operativo senza essere agentico, o combinare invece entrambe le condizioni quando è nella fase di maturità.
La distinzione è importante perché un progetto può avere valore anche senza essere un agente. Chiamarlo per ciò che è consente di definire aspettative, responsabilità e investimenti con maggiore precisione.
È anche il criterio di base per capire come evitare l’agent-washing: non vogliamo svalutare chatbot e automazioni, ma evitare di presentarli come qualcosa di diverso.
Tre gradini diversi sulla scala agentica
Il White Paper Gunpowder “Agentic Enterprise” usa la metafora di una scala composta da tre gradini sequenziali per identificare i livelli di readiness.
- Il primo riguarda la collocazione di dati e modelli.
- Il secondo riguarda la gradualità con cui integrare sistemi esistenti, automazione e capacità agentiche.
- Il terzo è il passaggio dal pilot alla realtà operativa.
Saltarne uno è rischioso. Se dati e architettura non sono sotto controllo, la discussione sul modello è prematura. Se i sistemi non comunicano, aggiungere un’interfaccia conversazionale non risolve la frammentazione. Se manca un presidio dopo il rilascio, il go-live è solo una data nel calendario.
Per questo presentiamo tre casi che abbiamo realizzato attraverso la stessa griglia: problema, architettura, persone, status e metrica.
Esempio 1: Regione Abruzzo, il pilot di agente AI per la PA che parte dalla sovranità del dato
Il primo caso ci porta dentro una pubblica amministrazione, dove documenti, norme e vincoli sul trattamento delle informazioni condizionano l’intero progetto.
Qui, per caratteristiche di privacy e riservatezza, la domanda iniziale è stata d’obbligo: “dove devono restare dati e modelli mentre il sistema lavora?”.
Il problema: applicare norme e documenti alle istanze
RA-Copilot è inserito in RASportello, il contesto operativo usato per la gestione delle istanze, come ad esempio le pratiche per il taglio degli alberi. Dietro una richiesta apparentemente circoscritta ci sono documenti da esaminare e riferimenti normativi regionali da recuperare nel contesto corretto.
La necessità non era ottenere una risposta generica prodotta da un modello generico. Occorreva lavorare sulla documentazione pertinente, mantenere un legame controllabile con le fonti normative dell’ente e conservare dati e componenti applicativi nel perimetro definito dalla Regione. In un processo amministrativo, una formulazione plausibile ma priva del giusto riferimento non basta.
RA-Copilot viene quindi creato e sperimentato per il supporto a un’attività documentale e normativa. Il perimetro del pilot permette di osservare come il sistema recupera le informazioni e come si inserisce nel lavoro degli uffici, prima di parlare di estensione.
L’architettura: Giano on-premise e RAG normativa
Il progetto usa Giano, la piattaforma AI di Gunpowder installabile on-premise. Dati e componenti applicativi restano nel perimetro definito dall’ente, mentre l’architettura può lavorare con modelli open-source e commerciali, fra cui GPT, Gemini, LLaMA, Mistral, Gemma e Phi.
La scelta non impone quindi un unico modello per ogni attività. Il punto centrale è il controllo dell’architettura e delle fonti. Un sistema RAG (Retrieval-Augmented Generation) recupera i contenuti dalle knowledge base normative regionali e li porta nel contesto della richiesta. Il modello non viene infatti mai lasciato a rispondere sulla sola base della propria conoscenza generale.
Questa combinazione, on-premise, modelli selezionabili e RAG sulla documentazione dell’ente, traduce la sovranità del dato in una scelta progettuale. Non è la soluzione migliore per qualsiasi organizzazione, ma è la più coerente con un contesto in cui controllo, riservatezza e tracciabilità pesano più della rapidità di attivazione offerta da un servizio standard.
Perché RA-Copilot è agentico
In un workflow tradizionale, il dominio amministrativo e la normativa applicabile verrebbero determinati attraverso regole statiche, classificazioni predefinite o corrispondenze configurate a monte.
RA-Copilot opera diversamente. Analizza il contenuto semantico della pratica e i documenti allegati, identifica il dominio amministrativo e determina dinamicamente quale corpus normativo interrogare. Costruisce quindi una catena operativa composta da classificazione contestuale, selezione delle fonti, retrieval semantico, reasoning istruttorio e generazione dell’output.
La sequenza non è rigidamente deterministica: cambia in base alla pratica e al contesto amministrativo rilevato. È inoltre orientata a un obiettivo preciso, produrre un supporto istruttorio coerente, non una semplice risposta conversazionale.
L’autonomia resta delimitata. RA-Copilot opera autonomamente nella pre-istruttoria, ma validazione, approvazione e rigetto dell’istanza restano in capo al funzionario, che decide e firma.
Lo status e il risultato
RA-Copilot è, al momento della scrittura di questo articolo, in fase di pilot. La precisazione è necessaria: il caso dimostra un’impostazione architetturale e un’applicazione concreta, ma presentarlo come agente già esteso alla normale operatività dell’ente sarebbe fuorviante.
Lo stesso impianto è stato replicato nella Regione Marche all’interno della sperimentazione Reg4AI. Per questa evoluzione è indicata una stima del -80% del tempo di controllo documentale a regime. Tutti i dati disponibili per sperimentazioni e pilot si riferiscono a una previsione riferita allo scenario in cui il sistema raggiunga il funzionamento previsto, e vanno quindi presi come tali.
Un pilot ha valore quando delimita l’ipotesi, rende visibili i vincoli e produce elementi per decidere il passo successivo. Nel caso Abruzzo, la condizione da verificare viene prima della scala: collegare modelli e norme senza cedere il controllo sui dati. Essendo riusciti a fare questo, il progetto è già un successo.
Esempio 2: AXPO e LEVI, l’automazione che è lo step intermedio verso l’Agente AI
Il secondo caso riguarda il recupero crediti nel settore energetico.
LEVI è un’automazione intelligente costruita su Salesforce, con una roadmap che prevede capacità conversazionali e adattive.
Includerla fra gli esempi di agenti AI serve a mostrare un punto spesso trascurato: prima dell’agente può esserci un lavoro di integrazione che produce valore e prepara il processo.
Saltarlo per arrivare più rapidamente all’etichetta “agentico” rischia di lasciare intatta la frammentazione di partenza.
Ieri: il buco nero comunicativo del recupero crediti
Nel processo precedente, la gestione delle posizioni coinvolgeva AXPO, collector e studi legali. Il gestionale conteneva informazioni essenziali, ma lo scambio con i partner esterni passava spesso anche da email e file Excel. Il tutto dentro un settore regolato da ARERA.
La situazione ci era stata presentata come un “buco nero comunicativo” verso l’esterno. Le informazioni esistevano, ma la loro circolazione richiedeva passaggi manuali fra organizzazioni e strumenti diversi. Il personale interno finiva per fare sempre da ponte, inoltrando dati e riallineando interlocutori.
Questo è un problema di processo e integrazione prima ancora che di AI. Se le informazioni non hanno un percorso condiviso, un agente costruito sopra quel sistema eredita la stessa frammentazione. Potrà conversare in modo fluido, ma continuerà a dipendere da dati dispersi e passaggi fragili.
Oggi: un layer Salesforce-native fra sistemi e partner
LEVI interviene su questo livello. È un layer applicativo basato su Salesforce Communities e progettato per essere GDPR-compliant. Collega SAP ERP, SAP IS-U, PITECO e i partner esterni coinvolti nel recupero crediti.
Collector e studi legali trovano nel portale un punto di accesso al processo, per vedere lo status delle attività e dei contatti senza dover sempre richiedere intermediazione.
Per AXPO, il cambiamento riguarda anche il lavoro interno: le persone non devono più agire da “passacarte” fra sistemi e soggetti diversi. Possono concentrarsi sulla gestione delle eccezioni e sulle attività che richiedono responsabilità e giudizio.
Il beneficio è interessante sul piano operativo, anche se non possiamo indicare KPI specifici per LEVI.
Cos’è ad oggi LEVI: automazione intelligente
LEVI è più flessibile di un RPA tradizionale: non esegue script fissi, ma gestisce un workflow low-code che il cliente può riconfigurare. Questa flessibilità, però, non basta a renderlo un agente.
Il cuore decisionale resta nel processo configurato, non in un modello che decide autonomamente come raggiungere un obiettivo. LEVI orchestra sistemi, dati, attori e passaggi definiti a monte, ma non determina da solo la strategia di recupero e non agisce sulle eccezioni con autonomia relativa.
Per questo vogliamo collocarlo esplicitamente sul piano dell’automazione intelligente, sottolineando come questo ruolo nel percorso agentico sia fondamentale e preparatorio: costruisce l’infrastruttura sulla quale potranno essere introdotte capacità autonome successive.
Domani: la roadmap agentica
La roadmap di LEVI è dove le cose si fanno davvero interessanti: prevede un’interfaccia conversazionale e algoritmi adattivi per valutare la gravità del sollecito.
Sono evoluzioni future, che portano il progetto sempre un po’ più in là in termini di efficacia e intelligenza. Senza gli step precedenti, però, non sarebbe stato possibile identificare e mappare correttamente il processo per replicarlo con l’AI.
Il percorso verso l’agentico segue infatti una sequenza chiara: prima l’integrazione e l’orchestrazione dei sistemi esistenti, poi un agente conversazionale su un perimetro definito, infine sistemi multi-agent e algoritmi adattivi. Nel caso AXPO come in tutti quelli che seguiamo, il lavoro di integrazione è parte del progetto, non un’attività tecnica secondaria.
Senza questo passaggio, un futuro agente opererebbe su dati frammentati e processi fragili.
uBroker e Ubi, un esempio di Agente AI in produzione e operativo
Il terzo caso cambia prospettiva. Ubi non è una roadmap né un ambiente di prova: è l’agente conversazionale di uBroker entrato in produzione il 15 aprile 2025. Opera nel customer service su canali reali e viene valutato con KPI a regime.
La storia non finisce con il rilascio. Il passaggio in produzione ha esposto anche le imperfezioni di una piattaforma agentica enterprise ancora in maturazione, richiedendo un presidio congiunto di Gunpowder e Salesforce. È qui che si vede la distanza fra una demo efficace e un sistema destinato a lavorare ogni giorno.
L’architettura e la conoscenza
Ubi è costruito su Salesforce Agentforce con Atlas Reasoning Engine e Trust Layer. Questi componenti definiscono l’impianto tecnologico del progetto e operano insieme alla knowledge base usata nel perimetro assegnato.
La base di conoscenza comprende oltre 500 FAQ, curate da un Knowledge Manager dedicato. Il numero, da solo, non misura la qualità delle risposte. Dice però qualcosa sull’organizzazione necessaria: le fonti sono un asset fondamentale per gli Agenti AI e devono essere selezionate, aggiornate e mantenute da una persona che ne assume il presidio.
Un agente in produzione non vive di una knowledge base caricata una volta e dimenticata. Cambiano le domande, emergono casi non previsti, alcune informazioni diventano obsolete. La knowledge governance entra quindi nel funzionamento ordinario del servizio.
Perché Ubi è agentico e non soltanto un chatbot
Un chatbot tradizionale associa una domanda a una risposta o a un percorso configurato in anticipo. Ubi, invece, deve stabilire come gestire richieste in linguaggio naturale che non seguono un copione fisso.
Nel caso di Ubi c’è invece una catena composta da più passaggi. La richiesta proveniente da sito, WhatsApp o app viene interpretata da Atlas Reasoning Engine, che agisce come motore decisionale. Ubi consulta quindi la knowledge base e le regole di escalation, utilizza il contesto disponibile in Service Cloud e nel CRM e applica i controlli del Trust Layer. In base alla richiesta e alle informazioni disponibili, il sistema può produrre una risposta oppure effettuare un handover contestualizzato a un operatore.
A rendere Ubi agentico è la capacità di determinare questo percorso in funzione dell’intento e del contesto, anziché eseguire una sequenza di risposte interamente stabilita a monte. Le risposte non sono predefinite e alcuni comportamenti emergono soltanto davanti a richieste reali e imprevedibili.
Non si tratta, almeno per ora, di un sistema multi-agent, ma di un singolo agente che orchestra componenti, conoscenza, contesto e regole di escalation. La bounded autonomy ne stabilisce il confine, indicando quali richieste può gestire e quando deve passare la conversazione a una persona, ma dentro questo perimetro decide autonomamente come gestire le richieste ed è quindi agentico.
Canali, identità ed escalation
Ubi opera su WhatsApp, nella chat del sito e nella chat dell’app clienti. La roadmap prevede in fase 2 alcune azioni dispositive, come l’invio autenticato delle bollette, la lettura OCR delle contabili di pagamento e la raccolta delle autoletture, fino anche a un voicebot integrato con l’IVR telefonico come fase successiva.
L’approccio è Human-First. Ubi dichiara la propria identità e offre subito la possibilità di passare a un operatore. L’escalation non rappresenta un fallimento dell’agente: delimita l’autonomia e protegge l’utente quando la richiesta esce dal perimetro o richiede l’intervento di una persona, mantenendo la sua esperienza positiva al centro.
Questa scelta evita anche un equivoco frequente nel customer service, che sta dando una pessima nomea ai chatbot in generale. Il sistema non deve simulare un essere umano o nascondere la tecnologia: deve risolvere le richieste che può gestire in modo affidabile e consegnare le altre al team con un confine comprensibile e rapido, così da evitare qualsiasi tipo di frustrazione.
Il go-live e il test contro la prova della realtà
Il go-live del 15 aprile 2025 ha aperto la fase più istruttiva: quella in cui conversazioni, eccezioni e comportamenti reali mettono alla prova le ipotesi fatte in progettazione.
Il periodo successivo al rilascio ha fatto emergere, come in ogni progetto, varie problematiche legate alle imperfezioni della piattaforma. Gunpowder ha mantenuto il presidio lavorando con Salesforce durante la stabilizzazione, consapevole che il go-live non è altro che un’ennesima (e anzi la più importante) fase di test.
Questo ci permette di sottolineare un altro punto fondamentale per gli esempi di agenti AI. Il post go-live non può essere trattato come semplice assistenza accessoria. Serve a osservare dove l’agente funziona, dove deve passare la mano, quali contenuti mancano e quali comportamenti richiedono correzione. È lavoro di prodotto, knowledge management e governo operativo.
I KPI a regime
Nel 2026 Ubi ha fatto registrare un deflection rate del 25% in orario lavorativo. La metrica indica la quota di richieste gestite senza il passaggio a un operatore nel periodo osservato. A questo dato si affianca il vantaggio della copertura H24/7, cioè la disponibilità del canale anche quando il servizio umano non è operativo.
Il progetto è stato inoltre candidato agli Utility Day 2025 nella categoria Best AI Application and Automation Project.
Cosa insegnano insieme i tre esempi di agenti AI
Regione Abruzzo, AXPO e uBroker non formano una classifica. Mostrano tre condizioni diverse che un’organizzazione incontra quando passa dall’intenzione alla realtà operativa.
Lo status conta quanto la tecnologia. Un pilot verifica un’ipotesi; una roadmap descrive ciò che si vuole costruire; la produzione espone il sistema a casi reali e responsabilità continuative. Usare la stessa etichetta per tutti e tre impedisce di capire che cosa sia già stato dimostrato.
L’architettura segue il vincolo dominante. Per Regione Abruzzo il nodo è la sovranità su dati, modelli e fonti normative. Per LEVI è l’integrazione fra sistemi e partner del recupero crediti. Per Ubi sono centrali piattaforma agentica, knowledge governance, canali ed escalation. Non esiste uno stack astrattamente migliore, separato dal contesto.
Il lavoro di consulenza di un partner come Gunpowder deve saper fare proprio questo.
Le persone restano dentro il sistema. Gli uffici regionali validano il perimetro del pilot; il personale AXPO si sposta dai passaggi manuali alla gestione delle attività che richiedono attenzione; il Knowledge Manager e gli operatori in escalation presidiano Ubi. L’autonomia utile è delimitata e governata, a supporto dell’umano e mai in sostituzione.
I tre gradini non prescrivono che ogni progetto debba replicare lo stesso percorso. Offrono però un controllo semplice: prima di discutere di agenti, serve capire se dati, integrazioni e responsabilità operative sono pronti a sostenerli.
Il White Paper Gunpowder “Dall’agent-washing all’Agentic Enterprise” sviluppa la scala completa, presenta i casi in versione estesa e propone una matrice per orientare la scelta architetturale. È pensato per valutare il punto di partenza prima di trasformare l’agentico in una voce di roadmap.
Domande frequenti sugli esempi di agenti AI
Quali sono esempi di agenti AI in Italia?
RA-Copilot supporta i funzionari della Regione Abruzzo nella pre-istruttoria delle pratiche amministrative: analizza i documenti allegati, identifica il dominio della pratica, seleziona le fonti normative pertinenti e prepara un output con criticità, verifiche e riferimenti utili alla valutazione. LEVI centralizza il recupero crediti di AXPO, collegando SAP, PITECO, collector e studi legali in un unico processo nel quale consultare e aggiornare lo stato delle pratiche. Ubi gestisce le richieste del customer service di uBroker su WhatsApp, sito e app: interpreta l’intento, consulta knowledge base e CRM, decide come rispondere e passa la conversazione a un operatore quando necessario.
Qual è la differenza tra un pilot e un agente AI in produzione?
Un pilot verifica un’ipotesi su un perimetro controllato e serve a raccogliere evidenze prima dell’estensione. Un agente in produzione opera invece su processi e utenti reali, con responsabilità chiare, escalation, monitoraggio e metriche.
Cosa fa RA-Copilot, l’agente AI della Regione Abruzzo?
RA-Copilot è inserito in RASportello e supporta la pre-istruttoria di pratiche come l’istanza per il taglio degli alberi. Analizza documenti e contesto, identifica il dominio amministrativo e determina dinamicamente quale corpus normativo interrogare, costruendo una sequenza adattiva fino all’output istruttorio. La decisione finale resta al funzionario.
LEVI di AXPO è un agente AI?
No, non ancora. LEVI è un’automazione intelligente basata su Salesforce Communities che integra SAP ERP, SAP IS-U, PITECO e i partner esterni del recupero crediti. Il workflow è flessibile e riconfigurabile, ma il cuore decisionale resta nel processo definito a monte. In roadmap sono previsti un’interfaccia conversazionale e algoritmi predittivi per aggiungere capacità di assistenza e suggerimento, step essenziali per validare quello che può diventare un processo agentico.
Perché Ubi di uBroker è un agente AI e non un chatbot?
Un chatbot tradizionale associa una domanda a una risposta o a un percorso configurato in anticipo. Ubi, invece, usa Atlas Reasoning Engine per interpretare richieste non predefinite e determinare il percorso da seguire in funzione dell’intento e del contesto. Consulta la knowledge base e le regole di escalation, utilizza le informazioni disponibili in Service Cloud e nel CRM e applica i controlli del Trust Layer; al termine può produrre una risposta oppure effettuare un handover contestualizzato a un operatore. Non è ancora un sistema multi-agent, ma un singolo agente che orchestra autonomamente questi componenti entro i confini della bounded autonomy. È in produzione dal 15 aprile 2025 e nel 2026 registra un deflection rate del 25% in orario lavorativo, con copertura H24/7.
Quali KPI si usano per valutare un agente AI?
Il KPI dipende dal processo e deve essere letto insieme allo status del progetto. Fra gli esempi esaminati troviamo il tempo di controllo documentale, stimato a regime per Reg4AI, il deflection rate misurato per Ubi e la copertura temporale del servizio. Prima di confrontare due numeri bisogna capire se siano stime, obiettivi o risultati osservati dopo la stabilizzazione.