Quando si valuta una soluzione di AI enterprise, la prima domanda tende a essere sempre la stessa: quanto risponde bene? È una domanda naturale, perché nei primi test l’attenzione va alla qualità della risposta, alla velocità con cui il sistema recupera le informazioni, alla pertinenza delle fonti e alla naturalezza con cui riesce a interagire con l’utente. Tuttavia, quando un progetto esce dalla fase di sperimentazione e inizia ad avvicinarsi ai processi reali, la domanda più rilevante cambia: non basta più chiedersi se il sistema sappia rispondere, bisogna chiedersi quando dovrebbe scegliere di non farlo.
È un passaggio meno immediato, ma fondamentale, soprattutto nei progetti basati su RAG, dove l’AI non risponde solo grazie alle capacità del modello, ma utilizza documenti, procedure, policy, knowledge base e repository aziendali per costruire una risposta aderente al contesto dell’organizzazione. In una demo, una buona risposta è spesso sufficiente per generare interesse; in produzione, invece, una risposta può orientare un’attività operativa, influenzare una decisione, supportare una richiesta cliente o suggerire un comportamento a una persona che si fida del sistema.
È proprio qui che si vede se una soluzione è governabile. Un RAG enterprise non dovrebbe essere progettato per rispondere sempre, ma per rispondere quando esistono condizioni sufficienti di affidabilità, tracciabilità e controllo.
Nei progetti in cui lavoriamo su soluzioni di AI e RAG enterprise, questo punto emerge molto presto, spesso già nei primi workshop con IT, business owner e funzioni di controllo. All’inizio si parla di architettura, integrazione con i repository, qualità del retrieval, scelta del modello e modalità di esposizione delle fonti; poi, quando si analizzano i casi d’uso reali, la conversazione si sposta quasi sempre su domande più profonde: quali fonti sono davvero autorevoli? Quali documenti possono supportare una risposta operativa? Cosa deve accadere se due fonti sono in conflitto? Quando il sistema può sintetizzare un’indicazione e quando, invece, deve fermarsi e coinvolgere una persona?
Questo accade perché, prima ancora della risposta, esiste una strategia di ricerca. Un RAG tradizionale segue una logica abbastanza lineare: riceve una domanda, recupera i contenuti più pertinenti, li passa al modello e genera una risposta. È un approccio utile, ma non sempre sufficiente in un contesto enterprise, dove molte domande non richiedono semplicemente di trovare un documento, ma di capire quali fonti interrogare, in quale ordine, con quale livello di priorità e con quali criteri di verifica.
Nei sistemi più evoluti, soprattutto quando si lavora su approcci di Agentic RAG, il processo assomiglia di più al modo in cui ragionerebbe una persona esperta. Prima di rispondere, il sistema può riformulare la domanda se è ambigua, indirizzare la ricerca verso repository diversi, confrontare più fonti, verificare se esistono versioni più recenti, controllare eventuali incoerenze e solo alla fine decidere se dispone davvero di elementi sufficienti per produrre una risposta. In altre parole, la domanda non è solo se il sistema abbia trovato qualcosa, ma se abbia fatto abbastanza verifiche prima di rispondere.
Pensiamo a un caso concreto. Un team commerciale chiede al sistema se sia possibile applicare una deroga contrattuale a un cliente strategico. Il RAG recupera una policy commerciale, una linea guida interna e alcuni documenti relativi a casi simili gestiti in passato. A prima vista, sembra tutto corretto: le fonti parlano dello stesso tema, contengono informazioni pertinenti e possono aiutare a costruire una risposta plausibile. Ma chi ha responsabilità su un sistema enterprise sa che la pertinenza non basta.
Quelle fonti sono ancora valide? Hanno valore autorizzativo o sono solo materiali di supporto? La policy recuperata è l’ultima versione approvata? I casi passati sono davvero comparabili o appartengono a contesti commerciali, geografici o normativi differenti? Il sistema sta rispondendo su una regola generale o sta entrando in un’area in cui serve una valutazione umana?
Sono domande che non possono restare implicite, perché se il sistema produce comunque una risposta convincente, il rischio non è solo informativo, ma operativo. Può generare un’azione non conforme, creare aspettative verso il cliente, introdurre incoerenze di processo o trasferire sull’utente una responsabilità che il sistema non era autorizzato ad assumere. In casi come questo, la risposta più matura non è necessariamente una sintesi ben formulata, ma una presa di posizione chiara: le fonti disponibili non sono sufficienti per fornire un’indicazione affidabile e la richiesta deve essere indirizzata al responsabile commerciale, alla funzione legale o all’owner del processo.
Questa non è una debolezza del sistema, ma una caratteristica di governance.
Ed è qui che alcuni dettagli tecnici diventano importanti, non perché siano tecnicismi da aggiungere al progetto, ma perché determinano il comportamento reale della soluzione. Se la query iniziale è troppo generica, può servire un meccanismo di query rewriting per distinguere tra deroga commerciale, deroga legale e deroga pricing; se le fonti recuperate non arrivano dal repository corretto, può essere necessario un routing verso documentazione Legal, Compliance o Finance; se i documenti più rilevanti non sono coerenti tra loro, il sistema deve essere in grado di riconoscere il conflitto tra una policy globale e una procedura locale, e se il livello di confidenza non è sufficiente, può essere più corretto mostrare le fonti e attivare un’escalation, invece di generare una risposta operativa.
Dal punto di vista di un CIO, queste scelte non riguardano solo l’architettura, ma il controllo. Progettare un RAG enterprise significa infatti definire non solo cosa il sistema può sapere, ma anche cosa può fare con ciò che sa. Può limitarsi a mostrare le fonti? Può sintetizzarle? Può suggerire un’azione? Può raccomandare un percorso operativo? E in quali casi deve invece fermarsi, dichiarare incertezza o coinvolgere una persona?
Questo richiede una progettazione che va oltre il solo layer tecnologico. Serve classificare le fonti, distinguere tra contenuti ufficiali e contenuti informativi, gestire versioni e permessi, definire ownership, tracciare le risposte, monitorare gli errori, raccogliere feedback dagli utenti e stabilire meccanismi di escalation quando il livello di confidenza non è sufficiente. Serve anche decidere, prima che il sistema venga usato, che cosa significhi “abbastanza affidabile”: quante fonti autorevoli devono supportare una risposta, cosa accade se due fonti sono in conflitto, se il sistema deve privilegiare la fonte più recente, quella con maggiore valore autorizzativo o quella più vicina al contesto dell’utente, e sotto quale soglia di confidenza è obbligatorio fermarsi.
Il punto, quindi, è evitare che il sistema produca risposte apparentemente corrette, ma costruite su informazioni incomplete, superate, non autorizzate o interpretate fuori contesto. Perché nel mondo enterprise l’errore più pericoloso non è sempre la risposta palesemente sbagliata, spesso è la risposta quasi giusta, coerente nella forma e utile in apparenza, ma non abbastanza solida da poter sostenere un processo reale.
Per questo motivo, uno degli aspetti più importanti in un progetto RAG è la progettazione dei casi di non risposta. Quando il sistema deve dichiarare incertezza? Quando deve mostrare le fonti senza formulare una raccomandazione? Quando deve chiedere una validazione umana? Quando deve indirizzare l’utente verso un owner di processo? Quando una risposta è abbastanza supportata da poter essere utilizzata e quando, invece, è solo un punto di partenza per ulteriori verifiche?
Un buon RAG non si misura solo dalle risposte che produce. Si misura dalle verifiche che compie prima di rispondere e anche dalle domande a cui sceglie, responsabilmente, di non rispondere.
