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, vo vektorovom indexe a v embeddingoch len na spoľahlivom právnom základe, s minimalizáciou údajov, hostingom v EÚ, oddelením tenantov a mazacou pipeline, ktorá odstraňuje chunky a embeddingy spoločne. Embeddingy z textov s osobnými údajmi treba pritom považovať za pseudonymné osobné údaje, nie za anonymné. Tento návod priraďuje technické stavebné prvky k požiadavkám na ochranu údajov a obsahuje kontrolný zoznam na odškrtávanie.

Tri rýchle odpovede:

• Embeddingy nie sú anonymné. Z vektorov sa dá rekonštruovať obsah (inverzia textových embeddingov). Zaobchádzaj s nimi ako s pseudonymnými osobnými údajmi.
• Vymazanie znamená chunk plus embedding. Kto odstráni len zdrojový dokument, ponechá vektor, ktorý cez vyhľadávanie podľa podobnosti naďalej prezrádza obsah.
• Hosting v EÚ a oddelenie tenantov patria do návrhu od začiatku, nie ako dodatočná nadstavba: suverénna vektorová DB plus LLM v regióne EÚ, ACL filter pri každom dopyte.

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

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

RAG (Retrieval-Augmented Generation) pred generovaním odpovede cielene vyhľadá znalosti z externého zdroja a vloží ich do promptu. Osobné údaje pritom vznikajú na viacerých miestach súčasne: v zdrojových dokumentoch (záznamy z CRM, HR a o zákazníkoch), v indexovaných chunkoch, vo vektoroch embeddingov, v samotnom dopyte, vo vygenerovanej odpovedi a v logoch a trasovacích záznamoch. Každé z týchto miest predstavuje samostatné spracúvanie v zmysle GDPR.

Najdôležitejším nemeckým referenčným dokumentom je orientačná pomôcka Konferencie pre ochranu údajov (DSK) k RAG systémom z októbra 2025. Ako ochranné opatrenia pre vektorovú databázu uvádza oddelenie tenantov a koncepciu práv a rolí a konštatuje, že záznamy vo vektorovej databáze a v referenčných dokumentoch sa dajú cielene vymazať. V Rakúsku je príslušný Úrad na ochranu údajov (Datenschutzbehörde, DSB), a to aj pre otázky ochrany údajov pri systémoch AI. DSK je grémium nemeckých dozorných orgánov pre ochranu údajov na spolkovej a krajinskej úrovni; pre rakúsky úrad DSB preto jej dokumenty nie sú záväzné, slúžia tam však ako pomôcka pri výklade. Doplnkovo platia zásady GDPR z čl. 5 (obmedzenie účelu, minimalizácia údajov, správnosť, minimalizácia uchovávania) aj pre vektorové reprezentácie, len čo sa dajú priradiť dotknutej osobe.

Hlavný omyl: embeddingy nie sú anonymizácia

Rozšírenou chybou je vyhlasovať vektorové cache za „anonymizované príznaky“. To odporuje stavu výskumu. Útoky inverziou textových embeddingov (Morris et al., Text Embeddings Reveal (Almost) As Much As Text, 2023, a nadväzujúce práce z rokov 2024 až 2025) ukazujú, že z embeddingov sa dajú rekonštruovať veľké časti pôvodného textu. K tomu pribúdajú útoky typu membership inference a reidentifikácia cez vyhľadávanie podľa podobnosti: kto má podobný text, nájde indexovanú osobu.

