Des auteurs testent sur 8 exemples ce qui reste dans un texte masqué avant son envoi à un LLM
Habr publie une analyse sur la façon de vérifier le masquage des données personnelles avant l'envoi d'un texte à un LLM. L'idée de départ : masquer nom, prénom et patronyme ne suffit pas, car un numéro permettant de retrouver la personne dans un registre public peut rester à proximité. Les auteurs prennent huit exemples artificiels, comparent le résultat à une liste de résidus définie à l'avance, puis observent ce qui change lorsqu'on désactive la normalisation et la reconnaissance des noms. • Ils vérifient les résidus, et pas seulement les entités détectées. • Huit textes synthétiques, aucune donnée réelle. • Deux modules sont désactivés tour à tour : la normalisation et la reconnaissance des noms.
Traité par IA depuis Хабр: Машинное обучение ; édité par Hamidun News
Huit textes artificiels, une liste de « résidus » définie à l'avance et deux modules désactivables du pipeline : voilà les ingrédients d'une analyse publiée sur Habr à propos de la vérification du masquage des données personnelles avant l'envoi d'un texte à un LLM. Sa thèse de départ : supprimer le nom, le prénom et le patronyme ne suffit pas. Si un numéro présent dans un registre public subsiste à côté, il reste possible d'identifier la personne.
Pour l'instant, la publication n'est disponible que sous forme d'annonce. Ce qui suit présente ce qui y est annoncé et la logique de l'approche. Les résultats chiffrés du texte complet ne sont pas repris ici.
Le masque cache le nom, mais pas la personne
Le schéma habituel est le suivant. Avant toute requête vers un modèle externe, le texte passe par un masqueur. Celui-ci remplace les noms, les numéros de téléphone et les adresses par des espaces réservés comme [PERSON] ou [PHONE]. L'équipe considère ensuite que les données personnelles ont été supprimées.
Mais le nom n'est pas le seul élément qui identifie une personne. Un numéro d'entrepreneur individuel (IP), un INN, un numéro d'affaire judiciaire, une plaque d'immatriculation ou un numéro de contrat peuvent mener à un individu précis via des registres et des fichiers publics. Si le masqueur est configuré pour les noms et les téléphones, ces valeurs passent sans être touchées. Le modèle, le journal des requêtes et le fournisseur tiers reçoivent alors des données formellement « anonymisées », mais qui ne le sont pas dans les faits.
Les auteurs proposent de changer de question. Plutôt que de demander ce que le masqueur a trouvé, ils vérifient ce qui reste dans le texte après son passage.
Comment fonctionne la vérification
L'approche repose sur un jeu de données réduit, mais reproductible. Voici les paramètres de l'expérience, tels qu'ils figurent dans l'annonce :
- 8 exemples synthétiques, sans aucune donnée personnelle réelle dans l'échantillon ;
- une liste de résidus définie à l'avance : les valeurs qui ne doivent pas apparaître dans le texte de sortie ;
- la comparaison de la sortie du masqueur avec cette liste, c'est-à-dire une vérification sur le résultat réel, et non sur le rapport du détecteur ;
- une expérience avec la normalisation désactivée ;
- une expérience avec la reconnaissance des noms désactivée.
Les deux derniers modes ne sont pas choisis au hasard. La normalisation ramène le texte à une forme unique : elle supprime les espaces et les tirets superflus dans les numéros, uniformise la casse et réduit les différentes graphies d'une même valeur à une seule. Sans elle, une règle ou un dictionnaire peut laisser passer un numéro écrit légèrement différemment du modèle attendu. La reconnaissance des noms prend en charge les identités absentes des dictionnaires, ainsi que les déclinaisons et les formes d'écriture comme « Иванову А. П. ». Désactiver l'un de ces modules permet de voir quelle part de la protection il assurait. Les chiffres de l'analyse complète indiqueront laquelle.
Les limites de la méthode
Huit exemples conviennent comme démonstration et comme test de régression, mais pas comme benchmark. Un tel échantillon ne permet pas de juger du rappel et de la précision d'un masqueur sur un flux réel. Les données synthétiques sont généralement plus propres que les données réelles : on y trouve moins de fautes de frappe, de bruit issu de l'OCR, de fragments de transcriptions d'appels et de mélanges de langues. La liste définie à l'avance limite aussi la vérification : elle ne détectera que ce qu'on y a inscrit. Un identifiant inattendu, auquel l'équipe n'a pas pensé, passera inaperçu.
L'approche a aussi un point fort. Elle transforme le vague « nous masquons les données » en une affirmation vérifiable, avec une liste précise et un résultat précis.
Comment l'appliquer chez soi
Pour transposer l'idée à votre projet, cinq étapes sont nécessaires :
- dressez la liste des identifiants qui, dans votre domaine, mènent à une personne via des sources ouvertes, sans vous limiter aux noms et aux téléphones ;
- constituez un corpus synthétique contenant différents formats d'écriture d'un même numéro ;
- exécutez le pipeline en mode complet, puis avec les modules désactivés un à un, afin de mesurer la contribution de chacun ;
- intégrez la vérification des résidus à la CI, pour que toute modification des règles ou tout changement de modèle de reconnaissance y soit soumis ;
- ajoutez régulièrement au corpus des exemples issus de défaillances réelles, anonymisés dans leur structure.
Le masquage reste une mesure d'ingénierie, et non un avis juridique. La question de savoir s'il suffit pour satisfaire aux exigences de la loi sur les données personnelles se tranche séparément. Mais sans vérification des résidus, même un masqueur correctement configuré reste une hypothèse non vérifiée.
Access Frontier LLMs & Multimodal AI in One Workspace
Discover NomadNet AI (nomadnet.ai) — unified access to frontier language models, research synthesis, and multimodal workflows.
L'essentiel de l'IA — une fois par semaine
Sept actus qui ont vraiment compté, choisies à la main. Sans bruit ni communiqués.
C'est fait ! Vérifiez votre boîte mail pour la confirmation.