Conformité HIPAA et IA : ce qu’un BAA ne couvre pas

L’essentiel

• Le BAA, ce contrat de sous-traitance propre à HIPAA, répartit la responsabilité sur la donnée. Il ne dit rien de la justesse, de l’équité ou de la sécurité clinique du modèle, là où se concentre pourtant l’essentiel du risque.
• HIPAA a renoncé à encadrer l’IA. La réforme de la Security Rule proposée en janvier 2025 se contente d’un appel à commentaires sur l’intelligence artificielle et n’introduit aucune garantie spécifique.
• La règle qui encadre réellement l’IA clinique aux États-Unis s’appelle Section 1557. Ses obligations sur les outils d’aide à la décision de soins sont exigibles depuis le 1er mai 2025.
• HTI-1 impose aux logiciels de santé certifiés d’exposer 31 attributs de source pour l’aide à la décision prédictive. C’est aussi une grille d’audit fournisseur prête à l’emploi.
• Une démarche de conformité HIPAA appliquée à l’IA tient debout quand un socle unique de contrôles répond à la fois à HIPAA, à la Section 1557, à HTI-1, à la FDA et, pour les acteurs transatlantiques, à l’AI Act européen.

Ce que HIPAA couvre réellement quand l’IA touche aux données de santé

La quasi-totalité des contenus consacrés à la conformité HIPAA et à l’IA commence au même endroit : choisir un fournisseur qui signe un BAA, vérifier le chiffrement, s’assurer que l’outil n’entraîne pas ses modèles sur vos requêtes. Le conseil est juste. Il ne couvre que la plus petite partie du problème. HIPAA se compose de deux blocs opérationnels. La Privacy Rule encadre les usages et les divulgations des informations de santé protégées, les fameuses PHI. La Security Rule impose des garanties administratives, physiques et techniques sur leur version électronique. Un fournisseur d’IA qui reçoit, stocke ou traite des PHI pour le compte d’une entité couverte devient un business associate, et les deux règles l’atteignent par le contrat. Ce que HIPAA ne fait pas, c’est encadrer le modèle. Le texte ne dit rien de la provenance des données d’entraînement, de la performance par sous-population, de la dérive de calibration ni de la pertinence clinique d’une recommandation. Ces questions relèvent d’autres régimes, et ce sont précisément elles qui déterminent si un déploiement d’IA nuit à un patient. Deux zones frontières méritent plus d’attention qu’elles n’en reçoivent. La première est l’anonymisation. Les données traitées par la méthode Safe Harbor ou certifiées par Expert Determination sortent du périmètre HIPAA, ce qui explique le nombre de projets d’IA en santé bâtis sur des corpus anonymisés. Les grands modèles fragilisent ce confort : la mémorisation et le croisement d’informations dans du texte clinique riche peuvent ramener un jeu de données vers l’identifiabilité, dans des conditions que la certification initiale n’avait pas envisagées. Si votre attestation d’anonymisation est antérieure au modèle, elle ne couvre pas le modèle. La seconde zone frontière, c’est le périmètre lui-même. HIPAA s’applique selon l’identité de celui qui détient la donnée, pas selon sa sensibilité. Un vérificateur de symptômes grand public, une application de bien-être ou un agent conversationnel destiné directement au patient, dès lors qu’ils ne contractent avec aucune entité couverte, échappent en général totalement à HIPAA et relèvent du FTC Act et de la Health Breach Notification Rule. La donnée de santé ne transporte pas HIPAA avec elle. C’est la relation contractuelle qui le fait. Cette distinction recoupe celle qui structure toutes vos autres analyses d’impact, et elle se lit utilement en parallèle des différences entre analyse d’impact sur la vie privée, AIPD et FRIA, car un programme d’IA en santé en mobilise rarement une seule.

Le BAA est nécessaire, il n’est pas suffisant

