L’assistente che risponde sui tuoi documenti ne tiene una seconda copia

Un assistente che «risponde sui tuoi documenti» non li legge nel momento in cui gli fai la domanda. Li ha letti prima, li ha tagliati a pezzi e di ogni pezzo ha conservato due cose: il testo e una lista di numeri che ne rappresenta il significato. Quella lista si chiama embedding; l’archivio che le contiene tutte si chiama indice vettoriale; cercare al suo interno si dice ricerca per similarità, perché la domanda viene trasformata nella stessa forma numerica e il sistema restituisce i pezzi i cui numeri le assomigliano di più. L’insieme di questi passaggi ha un nome che gira molto: RAG, generazione aumentata dal recupero.

Da questa descrizione, apparentemente innocua, segue il punto che interessa chi deve rispondere di quei documenti: l’indice è una seconda copia. Non è un collegamento al file originale né una vista filtrata del gestionale documentale: è un archivio nuovo, con permessi suoi, backup suoi, chiavi sue e cancellazioni sue. Trattarlo come un dettaglio di implementazione è il modo più rapido per scoprire, mesi dopo, che una copia dei contratti vive dove nessuno l’ha messa in procedura.

Una voce a sé nella lista dei rischi

La OWASP — la fondazione che da anni pubblica le liste dei difetti più diffusi nelle applicazioni, dal web ai modelli linguistici — dedica a questo strato una voce a sé nella Top 10 for LLM Applications, edizione «Version 2026»: è LLM09:2026 Vector and Embedding Weaknesses. Il documento la apre dicendo che questi difetti «present security risks in any LLM application that converts text, images, code, or audio» in rappresentazioni numeriche, e precisa che la differenza con la prompt injection è sostanziale: là si sfrutta l’obbedienza del modello alle istruzioni, qui la geometria dello spazio dei significati e la meccanica della ricerca. Due famiglie di problemi distinte, che si difendono in punti diversi del sistema.

Fra i sette esempi di rischio elencati, il primo è quello che in azienda si incontra prima degli altri: la perdita di dati fra clienti diversi dello stesso sistema. La formulazione è chirurgica: «similarity search frequently runs across the full index before access control is applied at the application layer». Cioè la ricerca passa su tutto l’archivio, e poi l’applicazione butta via quello che non spetta a chi ha chiesto. Se il filtro è scritto bene non succede nulla; se un percorso di codice lo salta, o se si limita a nascondere risultati già calcolati, le informazioni sono uscite dall’indice.

Il filtro che arriva dopo la ricerca

La prima contromisura dice dove va messo quel controllo: dentro l’interrogazione all’indice, non dopo, e validato dal servizio e non dal programma che chiama. La frase da ricordare è una: «A client-supplied scope is a suggestion, not a control». Un parametro che dice «cerca solo nei documenti del cliente Rossi», se arriva dal chiamante e nessuno lo verifica, è un buon proposito, non un confine.

La documentazione di un prodotto reale mostra la differenza meglio di qualunque spiegazione astratta. Per Azure AI Search, Microsoft documenta due modi di ottenere lo stesso risultato. Il primo è lo schema a filtri: «The security filter pattern simulates document-level authorization by using a regular OData filter», e la pagina avverte che «There’s no authentication or authorization through the security principal. The principal is just a string, used in a filter expression». È un filtro, non un’autenticazione: funziona finché l’applicazione lo applica «to every query», cioè finché nessuno dimentica un percorso.

Nel secondo il controllo sta nel servizio: il motore «validates the caller’s Microsoft Entra token on each request and trims result sets to only the documents the caller is authorized to read», e a quel punto «You don’t need to implement nested group resolution, multilevel ACL traversal, or post-query trimming in your application». La domanda da fare al fornitore non è dunque «i permessi sono rispettati?» — risponderanno sempre sì — ma «chi li verifica, il motore di ricerca o il vostro codice?». Sono due livelli di garanzia diversi.

Un dettaglio della stessa pagina vale una clausola contrattuale: le modifiche ai permessi nel sistema di origine «are only reflected in search results after that metadata is synchronized to the index». Togli a una persona l’accesso a una cartella e l’indice continua a considerarla autorizzata fino alla sincronizzazione successiva. Quanto duri quella finestra è una domanda da porre prima di firmare, non dopo un incidente.

Cancellare il documento non cancella il vettore

La quinta contromisura della voce LLM09 riguarda il ciclo di vita dell’archivio: cancellare gli embedding insieme ai documenti da cui derivano, proteggere i backup e cifrare a riposo, ricalcolare l’indice quando cambia il modello che produce i vettori. La prima è quella che si dimentica sempre. In molte installazioni «cancellare un documento» vuol dire togliere il file dalla cartella sorgente: i pezzi già indicizzati restano, l’assistente continua a citarli, e il documento risulta rimosso soltanto dove qualcuno guarda.

