La responsabilité liée à l’IA clinique dépend des preuves

Lorsqu’un outil d’IA clinique cause un préjudice à un patient, personne ne commencera par demander quel modèle a généré le résultat. On voudra savoir qui a pu consulter quels dossiers patients, sous quelle autorité, et où se trouve la preuve de cet accès. Cette question s’adresse au système de santé, que l’outil ait été conçu par un prestataire, paramétré par une équipe interne ou simplement intégré au dossier médical électronique par un service bien intentionné.

L’American Medical Association (AMA) a désormais donné un cadre à cette question. Dans un communiqué du 29 octobre 2026, l’AMA présente un modèle de responsabilité pour l’IA clinique qui répartit les responsabilités entre trois parties, selon ce que chacune contrôle. Les développeurs répondent de la sécurité et de l’efficacité de ce qu’ils créent. Les médecins répondent du jugement clinique qu’ils peuvent réellement exercer. Les établissements de santé, qui déploient les outils, répondent de la sélection, de la mise en œuvre, de la gouvernance et du suivi des systèmes d’IA une fois ceux-ci déployés à l’hôpital.

Ce cadre relève de la politique, pas de la loi, et rien n’y modifie du jour au lendemain l’analyse des tribunaux. Mais pour un RSSI ou un Chief Compliance Officer dans la santé, la troisième partie citée est celle qui pose un problème de documentation. Chaque verbe associé au déployeur — sélectionner, mettre en œuvre, gouverner, surveiller — implique soit une trace, soit une lacune. Un enquêteur, un assureur ou un avocat adverse cherchera cette trace, et la couche de données est la principale source. C’est précisément sur ce terrain que Kiteworks secure data exchange intervient, en gouvernant et en journalisant la façon dont les personnes et les systèmes d’IA accèdent au contenu sensible, afin que la preuve existe avant même que la question ne soit posée.

Résumé des points clés

1. La responsabilité est répartie selon le contrôle.

Le cadre de l’AMA du 29 octobre 2026 répartit la responsabilité entre développeurs, établissements de santé et médecins, selon ce que chacun peut contrôler.

2. Les établissements de santé détiennent la preuve de la gouvernance.

Selon ce cadre, les déployeurs répondent de la sélection, de la mise en œuvre, de la gouvernance et du suivi de l’IA, et chaque action génère une preuve ou révèle une faille.

3. HIPAA s’applique déjà.

L’identification unique des utilisateurs et les contrôles d’audit sont en vigueur aujourd’hui, la Security Rule ne prévoit aucune exception pour l’IA, et attendre la réforme proposée n’est pas une stratégie.

4. Le déficit de preuve est mesurable.

Selon une étude Kiteworks, la moitié des organisations interrogées ne peuvent fournir un audit complet des accès IA aux données en moins d’un jour ouvré.

5. La preuve est ce que vous pouvez construire dès maintenant.

Une couche de données gouvernée, qui relie chaque requête IA à un humain identifié, applique les règles et écrit un journal infalsifiable, soutient votre défense sans prétendre corriger l’exactitude clinique.

Ce que dit (et ne dit pas) le cadre de l’AMA

Commençons par la structure de la proposition, car les détails déterminent ce qu’un service conformité doit en faire. Le principe de l’AMA est que la responsabilité doit suivre l’autorité permettant de prévenir ou de réduire le risque. Un développeur contrôle la conception, les tests et la documentation d’un outil, il porte donc le risque qui en découle. Un médecin contrôle la décision clinique au chevet du patient, il porte donc la responsabilité du jugement qu’il peut réellement exercer. Un établissement de santé contrôle les outils qui entrent dans l’organisation, qui est formé à leur usage, et comment ils sont surveillés par la suite.

