L’IA clinique avance plus vite que les garde-fous, alerte une revue de la TU de Dresde

Des risques à chaque étape du cycle de vie

La revue classe les risques de l’IA clinique selon plusieurs niveaux, depuis sa conception jusqu’à son utilisation par les établissements de santé :

• Conception et données d’entraînement : des données manipulées ou « empoisonnées » peuvent modifier le comportement du système avant même son arrivée dans un environnement de soins.
• Déploiement et interfaces : une injection de prompt peut introduire des instructions malveillantes dans un processus clinique. La revue évoque notamment le scénario où une attaque à l’interface conduirait un modèle à ne pas repérer une tumeur pourtant visible. Des infrastructures informatiques hospitalières vulnérables peuvent également interrompre les soins ou exposer des informations de patients.
• Comportement du modèle : les grands modèles de langage peuvent produire des informations médicales fausses, mais formulées de manière suffisamment convaincante pour sembler exactes. Ils peuvent aussi approuver trop facilement les hypothèses d’un utilisateur au lieu de remettre en question un raisonnement erroné.
• Interaction entre l’humain et l’IA : des réponses persuasives peuvent favoriser le biais d’automatisation, lorsque les soignants s’en remettent trop facilement au système, ou le biais de confirmation, lorsqu’ils utilisent l’outil pour conforter une conclusion déjà envisagée.
• Usage institutionnel : des cliniciens peuvent recourir à des services publics ou non approuvés sans autorisation formelle. Cet « usage fantôme » peut contourner les protections de la vie privée, l’évaluation locale, les règles de responsabilité et les procédures de signalement des incidents.

Cette approche globale est essentielle : un système peut sembler performant dans un test contrôlé et devenir risqué une fois confronté à de vrais patients, à des utilisateurs différents, à une infrastructure imparfaite ou à un contexte clinique imprévu.

Ce qu’impliquerait un déploiement responsable

Pour les chercheurs, la sécurité doit rester active après la mise en service. Cela suppose notamment un développement sécurisé, une gouvernance rigoureuse des données d’entraînement, des évaluations menées dans le contexte clinique réel, une définition précise des responsabilités humaines et une surveillance continue des performances et des incidents.

Avant d’adopter un outil, un hôpital ou un réseau de soins devrait donc pouvoir répondre à plusieurs questions concrètes :

• qui est autorisé à l’utiliser et pour quelles tâches ;
• quelles données peuvent être consultées par le système et où elles sont transférées ;
• comment les professionnels doivent vérifier ses réponses ;
• qui est responsable lorsqu’un compte rendu ou une recommandation assisté par l’IA est erroné ;
• comment l’établissement peut enquêter sur un problème, suspendre le système ou le retirer.

Le déploiement ne devrait ainsi pas être considéré comme l’aboutissement de l’évaluation, mais comme le début d’une surveillance organisée.

Une gouvernance à deux niveaux

La revue propose une architecture de contrôle combinant responsabilité locale et coordination plus large.

Des équipes de gouvernance de l’IA dans les établissements

Les établissements de santé devraient disposer d’équipes dédiées pour autoriser les outils, les évaluer dans leurs propres services, définir les rôles de chacun et superviser leur fonctionnement. Cette organisation permet de tenir compte des patients concernés, des procédures internes, des systèmes informatiques et des obligations professionnelles propres à chaque structure.

Des centres de sécurité de l’IA coordonnés

Les auteurs recommandent également la création de centres centralisés de sécurité des opérations liées à l’IA — les AI Security Operations Centers, ou SOC. Leur rôle serait de détecter les incidents touchant plusieurs organisations, de partager les signaux de menace et de coordonner les réponses.

Cette logique repose sur un constat simple : une attaque ou une défaillance observée dans un établissement peut révéler une vulnérabilité présente dans d’autres systèmes de santé.

Pourquoi les règles actuelles risquent de prendre du retard

Les cadres traditionnels applicables aux dispositifs médicaux ont été largement conçus pour des produits relativement stables, dont les caractéristiques pouvaient être évaluées à un moment donné. Les logiciels d’IA clinique peuvent, eux, évoluer après leur autorisation ou leur évaluation : une mise à jour du modèle, une modification de la répartition des données, un changement de procédure ou une nouvelle technique d’attaque peut transformer leur profil de risque.

Une évaluation ponctuelle ne garantit donc pas automatiquement qu’un système restera sûr dans tous les contextes ultérieurs. Les travaux plus larges de la TU de Dresde sur la régulation de l’IA médicale soulignent eux aussi la nécessité d’adapter la science réglementaire au rythme des technologies émergentes.

La question est d’autant plus importante que seule une part limitée des outils d’IA utilisés en clinique bénéficie d’une approbation formelle comme dispositif médical. Les établissements doivent donc mettre en place leurs propres contrôles continus sur la performance, la sécurité, la cybersécurité, la confidentialité et l’équité, avec des procédures permettant de signaler les incidents et de suspendre un outil si nécessaire.

Le consentement des patients est aussi un enjeu de sécurité

Les difficultés entourant les assistants de documentation clinique alimentés par l’IA illustrent cette problématique. Les recommandations australiennes demandent que les patients soient informés de la finalité du système, de son périmètre d’utilisation, de ses bénéfices et de ses risques, ainsi que des modalités de suivi de sa sécurité et de ses performances. Elles rappellent également que le clinicien reste responsable des soins et des dossiers produits avec l’aide de l’IA.

Les recommandations professionnelles destinées à la médecine générale australienne insistent de leur côté sur la nécessité de comprendre et de tester un assistant de transcription, d’obtenir le consentement avant chaque utilisation, de protéger les données conservées et de vérifier l’exactitude du dossier médical.

Des informations récentes font état de pratiques très variables en Australie : dans certains cas, une simple affiche en salle d’attente aurait été considérée comme suffisante pour informer les patients. Le régulateur australien des professions médicales a également rappelé que les cliniciens doivent vérifier l’exactitude de toutes les productions d’un assistant d’IA.

Ces éléments ne permettent pas d’établir l’ampleur des consentements insuffisants ou de la mauvaise compréhension de la technologie dans l’ensemble du pays. Ils renforcent toutefois l’argument de la revue : la transparence, le consentement réellement éclairé, la compétence technique des utilisateurs et le maintien de la responsabilité clinique sont des contrôles de sécurité à part entière, et non de simples formalités administratives.

Le principal enseignement pour les organisations de santé

Le message de la revue n’est pas un refus de l’IA clinique, mais un appel à relever le niveau d’exigence avant et après son déploiement. Les grands modèles de langage doivent être considérés comme des systèmes sociotechniques évolutifs, et non comme de simples logiciels que l’on installe une fois pour toutes.

Les responsables de santé doivent être prêts à évaluer les outils dans leur contexte, sécuriser les infrastructures associées, former les utilisateurs, expliquer aux patients la place de l’IA, suivre les performances en conditions réelles et définir clairement qui peut intervenir en cas de défaillance.

Sans ces garde-fous, l’adoption de l’IA clinique continuera de progresser plus vite que la surveillance nécessaire pour la rendre digne de confiance.