Le RGPD a été conçu de manière technologiquement neutre, mais plusieurs des droits qu’il reconnaît reposent implicitement sur l’idée qu’une donnée personnelle peut être identifiée, localisée, consultée, corrigée ou supprimée. [Le raisonnement est largement transposable en droit suisse…]

Or un système d’IA, en particulier un grand modèle de langage, ne fonctionne pas comme une base de données. Les données d’entraînement contribuent à modifier les paramètres du modèle, qui apprend des régularités, des relations et des représentations statistiques. L’information initiale peut ainsi cesser d’exister sous la forme d’un enregistrement identifiable tout en continuant à influencer le comportement du modèle. C’est ce passage de la « donnée stockée » à la « connaissance apprise » qui rend l’exercice de certains droits particulièrement délicat.

En amont, les articles 12 à 14 RGPD imposent la transparence et l’information de la personne concernée. L’IA complique déjà ces exigences. Les modèles peuvent être entraînés sur d’immenses ensembles de données provenant du web, combinés, nettoyés et réutilisés à plusieurs étapes. Il peut devenir difficile de déterminer si les données d’une personne déterminée figurent effectivement dans l’entraînement, de quelle source elles proviennent, dans quel modèle elles ont été incorporées et dans quels systèmes dérivés elles ont ensuite été utilisées. L’opacité ne résulte donc pas seulement de la complexité mathématique du modèle, mais aussi de la chaîne de traitement.

Le droit d’accès de l’article 15 RGPD rencontre une difficulté analogue. Dans une base de données, le responsable peut en principe rechercher les entrées correspondant à une personne et les lui communiquer. Dans un modèle d’IA, une information peut être dispersée dans les paramètres ou résulter d’une combinaison de multiples données. Le responsable peut alors ne pas être capable d’isoler ce que le modèle « sait » d’une personne. Le problème est encore plus délicat pour les informations déduites par le modèle. Une IA peut, à partir de données apparemment banales, produire des inférences sur le comportement, les préférences, les émotions ou d’autres caractéristiques d’une personne. Dès lors que ces informations concernent une personne identifiable, elles ne peuvent pas être exclues du champ du RGPD au seul motif qu’elles ont été produites par le système plutôt que directement fournies à celui-ci.

Le droit de rectification de l’article 16 RGPD est l’un des droits les plus directement mis en difficulté. Corriger une date de naissance erronée dans une base de données consiste à remplacer une valeur par une autre. Un modèle de langage ne comporte généralement aucun « champ » correspondant à cette date. L’information incorrecte peut être répartie entre de très nombreux paramètres. Plus encore, elle peut ne jamais avoir figuré dans les données d’entraînement : les hallucinations peuvent conduire le modèle à inventer une information fausse concernant une personne réelle. Il n’existe alors aucun enregistrement erroné à corriger. Une intervention sur les données sources ne suffit donc pas nécessairement. Il peut falloir modifier le modèle lui-même, par un nouvel entraînement, un réglage ciblé ou une opération de « model editing ». Même dans ce cas, rien ne garantit que l’information correcte apparaîtra dans toutes les formulations possibles d’une question ni que l’information erronée ne réapparaîtra pas.

La difficulté la plus étudiée concerne le droit à l’effacement de l’article 17 RGPD. Dans un système classique, effacer signifie supprimer le fichier ou l’enregistrement concerné. Pour un modèle déjà entraîné, supprimer les données du jeu d’entraînement ne supprime pas l’influence qu’elles ont exercée sur le modèle. Le modèle a déjà été modifié par leur utilisation. Le droit à l’effacement exige alors de déterminer ce que signifie réellement « effacer » une information devenue apprentissage.

Le machine unlearning cherche précisément à résoudre ce problème. Il vise à modifier le modèle de manière à éliminer ou réduire l’influence de certaines données sans nécessairement reconstruire tout le modèle. Les techniques les plus rigoureuses cherchent à obtenir un modèle se comportant comme s’il n’avait jamais été entraîné avec les données concernées. La méthode de référence reste toutefois, dans de nombreux cas, le réentraînement du modèle à partir de zéro en excluant les données visées. Une telle opération peut être extrêmement coûteuse pour de grands modèles et difficile à répéter chaque fois qu’une personne exerce son droit à l’effacement.

Les méthodes approximatives sont beaucoup moins coûteuses, mais elles ne garantissent pas que toute influence de la donnée ait disparu. Le modèle peut conserver des représentations, des corrélations ou des connaissances permettant de reconstruire indirectement l’information. Quant aux techniques qui se limitent à empêcher l’affichage de certaines réponses, elles ne constituent pas un véritable effacement : la donnée ou son influence demeure dans le modèle et un autre prompt, une attaque ou un accès direct aux paramètres peut permettre de la retrouver. Masquer une information n’équivaut donc pas à l’effacer.

Même la solution réputée la plus sûre ne clôt pas nécessairement le problème. Comparons  l’état d’un modèle avant et après l’effacement. Lorsque l’attaquant dispose des deux versions, les différences entre elles peuvent révéler précisément ce qui a été supprimé. L’opération destinée à protéger la personne crée ainsi elle-même un signal sur les données retirées. Les expériences réalisées sur plusieurs jeux de données, notamment sur des dossiers médicaux synthétiques, montrent que cette comparaison peut améliorer considérablement la reconstruction des informations censées avoir été oubliées. Il ne suffit donc pas d’examiner la sécurité du modèle après effacement : il faut prendre en compte les anciennes versions du modèle, les checkpoints conservés, les copies diffusées et les informations déjà enregistrées par des tiers.

