Sécurité RAG : quel impact sur vos données sensibles ?

La génération augmentée par récupération (RAG) permet à un modèle d’IA de répondre à des questions en s’appuyant sur les documents et bases de données propres à votre organisation, et non uniquement sur ce qu’il a appris pendant son entraînement. C’est précisément ce qui fait la valeur du RAG — et c’est aussi ce qui en fait un enjeu de sécurité des données à comprendre avant tout déploiement.

Tout système RAG est, à la base, un pipeline qui connecte un modèle de langage à une source de données. Si cette source contient des données sensibles — dossiers clients, informations financières, données de santé protégées, informations non classifiées contrôlées (CUI) — alors le système RAG constitue une nouvelle voie d’accès à ces données, avec ses propres exigences d’authentification, ses propres obligations de traçabilité et sa propre surface d’attaque. Comprendre le fonctionnement mécanique du RAG est simple. Comprendre ce qu’implique sa sécurisation, c’est là que la plupart des organisations accusent un retard.

Génération Augmentée par Récupération

Résumé exécutif

Idée principale : Le RAG améliore la précision des modèles d’IA en récupérant les informations pertinentes dans des sources de données externes avant de générer une réponse. Pour toute organisation déployant le RAG sur des données incluant des informations sensibles ou réglementées, la couche de récupération constitue un point de contrôle d’accès aux données, qui doit être gouverné avec la même rigueur que tout autre système ayant accès à ces données.

Pourquoi c’est important : Les systèmes RAG se déploient rapidement dans les secteurs réglementés — des organisations de santé connectant l’IA aux dossiers patients, des institutions financières connectant l’IA aux données de transactions, des sous-traitants de la défense connectant l’IA aux CUI. Aucun des cadres de conformité régissant ces données — HIPAA, CMMC, RGPD — ne prévoit d’exemption pour l’IA. Si votre système RAG peut récupérer des données sensibles, chaque accès à ces données via le pipeline RAG est soumis aux mêmes obligations réglementaires que tout autre accès — et la plupart des organisations n’ont aucune visibilité sur la conformité de leurs déploiements RAG.

Points clés à retenir

Le RAG connecte un modèle de langage à des données externes au moment de la requête. Plutôt que de s’appuyer uniquement sur les connaissances acquises pendant l’entraînement, un système RAG récupère des documents ou données pertinents dans une source externe — base de données, référentiel documentaire, index de recherche — puis fournit ce contenu au modèle en tant que contexte avant qu’il ne génère une réponse. Cela permet au modèle de répondre à des questions à partir d’informations actuelles, propres à l’organisation ou propriétaires, qui ne faisaient pas partie de ses données d’entraînement.
La source de récupération constitue la frontière de sécurité des données, pas le modèle. Les discussions sur la sécurité de l’IA se concentrent souvent sur le modèle — injection de prompt, jailbreak, comportement du modèle. Pour les systèmes RAG, la frontière de sécurité la plus déterminante est la source de récupération : quelles données le système peut consulter, qui (ou quoi) peut l’interroger, et ce qui régit ce qui est renvoyé. Un modèle au comportement irréprochable peut malgré tout exposer des données sensibles si la couche de récupération ne dispose d’aucun contrôle d’accès.
Le RAG hérite des obligations de conformité liées aux données qu’il récupère. Si un système RAG effectue des recherches dans une source de données contenant des PHI, ce système est soumis aux exigences de garanties techniques de HIPAA — contrôles d’accès, journalisation, chiffrement — que l’organisation le considère ou non comme « un projet d’IA » ou « un système de conformité ». La même logique s’applique aux CUI dans le cadre du CMMC, aux données personnelles dans le cadre du RGPD, et à toute autre catégorie de données réglementées. Déployer le RAG ne crée pas d’exemption de conformité ; cela crée une nouvelle voie d’accès qui hérite de l’obligation existante.
Des sources de récupération non assainies créent une véritable surface d’attaque. Si un système RAG s’appuie sur des sources qui ne sont pas rigoureusement contrôlées — sites web externes, documents non validés, référentiels internes mixtes aux contrôles d’accès incohérents — il peut être manipulé pour récupérer et restituer du contenu malveillant ou non autorisé, un schéma que les chercheurs en sécurité appellent l’injection indirecte de prompt par empoisonnement de la récupération. Les sources de récupération doivent être fiables et soumises à des contrôles d’accès aussi rigoureux que toute autre source de données alimentant un système en production.
Sécuriser le RAG exige de gouverner la couche de données, pas seulement la couche IA. Les contrôles techniques qui rendent un déploiement RAG défendable sont les mêmes que ceux qui régissent tout accès à des données sensibles : un accès authentifié et selon le principe du moindre privilège à la source de récupération ; le chiffrement des données sous-jacentes ; une piste d’audit de ce qui a été récupéré, par quelle requête, et transmis à qui ; et un filtrage des sorties empêchant les catégories de données réglementées d’atteindre des utilisateurs finaux non autorisés à les consulter.

