OpenAI ha rilasciato uno strumento di classificazione della privacy. openai/privacy-filter è un classificatore token bidirezionale da 1,5 miliardi di parametri, pubblicato con licenza Apache 2.0, che gira nel browser, rileva otto categorie di informazioni personalmente identificabili in un singolo forward pass e copre un livello di governance che molti stack agente trascurano.
Chi legge queste note di rilascio come l'ennesimo drop di un modello perde il segnale reale.
Per chi gestisce agenti su dati di clienti, la redazione dei dati personali viene oggi gestita solitamente con una libreria regex interna oppure instradando le richieste attraverso un LLM: entrambi gli approcci comportano compromessi. Questo articolo analizza cosa sia davvero openai/privacy-filter, le scelte architetturali rilevanti e dove si colloca in uno stack reale di governance degli agenti. Spiega anche perché questa release aggiorna la posizione sugli agenti che leggono input non attendibili e cosa fare con essa quando si distribuiscono carichi di lavoro regolamentati.
Vincoli di governance
- openai/privacy-filter è un classificatore addestrato per uno scopo specifico, non un LLM general-purpose. 1,5 miliardi di parametri totali, 50 milioni attivi tramite routing MoE, contesto da 128.000 token, licenza Apache 2.0.
- L'architettura deriva dalla famiglia gpt-oss. La testa del language model è sostituita da una head di classificazione token BIOES a 33 classi. Decodificata con Viterbi vincolato per la coerenza degli span.
- Gira in una scheda del browser tramite Transformers.js e WebGPU. Nessuna chiamata API, nessuna uscita verso server, nessun account OpenAI richiesto a runtime.
- Rileva otto categorie di dati personali: private_person, private_email, private_phone, private_address, private_url, private_date, account_number, secret.
- Non è anonimizzazione. Priorità all'inglese, con recall ridotto su script non latini. Tassonomia di etichette statica che richiede fine-tuning per essere estesa.
OpenAI ha rilasciato uno strumento di classificazione della privacy.
La maggior parte delle testate lo presenterà come l'ennesimo drop di OpenAI su Hugging Face. Il segnale architetturale è diverso. Si tratta di un classificatore bidirezionale post-addestrato a partire da un checkpoint autoregressivo con struttura gpt-oss, in cui la testa del language model è stata sostituita da una head di classificazione token a 33 classi su otto categorie di span di privacy più una classe di sfondo.
OpenAI non ha rilasciato un modello con cui conversare. Ha rilasciato uno strumento per filtrare input e output destinati ad altri modelli.
È una distinzione importante: il settore ha tendenzialmente utilizzato LLM generativi per compiti che si prestano meglio a classificatori dedicati, incluso il rilevamento dei dati personali. Eseguire un modello general-purpose da 70 miliardi di parametri su ogni richiesta in ingresso per mascherare i dati personali è computazionalmente costoso per quello che è fondamentalmente un compito di classificazione. Un classificatore da 1,5 miliardi di parametri con 50 milioni attivi tramite MoE svolge lo stesso lavoro in un singolo forward pass, gira su un laptop e non può allucinare nuovi indirizzi email.
La scelta di derivare questo strumento da gpt-oss è l'elemento meno riportato. OpenAI sta segnalando che la famiglia gpt-oss sta diventando una base per modelli ausiliari dedicati che agenzie e team di ingegneria sono attesi a eseguire localmente. Ne arriveranno altri.
Per chi sta valutando uno stack di governance agente per un carico di lavoro regolamentato, webvise progetta stack compliance-oriented dall'inizio.
L'architettura, in termini semplici
Privacy Filter è uno stack encoder pre-norm di otto blocchi con grouped-query attention (14 query head, 2 KV head, group size 7), rotary positional embedding e uno sparse MoE a 128 esperti con top-4 routing. La larghezza del residual stream è 640. I parametri totali sono 1,5 miliardi, quelli attivi per token 50 milioni.
Utilizza la banded attention con band size di 128, per una finestra effettiva di 257 token. La lunghezza del contesto arriva a 128.000 token, eliminando la necessità di chunking per i carichi di lavoro tipici su documenti lunghi.
La testa di etichettatura emette 33 logit per token: un'etichetta di sfondo più otto categorie di span espanse in tag BIOES (Begin, Inside, End, Single). L'inferenza utilizza un decoder Viterbi vincolato con linear-chain transition scoring sull'intero percorso di etichette. Sei parametri di transition bias controllano la persistenza dello sfondo, l'ingresso nello span, la continuazione, la chiusura e il passaggio da un confine all'altro. L'effetto pratico è che i confini degli span rimangono coerenti nel testo in formato misto, dove l'argmax indipendente frammenta.
I punti operativi a runtime consentono di regolare il compromesso precisione-recall senza riaddestrare il modello. Orientare verso l'ingresso e la continuazione nello span favorisce la over-redaction (conforme, più rumorosa). Orientare verso la persistenza dello sfondo favorisce la under-redaction (preserva il contesto, rischia perdite). La model card completa, inclusa la metodologia di valutazione, si trova su huggingface.co/openai/privacy-filter.
Perché l'esecuzione nel browser cambia la decisione di posizionamento
La maggior parte dei middleware di redazione dei dati personali gira lato server. I dati attraversano la rete in chiaro, raggiungono un servizio di redazione, vengono sanificati e proseguono verso l'API del modello. Ogni passaggio aggiunge latenza, costi e un punto in cui la versione in chiaro rimane nei log.
Privacy Filter gira in una scheda del browser tramite Transformers.js con WebGPU e quantizzazione q4. L'implicazione: è possibile redigere l'input dell'utente nel suo browser prima che il testo lasci il dispositivo.
Il server riceve una versione redatta. Il log store riceve una versione redatta. Il provider LLM riceve una versione redatta. Non è necessario fidarsi della propria infrastruttura al punto da pretendere che sia perfetta, perché il testo in chiaro non la raggiunge mai.
Questo cambia il calcolo del posizionamento in tre modi. L'inferenza client-side sposta il trust boundary fuori dal data center. Un modello con 50 milioni di parametri attivi è abbastanza compatto da essere distribuito come parte di un bundle standard senza appesantire il budget di caricamento di una web app moderna. La licenza Apache 2.0 consente di fare fine-tuning sui propri dati di dominio e di re-hostare i pesi senza dover negoziare un accordo commerciale.
Ci sono costi reali. Il supporto WebGPU non è uniforme al di fuori dei browser Chromium, i pesi del modello devono essere scaricati una volta per ogni cache bust, e la finestra di inferenza è limitata dalla memoria disponibile del dispositivo. Per un flusso di compliance su una web app desktop, questi costi sono accettabili. Per una webview mobile con cache eviction aggressiva, di solito non lo sono.
Dove si colloca in uno stack di governance degli agenti
Uno stack di governance degli agenti ben strutturato ha livelli distinti. Il modello di lavoro usato presso webvise è questo:
- Layer 1: Autenticazione in ingresso e rate limiting
- Layer 2: Data minimization (redazione dell'input)
- Layer 3: Composizione del prompt e assemblaggio del contesto
- Layer 4: Inferenza del modello
- Layer 5: Filtraggio dell'output (dati personali, sicurezza, policy)
- Layer 6: Uscita verso handler di azioni, storage, API di terze parti
openai/privacy-filter si posiziona naturalmente al Layer 2 e, con una calibrazione diversa del punto operativo, al Layer 5. Non sostituisce i modelli di sicurezza, i rilevatori di prompt injection o i policy engine a livello agente. Sostituisce la libreria regex in manutenzione, con proprietà architetturali che gli approcci basati su regole non possono eguagliare.
| Posizionamento | Trust boundary | Quando usarlo |
|---|---|---|
| Client-side (browser + WebGPU) | Il testo in chiaro non lascia il dispositivo | Web app compliance-first, settori regolamentati, strumenti interni |
| Middleware server (Node + Transformers) | Server attendibile, log verificati | API, agenti backend, pipeline batch |
| Filtro di output (post-risposta) | L'output del modello non raggiunge il client grezzo | Agenti chat, contenuti generati, flussi RAG rivolti all'utente |
Per la maggior parte degli stack client progettati, la risposta è Layer 2 e Layer 5 in combinazione. Il controllo locale nel browser impedisce che dati personali accidentali entrino nella finestra di contesto. Il controllo server-side sull'output intercetta qualsiasi dato che il modello generi o riveli nella risposta. La difesa in profondità è il punto.
Per chi sta mappando i propri flussi di dati rispetto a un livello di governance, è utile confrontarsi con webvise sulla progettazione dello stack prima di prendere decisioni definitive.
Le otto categorie e i limiti del modello
La tassonomia di etichette di Privacy Filter è statica: otto categorie più una classe di sfondo, con tag di confine BIOES per categoria.
| Categoria | Cosa rileva | Modalità di errore nota |
|---|---|---|
| private_person | Nomi di persone | Nomi regionali non comuni, iniziali, riferimenti con honorifici frequenti vengono sotto-rilevati |
| private_email | Indirizzi email | Copertura solida. I formati offuscati ("nome chiocciola dominio") possono sfuggire |
| private_phone | Numeri di telefono | I formati internazionali sono gestiti bene. I separatori non standard frammentano occasionalmente |
| private_address | Indirizzi postali | Gli indirizzi su più righe in layout densi si frammentano ai confini |
| private_url | URL identificativi | Over-redact sugli URL di entità pubbliche quando il contesto locale è ambiguo |
| private_date | Data di nascita, appuntamenti | Sensibile al contesto. Le date di calendario nel testo di pianificazione possono essere over-redatte |
| account_number | Conti bancari, ID cliente, ID paziente | Sotto-rileva i pattern di identificatori specifici del dominio |
| secret | Chiavi API, credenziali, token | I formati di credenziali nuovi e i segreti suddivisi vengono mancati |
Se il dominio include categorie non presenti in questo elenco, è necessario fare fine-tuning. La model card è esplicita sul fatto che la label policy non può essere modificata a runtime: questo è il costo di un classificatore con 50 milioni di parametri attivi, la tassonomia è incorporata nel modello. Per i team che confrontano le opzioni, la guida ai migliori modelli AI locali per le aziende conformi nel 2026 copre il lato LLM general-purpose della stessa decisione.
La model card di OpenAI è insolitamente diretta. Tre limiti da considerare seriamente prima del rilascio in produzione.
Performance multilingue con priorità all'inglese
Il modello è stato testato su benchmark multilingue selezionati. L'accuratezza cala su script non latini e convenzioni di denominazione di gruppi protetti. Per chi distribuisce a clienti con dati personali in tedesco, polacco o italiano, il recall degrada. È consigliabile fare fine-tuning su esempi del proprio dominio o eseguire un fallback regex in secondo passaggio per le categorie più critiche.
Non è anonimizzazione
Si tratta di uno strumento di redazione, non di una garanzia di anonimizzazione. Rimuovere i dati personali in superficie non elimina il rischio di re-identificazione quando quasi-identificatori (codice postale, età, diagnosi rara) si combinano. Se l'obbligo di conformità è l'anonimizzazione GDPR o la de-identificazione HIPAA con il metodo Safe Harbor, è necessaria una pipeline dedicata che si affianca a questo strumento. L'analisi su normative e certificazioni AI in Germania e in Europa mappa in dettaglio lo stack regolatorio.
I flussi ad alta sensibilità richiedono supervisione umana
Ambito medico, legale, finanziario, HR, educativo, pubblico. In questi settori, i falsi negativi espongono dati e i falsi positivi eliminano contesto necessario ai revisori per prendere decisioni. Privacy Filter è un input per un processo di revisione in questi contesti, non un sostituto.
La regola adottata: Privacy Filter si inserisce in uno stack con almeno un ulteriore controllo a valle. Se è l'unico livello, un singolo aggiornamento del modello può introdurre una regressione che nessuno intercetta.
Aggiornamento della posizione "nessun agente sul web aperto"
All'inizio di questo mese è stata pubblicata una posizione: webvise non distribuirà agenti AI che leggono il web aperto per i clienti. Il motivo era concreto. Gli input controllati da un attaccante, come una pagina web scraped, un URL inviato dall'utente o un feed di terze parti, portano all'agente dati personali, credenziali o payload di prompt injection che filtrano verso le azioni a valle.
openai/privacy-filter cambia parzialmente questo calcolo. Sul fronte della perdita di input, eseguire un classificatore locale nel browser sul contenuto scraped prima che entri nel contesto del prompt attenua due pattern specifici: l'esposizione di dati sensibili e l'avvelenamento del contesto tramite dati personali incorporati.
Il vettore di prompt injection non viene toccato. Una pagina costruita ad arte può comunque istruire l'agente a inviare via email il contenuto della sua memoria. Quello che questo strumento impedisce è che quella stessa pagina porti accidentalmente l'indirizzo di casa di un cliente nella finestra di contesto del modello.
L'aggiornamento della posizione: verranno ora distribuiti lettori open-web circoscritti per flussi di lavoro non sensibili (aggregazione di dati pubblici, intelligence competitiva, ricerche di mercato) se Privacy Filter è attivo su entrambi i lati della chiamata al modello. Non verranno distribuiti per flussi che toccano dati di clienti, documenti interni o azioni autenticate senza prima un red-team pass dedicato.
Come integrarlo
Due pattern comuni, entrambi direttamente dalla model card. La pipeline Python per la redazione lato server:
`from transformers import pipeline; classifier = pipeline(task="token-classification", model="openai/privacy-filter"); classifier("My name is Alice Smith")`
La pipeline Transformers.js per la redazione lato browser tramite 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" });`
La pipeline browser va inserita in un Web Worker in modo che l'inferenza non blocchi il thread principale. I pesi del modello vanno messi in cache con un service worker in modo che la penalità della prima visita si paghi una sola volta per cache bust. Il punto operativo va calibrato in staging con dati rappresentativi prima di toccare la produzione. Il repository ufficiale contiene la model card completa, uno spazio demo e la guida al fine-tuning.
Il rilascio di privacy-filter da parte di OpenAI è una tesi su dove sta andando il settore: classificatori dedicati, eseguibili nel browser, con licenza Apache 2.0, ai bordi dello stack, che filtrano ciò che gli LLM ricevono e ciò che restituiscono. È la forma del lavoro di compliance che si fa presso webvise, ed è la forma del livello di governance che manca alla maggior parte degli agenti oggi.
Gli stack agente senza un livello di data minimization hanno in questa release un solido punto di partenza open-weight. Per chi vuole supporto nell'integrarlo in qualcosa su cui i clienti possano fare affidamento in produzione, webvise costruisce esattamente questo.
Le pratiche di webvise sono allineate agli standard ISO 27001 e ISO 42001.