Un responsabile acquisti chiede perché una consegna critica è in ritardo. La risposta utile non è un riassunto di email e PDF: deve verificare l’ordine nell’ERP, leggere le comunicazioni del fornitore, confrontare le date di magazzino e proporre l’azione prevista dalla procedura. È qui che un sistema di agentic RAG cambia natura: dall’AI che trova informazioni all’AI che usa informazioni autorizzate per avanzare un processo.
Il RAG tradizionale ha già risolto un problema concreto: permette a un modello linguistico di rispondere basandosi sulla conoscenza aziendale, anziché solo sulla propria conoscenza generica. Ma molte aziende non hanno bisogno soltanto di interrogare una knowledge base. Devono coordinare dati frammentati, applicare regole, utilizzare software e lasciare una traccia verificabile di ciò che è accaduto.
L’agentic RAG è l’architettura che rende possibile questo passaggio. Non è un chatbot con qualche integrazione aggiunta. È un sistema composto da retrieval, ragionamento controllato, strumenti software, policy di autorizzazione e supervisione umana. AI che agisce, non soltanto risponde.
Cos’è l’agentic RAG
Con Retrieval-Augmented Generation, o RAG, il sistema recupera documenti o record rilevanti e li passa al modello linguistico per generare una risposta fondata su fonti specifiche. Un RAG ben progettato può citare procedure, manuali, contratti, listini, ticket e documentazione tecnica, riducendo il rischio di risposte inventate.
L’agentic RAG aggiunge la capacità di pianificare una sequenza di attività e scegliere, entro confini definiti, quale strumento usare. L’agente può decidere che una domanda richiede prima una ricerca semantica nei documenti, poi una query su un database, quindi la verifica dello stato nel CRM o nell’ERP. Se le regole lo consentono, può preparare una bozza di risposta, aprire un ticket, aggiornare un campo o inviare una richiesta di approvazione.
La differenza non sta nel rendere il modello “libero” di fare qualunque cosa. Al contrario, un progetto serio restringe l’autonomia alle azioni utili, sicure e misurabili. L’agente lavora con strumenti espliciti, parametri validati, identità applicative, ruoli e soglie di approvazione. Ogni azione deve essere attribuibile, ripetibile e reversibile quando necessario.
Perché il RAG tradizionale non basta sempre
Un RAG documentale è spesso il punto di partenza corretto. Per una rete commerciale che deve trovare velocemente specifiche di prodotto o per un ufficio HR che consulta policy interne, una ricerca conversazionale con fonti può offrire valore immediato. Forzare una componente agentica in questi casi aumenta complessità, costi di gestione e superficie di rischio senza produrre un vantaggio proporzionato.
Il limite emerge quando la risposta richiede dati dinamici o deve produrre un effetto operativo. Un documento può spiegare come gestire un reso, ma non sa se quella specifica pratica è già stata aperta, se l’articolo è ancora in garanzia o quale vettore è stato assegnato. Queste informazioni vivono in sistemi diversi e cambiano continuamente.
L’agentic RAG è utile quando il processo impone verifiche sequenziali, eccezioni e decisioni basate sul contesto. Pensiamo a un copilot per il customer service B2B: legge lo storico del cliente, recupera le condizioni contrattuali, controlla disponibilità e spedizioni, riconosce un’anomalia e prepara una proposta coerente con le deleghe commerciali. Il risultato non è soltanto più rapido. È più vicino al modo in cui lavora un operatore esperto.
L’architettura che trasforma una demo in un sistema
La qualità di un agentic RAG dipende molto meno dal prompt iniziale di quanto si pensi. La parte decisiva è l’architettura attorno al modello linguistico. Documenti, database e applicazioni devono diventare fonti consultabili con permessi coerenti, metadati affidabili e aggiornamenti governati.
Dati preparati per essere interrogati
Il retrieval non consiste nel caricare indiscriminatamente file in un archivio vettoriale. Prima servono classificazione, normalizzazione, deduplicazione e segmentazione dei contenuti. Un contratto, una distinta base o una procedura di sicurezza richiedono strategie di indicizzazione diverse, perché la loro struttura e il loro utilizzo sono differenti.
Anche i metadati contano. Versione del documento, business unit, lingua, validità, livello di riservatezza, cliente o impianto di riferimento permettono di recuperare il contenuto corretto e applicare filtri di accesso. Senza questa disciplina, l’AI può trovare una risposta plausibile ma obsoleta, non pertinente o non autorizzata.
Strumenti con contratti chiari
Un agente non dovrebbe accedere direttamente a un gestionale attraverso istruzioni in linguaggio naturale. Deve usare tool definiti: per esempio, “verifica stato ordine”, “crea richiesta di assistenza”, “recupera anagrafica cliente”. Ogni tool espone funzioni limitate, parametri validati e risposte strutturate.
Questo approccio evita che il modello trasformi una richiesta ambigua in un’operazione irreversibile. Se un utente chiede di modificare una condizione commerciale, l’agente può raccogliere i dati, controllare le autorizzazioni e generare una proposta. L’esecuzione effettiva può restare subordinata a un’approvazione, oppure essere consentita solo entro soglie predefinite.
Orchestrazione e controllo
Un processo reale non segue sempre una linea retta. Può mancare un dato, una fonte può essere in conflitto con un’altra, oppure una policy può richiedere l’intervento di una persona. L’orchestratore gestisce questi passaggi: definisce quali agenti o componenti intervengono, quando fermarsi, come gestire gli errori e quando chiedere chiarimenti.
Qui entra in gioco il principio human-in-the-loop. Non tutte le attività meritano lo stesso livello di autonomia. La classificazione di una richiesta ripetitiva può essere automatizzata; l’approvazione di uno sconto rilevante o la modifica di dati contabili richiede normalmente una verifica umana. Progettare bene questi confini è una scelta di processo, non un dettaglio tecnico.
Casi d’uso dove l’agentic RAG crea valore misurabile
Nella manifattura, un agente può assistere manutentori e tecnici collegando manuali, schemi, storico guasti, ticket e dati macchina. Non si limita a suggerire una procedura: può verificare i ricambi disponibili, controllare gli interventi passati e predisporre una richiesta di approvvigionamento quando la policy lo prevede.
In logistica, il sistema può analizzare eccezioni di consegna combinando ordini, tracking, email e SLA contrattuali. Può classificare il problema, identificare il reparto responsabile, proporre al cliente una comunicazione basata sui dati disponibili e aprire il workflow di gestione dell’anomalia.
Per studi professionali, assicurazioni e aziende con processi documentali intensi, l’agente può leggere pratiche, verificare requisiti, individuare documenti mancanti e preparare istruttorie. La decisione finale resta in mano al professionista, ma il tempo speso a cercare, ricopiare e ricontrollare informazioni si riduce in modo significativo.
Il valore va misurato su indicatori concreti: tempo medio di gestione, percentuale di pratiche completate senza rilavorazioni, accuratezza del retrieval, tasso di escalation umana, qualità delle risposte e rispetto degli SLA. Un sistema che produce conversazioni convincenti ma non migliora questi parametri resta una demo.
Sicurezza, affidabilità e responsabilità
Più un agente può fare, più il controllo diventa parte integrante del prodotto. La sicurezza non è un livello aggiunto a fine progetto. Deve essere incorporata nella gestione delle identità, nei permessi sulle fonti, nella separazione tra ambienti, nei log e nelle regole di esecuzione.
Un’architettura enterprise deve impedire che un utente ottenga tramite l’AI dati che non potrebbe consultare nei sistemi originali. Deve inoltre difendersi dalle istruzioni malevole contenute nei documenti, dalle richieste ambigue e dalle azioni duplicate in caso di errore o timeout. Per le attività sensibili servono conferme esplicite, limiti di spesa o di modifica, audit trail e meccanismi di rollback.
C’è poi il tema della qualità. Il modello può interpretare male una richiesta anche quando il retrieval è corretto. Per questo è necessario valutare il sistema con casi realistici, dataset di test, scenari limite e controlli continui in produzione. La qualità non è un obiettivo, ma uno standard operativo da monitorare.
Come partire senza costruire un progetto eccessivo
Il primo passo non è scegliere un modello linguistico. È individuare un processo con un volume sufficiente di richieste, fonti dati disponibili e un costo operativo misurabile. Un buon candidato combina ricerca di informazioni, passaggi ripetitivi e regole già esistenti, senza coinvolgere da subito decisioni ad alto rischio.
Conviene poi delimitare un perimetro: una funzione aziendale, pochi strumenti integrati, un set chiaro di azioni consentite e criteri di successo concordati. Prima si costruisce un retrieval affidabile; solo dopo si aggiungono capacità agentiche dove producono un vantaggio reale. L’autonomia cresce insieme alla qualità dei dati, alla maturità delle integrazioni e alla fiducia guadagnata sul campo.
PurpleSoft progetta questi sistemi come infrastrutture operative: software, dati e intelligenza artificiale in un’unica architettura, con integrazioni, controlli e monitoraggio pensati per la produzione. Il punto non è mettere un agente davanti ai sistemi esistenti. È farlo lavorare dentro i processi, rispettando le regole che rendono l’azienda affidabile.
La domanda utile da porre al prossimo progetto AI non è “quale chatbot possiamo lanciare?”. È: quale decisione o attività oggi rallentata da dati dispersi può essere svolta meglio da un agente controllato, con una persona pronta a intervenire quando conta davvero?
