Governance danych do AI: klasyfikacja, dostęp, retencja i lineage

Widzimy to regularnie: zespół buduje firmowego asystenta, indeksuje „wszystko, co się da”, a potem okazuje się, że w bazie wektorowej wylądowały umowy z klauzulami poufności, dane kadrowe i historia korespondencji z klientami — dostępne dla każdego pracownika, który zada odpowiednie pytanie. Model działa poprawnie. Problemem jest brak ładu nad tym, co w ogóle wolno mu pokazać. Governance danych to praca, którą trzeba wykonać zanim pierwszy dokument trafi do indeksu, a nie audyt, który robi się po incydencie.

Każdy dokument, który rozważasz jako źródło dla AI, musi mieć przypisaną klasę wrażliwości. To fundament — od niego zależą wszystkie pozostałe decyzje o dostępie, retencji i hostingu. Bez klasyfikacji nie da się sensownie odpowiedzieć na pytanie „czy ten plik może trafić do chmurowego modelu”.

Pracujemy zwykle na czterech poziomach. Im wyżej, tym ostrzejsze reguły przetwarzania i tym większe prawdopodobieństwo, że dane muszą zostać lokalnie.

Klasyfikacja nie musi być idealna od pierwszego dnia. Wystarczy, że jest jednoznaczna i przypisana automatycznie tam, gdzie się da — po lokalizacji w systemie źródłowym, etykiecie w SharePoincie albo regule na poziomie folderu. Dokument bez klasy traktujemy domyślnie jak poufny, nigdy jak publiczny. To bezpieczniejszy fallback.

Najczęstszy błąd we wdrożeniach RAG to indeks „płaski” — jeden zbiór wektorów, do którego każdy ma identyczny dostęp. Asystent dziedziczy wtedy najszerszy możliwy zasięg: wystarczy zręcznie sformułowane pytanie, żeby wyciągnąć fragment dokumentu, którego pytający nigdy nie powinien zobaczyć.

Poprawny wzorzec to przeniesienie uprawnień z systemu źródłowego do warstwy wyszukiwania. Każdy fragment niesie metadane o tym, kto może go zobaczyć (dział, rola, poziom dostępu), a zapytanie filtruje wyniki po tożsamości użytkownika przed podaniem ich modelowi. Model nigdy nie dostaje kontekstu, do którego pytający nie ma prawa — więc nie może go ujawnić nawet pod presją sprytnego promptu.

W praktyce oznacza to trzy rzeczy: oddzielne kolekcje lub filtry metadanych dla różnych klas wrażliwości, mapowanie ról firmowych na uprawnienia w indeksie, oraz zasadę „odmów, jeśli nie wiesz”. Jeśli system nie potrafi ustalić uprawnień użytkownika, nie pokazuje wrażliwego fragmentu. Więcej o tym, jak takie ograniczenia wpinamy w samą warstwę modelu, opisujemy w tekście o bezpieczeństwie agentów AI.

Retencja to pytanie, na które większość firm nie ma gotowej odpowiedzi w kontekście AI. Dane wejściowe (dokumenty w indeksie) i dane operacyjne (logi rozmów, zapytania, wygenerowane odpowiedzi) podlegają osobnym politykom — i osobnym ryzykom.

Dane wejściowe powinny żyć tak długo, jak długo są aktualne i potrzebne. Nieaktualna procedura sprzed trzech lat w indeksie to nie tylko gorsza jakość odpowiedzi, ale i ryzyko prawne, jeśli zawiera dane osobowe, których podstawa przetwarzania już wygasła. Logi rozmów to osobny temat: domyślnie stosujemy zerową lub minimalną retencję treści zapytań, bo użytkownicy wklejają do asystenta dane, których nikt nie przewidział.

Dobra polityka retencji odpowiada na cztery pytania dla każdego typu danych:

• Po co to trzymamy? Cel przetwarzania musi być konkretny — „bo może się przyda” nie jest celem zgodnym z minimalizacją.
• Jak długo? Konkretny okres z datą wygaśnięcia, nie „bezterminowo”.
• Co się dzieje po terminie? Automatyczne usunięcie z indeksu i z bazy wektorowej, nie tylko z systemu źródłowego.
• Jak realizujemy prawo do usunięcia? Selektywne kasowanie fragmentów konkretnej osoby — wektory też trzeba usunąć, nie tylko plik źródłowy.

To ostatnie jest zaskakująco częstym niedopatrzeniem. Usunięcie pliku z SharePointa nie usuwa jego embeddingów z bazy wektorowej. Jeśli pipeline nie obsługuje selektywnego kasowania, żądanie usunięcia danych z RODO zostaje technicznie niezrealizowane.

Lineage (pochodzenie danych) to zdolność do prześledzenia, z jakiego dokumentu, w jakiej wersji i z jakiego źródła pochodzi każdy fragment w indeksie — a docelowo każde zdanie w odpowiedzi asystenta. Bez tego nie da się odpowiedzieć na dwa krytyczne pytania: „dlaczego model to powiedział?” i „czy ta informacja jest jeszcze aktualna?”.

W praktyce każdy fragment w bazie wektorowej powinien nieść metadane pochodzenia: identyfikator dokumentu źródłowego, wersję, datę, system origin i klasę wrażliwości. Gdy asystent cytuje fragment, potrafi wskazać konkretne źródło — to fundament zaufania użytkownika i warunek audytowalności. Lineage to także podstawa zgodności z zasadą rozliczalności w RODO: musisz umieć wykazać, jakie dane osobowe są przetwarzane przez system i skąd pochodzą.

