Gouvernance de l'IA dans la santé : Conformité et sécurité

Les organisations de santé ont adopté l’IA plus rapidement qu’elles n’ont mis en place la gouvernance nécessaire. Quatre-vingt-huit pour cent des systèmes de santé utilisent déjà l’IA en interne, tandis que seulement 18 % disposent à la fois d’une gouvernance mature de l’IA et d’une stratégie IA pleinement élaborée.

La Healthcare Financial Management Association a rapporté les deux chiffres dans Health System Readiness for AI, à partir d'une enquête de mai 2025 auprès de plus de 230 dirigeants de systèmes de santé.

L'IA arrive rarement par le biais des achats, ce qui lui permet de dépasser l'inventaire. Une licence Microsoft 365 Copilot est ajoutée à un accord existant, une fonction de documentation ambiante est intégrée dans le dossier médical électronique (EHR), ou un clinicien utilise un appareil personnel.

Le Shadow AI Report de décembre 2025 de Wolters Kluwer Shadow AI Report a sondé 518 prestataires et administrateurs hospitaliers et a constaté que 57 % avaient rencontré ou utilisé un outil d'IA non autorisé.

Ne pas savoir ce qu’un outil d’IA peut atteindre devient un problème de responsabilité dès qu’un membre du conseil d’administration ou un auditeur demande quels outils manipulent des informations de santé protégées (PHI), qui en est propriétaire et ce qui prouve que les contrôles fonctionnent.

Qu'est-ce que la gouvernance de l'IA en santé ?

Gouvernance de l'IA dans le secteur de la santé est la discipline qui consiste à savoir où les systèmes d'IA accèdent aux PHI, qui est responsable de chaque cas d'utilisation et si les contrôles autour de cet accès peuvent être prouvés efficaces. Les organisations sous-estiment le troisième élément car elles considèrent une politique écrite comme une preuve, alors qu'elle ne décrit que l'intention.

Un comité du conseil ou un auditeur externe teste si l'organisation peut dire, sur le champ, ce qu'un outil d'IA spécifique atteint et qui en est propriétaire. La plupart des organisations de santé ne le peuvent pas, car Copilot pilots, l'IA intégrée du fournisseur et les outils conversationnels atteignent des systèmes adjacents à PHI avant que la sécurité ne termine leur catalogage.

Les conséquences apparaissent dans les données de violation. Le Netwrix 2026 Data and Identity Security Report a enregistré un taux de violation de 43 % au cours des 12 derniers mois dans les organisations où l'IA a considérablement augmenté l'empreinte d'identité, contre 11 % là où l'IA ne l'a pas modifiée de manière significative.

L'enquête à l'origine de ce rapport a également révélé que seulement 21 % des organisations disposent d'une visibilité complète, d'une surveillance et de contrôles sur les données sensibles utilisées par les outils, modèles ou copilotes d'IA.

Pourquoi le secteur de la santé présente un niveau de risque IA différent

Le cas générique de la gouvernance de l'IA repose sur le risque réputationnel et opérationnel. Dans le secteur de la santé, l'exposition est réglementée, les données sont exceptionnellement précieuses, et la responsabilité incombe au fournisseur, pas à celui qui a construit le modèle. La cybersécurité dans la santé porte déjà cette asymétrie.

Un dossier médical volé n’expire jamais

La plupart des données réglementées ont une durée de vie, ce qui limite la valeur d’une violation. Une carte de paiement volée est annulée et réémise en quelques jours. Un dossier médical contient des diagnostics, des détails d’assurance, des données démographiques et un numéro de Sécurité sociale, aucun de ces éléments ne pouvant être réémis, il reste exploitable pendant des années après la violation qui l’a produite.

Le secteur de la santé ne peut donc pas compter sur la protection gratuite dont bénéficient d’autres secteurs. Un outil d’IA qui accède à PHI crée une exposition sans date d’expiration, ce qui augmente le coût d’une erreur dans la conception des accès plutôt que seulement la probabilité d’une erreur.