Un BAA remplit trois fonctions utiles. Il soumet le fournisseur à la Privacy Rule et à la Security Rule, il délimite les usages autorisés des PHI et il l’oblige à notifier les violations de données. S’en passer est indéfendable. Lorsqu’un prestataire mésuse de PHI sans contrat signé, l’Office for Civil Rights traite l’absence de BAA comme un manquement autonome, qui s’ajoute au reste. L’historique des sanctions confirme qu’il faut le prendre au sérieux. Le 23 avril 2026, l’OCR a annoncé des transactions avec quatre organisations à la suite de violations liées à des rançongiciels, pour un total de 1 165 000 dollars et plus de 427 000 personnes concernées, chacune assortie d’un plan d’action correctif de deux ans sous surveillance. La supervision des prestataires pèse dans une part croissante de ces pénalités, et l’implication d’un tiers dans les violations de données de santé est passée de 15 % à 30 % d’une année sur l’autre en 2025. Signez donc le contrat. Puis observez ce qu’il ne vous a pas acheté. Un BAA signé ne vous dit pas quelle version du modèle tourne en production. Il ne consigne pas les données d’entraînement, ni la ressemblance entre la population d’entraînement et votre file active. Il ne mesure pas la performance selon l’âge, le sexe, la langue ou le régime de couverture. Il ne détecte pas qu’un éditeur a remplacé son modèle de fondation lors d’une mise à jour trimestrielle. Il ne produit aucun élément que vous pourriez présenter à un auditeur demandant pourquoi tel patient a reçu telle recommandation. Ces angles morts relèvent de la gouvernance, pas des achats. Ils appartiennent au même ensemble que le reste de votre dispositif de conformité et de gouvernance : un inventaire, un responsable identifié, une cotation du risque, un résultat de test, une fréquence de surveillance et une trace de décision. Le contrat répartit la faute une fois l’incident survenu. La gouvernance rend l’incident moins probable et démontrable dans les deux sens.

Là où HIPAA s’arrête : la réforme de 2025 a esquivé l’IA

Qui attend de HIPAA la réponse à la question de l’IA devrait lire ce qui s’est passé lors de la dernière procédure réglementaire. Le 27 décembre 2024, le Department of Health and Human Services a annoncé un projet de modernisation de la Security Rule, publié au Federal Register le 6 janvier 2025. Il s’agit de la première refonte substantielle de ce texte depuis une vingtaine d’années. Le projet est ambitieux sur les fondamentaux de cybersécurité : inventaire des actifs, cartographie réseau, authentification multifacteur obligatoire, exigences de chiffrement, et suppression d’une bonne partie de la souplesse qui permettait de traiter les garanties comme facultatives. Sur l’intelligence artificielle, il ne fait presque rien. L’IA n’apparaît que dans un appel à commentaires, aux côtés de l’informatique quantique et de la réalité virtuelle et augmentée, invitant le public à dire comment la Security Rule devrait traiter les PHI électroniques utilisées par les technologies émergentes. L’OCR avait l’occasion de poser des règles pour l’IA et l’apprentissage automatique ; il a préféré recueillir des avis. La consultation s’est close le 7 mars 2025 avec près de 5 000 contributions, et le texte définitif se fait toujours attendre. La lecture opérationnelle est simple. Quand la règle finale paraîtra, elle relèvera votre socle de sécurité, ce qui est utile. Elle ne vous dira ni comment valider un modèle, ni comment tester des écarts de performance, ni quelles preuves conserver au sujet d’une recommandation algorithmique. Réduire l’obligation en matière d’IA au seul HIPAA revient à demander à un texte conçu pour des dossiers de répondre sur de l’inférence. Le tableau complet s’étale sur plusieurs régimes à la fois, raison pour laquelle la cartographie mondiale des lois sur l’IA intéresse même un établissement strictement américain.

Section 1557 : la règle qui encadre vraiment votre IA clinique

