Sicurezza dei sistemi RAG: come controllare ciò che vede un LLM

Chiunque abbia gestito un sistema documentale sa che, in pratica, il controllo degli accessi è sempre stato una questione di cartelle. Un fascicolo, una commessa, un progetto, un cliente: a ciascuno corrisponde una directory e, a ciascuna directory, una lista di chi può leggere e di chi può scrivere.

Perché le policy di accesso per RAG superano le cartelle

È un modello grossolano ma comprensibile e, soprattutto, ha una proprietà che, in sede di verifica, vale oro: la lista è un oggetto che esiste, si può stampare, confrontare con l’organigramma ed esibire a un auditor. Anticipiamo subito che questa proprietà va conservata, non abbandonata: l’elenco dei soggetti abilitati a una cartella resta il primo strato di controllo anche per un assistente basato su LLM. Ciò che cambia è che non è più l’ultimo.

Con l’arrivo degli assistenti basati su modelli linguistici di grandi dimensioni (LLM) collegati al patrimonio informativo delle organizzazioni, questa proprietà va perduta. L’assistente non apre cartelle: interroga un indice vettoriale che restituisce i frammenti di testo più simili alla domanda, ovunque si trovino, oppure percorre un knowledge graph in cui una persona, una società, un immobile o un prodotto sono nodi unici che collegano documenti nati in contesti diversi. Poi sintetizza, fondendo in un’unica risposta informazioni di provenienza eterogenea. E lo fa, nei sistemi agentici, attraverso catene di attività e chiamate a servizi esterni, ciascuna delle quali può ampliare il perimetro informativo iniziale.

Il risultato è che, in assenza di regole esplicite, la decisione su quali informazioni un utente può ricevere da un altro contesto è presa di fatto dall’algoritmo di retrieval, cioè dal software e da chi lo ha configurato, e non dall’organizzazione. Nessuno l’ha decisa, nessuno l’ha scritta, nessuno può esibirla. Per una funzione di compliance o per un revisore, questo è un difetto chiave: non un controllo debole, ma un controllo che non esiste come oggetto digitale, e quindi non è verificabile.

In questo articolo argomentiamo che la risposta deve andare oltre i filtri sui metadati aggiunti caso per caso: occorre un linguaggio formale per le politiche di accesso a RAG (retrieval-augmented generation) e ai knowledge graph, dotato di semantica precisa, di meccanismi di risoluzione dei conflitti e di un’architettura di applicazione che produca evidenze verificabili.

Accesso intra-tenant e isolamento dei dati nelle piattaforme RAG

Prima di entrare nel merito, bisogna fare una distinzione che nel dibattito attuale viene spesso trascurata. Quando un’organizzazione utilizza un servizio di IA generativa in modalità SaaS, il fornitore la considera un tenant. L’incapsulamento del contesto (context encapsulation) è la proprietà secondo cui nessuna richiesta, nessun indice vettoriale, nessuna partizione del grafo e nessuna cache di un tenant sono accessibili da parte di un altro tenant, né possono finire nel contesto in cui il modello elabora una risposta per un altro tenant.

Si realizza con identificatori di tenant propagati in ogni chiamata, spazi dei nomi separati, chiavi di cifratura distinte, isolamento a livello di rete e di processo, e, quando il modello viene adattato o affinato, con la garanzia che i dati di un tenant non entrino nell’addestramento di ciò che serve agli altri.

È una proprietà binaria e a grana grossa; soprattutto, è gestita dal fornitore. L’organizzazione cliente non la configura: la richiede contrattualmente, la verifica tramite certificazioni, audit dell’infrastruttura e test di penetrazione e, in caso di violazione, ne chiede conto. Il fornitore che non la garantisse non avrebbe un prodotto multi-tenant, ma un incidente in fieri.

Ma la multitenancy si ferma alla porta del tenant. All’interno dell’organizzazione, tra i suoi reparti, i suoi progetti, i suoi clienti, i suoi collaboratori esterni, la domanda cambia natura: non è più “questa informazione appartiene a chi esegue l’interrogazione?”, che ha risposta binaria, sì o no, ma “questa persona, per questo compito, può usare questa informazione che proviene da un altro contesto, e in quale forma?”.

La risposta dipende dagli attributi della persona, della risorsa, dell’azione e della situazione e deve essere fornita dall’organizzazione, perché solo essa conosce i vincoli deontologici, contrattuali e regolatori che la riguardano. Il fornitore può e deve offrire il meccanismo per esprimere e applicare la risposta; non dovrebbe darla al posto del cliente e, se lo fa per omissione, cioè lasciando che sia il retrieval a decidere, si assume una responsabilità che non è sua e che il cliente non ha delegato.

La tabella seguente riassume le differenze.

Tenere separati i due piani serve a entrambe le parti. Al fornitore, perché delimita ciò di cui risponde: la correttezza del meccanismo. All’organizzazione, perché le restituisce ciò che le spetta e che oggi rischia di perdere senza accorgersene: la scelta delle regole, con la responsabilità che ne consegue.

