La gouvernance des agents IA est désormais une question de preuves

Un agent d’IA qui accède à des données sensibles doit être encadré comme l’employé qui l’a autorisé, et beaucoup d’organisations ne sont pas encore en mesure de prouver qu’elles le font. Le problème ne vient pas d’un manque de règles, mais d’un manque de preuves que ces règles ont bien été appliquées au moment où un agent lit, déplace ou modifie une donnée.

Une enquête menée par Foundry et Rubrik, relayée dans un BrandPost sponsorisé par Rubrik et publié le 29 octobre 2026 sur CIO, quantifie ce constat. Sur 200 décideurs IT et IA interrogés, 38 % déclarent que des agents ont exfiltré des données ou provoqué une fuite de données sensibles, et 42 % citent la gouvernance, les garde-fous et la conformité comme des obstacles à la mise en place d’agents. Interprétez ces chiffres avec prudence, car la source est sponsorisée et l’échantillon limité, mais ils s’inscrivent dans la lignée d’autres études publiées ces six derniers mois.

Pour un RSSI, un Chief Compliance Officer ou un Data Protection Officer, la question est celle que posera un régulateur. Qui était l’utilisateur, sous quelle autorité l’agent a-t-il agi, et où est le journal d’audit ? Cet article distingue ce que l’enquête Foundry et Rubrik permet ou non d’affirmer, la compare aux résultats d’EY et d’autres acteurs, et détaille le « package de preuves » qui permet à une organisation de gouverner agents et humains selon un même ensemble de règles. Il explique aussi comment Kiteworks Compliant AI et le Control Plane Kiteworks interviennent lorsque la preuve doit être produite au niveau de la donnée.

Résumé des points clés

1. Le signal de l’enquête est réel, mais la source est sponsorisée.

Une enquête sponsorisée par Rubrik auprès de 200 décideurs rapporte que 38 % confirment une fuite causée par un agent, ce qui doit inciter à tester vos propres contrôles, sans en faire une référence sectorielle.

2. L’autonomie se gère, l’absence d’attribution non.

Les agents constituent une seconde catégorie d’identités à gouverner au même titre que les humains, chaque action devant être rattachée à une personne responsable.

3. La gouvernance est le principal point de blocage identifié.

Les recherches d’EY et d’autres montrent que les règles existent, mais que le contrôle opérationnel et la responsabilisation accusent un retard.

4. Les règles existantes sur les données s’appliquent déjà aux agents.

HIPAA, RGPD et les réglementations sectorielles ne prévoient aucune exception pour les accès automatisés aux données réglementées : la preuve attendue pour un agent est la même que pour un humain.

5. La preuve prévaut sur l’intention.

Les organisations capables de produire rapidement un historique unifié et attribuable des accès agents aux données répondront à des demandes auxquelles d’autres ne pourront pas répondre.

Ce que dit l’enquête Foundry et Rubrik

Le BrandPost indique que les agents agissent en totale autonomie (26 %) ou en autonomie limitée (35 %). Il précise que 42 % citent la gouvernance, les garde-fous et la conformité comme obstacles à la mise en œuvre d’agents, et que 24 % considèrent la sécurité et la gouvernance comme le principal frein à leur déploiement à grande échelle. 38 % confirment qu’un agent a exfiltré des données ou causé une fuite de données sensibles, et près de la moitié ont déjà été confrontés à un agent ou chatbot diffusant des informations fausses ou erronées.

Voici les limites à garder en tête. L’article est un BrandPost sponsorisé par Rubrik, un fournisseur de solutions de gouvernance et de récupération pour agents, et il ne précise ni la période de l’enquête ni la méthode de sélection des répondants. Un échantillon de 200 personnes ne permet pas de tirer des conclusions sectorielles. Le chiffre de 38 % repose sur les déclarations des répondants, et l’article ne définit pas ce qu’est une fuite ni comment elle a été confirmée.

