Faire passer des données personnelles dans un grand modèle de langage soulève une question simple en apparence et complexe en pratique : comment rester conforme au RGPD ? Dès qu'un prompt contient le nom d'un client, un numéro de dossier ou un échange avec un salarié, vous traitez des données personnelles, et toutes les obligations du règlement s'appliquent — y compris si le modèle est hébergé à l'autre bout du monde.
Le risque le plus courant n'est pas malveillant : c'est l'envoi par défaut de données sensibles vers une API hébergée hors UE, sans base légale claire, sans encadrement contractuel et sans traçabilité. Une pratique banale qui peut constituer un transfert non encadré et une violation du RGPD.
Cet article donne une méthode opérationnelle pour utiliser un LLM sur des données personnelles sans prendre de risque : choisir une base légale, minimiser et pseudonymiser, encadrer la sous-traitance et les transferts hors UE, savoir quand réaliser une analyse d'impact (DPIA), et concevoir une architecture RAG sécurisée — au besoin on-premise — qui garde la maîtrise de vos données.
Le principe : le RGPD ne disparaît pas avec l'IA
Le RGPD s'applique intégralement dès qu'un système d'IA traite des données personnelles, qu'il soit hébergé en interne ou via une API externe. L'IA n'est pas une zone de non-droit : envoyer une donnée à un modèle est un traitement, soumis aux mêmes principes que n'importe quel autre.
Les principes fondateurs à garder en tête :
- Licéité — chaque traitement doit reposer sur une base légale (consentement, contrat, intérêt légitime, obligation légale).
- Minimisation — vous ne devez traiter que les données strictement nécessaires à la finalité.
- Finalité — les données collectées pour un usage ne peuvent pas être réutilisées librement pour un autre, y compris l'entraînement d'un modèle.
- Transparence — les personnes concernées doivent savoir comment leurs données sont traitées.
- Sécurité — vous devez protéger les données par des mesures techniques et organisationnelles appropriées.
Le point qui surprend souvent : même si vous n'entraînez pas le modèle, le simple fait de lui envoyer des données personnelles dans un prompt est un traitement à encadrer. Et selon les conditions du fournisseur, ces données peuvent être conservées ou réutilisées, ce qui pose un enjeu de finalité et de sous-traitance.
Choisir une base légale solide
Tout traitement de données personnelles par un LLM doit reposer sur l'une des bases légales du RGPD. Sans base légale, le traitement est illicite, quel que soit le soin apporté au reste.
Les bases les plus pertinentes pour un usage IA en entreprise :
- L'intérêt légitime — souvent invocable pour des usages internes d'efficacité (assistance à la rédaction, synthèse de documents), à condition de mettre en balance vos intérêts et les droits des personnes et de documenter cette analyse.
- L'exécution d'un contrat — pertinent quand le traitement est nécessaire à un service que vous rendez au client.
- Le consentement — requis pour certains usages, notamment quand vous sortez du cadre attendu par la personne ; il doit être libre, spécifique, éclairé et révocable.
- L'obligation légale — pour des traitements imposés par la loi.
Le piège le plus fréquent : réutiliser des données collectées pour une finalité (par exemple le support client) afin d'alimenter un modèle d'IA pour une autre finalité, sans nouvelle base légale ni information des personnes. La finalité initiale ne couvre pas automatiquement l'usage IA. Documenter la base légale et la finalité de chaque usage IA est un réflexe simple qui évite la majorité des problèmes.
Minimisation, anonymisation et pseudonymisation
La minimisation est le levier le plus efficace pour réduire le risque RGPD d'un usage IA : moins vous envoyez de données personnelles au modèle, plus votre exposition est faible. Avant tout dispositif technique sophistiqué, posez-vous la question : ce prompt a-t-il vraiment besoin de cette donnée nominative ?
Trois techniques complémentaires :
- Minimisation — n'envoyez au modèle qu'un extrait pertinent plutôt qu'un dossier complet. Un résumé d'un échange suffit souvent là où on enverrait par réflexe toute la conversation.
- Anonymisation — supprimer irréversiblement tout élément identifiant. Une donnée réellement anonymisée sort du champ du RGPD, mais l'anonymisation robuste est techniquement exigeante.
- Pseudonymisation — remplacer les identifiants directs par des pseudonymes réversibles via une clé conservée séparément. La donnée reste personnelle au sens du RGPD, mais le risque en cas de fuite est fortement réduit.
En pratique, la pseudonymisation automatisée en amont du modèle est souvent le meilleur compromis : un composant logiciel détecte et remplace noms, emails, numéros de dossier avant l'envoi au LLM, puis réinjecte les vraies valeurs dans la réponse côté entreprise. Le modèle ne voit jamais les données brutes. C'est typiquement le genre de garde-fou que l'on intègre dans un outil interne sur mesure.
Sous-traitance et transferts hors UE
Utiliser l'API d'un fournisseur de LLM, c'est lui confier le traitement de vos données : il devient votre sous-traitant au sens de l'article 28 du RGPD, et si ses serveurs sont hors UE, vous réalisez un transfert international encadré par la jurisprudence Schrems II.
Vos obligations concrètes :
- Contrat de sous-traitance (art. 28) — un accord de traitement des données (DPA) doit encadrer ce que le fournisseur peut faire de vos données, notamment l'interdiction de les réutiliser pour entraîner ses modèles si tel est votre choix.
- Transferts hors UE — un transfert vers les États-Unis ou un autre pays tiers exige un mécanisme valide (clauses contractuelles types, cadre d'adéquation applicable) et une analyse des risques liés à l'accès des autorités locales aux données.
- Localisation — privilégier un hébergement dans l'UE, voire on-premise, supprime une grande partie de cette complexité.
C'est précisément ici que la souveraineté rejoint la conformité. Un modèle européen open-weight comme Mistral, ou un modèle open source déployé on-premise, évite le transfert hors UE : les données ne quittent pas votre infrastructure. La question « mon fournisseur de LLM est-il un sous-traitant conforme, et mes données partent-elles hors UE ? » disparaît quand vous hébergez vous-même. Nous comparons ces approches dans notre guide RAG sécurisé en entreprise.
Quand réaliser une DPIA ?
Une analyse d'impact relative à la protection des données (DPIA) est obligatoire lorsqu'un traitement est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes. Plusieurs usages d'IA entrent dans ce cas.
Vous devez réaliser une DPIA notamment quand votre usage IA implique :
- Une évaluation ou un scoring de personnes — notation de clients, présélection de candidats, profilage à grande échelle.
- Un traitement de données sensibles — santé, opinions, données biométriques, à grande échelle.
- Une prise de décision automatisée produisant des effets juridiques ou significatifs sur les personnes.
- Une surveillance systématique ou le croisement de jeux de données à grande échelle.
La DPIA n'est pas une formalité bureaucratique : c'est un outil de conception. Elle force à documenter la finalité, à évaluer la proportionnalité, à identifier les risques et à définir les mesures pour les réduire — minimisation, pseudonymisation, supervision humaine. Réalisée tôt, elle oriente l'architecture du système vers la conformité plutôt que de la constater trop tard. Elle s'articule directement avec les obligations de l'EU AI Act sur les usages à haut risque.
RAG sur données internes : la bonne architecture
Le RAG (retrieval-augmented generation) est l'architecture de référence pour exploiter un LLM sur vos données internes en maîtrisant la confidentialité : plutôt que d'entraîner un modèle sur vos données, vous les stockez chez vous et n'envoyez au modèle que les extraits pertinents au moment d'une requête.
Pourquoi c'est conforme par conception :
- Vos données restent chez vous — la base de connaissances (documents, dossiers, historiques) est hébergée sous votre contrôle, pas dans le modèle.
- Minimisation native — seuls les extraits nécessaires à répondre à une question sont transmis au modèle, ce qui réduit l'exposition.
- Traçabilité — vous pouvez journaliser quelles sources ont été utilisées pour chaque réponse, précieux pour le RGPD et l'AI Act.
- Pas de réentraînement — mettre à jour la connaissance revient à mettre à jour la base documentaire, sans repasser par un entraînement coûteux.
Le choix décisif est l'hébergement du modèle qui génère les réponses. Avec une API externe, les extraits transmis restent soumis aux enjeux de sous-traitance et de transfert. Avec un modèle déployé on-premise, rien ne sort de votre infrastructure. Nous détaillons cette mise en œuvre dans notre guide sur le déploiement de RAG on-premise.
Les garde-fous techniques indispensables
Au-delà des principes juridiques, quelques garde-fous techniques rendent un usage IA durablement conforme. Ils transforment des obligations RGPD abstraites en mécanismes concrets du système.
- Pseudonymisation automatisée en amont — détecter et masquer les données personnelles avant l'envoi au modèle, puis les réinjecter côté entreprise.
- Journalisation des traitements — conserver quelles données ont été traitées par quel modèle et pour quelle finalité, base de la démonstration de conformité.
- Contrôle d'accès — restreindre qui peut interroger le système et sur quelles données, selon les habilitations.
- Politique de rétention — supprimer les prompts et historiques au-delà de la durée nécessaire.
- Couche d'abstraction du modèle — pouvoir router les données sensibles vers un modèle on-premise ou européen, et changer de fournisseur sans réécriture.
Ces garde-fous sont d'autant plus faciles à mettre en place qu'ils sont prévus dès la conception. Greffer la conformité sur un système existant coûte plus cher et laisse des angles morts. Si vous souhaitez exploiter vos données avec un LLM tout en restant conforme, échangeons sur votre cas et l'architecture la plus adaptée à votre niveau de sensibilité.
FAQ — RGPD et IA : utiliser un LLM sur des données personnelles sans risque
Puis-je envoyer des données clients à ChatGPT ou Claude sans risque ?
Pas sans précautions. Envoyer des données personnelles à une API externe est un traitement soumis au RGPD : il faut une base légale, un contrat de sous-traitance (art. 28) et, si le fournisseur est hors UE, un encadrement du transfert. Le plus sûr est de minimiser et pseudonymiser les données avant l'envoi, voire d'héberger un modèle on-premise pour que rien ne sorte de votre infrastructure.
Quelle est la différence entre anonymisation et pseudonymisation ?
L'anonymisation supprime irréversiblement tout élément identifiant : la donnée sort alors du champ du RGPD, mais une anonymisation robuste est techniquement difficile. La pseudonymisation remplace les identifiants par des pseudonymes réversibles via une clé conservée à part : la donnée reste personnelle au sens du RGPD, mais le risque en cas de fuite est fortement réduit. La pseudonymisation automatisée est souvent le meilleur compromis pratique.
Dois-je faire une DPIA pour mon projet d'IA ?
Une DPIA est obligatoire si le traitement présente un risque élevé pour les personnes : scoring ou évaluation, traitement de données sensibles à grande échelle, décision automatisée à effet significatif, ou surveillance systématique. Au-delà de l'obligation, c'est un outil de conception qui oriente l'architecture vers la conformité dès le départ et s'articule avec les obligations de l'AI Act sur les usages à haut risque.
Le RAG est-il conforme au RGPD ?
Le RAG est l'une des architectures les plus favorables à la conformité : vos données restent stockées chez vous, seuls les extraits pertinents sont transmis au modèle au moment d'une requête, et vous pouvez tracer les sources utilisées. La conformité dépend ensuite de l'hébergement du modèle générateur : une API externe garde des enjeux de sous-traitance, tandis qu'un modèle on-premise garantit que rien ne quitte votre infrastructure.
Héberger le modèle on-premise règle-t-il les problèmes de transfert hors UE ?
En grande partie, oui. Un modèle open source ou open-weight comme Mistral, déployé sur votre infrastructure ou un cloud européen, fait que les données personnelles ne quittent pas l'UE ni votre périmètre. Cela supprime la question du transfert international et de la sous-traitance hors UE. Il reste à sécuriser l'hébergement lui-même, mais l'enjeu Schrems II disparaît.