Un employé de RIZAP a téléversé les dossiers de santé de 726 personnes dans un chatbot IA personnel.

Le 20 août 2026, un salarié de RIZAP Inc., le groupe japonais de fitness et d'accompagnement santé, extrayait des enregistrements du système de gestion de l'accompagnement santé qu'elle exploite pour les assureurs lorsque les données ont été versées dans un service d'IA générative sur un compte personnel que l'entreprise n'avait jamais autorisé. Les enregistrements concernaient 726 adhérents de la Mutuelle des agents des collectivités locales (地方職員共済組合), répartis sur quatorze antennes régionales, et comprenaient des noms, des dates de naissance, les symboles et numéros des cartes d'assurance, ainsi que les catégories de maladies hypertension, diabète et dyslipidémie — des données personnelles sensibles au sens de la loi japonaise sur la protection des informations personnelles. L'association a publié sa notification le 4 septembre 2026. Ce cas figure parmi les incidents documentés dans l'archive d'incidents Orca AI, qui répertorie chaque entrée avec ses propres sources, son niveau de gravité, son degré de confiance et son indicateur de contestation.

Il ne s’agissait pas d’une violation au sens habituel. Aucun attaquant, aucun identifiant compromis, aucune vulnérabilité exploitée. Une personne effectuant un travail d’agrégation de routine a choisi le mauvais outil, et les données des adhérents d’un assureur santé — y compris la catégorie que le droit japonais considère comme exigeant le traitement le plus strict — ont quitté les locaux par un onglet de navigateur dont personne dans l’entreprise ne savait qu’il existait. L’archive classe cet enregistrement à son niveau de confiance le plus élevé, lui attribue une gravité élevée, consigne un préjudice réel et ne le signale pas comme contesté, et les deux parties qui ont publié des notifications s’accordent sur le mécanisme. Ce qui suit distingue ce que ces notifications établissent de ce qui repose sur les assurances du fournisseur lui-même.

Ce que RIZAP a réellement divulgué, et quand

Les excuses et l'avis de RIZAP portent la date du 3 septembre 2026. Ils situent l'incident dans la division des activités de gestion de la santé et d'assurance de l'entreprise et indiquent que l'employé travaillait sur l'agrégation de données pour le système spécifique de gestion des conseils en santé au moment du téléversement. L'employé utilisait un service d'IA générative à usage privé — formulation de l'entreprise — et non un compte d'entreprise. L'avis ne donne aucune date d'occurrence qui lui soit propre ; la date du 20 août, ainsi que le fait que l'employé ait lui-même signalé le téléversement, proviennent des avis des deux assureurs qui ont suivi.

Le périmètre décrit par RIZAP est un sous-ensemble des dossiers enregistrés dans ce système entre le 1er janvier et le 19 août 2026 : les personnes inscrites au programme spécifique d’accompagnement en matière de santé, que les assureurs japonais proposent aux membres jugés à risque de maladie liée au mode de vie. L’avis répertorie des informations personnelles ordinaires (symbole et numéro de la carte d’assurance, adresse e-mail, nom, date de naissance, sexe et, pour certaines personnes, une adresse et un numéro de téléphone) et, séparément, deux catégories d’informations personnelles sensibles : la forme d’accompagnement en matière de santé dont la personne bénéficiait, et les informations sur les maladies pour toute personne enregistrée comme souffrant d’hypertension, de diabète ou de dyslipidémie. Il indique que les numéros de carte de crédit, les coordonnées bancaires et les identifiants de connexion ne figuraient pas parmi les données.

RIZAP indique avoir établi un rapport à l’intention de la Personal Information Protection Commission, l’autorité de régulation qui reçoit les notifications de certains incidents liés aux données personnelles en vertu de la Loi. Ni l’avis de RIZAP ni celui de l’association n’indique ce que la commission en a fait, et aucune conclusion de la commission n’apparaît dans l’un ou l’autre document.

La date sous laquelle l’archive classe ce dossier est le 4 septembre 2026, et il s’agit de la date de publication propre à l’association, et non de celle de RIZAP. Les deux dates sont séparées d’un jour parce que l’entreprise a notifié en premier, et l’assureur dont les membres figuraient dans les données a rendu l’information publique le lendemain, lorsqu’il a également fait en sorte que le prestataire envoie un courriel aux personnes concernées. ITmedia NEWS a rapporté la notification de l’entreprise le 4 septembre à 11 h 33, heure locale.

D'où vient le nombre 726

RIZAP n’a pas publié de chiffre. Son avis décrit les données et la réponse, mais ne donne aucun nombre de personnes concernées, et le rapport d’ITmedia du 4 septembre indique clairement que l’entreprise n’en a pas divulgué. Le chiffre de 726 appartient à la Local Government Employees’ Mutual Aid Association, qui gère l’assurance maladie des fonctionnaires locaux et était l’un des assureurs ayant chargé RIZAP de dispenser le programme d’accompagnement.