Ces limites ne rendent pas ces résultats inutiles. Elles en font une hypothèse à tester dans votre propre environnement. Si près de deux répondants sur cinq affirment avoir déjà constaté une fuite par un agent, la question pour les autres est de savoir s’ils le sauraient. Une fuite non détectée n’apparaît dans aucune enquête.

L’analyse la plus utile est structurelle. Les répondants donnent aux agents une réelle autonomie tout en désignant la gouvernance comme principal obstacle. Ces deux faits décrivent un programme qui avance plus vite que sa capacité à produire des preuves.

L’autonomie n’est pas le problème, l’attribution si

On pourrait voir dans les 26 % d’autonomie totale un signal d’alerte, comme si les agents agissaient sans contrôle. La vraie question est de savoir si chaque action autonome peut être reliée à un humain responsable et à une règle de gouvernance. Un agent agissant dans le cadre d’une délégation documentée est normal dans le monde du travail moderne. Un agent agissant sans délégation enregistrée pose un problème de conformité.

L’enquête d’EY va plus loin. Dans l’AI Risk and Governance Survey d’EY aux États-Unis, publiée le 15 septembre 2026, 85 % des utilisateurs d’IA agentique déclarent exploiter au moins quelques systèmes agentiques sans intervention humaine en temps réel. L’enquête cible des décideurs IA de grandes entreprises américaines cotées, générant au moins un milliard de dollars de chiffre d’affaires. EY est aussi un cabinet d’audit ayant un intérêt sur le sujet.

L’intervention humaine en temps réel n’est pas le bon critère de contrôle. Personne ne vérifie chaque requête d’un collaborateur de confiance dans une base de données. Ce qui rend cela acceptable, c’est que l’employé dispose d’une identité unique, d’un rôle, d’autorisations adaptées à sa mission et d’un journal d’audit retraçant ses actions. La même architecture doit s’appliquer aux agents. Un agent est une seconde identité, gouvernée par les mêmes règles, et l’humain qui l’autorise reste responsable.

Ce cadrage change la conception à adopter. L’objectif n’est pas de ralentir les agents pour qu’un humain valide chaque action, mais de garantir qu’un agent ne puisse jamais dépasser les droits de l’utilisateur qui l’a autorisé, que chaque action lui soit attribuée et que l’historique ne puisse être modifié discrètement. Si ces conditions sont réunies, l’autonomie devient un atout de productivité. Sinon, elle crée un accès non tracé.

La gouvernance est le principal point de blocage, et l’audit trail en est le révélateur

Les 42 % qui citent la gouvernance comme obstacle décrivent une réalité que les données d’EY expliquent. La même enquête EY révèle que 98 % des répondants déclarent avoir des règles formelles de gouvernance IA, et 69 % une politique unifiée, mais 47 % reconnaissent avoir déjà contourné leur processus de gouvernance IA pour un déploiement urgent. Parmi les utilisateurs d’IA agentique, 49 % estiment que leur cadre de gouvernance n’a pas été spécifiquement adapté aux risques liés à l’IA agentique.

En croisant ces chiffres, un schéma se dessine. Les règles existent. Leur application sous pression est inégale. Le cadre a été conçu pour une IA qui produit des résultats, mais n’a pas encore intégré l’IA qui agit. C’est la même distinction que fait un RSSI entre un document de politique et un contrôle opérationnel.

La question de la preuve fait de ce sujet un enjeu de conformité. Un auditeur ne demande pas si vous avez une politique IA, mais de montrer un échantillon d’actions d’agents sur des données sensibles, l’identité utilisée, la règle qui l’a permis et le journal qui le prouve. Si la réponse prend des semaines à assembler, la politique n’est pas opérationnelle pour l’audit.

