Le risque de shadow AI se concentre chez les utilisateurs intensifs en entreprise

Google News a relayé un avertissement marquant d’Akamai : 5 % des utilisateurs en entreprise génèrent 12 fois plus de conversations avec l’IA que la moitié des employés les moins actifs. Ces personnes ne se contentent pas de poser quelques questions occasionnelles. Elles intègrent l’IA à des processus récurrents, partagent du contexte de travail, importent des fichiers et déploient parfois des agents ayant accès aux systèmes de l’entreprise.

Cette conclusion remet en cause la réponse habituelle au shadow AI, c’est-à-dire l’usage de l’IA au travail en dehors des contrôles approuvés par l’employeur. De nombreuses entreprises publient encore une politique unique pour tous, bloquent quelques sites web connus et comptabilisent les licences des plateformes autorisées. Cette approche suppose une exposition uniformément répartie, alors que la télémétrie d’Akamai indique qu’elle est fortement concentrée.

Il ne s’agit pas pour autant d’ignorer les usages occasionnels. Près de la moitié des conversations d’IA observées en entreprise ont utilisé des identités personnelles plutôt que des comptes gérés par l’entreprise. Toutefois, la combinaison d’un accès personnel, de requêtes intensives et d’agents connectés crée un risque bien plus important qu’une demande isolée.

Le conflit principal n’oppose donc pas les employés aux équipes de sécurité. Il oppose une gouvernance large, centrée sur les applications, à des contrôles tenant compte de l’identité et axés sur les comportements réels. La première approche demande si un service d’IA est autorisé. La seconde demande qui l’utilise, sous quelle identité, avec quelles données et avec accès à quels systèmes.

Cette distinction est importante, car les employés qui créent le plus de valeur avec l’IA peuvent également engendrer l’exposition non gérée la plus importante. Les ralentir sans discernement gaspillerait leur expertise et encouragerait davantage de contournements. Laisser leur activité invisible permettrait à des processus sensibles de se développer au-delà des limites habituelles de sécurité.

Google News révèle un problème de shadow AI plus ciblé

Les données d’Akamai déplacent le débat sur le shadow AI de l’adoption globale vers la concentration de l’activité et des accès.

Les conclusions sous-jacentes proviennent de l’Enterprise AI Usage Risk Report 2026 d’Akamai, publié le 5 août. Akamai a fondé ce rapport sur des données d’utilisation de LayerX, l’entreprise de sécurité des navigateurs pour entreprises qu’elle a acquise. La recherche examine les comptes personnels, les applications d’IA, les extensions de navigateur, les requêtes sensibles et les agents autonomes.

Selon le rapport sur l’IA en entreprise, l’utilisateur moyen en entreprise a généré plus de 36 conversations avec l’IA. Cette moyenne masque une répartition très inégale. La moitié des utilisateurs ont enregistré 12 conversations ou moins, tandis que les 5 % les plus actifs en ont généré au moins 144.

L’écart ne se limite pas au nombre de conversations. Une conversation avec l’IA comporte généralement environ cinq requêtes, selon Akamai. Chez les utilisateurs les plus intensifs, les conversations atteignent au moins 18 requêtes, ce qui témoigne d’une collaboration soutenue plutôt que d’un simple échange comparable à une recherche.

Les conversations plus longues offrent davantage d’occasions pour que des informations professionnelles entrent dans un système externe. Un utilisateur peut commencer par une demande inoffensive de plan. Les requêtes suivantes peuvent ajouter des informations clients, des contraintes internes, des extraits de documents, du code source, des hypothèses financières ou des instructions copiées depuis des communications privées.

Ce contexte accumulé compte davantage qu’une phrase isolée. Le travail moderne avec l’IA se construit souvent par fragments. Un employé ajoute des faits au fil de plusieurs requêtes, importe des fichiers de référence et demande au modèle de réviser sa production à plusieurs reprises. Chaque divulgation peut sembler modeste prise séparément, tandis que la conversation complète reconstitue un processus métier sensible.

Akamai indique également que 47,11 % des conversations d’IA en entreprise se déroulent via des identités personnelles. Ces sessions échappent aux contrôles d’identité de l’entreprise, aux paramètres de conservation, aux systèmes d’audit et aux protections négociées des données. Les équipes de sécurité peuvent constater qu’un navigateur a accédé à un service d’IA sans savoir si l’employé utilisait un compte géré.

