RAG și GDPR: securitate și protecția datelor personale

Un sistem RAG nu e doar o bază de date cu un LLM deasupra ei. Din perspectiva securității RAG și GDPR, arhitectura introduce patru suprafețe noi prin care pot ieși date personale: corpusul de documente, vectorii de embeddings, modelul terț care generează răspunsul și pasul de retrieval, care decide la runtime — pe bază de similaritate semantică, nu de reguli explicite de acces — ce ajunge în context.

Miza nu e teoretică. Art. 83(5) din GDPR permite amenzi de până la 20 de milioane de euro sau 4% din cifra de afaceri globală anuală, oricare valoare e mai mare; Art. 83(4) prevede un prag mai mic, 10 milioane de euro sau 2%, pentru încălcări mai puțin severe. Din decembrie 2023, Curtea de Justiție a UE a clarificat, în cazul Volkswagen (C-807/21), că acest plafon se calculează pe cifra de afaceri a întregului grup economic, nu doar a entității tehnic responsabile.

Dacă arhitectura ta gestionează date personale prin RAG, fiecare din cele patru suprafețe cere un răspuns concret — nu un principiu general.

De ce un sistem RAG e alt profil de risc GDPR decât o aplicație CRUD

O aplicație CRUD clasică ține datele personale într-un singur loc, cu un model de acces clar: un rând într-un tabel, un user_id, un set de permisiuni verificate la citire. Un RAG rupe tiparul ăsta în trei feluri.

Primul: duplicarea. Același fragment de text ajunge, de regulă, în cel puțin trei locuri — documentul sursă, indexul de vectori și, adesea, un cache de răspunsuri sau de embeddinguri intermediare. O cerere de ștergere care golește doar tabelul principal lasă două copii în urmă.

Al doilea: reprezentarea. Datele personale nu mai stau doar ca text simplu — sunt codificate în vectori numerici (embeddings), pe care mulți arhitecți îi tratează, greșit, ca pe o formă abstractă și „sigură" a informației. Nu e cazul — vezi secțiunea despre inversarea embeddingurilor mai jos.

Al treilea: accesul decis la runtime. Într-un CRUD, permisiunile se aplică la scriere sau la interogare, cu reguli explicite. Într-un RAG, pasul de retrieval alege ce ajunge în context pe bază de similaritate semantică — un mecanism optimizat pentru relevanță, nu pentru izolare. Fără un strat suplimentar de control de acces, un chunk dintr-un document confidențial poate ajunge în răspunsul unui utilizator care n-ar trebui să-l vadă niciodată, doar pentru că e semantic apropiat de întrebarea lui.

Fiecare din cele patru suprafețe de mai jos cere un răspuns concret — parte din seria mai largă despre RAG în producție.

Cei patru vectori de scurgere a datelor personale într-un RAG

Patru puncte din pipeline pot scurge date personale, fiecare cu un profil de risc diferit.

Corpusul

Documentele sursă conțin, adesea nedetectat, date personale — nume în contracte, adrese de email în ticket-uri de suport, CNP-uri în formulare scanate. Dacă indexarea le ingerează fără o etapă de detecție, orice PII din corpus ajunge, garantat, în index.

Strategia de chunking contează și ea aici — modul în care tai documentele în fragmente determină cât de izolat sau de răspândit rămâne un fragment cu date personale prin index.

Embeddings

Embeddingurile nu sunt o formă ireversibilă de anonimizare. Song și Raghunathan au arătat în 2020, la CCS, că un atac de inversare recuperează 50-70% din cuvintele textului original dintr-un embedding de propoziție (F1 între 0,5 și 0,7).

Trei ani mai târziu, Morris și colegii au dus tehnica mai departe cu Vec2Text (EMNLP 2023): prin corecție iterativă, metoda reconstruiește exact 92% dintre texte de 32 de tokeni (BLEU 97,3), iar pe note clinice din setul MIMIC-III recuperează 89% dintre numele complete ale pacienților. Testele originale au fost făcute pe GTR-base și pe text-embedding-ada-002 de la OpenAI; lucrări ulterioare au extins rezultatul și la familia sentence-transformers (all-MiniLM), deși nu în paper-ul inițial.

