RBAC nei sistemi RAG aziendali: come proteggere i dati sensibili

In molti progetti di intelligenza artificiale generativa, la sicurezza viene trattata come un elemento secondario fino a quando un modello non restituisce il bilancio provvisorio o una lista di stipendi al dipendente sbagliato. Nel contesto delle architetture Retrieval-Augmented Generation (RAG) aziendali, la ricerca semantica analizza vettori di testo senza conoscere, di default, chi ha il diritto di leggere cosa. L’illusione che l’IA comprenda implicitamente la riservatezza aziendale è una delle vulnerabilità più critiche dell’adozione enterprise.

La risposta diretta alla domanda su come garantire la riservatezza dei dati nei sistemi RAG è una sola: il controllo d’accesso basato sui ruoli (RBAC) deve essere applicato a livello di retrieval vettoriale tramite pre-filtering deterministico, e mai affidato alle istruzioni del prompt inviato al Large Language Model (LLM). L’LLM deve ricevere esclusivamente contesti che l’utente corrente è già autorizzato a visualizzare.

Architettura RBAC nei sistemi RAG: pre-filtering vs post-filtering

Quando un utente pone una domanda a un sistema RAG, il sistema converte la query in un embedding vettoriale ed esegue una ricerca per similarità nel database vettoriale. In assenza di RBAC, il database restituisce i nodi di testo più pertinenti dal punto di vista semantico, indipendentemente dalla classificazione di sicurezza del documento sorgente. Per evitare l’esposizione impropria di informazioni, esistono due approcci architetturali principali.

Il post-filtering recupera i primi k risultati più simili dal database vettoriale e applica successivamente un filtro sui permessi dell’utente prima di inviare il contesto al modello. Questo approccio presenta un difetto strutturale noto come fenomeno della privazione di contesto. Se i primi venti documenti più rilevanti per una query appartengono a cartelle riservate alla direzione, il filtro di sicurezza li eliminerà tutti, lasciando il modello privo di informazioni utili o costringendolo ad allucinare una risposta, anche se l’utente avrebbe avuto accesso a documenti pertinenti ma con uno score di similarità leggermente inferiore.

Il pre-filtering, raccomandato nelle architetture servizi di Architetture API, AI orchestration e sistemi backend per piattaforme enterprise, integra gli elenchi di controllo d’accesso (ACL) direttamente nei metadati di ciascun vettore. Durante l’esecuzione della query, il database vettoriale applica una maschera booleana basata sulle credenziali JWT o sui ruoli dell’utente prima di calcolare la similarità coseno o la distanza euclidea. In questo modo, la ricerca semantica avviene esclusivamente sul sottoinsieme di dati a cui l’utente ha diritto di accedere.

Affidare la sicurezza dei dati riservati alle istruzioni del sistema nel prompt è la causa primaria di fuga di informazioni sensibili nei progetti RAG enterprise.

I quattro passaggi per configurare l’accesso basato sui ruoli

Per implementare un sistema RBAC efficace e resiliente all’interno della pipeline RAG, è necessario strutturare il processo di ingestion e recupero dei dati seguendo uno schema rigoroso.

1. Mappatura dei dati e sincronizzazione dell’Identity Provider: Integrare la pipeline di Data Engineering con l’Identity Provider aziendale (come Microsoft Entra ID o Okta). Durante la fase di ingestion dei documenti, le ACL associate ai file sorgente devono essere lette ed estratte come metadati strutturati.
2. Arricchimento dei metadati del payload vettoriale: Ogni chunk di testo salvato nel vector database deve contenere un payload di metadati che definisce i ruoli autorizzati, i gruppi o gli ID utente specifici (ad esempio: allowed_roles: ["finance_mgr", "hr_dir"]).
3. Propagazione del contesto di sicurezza nella query API: Quando l’applicazione client invia una richiesta, il gateway API autentica l’utente, estrae i ruoli confermati dal token e li inietta nella richiesta inviata al database vettoriale. Per approfondire gli standard di sicurezza per le API enterprise, fa fede la documentazione di riferimento dell’organizzazione OWASP per le applicazioni LLM.
4. Esecuzione del pre-filtering nativo sul vector store: Utilizzare database vettoriali che supportano l’indicizzazione dei metadati ad alte prestazioni (come Qdrant, Pinecone o pgvector con indici HNSW combinati a filtri B-tree) per garantire che l’applicazione dei filtri di sicurezza non degradi i tempi di risposta.

Gli errori più comuni nella gestione dei permessi vettoriali

Uno degli errori più diffusi tra i team di sviluppo consiste nel tentare di gestire i permessi tramite la sicurezza basata sull’istruzione nel prompt (prompt-based security). Scrivere nel sistema istruzioni del tipo “non mostrare informazioni sui compensi se l’utente non è un manager” non offre alcuna garanzia. Tecnica ben nota come prompt injection, l’utente può facilmente aggirare queste restrizioni con tecniche di jailbreaking o riformulando la domanda in modo indiretto.

Un altro rischio frequente riguarda il disallineamento dei permessi (permission drift). Se un dipendente cambia ruolo o lascia l’azienda, oppure se i permessi di una cartella su SharePoint vengono modificati, il database vettoriale rischia di conservare i vecchi metadati ACL. Senza una pipeline automatizzata di sincronizzazione ed eliminazione dei vettori obsoleti sviluppata con adeguate pratiche di servizi di Data science, machine learning, data engineering per decisioni basate sui dati, l’indice vettoriale diventa rapidamente una falla di sicurezza.

Impatto sui costi, latenza e manutenzione

L’integrazione del controllo d’accesso basato sui ruoli nelle architetture RAG comporta impatti precisi su infrastruttura e operatività aziendale:

• Latenza di ricerca: Il pre-filtering richiede l’uso di indici compositi. L’aumento del tempo di risposta per query è generalmente contenuto tra i 5 e i 20 millisecondi, a condizione che i metadati siano corretti e indicizzati.
• Consumo di memoria RAM e storage: L’aggiunta di payload complessi contenenti liste di ruoli aumenta la dimensione dell’indice vettoriale del 15-25%, richiedendo risorse hardware aggiuntive per mantenere le prestazioni in-memory.
• Costi di ingegnerizzazione: La fase di configurazione iniziale richiede da 3 a 5 settimane uomo per integrare gli Identity Provider, gestire le logiche di sincronizzazione differenziale delle ACL ed eseguire i test di penetrazione.

Raccomandazioni pratiche per i decision maker

Garantire la sicurezza nei sistemi RAG non è un problema di intelligenza artificiale, ma un classico problema di ingegneria dei sistemi e di governance dei dati. Non accettate soluzioni che rimandano la gestione della sicurezza alla fase di generazione del testo o che si affidano a filtri euristici a monte del modello.

Prima di passare alla produzione con qualsiasi assistente basato su dati aziendali, assicuratevi che la pipeline di ingestion automatizzi la sincronizzazione delle ACL e che l’architettura vettoriale imponga il pre-filtering sui dati. La riservatezza deve essere deterministica, non probabilistica.

Se volete valutare la sicurezza dell’architettura RAG della vostra azienda o progettare un sistema sicuro fin dalle fondamenta, parla con il nostro team per analizzare il vostro caso d’uso con i nostri ingegneri.