RAG e Diritto alla Cancellazione: l'Art. 17 GDPR nei Database Vettoriali

Fonti: Reg. UE 2016/679 (GDPR) Art. 17 · Reg. UE 2024/1689 (AI Act) Art. 26 · EDPB: Guidelines on AI models and personal data (2025) · EDPS — TechSonar 2025 (RAG, Machine Unlearning) · Morris et al., "Text Embeddings Reveal (Almost) As Much As Text" (Cornell, 2023) · Legge 23 settembre 2025, n. 132

La Retrieval-Augmented Generation (RAG) è ormai l'architettura dominante per i prodotti B2B basati su AI generativa: invece di affidarsi alla sola conoscenza "memorizzata" nel modello, il sistema recupera in tempo reale i documenti aziendali rilevanti e li passa al modello per generare la risposta. Questo riduce le allucinazioni e ancora le risposte a fonti verificabili, ma sposta il baricentro del rischio privacy sull'infrastruttura backend.

Il flusso di ingestione frammenta i documenti in segmenti (chunking), li converte in vettori tramite un modello di embedding e li indicizza in un database vettoriale (Pinecone, Weaviate, Qdrant, o l'estensione pgvector per PostgreSQL). Il problema emerge quando un interessato esercita il diritto alla cancellazione ex Art. 17 GDPR. In un database relazionale si risolve con una DELETE e qualche vincolo ON DELETE CASCADE. In un database vettoriale, il dato è stato disperso in molti chunk all'interno di un grafo di prossimità multidimensionale, e rimuoverlo davvero, senza degradare le performance di ricerca, è una sfida che la letteratura tecnica descrive come complessa e costosa.

Questa guida analizza perché gli embedding sono dati personali, perché la cancellazione "ovvia" spesso non cancella nulla, e quali quattro pattern architetturali rendono l'adempimento sostenibile. Per la mappatura dei trattamenti nella pipeline RAG si veda la guida alla DPIA per sistemi RAG e IA generativa; per il quadro integrato GDPR + AI Act, la guida alle architetture di compliance per SaaS e startup.

Perché un embedding è (quasi sempre) un dato personale

Il malinteso più diffuso nelle pipeline ML enterprise è trattare l'embedding come una funzione di hash o un meccanismo di anonimizzazione. L'idea è che, trasformando un curriculum o una cartella clinica in un vettore denso (ad esempio i 1536 valori in virgola mobile restituiti da text-embedding-3-small di OpenAI), il dato originale sia de-identificato in modo irreversibile. Non è così.

I modelli di embedding non distruggono l'informazione: la conservano. Per costruzione, mappano testi semanticamente simili in punti geometricamente vicini, e questo richiede di preservare il contenuto semantico originale. La ricerca lo ha dimostrato: nel lavoro "Text Embeddings Reveal (Almost) As Much As Text" (Morris, Kuleshov, Shmatikov, Rush, Cornell, 2023), il metodo Vec2Text ricostruisce il testo di partenza a partire dal solo vettore, recuperando in modo esatto circa il 92% dei testi da 32 token con un approccio iterativo di correzione. Il modello di minaccia è realistico: all'attaccante non servono i pesi del modello, basta sapere quale API di embedding è stata usata e avervi accesso in query.

Questo è ciò che si intende quando si dice che la "permanenza" semantica degli embedding rende fragile ogni pretesa di anonimizzazione: una volta vettorizzata, l'informazione resta ricostruibile. Di conseguenza, gli embedding che derivano da informazioni relative a persone fisiche identificate o identificabili rientrano nella definizione di dato personale dell'Art. 4, par. 1 GDPR. Trattarli come artefatti di sistema privi di sensibilità, senza audit log, talvolta senza cifratura a riposo, è una scelta a rischio.

L'attenzione delle autorità sul trattamento di dati personali nei sistemi di AI generativa è alta. Il Garante ha sanzionato Luka Inc., società che gestisce il chatbot Replika, con 5 milioni di euro (provvedimento del 19 maggio 2025) per assenza di base giuridica, informativa inadeguata e mancata verifica dell'età. Va citato con precisione anche il caso OpenAI/ChatGPT: la sanzione da 15 milioni del Garante (dicembre 2024) è stata annullata dal Tribunale di Roma con sentenza n. 4153/2026 per sproporzione, quindi non costituisce oggi un precedente fermo, ma il principio che il GDPR si applica al trattamento dei dati per l'addestramento e l'indicizzazione non è in discussione.

La conseguenza operativa è netta: quando un interessato esercita l'Art. 17, il titolare non può limitarsi a cancellare il record testuale nei sistemi di origine. L'obbligo si estende alla rimozione effettiva e verificabile di tutti i vettori derivati da quel documento e presenti nel vector store. Mantenerli in produzione equivale a trattare dati personali senza base giuridica.

Il problema dell'Art. 17 in un vector database: cosa cancelli davvero?

C'è una distanza tra ciò che restituisce l'API del database e ciò che resta sullo storage fisico. L'Art. 17 GDPR, letto secondo il principio di effettività, richiede che la cancellazione sia reale, non una semplice rimozione dalla lista dei risultati mostrati all'utente.

Perché la cancellazione istantanea è difficile: l'algoritmo HNSW. I motori vettoriali ad alta efficienza (Weaviate, Qdrant, Milvus, pgvector) si appoggiano in larga parte all'indice HNSW (Hierarchical Navigable Small World). A differenza di un B-Tree, HNSW costruisce un grafo multi-livello in cui ogni nodo è un vettore collegato a un numero definito di vicini (parametro m). Una query naviga il grafo con una discesa "greedy" dai livelli più sparsi fino al vicinato locale, garantendo ricerche sub-millisecondo su corpus enormi. Il rovescio è la rigidità topologica: rimuovere fisicamente un nodo in tempo reale reciderebbe gli spigoli che lo attraversano, frammentando il grafo e degradando recall e velocità.

Il pattern soft-delete (tombstoning). Per non pagare questo costo a ogni cancellazione, quasi tutti i vector store usano il "soft-delete". Quando si invoca l'eliminazione di un ID, il motore non sovrascrive il vettore sul disco: aggiorna una struttura di metadati applicando un flag (tombstone) all'ID. Le query successive continuano ad attraversare il nodo come "ponte" verso altre aree del grafo, ma lo escludono dai risultati restituiti. Il vettore resta quindi fisicamente allocato e leggibile a livello di file binario finché non interviene un processo di pulizia.

Sotto il profilo GDPR, affidarsi al solo soft-delete genera due problemi concreti:

• Persistenza sullo storage. Chi accede ai file dell'indice (ad esempio i dump del volume PostgreSQL o i file dell'indice) può estrarre i vettori marcati come cancellati e tentarne l'inversione con tecniche come Vec2Text, recuperando il testo in chiaro. La rimozione applicativa non protegge il dato a livello di storage.
• Violazione della limitazione della conservazione. Trattenere i dati oltre il necessario, mascherandoli solo a livello applicativo per preservare le performance, è in tensione con l'Art. 5(1)(e) e con l'effettività dell'Art. 17.

