Dane firmowe dla AI: jak przygotować bezpieczny, oparty na źródłach RAG

1. Zbuduj inwentaryzację źródeł przed indeksem

Lista folderów nie jest inwentaryzacją. Dla każdego źródła zapisz właściciela biznesowego, system źródłowy, odbiorców, klasę informacji, sposób aktualizacji, okres obowiązywania i kryterium wycofania. Odróżnij dokument zatwierdzony od szkicu, aktualną procedurę od archiwum i wzór od zawartej umowy. RAG, który nie zna tych różnic, może znaleźć fragment trafny językowo, ale błędny operacyjnie.

Nie zaczynaj od wszystkich dokumentów firmy. Wybierz jeden zbiór powiązany z konkretną decyzją, na przykład aktualne instrukcje operacyjne dla jednego zespołu. Usuń duplikaty, jawnie oznacz wersje i ustal, co ma się stać po zmianie źródła: ponowne przetworzenie, unieważnienie poprzednich fragmentów i aktualizacja indeksu w określonym czasie.

Sprawdź jakość ekstrakcji. Skan, tabela, przypis, nagłówek, kolumna lub załącznik mogą utracić kontekst podczas dzielenia dokumentu. Zachowaj identyfikator dokumentu, wersję, sekcję, datę i poziom dostępu przy każdym fragmencie. Bez tych metadanych późniejsze cytowanie i analiza błędu będą niepełne.

• Właściciel i osoba zatwierdzająca treść.
• System źródłowy, wersja, data obowiązywania i data przeglądu.
• Klasa danych, dozwoleni odbiorcy i ograniczenia użycia.
• Reguła aktualizacji, unieważnienia i usuwania z indeksu.
• Sposób odtworzenia fragmentu w pełnym dokumencie.

2. Egzekwuj dostęp przed wyszukiwaniem, nie po odpowiedzi

Najbezpieczniejszą odpowiedzią na niedozwolone źródło jest sytuacja, w której fragment nigdy nie trafia do kontekstu modelu. Filtruj wyszukiwanie według tożsamości, roli, zespołu i klasy dokumentu przed pobraniem treści. Filtrowanie gotowej odpowiedzi jest za późne: model mógł już wykorzystać informację w streszczeniu, porównaniu albo samym doborze słów.

Uprawnienia w indeksie powinny odzwierciedlać realne źródło i zmieniać się wraz z nim. Zaplanuj odebranie dostępu, zmianę roli, wycofanie dokumentu i usunięcie konta. Bufory, cache, kopie indeksu i środowiska testowe także podlegają kontroli; inaczej stara treść może pozostać dostępna mimo poprawnej zmiany w systemie głównym.

Nie używaj wspólnego technicznego konta jako substytutu autoryzacji użytkowników. Jeżeli proces wymaga dostępu serwisowego, jego zakres powinien być minimalny, jawny i audytowalny. System musi rozróżnić „nie znaleziono” od „brak uprawnień” w logice wewnętrznej, nie ujawniając przy tym istnienia dokumentu osobie nieuprawnionej.

3. Pokaż pochodzenie odpowiedzi i granice dowodu

Każda odpowiedź o znaczeniu operacyjnym powinna wskazywać dokument, wersję i konkretny fragment, na którym się opiera. Użytkownik potrzebuje drogi do pełnego źródła, nie tylko nazwy pliku. Interfejs powinien odróżnić treść przytoczoną, wniosek modelu i brak wystarczającego materiału.

Cytat nie jest automatycznym dowodem poprawności. Może być wyrwany z kontekstu, pochodzić ze starej wersji albo wspierać tylko część zdania. Testuj zgodność każdej istotnej tezy z podanym fragmentem oraz to, czy wybrano właściwe źródło spośród podobnych dokumentów. W sprawach o większych skutkach człowiek powinien otworzyć materiał i zatwierdzić działanie.

Zdefiniuj odpowiedź na brak dowodu. System powinien powiedzieć, że nie znalazł wystarczającego źródła, zadać pytanie doprecyzowujące lub przekazać sprawę. Nie wolno uzupełniać luki ogólną wiedzą modelu, jeżeli użytkownik oczekuje odpowiedzi wyłącznie na podstawie dokumentów firmy.

