Un RAG montato male è il modo più rapido di far uscire dati che non dovrebbero mai vedere la luce. Il pattern classico: indicizzi «tutta la documentazione», un utente chiede qualcosa di innocente e il sistema gli restituisce un frammento di un documento a cui quella persona non dovrebbe avere accesso. Non è un bug esotico — è l'architettura di default di quasi tutti i RAG da demo.
Permessi prima degli embedding
Il controllo di accesso non è un filtro che si aggiunge alla fine: vive nel livello di recupero. Prima che il modello veda qualsiasi cosa, il sistema ha già ristretto quali frammenti può recuperare questo utente specifico. L'identità comanda; l'embedding viene dopo.
Partiziona l'indice per permesso
Non buttiamo tutto in un unico indice pregando. Segmentiamo per livello di accesso e attacchiamo metadati di permesso a ogni frammento, così che la query possa toccare solo ciò che spetta a chi chiede.
- Filtro per identità nel recupero, non nella risposta.
- Indici o partizioni segmentati per livello di accesso.
- Metadati di permesso su ogni frammento indicizzato.
- Audit delle query: chi ha chiesto cosa e cosa gli è stato restituito.
Citazione o non serve
Ogni risposta linka la sua fonte. Senza citazione non c'è fiducia né tracciabilità: l'utente non può verificare, e tu non puoi auditare. In enterprise, una risposta senza fonte è una risposta che non puoi difendere.
Cosa misuriamo
- Precisione del recupero (porta ciò che è rilevante?).
- Fughe di accesso: l'obiettivo è zero, e si audita.
- Copertura della citazione: % di risposte con fonte verificabile.
- Uptime e latenza del pipeline.
Questo è ciò che fa un Senior AI Infrastructure Implementer: non «collega un RAG», fa il deploy di un sistema di conoscenza che scala, cita e rispetta i permessi — perché in enterprise un dato uscito non è un incidente tecnico, è una crisi.