Dôsledok: embeddingy z textov s osobnými údajmi považuj za pseudonymné osobné údaje. Diskusný dokument hamburského poverenca pre ochranu údajov z júla 2024 síce v embeddingoch vo vnútri LLM nevidí osobné údaje, výslovne však hodnotí len samotný model. Pri dopytoch do databáz v ostatných častiach systému AI práva dotknutých osôb naďalej platia. Vektory RAG databázy, z ktorých každý patrí k chunku s osobnými údajmi, tento dokument teda nepokrýva. Pseudonymizované údaje zostávajú osobnými údajmi pre prevádzkovateľa, ktorý vie priradenie obnoviť (odôvodnenie 26 GDPR). Pre príjemcu bez reálnej možnosti priradenia nie sú podľa rozsudku Súdneho dvora EÚ C-413/23 P zo 4. septembra 2025 nevyhnutne osobnými údajmi. Na výsledku pre tvoje vlastné vektorové úložisko to nič nemení. Samotný embedding podľa prevládajúceho názoru nie je bezpečnou pseudonymizáciou. Embeddingy preto nikdy nepropaguj ani nedokumentuj 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 kontexte RAG otázkou pipeline, nie dodatočného filtra. Najúčinnejšie páky:

• Detekcia PII pred indexovaním: NER alebo pipeline založené na pravidlách (napríklad Microsoft Presidio alebo interný NER) označia v chunkoch mená, adresy a čísla dokladov skôr, než sa z nich vytvoria embeddingy.
• Pseudonymizácia zdrojových chunkov: nahradiť identifikátory stabilnými pseudonymami; tabuľku priradení uchovávať v oddelenom úložisku s prístupom podľa rolí.
• Riadenie kontextu pri každom dopyte: vyhľadať a do promptu odovzdať len to, čo úloha potrebuje, nie celý súbor dokumentov. Re-ranking na top_k = 5 až 10 znižuje náklady aj množstvo odhalených údajov.
• Redigovanie logov: logy promptov a výstupov pred trvalým uložením redigovať; na prepojenia naprieč systémami používať pseudonymné ID.

Pri technickej realizácii odkazuje DSK vo svojej orientačnej pomôcke k technickým a organizačným opatreniam pri systémoch AI (jún 2025) na štandardný model ochrany údajov (SDM V3.1). Ten prekladá požiadavky GDPR cez ciele ochrany, ako sú minimalizácia údajov a nespojiteľnosť, do technických a organizačných opatrení.

Hosting v EÚ pre LLM a vektorové úložisko

Rezidencia údajov je priamou pákou na riziko. Hosting v regióne EÚ znižuje riziko spojené s tretími krajinami, u amerických poskytovateľov však automaticky neodstraňuje zvyškové riziko podľa CLOUD Act. Pri prepojení s treťou krajinou treba preskúmať štandardné zmluvné doložky (SCC) a posúdenie vplyvu prenosu (TIA). Suverénne možnosti z regiónu DACH a z EÚ sa tejto otázke do veľkej miery vyhnú. Jina a BGE-M3 v tabuľke sú otvorené modely na vlastnú prevádzku, nie však suverénni poskytovatelia z regiónu DACH:

Pri nemeckojazyčných korpusoch je navyše dôležitý výber modelu: najlepšie výsledky dosahujú viacjazyčné modely ako Cohere Embed v4, Voyage-3 alebo Gemini Embedding 002; modely špecializované na nemčinu (GBERT, GELECTRA, GermanDPR) zostávajú konkurencieschopné v úzko vymedzených doménach s prevádzkou on-prem. BGE-M3 je viacjazyčný fallback s otvoreným zdrojovým kódom z Číny (BAAI), a teda nie suverénny model z regiónu DACH, dá sa však prevádzkovať 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žšie splniteľným nárokom. Dôležité je rozlíšiť dve úrovne:

1. Inferenčná vrstva (managed API): na úrovni modelu neexistuje produkčne zrelé, overiteľné vymazanie jednotlivých osobných údajov bez úplného pretrénovania. Tu sa treba oprieť o záväzok nepoužívať údaje na tréning v zmluve so sprostredkovateľom a o výstupné filtre, ktoré potláčajú reprodukciu určitého obsahu.
2. Úrovne pod kontrolou nasadzujúceho subjektu: vektorové úložisko, pamäť agentov, logy a prípadné súbory údajov na fine-tuning sa dajú úplne vymazať a nesú hlavnú ťarchu súladu s predpismi.