Le message adressé aux établissements de santé est explicite. Le communiqué indique que les organisations de santé doivent être responsables de la sélection, de la mise en œuvre, de la gouvernance et du suivi des systèmes d’IA dans des conditions réelles. Il s’agit d’une exigence de gouvernance, et la gouvernance se prouve par des documents, des journaux et des décisions reconstituables, pas par des intentions.

Le passage concernant les médecins est tout aussi direct, et il n’avantage pas les établissements. L’AMA précise que les médecins doivent répondre du jugement clinique qu’ils peuvent réellement exercer, et ajoute que la supervision médicale ne remplace pas des preuves suffisantes ni une conception adéquate des systèmes. Relisez bien cela. Si un clinicien ne peut être tenu de détecter une faille invisible au moment du soin, la responsabilité de cette faille incombe à un autre acteur, et le cadre vise le développeur et l’organisation qui a choisi, configuré et surveillé l’outil.

Le cadre s’adresse aussi aux patients. Il affirme que les patients doivent conserver des moyens concrets de demander des comptes et d’obtenir réparation en cas de préjudice causé par un système d’IA défectueux ou toute autre défaillance. Cette phrase explique pourquoi la question de la preuve est centrale. Un recours n’a de sens que si l’on peut établir ce qui s’est passé, et cela relève d’abord d’un problème de traçabilité, avant d’être un problème juridique.

Ce que le cadre ne fait pas est tout aussi important. Il ne crée pas de nouveau motif d’action, il ne modifie pas HIPAA, et il ne dicte pas aux hôpitaux quels contrôles techniques acheter. Il s’agit d’une prise de position sur la répartition des responsabilités selon l’AMA, qui servira de référence dans les débats politiques, les négociations contractuelles, et à terme dans les discussions sur la norme de soins. Un responsable conformité qui l’interprète comme un avant-goût des questions à venir, plutôt qu’un règlement déjà en vigueur, l’aura bien compris.

Pourquoi la charge de la preuve incombe aux déployeurs

Il faut être lucide sur la raison pour laquelle le rôle du déployeur est si exposé. Les développeurs détiennent le modèle, les données d’entraînement et les résultats de test. Les médecins détiennent la relation clinique. Les établissements de santé détiennent quelque chose de moins valorisant mais de plus traçable : la configuration des accès, le code d’intégration, les comptes de service, les contrats fournisseurs, les registres de formation et les journaux. En cas de litige, ce sont ces éléments que l’on demandera en premier.

La formation illustre bien cette faille. L’enquête menée par l’AMA auprès des médecins en 2026, du 15 janvier au 2 février, a interrogé 1 692 médecins : 27 % déclarent n’avoir reçu aucune formation à l’IA, et 92 % souhaitent davantage de sensibilisation et de formation. Ce résultat n’a rien de surprenant. Mais il intéressera un avocat de la partie adverse, car le cadre rend les déployeurs responsables de la mise en œuvre des outils, et un personnel non formé fait partie de cette mise en œuvre.

La même enquête montre pourquoi la question de la responsabilité est passée au premier plan. Parmi les 1 419 médecins ayant répondu à une question sur les mesures réglementaires qui renforceraient leur confiance dans l’IA, la mise en place de cadres de responsabilité clairs arrive en tête, choisie par 31 %. Ce classement montre que les médecins veulent des règles écrites avant d’assumer le risque. Les établissements incapables de prouver comment un outil a été validé, qui peut l’utiliser et quelles données il peut consulter auront du mal à rassurer autrement que par des promesses.

La charge du déployeur se résume donc à quelques questions concrètes qu’un RSSI peut poser dès cette semaine. Quels outils d’IA sont utilisés en clinique ou en exploitation, y compris ceux qui n’ont pas été officiellement achetés ? Quelles données patients chaque outil peut-il consulter ? Chaque outil ou agent est-il rattaché à une personne responsable de ses actions ? Et si un régulateur demandait le journal des accès de mardi dernier, combien de temps faudrait-il pour le produire ? Les sections suivantes détaillent ces questions.

HIPAA régit les données, pas le modèle