Comment fonctionne le RAG

Un système RAG repose sur deux composants principaux fonctionnant ensemble : un module de récupération (retriever) et un module de génération (generator).

Lorsqu’un utilisateur soumet une requête, le module de récupération recherche dans une source de connaissances externe — base de données vectorielle, référentiel documentaire, base de données structurée — le contenu pertinent pour cette requête. Il renvoie les correspondances les plus pertinentes, généralement sous forme de passages de texte ou d’extraits de documents. Le module de génération, un grand modèle de langage, reçoit ensuite à la fois la requête initiale et le contenu récupéré en guise de contexte, puis produit une réponse ancrée dans ces informations récupérées plutôt que de s’appuyer uniquement sur ce qu’il a appris pendant son entraînement.

Cette architecture résout deux problèmes propres aux modèles de langage pris isolément. Premièrement, elle répond au problème de la date limite des connaissances — un modèle entraîné sur des données jusqu’à une certaine date n’a aucune connaissance de ce qui s’est passé après, alors qu’un système RAG peut récupérer des informations actuelles au moment de la requête. Deuxièmement, elle atténue significativement le problème des hallucinations — en ancrant les réponses dans des sources récupérées plutôt que dans la représentation interne (parfois erronée) des faits par le modèle, le RAG réduit la fréquence des réponses affirmées avec assurance mais factuellement fausses, sans toutefois éliminer totalement le phénomène.

Le RAG est ce qui permet à un chatbot IA de répondre à des questions sur les politiques internes d’une entreprise, à un système de support client de s’appuyer sur la documentation produit actuelle, ou à un outil de recherche de synthétiser des informations à partir d’un ensemble spécifique de documents plutôt que depuis l’ensemble d’Internet.

Pourquoi le RAG est une question de sécurité des données, pas seulement d’architecture IA

L’étape de récupération est précisément le moment où se produit l’exposition des données d’un système RAG. Chaque requête soumise au système déclenche une recherche dans la source de récupération — et tout ce que contient cette source est potentiellement exposé à quiconque peut interroger le système.

Cela crée un risque précis et souvent sous-estimé : les contrôles d’accès sur la source de données sous-jacente doivent être au moins aussi rigoureux que ceux appliqués au système RAG lui-même, car ce dernier constitue en réalité une nouvelle interface vers ces données. Une organisation qui restreint soigneusement l’accès direct à une base de données contenant des PHI, mais qui déploie ensuite un système RAG s’appuyant sur cette même base sans contrôles d’accès équivalents, a créé une nouvelle voie d’accès, moins gouvernée, vers les mêmes données réglementées.

Ce problème s’aggrave lorsque les systèmes RAG s’appuient sur des sources multiples et hétérogènes — certaines contenant des données réglementées, d’autres non, souvent avec des contrôles d’accès incohérents d’une source à l’autre. Sans gouvernance unifiée, un système RAG conçu pour un usage interne général peut exposer involontairement des données réglementées à des utilisateurs qui n’ont jamais été autorisés à les consulter, car la couche de récupération ne fait pas de distinction entre une page de wiki interne publique et un document contenant des CUI.

Ce qu’exige réellement la sécurisation d’un déploiement RAG

Un accès à la récupération authentifié et fondé sur le moindre privilège. L’accès du système RAG à sa source de récupération doit être limité à ce que l’utilisateur ou l’agent à l’origine de la requête est réellement autorisé à consulter — et non une connexion globale récupérant l’intégralité de la base de données sous-jacente, quel que soit le demandeur. Ce sont des politiques de contrôle d’accès basées sur les attributs (ABAC), appliquées au niveau de la couche de récupération et non seulement au niveau applicatif, qui rendent cela réellement applicable.