Le fournisseur assume la responsabilité même lorsqu’un vendeur cause la violation

Les organisations de santé soumises à HIPAA, que la règle appelle entités couvertes, restent légalement responsables des PHI, quel que soit le modèle qui les traite. C’est ce qui distingue l’achat d’IA ici de l’achat d’IA dans un secteur non réglementé, où un contrat fournisseur peut transférer le risque. Les règles de conformité HIPAA qui régissent tous les autres systèmes s’appliquent à l’IA sans changement.

Le Département de la Santé et des Services sociaux (HHS) Bureau des droits civils (OCR) considère un chatbot IA tiers traitant des PHI sur un portail patient comme un business associate, le même statut qu'il applique aux fournisseurs cloud. Les business associates ont des obligations directes propres, ce qui ne diminue pas celles du fournisseur. L'OCR a déjà réglé des litiges avec des fournisseurs pour des défaillances de prestataires, y compris le North Memorial settlement lié à une absence de Business Associate Agreement (BAA).

Un seul processus de révision ne peut couvrir les deux types d’IA qu’un hôpital utilise

La plupart des secteurs déploient une seule classe d'IA et la gèrent d'une seule manière. Un hôpital en utilise deux simultanément, et elles échouent de manière suffisamment différente pour qu'un seul processus de révision en manque une.

Un outil de diagnostic échoue lorsqu'il atteint un patient avec une recommandation erronée ou biaisée, ce qui est une question de sécurité des patients pour la direction clinique et souvent pour la FDA. Un assistant de productivité échoue en exposant des PHI à quelqu'un qui n'aurait jamais dû les voir, ce qui est une question de contrôle d'accès pour la sécurité. Soumettre les deux au même comité signifie que les outils administratifs subissent un examen de type clinique dont ils n'ont pas besoin, tandis que personne ne demande ce à quoi ils peuvent réellement accéder.

Une violation dans le secteur de la santé coûte plus cher que partout ailleurs

Le secteur de la santé a enregistré le coût moyen le plus élevé des violations de données depuis plus d'une décennie, atteignant 6,64 millions de dollars en 2026 (en baisse par rapport à 7,42 millions en 2025) selon IBM's Cost of a Data Breach Report. Aucun autre secteur n'est resté aussi longtemps en tête.

Ce chiffre est ce qui fait du design d'accès IA une question au niveau du conseil d'administration plutôt qu'informatique. Il fixe le prix de l'erreur, et c'est généralement le chiffre que le conseil retient d'un briefing.

La différence entre l'IA clinique et l'IA administrative dans les soins de santé

La gouvernance se divise entre l'IA qui informe les soins et l'IA qui gère le travail autour. Chaque partie a des propriétaires, des régulateurs et des questions différents à traiter.

La validation clinique de l'IA est une discipline sérieuse avec son propre cadre réglementaire, et ce n'est pas quelque chose qu'une plateforme de visibilité des données devrait prétendre résoudre. L'IA administrative appartient à la sécurité, à l'informatique et à la confidentialité, et c'est là que les questions d'accès posées par un conseil d'administration se retrouvent réellement.

Comment les régulateurs américains réagissent à l'IA dans la santé

L'élaboration des règles fédérales, l'accréditation et la législation étatique progressent toutes, et aucune ne nécessite d'attendre une règle finale avant d'agir. Les régulateurs considèrent l'IA comme une extension des obligations existantes, de sorte que les nouvelles exigences s'appliquent aux systèmes de santé déjà gérés par la machinerie HIPAA.

La mise à jour de la règle de sécurité HIPAA nomme directement l'IA

Le HHS a publié un avis de proposition de réglementation (NPRM) sur la règle de sécurité HIPAA qui traite explicitement de l'intelligence artificielle. Sa proposition de analyse des risques pour les informations électroniques protégées (ePHI) nomme directement les outils d'IA. Elle exige une "considération répétée, entre autres, du type et de la quantité d'ePHI accessible par les outils d'intelligence artificielle, à qui les données sont divulguées et à qui la sortie est fournie."