Les établissements de santé disposent ici d’un avantage structurel, même s’il est rarement perçu comme tel. HIPAA ne s’intéresse pas à la sophistication du modèle. Il régit ce qui advient des informations médicales protégées, sans aucune exemption pour l’IA. Lorsqu’un assistant IA consulte un dossier, qu’un outil de synthèse extrait des notes dans une invite, ou qu’un agent assemble des dossiers pour une demande d’autorisation, les exigences d’accès et d’audit de la Security Rule s’appliquent comme pour une infirmière qui se connecte au système.

Deux dispositions méritent d’être rappelées. Selon 45 CFR 164.312, l’identification unique de l’utilisateur est une exigence obligatoire, c’est-à-dire l’attribution d’un identifiant unique pour tracer chaque utilisateur. La norme sur les contrôles d’audit impose des mécanismes matériels, logiciels ou procéduraux pour enregistrer et examiner l’activité sur les systèmes d’information. Aucune de ces exigences ne précise si l’acteur est une personne ou un programme. Toutes deux exigent de pouvoir reconstituer qui a fait quoi.

C’est là que les architectures IA classiques posent problème. Un assistant qui interroge les données patients via un compte de service partagé rend difficile la démonstration de l’identification unique, car le journal ne montre que le compte de service, pas le clinicien ou le workflow à l’origine de la requête. Une invite système dotée de larges droits présente la même faille. Ces conceptions sont rapides à mettre en place, d’où leur omniprésence, mais elles brouillent la frontière entre décision humaine et action machine — ce que tout auditeur ira examiner.

Le sujet du chiffrement est plus nuancé. Aujourd’hui, le chiffrement des informations médicales protégées électroniques est une exigence « adressable » dans la même section, ce qui signifie que les organisations doivent l’évaluer, le mettre en œuvre ou documenter une alternative équivalente. L’Office for Civil Rights a publié en janvier 2025 un projet de renforcement de la Security Rule, et Holland and Knight indiquait en juillet 2026 que la publication finale était prévue pour juillet 2027 selon l’agenda fédéral. Un projet n’est pas une obligation. Mais un établissement qui attend le texte définitif avant de réfléchir à la façon dont l’IA accède aux données patients attend une échéance qui ne régit pas les faits déjà soumis à un plaignant ou à un auditeur.

La conclusion pratique est que le cadre le plus solide pour un responsable conformité santé est le plus simple. HIPAA régit les données, et il s’appliquera à l’accès IA à ces données selon les règles déjà en vigueur. La Security Rule HIPAA n’a pas besoin d’être réécrite pour qu’un enquêteur demande qui a accédé à un dossier. Il suffit que la trace existe.

Le déficit de preuve derrière le cadre

Si la preuve est centrale, dans quelle mesure les organisations sont-elles prêtes à la produire ? Honnêtement, la plupart ne le sont pas, et les chiffres sont cohérents, quelle que soit la source.

Commençons par les journaux d’audit des accès IA. Dans le Kiteworks Data Security and Compliance Risk: 2026 Annual Survey Report, basé sur les réponses de 459 professionnels de la sécurité, de la conformité et de la technologie au deuxième trimestre 2026, 50 % déclarent ne pas pouvoir fournir un audit complet des accès IA en moins d’un jour ouvré, et seuls 17 % y parviennent en moins d’une heure. Deux réserves : les résultats sont auto-déclarés, et l’échantillon couvre tous les secteurs, donc ce n’est pas un chiffre santé. Mais cela montre l’ampleur du déficit : la moitié échouerait à respecter un délai d’un jour.

Ce délai n’est pas arbitraire. L’horloge d’un régulateur, une injonction judiciaire ou un questionnaire d’assurance n’attendent pas une semaine de reconstitution manuelle des journaux. Une organisation qui doit mobiliser plusieurs systèmes et équipes pour répondre à une question d’accès a un processus, mais pas une preuve au sens d’un auditeur : une trace complète, fiable et disponible à la demande.

