Il momento più pericoloso in un progetto RAG non è quando il modello sbaglia risposta. È quando risponde correttamente con un documento che l'utente non avrebbe mai dovuto vedere.
Un RAG aziendale non è una barra di ricerca più intelligente. È un sistema che porta la conoscenza interna dentro una conversazione. Se non rispetta permessi, reparti, riservatezza e audit log, trasforma l'AI in una scorciatoia per attraversare muri che l'azienda aveva costruito per un motivo.
Questa è la tesi: in un RAG aziendale serio, i permessi non si aggiungono alla fine. Devono entrare nell'indice, nel retrieval, nella generazione e nei log. Altrimenti il problema non è tecnico. È organizzativo, legale e reputazionale.
La demo facile: indicizzare tutto
La demo che vende bene è sempre la stessa: "carichiamo tutti i vostri PDF, poi chiedete quello che volete". Funziona. Fa impressione. Dopo dieci minuti qualcuno chiede una procedura dimenticata, il sistema la trova, tutti annuiscono.
Poi arriva la prima domanda scomoda.
Un commerciale chiede: "fammi vedere tutti i contratti con margine sotto il 20%". Un project manager chiede: "quali clienti sono in contenzioso?". Un neoassunto chiede: "qual è la RAL media dei senior developer?". Se il sistema risponde, il problema non è che l'AI è stata brava. Il problema è che l'azienda ha appena perso il controllo del proprio perimetro informativo.
Molte cartelle condivise aziendali vivono in un equilibrio fragile. I permessi non sono perfetti, ma esistono. HR ha una sua area. Legal ha i suoi fascicoli. Commerciale vede i contratti che gli servono. Operations vede procedure e ticket. La direzione vede quasi tutto. Un RAG che indicizza tutto in un unico calderone e poi risponde a chiunque rompe questo equilibrio in modo silenzioso.
Il retrieval è il punto in cui si vince o si perde
Il modo ingenuo di costruire un RAG è questo: prendi i documenti, li dividi in chunk, calcoli embedding, li metti in un vector database, poi a ogni domanda recuperi i chunk più simili e li passi al modello.
Questo schema è incompleto. Manca una domanda: simili per chi?
Perché un chunk può essere perfetto semanticamente e proibito organizzativamente. Se un documento HR parla di "policy bonus 2026", è semanticamente rilevante per una domanda sui bonus. Ma se chi chiede è un tecnico del service desk, quel chunk non deve entrare nella shortlist. Non deve arrivare al prompt. Non deve finire nei log di generazione. Non deve essere citato per sbaglio.
Il filtro deve avvenire prima del modello, non dopo. Nascondere la citazione a valle non basta: a quel punto il contenuto riservato è già stato usato per comporre la risposta.
Nel linguaggio dei sistemi documentali, questo si chiama spesso security trimming: il motore di ricerca restituisce solo i risultati che l'utente è autorizzato a vedere. In un RAG la stessa regola vale due volte, perché il risultato non è solo un elenco di file. È materia prima per generare testo nuovo.
Permessi per documento non bastano
Qui c'è un dettaglio che sembra da tecnici pedanti e invece cambia tutto. Un RAG non lavora quasi mai sul documento intero. Lavora su chunk: pezzi di testo da qualche centinaio di token, arricchiti con metadata.
Se i permessi restano solo a livello file, perdi precisione. Un manuale operativo può contenere sezioni pubbliche e appendici riservate. Un contratto può avere condizioni generali accessibili al team delivery e una pagina con sconti e marginalità accessibile solo al commerciale. Una policy interna può essere leggibile da tutti tranne una nota disciplinare allegata.
Il livello giusto è: ogni chunk deve portarsi dietro i metadata che servono a decidere chi può vederlo.
In pratica significa memorizzare almeno:
- documento sorgente;
- pagina o sezione;
- classificazione del contenuto;
- gruppo o ruolo autorizzato;
- origine del permesso;
- data dell'ultima sincronizzazione;
- proprietario documentale.
Senza questi dati, il retrieval diventa cieco. Può trovare bene, ma non può decidere bene.
I permessi cambiano, l'indice deve seguirli
Il secondo errore classico è trattare l'indice come una fotografia. A gennaio indicizzi SharePoint, NAS, wiki e CRM. A febbraio una persona cambia reparto. A marzo un fornitore perde l'accesso. Ad aprile un documento passa da "bozza interna" a "approvato per il cliente". Se l'indice non segue questi cambiamenti, il RAG diventa una memoria non autorizzata.
Questo è più comune di quanto sembri. Molti prototipi RAG fanno ingestion una volta, poi aggiornano solo i nuovi documenti. I permessi, invece, vengono considerati un fastidio esterno. Il risultato è un sistema che risponde su documenti che oggi l'utente non potrebbe più leggere, perché li aveva visti in una versione vecchia dell'indice.
Un RAG aziendale deve quindi sincronizzare due cose: contenuti e permessi.
La sincronizzazione dei contenuti dice: "questo file è cambiato". La sincronizzazione dei permessi dice: "questa persona non ha più diritto di usare questo chunk". Sono due eventi diversi, e il secondo è spesso più importante del primo.
Il problema dei gruppi "tutti"
Ogni azienda ha una cartella chiamata più o meno "Condivisa", "Generale", "Documenti aziendali", "All hands". Sulla carta è innocua. In pratica diventa il deposito di tutto quello che nessuno ha voglia di classificare.
Quando costruisci un RAG sopra quella cartella, scopri cose interessanti: listini vecchi, offerte perse, PDF firmati, report clienti, bozze di budget, export di CRM lasciati lì per comodità. Tecnicamente sono "accessibili a tutti". Organizzativamente non dovrebbero esserlo.
Qui il RAG fa emergere una verità scomoda: non crea sempre un problema di permessi; spesso rivela un problema di permessi che esisteva già. Prima era nascosto dalla fatica di cercare. Ora basta una domanda in linguaggio naturale.
La soluzione non è bloccare il progetto. È fare una fase di bonifica documentale prima di accendere il RAG a tutta l'azienda.
In Celeris la chiamiamo pre-ingestion review: campioniamo le sorgenti, cerchiamo cartelle troppo aperte, documenti sensibili in aree generiche, duplicati, file obsoleti e proprietari mancanti. Non è lavoro glamour. È quello che evita incidenti dopo.
Audit log: chi ha chiesto cosa, e perché
Un sistema RAG professionale deve poter rispondere a una domanda scomoda: "chi ha visto questa informazione?".
Non basta loggare la domanda dell'utente. Devi loggare anche:
- quali chunk sono stati recuperati;
- quali chunk sono stati passati al modello;
- quali fonti sono state citate;
- quale utente o gruppo aveva diritto di vederle;
- quando è avvenuta la risposta;
- quale versione del documento era nell'indice.
Questo non serve per spiare i dipendenti. Serve per audit, incident response e qualità. Se una risposta sbagliata entra in un processo, devi poter ricostruire da dove è nata. Se un documento riservato viene citato, devi capire se il problema era nei permessi sorgente, nella sincronizzazione o nel filtro del retrieval.
Senza audit log, un RAG è una scatola nera gentile. Risponde con tono educato, ma quando qualcosa va storto nessuno sa più ricostruire il percorso.
Non tutti i reparti hanno bisogno della stessa AI
Un altro modo per ridurre il rischio è smettere di pensare al RAG come a un unico assistente universale.
Il commerciale ha bisogno di offerte, contratti, CRM, schede cliente. Il service desk ha bisogno di ticket, manuali, knowledge base tecnica. Legal ha bisogno di contratti, pareri, contenziosi. HR ha bisogno di policy interne, non dei margini delle offerte. La direzione può avere un perimetro più ampio, ma anche lì non tutto deve essere mischiato.
Architetturalmente questo può diventare:
- un indice unico con filtri robusti per ruolo;
- indici separati per dominio;
- una soluzione ibrida: indici separati per aree sensibili, indice comune per conoscenza generale.
Non esiste una risposta universale. Ma esiste una regola: se due reparti non dovrebbero potersi scambiare liberamente documenti, non dovrebbero condividere lo stesso spazio RAG senza filtri forti.
Dove Celeris entra nel discorso
Celeris nasce proprio per evitare che il RAG aziendale diventi una demo bella e fragile. Il punto non è solo "trova i documenti". Quello ormai lo fanno in tanti. Il punto è trovare i documenti giusti per la persona giusta, citare le fonti e lasciare traccia del percorso.
Questo si lega a due scelte che abbiamo già raccontato altrove: l'on-premise riduce l'esposizione dei dati verso provider esterni, e le citazioni verificabili riducono la fiducia cieca nel modello. Ma permessi e audit sono il terzo pezzo: riducono il rischio interno.
Un RAG può essere privato, citare le fonti e comunque essere pericoloso se ignora i permessi. "I dati non escono dall'azienda" è una buona notizia. Non basta. Anche dentro l'azienda i dati devono restare nel perimetro corretto.
FAQ
Un RAG aziendale deve rispettare i permessi dei documenti?
Sì. Un RAG serio deve recuperare e mostrare solo contenuti che l'utente avrebbe già il diritto di leggere nel sistema sorgente. Se un documento è vietato all'utente, non deve arrivare al modello.
Che cos'è il security trimming in un RAG?
È il filtro che applica i permessi dell'utente durante il retrieval. Serve a escludere dai risultati i chunk non autorizzati prima della generazione della risposta.
È meglio un indice unico o indici separati per reparto?
Dipende dalla sensibilità dei dati e dalla qualità dei permessi esistenti. Per aree come HR, legal o direzione spesso conviene separare gli indici o applicare filtri molto rigidi.
Il punto
Se stai valutando un RAG aziendale, non partire dal modello. Parti dai permessi. Chiedi quali sorgenti entrano, chi può vedere cosa, dove vengono salvati i log, quanto velocemente cambiano le ACL, cosa succede quando una persona cambia ruolo.
La domanda non è "quanto è intelligente l'AI?". La domanda è: quando diventa intelligente, resta ancora disciplinata?
Un buon RAG non deve far vedere tutto a tutti. Deve rendere accessibile la conoscenza giusta, alla persona giusta, nel momento giusto. Il resto non è produttività. È una fuga di informazioni con una bella interfaccia.