Da XACML alle policy di accesso per RAG

L’idea che le politiche di accesso debbano essere espresse in un linguaggio formale, separato dall’applicazione che le applica, non è nuova. All’inizio degli anni Duemila, con la diffusione dei servizi web e dei documenti XML, divenne evidente che le liste di controllo degli accessi legate al file system non potevano descrivere autorizzazioni a grana fine su porzioni di documento, condizionate da attributi dell’utente e del contesto.

Il lavoro di ricerca sul controllo degli accessi a grana fine per documenti XML, a cui il gruppo dell’Università di Milano contribuì con un modello pubblicato su ACM Transactions on Information and System Security nel 2002, confluì nell’iniziativa di standardizzazione di OASIS, che portò alla definizione di XACML, l’eXtensible Access Control Markup Language. La versione 1.0, alla cui stesura gli autori di quel modello parteciparono come membri del comitato tecnico, fu approvata come Committee Specification nel novembre 2002 e come standard OASIS nel febbraio 2003; la versione 3.0, tuttora di riferimento, è standard OASIS da gennaio 2013.

Ciò che di XACML vale la pena portare nel presente non è la sintassi, un XML verboso che nessun responsabile della compliance leggerebbe volentieri, ma due aspetti più profondi: l’architettura e il modello semantico.

L’architettura separa quattro funzioni. Il punto di applicazione (Policy Enforcement Point, PEP) intercetta la richiesta e ne blocca l’esecuzione finché non ha una decisione; il punto di decisione (Policy Decision Point, PDP) valuta le policy applicabili e restituisce permesso, diniego, non applicabile o indeterminato; i punti di informazione (Policy Information Point, PIP) forniscono al PDP gli attributi che non viaggiano con la richiesta, interrogando anagrafiche, directory aziendali, sistemi gestionali; il punto di amministrazione (Policy Administration Point, PAP) è dove le policy vengono scritte, versionate e pubblicate.

Questa separazione è la ragione per cui XACML è sopravvissuto a due decenni di cambiamenti tecnologici: il PEP può risiedere in un web server, in un gateway API o, come vedremo, in una pipeline di retrieval, senza che la politica debba cambiare.

Il modello semantico definisce una politica come un insieme di regole, ciascuna con un target (a quali soggetti, risorse e azioni si applica), una condizione booleana sugli attributi e un effetto. Le regole si compongono in policy e le policy in policy set, tramite algoritmi di combinazione espliciti: “il diniego prevale”, “il permesso prevale”, “vale la prima decisione applicabile”.

Alla decisione possono essere allegati obblighi, ovvero azioni successive che il PEP deve eseguire affinché la decisione sia valida, e avvisi. Sono queste ultime due nozioni, gli algoritmi di combinazione e gli obblighi, a rendere un linguaggio di policy qualcosa di più di un filtro: il primo garantisce che l’esito sia deterministico e spiegabile anche quando le regole entrano in conflitto, il secondo permette di dire non solo “sì” o “no”, ma “sì, purché”.

XACML ci ha anche insegnato cosa non funziona. La sua sintassi basata su XML ha frenato l’adozione da parte di chi doveva scrivere le regole, che raramente era un programmatore. Ne sono nate sintassi compatte con la stessa semantica, come ALFA (Abbreviated Language for Authorization), e, più di recente, altri linguaggi che, pur con nomi diversi, riproducono lo stesso impianto concettuale: Cedar, Rego (usato da Open Policy Agent) e, sul versante delle condizioni d’uso dei contenuti, ODRL del W3C. La lezione è che il modello è più importante della notazione, e che la notazione deve essere leggibile da chi ne risponde.

I limiti delle cartelle nei sistemi RAG agentici

Se il modello XACML è ancora valido, perché non basta applicarlo così com’è, con “documento” come risorsa e “lettura” come azione? Perché la pipeline di un LLM basato su RAG e su un knowledge graph introduce almeno quattro novità che il controllo degli accessi tradizionale non contempla.

Il livello di base: permessi, identità e contenuti derivati

Conviene partire dal basso, perché il primo strato di controllo esiste già ed è bene non smantellarlo. All’interno dello stesso tenant, la forma più elementare di politica di accesso consiste nel creare cartelle o spazi documentali distinti — per cliente, per commessa, per unità organizzativa — e nello stabilire, nominativamente o per gruppo, quali soggetti siano autorizzati ad accedervi.

È il modello che ogni organizzazione già governa nel proprio sistema documentale ed è il livello zero anche per un assistente basato su RAG: definisce, prima di qualunque considerazione semantica, l’insieme delle fonti che, per un dato utente, sono, in linea di principio, interrogabili. Ha il pregio della comprensibilità e quello, non secondario, di consentire la chiusura immediata, per impostazione predefinita, richiesta dall’articolo 25 del GDPR.

