Peut-on vraiment entraîner un LLM sur des données personnelles ?
L’essor des modèles de langage de grande taille (LLM) tels que GPT, LLaMA ou Mistral marque un tournant dans l’automatisation du traitement du langage. Leur capacité à comprendre, synthétiser ou générer des textes est inédite. Mais leur efficacité repose sur une phase d’entraînement massive, souvent opaque, qui pose un problème de fond : peut-on, en Europe, utiliser des données personnelles pour entraîner un LLM?
Un cadre juridique strict, souvent mal compris
L’article 4 du RGPD définit une donnée personnelle comme toute information relative à une personne identifiée ou identifiable. Entraîner un modèle sur des e-mails, des CV, des échanges Slack ou des documents RH contenant noms, adresses, identifiants ou données de santé est donc un traitement de données personnelles.
Ce traitement engage plusieurs obligations :
- Disposer d’une base légale (intérêt légitime, consentement, exécution d’un contrat, obligation légale ou intérêt vital).
- Informer les personnes concernées de la finalité du traitement.
- Minimiser les données utilisées (principe de proportionnalité).
- Garantir la sécurité du traitement et prévenir toute fuite ou réidentification.
- Permettre l’exercice du droit à l’effacement.
Or, dans le cas des LLM, la plupart de ces obligations deviennent extrêmement difficiles à tenir une fois les données ingérées dans le modèle.
La logique d’apprentissage : une boîte noire réglementaire
Contrairement à un moteur de recherche, un LLM n’indexe pas le contenu : il encode des représentations statistiques à travers des milliards de paramètres. Cela empêche a priori d’identifier ou d’extraire directement une donnée personnelle à partir du modèle. Pourtant, des tests empiriques ont démontré que :
- Certains prompts permettent de réinjecter des données identifiantes.
- Des LLM peuvent halluciner des numéros de téléphone ou des noms présents dans leur corpus d’entraînement.
- Il est quasiment impossible de désentraîner un modèle sans le réentraîner intégralement.
Le principe de Privacy by Design est donc difficilement applicable si ces précautions n’ont pas été intégrées avant l’entraînement.
Cas concrets et risques associés
🟠 Cas 1 : Données internes d’une entreprise
Une entreprise veut fine-tuner un LLM sur ses échanges internes (tickets de support, contrats, emails). Si elle n’a pas obtenu le consentement explicite des collaborateurs ou clients concernés, elle viole le RGPD. Même avec un hébergement on-premise, l’usage reste illégal sans base légale claire.
🟠 Cas 2 : Données publiques sur le Web
De nombreuses bases d’entraînement intègrent des données issues de Wikipédia, GitHub, StackOverflow ou Common Crawl. Or, le simple fait qu’une donnée soit publique n’annule pas son caractère personnel. Par exemple, le pseudonyme d’un utilisateur de forum peut être relié à une personne.
🔴 Cas 3 : Modèles open source pré-entraînés
Si une entreprise utilise un modèle open source déjà entraîné (ex : LLaMA, Falcon), elle hérite du risque juridique si des données personnelles illégalement acquises y ont été intégrées.
Quelles solutions techniques et opérationnelles ?
1. Pré-traitement des données (filtrage, anonymisation)
Avant tout entraînement, il est impératif d’identifier et nettoyer les données personnelles. Cela implique de :
- Détecter les entités nommées (NER).
- Supprimer ou pseudonymiser les éléments sensibles.
- Vérifier l’origine et la légitimité du corpus.
Limite : l’anonymisation est rarement parfaite. Un croisement avec d’autres données peut permettre une réidentification.
2. Utilisation de méthodes alternatives : RAG (Retrieval-Augmented Generation)
Le modèle n’est pas entraîné sur la donnée sensible, mais il y accède dynamiquement via une base documentaire externe.
Exemple : Un LLM n’a pas appris le contenu d’un contrat, mais il peut y accéder au moment du prompt via un moteur de recherche interne. L’information reste localisée et peut être modifiée ou supprimée à tout moment.
3. Fine-tuning contrôlé et hébergement souverain
Lorsqu’un entraînement interne est nécessaire, il doit :
- Être effectué dans un environnement maîtrisé (on-premise ou cloud de confiance).
- S’appuyer sur un traitement documenté, avec une base légale établie.
- Intégrer un registre de traitement RGPD spécifique.
Gouvernance et responsabilités
🔸 Qui est responsable ?
- Le responsable de traitement (souvent l’entreprise utilisatrice).
- Le fournisseur du modèle (éditeur ou intégrateur).
- Le sous-traitant qui fournit l’infrastructure ou les services cloud.
🔸 Risques encourus :
- Sanctions financières (jusqu’à 4 % du CA mondial).
- Contentieux civils (en cas d’atteinte à la vie privée).
- Perte de confiance ou d’image.
Et ailleurs ? Un contentieux en formation
Aux États-Unis, des class actions émergent contre OpenAI, Google ou Meta. Les plaignants dénoncent l’entraînement sans consentement sur leurs données (œuvres, photos, contenus journalistiques). En Europe, les autorités de protection des données (CNIL, EDPS) examinent de près les pratiques de traitement des LLM, notamment dans l’application du Data Governance Act et du AI Act.
Tableau récapitulatif
| Élément | Risque principal | Solution recommandée |
|---|---|---|
| Entraînement sur données RH | Violation du droit à l’oubli | Anonymisation ou RAG avec accès contrôlé |
| Utilisation de données publiques | Réidentification possible | Consentement ou exclusion préalable |
| Modèle open source pré-entraîné | Encapsulation de données personnelles inconnues | Audit du corpus, test sur hallucinations |
| Requête utilisateur (prompt) | Révélation involontaire de données sensibles | Filtrage du prompt, logs audités, monitoring |
En conclusion
L’entraînement d’un LLM sur des données personnelles n’est pas interdit, mais il est strictement encadré. Les entreprises doivent désormais considérer les LLM non comme des boîtes magiques, mais comme des traitements de données à haut risque. À défaut d’une gouvernance robuste, d’un audit des jeux de données et d’un contrôle sur l’infrastructure, l’usage de ces modèles pourrait exposer à des sanctions majeures.
