Ceci est une traduction automatique du document original en anglais. En cas de divergence entre cette traduction et la version originale anglaise, la version anglaise fera foi. Consulter la version originale en anglais
Pseudonymiseur sur l'appareil : conçu et testé
2026-05-22 · Caiioo Team
Nous voulions résoudre le problème de confidentialité des systèmes d'IA qui s'entraînent sur des informations personnelles identifiables réelles et les conservent. Les politiques et accords de « rétention de données nulle » réduisent les risques, mais ils sont truffés d'exceptions. Ils disent essentiellement : « Nous ne stockerons aucune de vos requêtes ou sorties, sauf pour : (insérez ici une longue liste d'exceptions : des fins de sécurité, surveillance gouvernementale, conservations pour litige, développement de produits, journaux d'erreurs, amélioration des services...) »
Pour résoudre ce problème, nous avons construit un filtre de données personnelles qui s'exécute sur la propre machine de l'utilisateur, voit le message avant qu'il ne quitte l'appareil, et renvoie la même réponse que celle que l'utilisateur aurait reçue s'il avait tapé sans filtre du tout.
Nous en avons donc construit un. La prochaine version de Caiioo inclura le Pseudonymizer. Accessible via l'icône du bouclier dans le chat de l'agent ainsi que dans les paramètres.
Ce livre blanc expose la raison d'être, l'architecture, le processus d'évaluation et les principes de conception de notre système de filtrage de la confidentialité.
Ce que nous avons entrepris de faire
Protection générale de la vie privée par la minimisation des données. Lorsqu'un utilisateur discute avec un modèle distant, le modèle n'a pas besoin d'un nom réel, d'une adresse personnelle, d'un e-mail réel ou du numéro de téléphone d'un client pour répondre à la question de l'utilisateur. Il a besoin de la forme de la question, et celle-ci doit ressembler à une question réelle pour que l'LLM ne rejette pas la requête en la considérant comme un test. Le filtre supprime donc les identifiants réels des données envoyées à l'IA et réintègre les valeurs réelles au retour. Le modèle voit des noms et des identifiants synthétiques ; l'utilisateur voit la conversation réelle.
Assistance à la conformité HIPAA. Un second mode cible les 18 identifiants de la règle HIPAA Safe Harbor (§164.514) et la variante plus souple Limited Data Set. Un clinicien, un administrateur de santé ou toute personne travaillant sur un flux de travail couvert peut discuter de cas réels avec un modèle polyvalent sans envoyer d'informations de santé protégées (PHI) à l'IA. Nous ne sommes pas le responsable de la conformité de l'entité couverte — mais nous pouvons être la couche qui empêche les PHI de quitter l'ordinateur portable en premier lieu. Nos évaluations fournissent des points de référence mesurables que les organisations peuvent utiliser pour évaluer l'adéquation du filtre à leurs normes de conformité et de confidentialité. Toutes les mesures de confidentialité et de sécurité sont des décisions discrétionnaires qui relèvent de la responsabilité de l'utilisateur ou de l'entité utilisatrice.
Nous avons choisi les deux car l'ingénierie est la même, et le cas d'utilisation des PHI est en fait techniquement plus simple en raison de l'utilisation d'entités nommées distinctes, qui sont plus faciles à caviarder que les données plus générales de la catégorie Données Personnelles. Le filtrage HIPAA est également facilité par le fait qu'il est généralement en anglais ou en espagnol. Nous détectons les identifiants, substituons des pseudonymes stables et des identifiants de remplacement dans le même format, les restaurons au retour, et n'enregistrons jamais les valeurs réelles. La correspondance entre les informations synthétiques et les informations réelles reste uniquement sur l'appareil de l'utilisateur, afin que celui-ci puisse lire des informations réelles dans les réponses de l'agent. La liste des catégories et la barrière de politique sont les seuls éléments qui changent entre les modes.
Pourquoi le regex plus l'apprentissage automatique, et pas seulement l'un des deux
Il existe deux technologies de filtrage principales dans notre pseudonymiseur : un langage de reconnaissance de formes déterministe appelé regex, et des modèles d'apprentissage automatique (machine learning) entraînés.
Le regex est imbattable sur les formats de surface. Une adresse e-mail a une forme ([email protected]). Il en va de même pour une IP, une carte de crédit, un IBAN, un VIN, un SSN (XXX-XX-XXXX) ou une clé API. Si le format est fiable, le regex le capture de manière déterministe, à chaque fois, sans chargement de modèle et sans coût d'inférence.
Le regex est cependant impuissant face au contexte. « Le dossier de Sarah de mardi dernier » contient une personne et une date, mais aucune des deux ne peut être distinguée par son seul format. « Le patient au 14 Elm » contient une adresse qui ressemble à un millier d'autres éléments qui ne sont pas des adresses. « Leur MRN est le 7741032 » nécessite les mots entourant le nombre pour avoir une signification.
Un petit modèle de langage affiné gère le contexte — le nôtre est un encodeur de 110 millions de paramètres spécialement entraîné, distillé à partir d'un modèle de langage multilingue miniature —. Il lit la phrase, et non la sous-chaîne, et il est suffisamment petit pour s'exécuter extrêmement rapidement sur un appareil, même un téléphone mobile.
Les benchmarks illustrent les forces complémentaires des deux couches. Nous avons testé les deux couches de manière isolée pour nous assurer que chacune apporte réellement sa contribution. Sur l'ensemble de 150 questions PrivacyBench-PD, où les questions et réponses n'ont explicitement PAS été utilisées pour entraîner le modèle :
| Couche | PII capturées | Taux de capture |
|---|---|---|
| Regex uniquement | 205 / 670 | 30,6 % |
| ML uniquement | 516 / 670 | 77,0 % |
| Les deux (prod) | 625 / 670 | 93,3 % |
Le regex seul manque les trois quarts des identifiants car la plupart des identifiants dans la prose réelle ne sont pas structurés. Le ML seul manque 16 points de pourcentage que la couche regex aurait capturés — les éléments qui se définissent uniquement par leur forme (une carte de crédit ressemble à une carte de crédit ; le modèle n'a aucun signal supplémentaire à ajouter). Ensemble, ils couvrent ce qu'aucun ne couvre seul.
En examinant de plus près où chaque couche est décisive : sur ce même ensemble, 16 valeurs de test ont été capturées uniquement par regex (e-mails, IP, comptes financiers, identifiants structurés) et 327 ont été capturées uniquement par ML (noms, identifiants contextuels, formulations multilingues).
Petit, intelligent, rapide — et fonctionne partout
Nous devions faire fonctionner le filtre sur l'appareil, ce qui représentait un défi technique.
Il doit être petit car notre application s'exécute localement sur de nombreux systèmes : dans une extension de navigateur, une application macOS, une application iOS, une application Android, ou sur Windows et Linux. Le paquet pèse environ 113 Mo par modèle. Il existe deux modèles — un pour les données personnelles générales, un pour les informations de santé protégées — et le mode Safe Harbor exécute les deux en parallèle. Parmi ceux-ci, un appareil Android bas de gamme est le moins performant, et pourtant notre système fonctionne parfaitement.
Il doit être intelligent car les faux négatifs laissent fuiter des données réelles vers un LLM distant et les faux positifs gâchent la conversation. Les noms doivent être caviardés ; les pronoms ne doivent pas l'être. L'e-mail du médecin dans un fil de discussion transféré doit être masqué ; le pied de page [email protected] ne devrait probablement pas l'être.
Il doit être rapide car il se situe directement sur le chemin de chaque message que l'utilisateur envoie ou reçoit. Nous avons mesuré le surcoût de l'aller-retour à moins de 200 ms sur un seul thread CPU, principalement pour la tokenisation. Sur WebGPU et sur le Neural Engine d'Apple, c'est infime par rapport à la latence réseau de l'appel au LLM lui-même.
Il doit s'exécuter dans plusieurs environnements car Caiioo est multiplateforme. Le même système fonctionne dans les extensions Chrome, macOS et iOS, Android, ainsi que sur Windows et Linux. Un seul modèle de détection, une seule bibliothèque de regex, un seul fusionneur, une seule politique — un comportement identique sur chaque interface où Caiioo s'exécute.
Les scores
Après plusieurs cycles de tests et d'entraînement, nous avons retenu la 16ème version de nos modèles. Vous trouverez ci-dessous trois benchmarks, mesurant chacun un aspect différent.
Notre propre jeu de tests, 150 questions jamais vues par le modèle
Avant de tester par rapport aux benchmarks publics, nous avons passé notre filtre Personal Data sur un jeu de tests interne délibérément tenu à l'écart des données d'entraînement — ainsi, le détecteur n'a jamais vu aucune de ces questions auparavant. 150 questions réparties en quatre groupes (extraits de code, prose de documents, formulations intentionnellement inhabituelles et 10 langues non-anglaises), plus un groupe "négatif" ne contenant aucune donnée privée (un test de cohérence pour vérifier que nous ne sur-anonymisons pas). Pipeline combiné regex + ML :
| Sous-bench | Capturé | Taux |
|---|---|---|
| code_bench | 69 / 74 | 93,2 % |
| doc_bench | 233 / 247 | 94,3 % |
| generalization_bench | 123 / 133 | 92,5 % |
| multilingual_bench | 200 / 216 | 92,6 % |
| Total 4 benches positifs | 625 / 670 | 93,3 % |
(Le groupe négatif ne contenait aucune donnée privée à trouver. Le filtre a masqué un élément qu'il n'aurait pas dû — ce qui est cohérent avec les chiffres de précision plus bas.)
L'évaluateur est strict : chaque donnée privée attendue doit disparaître totalement de la sortie masquée pour que la question soit comptabilisée. Pas de crédit partiel, pas de "presque". C'est plus sévère que les benchmarks qui demandent à un autre LLM d'être le juge (les juges LLM ont tendance à être généreux). Pour des chiffres directement comparables avec d'autres systèmes, voir la section comparative plus bas.
PrivacyBenchHIPAA — 40 questions sur la santé
Chaque question liste des informations de santé protégées qui doivent être caviardées (noms, numéros de dossier médical, etc.) ET des signaux qui doivent être conservés (dates, géographie, âge si moins de 90 ans — la règle HIPAA Limited Data Set). L'évaluateur vérifie les deux aspects : avons-nous supprimé ce qui devait l'être, et avons-nous laissé intact ce qui devait l'être ?
| Mode | PHI caviardé | Éléments conservés |
|---|---|---|
| Limited Data Set (préserve dates / géo / âge ≤89) | 79 / 79 (100 %) | 34 / 34 |
| Safe Harbor (tout caviarder, y compris les dates) | 99 / 104 (95,2 %) | — |
Le sous-mode Limited Data Set est parfait sur ce benchmark. Le mode Safe Harbor — qui a plus d'éléments à caviarder, donc plus d'occasions d'en oublier — couvre 95,2 %.
Résultats par catégorie sur nos propres données, 200 échantillons par mode
Les benchmarks publics regroupent tout. Nos données de test internes ventilent les résultats par catégorie (noms, e-mails, adresses, etc.) et testent chacune de trois manières : regex uniquement, ML uniquement, et les deux ensemble. Cela nous indique exactement quelle technologie capture quel type d'identifiant — et où l'une a besoin de l'autre. Dernier test en date, 2026-05-20 :
Résumé sur les trois modes de filtrage
| Mode | Rappel combiné | Précision | F2 | Échantillons |
|---|---|---|---|---|
| Filtre Personal Data | 97,3 % | 97,8 % | 97,4 | 200 |
| Filtre HIPAA — Limited Data Set | 92,3 % | 92,3 % | 92,3 | 200 |
| Filtre HIPAA — Safe Harbor | 91,9 % | 91,5 % | 91,8 | 200 |
Ces chiffres excluent les URLs, que nous laissons délibérément intactes — supprimer une URL briserait les actions en aval comme "ouvrir ce lien" ou "récupérer cette page". Plus de détails dans la section sur le flux de travail ci-dessous.
Vue d'ensemble avant les tableaux par catégorie : dans chaque mode, les identifiants qui identifient réellement une personne sont capturés à 100 % ou presque. Noms, e-mails, numéros de téléphone, adresses postales, identifiants gouvernementaux, identifiants biométriques, géolocalisation précise, numéros de dossier médical, dates de naissance, numéros de sécurité sociale — capturés sur chaque échantillon, à chaque test. Les catégories où nous descendons sous les 100 % sont prévisibles : identifiants d'appareils (grande variété de formats dans le texte réel), identifiants institutionnels divers (numéros de fidélité, identifiants d'employés — même problème), et photos (un filtre textuel ne peut pas voir le contenu d'une image). Aucun de ceux-là n'est l'identifiant "nom sur un graphique" ou "e-mail dans un brouillon" qui compte réellement pour les fuites. Les catégories à enjeux élevés sont les plus fiables.
Filtre Personal Data
Trié par rappel combiné (le meilleur en premier), puis par niveau de risque (T1 = le plus sensible).
| Catégorie | Tier | Rappel Regex | Rappel ML (brut) | Rappel combiné | Gold n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| email_address | T1 | 100,0 % (20/20) | 100,0 % (20/20) | 100,0 % | 20 |
| government_id | T1 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| person_name | T1 | 13,3 % (4/30) | 96,7 % (29/30) | 100,0 % | 30 |
| phone_or_fax | T1 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| postal_address | T1 | 0,0 % (0/10) | 100,0 % (10/10) | 100,0 % | 10 |
| precise_geolocation | T1 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| birth_date | T2 | 0,0 % (0/10) | 100,0 % (10/10) | 100,0 % | 10 |
| ip_address | T2 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| online_handle | T2 | 40,0 % (4/10) | 100,0 % (10/10) | 100,0 % | 10 |
| vehicle_id | T2 | 50,0 % (5/10) | 100,0 % (10/10) | 100,0 % | 10 |
| authentication_secret | T4 | 40,0 % (4/10) | 100,0 % (10/10) | 100,0 % | 10 |
| financial_account | T1 | 90,0 % (18/20) | 100,0 % (20/20) | 90,0 % | 20 |
| institutional_id | T3 | 80,0 % (8/10) | 90,0 % (9/10) | 90,0 % | 10 |
| device_id | T3 | 40,0 % (4/10) | 50,0 % (5/10) | 80,0 % | 10 |
À la lecture, la conception à deux couches porte ses fruits. Les adresses postales, les dates de naissance et les noms de personnes affichent un score de 0 à 13 % avec les regex seules — il n'y a pas de structure fixe à faire correspondre, donc seul le modèle ML peut les capturer. Les e-mails, numéros de téléphone, IPs, identifiants gouvernementaux, identifiants biométriques et la géolocalisation précise affichent 100 % avec les regex seules — des formats de surface que le modèle ML obtient "gratuitement". Les pseudonymes en ligne, identifiants de véhicules et secrets d'authentification sont mixtes : les regex capturent les formes standards, le ML capture le reste. Le rappel combiné égale ou dépasse la couche individuelle la plus forte, dans chaque catégorie.
Les identifiants d'appareils et les identifiants institutionnels divers sont les catégories sous les 100 %, et nous savons pourquoi : ils présentent la plus grande variété de formats dans le texte réel. Nous préférons être honnêtes sur les catégories où le rappel fléchit plutôt que de prétendre que le filtre est parfait partout.
Filtre HIPAA — sous-mode Limited Data Set
Le sous-mode Limited Data Set préserve les dates, la géographie et les âges de 89 ans ou moins par conception — ce sont les signaux que HIPAA autorise une organisation à conserver pour la recherche clinique et les opérations légitimes.
| Catégorie | Tier | Rappel Regex | Rappel ML (brut) | Rappel combiné | Gold n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100,0 % (12/12) | 100,0 % (12/12) | 100,0 % | 12 |
| email_address | T1 | 100,0 % (13/13) | 100,0 % (13/13) | 100,0 % | 13 |
| medical_record_number | T1 | 100,0 % (26/26) | 100,0 % (26/26) | 100,0 % | 26 |
| person_name | T1 | 15,4 % (4/26) | 100,0 % (26/26) | 100,0 % | 26 |
| phone_or_fax | T1 | 100,0 % (13/13) | 100,0 % (13/13) | 100,0 % | 13 |
| social_security_number | T1 | 100,0 % (12/12) | 100,0 % (12/12) | 100,0 % | 12 |
| account_number | T2 | 0,0 % (0/13) | 100,0 % (13/13) | 100,0 % | 13 |
| health_plan_id | T2 | 0,0 % (0/13) | 100,0 % (13/13) | 100,0 % | 13 |
| ip_address | T2 | 100,0 % (12/12) | 100,0 % (12/12) | 100,0 % | 12 |
| license_number | T2 | 0,0 % (0/12) | 100,0 % (12/12) | 100,0 % | 12 |
| vehicle_id | T2 | 25,0 % (3/12) | 100,0 % (12/12) | 100,0 % | 12 |
| device_id | T3 | 41,7 % (5/12) | 100,0 % (12/12) | 100,0 % | 12 |
| photo | T2 | 0,0 % (0/12) | 0,0 % (0/12) | 0,0 % | 12 |
Les photos sont un échec connu — un filtre textuel ne peut pas voir ce qu'il y a dans une image. Les PHI dans les images sont un problème distinct que nous n'avons pas encore traité. Toutes les autres catégories de ce mode sont à 100 %.
Filtre HIPAA — sous-mode Safe Harbor
Safe Harbor supprime tout ce que le sous-mode Limited Data Set aurait conservé — dates, âges de plus de 89 ans, géographie. Pour obtenir la couverture la plus stricte, il exécute les deux modèles de filtrage en parallèle : celui spécifique à HIPAA et celui général pour les données personnelles.
| Catégorie | Tier | Rappel Regex | Rappel ML (brut) | Rappel combiné | Gold n |
|---|---|---|---|---|---|
| age_over_89 | T1 | 100,0 % (18/18) | 0,0 % (0/18) | 100,0 % | 18 |
| biometric_id | T1 | 100,0 % (9/9) | 100,0 % (9/9) | 100,0 % | 9 |
| email_address | T1 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| medical_record_number | T1 | 100,0 % (20/20) | 100,0 % (20/20) | 100,0 % | 20 |
| person_name | T1 | 20,0 % (4/20) | 100,0 % (20/20) | 100,0 % | 20 |
| phone_or_fax | T1 | 100,0 % (10/10) | 100,0 % (10/10) | 100,0 % | 10 |
| social_security_number | T1 | 90,0 % (9/10) | 100,0 % (10/10) | 100,0 % | 10 |
| account_number | T2 | 0,0 % (0/10) | 100,0 % (10/10) | 100,0 % | 10 |
| general_date | T2 | 100,0 % (27/27) | 29,6 % (8/27) | 100,0 % | 27 |
| health_plan_id | T2 | 0,0 % (0/10) | 100,0 % (10/10) | 100,0 % | 10 |
| ip_address | T2 | 100,0 % (9/9) | 100,0 % (9/9) | 100,0 % | 9 |
| license_number | T2 | 0,0 % (0/10) | 100,0 % (10/10) | 100,0 % | 10 |
| vehicle_id | T2 | 10,0 % (1/10) | 100,0 % (10/10) | 100,0 % | 10 |
| device_id | T3 | 22,2 % (2/9) | 88,9 % (8/9) | 77,8 % | 9 |
| photo | T2 | 0,0 % (0/9) | 0,0 % (0/9) | 0,0 % | 9 |
Les deux lignes intéressantes sont les dates générales (regex 100 %, ML 30 %) et les âges de plus de 89 ans (regex 100 %, ML 0 %). Nous laissons délibérément les regex gérer les deux dans Safe Harbor : les dates ont une structure que les regex capturent à chaque fois, et nous ne voulons pas qu'un modèle probabiliste remette en question un seuil numérique comme ">89". Une règle déterministe est plus fiable que de demander au modèle ML d'apprendre la même règle.
Chiffres globaux toutes catégories confondues
En additionnant tout : comment le pipeline complet (regex + ML ensemble) se compare-t-il à chaque couche seule ?
| Mode | Couches | Rappel | Précision | F2 |
|---|---|---|---|---|
| Personal Data | regex seule | 65,8 % | 93,0 % | 69,9 % |
| Personal Data | ML seul | 95,4 % | 92,4 % | 94,8 % |
| Personal Data | les deux | 96,9 % | 98,0 % | 97,1 % |
| Limited Data Set | regex seule | 55,9 % | 95,0 % | 60,9 % |
| Limited Data Set | ML seul | 92,9 % | 84,5 % | 91,0 % |
| Limited Data Set | les deux | 92,9 % | 89,3 % | 92,1 % |
| Safe Harbor | regex seule | 58,9 % | 93,6 % | 63,6 % |
| Safe Harbor | ML seul | 82,4 % | 88,3 % | 83,5 % |
| Safe Harbor | les deux | 92,4 % | 88,9 % | 91,7 % |
La ligne "les deux" du filtre Personal Data bat les versions à couche unique sur chaque métrique — la combinaison des regex (pour les formats de surface) avec le modèle ML (pour le contexte) apporte réellement quelque chose qu'aucune couche seule ne peut offrir. Le chiffre de 97,3 % cité plus haut dans ce post est celui qui reflète ce qu'un utilisateur réel obtient. Le chiffre dans le tableau ci-dessus est un peu plus bas uniquement parce qu'il inclut la catégorie URL, que nous préservons délibérément pour ne pas briser les liens et les appels d'outils.
Face-à-face avec d'autres filtres de confidentialité dédiés
La comparaison équitable pour un filtre de confidentialité sur l'appareil et quasi instantané comme le nôtre se fait par rapport à d'autres filtres de confidentialité sur l'appareil et quasi instantanés — pas par rapport à des LLM géants hébergés dans le cloud qui prennent des secondes par message et nécessitent un aller-retour réseau. Nous avons testé tous les systèmes de cette catégorie par rapport aux mêmes jeux de tests, en utilisant les mêmes règles de correspondance. Le même standard pour tout le monde.
La classe de référence :
- openai/privacy-filter — le filtre de confidentialité dédié open-source d'OpenAI. Environ 50 millions de paramètres, assez petit pour fonctionner dans n'importe quel navigateur moderne.
- piiranha-v1 — un détecteur de 278 millions de paramètres de iiiorg. Sa licence le restreint à la recherche et à l'évaluation uniquement (nous pouvons le mesurer, mais il ne peut pas être commercialisé).
- Microsoft Presidio — le caviardeur open-source le plus largement déployé, combinant la reconnaissance de formes traditionnelle avec un petit modèle de langage pour le contexte.
- Famille GLiNER PII — une famille de petits classificateurs d'entités à usage général. Knowledgator propose des variantes small (~44M), base (~86M) et large (~304M) ; NVIDIA a publié une variante de 570M en octobre 2025.
- Caiioo dans ses trois modes (Personal Data, HIPAA Limited Data Set, HIPAA Safe Harbor).
Rappel sur les cinq jeux de tests, trié avec Caiioo en premier :
| Système | PrivacyBench PD-25 | Caiioo synthétique PD-200 | PrivacyBenchHIPAA-40 | Caiioo synthétique PHI-200 | Multilingue PD-40 (10 locales) |
|---|---|---|---|---|---|
| Caiioo — Personal Data | 96,2 % (76/79) | 99,0 % (198/200) | — | — | 92,6 % (200/216) |
| Caiioo — HIPAA Limited Data Set | — | — | 100,0 % (79/79) | 100,0 % (200/200) | — |
| Caiioo — HIPAA Safe Harbor | — | — | 100,0 % (79/79) | 100,0 % (200/200) | — |
| openai/privacy-filter (50M) | 96,2 % (76/79) | 83,0 % (166/200) | 93,7 % (74/79) | 77,0 % (154/200) | 94,9 % (205/216) |
| gliner_pii_nvidia (570M) | 94,9 % (75/79) | 85,5 % (171/200) | 84,8 % (67/79) | 85,0 % (170/200) | 76,9 % (166/216) |
| gliner_pii_large (~304M) | 72,2 % (57/79) | 86,5 % (173/200) | 84,8 % (67/79) | 93,0 % (186/200) | 50,0 % (108/216) |
| gliner_pii_base (~86M) | 87,3 % (69/79) | 66,0 % (132/200) | 74,7 % (59/79) | 66,0 % (132/200) | 51,4 % (111/216) |
| gliner_pii_small (~44M) | 88,6 % (70/79) | 84,5 % (169/200) | 91,1 % (72/79) | 83,0 % (166/200) | 68,5 % (148/216) |
| Microsoft Presidio | 82,3 % (65/79) | 76,5 % (153/200) | 84,8 % (67/79) | 76,5 % (153/200) | 69,0 % (149/216) |
| piiranha-v1 (~278M) | 60,8 % (48/79) | 58,5 % (117/200) | 43,0 % (34/79) | 47,0 % (94/200) | 82,4 % (178/216) |
Caiioo mène la catégorie des filtres dédiés sur les deux tests les plus importants (PD-200 et PHI-200), égale ou mène sur les benchmarks publics, et arrive deuxième sur le multilingue. Sur le plus petit test (PrivacyBench PD-25, seulement 25 questions), Caiioo et openai/privacy-filter sont à égalité à 96,2 %. Sur le multilingue, openai/privacy-filter mène toujours à 94,9 % contre 92,6 % pour Caiioo — la langue où nous sommes le plus en retrait est le chinois ; partout ailleurs, nous sommes au sommet ou presque. Si la couverture multilingue est critique pour votre mission, openai/privacy-filter est une alternative raisonnable. Pour la plupart des autres charges de travail de cette catégorie, Caiioo l'est.
Le résultat HIPAA est le point fort. Les deux modes HIPAA de Caiioo atteignent 100 % de rappel sur chaque test HIPAA — chaque nom de patient, chaque numéro de dossier médical, chaque date de naissance, chaque numéro de compte est capturé. Le deuxième meilleur système est openai/privacy-filter avec 93,7 % sur PrivacyBenchHIPAA — un écart de 6,3 points, sur un benchmark où chaque oubli est une divulgation réelle.
Un second chiffre mérite d'être lu : la sur-anonymisation — masquer des éléments qui n'étaient pas réellement des données privées. La sur-anonymisation n'est pas un préjudice pour la confidentialité, c'est un coût pour l'utilisabilité. Masquez trop d'éléments et le raisonnement du LLM s'en trouve amoindri, et la réponse retournée est dégradée. Caiioo masque inutilement 1 à 24 fois selon les jeux de tests. Presidio : 10 à 51. Le GLiNER de NVIDIA : 31 à 64 sur les seuls tests HIPAA. La précision compte autant que le rappel lorsque l'objectif est d'obtenir la meilleure réponse possible avec le moins d'exposition possible.
Pourquoi ne pas simplement utiliser un LLM de pointe comme filtre ?
Ils peuvent le faire — et sur le rappel brut, ils gagnent. Les grands LLM polyvalents (Llama 3.1 8B, Gemma 4, Qwen 3.5 9B, et similaires), fonctionnant soit dans le cloud soit localement, peuvent obtenir des scores de 95 à 100 % sur tous les tests, y compris le multilingue. C'est une option réelle pour les utilisateurs qui ont besoin d'un rappel maximal et qui sont prêts à en payer le prix.
Les inconvénients sont cependant réels :
- C'est lent. Des secondes par message au lieu de millisecondes. Le filtre se place devant chaque message envoyé par l'utilisateur.
- Soit le message quitte la machine de l'utilisateur, soit le modèle le fait. Pour filtrer dans le cloud, le message doit y monter — ce qui va à l'encontre de l'objectif. Pour filtrer sur l'appareil, il faut télécharger un modèle de 1 à 17 Go.
- Il peut être trompé. Un modèle génératif peut être convaincu, en plein milieu d'un message, de ne pas caviarder (une attaque par "injection de prompt"). Un petit classificateur comme le nôtre ne le peut pas.
- Même entrée, sortie différente. Les modèles génératifs ne donnent pas toujours deux fois la même réponse. Cela brise l'aller-retour — le masquage à l'aller et le démasquage au retour reposent sur le fait que la même valeur réelle corresponde toujours au même faux.
Caiioo est conçu pour l'autre côté de ce compromis : un filtre minuscule, prévisible, de moins d'une seconde, qui s'exécute dans l'éditeur avant que l'utilisateur n'appuie sur envoyer, et qui produit toujours le même faux pour la même valeur réelle au sein d'une conversation, afin que l'aller-retour reste cohérent. Le tableau de comparaison ci-dessus est la comparaison directe pour ce type de cas d'utilisation.
La preuve par l'exemple
Les benchmarks sont un point de départ, pas une ligne d'arrivée. Le filtre est intégré à la nouvelle fonctionnalité de Caiioo : le pseudonymiseur — le composant qui se situe réellement entre le compositeur et le modèle.
Voici ce qui se passe lorsque l'utilisateur appuie sur envoyer.
- Détecter. La couche regex s'exécute en premier — elle est déterministe et rapide à la microseconde près. Le modèle ML s'exécute ensuite sur ce qu'il reste. Si les deux couches se chevauchent sur le même segment de texte, nous utilisons une règle simple : la regex l'emporte sur les formats de surface, le ML l'emporte sur le contexte.
- Étiqueter soi-même vs. autrui. Caiioo sépare les identifiants qui se réfèrent à l'utilisateur des identifiants qui se réfèrent à d'autres personnes. L'utilisateur peut choisir de biffer l'un, l'autre, ou les deux. Les noms que l'utilisateur a ajoutés à un dictionnaire personnel comptent toujours comme "soi-même".
- Substituer. Chaque valeur réelle reçoit un pseudonyme stable et adapté au style. "Sarah Goldberg" devient "Maya Hartwell" — et reste "Maya Hartwell" pendant toute la conversation, afin que le raisonnement du modèle sur cette personne ne se fragmente pas au fil des échanges. Une table de correspondance réel-vers-fictif est conservée sur l'appareil de l'utilisateur, chiffrée avec une clé provenant du trousseau d'accès de la plateforme.
- Envoyer. Le modèle reçoit un message entièrement factice. Aucun identifiant réel ne traverse jamais le réseau, et notre journal d'audit n'enregistre que des décomptes — jamais les valeurs elles-mêmes.
- Restaurer. La réponse en streaming est remappée à mesure qu'elle arrive. "Maya Hartwell" dans la réponse du modèle redevient "Sarah Goldberg" avant d'atteindre l'écran, affiché avec une petite pastille lumineuse pour que l'utilisateur puisse voir d'un coup d'œil ce qui a été protégé.
- Restaurer aussi les arguments des outils. Si le modèle appelle un outil — envoyer un e-mail, créer un ticket, écrire dans un document — et que les arguments contiennent des données factices, nous substituons les valeurs réelles avant l'exécution de l'outil. Le modèle raisonne sur du factice ; l'action utilise la valeur réelle.
Le filtre ne se soucie pas du service d'AI utilisé. Il s'exécute avant même que le message n'atteigne le modèle, de sorte que OpenRouter, Anthropic, Google, OpenAI et un Ollama local reçoivent tous la même charge utile masquée. L'ajout d'un nouveau fournisseur ne rouvre pas de faille de confidentialité.
Qui il protège
L'utilisateur. Le nom, l'e-mail, l'adresse, le téléphone, l'IP et les identifiants biométriques d'un utilisateur — les éléments qui, pris ensemble, identifient une personne pour un agrégateur — ne quittent jamais l'appareil lorsque le filtre est activé.
Les personnes dont l'utilisateur parle. La plupart des outils de confidentialité se concentrent sur la personne qui tape, mais ils ignorent le « contrat social » — le fait que nous avons tous une responsabilité envers les autres autant qu'envers nous-mêmes. Soumettre « Veuillez analyser la conduite de M. Saunders pour incompétence » à un LLM, où cela peut être enregistré indéfiniment dans les journaux du système, est irresponsable (et potentiellement diffamatoire). Demander de l'aide à un LLM pour une feuille Google Sheet contenant 1 000 contacts professionnels dépose tous ces contacts dans le piège de la rétention de données (à des degrés divers, selon la « rétention de données nulle » réellement en vigueur). Le filtre de Caiioo couvre également les tiers : le client pour lequel un contrat est rédigé, le patient dont le dossier est analysé, le collègue dont l'e-mail a été collé dans le contexte. Ils n'ont pas consenti à ce qu'un LLM distant voie leurs identifiants. Le filtre respecte cela par défaut ; l'utilisateur peut passer en mode « soi-même uniquement » ou « autres uniquement » si un flux de travail l'exige.
Les entités — entreprises, hôpitaux, cabinets. Numéros de compte, numéros de licence, numéros de dossier médical, détails de routage financier, identifiants internes, clés API, listes de clients. Une entreprise a le même intérêt à la minimisation des données qu'une personne physique. Un clinicien utilisant Caiioo pour rédiger une note de sortie n'envoie pas le numéro de dossier médical du patient à OpenAI. Un avocat n'envoie pas le numéro de compte du client à Anthropic. Un ingénieur support n'envoie pas la clé API du journal du client à Google. Le filtre ne se demande pas si l'identifiant appartient à une personne ou à une entité — il le garde simplement sur l'appareil.
Utilité maximale, exposition minimale
Tout l'intérêt est que l'utilisateur ne doive pas ressentir le filtre.
La plupart des outils de confidentialité imposent un choix : caviarder de manière agressive et voir la réponse du modèle se dégrader, ou garder la requête utilisable et voir la promesse de confidentialité s'éroder. Nous avons rejeté ce compromis. Le modèle reçoit toujours une requête complète — il voit un nom, un lieu, une date, un numéro de dossier médical, tous aux bonnes positions grammaticales. Il voit simplement des données factices. Son raisonnement est identique ; seules les chaînes de caractères sont nettoyées.
C'est la substitution stable qui permet cela. Comme une même valeur réelle correspond toujours à la même valeur factice au sein d'une conversation — à travers le message de l'utilisateur, le résultat de l'outil qui revient en faisant référence à ce nom, la réponse précédente du modèle qui l'évoquait — le modèle dispose d'une personne, d'un lieu ou d'un objet cohérent sur lequel raisonner. Les conversations à plusieurs tours ne sont pas brouillées. Les appels d'outils ne se cassent pas. Les sous-agents héritent de la cartographie de la conversation parente et restent cohérents sur l'ensemble de la tâche.
Le résultat que l'utilisateur voit est la conversation réelle. Les données que le fournisseur voit sont une fiction cohérente. Le travail se fait dans l'écart entre ces deux vues, et l'objectif — le seul objectif — est de rendre cet écart invisible.
Un filtre de confidentialité qui gêne finira par être désactivé. Un filtre de confidentialité qui se fond dans le flux de travail est le seul qui vaille la peine d'être déployé.
C'est l'exigence que nous nous sommes fixée.