Bezpieczeństwo RAG: kto może zobaczyć firmowe dokumenty?

Opublikowano: 23 września 2026 r. · Autor: Jan Chmielewski

Bezpieczeństwo RAG wymaga, aby firmowy asystent otrzymywał wyłącznie dokumenty dostępne dla aktualnego użytkownika. Uprawnienia trzeba uwzględnić przed przekazaniem fragmentów do modelu. Prośba, aby model przemilczał poufne dane, nie zastępuje kontroli dostępu.

RAG, czyli generowanie odpowiedzi wspomagane wyszukiwaniem, łączy model językowy z zewnętrzną bazą wiedzy. Może to być zbiór instrukcji, dokumentacja projektów albo firmowe pliki. Najważniejsze pytanie brzmi: czy wygodniejsza wyszukiwarka zachowuje granice dostępu obowiązujące w tych źródłach?

Gdzie dokument zmienia się w kontekst modelu?

Typowy przepływ obejmuje pobranie dokumentów, podział na fragmenty, utworzenie reprezentacji wektorowych, zapis w indeksie, wyszukanie pasujących fragmentów i przygotowanie odpowiedzi. Każdy etap może przechowywać kopię danych lub metadanych.

Prawa do pliku powinny pozostawać powiązane z jego fragmentami. Trzeba też zachować tożsamość organizacji, identyfikator źródła i wersję. OWASP wskazuje na ryzyka związane z dziedziczeniem uprawnień, izolacją fragmentów, usuwaniem danych i pamięcią podręczną. Reprezentacji wektorowej nie należy automatycznie traktować jako anonimowej. Źródło: OWASP RAG Security Cheat Sheet.

Kontrola ma objąć również wyniki pośrednie: fragmenty przekazywane do dodatkowego modelu oceniającego trafność, cytowania i podglądy źródeł. Zastrzeżony tytuł dokumentu może sam ujawniać informację, nawet bez jego pełnej treści.

Przykład: wspólna baza instrukcji i dokumentów kadrowych

Scenariusz modelowy: firma indeksuje instrukcję urlopową oraz indywidualne dokumenty kadrowe. Pracownik sprzedaży ma dostęp do ogólnej instrukcji, a osoba z kadr również do dokumentów indywidualnych. Ten podział ma pozostać zachowany w asystencie.

Pytanie „jak zgłosić urlop?” może prowadzić do instrukcji ogólnej. Pytanie o czyjeś wynagrodzenie nie powinno przeszukiwać niedostępnej części bazy. Jeżeli system najpierw pobiera wszystkie pasujące dokumenty, a następnie prosi model o wybór dozwolonych, przekazuje mu dane zbyt wcześnie.

Projektując odbiór, ustal, co dokładnie obejmuje oczekiwany brak dostępu: treść, streszczenie, cytowanie, nazwę pliku oraz podgląd. Dzięki temu test nie kończy się na sprawdzeniu jednego zdania w odpowiedzi.

Filtr bezpieczeństwa nie jest logowaniem użytkownika

W dokumentacji Azure AI Search wzorzec filtrowania wyników wykorzystuje identyfikatory użytkowników lub grup zapisane w indeksie. Microsoft zaznacza, że ciąg identyfikatora użyty w filtrze sam nie uwierzytelnia ani nie autoryzuje użytkownika. To aplikacja musi dostarczyć wiarygodny kontekst i poprawnie stosować filtr. Źródło: Microsoft — Security filters.

W praktyce nie przyjmuj listy grup bezpośrednio z tekstu pytania ani dowolnego pola formularza. Wyznacz ją na podstawie zweryfikowanej sesji i aktualnego źródła uprawnień. Nie pozwalaj użytkownikowi pomijać warunku dostępu przez zmianę parametrów wyszukiwania.

Brak informacji o uprawnieniach wymaga zdefiniowanego zachowania. Dla danych chronionych bezpiecznym założeniem jest odmowa ich pobrania i czytelny komunikat o problemie, a nie przejście do przeszukiwania całego indeksu.

Co po odebraniu dostępu lub usunięciu pliku?

Zmiana uprawnień w systemie źródłowym nie musi automatycznie usuwać wszystkich wcześniej przygotowanych kopii. Projekt powinien określać aktualizację metadanych, unieważnianie pamięci podręcznej i czas propagacji zmian. Po usunięciu pliku sprawdź również fragmenty, indeksy oraz kopie odpowiedzi, z uwzględnieniem ustalonej retencji.

