Medalion vs OpenAI - detekcja danych osobowych

W kwietniu 2026 OpenAI opublikowało OpenAI Privacy Filter: otwarty model do wykrywania i maskowania danych osobowych w tekście. To ciekawy moment dla rynku narzędzi privacy, bo OpenAI nie pokazało kolejnego dużego modelu ogólnego, tylko wyspecjalizowany komponent infrastrukturalny: model, który można uruchomić lokalnie, dostroić i wpiąć w pipeline'y przetwarzania danych.

Postanowiliśmy więc porównać go z AnonimiNER 2.2, autorskim modelem i frameworkiem do detekcji oraz anonimizacji danych osobowych w języku polskim.

Nie chodziło nam o benchmark „pod wynik". Chcieliśmy odpowiedzieć na praktyczne pytanie: jeśli mamy polskie teksty, polskie formaty danych i realne przypadki typu PESEL, odmiana nazwisk, adresy z ul., m., kodami pocztowymi i literówkami, to jak zachowa się specjalistyczny polski system w porównaniu z nowym modelem OpenAI?

Czym jest OpenAI Privacy Filter?

To model klasyfikacji tokenów (bidirectional token-classification) do wykrywania PII - danych osobowych w tekście. Działa lokalnie i w jednym przebiegu etykietuje każdy token, a potem sklejane są z tego spójne fragmenty za pomocą Viterbiego i tagowania BIOES. Model ma 1.5B parametrów łącznie, z 50M aktywnych parametrów, wspiera kontekst do 128 tys. tokenów i jest dostępny na licencji Apache 2.0.

To bardzo sensowna architektura dla zadań redakcji danych: zamiast generować tekst token po tokenie, model przypisuje etykiety tokenom wejściowym. W teorii daje to większą kontrolę, lepszą przepustowość i łatwiejsze wdrożenie lokalne.

OpenAI Privacy Filter wykrywa osiem kategorii:

• private_person
• private_address
• private_email
• private_phone
• private_url
• private_date
• account_number
• secret

To od razu pokazuje, gdzie tkwi haczyk: ta lista jest szeroka, ale widać, że była tworzona głównie pod rynek amerykański i język angielski. Zupełnie nie przystaje do naszych polskich realiów, bo nie znajdziemy tam chociażby kategorii „PESEL". Moglibyśmy oczywiście pójść na łatwiznę i udawać, że PESEL to po prostu „numer konta" (account_number), ale zdecydowaliśmy, że nie będziemy tego robić. Nie chcemy sztucznie podbijać wyników w raportach i mieszać znaczenia tych etykiet tylko po to, żeby tabelki ładniej wyglądały.

Jak testowaliśmy?

Porównanie przeprowadziliśmy na benchmarku składającym się z 200 polskich tekstów. Skupiliśmy się na pięciu kluczowych kategoriach, które najczęściej sprawiają problemy przy anonimizacji:

• osoba
• pesel
• numer telefonu
• email
• adres

W przypadku AnonimiNERa 2.2 nie testowaliśmy samego "gołego" modelu, ale cały proces dokładnie tak, jak działa on u naszych klientów. Wykorzystaliśmy pełną ścieżkę produkcyjną: od zapytania do API, przez model i wyrażenia regularne (regexy), aż po walidatory, normalizację danych i mechanizmy rozstrzygające konflikty między nakładającymi się fragmentami tekstu. To dla nas kluczowe rozróżnienie – AnonimiNER to nie jest po prostu kolejny model typu NER. To kompletny, wielowarstwowy system detekcji danych osobowych, zaprojektowany od zera pod specyfikę polskiego języka.

Dla OpenAI Privacy Filter uruchomiliśmy oficjalny pakiet opf, lokalnie, z dekodowaniem viterbi. Mapowanie etykiet wyglądało tak:

• private_person -> osoba
• private_email -> email
• private_phone -> numer telefonu
• private_address -> adres
• account_number nie było mapowane na pesel

Metryki liczyliśmy przez nervaluate: strict, exact, partial i ent_type.

Wyniki: pełny benchmark

Na pełnym benchmarku różnica jest bardzo duża. Trzeba jednak uczciwie powiedzieć, że PESEL jest dla OpenAI Privacy Filter problemem taksonomicznym: model nie ma dedykowanej klasy PESEL. Dlatego spojrzeliśmy też na wyniki bez PESEL.

Wyniki bez PESEL

Takie zestawienie jest znacznie bardziej uczciwe, bo odrzucamy kategorię, której rozwiązanie OpenAI po prostu natywnie nie obsługuje. I choć ich ogólny wynik dzięki temu naturalnie podskoczył, AnonimiNER 2.2 wciąż utrzymuje wyraźną przewagę.

Najciekawszy jest jednak powód tej różnicy. Nawet jeśli zapomnimy o PESEL-u, przewaga nie wynika z jednego typu danych. OpenAI radzi sobie całkiem sprawnie z numerami telefonów czy adresami e-mail, ale wyraźnie gubi się przy typowo polskich imionach, nazwiskach i adresach. A to przecież tam kryje się największe ryzyko wycieku danych w naszych realiach.

Wyniki per typ encji

To dobrze pokazuje charakter obu systemów.

OpenAI Privacy Filter jest mocny tam, gdzie dane mają bardziej uniwersalny format: email, telefon. Słabnie tam, gdzie potrzebna jest znajomość lokalnego języka, fleksji, formatów administracyjnych i konwencji zapisu.

AnonimiNER 2.2 wygrywa szczególnie na:

• polskich nazwach osobowych,
• PESEL,
• adresach,
• danych zapisanych niestandardowo,
• przypadkach z literówkami i skrótami.

Analiza błędów OpenAI Privacy Filter

Błędy, które OpenAI Privacy Filter zaliczył w naszym teście, nie były przypadkowe - układały się w dość wyraźny i powtarzalny wzór.

Głównym wyzwaniem okazał się PESEL. Ponieważ nie chcieliśmy „naciągać" rzeczywistości i mapować numerów kont na PESEL-e, rozwiązanie od OpenAI zaliczyło w tej kategorii twarde zero. W praktyce system albo całkowicie ignorował te numery, albo mylił je z numerami telefonów. Trudno tu winić sam model – to po prostu efekt innej polityki etykietowania danych. Jednak dla kogoś, kto działa w Polsce, to bariera nie do przejścia: PESEL jest u nas przecież jedną z najważniejszych i najpilniej strzeżonych kategorii danych.

Drugi problem to polskie adresy. OpenAI Privacy Filter często łapał tylko fragment adresu, np. sam kod pocztowy z miastem albo samą ulicę bez miasta. Zdarzały się też przesunięte granice spanów: model wykrywał adres, ale kończył go za wcześnie albo za późno. Przykłady problematycznych struktur to ul., al., lok., m., adresy bez przecinków, adresy z literówkami oraz adresy wieloczłonowe.

Trzeci problem to nazwy osobowe w języku polskim. OpenAI Privacy Filter gubił osoby w przypadkach zależnych od fleksji, np. formy typu „Ewy Kamińskiej", „Pawła Urbaniaka", „Wiesławę Pietrzak". Miał też problem z tytułami i prefiksami: czasem włączał do encji dr, mecenas, Szanowny Panie, a czasem przez kontekst klasyfikował osobę jako adres.

Czwarty problem to false positives na zwykłych słowach. W wynikach pojawiały się dodatkowe encje typu serwis, Nasz, infolinię, Lekarz, Przesyłka, Zadzwoń. To pokazuje, że model próbuje działać kontekstowo, ale w krótkich polskich zdaniach potrafi nadinterpretować rzeczowniki i elementy formułek jako dane osobowe.

Piąty problem to niestandardowe formaty emaili i telefonów. OpenAI Privacy Filter często dobrze wykrywa klasyczne emaile, ale przy formach typu jan.kowalski AT poczta DOT onet DOT pl, anna_kowalska(at)gmail.com albo literówkach w domenie zaczynał mylić granice lub etykiety. AnonimiNER też nie jest tu bezbłędny, ale połączenie modelu, regexów i reguł daje mu stabilniejszy wynik.

Co z tego wynika praktycznie?

OpenAI Privacy Filter to naprawdę ciekawy model. Ma otwarte wagi, sensowną licencję, dobrą architekturę do token classification, długi kontekst i możliwość fine-tuningu. W zastosowaniach anglojęzycznych, szczególnie dla ogólnych workflowów redakcji PII, może być bardzo atrakcyjnym komponentem.

Nasz test pokazuje jednak coś, o czym często się zapomina: wyłapywanie danych osobowych to robota wybitnie lokalna. Lokalna pod kątem języka, przepisów i konkretnych formatów, z jakich korzystamy na co dzień.

W Polsce dane wrażliwe to znacznie więcej niż tylko mail czy telefon. To nasz specyficzny PESEL, to nazwiska odmieniane przez przypadki, to adresy z lokalnymi skrótami i kodami pocztowymi, a do tego masa literówek i specyficzny, półformalny styl dokumentów. Model ogólny może i wyłapie część tych schematów, ale bez znajomości naszych lokalnych niuansów i twardych reguł traci skuteczność dokładnie tam, gdzie ryzyko biznesowe jest największe.

Dlatego AnonimiNER 2.2 wypada w tym porównaniu bardzo mocno. Nie dlatego, że większy model zawsze przegrywa ze specjalistycznym. Raczej dlatego, że w anonimizacji produkcyjnej liczy się cały system:

• model dopasowany do języka,
• regexy dla krytycznych identyfikatorów,
• walidacja numerów,
• normalizacja spanów,
• deduplikacja,
• rozwiązywanie overlapów,
• lokalna taksonomia danych.

To właśnie daje przewagę w realnych polskich tekstach.

Podsumowanie

OpenAI Privacy Filter to mocny i ważny sygnał: rynek idzie w stronę wyspecjalizowanych, lokalnie uruchamialnych modeli privacy. To dobry kierunek.

Jednocześnie nasze wyniki pokazują, że dla polskich danych osobowych AnonimiNER 2.2 pozostaje rozwiązaniem znacznie skuteczniejszym i bardziej praktycznym. Na pełnym benchmarku osiągnął 93.54% strict F1 wobec 57.34% dla OpenAI Privacy Filter. Nawet po usunięciu PESEL, czyli najbardziej niekompatybilnej kategorii, AnonimiNER 2.2 osiągnął 92.31% strict F1, a OpenAI Privacy Filter 62.79%.

OpenAI Privacy Filter to solidne i uniwersalne narzędzie do ochrony prywatności. Z kolei AnonimiNER 2.2 to system od początku budowany z myślą o specyfice polskich danych osobowych. Nasz test udowadnia, że ta konkretna specjalizacja robi w praktyce kolosalną różnicę.

---

Chcesz sprawdzić AnonimiNER 2.2 w akcji? Odwiedź anoniminer.medalion.app lub skontaktuj się z nami.