Le 21 avril 2026, OpenAI a discrètement publié quelque chose appelé Privacy Filter. C'est un modèle mixture-of-experts de 1,5 milliard de paramètres qui détecte les informations personnellement identifiables dans le texte et les caviarde. Il fonctionne localement. Il est sous Apache 2.0. Il atteint 96 % de F1 sur le benchmark standard de masquage de PII. Le modèle entier, poids compris, est sur Hugging Face et GitHub pour que quiconque l'utilise.

Je veux parler de ce que cette publication signifie, et pourquoi nous l'ajoutons au pipeline d'Ostler cette semaine.

Ce qu'est réellement la chose

Le modèle est petit selon les standards des modèles de pointe. 1,5 milliard de paramètres au total, seulement 50 millions actifs au moment de l'inférence grâce au design mixture-of-experts. Fenêtre de contexte de 128k, ce qui est généreux pour une tâche qui opère habituellement sur de courtes chaînes. C'est un classificateur de tokens bidirectionnel avec décodage de spans, ce qui est la bonne architecture pour ce travail – il marque le début et la fin de chaque span privé dans le texte plutôt que de réécrire toute la chaîne en espérant.

Huit catégories prêtes à l'emploi : personne privée, adresse privée, e-mail privé, téléphone privé, URL privée, date privée, numéro de compte et secret générique. Affinable avec de petites quantités de données spécifiques au domaine, faisant passer le F1, paraît-il, d'environ 54 % à 96 % sans grand effort.

Sur un Mac grand public, cette chose est presque gratuite à exécuter. 50 millions de paramètres actifs, c'est moins de RAM qu'un onglet de navigateur. Vous pouvez nettoyer une charge utile de 10 000 caractères avant qu'une requête web ne finisse de charger.

Pourquoi le fait qu'OpenAI le publie compte

Mettez le produit de côté une minute. Le signal stratégique ici est fort.

L'activité commerciale d'OpenAI repose sur le fait que vous leur envoyiez votre texte. C'est l'économie unitaire. Chaque appel d'API est un revenu. Si la détection de PII devait se faire à leur périphérie, sur leurs serveurs, dans leur cloud, c'est là qu'ils l'auraient construite – et ils vous auraient facturé au token pour le privilège.

Ils ne l'ont pas fait. Ils l'ont publié à poids ouverts, sous licence permissive, conçu pour fonctionner sur votre propre machine, avec une documentation explicite disant ceci sert à désidentifier les données avant qu'elles ne quittent l'appareil.

Quand la plus grande entreprise d'IA cloud de la planète vous livre un modèle spécifiquement conçu pour empêcher vos données d'atteindre les entreprises d'IA cloud, soyez attentif. Ils vous disent où ils pensent que va le secteur.

C'est la même thèse que Karpathy a articulée chez Dwarkesh le 17 octobre 2025. De petits modèles, étroitement spécialisés, fonctionnant localement, battent les gros modèles qui font tout. Six mois plus tard, OpenAI a publié un exemple concret de ce schéma. Et quelques jours après, un article relu par les pairs de l'Université de Nanjing et de ByteDance ("PersonaVLM", arXiv:2604.13074) est paru avec le même argument architectural et un benchmark à l'appui – un raisonneur de 7 milliards de paramètres avec une mémoire personnalisée curatée battant GPT-4o de 5,2 % sur les tâches de personnalisation à long terme. Trois soutiens indépendants – un chercheur en octobre, un labo de pointe et une équipe académique en avril – pour le pari que nous avions déjà fait.

Ce que nous en faisons

Ostler a toujours été local-first. Vos données ne quittent pas votre Mac à moins que vous ne le demandiez explicitement, et même là, elles transitent par un visualiseur de charge utile qui vous montre chaque scalaire avant qu'il ne soit envoyé.

Privacy Filter s'insère comme une ceinture supplémentaire par-dessus les bretelles. Nous l'intégrons à trois endroits.

