IA conforme HIPAA pour le support client : un guide pratique

« IA conforme HIPAA » ne veut pas dire ce que dit le marketing

Voici ce qu'il faut retenir d'abord : HIPAA n'a aucun organisme de certification. Personne ne délivre de tampon « conforme HIPAA » comme un laboratoire délivre une certification ISO 27001. Donc quand la page d'accueil d'un outil affiche « conforme HIPAA », cette affirmation fait beaucoup de travail discret, et elle signifie généralement « vous pouvez configurer cet outil pour qu'il soit conforme », pas « cet outil est conforme dès que vous l'activez ».

Un professionnel de l'IT en santé a résumé cette distinction avec clarté dans un post LinkedIn :

"The marketing claim of 'HIPAA compliant' often means the AI tool can be configured to meet HIPAA requirements; not that it's compliant by [default]."

L'écart entre « peut être configuré » et « est conforme » est exactement là où vivent les violations de données. Sur r/healthIT, un fil de discussion décrivait précisément ce mode d'échec :

"A healthcare group near me just installed an AI chatbot, which claims to be HIPAA compliant. It gives out personal information without verifying identity."

C'est un outil « conforme HIPAA » qui fuit activement des PHI en production. L'étiquette était vraie au sens strict (le fournisseur signerait un BAA) et inutile au sens pratique (personne n'avait configuré la vérification d'identité). La leçon pour quiconque recherche un chatbot pour la santé : la posture de conformité du fournisseur est nécessaire mais pas suffisante. La configuration reste de votre responsabilité.

Quand un ticket de support devient une PHI

La plupart des équipes support sous-estiment la proportion de leur file qui constitue une information de santé protégée. Il ne s'agit pas seulement de résultats d'analyses et de diagnostics. La méthode Safe Harbor de HIPAA répertorie 18 identifiants, et dès que l'un d'eux est associé à une information de santé, vous détenez une PHI. Cela inclut les noms, tous les types de dates (naissance, admission, rendez-vous), les numéros de téléphone, les adresses e-mail, les numéros de dossier médical, et les identifiants d'assurance ou d'assuré.

Examinez un ticket de support en santé ordinaire sous cet angle, et presque chaque champ s'allume. « Alex R., rendez-vous le 23 mai, identifiant d'assuré 87234921, message : j'ai une douleur aiguë dans le bas du dos » est un exemple type de PHI. Ce n'est pas hypothétique : dans une action coercitive de la HHS en 2025, l'OCR a constaté qu'un prestataire avait divulgué de manière non autorisée des ePHI incluant les noms des patients, leurs dates de naissance et leurs diagnostics, exactement les champs que porte un ticket de support. C'est une des principales raisons pour lesquelles les logiciels de helpdesk pour la santé sont soumis à des exigences plus strictes que la plupart des autres outils.

C'est pourquoi le plan « on branche simplement ChatGPT sur notre helpdesk » est si dangereux dans le secteur de la santé. Chaque ticket que vous transmettez au modèle constitue une divulgation de PHI à un tiers, et les divulgations à des tiers sont précisément ce que régit HIPAA. Nous avons entendu cette préoccupation formulée presque mot pour mot par un acheteur danois du secteur de la télématique, dont l'audit de sécurité était un filtre absolu avant tout essai : leurs tickets contenaient des numéros de carte et des mots de passe, et tout l'audit reposait sur la question de savoir si ces données restaient à l'intérieur de leur environnement. Les acheteurs du secteur de la santé posent la même question, avec des enjeux plus élevés.

Ce qui est en jeu : ce que coûte réellement une erreur

La raison pour laquelle les acheteurs du secteur de la santé sont les auditeurs de sécurité les plus stricts que vous rencontrerez est que les conséquences négatives sont énormes et bien documentées.

Le secteur de la santé est celui où les violations de données coûtent le plus cher depuis 14 années consécutives, avec une moyenne de 7,42 millions de dollars par incident dans le rapport 2025 d'IBM, bien au-dessus de la moyenne tous secteurs confondus de 4,44 millions de dollars. Les violations dans le secteur de la santé sont aussi les plus longues à détecter et à contenir, avec 279 jours en moyenne. Et le risque extrême est réellement catastrophique : la violation Change Healthcare a été confirmée par la HHS comme ayant touché environ 192,7 millions de personnes, ce que le département qualifie de plus grande violation de données de l'histoire de la santé aux États-Unis.