La règle reste proposée, et l'OCR continue d'appliquer la Security Rule actuelle. Les entités couvertes qui effectuent des HIPAA risk analyses devraient déjà documenter aujourd'hui comment les outils d'IA interagissent avec ePHI.

La Joint Commission certifie désormais la gouvernance de l'IA

La Joint Commission a lancé sa Responsible Use of AI in Healthcare certification le 1er juin 2026, le premier programme de certification basé sur la manière dont les systèmes de santé gouvernent l’IA plutôt que sur les produits d’IA eux-mêmes.

Elle délivre la certification au niveau de l’organisation ou du système, et ses normes couvrent la gouvernance, la gestion des données, la réduction des risques et des biais, la surveillance et la validation, ainsi que la transparence et la formation.

La certification est volontaire, bien que les organisations accréditées doivent s'attendre à ce que les attentes sous-jacentes apparaissent dans les discussions des enquêtes.

Les lois étatiques sur l'IA s'ajoutent à HIPAA

La législation étatique ajoute des obligations plutôt que de remplacer les obligations fédérales, de sorte que les systèmes de santé opérant entre plusieurs États héritent de exigences qui varient selon le lieu de prestation des soins.

La Texas Responsible Artificial Intelligence Governance Act exige la divulgation au patient lorsque les prestataires utilisent l'IA dans les soins depuis le 1er janvier 2026, et l'AB 3030 de Californie exige des avertissements sur les communications générées par l'IA concernant les informations cliniques du patient.

La préemption fédérale semble peu susceptible d'alléger ce fardeau. Le Sénat a voté 99 contre 1 en juillet 2025 pour supprimer un moratoire de dix ans sur la réglementation étatique de l'IA du projet de loi de réconciliation budgétaire, laissant aux opérateurs multi-étatiques des obligations cumulatives spécifiques à chaque juridiction.

Les obligations de la FDA et du EU AI Act restent de portée clinique

Supervision de la FDA sur les dispositifs médicaux équipés d'IA et les règles à haut risque du EU AI Act imposent toutes deux des exigences réelles, et concernent principalement l'IA qui informe le diagnostic ou le traitement. Une équipe évaluant l'IA administrative doit néanmoins confirmer dans quelle catégorie chaque outil se situe, car la documentation ambiante et les outils de triage sont plus proches de la ligne clinique que ce que suggèrent parfois leurs fournisseurs.

Pourquoi Microsoft 365 Copilot mérite sa propre discussion sur la gouvernance

Copilot est le seul outil administratif d’IA que la plupart des systèmes de santé déploient à l’échelle du locataire, et il nécessite un traitement séparé car il ne change rien aux autorisations tout en changeant tout sur qui les remarque.

La documentation de Microsoft indique que Copilot « ne révèle que les données organisationnelles auxquelles les utilisateurs individuels ont au moins des permissions de consultation. » Chaque question de gouvernance repose donc sur ce que ces permissions autorisent déjà, ce qui engendre trois problèmes qu’un document de politique ne peut résoudre :

• L'effort s'effondre, donc l'accès dormant est utilisé : Quelqu'un qui pouvait déjà ouvrir un fichier dans SharePoint ou rechercher dans une boîte aux lettres peut maintenant demander à Copilot de le résumer, de le faire apparaître dans une autre conversation ou de l'intégrer dans un brouillon. La permission était toujours là. Ce qui disparaît, c'est le travail nécessaire pour l'exercer, d'une recherche délibérée à une phrase en langage naturel.
• Un partage excessif ancien devient une exposition actuelle : Les liens de partage larges, les permissions obsolètes et les adhésions à des groupes non révisées depuis une réorganisation restent inoffensifs jusqu'à ce que quelque chose commence à les parcourir rapidement. La licence Copilot dans un tenant de santé est ce moment, c’est pourquoi Copilot data security commence par un audit des permissions.
• Afficher des PHI au mauvais clinicien enfreint HIPAA : Lorsque ce contenu partagé excessivement est des PHI, le montrer à des utilisateurs qui n'en ont pas besoin viole la norme du minimum nécessaire à 45 CFR 164.502(b). Le chiffrement par étiquette de sensibilité modifie substantiellement l'exposition, car Copilot a besoin des droits d'extraction pour résumer le contenu.