Voici la règle que presque aucun guide de conformité HIPAA appliquée à l’IA ne mentionne, et elle est déjà en vigueur. La Section 1557 de l’Affordable Care Act interdit les discriminations fondées sur la race, la couleur, l’origine nationale, le sexe, l’âge et le handicap dans les programmes et activités de santé bénéficiant d’un financement fédéral. Le HHS a publié une règle définitive le 6 mai 2024, entrée en vigueur le 5 juillet 2024, qui étend explicitement ces principes à ce qu’elle nomme les outils d’aide à la décision de soins. La définition est volontairement large. Elle vise les outils, mécanismes, méthodes et technologies, automatisés ou non, mobilisés pour appuyer une décision clinique, ce qui englobe aussi bien les algorithmes cliniques, les scores de risque, les logiques de triage que les modèles d’apprentissage automatique. Les entités couvertes ont disposé de 300 jours à compter de l’entrée en vigueur pour se conformer aux dispositions sur l’aide à la décision, soit une échéance au 1er mai 2025. L’obligation comporte deux volets. D’abord, faire des efforts raisonnables pour recenser les outils d’aide à la décision utilisés qui emploient la race, la couleur, l’origine nationale, le sexe, l’âge ou le handicap comme variable d’entrée. Ensuite, faire des efforts raisonnables pour atténuer le risque de discrimination qui en découle. Les deux volets sont continus. Il ne s’agit pas d’une attestation que l’on signe une fois pour la classer. Confrontez ces deux verbes au conseil d’achat qui domine les résultats de recherche. Aucun chiffrement ne recense une variable d’entrée. Aucun BAA n’atténue un écart de performance. La règle atteint le modèle, et le devoir pèse sur l’entité couverte, pas sur le fournisseur.

À quoi ressemblent des efforts raisonnables, en preuves

Les autorités ne se satisfont pas des intentions. Elles se satisfont des traces. Pour chaque outil d’aide à la décision clinique, un dossier défendable contient une fiche d’inventaire nommant l’outil, sa version et sa finalité clinique ; une revue documentée des variables d’entrée signalant toute caractéristique protégée ou son proxy immédiat, code postal, langue de préférence ou statut assurantiel ; des résultats de performance ventilés selon les sous-groupes que la règle énumère ; une décision d’atténuation écrite et motivée, y compris lorsqu’elle consiste à accepter un risque résiduel ; une fréquence de surveillance assortie de seuils ; et un responsable nommément désigné. Cet ensemble de preuves couvre aussi l’essentiel de ce que demandera un auditeur IA, et il se complète naturellement d’une position claire sur la place du clinicien dans la boucle. Pour un outil consultatif, la différence entre supervision humaine dans la boucle et sur la boucle détermine exactement si une mesure d’atténuation est réelle ou nominale.

HTI-1 et la couche de transparence logée dans le dossier patient

Pendant que l’OCR renonçait à encadrer les modèles, le programme de certification des logiciels de santé s’en chargeait. La règle définitive HTI-1, publiée par l’Assistant Secretary for Technology Policy, ex-ONC, a créé un critère de certification consacré aux Decision Support Interventions. Il porte les premières exigences de transparence de ce type sur les algorithmes prédictifs intégrés à un logiciel de santé certifié. Ces systèmes doivent exposer au clinicien des attributs de source structurés : 13 pour l’aide à la décision fondée sur les preuves, 31 pour l’aide à la décision prédictive. Ces 31 attributs constituent la partie intéressante. Ils décrivent la finalité et l’usage prévu de l’intervention, le processus de développement, les données ayant servi à entraîner et valider le modèle sous-jacent, les modalités de mesure de la performance, la manière dont l’équité a été évaluée et la façon dont l’intervention est maintenue dans le temps. L’objectif affiché consiste à permettre à une organisation de juger si une intervention prédictive est équitable, appropriée, valide, efficace et sûre, un test que le programme résume par l’acronyme FAVES. Deux conséquences en découlent pour toute démarche de conformité HIPAA appliquée à l’IA. D’abord, si votre outil prédictif est embarqué dans un logiciel de santé certifié, cette documentation existe déjà et vous y avez droit. Beaucoup d’équipes conformité ne l’ont jamais réclamée. Ensuite, et c’est plus utile encore, ces 31 attributs forment un questionnaire fournisseur immédiatement réutilisable pour les IA qui ne sont certifiées par personne. Un éditeur incapable de décrire sa population d’entraînement, sa méthode de validation ou son évaluation d’équité vous dit quelque chose, et l’administration fédérale a déjà tranché : ces questions ont des réponses. Servez-vous-en au moment d’arbitrer entre une capacité d’IA intégrée à votre plateforme gouvernée et la nébuleuse d’outils qui gravite autour.

