Quando si parla di RAG in azienda, una delle prime ambizioni è spesso questa: rendere interrogabili documenti, procedure, manuali, knowledge base e repository interni.

È un obiettivo comprensibile. Le organizzazioni hanno accumulato negli anni un patrimonio informativo enorme, spesso difficile da navigare e poco accessibile nei momenti in cui servirebbe davvero.

Ma proprio qui nasce un equivoco. Il valore del RAG non sta nel portare più contenuti possibile dentro un sistema di AI generativa, ma sta nel decidere quali contenuti meritano di diventare parte di una risposta. Infatti non tutta la conoscenza aziendale ha lo stesso peso, non tutte le fonti hanno lo stesso livello di affidabilità. Non tutti i documenti sono adatti a supportare un processo operativo, una decisione o un’interazione con un utente.

In altre parole, il RAG non è solo una questione di accesso alla conoscenza, è una questione di responsabilità sulla conoscenza.

Rendere un documento interrogabile significa aumentare la sua capacità di incidere sui processi. Una procedura nascosta in una cartella, letta raramente da pochi specialisti, ha un impatto limitato. La stessa procedura, se diventa fonte per un sistema RAG utilizzato da molte persone, può influenzare decisioni, comportamenti e attività quotidiane.

Pensiamo, ad esempio, a un processo di assistenza tecnica interna. Un operatore chiede al sistema quale procedura seguire per gestire un’anomalia ricorrente su un impianto, un’applicazione o un servizio critico. Il sistema recupera tre documenti: una procedura ufficiale aggiornata, una guida operativa scritta da un team locale e una vecchia istruzione ancora presente nel repository perché mai formalmente rimossa.

Dal punto di vista tecnico, tutti e tre i documenti possono sembrare pertinenti, contengono parole simili, descrivono lo stesso problema e fanno riferimento allo stesso contesto operativo. Dal punto di vista aziendale, però, non hanno lo stesso valore.
La procedura ufficiale può essere l’unica autorizzata, la guida locale può contenere indicazioni pratiche utili, ma non sempre valide per tutti i Paesi o per tutte le unità operative, il documento obsoleto può riportare passaggi non più conformi alle policy attuali.

Se queste differenze non sono esplicitate, il sistema RAG potrebbe costruire una risposta formalmente plausibile, ma operativamente rischiosa. Non perché il modello “sbagli” in senso stretto, ma perché le fonti messe a sua disposizione non sono state qualificate in modo sufficiente.

È qui che si vede la differenza tra un progetto RAG sperimentale e un progetto RAG enterprise.

Nel primo caso, l’obiettivo è dimostrare che l’AI riesce a trovare e sintetizzare informazioni. Nel secondo, l’obiettivo è garantire che quelle informazioni siano corrette, autorizzate, aggiornate e coerenti con il contesto in cui verranno usate.

Questo cambia il modo in cui dovremmo guardare ai contenuti aziendali.

Non basta chiedersi: “Questo documento esiste?”
Bisogna chiedersi: “Questo documento può essere usato dall’AI per generare una risposta affidabile?”
E ancora: “Siamo disposti ad assumerci la responsabilità di quella risposta?”

È qui che il RAG introduce una forma nuova di selezione.

Non tutto deve entrare. 

Non tutto deve essere recuperato. 

Non tutto deve avere lo stesso livello di autorità.

Alcune fonti possono essere considerate ufficiali, altre possono servire come contesto. Altre ancora devono essere escluse, aggiornate o rese non interrogabili, almeno fino a quando non avranno un livello sufficiente di qualità e governance.

Questo passaggio è spesso sottovalutato, ma è cruciale.

Perché molte iniziative AI nascono con una logica di abilitazione: aprire l’accesso, velocizzare la ricerca, ridurre il tempo speso a cercare informazioni. Tutto corretto, ma in un contesto enterprise, abilitare significa anche definire confini. Confini tra ciò che è ufficiale e ciò che è informativo, tra ciò che può sostenere una decisione e ciò che può solo orientare una ricerca, tra ciò che è valido oggi e ciò che appartiene alla memoria storica dell’organizzazione.

Il RAG, quindi, non dovrebbe essere pensato come un grande connettore verso tutto il patrimonio documentale aziendale, dovrebbe essere progettato come un sistema di accesso controllato alla conoscenza rilevante.

E questo richiede scelte.

Scelte sulle fonti, sui permessi, sui ruoli, sui livelli di confidenza, sui processi di aggiornamento, sulle situazioni in cui l’AI può rispondere e su quelle in cui deve fermarsi, dichiarare incertezza o rimandare a una persona.

In questo senso, il RAG porta l’azienda davanti a una domanda più matura: non “quanto possiamo automatizzare?”, ma “a quali condizioni possiamo fidarci di ciò che automatizziamo?”.

Alla fine, il vero cambio di prospettiva è questo: il RAG non serve a dare all’AI accesso a tutto ciò che l’azienda sa. Serve a decidere, con metodo, quale parte della conoscenza aziendale è pronta per diventare operativa.