Cette observation a une conséquence juridique importante pour l’article 17 RGPD : l’effacement ne peut pas être apprécié uniquement à l’intérieur du modèle actuellement exploité. Si des versions antérieures, des modèles dérivés, des modèles distillés ou des produits construits à partir du modèle initial continuent à contenir l’information ou son influence, l’effectivité de l’effacement devient problématique. Une suppression réussie dans le modèle source ne fait pas automatiquement disparaître les traces déjà propagées dans l’écosystème technique.

Le droit à la limitation du traitement de l’article 18 RGPD soulève un problème voisin. Il paraît techniquement plus simple d’empêcher temporairement certaines réponses que d’effacer une connaissance du modèle. Mais limiter l’accès à une information au niveau de la sortie ne signifie pas que le modèle cesse de la traiter intérieurement. Les filtres peuvent en outre être contournés et leur mise en œuvre peut manquer de granularité : empêcher le système de fournir une information déterminée peut conduire à bloquer simultanément d’autres informations licites concernant la même personne. La limitation de l’usage apparent et la limitation effective du traitement ne coïncident donc pas nécessairement.

Le droit d’opposition de l’article 21 RGPD et le retrait du consentement prévu à l’article 7, paragraphe 3, posent une difficulté particulièrement nette lorsque les données ont déjà servi à l’entraînement. Il est relativement simple d’exclure une personne des futurs jeux de données. Il est beaucoup plus difficile de faire en sorte que ses données cessent d’influencer un modèle déjà entraîné. Pour donner un effet réel à l’opposition ou au retrait du consentement, il faut en principe procéder à une forme d’unlearning ou reconstruire le modèle. S’ajoute un problème de preuve : les techniques actuelles ne permettent pas toujours de fournir une preuve vérifiable que l’influence des données a effectivement disparu. La personne doit alors, dans une certaine mesure, se fier à l’affirmation du responsable selon laquelle le modèle a « oublié ». Or un droit dont l’exécution ne peut être contrôlée devient nécessairement moins effectif.

L’article 19 RGPD, qui impose dans certaines circonstances de communiquer la rectification, l’effacement ou la limitation aux destinataires auxquels les données ont été transmises, prend également une importance pratique dans un environnement d’IA. Lorsqu’un modèle a été copié, adapté, affiné ou intégré à d’autres produits, une modification du modèle initial ne se propage pas automatiquement à ces systèmes dérivés. La difficulté n’est donc plus seulement d’effacer une donnée, mais d’identifier toutes les ramifications techniques dans lesquelles son influence s’est diffusée.

La portabilité prévue à l’article 20 RGPD ne soulève pas de difficulté propre à l’IA comparable à celles concernant l’effacement ou la rectification. La portabilité vise en effet essentiellement les données fournies par la personne concernée et non l’ensemble des connaissances ou inférences produites par un modèle.

L’article 22 RGPD, relatif aux décisions fondées exclusivement sur un traitement automatisé produisant des effets juridiques ou des effets similaires significatifs, pose des problèmes distincts et spécifiques à ce genre de décisions. On relèvera que les hallucinations et les biais peuvent conduire un système à produire des informations ou des inférences erronées sur une personne. Lorsque de telles données servent ensuite à une décision automatisée, les problèmes d’exactitude et de rectification deviennent particulièrement importants. L’enjeu se situe alors autant dans la qualité des données utilisées par la décision que dans l’automatisation elle-même.

Le constat général des publications est ainsi que l’IA ne supprime aucun droit du RGPD et que la difficulté technique ne constitue pas une exception juridique. Elle révèle plutôt une incompatibilité potentielle entre certaines architectures et l’effectivité des droits. L’article 25 RGPD, relatif à la protection des données dès la conception et par défaut, prend dès lors une importance particulière : un système destiné à traiter des données personnelles devrait être conçu dès l’origine de façon à permettre l’exercice effectif des droits, plutôt que de rechercher après coup des solutions permettant au modèle d’oublier.

En conclusion, les droits les plus directement menacés par les caractéristiques techniques de l’IA sont donc le droit d’accès de l’article 15, le droit de rectification de l’article 16 et surtout le droit à l’effacement de l’article 17, auxquels s’ajoutent la limitation du traitement de l’article 18, l’opposition de l’article 21 et le retrait du consentement de l’article 7, paragraphe 3. La difficulté commune est toujours la même : le RGPD raisonne principalement à partir de données susceptibles d’être individualisées et maîtrisées, tandis que l’apprentissage automatique transforme ces données en influences distribuées, parfois impossibles à isoler. Le machine unlearning constitue une piste importante, mais il n’offre encore ni une garantie générale d’effacement, ni une preuve toujours vérifiable de celui-ci, ni une solution automatique au problème des copies et modèles dérivés. L’enjeu n’est donc plus seulement de savoir si une IA peut techniquement « oublier », mais de déterminer comment construire des systèmes dans lesquels l’exercice d’un droit juridique produit un effet technique réel, complet et vérifiable.

Références : Beatriz Fernández Delgado et Víctor Cazurro Barahona, « Can artificial intelligence forget? Reflections on the right to disappear in a world where algorithms remember everything », International Journal of Engineering Business Management, vol. 18, 2026, DOI 10.1177/18479790261468434. Jevan Hutson, Cedric Whitney et Jay T. Conrad, « Forget Me Not? Machine Unlearning’s Implications for Privacy Law », Columbia Science & Technology Law Review, vol. 27, 2026. Xiaoyu Wu, Yifei Pang, Terrance Liu et Zhiwei Steven Wu, « Unlearned but Not Forgotten: Data Extraction after Exact Unlearning in LLM », NeurIPS 2025 / arXiv:2505.24379.

Me Philippe Ehrenström, avocat, DPO ; LLM, CAS en Droit et intelligence artificielle, CAS en protection des donnés