Pourquoi les secteurs réglementés ne peuvent pas ajouter la confidentialité à leurs projets d’IA après coup

Une responsable conformité d’une banque régionale de taille moyenne assiste à la démonstration d’un chatbot IA, et sa première question n’est pas « est-ce que ça fonctionne ? » mais bien « où vont les données de nos clients ? » Cet instinct, décrit dans un article d’analyse de David Balaban publié sur SC World, est le bon réflexe. Pourtant, trop d’organisations dans la finance, la santé et l’assurance l’ignorent encore lors du lancement de leurs projets pilotes IA.

L’argument de Balaban est simple, mais il dérange dans les secteurs réglementés : la protection de la vie privée ne peut pas être reléguée à une seconde phase dans les projets IA. Un commerçant qui divulgue par erreur des informations personnelles identifiables (PII) peut corriger le bug lors du prochain sprint et passer à autre chose. Un hôpital qui applique la même méthode s’expose à une violation HIPAA, à des obligations de notification de violation et à une réunion du conseil d’administration pour comprendre comment cela a pu arriver. Les enjeux ne sont pas symétriques, et traiter un pilote IA comme un simple déploiement logiciel revient à ignorer cette réalité.

Il n’y a pas eu de fuite, d’incident ni de sanction officielle à l’origine de cet article, il s’agit d’une réflexion stratégique, pas d’une étude de cas. Ce qui retient l’attention de Kiteworks, c’est la pertinence du sujet : l’article aborde la cartographie des flux de données, la politique de conservation, les registres d’accès et le cadre de gestion des risques IA du NIST, en s’appuyant sur le RGPD et HIPAA pour illustrer les enjeux financiers et réglementaires. Ce sont précisément les deux cadres auxquels Kiteworks est certifié, et les recommandations de l’article correspondent à la façon dont une couche de données gouvernée doit fonctionner en pratique.

Dans cet article, nous revenons sur l’argumentaire de Balaban, vérifions le seul chiffre clé cité, et faisons le lien entre ses recommandations — cartographier les données avant l’entraînement, filtrer les PII, maintenir l’intervention humaine dans les décisions réglementées et tester de façon proactive — et ce qu’un responsable conformité ou un RSSI doit attendre d’un échange de données sécurisé Kiteworks pour accompagner les initiatives IA dans un environnement réglementé.

À retenir

1. La protection de la vie privée doit être intégrée dès la conception, pas ajoutée après coup.

Les organisations des secteurs financier, de la santé et de l’assurance sont soumises à des obligations de notification de violation, à la vigilance des régulateurs et à des remontées au conseil d’administration qu’un simple bug logiciel ne déclenche jamais. Les décisions sur la gestion des données IA doivent donc être prises avant même la rédaction du premier prompt, et non après réception d’une plainte.

2. Les LLM ne distinguent pas les données protégées du texte ordinaire.

Pour un modèle, les journaux d’entraînement, les transcriptions de chat, les tickets de support et les tableurs non nettoyés sont tous des tokens. Seule l’hygiène des données de l’organisation, et non le jugement du modèle, fait barrière entre un jeu d’entraînement et une violation de conformité.

3. Les auditeurs attendent trois éléments précis : un schéma des flux de données, une politique de conservation documentée et des registres d’accès.

Des promesses vagues sur « l’IA responsable » ne suffisent pas à un évaluateur. Pouvoir fournir ces trois éléments à la demande constitue le vrai standard, et le cadre de gestion des risques IA du NIST offre un vocabulaire commun pour les construire.

4. La responsabilité réglementaire ne se transfère pas au fournisseur IA.

Le RGPD, l’AI Act européen et l’historique des sanctions de la FTC considèrent que c’est l’organisation déployant l’IA, et non le fournisseur du modèle, qui est responsable de l’utilisation des données. Un abonnement à un outil IA tiers ne déplace pas cette responsabilité.

5. La gouvernance doit couvrir l’accès humain et agent IA sous une seule politique, pas deux.

Toute initiative IA traitant des données réglementées doit appliquer les mêmes contrôles d’accès, règles de conservation et journaux d’audit, que la requête soit faite par une personne ou un agent IA.

La première question du responsable conformité : où vont les données de nos clients ?