La FDA, ou la frontière entre une fonctionnalité et un dispositif

Une partie de l’IA clinique constitue un dispositif médical réglementé, et la frontière est plus mince que ne le supposent la plupart des acheteurs. La FDA avait autorisé plus de 1 350 dispositifs dotés d’IA début 2026, soit environ le double du décompte de 2022. Un logiciel qui analyse une image, calcule un score de risque pour une pathologie identifiée ou conduit à une conclusion diagnostique entre fréquemment dans la catégorie. Un logiciel qui résume une note, rédige un courrier ou oriente un message, en général non. La question discriminante porte sur la finalité déclarée, diagnostiquer, traiter, atténuer ou prévenir une maladie, et sur la capacité du clinicien à examiner de façon indépendante le fondement de la recommandation. L’apprentissage automatique met la réglementation des dispositifs sous tension sur un point précis : un dispositif autorisé est censé rester conforme à son autorisation, alors qu’un modèle a vocation à évoluer. La réponse de la FDA porte un nom, le Predetermined Change Control Plan, qui permet au fabricant de faire pré-autoriser un périmètre défini de modifications futures du modèle, à l’intérieur de l’usage prévu. L’adoption reste modeste : environ 10 % des autorisations d’IA de 2025 comportaient un tel plan. Pour un déployeur, cela se traduit par un contrôle concret. Demandez à chaque fournisseur d’IA clinique si le modèle relève d’un plan de gestion des changements, comment vous serez informé d’une mise à jour du modèle, et ce que deviennent vos preuves de validation quand le modèle change sous vos pieds. Un réentraînement silencieux peut faire sortir un produit de son usage autorisé et de votre propre campagne de tests au même instant. C’est un problème de mesure et de surveillance, qui correspond directement aux fonctions Measure et Manage du cadre de gestion des risques NIST AI RMF.

Si vous opérez aussi en Europe : la couche AI Act

Beaucoup d’organisations qui manipulent des PHI américaines ne sont pas américaines. Éditeurs de santé numérique européens, sociétés de recherche sous contrat, fabricants de dispositifs et groupes hospitaliers engagés dans des partenariats de recherche outre-Atlantique portent des obligations HIPAA par contrat et des obligations européennes par la loi. Pour eux, la conformité HIPAA ne constitue que le premier étage. Une IA qui est un dispositif médical, ou qui en constitue un composant de sécurité, relève automatiquement du haut risque au sens de l’AI Act. En pratique, les dispositifs de classe IIa, IIb et III au titre du MDR et de classe A à D au titre de l’IVDR basculent normalement dans la catégorie à haut risque. Les dispositifs de classe I du MDR, dispensés d’examen par un organisme notifié, n’y entrent pas par cette voie, mais peuvent y être ramenés s’ils remplissent une fonction listée à l’annexe III. L’annexe III ajoute d’ailleurs deux usages proches du soin, à haut risque sans être des dispositifs : la régulation des appels d’urgence et le triage des patients aux urgences, ainsi que l’évaluation des risques et la tarification en assurance vie et santé. Les organismes payeurs et les plateformes de triage supposent souvent que l’AI Act est une affaire de dispositifs. Il ne l’est pas. Le calendrier a changé en 2026. Depuis le Digital Omnibus adopté en juin 2026, les obligations applicables aux systèmes à haut risque autonomes de l’annexe III s’appliquent à compter du 2 décembre 2027, tandis que l’IA logée dans un dispositif régi par le MDR ou l’IVDR bénéficie d’un délai jusqu’au 2 août 2028. En mars 2026, les dispositifs médicaux dotés d’IA continuaient d’être certifiés exclusivement au titre du MDR et de l’IVDR, les obligations haut risque de l’AI Act ne leur étant pas encore applicables. Ce décalage est un temps de préparation, pas une dispense. Les organisations françaises disposent d’une avance utile. Le guide conjoint publié par la Haute Autorité de Santé et la CNIL en mars 2026 traite dans un même document de la qualification en dispositif médical, des exigences de l’AI Act pour les systèmes de santé à haut risque, de la protection des données patients et de la validation clinique. Il est librement accessible sur le site de la CNIL. Les équivalents allemand, italien, espagnol et portugais sont plus maigres, ce qui fait des obligations de l’AI Act pour les opérateurs la référence la plus sûre.