Les systèmes de santé ayant réalisé ce travail rapportent que la remédiation des permissions atteint des millions de corrections individuelles de partage avant un déploiement à l’échelle du locataire, ce qui fait de la préparation un projet plutôt qu’une simple case à cocher.

Comment créer un programme de gouvernance de l'IA en santé

Chacune de ces décisions appartient à un leader qui la prend puis délègue le travail, et elles doivent se faire dans l'ordre. Nommez un responsable avant que l'inventaire n'existe, et cette personne n'a encore rien à gérer.

Nommez un seul propriétaire responsable

"Le comité de gouvernance de l'IA s'en chargera," sans personne nommée derrière, c'est ainsi que ces programmes stagnent. Peu importe que cette personne soit en sécurité, conformité ou IT, ce qui compte est qu'une personne soit responsable, comme un responsable de la confidentialité HIPAA l'est pour la confidentialité.Les directives de la Joint Commission attendent un propriétaire nommé qui dirige la mise en œuvre de l'IA tout au long du cycle de vie.

Basez l'inventaire sur ce que chaque outil peut réellement atteindre

Cataloguez chaque système d’IA touchant les flux cliniques, administratifs ou intégrés, et associez chacun aux données PHI ou adjacentes à PHI qu’il peut atteindre. Orientez chaque entrée vers le propriétaire capable d’évaluer ses défaillances, envoyant les outils de diagnostic à la revue clinique et les outils de productivité à la sécurité.

La plupart des inventaires commencent à partir de rien, car la découverte elle-même est généralement informelle. Une enquête de décembre 2025 menée auprès de 51 organisations de santé par Censinet et la CHIME Foundation a révélé que 51 % s'appuyaient soit sur une découverte informelle ad hoc, soit sur les notes de version du fournisseur pour savoir quelle AI ils utilisaient. Les risques de sécurité de Shadow AI s'accumulent tant que cette découverte reste informelle.

Confirmez que la couverture du fournisseur et du BAA correspond à l'utilisation réelle de l'IA

Chaque fournisseur d'IA qui crée, reçoit, conserve ou transmet des PHI a besoin d'un BAA qui explique comment l'IA du fournisseur traite, stocke et conserve les PHI. Un BAA standard signé avant l'intégration de l'IA dans le produit crée une véritable lacune en matière de responsabilité, même si l'accord est toujours en vigueur, donc les mises à jour du produit du fournisseur devraient déclencher la révision plutôt que les dates de renouvellement.

Examinez spécifiquement les termes relatifs au service couvert, à l’utilisation des données, à la conservation, aux sous-traitants et à la sécurité. Vérifiez le contrat de service standard avec le BAA, car un BAA signé ne remplace pas les termes séparés accordant au fournisseur des droits étendus d’utilisation des données clients. La couverture varie également selon la gamme de produits. OpenAI propose des BAA pour les déploiements éligibles de ChatGPT Enterprise utilisant un Regulated Workspace, tandis que ChatGPT Business reste inéligible.

Définissez des contrôles de données et d'identité en fonction de ce que l'inventaire a trouvé

Les restrictions d'accès et la surveillance doivent prendre en compte l'exposition réellement révélée par l'inventaire. Un langage de moindre privilège rédigé avant que l'on sache quels systèmes l'IA pouvait atteindre ne résistera pas à la question de suivi d'un auditeur. Une évaluation des risques d'identity and access management limitée aux systèmes inventoriés produit cette spécificité.

Le contrôle résultant doit être concret, pas une déclaration de politique. Si l'inventaire montre que Copilot peut accéder à un partage de fichiers contenant des feuilles de calcul du recensement des patients, le contrôle est une remédiation des permissions sur ce partage, avec une date et un propriétaire.

Mettez en place un chemin de surveillance et d'escalade

