IA et confidentialité des données patients dans les essais cliniques : un modèle d'accès en quatre niveaux

Demandez à votre DPO si l'équipe d'étude peut utiliser l'IA sur les données de l'essai. Vous aurez l'une de deux réponses. « Non » bloque tous les cas d'usage, y compris ceux qui ne touchent aucune donnée patient. « Oui » sans conditions met des données de santé dans un outil que personne n'a évalué.

Les deux réponses oublient ce que votre EDC fait tous les jours. Quand une personne rejoint une étude, vous lui donnez un rôle. Ce rôle décide de ce qu'elle voit.

Un modèle d'accès en quatre niveaux applique la même règle à l'IA. Vous classez les données de l'étude selon leur proximité avec une personne, de L0 (métadonnées) à L3 (données identifiantes). Chaque outil IA reçoit les niveaux dont sa tâche a besoin et que sa conformité autorise. Datacapt utilise ce modèle dans son EDC et son connecteur MCP.

Une IA conforme données de santé respecte le RGPD, HIPAA et HDS ou un standard équivalent, ou tourne dans votre propre infrastructure. Le connecteur Datacapt donne par défaut L0 et L1 à tous les autres outils.

[[takeaways]]

Accès par rôle : vous limitez déjà ce que voit chaque utilisateur

Ouvrez les paramètres de rôles de n'importe quel EDC utilisé dans un essai réglementé. Vous y trouverez le même schéma :

Ce tableau vous permet de prouver à un inspecteur que chaque personne a eu accès à ce que son poste exigeait et à rien d'autre.

Les textes le demandent avec leurs propres mots :

• RGPD, article 5(1)(c) : la minimisation des données. Vous traitez les données personnelles nécessaires à la finalité, pas davantage. L'article 25 exige la protection des données dès la conception et par défaut.
• HIPAA fixe la règle du « minimum necessary » : une entité couverte limite l'usage ou la communication d'informations de santé protégées au minimum nécessaire à la tâche.
• 21 CFR Part 11, section 11.10(d) : limiter l'accès au système aux personnes autorisées. La section 11.10(g) ajoute des contrôles d'autorité sur qui peut faire quelle opération. La section 11.10(e) exige une piste d'audit sécurisée et horodatée.

Aucun de ces textes ne parle d'IA. Tous décrivent un contrôle d'accès par rôle. Vous pouvez les appliquer à un outil IA comme vous les appliquez à une personne.

Traitez un outil IA comme un utilisateur de plus

Quand un data manager demande à Claude de rédiger des edit checks, ou qu'un chef de projet demande à ChatGPT l'état d'un centre, l'IA lit des données d'étude. Pour votre système qualité, c'est donc un utilisateur. Il lui faut un rôle, un périmètre et une trace dans la piste d'audit.

Deux questions fixent son rôle :

1. De quoi la tâche a-t-elle besoin ? Des edit checks demandent le protocole et la structure des formulaires (L0). L'état d'un centre demande des chiffres (L1). La revue médicale du sujet 012 demande les réponses de ce sujet (L2).
2. Qu'a prouvé l'outil ? Un outil approuvé par votre entreprise, sous un contrat qui interdit à l'éditeur d'entraîner ses modèles sur vos données, est éligible à L0 et L1. Un outil conforme aux règles sur les données de santé est éligible à L2 et L3.

La tâche définit ce dont l'IA a besoin. La conformité de l'outil définit ce qu'elle peut recevoir. Si la tâche demande plus que ce que l'outil a prouvé, vous changez d'outil et gardez la règle.

Dans Datacapt, l'IA prend le rôle de la personne qui la connecte. Elle a exactement les mêmes droits que le compte de cet utilisateur. L'agent d'un ARC voit les centres de cet ARC. L'agent d'un data manager voit ce que voit le data manager, rien de plus. Chacune de ses actions entre dans la piste d'audit.

L0 : les métadonnées ne contiennent aucune donnée personnelle

Le protocole, le calendrier des visites, les formulaires, les variables, les codelists, les edit checks et l'eCRF vierge décrivent l'étude sans décrire une personne. Le RGPD s'applique aux données personnelles : L0 en sort. HIPAA et HDS ne s'appliquent pas non plus.

Le risque en L0 est la confidentialité. Votre protocole est la propriété intellectuelle du promoteur. Votre service juridique le traite dans le contrat avec l'éditeur de l'IA : pas d'entraînement sur vos données, durée de conservation limitée, engagements de sécurité.

