Un salarié copie-colle un fichier client dans un chatbot. Quelques semaines plus tard, ces données réapparaissent chez un concurrent. Qui paie la note — l'employé, l'entreprise, l'éditeur de l'IA, ou personne ?
En Europe, la réponse n'est plus une zone grise. Le RGPD fixe l'essentiel de la responsabilité, l'AI Act y ajoute une obligation générale de littératie IA (et des règles bien plus strictes pour les usages à haut risque), et la directive NIS2 étend l'exigence de sécurité à toute la chaîne d'outils numériques, y compris l'IA. Voici de quoi éclairer un risque juridique et financier que la plupart des entreprises sous-estiment encore.
L'histoire est devenue un classique dans les comités de direction.
Dans une PME, un commercial utilise un assistant IA grand public pour affiner une proposition commerciale. Il y injecte un fichier contenant des noms de clients, des montants de contrats et des commentaires internes. L'outil, configuré par défaut, absorbe ces données pour alimenter ses modèles.
Un mois plus tard, un concurrent interroge le même outil sur son marché. La réponse de l'IA inclut des extraits identifiables du fichier d'origine.
En interne, le dialogue de sourds s'installe :
"Comment cela a-t-il pu arriver ?" demande la direction. "Cet outil n'a jamais été validé ni sécurisé par nos services," répond la DSI. "Nous sommes en violation du RGPD, et probablement de notre obligation de littératie IA," ajoute le juridique. "Faut-il sanctionner le collaborateur ?" s'interroge les RH.
La question centrale n'est pourtant pas de savoir qui a cliqué sur "Envoyer", mais qui porte la responsabilité légale de cette faille.
En bref — qui est responsable en cas de fuite de données sur une IA ?
En Europe, la responsabilité légale incombe en priorité à l'entreprise, au titre du RGPD : c'est elle qui doit garantir la sécurité des données qu'elle traite (Art. 5, 24 et 32) et notifier toute violation sous 72 heures (Art. 33). L'AI Act ajoute une obligation générale de littératie IA pesant sur l'entreprise et sur l'éditeur (Art. 4), et impose des règles beaucoup plus strictes — traçabilité, supervision humaine, journalisation — mais uniquement lorsque l'entreprise déploie un système d'IA classé "à haut risque" (Art. 26). L'éditeur de l'outil grand public, lui, n'est responsable que de la sécurité de son propre système ; ses conditions d'utilisation excluent en général toute responsabilité pour les données que l'utilisateur choisit d'y saisir. Le salarié, sauf faute lourde ou intentionnelle, n'engage pas sa responsabilité personnelle envers les tiers.
Le RGPD est le socle de la responsabilité, dans la quasi-totalité des cas. C'est le texte qui s'applique en premier, presque systématiquement, dès qu'une donnée personnelle transite par un outil IA. Un fichier client copié dans un chatbot déclenche immédiatement l'obligation de notifier la CNIL (ou l'autorité européenne compétente) sous 72 heures, l'information des personnes concernées si le risque pour elles est élevé, et une amende potentielle allant jusqu'à 4 % du chiffre d'affaires mondial ou 20 millions d'euros, selon le montant le plus élevé. Le RGPD ne demande pas seulement de réagir après coup : son article 32 exige de prévenir en mettant en œuvre des mesures techniques et organisationnelles appropriées au risque — c'est précisément ce que les régulateurs regardent en premier après un incident.
L'AI Act est souvent cité de travers dans ce genre de scénario — y compris sur des contenus par ailleurs bien informés. Il faut distinguer deux niveaux. L'article 4, sur la littératie IA, s'applique à tous, quel que soit le système : fournisseurs comme déployeurs doivent garantir un niveau suffisant de compréhension de l'IA chez leurs équipes. C'est le seul volet de l'AI Act qui concerne systématiquement un usage grand public de chatbot. Les articles 9 et 26, sur la gestion des risques et les obligations du déployeur, sont réservés aux systèmes "à haut risque" au sens de l'Annexe III — recrutement, notation de crédit, identification biométrique, infrastructures critiques. Ces articles imposent traçabilité, supervision humaine et conservation des logs pendant six mois, mais uniquement si l'entreprise déploie ce type de système. Un chatbot généraliste utilisé pour rédiger une proposition commerciale n'entre en général pas dans ce périmètre. Autrement dit, pour l'immense majorité des fuites de données via des IA génératives grand public, ce n'est pas l'AI Act qui construit la responsabilité de l'entreprise — c'est le RGPD. L'AI Act n'ajoute que l'obligation de littératie (Art. 4), plus les règles renforcées si l'entreprise se trouve, par ailleurs, à déployer un système à haut risque. Attention également aux conditions d'utilisation des outils grand public ou gratuits : elles excluent presque systématiquement toute responsabilité de l'éditeur en cas de fuite causée par les données que l'utilisateur choisit d'y saisir.
Pour les entités essentielles ou importantes (énergie, santé, finance, transports, numérique, et d'autres secteurs listés par le texte), NIS2 impose une gestion des risques cyber sur l'ensemble de la chaîne d'approvisionnement — ce qui inclut les outils IA tiers utilisés par les salariés, y compris hors du système d'information officiel de l'entreprise.
Le salarié doit respecter la charte interne et les règles de littératie IA de l'article 4 — son risque se limite à une sanction disciplinaire interne, la responsabilité personnelle n'intervenant qu'en cas de faute lourde ou intentionnelle. L'entreprise doit sécuriser les données (articles 5, 24, 32 du RGPD), former ses équipes (article 4 de l'AI Act) et encadrer le haut risque le cas échéant (article 26) — elle s'expose à des amendes RGPD pouvant atteindre 4 % du chiffre d'affaires mondial, à une atteinte à sa réputation et à une mise en cause devant la CNIL. L'éditeur de l'IA doit sécuriser son système, avec des obligations renforcées s'il fournit un système à haut risque ou un modèle à usage général (articles 9 et 53) — sa responsabilité reste limitée par ses CGU sur les usages grand public, mais peut être bien plus engagée sur une offre entreprise.
Pour se couvrir, la majorité des entreprises rédigent une charte informatique et organisent des formations à la littératie IA. C'est une obligation légale (article 4 de l'AI Act) et une bonne pratique — mais c'est insuffisant à elle seule.
En cas de contrôle de la CNIL ou de contentieux, prouver que vous avez "demandé aux salariés de faire attention" ne suffit pas si vous ne pouvez pas démontrer avoir mis en place des mesures techniques et organisationnelles appropriées au sens de l'article 32 du RGPD — c'est-à-dire un contrôle réel à la source, pas seulement une politique sur papier.
L'erreur humaine est statistiquement inévitable. Compter uniquement sur la vigilance individuelle pour protéger vos secrets d'affaires revient à supprimer le pare-feu de votre réseau en demandant simplement aux salariés de ne pas cliquer sur les liens suspects.
C'est précisément pour combler cet écart entre la politique écrite et le contrôle réel que Miravig a été conçu.
Miravig s'interpose entre le poste de travail et l'IA générative, pour transformer une obligation déclarative en mesure technique vérifiable : il filtre en temps réel les données personnelles, identifiants, codes et montants stratégiques avant qu'ils ne quittent le poste du salarié — une mesure technique concrète au sens de l'article 32 du RGPD. Il conserve des registres d'usage locaux et une visibilité sur le shadow AI pour la DSI, pour documenter que des mesures ont été prises et, pour les entreprises qui déploient par ailleurs des systèmes à haut risque, contribuer aux exigences de traçabilité de l'article 26. Et il guide le salarié vers une meilleure formulation à la volée, en cohérence avec l'obligation de littératie de l'article 4, sans bloquer sa productivité.
Miravig ne supprime pas la responsabilité juridique de l'entreprise — personne ne le peut. Il donne les moyens de démontrer, preuves à l'appui, que les mesures attendues par le RGPD et l'AI Act ont été mises en œuvre avant qu'un incident ne survienne, plutôt qu'après.
Sauf cas d'espionnage industriel ou de violation délibérée et répétée des consignes de sécurité, la responsabilité civile et financière vis-à-vis des tiers incombe à l'employeur, pas au salarié agissant dans le cadre de ses fonctions.
Partiellement. Elles réduisent généralement l'utilisation de vos données pour l'entraînement des modèles, mais elles n'empêchent pas l'envoi de données confidentielles vers des serveurs tiers et ne fournissent pas, à elles seules, les registres d'usage qu'un contrôle RGPD ou AI Act peut exiger de l'entreprise.
Dans la plupart des cas, non : l'article 26 ne s'applique qu'aux entreprises qui déploient un système d'IA classé "à haut risque" au sens de l'Annexe III (recrutement, scoring, biométrie, etc.). Un usage bureautique courant d'un chatbot reste avant tout encadré par le RGPD et par l'obligation générale de littératie IA (art. 4).
Il vérifie si l'entreprise avait mis en place des mesures techniques et organisationnelles appropriées (analyse d'impact, filtres de sécurité, politique d'accès) pour prévenir l'incident. L'absence de barrières techniques réelles est traitée comme un défaut de prévoyance, indépendamment de l'existence d'une charte interne.
La responsabilité de la donnée ne se délègue pas — mais les moyens de la démontrer, si. Dans l'immense majorité des fuites de données via l'IA, c'est le RGPD qui porte le poids de la responsabilité, pas l'AI Act, dont la seule obligation vraiment systématique reste la littératie IA de l'article 4. Une charte et une session de formation couvrent une partie de cette obligation, mais les régulateurs cherchent un vrai contrôle technique à la source. C'est précisément l'écart qu'un outil positionné avant le départ de la donnée cherche à combler — non pas remplacer la responsabilité de l'entreprise, mais lui donner de quoi la démontrer.
Vérifier un texte avant de l'envoyer — Miravig repère les données identifiantes et sensibles dans un prompt avant qu'il ne parte, avec une analyse locale, sans compte et sans transmission serveur. Essayer gratuitement →