Quali dati usare nel RAG aziendale sicuro

Un sistema RAG può usare il modello linguistico migliore disponibile e continuare a fornire risposte sbagliate. Il motivo è quasi sempre a monte: scegliere quali dati usare nel RAG non significa riversare ogni file aziendale in un indice vettoriale. Significa progettare una base di conoscenza governata, aggiornata, autorizzata e coerente con le decisioni o le attività che l’AI deve supportare.

Per un’azienda, il valore non nasce dal numero di documenti indicizzati. Nasce dalla capacità di recuperare l’informazione corretta, nel momento corretto, per la persona corretta, mostrando la fonte e rispettando i confini di accesso. Un RAG enterprise non è un archivio che parla: è un livello operativo tra dati, processi e persone.

Quali dati usare nel RAG: partire dai casi d’uso

La domanda giusta non è “quanti dati abbiamo?”, ma “quale risposta o azione deve rendere possibile il sistema?”. Un copilota per il customer service richiede fonti diverse da un assistente per l’ufficio tecnico o da un agente che prepara offerte commerciali.

Se l’obiettivo è assistere un tecnico sul campo, la priorità va a manuali aggiornati, distinte base, procedure di manutenzione, bollettini tecnici, schede prodotto e ticket risolti verificati. Se il RAG deve aiutare l’area acquisti, diventano centrali condizioni contrattuali, listini approvati, anagrafiche fornitori, ordini, policy e dati ERP. Per la funzione commerciale, CRM, cataloghi, configuratori, offerte, documentazione di prodotto e storico delle opportunità possono essere più utili di migliaia di PDF generici.

Questo approccio evita un errore frequente: creare una knowledge base ampia ma indistinta, nella quale contenuti superati, documenti preliminari e procedure ufficiali competono sullo stesso piano. In produzione, l’AI non deve conoscere tutto. Deve conoscere ciò che è pertinente, affidabile e consentito per il compito assegnato.

Le fonti più utili non sono tutte dello stesso tipo

Una knowledge base efficace combina dati documentali e dati strutturati, ma li tratta in modo differente. I documenti spiegano contesto, eccezioni e regole. I sistemi gestionali registrano uno stato operativo: disponibilità, prezzo, avanzamento di un ordine, scadenze, anagrafiche, plafond, livelli di servizio.

Manuali, procedure, contratti, capitolati, FAQ validate, policy interne, report tecnici e documenti di qualità sono candidati naturali per il retrieval. Possono essere estratti, classificati, suddivisi in sezioni significative e ricercati semanticamente.

ERP, CRM, database di produzione, WMS, ticketing e applicazioni proprietarie richiedono invece spesso un’integrazione controllata. Una risposta come “qual è la disponibilità del componente X?” non dovrebbe dipendere da un export caricato sei mesi prima. Deve interrogare il sistema sorgente, o una replica dati governata, con filtri, permessi e controlli adeguati.

Qui emerge una distinzione decisiva: il RAG recupera conoscenza contestuale, mentre gli strumenti collegati ai sistemi aziendali recuperano o aggiornano dati transazionali in tempo reale. Confondere i due livelli crea risposte obsolete e rischi operativi. Un agente AI maturo può usare entrambi: cerca la procedura corretta nella knowledge base e verifica lo stato corrente nell’ERP prima di proporre un’azione.

Qualità, autorità e aggiornamento: il filtro prima dell’indicizzazione

Un file accessibile non è automaticamente un file idoneo. Prima di entrare nella base RAG, ogni fonte va valutata almeno su quattro dimensioni: autorevolezza, aggiornamento, completezza e destinazione d’uso.

Un documento approvato dal responsabile qualità ha un peso diverso rispetto a una bozza salvata in una cartella personale. Una procedura revocata non deve apparire come alternativa plausibile a quella vigente. Un listino privo di validità temporale può generare offerte errate. Le email sono un caso tipico: contengono conoscenza preziosa, ma anche istruzioni estemporanee, discussioni incomplete e informazioni riservate. Vanno selezionate e classificate, non importate in massa.

Per molte aziende è utile definire una gerarchia delle fonti. Le procedure ufficiali e i dati di sistema prevalgono su FAQ e materiali informativi. Le versioni approvate prevalgono sulle bozze. Il contenuto più recente prevale su quello storico, salvo casi in cui sia necessario ricostruire una regola valida in un periodo preciso.

Questa gerarchia deve tradursi nell’architettura, non restare una raccomandazione teorica. Il motore di retrieval può usare punteggi di qualità, date di efficacia, stato documentale e priorità della fonte. L’AI deve poter dire quando non trova una fonte sufficiente, invece di completare i vuoti con un’affermazione plausibile ma non verificata.

I metadati rendono i documenti utilizzabili dall’AI

Senza metadati, un RAG cerca frasi. Con i metadati, cerca informazione nel suo contesto aziendale. A ogni documento o sezione dovrebbero essere associati elementi come funzione aziendale, prodotto o linea, cliente o mercato, lingua, versione, autore, proprietario del contenuto, data di validità, livello di riservatezza e stato di approvazione.

Queste informazioni migliorano la pertinenza delle risposte e consentono filtri essenziali. Un commerciale può dover consultare un catalogo destinato alla propria area geografica; un tecnico può accedere alle procedure della linea su cui è abilitato; un responsabile amministrativo non deve vedere documenti HR solo perché una ricerca semantica li considera simili.