Vo vektorovom úložisku platí: hard delete odstráni vektor aj zdrojové metadáta a je preferovaným predvoleným nastavením. Soft delete záznam len označí a vektor ponechá; to so sebou nesie riziko úniku cez vyhľadávanie podľa podobnosti a obhájiť sa dá nanajvýš pri veľmi krátkom uchovávaní. Prevádzkové pravidlo: pri vymazaní osoby odstráň zdrojový dokument a embedding spoločne.

„Problém reindexácie“ sa často chápe nesprávne. Úplná reindexácia je potrebná len pri zmene embedding modelu (embedding drift inak robí indexy neporovnateľnými). Cielené vymazanie jednotlivých osôb by naopak malo fungovať cez stabilné ID dokumentov ako idempotentný upsert/delete, bez prestavby celého indexu. Každý záznam v pamäti a v indexe označ pomocou subject_id; endpoint pre žiadosti dotknutých osôb (DSAR) cez neho nájde všetky dotknuté záznamy.

Kontrola prístupu a oddelenie tenantov

Klasickým únikom osobných údajov v RAG je situácia, keď sa chunk tenanta A vyhľadá pre tenanta B. Oddelenie tenantov, ktoré uvádza nemecká DSK, sa dá technicky zrealizovať takto:

• Filtrovateľné metadáta: tenant_id, ACL, source, časová pečiatka pri každom chunku; Filterable HNSW (Qdrant, Weaviate, pgvector s Row-Level Security).
• Viacvrstvová ochrana (defense in depth): autentifikácia a určenie tenanta pred dopytom, predbežný filter na tenant_id, opätovná kontrola po vyhľadaní a auditný log každého prístupu.
• Kolekcia alebo menný priestor (namespace) pre každého tenanta ako alternatíva k samotnému filtru metadát, keď musí byť izolácia garantovaná silnejšie.

Právny základ a zmluvy s poskytovateľmi

Na vytváranie embeddingov z dokumentov s osobnými údajmi 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, so zdokumentovaným testom proporcionality). Spracúvanie osobitných kategórií osobných údajov (čl. 9, napríklad údaje o zdraví alebo o členstve v odboroch) je v zásade zakázané a možné len na základe niektorej z výnimiek; v prípade pochybností ich z indexu vylúč.

Každý externý stavebný prvok treba zaradiť z hľadiska ochrany údajov. Poskytovateľ modelu a cloud väčšinou vystupujú ako sprostredkovatelia; vtedy je zmluva so sprostredkovateľom (čl. 28) povinná. Dbaj na:

• Záväzok nepoužívať údaje na tréning: vstupy, výstupy, embeddingy a údaje na fine-tuning sa nepoužívajú na trénovanie modelov poskytovateľa. Pri podnikových tarifoch Microsoft Azure OpenAI, OpenAI, Anthropic, Google Vertex AI, AWS Bedrock, Mistral a Aleph Alpha je to (stav 2026) zmluvne predvolené; spotrebiteľské tarify sa líšia.
• Reťazec ďalších sprostredkovateľov: poskytovateľ modelu, cloud, vektorové úložisko, prípadne MCP server a nástroje observability musia byť bez výnimky uvedení a schválení (čl. 28 ods. 2 a 4 GDPR). Najčastejšie zistenie pri audite: nepokryté toky observability alebo MCP.
• Uchovávanie: konfigurovateľná doba uchovávania až po zero data retention. Predvolené nastavenia poskytovateľov (stav 2026): OpenAI API a Anthropic API uchovávajú vstupy a výstupy najviac 30 dní.
• Rezidenciu údajov záväzne stanov na EÚ/CH a vylúč failover routing do tretích krajín.

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

