Shadow AI en santé : pseudonymiser un prompt ne suffit pas

Le shadow IA, concrètement, c'est quoi ?

Actualité — Johns Hopkins, octobre 2026. Le 21 septembre 2026, un membre du personnel de Johns Hopkins Bayview Medical Center a téléversé par erreur un tableur contenant des données de patients vers un outil d'IA public non approuvé par l'établissement. L'hôpital a découvert la divulgation le même jour et a commencé à notifier 3 182 patients à partir du 22 octobre. Les informations concernées pouvaient notamment comprendre des noms, des dates d'admission et de traitement, des numéros de dossier médical, des médicaments administrés et des noms de professionnels. L'outil d'IA n'a pas été publiquement identifié.

Le shadow IA, ou shadow AI, désigne l'utilisation professionnelle d'outils ou de fonctions d'intelligence artificielle en dehors du cadre défini par l'organisation : outil non déclaré, compte personnel, fonction IA intégrée à un logiciel ou usage dépassant le périmètre autorisé. Il peut s'agir d'une extension de navigateur, d'un service de transcription ou d'un assistant de réunion, autant que d'un chatbot.

DPO, RSSI, directions d'établissement et responsables du numérique en santé : cet article vous aide à repérer les usages IA qui échappent à votre organisation et à évaluer les protections proposées.

Prenons trois situations illustratives : une secrétaire colle un compte rendu dans son assistant personnel ; un soignant active une transcription sans vérifier où part l'enregistrement ; un salarié autorise une extension à lire les documents affichés. Qui connaît le destinataire, les accès accordés et la durée de conservation ? Le shadow IA n'est pas le nom d'une infraction, mais ces usages peuvent engager des obligations que l'établissement n'a pas évaluées.

Une donnée de santé ne se limite pas à un diagnostic

Dans Lindenapotheke, 4 octobre 2024, C-21/23, la CJUE qualifie de données de santé les informations saisies pour commander en ligne des médicaments réservés aux pharmacies, même sans ordonnance. Le rapprochement entre une personne et un médicament peut révéler une information de santé. Dans ce contexte, la Cour n'exige pas de certitude que l'acheteur soit le patient : une probabilité suffit.

Bien avant le RGPD, Lindqvist, 6 novembre 2003, C-101/01, rendu sous la directive 95/46, retenait déjà cette qualification pour une blessure au pied et un congé de maladie partiel.

Meta Platforms, 4 juillet 2023, C-252/21, précise que les rapprochements de données de navigation relèvent des catégories sensibles s'ils révèlent de telles informations. La visite d'un site ne suffit pas à rendre les données de cette visite manifestement publiques.

Deux questions doivent rester distinctes : le contenu révèle-t-il une information de santé, directement ou par déduction ? Peut-on la rattacher à une personne identifiée ou identifiable ? Notre application aux prompts : examiner aussi les traitements, achats et absences évoqués, puis les possibilités d'identification. Ces arrêts ne portent pas directement sur les assistants d'IA.

Retirer le nom du patient : trois opérations très différentes

Une note sans nom peut encore mentionner une pathologie rare, un âge précis, une commune et une date d'intervention. Leur combinaison peut permettre de reconnaître le patient. Le vocabulaire du fournisseur doit donc correspondre à une propriété démontrée : la CNIL distingue la pseudonymisation de l'anonymisation.

Le CEPD a adopté le 7 juillet 2026 les lignes directrices 02/2026 sur l'anonymisation pour consultation publique. La version 1 a été publiée le 8 juillet ; la consultation s'est déroulée du 8 juillet au 30 octobre 2026 et est désormais close. Le texte publié reste la version soumise à consultation : il ne doit pas être présenté comme une version finale adoptée après consultation.

Le RGPD impose d'apprécier les moyens raisonnablement susceptibles d'être utilisés. La qualification dépend donc du traitement, de son contexte et des possibilités d'identification. Une étiquette « anonymisé » sur une interface ne remplace pas cette analyse.

Ce que les juges ont réellement décidé

L'absence de clé chez le destinataire ne clôt pas l'analyse. Dans l'arrêt Breyer du 19 octobre 2016, C-582/14, rendu sous la directive 95/46, la CJUE a expliqué que les informations permettant l'identification peuvent être détenues par plusieurs acteurs. Il faut examiner les moyens raisonnables de les réunir, notamment les voies légales d'accès à des informations complémentaires. Pour un prompt, les possibilités de recoupement doivent donc être étudiées concrètement.

