L’écart de gouvernance de l’IA agentique devient désormais un problème de conformité
Les organisations confient aux agents IA la capacité d’agir sur des données sensibles bien plus vite qu’elles ne mettent en place des contrôles pour encadrer ces accès. Un rapport d’un cabinet d’avocats spécialisé en droit du travail, une étude universitaire, un régulateur des marchés financiers, un fournisseur de dossiers médicaux et une équipe de cybersécurité cloud ont tous publié des conclusions similaires à quelques jours d’intervalle, dressant le même constat. La technologie passe de la suggestion à l’action, mais la capacité de surveillance ne suit pas le rythme.
Cet article rassemble ces éléments pour ceux qui devront en répondre : le RSSI et le Chief Compliance Officer. Le raisonnement est simple. Un agent IA capable de lire un dossier patient, de modifier un fichier ou d’interroger un modèle cloud est une identité à privilèges. Sa gouvernance ressemble à celle de toute autre identité privilégiée dans un modèle zero trust : une politique limite ses accès, et un registre retrace ses actions. La suite de cet article détaille les dernières preuves, les zones d’exposition et les bonnes pratiques pour adopter une posture défendable.
Résumé de l’article
1. Le déploiement devance la gouvernance.
Selon des chiffres Gartner relayés par un cabinet d’avocats, le déploiement d’agents IA va fortement augmenter alors que peu d’organisations estiment que leur gouvernance est adaptée.
2. Les agents font passer l’IA du conseil à l’action.
Dès qu’un assistant agit, la question ne porte plus sur la qualité du résultat mais sur l’accès et la traçabilité.
3. La transparence est limitée.
Une étude du MIT révèle que la plupart des entreprises IA communiquent peu sur les risques qu’elles génèrent, laissant aux clients la charge de leur propre analyse.
4. Les régulateurs vérifient désormais les affirmations sur l’IA.
Le directeur de l’application des lois de la SEC a indiqué que les déclarations exagérées sur les capacités IA seront examinées de près, d’où la nécessité de disposer de preuves à l’appui.
5. Le principe du moindre privilège est la solution pragmatique.
Google recommande, en cas de vol de credentials IA, de refuser toute autorisation non strictement nécessaire.
Ce que révèlent les dernières études sur le fossé à combler
Commençons par les chiffres qui illustrent le problème. Le rapport de Littler Mendelson sur l’IA agentique au travail indique que la technologie « fait passer l’IA en entreprise de la recommandation à l’action ». Selon l’enquête Gartner 2026 CIO and Technology Executive, le déploiement d’agents IA devrait passer de 17 % en 2026 à plus de 60 % en deux ans, et au moins 15 % des décisions opérationnelles quotidiennes devraient être prises de façon autonome par des agents IA.
Le même rapport indique que 74 % des organisations prévoient une utilisation modérée de l’IA dans les deux ans, mais seules 13 % estiment que leur gouvernance est adaptée. Il prévoit aussi que plus de 40 % des projets d’IA agentique seront abandonnés d’ici fin 2027, en raison du coût, d’une valeur business floue ou d’un manque de contrôle des risques. Ces chiffres, issus de Gartner et relayés par un cabinet d’avocats, sont à considérer comme des tendances. Ils reflètent cependant ce que constatent les équipes de sécurité : beaucoup d’enthousiasme, mais peu de visibilité sur les capacités réelles des agents.
Il faut décrire précisément ce fossé. Il ne s’agit pas d’un manque de politiques IA : beaucoup d’organisations en ont rédigé, et une bonne gouvernance des données en exige déjà plus. Le problème, c’est que la politique écrite et le contrôle effectif sont deux choses distinctes, et qu’un auditeur ou un régulateur s’intéresse au second. Littler propose un cadre appelé Decide, Design, Defend, qui résume bien la démarche. Décider ce que l’agent peut faire. Concevoir les contrôles qui l’imposent. Défendre la décision avec des preuves lorsqu’elle est contestée.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
Pourquoi un agent est une identité à privilèges
Il est utile de dépasser l’effet de nouveauté et de décrire un agent avec les termes de la sécurité. Un agent possède des credentials, se connecte à des systèmes, lit, écrit et envoie des données. Il agit sur des instructions, parfois issues de contenus non fiables. Toutes ces caractéristiques définissent une identité à privilèges, et tous les contrôles déjà appliqués à ces identités s’appliquent aussi ici. L’agent doit avoir un périmètre défini, une authentification non partagée, des décisions d’autorisation à chaque requête, et un journal retraçant ses actions dans un journal d’audit disponible sur demande.
La différence réside dans la vitesse et l’échelle. Un humain avec trop d’accès peut causer des dégâts lentement. Un agent avec trop d’accès peut le faire en quelques secondes sur des milliers de dossiers, sans rien signaler. Il faut donc se demander non pas si le modèle est précis, mais ce que l’agent est autorisé à manipuler et si vous pouvez reconstituer son activité. La réponse doit exister avant l’incident, car après, la preuve est là… ou non.
Un problème de visibilité se pose en amont. Impossible de gouverner des agents inconnus. La première étape opérationnelle, fondement de tout programme de gouvernance des données IA, consiste à inventorier les agents existants, les données auxquelles ils accèdent, leurs propriétaires et les connecteurs utilisés. Sans cette liste, tous les contrôles ultérieurs reposent sur des suppositions.
Un exemple dans la santé illustre l’ambiguïté
Un cas récent dans la santé rend ce point concret. Athenahealth a lancé une connexion baptisée athenaPatient MCP, selon HealthcareInfoSecurity, permettant aux patients d’autoriser Claude d’Anthropic à récupérer résultats d’analyses, traitements, diagnostics, allergies, vaccins, actes médicaux et plans de soins depuis leurs dossiers. Cette fonction est d’abord proposée aux abonnés Claude Pro et Max aux États-Unis, qui se connectent avec leurs identifiants du portail patient Athenahealth. Athenahealth précise que les patients peuvent révoquer l’accès à tout moment et que les informations partagées ne sont conservées que le temps de la session.
La question juridique est centrale. Athenahealth affirme que « HIPAA ne s’applique pas dans ce cas d’usage ». L’avocat Jordan Cohen (Akerman LLP) précise que HIPAA cesse généralement de s’appliquer une fois les dossiers transmis au patient. Rachel Rose cite la Texas House Bill 300, à la définition plus large, et recommande d’exclure les notes de psychothérapie et les dossiers soumis à la règle 42 CFR Part 2 de ces systèmes. Autrement dit, les experts ne s’accordent pas sur la protection HIPAA une fois qu’un patient autorise un assistant à accéder à ses données.
L’article cite une enquête Pew d’août 2026 montrant que 34 % des adultes américains ont utilisé un chatbot IA à des fins médicales, preuve que ce scénario est bien réel. Pour une organisation manipulant des informations médicales protégées, la leçon n’est pas de juger ce connecteur bon ou mauvais. Elle est que dès que des données sensibles transitent vers un assistant IA via une connexion, la question de la responsabilité, des règles applicables et de la traçabilité devient floue. Les équipes conformité doivent clarifier ces points par écrit avant tout transfert, et exclure les catégories à risque tant que ce n’est pas fait. La règle du minimum nécessaire HIPAA sert de référence pour limiter la quantité de données transférées.
La transparence est limitée : à vous de faire preuve de diligence
Si les fournisseurs communiquaient clairement sur leurs risques, la diligence des entreprises serait plus simple. Un rapport du MIT, basé sur des données début 2026, montre que ce n’est pas le cas. Il révèle que 62 % des 1 000 principales entreprises IA et 32 % du top 100 n’évoquent pas les risques potentiels. Celles qui le font ne citent que cinq catégories : discrimination, armes et cyberattaques, fraude et arnaques, perte de vie privée, et dévalorisation de la créativité humaine.
Les sociétés financières et d’assurance reconnaissent en moyenne 2,9 risques IA, contre 7,1 dans le secteur de l’information. Peu abordent les risques des systèmes multi-agents malgré leur adoption rapide. Peter Slattery (MIT FutureTech), co-auteur, note « qu’actuellement, la transparence est très faible ». L’article précise que la plupart des données sont antérieures à l’incident Hugging Face de juin, donc la situation a pu évoluer.
Conséquence pratique : un acheteur ne peut pas se contenter des déclarations publiques d’un fournisseur pour satisfaire ses propres régulateurs. L’entreprise doit constituer sa propre preuve : comment elle a évalué le risque, ce qu’elle a décidé, quels contrôles elle a mis en place. Ce dossier transforme la promesse du fournisseur en preuve interne. Il doit figurer dans votre dossier de gestion des risques supply chain, à côté de l’inventaire des agents et connecteurs.
Les régulateurs commencent à vérifier les affirmations
Le problème de transparence joue dans les deux sens. Le 30 octobre 2026, David Woodcock, directeur de l’application des lois à la SEC, a déclaré à Reuters et Law360 que l’agence surveille les déclarations IA des entreprises, selon le Debevoise Data Blog. Il a précisé que l’application des lois ciblera les sociétés cotées dont les déclarations « exagèrent les capacités IA », et signalé l’absence de mention de l’IA ou de ses risques dans des activités clés. Il a cité des affaires antérieures contre des sociétés privées pour avoir surestimé leurs capacités en IA et robotique, et prévoit des enquêtes similaires pour les sociétés cotées.
Les auteurs du blog Debevoise recommandent de revoir les documents destinés aux investisseurs pour détecter l’omission d’IA, de définir précisément les fonctions IA et agentiques, d’étayer les affirmations par des preuves, et d’utiliser des analyses de risques pour informer les déclarations. Le point commun avec le déficit de gouvernance, c’est la preuve. Une entreprise qui affirme que ses agents sont contrôlés doit pouvoir présenter la politique, les contrôles et les journaux. Une entreprise qui vante des fonctions IA avancées doit disposer de preuves. Sinon, la déclaration devient un risque.
Cela rejoint une leçon tirée d’autres domaines de la cybersécurité : l’exposition naît souvent de l’écart entre ce qui est déclaré et ce qui existe réellement. Cette logique s’applique désormais aux déclarations sur l’IA.
Des credentials IA volés illustrent le coût d’un accès trop large
Le dernier exemple illustre directement le coût d’autorisations excessives. Google Threat Intelligence Group et Mandiant ont analysé un schéma appelé LLMjacking, où des attaquants utilisent des clés API volées ou des endpoints exposés pour générer des frais IA cloud, selon BleepingComputer. Certaines victimes ont perdu plus de 100 000 $ en une journée, et le cumul a atteint 1 000 000 $ pour d’autres. Les attaquants revendent l’accès via des services appelés LLM mixers, dont Jet Night, qui propose un accès illimité pour 60 $ par mois.
Google identifie un cluster de menaces et une vulnérabilité dans LiteLLM, et son conseil est clair : « Refusez toutes les autorisations non strictement nécessaires, y compris l’accès aux services Cloud LLM. » Ici, le préjudice concerne la fraude à la facturation plus que le vol de contenu, donc il se situe au niveau de l’identité et des credentials. Cela illustre bien le principe : des credentials donnant accès aux services IA ont de la valeur, et plus leur périmètre est restreint, moins un attaquant peut en tirer profit.
Pour les agents manipulant des données sensibles, le même conseil s’applique, avec des enjeux accrus. Limitez chaque agent au strict minimum de données et d’actions, comme le recommandent les stratégies de protection des données zero trust, authentifiez-le comme une identité distincte et journalisez chaque requête.
Les cadres existants s’appliquent déjà à l’IA
L’erreur courante consiste à attendre une loi spécifique à l’IA avant d’agir. En réalité, plusieurs cadres déjà suivis par les organisations couvrent l’accès IA aujourd’hui. Les règles de confidentialité santé encadrent l’utilisation et la divulgation des données protégées. Les régulateurs financiers commencent à intégrer l’IA dans la gouvernance cyber, et la NYDFS Part 500 en est un exemple. Les régimes de protection des données comme le RGPD exigent déjà de savoir qui traite les données personnelles et sur quelle base, et un agent traitant ces données est soumis aux mêmes questions que tout autre sous-traitant.
L’essentiel n’est pas que chaque cadre cite les agents. La plupart ne le font pas. Mais les obligations sous-jacentes sont neutres technologiquement. Limiter l’accès au nécessaire, journaliser les accès, pouvoir expliquer qui a vu quoi : ces principes s’appliquent qu’il s’agisse d’une personne, d’un script ou d’un agent. Les équipes qui cartographient leur inventaire d’agents avec leurs obligations existantes verront que la majorité du travail leur est familière. Ce qui change, c’est le volume et la vitesse, d’où l’importance accrue de l’automatisation des contrôles et de la preuve.
Il faut aussi distinguer deux questions souvent confondues. La première : un agent est-il autorisé à agir ? (politique et accès). La seconde : l’organisation peut-elle prouver a posteriori ce qui s’est passé ? (preuve). Les programmes de gouvernance qui ne répondent qu’à la première laissent une faille si la seconde est posée, et l’intérêt affiché de la SEC pour la justification des déclarations IA montre que cette question va se poser de plus en plus.
Que doivent faire le RSSI et le CCO dès maintenant ?
Voici les étapes à suivre, classées selon la rapidité avec laquelle elles réduisent l’exposition, sans attendre de nouvelle réglementation.
Commencez par un inventaire. Listez chaque agent IA, assistant et connecteur utilisé, y compris ceux adoptés sans revue sécurité. Pour chacun, notez le propriétaire, les données accessibles, les credentials utilisés et la date d’approbation. C’est la base de tout le reste.
Ensuite, définissez ce que chaque agent peut faire et appliquez-le au point d’accès. Une politique écrite est un début. Une politique appliquée, évaluée à chaque requête selon l’identité, la donnée et l’action, constitue le contrôle. Appliquez le principe du moindre privilège et supprimez tout ce qui n’est pas strictement requis.
Puis, déterminez où les données réglementées peuvent ou non aller. Résolvez les ambiguïtés de type HIPAA par écrit selon votre contexte. Si les experts ne s’accordent pas sur la protection, gardez les catégories à risque hors du flux tant que la position n’est pas tranchée.
Après cela, testez votre capacité à reconstituer l’activité d’un agent. Choisissez-en un et demandez un historique complet de ses accès le mois dernier, par credential et selon quelle politique. Si cela prend des jours et plusieurs systèmes, c’est là qu’il faut agir en priorité.
Enfin, vérifiez vos communications externes. Comparez ce que vous avez déclaré à vos investisseurs, clients et régulateurs sur vos fonctions et contrôles IA avec les preuves disponibles. Corrigez tout écart avant qu’il ne soit découvert par d’autres.
Dernière habitude à instaurer : réviser l’inventaire à intervalles réguliers (par trimestre ou après tout changement majeur dans l’usage des agents) et consigner la revue. L’usage des agents évolue vite, avec de nouveaux connecteurs et cas d’usage entre deux audits. Un historique daté montre que la gouvernance est un processus vivant, et fournit au RSSI et au Chief Compliance Officer un support à présenter au conseil d’administration pour démontrer la gestion des risques IA.
Un test simple pour la gouvernance des agents
Un exercice utile pour une équipe sécurité ou conformité consiste à choisir un agent, assistant ou connecteur utilisé actuellement et à répondre à cinq questions simples : Qui l’a approuvé ? Quelles données peut-il atteindre ? Sous quelle identité agit-il ? Qu’a-t-il fait le mois dernier ? Qui contacter en cas de problème ? Ce sont les questions que poseront un régulateur, un auditeur ou un responsable d’incident, quel que soit le modèle sous-jacent.
La plupart des organisations trouvent facilement les deux premières réponses, mais peinent sur les trois suivantes. L’approbation et le périmètre sont généralement documentés au départ. L’identité, les traces d’activité et la propriété se diluent à mesure que le pilote devient dépendance. Selon Gartner (relayé par Littler), les agents prendront au moins 15 % des décisions quotidiennes de façon autonome, ce qui élargira le fossé entre ce qui a été approuvé et ce qui se passe réellement, à moins qu’un responsable ne s’en empare. Considérez cet exercice comme un contrôle récurrent, pas un audit ponctuel, et conservez les réponses sous une forme présentable à un examinateur.
Comment Kiteworks contribue à la gouvernance de l’accès IA
La partie du problème qui concerne l’accès IA à des contenus sensibles (fichiers, e-mails, dossiers) est celle où la gouvernance échoue le plus souvent, car l’accès s’effectue via une connexion hors des contrôles habituels. Le Kiteworks Secure MCP Server évalue chaque requête d’agent selon des contrôles d’accès basés sur les rôles et les attributs, et consigne l’activité des agents dans un journal d’audit unifié. Compliant AI applique la gouvernance au niveau des données, vérifiant l’identité authentifiée, la politique et le chiffrement avant la diffusion du contenu, et fonctionne avec les modèles IA compatibles MCP. Cela permet à l’équipe conformité de savoir précisément ce qu’un agent a manipulé.
La plateforme accompagne les démarches décrites ci-dessus, sans s’y substituer. Elle peut appliquer une politique et générer des preuves, mais l’inventaire des agents, les décisions de risque et les déclarations aux régulateurs restent de la responsabilité de votre organisation, et les auditeurs jugent si le contrôle répond à l’exigence.
Pour en savoir plus sur la gouvernance de l’accès IA aux contenus sensibles avec des preuves prêtes à l’audit, réservez votre démo sans attendre !
Foire Aux Questions
Les premiers outils produisaient surtout des recommandations, ensuite exécutées par une personne. Les agents agissent eux-mêmes, ce qui signifie qu’ils détiennent des credentials et prennent des initiatives. La question de conformité ne porte donc plus sur la qualité du résultat, mais sur ce que l’agent est autorisé à consulter et sur la capacité à prouver son activité. Un bon point de départ est le guide de gouvernance des données IA, à comparer à la gestion des autres identités à privilèges.
Les experts ne sont pas d’accord, et c’est là tout l’enjeu. Athenahealth affirme que la HIPAA ne s’applique pas dans ce cas d’autorisation par le patient, et un avocat d’Akerman précise que la HIPAA cesse généralement de s’appliquer une fois les dossiers transmis au patient. Un autre avocat cite la Texas House Bill 300 et recommande d’exclure les notes de psychothérapie et les dossiers soumis à la règle 42 CFR Part 2. Passez en revue les obligations de la HIPAA Security Rule applicables à vos systèmes et demandez l’avis de votre conseil avant tout transfert de données sensibles.
Considérez que vous devrez constituer vous-même le dossier de preuves. Une étude du MIT a révélé que 62 % des 1 000 principales entreprises IA n’évoquent pas les risques potentiels. Documentez votre évaluation de chaque fournisseur, vos décisions et les contrôles appliqués, et conservez-les dans votre dossier tiers. L’approche zero trust pour l’IA générative est un bon cadre pour ces contrôles.
Le directeur de l’application des lois a indiqué que l’agence examinera les déclarations susceptibles d’exagérer les fonctions IA, ainsi que l’absence de mention de l’IA ou de ses risques dans les activités clés. Le conseil est de définir précisément les fonctions et d’étayer chaque affirmation par des preuves. Conservez la preuve derrière chaque déclaration, appuyée par un journal d’audit des activités d’agents si besoin.
Appliquez le principe du moindre privilège. Google recommande de refuser toute autorisation non strictement nécessaire, y compris l’accès aux modèles cloud. Inventoriez les clés et agents utilisés, limitez leur périmètre, faites tourner les credentials et surveillez l’usage. Consultez le guide zero trust pour la confidentialité des données IA pour appliquer ce principe à l’accès aux données.
Ressources complémentaires
- Article de blog
Stratégies Zero Trust pour une protection abordable de la vie privée IA - Article de blog
Comment 77 % des organisations échouent sur la sécurité des données IA - eBook
Le fossé de la gouvernance IA : 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 vérifier si vous avez une politique IA. Ils veulent la preuve qu’elle fonctionne.