Anonimizacja danych w AI: jak tokenizować PII zanim trafią do LLM

Polityka bezpieczeństwa w polskim banku ma zwykle cztery strony zakazu wklejania danych klientów do ChatGPT. Praktyka analityka, który ma do końca dnia podsumować dziesięć stron wywiadu z reklamacją, bywa dokładnie odwrotna. Powstaje schemat, w którym formalnie nikt nie wysyła danych osobowych do modelu językowego, a faktycznie wysyłają wszyscy. Anonimizacja danych w AI to dziś już nie pytanie etyczne ani filozoficzne. Jest po prostu jedyną technicznie szczerą odpowiedzią na to, jak ludzie naprawdę używają ChatGPT i Claude w pracy biurowej. Instrukcja systemowa wpisana w prompt – “nie zapamiętuj tych danych” – nie jest kontrolą bezpieczeństwa, lecz co najwyżej deklaracją intencji. Realna ochrona zaczyna się dopiero w momencie, w którym dane wrażliwe nigdy nie wychodzą poza serwer klienta w swojej oryginalnej postaci. Stoi za tym warsztat, który decyduje dziś między audytem RODO bez uwag a kosztownym incydentem, którego nikt nie planował.

Co właściwie wkleja pracownik do prompta

Spójrzmy najpierw na to, co dziś naprawdę przechodzi przez okno czatu. Z kolejnych ankiet branżowych wynika spójnie jedno. Pracownicy biurowi coraz częściej korzystają z modeli językowych na własną rękę. Co więcej, znacząca część z nich przyznaje przy tym, że wkleja do nich treści służbowe. Te zaś w wielu branżach zawierają PII oraz szczególne kategorie danych z RODO. PII to dane osobowe pozwalające zidentyfikować konkretną osobę – imię i nazwisko, PESEL, adres, numer rachunku, IP, numer telefonu, e-mail. Szczególne kategorie z RODO obejmują natomiast dane o zdrowiu, religii, orientacji seksualnej, przynależności związkowej albo dane biometryczne. W kontekście branż zdrowotnych pojawia się też skrót PHI, który w sensie amerykańskiego HIPAA dotyczy identyfikowalnych informacji zdrowotnych. Z perspektywy RODO wszystkie te katalogi mają wspólny mianownik – opuszczają kontrolę administratora w momencie, w którym pracownik wysyła prompt do dostawcy z siedzibą w USA.

Co więcej, częściowa anonimizacja przed wklejeniem nie wystarcza. Dane można odtworzyć z kontekstu z niespodziewanie wysoką dokładnością. Na przykład wystarczy klient z rzadkim nazwiskiem, ulica w małej miejscowości albo unikalna data urodzenia w połączeniu z rocznikiem produktu. Pseudonimizacja, w której zamieniamy “Anna Kowalska” na “Klient X”, to natomiast dla małej kawiarni z Suwałk jednoznaczna identyfikacja po samym numerze NIP. RODO traktuje takie pseudonimizowane dane nadal jako dane osobowe, co oznacza, że ich transfer do LLM wymaga tej samej ostrożności co transfer wersji jawnej.

Czemu “nie zapamiętuj” w prompcie to nie ochrona

Najczęstszy mit, na który natykamy się w polskich zespołach, brzmi tak – “wpiszemy modelowi, żeby nie pamiętał, i po sprawie”. Trzeba sobie to powiedzieć wprost. Instrukcja systemowa w prompcie nie jest mechanizmem technicznym. Model jest deterministyczną maszyną do generowania tekstu, której rozumienie “pamięci” nie ma nic wspólnego z pamięcią w sensie infrastruktury dostawcy. Z perspektywy compliance liczy się tylko jedno – czy dane fizycznie znalazły się na serwerze dostawcy, ile czasu tam żyją i kto ma do nich dostęp.

W tym miejscu rynek jest dziś bardziej dojrzały, niż wielu zespołów zakłada. OpenAI udostępnia w ofercie Enterprise tryb non-training z deklaracją usuwania danych po określonym czasie. Anthropic ma osobny tryb Zero Data Retention dla klientów biznesowych. Google na poziomie Vertex AI deklaruje konfiguracje w regionie Unii Europejskiej. To są jednak deklaracje umowne, nie techniczne gwarancje. W rezultacie poziom faktycznej kontroli zależy od konkretnych zapisów umowy. Liczy się, czy zespół używa wersji konsumenckiej, czy też wariantu Enterprise z DPA i klauzulami transferu. Z kolei polski analityk z poprzedniego akapitu działa zwykle na wersji konsumenckiej z darmowego e-maila. Tam żadnych takich gwarancji nie ma.