In sintesi: la cancellazione "ovvia" tramite API, da sola, in molti motori non soddisfa l'Art. 17. Serve un'architettura che porti l'eliminazione fino allo storage fisico.

Quattro scelte architetturali che rendono la cancellazione possibile

Il principio di privacy by design (Art. 25 GDPR) impone di prevedere questi meccanismi già in fase di progettazione. Esistono quattro pattern, con costi e compromessi diversi.

1. Metadati per-chunk e lineage deterministica

La precondizione di qualsiasi cancellazione mirata è la tracciabilità granulare del dato. Quando un documento lungo viene segmentato in decine di chunk, ogni vettore risultante deve ereditare nei propri metadati i riferimenti univoci alla sorgente. L'antipattern è salvare il vettore con il solo testo grezzo e un ID autogenerato: in quel caso, alla richiesta di cancellazione, il team è costretto a un recupero euristico per similarità, esposto a falsi positivi (si cancella il dato di terzi) e falsi negativi (si lascia il dato da rimuovere, violando l'Art. 17).

La soluzione è un payload di metadati rigoroso:

Attenzione a una gotcha rilevante. Non tutti i motori permettono di cancellare filtrando per metadato. Su Pinecone serverless e Starter, la cancellazione per metadata filter non è supportata e restituisce un errore esplicito ("Serverless and Starter indexes do not support deleting with metadata filtering"). Le strade corrette sono due: cancellare per ID prefix (strutturando gli ID in modo gerarchico, ad esempio user12345#docA#chunk1, così da poter eliminare in blocco tutti i chunk di un soggetto) oppure cancellare un intero namespace (vedi punto 2). Su motori come Weaviate o Qdrant, invece, il filtro sui metadati in cancellazione è disponibile. Verificare il comportamento del proprio motore prima di promettere all'interessato una cancellazione "chirurgica" è parte della due diligence tecnica.

2. Namespace, multi-tenancy fisica e sharding

Nel SaaS B2B l'infrastruttura ospita i dati di più aziende clienti (tenant). Un'architettura "flat", in cui i vettori dell'azienda A convivono nello stesso spazio di quelli dell'azienda B, espone a leak cross-tenant indotti da query ambigue e rende le cancellazioni in blocco onerose. La prassi è l'isolamento strutturale tramite namespace o shard dedicati.

In Pinecone, assegnare un namespace distinto per cliente isola i dati a livello di backend: alla cessazione del rapporto o a una richiesta di cancellazione globale, si elimina l'intero spazio con index.delete(delete_all=True, namespace="tenant1") (comportamento deleteAll disponibile dalle versioni di API 2025-04 in poi). L'operazione è asincrona, rapida e aggira le criticità del grafo HNSW perché distrugge i dati a un livello di astrazione superiore rispetto ai singoli nodi.

Weaviate spinge il concetto più in profondità con la multi-tenancy nativa: assegna a ciascun tenant uno shard fisico isolato all'interno della collezione, con indice HNSW, indici invertiti e file di metadati separati. Questo consente di disattivare temporaneamente (offload) un tenant per risparmiare RAM, o di eliminarlo distruggendo lo shard associato. La compartimentazione rende gli audit trail più trasparenti e riduce il rischio di contaminazione in fase di retrieval.

3. Soft-delete gestito: compaction asincrona e re-indexing

Quando la logica di business impone cancellazioni puntuali all'interno di un grande indice HNSW condiviso (es. rimuovere un singolo individuo da un corpus documentale), bisogna gestire le "scorie" del soft-delete con procedure di garbage collection, compaction e ricostruzione dell'indice.

Con pgvector, gli indici HNSW non recuperano automaticamente lo spazio su disco quando i vettori vengono cancellati: i nodi tombstoned restano nel grafo, generando index bloat (più consumo di RAM e progressiva erosione dell'accuratezza). Perché l'eliminazione diventi effettiva, gli amministratori devono pianificare routine che eseguano REINDEX INDEX CONCURRENTLY: il comando ricostruisce un nuovo grafo HNSW leggendo i dati aggiornati, senza acquisire lock esclusivi che bloccherebbero le scritture in produzione, e solo al termine sostituisce l'indice compromesso liberando lo spazio. È un'operazione costosa: su tabelle con milioni di righe a 1536 dimensioni può richiedere ore, e maintenance_work_mem va dimensionato con cura per evitare che la costruzione del grafo finisca su disco, degradandone la qualità. Un pattern append-only affiancato da partizionamento e job notturni di reindicizzazione è la via praticabile per pgvector in scenari regolamentati.

I motori purpose-built gestiscono la criticità a livello di algoritmo. Weaviate include un processo asincrono di pulizia dei tombstone nel grafo HNSW, attivato periodicamente dal parametro cleanupIntervalSeconds: un pool di thread analizza i nodi marcati, riconnette i nodi superstiti per preservare la topologia e rimuove i tombstone da memoria e disco. La variabile TOMBSTONE_DELETION_CONCURRENCY (dalla v1.24, con default pari a metà dei core CPU disponibili) consente di calibrare il carico di pulizia per ciclo, così che la cancellazione diventi fisicamente definitiva nel giro di pochi cicli, in modo trasparente per il team.

4. Crypto-shredding ed envelope encryption (KMS)

Il pattern più robusto sul piano dello storage anticipa la protezione prima dell'indicizzazione, applicando i principi del machine unlearning preventivo tramite crittografia.

La tecnica del crypto-shredding si combina con l'envelope encryption: ogni documento (o, meglio, ogni chunk) viene cifrato con una chiave dati simmetrica (DEK) generata dinamicamente; le DEK sono a loro volta cifrate da una chiave primaria (KEK) custodita in un Key Management Service (AWS KMS, Google Cloud KMS, HashiCorp Vault). I vettori non vengono mai scritti in chiaro: si usa cifratura autenticata (AEAD, es. AES-256-GCM) che unisce confidenzialità e integrità.

Soluzioni progettate nativamente per la ricerca su dati cifrati, ad esempio CyborgDB (che trasforma backend come PostgreSQL o Redis in vector store cifrati), mostrano che è possibile eseguire ricerche di similarità (ANN) direttamente sul ciphertext, mantenendo le chiavi nel KMS del cliente e operando in logica zero-knowledge.

Il vantaggio sul fronte Art. 17: alla richiesta dell'interessato non serve manipolare il grafo HNSW né schedulare re-index massivi. Si revoca e si distrugge la chiave (DEK) associata a quell'utente nella console del KMS. Da quel momento i frammenti vettoriali cifrati sul disco diventano illeggibili (il ciphertext non è più decifrabile) in modo crittograficamente robusto e documentabile. Questo approccio neutralizza anche i tentativi di inversione e attenua i nodi del Capo V sullo storage cloud (vedi più avanti). Resta un trade-off: la gestione del ciclo di vita delle chiavi e l'overhead computazionale vanno progettati e testati.

RAG, AI Act e Legge 132/2025: il nuovo livello di accountability

I pattern visti sopra rispondono al GDPR. A questo si aggiungono due interventi normativi che alzano l'asticella della responsabilità: il Regolamento (UE) 2024/1689 (AI Act) e la Legge 23 settembre 2025, n. 132 (in vigore dal 10 ottobre 2025).

AI Act: log e dicotomia provider/deployer. Per i sistemi ad alto rischio dell'Allegato III, il corpo principale degli obblighi diventa pienamente applicabile dal 2 agosto 2026 (salvo lo slittamento condizionato in discussione con il "Digital Omnibus", non ancora adottato: prudente pianificare sulle scadenze originarie). Nella maggior parte dei casi una software house che assembla un RAG su modelli di terzi agisce come deployer. Qui si annida un nodo pratico: l'Art. 26(6) impone al deployer di conservare i log generati automaticamente dal sistema per un periodo adeguato e comunque non inferiore a sei mesi (è l'obbligo runtime del deployer; l'Art. 12 è invece l'obbligo, in capo al provider, di progettare il sistema in modo che sia capace di logging automatico). Se i log di interazione contengono dati personali (le query, il contesto recuperato, il prompt risultante), questa retention può collidere con le richieste di cancellazione tempestiva dell'Art. 17 GDPR. La via di equilibrio è la pseudonimizzazione all'ingresso (redaction pre-prompting), così da soddisfare la tracciabilità richiesta dall'AI Act senza inquinare i log con dati identificativi. Per il dettaglio degli obblighi si veda la guida all'Art. 26 AI Act e gli obblighi del deployer e a provider vs deployer.

Legge 132/2025 e machine unlearning. La norma italiana raccorda l'AI Act all'ordinamento, amplia il perimetro della DPIA (Art. 35 GDPR) ai rischi da bias algoritmico e, sul piano penale, introduce all'art. 612-quater c.p. il reato di diffusione illecita di contenuti generati o alterati con l'AI (reclusione da uno a cinque anni, procedibile a querela), con impatti anche sui modelli organizzativi 231. Per i sistemi RAG il punto critico emerge quando il prodotto non si limita al retrieval statico ma include meccanismi di fine-tuning o re-ranking che apprendono dai feedback: in quel caso il dato si "fonde" nei pesi del modello, e la sola rimozione del vettore non basta. Il machine unlearning è l'insieme delle tecniche per forzare un modello a neutralizzare l'apporto di uno specifico dataset senza riaddestrarlo da zero. L'EDPS, nel report TechSonar 2025, ha incluso sia la RAG sia il machine unlearning tra le tecnologie da monitorare, segnalandone anche i rischi collaterali (ad esempio il catastrophic forgetting, il degrado delle prestazioni quando l'unlearning è troppo aggressivo). Dove il modelo apprende dai dati dell'utente, la documentazione di processi di rimozione verificabili diventa parte dell'accountability.

RAG in outsourcing: il nodo dei trasferimenti extra-UE (Capo V)

Progettare bene la componente vettoriale non esaurisce i rischi. Nel report TechSonar 2025 l'EDPS ha richiamato l'attenzione sulle vulnerabilità dei RAG erogati in outsourcing ("RAG-as-a-service"). Costruire modelli di embedding, infrastrutture di fine-tuning e database HNSW su larga scala richiede investimenti elevati: questo spinge molte aziende a esternalizzare la logica core tramite API di terzi. Di conseguenza, contenuti riservati (contratti, email, storico sanitario) vengono inviati fuori dal perimetro per la vettorizzazione e depositati in vector store cloud gestiti.

Quando un testo con dati personali viene inviato a un fornitore di modelli con sede negli USA, si perfeziona un trasferimento transfrontaliero disciplinato dal Capo V GDPR. Se il data center o l'infrastruttura serverless sono soggetti a normative di sorveglianza extraterritoriali (Cloud Act, FISA 702), il titolare deve valutare l'adeguatezza del trasferimento secondo la giurisprudenza Schrems II, adottando Standard Contractual Clauses (SCC) e un Transfer Impact Assessment (TIA) documentato.

A questo si aggiunge la superficie d'attacco del retrieval. Un vector store centralizzato aggrega documenti di reparti diversi; se l'interfaccia interroga il database senza propagare i permessi dell'utente (controlli di accesso a livello di metadati pre-query), il sistema è esposto. In particolare, tecniche di indirect prompt injection (istruzioni occulte nascoste in documenti esterni) possono indurre il modello ad aggirare i filtri e restituire documenti a cui l'utente non dovrebbe accedere. Per questo il DPA con il fornitore (Art. 28 GDPR) e i controlli di accesso vanno definiti esplicitamente: la responsabilità di conformità resta in capo al titolare/deployer e non si trasferisce all'infrastruttura tecnica di terzi.

Sintesi operativa

Integrare AI generativa in applicazioni B2B nel 2025-2026 va oltre la chiamata a una libreria o a un'API. La conversione in vettore preserva l'impronta semantica del dato, espone agli attacchi di inversione e qualifica gli embedding come dati personali; i motori HNSW tendono a eludere la cancellazione effettiva con il soft-delete. Per gestire l'Art. 17 in modo difendibile, la roadmap per CTO e team backend è:

• Lineage e data mapping deterministici. Metadati rigorosi per ogni chunk (incluso un data_subject_id pseudonimizzato), verificando però come il proprio motore supporta la cancellazione (per ID prefix, per namespace o per filtro su metadati).
• Isolamento fisico. Namespace o shard per tenant, per circoscrivere i leak e consentire l'eliminazione in blocco dei dati di un cliente.
• Gestione del motore vettoriale. REINDEX CONCURRENTLY e routine di compaction per pgvector; affidamento alla pulizia asincrona dei tombstone per motori dedicati come Weaviate.
• Crypto-shredding dove serve maggiore robustezza. Envelope encryption sui payload o vector store cifrati: la distruzione della chiave nel KMS rende il ciphertext illeggibile e affronta anche i nodi del Capo V sullo storage cloud.
• Compliance AI Act e machine unlearning. Log dell'Art. 26(6) privi di PII (via pseudonimizzazione), e, dove il modello apprende dai dati, processi documentati di rimozione verificabile, in linea con la Legge 132/2025.

Con la piena applicazione dell'AI Act prevista per agosto 2026, progettare l'oblio come funzionalità infrastrutturale, e non come eccezione da gestire a posteriori, è parte della qualità stessa del prodotto.

Articolo aggiornato al 27 giugno 2026. Le disposizioni citate fanno riferimento al Regolamento (UE) 2016/679 (GDPR), al Regolamento (UE) 2024/1689 (AI Act) e alla Legge 23 settembre 2025, n. 132. Per supporto specifico, contatta lo studio.