Confidentialité Reproductible : Pourquoi les Équipes ML Ont Besoin de Préréglages de Configuration, Pas Juste de Documentation
Le DPO a approuvé le document de procédure d'anonymisation. Il spécifie : supprimer les noms, les e-mails, les numéros de téléphone et les dates de naissance des ensembles de données d'entraînement en utilisant la méthode Remplacer. Le document fait 4 pages et se trouve dans le wiki de conformité.
Douze scientifiques des données le consultent au lancement du projet. Ils configurent leurs propres versions de l'outil d'anonymisation. Certains ajoutent des identifiants nationaux. Certains incluent des adresses IP. Certains utilisent Rédiger au lieu de Remplacer. Trois mois plus tard, les ensembles de données d'entraînement sont incohérents.
La CNIL (DPA de France) a enquêté sur plusieurs entreprises d'IA en 2024 pour utilisation inappropriée des données personnelles dans les ensembles de données d'entraînement. Les enquêtes ont examiné non seulement si l'anonymisation avait eu lieu mais aussi comment elle avait été appliquée de manière cohérente.
La documentation est nécessaire. Ce n'est pas suffisant. La solution technique est le préréglage.
Pourquoi les Données d'Entraînement ML Nécessitent une Configuration Spécifique
L'anonymisation des données d'entraînement ML a des exigences que l'anonymisation de documents généraux n'a pas :
Remplacer, pas Rédiger : Les modèles de langage neuronaux entraînés sur du texte où les noms sont remplacés par des tokens [RÉDACTÉ] apprennent que [RÉDACTÉ] est un identifiant spécial apparaissant dans les positions de nom. Cela crée un comportement indésirable du modèle. La méthode Remplacer (substituant "John Smith" par "David Chen") préserve la distribution statistique des noms dans le texte tout en supprimant les informations identifiantes. Le modèle apprend à partir de distributions réalistes de positions de noms, pas d'un token masqué.
Cohérence à travers l'ensemble de données : Un ensemble de données d'entraînement où 70 % des noms sont remplacés et 30 % sont [RÉDACTÉ] produit un signal d'entraînement incohérent. Tous les enregistrements doivent être traités de manière identique.
Sélection d'entités cohérente : Si l'ensemble de données d'entraînement contient des données de santé, supprimer les noms mais pas les dates de naissance dans certains enregistrements crée une incohérence. Tous les 12 scientifiques des données doivent supprimer le même ensemble de types d'entités.
Pas de sur-anonymisation : La méthode Remplacer appliquée de manière excessive — supprimant des dates qui ne sont que des horodatages, pas des dates de naissance — dégrade l'utilité de l'ensemble de données sans améliorer la conformité. Le préréglage approuvé définit exactement quels types d'entités de date supprimer (date de naissance, pas des horodatages généraux).
Reproductibilité à travers les exécutions : Si le même ensemble de données doit être retraité (par exemple, après avoir détecté un type d'entité manqué), le retraitement avec le même préréglage produit une sortie cohérente. Les configurations ad hoc ne sont pas reproductibles.
Le Problème des 12 Scientifiques des Données
L'équipe ML d'une entreprise fintech européenne utilise un ensemble de données d'entraînement dérivé des journaux d'interaction client. Le DPO a approuvé le but de traitement (entraînement du modèle pour la détection de fraude) avec des conditions : tous les noms de clients, e-mails, numéros de téléphone et identifiants de paiement doivent être remplacés en utilisant la méthode Remplacer avant tout entraînement de modèle.
Sans préréglages :
- Le scientifique des données 1 supprime les noms, e-mails, numéros de téléphone (n'inclut pas les identifiants de paiement)
- Le scientifique des données 2 inclut les identifiants de paiement mais utilise Rédiger au lieu de Remplacer
- Le scientifique des données 3 suit exactement le document de procédure
- Les scientifiques des données 4-12 varient
Résultat : 12 versions traitées différemment des données d'entraînement. L'ensemble de données fusionné est partiellement non conforme, partiellement sur-anonymisé et statistiquement incohérent.
Avec le préréglage approuvé par le DPO :
- Le DPO crée le préréglage "Entraînement ML — Détection de Fraude" avec les types d'entités exacts et la méthode Remplacer
- Préréglage partagé avec les 12 scientifiques des données avec des instructions : "Utilisez ce préréglage pour toute préparation de données d'entraînement"
- Le préréglage ne peut pas être modifié sans révision du DPO (contrôle d'accès à la configuration)
Résultat : Tous les 12 scientifiques des données produisent une sortie d'anonymisation identique. L'ensemble de données fusionné est cohérent. L'audit annuel de conformité de l'IA passe sans constatations.
Année précédente : 3 constatations liées à l'anonymisation incohérente des données d'entraînement ML. Post-préréglage : 0 constatations.
Intersection de la Loi sur l'IA et du RGPD
La Loi sur l'IA de l'UE (en vigueur depuis août 2024) ajoute des exigences de conformité pour les systèmes d'IA utilisant des données personnelles pour l'entraînement. Les systèmes d'IA à haut risque doivent documenter leurs données d'entraînement, y compris les mesures d'anonymisation appliquées.
Le principe de limitation de finalité du RGPD (Article 5(1)(b)) limite l'utilisation des données personnelles pour l'entraînement ML sans base légale spécifique. Les actions d'application de la CNIL en 2024 contre les entreprises d'IA se sont concentrées sur cette intersection : des données personnelles collectées pour la prestation de services étant utilisées pour l'entraînement sans base légale adéquate ou anonymisation.
Les exigences de documentation du RGPD et de la Loi sur l'IA sont plus faciles à satisfaire lorsque le processus d'anonymisation des données d'entraînement est techniquement appliqué via des préréglages :
- Nom et configuration du préréglage : la méthodologie d'anonymisation documentée
- Journaux de traitement : preuve que la méthodologie a été appliquée à des ensembles de données spécifiques
- Approbation du DPO : décision enregistrée autorisant la configuration du préréglage
Cela crée la piste de vérification que les deux réglementations exigent.
Configuration de Préréglage pour les Données d'Entraînement ML
Types d'entités pour la plupart des données d'entraînement NLP :
- PERSONNE (noms — Remplacer par des noms similaires)
- EMAIL_ADDRESS (Remplacer par des e-mails synthétiques)
- PHONE_NUMBER (Remplacer par des numéros de téléphone synthétiques)
- CREDIT_CARD / IBAN (Remplacer ou Rédiger — données de paiement)
- LOCATION (Remplacer par des lieux similaires si la géo est nécessaire pour le modèle ; Rédiger si ce n'est pas le cas)
- DATE_OF_BIRTH (Rédiger — généralisation d'âge souvent nécessaire)
Types d'entités généralement NON inclus pour les données d'entraînement NLP :
- Dates générales (pas de date de naissance) — les horodatages et les dates dans le texte sont souvent nécessaires pour la modélisation temporelle
- Noms d'organisations — souvent nécessaires pour l'entraînement à la reconnaissance d'entités
- URLs — souvent nécessaires pour l'extraction de liens et de références
Le responsable ML et le DPO définissent ces distinctions dans le préréglage approuvé. Les scientifiques des données individuels ne prennent pas ces décisions — ils appliquent le préréglage.
Connaissance Institutionnelle et Versionnage de Préréglage
Les préréglages servent une fonction de mémoire institutionnelle :
Avant les préréglages : La configuration correcte des entités pour les données d'entraînement ML vivait dans l'esprit des trois scientifiques des données qui avaient traversé le processus de révision de conformité. Lorsque deux d'entre eux sont partis au T3, la connaissance institutionnelle a été perdue.
Après les préréglages : La configuration est codée dans "Entraînement ML — Données Client v2.1". L'historique des versions montre quand elle a été créée, qui l'a approuvée et ce qui a changé entre v2.0 et v2.1. De nouveaux scientifiques des données utilisent le préréglage et héritent de la connaissance institutionnelle intégrée.
La version 2.1 a ajouté la détection d'IBAN après qu'une révision de conformité a révélé qu'elle manquait. Les enregistrements de la version 2.0 montrent qu'elle a été approuvée en février 2025. La piste de vérification est complète.
Conclusion
La documentation indique aux membres de l'équipe quoi faire. Les préréglages rendent techniquement facile — et techniquement applicable — de le faire de manière cohérente.
Pour les données d'entraînement ML spécifiquement, la cohérence est à la fois une exigence de conformité (RGPD, Loi sur l'IA) et une exigence technique (l'entraînement du modèle nécessite un prétraitement cohérent). Le préréglage satisfait les deux simultanément.
La CNIL et d'autres DPA enquêtant sur les pratiques de données d'entraînement en IA rechercheront des preuves d'anonymisation systématique et cohérente. Un préréglage appliqué uniformément à toute préparation de données d'entraînement est la preuve la plus forte disponible.
Sources :