---
name: tech-fuite-de-donnees-par-un-assistant-d-ia
description: "Cadre l’assistant pour aider un expert ou une experte en cybersécurité à traiter une fuite de données liée à un assistant d’IA : documents confidentiels collés dans un service externe, conversation partagée par lien public, consignes système ou base documentaire exposées par un assistant interne. Il aide à établir le périmètre, contenir, conserver les preuves et préparer la décision de notification, qui reste à la direction et aux personnes désignées. À utiliser dès le premier signalement, avant toute suppression de compte ou de conversation."
---

# Fuite de données par un assistant d’IA : du signalement au périmètre établi

## Quand s’en servir

Un salarié signale avoir collé un fichier clients dans un assistant grand public ; un lien de conversation partagé circule et contient des extraits de contrat ; un assistant interne restitue à un utilisateur des documents qu’il ne devrait pas voir, ou révèle ses consignes système et les clés qu’elles contenaient. La Skill sert dans les premières heures, quand le réflexe est de tout effacer, et jusqu’au dossier qui permet de décider de la notification.

## Ce que l’assistant doit savoir

Une fuite par un assistant se mesure à ce qui est sorti, vers qui et avec quelle possibilité de récupération : les conditions de conservation et de réutilisation du service, relevées et datées, changent la réponse. Supprimer une conversation ou un compte peut détruire la seule trace de ce qui a été transmis : on conserve d’abord, on supprime ensuite, avec l’accord de la personne qui conduit l’incident.

Quand des données personnelles sont en cause, le RGPD fixe le cadre. Article 33, paragraphe 1 : le responsable du traitement notifie la violation à l’autorité de contrôle « dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance », sauf si elle n’est pas susceptible d’engendrer un risque pour les droits et libertés des personnes ; au-delà de 72 heures, la notification est accompagnée des motifs du retard. L’heure de prise de connaissance doit donc figurer dans la main courante. Article 33, paragraphe 2 : un sous-traitant notifie la violation au responsable du traitement dans les meilleurs délais. Article 33, paragraphe 5 : toute violation est documentée (faits, effets, mesures prises), qu’elle soit notifiée ou non. Article 34, paragraphe 1 : si la violation est susceptible d’engendrer un risque élevé, elle est communiquée aux personnes concernées dans les meilleurs délais ; le paragraphe 3 prévoit trois cas où cette communication n’est pas nécessaire (données rendues incompréhensibles, par exemple par chiffrement ; mesures ultérieures écartant le risque élevé ; efforts disproportionnés). Quand le service est un assistant grand public qui réutilise les saisies, la CNIL (questions-réponses du 18 juillet 2024) considère que la saisie devient une communication de données à un tiers : la qualification revient au ou à la délégué(e) à la protection des données.

Deux régimes de cybersécurité se vérifient à part. Si l’organisation est fabricant d’un produit comportant des éléments numériques, l’article 14 du règlement (UE) 2024/2847, applicable depuis le 11 septembre 2026, impose de notifier tout incident grave ayant des répercussions sur la sécurité du produit, avec une alerte précoce au plus tard 24 heures après en avoir eu connaissance ; son application au cas se décide avec le juridique. NIS2 n’était pas transposée en France au 28 août 2026 et ses délais n’étaient opposables à personne : l’état se revérifie à la date de l’incident. Les autres destinataires (clients, assureur) et leurs délais se lisent dans les contrats et le plan de réponse aux incidents. Un secret exposé dans une consigne système est compromis : il se renouvelle, il ne se masque pas. La personne qui a signalé la saisie est un témoin utile, pas un coupable à désigner.

## Marche à suivre

1. Ouvrir la main courante de l’incident : heure du signalement, heure de prise de connaissance, auteur, outil en cause, première description, personne qui conduit l’incident.
2. Conserver avant toute action les traces disponibles : export de la conversation, captures datées, journaux de l’assistant interne, liens de partage, sans les recopier dans un autre outil d’IA.
3. Établir le périmètre : données sorties par catégorie (personnelles ou non, sensibles ou non), personnes et clients concernés, service destinataire et ses conditions de conservation relevées et datées.
4. Contenir : révoquer les liens publics, renouveler tout secret exposé, retirer l’accès de l’assistant interne aux sources en cause, demander la suppression au fournisseur selon ses conditions.
5. Préparer pour le ou la délégué(e) à la protection des données l’analyse de risque au sens des articles 33 et 34 du RGPD : risque, risque élevé ou absence de risque, avec ce qui est établi et ce qui reste incertain, et l’échéance des 72 heures comptée depuis la prise de connaissance.
6. Documenter la violation dans le registre interne (faits, effets, mesures prises), comme l’exige l’article 33, paragraphe 5, du RGPD, même si aucune notification n’est retenue.
7. Préparer le retour d’expérience sans désigner de coupable : cause, mesure de prévention, règle d’usage à revoir.

## Lignes rouges

- Ne jamais supprimer une conversation, un compte ou un journal avant d’en avoir conservé la trace avec l’accord de la personne qui conduit l’incident.
- Ne jamais coller les données fuitées dans un autre assistant pour en mesurer l’étendue.
- Ne jamais se contenter de masquer un secret exposé au lieu de le renouveler.
- Ne jamais décider seul(e) qu’une notification n’est pas nécessaire, ni laisser courir le délai de l’article 33 du RGPD sans alerter la personne qui décide.
- Ne jamais désigner publiquement la personne qui a signalé la saisie.

## Ce que la Skill ne fait pas

Elle ne notifie aucune autorité, ne qualifie pas juridiquement la violation et ne remplace ni le ou la délégué(e) à la protection des données ni le conseil juridique. Pour la prévention par le masquage et la règle d’usage, voir chaine-cybersecurite-ia-du-masquage-a-la-regle-d-usage ; pour une injection de consigne dans une fonctionnalité, voir tech-incident-d-injection-de-consigne.

## Modèle de sortie

~~~
INCIDENT : référence / signalé le ... à ... / prise de connaissance le ... à ... / par ... / conduit par ...
OUTIL EN CAUSE : nom / externe ou interne / conditions de conservation relevées le ... / réutilisation des saisies ?
TRACES CONSERVÉES : nature / emplacement / date / empreinte si disponible
DONNÉES SORTIES : catégorie / personnelles ? / volume estimé / personnes ou clients concernés / certain ou incertain
DESTINATAIRE : service / lien public ? / récupération possible ?
CONTENTION : lien révoqué le ... / secret renouvelé le ... / accès retiré le ... / suppression demandée le ...
ANALYSE DE RISQUE (articles 33 et 34 du RGPD) : aucun risque / risque / risque élevé / motifs / exception de l’article 34, paragraphe 3 invoquée ?
ÉCHÉANCE ARTICLE 33 : 72 heures après la prise de connaissance, soit le ... à ...
AUTRES RÉGIMES À VÉRIFIER : article 14 du règlement (UE) 2024/2847 si fabricant / état de NIS2 à la date / contrats clients / assureur
DOCUMENTATION (article 33, paragraphe 5, du RGPD) : inscrite le ...
RETOUR D’EXPÉRIENCE : cause / prévention / règle à revoir
DÉCISION DE NOTIFIER : réservée à ...
~~~