Un programme a besoin d’un moyen de détecter l’exposition aux PHI pilotée par l’IA au moment où elle se produit, et d’une personne désignée à qui escalader lorsque la détection se déclenche. La détection signifie surveiller les référentiels que les outils IA consultent, ce qui est une surveillance d’accès aux fichiers ordinaire pointée vers un nouveau consommateur. Sans la partie escalade, le premier signe d’un problème est un rapport d’incident là où une revue de gouvernance aurait dû avoir lieu.

Utiliser NIST AI RMF et HIPAA comme modèle opérationnel

NIST AI RMF fournit la structure pour un programme de gouvernance de l'IA en santé, et HIPAA fournit les détails juridiques ; ensemble, ils suppriment le besoin d'un cadre personnalisé.

Les quatre fonctions de NIST s’intègrent parfaitement dans un programme de gouvernance. Govern est le propriétaire responsable désigné, Map est l’inventaire, Measure est l’évaluation des risques réels de chaque cas d’utilisation, et Manage correspond aux contrôles et à la surveillance continus. Le cycle fonctionne en continu, pas comme une configuration unique.

L'attente en matière d'inventaire est explicite, car Subcategory GOVERN 1.6 exige des mécanismes pour inventorier les systèmes d'IA, et l'inventaire des actifs technologiques proposé par le NPRM rendrait cette attente réglementaire.

Les règles de confidentialité et de sécurité HIPAA fournissent ensuite les obligations légales sous cette structure chaque fois que des PHI sont impliquées. Ensemble, elles produisent un cadre large et lisible, et aucune des deux structures ne nécessite de certification formelle.

La preuve que l'accès à PHI est réellement contrôlé

Les auditeurs et les comités du conseil demandent des artefacts, et la récupération est là où la plupart des programmes échouent : ils font le travail, puis dispersent les preuves sur six systèmes et dans les boîtes de réception de quatre personnes. Chaque artefact doit exister avant que la question n'arrive.

Un inventaire actuel du système d’IA avec un propriétaire nommé

Chaque système catalogué, lié à une personne nommée, pas à un département, qui peut répondre lorsqu'un auditeur demande qui a approuvé une extension Copilot donnée. L'entrée doit également enregistrer quelles PHI le système peut atteindre, afin que l'inventaire et la carte du flux de données restent conciliables plutôt que de dériver en deux documents distincts.

Une carte du flux de données montrant où la PHI entre dans un outil d’IA

Chaque endroit où PHI entre dans un outil d'IA, une invite, un fichier, un embedding ou une sortie, localisé par outils de découverte de données sensibles le long de chaque chemin. La règle de sécurité HIPAA proposée exigerait une carte réseau ePHI mise à jour au moins annuellement, ce qui fait de cet artefact une exigence réglementaire plutôt qu'une bonne pratique.

Documentation fournisseur et BAA spécifique à chaque outil d'IA

Documentation liée à la capacité IA spécifique que chaque fournisseur propose, et non un dossier BAA général, correspondant à la couverture confirmée lors de la mise en place du programme. Un tel dossier ne répond pas à la question que se pose réellement un examinateur.

Rapports d'accès et d'autorisations montrant qui peut atteindre les systèmes adjacents à PHI

Une réponse instantanée sur ce qu’un outil d’IA peut voir, c’est-à-dire les identités et groupes ayant accès aux dépôts sous-jacents, et non l’écran de configuration de l’outil. Les paramètres de Copilot décrivent ce qu’il fera avec les permissions qu’il possède déjà, donc un rapport basé uniquement sur l’outil sous-estime la portée. Un examinateur demande les permissions effectives, y compris l’accès hérité via des groupes imbriqués.

Un journal des modifications indiquant quand cet accès a changé

La dérive des accès au fil des mois depuis le dernier instantané, plus large ou plus restreinte qu’avant, quelque chose qu’un seul rapport d’accès ne peut pas montrer à lui seul. C’est cette tendance qu’un auditeur demande réellement à voir.

