Personne n’assume les conséquences lorsqu’un agent IA échoue

Huit dirigeants sur dix en Europe et au Moyen-Orient déclarent qu’un incident lié à l’IA a été porté à l’attention de leur conseil d’administration ou de leur direction générale au cours de l’année écoulée. Demandez à ces mêmes dirigeants qui sera responsable lors du prochain incident causé par un agent IA, et aucun poste ne recueille plus de 17 % des réponses.

Cette répartition provient d’une étude IBM publiée le 14 octobre 2026, menée auprès de 3 221 dirigeants via Censuswide dans des organisations de 1 000 employés ou plus au Royaume-Uni, en France, en Allemagne, en Italie, en Espagne, aux Pays-Bas, en Arabie Saoudite et aux Émirats arabes unis. Le terrain s’est déroulé du 14 au 24 septembre 2026. Le chiffre de 80 % d’incidents a fait la une. Mais l’élément le plus utile pour un RSSI ou un Chief Compliance Officer se trouve plus loin dans le rapport, dans les réponses sur la responsabilité lorsque les agents se trompent.

On parle ici d’un incident sans propriétaire. Le conseil d’administration a officiellement attribué la gestion du risque IA à quelqu’un, les agents continuent d’accéder à des données sensibles, et quand un incident survient, la chaîne de responsabilité se disperse en huit réponses différentes. C’est un problème de gouvernance, mais aussi un problème de preuve, car lorsqu’un régulateur demande qui a autorisé un agent à accéder à un dossier, il veut un nom et une trace, pas un comité. Kiteworks secure data exchange répond à cette seconde partie de la question, et cet article explique comment les deux aspects sont liés.

Résumé des points clés

1. Le nombre d’incidents n’est plus l’information principale.

Quatre-vingts pour cent des dirigeants interrogés déclarent qu’un incident lié à l’IA a été porté à l’attention de leur conseil d’administration ou de leur direction générale au cours de l’année écoulée. La question qui se pose désormais est de savoir ce que la direction peut prouver concernant sa réaction.

2. La responsabilité est fragmentée là où elle compte.

La responsabilité de l’IA au niveau du conseil d’administration est quasi universelle, mais aucun poste n’est cité par plus de 17 % des répondants lorsqu’un agent IA provoque un incident.

3. L’escalade informelle expose à un risque d’audit.

Plus d’un tiers des incidents portés à la direction l’ont été de façon informelle, ce qui laisse le Chief Compliance Officer sans trace de ce qui a été décidé et à quel moment.

4. Les contrats ne sont pas des contrôles.

La plupart des organisations encadrent l’IA de leurs fournisseurs par des clauses contractuelles et des droits d’audit, alors qu’une minorité seulement surveille en continu l’IA tierce ou exige une assurance indépendante.

5. Les obligations liées aux données n’ont pas changé.

Le calendrier de la loi européenne sur l’IA a évolué, mais les obligations de sécurité et de notification de violation du RGPD, ainsi que les exigences de reporting NIS 2, s’appliquent toujours à l’accès des agents.

Huit conseils d’administration sur dix ont déjà été confrontés à un incident lié à l’IA

Commençons par le chiffre que personne ne peut ignorer. Selon le rapport IBM « The New Realities of AI Governance », 80 % des dirigeants interrogés déclarent qu’un incident lié à l’IA a été porté à l’attention de leur conseil d’administration ou de leur direction générale au cours de l’année écoulée. Ce n’est plus un risque hypothétique sur une cartographie des risques, mais un point récurrent à l’ordre du jour.

Ce qui s’est passé ensuite est encore plus révélateur que le nombre d’incidents. Parmi les organisations où un incident a été porté à la direction, 43 % déclarent qu’il a fait l’objet d’un examen formel à ce niveau, tandis que 37 % évoquent une communication informelle. Relisez bien : plus d’un tiers du temps, un incident lié à l’IA est remonté au sommet de l’organisation par une discussion de couloir plutôt que via un processus de gouvernance.

Une escalade informelle ne laisse aucune trace exploitable lors d’un contrôle. Lorsqu’une autorité de contrôle demande comment la direction a été informée de l’incident, ce qui a été décidé et à quel moment, « on en a parlé » n’est pas une réponse qu’un Chief Compliance Officer peut présenter à un régulateur. L’examen formel constitue le contrôle. La mention informelle représente un risque.

