L’alerte d’Akamai sur la Shadow AI révèle une faille dans le contrôle des entreprises

Akamai lance un avertissement sévère : près de la moitié des utilisateurs en entreprise accèdent à des outils d’IA, alors qu’une grande partie de cette activité peut échapper aux contrôles internes établis.

Cette conclusion est apparue dans un titre tronqué de Google News renvoyant vers un communiqué d’Akamai diffusé par GlobeNewswire. Cette fiche omettait le complément après « contourne », laissant l’affirmation centrale incomplète. Les recherches plus larges d’Akamai identifient toutefois clairement le conflit manquant : l’utilisation productive de l’IA se fait de plus en plus en dehors des identités gérées, des comptes approuvés et des canaux de sécurité visibles.

Il ne s’agit pas simplement d’une enquête de plus montrant que les salariés apprécient ChatGPT. Elle décrit une collision entre la demande des employés et le modèle de contrôle que les entreprises ont construit pour les logiciels traditionnels. OpenAI, Google, Anthropic, Microsoft et des centaines de fournisseurs plus modestes ont rendu des outils avancés accessibles depuis un navigateur ordinaire.

La question de sécurité a donc évolué. Les entreprises ne doivent plus seulement décider quels systèmes d’IA elles approuvent. Elles doivent déterminer si des informations sensibles atteignent n’importe quel modèle via des comptes personnels, du texte collé, des téléversements, des extensions ou des fonctionnalités intégrées.

Le renversement est inconfortable. Les entreprises ont passé des années à centraliser l’identité, les accès et l’achat de logiciels. L’adoption de l’IA décentralise désormais ces trois éléments depuis le navigateur.

Le titre révèle un angle mort à l’échelle du navigateur

L’avertissement d’Akamai porte sur le chemin emprunté par les employés pour accéder à l’IA, et pas seulement sur le nombre de personnes qui l’expérimentent.

Les éléments disponibles proviennent en partie de LayerX, l’entreprise de sécurité des navigateurs acquise par Akamai. LayerX collecte de la télémétrie sur l’activité au sein des applications web, notamment les connexions, les téléversements, le texte collé et les passages entre comptes professionnels et personnels.

Ses recherches publiées ont constaté que 45 % des utilisateurs en entreprise accédaient à l’IA générative depuis des terminaux professionnels. ChatGPT représentait 92 % de l’utilisation d’IA observée dans cet ensemble de données.

Ces chiffres ne signifient pas que 45 % de tous les employés dans le monde utilisent ChatGPT. Ils décrivent l’activité au sein des organisations et des terminaux couverts par la télémétrie du fournisseur. Cette distinction compte lors de l’interprétation de tout rapport d’une entreprise de sécurité.

La même recherche a relevé une tendance plus lourde de conséquences. Quarante pour cent des fichiers téléversés vers des outils d’IA contenaient des informations sensibles de l’entreprise. Vingt-deux pour cent du texte collé contenait également des éléments sensibles.

Ces pourcentages mesurent des transferts inspectés, et non des violations confirmées. Un téléversement sensible peut être autorisé, correctement protégé et nécessaire à un travail légitime. Il peut aussi transiter par un compte personnel que l’employeur ne peut pas auditer.

LayerX a indiqué que 32 % des transferts de données entre comptes professionnels et personnels passaient par des plateformes d’IA. Ses constats plus généraux sur l’utilisation de l’IA placent le navigateur au centre de cette exposition.

Cela aide à expliquer la formulation tronquée « contourne » dans la fiche Google News. Les contrôles concernés comprennent l’identité d’entreprise, l’authentification unique, les règles sur les comptes approuvés, les politiques de prévention des pertes de données et les procédures habituelles d’évaluation des logiciels.

L’authentification unique, souvent appelée SSO, permet à un employeur de gérer les accès par l’intermédiaire d’une identité professionnelle unique. Les comptes d’IA personnels évitent cette couche d’identité, même lorsque les employés les utilisent sur des appareils de l’entreprise.

