Rendre la shadow AI visible sans bloquer le travail utile

Une règle qui dit seulement « utilisez une IA approuvée » ne montre pas à l'équipe de sécurité ce qui se passe réellement. Une personne peut coller des notes de réunion dans un chatbot personnel, relier un assistant à son calendrier de travail ou installer une extension IA avant qu'une revue formelle commence. La première question n'est pas de savoir si tout usage non approuvé doit être qualifié d'incident. Il faut savoir si l'organisation voit assez bien les données, identités et actions en jeu pour prendre une décision proportionnée.

Le National Cyber Security Centre britannique décrit la shadow AI comme une IA utilisée hors des systèmes et processus approuvés. L'implication opérationnelle est de traiter l'IA non gérée comme un flux de travail à découvrir et à rendre plus sûr, et non uniquement comme une entorse aux règles par un salarié. Une interdiction générale peut réduire l'usage visible tout en laissant intact le besoin qui l'a suscité.

Commencer par l'exposition, pas par une liste de fournisseurs

Une liste de logos approuvés est trop grossière pour les usages actuels de l'IA. Le même fournisseur peut présenter peu de risque dans un environnement géré, avec journaux d'audit et données limitées, et beaucoup de risque dans un compte personnel doté d'un connecteur non examiné. L'unité de revue est le déploiement : type de compte, informations saisies, paramètres de conservation, intégrations, permissions des outils et personne responsable.

Créez trois voies pratiques. Dans la première, l'expérimentation utilise des données publiques ou synthétiques et ne se connecte pas aux services internes ; elle doit être simple à déclarer et à déplacer vers un bac à sable approuvé. Dans la deuxième, l'outil traite des informations métier, des éléments clients, du code source ou des données réglementées. Une revue du flux de données est nécessaire avant un usage courant. Dans la troisième, un agent peut récupérer des fichiers, appeler des API ou modifier un autre système. C'est un logiciel privilégié, non un simple assistant de rédaction : il lui faut un responsable désigné, des identifiants limités, des journaux et un moyen de le désactiver.

Ce cadrage évite deux erreurs coûteuses. Faire de chaque essai occasionnel un incident majeur surcharge la revue et apprend aux personnes à cacher leur travail. Considérer tout outil IA comme inoffensif parce qu'il produit du texte ignore les accès que les assistants connectés peuvent accumuler. Les conseils du NCSC sur l'IA agentique rappellent que les protections et la supervision doivent suivre les actions qu'un agent peut effectuer.

Faire en sorte que déclarer soit plus sûr que dissimuler

La plupart des usages cachés signalent qu'une tâche n'a pas de voie officielle acceptable. Les équipes peuvent devoir résumer un long document, préparer une correspondance client, traduire du matériel ou rechercher des informations dans une archive désordonnée. Si la seule réponse est une file de tickets lente, le produit grand public déjà connu l'emportera souvent.

Proposez une déclaration courte et non punitive : outil utilisé, type de compte, nature des données, connexion éventuelle à d'autres services et tâche facilitée. Ne demandez pas de reconstruire chaque prompt avant de déterminer s'il y a un problème. Préservez d'abord les éléments pertinents sur le compte, les permissions et les intégrations ; décidez ensuite si les identifiants doivent être renouvelés, les responsables des données avertis ou le flux migré.

Un bon dispositif d'entrée produit aussi un meilleur inventaire. Associez les déclarations volontaires à des signaux ayant une finalité opérationnelle légitime : journaux d'identité, inventaires de logiciels autorisés, achats et alertes de perte de données. Chaque source est incomplète. Ensemble, elles révèlent où demande, exposition et contournements non pris en charge se recoupent. Les conseils du NCSC sur la shadow IT font le même constat : les services non officiels naissent souvent du besoin d'accomplir le travail, pas de l'intention de déjouer la sécurité.

Concevoir une approbation que les équipes utiliseront

Le but n'est pas un inventaire parfait, mais un passage rapide d'un flux inconnu vers un flux plus sûr. Indiquez ce qui peut être utilisé immédiatement, ce qui demande une revue légère et ce qui est interdit car cela exposerait des données très sensibles ou donnerait trop d'autorité à un agent. Expliquez la raison dans le langage de la tâche. « Utilisez l'espace de travail géré pour les documents clients » est plus utile qu'une page de fournisseurs.

Mesurez le délai pour un modèle, un connecteur ou un bac à sable demandé. Si une équipe attend des semaines une capacité qu'un site public fournit en quelques minutes, les restrictions seules ne combleront pas l'écart. Un délai d'approbation court, des modèles d'évaluation réutilisables et un environnement d'expérimentation géré sont des contrôles de sécurité car ils réduisent l'incitation à les contourner.

Les données sur l'adoption doivent être lues avec prudence. L'enquête britannique commandée par Microsoft et citée par le NCSC rapporte un usage auto-déclaré d'IA grand public non approuvée parmi ses répondants. Elle ne démontre pas que la même part a exposé des données sensibles, causé des incidents ou représente tous les pays et secteurs. Elle reste un avertissement : l'acceptation d'une politique ne mesure pas le travail réel.

Poser des limites strictes aux agents

Un agent IA change le modèle de risque lorsqu'il peut agir. Une faille d'injection de prompt, un connecteur trop large ou un compte compromis peut hériter de tout ce que l'agent est autorisé à lire ou modifier. Examinez chaque intégration séparément : identité utilisée, données accessibles, opérations permises et manière dont une personne peut l'interrompre.

Préférez des identifiants de courte durée, des comptes de service à périmètre restreint, des données de test segmentées, une confirmation par action pour les changements importants et des journaux reliant utilisateur, agent, appel d'outil et résultat. Testez le parcours de désactivation avant d'en avoir besoin. Un interrupteur d'urgence qui dépend du développeur initial ou d'un compte personnel oublié n'est pas un contrôle réel.

Gardez cette revue distincte de l'évaluation du modèle. Un modèle performant sans accès interne peut convenir à une tâche à faible risque ; un modèle plus modeste doté d'une large autorité peut créer un problème opérationnel bien plus grand. Les permissions et les chemins de données méritent autant d'attention que la qualité de la réponse.

Suivre des résultats qui changent les comportements

Comptez davantage que les domaines bloqués. Suivez le nombre de flux déclarés déplacés vers des outils gérés, le temps d'approbation, le nombre d'agents ayant un responsable et des permissions examinées, et la capacité des équipes à expliquer la voie approuvée pour les tâches courantes. Une hausse initiale des déclarations de shadow AI peut montrer que la déclaration est devenue plus sûre, et non que la situation s'est brusquement dégradée.

La shadow AI ne se gouverne pas par un document de politique seul. Elle devient maîtrisable lorsque les personnes peuvent révéler tôt un travail utile, que les évaluateurs distinguent les essais à faible risque des déploiements comportant données ou agents, et que la voie prise en charge est assez pratique pour concurrencer l'option non officielle. La visibilité est le début du contrôle, pas une raison d'arrêter le travail utile.