Gestion des risques de l’IA en établissement de santé

L’éventail va des systèmes qui signalent des anomalies en radiologie et font remonter les cas urgents aux scores d’alerte précoce en soins intensifs, en passant par les analyses en laboratoire et en anatomopathologie et les propositions de posologie, jusqu’aux modèles de langage qui rédigent des courriers médicaux ou documentent des consultations. S’y ajoutent des outils sans lien direct avec le patient, par exemple pour la planification du personnel, la gestion des lits ou la prise de rendez-vous. Plus un système intervient près de la décision diagnostique ou thérapeutique, plus ses erreurs touchent directement des personnes.

Il suffit d’une mise à jour passée inaperçue, d’une base de données où certains groupes de patients sont presque absents ou d’un étalonnage qui s’est décalé pour que les résultats changent – souvent sans que cela se remarque dans le quotidien du service. Pour un déployeur, la question décisive n’est donc pas de savoir si un système est « intelligent », mais quelle décision il influence, qui se fie à ses résultats et ce qui se passe lorsqu’il se trompe ou tombe en panne.

Trois familles de risques

• Risques techniques : erreurs de classification, baisse de performance du modèle, attaques contre les données, le modèle ou les interfaces, pannes de services.
• Risques organisationnels : responsabilités floues, formation insuffisante, mises à jour non encadrées, utilisation d’outils d’IA non autorisés et lacunes dans le traitement des incidents.
• Risques éthiques et juridiques : discrimination de groupes de patients, manque de traçabilité, atteintes à la protection des données et perte de confiance entre soignants et soignés.

Deux notions à connaître

La dérive du modèle désigne la perte progressive de performance d’un modèle, parce que les données d’entrée, la population de patients, les appareils ou les processus cliniques ont évolué par rapport aux conditions de validation. Le guide MDCG 2025-6 recommande à cet égard de concevoir les jeux de données de sorte que les biais involontaires et la dérive des données restent maîtrisables et que l’on puisse repérer les sous-groupes pour lesquels un modèle obtient de moins bons résultats, y compris dans la durée.

Le biais d’automatisation désigne la tendance à se fier aux résultats produits par une machine, ou à leur accorder une confiance excessive. L’AI Act exige que les personnes chargées du contrôle humain soient en mesure de reconnaître cette tendance, d’interpréter correctement les résultats, de les écarter au cas par cas et d’arrêter le système au moyen d’un bouton d’arrêt ou d’une procédure similaire.

Cette page résume l’article « Risikomanagement für KI-Systeme im Medizinbetrieb » (Gestion des risques des systèmes d’IA en établissement de santé), paru en allemand dans mt|medizintechnik, numéro 2.2026, le restructure et le complète par les évolutions intervenues jusqu’en octobre 2026, notamment le Digital Omnibus relatif à l’AI Act.

L’AI Act ne classe pas l’IA médicale à haut risque par principe. Ce qui compte, c’est la voie de la législation sur les produits : si l’IA est elle-même un dispositif médical ou un dispositif de diagnostic in vitro, ou le composant de sécurité d’un tel dispositif, et si un organisme notifié doit intervenir dans l’évaluation de la conformité, elle est considérée comme un système d’IA à haut risque. Comme le MDR classe en règle générale au moins en classe IIa les logiciels qui fournissent des informations pour des décisions diagnostiques ou thérapeutiques, c’est le cas de la plupart des applications d’IA diagnostiques et thérapeutiques. Les exigences de l’AI Act sont alors examinées dans la procédure MDR existante de l’organisme notifié – sans seconde certification.

L’AI Act désigne par ailleurs directement comme à haut risque certains usages dans le domaine de la santé : l’évaluation des appels d’urgence et le triage des patients aux urgences, les décisions des autorités sur l’accès aux prestations de santé publiques ainsi que l’évaluation des risques et la tarification en assurance maladie et en assurance vie. Si un tel système de triage est en même temps un dispositif médical relevant d’un organisme notifié, la voie de la législation sur les produits prime.

