Anonimizacja i maskowanie PII przed wysłaniem do AI

Firma podpina system AI do skrzynki e-mail. Asystent ma odpowiadać na pytania klientów, klasyfikować zgłoszenia i sugerować odpowiedzi. Pierwsze testy wypadają świetnie. Kilka tygodni później ktoś pyta: skąd właściwie wiedziałeś, że w tych e-mailach są numery PESEL? Czy to wszystko trafia do chmury?

To jest moment, w którym większość wdrożeń AI staje przed pierwszym poważnym pytaniem o bezpieczeństwo danych. Nie jest to pytanie akademickie. RODO nakłada obowiązek minimalizacji danych: do modelu powinno trafić tyle informacji, ile niezbędne do realizacji zadania. Imię klienta, numer zamówienia, numer PESEL, adres IP, adres e-mail — żadna z tych wartości nie jest potrzebna, żeby model sklasyfikował intencję zapytania czy zaproponował odpowiedź. Wszystkie są PII i powinny być zastąpione tokenami jeszcze przed wysłaniem.

PII (Personally Identifiable Information) to każda informacja pozwalająca zidentyfikować lub wyróżnić konkretną osobę, bezpośrednio lub pośrednio. W polskim prawie zakres reguluje RODO, które obejmuje:

• imię i nazwisko,
• numer PESEL, NIP, numer dowodu,
• adres e-mail i numer telefonu,
• adres zamieszkania,
• adres IP i identyfikatory sesji,
• dane biometryczne i medyczne (szczególna kategoria, art. 9 RODO),
• kombinacje danych, które razem identyfikują osobę, choć żadna z osobna tego nie robi.

Modele językowe nie „zapamiętują" danych w sensie bazy danych. Ale przetwarzają je po stronie dostawcy: tekst wchodzi do środowiska obliczeniowego dostawcy, jest tokenizowany, przetwarza go model i zwracana jest odpowiedź. Zależnie od umowy i konfiguracji, dane mogą być używane do doskonalenia modelu lub logowane przez określony czas. To wystarczy, żeby prawnicy i audytorzy zadali pytanie o podstawę prawną takiego przekazania.

Maskowanie PII przed wysłaniem rozwiązuje ten problem u źródła: model widzi [IMIĘ_1], [EMAIL_1], [PESEL_1] zamiast prawdziwych wartości. Zadanie klasyfikacji czy sugestii odpowiedzi jest wykonane. Dane osobowe nie opuściły infrastruktury.

Nie wszystkie podejścia są równoważne. Warto rozróżnić trzy pojęcia, bo konsekwencje prawne i techniczne są różne.

W typowym przepływie RAG stosuje się maskowanie: PII jest zastępowane tokenem, odpowiedź modelu jest zwracana z tokenami, a warstwa lokalna odtwarza oryginalny kontekst tam, gdzie jest to potrzebne do akcji (np. wstawienia imienia do odpowiedzi e-mail). Mapa token–wartość nigdy nie opuszcza Waszego serwera.

Pełna anonimizacja jest trudna i rzadko potrzebna w przepływach operacyjnych. Przydaje się do logowania, raportowania i trenowania modeli: zbiór danych bez możliwości re-identyfikacji nie podlega RODO i może być używany dowolnie.

Standardowa implementacja składa się z czterech komponentów działających lokalnie, przed jakimkolwiek ruchem sieciowym do zewnętrznego LLM.

1. Detektor PII. Biblioteka lub model (np. spaCy NER, Microsoft Presidio, własne reguły regex) przeskanuje tekst i znajdzie wszystkie fragmenty, które wyglądają jak PII. Dla polskiego tekstu oznacza to rozpoznawanie PESEL (11-cyfrowy wzorzec z sumą kontrolną), NIP (10-cyfrowy), numerów telefonów (9-cyfrowe sekwencje z prefiksami), adresów e-mail (regex RFC 5322) i nazw własnych (NER).

2. Tokenizer. Każde znalezione PII jest zastępowane tokenem z zachowaniem typu i numeru porządkowego w dokumencie: Jan Kowalski → [OSOBA_1], [email protected] → [EMAIL_1], 48123456789 → [TELEFON_1]. Jeśli ten sam e-mail pojawia się trzykrotnie, wszystkie trzy wystąpienia dostają ten sam token.