Trzy poziomy anonimizacji danych w AI

Praktyka pokazuje, że anonimizacja danych w AI ma dziś trzy realnie używane poziomy techniczne. Każdy z nich rozwiązuje inną klasę problemów i niesie własne kompromisy.

Pierwszy poziom: regex i lista zakazanych wzorców

Najprostsza tarcza opiera się na wyrażeniach regularnych. Aplikacja przepuszcza tekst przez listę wzorców. PESEL ma na przykład jedenaście cyfr o określonej strukturze, NIP dziesięć, telefon zaczyna się od +48, a numer rachunku ma kod kraju i 26 cyfr. Tak złapane fragmenty zastępujemy etykietą typu [PESEL] albo [NUMER_TELEFONU]. W rezultacie ten poziom działa szybko, nie wymaga modelu i da się go uruchomić w przeglądarce. Płaci się jednak za prostotę. Imienia i nazwiska nie złapie. Adresu nie złapie. Powiązań z kontekstem (“ten Pan Marek, o którym mówiliśmy wczoraj”) nie złapie. Z tego powodu regex sprawdza się w mocno ustrukturyzowanych przypadkach (księgowość, dane operacyjne), ale w tekście swobodnym daje fałszywe poczucie ochrony.

Drugi poziom: model NER, czyli wykrywanie nazwanych encji

Lepiej wypada tu osobny model rozpoznający tak zwane wyodrębnione encje, czyli z angielska Named Entity Recognition. Sieć neuronowa – typowo mniejszy model językowy działający lokalnie – czyta tekst i oznacza w nim imiona, nazwiska, organizacje, lokalizacje, daty, kwoty. Popularnym otwartoźródłowym narzędziem tej klasy jest Microsoft Presidio, które można rozszerzyć o modele i reguły dla języka polskiego. Pracuje lokalnie albo na własnym serwerze, więc dane PII nigdy nie wychodzą poza środowisko klienta. Z naszej praktyki wynika, że poziom NER łapie w dobrze ustrukturyzowanym tekście biurowym około dziewięćdziesięciu procent przypadków, ale nadal ma problem ze skrótami, literówkami w nazwiskach i niestandardowymi notacjami. Z tego powodu w branżach silnie regulowanych traktuje się go jako warstwę pomocniczą, nie ostateczną.

Trzeci poziom: tokenizacja słownikowa z rehydracją

Najwięcej daje dziś tokenizacja słownikowa, czyli zastąpienie wykrytych encji nieprzewidywalnymi tokenami i przechowywanie mapowania w lokalnym słowniku po stronie klienta. Wówczas “Anna Kowalska, PESEL 86010178956” zamienia się w “PERSON_a37f2, ID_c1d04” przed wysłaniem promptu, a LLM widzi tylko te tokeny. W odpowiedzi modelu te same tokeny występują w sensownych miejscach. Na przykład “Klient PERSON_a37f2 zgłasza problem z saldem”. Aplikacja po stronie klienta tłumaczy je natomiast z powrotem na oryginalne wartości tylko w chwili wyświetlenia odpowiedzi w CRM albo w mailu wychodzącym. Co więcej, z perspektywy dostawcy LLM żaden fragment danych osobowych w ogóle nie istnieje. Z perspektywy pracownika końcowy tekst wygląda dokładnie tak, jakby model miał dostęp do oryginałów. To dzisiejszy złoty standard, który stosujemy w zespołach pracujących z CRM, ticketami i dokumentami prawnymi. Coraz częściej dostarczają go gotowe komponenty w narzędziach automatyzacyjnych typu n8n czy Make, a także biblioteki integrujące się z LangChain.

RODO i AI Act – kto za co odpowiada

Z perspektywy prawnej anonimizacja danych w AI rozgrywa się dziś na dwóch poziomach. RODO traktuje administratora danych osobowych jako podmiot odpowiedzialny za to, by transfer do procesora (dostawcy LLM) miał umocowanie w umowie powierzenia, klauzulach transferu (SCC) i ocenie ryzyka. W tej logice tokenizacja po stronie klienta znacząco ogranicza ryzyko transferu danych jawnych. Trzeba przy tym pamiętać, że pseudonimizowane tokeny same w sobie nadal mogą być uznane za dane osobowe, jeśli istnieje mapa pozwalająca je odtworzyć. Z tego powodu lokalne zabezpieczenie samego słownika mapowań staje się tak samo ważne jak ich tworzenie.

