Les cadres dirigeants alimentent vos risques liés à l’IA fantôme

La plupart des programmes d’IA fantôme reposent sur une idée reçue : le risque viendrait des jeunes collaborateurs qui copient des données clients dans un chatbot gratuit pour gagner du temps avant une échéance. Les nouvelles données d’enquête prouvent le contraire. Ce sont les dirigeants qui contournent les règles, et ils le font à un rythme environ deux fois supérieur à celui de leurs équipes.

Une enquête menée par TrustedTech, partenaire Microsoft, relayée par CSOonline révèle que près des deux tiers des décideurs seniors reconnaissent utiliser des outils d’IA non approuvés, dits « fantômes », contre 31 % des employés de niveau inférieur. Cet écart doit amener les équipes en charge de cybersécurité à revoir leur approche de la gouvernance de l’IA. Il ne s’agit pas d’un simple problème de formation des nouvelles recrues. C’est un problème de comportement au niveau du management, et ce sont les dirigeants qui donnent le ton à l’ensemble de l’organisation.

Ce constat est d’autant plus difficile à ignorer que la même enquête montre que trois employés sur quatre comprennent déjà les risques de sécurité et de confidentialité liés à l’IA fantôme. Les utilisateurs ne se tournent pas vers des outils non autorisés par ignorance. Les dirigeants, qui connaissent mieux que quiconque le coût d’une violation de données pour l’entreprise, privilégient malgré tout la facilité à la prudence. Un autre rapport de Teramind vient renforcer ce constat : plus des deux tiers des cadres dirigeants déclarent privilégier la rapidité à la sécurité lorsqu’ils utilisent l’IA.

Pour une entreprise qui a investi des années dans la mise en place de programmes de gouvernance des données IA, de règles d’utilisation et de modules de formation, ce constat est inconfortable mais nécessaire. Les programmes de gouvernance qui partent du principe que le risque vient des collaborateurs de premier niveau visent la mauvaise cible. Ceux qui approuvent la politique IA sont souvent ceux qui la transgressent.

Résumé de l’article

1. Les dirigeants utilisent l’IA fantôme à un rythme environ deux fois supérieur à celui de leurs équipes.

Une enquête menée par TrustedTech, partenaire Microsoft, révèle que près des deux tiers des décideurs seniors reconnaissent utiliser des outils d’IA non approuvés, contre 31 % des employés de niveau inférieur.

2. La sensibilisation au risque n’est pas le problème — c’est le comportement qui l’est.

Dans la même enquête, trois employés sur quatre reconnaissent les risques de sécurité et de confidentialité liés à l’IA fantôme, mais l’usage de ces outils au sommet de l’organigramme continue d’augmenter.

3. La rapidité prime sur la sécurité dans les directions générales.

Selon Teramind, plus des deux tiers des cadres dirigeants privilégient la rapidité à la sécurité lorsqu’ils utilisent des outils d’IA au travail.

4. La majorité des activités IA en entreprise échappent déjà à la surveillance de la DSI.

Selon Teramind, deux tiers des activités IA en entreprise passent par des comptes personnels sur des plateformes déjà sous licence de l’entreprise : les outils sont donc approuvés, mais pas les comptes utilisés.

5. La politique seule ne suffit pas à corriger une habitude ancrée chez les dirigeants.

Pour combler cet écart, il faut gouverner l’accès des outils et agents IA au contenu sensible, en appliquant des contrôles au point d’accès plutôt que dans un module de formation que personne ne relit.

Ce que révèlent réellement les données TrustedTech et Teramind

Il est utile d’examiner les chiffres précis plutôt que de les considérer comme une simple tendance, car l’ampleur du phénomène dépasse souvent les prévisions des équipes en charge de cybersécurité.

Le constat de TrustedTech — près des deux tiers des décideurs seniors utilisent des outils d’IA non approuvés, contre 31 % des employés de niveau inférieur — n’est pas une simple marge d’erreur : c’est plus du double. Concrètement, ceux qui disposent des contrôles d’accès les plus larges, d’une vision globale sur les résultats financiers, les opérations de fusion-acquisition, la stratégie contentieuse et les plans produits confidentiels, sont aussi ceux qui transfèrent le plus souvent ces informations vers des outils jamais validés par la DSI. Les dirigeants ne manipulent pas des fichiers anodins. Ils gèrent ceux que le conseil d’administration réclamerait après une violation de données : contrats, documents de M&A, propriété intellectuelle, soit les contenus les plus critiques et à risque pour l’organisation.