3. Mapa odwrócenia. Token-mapa ({„[OSOBA_1]": „Jan Kowalski"}) jest przechowywana lokalnie (w pamięci sesji lub zaszyfrowanej bazie), nigdy nie jest wysyłana do modelu.

4. De-tokenizer. Po powrocie odpowiedzi z modelu, warstwa lokalna opcjonalnie podstawia z powrotem wartości oryginalne tam, gdzie potrzeba działania (np. adresowanie odpowiedzi). Jeśli odpowiedź trafia do logu audytowego, zostaje z tokenami.

W naszej architekturze ta warstwa działa jako middleware w LLM routerze. Każde wywołanie modelu przechodzi przez nią automatycznie, bez zmian po stronie aplikacji.

Nie każde słowo wymaga maskowania. Priorytetyzacja według ryzyka:

Reguła praktyczna: jeśli dane trafiają do inference w modelu chmurowym, maskuj przynajmniej trzy pierwsze kategorie bezwarunkowo. Kategorie zdrowotne i biometryczne to szczególna kategoria RODO (art. 9) — wymagają osobnej analizy DPIA i w wielu przypadkach przetwarzania wyłącznie lokalnego.

Maskowanie PII redukuje ryzyko, ale nie eliminuje wszystkich wektorów. Dla danych szczególnie wrażliwych (akta pracownicze, dane medyczne, kontrakty z klauzulami poufności, dane dzieci) właściwą odpowiedzią jest self-hosting: model językowy i model embeddingów działają na Waszym sprzęcie, żadne zapytania nie wychodzą poza sieć wewnętrzną.

W naszym stacku lokalny BGE-M3 obsługuje warstwę embeddingów dla RAG bez żadnego ruchu wychodzącego. Modele generatywne mogą działać przez Ollama na lokalnym GPU lub przez LLM router z polityką fallback: tryby wrażliwe → lokalny model, tryby standardowe → chmura z maskowanym PII.

To rozwiązanie ma jeden koszt: modele lokalne są mniej zaawansowane niż duże modele chmurowe. Różnica jest akceptowalna dla klasyfikacji, ekstrakcji i wyszukiwania semantycznego. Jest bardziej zauważalna dla złożonego rozumowania. Odpowiedź na pytanie „czy self-hosting wystarczy?" zależy od zakresu zadań — omawia to szerzej artykuł o firmowym GPT na bazie wiedzy.

Wdrożenie AI przetwarzającego dane osobowe wymaga kilku kroków po stronie prawno-formalnej, niezależnie od jakości maskowania technicznego.

Ocena skutków dla ochrony danych (DPIA). Jeśli przetwarzanie jest systematyczne, na dużą skalę lub dotyczy szczególnych kategorii danych (zdrowie, pochodzenie, dane biometryczne), DPIA jest obowiązkowa na mocy art. 35 RODO. Automatyczne przetwarzanie korespondencji klientów zawierającej dane osobowe zwykle kwalifikuje się do DPIA.

Rejestr czynności przetwarzania. Nowe przepływy AI muszą znaleźć się w rejestrze: cel, podstawa prawna, kategorie danych, odbiorcy, czas retencji, środki zabezpieczające.

AI Act (obowiązuje od 2025/2026). Systemy klasyfikujące osoby, oceniające wiarygodność czy podejmujące decyzje wpływające na prawa jednostki są traktowane jako systemy wysokiego ryzyka. Wymagają human-oversight, dokumentacji technicznej i rejestracji w unijnej bazie danych. Systemy pomocnicze (sugestie dla konsultanta, które człowiek zatwierdza) mają niższy próg wymagań. Szczegółowe wymagania omawia artykuł AI Act i RODO 2026.

Umowa powierzenia przetwarzania (DPA). Jeśli korzystasz z modelu chmurowego, nawet z maskowaniem PII, formalnie powierzasz przetwarzanie dostawcy. DPA z dostawcą jest wymagana przez RODO art. 28.

