Qu’est-ce qu’un agent IA en santé, et quelles données touche-t-il ?

Un agent IA dans la santé finit presque toujours par croiser des données de santé : une fiche patient jointe à un e-mail, un compte rendu glissé dans une réclamation, une ordonnance scannée dans un dossier qualité. Le sujet se règle avant la mise en production.

Un agent IA en santé est un système fondé sur un modèle de langage qui exécute des tâches pour un laboratoire, un fabricant de dispositifs médicaux ou un établissement de soins : il lit des documents, interroge des outils, prépare des réponses. Son cadre juridique dépend des données qu’il voit et de la finalité qu’on lui donne.

Au 28 octobre 2026, plusieurs régimes se superposent pour un tel agent : l’article 9 du RGPD, la certification HDS, la doctrine de la CNIL sur la pseudonymisation et l’IA, l’AI Act modifié par le Digital Omnibus et l’Espace européen des données de santé. Chez Koneetiv, cabinet 100 % Claude et partenaire officiel Anthropic, c’est avec cette grille que nous décidons, au cadrage, où l’agent peut toucher la donnée de santé et où il doit s’arrêter. Les cas d’usage sont sur notre page agents IA pour la santé et les sciences de la vie.

Que dit le RGPD sur les données de santé ?

Une définition large, à apprécier au cas par cas

Le RGPD définit les données concernant la santé comme celles qui révèlent une information sur la santé physique ou mentale, passée, présente ou future, d’une personne (article 4, point 15, et considérant 35). La CNIL en tire trois familles : les données de santé par nature (antécédents, résultats d’examens, traitements), celles qui le deviennent par croisement avec d’autres données, et celles qui le deviennent par l’usage médical qu’on en fait.

Pour un agent, la famille du croisement est la plus piégeuse. Un historique de commandes de produits orthopédiques rapproché d’un nom et d’une adresse peut suffire à révéler un état de santé. Or un agent qui assemble du contexte à partir de plusieurs sources fabrique exactement ce genre de croisement, sans que personne l’ait décidé.

Une interdiction de principe, avec des exceptions limitées

L’article 9 du RGPD range les données de santé parmi les catégories particulières : leur traitement est interdit, sauf dans les cas que le texte énumère à son paragraphe 2. On y trouve le consentement explicite de la personne, la médecine préventive, le diagnostic et la prise en charge sanitaire (point h), l’intérêt public dans le domaine de la santé publique (point i) ou la recherche scientifique (point j). Il faut en plus une base légale au titre de l’article 6.

La CNIL considère qu’une analyse d’impact (AIPD) est à mener pour la majorité des traitements de données de santé. Un agent qui en manipule n’y échappe pas, et l’analyse doit décrire ce qu’il fait réellement : les sources qu’il interroge, les données qui partent vers le modèle, ce qu’il garde dans ses journaux, qui relit ses sorties avant envoi.

Faut-il un hébergeur certifié HDS pour un agent IA ?

Ce que dit l’article L1111-8 du Code de la santé publique

En France, toute personne qui héberge des données de santé à caractère personnel recueillies lors d’activités de prévention, de diagnostic, de soins ou de suivi social et médico-social, pour le compte de ceux qui les ont produites ou recueillies ou pour le compte du patient, doit être certifiée. C’est l’article L1111-8 du Code de la santé publique. L’Agence du numérique en santé (ANS) précise qu’un établissement de santé qui gère lui-même son système d’information n’a pas besoin de la certification.

Deux certificats existent, hébergeur d’infrastructure physique et hébergeur infogéreur (infrastructure virtuelle, plateforme d’applications, exploitation, sauvegarde externalisée), délivrés pour trois ans par un organisme accrédité par le Cofrac. Le même article interdit toute cession à titre onéreux de données de santé identifiantes, directement ou indirectement, même avec l’accord de la personne.

Le référentiel en vigueur : version 2.0, et une version 2.1 annoncée

Le référentiel de certification actuel est la version 2.0, approuvée par l’arrêté du 26 avril 2024. Les hébergeurs déjà certifiés avaient jusqu’au 16 mai 2026 pour s’y conformer. Cette version renforce les exigences sur les transferts de données hors de l’Union européenne, et la CNIL a rendu un avis favorable sur le projet le 13 juillet 2023.

