Le guide de conformité RGPD pour vos projets RAG : base légale, minimisation, données personnelles dans les embeddings et les prompts, droit à l'effacement qui cascade jusqu'aux vecteurs, sous-traitants et articulation avec l'AI Act.
Brancher un assistant RAG sur la documentation interne d'une entreprise, c'est presque toujours brasser des données personnelles : noms dans des comptes-rendus, coordonnées de clients dans des tickets, identités dans des contrats, signatures au bas des e-mails. Le RGPD ne s'arrête pas à la porte de votre projet d'IA — au contraire, l'IA générative en amplifie les enjeux, parce qu'elle duplique, vectorise et parfois exfiltre ces données vers des modèles externes. La bonne nouvelle : un RAG bien conçu est aussi un RAG conforme. La conformité n'est pas une couche juridique bolté après coup, c'est une propriété d'architecture qui se décide à l'ingestion, pas au moment du contrôle de la CNIL.
Ce guide déroule, point par point, la mise en conformité RGPD d'un projet RAG — du choix de la base légale jusqu'à l'effacement qui cascade dans les embeddings, en passant par l'AIPD, le registre des sous-traitants et l'articulation avec l'EU AI Act. L'objectif n'est pas de vous transformer en juriste, mais de vous donner les décisions d'ingénierie qui rendent un système défendable.
Premier réflexe : cartographier où vivent les données personnelles dans votre pipeline. Elles sont partout, souvent là où on ne les attend pas :
Prenez un cas concret. Une entreprise indexe ses comptes-rendus d'entretiens annuels pour qu'un assistant aide les managers à préparer leurs revues. Chaque document contient le nom du salarié, des appréciations, parfois des informations de santé (un arrêt mentionné), des éléments de rémunération. À l'ingestion, ce document devient une trentaine de chunks, chacun vectorisé en un embedding de 1536 ou 3072 dimensions, stocké dans un index. La question d'un manager (« Quels étaient les axes de progrès de Jean Dupont l'an dernier ? ») devient un prompt qui contient le nom et rapatrie les passages les plus sensibles du dossier. On a là, sur une seule requête, du traitement de données potentiellement sensibles, une diffusion à un modèle, et une trace persistante. Si ce modèle est une API hors UE, la donnée a voyagé.
Une erreur classique : croire que vectoriser « anonymise » les données. Un embedding est une transformation du contenu, pas une suppression. Des travaux de recherche ont montré qu'on peut reconstruire une partie substantielle du texte d'origine à partir de ses seuls vecteurs (attaques d'inversion d'embeddings). S'il dérive de données personnelles, l'embedding reste soumis au RGPD.
Tant que cette cartographie n'est pas faite, tout le reste est de l'aveuglement. C'est aussi elle qui alimentera votre registre des traitements et, le cas échéant, votre AIPD.
Aucun traitement de données personnelles n'est licite sans base légale. C'est l'article 6 du RGPD, et il n'admet pas d'exception : pas de base légale, pas de traitement. Pour un RAG d'entreprise, les bases pertinentes sont en pratique au nombre de trois ou quatre.
C'est la base la plus souvent retenue pour un outil interne de productivité. Mais l'intérêt légitime n'est pas un blanc-seing : il impose un test de mise en balance (balancing test) en trois temps, qu'il faut documenter par écrit.
Concrètement : un assistant qui interroge la base documentaire technique et les procédures internes passe facilement le test. Un assistant qui aspire les e-mails personnels de l'ensemble des salariés pour « tout savoir » échoue à la mise en balance — l'attente raisonnable d'un salarié n'est pas que ses échanges soient vectorisés et exposés à des collègues via un chatbot.
Le consentement est tentant mais piégeux en contexte employé. Le lien de subordination fragilise sa validité : un salarié n'est pas en position de refuser librement quand l'employeur le sollicite. La CNIL et le CEPD sont constants là-dessus. Pour un outil interne, on retiendra donc plutôt l'intérêt légitime (pour un outil de confort) ou l'exécution du contrat de travail / l'obligation légale (pour un traitement réellement nécessaire à la relation de travail). Réservez le consentement aux cas où il est réellement libre et révocable sans conséquence.
Un assistant qui traite les données strictement nécessaires à la fourniture d'un service contractuel (par exemple répondre aux clients à partir de leurs propres dossiers) peut s'appuyer sur l'exécution du contrat. L'obligation légale couvre des cas plus rares (conservation de documents comptables, par exemple).
Identifiez la base légale pour chaque catégorie de données ingérée, pas pour « le projet RAG » en bloc. La documentation technique relève souvent de l'intérêt légitime ; les dossiers clients, de l'exécution du contrat ; les données RH sensibles peuvent exiger une base distincte, voire être exclues du corpus. C'est la fondation : tout le reste en découle.
Le principe de minimisation (article 5.1.c) est aussi une bonne pratique d'ingénierie. N'ingérez que les documents réellement utiles à l'usage visé. Un corpus pléthorique :
En pratique, la minimisation se décline en plusieurs leviers concrets :
Minimiser sert deux maîtres à la fois : la conformité RGPD et la qualité du RAG. Un corpus resserré et pertinent est plus sûr et plus performant. Le bruit que vous retirez pour la conformité est aussi le bruit qui dégradait vos résultats de récupération.
C'est l'exigence la plus souvent ratée techniquement. Quand une personne exerce son droit à l'effacement (article 17), supprimer le document source ne suffit pas. L'information vit aussi dans :
La condition technique de l'effacement, c'est la traçabilité de la filiation : chaque embedding doit savoir de quel chunk il vient, et chaque chunk de quel document. Un schéma relationnel simple suffit, à condition que les clés étrangères soient posées dès le départ. Avec PostgreSQL et pgvector, cela ressemble à :
CREATE TABLE documents (
id BIGSERIAL PRIMARY KEY,
source_ref TEXT NOT NULL, -- identifiant côté source (GED, ticket…)
subject_id TEXT, -- personne concernée, si identifiable
created_at TIMESTAMPTZ DEFAULT now()
);
CREATE TABLE document_chunks (
id BIGSERIAL PRIMARY KEY,
document_id BIGINT NOT NULL REFERENCES documents(id) ON DELETE CASCADE,
content TEXT NOT NULL,
embedding vector(1536) -- index HNSW par-dessus
);
CREATE INDEX ON document_chunks USING hnsw (embedding vector_cosine_ops);
Le ON DELETE CASCADE est ici le détail qui change tout : supprimer une ligne documents purge automatiquement ses chunks et leurs embeddings, et l'index HNSW est mis à jour en conséquence. L'effacement d'une personne concernée devient alors une requête déterministe :
-- Effacement de tous les documents rattachés à une personne
DELETE FROM documents WHERE subject_id = $1;
-- chunks + embeddings supprimés en cascade, index nettoyé
Si vous stockez vos vecteurs dans une base séparée (moteur vectoriel dédié) plutôt que dans PostgreSQL, vous perdez le CASCADE gratuit : il faut alors propager la suppression vous-même, par identifiant de document, et vous assurer que le moteur supprime réellement le vecteur de l'index (et pas seulement le marque comme supprimé en attendant un compactage). C'est l'un des arguments en faveur d'un stockage vectoriel dans la base transactionnelle.
Le RGPD vous demande non seulement d'effacer, mais de pouvoir le prouver (principe d'accountability, article 5.2). Tracez chaque effacement dans un journal dédié : qui a demandé, quand, sur quel subject_id, combien de documents/chunks supprimés, et la confirmation de purge des caches et sauvegardes. Attention au paradoxe : ce journal de preuve ne doit pas lui-même réintroduire les données effacées — on y consigne des identifiants techniques et un horodatage, pas le contenu supprimé.
N'oubliez pas les angles morts : les sauvegardes (définissez une politique de réécrasement plutôt que de conserver éternellement des backups contenant des données effacées), les caches de réponses, et les historiques de conversation où un extrait du document a pu être restitué à un utilisateur.
Effacement demandé
─► supprimer le document source
─► supprimer les chunks rattachés (CASCADE)
─► supprimer les embeddings correspondants + index
─► purger caches de réponses et résultats mémorisés
─► planifier l'expiration dans les sauvegardes
─► tracer l'opération dans le journal de preuve
Concevez l'effacement dès le départ. Rattraper a posteriori une architecture où les embeddings ne sont pas reliés à leur source est douloureux — il faut parfois re-vectoriser tout le corpus pour reconstruire la filiation — et expose à des manquements coûteux.
Chaque requête envoie au modèle la question de l'utilisateur et le contexte récupéré, qui peut contenir des données personnelles. Si le modèle est une API hors UE, ces données sortent de votre périmètre au moment précis de l'inférence — c'est le point de fuite le plus fréquent et le plus sous-estimé. Deux parades complémentaires.
Avant d'envoyer le contexte à un modèle externe, on détecte les entités personnelles (noms, e-mails, numéros, IBAN…) et on les remplace par des jetons stables. « Stable » est le mot important : le même nom doit donner le même jeton dans tout le prompt, sinon le modèle perd le fil. Exemple :
Prompt brut :
« Jean Dupont (jean.dupont@acme.fr) a signalé un bug le 12/03.
Relance demandée par Marie Durand. »
Prompt pseudonymisé envoyé au modèle :
« [PERSONNE_1] ([EMAIL_1]) a signalé un bug le 12/03.
Relance demandée par [PERSONNE_2]. »
À la réception, on re-substitue les jetons par les vraies valeurs avant d'afficher la réponse à l'utilisateur autorisé. Le modèle externe, lui, n'a jamais vu les identités. On garde une table de correspondance jeton → valeur côté UE, en mémoire de session, jamais persistée chez le sous-traitant.
Cette technique a ses limites : elle ne rend pas les données anonymes au sens du RGPD (le RAG reste capable de ré-identifier, donc on est dans la pseudonymisation, qui demeure un traitement de données personnelles), elle peut échouer sur des entités mal détectées ou des données indirectement identifiantes (« le directeur financier de la filiale de Lyon »), et elle dégrade parfois la qualité de la réponse. Mais elle réduit fortement l'exposition au point de fuite le plus courant.
Toutes les requêtes ne se valent pas. Mettez en place un routage : les requêtes dont le contexte contient des données sensibles (santé, opinions, données RH) sont traitées par un modèle EU ou auto-hébergé (Mistral sur La Plateforme EU, un modèle ouvert type Llama 4 ou Mistral Small 3 sur OVHcloud ou Scaleway) ; les requêtes anodines peuvent aller vers une API externe plus performante. Le routage repose sur la classification du contexte récupéré, pas seulement de la question — c'est le contexte qui porte le risque.
Chaque fournisseur qui traite vos données pour votre compte est un sous-traitant au sens du RGPD (article 28). Le périmètre est plus large qu'on ne le croit.
Le réflexe est de ne penser qu'au LLM. Or la chaîne complète d'un RAG inclut souvent :
Chacun doit figurer dans votre registre des sous-traitants, avec sa localisation, la nature des données traitées, et le DPA (Data Processing Agreement) signé. Un outil d'observabilité qui capture les prompts en clair et les stocke aux États-Unis est un transfert hors UE que beaucoup d'équipes oublient.
Pour tout transfert hors de l'Espace économique européen, il faut une garantie appropriée (chapitre V du RGPD) :
Vérifiez aussi les engagements de non-rétention et de non-réutilisation pour l'entraînement : la plupart des offres « entreprise » des grands fournisseurs s'engagent à ne pas entraîner sur vos données et à ne pas les conserver au-delà d'un court délai anti-abus, mais ce n'est pas le cas des offres grand public. La frontière entre les deux est une source classique de fuite.
Le fournisseur de votre modèle, de votre hébergement vectoriel, de votre outil d'observabilité, de votre OCR : tous peuvent être des sous-traitants. Cartographiez la chaîne complète, pas seulement le LLM, et tenez le registre à jour à chaque nouvel outil branché sur le pipeline.
L'analyse d'impact relative à la protection des données (AIPD, ou DPIA en anglais — article 35) est obligatoire lorsqu'un traitement est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes.
Le RGPD et les lignes directrices du CEPD posent des critères. Une AIPD est requise notamment en cas d'évaluation/scoring à grande échelle, de traitement à grande échelle de données sensibles, de surveillance systématique, ou de combinaison de jeux de données. La CNIL publie en outre une liste de traitements qui imposent une AIPD. Pour un RAG, plusieurs situations la déclenchent typiquement :
À l'inverse, un assistant interrogeant uniquement de la documentation technique sans données personnelles significatives ne déclenche en général pas d'AIPD — mais documentez ce raisonnement (le « pourquoi pas » fait partie de l'accountability).
Une AIPD bien faite décrit :
L'AIPD est un document vivant : on la met à jour quand l'architecture change (nouveau modèle, nouvelle source de données, nouveau sous-traitant). C'est aussi votre meilleur outil de dialogue avec le DPO.
Les journaux de conversation et les historiques de requêtes contiennent des données personnelles (la question elle-même, le contexte rapatrié, parfois l'identité de l'utilisateur) et ne doivent pas s'accumuler indéfiniment (article 5.1.e). Définissez et appliquez des politiques de rétention concrètes. Quelques ordres de grandeur raisonnables, à adapter à votre contexte :
La mise en œuvre passe par des purges automatiques (tâches planifiées) plutôt que par des suppressions manuelles qu'on oublie. Une donnée qu'on ne conserve plus est une donnée qu'on n'a plus à protéger, plus à effacer sur demande, et qui ne fuitera pas.
Le RGPD et l'EU AI Act se cumulent : ils ne se substituent pas l'un à l'autre. Le premier protège les données personnelles (base légale, minimisation, droits des personnes, AIPD) ; le second encadre le système d'IA lui-même (classification par niveau de risque, documentation technique, transparence, supervision humaine).
Pour situer le calendrier : l'AI Act est entré en vigueur le 1er août 2024 ; les pratiques interdites et les obligations de littératie IA s'appliquent depuis février 2025 ; les obligations des modèles d'usage général (GPAI) depuis août 2025 ; le gros des obligations pour les systèmes à haut risque s'applique en août 2026, et certaines en 2027. L'approche est par niveaux de risque : inacceptable, élevé, limité (transparence), minimal.
La plupart des assistants RAG internes relèvent du niveau transparence limitée : il faut alors informer les utilisateurs qu'ils interagissent avec une IA et, le cas échéant, marquer les contenus générés. Mais un RAG qui interviendrait dans une décision à haut risque (tri de candidatures, évaluation d'accès à un service essentiel) bascule dans la catégorie « haut risque » et hérite d'obligations bien plus lourdes : gestion des risques, qualité des données, documentation technique, journalisation, supervision humaine.
En pratique, les deux régimes se nourrissent l'un l'autre. La cartographie des données de votre AIPD alimente la documentation technique de l'AI Act ; l'analyse de risque de l'AI Act recoupe l'analyse des risques pour les personnes de l'AIPD. Mais une conformité ne vaut pas l'autre : avoir fait une AIPD ne vous exempte pas des obligations de transparence de l'AI Act, et inversement.
ON DELETE CASCADE ou propagation explicite), purge des index et cachesLa conformité RGPD d'un RAG n'est pas une couche juridique posée à la fin du projet : c'est une série de décisions d'architecture, de l'ingestion à l'inférence. Identifier sa base légale et écrire son test de mise en balance, minimiser le corpus, relier chaque embedding à sa source pour permettre l'effacement et le prouver, pseudonymiser ce qui sort et router selon la sensibilité, cartographier et encadrer ses sous-traitants, réaliser une AIPD quand le risque l'exige, articuler le tout avec l'AI Act : chacun de ces choix protège vos utilisateurs et renforce votre système. Le secret le moins partagé du RGPD, c'est qu'une architecture conforme est presque toujours une meilleure architecture — plus maîtrisée, plus traçable, plus digne de confiance. La conformité n'est pas le prix de l'IA en entreprise : c'est sa condition de durabilité.
Les agents IA gérés par les grands hyperscalers américains posent un problème de conformité que beaucoup de DSI préfèrent ignorer. Faisons le point.
Anonymiser ou pseudonymiser avant de vectoriser ? La distinction RGPD, pourquoi l'anonymisation parfaite est rare sur du texte libre, les techniques (NER, pseudonymisation cohérente) et les réflexes à adopter.
Calendrier réel des obligations de l'EU AI Act (2025-2027), niveaux de risque, place d'un assistant RAG d'entreprise et checklist de conformité concrète — sans jargon, pour DPO et équipes produit.
Démarrez gratuitement. Premier audit Knowledge Pulse en 60 secondes.
Démarrer gratuitement