Pourquoi la gouvernance de l’IA passe au contrôle en temps réel

Les agents d’IA peuvent être créés en un après-midi et commencer immédiatement à agir sur les finances, les relations clients ou des processus réglementés. Un processus de gouvernance qui examine les systèmes périodiquement ne peut pas fonctionner au même rythme. « Appliquer à l’IA une gouvernance stratégique traditionnelle, comme on le ferait pour des applications et des systèmes, ne fonctionne tout simplement pas pour les agents d’IA », explique Philipp Herzig, CTO de SAP, qui commercialise des technologies d’IA, d’architecture, de processus, d’identité et de gouvernance, et en tire un bénéfice commercial à mesure que les entreprises investissent dans ces contrôles. Le changement est architectural : les entreprises ont besoin d’une découverte continue, d’un contexte métier, de preuves comportementales et de contrôles capables d’agir pendant qu’un agent s’exécute.

Les agents d’IA font passer la gouvernance du moment de la revue au runtime

Le problème de timing vient de l’autonomie, car un agent peut agir entre deux revues formelles. « Les choses vont beaucoup plus vite dès que vous introduisez de l’autonomie. L’agent agit en votre nom, parfois sans votre approbation explicite. Avec une gouvernance opérationnelle proactive en temps réel, vous prévenez les problèmes au lieu de leur courir après », explique Herzig. Les grands modèles de langage compliquent déjà la gouvernance de l’IA, tandis que les agents y ajoutent une exécution indépendante : un système peut prendre des décisions et poursuivre un travail entre deux revues de gouvernance, réduisant l’intervalle entre une décision de l’IA et sa conséquence métier.

Cet intervalle plus court compte surtout là où la responsabilité est déjà formalisée. Les banques opèrent sous des directives de risque des modèles, notamment SR 11-7 et SR 26-2 ; les fabricants de médicaments sont soumis aux exigences GxP et FDA ; les organisations gouvernementales font face à FedRAMP, aux exigences d’autorisation d’exploitation et aux règles de souveraineté des données. L’AI Act de l’UE et le NIST AI Risk Management Framework établissent également des attentes en matière de documentation, de classification des risques et de supervision humaine. Les services financiers, la santé et l’industrie pharmaceutique, ainsi que le secteur public, subissent donc une pression particulièrement forte pour rendre l’activité de l’IA traçable et responsable.

La production pharmaceutique rend cette exigence de responsabilité très concrète, car la gouvernance doit préserver un historique traçable tout au long du processus. « Pensez à l’industrie pharmaceutique, où vous avez une chaîne de traçabilité », dit Herzig. « Si vous fabriquez des médicaments, vous devez connaître chaque point où le produit a été manipulé. Vous ne pouvez pas avoir de zones blanches dans un processus métier réglementé. » Un agent non déterministe, dont la réponse peut varier dans des interactions apparemment identiques, rend la reconstitution plus difficile, car les organisations peuvent devoir expliquer pourquoi le système s’est comporté de cette manière.

Cette exigence de reconstitution met en lumière les limites des mécanismes de gouvernance construits autour de revues ponctuelles. Les registres établissent les actifs connus, les journaux de session conservent des preuves, les checklists et modèles structurent les revues, et les autorisations définies au moment du déploiement limitent l’accès initial. La reconstitution après incident peut expliquer certains événements une fois qu’ils se sont produits, mais l’exécution autonome exige que ces mesures fonctionnent comme un système continu, car le périmètre gouverné, le comportement d’un agent et son usage de l’autorité qui lui a été accordée peuvent tous évoluer après approbation.

La découverte continue suit un périmètre qui peut changer en un après-midi

Un système continu commence par savoir ce qui existe à l’instant présent. Les entreprises doivent pouvoir répondre à quatre questions à tout moment : quels agents existent et à quoi sert chacun ; à quelles données et à quels systèmes ils peuvent accéder ; à quels processus métier ils participent ; et si leur comportement reste conforme aux politiques. La première question rend les trois autres possibles, car un agent inconnu ne peut pas être relié de manière fiable aux informations d’accès, de processus ou de politique.