La répartition des identités varie fortement selon les plateformes. La télémétrie d’Akamai a montré que Gemini Enterprise conservait 98,15 % des interactions au sein des systèmes d’identité de l’entreprise. Microsoft Copilot for Microsoft 365 en conservait 90,55 % dans ces systèmes.

Les accès orientés grand public présentaient le schéma inverse. Le rapport associe 61,36 % des interactions avec ChatGPT, 61,09 % des interactions avec Claude et 63,92 % des interactions avec Microsoft Copilot Standard à des identités personnelles. DeepSeek atteignait 99,8 %.

Ces chiffres ne prouvent pas que chaque session personnelle a entraîné une fuite de données confidentielles. Ils établissent un manque de visibilité. Un employeur ne peut pas appliquer systématiquement les règles de conservation, d’accès et de traitement des données de l’entreprise lorsque le travail passe par une identité qu’il ne gère pas.

L’article relayé par Google News souligne aussi une corrélation cruciale. Les mêmes utilisateurs intensifs qui mènent des conversations plus approfondies sont davantage susceptibles d’importer des fichiers, de partager des informations professionnelles et de connecter l’IA à des tâches opérationnelles. Le risque suit l’activité, car chaque interaction supplémentaire crée une occasion de plus d’exposition inappropriée.

Ce cadre est plus utile que de considérer chaque employé comme une source de danger équivalente. Un salarié qui pose une question générale de rédaction ne crée pas le même risque qu’un ingénieur qui connecte un agent à un dépôt de code. Tous deux utilisent l’IA, mais leurs accès, leurs données et leur impact potentiel diffèrent radicalement.

Le chiffre de 5 % ne doit pas devenir un seuil permanent. Chaque organisation aura une répartition différente. Le changement important est méthodologique : les équipes de sécurité doivent mesurer la concentration avant de décider où des contrôles plus stricts sont nécessaires.

Les utilisateurs les plus risqués sont souvent les plus productifs

Les employés les plus susceptibles de contourner une politique générale sur l’IA sont souvent ceux qui ont déjà transformé l’IA en infrastructure de travail.

Les utilisateurs intensifs apparaissent généralement parce qu’ils découvrent une valeur répétable avant que les processus d’approvisionnement officiels ne les rattrapent. Ils peuvent utiliser l’IA pour résumer des recherches clients, déboguer du code, rédiger des contrats, comparer des documents techniques, analyser des appels commerciaux ou préparer des scénarios financiers. Les succès répétés favorisent une intégration plus poussée.

Cette progression commence souvent de manière anodine. Un employé teste un chatbot public avec des contenus non confidentiels. Il crée ensuite des requêtes réutilisables, ajoute des fichiers de référence, installe une extension de navigateur ou connecte le modèle à une autre application. Une expérimentation personnelle devient progressivement un processus de production non documenté.

Microsoft avait observé cette pression d’adoption des années avant le rapport d’Akamai. Son étude sur l’IA au travail de 2024 a révélé que 75 % des travailleurs du savoir interrogés utilisaient l’IA au travail. Parmi eux, 78 % avaient apporté leurs propres outils d’IA plutôt que d’attendre une option fournie par leur employeur.

Cette enquête antérieure mesurait des comportements déclarés, tandis qu’Akamai présente une télémétrie d’utilisation observée. Les sources emploient des méthodes et des périodes différentes ; leurs chiffres ne doivent donc pas être réunis dans une même affirmation statistique. Elles décrivent néanmoins la même tension organisationnelle : les travailleurs adoptent des outils pratiques plus vite que les entreprises ne peuvent les évaluer et les gouverner.

Les interdictions générales ne tiennent souvent pas compte de cette motivation. Une politique peut indiquer aux employés de ne pas placer d’informations sensibles dans un modèle non approuvé. Elle ne peut pas rendre une alternative approuvée utile, réduire une longue demande d’accès ni expliquer quelles informations sont sûres dans un processus spécifique.

Lorsque l’outil autorisé ne dispose pas des capacités nécessaires, un utilisateur intensif rencontre une friction immédiate. Il peut interrompre un travail productif, soumettre une demande d’approvisionnement ou continuer via un compte personnel. Si l’approbation prend des semaines, le compte personnel devient le chemin de moindre résistance.

Cela n’excuse pas un traitement non autorisé des données. Cela explique pourquoi les formations génériques produisent des résultats inégaux. Une présentation annuelle sur la conformité doit concurrencer des délais quotidiens, des interfaces grand public familières et la valeur immédiate d’une chaîne de requêtes fonctionnelle.