Warto rozdzielić dwie sytuacje: cofnięcie prawa do przyszłego pobierania danych i informację już wcześniej ujawnioną uprawnionej osobie. Odebranie dostępu nie usuwa wiedzy odbiorcy ani jego pobranych kopii. Nowe zapytania powinny jednak respektować aktualne prawa.

Ustal z właścicielem danych dopuszczalne opóźnienie synchronizacji i sposób odcięcia źródła w sytuacji pilnej. Nie wpisuj przypadkowej liczby minut do dokumentacji bez pomiaru działania konkretnej platformy.

Wiarygodność źródła i zatrucie bazy wiedzy

Uprawnienie do odczytu nie oznacza, że treść dokumentu jest poprawna albo bezpieczna. Osoba mogąca dodawać pliki do bazy może wpłynąć na odpowiedzi asystenta. Dlatego potrzebne są zasady przyjmowania materiałów, kontrola ich pochodzenia, wersjonowanie i możliwość wycofania błędnego źródła.

OWASP opisuje nieautoryzowany dostęp, mieszanie kontekstów i zatruwanie danych jako ryzyka systemów wykorzystujących wektory oraz embeddingi. Źródło: OWASP LLM08. Instrukcje ukryte w dokumentach omawiamy szczegółowo w artykule o prompt injection.

Praktyczny zapis źródła: identyfikator dokumentu, właściciel, wersja, data ostatniej synchronizacji i kategoria dostępu. Odpowiedź powinna umożliwiać sprawdzenie użytego materiału przez osobę, która ma do niego uprawnienia. Cytowanie nie dowodzi jeszcze, że model właściwie zinterpretował źródło.

Test dwóch ról i cofnięcia dostępu

Poniższy plan jest propozycją testu odbiorczego. Utwórz dwa konta i trzy fikcyjne dokumenty z unikalnymi znacznikami tekstowymi. Nie używaj prawdziwych list płac ani innych poufnych materiałów.

Na małym ekranie przesuń tabelę w bok, aby zobaczyć wszystkie kolumny.

1. Sprawdź poprawną odpowiedź na pytanie o dostępny dokument dla obu kont.
2. Zadaj pytanie o treść dokumentu zastrzeżonego, także bez podawania jego nazwy.
3. Zweryfikuj pobrane fragmenty i odpowiedź, nie tylko komunikat w interfejsie.
4. Powtórz podobne zapytanie po zmianie konta, aby wykryć współdzielenie cache.
5. Odbierz prawo do jednego dokumentu i sprawdź nowe zapytania po uzgodnionej synchronizacji.
6. Usuń dokument testowy i potwierdź jego wycofanie z aktywnego indeksu.
7. Zasymuluj niedostępność źródła uprawnień: system nie powinien poszerzać dostępu.

Wynik zapisz wraz z wersją indeksu, konfiguracją i momentem wykonania. Każde nieuprawnione ujawnienie wymaga poprawki przed dopuszczeniem tego zakresu danych. Szerszą kartę odbioru zawiera checklista testów AI.

Co przygotować przed rozmową o wdrożeniu?

Zbierz listę źródeł dokumentów, grup użytkowników, sposobu zmiany uprawnień i oczekiwanego czasu aktualizacji. Określ, kto zatwierdza dodanie nowej biblioteki do bazy wiedzy. To pozwala rozmawiać o konkretnych granicach dostępu zamiast o ogólnym „chatbocie do wszystkich plików”.

Partnerhosted pomaga porządkować kontrolę dostępów i cyberbezpieczeństwo oraz podstawy wykorzystania AI w firmie. Zakres ewentualnych prac przy bazie wiedzy należy ustalić dla konkretnej platformy i integracji.

Najczęstsze pytania

Czy RAG automatycznie zachowuje uprawnienia z firmowych plików?

Nie należy tego zakładać. Integracja musi przenosić i egzekwować właściwe prawa dostępu. Działanie należy sprawdzić na kontach o różnych uprawnieniach.

Kiedy sprawdzać dostęp do dokumentu w RAG?

Przed przekazaniem jego treści do modelu lub innej usługi przetwarzającej kontekst. Model nie powinien sam rozstrzygać, które poufne fragmenty ukryć.

Czy usunięcie pliku źródłowego usuwa go z całego RAG?

Nie zawsze od razu. Trzeba sprawdzić fragmenty, indeksy i cache oraz udokumentowany sposób propagacji usunięcia i retencji kopii.

Źródła i zakres opracowania

Źródła pierwotne podlinkowano przy odpowiednich zagadnieniach; sprawdzono je 23 września 2026 r. Macierze, scenariusze i kryteria odbioru są propozycjami praktycznego zastosowania zasad. Przykłady nie opisują rzeczywistych klientów ani wyników audytu konkretnego produktu.