Jak budować systemy RAG zgodne z RODO: praktyczny przewodnik

System RAG zgodny z RODO przetwarza dane osobowe zawarte w dokumentach źródłowych, indeksie wektorowym i embeddingach wyłącznie na solidnej podstawie prawnej, z minimalizacją danych, hostingiem w UE, separacją klientów i pipeline'em usuwania, który kasuje chunki i embeddingi jednocześnie. Embeddingi utworzone z tekstów zawierających dane osobowe należy traktować jako spseudonimizowane dane osobowe, a nie jako dane anonimowe. Ten przewodnik przyporządkowuje elementy techniczne do wymogów ochrony danych i zawiera checklistę do odhaczania.

Trzy szybkie odpowiedzi:

• Embeddingi nie są anonimowe. Z wektorów da się odtworzyć treści (inwersja embeddingów tekstowych). Traktuj je jako spseudonimizowane dane osobowe.
• Usunięcie oznacza chunk plus embedding. Kto usuwa tylko dokument źródłowy, zostawia wektor, który przez wyszukiwanie po podobieństwie nadal ujawnia treści.
• Hosting w UE i separacja klientów należą do projektu od samego początku, a nie są dodatkiem doklejanym na końcu: suwerenna baza wektorowa plus LLM w regionie UE, filtr ACL przy każdym zapytaniu.

Uwaga: ten artykuł to ocena merytoryczna i nie stanowi porady prawnej. Konkretne kwestie prawne wyjaśnij ze swoim działem ochrony danych lub działem prawnym.

Gdzie w systemie RAG powstają dane osobowe

RAG (Retrieval-Augmented Generation) przed wygenerowaniem odpowiedzi celowo pobiera wiedzę z zewnętrznego źródła i osadza ją w prompcie. Dane osobowe pojawiają się przy tym w kilku miejscach jednocześnie: w dokumentach źródłowych (rekordy CRM, HR, klientów), w zindeksowanych chunkach, w wektorach embeddingów, w samym zapytaniu, w wygenerowanej odpowiedzi oraz w logach i śladach (traces). Każdy z tych etapów jest odrębnym przetwarzaniem w rozumieniu RODO.

Najważniejszym niemieckim punktem odniesienia są wytyczne Konferencji Ochrony Danych (DSK) dotyczące systemów RAG z października 2025 roku. Wymieniają one separację klientów oraz koncepcję uprawnień i ról jako środki ochrony wektorowej bazy danych i stwierdzają, że wpisy w wektorowej bazie danych i w dokumentach referencyjnych można celowo usuwać. W Austrii właściwy jest organ ochrony danych (DSB), również w kwestiach ochrony danych dotyczących systemów AI. DSK to gremium niemieckich organów nadzorczych ds. ochrony danych na szczeblu federalnym i krajów związkowych; dlatego jej dokumenty nie są wiążące dla austriackiego DSB, ale mogą tam służyć jako pomoc interpretacyjna. Dodatkowo zasady RODO z art. 5 (ograniczenie celu, minimalizacja danych, prawidłowość, ograniczenie przechowywania) obowiązują także reprezentacje wektorowe, gdy tylko można je przypisać konkretnej osobie, której dane dotyczą.

Główny błąd: embeddingi to nie anonimizacja

Częstym błędem jest uznawanie wektorowych pamięci podręcznych za „zanonimizowane cechy”. To przeczy stanowi badań. Ataki inwersji embeddingów tekstowych (Morris et al., Text Embeddings Reveal (Almost) As Much As Text, 2023, oraz kolejne prace z lat 2024–2025) pokazują, że z embeddingów da się odtworzyć dużą część oryginalnego tekstu. Do tego dochodzą ataki membership inference i ponowna identyfikacja przez wyszukiwanie po podobieństwie: kto ma podobny tekst, znajdzie zindeksowaną osobę.