Les conclusions d’Akamai sur le shadow AI suggèrent que la formation devrait suivre les comportements observés. Les utilisateurs occasionnels ont besoin de limites claires et d’options approuvées. Les utilisateurs intensifs ont besoin de directives plus détaillées sur la classification des données, l’identité, les extensions, les connecteurs, les autorisations des agents et le signalement des incidents.

Ils ont également besoin d’un moyen plus sûr d’expérimenter. Une entreprise peut créer des environnements contrôlés dans lesquels les utilisateurs avancés testent de nouveaux modèles sans exposer de données de production. Les équipes de sécurité peuvent alors observer les besoins réels avant de décider quels services, intégrations et processus approuver.

Cette approche considère les utilisateurs intensifs du shadow AI comme des partenaires, sans supposer que l’expertise équivaut à une conscience des enjeux de sécurité. Une personne peut comprendre le comportement des modèles tout en sous-estimant les risques liés à la conservation, à l’autorisation ou au traitement par des tiers. La confiance technique peut parfois donner à un processus non officiel une apparence de sécurité qu’il n’a pas.

L’utilisateur productif peut aussi devenir un propriétaire de système caché. Si une équipe dépend de requêtes stockées dans un compte personnel, l’entreprise ne dispose d’aucun registre fiable de ces instructions. Si l’employé part, change d’outil ou perd l’accès, le processus peut disparaître avec lui.

Le même problème s’applique aux connaissances. Les travailleurs alimentent souvent l’IA avec des notes, des documents, le contexte de réunions et des décisions dispersées dans des espaces personnels. Un système de connaissances personnelles gouverné peut réduire cette fragmentation, mais uniquement si ses pratiques d’accès et de données correspondent aux exigences de l’organisation.

Les équipes de sécurité font donc face à une tâche délicate. Elles doivent préserver l’expertise qui rend l’IA utile tout en faisant basculer le processus environnant vers des identités gérées, des parcours de données approuvés et des systèmes contrôlables.

Sanctionner les utilisateurs les plus actifs peut les pousser davantage dans la clandestinité. Les ignorer peut transformer des expérimentations privées en infrastructure non suivie. La meilleure réponse commence par les identifier, comprendre ce qu’ils ont construit et distinguer les pratiques utiles des choix d’implémentation dangereux.

Une politique générale voit les applications, pas l’exposition

Une liste d’applications ne peut pas indiquer si un utilisateur a posé une question générale ou donné à un agent autonome accès à un dépôt critique.

Les programmes traditionnels de shadow IT recensent généralement les services, classent les fournisseurs et bloquent les domaines interdits. Ce modèle suppose que chaque application représente une unité de risque relativement stable. L’IA générative remet cette hypothèse en cause, car la même interface peut soutenir des comportements radicalement différents.

Un employé peut utiliser ChatGPT pour réécrire une offre d’emploi publique. Un autre peut coller des spécifications de produit non publiées dans le même service. Un troisième peut installer une extension de codage ayant accès à des fichiers locaux et à des identifiants de développement.

Le domaine est identique, mais l’exposition change selon l’identité, le contenu, les autorisations et la durée. Une simple décision d’autorisation ou de blocage ne peut pas exprimer ces différences.

L’analyse de sécurité d’Akamai identifie cinq domaines liés : l’expansion de l’usage de l’IA, les comptes personnels, l’exposition des données, les extensions de navigateur ou de développement et les agents autonomes. Leur combinaison compte davantage que chaque catégorie prise isolément.

Les extensions de navigateur méritent une attention particulière, car elles opèrent au plus près de l’activité des utilisateurs. Selon leurs autorisations, elles peuvent lire le contenu des pages, observer les saisies, interagir avec des applications cloud ou envoyer des informations vers des services externes. Les employés peuvent les installer sans considérer cette action comme un déploiement logiciel.

Les extensions d’environnements de développement intégrés posent un problème similaire aux ingénieurs. Un assistant de programmation par IA peut voir des fichiers sources, des éléments de configuration, des journaux d’erreurs ou des secrets à proximité. Même lorsque le service principal est approuvé, une extension, un type de compte ou une configuration particulière peut échapper aux contrôles de l’entreprise.

