IA Clinique : observabilité et auditabilité des réponses 

Pourquoi l’observabilité et l’auditabilité sont des problèmes distincts

La confusion entre ces deux notions est fréquente, et elle conduit à des architectures qui adressent l’une en croyant avoir adressé l’autre. 

L’observabilité est une propriété opérationnelle. Elle permet de savoir, en temps réel ou quasi-réel, si le système fonctionne correctement : les requêtes sont-elles traitées dans les délais attendus, les taux d’erreur sont-ils dans les normes, la qualité perçue des réponses se dégrade-t-elle, certains types de requêtes produisent-ils systématiquement des résultats insatisfaisants ? L’observabilité est ce qui permet de détecter un problème avant qu’il ne devienne un incident. 

L’auditabilité est une propriété réglementaire et légale. Elle permet de reconstituer, après coup, le cheminement complet d’une réponse : quels documents ont été récupérés, dans quelle version, avec quel score de pertinence, quel prompt a été soumis au modèle, quelle réponse a été générée, qui a posé la question et depuis quelle application. L’auditabilité est ce qui permet de répondre à un inspecteur, de défendre une décision clinique ou d’instruire un incident de pharmacovigilance. 

Ces deux dimensions nécessitent des mécanismes techniques différents, même si elles partagent une infrastructure commune de journalisation. 

Le contexte réglementaire : ce que les référentiels exigent concrètement

Les référentiels applicables aux systèmes d’information cliniques convergent sur des exigences similaires, même si leurs formulations varient. 

La réglementation 21 CFR Part 11 de la FDA exige que tout système informatique utilisé dans un contexte réglementé maintienne des journaux d’audit horodatés, non modifiables et liés à l’identité de l’utilisateur. Cette exigence s’applique aux systèmes IA dès lors qu’ils participent à un processus de décision documenté. 

Les bonnes pratiques cliniques ICH E6(R3) introduisent des exigences de traçabilité sur les données source et les processus de décision dans les essais cliniques. Un assistant IA utilisé par un investigateur ou un data manager dans ce cadre entre dans le périmètre de ces exigences. 

Le règlement européen sur les dispositifs médicaux MDR 2017/745, et plus encore le règlement AI Act en cours de déploiement, imposent des obligations de transparence et de traçabilité pour les systèmes d’IA à usage médical. Les systèmes d’aide à la décision clinique sont explicitement dans le périmètre des systèmes à haut risque. 

La norme GAMP 5 définit les exigences de validation des systèmes informatisés en environnement GxP. Un système IA déployé dans un processus clinique doit être qualifié et maintenir une documentation permettant de démontrer que son comportement est prévisible et contrôlé. 

Dans tous ces cadres, la question posée est la même : pouvez-vous démontrer, sur chaque réponse générée par votre système IA, sur quelle base elle a été produite et qui en était responsable ? 

Les quatre piliers d’un système IA observable et auditable

1. La journalisation structurée des interactions

Le premier pilier est la capture systématique et structurée de chaque interaction avec le système IA. Cela va au-delà de la simple conservation des logs : chaque requête doit être enregistrée avec son contexte complet, à savoir l’identité de l’utilisateur, l’application source, l’horodatage précis, la requête telle qu’elle a été formulée, et la réponse générée dans son intégralité. 

Cette journalisation doit être non modifiable. Dans un environnement réglementé, un log qui peut être altéré n’a pas de valeur probatoire. Les solutions de journalisation conformes à 21 CFR Part 11 utilisent des mécanismes de signature électronique ou d’enregistrement en écriture seule sur des infrastructures dont l’intégrité est garantie. 

La structure du log est également importante. Un log en texte libre est difficilement exploitable lors d’un audit. Un log structuré en JSON ou dans un format standardisé permet d’automatiser les requêtes d’audit, de produire des rapports et d’identifier des patterns problématiques. 

2. La traçabilité des sources documentaires

Dans une architecture RAG, la réponse générée par le modèle de langage est conditionnée par les documents récupérés par la couche de recherche. L’auditabilité d’une réponse IA clinique exige que ces sources soient tracées avec précision : quels documents ont été récupérés, dans quelle version, avec quel score de pertinence, et lesquels ont effectivement contribué au contexte soumis au modèle. 

Cette traçabilité n’est pas triviale à implémenter. La plupart des frameworks RAG récupèrent des chunks de documents sans exposer de manière structurée l’identifiant du document source, sa version ou sa date. Un système conçu pour un environnement clinique doit résoudre ce problème dès la conception, en maintenant une correspondance traçable entre chaque fragment utilisé et son document source versionné. 

La granularité de la traçabilité est également une question de conception : faut-il tracer au niveau du document entier, de la section, du paragraphe ? La réponse dépend du cas d’usage, mais dans un contexte de pharmacovigilance ou de soumission réglementaire, la précision au niveau de la section est généralement nécessaire. 

3. La gestion des versions du corpus et des modèles 

Une réponse IA n’est reproductible que si le corpus documentaire et le modèle utilisés pour la produire sont identifiés et versionnés. C’est une exigence que les équipes non techniques ont du mal à anticiper, et que les équipes techniques négligent parfois au profit de la simplicité opérationnelle. 

Un corpus documentaire évolue en permanence : de nouveaux documents sont ingérés, des documents existants sont mis à jour, certains sont archivés ou invalidés. Si une réponse a été générée à partir d’une version du corpus qui n’est plus l’état actuel, reproduire cette réponse lors d’un audit nécessite de restaurer l’état du corpus à la date correspondante. Sans gestion des versions, c’est impossible. 