La gouvernance logicielle traditionnelle suppose que le service informatique peut découvrir une application, l’approuver, provisionner les accès, puis les retirer ultérieurement. Les outils d’IA grand public réduisent l’adoption à une visite, une connexion et une requête.

Aucune demande d’installation n’est nécessaire. Un salarié peut ouvrir un chatbot, s’authentifier avec une adresse e-mail personnelle et coller un document client en quelques minutes.

L’IA intégrée complique encore davantage la découverte. Des fonctions génératives apparaissent désormais dans les suites de productivité, les outils de conception, les plateformes de réunion, les systèmes clients et les extensions de navigateur. Les employés ne considèrent pas forcément chaque fonctionnalité comme un service d’IA distinct.

Akamai définit la shadow AI comme l’utilisation de l’IA sans la connaissance, l’approbation ou la supervision des équipes informatiques, de sécurité ou de conformité. Cela englobe bien plus que les chatbots non autorisés.

Un développeur peut soumettre du code propriétaire à un assistant de programmation personnel. Un responsable marketing peut téléverser une liste de clients pour générer des segments de campagne. Un manager peut connecter un agent à des documents cloud sans examiner ses autorisations.

Chaque action peut ressembler à un trafic de navigateur ordinaire. L’élément risqué est le contexte, notamment l’identité de l’utilisateur, les informations transférées et le traitement contractuel de ces informations par le fournisseur.

Un pare-feu peut voir une connexion à un domaine autorisé. Il ne sait pas automatiquement si l’employé utilise un compte d’entreprise géré ou un compte privé.

C’est le changement central mis en évidence par le rapport. L’IA d’entreprise est devenue suffisamment courante pour que la gouvernance des accès par le seul nom de l’application n’offre plus une visibilité adéquate.

Pourquoi les contrôles de l’IA d’entreprise perdent la course à l’adoption

Les employés contournent les parcours approuvés lorsque l’IA grand public offre un accès plus rapide, des fonctionnalités plus étendues ou moins d’obstacles procéduraux.

La shadow AI commence souvent par une tâche pratique plutôt que par une intention malveillante. Un salarié doit résumer une réunion, réviser une proposition, examiner du code ou comparer plusieurs documents.

L’assistant approuvé peut ne pas proposer le modèle préféré, accepter moins de types de fichiers ou rester indisponible pour ce service. Les évaluations des achats et de la sécurité peuvent également avancer plus lentement que le travail.

Un chatbot personnel offre un accès immédiat. L’employé y voit un outil de productivité, tandis que l’équipe de sécurité y voit un sous-traitant de données non évalué.

Cet écart d’incitation explique pourquoi les interdictions produisent des résultats limités. Bloquer un service peut rediriger les utilisateurs vers un autre fournisseur, un appareil mobile, un profil de navigateur personnel ou une fonctionnalité intégrée.

Une politique efficace doit s’attaquer à la raison pour laquelle les employés ont choisi la voie non officielle. Sinon, l’application des règles traite le symptôme visible tout en préservant la demande.

Les propres recommandations d’Akamai indiquent que l’utilisation non contrôlée diminue lorsque les entreprises fournissent des outils approuvés performants, dotés de protections contractuelles, de journaux d’audit et d’une intégration SSO. Le parcours sécurisé doit tout de même résoudre le problème de l’utilisateur.

La comparaison historique est le shadow IT, qui s’est développé lorsque des services achetaient des applications cloud sans approbation centrale. Les équipes de sécurité ont fini par adopter des courtiers d’accès au cloud, la découverte d’applications et des procédures d’achat plus souples.

L’IA accroît les enjeux parce que la transaction contient souvent des données métier. Une application non autorisée classique peut stocker un nouveau calendrier de projet. Une interaction avec un chatbot peut transmettre immédiatement du code source, des formulations juridiques, des dossiers clients ou une stratégie non publiée.

Les systèmes génératifs créent également des résultats que les employés peuvent réutiliser sans en documenter l’origine. Cela soulève des questions d’exactitude, de propriété intellectuelle, de biais et de responsabilité, en plus de l’exposition des données.

Le même service d’IA peut présenter des profils de risque différents selon le compte. Un contrat d’entreprise peut offrir des contrôles de conservation, des journaux administratifs et des restrictions sur l’entraînement des modèles.