AI Act dorzuca do tego drugą warstwę. Z jednej strony social scoring obywateli przez administrację publiczną wpada wprost do katalogu praktyk zakazanych. Z drugiej strony zastosowania AI w rekrutacji, ocenie zdolności kredytowej osób fizycznych albo wybranych zastosowaniach medycznych mogą być klasyfikowane jako wysokie ryzyko. W tej drugiej grupie regulator wymaga dokumentacji, audytu i w wielu przypadkach human-in-the-loop. Tokenizacja sama w sobie nie zwalnia z tych obowiązków, jednak znacząco upraszcza je w jednym punkcie – mianowicie w rozdziale o ochronie danych. Co więcej, pisaliśmy szerzej o mapie regulacji w analizie europejskiego AI Act dla agentów, gdzie wątek tokenizacji wypływa równolegle do dyskusji o przejrzystości decyzji modelu.

Co zrobić w polskim zespole w przyszłym tygodniu

Z perspektywy operacyjnej rzeczy do zrobienia układają się w prostą sekwencję. Najpierw policz, ile w ostatnim miesiącu twoich pracowników wkleiło do ChatGPT albo Claude jakąkolwiek treść służbową. Dlatego warto zacząć od ankiety wewnętrznej, a nie od polityki bezpieczeństwa. Jeśli nie wiesz, masz pierwszy problem. Dalej zinwentaryzuj, jakie przypadki użycia mają sensowny ROI – notatki z reklamacji, podsumowania spotkań, draft maili do klienta, analiza ticketów. Każdy z tych przypadków potrzebuje innego progu anonimizacji. Z kolei dla najwrażliwszych obszarów (finanse, zdrowie, dane prawne) postaw na tokenizację słownikową z rehydracją po stronie klienta, najlepiej z wykorzystaniem otwartych komponentów typu Microsoft Presidio i własnego słownika.

Na koniec sprawdź, czy umowa z dostawcą LLM faktycznie pokrywa to, czego potrzebujesz. W efekcie zyskujesz drugą warstwę obrony. W wersjach Enterprise większości amerykańskich dostawców da się dziś dopisać klauzule non-training, retencji “zero” oraz regionalny tryb przetwarzania. To nie zastępuje tokenizacji, ale stanowi sensowną drugą warstwę obrony. Podobny dwustopniowy model bezpieczeństwa pokazywaliśmy wcześniej przy weryfikacji tożsamości w Claude przez biometryczne dane Persona, gdzie problem dotyczy danych biometrycznych, a mechanika RODO jest analogiczna. Ten sam wzorzec – “tokenizuj po swojej stronie, ufaj umowie po stronie dostawcy” – powtarza się też w sektorze zdrowotnym, o czym pisaliśmy w temacie medycznych LLM bez publicznego API.

Pierwsza Misja AI · Kodożercy

Rozumiesz zagrożenia AI, gdy rozumiesz jak naprawdę działa

Kurs Pierwsza Misja AI ma dedykowaną lekcję o ciemnej stronie AI: halucynacje, deepfakes, manipulacja. Zanim zaczniesz się bać, zacznij rozumieć.

Poznaj pełny program →

Podsumowanie

Przez ostatnie dwa lata polskie firmy dzieliły się na te, które oficjalnie zakazywały ChatGPT, i te, które otwarcie z niego korzystały. W praktyce obie grupy robiły to samo – wlewały dane klientów do modelu bez kontroli technicznej. W 2026 roku ta podwójność przestaje być akceptowalna. Anonimizacja danych w AI nie jest dziś wyborem między wygodą a bezpieczeństwem, lecz warunkiem koniecznym, by w ogóle można było mówić o produkcyjnym użyciu LLM w środowisku regulowanym. Trzy poziomy techniki – regex, Named Entity Recognition i tokenizacja słownikowa z rehydracją – dają konkretne narzędzia dla różnych klas problemów, a ich kombinacja jest dziś najczęściej spotykanym wzorcem produkcyjnym. Pytanie, które każdy CTO powinien sobie zadać przed końcem kwartału, nie brzmi już “czy wprowadzimy AI”, lecz “którą warstwę tokenizacji włączymy najpierw”. Ono samo decyduje o tym, czy najbliższy audyt RODO będzie rutyną, czy alarmem.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.