Comment NIS2 et la protection des données s’y rattachent

Pour les hôpitaux que la loi BSI – la transposition allemande de NIS2 – range parmi les entités particulièrement importantes ou importantes, les systèmes d’IA font partie du système d’information à protéger : un incident de sécurité important touchant un service d’IA doit être notifié rapidement – une alerte précoce au plus tard après 24 heures, une notification avec première évaluation après 72 heures et un rapport final au plus tard un mois plus tard. La protection des données exige une analyse d’impact pour les traitements à risque élevé ; l’AI Act oblige les déployeurs à s’appuyer pour cela sur les informations fournies par le fournisseur.

Calendrier du point de vue du déployeur

• Depuis le 2 février 2025 : interdiction de certaines pratiques d’IA ; obligation de favoriser la maîtrise de l’IA au sein du personnel – depuis l’Omnibus, expressément sans niveau de compétence garanti.
• Depuis le 2 août 2026 : application générale de l’AI Act et obligations de transparence ; surveillance par l’AI Office et les autorités nationales.
• Depuis le 11 septembre 2026 : obligations de notification des fabricants au titre du Cyber Resilience Act pour les vulnérabilités activement exploitées et les incidents de sécurité graves.
• À partir du 2 décembre 2027 : obligations haut risque pour les usages directement classés, par exemple un triage aux urgences qui n’est pas évalué comme dispositif médical avec organisme notifié.
• À partir du 2 août 2028 : obligations haut risque pour les dispositifs médicaux à IA – pour les fournisseurs comme pour les déployeurs. Les systèmes mis sur le marché auparavant ne sont concernés qu’après des modifications importantes de leur conception ; pour les systèmes destinés aux autorités publiques, l’échéance est fixée au plus tard au 2 août 2030.

L’Omnibus contient en outre une ouverture dont l’issue reste incertaine : pour les produits soumis à leur propre droit sectoriel – dont les dispositifs médicaux –, la Commission peut limiter par acte délégué certaines exigences de l’AI Act, dans la mesure où ce droit sectoriel offre une protection équivalente. Elle dispose pour cela d’un délai courant jusqu’au 2 août 2027. Pour la planification à l’hôpital, cela change peu, car les obligations des déployeurs n’en sont pas affectées. Une proposition de la Commission de décembre 2025 relative à la révision du MDR et de l’IVDR va plus loin : elle ferait passer les dispositifs médicaux à IA dans une catégorie de réglementation plus légère de l’AI Act, de sorte que les exigences relatives à l’IA seraient mises en œuvre en priorité par le MDR. Rien n’est adopté ; d’ici là, les échéances indiquées ici s’appliquent.

Est fournisseur celui qui développe un système d’IA ou le fait développer et le met sur le marché ou en service sous son propre nom ; pour les dispositifs médicaux, c’est en règle générale le fabricant au sens du MDR. Est déployeur celui qui utilise le système sous sa propre autorité dans un cadre professionnel. Le guide MDCG 2025-6 précise que le déployeur ne se confond pas avec l’« utilisateur » au sens du MDR : à l’hôpital, l’établissement est le déployeur, la médecin à son poste d’interprétation est l’utilisatrice.

Quand l’établissement devient lui-même fournisseur

• Il met sur le marché, sous son propre nom ou sa propre marque, un système à haut risque déjà commercialisé.
• Il modifie substantiellement un système à haut risque, c’est-à-dire d’une manière non prévue dans l’évaluation initiale de la conformité et qui affecte la conformité ou la destination.
• Il utilise un système jusque-là non classé à haut risque – y compris un modèle de langage généraliste – pour une finalité qui le rend à haut risque.

