Pourquoi les implémentations RAG échouent aux audits de sécurité — et comment en créer une qui passe le test

La démonstration a fonctionné. Le pilote était convaincant. Le business case était solide. Puis l’audit de sécurité a commencé.

Pour de nombreuses équipes IA en entreprise, c’est à ce moment que les projets de Retrieval Augmented Generation (RAG) s’arrêtent — non pas parce que la technologie a échoué, mais parce que l’architecture qui a permis une excellente démo n’est pas celle qui répond aux exigences de l’équipe sécurité pour un système d’accès aux données en production.

Ce schéma d’échec est suffisamment récurrent pour être prévisible : l’équipe IA construit un système optimisé pour la qualité de la recherche et la rapidité de développement ; l’équipe sécurité l’évalue comme un système accédant à grande échelle à des données sensibles de l’entreprise ; les deux points de vue aboutissent à des conclusions différentes sur le niveau de préparation.

Cet article s’adresse aux VP AI/ML Engineering et aux RSSI qui souhaitent comprendre ce schéma, combler l’écart et mener un projet RAG en production sans devoir relancer un audit de sécurité.

Résumé Exécutif

Idée principale : Les implémentations RAG échouent à l’audit de sécurité pour six raisons prévisibles, toutes liées à la même cause racine : la couche de recherche a été considérée comme une infrastructure et non comme un système d’accès aux données gouverné. Les équipes sécurité ne bloquent pas RAG parce qu’elles s’opposent à l’IA — elles le bloquent parce que le composant de recherche a le profil d’accès aux données d’un système privilégié, mais la gouvernance d’un outil de développement. Pour corriger ces six modes d’échec, il faut ajouter une couche de gouvernance à l’architecture de recherche avant l’audit de sécurité, et non pendant.

Pourquoi c’est important : Chaque cycle passé à corriger un projet RAG en audit de sécurité est un cycle où il ne génère pas de valeur métier. Le coût n’est pas seulement le retard — c’est aussi la crédibilité du programme IA auprès des parties prenantes qui ont validé l’initiative, et la relation entre l’équipe IA et la fonction sécurité qui gouvernera tous les futurs projets IA. Concevoir RAG correctement dès le départ n’est pas un simple exercice de conformité ; c’est ainsi que les équipes IA instaurent la confiance qui accélère les projets suivants.

5 Points Clés à Retenir

1. Les équipes sécurité évaluent les pipelines RAG comme des systèmes d’accès aux données, pas comme des outils IA. Les critères d’évaluation sont les mêmes que pour tout système accédant à grande échelle à des données sensibles : authentification, contrôles d’accès, journalisation d’audit, supervision et gestion des incidents. Les équipes IA qui présentent RAG comme une application de productivité répondent à des questions que l’équipe sécurité ne pose pas.
2. Les six modes d’échec les plus courants lors des audits de sécurité sont tous architecturaux, pas liés à la configuration. On ne peut pas les corriger en ajoutant de la documentation ou en ajustant des règles. Ils nécessitent des modifications de l’architecture d’authentification, de l’autorisation de la couche de recherche, de l’infrastructure de journalisation et de l’intégration de la supervision — des changements bien plus faciles à effectuer avant la construction de la couche de recherche qu’après le pilote.
3. L’écart entre ce que demande la sécurité et ce que construisent les équipes IA n’est pas un problème de communication — c’est un problème de priorisation. La qualité de la recherche, l’expérience développeur et le délai pour la démo sont optimisés lors de la construction ; les contrôles d’accès, la journalisation d’audit et la supervision ne le sont pas. Résultat : un système performant sur les axes mesurés par l’équipe IA, mais défaillant sur ceux mesurés par l’équipe sécurité.
4. La définition du périmètre d’autorisation avant la recherche est la décision architecturale qui résout le plus de questions de sécurité à la fois. Lorsque la couche de recherche applique un RBAC et un ABAC à chaque requête et limite la recherche à ce que l’utilisateur authentifié est autorisé à consulter, on élimine le mode d’échec lié aux droits excessifs, on répond à la question de l’application des classifications de données, et on satisfait au test d’équivalence des autorisations.
5. Une couche de recherche gouvernée n’est pas une contrainte pour RAG — c’est ce qui fait la différence entre un projet RAG qui passe en production et un autre qui tourne en boucle à l’audit de sécurité. Le modèle AI Data Gateway fournit cette couche de gouvernance sous forme de composant déployable plutôt qu’un développement sur mesure, permettant aux équipes IA de répondre aux exigences de sécurité sans reconstruire toute l’architecture de recherche.

Pourquoi les audits de sécurité bloquent les projets RAG : la déconnexion structurelle