• Identyfikator i czytelny tytuł dokumentu.
• Wersja, data obowiązywania i sekcja lub numer strony.
• Dokładny fragment użyty do odpowiedzi.
• Łącze do źródła respektujące te same uprawnienia.
• Jawny komunikat, gdy materiał nie wspiera odpowiedzi.

4. Testuj wyszukiwanie oddzielnie od generowania

Gdy odpowiedź jest błędna, najpierw ustal warstwę błędu. Zapytanie mogło zostać źle zinterpretowane, właściwy fragment nie znalazł się w wynikach, ranking mógł promować dokument podobny, lecz nieaktualny, albo model mógł zniekształcić poprawny kontekst. Jedna zbiorcza ocena odpowiedzi nie pokazuje, co należy naprawić.

Zbuduj zestaw pytań z oczekiwanymi źródłami, odpowiedziami i przypadkami „brak odpowiedzi”. Uwzględnij synonimy, skróty firmowe, literówki, pytania wieloczęściowe, wyjątki, podobne dokumenty i zmianę wersji. Oceniaj, czy właściwy fragment pojawia się w pierwszych wynikach, czy niedozwolony fragment nigdy się nie pojawia i czy system prawidłowo powstrzymuje się od odpowiedzi.

Zestaw ocen powinien pochodzić od osób znających proces i być wersjonowany razem ze źródłami. Po zmianie modelu embeddingowego, sposobu dzielenia dokumentów, rankera, promptu lub uprawnień uruchom ocenę ponownie. Wynik globalny nie powinien ukrywać słabej jakości dla rzadkiej, lecz ważnej kategorii.

• Retrieval: czy znaleziono właściwe źródło i właściwą wersję.
• Grounding: czy wszystkie istotne tezy wynikają z dostarczonych fragmentów.
• Abstention: czy system odmawia, gdy materiał jest niewystarczający.
• Authorization: czy niedozwolone źródła pozostają poza wynikami i kontekstem.
• Operacyjność: czy użytkownik potrafi przejść od odpowiedzi do decyzji i źródła.

5. Zaprojektuj retencję, logi i odtwarzalność

RAG tworzy więcej danych niż sam indeks. Zapytania mogą zawierać informacje osobowe lub tajemnice firmy, odpowiedzi mogą łączyć fragmenty, a logi mogą przechowywać identyfikatory użytkownika, pobrane źródła, oceny i ślady błędów. Dla każdej kategorii ustal cel, dostęp, okres przechowywania i sposób usunięcia. „Potrzebujemy do debugowania” nie jest wystarczającym opisem bez zakresu i końca retencji.

Aby odtworzyć incydent, zapisz wersję konfiguracji, modelu, indeksu i źródeł oraz identyfikatory pobranych fragmentów. Jednocześnie nie kopiuj całych dokumentów do logu, jeśli wystarczają identyfikatory i zabezpieczony dostęp do źródła. Log operacyjny, ślad audytowy i materiał do oceny jakości mogą mieć inne zasady i odbiorców.

Zaplanuj usunięcie na wszystkich warstwach: źródle, kolejce przetwarzania, indeksie, cache, kopii zapasowej w ramach obowiązujących zasad, logach i zbiorach ewaluacyjnych. Sprawdź, ile czasu zajmuje propagacja oraz jak system zachowuje się w tym oknie. Brak technicznej ścieżki usunięcia powinien zatrzymać włączenie źródła, które takiej obsługi wymaga.

6. Umieść człowieka przy decyzji, nie obok interfejsu

Samo wyświetlenie przycisku „zatwierdź” nie zapewnia skutecznego nadzoru. Osoba zatwierdzająca musi rozumieć zakres systemu, widzieć źródła, mieć czas na ocenę i realną możliwość odrzucenia rekomendacji. Jeżeli tempo pracy lub cele zespołu wymuszają mechaniczne akceptowanie, kontrola jest pozorna.