Les recherches de Teramind précisent encore le tableau. Deux tiers des activités IA en entreprise passent par des comptes personnels sur des plateformes déjà sous licence de l’entreprise. Cette distinction est essentielle. Il ne s’agit pas principalement d’employés qui se tournent vers des startups IA obscures ou non licenciées. Bien souvent, il s’agit de personnes qui se connectent avec un compte personnel sur un outil que leur entreprise paie déjà dans le cadre d’un contrat d’entreprise, ce qui fait sauter les contrôles administrateur, la journalisation des accès et les règles de conservation des données prévues par la licence. L’entreprise a acheté la version gouvernée de l’outil. Le dirigeant utilise la version non gouvernée, sur la même plateforme, depuis le même ordinateur portable.

C’est précisément pour cette raison que la plupart des organisations ne savent toujours pas répondre à une question simple sur leur exposition à l’IA : quelle part de l’activité IA se déroule sur des comptes non gérés ? Ce n’est pas une nouvelle politique qui manque, mais de la visibilité. Une évaluation formelle des risques qui cartographie l’utilisation actuelle des outils IA, sur les comptes professionnels comme personnels — en quantifiant les catégories de contenu qui transitent par des connexions non gouvernées — fournit aux équipes en charge de cybersécurité la base factuelle nécessaire pour prioriser les investissements en gouvernance, plutôt que de réagir à la prochaine fuite.

Pourquoi les dirigeants contournent-ils les règles qu’ils ont eux-mêmes validées ?

Une question légitime se pose : pourquoi ceux qui ont validé la politique IA sont-ils aussi ceux qui l’ignorent le plus souvent ?

L’une des raisons tient à l’accès. Les dirigeants font face à moins d’obstacles pratiques pour utiliser l’outil de leur choix. Ils ne sont pas soumis aux mêmes restrictions de gestion de terminaux, de réseau ou de supervision managériale qu’un collaborateur intermédiaire. Si la politique repose sur la friction — un domaine bloqué, un téléchargement signalé, un manager attentif — les dirigeants sont souvent ceux pour qui cette friction est la plus faible.

L’autre raison concerne l’incitation. Les cadres supérieurs sont évalués sur les résultats : chiffre d’affaires, délais, positionnement concurrentiel. Un outil d’IA qui rédige une présentation pour le conseil d’administration en une nuit ou résume un dossier de due diligence en une après-midi est un compromis facile face à un risque abstrait et futur d’exposition de données. Le fait que plus des deux tiers des cadres dirigeants privilégient la rapidité à la sécurité, selon Teramind, n’a rien d’étonnant quand on considère ce pour quoi ils sont récompensés.

Enfin, il faut reconnaître que les politiques écrites n’influencent pas le comportement. Une politique d’utilisation peut lister précisément les outils autorisés ou non, mais un document ne peut empêcher quelqu’un d’ouvrir un compte personnel dans un onglet de navigateur. La formation à la sécurité peut encore augmenter le taux de sensibilisation, mais les chiffres de l’IA fantôme chez les dirigeants resteraient inchangés, car la sensibilisation n’a jamais été le vrai problème. Ce qui manque, c’est un contrôle qui s’applique quel que soit le compte, l’appareil ou la connexion utilisée. L’IA fantôme — une IA non gouvernée, totalement hors du périmètre de la politique d’entreprise — diffère structurellement d’une simple violation de politique par un employé identifié utilisant un outil connu ; elle reste invisible pour l’équipe sécurité tant que la gouvernance ne s’attache pas au contenu lui-même plutôt qu’à l’écran de connexion.

Le problème des comptes personnels : outils gouvernés, accès non gouverné

Le constat de Teramind sur les comptes personnels mérite une attention particulière, car il met en lumière une faille que la plupart des programmes de gouvernance IA ne sont pas conçus pour détecter.

Les équipes en charge de cybersécurité évaluent généralement le risque IA au niveau de l’outil : cette plateforme IA est-elle approuvée ou non, figure-t-elle sur la liste des fournisseurs autorisés, le service juridique a-t-il validé ses conditions de traitement des données ? Cette évaluation fonctionne si le risque est « un employé utilise un outil IA non validé ». Elle ne sert à rien si le risque est « un employé utilise un outil IA validé via un compte que l’entreprise ne gère pas ». L’outil passe la revue. Le compte contourne tous les contrôles censés s’y appliquer.

C’est pourquoi une gouvernance des données fondée sur des listes d’outils approuvés est nécessaire, mais insuffisante. Un contrat d’entreprise avec un fournisseur IA inclut généralement des engagements sur la localisation des données, des limites de conservation, des journaux d’audit au niveau administrateur, et la garantie que les données clients ne servent pas à l’entraînement des modèles. Un compte personnel sur la même plateforme n’offre rien de tout cela. Si, comme l’indique Teramind, deux tiers de l’activité IA en entreprise passent par des comptes personnels, cela signifie que deux tiers de cette activité échappent à toutes ces protections, alors même que l’entreprise les a négociées. Pour les organisations qui traitent des informations personnelles identifiables (PII), des informations médicales protégées (PHI) ou d’autres données réglementées, cette faille n’est pas seulement un problème de sécurité — c’est un manquement à la conformité réglementaire, qui sera exposé lors du prochain incident par les obligations de notification, d’audit et de contrôle des autorités compétentes.

