Dans la pharma, la santé, un assistant IA qui se trompe ne crée pas seulement une mauvaise expérience : il crée un écart de conformité. C'est pourquoi un RAG générique — même performant — ne tient pas en environnement réglementé. La bonne question n'est pas « le RAG est-il assez bon ? » mais « le RAG est-il traçable, validable et auditable ? ». Cet article prolonge notre guide du RAG en entreprise sur le terrain le plus exigeant.
Pourquoi un RAG générique bute sur un mur réglementaire
Un RAG standard est optimisé pour une seule chose : donner une réponse utile. En environnement GxP, ce n'est pas suffisant. Quatre exigences manquent presque toujours :
- La traçabilité à la source validée : il ne suffit pas de citer « un document ». Il faut citer la version en vigueur et approuvée du document, à la bonne révision — pas une version périmée encore présente dans le corpus.
- L'audit trail : chaque requête, chaque réponse et chaque source consultée doivent être journalisées de manière inaltérable.
- L'intégrité des données : les principes ALCOA+ (attribuable, lisible, contemporain, original, exact, et complet, cohérent, durable, disponible) s'appliquent aussi aux sorties d'un système IA.
- La supervision humaine : sur tout usage décisionnel réglementé, l'assistant informe une décision ; il ne la prend pas.
Un RAG branché sur un dossier partagé non maîtrisé, sans journalisation ni gestion de version, échouera à la première inspection. La conformité ne se rajoute pas après coup : elle se conçoit dans l'architecture.
« En secteur réglementé, une hallucination n'est pas un bug d'expérience utilisateur. C'est un écart d'intégrité des données. »
Ce que « auditable » veut dire, concrètement
Un assistant RAG conforme doit pouvoir répondre, pour chaque réponse produite : d'où vient cette information, dans quelle version du document, qui l'a consultée et quand ? Cela suppose :
- Citation à la révision : chaque réponse renvoie au document, à la section et au numéro de version validée.
- Journalisation inaltérable : un audit trail horodaté des questions, réponses et sources, conservé selon les exigences de rétention.
- Contrôle d'accès tracé : qui a le droit d'interroger quoi (RBAC/ABAC), avec preuve d'accès.
- Reproductibilité : pouvoir démontrer qu'à corpus et version donnés, le système se comporte de manière maîtrisée.
La validation du système IA lui-même
Dans un environnement réglementé, le RAG est un système informatisé à part entière : il doit donc être validé, pas seulement testé. L'approche de référence est celle de la validation des systèmes informatisés :
- Approche par les risques (GAMP 5) : l'effort de validation est proportionné à l'impact du système sur la qualité produit et la sécurité patient.
- Cadres applicables : l'Annexe 11 des BPF européennes pour les systèmes informatisés, et le 21 CFR Part 11 (FDA) pour les enregistrements et signatures électroniques.
- Cycle de vie : analyse de risque, spécifications (URS), qualification (IQ/OQ/PQ), puis maîtrise du changement — un RAG évolue (corpus, modèle), et chaque évolution significative doit être gérée.
C'est précisément là qu'une expertise conformité change la donne : les acteurs purement techniques savent construire un RAG performant, mais peu savent le faire entrer dans un référentiel de validation GxP.
L'hallucination comme risque de conformité — et comment la maîtriser
Dans un contexte réglementé, on ne peut pas « tolérer » un taux d'hallucination. On l'encadre par conception :
- Quality gates de groundedness : une réponse n'est restituée que si elle est effectivement ancrée dans une source autorisée.
- Refus explicite : en l'absence de source fiable, le système répond « information non disponible dans la documentation autorisée » plutôt que d'inventer.
- Human-in-the-loop : validation humaine obligatoire sur les usages à impact réglementaire.
- Corpus borné : le RAG ne puise que dans un ensemble fermé, versionné et autorisé de documents (voir plus bas).
Le corpus borné : principe de conception central
La différence la plus structurante entre un RAG grand public et un RAG réglementé tient en deux mots : corpus borné. Plutôt que de laisser le modèle puiser largement, on le restreint à un périmètre documentaire fermé, autorisé et versionné — la documentation qualité en vigueur, les SOP approuvées, les textes réglementaires applicables. Tout document obsolète est retiré du périmètre interrogeable. Cette discipline garantit que l'assistant ne peut pas répondre à partir d'une procédure périmée ou d'une source externe non validée. C'est aussi ce qui rend le système prévisible, donc validable.
Cas d'usage par secteur réglementé
| Secteur | Cas d'usage RAG | Cadre clé |
|---|---|---|
| Industrie pharmaceutique | Assistant SOP, support déviations/CAPA, préparation d'inspection, interrogation des dossiers de lot | BPF / GxP, Annexe 11, ALCOA+ |
| Affaires réglementaires | Navigation dans les dossiers d'AMM et variations, veille sur les guidelines | GxP, données réglementaires |
| Santé / hospitalier | Assistant protocoles et recommandations pour les équipes soignantes (aide à la décision) | HDS, RGPD, secret médical |
| Banque / assurance | Interrogation des politiques de conformité, procédures KYC/LCB-FT, support d'audit | RGPD, DORA, supervision ACPR |
Dans tous les cas, le même principe gouverne : l'assistant accélère l'accès à la bonne information validée ; il reste un outil d'aide à la décision sous supervision, jamais un décideur autonome.
Et le cadre RGPD / AI Act ?
Au-delà des cadres sectoriels, deux textes transversaux s'appliquent : le RGPD dès que des données personnelles sont traitées (santé : données sensibles, hébergement HDS), et le règlement européen sur l'IA (AI Act), dont l'approche par les risques peut classer certains usages réglementés en catégorie à exigences renforcées (documentation, supervision humaine, gestion des risques). Concevoir l'assistant comme un système gouverné et documenté dès le départ facilite la mise en conformité avec ces cadres en évolution.
Un assistant IA pour un environnement réglementé ?
Nous concevons des RAG conformes pour la pharma, la santé : corpus borné, traçabilité à la source validée, audit trail et accompagnement à la validation. Commençons par un diagnostic de faisabilité et de conformité.
Échanger sur votre projetQuestions fréquentes
Un RAG peut-il être utilisé dans un environnement GxP / BPF ?
Oui, à condition d'être traité comme un système informatisé soumis à validation : traçabilité de chaque réponse vers la version validée du document source, audit trail, intégrité des données (ALCOA+) et human-in-the-loop sur les décisions réglementées. Un RAG générique branché sur un corpus non maîtrisé n'est pas conforme.
Comment gérer le risque d'hallucination dans un contexte réglementé ?
On l'encadre par des quality gates de groundedness qui n'autorisent une réponse que si elle est ancrée dans une source autorisée, par un refus explicite en l'absence de source, et par la validation humaine sur tout usage décisionnel.
Faut-il valider le système RAG comme un logiciel GxP ?
Oui. Il relève de la validation des systèmes informatisés (approche GAMP 5, cadre Annexe 11 en Europe et 21 CFR Part 11 aux États-Unis) : analyse de risque, spécifications, qualification et maîtrise du changement, proportionnées à l'impact.
Qu'est-ce qu'un corpus borné et pourquoi est-ce essentiel ?
C'est un ensemble fermé, autorisé et versionné de documents dans lequel le RAG est strictement limité à puiser. C'est la condition pour garantir que les réponses proviennent toujours de la documentation en vigueur, et non d'une source obsolète ou externe non validée.
Souveraineté et conformité : deux faces du même projet
Conformité et souveraineté vont de pair en secteur réglementé : l'auditabilité suppose de maîtriser où vivent les données et qui y accède. Pour le volet infrastructure et résidence des données, voir notre guide du RAG souverain et on-premise ; pour la vue d'ensemble, notre guide du RAG en entreprise.