La scène d’ouverture de Balaban mérite réflexion. Un responsable conformité de banque assiste à une démo de chatbot et s’inquiète d’abord de la destination des données, avant de s’intéresser à la fonctionnalité. Ce n’est pas de la paranoïa, c’est son métier. Dans les secteurs réglementés, « est-ce que ça marche » relève du produit. « Où vont les données » est une question juridique et de réputation, à traiter avant même la question produit, car la réponse conditionne l’existence même du pilote.

C’est ce profil que Kiteworks cible par défaut : le RSSI ou son adjoint, responsable du risque IA quel que soit le porteur du projet, et le Chief Compliance Officer ou responsable GRC, garant du dossier de preuves en cas de contrôle. Ces rôles n’ont que faire de l’assurance d’un fournisseur que « le modèle se comporte bien ». Ce qu’ils attendent, ce sont des contrôles d’accès, une gouvernance des données documentée, et une traçabilité prête à être remise à un examinateur sans panique de dernière minute.

Pourquoi la finance, la santé et l’assurance ne peuvent pas corriger a posteriori un échec de confidentialité IA

Le contraste souligné par Balaban est limpide : un commerçant qui expose des PII corrige la faille et déploie un correctif au sprint suivant. Un hôpital qui procède ainsi fait face à une violation HIPAA, à des notifications obligatoires et à un conseil d’administration qui veut savoir pourquoi personne n’a anticipé le problème. Les assureurs et établissements financiers sont logés à la même enseigne : GLBA, régulateurs d’assurance et superviseurs bancaires traitent les données financières et de santé avec un sérieux bien supérieur à l’historique d’achats d’un programme de fidélité.

C’est tout l’argument en faveur d’une prise en compte de la confidentialité dès le départ. Ce n’est pas que les organisations réglementées avancent plus lentement par prudence, c’est que le coût d’un échec de confidentialité dans ces secteurs est d’un tout autre ordre, et qu’aucune correction post-déploiement ne permet de rattraper le temps de notification, l’attention du régulateur ou la confiance du client. L’expertise conformité de Kiteworks, son autorisation FedRAMP Moderate, son chiffrement validé FIPS 140-3 et ses options de déploiement à locataire unique existent précisément parce que ce type d’acheteur exige des preuves, pas des promesses, avant que les données n’atteignent le modèle.

Les LLM sont voraces : comment l’ingestion des données d’entraînement expose les PHI et PII

La métaphore des grands modèles de langage « voraces » employée par Balaban illustre bien un vrai problème technique. Les LLM absorbent journaux d’entraînement, transcriptions de chat, tickets de support et tableurs non nettoyés, sans aucun étiquetage. Comme il le dit, aucune de ces données ne « sait » qu’il s’agit d’informations médicales protégées ou d’un numéro de sécurité sociale, ce ne sont que des tokens pour le modèle. Le modèle n’a aucune notion intrinsèque de la classification PHI ou PII, ce jugement doit intervenir avant l’ingestion, pas pendant.

C’est pourquoi la classification des données et la gouvernance des accès doivent se situer en amont du modèle, pas à l’intérieur. Si un ticket de support contenant un numéro de compte client et un code diagnostic est intégré à un jeu de fine-tuning parce que personne n’a cartographié où il était stocké ni qui pouvait y accéder, le modèle a déjà appris ce qu’il n’aurait jamais dû savoir, et il n’existe aucun moyen fiable de le lui faire « désapprendre ». La classification des données et la minimisation des données ne sont pas des options dans un projet IA : ce sont les seuls mécanismes qui préviennent ce type d’exposition en amont.

Cartographier les flux de données avant d’écrire un prompt

Le conseil pratique de Balaban : cartographier les flux de données avant même d’écrire un prompt. Où résident les données, qui peut les interroger, le fournisseur conserve-t-il les logs de conversation pour l’entraînement, et pour combien de temps ? Ce sont des questions de base, et le fait qu’elles prennent encore les équipes au dépourvu en dit long sur la façon dont les pilotes IA sont souvent lancés, avec une logique de preuve de concept qui fait l’impasse sur la rigueur exigée d’un projet de données en production.

Un schéma de flux de données n’est pas un diagramme pour la forme. C’est l’artefact qui permet à l’équipe conformité de répondre précisément : quels systèmes une fonction IA touche-t-elle, lesquels contiennent des données réglementées, et que devient une requête ou un document une fois sorti du périmètre de l’organisation. Sans cette cartographie, « nous pensons que le fournisseur ne conserve pas nos données » relève de l’espoir, pas d’un contrôle. Les principes du Zero trust data exchange — vérifier chaque demande d’accès, journaliser chaque transaction, ne jamais accorder la confiance sur la seule base de la localisation réseau — offrent une méthode concrète pour bâtir cette cartographie, au lieu de se contenter de suppositions.

