RAG et RGPD : conformité de la génération augmentée

Le RAG — Retrieval-Augmented Generation — est devenu le mécanisme standard pour connecter un modèle d’IA générative aux données internes d’une organisation. Au lieu de se fier uniquement à son entraînement, le modèle interroge une base documentaire en temps réel avant de générer sa réponse. Le problème : cette base documentaire contient très souvent des données personnelles — fiches clients, échanges email, dossiers RH, contrats. La CNIL a clairement posé le cadre dans ses recommandations IA publiées en 2024-2025 : le déployeur qui connecte un système d’IA à sa propre base de connaissances via RAG est responsable du traitement des données personnelles qu’elle contient.

Comment fonctionne le RAG du point de vue des données

Pour comprendre les enjeux RGPD, il faut décomposer le pipeline RAG en ses étapes techniques, car chacune implique un traitement de données distinct.

Étape 1 — Ingestion et indexation

Les documents sources (PDF, emails, bases de données, CRM) sont découpés en fragments (chunks), convertis en vecteurs numériques (embeddings) et stockés dans une base vectorielle (Pinecone, Weaviate, Qdrant, pgvector, etc.). Cette étape constitue un traitement de données personnelles au sens de l’Art. 4(2) du RGPD dès lors que les documents contiennent des informations relatives à des personnes identifiées ou identifiables.

Étape 2 — Requête et récupération

Lorsqu’un utilisateur soumet une question, le système transforme cette requête en vecteur, recherche les fragments les plus pertinents dans la base vectorielle, et les injecte dans le contexte du modèle de langage (le prompt enrichi). La requête elle-même peut contenir des données personnelles (« Quel est le statut du contrat de Jean Dupont ? »). Les fragments récupérés en contiennent presque systématiquement.

Étape 3 — Génération de la réponse

Le modèle de langage (GPT-4, Claude, Mistral, Llama, etc.) traite le prompt enrichi et génère une réponse. Cette réponse peut reproduire, synthétiser ou recombiner les données personnelles extraites de la base documentaire.

Chacune de ces trois étapes constitue un traitement au sens du RGPD. Et chacune peut impliquer des acteurs différents — d’où la complexité de la qualification juridique.

Qualification juridique : qui est responsable de quoi

Le déployeur est responsable de traitement

La CNIL l’a confirmé dans ses questions-réponses sur l’IA générative : le déployeur qui choisit de connecter un système d’IA à sa propre base de connaissances (RAG) est responsable du traitement lorsque cette base contient des données personnelles. C’est vous — l’entreprise qui met en place le RAG — qui déterminez les finalités (pourquoi ces données sont traitées) et les moyens essentiels (quels documents, quels utilisateurs, quelles requêtes autorisées).

Le fournisseur du modèle est sous-traitant

Si vous utilisez un modèle via API (OpenAI, Anthropic, Mistral AI, Google), le fournisseur agit en principe comme sous-traitant au sens de l’Art. 28 RGPD. Il traite les données que vous lui transmettez dans le prompt enrichi — mais c’est vous qui décidez quelles données y figurent. Un contrat de sous-traitance conforme à l’article 28 est donc obligatoire.

Attention au cas des modèles qui réutilisent les données d’entrée pour l’entraînement. Certains fournisseurs, dans leurs conditions par défaut, se réservent le droit d’utiliser les données des prompts pour améliorer leurs modèles. Dans ce cas, le fournisseur devient co-responsable de traitement pour cette finalité supplémentaire — ce qui change radicalement l’analyse juridique.

Vérifiez systématiquement les conditions de votre fournisseur sur ce point. OpenAI, par exemple, distingue les conditions API (pas de réutilisation pour l’entraînement par défaut) des conditions ChatGPT grand public (réutilisation possible sauf opt-out). Pour ChatGPT et le RGPD, nous avons publié un guide détaillé.

Le fournisseur de la base vectorielle

Si vous utilisez un service de base vectorielle hébergée (Pinecone, Weaviate Cloud), ce fournisseur est également sous-traitant pour les embeddings qu’il stocke. Ces embeddings ne sont pas directement lisibles, mais la CNIL considère que des vecteurs permettant de retrouver des informations sur des personnes identifiables constituent des données personnelles.

Base légale : quel fondement pour le traitement RAG

Le choix de la base légale dépend du contexte d’utilisation du RAG.

Intérêt légitime (Art. 6(1)(f))

C’est la base légale la plus fréquemment invoquée pour les usages internes : un outil RAG interne permettant aux collaborateurs de rechercher dans la documentation de l’entreprise, d’assister le service client, ou d’accélérer la rédaction de documents. L’intérêt légitime suppose un triple test documenté : intérêt légitime poursuivi, nécessité du traitement, et mise en balance avec les droits des personnes.

