OpenAI Privacy Filter : le modèle PII open-weight qui s'exécute dans votre navigateur (et sa place dans une architecture d'agents)

OpenAI vient de publier un outil, et non un modèle. openai/privacy-filter est un classificateur de tokens bidirectionnel de 1,5 milliard de paramètres, publié sous licence Apache 2.0, qui s'exécute dans votre navigateur, détecte huit catégories d'informations personnellement identifiables en un seul passage direct et comble la couche de gouvernance que la plupart des architectures d'agents ignorent.

Si vous lisez les notes de version comme une nouvelle publication de modèle, vous passerez à côté du véritable signal.

Si vous faites tourner des agents sur des données clients aujourd'hui, la suppression des données personnelles repose probablement sur une bibliothèque regex que vous maintenez ou sur un appel LLM que vous préféreriez éviter de payer. Cet article explique ce qu'est réellement openai/privacy-filter, les choix architecturaux qui importent et la place qu'il occupe dans une véritable architecture de gouvernance d'agents. Nous expliquerons également pourquoi cette publication fait évoluer notre position sur les agents qui lisent des entrées non fiables, et ce que vous devez en faire si vous déployez des charges de travail réglementées.

Points clés

• openai/privacy-filter est un classificateur entraîné à des fins spécifiques, et non un LLM généraliste. 1,5 milliard de paramètres au total, 50 millions actifs via le routage MoE, contexte de 128 000 tokens, licence Apache 2.0.

• L'architecture dérive de la lignée gpt-oss. La tête de modèle de langage est remplacée par une tête de classification de tokens à 33 classes en schéma BIOES. Décodage effectué avec Viterbi contraint pour assurer la cohérence des spans.

• S'exécute dans un onglet de navigateur via Transformers.js et WebGPU. Aucun aller-retour API, aucune sortie de données vers un serveur, aucun compte OpenAI requis à l'exécution.

• Détecte huit catégories de données personnelles : private_person, private_email, private_phone, private_address, private_url, private_date, account_number, secret.

• Ne constitue pas une anonymisation. Priorité à l'anglais, avec un rappel dégradé sur les scripts non latins. Taxonomie de labels statique nécessitant un Fine-Tuning pour être étendue.

OpenAI a publié un outil, et non un modèle. C'est là la nouveauté.

La plupart des médias présenteront cela comme une nouvelle publication OpenAI sur Hugging Face. Le signal architectural est différent. Il s'agit d'un classificateur bidirectionnel post-entraîné à partir d'un checkpoint autorégressif de forme gpt-oss, dont la tête de modèle de langage a été remplacée par une tête de classification de tokens à 33 classes couvrant huit catégories de spans de confidentialité, plus une classe de fond.

OpenAI ne publie pas un modèle pour dialoguer. Ils publient un outil pour filtrer les entrées et les sorties des autres modèles.

Cela importe parce que le secteur a passé trois ans à traiter les LLM génératifs comme le primitif par défaut pour tout problème textuel, y compris ceux pour lesquels les LLM sont peu adaptés. La suppression des données personnelles est un problème de classification. Faire tourner un modèle généraliste de 70 milliards de paramètres sur chaque requête entrante pour lui demander de masquer des adresses e-mail est un contournement coûteux. Un classificateur de 1,5 milliard de paramètres avec 50 millions de paramètres MoE actifs accomplit le même travail en un seul passage direct, s'exécute sur un ordinateur portable et ne peut pas halluciner de nouvelles adresses e-mail.

La décision de dériver ce modèle de gpt-oss est la partie la moins commentée. OpenAI signale que la famille gpt-oss n'est pas un geste isolé de relations publiques. Elle devient une fondation pour des modèles auxiliaires à vocation spécifique que les agences et les équipes d'ingénierie sont censées exécuter localement. D'autres modèles de ce type sont à prévoir.

Si vous évaluez une architecture de gouvernance d'agents pour une charge de travail réglementée, webvise conçoit des architectures conformes de bout en bout.

L'architecture, en langage accessible

Privacy Filter est une pile d'encodeurs pré-normalisés composée de huit blocs avec une attention par requête groupée (14 têtes de requête, 2 têtes KV, taille de groupe 7), des embeddings positionnels rotatifs et un bloc feed-forward MoE sparse à 128 experts avec routage top-4. La largeur du flux résiduel est de 640. Le total de paramètres s'élève à 1,5 milliard, les paramètres actifs par token à 50 millions.

Le modèle utilise une attention en bande avec une taille de bande de 128, offrant une fenêtre effective de 257 tokens. La longueur de contexte plafonne à 128 000 tokens, ce qui élimine le découpage en morceaux pour les charges de travail typiques sur des documents longs.