Les conséquences listées dans le rapport sont tout aussi concrètes. Parmi les organisations où un incident a été remonté à la direction, 40 % évoquent une modification de la politique de gouvernance IA, 38 % une évolution des investissements ou des plans de déploiement, 37 % le recours à des conseillers externes, et 35 % une notification aux régulateurs. Prenez ces chiffres comme des tendances. Ils proviennent d’une enquête commandée par un fournisseur auprès de dirigeants en auto-déclaration, et couvrent huit marchés, pas le monde entier.

Cependant, le chiffre concernant les régulateurs mérite une attention particulière, car c’est le seul que l’autorité de contrôle peut vérifier dans ses propres dossiers. Plus d’un tiers des organisations ayant remonté un incident ont également échangé avec un régulateur. Pour les responsables de l’audit, cela fait passer la question de la preuve de « un jour » à « ce trimestre ».

La responsabilité du conseil existe, mais pas celle des agents

Sur le papier, la situation semble claire. L’enquête IBM révèle que 98 % des répondants ont officiellement attribué la gestion du risque IA au niveau du conseil d’administration, et 26 % disposent d’un comité IA dédié à ce niveau. Les structures de gouvernance sont en place presque partout.

Mais la question devient plus complexe : lorsqu’un agent IA provoque un incident, qui est responsable ? Le CIO ou le CTO arrive en tête avec 17 %, et aucun poste n’est cité par plus de 17 %. La responsabilité partagée au sein du comité de direction recueille 14,5 %, le chief risk officer ou chief compliance officer 14 %, un chief AI officer 13 %, l’équipe déployant l’agent 11 %, le fournisseur IA 10 %, un responsable métier 10 %, et le CEO 9 %.

Ce n’est pas un désaccord sur l’organigramme, mais l’absence d’organigramme. Un comité peut gérer une catégorie de risques, mais un incident nécessite une personne capable d’expliquer ce que l’agent a fait, sous quelle autorité et selon quelle politique. Huit réponses différentes, aucune majoritaire, montrent que la plupart des organisations n’ont pas encore attribué cette responsabilité.

Cette fragmentation doit être nuancée comme toute enquête. Une enquête IBM menée en 2026 auprès de dirigeants de huit marchés ne fait pas office de vérité sectorielle sur la gestion de la sécurité IA. D’autres études, selon les régions, placent le CIO, le CTO ou le RSSI en tête. Ce qui ressort, c’est la fragmentation elle-même.

Voici l’enjeu principal. Une responsabilité limitée au niveau d’un comité ne produit pas de preuve. La preuve se trouve dans la couche données, là où se rencontrent un autorisateur identifié, l’identité de l’agent, une décision de politique et une trace d’audit. Si cette chaîne existe, la question de la responsabilité repose sur des faits. Sinon, l’organisation débat de la faute pendant que le délai réglementaire court.

Le RSSI hérite généralement de ce vide, que son titre apparaisse ou non dans les réponses. C’est vers lui que le conseil se tourne en cas d’incident, ce qui fait de cette chaîne manquante un problème personnel autant qu’institutionnel.

Une gouvernance pensée pour l’humain s’étend désormais aux agents

Les agents sont déjà en production dans une part significative de ces organisations. IBM indique que 35 % exploitent des agents IA en production, et 75 % s’attendent à ce que les agents agissent sans validation humaine systématique d’ici 2027. Pourtant, seuls 37 % estiment que leur gouvernance est conçue pour évoluer avec le déploiement des agents, tandis que 45 % pensent qu’elle pourrait suivre, mais doit être renforcée.

En mettant ces chiffres en perspective, le problème devient clair. Le déploiement suit un calendrier. La gouvernance, une intention. Le rapport ajoute que 56 % poursuivent le déploiement dans les limites de risque convenues pendant que leur gouvernance s’adapte, et un tiers retardent le déploiement jusqu’à ce que la gouvernance soit prête. La majorité construit l’avion en plein vol.

Le terme « retard de gouvernance » est approprié. Il désigne l’intervalle entre le moment où un agent commence à accéder à des données réglementées et celui où les contrôles qui le régissent atteignent un niveau de preuve suffisant. Chaque jour dans cet intervalle génère des accès impossibles à reconstituer par la suite.

Une précision est importante pour la rédaction interne. « Sans validation humaine systématique » décrit une délégation, pas une indépendance. Un humain autorise le workflow, une politique définit ce que l’agent peut faire, et la trace d’audit enregistre les deux. Les agents rejoignent les humains comme nouvelle identité dans un même modèle de gouvernance. Ils ne remplacent pas la chaîne de responsabilité humaine, et un programme qui les traite comme des acteurs autonomes se trompe déjà de mission.

