Le 22 avril 2026, OpenAI a publié Privacy Filter sous licence Apache 2.0 sur GitHub et Hugging Face.
Le modèle pèse 1,5 milliard de paramètres totaux, 50 millions actifs, et caviarde huit catégories de données personnelles avant qu’elles ne quittent une machine locale.
Pour les DPO et CTO français qui intègrent ChatGPT, Claude ou Gemini dans un pipeline interne, l’arrivée de Privacy Filter pose une question concrète : qu’est-ce que cela change dans l’arbitrage RGPD post-Schrems II, comment l’intégrer dans un pipeline RAG existant, comment le situer face à Microsoft Presidio et OpenMed, et où sont les limites que personne n’évoque ?
Cet article répond aux quatre questions, sans hype.
En bref
- Privacy Filter masque huit catégories de PII en local : 1,5 Md de paramètres totaux, 50 M actifs, F1 96 % sur PII-Masking-300k, licence Apache 2.0
- l’outil aide à respecter l’Article 5 RGPD : il minimise les données envoyées au cloud sans remplacer ni le DPA Article 46, ni l’EIPD Article 35
- aucun support natif des formats français : NSS, SIRET et IBAN FR ne sont pas reconnus sans fine-tuning ciblé
- mosaic effect et side-channel persistent : même payload caviardé, les logs, la télémétrie et les quasi-identifiants fuient
- tester sur un échantillon métier avant tout passage en production reste la seule méthode honnête de qualification
Le problème RGPD que Privacy Filter prétend résoudre
Depuis l’arrêt Schrems II de la CJUE en 2020, tout transfert de données personnelles vers un sous-traitant américain reste exposé au FISA 702 qui autorise les agences fédérales à requérir l’accès aux données traitées par un fournisseur soumis au droit américain.
Le Data Privacy Framework EU-US signé en 2023 a fragilement rétabli un cadre de transfert, et la jurisprudence reste attentive aux failles techniques restantes.
En janvier 2026, la CNIL a infligé 27 millions d’euros à Free pour défaut de minimisation des données collectées.
Le message est clair : un responsable de traitement qui envoie en clair des prénoms, adresses, numéros de compte ou identifiants vers un endpoint OpenAI, Anthropic ou Google s’expose à un double risque, contractuel et juridique.
Privacy Filter attaque ce point précis : caviarder localement les données sensibles avant qu’elles ne quittent la machine ou le navigateur de l’utilisateur.
L’analogie tient en une phrase : Privacy Filter joue le rôle du caviardage automatique au crayon noir avant l’envoi d’un dossier à un cabinet de conseil étranger.
Ce caviardage relève de l’Article 5 RGPD sur la minimisation, pas d’une promesse d’anonymisation totale au sens de l’Article 4(5).
L’écart sémantique est concret : la pseudonymisation reste réversible, l’anonymisation non, et les guidelines CEPD 01/2025 insistent sur cette distinction quand un quasi-identifiant subsiste dans le texte filtré.
Ce que Privacy Filter fait techniquement
Privacy Filter est un classifieur bidirectionnel par token, dérivé de l’architecture gpt-oss mais privé de sa tête de génération autorégressive.
Le modèle pèse 1,5 milliard de paramètres totaux dont seulement 50 millions sont actifs par token, grâce à un mélange d’experts (MoE) de 128 experts avec routage top-4.
L’image qui aide : un standard téléphonique avec 128 opérateurs spécialisés, dont seuls quatre sont mobilisés par appel, ce qui maintient la facture compute basse.
L’architecture intègre 8 blocs transformeur, une attention grouped-query avec 14 têtes de requête et 2 têtes KV, un encodage RoPE, et une fenêtre de contexte de 128 000 tokens.
La sortie ressemble à du tagging : pour chaque token, le modèle prédit une étiquette parmi 33 classes BIOES couvrant huit catégories de PII.
Les huit catégories sont private_person, private_address, private_email, private_phone, private_url, private_date, account_number et secret.
Le modèle atteint un F1 de 96 % sur le benchmark PII-Masking-300k, et 97,43 % sur la version corrigée des artefacts d’annotation, avec un débit supérieur à 1 500 tokens par seconde sur GPU consumer.
La licence est Apache 2.0, sans clause de non-commercialisation, et les dépôts publics sont github.com/openai/privacy-filter et huggingface.co/openai/privacy-filter.
Le modèle est suffisamment compact pour rester inspectable sur poste de travail, et c’est précisément cette inspectabilité qui distingue un outil de minimisation d’une boîte noire de conformité.