L0 est le seul niveau où l'IA peut écrire. Un agent peut construire des formulaires, poser des conditions d'affichage ou ajouter une langue à l'étude. Dans Datacapt, ces écritures arrivent dans une étude au statut DRAFT. Un concepteur d'étude relit et valide la construction avant la mise en production. Le système validé qui collecte les données patients reste sous contrôle humain.

💡 Commencez votre programme IA par L0. La construction d'étude fait gagner le plus de temps. Votre DPO n'a aucune donnée personnelle à évaluer.

L1 : les agrégats répondent à la plupart des questions de monitoring

Taux de complétion, nombre de queries, statut SDV, recrutement par centre et données manquantes par formulaire sont des agrégats. La plateforme les calcule et envoie un chiffre à l'IA. Le modèle lit « le centre 102 a 14 queries ouvertes depuis plus de 30 jours » et ne lit jamais les 14 valeurs derrière.

Le considérant 26 du RGPD exclut de son champ les informations anonymes, celles qui ne se rapportent plus à une personne identifiable. Un agrégat calculé sur assez de sujets passe ce test. C'est pourquoi tout outil IA approuvé peut lire L1.

L'IA lit les agrégats et ne les écrit jamais. Les données collectées appartiennent à l'utilisateur du centre qui les a saisies, avec une entrée dans la piste d'audit et un motif de modification, comme l'attend la Part 11.

⚠️ Attention aux petits effectifs. Si un centre n'a inclus qu'un sujet, « 1 événement indésirable grave au centre 104 » désigne une personne. Fixez un effectif minimal avec votre équipe protection des données. Traitez tout chiffre en dessous comme du L2.

L2 : une donnée pseudonymisée reste une donnée personnelle

L2, c'est l'eCRF lui-même : des réponses liées à un numéro de sujet comme 012, sans nom ni identifiant direct.

Beaucoup d'équipes pensent qu'un numéro de sujet rend la donnée anonyme. Le considérant 26 du RGPD traite les données pseudonymisées comme des données personnelles, parce que quelqu'un détient la clé : le centre investigateur peut relier 012 à un patient. En septembre 2025, la Cour de justice de l'UE (CEPD contre CRU) a admis qu'un destinataire sans moyen raisonnable de réidentifier peut détenir des données qui ne sont pas personnelles pour lui. Cela n'aide ni l'équipe d'étude, ni le promoteur, ni l'éditeur de l'EDC, qui peuvent remonter jusqu'au sujet via le centre. Les données cliniques sont aussi des données de santé, une catégorie particulière au sens de l'article 9.

Un outil IA qui lit du L2 devient sous-traitant de données de santé. Votre organisation a alors besoin :

• d'un contrat de sous-traitance avec l'éditeur de l'IA (article 28 du RGPD),
• d'une analyse d'impact (AIPD) qui couvre l'usage de l'IA (article 35),
• d'un mécanisme de transfert si l'éditeur traite les données hors de l'UE, comme une décision d'adéquation ou des clauses contractuelles types (chapitre V),
• d'un hébergement certifié HDS quand les données relèvent des règles françaises sur les données de santé,
• d'un Business Associate Agreement quand HIPAA s'applique,
• ou d'un modèle hébergé sur vos propres serveurs, où les données ne vont jamais chez un tiers.

L2 donne ce que les chiffres ne donnent pas. Une IA avec un accès L2 peut lire les visites d'un sujet dans l'ordre et signaler que V3 est datée avant V2. Elle peut proposer des codes MedDRA ou WHODrug, ou rédiger une narration pour un relecteur médical.

L3 : les données identifiantes restent chez ceux qui en ont besoin

L3 contient ce qui identifie une personne à lui seul : nom, coordonnées, date de naissance. Il contient aussi le texte libre non contrôlé, car un utilisateur du centre peut taper un nom ou un numéro de téléphone dans n'importe quel champ commentaire. Vous ne le savez qu'après l'avoir lu.

L3 suit la même exigence que L2. Dans une étude, peu de tâches IA en ont besoin. Le suivi du recrutement en est une, quand un coordinateur veut de l'aide pour planifier les appels avec des candidats présélectionnés. La minimisation des données et la règle HIPAA du « minimum necessary » vont dans le même sens : gardez L3 hors des flux IA sauf si la tâche l'exige.

Le serveur MCP de Datacapt ne renvoie jamais le nom, les coordonnées ou la date de naissance d'un participant. Ses outils connaissent un participant par son numéro de sujet et son Datacapt ID.

Ce que demande chaque texte et comment les niveaux y répondent