C’est aussi là que le coût de l’attentisme apparaît. Ajouter a posteriori l’identité, la politique et la traçabilité à des agents déjà en production revient à reconstruire une histoire jamais enregistrée. Intégrer les contrôles dès la couche données permet de gouverner chaque interaction agent dès la première requête. La gouvernance des données IA anticipée coûte moins cher qu’une reconstitution a posteriori.

Une responsabilité fragmentée exige une chaîne de preuve unique

Si la responsabilité est fragmentée, la chaîne de preuve doit être unique. C’est le principe qui résout le vide sans attendre que l’organigramme se stabilise.

Commencez par l’autorisateur. Chaque workflow agent doit remonter à une personne identifiée qui l’a délégué, comme l’accès d’un utilisateur humain remonte à son compte. Lorsque l’identité de l’agent est liée à celle de l’humain délégant, la question de la responsabilité trouve une réponse factuelle, quel que soit le poste qui finit par gérer le risque IA.

Vient ensuite la politique. Les règles basées sur le rôle déterminent ce qu’un poste peut voir, mais un agent agit sur plusieurs tâches, et un modèle uniquement basé sur le rôle accorde trop ou trop peu. Le contrôle d’accès basé sur les attributs évalue le profil de l’agent, la sensibilité des données, le contexte de la demande et l’opération demandée. Un agent autorisé à lire un dossier n’est pas automatiquement autorisé à le télécharger.

Puis vient la trace. Un journal d’audit infalsifiable qui enregistre qui a autorisé l’agent, quelles données il a consultées, selon quelle politique et à quel moment, transforme un incident en rapport. Cette différence est cruciale. Les régulateurs raisonnent en jours, et un dossier de preuve qui prend des semaines à assembler devient un constat d’échec.

Kiteworks Compliant AI gouverne l’accès des agents à la couche données selon ce modèle. Il vérifie l’identité de l’agent et la relie à l’autorisateur humain, évalue chaque demande selon une politique basée sur les attributs, applique un chiffrement validé FIPS 140-3 et consigne des traces d’audit infalsifiables. Le Kiteworks Secure MCP Server applique le même modèle aux clients IA comme Claude et Copilot, où chaque requête hérite des autorisations existantes de l’utilisateur via OAuth 2.0 et est enregistrée dans le même journal d’audit couvrant la messagerie électronique, le partage et le transfert de fichiers. Un seul journal d’audit pour tous les canaux, c’est l’essentiel. Cinq outils créent cinq angles morts.

L’angle mort fournisseur devient un angle mort d’audit

Le problème de responsabilité ne s’arrête pas à la frontière de l’entreprise. L’enquête IBM révèle que 54 % des dirigeants reconnaissent des lacunes dans la gouvernance de l’IA utilisée par les fournisseurs et partenaires de la supply chain.

Les contrôles privilégiés en disent long. Les clauses contractuelles arrivent en tête (43 %), suivies des droits d’audit (39 %), tandis que la surveillance continue du risque IA tiers atteint 21 % et l’assurance ou certification indépendante seulement 13 %. Les contrôles « papier » dominent, les contrôles observés sont loin derrière.

Une clause est une promesse. Un log est un fait. Quand l’agent d’un partenaire accède à vos données réglementées, le contrat dit ce qui aurait dû se passer, mais seuls vos propres journaux disent ce qui s’est réellement passé. Cette asymétrie constitue l’angle mort fournisseur, qui devient un angle mort d’audit dès qu’un examinateur demande l’historique d’accès à des données sorties de votre environnement.

Pour les organisations européennes, cette exposition est codifiée. La directive NIS 2 impose aux entités concernées de gérer la sécurité de la supply chain dans le cadre de leur gestion des risques cyber, et ses dispositions attribuent la responsabilité de l’approbation et du suivi de ces mesures à la direction. Concrètement, la gestion des risques tiers doit produire des preuves de ce que les partenaires et leurs agents ont fait avec vos données, pas seulement un questionnaire signé. Un programme mature de gestion des risques fournisseurs exige des journaux d’accès et des décisions de politique, puis vérifie leur existence avant qu’un régulateur ne le fasse.

Cette lacune a aussi un coût rarement visible dans un registre des risques. Si l’agent d’un fournisseur accède à vos données et que le journal ne vit que chez le fournisseur, votre capacité à répondre à un régulateur dépend de la rapidité de réaction du fournisseur et de la durée de conservation de ses logs. Rien de tout cela n’est garanti par une clause, surtout avec un délai de 72 heures.

L’AI Act a bougé, mais les obligations sur les données restent