Le besoin d’un inventaire à jour augmente lorsque les employés peuvent créer directement des systèmes autonomes. Les interfaces de chat et les outils de copilote peuvent permettre à quelqu’un d’assembler un agent fonctionnel en un après-midi et de le mettre immédiatement au travail. Herzig donne l’exemple du traitement des factures : « Disons que quelqu’un décide qu’il ne veut plus traiter les factures, alors il construit rapidement un agent dans un outil de copilote et lui confie le travail. » Cette décision peut introduire une activité autonome dans les finances et les relations clients avant qu’une fonction de gouvernance centralisée sache que cette entité existe.

Parce que la création peut se produire en dehors d’un processus de release planifié, la découverte doit la suivre en continu. « On ne peut pas gérer ce qu’on ne voit pas », dit Herzig. « Si je ne peux pas découvrir automatiquement et maintenir un inventaire opérationnel des actifs d’IA ou des agents d’IA, je ne sais pas ce que je gouverne. » Pour les responsables technologiques, le périmètre s’étend désormais au-delà d’un pipeline de déploiement approuvé, qui peut couvrir les systèmes publiés de manière centralisée tout en manquant les agents créés via des outils déjà à la disposition des employés.

Ce périmètre élargi inclut également l’infrastructure autour des agents. Herzig estime que les agents représentent « moins d’un tiers » du périmètre de gouvernance de l’IA en entreprise. Le reste comprend les grands modèles de langage ; les serveurs Model Context Protocol (MCP), qui connectent les systèmes d’IA aux applications et à d’autres ressources ; les protocoles agent-à-agent ; et l’orchestration multi-agents, dans laquelle plusieurs agents se répartissent et se délèguent le travail. La découverte de gouvernance doit donc identifier les acteurs autonomes et l’infrastructure par laquelle ils communiquent et agissent.

La délégation rend cet inventaire élargi plus déterminant, car l’agent qui reçoit une tâche peut être différent de celui qui exécute une action ultérieure. Une entreprise peut connaître l’agent qui a reçu la demande initiale tout en devant encore établir quel autre agent a agi, quel système il a atteint et sous quelle autorité. À mesure que des entités autonomes obtiennent des accès hors de la visibilité centrale, un inventaire mis à jour lors des revues de déploiement planifiées ne peut pas représenter de manière fiable l’environnement opérationnel.

L’AI Agent Hub de SAP illustre une approche fournisseur de la découverte cross-platform. SAP positionne ce hub comme un point d’entrée capable d’identifier des agents au-delà de ses propres produits, soutenant ainsi son offre commerciale de gouvernance. « Notre découverte couvre déjà les agents ServiceNow, AWS, Microsoft et Google, bien au-delà de l’écosystème SAP », explique Herzig. La découverte cross-platform est importante, car un inventaire d’entreprise doit suivre le mix technologique réel de l’organisation.

Une fois la présence établie par la découverte, la gouvernance doit encore établir les conséquences. Savoir qu’un agent de facturation existe n’établit pas qui est responsable de ses décisions, quelle autorité déléguée il porte, de quel workflow il dépend ou ce qui pourrait encore échouer si son comportement change. Répondre à ces questions exige de relier l’inventaire à l’architecture d’entreprise et aux processus métier.

La gouvernance relie les actifs aux processus, à l’identité et à la responsabilité

L’inventaire devient exploitable lorsque chaque actif acquiert un contexte métier. « Avoir un registre est une chose, et positionner ce périmètre dans le contexte de votre activité en est une autre », dit Herzig. « Savoir quels agents se trouvent dans quels processus et quelles applications s’exécutent au-dessus d’eux permet de répondre aux questions les plus difficiles. » Une fois qu’un agent est relié à des processus, des applications et des systèmes, les équipes peuvent identifier les dépendances et sa zone d’impact potentielle, c’est-à-dire les opérations métier et les composants technologiques exposés si l’agent se comporte incorrectement.