I metadati aiutano anche la manutenzione. Se una procedura viene aggiornata, il sistema deve sapere quali contenuti sostituire, quali versioni archiviare e quali risposte potrebbero essere impattate. La knowledge base è un sistema vivo, non un progetto da chiudere dopo il primo caricamento.

Dati sensibili e permessi: il retrieval deve rispettare l’organizzazione

Uno dei rischi più sottovalutati è costruire una ricerca intelligente che aggira le autorizzazioni già presenti nei sistemi aziendali. Se un utente non può aprire un file in SharePoint, nel documentale o nel file server, non dovrebbe riceverne il contenuto tramite un assistente AI.

La sicurezza va applicata prima della generazione della risposta. Questo significa propagare identità, ruoli, gruppi, entità organizzative e criteri di visibilità nel livello di retrieval. Il sistema recupera solo i contenuti che l’utente è autorizzato a consultare, quindi il modello lavora su un contesto già filtrato.

Serve inoltre distinguere le informazioni da indicizzare da quelle da escludere o mascherare. Credenziali, segreti industriali non necessari al caso d’uso, dati sanitari, coordinate bancarie, documenti disciplinari e dati personali eccedenti richiedono regole specifiche. Talvolta la scelta corretta non è anonimizzare un intero patrimonio informativo, ma non renderlo disponibile al RAG.

Tracciabilità e audit completano il controllo: quali fonti sono state consultate, quali passaggi ha eseguito l’agente, quale risposta è stata proposta e, se prevista, quale azione è stata avviata. Per un sistema che entra nei processi reali, queste evidenze non sono un dettaglio tecnico.

Preparare bene i contenuti cambia la qualità delle risposte

Un PDF ben leggibile per una persona può essere pessimo per un sistema RAG. Tabelle spezzate, scansioni senza OCR, intestazioni ripetute, allegati duplicati e titoli ambigui degradano il retrieval. Prima dell’indicizzazione serve data engineering: estrazione del testo, OCR dove necessario, rimozione dei duplicati, normalizzazione dei campi, riconoscimento delle sezioni e gestione delle versioni.

Anche la suddivisione in chunk richiede attenzione. Segmenti troppo piccoli perdono il contesto; segmenti troppo grandi introducono rumore e consumano spazio utile nella richiesta al modello. Non esiste una dimensione universale. Un capitolato, un manuale tecnico e una procedura a passaggi richiedono logiche diverse, spesso basate sulla struttura del documento e non solo su un conteggio di caratteri.

Le tabelle meritano un trattamento dedicato. In ambito industriale, commerciale e finanziario contengono spesso il dato più rilevante: codici, compatibilità, soglie, prezzi, tempi e parametri. Se vengono trasformate in testo disordinato, l’AI può interpretarle male. Quando possibile, è preferibile conservarne la struttura o interrogare direttamente il database sorgente.

Come decidere quali dati escludere

Un buon progetto RAG definisce esplicitamente anche cosa non deve entrare nella knowledge base. I contenuti obsoleti senza valore storico, le bozze non approvate, i duplicati, gli appunti personali, i file privi di proprietario e le fonti con qualità non verificabile aumentano il rumore senza aumentare la conoscenza.

Vanno trattati con cautela anche i documenti che esprimono opinioni o istruzioni contingenti. Uno scambio email può essere utile per individuare un precedente, ma non dovrebbe trasformarsi automaticamente in policy aziendale. Per gli stessi motivi, ticket e conversazioni di assistenza vanno ammessi quando sono stati chiusi, verificati e classificati come casi riutilizzabili.

L’esclusione non è una perdita. È un controllo di qualità. Una base più piccola, curata e ben governata supera quasi sempre un archivio enorme privo di regole.

Misurare se i dati scelti funzionano davvero

La qualità del RAG non si valuta con una demo di cinque domande fortunate. Occorre costruire un set di domande reali, raccolte dalle funzioni coinvolte, includendo richieste semplici, ambigue, multi-documento e casi in cui il sistema deve rispondere “non disponibile”.

Le metriche utili non riguardano soltanto la fluidità del linguaggio. Bisogna verificare se il sistema recupera la fonte giusta, se la risposta è supportata dal contesto, se rispetta i permessi, se usa informazioni aggiornate e se riduce realmente tempi, errori o passaggi manuali. Quando il RAG alimenta un agente che agisce, la valutazione deve includere anche correttezza delle decisioni, rispetto delle regole di business e necessità di approvazione umana.

È utile assegnare un proprietario a ogni dominio informativo. L’IT governa integrazioni, sicurezza e osservabilità; le funzioni business validano contenuti, eccezioni e aggiornamenti. Senza questa responsabilità condivisa, la knowledge base tende a degradarsi nel tempo.

PurpleSoft progetta questi sistemi come architetture integrate: software, dati e intelligenza artificiale in un’unica struttura controllabile. Perché l’obiettivo non è far rispondere un chatbot a un documento, ma costruire AI che agisce, non soltanto risponde.

La scelta dei dati per il RAG diventa quindi una scelta di processo: definire quale conoscenza merita fiducia, chi la governa e in quali condizioni può guidare una persona o un sistema. È da qui che un prototipo smette di essere una demo e inizia a diventare infrastruttura operativa.