Solidny lineage opłaca się też operacyjnie: gdy dokument źródłowy się zmienia, dokładnie wiesz, które fragmenty przeindeksować, zamiast przeliczać cały korpus. Fundament czystych danych wejściowych, na których lineage w ogóle działa, opisujemy w tekście jak przygotować dane firmowe pod AI.

Minimalizacja to zasada, która ratuje najwięcej projektów: do AI trafia tylko to, co jest niezbędne do celu. Asystent odpowiadający na pytania o procedury wewnętrzne nie potrzebuje pełnej bazy CRM z historią klientów. Im mniej danych osobowych w pipeline, tym mniejsze ryzyko i tym prostsza zgodność.

Praktycznie minimalizacja PII działa na dwóch poziomach. Po pierwsze — selekcja na wejściu: nie indeksujemy danych, które nie są potrzebne do zadania asystenta. Po drugie — maskowanie w locie: zanim fragment trafi do zewnętrznego modelu generatywnego, automatycznie wykrywamy i zastępujemy imiona, numery telefonów, PESEL i adresy e-mail. Przy danych objętych tajemnicą zawodową cały pipeline może działać lokalnie, co eliminuje problem wysyłki danych na zewnątrz — opisujemy to w tekście o self-hostowanym LLM a RODO.

DPIA, czyli ocena skutków dla ochrony danych, jest wymagana, gdy przetwarzanie może powodować wysokie ryzyko dla osób — a wdrożenia AI na danych kadrowych, zdrowotnych czy finansowych zwykle do tej kategorii należą. DPIA nie jest formalnością: to ćwiczenie, które wymusza odpowiedzi na pytania o cel, podstawę prawną, data residency i środki bezpieczeństwa, zanim system ruszy. Robiona dobrze, często ujawnia luki, które taniej naprawić na etapie projektu niż po wdrożeniu. Pełen kontekst obowiązków w tekście AI Act i RODO 2026.

Praktyczna checklista, którą przechodzimy przed każdym indeksowaniem. Jeśli nie potrafisz odhaczyć pozycji, dane nie wchodzą do indeksu, dopóki luka nie zostanie zamknięta.

• Klasyfikacja — każde źródło ma przypisaną klasę wrażliwości; brak klasy = traktowane jak poufne.
• Podstawa prawna — istnieje i jest udokumentowana dla każdego celu przetwarzania.
• Dostęp po roli — uprawnienia z systemu źródłowego odwzorowane w filtrach indeksu; zasada „odmów, jeśli nie wiesz”.
• Minimalizacja — indeksowane są tylko dane niezbędne do zadania asystenta.
• Maskowanie PII — automatyczne przed wysyłką do zewnętrznego modelu; zweryfikowane na próbce.
• Retencja — okres przechowywania i automatyczne usuwanie zdefiniowane dla danych wejściowych i logów.
• Prawo do usunięcia — pipeline obsługuje selektywne kasowanie fragmentów, łącznie z wektorami.
• Lineage — każdy fragment niesie metadane pochodzenia; odpowiedzi można odnieść do źródła.
• DPIA — wykonana dla obszarów wysokiego ryzyka przed wdrożeniem.
• Hosting — klasa wrażliwości decyduje o tym, czy dane mogą opuścić infrastrukturę.

To nie jest lista do odhaczenia raz. Wracamy do niej przy każdej zmianie zakresu danych, bo nowe źródło to nowe ryzyko. Governance, które żyje, jest tańsze niż incydent, który nie żyje.

Klasyczna polityka bezpieczeństwa skupia się na ochronie danych w spoczynku i w tranzycie — szyfrowanie, dostępy, kopie zapasowe. Governance danych do AI dokłada warstwę specyficzną dla modeli: kontrolę nad tym, co model może „zobaczyć” przez RAG, maskowanie PII przed wysyłką do modelu oraz lineage odpowiedzi. To rozszerzenie istniejącej polityki, nie zastąpienie jej.

Nie do każdego. DPIA jest wymagana, gdy przetwarzanie może powodować wysokie ryzyko dla praw osób — typowo przy danych kadrowych, zdrowotnych, finansowych lub profilowaniu na dużą skalę. Asystent na publicznym FAQ jej nie wymaga. W razie wątpliwości lepiej wykonać uproszczoną ocenę i udokumentować decyzję, bo to samo w sobie jest dowodem rozliczalności wymaganym przez RODO.

Kluczowe jest to, że usunięcie pliku źródłowego nie usuwa jego embeddingów z bazy wektorowej. Pipeline musi obsługiwać selektywne kasowanie fragmentów powiązanych z konkretną osobą lub dokumentem — i to właśnie lineage pozwala je odnaleźć. Bez metadanych pochodzenia żądanie usunięcia jest technicznie niewykonalne, a to bezpośrednie naruszenie obowiązków z RODO.

To zależy od klasy danych i podstawy prawnej, ale maskowanie samo w sobie zwykle nie wystarcza dla danych szczególnej kategorii. Maskowanie redukuje ryzyko dla danych wewnętrznych, jednak przy danych kadrowych, prawnych czy zdrowotnych rekomendujemy pełny self-hosting i data residency w infrastrukturze firmy. Wtedy żadna treść nie opuszcza Waszego środowiska — szczegóły w tekście o self-hostowanym LLM a RODO.

Zacznij od jednego obszaru, który chcesz wpuścić do AI, i sklasyfikuj tylko jego — nie całą firmę naraz. Przejdź folder po folderze, przypisz każdemu źródłu jedną z czterech klas i zastosuj zasadę, że dokument bez klasy jest domyślnie poufny. Pilot na jednym czystym, dobrze sklasyfikowanym obszarze jest bezpieczniejszy i szybszy niż próba uporządkowania wszystkiego — to samo podejście etapowe, które polecamy przy przygotowaniu danych firmowych pod AI.