Selon le guide MDCG 2025-6, une modification substantielle impose une nouvelle évaluation de la conformité même si l’établissement se contente d’utiliser lui-même le système modifié. Les modifications prédéfinies et évaluées à l’avance par le fabricant, par exemple dans un plan de changements prédéterminés, ne sont en revanche pas considérées comme substantielles. D’après le guide, les développements propres qu’un établissement de santé utilise exclusivement en interne, dans le cadre des règles applicables aux dispositifs fabriqués et utilisés en interne, ne constituent pas une IA à haut risque ; les autres obligations de l’AI Act demeurent.

Ce que le contrat doit prévoir

• Informations sur l’origine des données, les populations de validation et les limites de performance connues.
• Politique de mise à jour avec délais d’annonce, notes de version et possibilité de retour arrière.
• Accès aux journaux et soutien pour l’analyse des incidents et l’analyse d’impact relative à la protection des données.
• Circuits de notification, délais de réaction et interlocuteurs pour les questions de sécurité.
• Engagements de sécurité pour les composants cloud et les bibliothèques tierces, nomenclature logicielle comprise.
• Fin du support et restitution ou suppression ordonnée des données en fin de contrat.

La loi n’impose un système de gestion des risques au sens de l’AI Act qu’au fournisseur. Les déployeurs ont des obligations de surveillance, de contrôle, de données, de journalisation et de notification. Une gestion des risques structurée au sein de l’établissement reste pourtant la base pratique pour remplir ces obligations. La norme IEC 80001-1, destinée aux établissements exploitants, décrit précisément cette approche pour les dispositifs médicaux connectés et les logiciels de santé : gestion des risques avant, pendant et après l’intégration dans le système d’information hospitalier.

1. 1
   Avant l’achat : finalité et qualification

   Clarifier le bénéfice clinique, la destination, le rôle de l’établissement et la qualification réglementaire. Fixer des critères d’acceptation : quels taux d’erreur et quels risques résiduels sont acceptables pour cet usage, et qui en décide ?

2. 2
   Avant la mise en service : vérification dans son propre environnement

   Vérifier avec des données propres et représentatives que les performances annoncées par le fabricant sont atteintes dans sa propre population. Sécuriser interfaces, droits d’accès et segment réseau, désigner et former les personnes chargées du contrôle, définir la procédure de repli.

3. 3
   En exploitation : surveillance et retours

   Suivre en continu les indicateurs de performance, les taux de dérogation – c’est-à-dire la fréquence à laquelle le personnel passe outre l’IA –, la qualité des données et la disponibilité. Documenter les anomalies, les signaler au fournisseur et suspendre l’utilisation en cas de risque.

4. 4
   Lors de modifications : validation maîtrisée

   Chaque mise à jour du modèle, chaque nouvelle interface et chaque nouveau domaine d’utilisation passe par l’évaluation, le test, la validation et la documentation. Vérifier si la modification avait été prédéfinie par le fabricant ou si elle ferait basculer l’établissement dans le rôle de fournisseur.

5. 5
   À la mise hors service : un retrait ordonné

   Garantir un processus de remplacement, sécuriser journaux et preuves conformément aux durées de conservation, fermer accès et interfaces, faire supprimer les données chez le fournisseur et tirer les enseignements pour le prochain achat.

STRIDE remonte à Loren Kohnfelder et Praerit Garg, qui ont décrit ce schéma en 1999 chez Microsoft. Il range les menaces en six catégories et s’applique bien à un diagramme de flux de données : pour chaque composant et chaque connexion, on se demande quelle catégorie y est envisageable. Pour un système d’IA d’aide à l’interprétation, on y trouve typiquement l’appareil d’imagerie (appelé « modalité » en radiologie), l’archive d’images (PACS), le service d’inférence – local ou dans le cloud –, l’affichage des résultats, le système d’information hospitalier et le canal de mise à jour du fabricant.

Menaces propres à l’IA

L’AI Act cite lui-même des attaques typiques contre l’IA : empoisonnement des données et des modèles, entrées modifiées à dessein pour tromper un modèle, attaques contre la confidentialité et exploitation des faiblesses du modèle. Pour les applications fondées sur des modèles de langage, l’OWASP Top 10 for LLM Applications dans sa version 2026 propose une grille de lecture actuelle. Pour les établissements, les schémas suivants sont les plus pertinents :