Enregistrements de revue de gouvernance montrant que le programme fonctionne réellement

Procès-verbaux, approbations ou notes de révision démontrant une cadence réelle. Le cadre de gouvernance cyber IA du Health Sector Coordinating Council de mai 2026 AI cyber governance framework recommande des rapports structurés trimestriels sur les risques IA au conseil d'administration.

Une organisation capable de fournir chacun d'eux sur demande a un programme. Celle qui met une semaine à les rassembler a une politique.

Comment Netwrix prend en charge la couche de preuve

Netwrix fournit la couche de visibilité des données et de preuves d'audit sous un programme que l'organisation de santé construit et possède, répondant à la question des dépôts contenant des PHI, qui peut y accéder et ce qui a changé. La gouvernance de l'information dans le secteur de la santé dépend de la possibilité de récupérer ces réponses.

Visibilité des données sensibles

Netwrix 1Secure identifie les référentiels contenant des PHI accessibles par Copilot et d’autres outils d’IA et évalue la préparation de Copilot avant le déploiement, pas après. Netwrix Access Analyzer ajoute la découverte automatisée des PHI et la cartographie préconçue de conformité HIPAA sur les serveurs de fichiers, SharePoint et les environnements hybrides, avec des modèles de détection couvrant les codes ICD-10, les numéros de dossiers médicaux et les noms de médicaments sur ordonnance.

Contexte d'Identity et d'accès

Netwrix Access Analyzer rapporte les autorisations effectives sur les données adjacentes à PHI, y compris les accès excessifs et hérités que de larges groupes obtiennent sans que personne ne le remarque. Netwrix 1Secure et Netwrix Auditor rapportent l’activité et les modifications des autorisations dans Active Directory et Microsoft Entra ID au fil du temps.

King's College Hospital a utilisé Netwrix Auditor pour renforcer le contrôle des privilèges accédant aux données des patients, avec une visibilité complète sur un réseau de 10 000 utilisateurs soutenant ses rapports de conformité au National Health Service.

Preuve d’audit

Netwrix Auditor enregistre les modifications d’accès et de permissions, capturant qui a accédé à quoi, quand, et ce qui a changé, avec les valeurs avant et après. Son Archive à Long Terme conserve les preuves plus anciennes, ce qui permet de garder un journal des modifications utilisable sur un cycle d’audit complet et pas seulement depuis la dernière période de conservation.

Netwrix 1Secure couvre l’aspect IA de la même question. Il rapporte les interactions de Microsoft 365 Copilot et suit les données sensibles auxquelles Copilot a accédé et qu’il a affichées, ce qui est l’élément qui répond à ce qu’un outil a réellement atteint plutôt que ce qu’il était autorisé à atteindre.

Là où Netwrix s’arrête

Netwrix ne fournit pas de gouvernance de l’IA en santé en tant que catégorie et ne garantit pas la conformité HIPAA. Il ne gouverne ni n’applique de politique à Copilot ou à tout autre outil d’IA, et ne valide pas les modèles cliniques ni ne détecte les biais cliniques. Son rôle est la couche de preuve sous un programme de gouvernance détenu par l’organisation.

Découvrez ce que vos outils d’IA peuvent réellement atteindre avant qu’un auditeur ne le demande

La plupart des organisations de santé ne peuvent pas encore répondre à ce que Copilot et les autres outils administratifs d'IA atteignent, et la raison est rarement une politique manquante. Personne ne l'a cartographié.

Cette cartographie est le point de départ du programme, car elle indique au propriétaire responsable quels dépôts sont importants et transforme une liste d’artefacts requis en rapports que quelqu’un peut réellement exécuter. Les équipes évaluant une couche de preuve doivent tester si elle peut cartographier l’exposition PHI, calculer l’accès effectif, préserver l’historique des modifications des permissions et produire ces enregistrements à la demande.

Demandez une démo pour voir à quels référentiels adjacents à PHI vos outils d’IA peuvent accéder, qui détient l’autorisation sur ces données et comment cet accès a évolué dans le temps.