La déconnexion entre les équipes IA et sécurité sur RAG est structurelle, pas interpersonnelle. Les équipes IA construisent des pipelines RAG avec des frameworks — LangChain, LlamaIndex, Haystack — optimisés pour la qualité de la recherche et la rapidité de développement. Ces frameworks gèrent très bien l’indexation vectorielle, l’embedding, la recherche sémantique et l’assemblage du contexte. Mais ils ne gèrent pas l’autorisation par utilisateur, la journalisation par document, l’application des labels de sensibilité ou l’intégration SIEM — car ce ne sont pas des problèmes de qualité de recherche. Ce sont des problèmes de gouvernance, et les frameworks ont été conçus par des personnes cherchant à résoudre des problèmes de qualité de recherche.

Quand une équipe sécurité audite le système, elle applique le même cadre d’évaluation qu’à tout nouveau système d’accès aux données. Elle demande : qui peut accéder à quelles données, comment cet accès est-il contrôlé, comment est-il journalisé, comment est-il supervisé, et que se passe-t-il en cas d’incident ?

Le pipeline RAG répond mal à ces questions, non pas par négligence de l’équipe IA, mais parce que le framework utilisé ne fournit pas de bonnes réponses par défaut. Le compte de service existe parce que c’était la façon la plus simple de faire fonctionner la recherche. La journalisation au niveau de la session existe parce que c’est ce que proposait le framework. L’absence d’application des labels de sensibilité existe parce que le framework ne connaît pas les labels MIP.

Résultat : un cycle qui se répète dans les organisations : l’équipe IA présente la démo, l’équipe sécurité audite, trouve six problèmes, l’équipe IA passe deux mois à corriger pendant que les parties prenantes s’impatientent, l’équipe IA présente à nouveau, l’équipe sécurité trouve trois problèmes restants, et le cycle recommence. Les projets qui sortent de ce cercle vicieux sont ceux dont l’architecture de recherche a été conçue dès le départ selon les critères d’audit sécurité — où la gouvernance des données est un paramètre de conception, pas une barrière finale.

Les six modes d’échec : ce que trouve la sécurité et pourquoi elle bloque l’approbation

Les six modes d’échec suivants apparaissent dans la majorité des audits sécurité RAG en entreprise, notamment dans les secteurs réglementés. Chacun correspond à une question que l’équipe sécurité posera, à une réponse que l’équipe IA ne peut pas fournir avec l’architecture RAG par défaut, et à la modification architecturale requise pour la résoudre.

Ce que demandent réellement les équipes sécurité

Traduire les exigences d’audit sécurité en spécifications architecturales est souvent source de friction entre équipes IA et fonctions sécurité. Les questions posées par la sécurité ne sont pas arbitraires. Elles correspondent directement aux contrôles appliqués à tous les systèmes d’accès privilégié aux données, issus des mêmes référentiels qui régissent l’accès aux dossiers médicaux, aux systèmes de reporting financier et aux infrastructures de transfert de fichiers réglementés. Comprendre ce que ces questions impliquent rend l’architecture attendue plus lisible.

Quand la sécurité demande « qu’est-ce qui empêche un utilisateur d’accéder à des données hors de son autorisation »…

…elle attend la preuve que le système de recherche applique les règles d’accès de l’organisation à chaque requête, et non par session. La réponse attendue est : « la recherche est limitée par le profil RBAC et ABAC de l’utilisateur authentifié à chaque requête, et les documents hors de ce périmètre sont exclus avant d’entrer dans le contexte IA. » La réponse non attendue est : « le modèle IA est instruit de ne pas référencer les documents que l’utilisateur ne devrait pas voir. »

Quand la sécurité demande « qui est responsable de chaque accès aux données »…

…elle attend une traçabilité individuelle dans les logs d’audit, pas une identité de compte de service. La réponse attendue est : « OAuth 2.0 avec autorisation déléguée à l’utilisateur conserve l’identité de l’utilisateur authentifié jusqu’à la couche de recherche, et chaque entrée de log contient à la fois l’identité du système IA et celle de l’utilisateur. » La réponse non attendue est : « la plateforme IA journalise la session, et nous pouvons faire le lien avec l’activité utilisateur. »

Quand la sécurité demande « comment détecteriez-vous une extraction massive de données »…

…elle attend une architecture de supervision, pas une description théorique du comportement anormal. La réponse attendue est : « l’activité de recherche alimente le SIEM en temps réel ; des seuils de volume par utilisateur sont définis ; les dépassements génèrent des alertes automatiques. » La réponse non attendue est : « si quelqu’un faisait cela, on le verrait probablement dans les logs. »

Quand la sécurité demande « que se passe-t-il si ce système est compromis »…