Le 4 septembre 2025, dans l'affaire C-413/23 P, la CJUE a précisé, sous le règlement (UE) 2018/1725 applicable aux institutions et organes de l'Union, que des données pseudonymisées peuvent ne pas être personnelles pour un destinataire dépourvu de moyens raisonnables d'identifier les personnes. L'obligation d'information du responsable initial s'apprécie, elle, au moment de la collecte et de son point de vue. Cet arrêt n'autorise pas à envoyer n'importe quel texte masqué à une IA.

En France, le Conseil d'État, le 13 février 2026, n° 498628 et affaires jointes, a rejeté les recours concernant les bases THIN et « Gers Études clients ». Les parcours pouvaient être individualisés avec des outils courants, comme un tableur, et des recoupements permettaient de lever le pseudonymat avec des moyens raisonnables.

Pour un projet IA, notre lecture pratique est la suivante : documenter les données réellement envoyées, les informations complémentaires accessibles au destinataire et les garanties opposables. L'absence du nom dans le prompt n'est que le début de l'examen.

Des sanctions concrètes lorsque l'anonymat ne tient pas

Les trois affaires ci-dessous concernent des bases de données de santé. Ce ne sont pas des sanctions pour utilisation de ChatGPT. Elles éclairent, par analogie, le risque d'écarter des obligations en qualifiant trop vite des données d'anonymes. Les montants sanctionnent plusieurs manquements.

Le cas italien illustre une vérification essentielle pour les prompts : tester les textes libres, les pièces jointes et leurs métadonnées, pas seulement les colonnes « nom » et « prénom ». Pour un établissement, le livrable utile est une analyse documentée des risques de réidentification et des obligations qui restent applicables.

Ce qu'une passerelle d'IA voit réellement

Une passerelle peut contrôler les requêtes qu'elle reçoit, appliquer une règle, bloquer ou demander une validation humaine et conserver une trace. Ces possibilités dépendent des détecteurs, du paramétrage et des intégrations. Un appareil ou un compte personnel qui la contourne ne devient pas automatiquement visible.

Le contrôle technique doit aussi s'inscrire dans un cadre juridique : finalité, base légale, condition de traitement des données de santé, secret professionnel, destinataires, contrats et éventuels transferts. La CNIL recommande d'examiner ces conditions de déploiement. Un masquage peut réduire un risque ; il ne répond pas à toutes ces questions.

Six questions que le DPO et le RSSI doivent poser

Avant d'équiper les équipes, demander une démonstration sur des données de test représentatives et conserver les réponses.

Ce contrôle doit aussi être articulé avec l'article 4 du règlement IA, dans sa version consolidée au 27 juillet 2026. Les fournisseurs et déployeurs doivent prendre des mesures pour soutenir le développement de la maîtrise de l'IA de leur personnel et des autres personnes utilisant des systèmes d'IA pour leur compte, en tenant compte du contexte, des connaissances, de l'expérience, de l'éducation et de la formation. Le texte précise que cette obligation n'exige pas de garantir un niveau spécifique de maîtrise de l'IA à chaque individu. L'article 4 s'applique depuis le 2 février 2025.

1. Quels outils, comptes, extensions et appareils sont couverts ? Quels usages échappent au dispositif ?
2. Quelles données sont détectées, y compris les identifiants indirects, textes libres et pièces jointes ? Quels résultats et erreurs ont été mesurés ?
3. Quelle transformation est réalisée ? Qui détient les informations supplémentaires et quels recoupements restent possibles pour le destinataire ?
4. Quelles règles autorisent, transforment, bloquent ou soumettent la requête à validation ? Qui approuve les exceptions ?
5. Quelles preuves peut-on exporter : décision, règle appliquée, version de la politique et validation humaine ? Les traces évitent-elles de recopier inutilement les données sensibles ?
6. Que se passe-t-il si le détecteur échoue, si une information manque ou si la validation attendue n'arrive pas ?

Passer de l'inventaire aux décisions démontrables

Le travail commence par les usages réels : ce que les équipes font, les données qu'elles transmettent et les outils qu'elles peuvent raisonnablement adopter. Il se poursuit par des règles compréhensibles, une formation adaptée et des contrôles dont on connaît le périmètre.

Les DPO de la Santé accompagnent ce cadrage juridique et opérationnel : cartographie des usages, qualification des données et des rôles, règles internes, analyse des prestataires, mesures de sécurité et éléments de preuve à conserver.

L'objectif de l'échange est d'identifier vos usages prioritaires, les données à protéger et les mesures à vérifier avant déploiement, afin de prendre des décisions documentées sur des éléments concrets.