Perché sia un controllo reale e non un’apparenza, questo livello di base richiede però tre condizioni che le implementazioni frettolose trascurano. La prima è che le liste di abilitazione siano replicate come attributi dei frammenti indicizzati e valutate al momento dell’interrogazione, con un processo di sincronizzazione che propaghi all’indice le revoche e i cambi di appartenenza: un’autorizzazione revocata sulla cartella ma non ancora propagata all’indice vettoriale è un accesso ancora aperto.

La seconda è che il recupero sia eseguito con l’identità dell’utente finale e non con l’identità tecnica dell’agente o del connettore, che di norma ha visibilità sull’intero patrimonio documentale: se è l’agente a interrogare l’indice per conto proprio, la lista sulla cartella diventa meramente decorativa. La terza è che i contenuti derivati ereditino la lista della fonte, per le ragioni che vedremo più avanti.

A queste condizioni tecniche si aggiunge un’altra, organizzativa, che viene prima di tutto: le liste devono essere quelle giuste prima che l’assistente LLM venga attivato. In ogni sistema documentale esistono permessi troppo larghi, rimasti inosservati per anni perché nessuno sarebbe andato a cercare quel file in quella cartella. La ricerca semantica elimina questo attrito: tutto ciò a cui l’utente ha accesso diventa consultabile con una semplice domanda. Il mercato ha dato a questo fenomeno il nome di oversharing, e la sua bonifica è un lavoro sui permessi e sui responsabili dei dati prima che sull’intelligenza artificiale.

Anche una volta soddisfatte queste condizioni, il modello resta un punto di partenza. I suoi limiti sono di due ordini. Il primo è amministrativo: l’elenco nominativo è una fotografia che invecchia, le combinazioni fra cartelle e persone crescono in modo combinatorio con i progetti e i collaboratori esterni, e ogni eccezione si traduce in una nuova cartella o in un nuovo gruppo, fino a rendere l’insieme non più verificabile.

Già a questo livello conviene quindi esprimere le abilitazioni per ruolo o per assegnazione al progetto, riservando il riferimento nominativo alle deroghe individuali, che vanno documentate. Il secondo ordine di limiti è strutturale, ed è quello delle quattro novità appena richiamate: conviene esaminarle una a una.

Le quattro novità dei sistemi RAG agentici

La prima novità è che il retrieval è semantico, non gerarchico. Un utente che chiede “come abbiamo gestito clausole di questo tipo in passato” riceve i frammenti più simili alla domanda, indipendentemente dalla cartella in cui si trovano. La cartella non è più il perimetro naturale della ricerca; lo è, semmai, l’insieme degli attributi dei frammenti.

La seconda è che il knowledge graph collega entità, non documenti. Una controparte commerciale, un fornitore, un dipendente compaiono come nodi unici anche se ricorrono in progetti diversi, magari con interessi contrapposti. Attraversare un arco del grafo significa passare da un contesto all’altro senza che nessuno lo abbia deciso. La granularità rilevante diventa quella dell’arco: il nodo può essere visibile in entrambi i contesti, ma il passaggio da uno all’altro deve essere autorizzato.

La terza novità è che l’agente sintetizza. La risposta finale fonde informazioni di provenienza diversa, e un fatto appreso nel contesto B può comparire, senza citazione e senza che l’utente lo sappia, nella risposta redatta per il contesto A. La fuga di informazione non è più un documento aperto indebitamente: è una frase. Ne consegue che l’azione da autorizzare non è “leggere”, ma una famiglia di azioni distinte: recuperare, usare come contesto, citare testualmente, riassumere, e la policy deve poterle trattare diversamente.

La quarta è che l’agente agisce in più passaggi. In un flusso agentico la decisione di accesso non riguarda una singola query, ma una catena di sottoattività, strumenti e chiamate, e la finalità dichiarata del compito, che nei sistemi tradizionali era irrilevante, diventa un attributo di contesto decisivo.

Questa novità ha un corollario che nei sistemi tradizionali non esisteva: per un agente il contenuto recuperato può comportarsi come un’istruzione. Un documento che l’utente ha pieno diritto di leggere, ad esempio una bozza contrattuale ricevuta dalla controparte, può contenere del testo, anche invisibile alla lettura umana, scritto per indurre l’agente a cercare ulteriori informazioni e a farle uscire tramite uno strumento. È lo schema del “confused deputy”, noto da tempo nella letteratura sulla sicurezza: l’agente utilizza i permessi dell’utente per conto di un altro.

La vulnerabilità EchoLeak (CVE-2025-32711), corretta dal fornitore e resa pubblica nel giugno 2025 senza evidenze di sfruttamento reale, ha mostrato che, per un assistente aziendale fra i più diffusi, bastava un’email costruita ad arte: l’utente non doveva aprirla; era sufficiente che in seguito ponesse all’assistente una normale domanda di lavoro. Per il linguaggio di politiche ne discendono due requisiti.

