L'AI Act dans les établissements de santé

La santé cumule les difficultés : des systèmes souvent à haut risque, une double réglementation avec le dispositif médical, un rôle de déployeur mal identifié et des données parmi les plus sensibles qui soient.

Mis à jour le 16 juillet 2026 · 6 min de lecture

Deux règlements qui se superposent

Une aide au diagnostic en imagerie est déjà un dispositif médical, marqué CE au titre du règlement (UE) 2017/745. L'AI Act ne remplace pas ce régime : il s'y ajoute, via l'annexe I.

Conséquence pratique : le système est à haut risque au sens de l'AI Act par la porte de l'annexe I, et non par la liste d'usages de l'annexe III. C'est une distinction qui a des effets concrets, notamment sur la date d'application : 2 août 2028 pour l'annexe I, contre 2 décembre 2027 pour l'annexe III.

L'hôpital est déployeur, pas fournisseur

Un établissement qui achète une solution à un éditeur est déployeur. Ses obligations (article 26) sont réelles mais circonscrites : usage conforme à la notice, supervision humaine par des professionnels compétents, pertinence des données d'entrée, surveillance, conservation des journaux, information des personnes.

Il ne lui revient pas de produire la documentation technique du système, ni de conduire l'évaluation de conformité : c'est la charge du fournisseur.

Sauf si l'établissement développe en interne, appose sa marque, ou détourne le système d'un usage — auquel cas il devient fournisseur. Un outil de planification développé par la DSI place l'hôpital en position de fournisseur.

La validation clinique n'est pas la conformité AI Act

Une confusion tenace mérite d'être levée. La validation clinique d'un dispositif médical relève du fournisseur et du règlement 2017/745. La conformité AI Act est un autre objet : gestion des risques, gouvernance des données, transparence, supervision humaine, robustesse.

Un établissement ne « revalide » pas cliniquement un dispositif marqué CE. En revanche, il doit s'assurer que son usage réel reste dans le périmètre de la notice, et surveiller les performances en conditions réelles — ce qui n'est pas la même chose.

Les systèmes qu'on oublie de recenser

L'inventaire d'un établissement se limite trop souvent à l'imagerie. Or l'IA y est bien plus répandue :

• Chatbot d'accueil ou de prise de rendez-vous — risque limité, mais soumis à l'article 50 dès le 2 août 2026. C'est l'échéance la plus proche pour la plupart des hôpitaux.
• Tri automatisé des candidatures à la DRH — annexe III (emploi), haut risque, avec information obligatoire des travailleurs.
• Optimisation des plannings de blocs — généralement risque minimal, sauf si elle conditionne l'accès aux soins.
• Assistant de rédaction de comptes rendus — risque limité, et attention à l'article 50 si les contenus sont publiés.
• Aide au triage aux urgences — annexe III (accès aux services essentiels), haut risque.

Une règle empirique : le nombre de systèmes d'IA d'un établissement est presque toujours supérieur à ce que la direction imagine, parce que l'IA arrive par mise à jour de logiciels déjà installés, sans décision d'achat identifiée comme telle.

Articulation avec le RGPD

Les données de santé sont des données sensibles au sens de l'article 9 du RGPD. Un système d'IA qui les traite déclenche presque toujours une analyse d'impact relative à la protection des données (AIPD).

Si l'établissement est un organisme public ou fournit un service public, une FRIA peut également s'imposer pour les systèmes à haut risque de l'annexe III. Les deux analyses se complètent : l'AIPD regarde les données, la FRIA regarde les droits fondamentaux.

Enfin, l'hébergement de données de santé impose la certification HDS à l'hébergeur — une exigence française qui se cumule à tout le reste.