Agentúra z regiónu DACH buduje pre B2B zákazníka RAG nad 80 000 tiketmi podpory. Postup s číslami:

1. Načítanie údajov (ingestion): Presidio NER pseudonymizuje v chunkoch mená, e-mailové adresy a čísla zmlúv; mapovacia tabuľka je uložená v oddelenom úložisku chránenom pomocou RBAC.
2. Chunking a embedding: parsovanie so zohľadnením rozloženia (layout-aware), potom chunky s ~512 tokenmi; embedding pomocou modelu z EÚ alebo regiónu DACH; upsert do Qdrantu (región EÚ) s metadátami tenant_id, ticket_id, source, ts.
3. Dopyt: autentifikácia a určenie tenanta, hybridné vyhľadávanie top_k = 50, re-ranking na top_k = 8, odpoveď s citáciami zdrojov (ID chunkov).
4. Vymazanie: DSAR jedného zákazníka spustí hard delete všetkých vektorov s jeho subject_id a spolu s nimi vymaže zdrojové chunky. Pseudokó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: posúdenie vplyvu na ochranu údajov (DPIA) pred spustením do prevádzky (podľa orientačnej pomôcky DSK k AI je pri nasadení AI aplikácií potrebné „v mnohých prípadoch“; v Rakúsku nariadenie DSFA-V uvádza spracúvania, pri ktorých je DPIA potrebné v každom prípade), zmluvy so sprostredkovateľom uzavreté s poskytovateľmi cloudu a modelu, 30-dňové uchovávanie logov s redigovaním.

Kontrolný zoznam GDPR pre RAG na odškrtávanie

• Právny základ pre každé spracúvanie zdokumentovaný (čl. 6; pri písm. f s testom proporcionality)
  
• Osobitné kategórie (čl. 9) identifikované a tam, kde neplatí žiadna výnimka, vylúčené z indexu
  
• Detekcia PII a pseudonymizácia chunkov pred embeddingom
  
• Embeddingy klasifikované ako pseudonymné osobné údaje, nie ako anonymné
  
• Hosting LLM a vektorového úložiska v regióne EÚ; pri tretej krajine SCC + TIA
  
• Oddelenie tenantov cez tenant_id/ACL; filter pri každom dopyte plus opätovná kontrola a auditný log
  
• Mazacia pipeline: hard delete zdrojového dokumentu a embeddingu spoločne, cez stabilné ID
  
• Endpoint pre DSAR nájde subject_id vo vektorovom úložisku, v pamäti a v logoch
  
• Pravidlá uchovávania s redigovaním promptov, výstupov a logov
  
• Zmluva so sprostredkovateľom uzavretá s každým poskytovateľom (záväzok nepoužívať údaje na tréning, reťazec ďalších sprostredkovateľov, rezidencia údajov, uchovávanie)
  
• Citácie zdrojov v každej odpovedi (ID chunkov) kvôli vysledovateľnosti
  
• DPIA vykonané; riziká membership inference a data poisoning ošetrené
  

Pre agentúry a rozhodujúcich manažérov v B2B

Ochrana údajov nie je pri RAG dodatočným auditom, ale architektonickým rozhodnutím: suverénne stavebné prvky z EÚ, čistú mazaciu pipeline a oddelenie tenantov je najlacnejšie naplánovať od prvého dňa, nie dopĺňať neskôr. Agentúry, ktoré ukotvia súlad s GDPR ako štandardnú súčasť dodávky, znižujú riziko zodpovednosti svojich zákazníkov a odlišujú sa na trhu DACH. Ako viedenská agentúra sprevádza Blck Alpaca budovanie RAG systémov a systémov AI agentov v súlade s GDPR od DPIA až po produkčnú mazaciu pipeline. Tento obsah nenahrádza právne poradenstvo; konečné právne posúdenie urobí tvoje oddelenie ochrany údajov alebo právne oddelenie.