L'AI Act européen ajoute son propre calendrier, repoussé en 2026. La plupart des outils IA utilisés pour conduire un essai ne sont pas des systèmes à haut risque au sens de ce texte. Pour les dates, lisez ce que change le règlement 2026/1744 pour les essais cliniques.

La responsabilité est partagée, comme pour la validation logicielle

Vous partagez déjà la responsabilité de votre EDC. L'éditeur valide la plateforme : son processus de développement, ses tests, ses notes de version. Vous validez votre usage : la construction de l'étude, les tests d'acceptation, les rôles que vous attribuez. GAMP 5 et ICH E6(R3) décrivent ce partage. Un inspecteur s'attend à le trouver par écrit. Notre guide sur la validation des systèmes informatisés dans les essais cliniques détaille la méthode.

L'usage de l'IA suit le même partage :

Le promoteur garde la responsabilité finale des données de l'essai selon ICH E6(R3), même quand il délègue des tâches à une CRO ou à un prestataire. La décision d'utiliser l'IA sur une étude lui revient.

Si vous conduisez une étude pour un promoteur, demandez-lui avant qu'un outil IA n'y touche. Inscrivez sa réponse dans le contrat ou l'accord qualité : quels outils, quels niveaux, pour quelles tâches et qui valide les résultats. Si vous êtes le promoteur, ajoutez la même clause à vos contrats avec vos CRO et vos prestataires.

Faites-le aussi pour L0 et L1. Votre protocole appartient au promoteur. La plupart des clauses de confidentialité interdisent de le partager avec un tiers qu'il n'a pas approuvé. Le promoteur qualifie aussi chaque système qui touche son étude. Un inspecteur lui demandera comment l'équipe a utilisé l'IA. Une clause signée lui donne cette réponse. La piste d'audit montre que vous êtes resté dans le cadre.

💡 Ajoutez une clause IA à votre modèle de contrat : outils approuvés, niveau maximal par outil, tâches et la personne qui valide les résultats de l'IA. Vous la négociez ensuite une fois par promoteur.

Comment Datacapt applique les niveaux

Votre équipe ne devrait pas avoir à appliquer ces règles de mémoire. Datacapt intègre les niveaux au connecteur :

• Un outil qui n'atteint pas l'exigence données de santé reçoit par défaut L0 et L1.
• Les écritures de l'IA portent sur les métadonnées d'études en DRAFT. Une personne valide avant la mise en production.
• Les noms, coordonnées et dates de naissance ne sortent jamais de la plateforme par le serveur MCP.
• L'IA a les mêmes droits que l'utilisateur qui la connecte. Elle ne peut ouvrir ni étude, ni centre, ni formulaire que cet utilisateur ne peut pas ouvrir.
• Chaque utilisateur se connecte avec sa propre clé MCP, limitée et révocable. Chaque action de l'IA porte donc un nom.
• Chaque action MCP entre dans la piste d'audit avec son origine. Un inspecteur peut séparer une action de l'IA d'une action humaine.

Pour le fonctionnement d'un serveur MCP, lisez MCP et LLM en recherche clinique. Pour comparer ce que les éditeurs d'EDC laissent faire à un agent, lisez les quatre niveaux d'accès d'un agent IA. Cet article-là classe les capacités de l'agent, de la lecture de la documentation à l'écriture d'une étude. Celui-ci classe les données qu'une IA peut voir.

Six questions pour votre DPO et votre équipe qualité

1. De quel niveau chaque cas d'usage IA a-t-il besoin ? Listez les cas d'usage et attribuez le niveau le plus bas qui fonctionne. La plupart des tâches de construction et de monitoring s'arrêtent à L1.
2. Quels outils sont éligibles à quel niveau ? Gardez le BAA, le contrat de sous-traitance, les clauses de transfert ou le certificat HDS de chaque outil autorisé en L2.
3. L'éditeur entraîne-t-il ses modèles sur vos données ? Obtenez la réponse dans le contrat, pour chaque niveau.
4. Où arrivent les écritures de l'IA ? Dans un brouillon qu'une personne nommée valide.
5. Un inspecteur peut-il retracer ce que l'IA a fait ? La piste d'audit doit montrer chaque action de l'IA, sous quel utilisateur, sur quelles données.
6. Le promoteur a-t-il approuvé l'usage de l'IA par écrit ? Le contrat ou l'accord qualité doit nommer les outils et les niveaux, L0 et L1 compris.

Inscrivez les réponses dans votre AIPD, votre analyse de risque des systèmes informatisés et vos contrats. Un inspecteur qui demande comment vous contrôlez l'IA reçoit alors la même réponse que pour n'importe quel utilisateur : un rôle, un périmètre et une trace.

[[cta]]