Bâtir la conformité HIPAA de l’IA sur un socle unique de contrôles

Quatre régimes, quatre vocabulaires, une seule série de questions de fond. Qu’est-ce que ce système, qui en répond, que peut-il rater, comment le sauriez-vous, et pouvez-vous le prouver. Faire tourner quatre programmes de conformité en parallèle, c’est la méthode qui consomme une année entière et échoue quand même à l’audit. Commencez par un inventaire. Tout système d’IA qui touche un patient ou une donnée de santé protégée reçoit une fiche, y compris ceux que personne n’a déclarés. Les assistants de transcription achetés par un seul service, les fonctions de résumé activées dans une plateforme déjà en place et les cliniciens qui collent des notes dans un agent conversationnel grand public entrent tous dans le périmètre, et les trois cas sont fréquents. La question du shadow AI se pose avec plus d’acuité en santé qu’ailleurs, parce que le bénéfice clinique est immédiat quand le circuit d’achat, lui, est lent. Classez ensuite chaque système à l’aide de quatre questions binaires. Traite-t-il des données de santé protégées ? Influence-t-il une décision de soins ? Réside-t-il dans un logiciel de santé certifié ? Est-il, ou contient-il, un dispositif réglementé ? Les réponses déterminent les obligations qui s’attachent.

Adossez le tout à un système de management plutôt qu’à un tableur. ISO/IEC 42001 fournit la structure certifiable : politique, rôles, traitement du risque, audit interne, revue de direction. Le NIST AI RMF fournit la boucle de travail, Govern, Map, Measure, Manage. Aucun des deux n’est une réglementation sanitaire américaine, et c’est précisément ce qui en fait la couche de liaison : ils permettent de produire une preuve une seule fois et de l’opposer à plusieurs obligations. C’est l’argument qui sous-tend tout cadre de gouvernance de l’IA sérieux, appliqué à un secteur où les conséquences arrivent plus vite qu’ailleurs.

Questions fréquentes