La provenienza della fonte deve essere un attributo della risorsa, così che una regola possa stabilire che, quando nel contesto è entrato materiale di origine esterna, l’invocazione di strumenti che comunicano all’esterno richiede la conferma di una persona. E il permesso effettivo dell’agente deve essere l’intersezione tra ciò che l’utente può fare e ciò che è consentito a quell’agente per quel compito, mai la loro unione.

A queste novità si aggiunge una questione relativa ai contenuti derivati: embedding, riassunti, nodi ed archi estratti da un documento sono nuovi oggetti generati automaticamente e, se non ereditano la classificazione e la lista di abilitazione della fonte, la politica diventa aggirabile tramite una trasformazione intermedia. La possibilità di generare un riassunto non classificato di un documento riservato è una falla di sicurezza, non un’ottimizzazione.

Né la classificazione da ereditare è necessariamente uniforme lungo il documento: in un contratto l’allegato economico e il corpo delle clausole possono appartenere a classi di riservatezza diverse, e il frammento deve ereditare quella della sezione in cui nasce, non quella del file che lo contiene. Questo presuppone che, al momento dell’ingestione, la piattaforma riconosca le sezioni e vi associ gli attributi, così che la policy possa ragionare sul contenuto e non soltanto sul contenitore.

Come applicare le policy a RAG e knowledge graph

Dalle osservazioni che abbiamo fatto discende direttamente il profilo del linguaggio necessario. Deve basarsi su attributi (ABAC), perché il perimetro non è più strutturale, bensì descrittivo. Gli attributi del soggetto comprendono l’identità, l’appartenenza a gruppi, il ruolo, l’unità organizzativa, il team, le assegnazioni a progetti o pratiche, le abilitazioni;

quelli della risorsa comprendono la cartella o lo spazio documentale di origine con la relativa lista di abilitazione, il contesto di origine (cliente, progetto, commessa), la classe di riservatezza, la provenienza, lo stato (attivo, chiuso, archiviato), il tipo di nodo o di arco del grafo; quelli dell’azione distinguono recuperare, usare come contesto, citare, riassumere, attraversare un arco, invocare uno strumento; quelli del contesto comprendono la finalità dichiarata del compito, l’identità dell’agente che opera per conto dell’utente, il canale, l’orario.

Deve prevedere regole condizionali componibili con algoritmi espliciti di risoluzione dei conflitti, in modo che l’esito sia deterministico e, soprattutto, spiegabile a posteriori a chi non ha scritto la policy. Deve prevedere obblighi allegati alla decisione: redigere determinate categorie di dati, aggiungere un avviso, registrare l’accesso, chiedere conferma a un essere umano, limitare la risposta a una sintesi senza citazioni.

Nei sistemi agentici gli obblighi sono spesso più importanti del permesso o del diniego secco, perché il valore dell’assistente sta proprio nella via di mezzo fra “tutto aperto” e “tutto chiuso”. Deve imporre l’ereditarietà delle etichette ai contenuti derivati. E deve mantenere la separazione fra chi scrive la policy e chi la applica: l’organizzazione è l’autore, la piattaforma valuta e conserva le decisioni.

Dove applicare le policy nella pipeline agentica

Sul piano architetturale, i punti di applicazione nella pipeline sono almeno quattro. Prima del retrieval, filtrare gli indici e le partizioni interrogabili in base al soggetto e alla finalità, in modo che ciò che non può essere utilizzato non venga nemmeno cercato. È qui che si applica anche il livello di base, cioè il filtro derivato dalle liste di abilitazione delle cartelle di origine, ed è qui che si verifica se tali liste sono effettivamente sincronizzate con il sistema documentale e valutate in base all’identità dell’utente per conto del quale l’agente opera. Dopo il retrieval, per filtrare e trasformare i frammenti restituiti, ad esempio applicando la redazione.

Durante l’attraversamento del grafo, con un’autorizzazione a livello di arco, che è il punto in cui avviene il salto fra contesti. Prima della consegna, per applicare gli obblighi relativi alla risposta generata: avvisi, tracciamento delle fonti, blocco delle citazioni testuali non autorizzate. Tutto questo è indipendente dal modello linguistico: la policy governa ciò che entra nel contesto e ciò che esce nella risposta, non il modo in cui il modello ragiona. È una proprietà preziosa perché rende l’investimento nel motore di politiche indipendente dal ciclo di vita dei modelli, oggi misurato in mesi.

Chi costruisce queste piattaforme aggiunge un’avvertenza. La scorciatoia più diffusa sul mercato consiste nello scrivere la regola nelle istruzioni del modello, ad esempio: “non rivelare informazioni relative ad altri clienti”. Questo è molto fragile, per due ragioni. Un modello linguistico è un componente probabilistico, che rispetta l’istruzione quasi sempre, e un controllo degli accessi che funziona quasi sempre non è un controllo.

E un’istruzione può essere sovrascritta da un’altra istruzione, scritta dall’utente o nascosta in un documento recuperato: le linee guida OWASP per le applicazioni basate su LLM raccomandano infatti di non affidare al prompt di sistema il controllo dei comportamenti e di applicare i controlli di sicurezza al di fuori del modello. Il principio di progettazione che ne deriva è che ciò che l’utente non può usare non deve far parte del contesto. I primi tre punti di applicazione agiscono prima della generazione e possono essere implementati con codice deterministico: su di essi poggia la garanzia.

