Jak zbudować bezpieczny RAG: uprawnienia do dokumentów, RODO i ochrona przed wyciekiem?

Szybka odpowiedź

Bezpieczny RAG to taki, który nigdy nie pokaże użytkownikowi więcej, niż ten zobaczyłby bez AI. W praktyce oznacza to: uprawnienia z systemów źródłowych przeniesione do indeksu i sprawdzane w każdym zapytaniu (a nie po fakcie), ochronę przed wyciekiem przez odpowiedzi, logi i cache, ograniczenie danych osobowych zgodnie z RODO, modele on-premise tam, gdzie dane nie mogą opuścić firmy, oraz stałe testy i monitoring.

Dlaczego RAG zmienia zasady bezpieczeństwa danych?

Bo model widzi i streszcza wszystko, co zwróciło wyszukiwanie. RAG (Retrieval-Augmented Generation) to architektura, w której przed odpowiedzią system wyszukuje pasujące fragmenty dokumentów firmy i przekazuje je modelowi jako kontekst. Jak to działa krok po kroku, opisujemy w artykule jak RAG sprawia, że AI jest mądrzejsze.

Klasyczna wyszukiwarka pokazuje listę dokumentów, a system dostępu decyduje, czy użytkownik może je otworzyć. RAG działa inaczej: łączy treść wielu fragmentów w jedną odpowiedź. Jeśli do kontekstu trafi fragment umowy z działu prawnego albo tabela wynagrodzeń, model może go streścić osobie, która nigdy nie zobaczyłaby tego dokumentu.

OWASP w edycji 2026 listy ryzyk dla aplikacji LLM ujmuje to krótko: w warstwie wyszukiwania błąd kontroli dostępu sprawia, że system pokazuje treści bez rozróżnienia, komu wolno je zobaczyć (OWASP GenAI Security Project, 2026). W systemach agentowych, w których model sam decyduje, czego i ile razy szukać, ta zasada ma jeszcze większe znaczenie. Piszemy o nich w artykule o agentic RAG.

Jak działa wyszukiwanie z uprawnieniami (ACL-aware retrieval)?

Każdy dokument i fragment w indeksie niesie informację, kto może go czytać, a wyszukiwanie filtruje wyniki po tożsamości użytkownika w samym zapytaniu do indeksu. ACL (access control list) to lista użytkowników lub grup z prawem dostępu do zasobu.

OWASP wymienia to jako kontrolę podstawową dla każdego wdrożenia: autoryzacja przed wyszukiwaniem, na poziomie dokumentu i fragmentu, wewnątrz zapytania do indeksu, a nie w warstwie aplikacji po pobraniu wyników. Zakres przekazany przez klienta to "sugestia, a nie kontrola", więc tożsamość i grupy ustala się po stronie serwera (OWASP GenAI Security Project, 2026).

Tak to wygląda w praktyce:

1. Przy ładowaniu dokumentów pobierasz z systemu źródłowego (SharePoint, dysk sieciowy, DMS, CRM) listę grup z dostępem i zapisujesz ją przy każdym fragmencie.
2. Przy zapytaniu aplikacja ustala tożsamość użytkownika z tokenu logowania, pobiera jego grupy i dodaje filtr do zapytania wektorowego i pełnotekstowego.
3. Do modelu trafiają wyłącznie fragmenty, które przeszły filtr. Model nie decyduje o dostępie.
4. Przy zmianie uprawnień w źródle indeks jest aktualizowany. Odebranie dostępu, które dotrze do indeksu po tygodniu, to tydzień wycieku.

Wyszukiwarki i bazy wektorowe mają do tego gotowe mechanizmy. Przykładowo Azure AI Search opisuje wzorzec filtra bezpieczeństwa, w którym pole z identyfikatorami grup jest filtrowane w każdym zapytaniu, a dokumenty bez pasującej grupy w ogóle nie wracają w wynikach (Microsoft Learn). Elasticsearch ma bezpieczeństwo na poziomie dokumentu i pola (Elastic).