Les agents font encore monter les enjeux. Un agent d’IA est un logiciel qui utilise un modèle pour poursuivre un objectif au moyen d’outils avec une intervention humaine limitée. Selon les autorisations qui lui sont accordées, il peut rechercher des fichiers, appeler des API, modifier des enregistrements ou déclencher d’autres applications.

Un chatbot renvoie généralement du texte qu’une personne doit évaluer. Un agent peut agir. Ce changement transforme une sortie inexacte, des instructions manipulées ou des autorisations excessives en conséquences opérationnelles.

Un employé qui expérimente un agent peut connecter un jeton personnel, accorder un large accès à un dépôt ou exécuter le système depuis un appareil non géré. Les équipes de sécurité peuvent ignorer l’existence de l’agent, car son activité ressemble à une utilisation ordinaire du navigateur, d’API ou de développement local.

Le risque persiste également au-delà de la conversation initiale. Un prompt peut disparaître de l’attention une fois l’onglet du navigateur fermé. Un agent peut rester planifié, conserver des identifiants ou continuer à fonctionner via des intégrations.

Netskope a identifié cette surface d’exposition croissante dans sa recherche 2025 sur la shadow AI. L’entreprise a constaté que 60 % des utilisateurs d’entreprise observés accédaient encore à des applications d’IA générative personnelles en mai 2025. Elle a également suivi les agents personnalisés, les plateformes cloud d’IA et les outils sur site comme formes émergentes de shadow AI.

Netskope a indiqué que l’organisation moyenne de son jeu de données utilisait sept applications d’IA générative en mode logiciel en tant que service, contre 5,6 trois mois plus tôt. L’entreprise suivait également plus de 1 550 applications d’IA générative distinctes. Ces chiffres illustrent pourquoi maintenir une liste de blocage exhaustive devient difficile.

Cependant, remplacer une liste de blocage par la surveillance de chaque prompt créerait ses propres problèmes. La vie privée des employés, le droit du travail, la minimisation des données et la confiance restent des enjeux pertinents. Une visibilité accrue ne signifie pas automatiquement une meilleure gouvernance si la collecte ne repose pas sur un objectif clair ou des garanties appropriées.

L’objectif devrait être un contrôle proportionné. Les organisations peuvent commencer par des métadonnées telles que le type d’identité, la catégorie d’application, les événements de téléversement, les autorisations d’extension, les connexions d’outils et les niveaux d’activité inhabituels. Elles peuvent n’appliquer une inspection plus approfondie que lorsque le droit, la politique et le risque le justifient.

Ce modèle rappelle les principes établis du zero trust. L’accès dépend de l’identité, de l’appareil, de la ressource et du contexte, plutôt que du seul emplacement. La gouvernance de l’IA devrait évaluer chaque interaction à partir d’une combinaison similaire de signaux.

Un service d’IA géré ne rend pas chaque action sûre. Un service non approuvé ne rend pas non plus chaque action aussi dangereuse. La question importante est ce que l’utilisateur, le modèle et les outils connectés peuvent atteindre ensemble.

C’est pourquoi une politique générale passe à côté du principal problème de concentration. Elle régit le nom de l’application, tandis que l’exposition réelle s’accumule autour d’identités et de flux de travail particuliers.

Un contrôle concentré crée ses propres risques

Une gouvernance ciblée est plus précise qu’une restriction générale, mais les organisations ne doivent pas confondre volume d’utilisation et preuve de mauvaise conduite.

Les conclusions d’Akamai justifient une attention accrue aux utilisateurs intensifs. Elles n’établissent pas que les 5 % les plus actifs ont causé la plupart des incidents confirmés, divulgué les données les plus sensibles ou agi de manière irresponsable. Une activité élevée est un indicateur de risque, non un verdict d’incident.

Cette limite est importante. La télémétrie décrit des conversations, des identités et des schémas d’utilisation. Elle ne peut pas révéler l’objectif métier complet de chaque interaction. Un analyste de sécurité qui teste des contrôles d’IA peut ressembler à un utilisateur non sûr lorsqu’on ne mesure que le volume de conversations.

Les organisations devraient donc éviter de transformer le chiffre de 5 % en catégorie d’application automatique. Une activité intensive devrait déclencher un examen contextuel. Elle ne devrait pas justifier une suspension immédiate de compte, une surveillance intrusive ou une mesure disciplinaire sans éléments supplémentaires.

Le jeu de données reflète également la visibilité d’Akamai et de LayerX. Il ne doit pas être considéré comme un recensement universel de tous les secteurs, zones géographiques, appareils et déploiements d’IA. Les entreprises ont besoin de leur propre référence avant de fixer des seuils ou d’estimer l’exposition.