Le rapport annuel 2026 de Kiteworks sur la sécurité des données et les risques de conformité a mesuré ce décalage auprès de 459 répondants dans plusieurs régions. Seul un quart environ (27 %) peuvent produire un historique d’audit IA complet en une journée ouvrée, et seulement 17 % en une heure. Ces chiffres sont auto-déclarés dans une enquête fournisseur à échantillon mixte, mais ils confirment la tendance observée par EY. Les règles sont répandues, la preuve à la demande ne l’est pas. Combler ce fossé est au cœur de tout programme sérieux de gouvernance des données IA.

Visibilité et réversibilité : les angles morts

Si la gouvernance est l’obstacle principal, la visibilité et la récupération sont les angles morts. Rubrik Zero Labs a publié une autre étude, plus large, The State of the Agent, le 16 avril 2026, menée auprès de plus de 1 600 responsables IT et sécurité. Elle indique que 86 % s’attendent à ce que les agents dépassent les garde-fous de sécurité en moins d’un an, que 23 % déclarent avoir une visibilité totale sur les agents présents dans leur environnement, et que 88 % ne peuvent pas revenir en arrière sur les actions d’un agent sans perturber les systèmes. Le communiqué précise que le chiffre sur la visibilité est probablement surestimé.

Il s’agit du même fournisseur que pour l’enquête CIO, donc ce n’est pas une validation indépendante des chiffres Foundry et Rubrik. C’est un autre point de vue du même acteur, avec un échantillon plus large, mais peu de détails méthodologiques. À considérer comme une perspective fournisseur, à pondérer en conséquence.

Cet éclairage illustre l’enjeu de conformité lié à la réversibilité. Si un agent modifie ou expose une donnée, l’organisation doit savoir quelles données, sous quelle autorité, et à quel moment. Restaurer sans attribution règle le problème technique, mais pas la question légale. Les régulateurs veulent savoir ce qui s’est passé et pour qui, pas seulement si le système a été restauré.

Pour le Chief Compliance Officer, la leçon est que les incidents impliquant des agents requièrent la même traçabilité que ceux impliquant des humains. Le journal d’audit doit donc mentionner l’agent, l’utilisateur autorisant, la donnée concernée, la règle appliquée, et être consultable au même format que tout autre historique d’accès.

Agents autorisés et outils non validés : deux portes vers la même donnée

L’enquête Foundry et Rubrik décrit des agents que l’organisation a choisi de déployer. Un autre risque provient d’outils qu’elle n’a jamais validés. Compliance Week rapportait le 29 octobre 2026 que les régulateurs et autorités nationales s’inquiètent du risque que courent les entreprises en adoptant des outils d’IA chinois moins chers, ou des logiciels open source qui en dépendent. Le texte visible évoque des préoccupations de sécurité nationale, de cybersécurité et de protection des données, indique que ces outils pourraient ne pas répondre aux normes européennes ou américaines, et alerte sur le risque que les données saisies soient conservées et utilisées par les autorités chinoises. L’article complet est réservé aux abonnés, donc cette analyse s’appuie uniquement sur l’introduction, sans chiffres.

L’enjeu pour un responsable conformité ne concerne pas un fournisseur ou un pays en particulier. Une organisation peut perdre le contrôle de données sensibles via un outil d’IA non validé, ce que l’on appelle généralement le shadow AI. Un agent autorisé qui fait fuiter des données et un outil non validé qui les conserve sont deux portes vers la même pièce, et la question du régulateur est identique : quelles données sont sorties, via quel outil, sous quelle autorité, et où est la preuve ?

Un BrandPost sponsorisé par SailPoint, relayé par CIO, donne un nom à ce phénomène. Il définit le déficit de confiance en IA comme le fait de déployer des agents autonomes plus vite qu’on ne peut prouver qu’ils agissent dans le cadre des règles. Il cite une étude Omdia selon laquelle plus de la moitié des entreprises déploient déjà de l’IA agentique, et rapporte les propos de Mike Kiser (SailPoint) selon lesquels l’innovation IA a dépassé la sécurité IA. SailPoint est un fournisseur de solutions de sécurité des identités, il s’agit donc d’un contenu sponsorisé, à considérer comme une perspective, pas comme un constat. Cette définition reste utile, car elle rattache le problème à la preuve, et non à l’existence d’une règle.

