Construire des systèmes RAG conformes au RGPD : guide pratique

Un système RAG conforme au RGPD ne traite les données personnelles contenues dans les documents sources, l'index vectoriel et les embeddings que sur une base légale solide, avec minimisation des données, hébergement dans l'UE, cloisonnement des clients et un pipeline de suppression qui efface ensemble chunks et embeddings. Les embeddings issus de textes contenant des données personnelles doivent être traités comme des données personnelles pseudonymisées, et non comme des données anonymes. Ce guide associe les briques techniques aux exigences de protection des données et fournit une checklist à cocher.

Trois réponses rapides :

• Les embeddings ne sont pas anonymes. Des contenus peuvent être reconstruits à partir des vecteurs (inversion d'embeddings de texte). Traite-les comme des données personnelles pseudonymisées.
• Supprimer, c'est effacer le chunk et l'embedding. Si tu supprimes seulement le document source, le vecteur reste et continue de divulguer des contenus via la recherche par similarité.
• L'hébergement dans l'UE et le cloisonnement des clients font partie de la conception dès le départ, ce ne sont pas des options ajoutées après coup : base de données vectorielle souveraine et LLM dans une région UE, filtre ACL à chaque requête.

Remarque : cet article est une analyse technique et ne constitue pas un conseil juridique. Pour les questions juridiques concrètes, adresse-toi à ton service protection des données ou à ton service juridique.

Où apparaissent les données personnelles dans un système RAG

Le RAG (Retrieval-Augmented Generation) récupère de manière ciblée des connaissances dans une source externe avant de générer la réponse et les intègre au prompt. Des données personnelles apparaissent alors à plusieurs endroits simultanément : dans les documents sources (enregistrements CRM, RH, clients), dans les chunks indexés, dans les vecteurs d'embedding, dans la requête elle-même, dans la réponse générée ainsi que dans les logs et les traces. Chacune de ces étapes constitue un traitement distinct au sens du RGPD.

La principale référence allemande est le guide d'orientation de la Conférence sur la protection des données (DSK) consacré aux systèmes RAG d'octobre 2025. Il cite le cloisonnement des clients et un concept de droits et de rôles comme mesures de protection pour la base de données vectorielle et précise que les entrées de la base de données vectorielle et des documents de référence peuvent être supprimées de façon ciblée. En Autriche, c'est l'autorité de protection des données (DSB) qui est compétente, y compris pour les questions de protection des données liées aux systèmes d'IA. La DSK est l'instance qui réunit les autorités allemandes de contrôle de la protection des données au niveau fédéral et des Länder ; ses documents ne sont donc pas contraignants pour la DSB autrichienne, mais ils peuvent y servir d'aide à l'interprétation. En complément, les principes de l'art. 5 du RGPD (limitation des finalités, minimisation des données, exactitude, limitation de la conservation) s'appliquent aussi aux représentations vectorielles dès qu'elles peuvent être rattachées à une personne concernée.

L'erreur centrale : les embeddings ne sont pas une anonymisation

Une erreur courante consiste à déclarer les caches vectoriels comme des « features anonymisées ». C'est contraire à l'état de la recherche. Les attaques par inversion d'embeddings de texte (Morris et al., Text Embeddings Reveal (Almost) As Much As Text, 2023, ainsi que des travaux ultérieurs en 2024–2025) montrent qu'une grande partie du texte original peut être reconstruite à partir des embeddings. S'y ajoutent les attaques par inférence d'appartenance et la réidentification via la recherche par similarité : celui qui possède un texte similaire retrouve la personne indexée.

Conséquence : traite les embeddings issus de textes contenant des données personnelles comme des données personnelles pseudonymisées. Le document de réflexion du commissaire à la protection des données de Hambourg de juillet 2024 estime certes que les embeddings au sein d'un LLM ne contiennent pas de données personnelles, mais il n'évalue expressément que le modèle lui-même. Pour les requêtes de base de données dans le reste du système d'IA, les droits des personnes concernées continuent de s'appliquer. Le document ne couvre donc pas les vecteurs d'une base de données RAG, chacun rattaché à un chunk contenant des données personnelles. Les données pseudonymisées restent des données personnelles pour le responsable du traitement capable de rétablir le lien (considérant 26 du RGPD). Pour un destinataire sans possibilité réaliste de rétablir ce lien, elles ne sont pas nécessairement des données personnelles selon l'arrêt de la CJUE C-413/23 P du 4 septembre 2025. Cela ne change rien au résultat pour ta propre base vectorielle. Selon l'opinion dominante, l'embedding seul n'est pas une pseudonymisation fiable. Ne présente donc jamais les embeddings comme anonymes, ni dans ton marketing ni dans ta documentation, sauf si une méthode avec confidentialité différentielle (differential privacy) et des tests solides le démontre exceptionnellement.

Minimisation des données : détecter les PII et pseudonymiser avant l'embedding

Dans un contexte RAG, la minimisation des données (art. 5, par. 1, point c) est une question de pipeline, pas un filtre appliqué après coup. Les leviers les plus efficaces :

• Détection des PII avant l'indexation : des pipelines NER ou à base de règles (par exemple Microsoft Presidio ou un NER interne) repèrent les noms, adresses et numéros de pièce d'identité dans les chunks avant leur embedding.
• Pseudonymisation des chunks sources : remplacer les identifiants par des pseudonymes stables ; conserver la table de correspondance dans un stockage séparé, protégé par des rôles.
• Ingénierie du contexte par requête : ne récupérer et ne transmettre au prompt que ce dont la tâche a besoin, pas l'ensemble du corpus documentaire. Un reranking sur top_k = 5–10 réduit à la fois les coûts et le volume de données exposées.
• Caviardage des logs : caviarder les logs de prompts et de sorties avant tout stockage durable ; utiliser des identifiants pseudonymes pour les jointures entre systèmes.

Pour la mise en œuvre technique, la DSK renvoie, dans son guide d'orientation sur les mesures techniques et organisationnelles pour les systèmes d'IA (juin 2025), au modèle standard de protection des données (SDM V3.1). Celui-ci traduit les exigences du RGPD en mesures techniques et organisationnelles à travers des objectifs de protection comme la minimisation des données et la non-chaînabilité.

Hébergement dans l'UE pour le LLM et la base vectorielle

La résidence des données est un levier direct sur le risque. L'hébergement dans une région UE réduit le risque lié aux pays tiers, mais chez les fournisseurs américains, il n'élimine pas automatiquement le risque résiduel lié au CLOUD Act. En cas de transfert vers un pays tiers, il faut examiner les clauses contractuelles types (SCC) ainsi qu'une analyse d'impact des transferts (TIA). Les options souveraines de la zone DACH (Allemagne, Autriche, Suisse) et de l'UE évitent largement cette question. Dans le tableau, Jina et BGE-M3 sont des modèles ouverts à exploiter sur ta propre infrastructure, mais pas des fournisseurs souverains de la zone DACH :

Pour les corpus en allemand, le choix du modèle compte aussi : les modèles multilingues comme Cohere Embed v4, Voyage-3 ou Gemini Embedding 002 sont en tête ; les modèles spécifiques à l'allemand (GBERT, GELECTRA, GermanDPR) restent compétitifs dans des domaines on-premise très délimités. BGE-M3 est une solution de repli open source et multilingue venue de Chine (BAAI) ; ce n'est donc pas un modèle souverain de la zone DACH, mais il peut être exploité on-premise.

Concept de suppression et droit à l'oubli : le problème de la réindexation

Le droit à l'effacement (art. 17) est l'exigence la plus difficile à satisfaire dans une stack RAG. L'essentiel est de distinguer deux niveaux :

1. Couche d'inférence (API managée) : au niveau du modèle, il n'existe pas de suppression vérifiable et prête pour la production des données de personnes individuelles sans réentraînement complet. On s'appuie ici sur l'engagement de non-entraînement du contrat de sous-traitance et sur des filtres de sortie qui empêchent la restitution de certains contenus.
2. Couches contrôlées par le déployeur : la base vectorielle, la mémoire des agents, les logs et les éventuels jeux de données de fine-tuning peuvent être entièrement supprimés et portent l'essentiel de la charge de conformité.

Dans la base vectorielle, la règle est la suivante : le Hard Delete supprime le vecteur et les métadonnées sources et constitue le choix par défaut à privilégier. Le Soft Delete se contente de marquer l'entrée et conserve le vecteur ; cela crée un risque de fuite via la recherche par similarité et ne se défend, à la rigueur, qu'avec une durée de conservation très courte. Règle pratique : lors de la suppression des données d'une personne, efface ensemble le document source et l'embedding.

Le « problème de la réindexation » est souvent mal compris. Une réindexation complète n'est nécessaire qu'en cas de changement de modèle d'embedding (sinon, la dérive des embeddings rend les index incomparables). La suppression ciblée de personnes individuelles doit en revanche passer par des identifiants de documents stables, sous forme d'upsert/delete idempotent, sans reconstruire tout l'index. Attribue un subject_id à chaque entrée de mémoire et d'index ; un endpoint DSAR retrouve ainsi tous les enregistrements concernés.

Contrôle d'accès et cloisonnement des clients

La fuite de données classique dans un RAG : un chunk du client A est récupéré pour le client B. Le cloisonnement des clients cité par la DSK allemande peut être mis en œuvre techniquement ainsi :

• Métadonnées filtrables : tenant_id, ACL, source, horodatage pour chaque chunk ; Filterable HNSW (Qdrant, Weaviate, pgvector avec Row-Level Security).
• Défense en profondeur : authentification et résolution du tenant avant la requête, pré-filtre sur tenant_id, double vérification après le retrieval et journal d'audit de chaque accès.
• Une collection ou un namespace par tenant comme alternative au simple filtre de métadonnées, lorsque l'isolation doit être garantie plus fortement.

Base légale et contrat de sous-traitance avec les fournisseurs

Pour transformer des documents contenant des données personnelles en embeddings, il faut une base légale au sens de l'art. 6, généralement l'art. 6, par. 1, point b (contrat) ou point f (intérêt légitime, avec une mise en balance des intérêts documentée). Les catégories particulières de données personnelles (art. 9, par exemple les données de santé ou d'appartenance syndicale) sont en principe interdites et ne peuvent être traitées qu'au titre d'une exception ; dans le doute, exclus-les de l'index.

Chaque brique externe doit être qualifiée au regard de la protection des données. Les fournisseurs de modèles et de cloud agissent le plus souvent comme sous-traitants ; un contrat de sous-traitance (art. 28) est alors obligatoire. Vérifie les points suivants :

• Engagement de non-entraînement : les entrées, sorties, embeddings et données de fine-tuning ne servent pas à entraîner les modèles du fournisseur. Dans les offres entreprise de Microsoft Azure OpenAI, OpenAI, Anthropic, Google Vertex AI, AWS Bedrock, Mistral et Aleph Alpha, c'est contractuellement le réglage par défaut (état 2026) ; les offres grand public diffèrent.
• Chaîne de sous-traitants ultérieurs : fournisseur de modèle, cloud, base vectorielle et, le cas échéant, serveurs MCP et outils d'observabilité, tous nommés et autorisés sans exception (art. 28, par. 2 et 4, du RGPD). Constat d'audit le plus fréquent : des flux d'observabilité ou MCP non couverts.
• Conservation : rétention configurable jusqu'au Zero Data Retention. Valeurs par défaut des fournisseurs (état 2026) : l'API OpenAI et l'API Anthropic conservent les entrées et sorties 30 jours au maximum.
• Fixer de manière contraignante la résidence des données dans l'UE ou en Suisse et exclure tout routage de basculement (failover) vers des pays tiers.

Exemple pratique : RAG de support sur des tickets clients

Une agence de la zone DACH construit pour un client B2B un RAG portant sur 80 000 tickets de support. La démarche, chiffres à l'appui :

1. Ingestion : Presidio-NER pseudonymise les noms, adresses e-mail et numéros de contrat dans les chunks ; la table de correspondance se trouve dans un stockage séparé protégé par RBAC.
2. Chunking et embedding : parsing tenant compte de la mise en page, puis chunks de ~512 tokens ; embedding avec un modèle européen ou de la zone DACH ; upsert dans Qdrant (région UE) avec tenant_id, ticket_id, source, ts comme métadonnées.
3. Requête : authentification + résolution du tenant, retrieval hybride avec top_k = 50, reranking sur top_k = 8, réponse avec citations des sources (identifiants de chunks).
4. Suppression : une DSAR concernant un client déclenche un Hard Delete de tous les vecteurs portant son subject_id et supprime en même temps les chunks sources. Pseudo-code :

```
on dsar_erasure(subject_id):
ids = vector_db.query(filter={"subject_id": subject_id}, only_ids=True)
vector_db.delete(ids) # Embedding + métadonnées (Hard Delete)
source_store.delete(subject_id) # document source
audit_log.write("erasure", subject_id, count=len(ids))
```

5. Gouvernance : AIPD avant la mise en production (selon le guide d'orientation IA de la DSK, elle est requise « dans de nombreux cas » lors de l'utilisation d'applications d'IA ; en Autriche, le règlement DSFA-V liste les traitements pour lesquels une AIPD est requise dans tous les cas), contrat de sous-traitance avec les fournisseurs de cloud et de modèles, rétention de 30 jours sur les logs avec caviardage.

Checklist RGPD à cocher pour le RAG

• Base légale documentée pour chaque traitement (art. 6 ; pour le point f, avec mise en balance des intérêts)
  
• Catégories particulières (art. 9) identifiées et, en l'absence d'exception, exclues de l'index
  
• Détection des PII et pseudonymisation des chunks avant l'embedding
  
• Embeddings classés comme données personnelles pseudonymisées, et non comme anonymes
  
• Hébergement en région UE pour le LLM et la base vectorielle ; en cas de pays tiers, SCC + TIA
  
• Cloisonnement des clients via tenant_id/ACL ; filtre à chaque requête, plus double vérification et journal d'audit
  
• Pipeline de suppression : Hard Delete conjoint du document source et de l'embedding, via des identifiants stables
  
• L'endpoint DSAR retrouve le subject_id dans la base vectorielle, la mémoire et les logs
  
• Politique de rétention avec caviardage pour les prompts, les sorties et les logs
  
• Contrat de sous-traitance avec chaque fournisseur (non-entraînement, chaîne de sous-traitants ultérieurs, résidence des données, rétention)
  
• Citations des sources dans chaque réponse (identifiants de chunks) pour la traçabilité
  
• AIPD réalisée ; risques de membership inference et de data poisoning traités
  

Pour les agences et les décideurs B2B

Dans un RAG, la protection des données n'est pas un audit après coup, mais une décision d'architecture : des briques européennes souveraines, un pipeline de suppression propre et le cloisonnement des clients coûtent le moins cher quand on les prévoit dès le premier jour, pas quand on les ajoute plus tard. Les agences qui font de la conformité au RGPD une caractéristique standard de leurs livrables réduisent le risque de responsabilité de leurs clients et se démarquent sur le marché européen. Agence basée à Vienne, Blck Alpaca accompagne la mise en place de systèmes RAG et d'agents IA conformes au RGPD, de l'AIPD jusqu'au pipeline de suppression en production. Ces contenus ne remplacent pas un conseil juridique ; l'évaluation juridique finale revient à ton service protection des données ou à ton service juridique.