Uprawnienia RAG dla chatbotów na stronie: Bezpieczne zarządzanie dostępem do dokumentów

Chatbot na stronie internetowej może łączyć odpowiedzi ze stron FAQ, dokumentacji produktów i wewnętrznych baz wiedzy. Jest to niezwykle pomocne – dopóki ta sama baza nie zawiera treści, które nie są przeznaczone dla każdego. Wówczas o bezpiecznej odpowiedzi nie decyduje sama jakość modelu językowego, lecz poprzedzający ją krok wyszukiwania (Retrieval): do jakich dokumentów ten konkretny użytkownik w ogóle może mieć dostęp?

Uprawnienia RAG łączą zweryfikowane tożsamości, role lub grupy z metadanymi przypisanymi do dokumentów. Chatbot otrzymuje wyłącznie przefiltrowane wcześniej źródła. Celem jest świadome ograniczenie roli AI: to nie model ma na podstawie promptu decydować, czy coś jest poufne. Aplikacja ogranicza dozwolony kontekst, dokumentuje tę decyzję i w przypadku niepewności wybiera bezpieczny scenariusz awaryjny (fallback).

Dlaczego reguły w prompcie nie zastąpią kontroli dostępu

Instrukcja systemowa typu „Nie ujawniaj wewnętrznych informacji” jest przydatna, ale nie stanowi warstwy uprawnień. Jeśli niedozwolony dokument trafi do kontekstu, model w swojej odpowiedzi może go podsumować, pośrednio ujawnić lub odtworzyć na dopytanie użytkownika. Równie omylna i spóźniona jest późniejsza weryfikacja wygenerowanego tekstu. Bezpieczeństwo zaczyna się przed generowaniem – a najlepiej jeszcze przed ustaleniem kolejności wyników.

Azure AI Search opisuje Security Trimming jako wzorzec filtrowania: dokumenty zawierają identyfikatory tożsamości lub grup, a zapytanie zawiera tylko uprawnienia (Principals) osoby pytającej. Amazon Bedrock podobnie wskazuje, że filtry wyszukiwania uwzględniające ACL nie zastępują uwierzytelniania. Twoja aplikacja musi najpierw sama niezawodnie zweryfikować tożsamość i przekazać wyłącznie zweryfikowany kontekst.

Cztery filary stabilnego rozwiązania

1. Weryfikacja tożsamości i sesji po stronie serwera

Publiczne okno czatu z reguły nie posiada praw do prywatnych dokumentów i powinno korzystać wyłącznie z publicznych źródeł. W przypadku portalu klienta lub strefy pracowniczej tożsamość użytkownika jest ustalana na podstawie istniejącego logowania. Odczytuj rolę, organizację oraz odpowiednie grupy po stronie serwera z sesji lub podpisanego tokena. Nigdy nie polegaj na polach przesyłanych dowolnie przez przeglądarkę (np. role=admin) ani na wiadomościach na czacie deklarujących przynależność do grupy.

2. Utrzymywanie metadanych uprawnień przy każdym źródle

Każdy fragment tekstu (chunk) wymaga – oprócz samej treści, adresu URL i daty aktualizacji – przejrzystych informacji o dostępie: np. audience=public, ID najemcy (tenant ID), listy dozwolonych grup lub klasyfikacji. Metadane te muszą pochodzić z tego samego źródła biznesowego co uprawnienia do dokumentu. Osobny arkusz kalkulacyjny, aktualizowany tylko od czasu do czasu, prowadzi do niebezpiecznej rozbieżności danych. Przy nowych dokumentach i zmianach praw grup synchronizacja metadanych musi być stałą częścią procesu publikacji lub indeksowania (crawl).

3. Filtrowanie przed ustaleniem kolejności (rankingiem)

Zapytanie (Query) buduje filtr na podstawie zweryfikowanego kontekstu. Dopiero po tym oceniane są trafienia semantyczne lub hybrydowe. Dzięki temu poufna instrukcja nie wygra jako „najbardziej pasujący wynik”, by dopiero później zostać odrzuconą. W środowiskach wielonajemczych (multi-tenant) ID najemcy jest filtrem bezwzględnie wymaganym, a nie tylko sygnałem dla rankingu. Dla danych osobowych lub szczególnie chronionych zaleca się stosowanie osobnych przestrzeni danych zamiast jednej wspólnej, filtrowanej tylko logicznie zbiorczości.