Podziel przypadki według skutków błędu. Odpowiedź informacyjna może wymagać jedynie widocznego źródła i łatwego zgłoszenia problemu. Przygotowanie pisma, zmiana danych, zobowiązanie wobec klienta albo decyzja wpływająca na osobę powinny mieć silniejszą weryfikację i uprawnienia. Nie automatyzuj kolejnego działania tylko dlatego, że model wygenerował uporządkowany tekst.

Ustal kolejkę wyjątków i czas reakcji. Zbieraj poprawki w sposób, który pozwala rozróżnić błąd źródła, wyszukiwania, generowania, uprawnienia i interfejsu. Informacja zwrotna nie powinna automatycznie zmieniać produkcyjnej bazy ani promptu; potrzebuje przeglądu, wersjonowania i ponownej oceny.

7. Przygotuj pytania dla IOD lub doradcy prawnego

Ten przewodnik nie jest poradą prawną i nie potwierdza zgodności systemu z RODO. UODO wskazuje, że AI może przetwarzać i analizować dane osobowe, a EDPB opisuje ocenę skutków dla ochrony danych jako narzędzie identyfikacji i zarządzania ryzykiem dla osób. Administrator musi ocenić konkretny cel, dane, role, podstawy i skutki; dla operacji mogących powodować wysokie ryzyko ocena skutków może być wymagana przed rozpoczęciem przetwarzania.

Nie przedstawiaj architektury RAG jako sposobu na automatyczne osiągnięcie zgodności. Ograniczenie źródeł, kontrola dostępu, retencja i logi są technicznymi środkami, które mogą wspierać wymagania, ale ich adekwatność zależy od procesu. IOD lub doradca potrzebuje rzeczywistej mapy przepływu danych i proponowanych zabezpieczeń, nie samej nazwy technologii.

Rozmowę przeprowadź przed pełnym indeksowaniem. Późna konsultacja może wykazać, że źródła trzeba rozdzielić, zmienić role dostawców, ograniczyć logi albo przeprojektować interfejs. Te decyzje wpływają na koszt i harmonogram, dlatego powinny wejść do bramki dopuszczającej pilotaż.

• Jaki jest konkretny cel i zakres danych dla każdego źródła, zapytania, odpowiedzi oraz logu?
• Kto jest administratorem, podmiotem przetwarzającym i dalszym odbiorcą w całym łańcuchu?
• Czy źródła zawierają dane osobowe, szczególne kategorie danych, informacje o pracownikach lub klientach?
• Jak realizowane są obowiązki informacyjne, prawa osób, ograniczenie celu, minimalizacja i usunięcie?
• Czy charakter, zakres, kontekst i cele mogą powodować wysokie ryzyko wymagające DPIA, konsultacji lub dodatkowych zabezpieczeń?
• Czy planowane użycie może prowadzić do zautomatyzowanej decyzji lub znaczącego wpływu na osobę?
• Jakie wymagania sektorowe, umowne i tajemnice przedsiębiorstwa ograniczają użycie danych?

8. Dopuść system do produkcji na podstawie dowodów

Przed produkcją wymagaj zatwierdzonego katalogu źródeł, testów uprawnień, wyników zestawu ewaluacyjnego, prób usuwania, scenariuszy awarii i właściciela operacyjnego. Sprawdź zachowanie dla braku wyników, pustego dokumentu, niedostępnego źródła, zmiany uprawnień i błędu dostawcy. Brak realnej integracji powinien zatrzymać system, a nie uruchamiać zastępczą treść.

W ograniczonym pilotażu monitoruj nie tylko średnią jakość, lecz także krytyczne klasy błędów. Ustal próg zatrzymania dla ujawnienia informacji, użycia nieaktualnego dokumentu w istotnej decyzji, braku odtwarzalności i trwałej utraty źródła. Każdy incydent powinien prowadzić do poprawki właściwej warstwy oraz ponownej oceny.

NIST AI RMF proponuje ciągłe działania govern, map, measure i manage. W praktyce oznacza to, że uruchomienie nie kończy pracy: zmieniają się dokumenty, dostawcy, modele, użytkownicy i rodzaje pytań. Plan utrzymania powinien zawierać przegląd źródeł, testy regresji, przegląd dostępów, analizę zgłoszeń oraz możliwość kontrolowanego wycofania systemu.