Le communiqué de l'association du 4 septembre est plus détaillé que celui du prestataire : 726 personnes, réparties sur quatorze succursales — Iwate, Akita, Yamagata, Fukushima, Tochigi, Kanagawa, Fukui, Mie, Osaka, Tottori, Yamaguchi, Kagawa, Ehime et Kagoshima. Il fait remonter l'incident au 20 août, indique que le membre du personnel du prestataire a saisi les données dans un service que le prestataire n'avait pas autorisé et les a fait référencer, confirme que les données ont été supprimées de l'écran du service d'IA et qu'une demande de suppression a été adressée au fournisseur du service, et précise que RIZAP a envoyé un courriel aux personnes concernées à 10 h 00 le 4 septembre.

Deux petites différences entre les versions méritent d’être signalées plutôt que gommées. RIZAP appelle l’identifiant un symbole et numéro de carte d’assurance ; l’association l’appelle un symbole et numéro de membre. RIZAP énumère trois catégories de soutien en matière d’orientation sanitaire ; la notice de l’association en énumère deux, le soutien actif et le soutien motivationnel. Aucune de ces différences ne modifie la forme de l’incident, mais elles rappellent que les deux documents ont été rédigés par des organisations différentes pour des publics différents, et que le détail au niveau des membres provient de l’assureur, non de l’entreprise qui en a perdu le contrôle.

L’incident était plus étendu que le 726.

Étant donné que RIZAP n'a jamais fourni de total, l'ampleur de l'exposition ne peut être reconstituée qu'à partir des notifications des assureurs eux-mêmes, et les médias japonais spécialisés dans la sécurité s'y emploient précisément. Security Measures Lab (セキュリティ対策Lab), un site d'actualités japonais sur la sécurité, a compilé les notifications qu'il a pu vérifier et republié le chiffre qu'un assureur a attribué à l'ensemble du jeu de données : la National Health Insurance Association for Construction and Civil Engineering (全国土木建築国民健康保険組合) a déclaré que les données de 19 996 personnes avaient été saisies dans le service d'IA non approuvé et y avaient été consultées, dont 1 167 concernaient ses propres adhérents.

Ce chiffre doit être assorti de la réserve que le site lui-même y attache : il recense les personnes dont les données ont été saisies dans le service, et non celles dont il est confirmé que les informations ont atteint quelqu'un. Les autres chiffres publiés s'inscrivent dans celui-ci et ne doivent pas y être additionnés. La société d'assurance maladie du groupe IHI a cité 210 personnes dans un avis daté du 2 septembre. La société d'assurance maladie de Hitachi n'a publié aucun décompte mais a suspendu les nouvelles orientations vers le programme de conseil en santé de RIZAP jusqu'à ce qu'elle puisse vérifier que les mesures de prévention fonctionnent effectivement. Nippon Shokubai, Kansai Television Broadcasting, l'association d'entraide des employés municipaux de Gunma, la société d'assurance maladie des produits pétroliers, Unitika et Works Human Intelligence ont également publié des avis, la plupart sans chiffres.

Établi, attribué et toujours non confirmé

Établi par deux documents primaires indépendants.Le téléversement a eu lieu le 20 août 2026 lors de travaux d'agrégation de données ; le service concerné était l'un de ceux que le prestataire n'avait pas autorisés ; les données comprenaient des noms, des dates de naissance, des identifiants d'assureur et des informations de santé, notamment des catégories de maladies ; les membres concernés du régime de collectivité locale numéro 726 étaient répartis dans quatorze succursales ; RIZAP a signalé l'incident à la Commission de protection des informations personnelles ; un courriel a été envoyé aux membres concernés le 4 septembre.

Attribué à RIZAP, reposant sur les réponses de son fournisseur d'IA. Qu'aucun tiers extérieur au fournisseur d'IA n'aurait pu voir les données, et que les données n'ont pas servi à entraîner un modèle. L'avis de RIZAP en explique le fondement : le fournisseur a déclaré à l'entreprise que les fichiers contenant des informations identifiables ne sont jamais utilisés pour l'entraînement, même lorsqu'un compte l'autorise, et que les fichiers supprimés dans les 24 heures ne servent pas non plus à l'entraînement ; RIZAP affirme avoir supprimé les données dans ce délai. L'allégation est une assurance relayée, non un fait audité, et aucune partie indépendante ne l'a examinée.

Non confirmé au moment de la publication, de l’aveu même de l’entreprise. La question de savoir si le personnel propre au fournisseur d’IA aurait pu consulter les données téléversées. L’avis du 3 septembre de RIZAP indique que cela était encore en cours de vérification ; l’avis du 4 septembre de l’association indique que le prestataire attend la réponse du fournisseur. Au vu des documents, cette question reste ouverte — c’est pourquoi un lecteur devrait considérer « les données sont supprimées » et « personne ne les a vues » comme des affirmations différentes.

Nommé par un assureur, pas par le contractant. L’avis de la société d’assurance maladie du groupe IHI identifie OpenAI comme fournisseur de l’IA. RIZAP n’a pas nommé le service, et rien dans l’un ou l’autre des deux principaux avis ne confirme ni ne contredit les informations divulguées par IHI.

