OpenAI Privacy Filter: maskowanie PII to nie RODO

OpenAI udostępniło niewielki, otwarty model do lokalnego wykrywania i maskowania danych osobowych. Privacy Filter może pomóc oczyścić logi, dokumenty i prompty przed wysłaniem ich do zewnętrznej usługi. Nie jest jednak automatem, który jednym przebiegiem anonimizuje dane i zapewnia zgodność z RODO.

Producent wprost opisuje ograniczenia poza angielskim, przy nietypowych identyfikatorach i danych innych niż treningowe. Dla polskiej firmy oznacza to konieczność własnych testów na PESEL, NIP, REGON, adresach i odmienianych nazwiskach.

Co zostało opublikowane

Według oficjalnej prezentacji Privacy Filter model ma 1,5 mld parametrów, z czego około 50 mln jest aktywnych podczas inferencji, oraz kontekst do 128 tys. tokenów. Jest dostępny na licencji Apache 2.0 i może działać lokalnie.

Model rozpoznaje osiem szerokich kategorii, m.in. dane kontaktowe, identyfikatory finansowe i konta, numery dokumentów oraz sekrety takie jak klucze API. Kod jest dostępny w repozytorium GitHub, a model card na Hugging Face opisuje sposób użycia, wyniki i granice.

OpenAI raportuje F1 96 procent na zbiorze PII-Masking-300k oraz 97,43 procent po korekcie błędów anotacji. F1 łączy precision i recall na konkretnym zbiorze. Nie oznacza, że model znajdzie 96 procent każdego typu PII w realnym polskim dokumencie.

Maskowanie, pseudonimizacja i anonimizacja

Te terminy nie są zamienne.

Maskowanie zastępuje wykryty fragment znacznikiem albo zmodyfikowaną wartością. Jeśli model przeoczy PESEL lub nazwisko, dane pozostają w tekście.

Pseudonimizacja oddziela identyfikator od osoby, ale ponowne powiązanie jest możliwe przy użyciu dodatkowej informacji. Dane nadal są danymi osobowymi w rozumieniu RODO.

Anonimizacja wymaga, by identyfikacja osoby nie była rozsądnie możliwa, również przez połączenie kontekstu z innymi danymi. Usunięcie imienia nie wystarczy, jeśli dokument opisuje stanowisko, datę, małą miejscowość i wyjątkowe zdarzenie.

Privacy Filter pomaga w pierwszym kroku. Nie ocenia automatycznie ryzyka reidentyfikacji całego zbioru i nie wystawia certyfikatu zgodności.

Gdzie lokalny filtr ma największy sens

oczyszczanie logów i zgłoszeń przed analizą przez zewnętrzny LLM;
redakcja dokumentów do środowiska testowego;
wykrywanie kluczy API i danych kontaktowych w dużych zbiorach tekstu;
wsparcie procesu DSAR lub e-discovery, gdzie człowiek weryfikuje wynik;
dodatkowa warstwa DLP w pipeline RAG.

Lokalne uruchomienie ogranicza konieczność wysłania nieoczyszczonego materiału do innego dostawcy. Sam serwer modelu nadal musi być zabezpieczony: pliki tymczasowe, logi, cache, telemetria i dostęp administratorów mogą zawierać oryginalne dane.

Jak zbudować test dla polskich danych

Przygotuj legalny zbiór testowy. Użyj danych syntetycznych lub odpowiednio chronionych próbek obejmujących PESEL, NIP, REGON, IBAN, numery dokumentów, telefony i adresy.
Uwzględnij fleksję. Nazwisko może występować w kilku przypadkach, z polskimi znakami lub bez nich. Testuj też skróty i literówki.
Dodaj kontekst pośredni. Stanowisko, mała lokalizacja i data zdarzenia mogą identyfikować osobę bez jednego oczywistego numeru.
Mierz recall per kategoria. Przy ochronie danych koszt przeoczenia bywa wyższy niż koszt nadmiarowego zamaskowania. Ogólny F1 może ukryć słaby wynik dla PESEL.
Sprawdź false positives. Nadmierna redakcja może usunąć informacje potrzebne do analizy incydentu albo obsługi klienta.
Dodaj reguły deterministyczne. Sumy kontrolne PESEL, NIP i REGON oraz wzorce IBAN uzupełniają model. Żadna pojedyncza metoda nie wystarczy.
Zostaw human review dla wysokiego ryzyka. Dokument prawny, medyczny lub kadrowy wymaga weryfikacji przed udostępnieniem.
Testuj po każdej aktualizacji. Zmiana modelu, tokenizera, promptu lub formatu dokumentu może zmienić wyniki.

Bezpieczna architektura pipeline

Najpierw minimalizuj dane u źródła. Następnie uruchom lokalnie reguły i Privacy Filter, zweryfikuj wynik, a dopiero potem wyślij oczyszczoną treść do modelu docelowego. Zachowaj mapę zastąpień tylko wtedy, gdy jest potrzebna, zaszyfruj ją i oddziel uprawnieniami.

Nie loguj pełnych promptów „dla debugowania” bez limitu retencji. Monitoruj także dane wyjściowe, bo model docelowy może odtworzyć informacje z dołączonej bazy wiedzy. Zasady te rozwijają praktyki opisane w RODO dla IT i bezpieczeństwie AI w firmie.

Podsumowanie

Privacy Filter jest użytecznym, lokalnym komponentem: ma otwartą licencję, długi kontekst i potrafi wykrywać wiele klas PII oraz sekretów. Jego zaletą jest możliwość oczyszczenia danych przed opuszczeniem organizacji.

Nie jest gwarancją kompletności, anonimizacji ani zgodności z RODO. Bezpieczne wdrożenie łączy model z regułami deterministycznymi, polskim zestawem testowym, kontrolą człowieka, minimalizacją danych i ochroną całego pipeline. Najważniejsza metryka nie brzmi „jaki F1 podał producent”, lecz „jakie dane nasz proces nadal przepuszcza”.

Źródła i dalsza lektura: OpenAI — Introducing Privacy Filter, GitHub — openai/privacy-filter, Hugging Face — model card.