Intégrer Privacy Filter dans un pipeline RAG
L’intégration suit la logique d’un pipeline RAG sécurisé classique, à un détail près : Privacy Filter s’insère en amont des embeddings et de tout appel sortant.
L’image opérationnelle : passer chaque document par un détecteur de métaux avant de le glisser dans la valise diplomatique cloud.
Architecture cible
Le flux recommandé tient en cinq étages : texte brut, filtrage local par Privacy Filter, embeddings, vector store, reranker, et seulement ensuite l’appel au LLM cloud.
Cette séquence garantit que le payload caviardé est ce qui sert à indexer le corpus, pas l’original.
Sur la sortie de génération, un second passage de Privacy Filter reste utile si le modèle cloud reformule des segments d’un document avec leurs identifiants source.
Le code Python pour brancher LangChain ou LlamaIndex
L’API transformers charge openai/privacy-filter en AutoModelForTokenClassification, expose un pipeline token-classification, et renvoie les spans détectées avec leurs offsets.
Une fonction redact_pii(text) remplace chaque span par un placeholder typé du genre [PERSON_1], [EMAIL_2], [ACCOUNT_3], et conserve le mapping en mémoire pour la dépseudonymisation après réponse.
Cette fonction se branche en amont d’un LLMChain LangChain ou d’un QueryEngine LlamaIndex sans modifier le reste de la chaîne.
Latence ajoutée
Sur GPU consumer en FP16, l’overhead mesuré par OpenAI tourne autour de 50 à 100 millisecondes par requête courte et reste sous la seconde sur des documents de plusieurs pages.
Sur CPU FP32 sans accélérateur dédié, comptez 0,5 à 2 secondes selon la longueur du payload, ce qui reste acceptable pour des workloads back-office mais discutable pour un chatbot temps réel.
Une variante INT8 quantifiée via bitsandbytes ou onnxruntime ramène la latence CPU sous 500 ms au prix d’un léger recul sur le rappel.
Bench rapide vs Microsoft Presidio et OpenMed
Les blogs FR opposent souvent Privacy Filter à Microsoft Presidio comme s’ils faisaient le même métier ; c’est faux.
L’analogie utile : un couteau suisse Apache 2.0 face à une caisse à outils modulaire ; l’un sort de la boîte, l’autre se configure pour les vis françaises.
Ce que fait Presidio
Presidio est un framework open-source maintenu par Microsoft, articulé autour d’un analyzer et d’un anonymizer.
L’analyzer combine un modèle NER (spaCy), des expressions régulières par recognizer, des règles métier et des checksums (cartes de crédit, IBAN générique).
L’anonymizer applique ensuite des opérateurs de substitution, hash ou pseudonymisation Faker.
L’extensibilité est l’avantage clé : ajouter un recognizer NSS ou SIRET français reste faisable, à condition d’écrire le regex et de fournir la liste de validation.
Chiffres comparés
Sur la même tâche de masquage générique, Privacy Filter affiche 96 % de F1 hors fine-tuning, contre 0,60 à 0,85 pour Presidio selon le corpus et la configuration NER.
Sur des données cliniques anglaises, des études récentes mesurent Presidio à 0,51 de précision et 0,74 de rappel en configuration par défaut, et jusqu’à 0,85 de F1 après ajout de recognizers métier.
OpenMed, modèle médical communautaire orienté français, revendique de son côté 97,97 % de F1 avec 55 entités natives incluant NSS, IBAN FR et code fiscal.
Quand préférer chacun
Privacy Filter brille sur des corpus généralistes en anglais, longs documents, secrets et credentials d’API.
Presidio reste le choix par défaut quand l’équipe veut écrire ses propres recognizers et garder une dépendance Python familière.
OpenMed prend l’avantage dès que le corpus est français et que les entités NSS, SIRET, numéros de TVA ou identifiants administratifs dominent.
La règle simple : Privacy Filter pour minimiser un flux global, Presidio pour custom-fitter un cas, OpenMed pour les formats français natifs ; les trois peuvent vivre dans le même pipeline.
Limites honnêtes : ce qu’un PII detector LLM-based laisse passer
OpenAI le concède explicitement dans le model card : Privacy Filter est un outil de minimisation, pas une garantie d’anonymisation au sens du RGPD.
Faux négatifs contextuels multi-pages
Le modèle voit une fenêtre de 128 000 tokens, et la décision de masquage reste locale à un span : un identifiant indirect dispersé sur plusieurs pages peut survivre, surtout quand la référence implicite remplace le nom propre.
Le papier arxiv 2510.07551 documente ce type de faux négatif sur des transcripts d’audience où le sujet est nommé page 1 puis remplacé par un pronom contextuel pendant 50 pages.
Identifiants propriétaires hors entraînement
Sans fine-tuning, Privacy Filter ne reconnaît pas les NSS français, le SIRET, les codes APE, les IBAN FR, ni les identifiants internes maison (matricules RH, numéros de dossier sectoriels).
Ces formats échappent aux huit catégories de base et exigent un fine-tuning sur 200 à 500 exemples étiquetés pour rejoindre un F1 acceptable.
Mosaic effect et quasi-identifiants
Caviarder le nom de Jean Dupont mais laisser sa date de naissance, son code postal et son employeur revient à le réidentifier en cinq secondes via LinkedIn et l’INSEE.
Ce mosaic effect est l’angle mort principal des PII detectors : la CEPD, dans ses guidelines 01/2025 sur la pseudonymisation, rappelle que l’Article 4(5) RGPD continue de s’appliquer tant qu’un quasi-identifiant subsiste.
Risques side-channel
Le payload caviardé peut être propre, et les logs applicatifs, la mémoire non purgée et la télémétrie produit fuir des PII en parallèle.
L’analyse Cribl 2026 sur les pipelines de télémétrie démontre que 40 % des fuites RGPD documentées dans les SaaS B2B passent par les logs et les traces APM, pas par le payload principal.
Image qui frappe : caviarder le courrier mais laisser le brouillon dans l’imprimante du couloir.