Concluzia practică: un embedding stocat într-un index nu e mai puțin sensibil decât textul din care a fost derivat.

Modelul terț

Dacă folosești un LLM prin API extern pentru generarea răspunsului, datele din context — inclusiv fragmentele PII recuperate prin retrieval — trec prin infrastructura furnizorului. Politicile de reținere diferă sensibil între furnizori:

• OpenAI: reține implicit datele din API până la 30 de zile, pentru monitorizare anti-abuz; nu antrenează pe ele implicit; zero data retention e disponibil doar pentru clienți enterprise eligibili, aprobați caz cu caz — nu e self-service.
• Anthropic: nu reține conținutul conversațiilor din API implicit (excepție: „Covered Models", unde reținerea e de 30 de zile); datele reținute nu se folosesc niciodată pentru antrenare fără permisiune expresă; zero data retention e disponibil la cerere, per organizație.
• Azure OpenAI: Microsoft confirmă că prompturile, răspunsurile și embeddingurile nu ajung la OpenAI sau la alți furnizori și că niciun model nu se antrenează fără permisiune explicită; opțiunea „modified abuse monitoring" dezactivează fereastra de retenție pentru sarcini sensibile aprobate; rezidența regională e configurabilă.

Verifică însă clauzele exacte de retenție înainte de a semna un DPA — cifrele se schimbă des.

Retrieval fără control de acces

Cel mai frecvent vector, și cel mai ușor de reparat: un index de vectori partajat între utilizatori sau tenanți, interogat fără niciun filtru de permisiuni. Motorul de similaritate nu știe și nu-i pasă cine întreabă — găsește chunk-ul cel mai apropiat semantic, indiferent cui aparține.

Fără un strat explicit de control de acces la retrieval, cel mai relevant fragment cu datele personale ale altcuiva ajunge direct în răspunsul tău. Secțiunea de mai jos arată exact unde se aplică filtrul.

Redactare și detecție PII la ingestie

Cel mai eficient punct de intervenție e înainte ca datele să ajungă în index, nu după. Detecția PII la ingestie combină, de regulă, trei tehnici: reguli bazate pe expresii regulate (CNP-uri, IBAN-uri, adrese de email au formate previzibile), modele NER (named entity recognition) pentru nume și locații, și validare prin checksum pentru identificatori structurați.

Presidio, proiectul open-source al Microsoft, combină toate trei — dar chiar autorii lui avertizează explicit că nu e infailibil și că are nevoie de sisteme suplimentare pentru acoperire completă.

Alegerea concretă de tooling contează mai puțin decât principiul: fără o etapă dedicată de detecție și redactare (sau tokenizare reversibilă, pentru cazurile în care ai nevoie să recuperezi valoarea originală) înainte de embedding, orice PII din corpus ajunge, fără excepție, în index. Dacă implementezi pipeline-ul cu Next.js și Vercel AI SDK, etapa de redactare intră cel mai natural ca pas separat înainte de apelul de embedding, nu ascunsă în route handler-ul de retrieval.

Control de acces la retrieval: cum eviți scurgerea de date între utilizatori

Modelul clasic de RAG tratează indexul de vectori ca pe o singură colecție interogabilă de oricine. Corect e opusul: retrieval-ul trebuie să respecte aceleași granițe de acces ca restul aplicației.

Control la nivel de document. Fiecare chunk poartă metadate de proprietate (user_id, tenant_id, nivel de clasificare). Interogarea de similaritate se aplică doar pe sub-setul filtrat — pre-filtrare, nu post-filtrare, altfel motoarele ANN (approximate nearest neighbor) pot întoarce mai puține rezultate decât ai cerut dacă filtrezi după căutare.

Izolare multi-tenant la nivel de colecție. Pentru cerințe stricte de separare — clienți enterprise cu clauze contractuale de izolare, de exemplu — fiecare tenant primește propria colecție sau namespace în vector store, nu doar un filtru de metadate într-o colecție comună. Costă mai mult operațional, cu mai multe colecții și indexuri separate de gestionat, dar elimină clasa întreagă de bug-uri de tip „filtru uitat undeva în cod".

Dreptul la ștergere într-un vector store: ce cere GDPR și ce oferă tehnologia

Art. 17 din GDPR dă persoanei vizate dreptul de a cere ștergerea datelor sale personale. Într-un vector store, „ștergere" înseamnă altceva decât într-o bază de date relațională — iar tehnologia de indexare cea mai folosită, HNSW (Hierarchical Navigable Small World), nu a fost proiectată cu asta în minte.

Mecanismul tehnic: la o ștergere, HNSW de regulă doar marchează recordul ca șters — vectorul e exclus din căutările viitoare, dar rămâne fizic pe disc până când slotul respectiv e reutilizat de o inserare nouă. Un studiu din 2026 despre așa-numiții „ghost vectors" a confirmat că embeddingul rămâne neschimbat și recuperabil prin acces direct la fișierele indexului, ocolind complet API-ul aplicației.

Cifrele din același studiu sunt concrete: 25,5% dintre nume și 46,4% dintre locații au fost recuperate exact dintr-un set de date Wikipedia; pe date medicale sintetice, recuperarea vârstei și sexului a atins 100%, iar identitatea facială a fost recuperată în 99% din cazuri. Cuantizarea indexului (SQ8 sau PQ32, tehnici comune pentru reducerea dimensiunii) păstrează 78-93% din calitatea reconstrucției — reduce riscul, nu-l elimină.

Contramăsura care funcționează efectiv, conform aceluiași studiu, e rotația de chei pe epoci: embeddingurile se criptează cu o cheie care se schimbă periodic, iar la o cerere de ștergere, cheia corespunzătoare se aruncă definitiv, nu doar recordul. Rezultatul e 0% recuperare, cu o dovadă criptografică (semnătură ECDSA) că ștergerea a avut loc — utilă atât intern, cât și ca probă de conformitate.

Practic, dacă te bazezi doar pe delete din API-ul vector store-ului fără să verifici ce se întâmplă efectiv pe disc, cel mai probabil oferi un soft-delete, nu conformitate reală cu Art. 17.

Data residency în UE: unde stau datele când folosești un LLM prin API

Rezidența datelor devine relevantă imediat ce corpusul sau embeddingurile ies din infrastructura ta către un furnizor terț — una din zonele unde costul și securitatea unui RAG se intersectează cel mai direct.

Regiunea de procesare. Majoritatea furnizorilor mari oferă opțiuni de rezidență regională — Azure OpenAI, de exemplu, permite configurarea explicită a regiunii. Confirmă asta la nivel de contract, nu doar de documentație publică, fiindcă politicile se schimbă.

DPA cu furnizorul. Un Data Processing Agreement semnat clarifică cine e „operator" și cine e „persoană împuternicită" conform GDPR, ce se întâmplă cu datele la reziliere și, cel mai important pentru un RAG, dacă furnizorul antrenează modele pe datele tale. Toți cei trei furnizori discutați mai sus declară explicit că nu antrenează pe date API fără permisiune expresă, dar „declară" și „garantează contractual prin DPA" sunt lucruri diferite.

Self-hosted versus API. Pentru cerințe stricte de rezidență — sector public, sănătate, financiar — un model open-weight rulat self-hosted în UE elimină complet întrebarea „unde ajung datele", cu costul mentenanței infrastructurii proprii. Diferența de cost între cele două arhitecturi nu e mică, dar pentru date cu adevărat sensibile decizia se ia de multe ori din motive de conformitate, nu de buget.

Exfiltrare prin prompt injection: încă o cale către date personale

Chiar și cu redactare la ingestie, control de acces la retrieval și ștergere reală, mai rămâne un vector care nu ține de arhitectura de date: prompt injection. Un atacator poate ascunde instrucțiuni într-un document care ajunge, legitim, în corpus — iar la retrieval, acele instrucțiuni pot convinge modelul să reformuleze sau să expună fragmente din context pe care utilizatorul nu ar trebui să le vadă, ocolind orice filtru aplicat la interogarea inițială.

E un subiect suficient de larg cât să merite propriul tratament — de ce eșuează un RAG în producție acoperă mecanismul tehnic în detaliu. Din perspectivă GDPR, reține doar atât: controlul de acces de la retrieval nu te protejează dacă modelul poate fi convins să ignore rezultatul filtrului.

Checklist practic de conformitate GDPR pentru un RAG în producție

Opt verificări concrete, în ordinea în care contează:

• Detecție și redactare PII la ingestie, înainte de embedding — nu după.
• Metadate de proprietate pe fiecare chunk (user_id / tenant_id) și pre-filtrare la retrieval, nu post-filtrare.
• Izolare la nivel de colecție pentru tenanții cu cerințe contractuale de separare.
• Hard-delete verificat la nivel de disc, nu doar apel API — sau rotație de chei pe epoci dacă indexul nu suportă hard-delete nativ.
• DPA semnat cu fiecare furnizor de model, cu clauză explicită despre antrenare pe date trimise.
• Rezidență regională configurată și verificată contractual, nu doar declarată în documentație.
• Log de audit pentru cererile de ștergere, cu dovadă (hash sau semnătură) că ștergerea s-a produs efectiv.
• Testare periodică de prompt injection pe corpusul de producție, nu doar la lansare.

Întrebări frecvente

Cât timp poate reține un furnizor de LLM datele trimise prin API?

Depinde de furnizor și de contract. OpenAI reține implicit până la 30 de zile pentru monitorizare anti-abuz; Anthropic nu reține conținutul conversațiilor implicit, cu excepția modelelor acoperite de politici speciale, unde reținerea e tot de 30 de zile; Azure OpenAI oferă o opțiune care dezactivează fereastra de retenție pentru sarcini aprobate. Cifrele exacte se schimbă des — verifică documentația curentă a furnizorului înainte să le folosești într-un document de conformitate.

E suficient un soft-delete pentru dreptul la ștergere conform GDPR?

Nu, dacă indexul folosește HNSW sau o structură similară fără ștergere fizică imediată. Vectorul rămâne pe disc, recuperabil prin acces direct la fișiere, până când slotul e reutilizat. Pentru conformitate reală ai nevoie fie de hard-delete confirmat la nivel de disc, fie de o strategie de criptare cu rotație de chei care face imposibilă recuperarea după ștergere.

Ce amenzi riști dacă un sistem RAG expune date personale?

Plafonul din Art. 83(5) GDPR e 20 de milioane de euro sau 4% din cifra de afaceri globală anuală, oricare valoare e mai mare; pentru încălcări mai puțin severe, Art. 83(4) prevede 10 milioane de euro sau 2%. Din decembrie 2023, jurisprudența CJUE (cazul Volkswagen) confirmă că plafonul se calculează pe cifra de afaceri a întregului grup economic, nu doar a entității tehnic responsabile.

Poate fi „anonimizat" un model antrenat pe date personale?

Conform opiniei EDPB din decembrie 2024, un model AI e considerat cu adevărat anonim doar dacă probabilitatea de a extrage direct date de antrenare și probabilitatea de a le obține prin interogări repetate sunt amândouă nesemnificative — evaluat de la caz la caz, nu presupus implicit.

Cum previi scurgerea de date între utilizatori într-un RAG multi-tenant?

Filtrează la nivel de metadate înainte de căutarea de similaritate, adică pre-filtrare, nu post-filtrare. Pentru izolare strictă, ia în calcul colecții separate per tenant în loc de o singură colecție cu filtre.

Ce e un DPA și de ce ai nevoie de el pentru un furnizor de LLM?

Un Data Processing Agreement clarifică contractual rolurile — operator versus persoană împuternicită —, ce se întâmplă cu datele la reziliere și dacă furnizorul are voie să antreneze modele pe datele trimise. Fără el, declarațiile din documentația publică a furnizorului nu au forță contractuală.

O arhitectură RAG conformă cu GDPR nu se improvizează după un audit ratat sau o amendă. Dacă sistemul tău gestionează date personale prin RAG, o evaluare a celor patru vectori de mai sus — de la redactare la ingestie până la ștergere verificabilă — merită făcută înainte de producție, nu după. Vezi ce acoperă implementarea de sisteme AI/RAG dacă vrei sprijin pe partea de arhitectură și securitate.