Outils PII en anglais uniquement : la faille RGPD
Le RGPD n'a pas de préférence linguistique
Le RGPD couvre les données personnelles dans n'importe quelle langue. Allemand, français, polonais, suédois — tous sont couverts également. Un Steuer-ID manqué crée le même risque juridique qu'un numéro de sécurité sociale manqué. La loi ne fait pas de distinction selon la langue.
La plupart des outils de détection PII, si.
Les principaux outils commerciaux et open source ont été conçus pour le texte anglais. Leurs modules de détection le reflètent. Ils couvrent bien les numéros de sécurité sociale américains, les permis de conduire américains et les formats téléphoniques NANP. Les modules pour les identifiants nationaux non anglais sont moins précis. Ils sont moins bien maintenus. Ils manquent plus souvent les vrais identifiants.
Pour les entreprises dans les États membres de l'UE, cela crée une lacune de couverture. L'outil indique que la détection est complète. Mais les identifiants non anglais restent dans les données. Ce sont souvent les identifiants exposant le plus au RGPD dans certains pays.
Les autorités de protection des données le constatent. Les auditeurs le recherchent. Un outil peut fonctionner bien sur des enregistrements anglais. Mais s'il échoue sur des enregistrements allemands ou français, il n'est pas conforme. Un rapport propre n'y change rien.
Les identifiants nationaux diffèrent dans leur structure
L'écart entre les outils centrés sur l'anglais et les outils multilingues ne concerne pas l'ajout de plus de motifs regex. Les identifiants nationaux de l'UE sont très différents les uns des autres. Ils nécessitent une logique propre à chaque pays pour être détectés correctement.
German Steuer-Identifikationsnummer (Steuer-ID) : 11 chiffres. Il utilise une somme de contrôle basée sur une variante de la formule de Luhn. Un regex SSN générique ne correspondra pas. Un regex pour n'importe quel nombre à 11 chiffres crée trop de faux positifs dans les documents allemands.
French NIR (Numéro d'inscription au répertoire) : 15 chiffres. Le format encode le sexe, l'année de naissance, le mois de naissance et le département de naissance. Il inclut aussi l'ordre de naissance et une clé de contrôle à 2 chiffres. La clé de contrôle doit être validée pour une détection correcte.
Swedish Personnummer : 10 chiffres avec un chiffre de contrôle Luhn. Les personnes nées avant 1990 utilisent un séparateur + au lieu de -. Cela change le format à détecter.
Polish PESEL : 11 chiffres. Il encode la date de naissance, le sexe et un chiffre de contrôle basé sur des sommes pondérées. Une détection correcte nécessite à la fois la correspondance de format et la validation de somme de contrôle.
Ce ne sont pas des variantes d'un pattern commun. Chacun a une longueur différente. Chacun utilise une méthode de vérification différente. Chacun encode les données dans un schéma de position différent. Un modèle NER entraîné en anglais qui voit un NIR français ne le reconnaîtra pas comme identifiant national. Il l'ignorera ou le classifiera mal.
Le risque pratique de conformité
Considérez un responsable conformité dans un BPO européen. Il traite simultanément des données d'Allemagne, de France, de Pologne et des Pays-Bas. Son outil signale une anonymisation PII réussie.
Mais le résultat n'est pas complet. Les Steuer-IDs dans les enregistrements allemands demeurent. Les numéros NIR dans les enregistrements français demeurent. Les numéros PESEL dans les enregistrements polonais demeurent. Les modules de l'outil pour ces formats sont absents ou trop imprécis.
Plus tard, le jeu de données va vers l'analyse ou un partenaire de recherche. Les données contiennent toujours des identifiants nationaux re-identifiables. Le problème RGPD n'apparaît pas dans les journaux de sortie de l'outil. Il surgit lorsqu'une demande d'accès d'une personne concernée arrive. Il peut apparaître lors d'un audit d'une autorité de protection des données. Il peut surgir après une violation de données.
Les recherches comparant des approches hybrides multilingues aux outils centrés sur l'anglais ont trouvé des résultats clairs. Les méthodes hybrides atteignent des scores F1 de 0,60 à 0,83 sur les locales européennes. Les outils uniquement anglais obtiennent un score proche de zéro pour les formats d'identifiants nationaux non anglais.
Consultez notre présentation de la conformité RGPD pour voir comment ces lacunes s'appliquent aux obligations RGPD.
Ce que nécessite une couverture complète
La vraie détection PII multilingue pour la conformité RGPD de l'UE nécessite trois couches.
Les modèles spaCy natifs par langue fournissent une compréhension sémantique dans la langue du texte. Un modèle entraîné sur du texte allemand sait que « Müller » est un nom de famille allemand courant. Des modèles existent pour 25 langues européennes à hautes ressources.
Les modèles NLP Stanza étendent la couverture aux langues non incluses dans spaCy. Cela ajoute une portée pour d'autres communautés linguistiques de l'UE.
Les modèles transformeurs multilingues (XLM-RoBERTa) traitent les cas translinguistiques. Un nom dans une phrase française est reconnu comme un nom de personne. Cela fonctionne même si le moteur n'a pas été entraîné sur ce nom spécifique.
Le regex avec validation spécifique au pays couvre les identifiants nationaux structurés. Steuer-ID, NIR, PESEL et Personnummer ont chacun besoin de leur propre logique de somme de contrôle. Cela réduit les faux positifs. Les séquences de chiffres qui échouent aux règles de validation du pays sont filtrées.
La lacune est structurelle. Ajouter des listes de mots ou plus de motifs regex n'apporte qu'une amélioration mineure. Intégrer la couverture des identifiants de l'UE dès le départ est la seule approche fiable.
Vérifiez votre outil actuel
Demandez à votre fournisseur des scores F1 pour les enregistrements allemands, français, polonais et néerlandais. « Supporte plusieurs langues » signifie souvent que l'outil utilise d'abord la traduction. Ce n'est pas un scanning natif. La conformité RGPD exige un scanning natif.
Testez avec de vrais exemples d'identifiants nationaux. Créez un jeu de test court avec 10 exemples de chaque type d'ID dans vos opérations. Steuer-ID, NIR, PESEL, Personnummer. Vérifiez les taux de détection. C'est plus rapide qu'un test F1 complet et révèle rapidement les lacunes.
Consultez notre page sécurité et conformité pour savoir comment anonym.legal répond à ces exigences. Pour les définitions de types d'entités, visitez la référence des entités.