Dans mon expérience de conseil, le triple test est souvent bâclé. L’intérêt légitime ne signifie pas « c’est utile pour l’entreprise ». Il faut démontrer concrètement que le RAG est nécessaire à l’objectif poursuivi (pas seulement commode) et que les mesures de protection mises en place (contrôle d’accès, minimisation des données indexées, politique de conservation) compensent l’impact sur les personnes.

Exécution du contrat (Art. 6(1)(b))

Si le RAG est directement nécessaire à l’exécution d’un contrat avec la personne concernée — par exemple, un chatbot client qui accède à l’historique des commandes pour répondre à une réclamation —, cette base légale peut être invoquée. Elle est plus robuste mais plus étroite : le traitement doit être objectivement nécessaire à l’exécution du contrat, pas simplement utile.

Consentement (Art. 6(1)(a))

Le consentement est rarement la base légale appropriée pour un RAG interne. Il peut en revanche être pertinent pour des applications grand public où l’utilisateur choisit activement d’interroger un système alimenté par ses propres données.

Sécurité et mesures techniques : les recommandations de la CNIL

La CNIL, dans ses recommandations sur le développement des systèmes d’IA, a formulé des préconisations spécifiques au RAG en matière de sécurité.

Privilégier le déploiement on-premise

Lorsque la base de connaissances contient des données personnelles sensibles ou un volume important de données, la CNIL recommande de privilégier les solutions de déploiement on-premise (sur site). Cette approche réduit les risques d’exfiltration et les transferts de données vers des tiers.

En pratique, cela signifie héberger le modèle de langage et la base vectorielle sur votre propre infrastructure ou celle d’un hébergeur européen. Des modèles open source comme Mistral 7B, Llama 3, ou les modèles de la famille Qwen permettent un déploiement local performant.

Sécuriser les accès au pipeline

Le RAG ne doit pas devenir un moyen de contourner les contrôles d’accès existants. Si un document n’est accessible qu’à certains collaborateurs dans votre GED, le système RAG doit reproduire cette logique de permissions. C’est le principe du « permission-aware RAG » : les résultats de la recherche vectorielle sont filtrés en fonction des droits de l’utilisateur qui a soumis la requête.

Les failles de contrôle d’accès dans les systèmes RAG sont un risque majeur. J’ai vu des cas où un collaborateur junior pouvait, via le chatbot interne, accéder à des informations RH ou financières auxquelles il n’avait normalement pas accès — simplement parce que ces documents avaient été indexés sans filtre.

Minimiser les données indexées

Le principe de minimisation (Art. 5(1)© RGPD) s’applique directement à la base de connaissances RAG. N’indexez pas l’intégralité de votre SI par facilité. Identifiez précisément quels documents sont nécessaires à la finalité poursuivie et excluez les données non pertinentes.

Concrètement :

• Excluez les dossiers RH, les données de santé, les données financières personnelles sauf nécessité démontrée
• Anonymisez ou pseudonymisez les données avant indexation lorsque l’identification des personnes n’est pas nécessaire
• Mettez en place une politique de conservation des embeddings alignée sur la durée de conservation des documents sources

Journaliser les accès et les requêtes

La CNIL recommande de journaliser les requêtes soumises au système RAG et les documents récupérés, pour permettre un audit a posteriori. Ces logs doivent eux-mêmes respecter le RGPD — notamment en matière de durée de conservation et de contrôle d’accès.

AIPD : quand est-elle obligatoire pour un RAG

Une analyse d’impact (AIPD) au titre de l’Art. 35 est généralement obligatoire pour un système RAG dès lors qu’il réunit au moins deux des critères identifiés par le Comité européen de la protection des données (EDPB, Guidelines WP248) :

• Traitement à grande échelle de données personnelles
• Utilisation innovante ou application de nouvelles solutions technologiques
• Croisement de données provenant de sources multiples
• Données concernant des personnes vulnérables (salariés, patients, etc.)

En pratique, la plupart des déploiements RAG en entreprise cochent au moins deux de ces critères. Il est donc recommandé de réaliser systématiquement une AIPD. Pour la méthodologie, consultez notre guide AIPD pour l’IA.

Droits des personnes : les défis spécifiques du RAG

Droit d’accès et information

Les personnes dont les données sont indexées dans la base RAG doivent être informées de ce traitement (Art. 13/14 RGPD). Si vous indexez des emails clients, des dossiers salariés ou des profils fournisseurs, ces personnes doivent savoir que leurs données alimentent un système d’IA.

Le droit d’accès (Art. 15) pose un défi technique spécifique : comment permettre à une personne de savoir quelles informations la concernant figurent dans une base vectorielle ? Les embeddings ne sont pas directement lisibles. Il faut donc maintenir un mapping entre les fragments indexés et les documents sources — et être capable d’extraire les fragments relatifs à une personne donnée.

Droit à l’effacement et droit d’opposition

Le droit à l’effacement (Art. 17) et le droit d’opposition (Art. 21) imposent de pouvoir supprimer les données d’une personne de la base vectorielle. Techniquement, cela signifie :