Des sources de récupération contrôlées et assainies. Les sources de récupération doivent être répertoriées sur liste blanche, internes et soumises à des contrôles d’accès — et non ouvertes à du contenu externe arbitraire susceptible de manipuler les résultats du système par empoisonnement de la récupération. Mélanger des documents internes fiables avec des sources externes non validées au sein d’un même index de récupération est l’une des façons les plus courantes dont les déploiements RAG introduisent des risques inutiles.

Le chiffrement de la source de données sous-jacente. Quelle que soit la source dans laquelle le système RAG effectue ses recherches — base de données vectorielle, entrepôt documentaire, base de données structurée — celle-ci doit être chiffrée au repos et en transit selon les mêmes standards appliqués à tout autre système hébergeant des données sensibles ou réglementées. L’AES-256 associé à des modules cryptographiques validés FIPS 140-3 constitue la référence fédérale actuelle.

Le filtrage des sorties pour les catégories de données réglementées. Même avec un accès à la récupération bien gouverné, une couche supplémentaire de filtrage des sorties — bloquant les champs réglementés ou les informations confidentielles avant qu’une réponse n’atteigne un utilisateur final ou un système en aval — offre une défense en profondeur contre des contrôles d’accès mal configurés ou des schémas de requêtes imprévus.

Une piste d’audit complète de l’activité de récupération. Chaque événement de récupération — ce qui a été demandé, ce qui a été renvoyé, par qui et quand — doit être journalisé dans un format qui permette à la fois la surveillance de sécurité et le reporting de conformité. Pour les systèmes RAG accédant à des données réglementées, cette piste d’audit est ce qui permet de démontrer, auprès d’un auditeur ou d’un régulateur, que l’accès a été correctement délimité et surveillé.

Considérations de conformité RAG selon les cadres réglementaires

Un système RAG accédant à des données réglementées n’est pas évalué selon un standard différent de celui appliqué à tout autre système accédant à ces mêmes données — les exigences du cadre réglementaire s’appliquent directement.

Santé (HIPAA). Un système RAG qui récupère des données depuis une source contenant des ePHI est soumis aux exigences de garanties techniques de la règle de sécurité HIPAA — contrôles d’accès, contrôles d’audit et chiffrement — appliquées directement au pipeline de récupération. Découvrez comment les amendements proposés en 2025 à la règle de sécurité affectent les systèmes d’IA accédant aux PHI.

Défense (CMMC). Un système RAG accédant à une source de données contenant des CUI doit répondre aux mêmes exigences de contrôle NIST SP 800-171 — contrôle d’accès, audit et responsabilité, protection des systèmes et des communications — que celles applicables à tout autre système traitant des CUI. Consultez le guide de conformité CMMC de Kiteworks.

Confidentialité des données (RGPD et cadres similaires). Si un système RAG récupère des données personnelles, les mêmes exigences de base légale, de minimisation des données et de droits des personnes concernées, applicables à tout traitement de ces données, s’appliquent également à la récupération et à la restitution effectuées par le RAG.

Comment Kiteworks sécurise le RAG et les autres modes d’accès aux données par l’IA

Kiteworks aborde la sécurité du RAG au niveau où se situe le risque réel : la source de données à laquelle accède le système RAG, et non le modèle de langage qui génère les réponses.

L’AI Data Gateway de Kiteworks crée une couche d’accès gouvernée entre les systèmes d’IA — y compris les pipelines RAG — et les données sensibles auxquelles ils accèdent. Chaque demande de récupération est authentifiée selon des politiques de contrôle d’accès basées sur les attributs, garantissant qu’un système RAG ne peut récupérer que les données que l’utilisateur ou l’agent à l’origine de la requête est réellement autorisé à consulter. Les données consultées via la passerelle sont chiffrées à l’aide de modules cryptographiques validés FIPS 140-3, avec des clés de chiffrement détenues par le client, et chaque événement de récupération est journalisé dans une piste d’audit immuable et consolidée — la même piste d’audit qui couvre les canaux e-mail sécurisé, partage sécurisé de fichiers et transfert de fichiers géré de Kiteworks.

