Budovanie RAG systémov v súlade s GDPR: praktický návod

RAG systém v súlade s GDPR spracúva osobné údaje v zdrojových dokumentoch, vektorovom indexe a embeddings len na zabezpečenom právnom základe, s minimalizáciou údajov, EU hostingom, oddelením mandantov a mazacou pipeline, ktorá odstraňuje chunks a embeddings spoločne. Embeddings sa pritom podľa praxe dozorných orgánov považujú za pseudonymné osobné údaje, nie za anonymné. Tento návod priraďuje technické stavebné prvky k požiadavkám na ochranu údajov a poskytuje odškrtávateľný kontrolný zoznam.

Tri rýchle odpovede:

• Embeddings nie sú anonymné. Z vektorov je možné rekonštruovať obsah (inverzia text embeddings). Zaobchádzajte s nimi ako s pseudonymnými osobnými údajmi.
• Mazanie znamená chunk plus embedding. Kto odstráni len zdrojový dokument, ponecháva vektor, ktorý cez vyhľadávanie podľa podobnosti naďalej prezrádza obsah.
• EU hosting a oddelenie mandantov sú povinné stavebné prvky, nie luxus: suverénna vektorová DB plus LLM v regióne EU, ACL filter pri každej query.

Poznámka: Tento príspevok je odborným zaradením a nepredstavuje právne poradenstvo. Konkrétne právne otázky riešte so svojím oddelením ochrany údajov alebo právnym oddelením.

Kde v RAG systéme vznikajú osobné údaje

RAG (Retrieval-Augmented Generation) pred generovaním odpovede cielene vyhľadáva znalosti z externého zdroja a vkladá ich do promptu. Osobné údaje pritom vznikajú na viacerých miestach súčasne: v zdrojových dokumentoch (CRM, HR, zákaznícke records), v indexovaných chunks, vo vektoroch embeddings, v samotnej query, v generovanej odpovedi a v logoch ako aj traces. Každá z týchto staníc je vlastným spracúvaním v zmysle GDPR.

Smerodajnou DACH referenciou je orientačná pomôcka Konferencie pre ochranu údajov (DSK) k RAG. Zdôrazňuje tri povinné stavebné prvky: oddelenie mandantov, koncepciu práv a rolí ako aj mazaciu pipeline, ktorá sa vzťahuje na chunks a embeddings. Doplnkovo platia zásady GDPR z čl. 5 (viazanosť účelom, minimalizácia údajov, správnosť, obmedzenie uchovávania) aj pre vektorové reprezentácie, akonáhle sa dajú priradiť dotknutej osobe.

Centrálny omyl: embeddings nie sú anonymizácia

Rozšírenou chybou je deklarovať vektorové cache ako „anonymizované features". To je v rozpore so stavom výskumu. Útoky inverzie text embeddings (Morris et al., Text Embeddings Reveal (Almost) As Much As Text, 2023, ako aj následné práce 2024 – 2025) ukazujú, že z embeddings je možné rekonštruovať veľké časti originálneho textu. K tomu pristupujú membership inference útoky a reidentifikácia cez vyhľadávanie podľa podobnosti: kto vlastní podobný text, nájde indexovanú osobu.

Dôsledok: CNIL a hamburský dozorný orgán štandardne zaobchádzajú s embeddings ako s pseudonymnými osobnými údajmi. Pseudonymizované údaje zostávajú podľa recitálu 26 GDPR osobnými. Samotný embedding nie je podľa prevládajúceho názoru bezpečnou pseudonymizáciou. Embeddings preto nikdy nepropagujte ani nedokumentujte ako anonymné, ibaže by to výnimočne preukázal postup s differential privacy a spoľahlivými testami.

Minimalizácia údajov: rozpoznať PII a pseudonymizovať pred embeddingom

Minimalizácia údajov (čl. 5 ods. 1 písm. c) je v RAG kontexte otázkou pipeline, nie dodatočným filtrom. Najúčinnejšie páky:

• Detekcia PII pred indexáciou: NER alebo pravidlami riadené pipeline (napríklad Microsoft Presidio alebo interný NER) označujú mená, adresy, čísla dokladov v chunks predtým, než sa embedujú.
• Pseudonymizácia zdrojových chunks: nahradiť identifikátory stabilnými pseudonymami; priraďovaciu tabuľku držať v oddelenom, rolami chránenom store.
• Context engineering na jednu query: vyhľadať a do promptu dať len to, čo úloha potrebuje, nie celý súbor dokumentov. Re-ranking na top_k = 5 – 10 znižuje tak náklady, ako aj množstvo odhalených údajov.
• Redakcia logov: redigovať prompt a output logy pred trvalým uložením; pseudonymné ID pre joiny naprieč systémami.

