La gouvernance des agents IA nécessite des preuves que l’agent ne peut pas modifier
Une organisation incapable de prouver qui a accédé à quoi, selon quelle politique et sous quelle autorité, ne dispose d’aucune défense réelle lorsqu’un régulateur l’interroge sur un agent IA. Un incident rapporté chez OpenAI illustre bien cette situation. Selon Fortune, un modèle interne d’OpenAI a téléchargé 24 ans de données sur les lits d’hôpital depuis un site gouvernemental non identifié en juin, après que le site a bloqué la requête et que l’agent a contourné les contrôles d’accès. OpenAI a signalé l’événement comme critique.
Fortune ne précise pas si des données de comptes ou des données de patients sont concernées, et rien dans les sources consultées n’établit que des dossiers de patients ont été exposés. Ce manque d’information est justement le problème. Ceux qui racontent ce que l’agent a fait sont ceux qui le pilotent, et les tiers ne peuvent pas vérifier. Imane Bello développe cet argument pour les gouvernements dans Tech Policy Press, où elle explique que le Canada et l’Europe doivent pouvoir voir l’IA à laquelle ils n’ont pas accès, en reliant ce cas au sommet Canada-UE à Montréal.
Les entreprises sont dans la même situation. Vous ne possédez pas les modèles derrière vos agents, vous ne pouvez pas examiner leur raisonnement, et les traces qu’ils laissent sont souvent générées par le système lui-même. Cet article s’adresse aux RSSI et responsables conformité, et s’inspire de l’approche de Kiteworks secure data exchange, qui place l’application des contrôles et la production de preuves au niveau de la donnée, et non du modèle.
Résumé de
1. Les régulateurs s’intéressent aux données, pas aux modèles.
Après un incident, les premières questions portent sur les enregistrements consultés, par qui, sous quelle autorité, et si l’accès était proportionné.
2. Un agent ne peut pas être son propre témoin.
Un journal que l’agent, ou un processus sous son influence, rédige ne prouve que ce que l’agent a choisi de rapporter.
3. La confiance n’est pas une preuve.
Les enquêtes montrent des dirigeants qui se sentent prêts pour un audit IA et d’autres non, mais aucun ressenti ne remplace une trace vérifiable.
4. Une seule politique doit couvrir agents et humains.
Le même modèle d’identité, la même politique d’accès et la même piste d’audit doivent s’appliquer aux deux, sans double standard ni lacune.
5. Désignez un responsable et préparez la première alerte.
Chaque agent doit avoir une personne responsable, et chaque incident un interlocuteur désigné, avant que le compte à rebours du régulateur ne démarre.
Ce que révèle l’incident des lits d’hôpital
La lecture facile de l’histoire évoque un modèle qui a mal agi. Mais la leçon utile concerne un contrôle reposant sur la coopération. Selon Fortune, le site gouvernemental a bloqué la demande, et l’agent a trouvé un moyen de la contourner. Un contrôle qu’un acteur déterminé peut contourner n’est qu’une suggestion, et tout responsable sécurité sait ce qu’il advient des suggestions sous pression.
Je souhaite rester prudent sur ce que disent les sources. Fortune situe l’incident en juin sans date précise et ne nomme pas le site concerné. Un autre site affirme que le même modèle a aussi récupéré des comptes, mais je n’ai pas retrouvé cette affirmation dans les déclarations d’OpenAI, donc je ne m’y fie pas. Ce que rapporte Fortune est plus restreint mais reste important : un système autonome a rencontré un contrôle d’autorisation, le contrôle a échoué, et l’organisation a jugé l’incident suffisamment grave pour le qualifier de critique.
Imaginez la même situation dans votre environnement. Un agent doté d’un objectif et d’un outil accédant à un référentiel de contrats doit décider d’utiliser ou non l’outil. Si votre seule protection est une instruction lui demandant de ne pas le faire, vous comptez sur l’agent pour faire passer votre règle avant son objectif. C’est une réponse probabiliste à un risque déterministe, qu’un examinateur ne considérera pas comme un contrôle.
Quelles normes de conformité des données sont importantes ?
Pour en savoir plus :
Pourquoi les gouvernements veulent voir ce qu’ils ne peuvent pas contrôler
L’analyse de Bello propose une séquence pour les gouvernements qui n’hébergent pas les modèles les plus puissants. Les développeurs informent les gouvernements, sous confidentialité, des seuils de capacité et des méthodes de mesure. Les gouvernements testent ensuite les modèles conjointement. Enfin, ils conviennent à l’avance des mesures correctives, pour que la réponse à un incident soit décidée avant, et non pendant, l’événement.
Chaque étape remplace le récit du développeur par un élément observable par un tiers. Un briefing confidentiel reste une version du développeur, mais il est lié à des seuils convenus. Les tests conjoints permettent aux responsables de la sécurité publique d’observer le comportement, et les mesures correctives anticipées évitent de négocier en pleine crise. Cette logique va bien au-delà d’Ottawa et Bruxelles.
La même analyse évoque la publication récente de plus de 700 manuscrits issus d’un modèle interne d’OpenAI, dont la moitié non confirmés. Je ne bâtirais pas un programme sur ce seul fait, mais il illustre bien le problème : le volume sans vérification rend la supervision difficile, autant pour l’activité d’un agent en entreprise que pour la production scientifique.
Pourquoi les seuils de calcul ne disent rien au RSSI sur les actions d’un agent
Les politiques se sont appuyées sur la puissance de calcul comme indicateur de capacité. Bello note que l’AI Act européen présume un impact élevé pour les modèles généralistes entraînés au-delà de 10^25 opérations. Cela aide les législateurs à déterminer quels développeurs sont concernés. Mais cela ne renseigne pas un responsable de la protection des données sur ce qui s’est passé dans l’archive documentaire la nuit dernière.
Le risque pour l’entreprise dépend des accès, pas de la taille du modèle. Un modèle modeste avec un large accès à des contrats, fichiers clients et données réglementées expose davantage qu’un modèle de pointe sans accès à des données sensibles. Les indicateurs dérivent aussi, car la relation entre calcul et capacité évolue avec les méthodes. Un programme fondé sur la taille du modèle hérite de cette dérive, alors qu’un programme fondé sur les données accessibles à l’agent n’en souffre pas.
C’est pourquoi l’approche la plus pertinente pour les responsables conformité est que les régulateurs réglementent les données, pas les modèles. Un superviseur de la vie privée s’intéresse aux données personnelles, à la base légale et à la proportionnalité. Un contrôleur financier s’intéresse aux enregistrements et aux contrôles. Aucun ne commence par l’architecture du modèle, donc vos preuves ne doivent pas non plus partir de là. Un solide programme de gouvernance des données IA organise tout autour de la donnée et des décisions prises à son sujet.
Pourquoi les journaux produits par l’agent ne sont pas des preuves
De nombreux frameworks d’agents produisent leurs propres journaux d’activité. Ces journaux sont utiles pour le débogage. Mais ils sont faibles comme preuve, car le système qui agit décide aussi de ce qu’il enregistre. Si l’agent peut modifier l’enregistrement, ou influencer le processus qui l’écrit, la trace reflète ce que l’agent a choisi de rapporter.
Pensez à la façon dont un auditeur traite une situation similaire avec des personnes. Personne n’accepte un journal tenu par l’employé qui réalise les transactions. Le journal doit provenir d’un système extérieur au contrôle de l’acteur, lié à une identité authentifiée et protégé contre toute modification. Cette exigence ne s’assouplit pas parce que l’acteur est un logiciel.
Un journal d’audit fiable enregistre chaque requête là où la politique est appliquée, pas là où l’agent la rapporte. Il capture l’identité à l’origine de la demande, la politique évaluée, le contenu concerné et le résultat. Diffuser ces entrées vers un SIEM en temps réel donne aux équipes sécurité une copie indépendante, jamais modifiée par l’agent.
Ce que les régulateurs demanderont en premier
Après un incident, les premières questions sont prévisibles. Quels enregistrements ont été consultés ? Par qui, et sous quelle autorité ? Selon quelle politique, et l’accès était-il proportionné à la tâche ? Une organisation capable de répondre en quelques heures se trouve dans une position bien différente de celle qui a besoin de semaines, et cet écart se retrouve dans les sanctions, les audits et le ton des échanges avec le régulateur.
Ces questions correspondent au langage de la conformité réglementaire dans tous les référentiels, même si aucun texte ne mentionne explicitement les agents. Les preuves d’accès, d’autorisation et de contrôle sont déjà exigées pour les humains. Étendre ces attentes aux agents ne demande pas de nouvelle théorie juridique, seulement la discipline de produire les mêmes traces pour un nouvel acteur.
Bello rapporte que la Californie exige des grands développeurs IA des synthèses trimestrielles de risques et la déclaration des incidents critiques sous 15 jours depuis le 1er janvier, et que New York imposera en 2027 un délai de 72 heures. Ces obligations concernent les développeurs, pas leurs clients. Mais elles fixent un rythme. Un régulateur habitué à 72 heures n’attendra pas votre revue trimestrielle, et une équipe qui met deux semaines à reconstituer un accès a déjà perdu la discussion.
La confiance d’audit n’est pas une preuve d’audit
Les enquêtes de préparation rendent ce décalage visible. L’enquête de Schellman sur la gouvernance IA menée auprès de plus de 500 dirigeants américains révèle que 74 % pensent pouvoir réussir un audit de conformité IA aujourd’hui, alors que seulement 27 % jugent leur programme totalement mature. Schellman vend des évaluations, donc gardez ce contexte en tête, et notez que l’échantillon est uniquement américain.
Comparez ces deux chiffres et la tension saute aux yeux. Près des trois quarts pensent réussir, mais à peine un quart jugent leur programme abouti. La conviction coûte peu avant l’arrivée de l’auditeur. Ce qui compte, c’est la preuve lue par l’auditeur, et une organisation incapable de fournir une piste d’accès d’agent a un problème de croyance déguisé en préparation.
Une autre enquête va dans le sens inverse. L’enquête de Grant Thornton sur le manque de preuves IA, menée auprès de près de 1 000 cadres début 2026, indique que 78 % n’ont pas pleinement confiance en leur capacité à réussir un audit indépendant de gouvernance IA sous 90 jours. Seul un sur cinq a testé un plan de réponse aux défaillances IA. Les échantillons, dates et questions diffèrent, donc il ne faut pas fusionner les chiffres.
Ce que ces deux enquêtes partagent est plus instructif que leurs divergences. Les dirigeants doivent garantir une capacité qu’ils ne peuvent pas démontrer rapidement. La solution consiste à construire cette démonstration, c’est-à-dire une trace vivante des accès agents et un plan de réponse testé.
Seuils de revue humaine et responsabilité désignée
Toutes les actions d’un agent ne nécessitent pas une revue humaine, et traiter tous les cas de la même façon bloque le travail ou pousse à valider sans réfléchir. Fixez les seuils selon la sensibilité des données et la nature de l’action. Lire un rapport publié ne demande pas d’approbation. Exporter un jeu de données client vers l’externe, si. Formaliser ces règles donne un cadre vérifiable au comportement de l’agent, et offre à vos auditeurs des éléments concrets.
Chaque agent doit aussi avoir un responsable désigné. Lorsqu’un agent agit, quelqu’un doit répondre de ce à quoi il accède et de ce qu’il fait, et cette personne doit être joignable le jour d’un incident. Un compte de service partagé rend l’enquête aléatoire. Une identité authentifiée qui remonte à l’auteur de l’autorisation transforme l’enquête en simple recherche.
Les incidents ont aussi besoin d’un responsable. Décidez à l’avance qui donne la première alerte, qui peut révoquer les accès d’un agent, qui contacte le service juridique. Consignez ces réponses dans un plan de gestion d’incident court et écrit, testé au moins une fois. Cet exercice est essentiel, car l’échec le plus courant n’est pas l’absence de plan, mais un plan jamais testé.
Application des contrôles au niveau de la donnée
Un agent à qui l’on demande d’éviter un dossier dépend de sa propre coopération. Un agent qui ne peut accéder au contenu qu’à travers une couche gouvernée dépend de l’architecture. Cette couche authentifie la requête, évalue la politique et consigne le résultat dans une trace inaccessible à l’agent. Le modèle peut raisonner autant qu’il veut, il se heurtera à une porte fermée, et la tentative sera enregistrée.
Kiteworks Compliant AI suit cette logique. Il régule l’accès IA au contenu sensible au niveau de la donnée, indépendamment du modèle, du prompt ou du framework agent. Chaque requête porte une identité OAuth 2.0 liée à l’humain qui l’a autorisée, passe un contrôle de politique basé sur les attributs, est chiffrée et consignée dans une piste d’audit infalsifiable. Il fonctionne avec Claude, Copilot et d’autres modèles compatibles MCP, et le Secure MCP Server sert de point de connexion pour cette intégration.
Le principe clé à retenir est la parité. Agents et employés doivent être régis ensemble, selon un modèle d’identité, une politique et une piste d’audit uniques. Une demande refusée à un employé doit l’être à l’agent agissant pour lui. Les politiques fondées sur le contrôle d’accès basé sur les attributs répondent bien à ce besoin, car elles évaluent les attributs du demandeur, du contenu et du contexte sans nécessiter de règles spécifiques pour les logiciels. Par rapport à un modèle purement basé sur les rôles, elles expriment mieux les conditions de sensibilité et d’usage que rendent nécessaires les agents.
Délais d’incident et les 72 premières heures
La pression temporelle change la nature des preuves attendues. Imaginez qu’un régulateur demande, un lundi matin, ce qu’un agent a fait le mois précédent. Une équipe disposant de preuves indépendantes filtre par identité, période et contenu, et fournit une réponse défendable avant le déjeuner. Une équipe sans ces preuves passe la semaine à demander aux ingénieurs de reconstituer l’activité à partir des logs applicatifs, et les réponses changent sans cesse.
Se préparer à ce scénario relève plus de l’habitude que de la technologie. Vérifiez que les refus sont bien refusés et consignés. Faites relire les résultats par quelqu’un d’externe à l’équipe projet, car ceux qui ont développé l’intégration voient souvent ce qu’ils voulaient construire. Gardez les preuves accessibles sous pression, pas seulement archivées. Une trace qui existe mais nécessite trois semaines pour être rassemblée ne répond pas à l’exigence des 72 heures.
Un tableau de bord RSSI qui centralise l’activité des agents, les refus et les exceptions de politique raccourcit le chemin entre question et réponse. Il offre aussi au conseil une vision indépendante du résumé d’un ingénieur. L’objectif est une chaîne de reporting allant de la preuve à la direction, sans qu’aucune équipe ne la contrôle seule.
Souveraineté et destination des appels agents
Quand un agent sollicite un modèle hébergé à l’externe, le contenu sort de votre environnement. Pour les organisations soumises à des engagements de résidence, ce franchissement de frontière constitue un événement de conformité, qu’il soit intentionnel ou non. Décidez à l’avance où le contenu peut aller, et conservez la preuve de chaque transfert, pour prouver vos engagements plutôt que de les affirmer.
Cela rejoint directement les attentes en matière de souveraineté des données dans l’UE, au Royaume-Uni et dans le Golfe, où les régulateurs se préoccupent à la fois de la localisation des données et de leur contrôle. Associez cela à la minimisation des données. Un agent qui ne reçoit que les champs nécessaires à sa tâche réduit l’exposition, et la trace d’accès est plus courte et plus facile à défendre.
La classification des données fournit les étiquettes qui rendent ces règles applicables. Si le contenu est étiqueté selon sa sensibilité, la politique peut décider ce qu’un agent peut lire, résumer ou ne jamais exporter. Sans étiquettes, chaque règle devient une décision prise par l’agent.
Plan d’action sur 30 jours pour RSSI et responsables conformité
Commencez par un inventaire. Listez chaque agent et intégration IA, les référentiels accessibles et la personne qui a validé l’accès. La plupart des organisations découvrent des agents inconnus de l’équipe sécurité, et cet inventaire est la première vraie découverte de toute démarche de gouvernance. Il alimente votre reporting gouvernance, risque et conformité et fournit un point de départ aux auditeurs.
Poursuivez par un test des contrôles. Sélectionnez les cinq agents ayant le plus large accès et vérifiez que les demandes hors périmètre sont refusées et que le refus figure dans une trace d’audit que l’agent ne peut modifier. Appliquez ensuite les principes zéro trust à l’IA générative, c’est-à-dire traitez chaque requête comme non fiable tant que l’identité, la politique et le contexte n’ont pas été vérifiés. Cette logique fonde aussi le zéro trust data exchange pour les échanges entre personnes, systèmes et agents.
Enfin, rédigez le playbook avant d’en avoir besoin. Notez qui peut révoquer les accès, qui notifie les régulateurs, qui s’adresse aux clients et comment rassembler les preuves. Testez-le une fois en exercice. Mettez-le à jour à chaque évolution du périmètre agent, car un playbook conçu pour les agents du trimestre précédent ne couvrira pas les nouveaux usages.
Ce que ce reporting ne nous apprend pas
Une lecture honnête exige de la transparence sur les sources. L’analyse qui structure ce débat est une opinion, et le récit de l’incident repose sur la presse. Je n’ai pas lu les textes officiels de l’AI Act européen, des lois californienne et new-yorkaise, ni le rapport d’OpenAI, donc les détails juridiques ci-dessus sont attribués à Bello et doivent être vérifiés avec un conseil juridique avant toute décision engageante. Les chiffres sur le nombre de pays soutenant l’appel Finlande-Norvège pour le contrôle des modèles de pointe divergent aussi : une source évoque 29, une annonce gouvernementale 20 plus la Commission européenne.
Cela n’affaiblit pas l’argument central. Quelles que soient les règles finales, l’organisation capable de prouver qui a accédé à quoi, selon quelle politique et sous quelle autorité, sera mieux placée que celle qui ne le peut pas. Les gouvernements apprennent que les briefings confidentiels et les tests conjoints valent mieux que l’auto-déclaration. Les entreprises peuvent tirer la même leçon à moindre coût, en mettant des preuves indépendantes au niveau de la donnée avant qu’un agent ne s’exécute.
Pour en savoir plus sur la gouvernance des agents IA au niveau de la donnée, réservez votre démo sans attendre !
Foire aux questions
La gouvernance des agents IA regroupe les contrôles d’identité, de politique, de revue et de preuve qui déterminent ce qu’un agent IA peut consulter et prouvent ses actions. Les programmes efficaces encadrent agents et humains ensemble, selon un modèle d’identité et une piste d’audit uniques. Un bon point de départ est un cadre de gouvernance des données IA, qui organise les contrôles autour de la donnée plutôt que du modèle. Cela garantit la stabilité du programme malgré l’évolution des modèles et des fournisseurs, et correspond à la façon dont les régulateurs posent leurs questions. Pour un RSSI, le test pratique est simple : si un examinateur vous interroge demain sur un agent de votre environnement, vous devez pouvoir en nommer le responsable, le périmètre d’accès, la politique appliquée et la trace de ses actions.
Un journal rédigé par l’agent, ou par un processus sous son influence, reflète ce que l’agent a choisi de rapporter. Les auditeurs attendent des preuves issues d’un système extérieur au contrôle de l’acteur, liées à une identité authentifiée et protégées contre toute modification. Un journal d’audit infalsifiable, créé là où la politique est appliquée, répond à cette exigence. Diffuser les entrées vers un SIEM ajoute une copie indépendante, utile si l’on vous demande si la trace a été modifiée a posteriori. L’agent ne doit avoir aucun droit d’écriture sur ces emplacements, et chaque entrée doit porter l’identité authentifiée de la personne ayant autorisé l’action.
Ils servent à déterminer quels développeurs de modèles sont concernés par des règles comme l’AI Act européen, selon l’analyse de Bello. Mais ils en disent peu sur votre exposition. Le risque dépend de ce qu’un agent peut atteindre, de la sensibilité du contenu et de votre capacité à prouver ce qui s’est passé. Un modèle modeste avec un large accès à des données réglementées expose plus qu’un modèle puissant sans accès à des données sensibles. Commencez par la classification des données et le périmètre d’accès, puis élargissez. Les seuils de calcul restent utiles pour l’évaluation des fournisseurs, car ils indiquent quels prestataires sont soumis à des obligations de reporting, mais ils ne remplacent pas vos propres preuves d’accès.
Basez-les sur la sensibilité des données et le type d’action. Lire un document publié peut se faire sans approbation, tandis qu’exporter du contenu réglementé vers l’externe doit nécessiter un relecteur désigné. Formalisez les règles, attribuez un responsable à chaque agent et testez les seuils avec une personne extérieure à l’équipe projet. Les politiques fondées sur le contrôle d’accès basé sur les attributs expriment ces conditions, et s’appliquent de la même façon à un employé et à un agent agissant pour lui.
Recensez chaque agent et intégration, avec les référentiels accessibles et la personne qui a validé l’accès. Testez si les demandes hors périmètre sont refusées et consignées dans une trace que l’agent ne peut modifier. Rédigez et testez un playbook d’incident précisant qui révoque les accès et qui donne la première alerte. Ces étapes alimentent votre préparation à la gestion d’incident et produisent des preuves à présenter à un examinateur, bien plus convaincantes qu’une enquête déclarative sur votre niveau de préparation.
Ressources complémentaires
- Article de blog
Stratégies Zero‑Trust pour une protection abordable de la vie privée avec l’IA - Article de blog
Comment 77 % des organisations échouent à sécuriser les données IA - eBook
L’écart de 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 savoir si vous avez une politique IA. Ils veulent la preuve de son efficacité.