Kontrola dostępu w asystencie dokumentów: kto widzi który plik

Asystent dokumentów, który odpowiada na podstawie wewnętrznych plików, dziedziczy wszystkie problemy z uprawnieniami, jakie ma już repozytorium plików. I dokłada kilka nowych. Budujemy systemy retrieval augmented generation i kontrola dostępu to pytanie, które klienci zadają na końcu, a powinni na początku. Zrobienie tego dobrze to praca architektoniczna, a nie ptaszek do odhaczenia na tydzień przed startem.

Dlaczego retrieval psuje zwykły model uprawnień

Wyszukiwarka zwraca linki. Asystent zwraca gotowy tekst, więc wyciek przychodzi jako płynne zdanie, a nie jako widoczna nazwa pliku. Nikt nie zauważy sygnału ostrzegawczego. Chunking gubi kontekst folderu, jeśli uprawnienia nie jadą razem z każdym fragmentem, a indeks embeddingów jest domyślnie płaską przestrzenią nazw: każdy chunk tak samo osiągalny dla każdego zapytania. Do tego odpowiedzi wklejają się na czat, idą dalej, lądują w prezentacjach. Jedno złe pobranie zajdzie znacznie dalej niż kiedykolwiek zaszło jedno złe pobranie pliku. Rozstrzygnij to więc przed wszystkim innym: czy asystent egzekwuje dostęp, czy go dziedziczy?

Trzy miejsca na egzekwowanie dostępu i koszt każdego z nich

1. Przy ingestii: jeden indeks na grupę odbiorców. Najłatwiej to ogarnąć, najmniejszy zasięg ewentualnej szkody i prawdziwy ból w dniu, w którym ktoś zmienia zespół i całość idzie do ponownego indeksowania.
2. W zapytaniu: jeden indeks, metadane uprawnień przy każdym chunku, filtrowanie wewnątrz wyszukiwania wektorowego. Niewielki koszt opóźnienia, żadnego reindeksowania przy zmianie przynależności.
3. Po pobraniu: najpierw pobierz, potem odrzuć zakazane chunki. Najsłabsze z trzech, bo buggy filtr ma już ten tekst w pamięci.

Domyślnie robimy to w zapytaniu. Osobne indeksy zostawiamy dla materiałów, które nigdy nie mogą dzielić magazynu: kadry, dział prawny, dokumenty zarządu.

Uprawnienia jako metadane chunka

Każdy chunk niesie to, co odziedziczył po źródle: identyfikatory grup, wpisy ACL, przynależność do witryny lub folderu, etykietę poufności. Zapisuj identyfikatory, nie nazwy. Zmiana nazwy grupy nigdy nie powinna po cichu otworzyć drzwi. Reguły odmowy też muszą być jawne, bo logika oparta wyłącznie na liście dozwolonych udostępnia za dużo wszędzie tam, gdzie system źródłowy opiera się na wyjątkach - a większość się na nich opiera. Przynależność użytkownika rozstrzygaj w momencie zapytania, prosto z dostawcy tożsamości. Nigdy z kopii zbuforowanej podczas ingestii.

Wskazówka: chunk bez etykiety traktuj jako prywatny i zapisz to w logu, zamiast pozwolić mu wpaść do warstwy publicznej.

Jak utrzymać aktualne uprawnienia po ingestii

Uprawnienia zmieniają się szybciej niż dokumenty. Cofnięcia dostępu, odejścia z firmy, zarchiwizowane projekty, foldery przeciągnięte do przestrzeni z ograniczeniami. Sprawdzają się tu dwa wzorce synchronizacji: okresowy pełny przegląd ACL i aktualizacje sterowane zdarzeniami z kanału zmian systemu źródłowego. Usunięcie musi dotrzeć do trzech miejsc, a zespoły regularnie zapominają o trzecim - do rekordu źródłowego, do indeksu wektorowego oraz do zbuforowanych odpowiedzi i historii rozmów. Te zdarzenia podepnij w pierwszej kolejności:

• Użytkownik dezaktywowany lub odchodzący z firmy
• Dodanie lub usunięcie z grupy
• Przeniesienie dokumentu, zmiana jego ACL lub cofnięcie udostępnienia
• Usunięcie lub zarchiwizowanie dokumentu