Na co uważać przy uprawnieniach?

• Fragment, nie tylko dokument. OWASP przypomina, że w dokumencie w większości publicznym może być jeden poufny akapit. Dla takich treści uprawnienia nadaje się na poziomie fragmentu.
• Wspólny indeks dla różnych poziomów zaufania. Treści z internetu, dokumenty wewnętrzne i dane partnerów nie powinny dzielić jednego indeksu bez twardej izolacji. Przy najwrażliwszych danych lepsze są osobne indeksy niż etykiety w jednym.
• Wnioski z połączenia. Pojedyncze fragmenty mogą być dozwolone, a ich połączenie już nie (na przykład lista projektów plus lista osób na zwolnieniach). To decyzja z obszaru data governance: które źródła wolno łączyć w jednym systemie.

Jak dane wyciekają przez odpowiedzi RAG?

Częściej bokiem niż wprost. Złe uprawnienia w indeksie to najbardziej oczywisty kanał, ale nie jedyny.

Kanał z ukrytymi poleceniami to pośredni prompt injection: atak, w którym złośliwe instrukcje pochodzą z treści czytanej przez system, a nie od użytkownika. OWASP wskazuje, że wstrzyknięcie, które trafi do bazy RAG albo pamięci, wpływa na każdą kolejną sesję, która z niej czyta. Dlatego przy ładowaniu warto usuwać niewidoczne znaki i ukryty tekst (na przykład biały na białym tle) i śledzić pochodzenie każdego fragmentu. Więcej o tym zagrożeniu w artykule o bezpieczeństwie agentów AI i serwerów MCP.

Kanał z obrazkami jest mniej oczywisty: jeśli interfejs czatu automatycznie wyświetla obrazki z adresów wygenerowanych przez model, atakujący może skłonić model do wpisania danych w adres URL. OWASP opisuje to przy ryzyku niewłaściwej obsługi wyników.

Jak traktować dane osobowe w RAG zgodnie z RODO?

Jak w każdym innym systemie przetwarzającym dane osobowe, z kilkoma zadaniami specyficznymi dla RAG. RODO nie zakazuje baz wiedzy z AI, ale wymaga, żeby zakres danych, cel i zabezpieczenia były przemyślane.

Raport o ryzykach prywatności w modelach LLM, przygotowany na zlecenie Europejskiej Rady Ochrony Danych (EROD) w programie Support Pool of Experts, wymienia dla RAG trzy typowe ryzyka: niezabezpieczone logi i cache z pytaniami i pobranymi dokumentami, przekazywanie zapytań do zewnętrznych usług oraz ujawnienie danych osobowych przechowywanych w bazie wiedzy. Wśród zabezpieczeń wskazuje kontrolę dostępu, anonimizację lub pseudonimizację, logi dostępu i zmian oraz przestrzeganie zasad przekazywania danych przy RAG zlecanym na zewnątrz (EDPB, 2025).

W praktyce lista zadań wygląda tak:

• Minimalizacja (art. 5 RODO). Do indeksu trafiają dokumenty potrzebne do celu. Dane osobowe, które nie są potrzebne do odpowiedzi (numery PESEL, dane kontaktowe w stopkach, dane zdrowotne), usuwasz lub pseudonimizujesz przy ładowaniu. Do wykrywania danych osobowych w tekście służą narzędzia takie jak Microsoft Presidio (Presidio), ale warto je testować na polskich danych, bo skuteczność zależy od języka i formatu.
• Okres przechowywania. Ustal, jak długo żyją dokumenty w indeksie, logi pytań i cache.
• Prawo do usunięcia (art. 17). Usunięcie danych osoby oznacza usunięcie fragmentów i embeddingów z indeksu, a nie tylko pliku w źródle. Zaplanuj to w potoku ładowania.
• Ocena skutków (art. 35). Przy przetwarzaniu wysokiego ryzyka, na przykład dużej skali danych szczególnych kategorii, potrzebna jest DPIA. Warto przygotować ją z inspektorem ochrony danych przed wdrożeniem.
• Dostawcy (art. 28) i transfery. Jeśli model lub baza działają u dostawcy, potrzebna jest umowa powierzenia, wiedza o lokalizacji przetwarzania i wyłączenie trenowania na Twoich danych (RODO).