Il quarto agisce su un testo già generato e ha una natura diversa: può escludere con certezza una citazione testuale, confrontando la risposta con i frammenti di origine, ma non può escludere che la sostanza di un’informazione sia stata trasposta in una parafrasi. Chi scrive la policy deve saperlo.

Un secondo modello che rilegga la risposta alla luce della policy può segnalare una probabile fuga per parafrasi, e in un sistema che tratta informazioni riservate è opportuno che lo faccia; ma la sua segnalazione è un attributo, non una decisione: alimenta un obbligo, la conferma di una persona o la riduzione della risposta a una sintesi, e viene registrata insieme alla richiesta.

Il punto di decisione resta deterministico. Autorizzare l’azione “usare come contesto” significa accettare che quel contenuto si rifletta nella risposta, entro i limiti di forma fissati dagli obblighi; per questo, nell’esempio che segue, il muro verso le controparti nega l’uso come contesto e non la sola citazione.

Due dettagli di realizzazione determinano poi se il primo punto di applicazione funziona davvero. Il filtro va applicato all’interno della ricerca vettoriale e non sui suoi risultati: se si recuperano i dieci frammenti più simili e si scartano quelli non autorizzati, l’utente ottiene risposte povere proprio sui temi per cui esiste molto materiale riservato, e da quella povertà può dedurne l’esistenza.

La decisione del PDP deve quindi diventare un filtro che l’indice esegue nativamente. Inoltre, per l’utente, il diniego deve essere indistinguibile dall’assenza. Un assistente che risponde “esiste un documento pertinente, ma non posso mostrarlo” ha già rivelato ciò che la policy proteggeva: il motivo del diniego va nel log e non nella risposta.

Un esempio di policy ispirata ad ALFA

Vediamo ora un breve esempio, in una sintassi ispirata ad ALFA, per rendere il discorso più concreto. Immaginiamo un’organizzazione che svolge attività per conto di clienti diversi, alcuni dei quali possono trovarsi in conflitto d’interesse, e che voglia tre cose: impedire che nel contesto di lavoro per un cliente entrino contenuti provenienti da attività in cui quel cliente è controparte; consentire ai membri di un team di usare come contesto, ma non di citare testualmente, i materiali di altre attività dello stesso cliente; e rendere liberamente utilizzabile il know-how anonimizzato di attività concluse.

La prima politica traduce in linguaggio il livello di base descritto sopra: poiché il policyset applica il criterio del diniego prevalente, l’appartenenza alla lista della cartella di origine diventa una condizione necessaria ma non sufficiente, alla quale le politiche successive aggiungono vincoli di contesto. Una lista di controllo degli accessi non è dunque un modello alternativo al linguaggio di politiche, ma un suo caso degenere, che il linguaggio assorbe e rende verificabile insieme a tutto il resto.

Gli attributi, come context.controparti(…), sono forniti da un punto di informazione che interroga il gestionale dell’organizzazione o il knowledge graph. La prima regola, applicata a un arco del grafo che collega un’entità a due attività distinte, impedisce il passaggio nella direzione vietata, pur mantenendo il nodo visibile in entrambi i contesti. Si noti, poi, che la seconda politica distingue due azioni sullo stesso contenuto, “usare come contesto” e “citare testualmente”, permettendo l’una e vietando l’altra: è esattamente ciò che una lista di controllo degli accessi su una cartella non potrà mai esprimere.

Gerarchia delle fonti e copertura delle regole

Accanto alla decisione sull’accesso ce n’è una contigua, che oggi viene presa nello stesso modo implicito: quale fonte prevale quando le fonti autorizzate si contraddicono. Un assistente che lavora per uno studio o per una direzione legale attinge di norma a tre livelli: ciò che l’utente porta nella conversazione (documenti allegati o richiamati, istruzioni), il patrimonio dell’organizzazione (modelli, clausole, stile redazionale, regole interne) e la base di conoscenza generale fornita con la piattaforma.

Se la clausola tipo dello studio e quella generica divergono, qualcuno deve aver stabilito quale delle due prevale, e quel qualcuno non può essere l’ordinamento per somiglianza del motore di ricerca. Nelle piattaforme che alcuni di noi realizzano, la risposta è una gerarchia dichiarata: prevale il contesto dell’utente, poi il patrimonio dell’organizzazione, e la base generale interviene solo dove i primi due tacciono.

Anche qui la regola non è affidata soltanto a un’istruzione rivolta al modello: il recupero procede per livelli, senza mescolare nello stesso passaggio fonti di rango diverso, e, quando due fonti si contraddicono, l’assistente segue il livello superiore e lo segnala. In termini di XACML è un algoritmo di combinazione applicato all’autorità delle fonti anziché ai permessi.