Un compte personnel peut ne pas bénéficier de ces protections. Les équipes de sécurité doivent donc distinguer les identités et les sessions, et pas simplement reconnaître le domaine de destination.

Cette différence exerce une pression sur les directeurs des systèmes d’information et les responsables de la sécurité depuis des directions opposées. Les DSI sont censés accroître l’adoption de l’IA, tandis que les responsables de la sécurité doivent réduire les mouvements de données non contrôlés.

Les dirigeants opérationnels ajoutent une autre exigence : une productivité mesurable. Si l’environnement officiel ralentit les employés sans améliorer les résultats, l’utilisation non contrôlée devient une réponse prévisible.

Ce conflit apparaît au-delà de la clientèle d’Akamai. Axios a rapporté que les entreprises utilisaient couramment 67 outils d’IA générative, dont 90 % ne disposaient pas de licences ou d’approbations appropriées. Son reportage sur la shadow AI décrivait des fournisseurs de sécurité cherchant à combler à toute vitesse le déficit de visibilité.

Là encore, les mesures des fournisseurs varient selon la population de clients, la méthode de collecte et la définition retenue. Une entreprise peut compter les domaines, tandis qu’une autre compte les applications, les comptes, les utilisateurs ou les sessions individuelles.

La tendance est plus fiable que n’importe quel pourcentage isolé. Les employés disposent de nombreuses voies d’accès à l’IA, et les inventaires d’entreprise ne capturent systématiquement qu’une partie de cette activité.

La pression ne s’arrête pas aux équipes de sécurité. Les services juridiques doivent déterminer quels fournisseurs peuvent traiter des informations réglementées ou confidentielles.

Les équipes chargées de la confidentialité doivent comprendre où transitent les requêtes et les fichiers. Les équipes achats doivent examiner une liste croissante de fonctionnalités d’IA, y compris les fonctions ajoutées à des produits déjà sous contrat.

Les managers ont également besoin de règles pour les contenus générés. Un outil approuvé ne rend pas chaque réponse exacte, et un accord d’entreprise ne valide pas chaque décision prise à partir de ses résultats.

Le problème de contrôle comporte donc deux niveaux. Les entreprises doivent gouverner les informations qui entrent dans les systèmes d’IA et les décisions qui en sortent.

Bloquer les comptes non autorisés ne traite que le premier niveau. Cela ne détermine pas quand une réponse générée doit être vérifiée, quelles sources le système a utilisées ou qui demeure responsable.

Cette charge de gouvernance plus large explique pourquoi la course à l’adoption semble déséquilibrée. Un salarié peut commencer à utiliser l’IA immédiatement, tandis qu’une structure de contrôle d’entreprise complète exige une coopération entre plusieurs services.

Le véritable enjeu oppose l’IA gérée à l’IA utile

Le principal adversaire n’est pas Akamai face à un autre fournisseur de sécurité ; c’est l’IA gérée face aux outils que les employés jugent les plus utiles.

Les entreprises présentent parfois la sécurité et la productivité comme des objectifs opposés. Cette vision encourage des contrôles brutaux, notamment des blocages complets, des listes d’autorisation restreintes et de longues procédures d’approbation.

Les employés se retrouvent alors face à un choix simple. Ils peuvent attendre un flux de travail approuvé ou terminer la tâche avec un service grand public qu’ils connaissent.

Le meilleur terrain de concurrence concerne la qualité du produit. Un assistant géré doit offrir suffisamment de capacités, de contexte, de rapidité et de fiabilité pour devenir le choix par défaut.

Le contexte est particulièrement important. Les travailleurs du savoir ont besoin que l’IA opère sur des documents, des conversations, l’historique des projets et des contenus internes spécialisés.

Cet accès crée aussi des risques. Des autorisations étendues peuvent exposer des informations qu’un salarié ne réalisait pas pouvoir récupérer par une interface d’IA.

Un environnement de connaissances géré doit préserver les limites d’accès existantes. Il doit aussi indiquer quelles sources étayent une réponse et maintenir la recherche au sein des contenus autorisés.