L'application des sanctions n'est pas abstraite non plus. Le prestataire de santé comportementale visé par cette action de l'OCR a payé un règlement de 225 000 dollars et s'est engagé dans un plan d'action correctif de deux ans après une violation ayant touché 171 871 personnes, la cause profonde étant l'absence d'une analyse de risque HIPAA de base. Quand une décision liée à un outil de support pourrait plausiblement finir sur le portail public des violations de la HHS, on comprend pourquoi la conversation sur le BAA arrive en premier, bien avant que quiconque ne parle d'économies de coûts.

Ce que HIPAA exige réellement d'un fournisseur d'IA pour le support

Une fois le marketing mis de côté, les exigences de HIPAA envers un fournisseur sont précises. Si un outil d'IA traite des PHI en votre nom, il s'agit d'un « business associate », et la HHS est sans ambiguïté sur ce que cela implique.

Il doit signer un BAA. La HHS exige qu'une entité couverte obtienne des garanties écrites satisfaisantes qu'un business associate protégera les PHI, et « l'analyse, le traitement ou l'administration de données » (ce que fait une IA de support) est explicitement désigné comme une fonction de business associate. Sans BAA signé, pas de traitement licite. Point final.

Il est directement responsable. Depuis le HITECH Act, les mesures de protection de la Security Rule s'appliquent aux business associates de la même manière qu'à vous, et ces associés sont civilement et pénalement responsables en cas de violation. Votre fournisseur ne fait pas que promettre ; il est juridiquement exposé.

Il doit mettre en œuvre les mesures de protection de la Security Rule. C'est le trio administratif, physique et technique : analyse de risque, gestion des accès, chiffrement, contrôles d'audit, procédures d'incident, tout l'arsenal.

Il doit respecter le principe du « minimum nécessaire ». La Privacy Rule exige de limiter les PHI au minimum nécessaire pour accomplir la tâche. Pour une IA, c'est l'argument en faveur de la suppression des identifiants avant même que le modèle ne les voie.

Mis ensemble, c'est pourquoi un support IA conforme est un empilement de contrôles, et non une simple case à cocher.

Les grands modèles d'IA signent-ils même un BAA ?

C'est la question qui fait discrètement échouer beaucoup de projets bricolés en interne. Les équipes présument que, parce qu'elles construisent sur OpenAI ou Anthropic, elles sont couvertes. Les sources officielles disent : seulement sur la bonne offre, et seulement pour les bonnes fonctionnalités.

• OpenAI signera un BAA, mais uniquement pour l'API Platform, pas pour le produit grand public ChatGPT avec lequel vous avez probablement fait vos tests.
• Anthropic signe un BAA pour son API propriétaire « prête pour HIPAA » et ses offres Enterprise, et la liste des exclusions est stricte : le BAA ne couvre pas la Console, Claude Free/Pro/Max/Team, ni plusieurs fonctionnalités de l'API. La Messages API est couverte ; Batch, Files et Web Fetch ne le sont pas.
• Google Cloud propose un BAA HIPAA couvrant un ensemble précis de produits, dont Vertex AI, et exige que vous évitiez tout produit ne figurant pas explicitement sur la liste couverte lorsque vous travaillez avec des PHI.

Le schéma est cohérent chez les trois : les applications de chat grand public ne sont jamais éligibles HIPAA, et même les offres API ne couvrent qu'un sous-ensemble précis de fonctionnalités. Sur r/legaltech, un professionnel a résumé le bon modèle mental :

"Client data leaving your control doesn't mean you're not HIPAA compliant. OpenAI offers a BAA that forces you into non-retention API endpoints..."

C'est la nuance que ratent la plupart des prises de position à chaud du type « ChatGPT est-il conforme HIPAA ». Les données peuvent quitter vos quatre murs et rester conformes, à condition qu'il y ait un BAA et que les conditions de conservation soient verrouillées. C'est aussi l'argument le plus fort en faveur de l'achat plutôt que de la construction en interne : assembler le sous-ensemble de fonctionnalités couvertes de trois fournisseurs de modèles différents, chacun avec son propre BAA et sa propre liste d'exclusions, est un projet de conformité en soi. Comme nous l'a dit un acheteur lorsqu'il a choisi une plateforme plutôt qu'une application LLM développée en interne, il ne voulait pas de quelque chose qu'il devrait maintenir indéfiniment.

Comment fonctionne réellement un support IA conforme, sous le capot

Alors, à quoi ressemble concrètement un dispositif conforme correctement conçu ? L'action centrale consiste à satisfaire mécaniquement le principe du « minimum nécessaire » : supprimer les identifiants avant même que le modèle, votre base de données ou votre index de recherche n'y touchent.