La confiance dans la gouvernance raconte la même histoire sous un autre angle. L’AI Impact Survey 2026 de Grant Thornton, publié le 13 avril 2026, révèle que 78 % des près de 1 000 dirigeants interrogés n’ont pas une confiance totale dans la capacité de leur organisation à réussir un audit indépendant de gouvernance IA en moins de 90 jours. L’enquête ne concerne pas que la santé, et Grant Thornton vend des services de conseil sur ce sujet, donc prenez ce chiffre comme un indicateur de confiance des dirigeants, pas comme un taux d’échec mesuré. Mais l’expression « en moins de 90 jours » est révélatrice : les dirigeants ne disent pas qu’ils n’ont pas de gouvernance, mais qu’ils ne pourraient pas le prouver rapidement.

Les données spécifiques à la santé vont dans le même sens. Un rapport de référence SAI360 et Strategic Management Services, basé sur une enquête 2025 auprès de 261 entités couvertes et partenaires, indique que 86 % détectent les incidents HIPAA via des signalements d’employés à la direction ou à la conformité, tandis qu’environ 35 % utilisent une surveillance automatisée des accès utilisateurs aux informations médicales protégées et 21 % une revue automatisée des journaux d’audit des dossiers médicaux électroniques. L’échantillon est auto-sélectionné et orienté hôpitaux et santé mentale, donc il décrit ceux qui ont répondu, pas tout le secteur. Mais il suggère que dans beaucoup d’organisations, la première alerte vient d’un collègue, pas d’un système générant une trace.

Pris ensemble, ces trois constats révèlent un schéma qui n’a rien à voir avec tel ou tel modèle. Le point faible n’est pas l’intelligence, mais l’attribution : savoir quelle identité a accédé à quelles données sous quelle règle, et pouvoir le prouver rapidement. Les outils IA ne font qu’aggraver ce point faible, car ils agissent à la vitesse machine, souvent via des comptes qui n’ont jamais été conçus pour porter une responsabilité.

À quoi ressemble une preuve défendable pour l’accès IA aux PHI

Un enquêteur qui examine un incident lié à l’IA posera généralement les mêmes quatre questions, dans un ordre ou un autre. Qui ou quoi a accédé aux données ? Qu’a-t-on consulté précisément ? Selon quelle règle cet accès était-il autorisé ? Et pouvez-vous prouver que la trace n’a pas été modifiée ? Un programme défendable est celui qui peut répondre à ces quatre questions sans improviser.

Première question : une requête IA n’est pas un événement anonyme. Quelqu’un a configuré l’outil, quelqu’un a validé son usage, et dans de nombreux workflows, un clinicien ou un membre du personnel a déclenché la requête. La qualité de la preuve dépend du rattachement de la requête à un humain identifié, responsable, et non à un identifiant partagé. Considérez l’agent IA comme une classe d’identité supplémentaire, soumise à la même gouvernance que les employés, prestataires et partenaires, avec un modèle d’identité et un journal unique pour chaque action.

Deuxième question : la portée. Le principe du minimum nécessaire de HIPAA impose de limiter l’utilisation et la divulgation des informations médicales protégées à ce qui est requis pour l’objectif. Si un assistant peut accéder à tout un référentiel, ce principe dépend de la politique appliquée à l’accès, pas du bon vouloir de l’outil. Les contrôles d’accès basés sur les rôles ou sur les attributs permettent à l’équipe conformité de définir qui peut voir quoi, dans quelles conditions, et d’appliquer les mêmes règles à une personne ou à un agent agissant pour une personne.

Troisième question : la règle. Il ne suffit pas que l’accès ait été autorisé. Un examinateur veut voir quelle règle l’a permis. Cela signifie que la décision elle-même, et pas seulement le résultat, doit figurer dans la trace. Un moteur de politique qui évalue chaque requête et journalise le résultat offre au CCO une explication, pas seulement une liste d’événements.

