← Resources
USECASE · 2026-03-12
IA privée pour la santé : workspaces alignés HIPAA sans lock-in cloud
Une IA alignée HIPAA n'oblige pas à envoyer des PHI à un modèle tiers. Un workspace on-device-first avec repli cloud BYOK optionnel, journaux d'audit, RBAC et BAA signé là où le cloud est touché peut satisfaire la plupart des exigences des entités couvertes.
Ce que HIPAA exige réellement d'un assistant IA
*Cet article est une orientation générale et ne constitue ni un avis juridique ni un conseil de conformité ; le délégué à la protection des données de votre entité couverte a le dernier mot.*
HIPAA a été écrit autour de la donnée, pas autour de l'outil qui la lit, si bien qu'un assistant IA est traité comme tout autre membre du personnel ou business associate qui touche des données de santé protégées. La Privacy Rule régit les usages et divulgations autorisés des PHI ainsi que la norme du minimum nécessaire. La Security Rule impose des sauvegardes administratives, physiques et techniques : contrôle d'accès, contrôles d'audit, intégrité, sécurité de transmission et analyse de risque documentée. La Breach Notification Rule fixe l'obligation de notifier les personnes concernées, le HHS et, pour les incidents majeurs, les médias, en cas de divulgation non autorisée de PHI non sécurisées.
Les textes récents du HHS ont signalé que les systèmes IA qui créent, reçoivent, conservent ou transmettent des ePHI doivent être inventoriés et soumis à une analyse de risque comme tout autre actif, avec chiffrement en transit et au repos, authentification multi-facteur et réponse à incident en temps utile. L'obligation ne change pas parce que l'entité qui lit le dossier est un modèle.
Où ChatGPT, Copilot et Gemini ne suffisent pas pour les PHI
D'usine, les tiers grand public de ChatGPT, Microsoft Copilot et Google Gemini ne sont pas appropriés pour les PHI. Les abonnements gratuits et standards ne s'accompagnent pas d'un Business Associate Agreement, et les prompts peuvent être conservés ou utilisés pour l'amélioration du modèle selon les conditions par défaut.
Nuance à garder en tête : chaque éditeur propose des configurations entreprise pouvant être couvertes par un BAA. OpenAI signe des BAA pour l'API et pour ChatGPT Enterprise ou Edu via les comptes gérés par la vente. Microsoft propose une couverture BAA pour Azure OpenAI Service et certains tenants Microsoft 365 Copilot, mais GitHub Copilot et d'autres surfaces grand public sont exclues. Google supporte un BAA pour Gemini dans les niveaux Workspace qualifiants, mais exclut explicitement NotebookLM et la surface Gemini-dans-Chrome.
Le risque pratique, c'est la dérive du personnel. Un clinicien qui colle un compte rendu de sortie dans l'onglet d'un chatbot gratuit constitue par défaut une divulgation hors BAA, quel que soit le contenu du contrat entreprise.
L'architecture on-device-first : modèle local + BYOK opt-in
Une architecture qui minimise l'exposition HIPAA inverse le pattern SaaS habituel. Le modèle par défaut tourne sur l'appareil de l'utilisateur, typiquement un LLM open-weights quantifié servi localement, si bien que prompts et générations ne quittent jamais le terminal. Quand un clinicien a besoin d'un modèle de raisonnement plus puissant, le workspace peut basculer vers un fournisseur cloud avec la clé API de l'organisation, sous le BAA de ce fournisseur, avec un opt-in explicite par requête ou par workspace.
C'est le pattern derrière osFoundry : un runtime llama.cpp local est la valeur par défaut first-class, et tout appel cloud est en bring-your-own-key contre un éditeur que l'entité couverte a contractuellement validé. Il n'y a pas de pool d'inférence multi-locataire partagé entre le clinicien et le modèle.
Le bénéfice conformité est concret. Les charges traitables localement ne génèrent jamais d'événement de divulgation cloud. Les charges qui exigent de la capacité cloud sont tracées, attribuables et soumises au BAA déjà validé par l'entité couverte.
Audit, RBAC, DLP et minimum nécessaire en pratique
Les sauvegardes techniques sont l'endroit où la plupart des pilotes IA échouent à leur premier audit interne. Quatre contrôles font le gros du travail.
Les journaux d'audit doivent capturer qui a prompté, quel modèle a répondu, quelles sources de données étaient attachées et ce qui a été renvoyé, avec stockage à preuve d'altération et fenêtre de rétention alignée sur votre politique de conservation. Le RBAC doit lier accès modèle, accès dataset et accès outils au rôle, pour qu'un compte d'accueil ne puisse interroger un corpus oncologique et qu'un rôle de facturation ne puisse déclencher un générateur de notes cliniques.
La DLP appartient à la frontière du prompt. Une rédaction par patterns et classifieurs des identifiants avant tout appel cloud impose la norme du minimum nécessaire de façon programmatique, et non par la seule formation. Une résidence des données par workspace empêche les données d'un cabinet de se mélanger à celles d'un autre.
Aucun n'est une invention spécifique à l'IA, mais leur combinaison est ce qui permet à un délégué de signer pour qu'un modèle touche un dossier.
Trois flux : notes d'accueil, accord préalable, Q&R opérationnelles
Les notes d'accueil et de visite sont la charge locale à plus forte valeur. Un clinicien dicte, un modèle local rédige une note structurée, et rien ne quitte l'appareil tant que le clinicien n'a pas signé et que l'EHR n'a pas reçu un dossier posté via son interface existante. La latence est acceptable sur un portable moderne et la surface PHI se limite au terminal.
L'accord préalable bénéficie du retrieval. Le modèle assemble une lettre brouillon à partir du dossier patient et des documents de medical-policy publiés par le payeur, avec citations. Si un modèle cloud plus puissant est invoqué pour la rédaction, l'extrait de dossier est désidentifié à la frontière du prompt et réidentifié sur l'appareil après le retour de la réponse.
Les Q&R opérationnelles sur les politiques RH, les codes de facturation et les procédures n'ont rarement besoin de PHI et peuvent tourner entièrement sur des modèles locaux ou cloud avec une DLP bloquante des PHI en place. Répartir les charges ainsi maintient le trafic le plus risqué sur l'appareil et le moins risqué dans le cloud.
BAA et risque fournisseur : ce qu'il faut demander à tout éditeur IA
Avant de signer, déroulez une courte liste. L'éditeur exécutera-t-il un BAA couvrant la surface produit exacte que vous utiliserez, et non un produit voisin ? Quels endpoints, modèles et consoles précis sont in scope, et lesquels sont exclus par écrit ? Quelle est la rétention par défaut pour prompts, complétions, embeddings et artefacts de fine-tuning, et peut-elle être mise à zéro ?
Demandez la liste des sous-traitants et le mécanisme de notification de changement. Confirmez le chiffrement en transit et au repos, la posture de gestion de clés et la disponibilité de clés gérées par le client. Exigez des délais de notification de brèche qui vous permettent de tenir votre propre obligation de notification patient à 60 jours avec marge.
Demandez le dernier SOC 2 Type II et toute attestation HITRUST, la cadence des tests d'intrusion et le runbook de réponse à incident. Enfin, faites confirmer par écrit que l'éditeur n'entraînera pas de modèles partagés sur les données de votre tenant.
Déploiement pilote en 30 jours
La première semaine est cadrage. Le délégué à la protection des données, un sponsor clinique et la DSI choisissent deux ou trois flux, rédigent le diagramme de flux de données et mettent à jour l'analyse de risque. Identifiez quelles étapes peuvent être local-only et lesquelles nécessitent le cloud, et confirmez la couverture BAA pour toute surface cloud.
La deuxième semaine est provisioning. Montez le workspace avec des rôles RBAC mappés aux intitulés de poste, activez les journaux d'audit vers votre SIEM, configurez les règles de rédaction DLP à la frontière du prompt et chargez le modèle local sur les postes pilotes. Documentez le plan de rollback.
La troisième semaine est un pilote supervisé avec cinq à dix cliniciens. Suivez le temps gagné, le taux d'erreur contre un gold set revu par humain et tout déclenchement DLP. Tenez une revue en milieu de semaine avec le délégué.
La quatrième semaine est le go/no-go. Mettez à jour politique et matériels de formation, finalisez la communication d'usage d'IA aux patients le cas échéant, et fixez les critères d'extension à la prochaine cohorte.
Frequently asked questions
- Faire tourner un modèle on-device évite-t-il complètement le besoin de BAA ?
- Pour l'inférence locale elle-même, oui, puisqu'aucune PHI n'est divulguée à un tiers. Vous devez encore tenir compte du rôle de l'éditeur logiciel. Si le runtime local, le shell du workspace ou un plan de management peuvent recevoir des PHI via télémétrie, journaux ou sessions de support, l'éditeur agit en business associate et un BAA est approprié. Le pattern sûr consiste à faire confirmer par écrit que l'éditeur ne reçoit pas de PHI depuis l'appareil par défaut et à désactiver toute télémétrie optionnelle pouvant transporter du contenu. Les replis cloud exigent toujours un BAA avec le fournisseur du modèle cloud.
- Pouvons-nous utiliser ChatGPT, Copilot ou Gemini dans un flux HIPAA ?
- Oui, mais uniquement sur les configurations entreprise spécifiques que l'éditeur a acceptées de couvrir par BAA, et seulement pour les surfaces explicitement nommées dans cet accord. OpenAI couvre l'API et certains tenants ChatGPT Enterprise ou Edu. Microsoft couvre Azure OpenAI Service et les tenants Copilot qualifiants. Google couvre Gemini dans les niveaux Workspace qualifiants en excluant NotebookLM et Gemini dans Chrome. Les tiers gratuits et grand public ne sont pas couverts. Le problème plus difficile est le comportement du personnel : bloquer les surfaces grand public au niveau réseau ou navigateur compte autant que le contrat.
- En quoi les journaux d'audit IA diffèrent-ils de l'accès EHR classique ?
- Les journaux d'audit EHR classiques capturent l'accès au dossier par utilisateur, heure et action. Les journaux d'audit IA doivent capturer le prompt, le modèle et la version, le contexte récupéré, la réponse, l'utilisateur, le workspace et tout outil invoqué par le modèle. Ils doivent aussi capturer les décisions de routage cloud quand un repli BYOK est utilisé. Conservez-les à côté des journaux EHR sous la même politique de rétention, stockez-les à preuve d'altération et alimentez-les dans le SIEM que votre équipe sécurité surveille déjà, pour que l'activité IA fasse partie de la réponse normale aux incidents plutôt que d'un silo parallèle.
- Et les changements de la Security Rule 2026 ?
- Les textes récents du HHS font passer plusieurs sauvegardes auparavant addressable au statut required, avec un accent renforcé sur le chiffrement, l'authentification multi-facteur, un inventaire d'actifs incluant les systèmes IA qui manipulent des ePHI, et des délais de signalement d'incident plus serrés. Traitez tout assistant IA comme un actif in scope pour l'analyse de risque, documentez les flux de données et confirmez que votre runbook de réponse à incident peut tenir les fenêtres de notification raccourcies. Coordonnez-vous avec votre délégué sur les dates d'effet exactes et les transitions applicables à votre organisation, puisque la posture d'application et les éventuelles extensions peuvent évoluer après publication.
Sources