Chez eesel, la rédaction des PII se produit à l'ingestion. Lorsque vous l'activez, les identifiants personnels (numéros de carte, e-mails, numéros de téléphone, numéros de sécurité sociale, clés API, noms, et plus encore) sont supprimés du contenu avant qu'il ne soit traité ou envoyé à un fournisseur d'IA, de sorte que les données originales n'atteignent jamais notre base de données ni notre index de recherche. Un collègue a rassuré cet acheteur danois du secteur de la télématique avec le même principe : l'IA regarde en réalité les types de questions et la forme d'une bonne réponse d'agent, pas les PII brutes d'un client.

Trois couches supplémentaires comptent tout autant :

• Aucun entraînement sur vos données. Votre contenu n'est jamais utilisé pour l'entraînement, et il ne sert qu'à vos agents. Les fournisseurs de modèles sous-jacents le traitent pour générer une réponse et ne l'intègrent pas non plus dans leurs modèles généraux.
• Isolation par espace de travail. Les données de chaque client sont entièrement cloisonnées, sans contamination croisée entre les comptes, avec en plus un chiffrement AES-256 au repos et TLS en transit, hébergées sur AWS aux États-Unis avec une résidence des données dans l'UE disponible sur demande.
• Un véritable délai de suppression. Le contenu client est supprimé dans un délai de 60 jours suivant une demande, conformément au RGPD.

Je vais être direct sur l'état de notre dossier administratif, car les fournisseurs qui exagèrent sur ce point sont précisément le problème : eesel signe un BAA et propose un support HIPAA sur notre offre Enterprise, et notre certification SOC 2 Type II est actuellement en cours, avec une surveillance continue via Vanta, mais pas encore terminée. Si un fournisseur affirme avoir une certification SOC 2 achevée sans pouvoir montrer de rapport sous NDA, il faut le remettre en question.

Gardez un humain dans la boucle, surtout dans le secteur de la santé

Le choix de configuration le plus important n'est pas un paramètre de sécurité, c'est la marge de manœuvre que vous laissez à l'IA pour agir seule. Le secteur de la santé est le dernier endroit où l'on veut un bot trop confiant qui répond automatiquement à tout.

La meilleure façon de formuler cela que j'ai entendue vient d'une responsable CX d'une marque de compléments alimentaires en vente directe, traitant environ 7 000 tickets par mois, qui nous a dit que l'IA ne répondrait jamais à 100 % des questions, et que ce dont ils avaient réellement besoin était « une IA qui ne traite que les tickets pour lesquels elle est confiante » et qui laisse le reste de côté. C'est exactement le schéma dont a besoin le support en santé.

Avec eesel, vous définissez précisément quels types de tickets l'IA traite, vous fixez un seuil de confiance, et vous routez tout le reste vers une personne via le triage des tickets. Les cas riches en PHI ou à haut risque peuvent être entièrement exclus de l'automatisation et envoyés directement en escalade, tandis que l'IA traite en toute sécurité le volume de niveau 1, les réinitialisations de mot de passe, les « où est mon rendez-vous », les questions de facturation, qui encombrent la file.

Vous pouvez même simuler tout le dispositif sur vos tickets historiques avant sa mise en production, afin de voir le taux de résolution et le profil de risque avant qu'un seul vrai patient ne soit concerné. C'est toute la différence entre une IA copilote et une IA qui devient un risque non supervisé.

Ce qu'il faut vérifier avant de signer

Si vous évaluez un outil d'IA pour le service client pour une file en santé ou par ailleurs réglementée, voici la courte liste qui compte réellement :

Remarquez à quel point peu de ces points concernent la qualité des réponses de l'IA. Dans le secteur de la santé, l'audit de sécurité fait la vente. Les équipes qui mettent l'IA en production le plus vite sont celles qui arrivent avec ces six questions et un fournisseur capable de répondre aux six dès le premier appel.

Essayez eesel pour le support en santé

Si vous essayez de déployer l'IA sur une file de support qui touche aux PHI, eesel est conçu exactement pour ce niveau d'examen. Il se connecte à votre helpdesk existant (comme Zendesk ou Freshdesk), s'entraîne sur votre propre base de connaissances et vos tickets passés, et vous permet de déployer l'IA avec la rédaction des PII activée, des données isolées par espace de travail, aucun entraînement sur votre contenu, et un BAA disponible sur notre offre Enterprise.

Ce que les équipes en santé apprécient le plus généralement : vous pouvez simuler l'IA sur des milliers de vos tickets historiques réels avant qu'elle ne réponde au moindre ticket réel, afin de voir le taux de résolution, le routage par confiance et le profil de risque dès le départ, sans deviner, sans exposer de patients à un bot non testé. Vous contrôlez exactement quels types de tickets elle traite et lesquels sont routés vers un humain. Réservez une démo et apportez votre question de sécurité la plus difficile ; ce sont les appels que nous préférons.