Lo stesso caso mostra che la distinzione fra le azioni ha conseguenze sul prodotto: il patrimonio dell’organizzazione può essere messo a disposizione dell’assistente per tutti gli utenti, senza che questi possano consultarlo o modificarlo, cioè con “usare come contesto” consentito e “elencare”, “aprire” e “modificare” negati. Vale l’avvertenza già fatta: ciò che l’assistente può usare si riflette nelle risposte; quindi, in uno spazio di questo tipo va inserito ciò che l’organizzazione vuole vedere applicato, non ciò che deve restare segreto.

Chi scrive le politiche, in un’organizzazione, non è di norma un tecnico. Il linguaggio va quindi accompagnato da uno strato di authoring con modelli di policy precompilati, anteprima degli effetti e simulazione (“chi vedrebbe che cosa”), e da raccolte di policy predefinite per settore. Ma è essenziale che sotto l’interfaccia ci sia il linguaggio, perché è il linguaggio, non l’interfaccia, ad avere una semantica su cui un auditor può ragionare.

In questo strato, i modelli linguistici svolgono un ruolo utile, purché collocati al punto giusto dell’architettura. Un LLM può tradurre in policy formale una regola espressa in italiano, restituire in italiano il significato di una policy a chi ne risponde, generare i casi di test. Può anche porre domande che evidenzino i casi non previsti: un praticante assegnato a due pratiche dello stesso cliente può portare nell’una ciò che ha letto nell’altra? E un consulente esterno, a incarico concluso?

In molte organizzazioni le regole di riservatezza sono conoscenza tacita, note a tutti e non scritte da nessuna parte; scrivere le policy vuol dire, prima di tutto, esplicitarle, e per questo, in questo lavoro, interrogare le persone giuste rende più che analizzare i permessi esistenti. Il confine è uno solo: il modello può risiedere nel punto di amministrazione, ma mai nel punto di decisione. La singola richiesta va valutata da un motore deterministico, perché un esito che cambia a parità di condizioni non si può spiegare e, senza spiegazione, cade la ripartizione delle responsabilità che il linguaggio rende possibile.

Resta una funzione del punto di amministrazione che conviene non dare per scontata: verificare che le politiche caricate coprano davvero tutto ciò che la base di conoscenza contiene. Un motore di policy costruito sul modello XACML può rispondere a una richiesta anche “non applicabile”, quando nessuna regola la riguarda, oppure “indeterminato”, quando manca un attributo necessario a valutarla. Sono gli esiti più insidiosi, perché non sono decisioni: ciò che accade in quei casi lo stabilisce l’implementazione del punto di applicazione, e si torna alla situazione di partenza, in cui a decidere è il software.

Lo si vede già nell’esempio: un membro del team che chieda di riassumere un documento dello stesso cliente non ricade in alcuna regola, perché il perimetro di base esclude soltanto i non abilitati e la politica sullo stesso cliente disciplina soltanto l’uso come contesto e la citazione testuale. Non è un difetto dell’esempio ma la norma: nessun insieme di regole scritte a mano copre tutte le combinazioni al primo tentativo. In un sistema documentale, una lacuna del genere può restare inerte per anni; con un assistente che consulta tutto ciò che non gli è vietato, viene individuata alla prima domanda.

Servono quindi due cose. La prima è una regola di chiusura: il punto di applicazione tratta “non applicabile” e “indeterminato” come dinieghi, con obbligo di registrazione, così che ogni lacuna diventi visibile invece di restare silenziosa. La seconda è un’analisi di copertura, statica e deterministica, eseguita nel punto di amministrazione prima della pubblicazione di ogni versione della policy: enumera gli oggetti della base di conoscenza, le azioni e le classi di soggetti, e segnala ogni combinazione per cui la policy non produce una decisione definita, nonché ogni oggetto privo degli attributi da cui le regole dipendono.

Un frammento senza contesto di origine o senza classe di riservatezza rende indeterminate tutte le regole che lo richiamano: la copertura si misura sui metadati prima ancora che sulle regole. L’analisi va ripetuta a ogni modifica delle policy e a ogni crescita della base di conoscenza, perché una cartella nuova, un cliente nuovo o un nuovo tipo di nodo introducono valori di attributo che nessuna regola conosce. È il complemento della simulazione descritta sopra: quella mostra che cosa le regole fanno, questa mostra dove le regole non arrivano.

Audit delle policy di accesso e responsabilità sui sistemi RAG

Arriviamo così al punto da cui eravamo partiti: la compliance. Un motore di policy basato su questo modello produce, per ogni richiesta, una decisione riferibile a una versione identificata della policy, agli attributi valutati e agli obblighi eseguiti. Il log delle decisioni è l’equivalente, per i sistemi agentici, della lista di controllo degli accessi che si poteva stampare: un oggetto che esiste, che si può conservare con firma e marca temporale, e che si può esibire.