Pour les organisations qui développent des systèmes RAG sur des données réglementées — PHI, CUI, données financières ou autres catégories de données sensibles — cela signifie que la couche de récupération hérite du dispositif de conformité déjà en place chez Kiteworks : autorisation FedRAMP Moderate, prise en charge des exigences CMMC 2.0 niveau 2, et garanties techniques alignées sur HIPAA, plutôt que d’imposer la construction d’une architecture de sécurité distincte, spécifique au cas d’usage IA.

Pour découvrir comment Kiteworks sécurise le RAG et les autres modes d’accès aux données par l’IA selon vos exigences de conformité spécifiques, planifiez une démonstration personnalisée.

Foire aux questions

Le RAG est une technique qui permet à un modèle de langage IA de récupérer des informations pertinentes dans une source de données externe — base de données, référentiel documentaire ou index de recherche — avant de générer une réponse. Plutôt que de s’appuyer uniquement sur ce qu’il a appris pendant son entraînement, le modèle utilise le contenu récupéré comme contexte, ce qui lui permet de répondre à des questions à partir d’informations actuelles, propres à l’organisation ou propriétaires, et réduit la fréquence des réponses erronées énoncées avec assurance. Le RAG est ce qui permet à un système d’IA de répondre avec précision à des questions sur les documents ou politiques internes d’une entreprise, plutôt que de deviner à partir de connaissances générales issues de son entraînement.

Le RAG en lui-même est une technique, pas un risque en soi — mais il crée une nouvelle voie d’accès aux données qui doit être sécurisée comme tout autre système accédant à des données sensibles. Le risque survient lorsque la source de récupération contient des données réglementées ou sensibles et ne dispose pas de contrôles d’accès équivalents à ceux qui régiraient normalement ces données — ce qui signifie qu’un système RAG peut exposer involontairement des données à des utilisateurs qui l’interrogent, même s’ils n’étaient pas autorisés à y accéder directement. Les systèmes RAG s’appuyant sur des sources non vérifiées ou de fiabilité mixte sont également vulnérables à l’empoisonnement de la récupération, où du contenu malveillant présent dans la source est utilisé pour manipuler les résultats du système.

Le fine-tuning modifie les paramètres internes d’un modèle à l’aide de données d’entraînement supplémentaires, changeant durablement son comportement. Le RAG, lui, ne modifie en rien le modèle — il récupère du contenu externe pertinent au moment de la requête et le fournit en contexte, laissant le modèle sous-jacent inchangé. Le RAG est généralement plus rapide à mettre en œuvre, plus facile à actualiser (la mise à jour de la source de récupération prend effet immédiatement, sans nouvel entraînement) et plus transparent (les sources récupérées peuvent être affichées aux côtés de la réponse), ce qui en fait l’approche la plus courante pour connecter des systèmes d’IA aux données actuelles d’une organisation.

Le RAG ne crée pas de nouvelles obligations de conformité — il étend les obligations existantes à une nouvelle voie d’accès. Si un système RAG récupère des données depuis une source contenant des ePHI, ce pipeline de récupération est soumis aux garanties techniques de la règle de sécurité HIPAA, au même titre que tout autre système accédant à ces données. S’il récupère des données depuis une source contenant des CUI, les exigences de contrôle NIST SP 800-171 du CMMC s’appliquent à cette voie d’accès. Les organisations traitent parfois les déploiements RAG comme relevant purement d’une initiative IA, et négligent le fait que les obligations réglementaires attachées aux données ne disparaissent pas simplement parce qu’un système d’IA effectue la récupération.

Cinq contrôles permettent de traiter les risques essentiels : un accès authentifié et fondé sur le moindre privilège à la source de récupération, afin que le système ne récupère que les données que l’utilisateur à l’origine de la requête est autorisé à consulter ; des sources de récupération contrôlées et assainies, pour prévenir l’empoisonnement de la récupération par du contenu non validé ; le chiffrement de la source de données sous-jacente, au repos comme en transit ; un filtrage des sorties bloquant les catégories de données réglementées avant qu’elles n’atteignent des destinataires non autorisés ; et une piste d’audit complète et immuable de l’activité de récupération, permettant à la fois la surveillance de sécurité et le reporting de conformité. Les organisations qui mettent en œuvre ces contrôles au niveau de la couche de données — plutôt que de s’appuyer uniquement sur des garde-fous au niveau du modèle — construisent des systèmes RAG défendables face à un examen réglementaire.

Retour au Glossaire Risque & Conformité