Une deuxième préoccupation concerne la fausse confiance accordée aux comptes d’entreprise. Une identité gérée améliore l’audit, le contrôle d’accès et la protection contractuelle. Elle n’empêche pas un employé de saisir des informations restreintes, d’accepter une réponse hallucinée ou d’accorder des autorisations excessives à une application connectée.

Les versions d’entreprise de Gemini, Copilot, ChatGPT ou Claude peuvent réduire certains risques grâce aux contrôles administratifs. Elles ne peuvent pas remplacer la classification des données, la conception des autorisations, l’examen des flux de travail ou le jugement humain.

Une troisième préoccupation concerne la confiance organisationnelle. Les employés qui pensent que chaque interaction avec l’IA sera lue par la direction peuvent dissimuler leur utilisation, passer à des appareils personnels ou éviter les outils approuvés. Cette réaction réduit la visibilité qu’un programme ciblé était censé créer.

Les entreprises ont besoin de règles de surveillance transparentes. Les utilisateurs doivent comprendre quels signaux sont collectés, pourquoi ils comptent, qui peut les examiner et combien de temps ils restent disponibles. Les équipes de sécurité devraient séparer, dans la mesure du possible, la détection des risques du suivi des performances.

Le profil IA du NIST offre un contrepoids utile à une application restrictive et étroite. Il organise le travail sur les risques autour de la gouvernance, de la cartographie, de la mesure et de la gestion. Cette approche fondée sur le cycle de vie traite les contrôles comme un système continu plutôt que comme une politique unique applicable aux employés.

La gouvernance définit la propriété, les usages acceptables, les circuits de signalement et la responsabilité. La cartographie identifie le contexte métier, les personnes concernées, les données et les dépendances. La mesure vérifie si les risques et les contrôles peuvent être observés. La gestion hiérarchise les réponses en fonction de l’impact et de la tolérance.

Appliquée aux utilisateurs intensifs de shadow AI, cette séquence évite de passer trop tôt de la détection à la sanction. Une entreprise identifie d’abord les flux de travail intensifs, cartographie leur objectif métier et leur accès aux données, mesure l’exposition concrète, puis choisit un contrôle proportionné.

La réponse peut consister à migrer un compte personnel vers un compte géré. Elle peut supprimer une autorisation d’extension excessive, remplacer une clé API personnelle, limiter les outils d’un agent ou approuver un meilleur service d’entreprise.

Certains flux de travail devraient être arrêtés entièrement. Un agent non examiné qui modifie des données financières ou traite des données de santé réglementées présente un niveau d’exposition différent de celui d’un assistant de rédaction utilisant des contenus publics. L’analyse de concentration aide à repérer cette différence, mais l’examen humain en détermine toujours la signification.

Une gouvernance ciblée doit également tenir compte des utilisateurs privilégiés. Les ingénieurs, administrateurs, chercheurs, dirigeants, équipes juridiques et collaborateurs financiers manipulent souvent des informations plus conséquentes que leurs pairs. Le volume de conversations et la sensibilité des accès doivent être évalués ensemble.

Un utilisateur ayant 150 conversations à faible risque sur un langage marketing public peut présenter moins d’exposition qu’une personne ayant téléversé un seul document confidentiel d’acquisition. Le volume est utile parce qu’il identifie un comportement ancré. Le contenu et le contexte des autorisations déterminent l’impact potentiel.

La conclusion sceptique est simple : la télémétrie de shadow AI d’Akamai améliore la priorisation, mais ne fournit pas un score de risque complet. Les organisations ont toujours besoin de preuves locales, de règles transparentes et d’un examen rigoureux.

Ce que les équipes de sécurité devraient surveiller ensuite

La prochaine phase de la gouvernance de la shadow AI se mesurera à l’adoption d’identités gérées, aux autorisations des agents et à des réductions validées de l’exposition aux données sensibles.

Le premier signal est la part des activités d’IA liées au travail qui passent d’identités personnelles à des comptes gérés par l’entreprise. C’est plus significatif que de compter les licences achetées. Une entreprise peut posséder des milliers de licences d’entreprise tandis que les employés continuent d’utiliser leurs comptes personnels familiers.

