OpenAI Privacy Filter: otwarty model PII działający w przeglądarce i jego miejsce w stosie zarządzania agentami

OpenAI właśnie udostępniło narzędzie do klasyfikacji prywatności. openai/privacy-filter to dwukierunkowy klasyfikator tokenów o 1,5 miliarda parametrów, opublikowany na licencji Apache 2.0, działający w przeglądarce, wykrywający osiem kategorii danych osobowych w jednym przejściu w przód i wypełniający warstwę zarządzania, którą wiele stosów agentów pomija.

Kto odczyta te informacje o wydaniu jako kolejną premierę modelu, ten przeoczy właściwy sygnał.

Przy uruchamianiu agentów na danych klientów redakcja PII jest zazwyczaj obsługiwana przez wewnętrzną bibliotekę wyrażeń regularnych lub przez routing żądań przez LLM. Oba podejścia mają swoje kompromisy. Ten artykuł omawia, czym naprawdę jest openai/privacy-filter, jakie decyzje architektoniczne mają znaczenie i gdzie powinien on znaleźć się w rzeczywistym stosie zarządzania agentami. Wyjaśniam też, dlaczego to wydanie zmienia moje stanowisko dotyczące agentów odczytujących niezaufane dane wejściowe, oraz co z tym zrobić przy regulowanych obciążeniach.

Kluczowe wnioski

• openai/privacy-filter to klasyfikator trenowany do określonego celu, nie ogólny LLM. Łącznie 1,5 miliarda parametrów, 50 milionów aktywnych przez routing MoE, kontekst 128 000 tokenów, licencja Apache 2.0.
• Architektura wywodzi się z linii gpt-oss. Głowica modelu językowego została zastąpiona głowicą klasyfikacji tokenów z 33 klasami w formacie BIOES. Dekodowanie z użyciem ograniczonego algorytmu Viterbiego zapewnia spójność granic span.
• Działa w karcie przeglądarki przez Transformers.js i WebGPU. Brak wywołania API, brak egresji do serwera, brak wymagania konta OpenAI w czasie działania.
• Wykrywa osiem kategorii PII: private_person, private_email, private_phone, private_address, private_url, private_date, account_number, secret.
• Nie jest to anonimizacja. Model jest przede wszystkim zoptymalizowany pod kątem języka angielskiego i ma obniżoną czułość dla skryptów niełacińskich. Statyczna taksonomia etykiet wymaga dostrojenia w celu rozszerzenia.

OpenAI udostępniło narzędzie do klasyfikacji prywatności.

Większość mediów opisze to jako kolejną premierę OpenAI na Hugging Face. Sygnał architektoniczny jest inny. Jest to dwukierunkowy klasyfikator wytrenowany po fazie bazowej na podstawie autoregresywnego punktu kontrolnego w kształcie gpt-oss, z głowicą modelu językowego zastąpioną głowicą klasyfikacji tokenów z 33 klasami obejmującą osiem kategorii prywatności plus klasę tła.

OpenAI nie udostępnia modelu do prowadzenia rozmów. Udostępnia narzędzie do bramkowania danych wejściowych i wyjściowych dla innych modeli.

Ma to znaczenie, ponieważ branża przez ostatnie lata traktowała generatywne LLM jako domyślny prymityw dla każdego problemu tekstowego, w tym tych, do których LLM są mniej odpowiednie. Redakcja PII to problem klasyfikacji. Uruchamianie ogólnego modelu o 70 miliardach parametrów dla każdego przychodzącego żądania w celu maskowania adresów e-mail jest obliczeniowo kosztowne dla zadania będącego w istocie klasyfikacją. Klasyfikator o 1,5 miliarda parametrów z 50 milionami aktywnych parametrów MoE wykonuje tę samą pracę w jednym przejściu w przód, działa na laptopie i nie może halucynować nowych adresów e-mail.

Decyzja o wywodzeniu tego modelu z gpt-oss to element, o którym mówi się za mało. OpenAI sygnalizuje, że rodzina gpt-oss staje się fundamentem dla modeli pomocniczych budowanych do konkretnych celów, które agencje i zespoły inżynieryjne mają uruchamiać lokalnie. Należy spodziewać się kolejnych.

