RAG & RGPD : faire de l'IA sur vos documents sans envoyer vos données dehors

En bref

• Un RAG fait transiter vos documents par 3 briques (embeddings, base vectorielle, LLM) : la conformité se joue sur où chacune tourne.
• Avec des API US par défaut, vos extraits peuvent être retenus ou transférés hors UE. Pour des données sensibles, la CNIL oriente vers l'on-premise ou un hébergeur européen.
• Un RAG conforme est possible sans sacrifier la qualité : embeddings open-source en UE, base auto-hébergeable, LLM européen, et surtout réplication des droits d'accès.
• On dose selon la sensibilité réelle, pas par dogme : tout n'a pas besoin d'être souverain.

Le problème, concrètement

« On veut un chatbot sur nos documents, mais nos données ne doivent pas partir aux États-Unis. » C'est la première phrase de la moitié de mes échanges. Et c'est légitime : un RAG mal architecturé envoie, sans qu'on le réalise, chaque passage de vos contrats ou dossiers RH vers des serveurs tiers.

Où passent vraiment vos données

• Les embeddings : pour indexer, chaque extrait de document est transformé en vecteur. Avec une API (OpenAI, Google), cet extrait passe par leurs serveurs. Selon le contrat, il peut être retenu, voire transféré hors UE.
• La base vectorielle : Pinecone ou Weaviate Cloud sont hébergées aux États-Unis par défaut (régions UE en option) ; Qdrant et Chroma peuvent tourner sur votre infrastructure.
• Le LLM : à chaque question, les passages pertinents sont envoyés au modèle pour rédiger la réponse, autre point de sortie potentiel.

Ce que dit le cadre (RGPD, CNIL)

Quand la base contient des données personnelles sensibles ou des volumes importants, la CNIL recommande de privilégier l'hébergement on-premise ou européen : moins de transferts vers des tiers, moins de risque d'exfiltration. S'ajoute l'AI Act qui renforce les obligations de transparence et de gouvernance des données.

Comment faire un RAG conforme (sans le rendre médiocre)

• Embeddings open-source (familles BGE, E5) exécutés sur des serveurs européens : qualité au niveau des API, sans la sortie de données.
• Base vectorielle auto-hébergeable (Qdrant, Chroma) ou pgvector dans votre PostgreSQL européen.
• LLM via un hébergeur européen (ou un modèle ouvert) quand la sensibilité l'exige.
• Répliquer les droits d'accès : si un document est restreint dans votre SI, l'assistant doit l'être aussi. Le RAG ne doit jamais devenir un moyen de contourner les permissions (voir RAG multi-tenant).

La nuance qui fait la différence

Tout n'a pas besoin d'être souverain. Pour une FAQ produit publique, une API managée avec résidence UE et zéro-rétention (offres « entreprise ») est souvent parfaitement acceptable, et plus simple. Le souverain intégral (voir RAG self-hosted) se réserve aux données vraiment sensibles. L'erreur serait de tout sur-sécuriser et de payer une complexité inutile, ou l'inverse.

En pratique

Je cale le niveau de confidentialité à l'audit : je cartographie quelles données touchent quelles briques, et je propose l'architecture la plus simple qui respecte vos contraintes. Souvent un mix : sensible en interne, reste sur des services optimisés en UE.

Sources

• CNIL · Intelligence artificielle & données personnelles
• DGE · Guide de la génération augmentée par récupération (RAG)
• Supabase AI · pgvector & embeddings