Une matrice à deux axes a fait ses preuves. Le premier axe porte la probabilité, alimentée par des facteurs techniques comme la surface d’attaque et la robustesse du modèle, des facteurs organisationnels comme le niveau de formation et la maturité des processus, et des facteurs humains comme la pression temporelle et le biais d’automatisation. Le second porte la gravité des conséquences – sur le plan médical, de la protection des données, du fonctionnement de l’établissement et de la confiance qui lui est accordée.

Examiner les biais de façon ciblée

Les biais apparaissent lorsque les données d’entraînement ne reflètent pas la patientèle de l’établissement ou lorsque les processus et les appareils changent. Les déployeurs devraient donc analyser les indicateurs de performance non seulement globalement, mais aussi par sous-groupe pertinent, dans la mesure où les données et la base juridique le permettent. Depuis l’Omnibus, l’AI Act autorise les déployeurs de systèmes à haut risque à traiter exceptionnellement des catégories particulières de données à caractère personnel, comme les données de santé, pour détecter des biais – sous de strictes garanties et sans que cela crée une obligation.

Analyse d’impact sur les droits fondamentaux : quand est-elle obligatoire ?

L’AI Act n’exige une analyse d’impact sur les droits fondamentaux que pour les usages à haut risque qu’il énumère lui-même, et seulement de la part des organismes publics, des opérateurs privés fournissant des services publics et des déployeurs qui évaluent la solvabilité ou tarifient des assurances vie et maladie. Les hôpitaux publics et les établissements privés investis d’une mission de service public peuvent ainsi être concernés, par exemple lors du déploiement d’un système de triage aux urgences ; si ce système est en même temps un dispositif médical relevant d’un organisme notifié, il convient, compte tenu de la primauté de la législation sur les produits, de vérifier au cas par cas si l’obligation s’applique. Pour les dispositifs médicaux à IA qui ne sont à haut risque que par la voie du MDR, cette obligation ne s’applique pas. L’Omnibus permet de renvoyer à une analyse d’impact relative à la protection des données déjà réalisée.

1. 1
   Prévention

   La sécurité commence dès la sélection : exiger du fournisseur une approche Secure by Design, valider avec des données de test propres et représentatives, mettre en œuvre segmentation réseau, authentification multifacteur et droits fondés sur les rôles. Solliciter avant la mise en production un second regard indépendant – issu d’un test de sécurité externe ou d’un hôpital partenaire expérimenté dans le même domaine – permet de découvrir les angles morts avant qu’ils ne touchent des patients.

2. 2
   Détection

   Repérer tôt les écarts : surveiller la dérive des indicateurs de performance et des données d’entrée, analyser les journaux, définir des alertes en cas de comportement inhabituel et utiliser les dérogations du personnel comme indicateur précoce. En soins intensifs et aux urgences, ce qui compte, c’est la rapidité avec laquelle une anomalie parvient à l’équipe compétente.

3. 3
   Correction

   Quand quelque chose tourne mal : aux points critiques, l’humain garde le dernier mot et peut arrêter le système. Des procédures de repli sans IA, la possibilité de revenir à une version antérieure du modèle, des voies d’escalade claires et une procédure de traitement des incidents bien rodée limitent les dégâts.

4. 4
   Preuve

   La documentation relie le tout : qualification, évaluation des risques, résultats de tests, validations, formations, dérogations, incidents et corrections. Elle atteste du respect des obligations auprès des autorités et des auditeurs et fonde l’amélioration continue.

Notifier quand la situation devient sérieuse

