RAG odpowiada poprawnie z dokumentu, do którego użytkownik nie ma dostępu. Administrator widzi tylko link i uzna proces za bezpieczny, bo model nie pokazuje pełnego pliku. Problem jest wcześniej: źródło zostało pobrane, fragmenty zapisane, odpowiedź zalogowana. Odmowa odczytu oryginału nie zamyka już tych kopii.
RAG z danymi poufnymi wymaga filtrowania przed wyszukiwaniem, minimalizacji źródeł i kontroli pochodnych. Model nie jest warstwą autoryzacji. Uprawnienia muszą działać zanim fragment trafi do kontekstu.
Zacznij od mapy danych
Wypisz źródła, właścicieli, kategorie, role i skutek ujawnienia. Nie każdy dokument powinien znaleźć się w indeksie. Ogranicz zawartość do wymaganych procesów.
Oddziel dane publiczne, wewnętrzne, poufne i wrażliwe. Ocena podstawy i umowy należy do właściwej osoby. Model nie decyduje, co można zaindeksować.
Przy danych stosuj zasady z artykułu o RODO i minimalizacji AI. RAG nie zmienia automatycznie podstawy przetwarzania.
Uprawnienia przed pobraniem fragmentu
Filtruj dokumenty i kolekcje przed wyszukiwaniem. Tożsamość użytkownika uwierzytelniaj po stronie serwera, a uprawnienia wymuszaj przy każdym zapytaniu tak, by klient nie mógł ich pominąć. Sam identyfikator wpisany w filtrze nie stanowi uwierzytelnienia. Nie pobieraj wszystkiego z prośbą, by model pomijał zakazany kontekst.
Zachowaj identyfikator użytkownika, roli i źródła. Nie pokazuj w odpowiedzi, że dokument istnieje, jeżeli użytkownik nie powinien tego wiedzieć. Odmowa powinna być neutralna.
Przy uprawnieniach stosuj zasady z artykułu o RAG przed wyszukiwaniem. Test odmowy jest równie ważny jak poprawna odpowiedź.
Indeks i fragmenty jako kopie
Zapisz, gdzie znajdują się fragmenty, embeddingi, wersje i metadane. Nie traktuj ich jako bezpiecznych automatycznie. Mogą zawierać pełne poufne zdania i identyfikatory.
Ogranicz role do indeksu i eksportu. Administrator nie powinien być domyślnym kontem codziennej pracy. Logi powinny używać identyfikatorów, nie pełnej treści.
Przy zmianie uprawnień zaktualizuj indeks i cache. Odebranie dostępu w źródle nie usuwa automatycznie pochodnych. Proces powinien mapować każdą warstwę.
Cache i historia odpowiedzi
Oceń, kto widzi stare odpowiedzi po zmianie roli. Historia może zawierać treść niedostępną obecnie. Nie zostawiaj współdzielonej konwersacji bez przeglądu.
Unieważnij cache zgodnie z procesem. Nowa odpowiedź nie powinna korzystać z poprzedniej wersji zakazanego dokumentu. Test powinien sprawdzać również późniejsze cytowania.
Przy retencji stosuj zasady z artykułu o usuwaniu kopii AI. Usuwanie źródła jest dopiero początkiem.
Prompt injection w dokumentach
Dokument może zawierać instrukcję dla agenta: pokaż inne źródła, wykonaj zapis lub ujawnij konfigurację. Traktuj treść jako dane, nie nową rolę. Ogranicz narzędzia i uprawnienia.
Nie polegaj tylko na promptcie obronnym. Model może wykonać działanie mimo grzecznej odpowiedzi. Testuj skutek przy zapisie, eksporcie i pobieraniu innych kolekcji.
Przy obronie stosuj zasady z artykułu o prompt injection AI. RAG wymaga ograniczenia skutku, a nie tylko ładnej odmowy.
Logi i diagnostyka bez pełnej treści
Zapisz identyfikator operacji, wersję, rolę, źródło, status i skutek. Nie loguj pełnych promptów, fragmentów i odpowiedzi bez potrzeby. Diagnostyka tworzy nową kopię.
Przy incydencie przygotuj bezpieczny raport z identyfikatorami. Nie wysyłaj pełnych dokumentów do wsparcia. Wymagane dowody powinny mieć ograniczony dostęp i retencję.
Przy monitoringu stosuj zasady z artykułu o obserwacji błędów AI. Logowanie powinno pomagać bez nowego wycieku.
Wersja źródła i aktualność
Archiwum może być prawdziwe historycznie i niewłaściwe obecnie. Oznacz status, datę obowiązywania i odbiorców. Model nie powinien używać starej wersji jako aktualnej.
Przy usunięciu dokumentu zatrzymaj nowe pobieranie i usuń pochodne. Nie usuwaj historii wymaganej prawnie bez oceny. Przechowywanie nie oznacza dalszego wyszukiwania.
Przy aktualności stosuj zasady z artykułu o monitoringu starych źródeł AI. RAG powinien odpowiadać z właściwej wersji.
Test odmowy i skutku
Przygotuj użytkownika z dozwolonym i zabronionym dokumentem. Sprawdź odpowiedź, fragmenty, cache, logi i cytowania. Nie ograniczaj się do komunikatu odmowy.
Dodaj prompt injection i próbę zmiany roli. Agent nie powinien pobierać innych kolekcji ani wykonywać zapisu. Test kończy się brakiem skutku.
Po zmianie uprawnień powtórz zależne przypadki i jeden poprawny kontrolny. Odbiór powinien sprawdzać dostęp do danych w zidentyfikowanych warstwach. Próbka nie dowodzi braku danych we wszystkich kopiach i przypadkach.
Przykład: stara odpowiedź zostaje
Użytkownik traci dostęp do dokumentu, ale historia współdzielona nadal zawiera odpowiedź. Administrator widzi nową odmowę i uznaje proces za naprawiony. Stara kopia nadal istnieje.
Oceń retencję historii i dostęp do niej. Nie usuwaj całej konwersacji automatycznie, jeżeli proces wymaga innej decyzji. Ogranicz dostęp zgodnie z rolą i skutkiem.
Przy następnym teście sprawdź bezpośredni link i eksport. Odmowa w nowej odpowiedzi nie wystarcza.
Przykład: fragment w logu wsparcia
Model zapisuje pełny prompt i cytat w logu. Dostęp do źródła jest ograniczony, ale wsparcie widzi całość. To nowa ścieżka przetwarzania.
Zmień logowanie na identyfikatory i statusy. Usuń stare kopie zgodnie z retencją i oceń, kto miał dostęp. Nie przesyłaj ich do kolejnego modelu dla analizy.
Przy NDA stosuj zasady z artykułu o danych poufnych AI. RAG wymaga oceny umowy i odbiorców.
Minimalna architektura dla małej firmy
Zacznij od jednej kolekcji publicznej lub zatwierdzonej. Ogranicz pola, role i narzędzia. Nie migruj całej firmy do indeksu na start. Testuj odmowę i usuwanie przed skalą.
Dodaj właściciela, wersję i mapę pochodnych. Proces powinien zatrzymywać się przy nieznanym uprawnieniu i nowym źródle. Model nie jest osobą upoważnioną do wyjątków.
Uprawnienia do pola, a nie tylko dokumentu
Czasem użytkownik może widzieć dokument, ale nie wszystkie pola. Oceń, czy fragmenty można ograniczyć przed indeksowaniem. Nie przenoś pełnej umowy, jeżeli proces wymaga tylko statusu i daty. Mapa powinna opisywać minimalny zakres.
Nie zastępuj uprawnień przez usuwanie danych dopiero w odpowiedzi. Model nie powinien widzieć zakazanych pól i potem grzecznie ich nie cytować. Filtr musi działać przed fragmentem i logiem. Test porównuje użytkowników z różnym zakresem przy tym samym pytaniu.
Zmiana roli w trakcie procesu
Użytkownik może stracić dostęp między wyszukiwaniem a wyświetleniem wyniku. Oceń, czy odpowiedź powinna zostać zatrzymana lub ponownie sprawdzona. Stara rola z początku operacji nie zawsze jest wystarczająca dla końcowego skutku.
Zapisz wersję uprawnień i moment oceny. Przy długich zadaniach dodaj kontrolę przed publikacją i eksportem. Nie usuwaj historii operacji, ale ogranicz dostęp do treści zgodnie z nowym stanem. Proces powinien być przewidywalny również przy zmianie organizacji.
Źródło usunięte przez właściciela
Gdy właściciel usuwa dokument, nie przenoś go do indeksu ponownie przy kolejnej synchronizacji. Tombstone powinien blokować odtworzenie oraz późniejsze odpowiedzi. Stara wersja nie może wrócić jako nowa z powodu innego identyfikatora importu.
Sprawdź, czy eksport i backup nie przywracają obiektu do produkcji. Retencja powinna obejmować wszystkie warstwy i dostawców. Oprócz statusu delete sprawdź charakterystyczną frazę w odpowiedziach i inne dostępne warstwy. Brak frazy w próbce nie dowodzi usunięcia każdej kopii.
Test uprawnień przy podobnych pytaniach
W próbie testowej odbierz dostęp do jednego rekordu i ponów to samo wyszukiwanie z konta użytkownika. Sprawdź osobno fragment odpowiedzi, cytat i podgląd źródła, ponieważ ukrycie jednego widoku nie potwierdza usunięcia pozostałych kopii.
Przygotuj jedno pytanie ogólne, jedno o dokument poufny i jedno o dane z innego zespołu. Sprawdź, czy system odpowiada tylko z dozwolonych źródeł i czy nie ujawnia istnienia zakazanych dokumentów. Odmowa powinna być spokojna i jednoznaczna.
Dodaj użytkownika z prawem do części pola oraz rolę techniczną. Porównaj wyniki, logi i cache. Nie wystarczy sprawdzić administratora. Bezpieczeństwo wymaga zwykłych ról i przypadków brzegowych, a nie tylko pełnego dostępu.
Kiedy nie wdrażać RAG
Jeżeli nie potrafisz przypisać właścicieli i uprawnień, zacznij od mniejszej bazy publicznej lub wyszukiwania bez modelu. Nie migruj poufnych dokumentów dla samego efektu asystenta. Brak RAG jest lepszy niż niekontrolowany RAG.
Przy małej liczbie dokumentów może wystarczyć zwykłe wyszukiwanie z filtrami. Model nie jest obowiązkowym elementem każdej bazy wiedzy. Oceń koszt, ryzyko i rzeczywistą wartość przed dodaniem kolejnych kopii.
Minimalny rejestr źródeł RAG
Zapisz dokument, właściciela, kategorię, dozwolone role, wersję, retencję i powiązane pochodne. Nie przechowuj pełnej treści w rejestrze. Identyfikator wystarcza do mapowania i usuwania.
Przy każdym nowym źródle wymagaj zatwierdzenia przed indeksowaniem. Nie przenoś domyślnych uprawnień z poprzedniej kolekcji. Rejestr powinien pokazywać, które odpowiedzi i systemy używają dokumentu, aby ograniczyć skutek zmiany lub usunięcia.
Odbiór odpowiedzi przez właściciela źródła
Przy ważnych odpowiedziach pokaż właścicielowi nie tylko tekst, ale także dokument i rolę użytkownika. Może odpowiedź jest poprawna dla jednej roli i nie dozwolona dla innej. To pomaga zrozumieć, czy problem dotyczy faktu czy dostępu.
Nie wysyłaj pełnych poufnych wyników do przypadkowego zespołu. Odbiór powinien odbywać się w kontrolowanym kanale z minimalnymi kopiami. Zapisz wersję i datę, a przy błędzie ogranicz nowe odpowiedzi przed korektą.
Kiedy proces jest gotowy na większy zakres
Najpierw sprawdź na reprezentatywnych przypadkach poprawne odpowiedzi, odmowę, usuwanie i logi. Wynik próby nie potwierdza absolutnego braku wycieków. Dopiero potem dodaj kolejną kolekcję. Każda nowa grupa źródeł wymaga własnych ról i przypadków testowych.
Jeżeli proces wymaga stałej obsługi administratora, oceń, czy warto go rozwijać. Może prostsza konfiguracja z mniejszą liczbą dokumentów jest bezpieczniejsza i tańsza. Skala nie jest dowodem dojrzałości RAG.
Przy większym procesie Aeneia Audit pomaga zmapować dane i role. Aeneia Design pomaga opisać zachowanie użytkownika i odmowę.
Dobry RAG nie odpowiada za dużo. Pobiera tylko dozwolone źródła, ogranicza kopie i potrafi je usunąć. Bezpieczeństwo zaczyna się przed pierwszym wyszukiwaniem.
Przy każdej nowej wersji indeksu powtórz test odmowy i usuwania. Nie ograniczaj się do jakości odpowiedzi. Nowa konfiguracja może zmieniać cache, role i kopie bez zmiany modelu. Zapisz datę, wersję i właściciela wyniku. Jeżeli odpowiedź jest lepsza, ale pokazuje niedozwolone źródło, proces nie przechodzi odbioru. Jakość nie rekompensuje braku uprawnień.
Przy kolejnych zmianach dostawcy sprawdzaj także domyślne ustawienia eksportu i logów. Funkcja dodana dla wygody może tworzyć nową kopię. Odbiór powinien kończyć się na zachowaniu systemu, a nie na nazwie modelu.
Przy odbiorze końcowym sprawdź jedno pytanie zwykłego użytkownika i jedno administratora. Porównaj nie tylko treść, ale także linki do źródeł i historię. Jeżeli administrator widzi więcej, zapisz powód i zakres. Różnica powinna wynikać z roli, a nie z przypadkowej konfiguracji indeksu danych poufnych.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