Ces dépendances constituent la base de l’attribution de la responsabilité. La responsabilité doit être reliée à l’agent et au workflow dans lequel il opère, y compris les garde-fous autour de son comportement et l’autorité déléguée via un rôle utilisateur. Un agent travaillant sur des factures, par exemple, doit être compris à travers le workflow métier et les permissions qui rendent ses actions significatives. La propriété de l’actif à elle seule ne dit pas qui est responsable des décisions de processus que l’agent exécute.

Le lien entre responsabilité et permission fait entrer l’Identity and Access Management (IAM), la discipline utilisée pour contrôler les identités et leurs accès, dans le modèle de gouvernance. L’IAM a principalement été conçu autour des personnes, alors que des entités autonomes peuvent poursuivre des objectifs assignés en utilisant des permissions déléguées. Un agent peut utiliser ces permissions de manière inattendue, y compris en tentant de trouver une autre voie lorsqu’une restriction d’API l’empêche d’avancer. Les équipes doivent donc comprendre sous quelle autorité l’agent agit, quels accès en découlent et si l’usage réel reste cohérent avec le rôle prévu.

La délégation complique encore ce modèle d’identité dans le cadre de l’orchestration multi-agents. Un agent peut accepter une tâche et en déléguer une partie à un autre, séparant l’origine de la demande de l’entité qui finit par effectuer une action. La responsabilité et l’attribution dépendent alors de la conservation des relations entre les agents, leurs identités, le workflow et les permissions déléguées. Sans ces relations, un registre peut montrer que plusieurs agents existent tout en laissant floue la chaîne de responsabilité.

SAP répartit ces formes de contexte entre plusieurs produits, qui font tous partie de son portefeuille technologique commercial :

Cette organisation des produits reflète une exigence architecturale plus large, car les décisions opérationnelles concernant un agent dépendent d’informations qui résident traditionnellement dans des systèmes distincts d’architecture, de processus, d’identité et de main-d’œuvre. Relier ces systèmes rend l’analyse des risques plus précise : une entité autonome inconnue pose un problème de découverte, tandis qu’un agent connu, rattaché à une application, un workflow, un responsable et une identité, peut être évalué à travers ses dépendances et son impact probable. Le même contexte donne une structure à la surveillance continue, car une activité brute devient significative lorsqu’elle est reliée au processus qui importe à l’entreprise.

La télémétrie au niveau des processus peut gouverner le comportement et prouver la valeur métier

Une fois qu’un agent dispose d’un contexte métier, la surveillance peut comparer l’accès qui lui a été accordé avec l’accès et le comportement qu’il manifeste réellement. Les permissions peuvent rester formellement inchangées alors qu’un agent en évolution modifie la manière dont il les utilise ; une télémétrie continue fournit donc aux équipes de gouvernance des preuves de cet écart. Les équipes peuvent alors évaluer si l’accès reste approprié à mesure que l’exécution évolue.

Les agents génèrent déjà une quantité importante de preuves de bas niveau. « Les agents produisent beaucoup de télémétrie de base, notamment les entrées et sorties de tokens, l’usage du modèle dans le temps, l’état de santé des appels d’outils et les taux de réussite », explique Herzig. Ces signaux montrent comment un agent fonctionne, et leur valeur pour la gouvernance augmente lorsqu’ils sont rattachés au processus dans lequel l’agent agit. Le succès des appels d’outils, par exemple, devient plus utile lorsque les équipes peuvent le relier au fait qu’un workflow gouverné s’est correctement achevé.