L’ANS a annoncé une version 2.1, prévue pour octobre 2026 et non publiée au 28 octobre 2026, applicable trois mois après sa publication. Les contrats devront dire si l’hébergeur est soumis à une législation d’un pays tiers qui pourrait lui imposer un transfert, et détailler les transferts qui existent. L’ANS précise qu’un accès distant est considéré comme un transfert, ce qui vaut pour toute équipe de support qui accède aux données depuis un pays situé hors de l’Espace économique européen.

Le décret n° 2026-209 du 24 mars 2026, publié au Journal officiel du 26 mars 2026, a déjà durci le cadre de l’hébergement : les données de santé sont stockées sur le territoire de l’Union européenne ou de l’Espace économique européen, et un accès à distance depuis un pays tiers est traité comme un transfert, possible seulement dans les conditions du RGPD (décision d’adéquation ou garanties appropriées). L’hébergeur doit aussi informer ses clients des mesures prises face aux risques de transfert ou d’accès non autorisé par des États tiers. Pour un agent, cela revient à vérifier où les données sont stockées et depuis quels pays les équipes du fournisseur y accèdent.

Ce que ça implique pour l’architecture d’un agent

Un agent est une chaîne : l’application qui orchestre, le modèle appelé par API, la base documentaire interrogée, les journaux, l’historique des conversations, parfois un cache. Chaque maillon qui stocke des données de santé pour votre compte pose la question HDS. La réponse se tranche maillon par maillon, avec votre DPO et votre juriste.

Côté modèle, nous ne présumons rien des engagements d’un fournisseur. Les questions à lui poser par écrit, à Anthropic comme à tout autre, restent les mêmes :

Où l’agent peut-il toucher la donnée de santé, et où doit-il s’arrêter ?

La frontière se trace au cadrage, par écrit, avant la première ligne de code. Nous la découpons en zones, sur le modèle des zones de confiance pour classer les agents IA que nous utilisons dans LOOP™.

Sans donnée de santé : le terrain pour commencer

Documentation réglementaire, système qualité, support technique sur un produit, veille scientifique : une bonne partie du travail d’un laboratoire ou d’un fabricant ne demande aucune donnée de santé à caractère personnel. Un premier agent sur ce périmètre installe l’architecture et la gouvernance sans ouvrir le dossier HDS. Encore faut-il le garantir techniquement, avec un filtre en entrée qui écarte les pièces jointes et les champs sensibles avant qu’ils atteignent le modèle.

Avec des données pseudonymisées : moins de risque, même régime

La pseudonymisation remplace les identifiants directs par un code, la correspondance étant conservée à part et protégée (article 4, point 5, du RGPD). Le considérant 26 est explicite : des données pseudonymisées qu’une information supplémentaire permet de rattacher à une personne restent des données personnelles. Pour le responsable qui détient la table de correspondance, la donnée pseudonymisée reste une donnée de santé. La Cour de justice de l’Union a nuancé ce point le 4 septembre 2025 (affaire C-413/23 P) : pour un destinataire qui n’a aucun moyen raisonnable de réidentifier les personnes, des données pseudonymisées peuvent ne pas être personnelles. L’arrêt porte sur le règlement 2018/1725, applicable aux institutions de l’Union, et laisse entière l’obligation de l’entreprise qui garde la clé.

La pseudonymisation garde pourtant tout son intérêt pour l’architecture. L’agent travaille sur le dossier codé, la table de correspondance vit dans un autre système auquel il n’a aucun accès, et la réidentification, quand elle est nécessaire, se fait côté humain, dans l’outil métier. Les journaux de l’agent ne contiennent alors que des codes, et la surface exposée en cas d’incident diminue d’autant.

Les zones interdites : finalité médicale et décisions sur les personnes

Un logiciel que son fabricant destine au diagnostic, à la prévention, au suivi ou au traitement peut être un dispositif médical au sens du règlement (UE) 2017/745. Un agent qui propose un diagnostic, recommande un traitement ou trie des patients change donc de monde réglementaire, avec marquage CE et, souvent, organisme notifié.