Quatrième question : l’intégrité. Un journal modifiable par les personnes qu’il décrit est une preuve faible. Des journaux d’audit infalsifiables, transmis à une plateforme de gestion des événements de sécurité (SIEM) interrogeable par la conformité, transforment une pile d’événements en preuve.

C’est la logique de conception de Kiteworks Compliant AI et du Secure MCP Server. Quand un assistant IA accède au contenu d’entreprise via cette solution, chaque requête est liée à l’identité de l’humain qui l’a autorisée, vérifiée par une politique basée sur les attributs, protégée par un chiffrement validé FIPS 140-3, et inscrite dans un journal d’audit infalsifiable pouvant être transmis au SIEM de l’organisation. Le moteur de politique de données applique la même gouvernance aux personnes et aux agents IA, pour que l’équipe conformité n’ait qu’un seul journal à examiner. Le CISO Dashboard et un rapport de conformité HIPAA facilitent le reporting, en montrant comment le contenu sensible est consulté et partagé.

Il est important de préciser ce que cette approche couvre ou non, car toute exagération crée un risque. Cette démarche gouverne l’accès aux données. Elle ne juge pas l’exactitude d’une recommandation clinique, ne remplace pas l’obligation du développeur de surveiller la performance du modèle, et ne se substitue pas à la gestion d’incident si un outil IA fournit un mauvais conseil clinique. Elle s’applique au trafic IA passant par la couche gouvernée, et sa capacité à traiter un contenu comme information médicale protégée dépend de son étiquetage ou de sa classification. Sa valeur est plus restreinte qu’une promesse de rendre l’IA sûre, mais plus utile pour autant. Quand la question est « qui a accédé à quoi ? », la réponse est déjà consignée.

Là où s’arrête la responsabilité du développeur et où commence la vôtre

Un programme de gouvernance centré sur la preuve d’accès aux données ne couvre pas toute la sécurité de l’IA clinique, et l’AMA précise bien la répartition des rôles. Dans ses commentaires à la FDA sur les dispositifs médicaux à IA générative, publiés le 19 octobre 2026, l’AMA demande un renforcement de la surveillance post-commercialisation pour suivre la performance du dispositif tout au long de son cycle de vie, y compris après déploiement, et précise que les fabricants doivent rester responsables de la performance de leurs produits. Elle ajoute que la supervision médicale ne remplace pas la nécessité de preuves rigoureuses de la sécurité et de la fiabilité du dispositif dans son contexte d’utilisation.

Pour un établissement de santé, cette répartition apporte deux enseignements. D’abord, la surveillance de la performance par le fournisseur et la gouvernance des accès par le déployeur sont deux obligations distinctes, et un contrat qui ne couvre qu’un seul de ces aspects laisse un vide. Ensuite, le déployeur ne peut pas déléguer tout le problème au fournisseur. Même si le fabricant est principalement responsable de la performance du modèle, l’hôpital décide qui peut utiliser l’outil, à quels dossiers il peut accéder et comment son activité est tracée. Ces décisions relèvent de l’hôpital, tout comme la preuve de leur application.

C’est pourquoi la rédaction contractuelle compte autant que la technologie. Demandez aux fournisseurs la documentation sur l’usage prévu, les limites connues et la performance, ainsi que sur la journalisation et l’attribution de leurs produits lorsqu’ils accèdent à des données patients. Puis vérifiez votre côté : qui, dans l’organisation, est nommé responsable de chaque outil, et où cette attribution est-elle consignée ? La gestion du risque IA reste floue dans beaucoup d’organisations, et certaines n’ont aucun responsable désigné. Un cadre qui répartit la responsabilité entre les parties n’aide pas un hôpital dont la responsabilité interne n’est pas définie.

Un plan sur 90 jours pour le RSSI et la conformité