Ce lien avec le processus donne également aux équipes une base de référence pour juger les résultats. Des benchmarks de processus peuvent être établis « avant la mise en production », donnant à l’organisation un point de référence pour évaluer la conformité et les résultats métier après le déploiement. Les mesures peuvent ensuite être agrégées au niveau du processus et, au-delà, à l’échelle d’un portefeuille applicatif au niveau des capacités métier. La surveillance peut ainsi montrer ce qui a changé dans le fonctionnement tout en préservant la télémétrie technique nécessaire pour comprendre pourquoi.

Herzig illustre ce lien avec un workflow dont les effectifs passent de six personnes à deux personnes travaillant avec des agents. « La question est de savoir si vous pouvez agréger ce niveau de détail par rapport à un processus auparavant exécuté par six personnes et qui fonctionne maintenant avec deux personnes et des agents dans la boucle. Prouver le gain d’efficacité exige des outils capables de faire remonter ces signaux jusqu’au niveau où la valeur métier devient visible. » Les volumes de tokens ou l’usage du modèle à eux seuls ne peuvent pas établir ce gain d’efficacité ; la mesure au niveau du processus relie l’exécution de l’agent au résultat opérationnel modifié.

Parce que la conformité du processus et la valeur métier dépendent toutes deux de l’exécution réelle, les mêmes preuves peuvent soutenir à la fois la gouvernance et l’évaluation métier. Une équipe doit savoir si l’agent a suivi les chemins autorisés, tandis que les dirigeants doivent savoir si le processus résultant s’est amélioré. Une fois que les mappings d’architecture et de processus relient la télémétrie à l’activité métier, les deux évaluations peuvent s’appuyer sur le même historique opérationnel. Les données de gouvernance peuvent alors étayer les décisions de ROI ainsi que les preuves requises en cas d’incident ou d’audit.

Ces preuves partagées changent aussi le moment où la mesure doit être conçue. Si un benchmark est établi avant le déploiement, les équipes savent quels résultats et quelles conditions de politique elles ont l’intention de mesurer avant le début de l’exécution autonome. Concevoir la mesure après coup oblige les équipes à reconstituer la base de référence et l’effet de l’agent à partir des enregistrements déjà disponibles. Les preuves actuelles et le contexte de processus deviennent alors des prérequis à l’intervention, car un contrôle runtime a besoin des deux pour déterminer si une action est autorisée.

L’application au runtime dépend de la découverte, du contexte et des preuves

Avec des preuves actuelles disponibles, l’application au runtime peut faire passer la gouvernance de l’enregistrement du comportement à l’intervention pendant l’exécution. Si un agent tente d’atteindre un système restreint, une découverte après l’événement laisse la remédiation au responsable du processus affecté. Un contrôle runtime peut évaluer l’action au moment où elle se produit et empêcher une étape interdite avant que le système ne soit atteint.

Cette intervention devient plus importante à mesure que le comportement évolue après le déploiement. « Les agents continuent d’apprendre, de s’ajuster et de dériver », explique Herzig. Un droit approuvé lors de la mise en production d’un agent peut rester techniquement disponible alors même que la manière dont l’agent l’utilise évolue. La reconstitution conventionnelle est particulièrement difficile avec des systèmes non déterministes, de sorte que les permissions définies au moment du déploiement et l’analyse ultérieure des sessions ne peuvent pas, à elles seules, établir que la politique a été respectée tout au long de l’exécution.

Herzig considère donc le contrôle au runtime comme essentiel : « Sans la capacité de mesurer cela et d’appliquer des contrôles au runtime, vous n’avez pas de gouvernance de l’IA. » La mesure fournit les informations nécessaires à l’application, car un contrôle doit savoir quel agent agit, quel est son rôle autorisé, quel est le contexte de processus et ce qu’indique son comportement actuel. Avec ces éléments, le contrôle peut déterminer si une action particulière viole la politique.