C’est là qu’une base de connaissances personnelle peut réduire la copie improvisée entre les systèmes métier et les chatbots publics. La capture locale ou contrôlée n’élimine pas les obligations de gouvernance, mais elle peut réduire les transferts inutiles.

Les contrôles de sécurité doivent fonctionner au moment de l’interaction. Les outils réseau restent utiles, mais ils peuvent manquer des distinctions cachées au sein de sessions de navigateur chiffrées.

Les contrôles au niveau du navigateur peuvent identifier le compte actif, inspecter un téléversement et reconnaître un collage avant que l’information ne quitte le terminal. Ils peuvent ensuite avertir, masquer, bloquer ou consigner l’action.

Workforce Protector d’Akamai, anciennement LayerX, illustre cette approche. Selon Akamai, il gouverne le comportement des utilisateurs et des agents au sein des applications au lieu de s’appuyer uniquement sur le trafic périmétrique.

L’entreprise a un intérêt commercial à définir le navigateur comme le point d’application critique. Les acheteurs devraient examiner cette affirmation au regard des alternatives de sécurité des terminaux, du réseau, des identités et des données.

Aucune couche unique ne voit tous les parcours. Une extension de navigateur ne peut pas régir un téléphone non géré qui ne touche jamais l’environnement d’entreprise.

Les contrôles réseau peuvent identifier les destinations, mais manquer de contexte détaillé sur les sessions. Les agents sur les terminaux peuvent inspecter l’activité des appareils, mais ne comprennent pas forcément la sémantique interne de chaque application.

Les contrôles d’identité établissent qui s’est connecté, mais ils ne déterminent pas automatiquement si chaque prompt contient des informations restreintes. La classification des données peut reconnaître les contenus sensibles, mais dépend de libellés précis et d’une couverture adéquate.

L’architecture pratique combine ces signaux. Elle relie l’identité, la posture de l’appareil, la destination, le type de compte, la sensibilité du contenu et l’action demandée.

Prenons le cas d’un employé qui résume une annonce publique de produit. Un chatbot personnel présente un risque organisationnel limité, car la donnée saisie est déjà publique.

Considérons maintenant ce même employé qui colle des transcriptions d’échanges avec le support client. La destination peut rester identique, mais les exigences de confidentialité, de conservation et contractuelles changent la décision.

L’inspection des fichiers seule ne détecte pas non plus le comportement de copier-coller. Les mesures de LayerX indiquent que le texte collé constitue un canal d’exposition significatif, même lorsque les employés ne téléversent jamais de document.

Les agents ajoutent une dimension supplémentaire. Un agent peut récupérer des informations, appeler des services externes, mettre à jour des enregistrements et répéter des actions sans nécessiter un nouveau geste humain à chaque fois.

La conception des autorisations devient ainsi une question de sécurité opérationnelle. Un chatbot répond à une demande, tandis qu’un agent peut provoquer une modification.

L’étude sur la sécurité des API d’Akamai de 2026 a interrogé 1 840 responsables et praticiens de la sécurité dans dix pays. Elle a révélé que 80 % utilisaient des pare-feu d’applications web, tandis que seulement 35 % utilisaient des outils dédiés de sécurité des API.

Les API sont des interfaces qui permettent aux systèmes logiciels d’échanger des données et des commandes. Elles constituent la couche de liaison entre les agents, les modèles, les bases de données et les applications métier.

Une session de chatbot non autorisée peut divulguer des informations. Un agent doté de privilèges excessifs peut aussi modifier un ticket, émettre un remboursement, envoyer un message ou interroger un système restreint.

L’IA gérée doit donc se distinguer sur bien plus que la qualité des modèles. Elle a besoin d’intégrations utiles, d’autorisations limitées, de journaux fiables et d’une approbation humaine pour les actions importantes.

Si ces garde-fous rendent chaque tâche pénible, les employés les éviteront. S’ils disparaissent complètement, l’organisation ne peut plus distinguer la commodité d’une exposition inacceptable.