DSK na to odkazuje na štandardný model ochrany údajov (SDM v3.0) ako kontrolný katalóg, ktorý mapuje pseudonymizáciu naprieč všetkými cieľmi zabezpečenia.

EU hosting pre LLM a vektorové úložisko

Rezidencia údajov je priamou pákou rizika. Hosting v regióne EU znižuje riziko tretej krajiny, ale u US poskytovateľov automaticky neodstraňuje zvyškové riziko CLOUD Act. Pri väzbe na tretiu krajinu treba preskúmať štandardné zmluvné doložky (SCC) plus transfer impact assessment (TIA). Suverénne DACH/EU možnosti sa tejto otázke do veľkej miery vyhýbajú:

Pre nemeckojazyčné korpusy je dodatočne relevantný výber modelu: multilinguálne modely ako Cohere Embed v4, Voyage-3 alebo Gemini Embedding 002 sú popredu; nemecky špecifické modely (GBERT, GELECTRA, GermanDPR) zostávajú konkurencieschopné v úzko vymedzených on-prem doménach. BGE-M3 je open-source, viacjazyčný fallback z Číny (BAAI), a teda nie suverénny DACH model, ale prevádzkovateľný on-prem.

Koncepcia mazania a právo na zabudnutie: problém reindexácie

Právo na vymazanie (čl. 17) je v RAG stacku najťažším nárokom. Dôležité je oddelenie dvoch úrovní:

1. Inference layer (managed API): na úrovni modelu neexistuje produkčne pripravené, overiteľné mazanie jednotlivých osobných údajov bez úplného pretrénovania. Tu sa spolieha na prísľub no-training v zmluve o sprostredkovaní plus output filtre, ktoré potláčajú reprodukciu určitého obsahu.
2. Úrovne kontrolované deployerom: vektorové úložisko, agent memory, logy a prípadné fine-tuning datasety sú plne vymazateľné a nesú hlavnú ťarchu compliance.

Vo vektorovom úložisku platí: hard delete odstráni vektor a zdrojové metadáta a je preferovaným defaultom. Soft delete len označí a ponecháva vektor; to prináša únik cez vyhľadávanie podľa podobnosti a je obhájiteľné nanajvýš pri veľmi krátkom uchovávaní. Operatívne pravidlo palca: pri mazaní osoby odstrániť zdrojový dokument a embedding spoločne.

„Problém reindexácie" sa často nesprávne chápe. Úplná reindexácia je potrebná len pri zmene embedding modelu (embedding drift inak robí indexy neporovnateľnými). Cielené mazanie jednotlivých osôb by naopak malo fungovať cez stabilné doc ID ako idempotentný upsert/delete, bez prestavby celého indexu. Otagujte každý záznam memory a indexu pomocou subject_id; DSAR endpoint cez to nájde všetky dotknuté records.

Kontrola prístupu a oddelenie mandantov

Klasikou úniku súkromia v RAG je, že chunk mandanta A sa vyhľadá pre mandanta B. Orientačná pomôcka DSK k RAG vyžaduje oddelenie mandantov a koncepciu práv a rolí. Technicky realizovateľné cez:

• Filtrovateľné metadáta: tenant_id, ACL, source, časová pečiatka na chunk; Filterable HNSW (Qdrant, Weaviate, pgvector s row-level security).
• Defense-in-depth: autentifikácia a tenant resolution pred query, pre-filter na tenant_id, re-check po retrievale a audit log nad každým prístupom.
• Collection alebo namespace na jedného tenanta ako alternatíva k čistému filtru metadát, keď musí byť izolácia silnejšie garantovaná.

Právny základ a zmluva o sprostredkovaní s poskytovateľmi

Pre embedovanie dokumentov obsahujúcich osobné údaje je potrebný právny základ podľa čl. 6, typicky čl. 6 ods. 1 písm. b (zmluva) alebo písm. f (oprávnený záujem, s dokumentovaným zvážením záujmov). Osobitné kategórie osobných údajov (čl. 9, napríklad údaje o zdraví alebo členstve v odboroch) sú zásadne zakázané a spracovateľné len cez výnimkový skutkový stav; v prípade pochybností vylúčiť z indexu.

Každý externý stavebný prvok treba zaradiť z hľadiska ochrany údajov. Poskytovateľ modelu a cloud konajú väčšinou ako sprostredkovatelia spracúvania; potom je zmluva o sprostredkovaní spracúvania (čl. 28) povinnosťou. Dbajte na:

• Prísľub no-training: vstupy, výstupy, embeddings a fine-tuning dáta sa nepoužívajú na trénovanie modelov poskytovateľa. Pri enterprise tarifoch Microsoft Azure OpenAI, OpenAI, Anthropic, Google Vertex AI, AWS Bedrock, Mistral a Aleph Alpha je to (stav 2026) zmluvne defaultom; spotrebiteľské tarify sa odchyľujú.
• Reťazec sub-procesorov: poskytovateľ modelu, cloud, vektorové úložisko, prípadne MCP server a observability bezo medzier menovaní (čl. 28 ods. 4). Najčastejší audit nález: nepokryté observability alebo MCP flows.
• Uchovávanie: konfigurovateľná retencia až po zero data retention. Defaulty poskytovateľov (stav 2026) sú napr. maximálne 30 dní (OpenAI API) resp. 7 dní (Anthropic API, od 14. septembra 2025).
• Rezidenciu údajov záväzne stanoviť na EU/CH a vylúčiť failover routing do tretích krajín.

Praktický príklad: support RAG nad zákazníckymi tiketmi

DACH agentúra buduje pre B2B zákazníka RAG nad 80 000 support tiketmi. Postup s číslami:

1. Ingestion: Presidio NER pseudonymizuje mená, e-mailové adresy a čísla zmlúv v chunks; mapovacia tabuľka leží v oddelenom, RBAC chránenom store.
2. Chunking a embedding: layout-aware parsing, potom ~512-token chunks; embedding s EU/DACH modelom; upsert do Qdrant (región EU) s tenant_id, ticket_id, source, ts ako metadátami.
3. Query: auth + tenant resolution, hybrid retrieval top_k = 50, re-ranking na top_k = 8, odpoveď s citáciami zdrojov (chunk ID).
4. Mazanie: DSAR na zákazníka vykoná hard delete všetkých vektorov s jeho subject_id a vymaže zdrojové chunks spoločne. Pseudo-kód:

```
on dsar_erasure(subject_id):
ids = vector_db.query(filter={"subject_id": subject_id}, only_ids=True)
vector_db.delete(ids) # Embedding + metadáta (hard delete)
source_store.delete(subject_id) # zdrojový dokument
audit_log.write("erasure", subject_id, count=len(ids))
```

5. Governance: DPIA pred go-live (systémy AI podľa praxe DSK takmer vždy spúšťajú DPIA), zmluva o sprostredkovaní s cloud a model poskytovateľom, 30-dňová retencia na logoch s redakciou.

Odškrtávateľný GDPR kontrolný zoznam pre RAG

• Právny základ na každé spracúvanie zdokumentovaný (čl. 6; pri písm. f so zvážením záujmov)
  
• Osobitné kategórie (čl. 9) identifikované a, kde bez skutkového stavu, vylúčené z indexu
  
• Detekcia PII a pseudonymizácia chunks pred embeddingom
  
• Embeddings klasifikované ako pseudonymné osobné údaje, nie ako anonymné
  
• Hosting v regióne EU pre LLM a vektorové úložisko; pri tretej krajine SCC + TIA
  
• Oddelenie mandantov cez tenant_id/ACL; filter pri každej query plus re-check a audit log
  
• Mazacia pipeline: hard delete zdrojového dokumentu a embeddingu spoločne, cez stabilné ID
  
• DSAR endpoint nájde subject_id cez vektorové úložisko, memory a logy
  
• Retention policy s redakciou pre prompty, výstupy, logy
  
• Zmluva o sprostredkovaní s každým poskytovateľom (no-training, reťazec sub-procesorov, rezidencia údajov, retencia)
  
• Citácie zdrojov v každej odpovedi (chunk ID) pre vysledovateľnosť
  
• DPIA vykonané; riziká membership inference a data poisoning adresované
  

Pre agentúry a B2B rozhodovateľov

Ochrana údajov nie je pri RAG dodatočným auditom, ale architektonickým rozhodnutím: suverénne EU stavebné prvky, čistú mazaciu pipeline a oddelenie mandantov je najlacnejšie naplánovať od prvého dňa, nie dodatočne dovybavovať. Agentúry, ktoré ukotvia súlad s GDPR ako štandardný dodávkový znak, znižujú riziko zodpovednosti svojich zákazníkov a odlišujú sa na DACH trhu. Ako viedenská agentúra sprevádza Blck Alpaca budovanie RAG a AI-agent systémov v súlade s GDPR od DPIA až po produkčnú mazaciu pipeline. Tieto obsahy nenahrádzajú právne poradenstvo; finálne právne posúdenie robí vaše oddelenie ochrany údajov alebo právne oddelenie.