--- title: "Jak budować systemy RAG zgodne z RODO: praktyczny przewodnik" description: "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 U…" locale: "pl" canonical: "https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/jak-dzialaja-systemy-rag-w-ai/jak-budowac-systemy-rag-zgodne-z-rodo-praktyczny-przewodnik" category: "Agenci AI" topic: "Jak działają systemy RAG w AI" updated: "2026-10-28T13:35:57.990Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # 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 (tenantó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. ## W skrócie - Embeddingi nie są anonimowe: inwersja embeddingów tekstowych (Morris et al. 2023) i ataki membership inference (wnioskowanie o przynależności) umożliwiają ponowną identyfikację. Dlatego traktuj embeddingi z tekstów zawierających dane osobowe jako spseudonimizowane dane osobowe. - Minimalizacja danych zaczyna się przed embeddingiem: wykrywanie PII (np. Presidio, NER) i pseudonimizacja chunków źródłowych przed ich zindeksowaniem, a do tego minimalny payload kontekstu dla każdego zapytania. - Prawo do usunięcia danych (art. 17) wymaga wspólnego usunięcia dokumentu źródłowego i embeddingu (Hard Delete). Soft Delete niesie ryzyko wycieku przez wyszukiwanie po podobieństwie. - Separacja klientów za pomocą filtrowalnych metadanych (tenant_id, ACL) z obroną w głąb (defense in depth): uwierzytelnianie, filtr wstępny, ponowna kontrola, dziennik audytu. Wytyczne niemieckiej DSK dotyczące RAG wymieniają separację klientów oraz koncepcję uprawnień i ról jako środki ochrony. - Hosting LLM i bazy wektorowej w UE zmniejsza ryzyko związane z państwami trzecimi: suwerenne opcje to m.in. Qdrant (Berlin), Weaviate (NL), Aleph Alpha (Heidelberg, fuzja z Cohere w toku), Mistral (FR) oraz STACKIT/IONOS. - Z każdym dostawcą potrzebujesz umowy powierzenia przetwarzania danych (art. 28) z jasnym łańcuchem podprzetwarzających, zobowiązaniem do nietrenowania modeli na Twoich danych i konfigurowalnym okresem przechowywania. System RAG zgodny z [RODO](https://blckalpaca.at/pl/slownik/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](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/wdrazanie-agentow-ai-zgodnie-z-rodo/rezydencja-danych-w-ue-dla-llm-gdzie-przetwarzane-sa-twoje-dane), 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](https://blckalpaca.at/pl/slownik/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](https://blckalpaca.at/pl/slownik/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](https://blckalpaca.at/pl/slownik/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](https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf) 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)](https://dsb.gv.at/kuenstlichebrintelligenz/kuenstliche-intelligenz-datenschutz), również w kwestiach ochrony danych dotyczących systemów [AI](https://blckalpaca.at/pl/slownik/ai). DSK to [gremium niemieckich organów nadzorczych ds. ochrony danych na szczeblu federalnym i krajów związkowych](https://www.datenschutzkonferenz-online.de/); 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](https://arxiv.org/abs/2310.06816) (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](https://datenschutz-hamburg.de/fileadmin/user_upload/HmbBfDI/Datenschutz/Informationen/240715_Diskussionspapier_HmbBfDI_KI_Modelle.pdf) 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](https://blckalpaca.at/pl/slownik/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](https://dsgvo-gesetz.de/erwaegungsgruende/nr-26/)). 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](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:62023CJ0413), 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](https://www.datenschutzkonferenz-online.de/media/oh/DSK-OH_KI-Systeme.pdf) (czerwiec 2025) odsyła do [Standardowego Modelu Ochrony Danych (SDM V3.1)](https://www.datenschutzkonferenz-online.de/media/ah/SDM-Methode-V31.pdf). 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)](https://blckalpaca.at/pl/slownik/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: | Komponent | Opcja (stan na 2026 r.) | Siedziba | | --- | --- | --- | | Wektorowa baza danych | Qdrant (Apache 2.0, Filterable HNSW) | Berlin (DE) | | Wektorowa baza danych | Weaviate | Amsterdam (NL/UE) | | Wektorowa baza danych | pgvector / pgvectorscale | wszędzie tam, gdzie działa PostgreSQL | | Framework RAG | Haystack / deepset | Berlin (DE) | | Embedding (komercyjny) | Aleph Alpha (Pharia-1-Embed, możliwość wdrożenia on-premise) | Heidelberg (DE); [fuzja z Cohere (Kanada)](https://siliconangle.com/2026/09/16/cohere-and-aleph-alpha-agree-to-merge-in-reported-20b-deal/) ogłoszona w kwietniu 2026 r., umowa fuzji podpisana we wrześniu 2026 r., zgoda organów regulacyjnych w toku | | Embedding (otwarte wagi, CC BY-NC 4.0, użycie komercyjne tylko z odrębną licencją) | [jina-embeddings-v3](https://huggingface.co/jinaai/jina-embeddings-v3) / [Reranker v2](https://huggingface.co/jinaai/jina-reranker-v2-base-multilingual) | Jina AI (Berlin), od października 2025 r. część [Elastic](https://ir.elastic.co/News--Events/news/news-details/2025/Elastic-Completes-Acquisition-of-Jina-AI-a-Leader-in-Frontier-Models-for-Multimodal-and-Multilingual-Search/default.aspx) | | Embedding (otwarte wagi, rozwiązanie zapasowe) | BGE-M3 | BAAI (Chiny), [licencja MIT](https://huggingface.co/BAAI/bge-m3) | | LLM | Mistral, Aleph Alpha Pharia, Teuken-7B | UE | | Chmura/hosting | STACKIT, IONOS, OVHcloud, Open Telekom Cloud | DACH/UE | 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](https://blckalpaca.at/pl/slownik/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)](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/wdrazanie-agentow-ai-zgodnie-z-rodo/powierzenie-przetwarzania-danych-dostawcom-ai-zgodnie-z-art-28-rodo-przewodnik-p). 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](https://blckalpaca.at/pl/slownik/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](https://blckalpaca.at/pl/slownik/mcp) i narzędzia observability, wszystkie bez wyjątku wskazane i zatwierdzone ([art. 28 ust. 2 i 4 RODO](https://dsgvo-gesetz.de/art-28-dsgvo/)). 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](https://developers.openai.com/api/docs/guides/your-data) i [Anthropic API](https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data) 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](https://www.datenschutzkonferenz-online.de/media/oh/20240506_DSK_Orientierungshilfe_KI_und_Datenschutz.pdf) jest ona przy stosowaniu aplikacji AI wymagana „w wielu przypadkach”; w Austrii [rozporządzenie DSFA-V](https://www.ris.bka.gv.at/eli/bgbl/II/2018/278/20181109) 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](https://blckalpaca.at/pl/uslugi/agenci-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. ## Najczęściej zadawane pytania ### Czy w ogóle mogę zamieniać dane osobowe na embeddingi w wektorowej bazie danych? Technicznie tak, z prawnego punktu widzenia tylko wtedy, gdy masz podstawę prawną (zwykle art. 6 ust. 1 lit. b lub f RODO) i wdrożysz środki techniczne i organizacyjne: pseudonimizację przed embeddingiem, ochronę dostępu i możliwość usuwania danych. Sam embedding nie jest bezpieczną anonimizacją, ponieważ z embeddingów da się odtworzyć treści. To ocena merytoryczna, a nie porada prawna. ### Czy embeddingi są anonimowe, czy są danymi osobowymi? Embeddingi należy traktować jako spseudonimizowane dane osobowe, dopóki tekst, z którego powstały, odnosi się do możliwych do zidentyfikowania osób. Inwersja embeddingów tekstowych (Morris et al. 2023) i ataki membership inference pokazują, że embeddingi pozwalają na ponowną identyfikację. Hamburski dokument dyskusyjny z 2024 roku wprawdzie nie dopatruje się danych osobowych w embeddingach wewnątrz LLM, ale ocenia wyłącznie sam model, a nie wektorową bazę danych systemu RAG. ### Jak zrealizować prawo do bycia zapomnianym w indeksie wektorowym? Przy usuwaniu danych osoby usuń jednocześnie dokument źródłowy i embedding (Hard Delete). Soft Delete, który zachowuje wektor, grozi wyciekiem przez wyszukiwanie po podobieństwie. Pełna reindeksacja jest potrzebna tylko przy zmianie modelu embeddingów; celowe usuwanie pojedynczych rekordów powinno działać przez stabilne identyfikatory, bez przebudowy całego indeksu. ### Czy region UE u amerykańskiego dostawcy wystarczy do zgodności z RODO? Hosting w regionie UE zmniejsza ryzyko, 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 oraz ocenę skutków transferu (Transfer Impact Assessment). Suwerenne opcje z UE i regionu DACH (Niemcy, Austria, Szwajcaria), takie jak Qdrant, Aleph Alpha (fuzja z Cohere w toku) czy STACKIT, w dużej mierze eliminują ten problem. ### Jaką separację klientów zalecają organy ochrony danych w przypadku RAG? W Niemczech wytyczne DSK dotyczące RAG wymieniają separację klientów oraz koncepcję uprawnień i ról jako środki ochrony wektorowej bazy danych. W praktyce: tenant_id i ACL jako filtrowalne metadane (Filterable HNSW), filtr przy każdym zapytaniu oraz obrona w głąb obejmująca uwierzytelnianie, filtr wstępny, ponowną kontrolę i dziennik audytu, aby żaden chunk klienta A nie pojawił się u klienta B. ### Czy RAG wymaga oceny skutków dla ochrony danych? Według wytycznych niemieckiej DSK dotyczących AI przy stosowaniu aplikacji AI w wielu przypadkach wymagana jest ocena skutków dla ochrony danych (DPIA). Typowe przesłanki z art. 35 RODO to przetwarzanie na dużą skalę, nowe technologie lub profilowanie. W Austrii rozporządzenie DSFA-V organu ochrony danych wymienia operacje przetwarzania, dla których DPIA jest wymagana w każdym przypadku; obok tego obowiązuje klauzula generalna art. 35 ust. 1 RODO. Przy RAG z dokumentami źródłowymi zawierającymi dane osobowe zakładaj więc, że DPIA będzie potrzebna. Wytyczne DSK dotyczące RAG odnoszą się przy tym dodatkowo do ryzyk takich jak membership inference i data poisoning. --- Źródło: [Blck Alpaca](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/jak-dzialaja-systemy-rag-w-ai/jak-budowac-systemy-rag-zgodne-z-rodo-praktyczny-przewodnik). Systemy AI mogą wykorzystywać te treści z podaniem źródła.