Permission-Aware RAG: Il Vero Costo per Farlo Bene

Il permission-aware RAG significa che il vostro step di retrieval filtra in base a chi fa la richiesta, non solo a cosa viene chiesto — e quel filtro deve vivere dentro la query vettoriale stessa, non come secondo passaggio affidato all'LLM a posteriori. La maggior parte dei team lo scopre a proprie spese: il loro demo RAG funziona perfettamente su una knowledge base condivisa, poi qualcuno chiede di applicare l'accesso ai documenti per singolo utente e l'intero layer di retrieval deve essere riscritto.

Perché "aggiungere solo un controllo sui permessi" non funziona

L'istinto è di mantenere la pipeline di retrieval esistente e agganciare un controllo alla fine: recuperare i top-k chunk, poi chiedere a un LLM (o a un motore di regole) "questo utente può vedere questo?" prima di passare il contesto allo step di risposta. Questo approccio fallisce in due modi:

• È non deterministico. Un LLM a cui si chiede di vigilare sull'access control occasionalmente sbaglia, e "occasionalmente sbagliato" non è una policy di access control accettabile — specialmente quando si tratta di cartelle cliniche, documenti legali o file HR.
• La fuga di dati è già avvenuta. Nel momento in cui si filtra dopo il retrieval, il contenuto riservato è già stato caricato in una context window e inviato da qualche parte. Log, cache o una traccia di debug lasciata per sbaglio possono farlo trapelare prima che il vostro filtro venga mai eseguito.

La soluzione è portare i permessi dentro la query — esattamente come si inserirebbe una clausola WHERE user_id = ? in una query SQL invece di recuperare tutto e filtrare nel codice applicativo. Abbiamo visto lo stesso principio applicarsi nei nostri strumenti interni: in un motore di outreach che abbiamo costruito, una singola chiamata che filtra ed estrae in un unico passaggio ha costantemente battuto una catena multi-step che recuperava in modo ampio e ragionava sulla rilevanza in seguito — più economica, più veloce e con meno punti di errore. Il permission-aware RAG è la versione security-critical di questa stessa lezione: filtrate alla fonte, non dopo il fatto.

Cosa cambia concretamente nella vostra architettura

Se utilizzate Postgres con pgvector o un vector store gestito, il retrieval permission-aware richiede tipicamente:

1. Metadati sui permessi su ogni chunk. Non basta un document_id — è necessario sapere quali ruoli, team o user ID possono vedere ogni chunk al momento dell'indicizzazione. Questo di solito significa re-chunking e re-embedding dell'intero corpus esistente, non una semplice patch ai metadati.
2. Row-level security o un filtro equivalente nel percorso della query. Postgres ha supporto nativo per questo tramite le policy di row-level security, e Supabase si costruisce direttamente sopra per RLS multi-tenant. La ricerca per similarità e il filtro per accesso vengono eseguiti come un'unica query, quindi una ricerca vettoriale dell'utente letteralmente non può restituire righe che non è autorizzato a vedere.
3. Un modello di permessi che cambia nel tempo. I documenti vengono condivisi, i ruoli revocati, i team ristrutturati. Se gli embedding e i permessi risiedono in sistemi diversi che si sincronizzano periodicamente, esiste una finestra temporale in cui la sessione di un dipendente licenziato può ancora recuperare documenti a cui ha perso l'accesso un'ora prima. I controlli sui permessi in tempo reale non sono negoziabili quando ci si avvicina a qualsiasi ambito regolamentato.
4. Una strategia di re-indicizzazione, non solo logica di retrieval. È questo il punto che fa saltare le stime. Aggiungere ACL a un sistema RAG che ha già 50.000 documenti indicizzati significa non scrivere una nuova query — significa ri-processare l'intero corpus con i tag dei permessi allegati, poi validare che i tag siano corretti prima di affidare al sistema contenuti sensibili.

Dove va davvero il costo

I team stimano il costo del modello e della logica di retrieval. Sullo stesso corpus di 50.000 documenti, il costo reale emerge in:

• Audit dei dati. Qualcuno deve determinare chi è effettivamente autorizzato a vedere cosa — e con 50.000 documenti non è un foglio di calcolo compilato in un pomeriggio, ma una verifica degli accessi reparto per reparto, spesso basata su conoscenze tacite mai messe per iscritto, prima che venga assegnato un singolo tag di permesso.
• Re-embedding su larga scala. Re-chunking e re-embedding di 50.000 documenti non è un job da accodare di notte e controllare il giorno dopo — se il modello dei permessi cambia cosa costituisce un'unità recuperabile (dividendo una cartella condivisa in sezioni per team, per esempio), i confini dei chunk stessi cambiano, quindi si tratta di un passaggio di ri-processamento sull'intero corpus, non di un aggiornamento dei metadati sovrapposto.
• Test dei casi negativi. Testare che il sistema recuperi correttamente è semplice. Testare che non recuperi mai qualcosa che un utente non dovrebbe vedere, in ogni combinazione di ruoli, è la parte che richiede un vero lavoro di QA — rientra nella stessa categoria di attività descritta in una checklist di sicurezza per agenti AI, e merita lo stesso rigore che applichereste al codice di autenticazione, non "abbiamo provato qualche prompt e sembrava ok."
• Audit logging. In ambito sanitario o governativo, spesso è necessario dimostrare a posteriori esattamente cosa ha recuperato un utente e perché — il che significa registrare la query filtrata, non solo la risposta finale. Questo si sovrappone direttamente a quanto abbiamo scritto sull'architettura difendibile in sede legale per l'AI in sanità: il log deve essere difendibile, non semplicemente presente.

Quando conviene costruire e quando acquistare

Se il vostro modello di accesso è semplice — un tenant, una knowledge base condivisa, tutti vedono tutto — non costruite il permission-aware retrieval. È complessità inutile per un problema che non avete. Partite dalle basi in RAG spiegato per i founder e andate avanti.

Costruitelo voi stessi quando:

• Il vostro modello di permessi è centrale nel prodotto (SaaS multi-tenant, cartelle cliniche, knowledge base interne con contenuti HR o legali riservati).
• Avete bisogno di revoca in tempo reale — le modifiche agli accessi devono avere effetto immediatamente, non alla prossima sincronizzazione.
• Operate in un settore regolamentato dove "abbiamo filtrato dopo il retrieval" non reggerà a un audit.

Considerate un layer gestito (molte piattaforme enterprise di search e RAG ora includono retrieval ACL-aware di serie) quando il vostro modello di permessi si mappa in modo pulito su strutture standard di ruolo/gruppo e non avete bisogno di personalizzare la logica di filtraggio stessa. Qualunque sia la scelta, applicate lo stesso rigore alle garanzie di retrieval del fornitore che applichereste a qualsiasi contratto con un vendor AI — consultate le valutazioni nei contratti con vendor AI per sapere cosa richiedere concretamente.

La versione in una frase

Non chiedete all'LLM di applicare l'access control dopo il retrieval — applicatelo nella query che esegue il retrieving, e stimate il costo della re-indicizzazione del corpus, non solo della scrittura del nuovo codice di retrieval.

Se state pianificando un sistema RAG che necessita di veri confini sui permessi — cartelle cliniche, SaaS multi-tenant, documenti interni con sezioni riservate — parliamone.