L’analogia con la lista stampabile regge a una condizione: che il registro tracci l’agente e non soltanto la persona. Un registro degli accessi documentali traccia le azioni delle persone: chi ha aperto quale file e quando. In un flusso agentico la richiesta dell’utente è soltanto l’inizio. A valle di essa l’agente compie, senza che nessuno le abbia richieste una per una, decine di azioni che toccano l’informazione: recuperi, attraversamenti di archi, invocazioni di strumenti, compattazioni del contesto in cui i contenuti vengono ridotti, scartati o anonimizzati.

Se il log registra soltanto la domanda e la decisione finale, resta senza risposta la domanda che conta, chi ha deciso che ciò fosse possibile, perché è proprio in quel tratto che un’informazione del contesto B entra nella risposta per il contesto A. L’agente va quindi trattato come un soggetto tracciato al pari dell’utente: ogni sua azione su informazione produce una voce di registro riferibile alla decisione di policy che l’ha consentita, all’utente per conto del quale operava e al compito dichiarato; e la traccia di ciò che è entrato nel contesto e di ciò che ne è stato escluso fa parte dell’evidenza quanto la risposta stessa.

Due condizioni rendono questo registro utilizzabile in sede di verifica. La prima è che sia prodotto dal codice che orchestra l’agente, non dal modello: un resoconto generato dal modello su ciò che ha fatto ha lo stesso statuto probabilistico di qualsiasi altro suo output. La seconda è che il registro sia, a sua volta, una risorsa protetta e, dove necessario, anonimizzata, perché documenta l’esistenza e la natura di ciò che la policy nasconde, e chi lo consulta deve essere soggetto alla policy come chiunque altro.

Non si tratta di un adempimento aggiuntivo: la registrazione degli eventi del sistema di IA è già tra i controlli che ISO/IEC 42001 prevede per chi gestisce sistemi di intelligenza artificiale in un’organizzazione; ciò che il linguaggio di policy aggiunge è il legame tra ogni voce del registro e la regola che l’ha autorizzata.

Le ragioni per cui questa evidenza è già oggi esigibile, e non un requisito futuro, sono di tre ordini.

GDPR, norme di settore e AI Act

Il primo è la protezione dei dati. Ai sensi del GDPR, l’organizzazione che utilizza l’assistente è titolare del trattamento e il fornitore, ai sensi dell’articolo 28, è responsabile e tenuto a trattare i dati esclusivamente su istruzione documentata del titolare. La regola che stabilisce quali dati di un contesto possono confluire nel trattamento di un altro contesto è un’istruzione del titolare: se non è espressa, il responsabile sta di fatto decidendo al posto del titolare, il che è precisamente la situazione che l’articolo 28 vuole evitare e che, nei casi più gravi, può portare a riqualificare il responsabile come titolare autonomo.

Si aggiungono i principi di limitazione della finalità e di integrità e riservatezza (articolo 5), l’obbligo di privacy by design e by default (articolo 25), che richiede che, per impostazione predefinita, siano trattati solo i dati necessari alla finalità specifica (requisito che la segmentazione in cartelle con soggetti abilitati soddisfa soltanto in parte, perché fissa chi può accedere, ma non per quale finalità né in quale forma), e le misure di sicurezza dell’articolo 32. Un log delle decisioni è inoltre il modo più diretto per dimostrare l’accountability richiesta dall’articolo 5, paragrafo 2, in una valutazione d’impatto.

Il secondo ordine di ragioni è settoriale, e varia da organizzazione a organizzazione: sono i vincoli deontologici e regolatori che impongono barriere informative interne. Le professioni organizzate in Ordini ne offrono l’esempio più evidente, con il segreto professionale e l’obbligo di astensione in caso di conflitto di interessi, esteso ai colleghi che collaborano nella stessa struttura; ma vincoli analoghi valgono per le barriere informative fra le funzioni di un intermediario finanziario, per la separazione fra reparti in un gruppo industriale che serve concorrenti, per la riservatezza dei dati clinici fra unità di una struttura sanitaria.

In Italia, per le professioni intellettuali, la legge 132/2025 impone all’articolo 13 di informare il cliente sull’uso di sistemi di IA: un’organizzazione che può dichiarare “il sistema applica regole di separazione definite dall’organizzazione stessa e ne conserva traccia” ha un’informativa molto più solida di una che non può farlo. Per i soggetti regolati, i requisiti di controllo degli accessi e di gestione dei fornitori ICT di NIS2 e DORA fanno sì che la domanda “come governate ciò che l’assistente può vedere?” arrivi in fase di due diligence, prima ancora che in fase di audit.

Merita una precisazione l’AI Act. Gli assistenti documentali per uso interno non rientrano, di regola, fra i sistemi ad alto rischio dell’allegato III, e, in ogni caso, il regolamento 2026/1744 (il cosiddetto Digital Omnibus) ha rinviato gli obblighi per tali sistemi al dicembre 2027, lasciando in vigore, dall’agosto 2026, gli obblighi di trasparenza dell’articolo 50 e le misure di alfabetizzazione dell’articolo 4. Ciò significa che la governance dell’accesso ai dati negli assistenti aziendali non è imposta dall’AI Act, ma dal GDPR e dalle norme di settore: è, cioè, già dovuta.