La solution concrète n’est pas d’allonger la liste des domaines interdits. Il s’agit de contrôler en amont quels contenus sensibles peuvent atteindre un outil IA, indépendamment du compte utilisé. Si un moteur de politique se situe entre le contenu et la requête, et non entre l’employé et l’écran de connexion, peu importe que la demande vienne d’un compte professionnel ou personnel : le fichier sensible respecte la règle d’accès ou il ne la respecte pas. La classification des données appliquée au contenu d’entreprise avant tout accès par un outil IA est le prérequis pour une application précise de ces règles : un moteur de politique ne peut appliquer des règles d’accès fondées sur la sensibilité à des contenus non catégorisés.

Pourquoi la formation et la politique seules ne suffisent pas à combler l’écart au niveau des dirigeants

La plupart des efforts de gouvernance IA en entreprise reposent sur trois outils : une politique d’utilisation, une formation à la sécurité, et une liste de fournisseurs approuvés. Ces trois éléments sont utiles. Aucun ne traite ce que décrivent réellement les données TrustedTech et Teramind.

Un document de politique ne modifie le comportement que des personnes qui le lisent, se sentent concernées, et n’ont pas de moyen plus simple de le contourner. La formation augmente la sensibilisation, mais les enquêtes montrent déjà que ce n’est pas le problème — trois employés sur quatre reconnaissent le risque. Une liste de fournisseurs approuvés détermine les outils que la DSI prendra en charge, pas le compte qu’un dirigeant utilisera pour accéder à un outil autorisé depuis un compte personnel.

Aucun de ces contrôles n’intervient au moment décisif : celui où un fichier, un dossier ou un jeu de données est transmis à un système IA. C’est à ce niveau que les principes du zéro trust data protection s’appliquent directement : ne jamais faire confiance par défaut, vérifier chaque demande par rapport à la politique, et appliquer cette politique de la même façon, quel que soit le titre, l’appareil ou le type de compte. La demande d’un dirigeant pour résumer un fichier client est évaluée selon la même règle que celle de n’importe qui, car la règle est attachée à la donnée, non au statut de la personne. La minimisation des données appliquée à ce niveau — ne transmettre que le strict nécessaire pour la tâche IA, plutôt qu’un accès large à tout un référentiel — réduit encore l’impact de toute faille de gouvernance.

Gouverner l’IA au niveau des données : la solution pour combler l’écart

Si le comportement des dirigeants est à l’origine du risque, la solution doit fonctionner indépendamment de ce comportement. Il faut donc passer du contrôle des outils autorisés à la gestion de l’accès des outils et agents IA au contenu sensible, et dans quelles conditions.

Un modèle de gouvernance construit au niveau des données évalue chaque demande IA en temps réel : quelle est la classification du fichier, qui ou quoi fait la demande, quelle est la justification métier, et cette demande respecte-t-elle la règle ? Peu importe que le demandeur soit une personne connectée avec un compte professionnel, un compte personnel sur la même plateforme, ou un agent IA agissant pour le compte de quelqu’un — la demande respecte la politique d’accès ou elle est refusée. C’est la même logique déjà appliquée au contrôle d’accès basé sur les rôles et au contrôle d’accès basé sur les attributs pour les utilisateurs humains, étendue aux requêtes générées par les systèmes IA pour leur compte.

Deux fonctions sont essentielles dans ce modèle. D’abord, le contrôle d’accès par requête : chaque interaction IA avec un contenu sensible est évaluée selon la classification, le contexte et la politique au moment où elle se produit, jamais validée une fois pour toutes. Ensuite, une traçabilité complète de cette évaluation — qui ou quoi a demandé, ce qui a été sollicité, la décision de la politique, et quand. Quand un RSSI doit répondre à une question du conseil sur l’exposition à l’IA, « nous avons une politique » est bien moins convaincant que « voici le journal de toutes les requêtes IA sur des données réglementées du trimestre dernier, et voici ce qui a été autorisé ou bloqué ». L’intégration en temps réel de ce journal d’audit dans une plateforme SIEM permet aux équipes en charge de cybersécurité de détecter tout écart de comportement IA par rapport à la norme — transformant l’IA fantôme d’un risque invisible en un événement signalé et exploitable.