Wniosek: traktuj embeddingi z tekstów zawierających dane osobowe jako spseudonimizowane dane osobowe. Dokument dyskusyjny hamburskiego Pełnomocnika ds. Ochrony Danych z lipca 2024 roku wprawdzie nie dopatruje się danych osobowych w embeddingach wewnątrz LLM, ale wyraźnie ocenia wyłącznie sam model. W przypadku zapytań do baz danych w pozostałej części systemu AI prawa osób, których dane dotyczą, nadal obowiązują. Dokument nie obejmuje więc wektorów bazy danych RAG, z których każdy jest przypisany do chunka z danymi osobowymi. Dane spseudonimizowane pozostają danymi osobowymi dla administratora, który może przywrócić powiązanie (motyw 26 RODO). Dla odbiorcy bez realnej możliwości takiego powiązania nie są one, zgodnie z wyrokiem TSUE C-413/23 P z 4 września 2025 roku, z konieczności danymi osobowymi. Dla Twojej własnej bazy wektorowej nic to nie zmienia. Według dominującego poglądu sam embedding nie jest bezpieczną pseudonimizacją. Dlatego nigdy nie przedstawiaj embeddingów jako anonimowych ani w marketingu, ani w dokumentacji, chyba że wyjątkowo wykaże to metoda z prywatnością różnicową (differential privacy) i rzetelnymi testami.

Minimalizacja danych: wykrywanie PII i pseudonimizacja przed embeddingiem

Minimalizacja danych (art. 5 ust. 1 lit. c) to w kontekście RAG kwestia pipeline'u, a nie filtra stosowanego po fakcie. Najskuteczniejsze dźwignie:

• Wykrywanie PII przed indeksowaniem: pipeline'y NER lub oparte na regułach (np. Microsoft Presidio lub wewnętrzny NER) oznaczają imiona i nazwiska, adresy oraz numery dokumentów tożsamości w chunkach, zanim zostaną one przekształcone w embeddingi.
• Pseudonimizacja chunków źródłowych: zastąpienie identyfikatorów stabilnymi pseudonimami; tabelę mapowania trzymaj w osobnym magazynie chronionym na podstawie ról.
• Inżynieria kontekstu dla każdego zapytania: pobieraj i przekazuj do promptu tylko to, czego wymaga zadanie, a nie cały zbiór dokumentów. Reranking do top_k = 5–10 obniża zarówno koszty, jak i ilość ujawnianych danych.
• Maskowanie logów: przed trwałym zapisem maskuj dane w logach promptów i odpowiedzi; do łączenia danych między systemami używaj pseudonimowych identyfikatorów.

W kwestii technicznego wdrożenia DSK w swoich wytycznych dotyczących środków technicznych i organizacyjnych w systemach AI (czerwiec 2025) odsyła do Standardowego Modelu Ochrony Danych (SDM V3.1). Przekłada on wymogi RODO na środki techniczne i organizacyjne poprzez cele ochrony, takie jak minimalizacja danych i niepowiązywalność.

Hosting LLM i bazy wektorowej w UE

Rezydencja danych to bezpośrednia dźwignia ryzyka. Hosting w regionie UE zmniejsza ryzyko związane z państwami trzecimi, ale u dostawców z USA nie eliminuje automatycznie ryzyka resztkowego wynikającego z CLOUD Act. Przy przekazywaniu danych do państw trzecich trzeba sprawdzić standardowe klauzule umowne (SCC) oraz ocenę skutków transferu (TIA). Suwerenne opcje z regionu DACH (Niemcy, Austria, Szwajcaria) i UE w dużej mierze eliminują ten problem. Jina i BGE-M3 w tabeli to otwarte modele do samodzielnego hostingu, ale nie suwerenni dostawcy z regionu DACH:

W przypadku korpusów niemieckojęzycznych znaczenie ma także wybór modelu: prowadzą modele wielojęzyczne, takie jak Cohere Embed v4, Voyage-3 czy Gemini Embedding 002; modele specyficzne dla języka niemieckiego (GBERT, GELECTRA, GermanDPR) pozostają konkurencyjne w wąsko zdefiniowanych domenach on-premise. BGE-M3 to otwartoźródłowy, wielojęzyczny model zapasowy z Chin (BAAI), a więc nie suwerenny model z regionu DACH, ale można go uruchomić on-premise.

Koncepcja usuwania danych i prawo do bycia zapomnianym: problem reindeksacji

Prawo do usunięcia danych (art. 17) to w stacku RAG najtrudniejsze do spełnienia żądanie. Kluczowe jest rozdzielenie dwóch poziomów:

1. Warstwa inferencji (zarządzane API): na poziomie modelu nie istnieje gotowe do produkcji, weryfikowalne usuwanie danych pojedynczych osób bez pełnego ponownego trenowania. Tu pozostaje oprzeć się na zobowiązaniu do nietrenowania zapisanym w umowie powierzenia oraz na filtrach wyjściowych, które blokują odtwarzanie określonych treści.
2. Warstwy kontrolowane przez podmiot stosujący (deployera): baza wektorowa, pamięć agentów, logi i ewentualne zbiory danych do fine-tuningu można w pełni usunąć; to one niosą główny ciężar zgodności.

W bazie wektorowej obowiązuje zasada: Hard Delete usuwa wektor i metadane źródłowe i jest preferowanym ustawieniem domyślnym. Soft Delete jedynie oznacza wpis i zachowuje wektor; grozi to wyciekiem przez wyszukiwanie po podobieństwie i da się to uzasadnić co najwyżej przy bardzo krótkim okresie przechowywania. Praktyczna zasada: przy usuwaniu danych osoby usuń jednocześnie dokument źródłowy i embedding.

„Problem reindeksacji” jest często źle rozumiany. Pełna reindeksacja jest potrzebna tylko przy zmianie modelu embeddingów (w przeciwnym razie dryf embeddingów sprawia, że indeksy stają się nieporównywalne). Celowe usuwanie pojedynczych osób powinno natomiast działać przez stabilne identyfikatory dokumentów jako idempotentny upsert/delete, bez przebudowy całego indeksu. Oznacz każdy wpis w pamięci i indeksie tagiem subject_id; dzięki temu endpoint DSAR znajdzie wszystkie rekordy, których to dotyczy.

Kontrola dostępu i separacja klientów

Klasyczny wyciek danych w RAG polega na tym, że chunk klienta A zostaje pobrany dla klienta B. Separację klientów, o której mówi niemiecka DSK, można technicznie wdrożyć w następujący sposób:

• Filtrowalne metadane: tenant_id, ACL, source, znacznik czasu dla każdego chunka; Filterable HNSW (Qdrant, Weaviate, pgvector z Row-Level Security).
• Obrona w głąb: uwierzytelnianie i ustalenie tenanta przed zapytaniem, filtr wstępny na tenant_id, ponowna kontrola po retrievalu i dziennik audytu dla każdego dostępu.
• Osobna kolekcja lub namespace dla każdego tenanta jako alternatywa dla samego filtra metadanych, gdy izolacja musi być silniej zagwarantowana.

Podstawa prawna i umowa powierzenia z dostawcami

Do przekształcania dokumentów z danymi osobowymi w embeddingi potrzebujesz podstawy prawnej z art. 6, zwykle art. 6 ust. 1 lit. b (umowa) lub lit. f (prawnie uzasadniony interes, z udokumentowanym testem równowagi interesów). Szczególne kategorie danych osobowych (art. 9, np. dane o zdrowiu lub przynależności do związków zawodowych) są co do zasady zakazane i można je przetwarzać tylko na podstawie wyjątku; w razie wątpliwości wyklucz je z indeksu.

Każdy zewnętrzny element trzeba zakwalifikować z perspektywy ochrony danych. Dostawcy modeli i chmury działają zwykle jako podmioty przetwarzające; wtedy obowiązkowa jest umowa powierzenia przetwarzania danych (art. 28). Zwróć uwagę na:

• Zobowiązanie do nietrenowania: dane wejściowe, wyjściowe, embeddingi i dane do fine-tuningu nie są wykorzystywane do trenowania modeli dostawcy. W planach enterprise Microsoft Azure OpenAI, OpenAI, Anthropic, Google Vertex AI, AWS Bedrock, Mistral i Aleph Alpha jest to (stan na 2026 r.) umowne ustawienie domyślne; plany konsumenckie się od tego różnią.
• Łańcuch podprzetwarzających: dostawca modelu, chmura, baza wektorowa, ewentualnie serwery MCP i narzędzia observability, wszystkie bez wyjątku wskazane i zatwierdzone (art. 28 ust. 2 i 4 RODO). Najczęstsze ustalenie audytowe: nieobjęte umową przepływy observability lub MCP.
• Przechowywanie: konfigurowalna retencja, aż po Zero Data Retention. Domyślne ustawienia dostawców (stan na 2026 r.): OpenAI API i Anthropic API przechowują dane wejściowe i wyjściowe maksymalnie 30 dni.
• Wiążąco ustal rezydencję danych na UE/Szwajcarię i wyklucz routing failover do państw trzecich.

