Niniejszy dokument jest automatycznym tłumaczeniem oryginału w języku angielskim. W przypadku jakichkolwiek rozbieżności między tym tłumaczeniem a oryginalną wersją angielską, wersja angielska jest rozstrzygająca. Przeczytaj oryginał w języku angielskim
Pseudonimizator działający na urządzeniu: zbudowany i przetestowany
2026-05-22 · Caiioo Team
Chcieliśmy rozwiązać problem prywatności w systemach AI, które trenują na rzeczywistych danych osobowych i je przechowują. Polityki i umowy „Zero Data Retention” (zerowej retencji danych) zmniejszają ryzyko, ale są pełne wyjątków. Zasadniczo mówią: „Nie będziemy przechowywać żadnych Twoich promptów ani wyników, z wyjątkiem: (tu następuje długa lista wyjątków: cele bezpieczeństwa, nadzór rządowy, blokady procesowe, rozwój produktu, logi błędów, ulepszanie usług...)”.
Aby to rozwiązać, zbudowaliśmy filtr danych osobowych, który działa na własnym komputerze użytkownika, widzi wiadomość zanim opuści ona urządzenie i zwraca tę samą odpowiedź, którą użytkownik otrzymałby, gdyby napisał ją bez żadnego filtra.
Zbudowaliśmy go więc. Następna wersja Caiioo będzie zawierać Pseudonimizator. Dostępny poprzez ikonę tarczy w czacie agenta oraz w ustawieniach.
Niniejszy dokument (white paper) przedstawia uzasadnienie, architekturę, proces oceny i zasady projektowania naszego systemu filtrowania prywatności.
Co zamierzamy osiągnąć
Ogólna ochrona prywatności poprzez minimalizację danych. Gdy użytkownik czatuje ze zdalnym modelem, model ten nie potrzebuje prawdziwego imienia i nazwiska, adresu zamieszkania, prawdziwego adresu e-mail ani numeru telefonu klienta, aby odpowiedzieć na pytanie użytkownika. Potrzebuje on kształtu pytania i musi ono wyglądać jak prawdziwe zapytanie, aby LLM nie odrzucił go jako testu. Filtr usuwa zatem prawdziwe identyfikatory z danych przesyłanych do AI i przywraca realne wartości w drodze powrotnej. Model widzi syntetyczne nazwiska i identyfikatory; użytkownik widzi prawdziwą rozmowę.
Wsparcie w zakresie zgodności z HIPAA. Drugi tryb koncentruje się na 18 identyfikatorach zawartych w zasadzie HIPAA Safe Harbor (§164.514) oraz luźniejszym wariancie Limited Data Set. Klinicysta, administrator opieki zdrowotnej lub ktokolwiek pracujący nad objętym przepisami procesem może rozmawiać z modelem ogólnego przeznaczenia o rzeczywistych przypadkach bez wysyłania chronionych informacji zdrowotnych (PHI) do AI. Nie jesteśmy oficerem ds. zgodności podmiotu objętego przepisami — ale możemy być warstwą, która zapobiega opuszczeniu laptopa przez PHI w pierwszej kolejności. Nasze oceny dostarczają mierzalnych punktów odniesienia, których organizacje mogą użyć do oceny przydatności filtra dla ich standardów zgodności i prywatności. Wszystkie środki prywatności i bezpieczeństwa są decyzjami opartymi na osądzie, za które odpowiedzialność ponosi użytkownik lub podmiot użytkujący.
Wybraliśmy oba rozwiązania, ponieważ inżynieria jest taka sama, a przypadek użycia PHI jest w rzeczywistości technicznie łatwiejszy ze względu na wykorzystanie wyraźnych nazwanych jednostek, które są łatwiejsze do zredagowania niż bardziej ogólne dane w kategorii Danych Osobowych. Filtrowanie HIPAA ułatwia również fakt, że odbywa się ono zazwyczaj w języku angielskim lub hiszpańskim. Wykrywamy identyfikatory, zastępujemy je stabilnymi pseudonimami i podstawionymi identyfikatorami w tym samym formacie, przywracamy je w drodze powrotnej i nigdy nie logujemy prawdziwych wartości. Mapa między informacjami syntetycznymi a prawdziwymi pozostaje wyłącznie na urządzeniu użytkownika, dzięki czemu użytkownik może czytać prawdziwe informacje w odpowiedziach agenta. Lista kategorii i bramka polityki to elementy, które zmieniają się między trybami.
Dlaczego regex plus uczenie maszynowe, a nie tylko jedno z nich
W naszym pseudonimizatorze istnieją dwie główne technologie filtrowania: deterministyczny język rozpoznawania wzorców zwany regex oraz wytrenowane modele uczenia maszynowego.
Regex jest bezkonkurencyjny w przypadku formatów powierzchniowych. Adres e-mail ma określoną strukturę ([email protected]). Podobnie jest z adresem IP, kartą kredytową, numerem IBAN, VIN, SSN (XXX-XX-XXXX) czy kluczem API. Jeśli format jest wiarygodny, regex wychwytuje go deterministycznie za każdym razem, bez obciążania modelu i kosztów inferencji.
Regex jest jednak bezradny wobec kontekstu. Fraza „Karta Sarah z zeszłego wtorku” zawiera osobę i datę, ale żadnego z tych elementów nie da się odróżnić na podstawie samego formatu. „Pacjent pod numerem 14 na Elm” zawiera adres, który pokrywa się z tysiącem innych ciągów znaków niebędących adresami. „Ich MRN to 7741032” wymaga słów otaczających liczbę, aby nabrała ona znaczenia.
Mały, precyzyjnie dostrojony model językowy radzi sobie z kontekstem — nasz to specjalnie wytrenowany koder o 110 milionach parametrów, wydestylowany z wielojęzycznego, niewielkiego modelu językowego. Odczytuje on całe zdanie, a nie tylko podciąg znaków, i jest wystarczająco mały, aby działać niezwykle szybko na urządzeniu, nawet na telefonie komórkowym.
Benchmarki ilustrują uzupełniające się mocne strony obu warstw. Przetestowaliśmy obie warstwy w izolacji, aby upewnić się, że każda z nich rzeczywiście wnosi realną wartość. W zestawie 150 pytań PrivacyBench-PD, gdzie pytania i odpowiedzi jawnie NIE były używane do trenowania modelu, wyniki prezentują się następująco:
| Warstwa | Wykryte PII | Współczynnik wykryć |
|---|---|---|
| Tylko Regex | 205 / 670 | 30.6 % |
| Tylko ML | 516 / 670 | 77.0 % |
| Obie (produkcja) | 625 / 670 | 93.3 % |
Sam regex pomija trzy czwarte identyfikatorów, ponieważ większość identyfikatorów w rzeczywistym tekście nie jest ustrukturyzowana. Samo ML traci 16 punktów procentowych, które wychwyciłaby warstwa regex — rzeczy, które są definiowane wyłącznie przez swój kształt (karta kredytowa wygląda jak karta kredytowa; model nie ma tu żadnego dodatkowego sygnału do dodania). Razem pokrywają to, czego żadne z nich nie obejmuje samodzielnie.
Przyglądając się głębiej temu, gdzie każda warstwa jest decydująca: w tym samym zestawie danych, 16 wartości testowych zostało wykrytych tylko przez regex (e-maile, adresy IP, konta finansowe, ustrukturyzowane identyfikatory), a 327 zostało wykrytych tylko przez ML (imiona i nazwiska, identyfikatory kontekstowe, sformułowania wielojęzyczne).
Mały, inteligentny, szybki — i działa wszędzie
Musieliśmy sprawić, by filtr działał na urządzeniu, co było wyzwaniem inżynieryjnym.
Musi być mały, ponieważ nasza aplikacja działa lokalnie na wielu systemach: wewnątrz rozszerzenia Chrome, aplikacji macOS, iOS, Android oraz na Windows i Linux. Pakiet zajmuje około 113 MB na model. Istnieją dwa modele — jeden dla ogólnych danych osobowych, drugi dla chronionych informacji medycznych — a tryb Safe Harbor uruchamia oba równolegle. Wśród nich najmniej wydajne jest urządzenie z Androidem z niskiej półki, a mimo to nasz system działa sprawnie.
Musi być inteligentny, ponieważ błędy typu „false negative” powodują wyciek danych do zdalnego LLM, a „false positive” niszczą rozmowę. Imiona muszą być maskowane; zaimki nie. Adres e-mail lekarza w przekazanym wątku powinien zostać zamaskowany; stopka [email protected] prawdopodobnie nie.
Musi być szybki, ponieważ znajduje się bezpośrednio na drodze każdej wiadomości wysyłanej lub odbieranej przez użytkownika. Zmierzyliśmy narzut czasowy na poziomie poniżej 200 ms na jednym wątku procesora, co w większości zajmuje tokenizacja. Na WebGPU i Apple Neural Engine jest on znikomy w porównaniu z opóźnieniem sieciowym samego wywołania LLM.
Musi działać w wielu środowiskach, ponieważ Caiioo jest wieloplatformowe. Ten sam system działa w rozszerzeniach Chrome, na macOS i iOS, Androidzie oraz na Windows i Linux. Jeden model detekcji, jedna biblioteka regex, jeden moduł łączący, jedna polityka — identyczne zachowanie na każdej powierzchni, na której działa Caiioo.
Wyniki
Po wielu rundach testów i trenowania, zatwierdziliśmy 16. wersję naszych modeli. Poniżej przedstawiamy trzy benchmarki, z których każdy mierzy inny aspekt wydajności.
Nasz własny zestaw testowy, 150 pytań, których model nigdy nie widział
Przed testami na publicznych benchmarkach, przepuściliśmy nasz filtr Personal Data przez wewnętrzny zestaw testowy, który celowo trzymaliśmy poza danymi treningowymi — dzięki temu detektor nigdy wcześniej nie widział żadnego z tych pytań. 150 pytań podzielono na cztery grupy (fragmenty kodu, proza dokumentowa, celowo nietypowe sformułowania oraz 10 języków obcych), plus grupę „negatywną”, która nie zawiera żadnych prywatnych danych (test poprawności, aby upewnić się, że nie redagujemy nadmiarowo). Połączony potok regex + ML:
| Sub-bench | Wykryte | Skuteczność |
|---|---|---|
| code_bench | 69 / 74 | 93.2 % |
| doc_bench | 233 / 247 | 94.3 % |
| generalization_bench | 123 / 133 | 92.5 % |
| multilingual_bench | 200 / 216 | 92.6 % |
| Wszystkie 4 pozytywne | 625 / 670 | 93.3 % |
(Grupa negatywna nie zawierała danych prywatnych do wykrycia. Filtr zamaskował jedną rzecz, której nie powinien — co jest spójne z danymi dotyczącymi precyzji przedstawionymi poniżej).
System oceniający jest surowy: każdy oczekiwany element danych prywatnych musi całkowicie zniknąć z zamaskowanego wyjścia, aby pytanie zostało zaliczone. Nie ma punktów częściowych ani uznawania wyników „wystarczająco bliskich”. To podejście bardziej rygorystyczne niż w benchmarkach, które wykorzystują inny LLM jako sędziego (sędziowie LLM mają tendencję do bycia pobłażliwymi). Bezpośrednie porównanie z innymi systemami znajduje się w sekcji zestawienia poniżej.
PrivacyBenchHIPAA — 40 pytań z zakresu opieki zdrowotnej
Każde pytanie zawiera chronione informacje zdrowotne, które muszą zostać zredagowane (nazwiska, numery dokumentacji medycznej itp.) ORAZ sygnały, które muszą zostać zachowane (daty, lokalizacja geograficzna, wiek poniżej 90 lat — zgodnie z zasadą HIPAA Limited Data Set). System oceniający sprawdza oba kierunki: czy usunęliśmy to, co należało usunąć, i czy zostawiliśmy to, co należało zostawić?
| Tryb | Zredagowane PHI | Zachowane dane |
|---|---|---|
| Limited Data Set (zachowaj daty / geogr. / wiek ≤89) | 79 / 79 (100 %) | 34 / 34 |
| Safe Harbor (redaguj wszystko, w tym daty) | 99 / 104 (95.2 %) | — |
Podtryb Limited Data Set osiągnął w tym benchmarku wynik idealny. Safe Harbor — który wymaga redagowania większej liczby danych, co stwarza więcej okazji do pomyłek — pokrywa 95.2%.
Wyniki kategoria po kategorii na naszych danych, 200 próbek na tryb
Publiczne benchmarki wrzucają wszystko do jednego worka. Nasze wewnętrzne dane testowe rozbijają wyniki na kategorie (nazwiska, e-maile, adresy itd.) i testują każdą z nich na trzy sposoby: tylko regex, tylko ML oraz oba naraz. To mówi nam dokładnie, która technologia wykrywa dany rodzaj identyfikatora — i gdzie jedna potrzebuje wsparcia drugiej. Ostatnie uruchomienie, 2026-05-20:
Podsumowanie we wszystkich trzech trybach filtra
| Tryb | Łączny recall | Precyzja | F2 | Próbki |
|---|---|---|---|---|
| Filtr Personal Data | 97.3 % | 97.8 % | 97.4 | 200 |
| Filtr HIPAA — Limited Data Set | 92.3 % | 92.3 % | 92.3 | 200 |
| Filtr HIPAA — Safe Harbor | 91.9 % | 91.5 % | 91.8 | 200 |
Liczby te nie obejmują adresów URL, które celowo zostawiamy bez zmian — usunięcie URL przerwałoby dalsze działania, takie jak „otwórz ten link” lub „pobierz tę stronę”. Więcej na ten temat w sekcji dotyczącej workflow poniżej.
Ogólny obraz przed tabelami kategorii: w każdym trybie identyfikatory, które faktycznie pozwalają zidentyfikować osobę, są wykrywane w niemal 100% przypadków. Nazwiska, e-maile, numery telefonów, adresy pocztowe, dowody tożsamości, identyfikatory biometryczne, precyzyjna geolokalizacja, numery dokumentacji medycznej, daty urodzenia, numery ubezpieczenia społecznego — wykryte w każdej próbce, w każdym teście. Kategorie, w których spadamy poniżej 100%, są przewidywalne: identyfikatory urządzeń (ogromna różnorodność formatów w rzeczywistym tekście), różne identyfikatory instytucjonalne (numery lojalnościowe, ID pracowników — ten sam problem) oraz zdjęcia (filtr tekstowy nie widzi zawartości obrazu). Żaden z nich nie jest kluczowym identyfikatorem typu „nazwisko na karcie” czy „e-mail w szkicu”, który ma znaczenie dla wycieku danych. Kategorie o wysokiej stawce są niezawodne.
Filtr Personal Data
Posortowane według łącznego recall (najlepsze najpierw), a następnie według poziomu ryzyka (T1 = najbardziej wrażliwe).
| Kategoria | Tier | Recall regex | Recall ML (raw) | Łączny recall | Gold n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| email_address | T1 | 100.0 % (20/20) | 100.0 % (20/20) | 100.0 % | 20 |
| government_id | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| person_name | T1 | 13.3 % (4/30) | 96.7 % (29/30) | 100.0 % | 30 |
| phone_or_fax | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| postal_address | T1 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| precise_geolocation | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| birth_date | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| ip_address | T2 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| online_handle | T2 | 40.0 % (4/10) | 100.0 % (10/10) | 100.0 % | 10 |
| vehicle_id | T2 | 50.0 % (5/10) | 100.0 % (10/10) | 100.0 % | 10 |
| authentication_secret | T4 | 40.0 % (4/10) | 100.0 % (10/10) | 100.0 % | 10 |
| financial_account | T1 | 90.0 % (18/20) | 100.0 % (20/20) | 90.0 % | 20 |
| institutional_id | T3 | 80.0 % (8/10) | 90.0 % (9/10) | 90.0 % | 10 |
| device_id | T3 | 40.0 % (4/10) | 50.0 % (5/10) | 80.0 % | 10 |
Analizując dane, widać, że dwuwarstwowa konstrukcja przynosi efekty. Adresy pocztowe, daty urodzenia i nazwiska osiągają 0–13% przy samym regex — nie mają stałego wzorca do dopasowania, więc tylko model ML może je wykryć. E-maile, numery telefonów, adresy IP, dowody tożsamości, ID biometryczne i precyzyjna geolokalizacja osiągają 100% przy samym regex — to formaty powierzchniowe, które model ML otrzymuje „za darmo”. Nicku online, ID pojazdów i sekrety uwierzytelniania dają wyniki mieszane: regex wykrywa standardowe formy, ML resztę. Łączny recall dorównuje lub przewyższa wynik silniejszej z warstw w każdej kategorii.
Identyfikatory urządzeń i mieszane ID instytucjonalne to kategorie poniżej 100% i wiemy dlaczego: mają one najszerszą gamę formatów w rzeczywistym tekście. Wolimy być szczerzy w kwestii kategorii, w których recall spada, niż udawać, że filtr jest wszędzie idealny.
Filtr HIPAA — podtryb Limited Data Set
Podtryb Limited Data Set z założenia zachowuje daty, lokalizację geograficzną oraz wiek 89 lat lub mniej — są to sygnały, które HIPAA pozwala organizacji zachować do uzasadnionych badań klinicznych i operacji.
| Kategoria | Tier | Recall regex | Recall ML (raw) | Łączny recall | Gold n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| email_address | T1 | 100.0 % (13/13) | 100.0 % (13/13) | 100.0 % | 13 |
| medical_record_number | T1 | 100.0 % (26/26) | 100.0 % (26/26) | 100.0 % | 26 |
| person_name | T1 | 15.4 % (4/26) | 100.0 % (26/26) | 100.0 % | 26 |
| phone_or_fax | T1 | 100.0 % (13/13) | 100.0 % (13/13) | 100.0 % | 13 |
| social_security_number | T1 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| account_number | T2 | 0.0 % (0/13) | 100.0 % (13/13) | 100.0 % | 13 |
| health_plan_id | T2 | 0.0 % (0/13) | 100.0 % (13/13) | 100.0 % | 13 |
| ip_address | T2 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| license_number | T2 | 0.0 % (0/12) | 100.0 % (12/12) | 100.0 % | 12 |
| vehicle_id | T2 | 25.0 % (3/12) | 100.0 % (12/12) | 100.0 % | 12 |
| device_id | T3 | 41.7 % (5/12) | 100.0 % (12/12) | 100.0 % | 12 |
| photo | T2 | 0.0 % (0/12) | 0.0 % (0/12) | 0.0 % | 12 |
Zdjęcia są znanym brakiem — filtr tekstowy nie widzi zawartości obrazu. PHI w obrazach to osobny problem, którego jeszcze nie rozwiązaliśmy. Każda inna kategoria w tym trybie wynosi 100%.
Filtr HIPAA — podtryb Safe Harbor
Safe Harbor usuwa wszystko, co podtryb Limited Data Set by zachował — daty, wiek powyżej 89 lat, lokalizację geograficzną. Aby uzyskać najbardziej rygorystyczne pokrycie, uruchamia on oba modele filtrów równolegle: ten specyficzny dla HIPAA oraz ogólny dla danych osobowych.
| Kategoria | Tier | Recall regex | Recall ML (raw) | Łączny recall | Gold n |
|---|---|---|---|---|---|
| age_over_89 | T1 | 100.0 % (18/18) | 0.0 % (0/18) | 100.0 % | 18 |
| biometric_id | T1 | 100.0 % (9/9) | 100.0 % (9/9) | 100.0 % | 9 |
| email_address | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| medical_record_number | T1 | 100.0 % (20/20) | 100.0 % (20/20) | 100.0 % | 20 |
| person_name | T1 | 20.0 % (4/20) | 100.0 % (20/20) | 100.0 % | 20 |
| phone_or_fax | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| social_security_number | T1 | 90.0 % (9/10) | 100.0 % (10/10) | 100.0 % | 10 |
| account_number | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| general_date | T2 | 100.0 % (27/27) | 29.6 % (8/27) | 100.0 % | 27 |
| health_plan_id | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| ip_address | T2 | 100.0 % (9/9) | 100.0 % (9/9) | 100.0 % | 9 |
| license_number | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| vehicle_id | T2 | 10.0 % (1/10) | 100.0 % (10/10) | 100.0 % | 10 |
| device_id | T3 | 22.2 % (2/9) | 88.9 % (8/9) | 77.8 % | 9 |
| photo | T2 | 0.0 % (0/9) | 0.0 % (0/9) | 0.0 % | 9 |
Dwa interesujące wiersze to ogólne daty (regex 100%, ML 30%) i wiek powyżej 89 lat (regex 100%, ML 0%). Celowo pozwalamy regexowi obsługiwać oba te przypadki w Safe Harbor: daty mają wzorzec, który regex wykrywa za każdym razem, a nie chcemy, aby model probabilistyczny kwestionował próg numeryczny, taki jak „>89”. Deterministyczna reguła jest bardziej niezawodna niż proszenie modelu ML o nauczenie się tej samej zasady.
Ogólne statystyki we wszystkich kategoriach
Podsumowując: jak pełny potok (regex + ML razem) wypada w porównaniu z każdą warstwą z osobna?
| Tryb | Warstwy | Recall | Precyzja | F2 |
|---|---|---|---|---|
| Personal Data | tylko regex | 65.8 % | 93.0 % | 69.9 % |
| Personal Data | tylko ML | 95.4 % | 92.4 % | 94.8 % |
| Personal Data | obie (pełny) | 96.9 % | 98.0 % | 97.1 % |
| Limited Data Set | tylko regex | 55.9 % | 95.0 % | 60.9 % |
| Limited Data Set | tylko ML | 92.9 % | 84.5 % | 91.0 % |
| Limited Data Set | obie (pełny) | 92.9 % | 89.3 % | 92.1 % |
| Safe Harbor | tylko regex | 58.9 % | 93.6 % | 63.6 % |
| Safe Harbor | tylko ML | 82.4 % | 88.3 % | 83.5 % |
| Safe Harbor | obie (pełny) | 92.4 % | 88.9 % | 91.7 % |
Wiersz „pełny” dla filtra Personal Data bije obie wersje jednowarstwowe w każdym metryce — połączenie regex (dla formatów powierzchniowych) z modelem ML (dla kontekstu) autentycznie zapewnia coś, czego żadna warstwa sama nie potrafi. Wynik 97.3% wspomniany wcześniej to liczba odzwierciedlająca to, co otrzymuje realny użytkownik. Liczba w powyższej tabeli jest nieco niższa tylko dlatego, że obejmuje kategorię URL, którą celowo zachowujemy, aby nie psuć linków i wywołań narzędzi.
Bezpośrednie zestawienie z innymi dedykowanymi filtrami prywatności
Uczciwym porównaniem dla działającego na urządzeniu, niemal natychmiastowego filtra prywatności, takiego jak nasz, są inne działające na urządzeniu, niemal natychmiastowe filtry — a nie gigantyczne LLM hostowane w chmurze, które potrzebują sekund na wiadomość i wymagają połączenia sieciowego. Przetestowaliśmy każdy system w tej klasie na tych samych zestawach testowych, stosując te same zasady dopasowania. Ten sam standard dla wszystkich.
Klasa porównawcza:
- openai/privacy-filter — dedykowany filtr prywatności open-source od OpenAI. Około 50 milionów parametrów, wystarczająco mały, by działać w każdej nowoczesnej przeglądarce.
- piiranha-v1 — detektor o 278 mln parametrów od iiiorg. Jego licencja ogranicza go wyłącznie do badań i ewaluacji (możemy go mierzyć, ale nie może być dostarczany komercyjnie).
- Microsoft Presidio — najczęściej wdrażany redaktor open-source, łączący tradycyjne dopasowywanie wzorców z małym modelem językowym dla kontekstu.
- Rodzina GLiNER PII — rodzina małych, ogólnych klasyfikatorów encji. Knowledgator dostarcza warianty small (~44M), base (~86M) i large (~304M); NVIDIA wydała wariant 570M w październiku 2025 r.
- Caiioo we wszystkich trzech trybach (Personal Data, HIPAA Limited Data Set, HIPAA Safe Harbor).
Recall we wszystkich pięciu zestawach testowych, posortowany z Caiioo na początku:
| System | PrivacyBench PD-25 | Caiioo synthetic PD-200 | PrivacyBenchHIPAA-40 | Caiioo synthetic PHI-200 | Multilingual PD-40 (10 lokalizacji) |
|---|---|---|---|---|---|
| Caiioo — Personal Data | 96.2 % (76/79) | 99.0 % (198/200) | — | — | 92.6 % (200/216) |
| Caiioo — HIPAA Limited Data Set | — | — | 100.0 % (79/79) | 100.0 % (200/200) | — |
| Caiioo — HIPAA Safe Harbor | — | — | 100.0 % (79/79) | 100.0 % (200/200) | — |
| openai/privacy-filter (50M) | 96.2 % (76/79) | 83.0 % (166/200) | 93.7 % (74/79) | 77.0 % (154/200) | 94.9 % (205/216) |
| gliner_pii_nvidia (570M) | 94.9 % (75/79) | 85.5 % (171/200) | 84.8 % (67/79) | 85.0 % (170/200) | 76.9 % (166/216) |
| gliner_pii_large (~304M) | 72.2 % (57/79) | 86.5 % (173/200) | 84.8 % (67/79) | 93.0 % (186/200) | 50.0 % (108/216) |
| gliner_pii_base (~86M) | 87.3 % (69/79) | 66.0 % (132/200) | 74.7 % (59/79) | 66.0 % (132/200) | 51.4 % (111/216) |
| gliner_pii_small (~44M) | 88.6 % (70/79) | 84.5 % (169/200) | 91.1 % (72/79) | 83.0 % (166/200) | 68.5 % (148/216) |
| Microsoft Presidio | 82.3 % (65/79) | 76.5 % (153/200) | 84.8 % (67/79) | 76.5 % (153/200) | 69.0 % (149/216) |
| piiranha-v1 (~278M) | 60.8 % (48/79) | 58.5 % (117/200) | 43.0 % (34/79) | 47.0 % (94/200) | 82.4 % (178/216) |
Caiioo prowadzi w klasie dedykowanych filtrów w dwóch największych testach (PD-200 i PHI-200), remisuje lub prowadzi w publicznych benchmarkach i zajmuje drugie miejsce w testach wielojęzycznych. W najmniejszym teście (PrivacyBench PD-25, tylko 25 pytań) Caiioo i openai/privacy-filter remisują z wynikiem 96.2%. W testach wielojęzycznych openai/privacy-filter wciąż prowadzi z 94.9%, podczas gdy Caiioo ma 92.6% — językiem, w którym odstajemy najbardziej, jest chiński; wszędzie indziej jesteśmy na szczycie lub blisko niego. Jeśli wielojęzyczność jest krytyczna, openai/privacy-filter jest rozsądną alternatywą. Dla większości innych zadań w tej klasie, Caiioo jest lepszym wyborem.
Wynik HIPAA to najważniejsza wiadomość. Oba tryby Caiioo HIPAA osiągnęły 100% recall w każdym teście HIPAA — każde nazwisko pacjenta, każdy numer dokumentacji medycznej, każda data urodzenia, każdy numer konta zostały wykryte. Drugim najlepszym systemem jest openai/privacy-filter z wynikiem 93.7% w PrivacyBenchHIPAA — to 6.3 punktu różnicy w benchmarku, gdzie każde pominięcie oznacza ujawnienie danych w świecie rzeczywistym.
Druga liczba warta uwagi: nadmierna redakcja — maskowanie rzeczy, które nie były danymi prywatnymi. Nadmierna redakcja nie jest naruszeniem prywatności, lecz kosztem użyteczności. Zamaskowanie zbyt wielu elementów pogarsza rozumowanie LLM i obniża jakość odpowiedzi. Caiioo maskuje niepotrzebnie 1–24 razy w zestawach testowych. Presidio: 10–51. GLiNER od NVIDIA: 31–64 w samych testach HIPAA. Precyzja ma takie samo znaczenie jak recall, gdy celem jest uzyskanie najlepszej możliwej odpowiedzi przy minimalnej ekspozycji danych.
A co z użyciem czołowego LLM jako filtra?
Mogą one pełnić tę rolę — i pod względem surowego recall wygrywają. Duże, ogólne modele LLM (Llama 3.1 8B, Gemma 4, Qwen 3.5 9B i podobne), działające w chmurze lub lokalnie, mogą osiągać 95–100% we wszystkich testach, w tym wielojęzycznych. Jest to realna opcja dla użytkowników, którzy potrzebują maksymalnego recall i są gotowi za to zapłacić.
Istnieją jednak realne wady:
- Jest to wolne. Sekundy na wiadomość zamiast milisekund. Filtr działa przed każdą wiadomością wysyłaną przez użytkownika.
- Albo wiadomość opuszcza maszynę użytkownika, albo model. Aby filtrować w chmurze, wiadomość musi tam trafić — co przeczy celowi. Filtrowanie na urządzeniu wymaga pobrania modelu o rozmiarze 1–17 GB.
- Można go oszukać. Model generatywny można w trakcie wiadomości przekonać do zaniechania redakcji (atak „prompt injection”). Mały klasyfikator, taki jak nasz, jest na to odporny.
- To samo wejście, różne wyjście. Modele generatywne nie zawsze dają tę samą odpowiedź dwa razy. To psuje proces „round-trip” — maskowanie przy wysyłaniu i odmaskowywanie przy powrocie opiera się na tym, że ta sama realna wartość zawsze mapuje się na tę samą fałszywą.
Caiioo został zbudowany dla drugiej strony tego kompromisu: malutki, przewidywalny, działający w ułamku sekundy filtr, który uruchamia się w edytorze, zanim użytkownik naciśnie „wyślij”, i który zawsze generuje tę samą fałszywą wartość dla tej samej realnej wartości w obrębie rozmowy, dzięki czemu proces round-trip pozostaje spójny. Powyższa tabela porównawcza jest zestawieniem typu „jabłko do jabłka” dla tego rodzaju zastosowań.
Dowód tkwi w praktyce
Benchmarki to punkt wyjścia, a nie linia mety. Filtr jest wbudowany w nową funkcję Caiioo: pseudonymizer — komponent, który faktycznie znajduje się między oknem edycji a modelem.
Oto co się dzieje, gdy użytkownik naciska przycisk wyślij.
- Wykrywanie. Najpierw uruchamiana jest warstwa regex — jest ona deterministyczna i działa z szybkością mikrosekund. Następnie na pozostałym tekście uruchamiany jest model ML. Jeśli obie warstwy nakładają się na ten sam fragment tekstu, stosujemy prostą zasadę: regex wygrywa w przypadku formatów powierzchniowych, ML wygrywa w przypadku kontekstu.
- Oznaczanie siebie vs. innych. Caiioo oddziela identyfikatory odnoszące się do użytkownika od identyfikatorów odnoszących się do innych osób. Użytkownik może zdecydować się na anonimizację tylko jednej grupy lub obu. Nazwy dodane przez użytkownika do osobistego słownika zawsze są traktowane jako „własne”.
- Zastępowanie. Każda rzeczywista wartość otrzymuje stabilny, dopasowany stylistycznie pseudonim. „Sarah Goldberg” staje się „Mayą Hartwell” — i pozostaje „Mayą Hartwell” przez całą rozmowę, dzięki czemu wnioskowanie modelu na temat tej osoby nie ulega rozproszeniu między kolejnymi wypowiedziami. Tabela mapowania wartości rzeczywistych na fałszywe jest przechowywana na urządzeniu użytkownika, zaszyfrowana kluczem z pęku kluczy platformy.
- Wysyłanie. Model otrzymuje w pełni sfałszowaną wiadomość. Żaden rzeczywisty identyfikator nigdy nie trafia do sieci, a nasz dziennik audytu rejestruje wyłącznie liczby — nigdy same wartości.
- Przywracanie. Odpowiedź strumieniowa jest mapowana z powrotem w miarę jej napływania. „Maya Hartwell” w odpowiedzi modelu staje się „Sarah Goldberg”, zanim trafi na ekran, i jest wyświetlana z delikatnym podświetleniem, aby użytkownik mógł na pierwszy rzut oka zobaczyć, co zostało objęte ochroną.
- Przywracanie argumentów narzędzi. Jeśli model wywołuje narzędzie — wysłanie e-maila, założenie zgłoszenia, zapisanie w dokumencie — a argumenty zawierają fałszywe dane, przywracamy rzeczywiste wartości zanim narzędzie zostanie uruchomione. Model operuje na danych sfałszowanych; działanie przyjmuje wartość rzeczywistą.
Filtr nie dba o to, która usługa AI jest używana. Działa on zanim wiadomość dotrze do modelu, więc OpenRouter, Anthropic, Google, OpenAI oraz lokalna Ollama otrzymują ten sam zamaskowany ładunek. Dodanie nowego dostawcy nie powoduje ponownego otwarcia luki w prywatności.
Kogo chroni
Użytkownika. Imię i nazwisko użytkownika, e-mail, adres, telefon, IP i identyfikatory biometryczne — rzeczy, które razem wzięte pozwalają agregatorowi zidentyfikować osobę — nigdy nie opuszczają urządzenia, gdy filtr jest włączony.
Ludzi, o których mówi użytkownik. Większość narzędzi prywatności skupia się na osobie piszącej, ale ignorują one „umowę społeczną” — fakt, że wszyscy jesteśmy odpowiedzialni za innych, tak samo jak za siebie. Przesłanie do LLM prośby „Proszę przeanalizować zachowanie pana Saundersa pod kątem niekompetencji”, gdzie może to zostać zapisane w logach systemowych na czas nieokreślony, jest nieodpowiedzialne (i potencjalnie zniesławiające). Prośba do LLM o pomoc w arkuszu Google Workspace zawierającym 1000 kontaktów biznesowych deponuje je wszystkie w „lepie na muchy” retencji danych (w różnym stopniu, zależnie od faktycznej polityki „zero data retention”). Filtr Caiioo obejmuje również osoby trzecie: klienta, dla którego przygotowywana jest umowa, pacjenta, którego dokumentacja jest analizowana, kolegę, którego e-mail został wklejony do kontekstu. Oni nie wyrazili zgody na to, by zdalny LLM widział ich identyfikatory. Filtr domyślnie to respektuje; użytkownik może przełączyć się na „tylko ja” lub „tylko inni”, jeśli wymaga tego proces pracy.
Podmioty — firmy, szpitale, kancelarie. Numery kont, numery licencji, numery dokumentacji medycznej, szczegóły rozliczeń finansowych, wewnętrzne identyfikatory, klucze API, listy klientów. Firma ma taki sam interes w minimalizacji danych jak osoba prywatna. Lekarz używający Caiioo do przygotowania wypisu nie wysyła numeru dokumentacji medycznej pacjenta do OpenAI. Prawnik nie wysyła numeru konta klienta do Anthropic. Inżynier wsparcia nie wysyła klucza API z logów klienta do Google. Filtr nie pyta, czy identyfikator należy do osoby czy podmiotu — po prostu zatrzymuje go na urządzeniu.
Maksymalna użyteczność, minimalna ekspozycja
Cały sens polega na tym, aby użytkownik nie odczuwał działania filtra.
Większość narzędzi prywatności wymusza wybór: agresywnie maskuj i patrz, jak odpowiedzi modelu stają się gorsze, albo zachowaj użyteczność promptu i patrz, jak obietnica prywatności eroduje. Odrzuciliśmy ten kompromis. Model nadal otrzymuje w pełni sformułowany prompt — widzi nazwisko, miejsce, datę, numer dokumentacji medycznej, wszystko w odpowiednich miejscach gramatycznych. Widzi po prostu fałszywe dane. Jego rozumowanie jest identyczne; tylko ciągi znaków są wyczyszczone.
Stabilna substytucja sprawia, że to działa. Ponieważ ta sama rzeczywista wartość zawsze mapuje się na tę samą fałszywą w obrębie rozmowy — w wiadomości użytkownika, w wyniku narzędzia, który wraca z odniesieniem do tego nazwiska, we wcześniejszej odpowiedzi modelu, która o nim wspominała — model ma spójną osobę, miejsce lub rzecz do analizy. Rozmowy wieloturowe nie ulegają pomieszaniu. Wywołania narzędzi nie psują się. Podagenci dziedziczą mapę rozmowy nadrzędnej i pozostają spójni w całym zadaniu.
Wynik, który widzi użytkownik, to prawdziwa rozmowa. Dane, które widzi dostawca, to spójna fikcja. Praca odbywa się w luce między tymi dwoma widokami, a celem — jedynym celem — jest uczynienie tej luki niewidoczną.
Filtr prywatności, który przeszkadza, zostanie wyłączony. Filtr prywatności, który wtapia się w proces pracy, jest jedynym rodzajem wartym wdrożenia.
To jest poprzeczka, którą sobie postawiliśmy.