4. Logowanie źródeł i podjętych decyzji

Na potrzeby wsparcia technicznego i analizy incydentów same transkrypcje rozmów nie wystarczą. Przy każdym zapytaniu powinno dać się odtworzyć, jakie niesensytywne atrybuty tożsamości posłużyły do utworzenia filtra, jaka klasa filtra obowiązywała, ile wyników pozostało po przefiltrowaniu i które źródła rzeczywiście trafiły do promptu. Nie przechowuj niepotrzebnych pełnych treści ani tokenów. Oszczędny pod względem danych rejestr zdarzeń (audit log) pozwala wykrywać błędy bez przekształcania systemu monitoringu w drugie wyciekające źródło wiedzy.

Praktyczny proces dla zespołów zajmujących się stroną

1. Przypisz każde źródło wiedzy do jasnej grupy docelowej: publicznej, klientów, partnerów, zespołu wewnętrznego lub konkretnego najemcy.
2. Zdefiniuj, które roszczenia sesyjne (session claims) potwierdzają tę grupę docelową. Grupy z systemu tożsamości są znacznie bezpieczniejsze niż dowolne dane z formularzy.
3. Przenieś te roszczenia po stronie serwera do filtra wyszukiwania i zezwól tylko na mały, znany zestaw pól filtrowania.
4. Przy każdym indeksowaniu wykonuj weryfikację: nowe, zmienione i usunięte dokumenty wymagają również zaktualizowanych metadanych uprawnień.
5. Przekazuj modelowi wyłącznie przefiltrowane wyniki wraz z jasną instrukcją, aby nie zgadywał brakujących informacji.
6. W przypadku braku wyników, sprzecznych źródeł lub niejasnych uprawnień przekieruj użytkownika do bezpiecznego kanału kontaktu.

Proces ten uzupełnia strukturę opisaną w naszym artykule na temat dzielenia treści na fragmenty (RAG Chunking): dobrze podzielone sekcje poprawiają trafność, ale nie zastępują kontroli dostępu. Równie ważna pozostaje świeżość źródeł – nieaktualny stan uprawnień to jednocześnie problem z jakością i bezpieczeństwem.

Błąd architektoniczny: Filtrowanie po wyszukaniu

Częstym błędem projektowym jest podejście: system pobiera 10 najlepszych wyników, a następnie sprawdza ich etykiety i usuwa niedozwolone dokumenty. Z pozoru wydaje się to wystarczające, lecz prowadzi do niebezpiecznych skutków ubocznych. Niedozwolony wynik może trafić do logów, pamięci podręcznej (cache) lub widoku debugowania. Ponadto jego punktacja (score) wpływa na dobór pozostałych wyników. Zdecydowanie lepszym rozwiązaniem jest stosowanie filtra na etapie zapytania wyszukującego, co pozwala rozważać wyłącznie uprawnione dokumenty.

Drugim błędem jest ślepe zaufanie do wbudowanej funkcji ACL danego dostawcy. Dokumentacja techniczna może jasno wskazywać, że usługa uwzględnia listy ACL przy pobieraniu, ale sama nie weryfikuje prawdziwości przekazanego kontekstu użytkownika. Dlatego zweryfikuj dokładnie: kto uwierzytelnia osobę? Skąd pochodzą informacje o grupach? Kiedy uprawnienia są synchronizowane z systemem wyszukiwania? Co się dzieje, gdy brakuje metadanych?

Zasada Fail closed: Co zrobić w przypadku niepewności

W przypadku braku wymaganego claima, niesynchronizowanego źródła lub błędu wyszukiwania chatbot nie powinien próbować szerszego wyszukiwania. Zastosuj neutralną odpowiedź: żądana treść nie jest dostępna w bieżącym kontekście dostępu, a konsultant może sprawdzić uprawnienia. Nie jest to słabość interfejsu konwersacyjnego (Conversational UX), lecz uczciwe wyznaczenie granicy. Artykuł poświęcony przekazywaniu rozmowy człowiekowi (Human Handoff) pokazuje, jak przygotować takie przekazanie płynnie i bez wpadania w ślepy zaułek.