Si può obiettare che un vettore non è il documento, è una fila di numeri. La voce OWASP risponde con un esempio di rischio esplicito, l’inversione: «Stored embeddings can be inverted to recover source text». Non sempre, non con qualunque modello, non alla perfezione — ma la direzione è quella, e progettare dando per impossibile quell’operazione non è prudente.

Su questo tipo di valutazione il Comitato europeo per la protezione dei dati ha già ragionato, su un oggetto diverso. Il parere 28/2024, adottato il 17 dicembre 2024, riguarda i modelli addestrati su dati personali, non gli indici vettoriali, e afferma che «AI models trained on personal data cannot, in all cases, be considered anonymous»: perché un modello possa dirsi anonimo devono essere insignificanti sia «the likelihood of direct (including probabilistic) extraction of personal data» sia la probabilità di ottenerli, intenzionalmente o no, dalle interrogazioni. Applicare lo stesso criterio a un archivio di embedding è una mia estensione, non una posizione del Comitato; ma è il tipo di verifica che conviene fare, perché non chiede «questo artefatto è leggibile?», chiede «con mezzi ragionevolmente disponibili se ne possono ricavare dati personali?». Se la risposta è sì, quell’archivio va governato come i documenti da cui proviene, non come una cache.

Avvelenare l’indice invece del prompt

L’altra metà della voce riguarda chi scrive nell’indice, non chi lo interroga. Il terzo esempio di rischio è l’avvelenamento al momento del recupero: un attaccante «can craft content whose embedding lands close to a target query», cioè fabbrica un documento che verrà pescato quando si fa una certa domanda e che il modello tratterà come contesto attendibile. Variante più sottile, elencata subito dopo: il retrieval jamming, un documento inserito perché il sistema risponda di non sapere. Chi legge la risposta evasiva pensa che l’informazione non ci sia; è stata coperta.

La contromisura qui non è tecnologica ma organizzativa, ed è la terza dell’elenco: non mescolare in un unico indice contenuti con livelli di fiducia diversi. Se nello stesso archivio finiscono le procedure interne, le mail dei clienti e le pagine raccolte dal web, la domanda «chi ha scritto questo pezzo di contesto» non ha più risposta — e la provenienza di ogni embedding, altra contromisura esplicita, è ciò che permette di rispondere dopo.

Due accorgimenti minori costano poco: non restituire a chi interroga i punteggi di similarità grezzi — «Do not return raw similarity scores to clients» — perché quei numeri dicono se un documento sta nell’indice anche senza mostrarlo; e trattare le chiavi dell’API di embedding come segreti, dato che «A leaked key gives an attacker query access to your exact encoder».

Le domande da fare a chi ti vende l’assistente

Queste sei domande non sono un protocollo OWASP: traducono le contromisure appena viste in cose che un fornitore può rispondere per iscritto e che nessuna demo mostra.

1. L’indice vettoriale dove si trova, in che Paese, e di chi è il contratto?
2. Il filtro sui permessi è dentro l’interrogazione all’indice o è un
   filtro applicato dopo, nel vostro codice applicativo?
3. Chi valida l’identità di chi fa la domanda: il motore di ricerca
   o il programma che lo chiama?
4. Se revoco a una persona l’accesso a una cartella, dopo quanto tempo
   l’indice ne tiene conto?
5. Se cancello un documento, quando sparisce il suo embedding —
   e dai backup?
6. Clienti diversi condividono lo stesso indice? Se sì, la separazione
   è un campo nei dati o sono archivi distinti?

Le risposte utili sono verificabili: un nome di regione, un numero di minuti, un sì o un no. «È tutto cifrato e sicuro» non è una risposta a nessuna delle sei.

Cosa puoi fare

Se hai già un assistente che risponde sui tuoi documenti, la prima cosa da fare non richiede strumenti: scrivi l’elenco di cosa è stato indicizzato e confrontalo con l’elenco di cosa credevi fosse indicizzato. I due elenchi non coincidono quasi mai, perché il caricamento iniziale si fa in fretta e poi nessuno lo rilegge. Poi prova la domanda scomoda: chiedi all’assistente qualcosa che riguardi un cliente o un reparto a cui l’utenza con cui sei entrato non dovrebbe accedere. Non è un test di sicurezza serio, ma in cinque minuti distingue un sistema che filtra da uno che non filtra.

Se l’assistente lo devi ancora comprare, le sei domande qui sopra vanno in trattativa, non nel collaudo. Se lo stai costruendo, le due decisioni da prendere subito sono la separazione per livello di fiducia — un indice per i documenti interni, un altro per quello che arriva da fuori — e la cancellazione, cioè la procedura che toglie un pezzo dall’indice quando il documento viene eliminato. Aggiungerla dopo significa ricostruire l’archivio, operazione che nessuno autorizza quando il sistema funziona.

Una nota di onestà: niente di tutto questo è stato provato su un prodotto in questa redazione. I comportamenti di Azure AI Search vengono dalla documentazione Microsoft, non da un ambiente attivo, e i rischi dalla voce LLM09 del documento OWASP. Il valore qui non sta in una prova, sta nelle domande: sono quelle che un’offerta ben fatta sa reggere.