…elle attend des procédures de gestion d’incident spécifiques au pipeline IA, pas une référence à la politique générale de gestion des incidents. La réponse attendue est : « le plan de gestion d’incident comporte un addendum spécifique à l’IA couvrant les indicateurs de détection, les procédures de confinement pour la couche de recherche, les étapes de préservation forensique, et le workflow de notification si des informations médicales protégées ou des données personnelles sont concernées. »

Préparer l’audit sécurité : dix exigences et comment y répondre

La checklist suivante relie les dix exigences d’audit sécurité les plus fréquentes pour les projets RAG en entreprise aux fonctions architecturales nécessaires pour y répondre. Les équipes IA doivent utiliser cette liste avant de soumettre leur projet à l’audit sécurité — toute exigence à laquelle la réponse est « pas encore » entraînera un retard d’approbation.

Une architecture qui passe l’audit : construire la couche de gouvernance avant l’audit sécurité

La meilleure façon de réussir un audit sécurité RAG est d’en faire une version préliminaire avant la construction. Avant de finaliser l’architecture de recherche, l’équipe IA doit passer en revue les dix exigences ci-dessus et identifier celles qui nécessitent des choix architecturaux plutôt que de simples réglages de configuration.

Ce sont ces décisions qui coûtent cher à corriger une fois le pipeline construit. Celles qui sont faciles à ajouter plus tard — documentation, mises à jour de règles, addenda au plan de gestion d’incident — peuvent attendre. Celles qui imposent de revoir le modèle d’authentification, de reconstruire la couche d’autorisation de recherche ou de remplacer les identifiants de compte de service sont coûteuses à ajouter après coup.

La décision architecturale la plus critique et la plus irréversible concerne l’authentification. Choisir OAuth 2.0 avec autorisation déléguée à l’utilisateur plutôt qu’un compte de service comme mécanisme d’authentification pour la recherche détermine si l’attribution individuelle est disponible dans chaque log, chaque traçabilité d’audit et chaque notification de violation.

Il est simple d’opérer ce choix avant la construction ; il est coûteux de le rétrofiter dans un pipeline déployé où la gestion de session repose sur l’identité du compte de service.

La décision architecturale sur l’autorisation de recherche est la seconde plus importante. La définition du périmètre d’autorisation avant la recherche — appliquer les contraintes RBAC et ABAC avant l’opération de recherche, et non en filtrage après coup — impose que le système de recherche connaisse le profil d’autorisation de l’utilisateur demandeur.

Ce n’est pas disponible dans les configurations standard des frameworks RAG ; il faut une couche de recherche gouvernée entre la requête utilisateur et l’opération de recherche vectorielle. Intégrer cette couche dès la conception est simple ; la rajouter ensuite dans un pipeline où la recherche vectorielle opère directement sur tout le corpus impose de reconstruire le composant de recherche.

La décision sur la journalisation découle de celle sur l’autorisation de recherche. La journalisation par document requiert que la couche de recherche génère un événement de log pour chaque document retourné, avec l’identifiant du document, l’identité de l’utilisateur, la décision d’autorisation et la classification de sensibilité.

Ce log doit être généré à la couche de recherche, pas reconstruit à partir des logs applicatifs. Si la couche de recherche ne le génère pas par conception, l’ajouter ensuite impose d’instrumenter le composant de recherche — ce qui est plus simple quand le composant est conçu pour la gouvernance que lorsqu’il s’agit d’une recherche vectorielle par défaut du framework.

La couche de gouvernance : pourquoi le modèle AI Data Gateway résout le problème de l’audit sécurité

L’idée architecturale qui simplifie l’audit sécurité RAG est que les six modes d’échec se résolvent par une seule couche de gouvernance, placée entre la requête de recherche du pipeline RAG et les référentiels de données indexés.

Cette couche de gouvernance gère l’authentification (OAuth 2.0 avec PKCE), l’autorisation à chaque requête (RBAC et ABAC évalués selon le profil utilisateur), l’application des labels de sensibilité (évaluation MIP à la recherche), la journalisation par document (chaque accès journalisé avec attribution complète) et l’intégration SIEM (transfert en temps réel).

Le pipeline RAG lui-même — indexation vectorielle, embedding, assemblage du contexte, modèle — reste inchangé. La couche de gouvernance n’est pas une contrainte sur la qualité de la recherche ; c’est un « wrapper » autour de l’opération de recherche qui garantit un accès conforme plutôt qu’un accès sans restriction.

C’est le modèle AI Data Gateway. Plutôt que d’intégrer les fonctions de gouvernance directement dans le framework RAG — ce qui impose un développement sur mesure sur des frameworks non conçus pour cela — la couche de gouvernance est un composant séparé par lequel passe l’opération de recherche.