La tête de labellisation émet 33 logits par token : un label de fond plus huit catégories de spans développées en tags BIOES (Begin, Inside, End, Single). L'Inference exécute un décodeur Viterbi contraint avec un scoring de transition à chaîne linéaire sur les chemins de labels complets. Six paramètres de biais de transition contrôlent la persistance du fond, l'entrée dans un span, la continuation, la clôture et le transfert entre frontières. L'effet pratique est que les frontières de spans restent cohérentes dans les textes à format mixte où le décodage argmax indépendant fragmente les résultats.

Les points de fonctionnement à l'exécution vous permettent d'ajuster le compromis précision-rappel sans réentraînement. Biais vers l'entrée et la continuation de span pour une sur-suppression (favorable à la conformité, plus de bruit). Biais vers la persistance du fond pour une sous-suppression (préserve le contexte, risque de fuite). La fiche modèle complète, y compris la méthodologie d'évaluation, est disponible sur huggingface.co/openai/privacy-filter.

Pourquoi l'exécution dans le navigateur change la décision de placement

La plupart des middlewares de suppression de données personnelles s'exécutent côté serveur. Les données transitent en clair, atteignent un service de suppression, sont nettoyées, puis continuent vers l'API du modèle. Chaque étape ajoute de la latence, des coûts et un point où la version en clair se retrouve dans les journaux.

Privacy Filter s'exécute dans un onglet de navigateur via Transformers.js avec WebGPU et la quantification q4. L'implication : vous pouvez supprimer les données personnelles de la saisie de l'utilisateur dans son propre navigateur avant que le texte ne quitte jamais l'appareil.

Le serveur reçoit une version nettoyée. Le stockage des journaux reçoit une version nettoyée. Le fournisseur de LLM reçoit une version nettoyée. Vous n'avez pas à faire confiance à votre propre infrastructure pour être parfaite, car le texte en clair ne l'atteint jamais.

Cela modifie le calcul de placement de trois façons. L'Inference côté client déplace la frontière de confiance hors de votre centre de données. Un modèle de 50 millions de paramètres actifs est suffisamment petit pour être intégré dans un bundle standard sans dépasser le budget de chargement d'une application web moderne. Et la licence Apache 2.0 signifie que vous pouvez effectuer un Fine-Tuning sur vos propres données de domaine et héberger les poids vous-même sans négocier d'accord commercial.

Il existe un coût réel. La prise en charge de WebGPU est inégale en dehors des navigateurs Chromium, les poids du modèle doivent être téléchargés une fois par invalidation de cache, et la fenêtre d'Inference est limitée par la mémoire disponible de l'appareil. Pour un processus de conformité sur une application web de bureau, ces coûts sont acceptables. Pour une webview mobile avec une éviction de cache agressive, ce n'est généralement pas le cas.

La place de ce modèle dans une architecture de gouvernance d'agents

Une véritable architecture de gouvernance d'agents comporte des couches distinctes. Le modèle de travail que nous utilisons chez webvise se présente comme suit :

• Couche 1 : Authentification à l'entrée et limitation du débit

• Couche 2 : Minimisation des données (suppression en entrée)

• Couche 3 : Composition des prompts et assemblage du contexte

• Couche 4 : Inference du modèle

• Couche 5 : Filtrage des sorties (données personnelles, sécurité, politique)

• Couche 6 : Sortie vers les gestionnaires d'actions, le stockage, les API tierces

openai/privacy-filter s'intègre naturellement à la Couche 2 et, avec un calibrage différent du point de fonctionnement, à la Couche 5. Il ne remplace pas les modèles de sécurité, les détecteurs d'injection de prompts ni les moteurs de politique au niveau des agents. Il remplace en revanche la bibliothèque regex que vous mainteniez, et ce avec des propriétés architecturales que les approches basées sur des règles ne peuvent pas égaler.

Pour la plupart des architectures clients que nous concevons, la réponse est la combinaison des Couches 2 et 5. La vérification locale au navigateur empêche les données personnelles accidentelles d'entrer dans la fenêtre de contexte en premier lieu. La vérification côté serveur en sortie intercepte tout ce que le modèle génère ou laisse filtrer dans sa réponse. La défense en profondeur est l'objectif.

Si vous cartographiez vos flux de données par rapport à une couche de gouvernance aujourd'hui, parlez à webvise de la conception de votre architecture avant de vous engager.

Les huit catégories, et les limites de ce modèle

La taxonomie de labels de Privacy Filter est statique. Huit catégories plus une classe de fond, avec des tags de frontière BIOES par catégorie.

Si votre domaine comporte des catégories hors de cette liste, vous effectuez un Fine-Tuning. La fiche modèle précise explicitement que vous ne pouvez pas modifier la politique de labels à l'exécution. C'est le coût d'un classificateur de 50 millions de paramètres actifs : la taxonomie est intégrée. Pour les équipes qui comparent leurs options, notre guide sur les meilleurs modèles d'IA locaux pour les entreprises soumises à des contraintes de conformité en 2026 couvre le volet LLM généraliste de la même décision.