Kiedy uruchomić model on-premise zamiast API w chmurze?

Gdy dokumenty albo pytania zawierają dane, które nie mogą opuścić firmy: tajemnicę przedsiębiorstwa, dane szczególnych kategorii, dokumentację objętą tajemnicą zawodową. Wtedy model językowy, model embeddingów i reranker działają na Twojej infrastrukturze.

Tak zbudowaliśmy naszą agentową bazę wiedzy: całość działa on-premise, na własnych GPU, z lokalnymi modelami, więc dokumenty i pytania nie opuszczają firmy. Jak wygląda AI na własnej infrastrukturze, pokazujemy na stronie Infrastruktura AI.

Jak testować i monitorować bezpieczeństwo RAG?

Tak samo regularnie jak jakość odpowiedzi, bo jedno i drugie psuje się przy zmianach indeksu, modelu i uprawnień. Bezpieczeństwo RAG to nie jednorazowy przegląd, tylko zestaw testów, który uruchamia się po każdej zmianie.

Testy przed wdrożeniem i po każdej zmianie:

• Testy uprawnień. Pytania z kont różnych działów o treści, których nie powinny zobaczyć. Wynik oczekiwany: odmowa albo odpowiedź bez tych danych.
• Testy wstrzyknięć. Dokumenty testowe z ukrytymi poleceniami. Sprawdzasz, czy system je wykonuje.
• Testy wycieku danych osobowych. Pytania, które próbują wydobyć dane osób z dokumentów, w których nie powinny być widoczne.

Ugruntowanie i źródła w każdej odpowiedzi:

OWASP przy ryzyku dezinformacji zaleca opieranie twierdzeń na aktualnych, autorytatywnych źródłach i sprawdzanie ugruntowania, a nie samej pewności modelu (OWASP GenAI Security Project, 2026). W naszej bazie wiedzy każde twierdzenie w odpowiedzi ma przypis do konkretnego fragmentu dokumentu, a przed wysłaniem odpowiedź przechodzi przez kontrolę ugruntowania w źródłach i detektor halucynacji. Przypisy pomagają też w bezpieczeństwie: od razu widać, z którego dokumentu pochodzi informacja, więc łatwiej wykryć fragment, który nie powinien był trafić do kontekstu.

Monitoring w produkcji:

• ślad każdego kroku (zapytanie, filtry, pobrane fragmenty, odpowiedź) w warstwie obserwowalności, z kontrolą dostępu do samych logów,
• alerty na nietypowe wzorce: duża liczba zapytań z jednego konta, zapytania zwracające nietypowo wiele fragmentów, fragmenty pasujące do bardzo wielu różnych pytań (OWASP opisuje to jako sygnał zatrucia indeksu),
• prosty kanał zgłaszania złych odpowiedzi i ścieżka od zgłoszenia do źródła.

Lista kontrolna bezpiecznego RAG

Częsty błąd przy budowie RAG to uprawnienia "do zrobienia później": system powstaje na wspólnym indeksie wszystkich dokumentów, a kontrolę dostępu planuje się na drugi etap. Wtedy trzeba przebudować potok ładowania. Taniej jest zaprojektować uprawnienia od pierwszego dokumentu.

Źródła

• OWASP GenAI Security Project: OWASP GenAI LLM Top 10 2026
• EDPB: AI Privacy Risks and Mitigations, Large Language Models (2025)
• Rozporządzenie (UE) 2016/679 (RODO)
• Microsoft Learn: Security filter pattern, Azure AI Search
• Elastic: Controlling access at the document and field level
• Microsoft Presidio: wykrywanie i anonimizacja danych osobowych