Un : l'ingestion. Quand Ostler importe un export RGPD, ou lit votre historique de navigation, ou extrait des faits d'une conversation enregistrée, il existe des cas limites où des noms de tiers se glissent dans des endroits que l'utilisateur n'attendait pas. Faire passer Privacy Filter sur les faits extraits nous permet de signaler "cette note mentionne quelqu'un qui n'est pas encore dans votre graphe, voulez-vous stocker ses coordonnées ?" au lieu de les indexer en silence. C'est une question de consentement de l'utilisateur qu'Ostler est désormais en position de poser.

Deux : le bundle de diagnostic Doctor. Quand quelque chose casse et que vous nous envoyez un bundle de support, nous le nettoyons déjà. Aujourd'hui, c'est une liste d'autorisation entretenue à la main de types scalaires acceptables. Demain, c'est la liste d'autorisation plus Privacy Filter passant sur chaque chaîne du bundle avant compression. Tout ce que le modèle signale est caviardé et vous est montré dans une vue avant-après. Vous approuvez l'envoi, ou vous l'annulez. Rien ne part sans votre œil dessus.

Trois : le routage cloud, si et quand. Ostler ne route actuellement aucune requête vers des LLM cloud. À un moment, nous pourrions ajouter un chemin opt-in pour les requêtes manifestement publiques – "en quelle année le mur de Berlin est-il tombé" – où un modèle cloud donne une meilleure réponse et aucune donnée personnelle n'est en jeu. Privacy Filter devient le portail de pré-vol. S'il détecte quoi que ce soit de privé dans la requête, la route est avortée, la requête s'exécute localement, et on vous montre pourquoi. Aucune fuite silencieuse.

Le travail d'ingénierie n'est pas énorme. Le document de cadrage d'intégration que j'ai rédigé cette semaine situe la Phase 1 à moins de trois jours-ingénieur. Le plus gros travail est l'interface autour – le visualiseur avant-après, les flux de consentement, la piste d'audit – car c'est là que la confiance des utilisateurs se gagne réellement.

L'argument de la ceinture et des bretelles

Privacy Filter n'est pas une solution miracle. 96 % de F1 signifie que 4 % des PII passent quelque part au travers, ce qui, sur une échelle de temps suffisamment longue, est un véritable mode de défaillance. Nous ne remplaçons pas nos contrôles existants par lui. Nous l'empilons par-dessus.

L'architecture est ainsi : la liste d'autorisation d'abord, le modèle ensuite, les yeux de l'utilisateur en troisième. La défaillance de l'une quelconque de ces couches ne fait pas fuir vos données. La liste d'autorisation rejette tout ce qui ne correspond pas à un schéma sûr connu. Le modèle signale les PII en langage naturel que la liste d'autorisation ne peut pas raisonner. Le visualiseur vous montre la charge utile finale avant qu'elle ne quitte la machine. Trois défaillances doivent s'empiler pour qu'une fuite se produise, et la troisième, c'est vous qui cliquez sur "envoyer" sur quelque chose que vous pouvez lire.

C'est un modèle de confiance différent de "on jure craché que notre cloud est sécurisé". La question intéressante n'est pas de savoir si nos couches sont parfaites. C'est de savoir si nos couches plus votre attention sont plus dignes de confiance que le serveur de quelqu'un d'autre plus sa politique de confidentialité. Je pense qu'elles le sont à l'évidence. J'ai construit Ostler sur cette conviction.

Ce que cela dit des douze prochains mois

Les modèles spécialistes à poids ouverts vont inonder le marché au cours de l'année à venir. Privacy Filter en est un. Il y aura de petits modèles locaux pour l'analyse de code, pour la classification de documents, pour le caviardage médical, pour la transcription accessible. Chacun d'eux est une brique d'infrastructure qu'un produit local-first peut composer dans son pipeline pour à peu près le coût de la RAM qui les contient.

L'écart entre "IA locale" et "IA cloud" était autrefois un écart de capacité. Il devient un écart d'assemblage. Qui a le meilleur pipeline de petits modèles locaux, composables, faisant vraiment bien des travaux étroits ? Pas qui a le plus gros modèle unique.

Nous avons une longueur d'avance sur ce pipeline. OpenAI vient d'y ajouter une bonne pièce gratuitement.

Réflexions, questions ou corrections sur la conception du pipeline – [email protected].