La fiche modèle d'OpenAI est inhabituellement directe. Trois limites méritent d'être prises au sérieux avant tout déploiement.

Priorité à l'anglais, pas multilingue

Le modèle a été testé sur des benchmarks multilingues sélectionnés, mais la précision diminue sur les scripts non latins et les conventions de nommage des groupes protégés. Si vous déployez pour un client avec des données personnelles en allemand, en polonais ou en italien, attendez-vous à une dégradation du rappel. Effectuez un Fine-Tuning sur des exemples du domaine ou appliquez un fallback regex en second passage pour les catégories les plus critiques.

Pas une anonymisation

Il s'agit d'un outil d'aide à la suppression, et non d'une garantie d'anonymisation. Supprimer les données personnelles de surface n'élimine pas le risque de ré-identification lorsque des quasi-identifiants (code postal, âge, diagnostic rare) se regroupent. Si votre obligation de conformité est l'anonymisation au sens du RGPD ou la dé-identification HIPAA selon la méthode Safe Harbor, vous avez besoin d'un pipeline dédié en plus de cet outil, et non de cet outil seul. Notre article sur les réglementations et certifications en matière d'IA en Allemagne et en Europe cartographie en détail l'architecture réglementaire.

Les processus à haute sensibilité nécessitent des humains dans la boucle

Médical, juridique, financier, RH, éducation, secteur public. Dans ces domaines, les faux négatifs exposent des données et les faux positifs suppriment le contexte dont les relecteurs ont besoin pour prendre des décisions. Privacy Filter est une entrée dans un processus de révision dans ces environnements, et non un substitut à ce processus.

Notre règle : Privacy Filter s'intègre dans une architecture comprenant au moins une autre vérification en aval. S'il constitue la seule couche, vous êtes à une mise à jour de modèle d'une régression que personne ne détectera.

Évolution de notre position sur les agents exposés au web ouvert

Début du mois, nous avons publié une position : webvise ne déploie pas d'agents IA qui lisent le web ouvert pour ses clients. La raison était concrète. Les entrées contrôlées par des attaquants (une page scrapée, une URL soumise par l'utilisateur, un flux tiers) transmettent à l'agent des données personnelles, des credentials ou des charges d'injection de prompts qui fuient vers des actions en aval.

openai/privacy-filter modifie partiellement ce calcul. Pour le volet fuite en entrée, exécuter un classificateur local au navigateur sur le contenu scrappé avant qu'il entre dans le contexte du prompt atténue deux schémas spécifiques : l'exposition de données sensibles et l'empoisonnement du contexte via des données personnelles intégrées.

Il ne traite pas le vecteur d'injection de prompts. Il n'empêche pas une page soigneusement conçue d'ordonner à l'agent d'envoyer par e-mail le contenu de sa mémoire. Il empêche en revanche cette page de faire entrer accidentellement l'adresse personnelle d'un client dans la fenêtre de contexte du modèle.

L'évolution de notre position : nous déploierons désormais des lecteurs web ouverts restreints pour les processus non sensibles (agrégation de données publiques, veille concurrentielle, études de marché) si Privacy Filter est intégré des deux côtés de l'appel au modèle. Nous ne les déploierons toujours pas pour des processus touchant aux dossiers clients, aux documents internes ou aux actions authentifiées sans un test red-team dédié au préalable.

Comment l'intégrer

Deux schémas courants, tous deux tirés directement de la fiche modèle. Le pipeline Python pour la suppression côté serveur :

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

Et le pipeline Transformers.js pour la suppression côté navigateur via 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" });`

Placez le pipeline navigateur dans un Web Worker afin que l'Inference ne bloque pas le thread principal. Mettez en cache les poids du modèle avec un service worker pour que la pénalité de première visite n'intervienne qu'une fois par invalidation de cache. Ajustez le point de fonctionnement en environnement de staging avec des données représentatives avant de toucher à la production. Le dépôt officiel contient la fiche modèle complète, un espace de démonstration et les instructions de Fine-Tuning.

La publication de privacy-filter par OpenAI n'est pas un modèle. C'est une thèse sur la direction que prend le secteur : des classificateurs à vocation spécifique, exécutables dans le navigateur, sous licence Apache 2.0, fonctionnant aux frontières de votre architecture pour filtrer ce que vos LLM voient et ce qu'ils retournent. C'est la forme du travail de conformité que nous réalisons chez webvise, et c'est la forme de la couche de gouvernance qui manque à la plupart des agents aujourd'hui.

Si votre architecture d'agents ne dispose pas d'une couche de minimisation des données, cette publication est celle sur laquelle construire cette couche. Si vous souhaitez de l'aide pour l'intégrer dans quelque chose sur lequel vos clients peuvent réellement s'appuyer en production, webvise s'en charge.