Notre position est de laisser ces usages hors du périmètre d’un agent généraliste, sauf projet porté comme un dispositif médical, avec l’équipe réglementaire qu’il exige. La même prudence vaut pour les décisions qui touchent une personne sur la base de sa santé : tarification d’assurance, accès à une prestation, priorité de prise en charge. Dans la grille LOOP™, ces actions relèvent de la zone rouge ou noire : l’agent prépare, une personne habilitée décide et signe.

Comment l’AI Act s’articule-t-il avec les règles de santé ?

L’AI Act (règlement (UE) 2024/1689) se cumule avec le RGPD et le droit de la santé. Son calendrier a bougé : le Digital Omnibus sur l’IA, règlement (UE) 2026/1744 publié au Journal officiel le 24 juillet 2026 et entré en vigueur le 27 juillet, a repoussé les obligations des systèmes à haut risque. Le détail des échéances figure sur notre page conformité AI Act en entreprise.

Un agent devenu dispositif médical : haut risque au 2 août 2028

Un système d’IA qui est un dispositif médical, ou le composant de sécurité d’un dispositif, et qui passe par un organisme notifié, est classé à haut risque par l’article 6, paragraphe 1, et l’annexe I. Celle-ci vise notamment les règlements 2017/745 sur les dispositifs médicaux et 2017/746 sur les dispositifs de diagnostic in vitro. Depuis l’Omnibus, les exigences du haut risque s’appliquent à ces systèmes à partir du 2 août 2028. Les deux règlements restent en section A de l’annexe I, et l’Omnibus ajoute un mécanisme d’équivalence (nouvel article 2, paragraphe 13) : certaines exigences de l’AI Act pourront être limitées quand le droit sectoriel offre une protection équivalente ou supérieure, selon des actes délégués que la Commission doit adopter d’ici le 2 août 2027.

Les cas de l’annexe III qui touchent la santé : 2 décembre 2027

L’annexe III liste des usages à haut risque indépendants de tout produit, et plusieurs concernent la santé : l’évaluation par une autorité publique de l’éligibilité à des prestations, y compris de soins (point 5 a), l’évaluation des risques et la tarification en assurance vie et santé (point 5 c), le tri des appels d’urgence et le triage des patients aux urgences (point 5 d). Pour ces systèmes, l’échéance est désormais le 2 décembre 2027.

Les obligations de transparence de l’article 50 s’appliquent, elles, depuis le 2 août 2026 : un agent conçu pour échanger directement avec des personnes doit leur indiquer qu’elles s’adressent à une IA, sauf si c’est évident.

Que change l’Espace européen des données de santé (EHDS) ?

Un règlement adopté, des obligations étalées jusqu’en 2031

Le règlement (UE) 2025/327 sur l’Espace européen des données de santé a été adopté le 11 février 2025 et publié au Journal officiel le 5 mars 2025. Il s’applique à partir du 26 mars 2027, et ses volets les plus lourds arrivent plus tard.

Pour l’usage primaire, c’est-à-dire l’échange de données pour soigner, les catégories prioritaires arrivent en deux temps : résumés patients, prescriptions et dispensations électroniques à partir du 26 mars 2029, puis imagerie médicale, résultats d’examens et comptes rendus de sortie à partir du 26 mars 2031.

L’usage secondaire ouvre l’entraînement d’IA, sous permis

Le chapitre IV, applicable à partir du 26 mars 2029, organise l’usage secondaire des données de santé. Parmi les finalités admises, l’article 53 cite l’entraînement, le test et l’évaluation d’algorithmes, y compris de systèmes d’IA et de dispositifs médicaux, dans le cadre de la recherche scientifique liée à la santé. L’accès passe par un permis délivré par un organisme d’accès aux données de santé, et l’article 54 interdit d’utiliser ces données pour prendre des décisions préjudiciables à une personne ou pour l’exclure d’un contrat d’assurance ou de crédit.

Pour une entreprise qui déploie un agent en 2026, l’EHDS change peu de choses avant 2029. Il donne en revanche une direction : des données de santé plus structurées, plus échangées, avec un usage secondaire très encadré. Une architecture qui trace dès aujourd’hui qui voit quelle donnée, et pour quelle finalité, n’aura pas à être refaite.

Quel rôle joue la CNIL face à un agent IA en santé ?

La CNIL est l’autorité de contrôle du RGPD en France, et son rôle en santé dépasse le contrôle. Elle publie des méthodologies de référence (MR-001 et suivantes) qui simplifient les formalités des traitements de recherche, et instruit les demandes d’autorisation quand aucun cadre simplifié ne s’applique.