Ce que les auditeurs attendent vraiment : schémas de flux, politiques de conservation et registres d’accès

Balaban est précis sur les attentes des auditeurs : un schéma des flux de données, une politique de conservation documentée et des registres d’accès. La liste est courte, mais chaque élément doit pouvoir être produit à la demande, dans un format lisible et vérifiable par un évaluateur externe, et non reconstruit dans l’urgence après réception de l’avis d’audit.

Les registres d’accès sont souvent le point faible des pilotes IA. Si une organisation ne peut pas répondre clairement à « qui a interrogé ce système IA, quand, et avec quelles données », peu importe la robustesse des garde-fous du modèle, le simple manque de preuve devient une non-conformité. C’est le problème typique du Chief Compliance Officer : disposer d’une traçabilité qui existe techniquement dans un fichier log n’a rien à voir avec une preuve exploitable, produite dans les délais du régulateur et non des semaines après la demande.

Le cadre de gestion des risques IA du NIST comme langage commun

Balaban cite le pendant IA de la famille NIST CSF, le cadre de gestion des risques IA du NIST, comme outil permettant aux équipes juridiques, sécurité, data science et achats de partager un vocabulaire commun sur le risque IA. Cette approche est validée : les fonctions « Gouverner, Cartographier, Mesurer, Gérer » du cadre IA RMF sont conçues pour offrir aux équipes transverses, ainsi qu’aux auditeurs et régulateurs, une structure commune pour décrire les contrôles existants et leur justification.

Il est important de préciser ce que ce cadre est — et n’est pas. Le cadre IA RMF du NIST est volontaire, il ne s’agit pas d’une certification ; aucune entreprise n’est auditée « selon » ce référentiel comme un C3PAO le ferait pour la conformité CMMC. Sa valeur, ici, réside exactement dans ce que décrit Balaban : un langage commun pour le schéma de flux et le registre des risques, et non une case à cocher de conformité.

Quatre pratiques qui distinguent les organisations qui réussissent leurs audits IA

Balaban liste quatre pratiques qui séparent les organisations qui passent les audits IA de celles qui échouent :

1. Cartographier chaque source de données avant l’entraînement. Identifier les systèmes qui alimentent le modèle et ceux qui contiennent des données réglementées avant le premier entraînement, pas après une question en revue.
2. Filtrer les jeux d’entraînement à la recherche de PII avec des outils dédiés. Balaban cite Microsoft Presidio et AWS Macie comme exemples d’outils conçus pour détecter les données personnelles cachées dans un corpus d’entraînement.
3. Maintenir l’humain dans la boucle pour les décisions réglementées. Les décisions de crédit, d’indemnisation ou d’aide au diagnostic doivent intégrer une étape de revue humaine, avec possibilité d’outrepasser la sortie du modèle, et non être entièrement automatisées.
4. Tester les modèles avec des prompts adverses. Chercher activement à faire fuiter des données que le modèle ne devrait pas connaître, avant qu’un chercheur externe ou un client curieux ne le fasse à votre place.

Aucune de ces pratiques n’est exotique. Ce qui est frappant, c’est la corrélation entre leur absence et les organisations qui finissent par devoir expliquer une faille à un régulateur, plutôt que de démontrer un contrôle déjà en place.

La responsabilité ne se transfère pas avec un abonnement : RGPD, AI Act et FTC

L’article de Balaban s’appuie sur deux cadres réglementaires pour illustrer concrètement la question de la responsabilité, et les deux résistent à l’analyse. Selon le RGPD et l’AI Act européen, les régulateurs ont clairement établi ce que Balaban énonce : la responsabilité ne se transfère pas par l’achat d’un abonnement. Acheter un outil IA chez un fournisseur ne rend pas ce dernier responsable de l’utilisation des données de l’organisation déployant la solution, c’est toujours cette dernière qui l’est.

Il cite aussi la Federal Trade Commission américaine, qui a déjà sanctionné des entreprises pour avoir réutilisé discrètement des données clients à des fins d’entraînement de modèles sans consentement. Ce constat s’inscrit dans une tendance plus large : la FTC a poursuivi plusieurs sociétés ces dernières années pour avoir entraîné des IA ou construit des profils à partir de données collectées sous d’autres conditions que celles utilisées ensuite pour l’entraînement, et a exigé la suppression des données et des modèles comme mesure corrective à plusieurs reprises.