Przykład z praktyki: RAG wsparcia technicznego na zgłoszeniach klientów

Agencja z regionu DACH buduje dla klienta B2B system RAG obejmujący 80 000 zgłoszeń supportowych. Postępowanie w liczbach:

1. Ingestia: Presidio-NER pseudonimizuje imiona i nazwiska, adresy e-mail i numery umów w chunkach; tabela mapowania znajduje się w osobnym magazynie chronionym przez RBAC.
2. Chunking i embedding: parsowanie z uwzględnieniem układu dokumentu, następnie chunki po ~512 tokenów; embedding modelem z UE lub regionu DACH; upsert do Qdrant (region UE) z tenant_id, ticket_id, source, ts jako metadanymi.
3. Zapytanie: uwierzytelnianie + ustalenie tenanta, hybrydowy retrieval z top_k = 50, reranking do top_k = 8, odpowiedź z cytatami źródeł (identyfikatory chunków).
4. Usuwanie: DSAR dotyczący klienta uruchamia Hard Delete wszystkich wektorów z jego subject_id i jednocześnie usuwa chunki źródłowe. Pseudokod:

```
on dsar_erasure(subject_id):
ids = vector_db.query(filter={"subject_id": subject_id}, only_ids=True)
vector_db.delete(ids) # Embedding + metadane (Hard Delete)
source_store.delete(subject_id) # dokument źródłowy
audit_log.write("erasure", subject_id, count=len(ids))
```

5. Nadzór (governance): DPIA przed uruchomieniem produkcyjnym (według wytycznych DSK dotyczących AI jest ona przy stosowaniu aplikacji AI wymagana „w wielu przypadkach”; w Austrii rozporządzenie DSFA-V wymienia operacje przetwarzania, dla których DPIA jest wymagana w każdym przypadku), umowa powierzenia z dostawcą chmury i modelu, 30-dniowa retencja logów z maskowaniem.

Checklista zgodności RAG z RODO

• Udokumentowana podstawa prawna dla każdej operacji przetwarzania (art. 6; przy lit. f z testem równowagi interesów)
  
• Szczególne kategorie danych (art. 9) zidentyfikowane i, jeśli brak przesłanki, wykluczone z indeksu
  
• Wykrywanie PII i pseudonimizacja chunków przed embeddingiem
  
• Embeddingi sklasyfikowane jako spseudonimizowane dane osobowe, a nie jako anonimowe
  
• Hosting LLM i bazy wektorowej w regionie UE; przy państwach trzecich SCC + TIA
  
• Separacja klientów przez tenant_id/ACL; filtr przy każdym zapytaniu oraz ponowna kontrola i dziennik audytu
  
• Pipeline usuwania: Hard Delete dokumentu źródłowego i embeddingu jednocześnie, przez stabilne identyfikatory
  
• Endpoint DSAR znajduje subject_id w bazie wektorowej, pamięci i logach
  
• Polityka retencji z maskowaniem dla promptów, odpowiedzi i logów
  
• Umowa powierzenia z każdym dostawcą (zakaz trenowania, łańcuch podprzetwarzających, rezydencja danych, retencja)
  
• Cytaty źródeł w każdej odpowiedzi (identyfikatory chunków) dla możliwości weryfikacji
  
• DPIA przeprowadzona; ryzyka membership inference i data poisoning uwzględnione
  

Dla agencji i decydentów B2B

W RAG ochrona danych to nie audyt przeprowadzany po fakcie, lecz decyzja architektoniczna: suwerenne komponenty z UE, porządny pipeline usuwania i separację klientów najtaniej jest zaplanować od pierwszego dnia, a nie dobudowywać później. Agencje, które traktują zgodność z RODO jako standardowy element swoich wdrożeń, zmniejszają ryzyko odpowiedzialności swoich klientów i wyróżniają się na rynku. Jako agencja z Wiednia Blck Alpaca wspiera budowę zgodnych z RODO systemów RAG i agentów AI, od DPIA aż po produkcyjny pipeline usuwania. Te treści nie zastępują porady prawnej; ostateczną ocenę prawną przeprowadza Twój dział ochrony danych lub dział prawny.