Les responsables de la sécurité devraient mesurer la migration des comptes par équipe et par niveau d’activité. Les progrès parmi les utilisateurs occasionnels sont utiles, mais les évolutions chez les utilisateurs les plus intensifs comptent le plus. Une baisse de la part des comptes personnels dans ce groupe étayerait la thèse de concentration d’Akamai et montrerait que l’intervention ciblée fonctionne.

Cette mesure nécessite une interprétation prudente. Une connexion gérée ne prouve pas un comportement sûr. Elle fournit toutefois une base plus solide pour le contrôle d’accès, les paramètres de conservation, l’auditabilité et la réponse aux incidents.

Le deuxième signal est la croissance des agents et extensions ayant accès aux systèmes métier. Les organisations devraient inventorier ce que ces outils peuvent lire, modifier et transmettre. Elles devraient également identifier quelles identités ont fourni les identifiants.

Les autorisations comptent davantage que le nombre d’agents. Dix agents limités à des informations publiques peuvent créer moins d’exposition qu’un seul système disposant d’un accès en écriture à des données de production. Les examens devraient donner la priorité aux ressources sensibles, aux identifiants persistants, aux transferts externes de données et aux actions dépourvues de confirmation humaine.

Toute réduction des autorisations excessives renforcerait l’argument en faveur d’une gouvernance ciblée. Une croissance rapide d’agents non découverts affaiblirait les affirmations selon lesquelles les politiques actuelles d’IA assurent une couverture significative.

Le troisième signal est de savoir si les organisations peuvent démontrer une diminution des événements impliquant des données sensibles sans freiner une adoption utile. C’est la mesure la plus difficile, car elle exige que les équipes de sécurité et de productivité évaluent les résultats ensemble.

Un programme réussi devrait réduire les téléversements restreints, les identifiants non gérés et les intégrations non approuvées. Il devrait aussi maintenir une utilisation approuvée suffisamment accessible pour que les employés ne basculent pas vers des canaux invisibles.

Les métriques fondées uniquement sur les requêtes bloquées créent de mauvaises incitations. Davantage de blocages peuvent indiquer une application plus stricte, une demande croissante et non sûre, ou de mauvaises alternatives approuvées. Les équipes doivent comparer les événements de prévention avec la migration des comptes, l’adoption de flux de travail approuvés, les retours des utilisateurs et les incidents confirmés.

Le cadrage de Google News ne restera utile que si les organisations le confrontent à leurs propres environnements. Le seuil précis de 5 % peut évoluer, mais la concentration devrait apparaître dans la télémétrie interne si le schéma sous-jacent se confirme.

Les équipes de sécurité peuvent commencer par plusieurs questions pratiques. Quels employés utilisent l’IA le plus souvent ? Lesquels s’appuient sur des identités personnelles ? Qui téléverse des fichiers, installe des extensions ou connecte des agents à des systèmes internes ? Quels outils approuvés ne répondent pas à leurs besoins ?

Ces questions constituent un meilleur point de départ que de se demander si toute IA devrait être autorisée ou interdite. Elles relient la gouvernance au travail réel et révèlent là où la commodité contourne le contrôle.

Les entreprises devraient également établir un circuit d’escalade qui ne commence pas par une sanction. Lorsque la sécurité découvre un flux de travail non officiel avancé, le premier examen devrait identifier sa valeur métier, ses données d’entrée, ses autorisations et ses alternatives. Cela crée l’occasion de préserver des pratiques utiles tout en supprimant une exposition inutile.

Lorsque le risque est immédiat, comme pour un agent disposant d’un large accès à la production, le confinement devrait passer en premier. Lorsque l’exposition est moindre, la migration et l’accompagnement peuvent offrir une meilleure conformité à long terme qu’une interdiction générale.

Les dirigeants devraient se poser une dernière question avant de déclarer le problème maîtrisé : l’organisation peut-elle décrire ses flux de travail d’IA les plus intensifs sans s’appuyer sur une enquête ? Si la réponse est non, la politique devance les éléments de preuve.

Google News a attiré l’attention sur un renversement important. La shadow AI est répandue, mais son exposition la plus grave n’est pas nécessairement répartie uniformément. Les personnes qui utilisent l’IA le plus profondément sont celles où convergent productivité, données, identité et accès autonome.

Cela clarifie la prochaine action. Identifiez les flux de travail concentrés, placez-les sous une identité gérée, examinez leurs autorisations et mesurez si l’exposition des données sensibles diminue. Des règles générales peuvent fixer des limites, mais seules les preuves issues de l’usage réel indiquent où la protection est nécessaire.