LLM et données personnelles
Dernières tendances en matière de tokensiation et sphère privée
Selon les dernières prises de position à ce sujet, le modèle d’un LLM ne contiendrait pas de données personnelles. Dans ces lignes, nous expliquons les fondements de cette conclusion et mettons en évidence certaines faiblesses de ce raisonnement. Enfin, la portée pratique de ce débat est aussi clarifiée ; quelle que soit la solution finalement retenue, il ne fait aucun doute que les questions liées aux données personnelles resteront centrales dans le monde de l’intelligence artificielle générative.
I. Introduction
Depuis 2022 et l’adoption massive des large language models (LLM), comme ChatGPT, des problématiques juridiques sont rapidement apparues. On pensera notamment à l’interdiction temporaire de ChatGPT en Italie par le GPDP en mars 2023[1], évoquant des incertitudes sur les données collectées par OpenAI. Ces enjeux ont conduit les professionnels de la protection des données à s’interroger concernant les LLM sur : i) la nature des données utilisées, ii) les traitements effectués, et iii) leur base légale[2].
Ces lignes vous proposent en bref aperçu des dernières tendances en matière de protection de la sphère privée dans le monde des LLM. Nous prêterons un intérêt particulier au discussion paper (le Discussion Paper) du Hamburg Commissioner for Dataprotection and freedom of information, (HmbBfDI). Enfin, nous analyserons également la récente opinion 28/2024 de European Data Protection Board (EDPB) qui se positionne sur ces questions
II. Notions théoriques
Avant toutes choses, nous vous proposons une brève vulgarisation de quelques notions, nécessaires à la compréhension de cet article.
A. Architecture d’un réseau neuronal
Un LLM repose sur un modèle informatique entraîné avec un dataset converti en tokens (concept expliqué en section B ci-dessous). Le réseau neuronal comprend trois types de couches [3] :
- Couche d’entrée (input layer) : elle représente la requête de l’utilisateur sous forme tokenisée.
- Couches cachées (hidden layers) : elles transforment la requête en un format exploitable.
- Couche de sortie (output layer) : elle génère une réponse à la requête.
B. La Tokenisation des données
Les données d’entraînement sont transformées en tokens, qui peuvent être des mots, des caractères ou des combinaisons[4]. Chaque token est associé à une valeur numérique utilisée dans les calculs du modèle. Cette représentation mathématique permet de gérer les requêtes et d’établir des connexions statistiques entre les tokens .
Lorsqu’une requête est effectuée sur un LLM, l’entrée est convertie en tokens. Puis, des poids (weights) déterminent comment les tokens seront transférés lorsqu’ils passent à travers les différentes couches, jusqu’à la couche de sortie.
C. Problématiques spécifiques aux LLM
Les LLM présentent des difficultés uniques dans le traitement des données personnelles :
- Localisation des données: Les données personnelles peuvent se situer dans le dataset ou à travers les couches du modèle.
- Nature générative: Les LLM permettent une variété de traitements complexes.
- Responsabilités multiples: En cas d’ajustements (fine-tuning), plusieurs responsables peuvent être impliqués, compliquant l’exercice des droits des personnes concernées[5].
III. Tokenisation et anonymité
Selon le HmbBfDI, les données dans un LLM sont anonymes car transformées en probabilités mathématiques, par le biais de la tokenisation. Selon cette autorité, les outputs générés ne reproduisent pas directement les données du dataset, différant ainsi d’autres types de traitements.
En outre, selon l’autorité, pour déterminer l’existence d’une donnée personnelle au sein d’un modèle, une privacy attack serait nécessaire. Cela représenterait une effort disproportionné.
A. Critique de la position du HmbBfDI
La jurisprudence européenne [6] et suisse [7] adoptent un standard élevé pour considérer une donnée comme anonyme, même si l’identification n’est possible qu’indirectement[8]. Or, des réponses concordantes à de nombreux prompts suggèrent une forte association entre les tokens à la base du LLM. Implicitement ces données personnelles existent dans le modèle, sous forme de probabilité[9].
Exemple : GPT-4 peut fournir des réponses cohérentes sur le nombre d’enfants de Roger Federer, démontrant une connaissance implicite de cette donnée personnelle. Peu importe le nombre de fois et la manière dont la question est posée, la réponse est invariablement quatre. Cette donnée existe donc probablement, certes sous une forme différente, dans le modèle.
Autre faiblesse de la position du HmbBfDI : soutenir qu’une privacy attack pour identifier les données serait nécessaire[10]. Un simple prompt suffirait fréquemment à notre avis pour révéler la probable existence au sein du modèle des données personnelles.
B. Position de l’EDPB
Dans son analyse, l’EDPB est plus nuancé que l’HmbBfDI. Notons en outre que opinion 28/2024 traite plus largement de l’IA et pas uniquement de LLM.
Le comité européen soutient que, dans la grande majorité des cas, une analyse détaillée et au cas par cas sera nécessaire. L’autorité précise que conclure à l’anonymité des données en utilisant des moyens raisonnables pour extraire les données, il faut examiner: i) la probabilité d’une extraction directe de données à caractère personnel concernant les personnes dont les données à caractère personnel ont été utilisées pour former le modèle et ii) la probabilité d’obtenir, intentionnellement ou non, de telles données à caractère personnel à partir de requêtes, devrait être insignifiante pour toute personne concernée.
Au vu de ce qui précède, la tokenisation des données personnelles, ne semble pas à elle seule être déterminante.
IV. Conséquences pour le monde de l’intelligence artificielle
A. Implications pratiques
Si la position du HmbBfDI est suivie, héberger ou mettre à disposition un LLM ne serait pas considéré comme un traitement de données personnelles. Cependant, l’entraînement et les outputs demeurent soumis au RGPD.
En cas d’exercice des droits de la personne concernée, corriger un output erroné reste complexe, pouvant nécessiter un réentraînement très coûteux (estimé à plus de 100 millions USD pour GPT-4).
B. Conséquences indirectes
ette position pourrait influencer la définition des données personnelles, mais devrait être nuancée en fonction de la probabilité d’identification. De plus, certains modèles utilisant des techniques comme le Retrieval-Augmented Generation (RAG) peuvent reproduire des données personnelles.
En dehors du domaine de la protection des données, l’absence de reproduction pourrait aussi affecter les droits d’auteur (dans le cadre des nombreux procès ouverts actuellement contre les développeur d’IA génératives).
V Conclusion
Les implications théoriques du Discussion Paper sont intéressantes, mais ses effets pratiques restent limités. Les effets pratiques nous semblent relativement limités (du moins sous l’angle de la protection des données) puisque la collecte d’un jeu de données, l’entraînement du modèle et les données de sortie demeurent considérés comme des traitement de données. Selon le HmbBfDI, la personne concernée conserve par exemple un droit à l’effacement concernant les inputs et outputs d’un LLM.
L’avenir dira quelle est la position des autorités suisses à ce sujet. La Suisse devra concilier protection des données, propriété intellectuelle et promotion de l’IA. A notre sens, les LLM sont conçus à des fins conversationnelles et ne garantissent donc pas l’exactitude de leurs outputs. Exiger une rectification revient, à notre avis, à méconnaître leur fonctionnement. En outre, un cadre légal rigide risquerait d’entraver l’innovation. De la jurisprudence zurichoise va par exemple dans ce sens concernant les résultats affichés par un moteur de recherche[11].
[1] Voir le communiqué du 31 mars 2023.
[2] Voir par exemple l’analyse de la CNIL sur l’utilisation de l’intérêt légitime comme base légale.
[3] Voir : https://cnil.fr/fr/definition/couche-de-neurones
[4] Pour davantage de détails sur ce point, voir le Discussion Paper: Large Language Models (Discussion Paper) publié par le Hamburg Commissioner for Dataprotection and freedom of information, (HmbBfDI).
[5] Art. 25ss LPD et art. 12 ss. RGPD
[6] Par exemple : CJUE, Patrick Breyer ./. Bundesrepublik Deutschland, C-582/14 (19 octobre 2016), § 44ss relatif aux adresses IP dynamiques et CJUE, IAB Europe ./. Gegevensbeschermingsautoriteit, C-604/22 (7 mars 2024), § 50 relatif aux TC strings.
[7] Par exemple: ATF 136 II 508, c. 3.4
[8] ATF 136 II 508, c. 3.5
[9] Voir à ce sujet la position de David Rosentahl
[10] Discussion Paper, 7
[11] A ce sujet, voir l’arrêt du tribunal de commerce de Zurich HG220030-O du 21 août 2024 opposant la FIFA et Google.