Peut-on utiliser l’IA tout en respectant HIPAA ? Oui. HIPAA n’interdit pas l’intelligence artificielle, et rien dans la Privacy Rule ou la Security Rule n’empêche une entité couverte de traiter des données de santé protégées avec un modèle. Ce que HIPAA exige, c’est que le fournisseur entre dans le dispositif comme business associate au moyen d’un contrat écrit, que les garanties s’appliquent aux PHI électroniques concernées et que l’usage soit autorisé par la Privacy Rule. Une revue de conformité HIPAA appliquée à l’IA devrait donc partir de la finalité clinique plutôt que du fournisseur, car la vraie difficulté consiste à satisfaire les autres règles applicables, la Section 1557 au premier chef. ChatGPT est-il conforme à HIPAA pour un usage en santé ? La version grand public ne l’est pas. Un modèle n’est jamais conforme en soi ; c’est un déploiement qui l’est. La conformité dépend de la volonté de l’éditeur de signer un BAA, de l’exclusion des requêtes et des réponses de l’entraînement, de la politique de conservation, et de la capacité de la configuration à gérer le contrôle d’accès et la journalisation. Les offres entreprise et les API des grands fournisseurs peuvent soutenir un déploiement conforme. Les interfaces grand public gratuites, en général non, ce qui explique que le collage de notes cliniques dans un agent public figure aujourd’hui parmi les violations les plus courantes du secteur. Un BAA signé rend-il un outil d’IA conforme à HIPAA ? Non. Un BAA est une répartition contractuelle d’obligations portant sur la donnée. Il n’évalue pas le modèle, ne vérifie pas l’exactitude selon les sous-populations de patients et ne crée aucune trace expliquant pourquoi telle recommandation a été formulée. Les autorités n’ont jamais traité un contrat signé comme la preuve que les garanties étaient effectivement mises en oeuvre, et les obligations de la Section 1557 pèsent sur l’entité couverte indépendamment de ce que le fournisseur a accepté. Quelle était l’échéance de la Section 1557 pour les outils d’aide à la décision ? La règle définitive a été publiée le 6 mai 2024 et est entrée en vigueur le 5 juillet 2024. Les entités couvertes disposaient de 300 jours à compter de cette entrée en vigueur pour se conformer aux dispositions relatives aux outils d’aide à la décision de soins, soit une échéance fixée au 1er mai 2025. Ces obligations sont désormais actives et continues : une organisation qui n’a jamais recensé ses algorithmes cliniques à la recherche de variables protégées accuse déjà du retard. HIPAA s’applique-t-il si mon IA n’utilise que des données anonymisées ? Des données correctement anonymisées sortent du champ de HIPAA, que ce soit par la méthode Safe Harbor ou par Expert Determination. La prudence s’impose parce que l’anonymisation est une propriété d’un jeu de données à un instant donné, non un statut définitif. Du texte clinique riche, une combinaison de quasi-identifiants et la mémorisation par un modèle peuvent tous faire remonter le risque de réidentification. Si la certification est antérieure à l’entrée des données dans une chaîne de traitement par modèle, faites-la réexaminer au regard de cette chaîne plutôt que de la supposer transposable. Qui est responsable quand un fournisseur d’IA provoque une fuite de données de santé ? Les deux parties peuvent l’être. Les business associates répondent directement de leurs propres manquements au titre de HIPAA, et les entités couvertes demeurent comptables du choix et de la supervision de leurs prestataires. En l’absence de contrat, l’entité couverte s’expose à un constat distinct pour ce seul manquement. Au-delà de HIPAA, la responsabilité d’une recommandation clinique dommageable relève du droit de la responsabilité médicale et de celle du fait des produits, où l’établissement de soins est rarement absent de la procédure. Votre processus de signalement d’incident doit donc partir du principe d’une exposition partagée. Une organisation de santé européenne qui sert des patients américains doit-elle respecter à la fois HIPAA et l’AI Act ? Le plus souvent oui, et devant des autorités distinctes. HIPAA atteint un acteur européen par le BAA qui le lie à une entité couverte américaine. L’AI Act, le RGPD et le MDR ou l’IVDR l’atteignent par le droit de l’Union. Les obligations se recoupent largement sur la gestion des risques, la journalisation, la documentation et la supervision humaine : la voie efficace consiste donc à mapper un socle de contrôles unique sur les deux régimes, et non à faire tourner deux programmes en parallèle.

Conclusion

Les résultats de recherche sur la conformité HIPAA et l’IA décrivent une décision d’achat. L’obligation réelle, elle, décrit un mode de fonctionnement. HIPAA encadre la donnée. La Section 1557 encadre la décision, et le fait depuis mai 2025. HTI-1 encadre l’information délivrée. La FDA encadre le dispositif. Pour les organisations présentes des deux côtés de l’Atlantique, l’AI Act encadre le système. Aucune de ces règles n’est à elle seule la réponse, et aucune ne se satisfait d’un contrat signé assorti d’une promesse de chiffrement. Ce qui les relie n’a rien de spectaculaire et reste parfaitement atteignable : connaître chaque système d’IA en service, le classer honnêtement, le tester au regard des caractéristiques que la loi énumère, écrire ce que l’on a décidé et pourquoi, puis le surveiller après la mise en service. C’est cela, la gouvernance de l’IA, et en santé elle fait la différence entre un dispositif défendable et une bonne intention.