Notez la nature du déficit de confiance : il ne s’agit pas d’affirmer que les agents sont dangereux, mais que l’organisation ne peut pas prouver qu’ils agissent dans le cadre des règles. C’est un problème de preuve, que le journal d’audit et le contrôle au niveau de la donnée sont conçus pour résoudre. Que la porte soit un agent autorisé ou un outil non validé, la solution commence par la discipline consistant à savoir quelles données chaque outil peut atteindre et à enregistrer chaque accès.

La question de la responsabilité reste floue, et c’est le vrai risque

Demandez à trois responsables d’une même organisation qui est chargé de la sécurité des agents IA, et vous obtiendrez trois réponses différentes. Cette ambiguïté est un risque en soi, et les données d’EY montrent ce qu’elle peut coûter. EY indique que 26 % des utilisateurs d’IA agentique ne peuvent pas détecter d’agents IA non autorisés dans leur organisation, et une fonction qui ne voit pas un agent ne peut en être responsable.

Un vide de responsabilité est la pire situation pour produire des preuves, car il faut un responsable pour chaque question. Si le CIO déploie l’agent, le RSSI sécurise la plateforme et le Chief Compliance Officer répond au régulateur, personne ne détient la preuve reliant les trois. Lorsqu’une enquête arrive, chacun n’a qu’un fragment.

La solution est d’abord organisationnelle, avant d’être technique. Désignez un responsable unique de l’accès aux données par les agents, donnez-lui autorité sur le journal d’audit, et faites du RSSI et du Chief Compliance Officer des utilisateurs du même historique. Le Chief AI Officer ou le CIO peuvent piloter l’adoption et la rapidité, mais la norme de preuve doit être fixée par ceux qui rendent des comptes aux régulateurs, et une structure claire de gouvernance, gestion des risques et conformité évite que les rôles ne s’éloignent.

Les règles existantes sur les données s’appliquent déjà aux agents

Le cadre réglementaire ne considère pas un agent comme une catégorie à part. HIPAA ne fait pas de distinction entre un clinicien et un agent IA qui consulte un dossier. Les obligations de sécurité et de responsabilité du RGPD s’appliquent qu’il s’agisse d’un humain ou d’un système, et l’article 22 ajoute des limites aux décisions entièrement automatisées. La question reste la même : l’accès aux données sensibles était-il autorisé, limité au strict nécessaire et enregistré ?

La Security Rule d’HIPAA illustre ce principe. 45 CFR 164.308(a)(1)(ii) impose aux entités concernées de réaliser une analyse de risque précise et approfondie, et de mettre en place des procédures pour examiner régulièrement les historiques d’activité des systèmes d’information, ces deux exigences étant obligatoires. Aucune ne précise qui ou quoi effectue la lecture. Un agent qui consulte des dossiers patients déclenche les mêmes obligations au titre de la Security Rule HIPAA que tout autre utilisateur : il doit donc figurer dans l’analyse de risque et pouvoir être retrouvé dans les historiques d’activité.

La même logique s’applique dans les services financiers, où les règles de protection et de sécurité des données s’appliquent, qu’il s’agisse d’un humain ou d’un agent, et dans le domaine juridique où le secret professionnel s’attache à l’information, pas à l’outil. Le point commun est qu’un agent IA est un nouveau moyen d’accéder à des données réglementées, pas une nouvelle catégorie d’activité réglementée.

C’est l’argument le plus fort pour gouverner au niveau de la donnée. La gouvernance du modèle compte pour la précision et les biais, mais le risque de conformité se situe là où la donnée est consultée, utilisée ou échangée. Si vous pouvez gouverner et tracer cet accès pour chaque identité, humaine ou agent, la preuve suit.