SAP décrit le développement de sa gouvernance comme un passage de la visibilité sur le périmètre IA et les risques associés vers le contrôle et la gestion au runtime, une évolution qui élargit également le périmètre de son offre commerciale de gouvernance. Dans le parcours de déploiement de SAP, SAP Integration Suite peut construire et gérer des serveurs MCP et exige une vérification avant que ces serveurs n’entrent en production. Joule Studio applique une vérification avant que les agents ne quittent un environnement de test. SAP prévoit également des sceaux de vérification explicitement fondés sur des réglementations telles que l’AI Act de l’UE.

Ces garde-fous au déploiement établissent un état initial contrôlé, tandis que l’intervention continue traite le comportement après la mise en production. SAP indique que les capacités d’application au runtime et les garde-fous sont prévues avant la fin de 2026 ; il s’agit donc encore d’éléments futurs de sa feuille de route annoncée. Il est important de garder ce calendrier clair sur le plan opérationnel, car la vérification avant la production et l’application pendant l’exécution ultérieure résolvent des parties différentes du problème de gouvernance.

Les contrôles runtime dépendent donc des couches établies plus tôt. La découverte indique au système de contrôle que l’agent existe ; les mappings d’architecture et de processus montrent ce que ses actions affectent ; la responsabilité et l’identité établissent la responsabilité et l’autorité déléguée ; la surveillance montre ce qu’il fait réellement. Ensemble, ces éléments donnent au point d’intervention suffisamment d’informations pour prendre une décision de politique pendant l’exécution.

Les exemples d’entreprise transforment la gouvernance en discipline opérationnelle

Ce même modèle en couches façonne déjà des pratiques opérationnelles reproductibles au sein des entreprises. AmTrust Financial Services a étendu sa pratique d’architecture d’entreprise SAP LeanIX à la gouvernance de l’IA en amont des obligations liées à l’AI Act de l’UE. L’entreprise a créé un inventaire de l’IA, classé les applications par risque et mis en place un conseil de gouvernance de l’IA transverse. Ces étapes relient la découverte et la classification des risques à une structure organisationnelle capable de prendre des décisions de gouvernance.

CapitaLand traite le problème du passage à l’échelle grâce à des frameworks de gouvernance réutilisables dans des business units opérant dans plus de 260 villes. À mesure que l’adoption de l’IA progresse, reconstruire une méthode de gouvernance pour chaque déploiement crée sa propre contrainte de passage à l’échelle. Des frameworks réutilisables donnent aux business units distribuées une structure répétable à mesure que leur usage de l’IA s’étend.

Ces cas démontrent l’inventaire, la classification des risques, la coordination et des structures de gouvernance scalables, tandis qu’une application complète au runtime représente une couche supplémentaire du modèle opérationnel. Les entreprises peuvent faire mûrir des couches individuelles à mesure que le modèle plus large se développe. La coordination organisationnelle fait partie de ce travail, car les architectes d’entreprise, les RSSI et les responsables conformité détiennent différentes parties des informations et de l’autorité nécessaires pour gouverner un système autonome.

Cette répartition des responsabilités aide aussi à expliquer l’émergence de centres d’excellence IA dans les grandes organisations. La gouvernance continue traverse l’architecture, la sécurité, la conformité, l’identité et la gestion des processus ; des écarts peuvent donc apparaître entre les fonctions même lorsque chaque équipe remplit correctement son propre rôle. Une structure opérationnelle transverse donne à ces fonctions un lieu pour coordonner les décisions à mesure que les agents sont découverts, évalués, surveillés et gouvernés tout au long de leur cycle de vie.

La télémétrie cross-vendor limite la gouvernance continue

Dès que ce modèle opérationnel traverse plusieurs fournisseurs technologiques, la contrainte la plus difficile devient l’accès à la télémétrie. Les entreprises peuvent découvrir des agents à travers différents écosystèmes, mais les signaux détaillés de comportement et de performance nécessaires à la surveillance peuvent rester enfermés dans les environnements propres à chaque fournisseur. La découverte cross-vendor fournit donc une partie de la visibilité requise pour des contrôles à l’échelle de l’entreprise, tandis que la télémétrie détermine dans quelle mesure le comportement des agents peut réellement être évalué.

