Esperienze dalla pratica

Conoscenze aziendali con l’IA: perché il RAG richiede un controllo dei permessi

Un risultato di ricerca pertinente non equivale a un accesso autorizzato. Identità, permessi, indice e cache devono far parte di un’architettura RAG controllata.

IntegrazioneSicurezza
Tablet con fonti documentali accanto a cartelle e una lista di controllo.

Una ricerca con IA risponde a una domanda interna con una citazione pertinente. Tecnicamente notevole, ma la persona che ha posto la domanda poteva leggere il documento citato? È qui che si decide se una soluzione RAG è adatta all’azienda.

Il RAG collega ricerca e modello linguistico.

La Retrieval-Augmented Generation arricchisce una richiesta con informazioni pertinenti provenienti da fonti. I documenti vengono preparati e resi ricercabili; gli estratti selezionati diventano poi il contesto del modello linguistico. Da questo il modello può creare una risposta con riferimenti alle fonti.

Questo collegamento è utile quando le informazioni corrette sono aggiornate e autorizzate per l’utente. Diventa pericoloso se un indice condiviso restituisce tutti i documenti senza limiti di accesso efficaci. L’autenticazione all’interfaccia di chat non costituisce un’autorizzazione per ogni documento reperibile al suo interno.

Il controllo degli accessi deve intervenire prima del modello.

La ricerca autorizzata passa al modello linguistico solo il contesto documentale consentito; fonti e modifiche ai permessi vengono aggiornate.
Possibile situazione o architettura, senza dati reali di clienti o del personale.

L’applicazione determina l’identità dell’utente tramite un metodo di autenticazione affidabile. La ricerca limita risultati ed estratti all’ambito consentito. Solo questo contesto autorizzato viene passato al modello linguistico. Anche l’indice, i suoi accessi amministrativi e il collegamento alla fonte richiedono controlli adeguati.

Un’istruzione nel prompt che vieta di divulgare informazioni riservate arriva troppo tardi come unica protezione dell’accesso: i dati non autorizzati sarebbero già stati elaborati. Anche nascondere successivamente una citazione non corregge questo percorso dei dati.

Contano anche i piccoli percorsi secondari.

Titoli dei risultati
Un titolo relativo, per esempio, a una misura pianificata sul personale può già essere riservato. Il filtro dei permessi non serve solo al testo completo del documento.
Cache
Una risposta creata per l’utente A non può essere riutilizzata per B senza verifica. Identità, tenant e permessi appropriati devono essere considerati nella progettazione della cache.
Link alle fonti
Una fonte cliccabile richiede che l’accesso all’originale resti autorizzato. Un link privato per il download non deve generare una condivisione generale.
Log
Ricerche, estratti e dettagli degli errori possono contenere segreti aziendali. Accesso e conservazione vengono limitati.

I permessi cambiano più rapidamente di alcuni indici.

Una persona cambia reparto, un progetto termina o una condivisione viene revocata. Le fonti e i diritti di ricerca devono tornare a coincidere. L’architettura richiede quindi un percorso di aggiornamento descritto e tempi di reazione adeguati.

Un test particolarmente importante è la revoca dei permessi: una domanda inizialmente consentita viene ripetuta con lo stesso account dopo la modifica. Si verifica inoltre se vecchie cache, anteprime o risposte salvate consentano ancora l’accesso. Il risultato deve essere documentato; il solo completamento corretto di un’importazione non basta.

Le funzioni dei prodotti non sono componenti intercambiabili.

Alcuni servizi di ricerca supportano controlli nativi a livello di documento, altri richiedono filtri applicati esplicitamente e una sincronizzazione dedicata. Per Azure AI Search, per esempio, la documentazione attuale distingue i filtri di sicurezza da ulteriori procedure integrate, in parte indicate come anteprima. Versioni e stato delle API fanno quindi parte della scelta architetturale.

Indipendentemente dallo strumento, il collaudo deve dimostrare quali fonti un’identità di prova può vedere e quali non riceve. I limiti desiderati non vengono ricavati solo da una risposta casuale del modello.

Un progetto pilota verificabile unisce utilità e protezione.

DAXS può iniziare con una base di conoscenze circoscritta: responsabili delle fonti nominati, documenti aggiornati, account di prova, criteri chiari per le risposte e test negativi verificabili. L’ambito viene ampliato solo quando ricerca, permessi e riferimenti alle fonti sono adeguati.

La pagina specialistica Conoscenze aziendali e RAG descrive insieme importazione e interrogazione. Sicurezza dell’IA approfondisce oversharing, identità e permessi degli agenti.

Fonti: Microsoft: controllo degli accessi a livello di documento · OWASP: vulnerabilità di vettori ed embedding. Lo schema mostra una possibile architettura senza dati di clienti.