Question
Un modèle d'IA contient-il des données personnelles ?
Avis 28/2024 du CEPD et fiche CNIL du 22/07/2025 : quand un modèle d'IA relève du RGPD, quels tests mener et quoi documenter pour le dire anonyme.
Mis à jour le
Cela dépend du modèle, et cela se démontre. Le CEPD (Comité européen de la protection des données), dans son avis 28/2024 annoncé le 18/12/2024 à la demande de l'autorité irlandaise, refuse toute réponse générale : l'anonymat d'un modèle s'apprécie au cas par cas. Un modèle entraîné sur des données personnelles n'est anonyme que s'il est « très peu probable » d'identifier les personnes dont les données ont servi, et d'extraire ces données par des requêtes. La CNIL (Commission nationale de l'informatique et des libertés) a traduit cet avis en méthode dans sa fiche du 22/07/2025.
Les enjeux sont concrets. Un modèle anonyme sort du champ du RGPD (règlement général sur la protection des données). Un modèle qui ne l'est pas emporte avec lui toutes les obligations : base légale, information, droits des personnes, sécurité.
La règle posée par la CNIL
Un modèle relève du RGPD s'il a mémorisé des données d'entraînement et que des données personnelles peuvent en être extraites « avec des moyens raisonnablement susceptibles d'être mis en œuvre ». Un modèle conçu pour produire ou déduire des informations sur les personnes de son jeu d'entraînement y est soumis dans tous les cas. Le fournisseur est en général responsable du traitement de développement.
La vraisemblance de réidentification doit être très faible sur deux plans :
- par l'analyse des paramètres du modèle (attaques dites « white-box », avec accès aux poids) ;
- par l'interrogation du modèle, en cherchant à extraire des données.
Le faisceau d'indices
Avant les tests, la CNIL propose de regarder des indices qui augmentent le risque de mémorisation :
| Côté | Indices de risque |
|---|---|
| Données | Éléments identifiants et précis (noms, photographies du visage), données rares ou aberrantes, doublons |
| Architecture et entraînement | Beaucoup de paramètres par rapport au volume de données, surapprentissage, pas de confidentialité différentielle, données personnelles utilisées pour l'affinage |
| Usage | Génération de contenus, requêtes visant les données d'entraînement, attaques réussies sur des modèles comparables |
L'absence d'un indice ne dispense pas de tester. Les mesures qui réduisent le risque à l'entraînement : suppression ou pseudonymisation des données, déduplication, régularisation, arrêt précoce, bruitage du gradient.
Les tests à mener
La fiche cite, par difficulté croissante :
- des tests de régurgitation pour les modèles génératifs ;
- les attaques par inférence d'appartenance (deviner si une donnée faisait partie de l'entraînement) ;
- les attaques par exfiltration, par inversion de modèle et par reconstruction ;
- la mesure de la capacité de mémorisation propre à l'architecture.
Si une attaque réussit, on peut s'arrêter là, ou continuer pour évaluer le risque par type de données. Résister à une technique ne prouve pas qu'on résiste à une autre.
Le système peut réduire le risque, pas l'effacer
Un modèle non anonyme peut être intégré dans un système qui rend l'extraction beaucoup plus difficile : pas d'accès aux poids, authentification, limites d'usage, réglages de génération, filtrage des données personnelles en sortie, chiffrement, journalisation. La CNIL prévient que certaines mesures sont inefficaces en pratique, comme limiter la sortie à une seule valeur ou masquer des noms par liste noire. Le système doit lui-même être testé, et l'analyse revue régulièrement. Et le RGPD peut s'appliquer à l'utilisation d'un modèle que son fournisseur juge anonyme.
Pour un modèle utilisé par API (interface de programmation), ces mesures sont entre les mains du fournisseur ; de votre côté, la première protection reste de limiter ce que vous lui envoyez (voir pseudonymiser avant l'envoi).
Si le modèle n'est pas anonyme
- Le RGPD et la loi Informatique et libertés s'appliquent, à tous les acteurs de la chaîne.
- Il faut une base légale, informer les personnes (page dédiée), permettre l'exercice des droits (page dédiée) et sécuriser le modèle.
- Une extraction avérée peut être une violation de données. L'article 33 du RGPD prévoit la notification à l'autorité « si possible, 72 heures au plus tard » après en avoir pris connaissance.
- Selon la gravité, la CNIL peut exiger un réentraînement ou la suppression du modèle.
Le CEPD ajoute qu'un modèle construit sur des données traitées illicitement peut voir son déploiement remis en cause, sauf s'il a été correctement anonymisé.
La documentation attendue
Pour soutenir la conclusion « modèle anonyme » ou « modèle soumis au RGPD », la CNIL attend : l'analyse d'impact relative à la protection des données (AIPD) ou la décision de ne pas en faire, l'avis du délégué à la protection des données, les mesures prises à chaque étape, une analyse de résistance au regard de l'état de l'art, et les résultats des tests (qui, quand, comment, par niveau d'attaquant). Ces tests sont requis « dans la plupart des cas » pour un modèle et « dans tous les cas » pour un système.
Le cas des vecteurs d'une base de recherche sémantique, voisin mais distinct, est traité dans embeddings et données personnelles.
Questions fréquentes
Un grand modèle de langage est-il anonyme par nature ?
Non. Le CEPD demande une analyse au cas par cas : un modèle n'est anonyme que s'il est très peu probable d'identifier les personnes de la base d'entraînement et d'extraire leurs données par des requêtes.
Que se passe-t-il si des données personnelles sont extraites d'un modèle ?
Selon la CNIL, il faut empêcher leur exploitation et examiner la situation, qui peut constituer une violation de données : documentation, notification à la CNIL dans les 72 heures si un risque existe, information des personnes si le risque est élevé.
Sources
Pages consultées pour écrire cet article :