Gouverner la donnée pour humains et agents ensemble

Kiteworks Compliant AI repose sur un principe : gouverner la donnée, pas le modèle. Concrètement, les contrôles protégeant le contenu sensible pour les utilisateurs humains s’appliquent aussi lorsqu’un système d’IA y accède. Le serveur Kiteworks Secure MCP connecte les clients IA au contenu d’entreprise sous héritage role-based et attribute-based access control, empêchant un client IA de dépasser les autorisations de l’utilisateur qui l’a validé. L’authentification utilise OAuth 2.0 avec PKCE, et chaque action est tracée à l’utilisateur autorisant l’agent.

Toutes ces actions sont consignées dans le même journal d’audit unifié qui trace la messagerie électronique, le partage de fichiers, SFTP, les formulaires et le transfert sécurisé de fichiers, avec des flux vers un SIEM pour la corrélation. Le Data Policy Engine applique les règles de données de façon cohérente, et le CISO Dashboard offre une vue globale à la direction sécurité. Le Control Plane Kiteworks gouverne l’accès, l’utilisation et l’échange de données pour humains et agents sous un même ensemble de règles, un modèle d’identité unique et un seul journal d’audit.

Deux limites sont à rappeler. Un contrôle au niveau de la donnée ne remplace ni l’analyse de risque, ni le comité de gouvernance IA, ni le responsable désigné, qui restent des responsabilités humaines. Et il ne gouverne que le contenu sensible circulant dans l’échange de données sécurisé Kiteworks ; les agents ayant un accès direct à d’autres sources de données doivent faire l’objet de contrôles spécifiques. Cette architecture réduit le nombre de points où assembler un « package de preuves », mais n’exonère pas de savoir où résident toutes vos données.

Construisez dès maintenant votre « package de preuves » pour les agents

Commencez par recenser les agents. Puisque 26 % des répondants à l’enquête EY ne peuvent pas détecter d’agents non autorisés, un registre est le premier contrôle à mettre en place : on ne gouverne que ce que l’on connaît. Notez chaque agent, l’utilisateur ou l’équipe l’ayant autorisé, les données accessibles et les systèmes connectés.

Puis, définissez la règle dans des termes vérifiables par un auditeur. Pour chaque agent, précisez quelles classes de données il peut lire, lesquelles lui sont interdites, et dans quelles conditions. Exprimez ces règles comme des politiques basées sur les attributs, qui suivent la donnée, et non comme des recommandations dans un document. Une règle qui n’existe que dans un PDF ne peut pas être prouvée comme appliquée.

Troisièmement, prouvez l’attribution. Sélectionnez un échantillon d’actions d’agents du mois écoulé et rattachez chacune à un utilisateur autorisant, une règle appliquée et une entrée dans le journal. Si un maillon manque, vous avez identifié le point faible avant l’auditeur. Répétez l’exercice chaque trimestre et archivez les résultats.

Quatrièmement, testez votre capacité de réaction. Organisez un exercice de crise simulant l’accès non autorisé d’un agent à des données. Mesurez le temps nécessaire pour identifier les données concernées, l’utilisateur autorisant et la faille de règle, puis comparez ce délai aux exigences réglementaires qui vous incombent.

Enfin, informez le conseil d’administration avec des preuves, pas des promesses. Un résumé d’une page listant les agents en production, les classes de données accessibles, le dernier test d’attribution et les exceptions en cours sera plus utile qu’un score de maturité. La question du conseil est de savoir si l’organisation maîtrise la situation, et la réponse doit venir des historiques.

Pour en savoir plus sur la gouvernance des agents IA et des utilisateurs humains sous une même règle et un même journal d’audit, réservez une démo personnalisée dès maintenant.

Ressources complémentaires

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