Przy ocenie stosu zarządzania agentami pod kątem regulowanych obciążeń zapraszamy do kontaktu: webvise projektuje stosy zgodne z wymogami compliance od podstaw.

Architektura, prostym językiem

Privacy Filter to stos koderów pre-norm złożony z ośmiu bloków z grupowaną uwagą zapytań (14 głowic zapytań, 2 głowice KV, rozmiar grupy 7), rotacyjnymi osadzeniami pozycji oraz rzadką siecią MoE z 128 ekspertami i routingiem top-4. Szerokość strumienia resztkowego wynosi 640. Łączna liczba parametrów to 1,5 miliarda, aktywnych na token 50 milionów.

Model używa uwagi pasmowej o rozmiarze pasma 128, co daje efektywne okno 257 tokenów. Maksymalna długość kontekstu to 128 000 tokenów, co eliminuje konieczność podziału na fragmenty przy typowych długich dokumentach.

Głowica etykietowania generuje 33 logity na token: jedną etykietę tła plus osiem kategorii span rozszerzonych do tagów BIOES (Beginning, Inside, End, Single). Wnioskowanie korzysta z ograniczonego dekodera Viterbiego z liniowym ocenianiem przejść po kompletnych ścieżkach etykiet. Sześć parametrów biasu przejść kontroluje trwałość tła, wejście do span, kontynuację, zamknięcie i przekazanie granicy do granicy. Praktycznym efektem jest spójność granic span w tekście mieszanego formatu, gdzie niezależne dekodowanie argmax prowadzi do fragmentacji.

Parametry operacyjne w czasie wykonania pozwalają dostroić kompromis między precyzją a czułością bez ponownego trenowania. Przesunięcie biasu w kierunku wejścia do span i kontynuacji daje nadmierną redakcję (korzystna dla compliance, wyższy poziom szumów). Przesunięcie w kierunku trwałości tła daje niedostateczną redakcję (zachowuje kontekst, ryzyko wycieku). Pełna karta modelu wraz z metodologią ewaluacji dostępna jest pod adresem huggingface.co/openai/privacy-filter.

Dlaczego możliwość uruchomienia w przeglądarce zmienia decyzję o umiejscowieniu

Większość oprogramowania pośredniczącego do redakcji PII działa po stronie serwera. Dane przechodzą przez sieć w postaci jawnej, trafiają do serwisu redakcji, są sanityzowane i kontynuują drogę do API modelu. Każdy krok dodaje opóźnienie, koszty i punkt, w którym jawna wersja pojawia się w logach.

Privacy Filter działa w karcie przeglądarki przez Transformers.js z WebGPU i kwantyzacją q4. Implikacja: możliwa jest redakcja danych wejściowych użytkownika w jego własnej przeglądarce, zanim tekst w ogóle opuści urządzenie.

Serwer widzi wersję zredagowaną. Serwis logów widzi wersję zredagowaną. Dostawca LLM widzi wersję zredagowaną. Własna infrastruktura nie musi być perfekcyjna, ponieważ jawny tekst do niej nie dociera.

To zmienia kalkulację umiejscowienia na trzy sposoby. Wnioskowanie po stronie klienta przesuwa granicę zaufania poza centrum danych. Model z 50 milionami aktywnych parametrów jest wystarczająco mały, by dostarczać go jako część standardowego pakietu bez nadmiernego obciążania budżetu ładowania nowoczesnej aplikacji webowej. Licencja Apache 2.0 pozwala na dostrojenie na własnych danych dziedzinowych i ponowne udostępnienie wag bez negocjowania umowy komercyjnej.

Istnieje też realny koszt. Obsługa WebGPU jest niespójna poza przeglądarkami opartymi na Chromium, wagi modelu muszą być pobrane raz przy każdym wygaśnięciu cache, a okno wnioskowania ogranicza dostępna pamięć urządzenia. Dla procesu compliance w desktopowej aplikacji webowej koszty te są akceptowalne. Dla mobilnego widoku webowego z agresywnym usuwaniem cache zazwyczaj nie.