Si l’établissement a des raisons de penser que l’utilisation présente un risque, il informe sans délai le fournisseur ou le distributeur ainsi que l’autorité de surveillance du marché et suspend l’utilisation. En cas d’incident grave, l’AI Act exige d’informer sans délai, en premier lieu, le fournisseur. Pour les dispositifs médicaux à IA, les incidents liés à la santé passent par le système de vigilance du MDR – le fabricant notifie, selon la gravité, au plus tard sous 15, 10 ou 2 jours ; au titre de l’AI Act, seules les violations d’obligations protégeant les droits fondamentaux restent alors à notifier. En Allemagne, exploitants et utilisateurs doivent en outre signaler sans délai les incidents graves présumés à l’autorité fédérale compétente, en règle générale le BfArM. En parallèle, des notifications au titre de la loi BSI et du droit de la protection des données peuvent s’imposer.

Les mesures concrètes en un coup d’œil

• Inventaire de tous les systèmes d’IA avec finalité, qualification, responsables et flux de données.
• Personnes chargées du contrôle désignées pour chaque système, avec formation documentée et habilitation à passer outre.
• Journalisation incluant la version du modèle et l’action de l’utilisateur, conservation d’au moins six mois.
• Procédure de validation des mises à jour avec test dans un environnement de référence.
• Tests de sécurité réguliers et red teaming IA, en particulier pour les modèles de langage et les agents.
• Matrice de notification concertée couvrant le fournisseur, la vigilance des dispositifs médicaux, le BSI et l’autorité de protection des données.

De nombreux établissements disposent déjà d’un système de management de la sécurité de l’information (SMSI), d’un management de la qualité et d’un management de la protection des données. Les risques liés à l’IA peuvent s’y greffer : comme catégorie de risque à part entière, avec leurs propres contrôles et un rôle clairement défini dans la validation des nouveaux systèmes. La vue d’ensemble ci-dessous montre ce qu’apporte chaque norme.

Pour les hôpitaux soumis à la loi BSI, cette intégration s’impose aussi sur le plan juridique : les mesures de gestion des risques exigées comprennent notamment la gestion des incidents, la sécurité de la chaîne d’approvisionnement ainsi que la sécurité de l’acquisition, du développement et de la maintenance, y compris le traitement des vulnérabilités. Les services d’IA et leurs fournisseurs ont donc leur place dans la gestion des fournisseurs et des vulnérabilités du SMSI.

1. 1
   Jours 1–15 : fixer les responsabilités

   Désigner une fonction responsable de l’IA, réunir l’ingénierie biomédicale, la sécurité informatique, la protection des données, le management de la qualité et la direction médicale au sein d’un comité, et soumettre la validation de tout nouveau système d’IA à ce comité.

2. 2
   Jours 16–30 : dresser l’inventaire

   Recenser tous les systèmes d’IA, y compris les fonctions intégrées aux appareils et aux services cloud. Consigner pour chaque système la finalité, le fournisseur, les flux de données, les groupes d’utilisateurs et la qualification réglementaire.

3. 3
   Jours 31–45 : prioriser les risques

   Pour les systèmes les plus proches du patient, établir un modèle de menaces selon STRIDE et évaluer les impacts. Le résultat est une liste des mesures les plus urgentes.

4. 4
   Jours 46–60 : contrats et fournisseurs

   Examiner les contrats existants au regard de la politique de mise à jour, de l’accès aux journaux, de l’origine des données, des circuits de notification et de la fin du support ; renégocier les engagements manquants et fixer des exigences d’achat pour les acquisitions futures.

5. 5
   Jours 61–75 : contrôle et compétences

   Désigner les personnes chargées du contrôle pour chaque système, organiser des formations ciblées sur les limites de performance et le biais d’automatisation, informer le personnel et ses représentants.

6. 6
   Jours 76–90 : ancrer l’exploitation

   Mettre en place la surveillance et la conservation des journaux, faire entrer en vigueur la procédure de gestion des modifications et la matrice de notification, réaliser un exercice de traitement d’incident et adopter le plan des douze mois suivants.

Ce plan est une orientation et ne remplace pas un examen au cas par cas. Son ampleur et l’ordre des étapes dépendent de la taille, de la mission de soins et du parc d’IA de l’établissement.