• Supprimer les fragments (chunks) contenant des données de la personne
• Supprimer ou recalculer les embeddings correspondants
• S’assurer que le modèle de langage ne mémorise pas les données des prompts précédents (ce qui est généralement le cas pour les API stateless, mais pas pour les systèmes avec mémoire conversationnelle)

Décisions automatisées (Art. 22)

Si le système RAG alimente une prise de décision automatisée ayant des effets juridiques ou significatifs sur les personnes (scoring crédit, présélection de candidats, attribution de prestations), les obligations de l’Art. 22 s’appliquent : droit à l’intervention humaine, droit de contester la décision, et droit d’obtenir une explication. Consultez notre guide sur les décisions automatisées pour le détail de ces obligations.

Transferts de données hors UE

L’utilisation d’API de modèles hébergés aux États-Unis (OpenAI, Anthropic, Google) implique un transfert de données hors de l’UE. Même si les données de la base vectorielle restent en Europe, les fragments injectés dans le prompt sont transmis au fournisseur du modèle pour la génération de la réponse.

Les mécanismes de transfert applicables sont les mêmes que pour tout transfert : EU-US Data Privacy Framework (pour les fournisseurs certifiés), clauses contractuelles types (CCT), ou dérogations de l’Art. 49. Un Transfer Impact Assessment (TIA) est recommandé.

L’alternative : utiliser un modèle hébergé en Europe ou déployé on-premise. C’est l’approche la plus protectrice et celle recommandée par la CNIL pour les données sensibles.

Plan d’action pour un RAG conforme

1. Cartographier les données personnelles présentes dans la base documentaire et identifier les personnes concernées
2. Qualifier les rôles : vous êtes responsable de traitement, le fournisseur du modèle et le fournisseur de la base vectorielle sont sous-traitants — formalisez les DPA
3. Choisir la base légale appropriée (intérêt légitime avec triple test documenté, ou exécution du contrat)
4. Réaliser une AIPD documentant les risques et les mesures compensatoires
5. Sécuriser : contrôle d’accès permission-aware, chiffrement, minimisation des données indexées, journalisation
6. Informer les personnes concernées et prévoir les mécanismes d’exercice des droits (accès, effacement, opposition)
7. Documenter l’ensemble dans le registre des traitements et conserver les preuves de conformité

La mise en conformité d’un pipeline RAG implique de coordonner des aspects juridiques, techniques et organisationnels. C’est exactement le type de travail que Legiscope automatise — de la cartographie des traitements à la gestion des sous-traitants IA.

Ce qu’il faut retenir

• Le déployeur d’un système RAG est responsable de traitement dès que la base de connaissances contient des données personnelles — la CNIL l’a expressément confirmé.
• Chaque étape du pipeline RAG (ingestion, requête, génération) constitue un traitement de données distinct soumis au RGPD.
• Le fournisseur du modèle IA et le fournisseur de la base vectorielle sont des sous-traitants nécessitant un contrat conforme à l’Art. 28.
• Le contrôle d’accès (permission-aware RAG) et la minimisation des données indexées sont des mesures de sécurité critiques.
• Une AIPD est quasi systématiquement obligatoire pour les déploiements RAG en entreprise.

FAQ

Le RAG est-il plus conforme que le fine-tuning au regard du RGPD ?

Le RAG présente un avantage structurel : les données personnelles ne sont pas intégrées dans les poids du modèle, ce qui facilite l’exercice des droits d’effacement et de rectification. Avec le fine-tuning, les données sont absorbées dans le modèle de façon irréversible. Cela dit, le RAG n’est pas exempt d’obligations : la base vectorielle contient les données et doit être gérée conformément au RGPD.

Faut-il informer les salariés si leurs données alimentent un RAG interne ?

Oui. L’Art. 13 du RGPD impose d’informer les personnes concernées de tout traitement de leurs données. Si des emails, dossiers ou documents internes contenant des données de salariés sont indexés dans un système RAG, une information spécifique doit être communiquée — idéalement via une mise à jour de la politique de confidentialité interne et une communication dédiée.

Les embeddings sont-ils des données personnelles au sens du RGPD ?

La CNIL considère que des données permettant de retrouver des informations sur des personnes identifiables constituent des données personnelles, même sous forme de vecteurs numériques. Les embeddings d’un RAG, combinés à la base de fragments correspondante, permettent de reconstituer des informations nominatives. Ils entrent donc dans le champ du RGPD.

Peut-on utiliser un RAG avec des modèles open source pour éviter les transferts hors UE ?

Oui, c’est même l’approche recommandée par la CNIL pour les données sensibles. En déployant un modèle open source (Mistral, Llama, etc.) sur une infrastructure européenne, vous éliminez le risque de transfert lié à l’appel d’API vers des fournisseurs américains. Vous restez cependant soumis à toutes les autres obligations RGPD : base légale, minimisation, sécurité, droits des personnes, AIPD.