Cela résout aussi directement le problème des comptes personnels. Si la gouvernance s’attache à la donnée plutôt qu’au compte, peu importe que les deux tiers de l’activité IA identifiés par Teramind se déroulent via un compte professionnel ou personnel. Le contenu porte sa propre règle d’accès.

Comment Kiteworks Compliant AI et le serveur sécurisé MCP régulent l’accès IA aux données sensibles

C’est précisément ce problème que Kiteworks Compliant AI et le Kiteworks Secure MCP Server sont conçus pour résoudre : gouverner l’accès des outils, utilisateurs et agents IA au contenu sensible, sans se limiter au compte utilisé.

Les régulateurs édictent des règles sur l’accès, la gestion et la protection des données — pas sur le modèle de langage ou le framework IA utilisé. C’est tout le principe de Kiteworks Compliant AI : une personne et un agent IA sont deux types d’identités dont l’accès et l’utilisation des données réglementées doivent être gouvernés sous une seule couche de politique, et non deux séparées. Qu’un employé sollicite un assistant IA ou qu’un agent agisse pour son compte, les mêmes règles s’appliquent, car la réglementation ne s’intéresse qu’à la donnée.

Concrètement, chaque requête pilotée par l’IA — qu’elle soit initiée par un humain via une interface de chat ou générée par un agent — passe par des contrôles d’accès basés sur les rôles et les attributs, qui évaluent la classification des données, l’identité du demandeur et le contexte avant tout transfert de contenu. Le serveur sécurisé MCP de Kiteworks connecte des clients IA comme Claude ou Copilot au contenu gouverné de l’organisation via le Model Context Protocol, chaque accès à un fichier, dossier ou métadonnée héritant des mêmes autorisations OAuth 2.0 et contrôles de politique déjà appliqués ailleurs à cette personne. Les identifiants restent dans le trousseau du système d’exploitation, jamais dans le modèle IA, et chaque opération alimente en temps réel une traçabilité intégrée aux workflows SIEM et conformité existants. Le tableau de bord RSSI centralise tous les accès IA aux données, offrant aux responsables sécurité la visibilité en temps réel sur les flux de contenu médiés par l’IA que le problème des comptes personnels rend autrement invisibles.

Tout cela ne dépend pas du choix d’un dirigeant de respecter la politique. Cela dépend du fait que le contenu sensible porte des règles d’accès applicables de la même façon, que la personne en face suive ou contourne les règles. Voilà la différence entre espérer que la direction lise la politique IA et savoir que la donnée est protégée dans tous les cas.

Ce que les RSSI doivent retenir de ces données

Les résultats TrustedTech et Teramind offrent aux responsables sécurité un point de départ concret, pas une statistique de plus pour une présentation au conseil.

Commencez par la visibilité sur l’usage, plutôt que par une réécriture de la politique. La plupart des organisations disposent déjà de capacités de journalisation sur leurs plateformes IA sous licence ; le problème, c’est que personne n’a extrait de rapport comparant l’activité sur comptes gouvernés à l’estimation totale de l’usage IA dans l’organisation. Si le ratio Teramind se vérifie chez vous — deux tiers de l’activité hors comptes gouvernés — c’est un chiffre mesurable, traçable, et bien plus convaincant pour le conseil que « nous pensons que l’IA fantôme est un risque ».

Puis, concentrez-vous spécifiquement sur les dirigeants plutôt que de cibler l’audience habituelle des formations sécurité. Si ce sont les décideurs seniors qui génèrent l’usage non approuvé, le processus de provisionnement des comptes et la gestion des escalades doivent suivre un circuit dédié aux dirigeants, pas un simple email d’information envoyé à toute l’entreprise qu’un VP supprimera sans le lire.

Enfin, traitez « l’outil gouverné est trop lent ou trop limité » comme un vrai retour produit, pas seulement comme une violation de conformité à sanctionner. Si deux tiers de l’activité se font sur des comptes personnels de plateformes déjà payées par l’entreprise, c’est souvent le signe que la version gouvernée de l’outil présente des frictions absentes de la version personnelle — étapes d’approbation supplémentaires, fonctions manquantes, processus de connexion inadapté en réunion. Lever ces frictions, associé à une gouvernance au niveau du contenu comme l’échange sécurisé de données Kiteworks, agit à la fois sur le comportement et sur l’exposition des données. Le Réseau de données privé Kiteworks offre un environnement de gouvernance unifié — un moteur de politique, une traçabilité sur tous les canaux de contenu — qui rend l’option gouvernée aussi fluide que le compte personnel, pour que les dirigeants la choisissent non parce que la politique l’impose, mais parce qu’elle fonctionne aussi bien.

Pour en savoir plus sur la gouvernance des accès IA aux contenus sensibles dans votre organisation, réservez votre démo sans attendre !

Ressources complémentaires

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