La conception gagnante rend faciles les actions courantes à faible risque. Elle réserve une friction supplémentaire aux données sensibles, aux destinations inhabituelles, aux comptes personnels et aux commandes à fort impact.

C’est autant un défi produit qu’un défi de politique interne. Les entreprises ne peuvent pas résoudre par la formation des interfaces qui récompensent systématiquement les raccourcis dangereux.

Ce que le titre de Google News n’établit pas

Le risque sous-jacent est crédible, mais ce titre tronqué ne prouve pas de façon indépendante que près de la moitié de toute l’activité d’IA en entreprise contourne les contrôles.

L’entrée Google News tronque l’affirmation juste après « contourne ». Elle n’identifie ni le contrôle concerné, ni la période de mesure, ni l’échantillon, ni la zone géographique, ni le dénominateur.

Ces omissions empêchent toute interprétation précise. « Près de la moitié de l’usage de l’IA en entreprise » peut désigner des utilisateurs, des comptes, des sessions, des terminaux, des organisations, des téléversements ou une autre catégorie mesurée.

Les documents Akamai et LayerX indexés publiquement étayent plusieurs constats connexes. Ils ne rendent pas interchangeables toutes les interprétations possibles de cette phrase.

LayerX a indiqué que 45 % des utilisateurs en entreprise accédaient à des outils d’IA sur des terminaux d’entreprise. L’entreprise a également signalé du contenu sensible dans 40 % des fichiers téléversés et dans 22 % des textes collés.

Elle a aussi signalé un recours important aux identités personnelles dans les services logiciels. Ses recherches sur l’identité de 2025 ont révélé que 40 % des accès SaaS utilisaient des identifiants personnels et que 67 % contournaient le SSO.

Ces statistiques décrivent des populations et des comportements différents. Les combiner en une seule affirmation générale créerait un chiffre que la recherche n’a pas publié.

La première mise en garde concerne donc la rigueur du dénominateur. Les lecteurs devraient demander ce qui a été compté avant de traiter un pourcentage comme un taux d’adoption universel.

La deuxième mise en garde concerne la télémétrie des fournisseurs. Les prestataires de sécurité analysent souvent l’activité de clients qui ont déjà déployé leurs produits.

Ces organisations peuvent différer des entreprises dépourvues d’une surveillance comparable. Leurs secteurs, tailles, politiques et profils de risque peuvent façonner les résultats mesurés.

La télémétrie conserve néanmoins sa valeur, car elle observe les comportements plutôt que de se fier uniquement à la mémoire. Elle ne représente toutefois pas automatiquement toutes les entreprises ni tous les employés.

Les enquêtes comportent une limite différente. Les répondants peuvent mal comprendre les définitions, sous-déclarer des activités interdites ou représenter des organisations dotées de programmes d’IA exceptionnellement matures.

Les recherches indépendantes devraient donc comparer plusieurs formes de preuves. Les sources utiles comprennent la télémétrie des terminaux, les journaux réseau, les enregistrements d’identité, les enquêtes auprès des employés, les rapports d’incidents et les divulgations réglementaires.

La troisième mise en garde concerne le mot « contournement ». Une connexion personnelle peut contourner la gestion des identités de l’entreprise sans contourner tous les contrôles de sécurité.

Le terminal peut toujours exécuter un logiciel de prévention des pertes de données. Le réseau peut toujours bloquer certaines destinations. Le fournisseur peut toujours proposer des paramètres de confidentialité pour les particuliers.

À l’inverse, un compte approuvé peut créer un risque même lorsqu’il passe par le SSO. Des autorisations excessives, des règles de conservation insuffisantes, l’injection de prompt et des résultats inexacts restent possibles.

Cette distinction évite une conclusion simpliste. Géré ne signifie pas sûr, et non géré ne signifie pas violation confirmée.

L’étude d’Akamai sur l’IA en entreprise, commandée en 2025, illustre une préoccupation plus large. Parmi 400 répondants internationaux de niveau direction, 63 % ont identifié les préoccupations de sécurité comme l’un des principaux défis liés aux applications d’IA.