La ripartizione tra fornitore e organizzazione

Il terzo ordine di ragioni è quello che riteniamo più rilevante, e riguarda l’allocazione delle responsabilità. Oggi, se un assistente, nella risposta al contesto A, porta nella risposta un’informazione dal contesto B e da essa deriva un danno, la domanda “chi ha deciso che ciò fosse possibile?” non ha una risposta documentata: il comportamento è emerso dal retrieval. In quel vuoto, il liability gap di cui si discute nella letteratura sulla responsabilità dei sistemi algoritmici, la responsabilità tende a ricadere su chi ha costruito e gestisce il sistema, oppure viene contesa senza che nessuno possa provare nulla.

Con un linguaggio di policy, la situazione si capovolge in modo difendibile: il fornitore risponde dell’applicazione corretta delle regole, del meccanismo; l’organizzazione risponde del contenuto delle regole, della scelta. Il contratto può allora stabilire che la piattaforma applica le policy autorizzate dal cliente, che le policy predefinite fornite dal fornitore sono raccomandazioni adottate dal cliente sotto la propria responsabilità, e che i log delle decisioni costituiscono la prova dell’applicazione delle policy. È esattamente il modello che gli standard ABAC hanno formalizzato, separando amministrazione, decisione e applicazione, ed è la ragione per cui insistiamo sull’adozione del modello XACML e non su un semplice filtro sui metadati.

L’incapsulamento multi-tenant è responsabilità del fornitore di servizi e si dimostra tramite audit dell’infrastruttura; la policy intra-tenant è responsabilità dell’organizzazione e si dimostra tramite il log delle decisioni. Due evidenze distinte, relative a due obbligazioni diverse, che oggi vengono spesso confuse in un’unica, generica rassicurazione sulla “sicurezza dei dati”.

Policy per RAG: oltre le liste di accesso

Il valore di una piattaforma agentica collegata al patrimonio informativo di un’organizzazione risiede nella possibilità di riutilizzare in sicurezza la conoscenza accumulata. Senza politiche esplicite, la scelta è fra tutto aperto, che è rischioso, e tutto chiuso, che è inutile. Un linguaggio di policy basato su attributi, con obblighi e algoritmi di combinazione, applicato nei punti giusti della pipeline di retrieval e di attraversamento del grafo, offre la via di mezzo, dove sta il valore, e produce al contempo le evidenze richieste per la compliance e l’auditing.

Non si tratta di abbandonare le liste di abilitazione per cartella: sono il primo strato, vanno mantenute, sincronizzate con l’indice e verificate periodicamente. Si tratta di non fermarsi lì. E non serve inventare tutto da capo. L’esperienza di XACML, con i suoi successi e i suoi limiti, ci consegna un modello architetturale e semantico maturo, oggi riproposto in notazioni più leggibili.

Quello che manca è la sua estensione ai nuovi oggetti (frammenti, embedding, nodi e archi) e alle nuove azioni (usare come contesto, citare, riassumere, attraversare) introdotte dagli LLM, e la sua adozione da parte di chi costruisce piattaforme di IA per le organizzazioni come componente di prodotto, non come personalizzazione su richiesta. È un lavoro che coinvolge chi progetta i sistemi, chi ne risponde in sede regolatoria e le comunità di standardizzazione, e che, a nostro avviso, non può più essere rinviato.

Riferimenti su policy di accesso, RAG e XACML

• E. Damiani, S. De Capitani di Vimercati, S. Paraboschi, P. Samarati, “A Fine-Grained Access Control System for XML Documents”, ACM Transactions on Information and System Security, vol. 5, n. 2, 2002.
• OASIS, “eXtensible Access Control Markup Language (XACML) Version 1.0”, Committee Specification, 7 novembre 2002 (OASIS Standard, 18 febbraio 2003). Fra i contributori: E. Damiani e P. Samarati, Università degli Studi di Milano.
• OASIS, “eXtensible Access Control Markup Language (XACML) Version 3.0”, OASIS Standard, 22 gennaio 2013.
• OASIS, “Abbreviated Language for Authorization (ALFA) Version 1.0”, Working Draft.
• W3C, “ODRL Information Model 2.2”, W3C Recommendation, 2018.
• NIST, Special Publication 800-162, “Guide to Attribute Based Access Control (ABAC) Definition and Considerations”, 2014.
• Regolamento (UE) 2016/679 (GDPR), artt. 5, 25, 28, 32.
• Regolamento (UE) 2024/1689 (AI Act), artt. 4 e 50 e allegato III; Regolamento (UE) 2026/1744 (Digital Omnibus).
• Legge 23 settembre 2025, n. 132, “Disposizioni e deleghe al Governo in materia di intelligenza artificiale”, art. 13.
• Direttiva (UE) 2022/2555 (NIS2); Regolamento (UE) 2022/2554 (DORA).