Coût TCO et arbitrages opérationnels
L’API cloud reste plus simple à comptabiliser que l’infrastructure locale, et l’écart de prix change l’équation à partir d’un certain volume.
Côté API, Gemini 1.5 Flash facture environ 3,13 dollars par million de tokens en entrée et GPT-4 Turbo autour de 20 dollars par million.
Côté local, Privacy Filter tourne sur une RTX 4060 à 1 500 tokens par seconde, soit environ 5,4 millions de tokens par heure sur une machine amortie en moins d’un an.
Le point de bascule TCO se situe entre le mois 6 et le mois 12 selon le volume traité, l’inflation cloud et le coût d’opération de l’infra locale (énergie, supervision, MAJ).
Une comparaison TCO honnête doit aussi comptabiliser le temps DPO consacré à documenter et auditer le pipeline interne, qui n’apparaît jamais sur la facture API.
L’arbitrage final dépend de trois variables : volume mensuel de tokens à filtrer, profil hardware disponible, et tolérance au risque side-channel côté cloud.
Un fondateur SaaS qui pousse 50 millions de tokens par mois vers OpenAI gagne mécaniquement à internaliser le filtre PII dès la deuxième année.
Une PME qui en pousse 5 millions reste à l’aise avec un filtrage cloud-side complété par un audit DPA OpenAI.
Le calcul TCO ne se résume pas au prix par million de tokens : il pèse aussi le coût d’un défaut de conformité, et la jurisprudence CNIL 2026 rappelle que ce coût se chiffre en pourcentage du chiffre d’affaires.
Ce que ça change dans l’EIPD ou la DPIA
Pour un DPO, l’arrivée de Privacy Filter ouvre une ligne nouvelle dans l’EIPD : la documentation d’une mesure technique de minimisation conforme à l’Article 5 RGPD.
Cette ligne ne supprime ni la mesure d’impact relatif au transfert (TIA) exigée par les guidelines CEPD post-Schrems II, ni le DPA contractuel signé avec OpenAI.
Elle réduit la surface de risque résiduel et renforce la défendabilité du dossier en cas de contrôle CNIL.
Concrètement, le DPO documente trois éléments : la version du modèle utilisée, le profil hardware d’inférence, et le taux de rappel mesuré sur un échantillon métier représentatif.
Le rappel mesuré sur un corpus interne reste plus parlant que le F1 publié sur PII-Masking-300k, car les formats français et les identifiants maison y sont représentés.
Un audit interne trimestriel sur 200 à 500 documents annotés à la main suffit à maintenir la traçabilité exigée par l’Article 35.
Pour les agences et SaaS qui revendent un service IA aux administrations françaises, ce dossier devient un atout commercial direct, au même titre que la certification SecNumCloud ou les contrôles HDS.
Un parallèle utile sur la gestion du risque concerne aussi la vie privée et IA dans Gmail, où la même grille s’applique à l’usage interne d’un assistant cloud.
Conclusion
Privacy Filter rejoint la trousse RGPD du DPO, sans devenir un sceau de conformité automatique.
Il aide à minimiser les données qui quittent le SI, sans supprimer ni le DPA OpenAI, ni la TIA Schrems II, ni la responsabilité de contrôleur.
Le bench face à Presidio et OpenMed clarifie son terrain de jeu : généraliste, multilingue, taillé pour les flux longs et les secrets de code.
Pour un fondateur SaaS qui prépare un déploiement IA en entreprise, l’arbitrage devient lisible : tester Privacy Filter sur un échantillon de cinquante documents sensibles métier, mesurer le rappel réel, documenter dans l’EIPD, puis basculer en production.
FAQ
Privacy Filter rend-il ChatGPT 100 % conforme au RGPD ?
Non, il minimise les données transférées vers le cloud et solidifie la défense d’un dossier RGPD, sans supprimer ni le DPA Article 46, ni l’EIPD Article 35, ni la TIA Schrems II.
Où placer Privacy Filter dans un pipeline RAG ?
Avant les embeddings et avant tout appel LLM cloud, avec un second passage optionnel sur la sortie de génération si le modèle reformule des segments avec leurs identifiants source.
Faut-il préférer Privacy Filter ou Microsoft Presidio en 2026 ?
Privacy Filter convient pour des flux globaux multilingues et longs documents, Presidio reste préférable quand l’équipe veut écrire ses propres recognizers métier ; les deux outils peuvent cohabiter dans le même pipeline.
Privacy Filter détecte-t-il les PII français comme NSS, SIRET ou IBAN FR ?
Pas sans fine-tuning ciblé : ces formats ne figurent pas dans les huit catégories de base et exigent 200 à 500 exemples étiquetés pour atteindre un F1 acceptable.
Quelle latence Privacy Filter ajoute-t-il à un appel LLM cloud ?
Environ 50 à 100 millisecondes sur GPU consumer FP16, 0,5 à 2 secondes sur CPU FP32, et sous 500 millisecondes en INT8 quantifié.
Que se passe-t-il si Privacy Filter rate une PII ?
Le responsable de traitement reste juridiquement responsable, le caviardage automatique étant une mesure de minimisation et non un transfert de responsabilité vers OpenAI.
Privacy Filter peut-il tourner dans un navigateur ou sur mobile ?
Oui, le modèle fonctionne via WebGPU dans un onglet Chromium grâce à Transformers.js, et un export ONNX rend possible l’inférence mobile à condition d’aligner le mapping mémoire.
Comment documenter Privacy Filter dans une EIPD ?
Le DPO consigne la version du modèle, le profil hardware d’inférence, le taux de rappel mesuré sur un corpus métier représentatif, et planifie un audit trimestriel sur 200 à 500 documents annotés.
Privacy Filter remplace-t-il l’anonymisation au sens du RGPD ?
Non, il pseudonymise au sens de l’Article 4(5) ; le risque de réidentification par mosaic effect persiste tant que des quasi-identifiants comme la date de naissance ou le code postal subsistent dans le texte.
Quel est le coût réel d’un déploiement local de Privacy Filter ?
Une RTX 4060 amortie sur dix-huit mois et un poste de supervision DPO suffisent pour un volume jusqu’à cinq millions de tokens par heure, avec un point de bascule TCO face à l’API cloud entre le mois 6 et le mois 12.
Articles Similaires
Hermes vs OpenClaw : apprendre ou orchestrer, deux visions de l’agent IA open-source
Depuis février 2026, deux projets open-source se disputent l’attention de la communauté agents IA : Hermes, le runtime auto-apprenant de Nous Research, et OpenClaw, le framework d’orchestration multi-canal adopté massivement…
GPT-5.5 : ce qui change vraiment (benchmarks officiels + retours terrain 24 h)
GPT-5.5 est sorti le 23 avril 2026. Point factuel à 24 h : benchmarks officiels, retours terrain de r/codex et Hacker News, ce qui change vraiment dans Codex et qui devrait upgrader.