La même logique s’applique aux modèles. Un LLM est mis à jour, fine-tuné, remplacé. La réponse produite par une version antérieure du modèle n’est pas nécessairement reproductible avec la version actuelle. Un système clinique auditable doit donc maintenir un registre des versions de modèles utilisées et les lier aux journaux d’interaction correspondants. 

4. Le contrôle d’accès lié à l’identité 

L’auditabilité suppose que l’on sait qui a posé quelle question. Dans un environnement clinique multi-utilisateurs, cela implique une authentification forte et une gestion des identités intégrée dans la couche IA, pas seulement dans l’application frontale. 

Il ne suffit pas de logger un identifiant utilisateur : cet identifiant doit être lié de manière non répudiable à une identité physique vérifiée, avec les droits et le rôle correspondants au moment de l’interaction. Dans les processus GxP, la signature électronique au sens de 21 CFR Part 11 peut être requise pour certaines catégories d’interactions. 

Le contrôle d’accès granulaire, tel qu’il est défini dans les systèmes sources, doit se propager jusqu’à la couche IA : un utilisateur ne doit pas pouvoir obtenir via un assistant IA des informations auxquelles il n’a pas accès directement. Cette propriété, parfois appelée sécurité de bout en bout dans les architectures RAG, est difficile à garantir sans une conception explicite. 

Les points de défaillance les plus fréquents en pratique 

Dans les déploiements IA cliniques que l’on observe aujourd’hui, les défaillances sur l’observabilité et l’auditabilité suivent des patterns récurrents. 

Le premier est l’absence de journalisation au niveau de la couche RAG. Les équipes loggent les appels au LLM mais pas les requêtes à la couche de recherche ni les documents récupérés. Le résultat est une réponse conservée sans contexte documentaire traçable. 

Le deuxième est la confusion entre les logs d’application et les logs d’audit. Un log d’application est conçu pour le débogage : il est souvent rotatif, parfois compressé, pas nécessairement lié à l’identité. Un log d’audit est conçu pour la preuve : il doit être complet, immuable et exploitable par un tiers. Confondre les deux conduit à disposer de beaucoup de données mais d’aucune preuve utilisable. 

Le troisième est l’absence de versionnement du corpus. Les organisations mettent à jour leur base documentaire sans maintenir d’historique des états successifs du corpus. Elles se retrouvent alors dans l’impossibilité de reproduire une réponse générée six mois auparavant lors d’un audit ou d’une instruction d’incident. 

Le quatrième est l’utilisation d’API de modèles tiers sans SLA sur la conservation des logs. Quand un LLM est consommé via une API externe, les logs de l’API appartiennent au fournisseur, pas à l’organisation. Cela crée une dépendance réglementaire inacceptable dans un contexte clinique. 

Ce qu’une architecture correcte garantit 

Un système IA clinique correctement conçu doit permettre de répondre, pour n’importe quelle réponse générée dans les 24 derniers mois, aux questions suivantes : qui a posé cette question, depuis quelle application, à quelle heure, quels documents ont été utilisés pour construire la réponse, dans quelle version de ces documents et du modèle, et quelle était la réponse exacte. 

Cette capacité ne se greffe pas après coup sur un système existant. Elle doit être architecturée dès la conception, en intégrant la journalisation structurée, le versionnement du corpus, la traçabilité des sources et le contrôle d’accès à l’identité comme des composantes de premier ordre, au même titre que la qualité des réponses ou la performance du système. 

Les organisations qui abordent ces sujets dans cet ordre, en commençant par la qualité des réponses et en remettant la conformité à plus tard, découvrent généralement qu’une refonte architecturale est nécessaire avant de pouvoir déployer en production clinique. C’est un coût évitable. 

FAQ

01

Un système IA clinique doit-il nécessairement être déployé on-premise pour être auditable ?

Non. Une architecture cloud peut être auditable si les journaux sont conservés sous la responsabilité de l’organisation, si les contrats fournisseurs garantissent les SLA de conservation et d’accès aux logs, et si les données ne transitent pas par des infrastructures mutualisées non conformes aux exigences réglementaires applicables.

02

Quelle est la durée de conservation recommandée pour les logs d’audit IA en environnement clinique ?

La durée dépend du référentiel applicable. En environnement ICH E6, la conservation des données d’essai est liée à la durée de vie du produit. En pratique, une conservation minimale de 15 ans est souvent applicable pour les données cliniques. Ces exigences doivent être définies avec les équipes réglementaires et juridiques avant le déploiement.

03

Comment gérer l’observabilité quand plusieurs LLM sont utilisés en parallèle ?

Chaque modèle doit être identifié dans les logs avec sa version précise. Un middleware d’orchestration centralisé, qui route les requêtes vers les différents modèles et agrège les logs, est la solution la plus robuste pour maintenir une observabilité cohérente dans un environnement multi-modèles.

04

L’auditabilité s’applique-t-elle aux interactions en mode conversationnel multi-tours ?

Oui, et c’est l’un des cas les plus complexes. Dans une conversation multi-tours, le contexte de chaque réponse dépend de l’historique des échanges précédents. L’auditabilité complète nécessite de conserver non seulement chaque réponse individuelle mais l’intégralité de la session de conversation, y compris le contexte documentaire mobilisé à chaque tour.

05

Quel est le lien entre auditabilité et explicabilité ?

L’auditabilité est une propriété du système : elle concerne la traçabilité des sources et du processus. L’explicabilité est une propriété de la réponse : elle concerne la capacité à expliquer pourquoi le modèle a produit tel ou tel raisonnement. Les deux sont complémentaires mais distincts. Un système peut être auditable sans être explicable, et un modèle peut fournir des explications sans que le système qui l’héberge soit auditable.