Quatre-vingt-dix jours constituent un horizon pertinent, car il correspond à la fenêtre utilisée par Grant Thornton pour la question de l’audit, et il est suffisant pour construire quelque chose de concret. Un plan n’a pas besoin d’attendre que le cadre de l’AMA devienne plus qu’un cadre.

Inventaire et attribution (jours 1 à 30)

Établissez la liste de tous les outils et agents IA qui accèdent à des données cliniques ou administratives, y compris les non officiels. Pour chacun, consignez les données accessibles, l’identité utilisée et la personne responsable. Tout outil utilisant un compte de service partagé doit figurer sur une liste de remédiation, car ce schéma échoue le plus souvent à l’identification unique. Profitez-en pour repérer les outils qui acceptent des données patients dans les prompts sans passer par une couche gouvernée.

Accès gouverné et politique (jours 31 à 60)

Faites passer l’accès IA au contenu sensible par une couche gouvernée unique, plutôt qu’une multitude d’intégrations directes. Définissez les règles dans un langage lisible par un responsable conformité : quels rôles, quelles classes de données, quels usages. Appliquez la même politique aux personnes et aux agents. Vérifiez que chaque requête IA est liée à un humain autorisateur et que le journal est transmis à la pile de surveillance sécurité. L’objectif réaliste de cette phase est de couvrir les workflows les plus à risque, pas tous les workflows.

Exercice de preuve (jours 61 à 90)

Réalisez un exercice qui simule une enquête réelle. Choisissez un dossier patient, une date et un outil, et demandez à l’équipe de produire la trace complète des accès IA. Chronométrez l’exercice. S’il faut plus d’un jour ouvré, considérez ce délai comme une anomalie et corrigez d’abord l’attribution et la journalisation. Présentez ensuite le résultat au comité ou au conseil de gouvernance IA, en termes d’exposition et de preuve, pas de métriques de modèle. Répétez l’exercice chaque trimestre, car les intégrations IA évoluent plus vite que les politiques.

Rien de tout cela n’exige de certitude sur la façon dont le cadre AMA sera adopté. Il s’agit de pouvoir répondre à une question que chaque version du futur posera.

Ce que cela implique pour les dirigeants santé réglementés

Le cadre de l’AMA indique une direction. Il ne tranche pas qui paiera en cas de défaillance de l’IA clinique, et le débat se poursuivra entre médecins, juristes et industriels. Mais la tendance est claire : la responsabilité se rapproche des acteurs capables de contrôler le risque, et celui qui contrôle l’accès aux données patients, c’est l’établissement de santé.

C’est une opportunité autant qu’une contrainte. Les organisations capables de montrer, rapidement et de façon crédible, comment les outils IA sont sélectionnés, qui peut les utiliser, quelles données ils peuvent consulter et ce qu’ils ont fait, négocieront leurs contrats fournisseurs en position de force, répondront plus facilement aux assureurs et rencontreront les régulateurs avec un dossier déjà prêt. Les autres découvriront le déficit de preuve au pire moment, en pleine enquête, avec le temps qui presse.

La question à poser lors du prochain comité de gouvernance n’est pas de savoir si vos outils IA cliniques sont assez intelligents. C’est de savoir si, demain après-midi, vous pourriez prouver qui et quoi a accédé à un dossier patient donné, et selon quelle règle. Si la réponse honnête est « pas encore », vous savez par où commencer.

Pour en savoir plus sur la production de preuves d’audit pour l’accès IA aux données patients, réservez une démo personnalisée dès aujourd’hui.

Ressources complémentaires

• Article de blog
  Stratégies Zero Trust pour une protection abordable de la vie privée avec l’IA
• Article de blog
  Comment 77 % des organisations échouent à sécuriser les données IA
• eBook
  Le déficit de gouvernance IA : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025
• Article de blog
  Il n’existe pas de « –dangerously-skip-permissions » pour vos données
• Article de blog
  Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent la preuve qu’elle fonctionne.