La même étude a révélé que 55 % citaient des lacunes technologiques ou de plateforme, tandis que 55 % citaient les enjeux de conformité et de réglementation. Quarante-cinq pour cent s’inquiétaient d’applications ne fonctionnant pas comme prévu.

Ces résultats montrent que la pression en matière de gouvernance dépasse les comptes fantômes. Les organisations s’inquiètent des performances, de la fiabilité, de la conformité et des conséquences sur la marque, même dans les déploiements formels.

La quatrième mise en garde concerne la causalité. L’IA fantôme est souvent décrite comme une faute des employés, mais les éléments disponibles ne soutiennent pas un motif universel unique.

Certains employés ignorent délibérément les règles. D’autres se heurtent à des politiques floues, des outils manquants, des approbations lentes ou à des fonctionnalités d’IA intégrées à des produits déjà approuvés par l’informatique.

Les dirigeants peuvent également créer des incitations contradictoires. Ils exigent une adoption rapide de l’IA tout en évaluant les équipes sur leur vitesse, puis imposent des restrictions qui empêchent les employés d’atteindre ces objectifs.

Une analyse crédible doit tenir compte des deux aspects. Les utilisateurs restent responsables du traitement des informations sensibles, tandis que les organisations restent responsables de proposer des voies approuvées et praticables.

Les prévisions réglementaires exigent également de la prudence. Gartner a prédit que 40 % des entreprises connaîtront d’ici 2030 un incident de sécurité ou de conformité lié à l’IA en raison d’un usage non autorisé de l’IA fantôme.

Comme le résume la couverture des prévisions de Gartner, ce chiffre concerne des incidents projetés. Il ne s’agit pas d’un décompte actuel de violations.

Les prévisions peuvent identifier une exposition, mais elles ne confirment pas qu’une organisation donnée a perdu des données. Les acheteurs devraient éviter de transformer des estimations de risque en affirmations sur des attaques déjà réalisées.

L’élément incomplet du flux crée un dernier problème éditorial. Google News est une couche d’agrégation, et non la preuve sous-jacente.

La publication directe, la méthodologie et le rapport complet devraient déterminer le libellé. Tant que l’affirmation complète et le dénominateur ne sont pas visibles, « près de la moitié » mérite une attribution plutôt qu’une présentation comme un fait universel établi.

Cela ne rend pas l’histoire moins importante. Cela fait de la lacune de vérification une partie de l’histoire.

Trois signaux montreront si les entreprises reprennent le contrôle

La prochaine phase sera mesurée par la visibilité des comptes, le mouvement des données sensibles et les autorisations accordées aux agents d’IA.

Le premier signal est la part de l’activité d’IA associée à des identités d’entreprise gérées. Les entreprises devraient suivre si les employés passent, au fil du temps, de comptes personnels à des services approuvés.

Une baisse de la part des comptes personnels renforcerait l’idée que des outils d’entreprise utiles peuvent réduire l’IA fantôme. Une part stable ou en hausse montrerait que les politiques et les licences ne modifient pas les comportements.

Cette métrique devrait être ventilée par service et par tâche. Les développeurs, les spécialistes du marketing, les analystes, les équipes de support et les dirigeants utilisent des outils différents et manipulent des informations différentes.

Une moyenne à l’échelle de l’entreprise peut masquer une exposition concentrée. Un petit groupe peut être à l’origine de la plupart des transferts sensibles, car son travail concerne du code, des dossiers clients ou des documents juridiques.

La mesure de l’identité nécessite également un dénominateur clair. Les organisations devraient rendre compte séparément des utilisateurs, des sessions, des transferts et des applications.

Le deuxième signal est le taux de données sensibles entrant dans les services d’IA. Cela comprend les textes collés, les téléversements de fichiers, les saisies dans des formulaires, les extensions de navigateur et les requêtes API.

Une mesure utile distingue les tentatives bloquées des transferts effectués. Elle sépare aussi les comptes d’entreprise approuvés des identités personnelles et inconnues.

Si les transferts sensibles effectués diminuent tandis que l’usage légitime de l’IA augmente, la gouvernance s’améliore. Si seules les tentatives bloquées augmentent, les employés se heurtent peut-être simplement à davantage de friction.