Nulle part allégué. Aucun attaquant, aucune extorsion, aucun usage abusif en aval, aucune preuve que les données d’un membre aient été utilisées contre lui. Les deux notifications mettent en garde les membres contre l’hameçonnage et indiquent toutes deux que RIZAP ne demandera jamais d’argent, de détails de carte, de numéros de compte ni de mots de passe — une précaution, et non le signalement d’une attaque.

Qu’est-ce qui a changé par la suite ?

RIZAP liste trois niveaux de réponse. Au niveau des personnes : une nouvelle notification à l’échelle de l’entreprise indiquant que les services d’IA générative non approuvés par l’entreprise ne peuvent pas être utilisés pour le travail, ainsi que la poursuite de la formation sur la protection des données personnelles et l’utilisation appropriée de l’IA. Au niveau des systèmes : un examen des autorisations d’accès et des environnements de travail afin d’empêcher l’extraction de données ou l’utilisation de services non approuvés. Au niveau de la gouvernance : l’étude d’un système de gestion de l’IA parallèlement à son système de gestion de la sécurité de l’information existant.

Les engagements de l’association vont dans l’autre sens, du côté du prestataire. Elle déclare qu’elle renforcera sa supervision de RIZAP et vérifiera que les mesures de prévention sont réellement mises en œuvre, et elle indique avoir demandé au prestataire une enquête plus approfondie sur les faits et l’ampleur de l’impact. La caisse d’assurance maladie de Hitachi est allée plus loin que les deux autres, en suspendant les nouvelles orientations jusqu’à ce qu’elle soit convaincue que les mesures tiennent.

Ce qui n'a pas changé, c'est le cadre réglementaire. Une notification à la Commission de protection des informations personnelles constitue une obligation de déclaration, non une décision, et aucune des deux notifications ne consigne d'instruction, d'orientation ou de sanction de sa part.

Pourquoi l’archive considère cela comme un jalon

La plupart des incidents d’IA connus publiquement impliquent un système qui fait quelque chose de travers. Celui-ci implique une personne faisant quelque chose d’ordinaire avec un système qui fonctionnait exactement comme prévu — ce qui constitue le problème plus difficile, car la défaillance est invisible pour l’organisation jusqu’à ce que les données aient quitté son périmètre. La catégorie à laquelle appartient cet incident est celle que les praticiens japonais appellent l’IA fantôme : des membres du personnel utilisant un service d’IA grand public pour le travail parce que c’est plus rapide que la voie approuvée, généralement sans malveillance et souvent avec l’intention de bien faire leur travail.

La source citée pour cet enregistrement, un site japonais d’explication en matière de sécurité, regroupe l’incident avec deux autres événements liés à l’IA de la même semaine — une fraude au paiement par clonage vocal et une intrusion par agent IA — et souligne que tous trois ont exploité des faiblesses qui existaient déjà plutôt que d’en créer de nouvelles. Cette formulation relève de l’analyse du site plutôt que d’un constat, mais la comparaison est pertinente : aucun des trois n’a exigé une capacité inédite, seulement une voie plus rapide vers une capacité préexistante.

Ce qui rend ce document digne d’être lu pour lui-même, c’est la précision du préjudice. Sept cent vingt-six personnes ont vu leurs identifiants d’assureur, leurs coordonnées et trois catégories de maladies nommées placés dans un compte d’IA grand public que le sous-traitant de leur assureur n’avait jamais approuvé, et la seule raison pour laquelle quelqu’un l’a découvert, c’est que l’employé qui l’a fait l’a dit. L’archive documente ici un préjudice réel. Ce que les deux notifications établissent, c’est l’exposition et la perte de contrôle sur des données sensibles — non pas que quelqu’un les ait utilisées.

Qu’est-ce qui corrobore le dossier, et qu’est-ce qui ne le corrobore pas ?

La note de confiance attribuée à cette fiche repose sur davantage que l'agrégateur cité par l'archive. Trois parties indépendantes ont publié dans les deux semaines suivant l'incident : RIZAP elle-même le 3 septembre, la Local Government Employees' Mutual Aid Association le 4 septembre, et ITmedia NEWS, qui a rapporté l'avis de l'entreprise le 4 septembre en précisant qu'aucun décompte n'avait été divulgué. La société d'assurance maladie du groupe IHI, celle de Hitachi et au moins six autres assureurs ont publié leurs propres avis, et Security Measures Lab les a compilés. Un blog japonais consacré aux archives d'incidents, b-son.net, reproduit intégralement le communiqué de l'association ainsi que son propre résumé.

Ce que rien de tout cela n’établit, c’est le total. RIZAP n’en a publié aucun, les chiffres des assureurs se chevauchent, et le chiffre de 19 996 est la déclaration d’un assureur à propos du jeu de données, plutôt qu’un décompte des expositions confirmées. Quiconque cite un chiffre unique pour cet incident devrait préciser de quel document il provient — c’est la discipline que l’archive elle-même applique à chacune des entrées qu’elle conserve.