W przypadku treści publicznych obowiązuje ta sama zasada w mniejszej skali: jeśli dostępne źródła nie są wystarczające, bot powinien zasygnalizować niepewność, zaoferować zweryfikowane linki lub wskazać kontakt – zamiast wymyślać prawdopodobne szczegóły. Zmniejsza to ryzyko halucynacji i zapobiega sytuacji, w której odpowiedź sugeruje użytkownikowi wykonanie błędnych działań.

Przypadki testowe wymagane przed wdrożeniem

Testowanie uprawnień to nie jednorazowa weryfikacja przez administratora. Stwórz zestaw testowy (Golden Set) z identycznymi pytaniami dla różnych ról: gościa, zarejestrowanego klienta, uprawnionego partnera, zablokowanego użytkownika oraz administratora. Zdefiniuj dla każdej kombinacji oczekiwane źródła, a nie tylko samą treść odpowiedzi. Przetestuj także zmiany grup, wygaśnięcie sesji, usunięte dokumenty, brakujące metadane ACL oraz awarię usługi wyszukiwania.

Sprawdź w wynikach co najmniej cztery kwestie: żaden niedozwolony URL ani ID dokumentu nie trafia do kontekstu; dozwolone źródła pozostają dostępne; odpowiedź nie cytuje treści z przefiltrowanych dokumentów; a komunikat zastępczy pozostaje zrozumiały. Dołącz te weryfikacje do swoich testów jakości odpowiedzi, aby mierzyć bezpieczeństwo równolegle z jakością merytoryczną.

Pragmatyczne podejście do ochrony danych i przejrzystości

Same dane o uprawnieniach również podlegają ochronie. Używaj stabilnych identyfikatorów technicznych zamiast jawnych nazw w metadanych wyszukiwania. Ogranicz logi audytowe do niezbędnego celu, przedziału czasowego i kluczowych atrybutów. Informuj użytkowników w jasny sposób, gdy chatbot korzysta z dostępu do strefy zalogowanej, oraz zapewnij ścieżkę kontaktu z człowiekiem w sprawach związanych z dostępem. Niniejszy artykuł nie zastępuje indywidualnej porady prawnej – konkretne okresy przechowywania danych i podstawy prawne zależą od kontekstu wdrożenia.

Pod względem technicznym warto opierać się na jasnym podziale odpowiedzialności: właściciele treści (Content Owners) dbają o grupy docelowe, zespół ds. tożsamości odpowiada za tokeny i weryfikację sesji, a zespół produktowy utrzymuje przetestowane filtry i reguły awaryjne. Dzięki temu baza wiedzy nie stanie się niekontrolowanym zbiorem danych, lecz pozostanie źródłem o w pełni nadzorowanym zasięgu.

Lista kontrolna przed uruchomieniem

• Czy każde niepubliczne źródło jest przypisane do roli, grupy lub ID najemcy?
• Czy kontekst zapytania pochodzi ze zweryfikowanej po stronie serwera tożsamości?
• Czy filtr działa jeszcze przed wyszukaniem i ustaleniem kolejności (rankingiem)?
• Czy zmiany praw i procesy crawlera są synchronizowane jednocześnie?
• Czy przeprowadzasz regresyjne testy ról z oczekiwanymi źródłami?
• Czy każdy nieznany lub błędny stan prowadzi do bezpiecznego przekierowania (handoff)?
• Czy logi są oszczędne pod kątem danych i wystarczające do analizy błędów?

Podsumowanie

Dobrej klasy chatbot na stronie internetowej nie odpowiada na każde pytanie każdemu użytkownikowi. Pokazuje wyłącznie źródła pasujące do zweryfikowanego kontekstu dostępu, a w przypadku wątpliwości świadomie powstrzymuje się od odpowiedzi. Zacznij od prostej macierzy źródeł, filtra po stronie serwera i kilku jasnych ról testowych. Następnie możesz stopniowo rozbudowywać metadane uprawnień, logi audytowe i synchronizację – bez powierzania kwestii bezpieczeństwa formułom promptów.

Źródła

• Microsoft Learn: Security Filter Pattern in Azure AI Search
• Microsoft Learn: Document-level access control in Azure AI Search
• Amazon Bedrock: ACL awareness enablement
• Amazon Bedrock: Document-level access controls