Les équipes de sécurité devraient également examiner où les utilisateurs se dirigent après un blocage. Un avertissement qui redirige le travail vers un assistant approuvé est plus utile qu’un avertissement qui met fin au flux de travail.

L’objectif sous-jacent n’est pas de produire un plus grand nombre de violations de politiques. Il est de réduire les expositions inutiles tout en préservant un travail précieux.

Les organisations peuvent soutenir cet objectif en donnant aux employés des moyens contrôlés de rechercher, résumer et relier leurs propres documents. Un second cerveau local peut limiter les copies répétées entre des services sans rapport.

Le troisième signal est le profil d’autorisations attribué aux agents d’IA. Les entreprises ont besoin d’un inventaire indiquant quels systèmes chaque agent peut lire, écrire et déclencher.

L’accès en lecture seule présente un niveau de risque. L’autorisation d’envoyer des messages, de mettre à jour des données financières, de modifier du code ou d’approuver des transactions en présente un autre.

Les entreprises devraient surveiller les réductions d’accès par défaut, les périodes d’autorisation plus courtes, les journaux au niveau des actions et les barrières d’approbation pour les commandes importantes.

C’est là que la visibilité sur les API devient décisive. Un agent agit souvent par l’intermédiaire d’API, même lorsqu’un utilisateur commence la tâche dans un navigateur.

Les équipes de sécurité doivent relier l’identité humaine, l’identité de l’agent, la requête au modèle, l’appel d’outil et l’action métier qui en résulte. Un journal déconnecté pour chaque composant ne peut pas reconstituer la décision complète.

Ce signal renforcera la thèse d’Akamai si les entreprises découvrent de nombreux agents inconnus ou des autorisations excessives. Il l’affaiblira si les inventaires montrent des accès limités, surveillés et intentionnels.

Les annonces de produits méritent moins de poids que les données opérationnelles. Les fournisseurs continueront de lancer des passerelles d’IA, des navigateurs sécurisés, des pare-feu de modèles et des systèmes de contrôle des agents.

La vraie question est de savoir si ces produits modifient les comportements. Une baisse de l’utilisation de comptes inconnus et des transferts de données sensibles constituerait une preuve plus solide que le nombre de déploiements.

Les dirigeants devraient également surveiller la satisfaction des employés à l’égard des outils approuvés. Une faible utilisation peut signaler un contrôle efficace, mais elle peut aussi indiquer que les employés ont cessé d’utiliser toute IA utile.

Un programme mature mesure à la fois la sécurité et l’utilité. Les résultats pertinents comprennent l’accomplissement des tâches, l’adoption, les taux d’erreur, le temps de revue, les exceptions aux politiques et les incidents confirmés.

La décision à laquelle font face les entreprises n’est pas de savoir si les employés utiliseront l’IA. Ce comportement s’est déjà répandu via les navigateurs, les suites logicielles et les environnements de développement.

La décision est de savoir si les systèmes officiels deviennent suffisamment utiles pour ramener cette activité vers des canaux visibles. Les équipes de sécurité ne peuvent pas gouverner ce qu’elles ne peuvent pas voir.

L’avertissement d’Akamai devrait donc entraîner un examen direct. Quels comptes d’IA sont actifs, quelles informations leur parviennent et quels agents peuvent agir sur les systèmes de l’entreprise ?

L’affirmation tronquée de Google News nécessite encore sa méthodologie complète avant que les lecteurs ne considèrent « près de la moitié » comme un taux universel. Les éléments de contexte étayent déjà une conclusion plus nuancée.

L’adoption de l’IA en entreprise a dépassé les contrôles traditionnels des comptes et des applications. Les organisations qui combleront cet écart rendront le parcours approuvé plus simple, instrumenteront le navigateur et limiteront les autorisations des agents.

Commencez par un audit pratique ce mois-ci. Mesurez les sessions d’IA gérées par rapport aux sessions personnelles, identifiez les transferts sensibles et recensez chaque agent disposant d’un accès en écriture. Ces trois vues révéleront si la gouvernance de l’IA existe dans les opérations ou uniquement dans les politiques.