Miejsce w stosie zarządzania agentami

Rzeczywisty stos zarządzania agentami składa się z wyraźnych warstw. Model roboczy stosowany w webvise wygląda następująco:

• Warstwa 1: Uwierzytelnianie przy wejściu i ograniczanie liczby żądań
• Warstwa 2: Minimalizacja danych (redakcja danych wejściowych)
• Warstwa 3: Kompozycja promptów i asemblacja kontekstu
• Warstwa 4: Wnioskowanie modelu
• Warstwa 5: Filtrowanie danych wyjściowych (PII, bezpieczeństwo, polityki)
• Warstwa 6: Egresja do obsługi akcji, pamięci masowej, zewnętrznych API

openai/privacy-filter pasuje precyzyjnie do Warstwy 2 oraz, przy innej kalibracji parametrów operacyjnych, do Warstwy 5. Nie zastępuje modeli bezpieczeństwa, detektorów wstrzyknięć promptów ani silników polityk na poziomie agenta. Zastępuje natomiast bibliotekę wyrażeń regularnych wymagającą bieżącego utrzymania, i robi to z właściwościami architektonicznymi, których podejścia oparte na regułach nie mogą dorównać.

Dla większości projektowanych stosów klientów odpowiedzią jest połączenie Warstwy 2 i Warstwy 5. Sprawdzenie lokalne w przeglądarce zapobiega przypadkowemu trafieniu PII do okna kontekstu. Sprawdzenie danych wyjściowych po stronie serwera wychwytuje to, co model wygeneruje lub ujawni w odpowiedzi. Obrona w głąb jest tutaj celem.

Przy mapowaniu przepływów danych względem warstwy zarządzania zapraszamy do rozmowy o architekturze stosu przed podjęciem zobowiązań: webvise, kontakt.

Osiem kategorii i ograniczenia modelu

Taksonomia etykiet Privacy Filter jest statyczna. Osiem kategorii plus klasa tła, z tagami granicznymi BIOES dla każdej kategorii.

Jeśli dana dziedzina zawiera kategorie spoza tej listy, konieczne jest dostrojenie modelu. Karta modelu wyraźnie wskazuje, że polityki etykiet nie można zmieniać w czasie wykonania. To koszt klasyfikatora z 50 milionami aktywnych parametrów: taksonomia jest wbudowana. Dla zespołów porównujących opcje, przewodnik dotyczący najlepszych lokalnych modeli AI dla firm z wymogami compliance w 2026 roku omawia stronę ogólnych LLM w tej samej decyzji.

Karta modelu OpenAI jest wyjątkowo konkretna. Trzy ograniczenia warte poważnego rozważenia przed wdrożeniem.

Przede wszystkim angielski, nie wielojęzyczny

Model był testowany na wybranych wielojęzycznych testach porównawczych. Dokładność spada dla skryptów niełacińskich i konwencji nazewnictwa grup chronionych. Przy wdrożeniach dla klientów z danymi osobowymi w języku niemieckim, polskim lub włoskim należy liczyć się z obniżoną czułością. Zalecane jest dostrojenie na przykładach z danej dziedziny lub uruchomienie rezerwowego sprawdzania wyrażeniami regularnymi dla najważniejszych kategorii.

Nie jest to anonimizacja

To narzędzie wspomagające redakcję, nie gwarancja anonimizacji. Usunięcie powierzchniowych danych PII nie eliminuje ryzyka reidentyfikacji, gdy quasi-identyfikatory (kod pocztowy, wiek, rzadka diagnoza) skupiają się razem. Jeśli obowiązek compliance dotyczy anonimizacji RODO lub deanonimizacji HIPAA metodą Safe Harbor, wymagany jest dedykowany potok ponad tym rozwiązaniem, a nie samo to rozwiązanie. Artykuł o regulacjach i certyfikacjach AI w Niemczech i Europie szczegółowo mapuje stos regulacyjny.

Procesy o wysokiej wrażliwości wymagają człowieka w pętli