Cytowania, fragmenty i wyciek, którego nikt nie pilnuje

To dołączanie źródeł sprawia, że asystentowi można zaufać. Tworzy też dokładnie tę powierzchnię, przez którą wymyka się tytuł. Sama nazwa pliku zdradza klienta, kod projektu, reorganizację, której nikt jeszcze nie ogłosił. Filtruj cytowania tą samą regułą, która przefiltrowała chunk, i pokazuj tylko to, co czytelnik mógłby otworzyć samodzielnie. Drugim martwym polem jest pamięć rozmowy: dziedziczy wszystko, co pobrały wcześniejsze tury, więc udostępniony wątek może przeżyć dostęp osoby, która go udostępniła.

Wskazówka: zrób z każdego cytowania żywy link do systemu źródłowego, żeby jego własne sprawdzenie uprawnień stało się drugą bramką.

Chmura czy instalacja własna: co naprawdę się zmienia

Model uprawnień jest w obu wdrożeniach identyczny. Różni się to, gdzie sprawdzana jest tożsamość i kto trzyma logi. Instalacje własne siedzą wewnątrz istniejącego perymetru i mają dostęp do wewnętrznych katalogów, które nigdy nie wychodzą do internetu. Wdrożenia chmurowe wymagają jasnej odpowiedzi, gdzie leżą embeddingi, bo embedding pochodzi z dokumentu i zasługuje na takie samo traktowanie. Klienci z branż regulowanych zwykle chcą całej ścieżki retrievalu na własnym sprzęcie, a nie samego modelu. Żaden z tych wyborów nie zdejmuje uprawnień na poziomie chunka. Izolacja sieciowa pilnuje perymetru; w niczym nie chroni współpracowników przed sobą nawzajem.

Testowanie, czy reguły trzymają

Zbuduj dane testowe: użytkowników testowych na każdym poziomie, dokumenty, do których ma sięgać tylko jeden poziom. Potem przed startem przejdź te kontrole:

1. Zapytaj pośrednio o treści zastrzeżone - widełki płacowe, nieogłoszoną akwizycję, sprawę dyscyplinarną.
2. Cofnij użytkownikowi dostęp w trakcie sesji i sprawdź, czy kolejna odpowiedź się zmieni.
3. Przejdź cały zestaw jeszcze raz po każdej zmianie chunkera albo konektora, bo metadane gubią się bez śladu.
4. Loguj identyfikatory pobranych chunków przy każdej odpowiedzi, żeby audyt mógł odtworzyć, co zostało pokazane, bez przechowywania treści odpowiedzi.

FAQ

Czy asystent może po prostu korzystać z uprawnień z SharePointa albo Google Drive?

Tak, jeśli konektor czyta ich listy ACL i utrzymuje je zsynchronizowane. Ryzyko siedzi w nieaktualnych kopiach i w regułach odmowy, których konektor nie obsługuje.

Czy filtrowanie per użytkownik spowalnia retrieval?

Współczesne bazy wektorowe filtrują po metadanych już w trakcie samego wyszukiwania. Prawdziwym kosztem jest recall przy wąskim filtrze, co naprawia się pobieraniem większej liczby kandydatów.

Co dzieje się z odpowiedziami wygenerowanymi wcześniej, gdy dostęp zostanie cofnięty?

Zostają, chyba że historia rozmów ma swój zakres i jest ponownie sprawdzana. Traktuj historię jak treść do pobrania, rządzącą się własnymi regułami.

Podsumowanie

Kontrola dostępu należy do fazy projektowania, przed ingestią, a nie do doklejenia na tydzień przed startem. Sensowne ustawienie domyślne: uprawnienia jako metadane chunka, przynależność rozstrzygana w momencie zapytania, cytowania filtrowane tą samą regułą. Osobne indeksy pozostają przydatne dla wąskiego zestawu materiałów, które nigdy nie powinny dzielić magazynu. Niezależnie od wdrożenia twój asystent powinien umieć odpowiedzieć na pytanie audytu - które chunki zobaczyła ta osoba i dlaczego wolno jej było?