RGPD et LLM : ce que les Équipes Enterprise Manquent
Envoyer des données personnelles à un LLM tiers est un transfert de données. La plupart des équipes n'ont pas réfléchi aux implications.

Voici un scénario très courant : une entreprise SaaS B2B construit un assistant IA pour son produit. Les utilisateurs peuvent poser des questions, obtenir des résumés, générer du contenu. L'équipe intègre l'API OpenAI, écrit un prompt système, livre.

Six mois plus tard, le service juridique demande : "Quelles données personnelles envoyons-nous à OpenAI, et sur quelle base légale ?"

Le silence qui suit est gênant.

Pourquoi c'est un problème RGPD

Le RGPD s'applique lorsque vous traitez des données personnelles. Le "traitement" inclut la transmission de données à un tiers. Lorsque le message d'un utilisateur contient des données personnelles, son nom, son adresse email, son employeur, sa situation médicale, et que vous envoyez ce message à une API LLM, vous transférez des données personnelles à un sous-traitant.

En vertu du RGPD, vous avez besoin de :

1. Une base légale pour le traitement (Article 6, généralement nécessité contractuelle ou intérêt légitime)
2. Un Accord de Traitement de Données (DPA) avec le sous-traitant (Article 28)
3. Si le sous-traitant est hors UE/EEE : un mécanisme de transfert international (Article 46, généralement des Clauses Contractuelles Standard)
4. Une notice de confidentialité qui divulgue l'utilisation du traitement IA à vos utilisateurs

La plupart des équipes ont coché la case 2 (OpenAI, Anthropic et Google proposent tous des DPA). Les cases 1, 3 et 4 sont là où se trouvent les lacunes.

Où se trouvent vraiment les données personnelles

Les messages utilisateurs sont la source la plus évidente. Mais les sources moins évidentes sont plus dangereuses :

Documents récupérés par RAG : si votre IA récupère des documents pour fournir du contexte, ces documents contiennent souvent des données personnelles. Noms, emails, contrats, factures, notes de réunion, tout cela est assemblé dans la fenêtre de contexte et transmis au modèle.

Historique de conversation : les conversations multi-tours accumulent du contexte. Les données personnelles mentionnées cinq tours auparavant sont encore dans la fenêtre envoyée avec chaque requête suivante.

Prompts système : parfois le prompt système lui-même contient des données personnelles, le profil d'un utilisateur, son niveau d'abonnement, son comportement passé.

Les contrôles techniques qui comptent

Détection PII au niveau du gateway

Le contrôle le plus efficace est de scanner les messages utilisateur (et optionnellement le contenu récupéré) pour les données personnelles avant transmission à l'API LLM.

Un scanner pertinent pour le RGPD doit détecter :

• Adresses email
• Numéros de téléphone français (+33 / 0033 / 0[1-9]) et suisses (+41)
• IBANs français (commencent par FR76, 27 caractères)
• Identifiants nationaux (SIRET 14 chiffres, SIREN 9 chiffres)

En mode monitor, vous obtenez une visibilité sur le volume de données personnelles qui transitent par votre système sans rien bloquer. En mode block, vous empêchez la transmission et renvoyez une erreur à l'application.

Hash du prompt pour la piste d'audit

Lorsqu'un événement est loggué, stocker le texte intégral du prompt crée un nouveau problème de rétention de données, vous avez maintenant une copie des données personnelles dans vos logs de sécurité.

La bonne approche est de hasher le prompt (SHA-256) et de ne stocker que le hash. Cela permet de corréler les événements avec des requêtes spécifiques sans conserver le texte brut.

Configuration de la rétention

Le principe de minimisation des données du RGPD s'applique aussi à vos logs d'événements de sécurité. Configurez une fenêtre de rétention, généralement 30 à 90 jours, et appliquez-la avec un job de purge automatisé.

La lacune DPA et transfert international

La plupart des équipes ont signé le DPA du fournisseur de modèles. Moins ont vérifié que le DPA couvre leur cas d'usage réel.

OpenAI, Anthropic et Google traitent les données aux États-Unis. Si vos utilisateurs sont dans l'UE/EEE, c'est un transfert international. Vous avez besoin d'un mécanisme de transfert valide, les Clauses Contractuelles Standard (CCS) sont la voie standard. Tous les trois les proposent, mais vous devrez peut-être demander la documentation CCS spécifique.

La lacune notice de confidentialité

Si votre produit utilise l'IA pour traiter des données utilisateur, le RGPD exige que vous le divulguiez dans votre notice de confidentialité. La divulgation doit couvrir :

• Quels systèmes IA vous utilisez et qui les fournit
• Quelles catégories de données personnelles sont traitées par l'IA
• La base légale du traitement
• Si les données sont utilisées pour l'entraînement (et si oui, sur quelle base)

"Nous utilisons l'IA" n'est pas suffisant. Le bon niveau de précision est : "Nous transmettons le contenu des messages à Anthropic pour traitement dans le cadre de leurs conditions d'API, sous réserve de leur politique de confidentialité et de notre Accord de Traitement de Données."

Construire une position défendable

Une position défendable requiert :

1. Détection PII dans votre pipeline, pour démontrer que les données personnelles sont surveillées et optionnellement bloquées
2. Une piste d'audit, logs immuables des événements de sécurité, conservés pendant la fenêtre appropriée
3. Un DPA avec le fournisseur de modèles, couvrant votre cas d'usage spécifique
4. Des CCS ou équivalent, pour les transferts internationaux
5. Une notice de confidentialité, qui décrit précisément votre traitement IA

Le gateway est le bon endroit pour implémenter les contrôles 1 et 2. Les contrôles 3 à 5 sont du travail juridique que le gateway peut soutenir avec les données d'audit qu'il génère.