Maskowanie PII to konieczny fundament, nie kompletna odpowiedź na bezpieczeństwo. Trzy obszary, które wymagają osobnych rozwiązań:

Inference attacks. Nawet zanonimizowane dane mogą pozwalać na re-identyfikację, gdy kontekst jest wystarczająco unikalny. Dokument opisujący „[OSOBA_1], dyrektor spółki w małym mieście na Śląsku, zatrudniającej 12 osób" może być identyfikowalny bez imienia. Mitygacja: uogólnianie kontekstu w logach, ograniczanie granularności.

Prompt injection. Złośliwe instrukcje ukryte w danych wejściowych mogą próbować wyciągnąć token-mapę lub ominąć maskowanie. Rozwiązanie to guardrails działające przed i po modelu, opisane w artykule bezpieczeństwo agentów AI.

Model memorization. Jeśli Twoje dane trafiają do trenowania modelu dostawcy, istnieje ryzyko, że model „zapamiętał" fragmenty Twoich dokumentów. Przy mocno wrażliwych danych jedyną pewną ochroną jest wyłączenie opcji trenowania (opt-out w API dostawcy) lub self-hosting. Sprawdź politykę dostawcy przed wdrożeniem.

Wklej fragment tekstu z potencjalnymi danymi osobowymi, a model pokaże, jak warstwa maskowania PII identyfikuje i tokenizuje dane przed wysłaniem do modelu (playground: PII maskowane lokalnie, zero retencji):

RODO nie nakazuje dosłownie maskowania, ale art. 5 ust. 1 lit. c (minimalizacja danych) i art. 25 (privacy by design) razem wymagają, żeby do przetwarzania trafiało tylko to, co niezbędne. Wysyłanie pełnych danych osobowych do modelu chmurowego, gdy zadanie wymaga tylko klasyfikacji intencji, narusza minimalizację. Maskowanie PII jest najprostszą techniką spełnienia tego wymogu. Dla danych szczególnych kategorii (zdrowie, biometria) wymagane jest też DPIA.

Najpopularniejsze opcje to Microsoft Presidio (open source, rozszerzalny o polskie wzorce NER i regex), spaCy z modelem pl_core_news_lg (dobre rozpoznawanie nazw własnych i NER) oraz własne reguły wyrażeń regularnych dla deterministycznych identyfikatorów (PESEL, NIP, numer konta IBAN). W praktyce stosuje się kombinację: regex dla identyfikatorów o znanych wzorcach + NER dla imion i nazw miejsc. Żadna z tych bibliotek nie jest perfekcyjna, dlatego po maskowaniu warto weryfikować losowe próbki.

Dokumenty PDF i obrazy są trudniejsze, bo PII może być wbudowane w skan, logo, stopkę lub odręczny podpis. Warstwa OCR (OCR) powinna najpierw wyekstrahować tekst, a dopiero potem detektor PII przetworzy go przed wysłaniem do modelu. Dla dokumentów o bardzo wysokiej wrażliwości (umowy, akta medyczne) bezpieczniejszy jest self-hosted model vision działający bez dostępu do sieci zewnętrznej.

Przy dobrze zaprojektowanym maskowaniu wpływ jest minimalny. Klasyfikacja intencji, ekstrakcja struktury, wyszukiwanie semantyczne i generowanie odpowiedzi działają na tokenach równie dobrze jak na prawdziwych danych, ponieważ model przetwarza strukturę i kontekst, nie wartości liczbowe. Problem pojawia się, gdy logika biznesowa wymaga wartości (np. obliczenie lat na podstawie PESEL) — tu maskowanie należy zastosować po obliczeniu, nie przed.

Najszybsza ścieżka to middleware w warstwie routera LLM: każde wywołanie modelu przechodzi przez pre-processor PII i post-processor de-tokenizujący odpowiedź. Aplikacja nie musi wiedzieć o maskowaniu. Wdrożenie takiej warstwy zajmuje zwykle od kilku dni do kilku tygodni, zależnie od złożoności przepływów. Kalkulator zakresu i kosztów znajdziesz w kalkulatorze ROI. Jeśli dopiero badasz możliwości, zacznij od oceny gotowości.