Le pipeline RAG demande une recherche ; la couche de gouvernance évalue la requête selon le profil d’autorisation de l’utilisateur authentifié, applique les politiques de sensibilité, exécute la recherche sur le sous-ensemble autorisé du corpus, journalise le résultat et renvoie les documents récupérés au pipeline.

Du point de vue du pipeline RAG, il reçoit les documents demandés. Du point de vue de l’équipe sécurité, toutes les exigences de l’audit sont satisfaites avant le retour des documents.

Le choix entre construire ou acheter ce modèle est simple pour la plupart des organisations. Construire une couche de recherche gouvernée de zéro impose : l’implémentation d’OAuth 2.0 avec PKCE et son intégration au système de gestion des identités et des accès de l’entreprise ; la construction d’un moteur d’autorisation à chaque requête évaluant les politiques RBAC et ABAC du référentiel de règles de l’organisation ; l’intégration de l’évaluation des labels MIP dans le chemin de recherche ; la création d’une infrastructure de journalisation par document avec transfert SIEM ; et la maintenance de l’ensemble en production.

L’alternative consiste à déployer un AI Data Gateway conçu pour fournir toutes ces fonctions en tant que composant managé, permettant à l’équipe IA de se concentrer sur l’application IA pendant que la couche de gouvernance répond aux attentes de la sécurité.

Comment Kiteworks amène RAG en production

Le principe du AI Data Gateway de Kiteworks est que l’échec à l’audit sécurité RAG est un problème d’architecture qui appelle une solution architecturale — et que cette solution ne nécessite pas de reconstruire tout le pipeline RAG, mais simplement d’ajouter la couche de gouvernance manquante. L’AI Data Gateway fournit cette couche sous forme de composant déployable, intégré au Réseau de données privé Kiteworks, éliminant chacun des six modes d’échec sans développement sur mesure.

L’authentification s’effectue via OAuth 2.0 avec PKCE, conservant l’identité du collaborateur authentifié depuis l’assistant IA jusqu’à la couche de recherche. Aucun compte de service n’intervient dans la chaîne d’accès ; chaque recherche est autorisée sous l’identité individuelle de l’utilisateur et chaque log d’audit porte cette identité en plus de celle du système IA.

L’autorisation RBAC et ABAC à chaque requête est appliquée à la couche de recherche par le Data Policy Engine de Kiteworks, qui évalue le profil d’autorisation de l’utilisateur par rapport au document demandé avant que celui-ci n’entre dans le contexte IA. Les labels de sensibilité MIP sont évalués au moment de la recherche ; les documents au-dessus du niveau d’habilitation de l’utilisateur sont refusés avant la recherche, et le refus est journalisé avec le fondement de la règle.

La journalisation par document génère une entrée d’audit complète pour chaque accès : identité utilisateur, identité système IA, identifiant du document, classification de sensibilité, décision d’autorisation et horodatage. Chaque entrée alimente l’intégration SIEM de Kiteworks en temps réel, établissant la traçabilité continue exigée par les équipes sécurité et les référentiels de conformité.

Des seuils de volume par utilisateur sont actifs par défaut, et des alertes d’anomalie sont générées en cas de schéma de recherche inhabituel — fournissant la capacité de détection attendue par la sécurité et rarement maîtrisée par les équipes IA.

L’architecture d’échange de données zero trust qui gouverne le partage sécurisé de fichiers, le transfert sécurisé de fichiers et la messagerie sécurisée dans l’organisation s’étend à chaque recherche RAG — la posture de gouvernance démontrée à la sécurité pour les canaux de données traditionnels est la même pour le pipeline IA.

Il n’y a pas d’audit sécurité séparé pour une nouvelle architecture d’accès aux données ; il s’agit d’une extension d’un cadre de gouvernance déjà validé à un nouveau mode de consommation. Pour les équipes IA qui veulent passer RAG du pilote à la production, c’est la différence entre un cycle d’audit de six mois et un processus maîtrisé.

Pour les VP AI/ML Engineering et les RSSI qui veulent arrêter de perdre leurs projets RAG à la porte de la sécurité, Kiteworks fournit la couche de gouvernance qui comble l’écart. Pour voir comment l’AI Data Gateway répond à chacune des dix exigences d’audit sécurité, réservez votre démo sans attendre !

Ressources complémentaires

• Article de blog
  Stratégies Zero Trust pour une protection abordable de la vie privée en IA
• Article de blog
  Comment 77 % des organisations échouent sur la sécurité des données IA
• eBook
  AI Governance Gap : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025
• Article de blog
  Il n’existe pas de « –dangerously-skip-permissions » pour vos données
• Article de blog
  Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent la preuve qu’elle fonctionne.