Medycyna, prawo, finanse, HR, edukacja, administracja publiczna. W tych sektorach fałszywe negatywy narażają dane, a fałszywe pozytywy pozbawiają recenzentów kontekstu niezbędnego do podejmowania decyzji. Privacy Filter jest w tych zastosowaniach danymi wejściowymi do procesu przeglądu, a nie jego zamiennikiem.

Zasada robocza: Privacy Filter powinien działać w stosie z co najmniej jednym dodatkowym sprawdzeniem poniżej. Jeśli jest jedyną warstwą, jedna aktualizacja modelu może spowodować regresję, której nikt nie wychwytuje.

Aktualizacja stanowiska dotyczącego agentów w otwartym internecie

Wcześniej w tym miesiącu webvise opublikowało stanowisko: nie będą wdrażane agenty AI odczytujące otwarty internet dla klientów. Powód był konkretny. Dane wejściowe kontrolowane przez atakującego (zeskrobana strona, URL przesłany przez użytkownika, zewnętrzne źródło danych) dostarczają agentowi PII, poświadczeń lub przeładunków wstrzyknięć promptów, które wyciekają do dalszych działań.

openai/privacy-filter częściowo zmienia tę kalkulację. W zakresie wycieku danych wejściowych uruchomienie lokalnego klasyfikatora przeglądarki na zeskrobanych treściach przed ich wejściem do kontekstu promptu tłumi dwa konkretne wzorce: narażenie danych wrażliwych i zatruwanie kontekstu przez osadzone PII.

Wektor wstrzyknięcia promptu pozostaje niezmieniony. Model nie powstrzyma starannie spreparowanej strony przed wydaniem agentowi polecenia wysłania zawartości pamięci e-mailem. Powstrzyma natomiast przypadkowe przeniesienie adresu domowego klienta do okna kontekstu modelu.

Zaktualizowane stanowisko: wąskie narzędzia odczytujące otwarty internet będą teraz wdrażane dla procesów nieobejmujących danych wrażliwych (agregacja danych publicznych, wywiad konkurencyjny, badania rynku), jeśli Privacy Filter jest podłączony po obu stronach wywołania modelu. Nie będą wdrażane dla procesów dotykających rejestrów klientów, dokumentów wewnętrznych lub uwierzytelnionych działań bez uprzedniego dedykowanego badania bezpieczeństwa.

Jak podłączyć model

Dwa typowe wzorce, oba wprost z karty modelu. Potok Python do redakcji po stronie serwera:

`from transformers import pipeline; classifier = pipeline(task="token-classification", model="openai/privacy-filter"); classifier("My name is Alice Smith")`

Oraz potok Transformers.js do redakcji po stronie przeglądarki przez WebGPU:

`import { pipeline } from "@huggingface/transformers"; const classifier = await pipeline("token-classification", "openai/privacy-filter", { device: "webgpu", dtype: "q4" }); await classifier(input, { aggregation_strategy: "simple" });`

Potok przeglądarki powinien działać w Web Workerze, by wnioskowanie nie blokowało głównego wątku. Wagi modelu należy buforować za pomocą service workera, by koszt pierwszej wizyty był ponoszony tylko raz przy wygaśnięciu cache. Przed wdrożeniem produkcyjnym parametr operacyjny powinien być dostrojony na reprezentatywnych danych w środowisku testowym. Oficjalne repozytorium zawiera kompletną kartę modelu, przestrzeń demo i wskazówki dotyczące dostrajania.

Premiera openai/privacy-filter to teza o kierunku, w którym zmierza branża: dedykowane klasyfikatory na licencji Apache 2.0 działające w przeglądarce na krawędziach stosu, filtrujące to, co LLM widzą i co zwracają. To kształt pracy nad compliance realizowanej w webvise i kształt warstwy zarządzania, której większości agentów dziś brakuje.

Stosy agentów bez warstwy minimalizacji danych mają w tej premierze solidny punkt wyjścia oparty na otwartych wagach. Dla tych, którzy potrzebują pomocy przy wdrożeniu rozwiązania, na którym klienci mogą polegać w produkcji: webvise buduje takie stosy.