Analyse du cadre de l’IA dans les soins de santé au Royaume-Uni : obligations relatives aux produits

L’échec le plus banal de l’IA à l’hôpital est aussi le plus coûteux : un outil fonctionne suffisamment bien lors d’un projet pilote, puis plus personne ne peut dire qui le surveille après son lancement. MobiHealthNews rapporte qu’une proposition d’une commission britannique sur la réglementation de l’IA dans les soins de santé appelle à un suivi tout au long du cycle de vie, à la déclaration des incidents de sécurité liés à l’IA, à des exigences de cybersécurité renforcées et à une formation des utilisateurs. Ce n’est pas une consigne pour acheter un classeur de politiques plus épais. C’est un avertissement : la surface opérationnelle de l’IA en santé devient une partie du produit.

Une proposition avec deux horloges réglementaires

MobiHealthNews décrit le cadre britannique pour l’IA en santé comme étant proposé, et son article n’indique pas de date d’entrée en vigueur. C’est important, car « proposé » ne veut pas dire « applicable », une distinction qui a tendance à disparaître dans les tables rondes de conférences. Legal Nodes indique que le Royaume-Uni travaille sur un cadre sectoriel qui s’appuie sur les régulateurs existants pour établir des règles adaptées à l’IA en santé. En parallèle, Tandem Health indique que l’AI Act de l’UE, le règlement UE 2024/1689, a été adopté par le Parlement européen en mars 2024 et publié au Journal officiel de l’Union européenne en juillet 2024, tandis que Legal Nodes indique que la plupart des outils d’IA en santé relèvent de la catégorie à haut risque, avec des règles applicables à partir de février 2025 et des échéances clés qui s’étendent jusqu’en juillet 2025.

La conséquence pratique est familière : les fournisseurs et les hôpitaux britanniques peuvent se préparer à un cadre sectoriel national tout en vendant dans le régime de l’UE, en achetant auprès de celui-ci ou en se comparant à lui. La réponse raisonnable n’est pas de prétendre que les deux systèmes sont identiques. Elle consiste à concevoir les preuves une seule fois, puis à les faire correspondre soigneusement à chaque exigence : documentation des dispositifs médicaux, gouvernance de l’IA, revue de sécurité clinique, documents de confidentialité et garanties d’achat.

Le suivi doit faire partie du dossier produit

ASCO AI in Oncology rapporte que le Health AI Partnership a proposé un cadre de divulgation des fournisseurs d’IA pour les systèmes de santé, couvrant ce que fait un outil, comment il a été testé, ce qu’il advient des données de l’organisation, ce que nécessite son intégration, combien il coûte et qui le surveille après son lancement. Cette dernière question est celle où de nombreux projets pilotes deviennent des problèmes d’achat. Si le suivi n’est ni budgété, ni doté en personnel, ni soutenu techniquement, l’hôpital a acheté une promesse sans tableau de bord derrière.

Pour les fournisseurs, le suivi du cycle de vie devrait donc être conçu avant que l’équipe commerciale ne promette un déploiement. Un contrat devrait pouvoir identifier l’utilisation prévue, les utilisateurs prévus, les populations concernées, les preuves de test, les engagements de traitement des données et la responsabilité du suivi après lancement, car ce sont les questions qu’ASCO dit que les équipes d’achat sont encouragées à poser. Pour les hôpitaux, le même point fonctionne en sens inverse : n’acceptez pas une démonstration comme preuve que l’outil peut être exploité en toute sécurité dans votre environnement. Demandez qui reçoit les signaux de performance, qui peut suspendre l’utilisation et ce que le fournisseur doit fournir lorsque le système change.

Les incidents, les contrôles cyber et la formation ne sont pas des quêtes secondaires

MobiHealthNews rapporte que la proposition britannique appelle à la déclaration des incidents de sécurité liés à l’IA, à des exigences de cybersécurité renforcées et à la formation des utilisateurs. En clair, cela signifie que la réponse aux incidents ne peut pas commencer lorsqu’un clinicien soulève une inquiétude en réunion. Les produits doivent soutenir l’enquête, l’examen de sécurité et l’escalade d’une manière que les équipes cliniques, de gouvernance de l’information et fournisseurs peuvent réellement utiliser. La loi ne donne peut-être pas encore chaque ligne de détail, mais le dossier d’achat ne se satisfera pas d’espaces vides.

Layer3 Labs note qu’en vertu du RGPD britannique et européen, les données de santé sont des données de catégorie particulière, que leur traitement est interdit par défaut, et que les organisations ont besoin à la fois d’une condition au titre de l’article 9 et d’une base légale au titre de l’article 6 avant d’utiliser l’IA sur des données de patients ou de santé. Son guide signale aussi des obligations propres à l’IA concernant les analyses d’impact, les contrats fournisseurs, les transferts internationaux et les décisions automatisées. En pratique, la déclaration des incidents et la cybersécurité sont liées à la conformité en matière de confidentialité, et non placées à côté. Si un fournisseur ne peut pas expliquer où vont les données de santé, ce que disent les clauses de sous-traitance et comment l’accès depuis l’étranger est contrôlé, la conversation sur la sécurité de l’IA comporte déjà un problème de protection des données.

Les débats sur le périmètre vont se resserrer

Digital Colliers indique que la première question réglementaire pour les fournisseurs d’IA en santé en Europe est de savoir si le système est un dispositif médical, en notant que l’IA destinée au diagnostic, au traitement ou au suivi d’une maladie ou d’une blessure, ou à la prise de décision clinique, est généralement classée ainsi dans l’UE. Legal Nodes indique séparément que l’AI Act de l’UE place la plupart des outils d’IA en santé dans la catégorie à haut risque. Ce ne sont pas des tests identiques, et c’est précisément ce qui complique les choses. Un produit peut être soumis en même temps à une analyse au titre des dispositifs médicaux, à des obligations de l’AI Act, aux exigences du RGPD et à l’examen des achats hospitaliers.

La préparation utile est donc très concrète. Conservez une déclaration d’utilisation prévue que les équipes produit, réglementaires et commerciales ne peuvent pas réécrire discrètement. Maintenez des preuves de test qui nomment la population et le contexte, pas seulement la métrique. Intégrez la formation des utilisateurs dans le déploiement, surtout lorsque l’outil affecte des décisions cliniques ou opérationnelles. Suivez la prochaine étape de la proposition britannique, mais n’attendez pas le premier avis d’application pour découvrir que le suivi, la déclaration, la sécurité et la formation auraient dû être intégrés au plan de lancement.