Herzig identifie cela comme un problème d’écosystème ouvert : « Là où l’industrie doit encore progresser, c’est vers un écosystème ouvert d’agents plus solide, parce que la télémétrie granulaire nécessaire pour évaluer les performances des agents, surveiller leur état de santé et leur comportement, et agréger ces informations en résultats métier mesurables reste derrière des portes closes dans chaque grand environnement technologique. Aucune organisation ne fonctionne uniquement sur SAP ou uniquement sur Microsoft. Ouvrir cela améliore la gouvernance de l’IA pour tout le monde. » En tant que CTO de SAP, Herzig a un intérêt commercial dans une interopérabilité qui permet aux produits de gouvernance de SAP de fonctionner à travers des environnements d’entreprise hétérogènes. Cette affirmation est importante sur le plan opérationnel, car la télémétrie comportementale sous-tend l’application des politiques et les mesures de ROI au niveau des processus utilisées pour juger si les agents créent de la valeur.

Les protocoles agent-à-agent et les serveurs MCP rendent cette frontière plus importante à mesure que l’activité se déplace entre les plateformes. Une entreprise peut découvrir les entités participantes tout en manquant encore de preuves cohérentes sur ce qui s’est passé pendant la délégation, quels outils ont été appelés et comment l’exécution a affecté un processus lorsque différents fournisseurs exposent des télémétries différentes. Une gouvernance pleinement continue dépend donc d’une visibilité qui suit l’activité des agents au-delà des frontières entre plateformes.

Cette dépendance fait de l’interopérabilité une exigence de gouvernance ayant des effets directs sur la qualité du contrôle. La découverte, le contexte et les contrôles runtime peuvent continuer à s’améliorer à l’intérieur d’environnements individuels, mais la gouvernance à l’échelle de l’entreprise reste contrainte lorsque les preuves nécessaires pour évaluer le comportement s’arrêtent à la frontière d’un fournisseur. À mesure que les agents agissent à travers les systèmes et délèguent à travers les plateformes, l’efficacité de la couche de contrôle dépend de la part de cette exécution que les entreprises peuvent réellement voir.

En conclusion

Pour les dirigeants, le passage à l’IA agentique transforme la gouvernance d’un exercice périodique d’assurance en une capacité opérationnelle. L’approbation avant le déploiement reste importante, mais elle ne peut pas prendre en compte des agents créés en dehors des processus de release centralisés, qui changent la manière dont ils utilisent des permissions existantes ou délèguent du travail entre systèmes après leur mise en production.

La priorité pratique consiste à construire les connexions qui rendent possible une gouvernance continue : un inventaire à jour des agents et de l’infrastructure de support, une responsabilité et une identité claires, des mappings vers les processus métier et les applications, et une télémétrie montrant comment les systèmes autonomes se comportent réellement. Les contrôles runtime peuvent alors agir sur ce contexte plutôt que d’appliquer une politique sans connaître la conséquence métier.

Les secteurs réglementés subissent la pression immédiate la plus forte, car ils doivent déjà démontrer responsabilité, traçabilité et contrôle. Mais le défi sous-jacent s’étend à toute entreprise qui donne à l’IA une autorité sur des transactions financières, des interactions clients ou d’autres processus à fort enjeu. La maturité de la gouvernance dépendra de plus en plus non seulement de la capacité d’une organisation à approuver un agent, mais aussi de sa capacité à voir, comprendre et contrôler cet agent tout au long de son exécution.

La visibilité cross-vendor reste une contrainte. À mesure que les agents opèrent à travers les plateformes technologiques, la gouvernance ne sera continue qu’à hauteur des preuves que les entreprises peuvent obtenir à travers ces frontières. Les responsables technologiques qui évaluent l’IA agentique devraient donc considérer la découverte, l’interopérabilité, le contexte de processus et l’application au runtime comme des exigences architecturales plutôt que comme des contrôles à ajouter après le déploiement.