Le seul chiffre précis de l’article concerne le plafond légal du RGPD : les amendes peuvent atteindre 4 % du chiffre d’affaires mondial annuel. Cette information est juste, avec une nuance importante : le texte du RGPD fixe le plafond supérieur à 20 millions d’euros ou 4 % du chiffre d’affaires mondial de l’exercice précédent, le montant le plus élevé étant retenu, et non le « revenu ». Les deux termes sont souvent confondus dans les commentaires, mais l’essentiel reste : pour une banque, un groupe de santé ou un assureur international, 4 % du chiffre d’affaires mondial dépasse largement le plafond fixe et attire forcément l’attention du conseil d’administration.

Gouverner l’accès aux données pour humains et agents IA sous un même plan de contrôle

Toutes les pratiques recommandées par Balaban partent d’un constat que les secteurs réglementés doivent désormais énoncer explicitement : les mêmes règles d’accès, limites de conservation et exigences de journalisation s’appliquent, que l’entité interrogeant les données réglementées soit une personne ou un agent IA. HIPAA ne fait pas de distinction entre un analyste humain ou un agent IA consultant un dossier patient sans autorisation, la violation reste la même. Le principe de responsabilité du RGPD ne s’assouplit pas parce qu’un agent, et non un salarié, a accédé aux données.

C’est la logique de l’approche Kiteworks Control Plane pour la gouvernance IA : une couche de politique unique pour l’accès, l’utilisation et l’échange des données, applicable aux humains comme aux agents IA, et non une politique humaine à laquelle on ajoute une exception IA après coup. Parler d’une gouvernance « étendue » aux agents laisse entendre qu’ils étaient auparavant hors de tout cadre, ce qui est une erreur de conception. Le bon modèle, c’est un ensemble unique de règles — qui peut voir quelles données, dans quelles conditions, avec quelle traçabilité — applicable dès le départ aux utilisateurs humains comme aux agents IA.

Comment Kiteworks comble l’écart entre ambition IA et réalité réglementaire

Les recommandations de Balaban — cartographier les données avant l’entraînement, filtrer les PII, maintenir l’humain dans les décisions réglementées, tester de façon proactive, produire schéma de flux, politique de conservation et registres d’accès à la demande — décrivent des résultats attendus. Mais elles ne disent pas comment industrialiser ces résultats à grande échelle, pour des dizaines d’initiatives IA et d’unités métier.

C’est là que deux fonctions spécifiques de Kiteworks rejoignent l’argumentaire de l’article. Kiteworks Compliant AI définit les contenus qu’un système IA est autorisé à consulter et applique cette politique au moment de la requête, sans dépendre du modèle lui-même ou d’un nettoyage a posteriori pour filtrer les données protégées. C’est la réponse architecturale au problème d’ingestion de Balaban : si le système IA ne peut pas récupérer de PHI ou de PII non nettoyées, il n’y a rien à « désapprendre » ensuite.

Côté audit, le Control Plane de Kiteworks produit le journal unifié et les registres d’accès qui répondent exactement à ce que les auditeurs attendent : une trace de qui a accédé à quoi, quand, et sous quelle politique, consolidée sur la messagerie électronique, le partage, le transfert de fichiers et l’accès IA, au lieu d’être éparpillée dans une douzaine de logs disparates. Le programme de conformité de Kiteworks couvre les exigences de conformité HIPAA et de conformité RGPD, les deux régimes utilisés par Balaban pour illustrer les enjeux, et inclut l’autorisation FedRAMP, l’attestation SOC 2 Type II et des contrôles alignés sur ISO 27001, étendus à NIS2 et DORA. Pour un responsable conformité dont la première question sur tout pilote IA est « où vont nos données », c’est la réponse qui doit exister avant le lancement, pas après la demande d’un examinateur.

Pour en savoir plus sur la cartographie des flux de données IA, la production de registres d’accès exploitables comme preuves et la gouvernance des accès agents IA et humains sous HIPAA et RGPD, réservez une démo personnalisée dès maintenant.

Ressources complémentaires

• Article de blog
  Stratégies Zero Trust pour une protection abordable de la vie privée en IA
• Article de blog
  Comment 77 % des organisations échouent à sécuriser les données IA
• eBook
  L’écart 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 savoir si vous avez une politique IA. Ils veulent des preuves de son efficacité.