Le secteur de la santé met en place des comités de gouvernance de l’IA partout. Pourtant, presque personne ne sait réellement quelles IA sont utilisées.
Le secteur de la santé raffole des comités. On crée un organe de gouvernance, on rédige une charte, on nomme des représentants de différents services, on planifie des réunions trimestrielles. On coche la case.
Le problème, c’est que les comités ne gouvernent rien s’ils n’ont aucune visibilité sur ce qui se passe. Et aujourd’hui, la plupart des organisations de santé ne savent pas ce que l’IA fait réellement dans leur environnement.
C’est la principale conclusion de l’étude de référence 2026 sur la cybersécurité dans la santé, annoncée par Censinet lors de ViVE 2026 à Los Angeles. Réalisée en partenariat avec l’American Hospital Association, Health-ISAC, le Health Sector Coordinating Council, le Scottsdale Institute et l’Université du Texas à Austin, cette étude a interrogé un large panel d’organisations de santé sur leur maturité en cybersécurité et leur niveau de préparation à la gouvernance de l’IA. Les résultats dressent le portrait d’un secteur qui a bâti une solide structure de gouvernance autour de l’IA, mais dont les fondations opérationnelles restent inachevées.
Les chiffres sont éloquents. 70 % des organisations de santé ont mis en place des comités de gouvernance de l’IA. Seules 30 % tiennent un inventaire de l’IA à l’échelle de l’entreprise. Plus de la moitié n’ont aucune méthode documentée pour détecter l’intégration de l’IA par les fournisseurs dans leurs produits existants. Et 64 % expérimentent ou déploient déjà de l’IA agentique — des systèmes autonomes capables de raisonner, d’agir et d’interagir avec les ressources de l’entreprise de façon indépendante.
Ed Gaudet, CEO de Censinet, résume ce décalage : le secteur de la santé a bâti la structure de gouvernance de l’IA, mais la partie opérationnelle — inventaire, gestion des actifs, méthodes de détection et responsabilité claire — ne suit pas le rythme de l’adoption.
Cela a des conséquences majeures pour un secteur qui traite certaines des données les plus sensibles qui existent. Lorsque des systèmes d’IA traitent des informations médicales protégées sans suivi d’inventaire, sans journal d’audit et sans propriétaire clairement identifié, il ne s’agit pas seulement d’un problème de conformité. C’est un risque pour la sécurité des patients. Et c’est précisément ce fossé — entre structure de gouvernance et application opérationnelle — que des plateformes de gouvernance des données comme Kiteworks visent à combler.
5 enseignements clés
- Le secteur de la santé réagit mieux aux attaques qu’il ne les prévient. L’étude de référence 2026 confirme une tendance qui devrait alerter tous les RSSI du secteur : les organisations ont renforcé leurs capacités de réponse aux incidents, mais les contrôles préventifs essentiels — gouvernance, gestion des actifs, préparation de la supply chain — restent à la traîne. Le secteur de la santé investit dans la gestion des conséquences des violations, mais sous-investit dans leur prévention.
- Les comités de gouvernance de l’IA existent. Les contrôles opérationnels, non. 70 % des organisations de santé ont mis en place des comités de gouvernance de l’IA. Seules 30 % tiennent un inventaire de l’IA à l’échelle de l’entreprise. Un écart de 40 points sépare la mise en place d’une structure de gouvernance et la connaissance réelle des systèmes d’IA présents dans l’organisation. Des comités sans visibilité ne font que de la figuration. Pour combler ce fossé, il faut une infrastructure opérationnelle — comme des journaux d’audit et l’application de la classification des données — qui offre aux comités de gouvernance la visibilité en temps réel nécessaire pour faire appliquer leurs propres règles.
- L’IA fantôme des fournisseurs : l’angle mort ignoré de tous. Plus de la moitié des organisations de santé n’ont aucune méthodologie documentée pour détecter l’intégration de fonctions d’IA dans les produits existants par les fournisseurs. Cela signifie que l’IA peut traiter des informations médicales protégées à l’instant même — via des outils déjà validés par l’organisation — sans que personne ne le sache. Les processus d’approbation conçus pour le produit d’origine ne couvrent pas ce qu’il devient après une mise à jour intégrant l’IA. Une surveillance continue des schémas d’accès aux données des fournisseurs permet de détecter les changements de comportement révélant de nouvelles fonctions, et les journaux d’audit documentent précisément quelles données les fournisseurs consultent sur chaque canal.
- L’IA agentique est déjà en production — la gouvernance ne suit pas. 64 % des organisations de santé expérimentent ou déploient activement de l’IA agentique. Seules 8 % y opposent un refus catégorique. Parmi celles qui estiment que l’adoption de l’IA dépasse leur niveau de préparation, plus de la moitié déclarent avoir avant tout besoin de procédures de gouvernance mieux formalisées. Le train de l’adoption est déjà parti. La clôture de la gouvernance est encore en construction. Une gouvernance efficace impose un accès aux données selon le principe du moindre privilège, des restrictions liées à la finalité, une vérification continue et une infrastructure d’audit qui transforme les politiques de gouvernance en contrôles effectifs.
- Les établissements de santé ruraux font face aux mêmes menaces avec beaucoup moins de ressources. Les systèmes de santé ruraux sont au même niveau que leurs homologues sur les fondamentaux du NIST Cybersecurity Framework, mais ils sont deux fois plus susceptibles de n’avoir aucune gouvernance de l’IA. Ils subissent les mêmes cybermenaces et la même pression à adopter l’IA que les plus grands groupes du pays — sans le budget, ni la profondeur d’effectif, ni l’expertise spécialisée pour gérer le risque. Le déficit de gouvernance de l’IA dans la santé rurale n’est pas un problème technologique. C’est un problème de ressources qui exige des solutions évolutives offrant une gouvernance de niveau entreprise sans nécessiter de personnel dédié.
Meilleurs en réaction, moins là où ça compte
L’étude de référence met en lumière un déséquilibre de maturité qui perdure depuis plusieurs années. Les organisations de santé ont progressé dans leur capacité à répondre aux incidents de cybersécurité. Les capacités de détection se sont améliorées. Les plans de réponse aux incidents sont plus aboutis. Les procédures de reprise sont mieux documentées.
Mais le versant préventif — les contrôles qui empêchent les violations en amont — reste à la traîne. Les structures de gouvernance demeurent incomplètes. Les pratiques de gestion des actifs ne couvrent pas l’ensemble de l’infrastructure numérique, en particulier les charges de travail liées à l’IA. La préparation de la supply chain est sous-développée, alors même que le secteur dépend fortement des fournisseurs et partenaires commerciaux.
Ce schéma ne concerne pas que la santé, mais il y est particulièrement dangereux. Les cyberattaques criminelles ou soutenues par des États continuent de cibler l’infrastructure critique du secteur. L’intégration rapide de l’IA, sans supervision adéquate, introduit de nouveaux vecteurs de risques qui touchent directement la sécurité des patients et la qualité des soins. John Riggi, National Advisor for Cybersecurity and Risk à l’American Hospital Association, l’affirme sans détour : la cybersécurité et la gouvernance de l’IA ne sont plus des disciplines séparées. Protéger l’une, c’est protéger l’autre.
Concrètement, les organisations de santé doivent rééquilibrer leurs investissements en cybersécurité. Les capacités de réaction sont nécessaires mais insuffisantes. La prévention — c’est-à-dire la gouvernance, la visibilité sur les actifs, le contrôle des accès et la supervision de la supply chain — est le domaine où le sous-investissement crée le plus de vulnérabilités.
L’écart de 40 points entre gouvernance et visibilité
70 % avec des comités de gouvernance de l’IA. 30 % avec un inventaire de l’IA. Cet écart de 40 points est le chiffre le plus marquant de l’étude 2026.
Un comité de gouvernance de l’IA sans inventaire, c’est une réunion de conseil sans ordre du jour. Le comité peut définir des règles, valider des cas d’usage, fixer des seuils de risque — mais il ne peut rien faire appliquer s’il ignore quels systèmes d’IA existent, quelles données ils consultent, qui les a autorisés ou quelles actions ils réalisent.
Le problème de l’inventaire ne se limite pas à compter les outils d’IA. Il s’agit de comprendre les flux de données. Quels systèmes d’IA accèdent à des informations médicales protégées ? Quelles données ont servi à entraîner ou à affiner les modèles ? Quels produits de fournisseurs intègrent désormais des fonctions d’IA qui n’existaient pas lors de la signature du contrat initial ? Qui a autorisé l’accès de chaque système d’IA, et dans quelles conditions cet accès peut-il être révoqué ?
Sans réponse à ces questions, les comités de gouvernance avancent à l’aveugle. Ils peuvent produire des règles. Ils ne peuvent pas vérifier la conformité à ces règles. Et dans un environnement réglementaire régi par l’HIPAA, le NIST AI Risk Management Framework et des exigences sectorielles croissantes sur l’IA, l’incapacité à prouver la conformité opérationnelle constitue en soi un risque majeur.
Pour combler cet écart, il faut une infrastructure opérationnelle dont la plupart des comités de gouvernance ne disposent pas. Des journaux d’audit suivent chaque interaction de l’IA avec les données de santé, une journalisation centralisée consigne qui a accédé à quoi, quand et via quel système, et la classification des données permet d’appliquer automatiquement les règles d’accès sans dépendre d’une revue manuelle. Le comité de gouvernance définit la stratégie. L’exécution opérationnelle transforme la stratégie en contrôles applicables et en preuves auditées.
L’IA fantôme ne vient pas des employés, mais de vos fournisseurs
Le récit classique de l’IA fantôme met l’accent sur les employés qui utilisent des outils d’IA non autorisés — comptes personnels ChatGPT, extensions de navigateur non validées, plateformes gratuites. Ce risque est réel et bien documenté.
Mais l’étude Censinet met en lumière une autre forme d’IA fantôme, plus difficile à détecter et potentiellement plus dangereuse : des fonctions d’IA discrètement intégrées dans des produits et plateformes déjà validés par les organisations de santé.
Plus de la moitié des organisations de santé n’ont aucune méthodologie documentée pour détecter ce phénomène. Un fournisseur met à jour une plateforme existante avec des analyses dopées à l’IA. Un partenaire commercial intègre du machine learning dans une chaîne de traitement de données. Un module de Dossier Patient Informatisé ajoute une aide à la décision clinique pilotée par l’IA. À chaque fois, le produit a été validé par le processus d’achat standard — avant l’ajout de l’IA. Le comité de gouvernance a examiné et approuvé un produit. Le produit a changé. La revue n’a pas eu lieu à nouveau.
Cela crée un risque de conformité précis au regard de l’HIPAA. Si une fonction d’IA d’un fournisseur traite des informations médicales protégées d’une manière non couverte par l’accord de partenariat existant, l’organisation peut être exposée sans le savoir. Les données circulent. L’IA traite. Et le journal d’audit qui permettrait de prouver la conformité — ou de révéler une violation — n’existe pas.
Détecter l’IA intégrée par les fournisseurs exige une surveillance continue des schémas d’accès aux données, et non des évaluations ponctuelles. Kiteworks surveille tous les canaux par lesquels les fournisseurs interagissent avec les données de l’organisation — messagerie électronique, partage de fichiers, API, transferts SFTP et accès direct au système — via une infrastructure d’audit unifiée. Dès qu’un compte fournisseur présente un comportement inhabituel — variation soudaine du volume de données, de la fréquence d’accès ou de la complexité des requêtes — Kiteworks signale immédiatement l’écart. Cela permet aux équipes de sécurité d’identifier les changements de produits fournisseurs qui impactent le traitement des informations médicales protégées.
Les comités et les processus d’approbation seuls ne suffisent pas à résoudre ce problème. Il faut une surveillance opérationnelle continue qui suit l’accès aux données en temps réel et détecte les écarts révélateurs de nouvelles fonctions non validées.
L’IA agentique est déjà là. La gouvernance, non.
La conclusion la plus marquante de l’étude 2026 est sans doute le rythme d’adoption de l’IA agentique. 64 % des organisations de santé expérimentent ou déploient activement des systèmes d’IA agentique — des IA autonomes capables d’exécuter des processus complexes, d’accéder à des bases de données, d’interagir avec des API et de prendre des décisions opérationnelles avec peu de supervision humaine.
Seules 8 % ont fixé une limite stricte à l’adoption de l’IA agentique. Les autres se situent entre exploration et déploiement en production.
L’IA agentique introduit un profil de risque fondamentalement différent des chatbots et outils d’analyse qui dominaient les premières vagues d’IA dans la santé. Un chatbot répond à des questions à partir des données qu’on lui fournit. Un système d’IA agentique agit sur ces données — il récupère des dossiers, met à jour des systèmes, déclenche des workflows et interagit avec des services externes. Chaque agent crée une identité non humaine qui exige authentification, autorisation et surveillance à un niveau que la plupart des systèmes de gestion d’identité du secteur n’ont pas prévu.
Les enjeux de gouvernance sont majeurs. Chaque système d’IA agentique doit être recensé. Son accès aux données doit être consigné dans les journaux d’audit. Ses autorisations doivent respecter le principe du moindre privilège avec vérification continue — pas d’accès permanent après une seule authentification. Toutes ses actions doivent être auditées. Et une responsabilité claire doit être attribuée afin que, si un agent accède à des données non autorisées ou agit hors de son périmètre, il y ait un responsable identifié et une procédure d’escalade.
Kiteworks fournit l’infrastructure opérationnelle pour gouverner l’IA agentique au niveau des données. Grâce à son Secure MCP Server, Kiteworks permet à l’IA agentique d’accéder aux données de l’entreprise via l’authentification OAuth 2.0 et des contrôles d’accès basés sur les rôles, garantissant que chaque agent hérite des autorisations de son utilisateur humain autorisant — sans pouvoir les dépasser. Le binding de finalité limite chaque agent aux classifications de données et fonctions pour lesquelles il a été autorisé. La vérification continue évalue chaque demande de données selon les règles en vigueur. Et des journaux d’audit détaillent chaque action de l’agent, fournissant la preuve dont les comités de gouvernance ont besoin pour faire appliquer leurs propres politiques.
Parmi les organisations qui estiment que l’adoption de l’IA dépasse leur niveau de préparation, plus de la moitié identifient le besoin de procédures de gouvernance formelles comme leur priorité. Le message est clair.
Santé rurale : mêmes risques, réalité différente
Brian Sterud, VP and CIO chez Faith Regional Health Services, décrit le défi des établissements ruraux avec une franchise caractéristique : ils affrontent les mêmes cybermenaces et la même pression à adopter l’IA que les plus grands groupes, mais sans les mêmes budgets ni la même profondeur d’effectif.
Les données de référence le confirment. Les systèmes de santé ruraux sont au même niveau que leurs homologues sur les fondamentaux du NIST Cybersecurity Framework — les bases de la cybersécurité. Mais ils sont deux fois plus susceptibles de n’avoir aucune gouvernance de l’IA. Pas une gouvernance plus faible. Aucune gouvernance.
Ce déficit ne s’explique pas par un manque de sensibilisation ou de volonté. Il s’explique par le manque de ressources. Les établissements ruraux manquent généralement de personnel dédié à la gouvernance de l’IA, d’analystes de la menace et du budget pour déployer des plateformes de gouvernance de niveau entreprise. Ils ont besoin de solutions qui offrent les mêmes journaux d’audit, l’application des règles et les capacités de conformité que les grands groupes — sans exiger le même effectif ou investissement en infrastructure.
Kiteworks propose l’application automatisée des règles, des modèles de conformité préconfigurés alignés sur les cadres HIPAA et NIST, et des fonctions d’audit prêtes à l’emploi qui allègent la charge de gouvernance des petites équipes IT. Les établissements ruraux bénéficient ainsi de la même gouvernance des données que les plus grands groupes — sans devoir tout construire ni recruter du personnel dédié.
Personne ne porte le risque IA. Tout le monde croit que c’est à un autre de le faire.
38 % des organisations de santé partagent la responsabilité du risque IA entre plusieurs équipes sans chemin d’escalade clair, ou n’ont pas défini de responsable du tout. C’est une vulnérabilité structurelle qui va s’aggraver à mesure que les déploiements d’IA se multiplient.
Une responsabilité fragmentée du risque crée un scénario d’échec typique : lorsqu’un incident lié à l’IA survient — fuite de données, violation de conformité, accès non autorisé — il n’y a pas de chemin clair entre détection et réponse. Le RSSI pense que c’est à l’équipe conformité de gérer. L’équipe conformité pense que c’est au comité de gouvernance de l’IA. Le comité de gouvernance pense que c’est à l’équipe informatique clinique. Pendant ce temps, l’incident s’aggrave.
Pour résoudre cela, il faut une visibilité unifiée. Quand le RSSI, le responsable conformité, le DPO et le comité de gouvernance de l’IA accèdent tous au même journal d’audit — la même trace de ce qui s’est passé, quand et sur quel système — les conflits de responsabilité diminuent car les faits sont partagés. Kiteworks offre cette visibilité unifiée via son journal d’activité consolidé et son tableau de bord RSSI, donnant à chaque partie prenante un accès en temps réel aux données d’audit. Les alertes automatisées avec règles d’escalade garantissent que les incidents parviennent immédiatement aux bonnes personnes, quelle que soit la structure de l’organisation.
Janet Guptill, Présidente et CEO du Scottsdale Institute, résume l’évolution globale : la cybersécurité et la gouvernance de l’IA ne sont plus de simples défis techniques. Ce sont des enjeux stratégiques qui exigent l’implication de la direction générale à l’échelle de l’entreprise. Du RSSI au CEO en passant par les membres du conseil, la responsabilité du risque IA doit être explicite, documentée et appliquée opérationnellement.
De la structure à l’action : ce que doivent faire les organisations de santé dès maintenant
Constituez un inventaire centralisé de l’IA et tenez-le à jour. Chaque système d’IA qui accède à des données de l’organisation — qu’il soit déployé en interne, intégré dans des produits fournisseurs ou accessible via des API tierces — doit être identifié, catalogué et surveillé. Les journaux d’audit constituent la base de cet inventaire en enregistrant chaque interaction avec les données sur tous les canaux, ce qui permet d’identifier l’arrivée de nouveaux systèmes ou fonctions d’IA, même s’ils n’ont pas été déclarés officiellement.
Mettez en place une surveillance continue de l’IA intégrée par les fournisseurs. Allez au-delà des évaluations ponctuelles. Kiteworks surveille en continu les schémas d’accès aux données des fournisseurs via la messagerie électronique, le partage de fichiers, les API, SFTP et le transfert sécurisé de fichiers. Dès qu’un comportement fournisseur change — révélant de nouvelles fonctions d’IA — Kiteworks signale l’écart et documente la preuve. Mettez à jour les accords de partenariat pour exiger la déclaration des changements de fonctions IA par les fournisseurs, et utilisez les journaux d’audit pour vérifier la conformité.
Attribuez clairement la responsabilité du risque IA avec des chemins d’escalade documentés. Désignez explicitement un responsable du risque IA au niveau exécutif. L’infrastructure d’audit unifiée de Kiteworks garantit que le RSSI, le responsable conformité, le DPO et le comité de gouvernance de l’IA partagent l’accès aux mêmes données. Les alertes automatisées avec règles d’escalade assurent que les incidents parviennent immédiatement aux bonnes personnes. Définissez des procédures d’escalade précisant qui intervient lors d’un incident lié à l’IA, dans quelles conditions et avec quelle autorité.
Appliquez les principes du zéro trust à toutes les charges de travail IA. Chaque système et agent d’IA doit fonctionner selon le principe du moindre privilège avec vérification continue. Kiteworks applique cela via des contrôles d’accès basés sur les attributs, évaluant la classification des données, l’identité de l’agent et la finalité de chaque demande. Le binding de finalité limite l’accès de l’IA à certaines catégories de données et fonctions. La vérification continue évalue chaque demande de données selon les règles en vigueur — pas d’accès permanent après une authentification unique.
Investissez dans la prévention, pas seulement dans la réaction. Rééquilibrez les budgets cybersécurité vers les contrôles fondamentaux identifiés comme en retard : maturité de la gouvernance, gestion des actifs, classification des données et supervision de la supply chain. Kiteworks fournit l’infrastructure préventive — application automatisée des règles, classification des données, contrôles d’accès et surveillance des fournisseurs — qui empêche les violations au lieu de simplement les documenter après coup.
Adaptez la gouvernance aux environnements à ressources limitées. Les établissements ruraux et de petite taille ont besoin de solutions de gouvernance offrant des journaux d’audit, l’application automatisée des règles et le reporting de conformité de niveau entreprise sans personnel dédié à la gouvernance de l’IA. Kiteworks propose cette évolutivité : modèles de conformité préconfigurés, application automatisée, fonctions d’audit prêtes à l’emploi qui allègent la charge des équipes IT à ressources limitées.
Le fossé de la gouvernance ne se comblera pas tout seul
L’étude de référence 2026 sur la cybersécurité dans la santé délivre un message inconfortable mais nécessaire : le secteur de la santé a fait le plus simple en matière de gouvernance de l’IA. Les comités existent. Les chartes sont rédigées. Les discussions ont lieu.
Le plus difficile — bâtir l’infrastructure opérationnelle qui transforme ces comités en véritables organes de gouvernance — est là où la plupart des organisations échouent. Inventaire de l’IA. Surveillance continue. Journaux d’audit. Détection des fournisseurs. Responsabilité claire. Ce ne sont pas des objectifs à long terme. Ce sont des exigences opérationnelles dans un secteur où l’IA traite déjà des informations médicales protégées, où des systèmes d’IA agentique agissent déjà de façon autonome, et où les adversaires utilisent déjà l’IA pour attaquer les infrastructures critiques de la santé.
Kiteworks fournit la base de gouvernance des données qui rend la gouvernance de l’IA opérationnelle. Journaux d’audit qui prouvent l’application des contrôles. Surveillance continue qui détecte l’IA intégrée par les fournisseurs avant qu’elle ne devienne une violation de conformité. Contrôles d’accès selon le principe du moindre privilège qui empêchent les systèmes d’IA d’accéder à des données au-delà de leur finalité autorisée. Et une infrastructure automatisée et évolutive qui rend la gouvernance de niveau entreprise accessible à toutes les organisations, quelle que soit leur taille.
Les organisations qui combleront ce fossé seront celles qui auront dépassé la structure pour passer à l’action. Celles qui auront bâti la force opérationnelle à la hauteur de leur structure de gouvernance. Celles qui auront considéré la gouvernance de l’IA non comme un exercice de conformité, mais comme un impératif de sécurité des patients — et déployé l’infrastructure opérationnelle pour le garantir.
Pour découvrir comment Kiteworks peut vous accompagner, réservez votre démo personnalisée dès aujourd’hui.
Foire aux questions
L’inventaire de l’IA d’une organisation de santé doit aller bien au-delà d’une simple liste d’outils validés. Pour chaque système d’IA, il faut documenter : quelles informations médicales protégées le système peut consulter, y compris les données d’entraînement et les entrées d’inférence ; qui a autorisé cet accès et dans quelles conditions il peut être révoqué ; quel fournisseur ou partenaire exploite le système et quelles sont ses obligations contractuelles ; la classification des données produites par le système ; et si le système fonctionne de façon autonome ou avec supervision humaine. Constituer cet inventaire nécessite une surveillance continue, et non une enquête ponctuelle — car les produits fournisseurs évoluent, des fonctions d’IA sont intégrées sans annonce, et de nouveaux déploiements échappent souvent aux processus d’approbation formels. Les journaux d’audit qui consignent chaque interaction de l’IA avec les données de santé constituent la mémoire vivante qui tient l’inventaire à jour, permettant d’identifier l’arrivée de nouveaux systèmes ou fonctions d’IA même non déclarés. L’inventaire est aussi un prérequis pour la conformité à la HIPAA Security Rule, qui impose une revue documentée de l’activité des systèmes d’information pour tous les systèmes traitant des informations médicales protégées électroniques.
Selon l’HIPAA, tout fournisseur qui crée, reçoit, conserve ou transmet des informations médicales protégées pour le compte d’une entité couverte est un partenaire commercial et doit opérer dans le cadre d’un accord précisant les usages et divulgations autorisés de ces données. Lorsque l’IA est intégrée dans un produit existant, deux problèmes se posent. D’abord, l’accord initial a été négocié avant l’apparition de la fonction IA et ne traite probablement pas la façon dont l’IA traite les informations médicales protégées, si ces données servent à entraîner ou améliorer le modèle, ou comment les résultats de l’IA sont protégés. Ensuite, si la fonction IA a été ajoutée via une mise à jour — et non un nouvel achat — le processus d’approbation et de revue de l’accord n’a peut-être pas été déclenché. Cela crée une exposition non documentée : les données circulent vers un système d’IA selon des conditions qui ne régissent pas ce traitement. Les entités couvertes doivent exiger des fournisseurs qu’ils déclarent toute évolution de leurs fonctions IA, revoir les accords pour s’assurer que le traitement par l’IA est explicitement couvert, et mettre en place une surveillance continue pour détecter tout changement dans les schémas d’accès aux données indiquant une nouvelle activité IA. Les journaux d’audit qui documentent l’accès des fournisseurs aux données sur chaque canal — SFTP, API, transfert sécurisé de fichiers, messagerie électronique — fournissent la preuve nécessaire pour identifier les traitements non déclarés et prouver la conformité en cas de contrôle.
La gestion classique des identités et des accès est conçue pour les utilisateurs humains : authentifier une personne à la connexion, attribuer des droits selon son rôle, et consigner ses sessions. L’IA agentique bouleverse ce modèle sur trois points. D’abord, les agents créent des identités non humaines qui peuvent s’authentifier des milliers de fois par heure, rendant la revue des sessions inopérante. Ensuite, les agents agissent sur les données plutôt que de simplement les lire — ils récupèrent des dossiers, mettent à jour des systèmes, déclenchent des workflows, appellent des API externes — donc l’impact d’un accès trop large est bien plus important que pour un utilisateur humain surveillé individuellement. Enfin, les agents opèrent souvent avec les droits d’un compte de service, qui détient généralement plus d’autorisations qu’un utilisateur humain. Les organisations de santé doivent ajouter quatre fonctions à leur IAM : le binding de finalité qui limite chaque agent à certaines catégories de données et fonctions, quelle que soit la portée technique de ses identifiants ; la vérification continue qui réévalue chaque demande de données selon la politique en vigueur, sans se contenter d’une authentification de session ; un kill switch pour révoquer immédiatement l’accès d’un agent en cas de comportement anormal ; et des journaux d’audit qui consignent chaque action de l’agent au niveau des données — pas seulement les événements d’authentification — reliés à l’utilisateur humain autorisant. Un contrôle d’accès basé sur les attributs, qui évalue l’identité de l’agent, la classification des données et la finalité, apporte la couche de gouvernance qui manque aux systèmes basés sur les rôles seuls.
En environnement clinique, le zéro trust pour l’IA consiste à considérer chaque demande de données — de tout système d’IA, quel que soit son contexte de déploiement — comme non fiable tant qu’elle n’est pas évaluée selon la politique en vigueur. C’est un changement radical par rapport à la pratique actuelle, où l’approbation lors de l’achat vaut autorisation permanente. Concrètement, le zéro trust pour l’IA repose sur quatre piliers. Accès aux données par défaut selon le moindre privilège : les systèmes d’IA ne peuvent accéder qu’aux classifications d’informations médicales protégées nécessaires à leur fonction clinique définie — un outil d’aide à la décision clinique accède aux données de diagnostic, pas aux dossiers de facturation. Vérification continue : chaque requête est vérifiée par rapport à la finalité autorisée de l’IA et à la classification de sensibilité des données, pas seulement à la connexion. Contrôles de prévention des pertes de données : application automatisée qui bloque l’export, la transmission ou le traitement hors périmètre. Et détection des anomalies comportementales : surveillance de référence qui signale tout écart dans les schémas d’accès aux données d’un système d’IA — volume de requêtes inhabituel, accès à de nouveaux types de dossiers, activité hors horaires — déclenchant une alerte automatique et, si nécessaire, la suspension de l’accès. Dans un secteur où les attaques par ransomware ciblent de plus en plus les systèmes d’IA clinique comme points d’entrée vers l’infrastructure, le zéro trust au niveau des données limite l’impact quand les défenses périmétriques échouent.
La responsabilité réglementaire de la gouvernance IA dans la santé converge de plusieurs directions. La Security Rule de l’HIPAA impose aux entités couvertes de mettre en place des politiques et procédures pour la revue de l’activité des systèmes d’information — une obligation qui s’étend aux systèmes d’IA traitant des informations médicales protégées électroniques et exige la preuve documentée que ces revues ont lieu, et pas seulement l’existence de politiques. Le NIST AI Risk Management Framework recommande que la gouvernance de l’IA implique la direction générale, avec des rôles définis, des chemins d’escalade et un reporting au niveau du conseil. Les Health Industry Cybersecurity Practices 405(d) du HHS, qui servent de base au cadre de l’étude, identifient la gouvernance et la gestion des risques comme des pratiques fondamentales avec des exigences de responsabilité explicites. Le constat de l’étude Censinet selon lequel 38 % des organisations ont une responsabilité fragmentée ou non définie du risque IA est en contradiction directe avec ces exigences : un régulateur qui examine une violation impliquant un système d’IA s’attendra à voir qui portait le risque, quel contrôle existait, quels journaux d’audit ont été tenus et quelles procédures d’escalade ont été suivies. La responsabilité au niveau du conseil exige des rapports de conformité exportables qui prouvent la gouvernance opérationnelle — pas seulement des documents de gouvernance — et une infrastructure de gouvernance des données unifiée donnant à chaque dirigeant accès à la même base de preuves en cas de contrôle.
Ressources complémentaires
- Article de blog Architecture Zero Trust : ne jamais faire confiance, toujours vérifier
- Vidéo Microsoft GCC High : Les inconvénients qui poussent les sous-traitants de la défense à chercher de meilleures solutions
- Article de blog Comment sécuriser les données classifiées une fois signalées par le DSPM
- Article de blog Instaurer la confiance dans l’IA générative grâce à une approche Zero Trust
- Vidéo Guide ultime pour le stockage sécurisé des données sensibles à destination des responsables IT