Sur l’IA, ses recommandations finalisées le 22 juillet 2025 guident l’analyse qui permet de savoir si un modèle est soumis au RGPD, et citent parmi les solutions des filtres placés au niveau du système qui encapsule le modèle. Le 5 mars 2026, elle a publié la fiche « IA et santé : développer et évaluer des systèmes d’IA en conformité avec la réglementation », qui couvre la constitution d’un entrepôt de données de santé pour des recherches ultérieures, la constitution d’une base de données de santé pour développer un système d’IA et l’évaluation de l’impact de son déploiement, avec les formalités préalables.

Le même jour, elle a ouvert avec la Haute Autorité de santé, qui copilote le projet avec elle, une consultation sur un guide « IA en contexte de soins », close le 16 avril 2026. La fiche laisse de côté le déploiement lui-même. Pour les établissements et professionnels de santé, le projet de guide HAS-CNIL, dans sa version soumise à consultation, couvre justement le déploiement en contexte de soins ; les autres entreprises qui déploient un agent restent sur les règles générales, AIPD, registre et minimisation. Pour un projet d’agent, le dialogue avec la CNIL se prépare en amont : l’AIPD, le registre des traitements et la documentation de l’agent sont les pièces qui permettent de répondre à un contrôle.

À quoi ressemble un agent santé bien cadré ?

Une équipe affaires réglementaires et qualité, chez un industriel de santé, confie à un agent la veille de littérature scientifique et réglementaire : il parcourt les publications, les recommandations des autorités sanitaires et les évolutions de normes, repère ce qui touche les produits de l’entreprise et rédige une synthèse sourcée que l’équipe relit avant diffusion. C’est le type d’usage décrit sur notre page agent IA de veille réglementaire.

Sur des sources publiques, l’agent ne voit en principe aucune donnée de santé à caractère personnel. Elle surgit quand le périmètre s’élargit : une publication qui décrit un cas clinique en détail, ou la demande de croiser la veille avec les réclamations et signalements internes, qui peuvent relater un incident survenu chez un patient. Le cadrage fixe la règle avant que le cas se présente. Un filtre en amont n’admet que les sources publiques, les extraits internes arrivent pseudonymisés, et toute synthèse qui rapproche un signal d’un patient identifiable quitte l’automatisme pour la zone rouge de LOOP™, où une personne décide. Les autres synthèses passent par la zone orange, un cran plus prudent qu’en veille réglementaire classique parce qu’une publication clinique peut toujours contenir un détail identifiant : l’agent propose, l’équipe valide avant diffusion.

Comment cadrer un agent IA qui touche des données de santé ?

L’ordre que nous suivons au cadrage, avant la première mise en production :

  1. Écrire la finalité de l’agent et exclure toute finalité médicale qui n’est pas visée.
  2. Cartographier les données que l’agent verra, champ par champ, en repérant celles qui deviennent des données de santé par croisement.
  3. Choisir la base légale et l’exception de l’article 9, puis mener l’AIPD sur le fonctionnement réel de l’agent.
  4. Vérifier, maillon par maillon, qui stocke quoi et où, et si l’hébergement doit être certifié HDS.
  5. Filtrer et pseudonymiser en amont du modèle, et tenir la table de correspondance hors de portée de l’agent.
  6. Garder la signature humaine sur tout ce qui engage l’entreprise et journaliser les validations, comme le prévoit la gouvernance LOOP™.
  7. Qualifier l’agent au regard de l’AI Act (annexe I, annexe III, article 50) et dater les échéances qui le concernent.

Cette méthode vaut pour les entreprises de toutes tailles : une PME de quelques dizaines de personnes et un groupe pharmaceutique se posent les mêmes questions, à des volumes différents. Pour la sécurité de l’agent lui-même, droits d’accès et journaux compris, notre guide pour sécuriser un agent Claude en production complète cette grille, et l’audit des connecteurs MCP en production couvre les accès aux systèmes métiers.

Pour savoir où en est votre organisation sur la gouvernance des agents avant d’ouvrir un chantier santé, le diagnostic de maturité IA mesure les six axes du référentiel Koneetiv (édition 2026).