Certains dirigeants verront dans le report du calendrier de l’AI Act européen un soulagement. L’AI Omnibus, résumé par le Future of Privacy Forum, reporte la date d’application des exigences à haut risque de l’annexe III du 2 août 2026 au 2 décembre 2027, et celle des systèmes de l’annexe I du 2 août 2027 au 2 août 2028. Le Parlement a adopté le texte le 16 juin 2026, le Conseil le 29 juin 2026, et il a été publié au Journal officiel le 24 juillet 2026.

Considérez cela comme un changement de calendrier pour une réglementation, pas une pause sur la gouvernance. IBM constate que 41 % des dirigeants européens de son échantillon accélèrent leurs investissements en gouvernance avant l’entrée en vigueur des obligations à haut risque, ce qui montre qu’ils ont bien compris le report. Ils utilisent ce temps pour construire, pas pour attendre.

La raison est simple : les régulateurs réglementent les données, pas les modèles. Le RGPD s’applique aux données personnelles, qu’elles soient traitées par une personne ou un agent logiciel, et ses obligations de sécurité (article 32) et de notification de violation sous 72 heures (article 33) ne dépendent pas du calendrier de l’AI Act. NIS 2 ajoute son propre délai de notification, avec une alerte précoce sous 24 heures et une notification complète sous 72 heures en cas d’incident majeur. Aucune de ces obligations ne prévoit d’exception pour les agents.

La question pratique pour un Chief Compliance Officer ou un Data Protection Officer reste donc la même. Si un agent accède à des données personnelles à deux heures du matin et qu’un problème survient, l’organisation peut-elle démontrer qui a autorisé l’accès, ce que l’agent a vu et selon quelle politique, dans le délai imposé par le régulateur ? Un DPO incapable de répondre à cette question est déjà exposé au RGPD, indépendamment de ce que l’AI Act prévoit pour 2027.

Que peuvent faire un RSSI et un CCO avant la prochaine réunion du conseil ?

Cessez de vous demander quel dirigeant doit gérer l’IA. Demandez-vous plutôt si chaque workflow agent a un propriétaire, une politique et une trace d’audit. Ce sont trois éléments vérifiables dès ce mois-ci, et ils restent valables quelle que soit l’évolution de la question managériale.

Premièrement, attribuez un autorisateur humain identifié à chaque workflow agent accédant à des données réglementées, et consignez cette attribution dans un système d’identité et un journal d’audit accessibles. Un comité qui gère le « risque IA » ne remplace pas une personne responsable de « l’accès de cet agent ». Lorsque les répondants IBM se dispersent sur huit postes, c’est généralement ce point qui manque.

Deuxièmement, réalisez un exercice de preuve. Sélectionnez un workflow agent et demandez à l’équipe de fournir, en quelques heures, l’historique complet d’accès pour un échantillon de ses actions, incluant l’autorisateur, les données consultées et la politique appliquée. Si la réponse prend des semaines, vous avez mesuré votre déficit de preuve, et vous disposez d’un indicateur à présenter au conseil, facilement compréhensible.

Troisièmement, formalisez l’escalade des incidents. Les 37 % d’incidents portés à la direction de façon informelle doivent désormais l’être via un examen documenté, consignant les décisions et leur date. Un compte rendu écrit de la réaction de la direction est une preuve à part entière, et cela ne coûte rien.

Quatrièmement, passez de la gestion contractuelle à des contrôles observés pour l’IA des fournisseurs. Demandez aux partenaires des logs et des décisions de politique pour tout agent accédant à vos données, et inscrivez ce droit dans les accords. La surveillance continue à 21 % est le chiffre à dépasser.

Cinquièmement, appliquez la minimisation des données au niveau opérationnel. Un agent qui ne reçoit que les données nécessaires à sa tâche limite l’impact d’un incident et simplifie la réponse à une autorité de contrôle.

La formulation d’IBM mérite d’être affichée. Dans le communiqué, Ana Paula Assis, présidente IBM pour EMEA et APAC, affirme que la gouvernance « ne peut plus être considérée comme un simple exercice de conformité ». La conséquence pour ceux qui signent la réponse à l’audit est limpide : une gouvernance incapable de produire des preuves à la demande reste un exercice de conformité, quel que soit son intitulé.

Pour en savoir plus sur la production de preuves de qualité concernant l’accès des agents IA à des données réglementées, réservez votre 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 avec l’IA
• Article de blog
  Comment 77 % des organisations échouent à sécuriser les données de l’IA
• eBook
  É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 demander si vous avez une politique IA. Ils veulent la preuve de son efficacité.