La plupart des programmes de gouvernance échouent au même endroit.

La policy est écrite. Elle est approuvée. Elle est publiée. Puis le runtime prend une décision sans jamais l'avoir évaluée.

C'est le passage de relais que la gouvernance ne fait jamais.

Une policy peut être parfaitement rédigée, revue juridiquement et techniquement cohérente, tout en ne gouvernant rien si le chemin d'exécution ne peut pas l'évaluer avant qu'un agent agisse.

Cet article est la quatrième partie de la série en dix volets AI Governance in an AI-Native Software Development Company. La partie 3, Pourquoi la plupart des équipes s'arrêtent aux contrôles d'action, a décrit les systèmes Knowledge, Execution et Evaluation qui rendent opérationnelles les couches profondes de gouvernance. Cette partie traite de la frontière suivante : transformer la policy en comportement runtime.

Si la policy s'arrête à la documentation, vous n'avez pas de gouvernance de l'IA. Vous avez du formatage.

Le fossé de l'application manuelle

La plupart des organisations ont déjà des policies.

Elles disposent de règles d'usage acceptable, d'exigences de traitement des données, de matrices d'approbation, de contrôles d'accès production, de standards de sécurité et de procédures d'escalade. Le problème n'est pas l'absence d'intention.

Le problème est la traduction.

Un humain peut lire une règle comme « les changements de production qui affectent les données client nécessitent l'approbation du propriétaire du service » et l'interpréter dans son contexte. On ne peut pas demander à un agent de reconstruire cette interprétation à partir de prose à chaque action.

La même règle peut dépendre de faits runtime :

  • quel agent agit
  • quelle capability version est active
  • quel utilisateur a délégué la demande
  • quel tool est appelé
  • si l'action est read-only ou modifie l'état
  • quel environnement est ciblé
  • quelle classification de données est concernée
  • quel blast radius est possible
  • quel budget reste disponible
  • si une exception est active
  • quelle policy version est en vigueur

Ces faits changent à chaque requête.

Une page wiki ne les évalue pas.

Un system prompt ne les enforce pas.

Une file d'approbation humaine ne peut pas scaler pour chaque action faible risque quand les agents fonctionnent en continu.

C'est pourquoi la gouvernance meurt avant le runtime. L'organisation possède l'intention, mais pas la frontière de décision exécutable entre cette intention et l'effet réel.

Ce que signifie vraiment Executable Policy

Executable Policy ne veut pas dire convertir tout document de gouvernance en code.

Cela signifie identifier les règles qui doivent modifier le comportement machine et les représenter de manière à ce que le runtime puisse les évaluer de façon cohérente.

Une policy exécutable utile possède sept propriétés.

Externe au modèle. Le modèle peut proposer une action, mais il ne doit pas être l'autorité finale qui décide si elle est permise.

Structurée. La décision porte sur des attributs explicites et une intention typée, pas sur un paragraphe que le modèle doit réinterpréter.

Consciente de l'état. La même intention peut être acceptable en staging et interdite en production. Elle peut être autorisée avec beaucoup de budget restant et exiger une approbation quand le budget est presque épuisé.

Versionnée. Chaque décision doit être attribuable à la version exacte de policy qui l'a produite.

Déterministe lorsque la frontière l'exige. Un modèle probabiliste peut planifier. Une frontière de permission stricte ne doit pas dépendre de son niveau de confiance.

Enforceable. Un verdict deny doit réellement empêcher le tool call ou la modification d'état.

Productrice de preuves. Le système doit enregistrer ce qui a été évalué, quelle règle a matché, quel verdict a été rendu et ce qui s'est passé ensuite.

Le but n'est pas de rendre chaque question de gouvernance déterministe. De nombreuses décisions métier nécessitent toujours du jugement.

Le but est de rendre la frontière d'enforcement explicite.

Le raisonnement probabiliste peut proposer. Le contrôle déterministe décide ce qui a le droit de se produire.

L'architecture de policy runtime

L'architecture est plus simple que le vocabulaire de gouvernance ne le laisse penser.

Un flux utile :

request -> structured intent -> policy decision -> enforcement -> action -> evidence

L'agent ou la couche d'orchestration transforme d'abord l'action envisagée en données structurées. Le Policy Decision Point évalue cette intention avec l'identité, le scope, l'environnement, l'état runtime et le policy bundle actif. Le Policy Enforcement Point applique ensuite le verdict avant que l'effet de bord ne se produise.

La décision ne doit pas se limiter à oui ou non.

Verdicts utiles :

  • allow : poursuivre dans le scope approuvé
  • deny : bloquer avec une raison structurée
  • require approval : suspendre jusqu'à l'approbation d'une autorité nommée
  • defer : ne pas exécuter maintenant car une condition runtime nécessaire manque
  • degrade : utiliser un chemin moins risqué ou moins coûteux lorsque la policy l'autorise
  • quarantine : produire l'artefact mais le garder hors du chemin live jusqu'à review

Le vocabulaire peut varier. L'important est que le comportement associé à chaque verdict soit défini avant l'incident.

Un verdict qui existe seulement dans les logs n'est pas un enforcement.

Ce que le Decision Point doit connaître

Un policy evaluator n'est fiable que si l'état qu'il voit l'est aussi.

Pour une action agentique importante, plusieurs groupes d'attributs sont généralement nécessaires.

Identité et délégation

  • identité de l'agent
  • identité et version de capability
  • humain ou service demandeur
  • autorité déléguée
  • expiration et scope de la délégation

Action

  • tool demandé
  • opération
  • ressource cible
  • effet attendu
  • classes de données lues ou écrites

Environnement

  • développement, staging ou production
  • scope tenant ou client
  • région
  • criticité du service

Risque et autonomie

  • classe d'action
  • autonomy tier
  • blast radius maximal
  • niveau de preuve requis
  • exigences d'approbation humaine

État runtime

  • budget coût et tokens restant
  • budget temps ou steps restant
  • rate-limit headroom
  • état incident ou maintenance
  • signaux récents de refus ou d'anomalie

État de gouvernance

  • policy bundle actif
  • exceptions
  • dates d'expiration
  • contrôles requis
  • propriétaire de la policy

C'est pourquoi la gouvernance runtime ne peut pas vivre uniquement dans un prompt. Le prompt ne possède pas fiablement tout cet état et, même s'il le voit, il ne doit pas pouvoir lever sa propre frontière.

Les prompts ne sont pas des frontières de permission

Une implémentation courante commence par l'instruction :

« Ne déploie pas en production sans approbation. »

Cette instruction est utile. Ce n'est pas un mécanisme d'enforcement.

Le modèle peut mal l'interpréter. Un autre prompt peut la contredire. Un tool peut exposer un chemin qui la contourne. Du contenu récupéré peut manipuler l'agent. Une mise à jour du host peut modifier la priorité des instructions.

Aucun de ces événements ne doit transformer une frontière production en suggestion.

La séparation correcte est :

  • prompts et skills guident le comportement
  • tools exposent des capacités
  • policy décide si une capacité peut être exercée dans le contexte actuel
  • enforcement empêche les effets non autorisés

Cette séparation facilite aussi les tests.

On peut évaluer si le modèle respecte généralement l'instruction.

Séparément, on peut prouver que le runtime bloque une action interdite même lorsque le modèle ne la respecte pas.

Ce sont deux garanties différentes, et la gouvernance a besoin des deux.

La policy doit exister à plusieurs gates

Le runtime est la frontière finale d'enforcement, mais il ne doit pas être le premier endroit où la policy apparaît.

Un système mature réutilise la policy dans tout le delivery lifecycle.

Authoring

La policy doit influencer ce que l'agent est autorisé à proposer.

Un coding agent doit savoir qu'il ne peut pas ajouter une dépendance non approuvée, accéder à un domaine de données restreint ou modifier un chemin de secrets production. Le feedback précoce réduit le travail perdu.

Pull Request et CI

Le pipeline doit évaluer les policies machine-checkable avant merge.

Architecture boundaries, restrictions de dépendances, exigences de preuve, contrôles de sécurité et reviewers requis appartiennent ici.

Deployment

La policy doit décider si l'artefact peut entrer dans un environnement.

Classification de risque, preuves de test, stratégie de rollout, approbation du owner et préparation du rollback peuvent être des inputs.

Runtime

Le runtime évalue l'action concrète contre l'état actuel.

C'est ici que identité, target, budget, environnement, tool, exception et conditions live convergent.

Le langage de policy n'a pas besoin d'être identique à chaque couche, mais le modèle doit être cohérent.

Si authoring interdit une action que runtime autorise, le système possède un conflit de policy.

Si runtime bloque quelque chose que CI a approuvé, la preuve doit expliquer quel état a changé.

Le comportement est une surface de déploiement

La policy doit aussi reconnaître que le code n'est pas la seule chose qui change le comportement.

Dans un système agentique, tous ces éléments peuvent modifier la production :

  • model version
  • system prompt
  • instruction files
  • skills
  • rules
  • tool schemas
  • tool permissions
  • routing logic
  • retrieval configuration
  • knowledge sources
  • policy bundles
  • runtime host version

Un model swap change le comportement.

Une skill update change le comportement.

Une nouvelle permission change le comportement.

Un policy bundle change le comportement.

Si le comportement change, quelque chose a été déployé.

Les artefacts de policy ont donc eux aussi besoin de release discipline : versions, owners, tests, promotion stages, rollback et traceability.

Une policy change qui modifie le comportement runtime est une production change.

Skills, rules et instructions sont des artefacts, pas le système de gouvernance

Les frameworks d'agents exposent de plus en plus des objets appelés skills, rules, instructions, guardrails ou policies.

Ils sont utiles car ils transforment l'intention humaine en guidance consommable par machine.

Mais appeler une instruction « policy » ne la transforme pas en frontière d'enforcement.

La bonne question n'est pas :

« Avons-nous un fichier de règles ? »

Les bonnes questions sont :

  • qui en est propriétaire
  • est-il versionné
  • comment est-il testé
  • l'agent peut-il l'ignorer
  • un tool peut-il le contourner
  • le runtime l'évalue-t-il avant l'effet
  • deny arrête-t-il réellement l'exécution
  • peut-on prouver quelle version était active
  • peut-on rollback

Skills, rules, agent instructions et tool constraints font partie de la surface comportementale.

La gouvernance est le système opérationnel autour de ces artefacts.

Les exceptions doivent être first-class

Tout système sérieux a besoin d'exceptions.

L'erreur consiste à les traiter comme des overrides informels.

« Donnez un accès temporaire pour cet incident » devient un message Slack.

« Autorisez ce tool pour la migration » devient une modification de config.

« Sautez l'approbation cette fois » devient un bypass impossible à expliquer ensuite.

Une exception gouvernée doit être un objet explicite avec :

  • requester
  • approver
  • raison
  • policy concernée
  • scope exact
  • heure de début
  • expiration
  • classe d'action autorisée
  • exigences de preuve
  • chemin de révocation

Une exception doit être plus étroite que la règle qu'elle remplace.

Elle doit expirer automatiquement.

Le runtime doit l'évaluer comme tout autre policy input.

Une exception sans expiration est une policy change qui prétend être temporaire.

Les policy changes ont besoin de progressive delivery

Une mauvaise policy runtime peut casser la production aussi efficacement qu'un mauvais code.

Une règle deny trop large peut arrêter des workflows critiques.

Une condition manquante peut autoriser une action dangereuse.

Un seuil modifié peut inonder les humains d'approvals.

La policy ne doit donc pas passer directement de l'authoring au full enforcement.

Séquence plus sûre :

  1. test sur des scénarios connus
  2. replay sur des traces récentes
  3. shadow de la nouvelle policy sans enforcement
  4. compare les anciens et nouveaux verdicts
  5. canary l'enforcement sur un scope borné
  6. promote lorsque les preuves sont acceptables
  7. rollback si les signaux de refus, escalation ou incident régressent

C'est le progressive delivery appliqué à la gouvernance.

L'artefact change. Le principe d'ingénierie ne change pas.

Chaque verdict doit produire une preuve

Une policy sans preuve crée une autre forme de mystère.

Le runtime doit émettre un decision record compact pour les actions importantes.

Un record utile inclut :

  • root trace ID
  • policy decision ID
  • identité agent et capability
  • structured intent
  • attributs d'état pertinents
  • policy bundle et version
  • règle matchée ou raison
  • verdict
  • résultat d'enforcement
  • référence d'approbation humaine si nécessaire
  • référence d'exception si nécessaire
  • timestamp

Il ne faut pas logger tout le contexte par défaut.

Il faut conserver assez d'information pour reconstruire pourquoi l'action a été autorisée, bloquée ou escaladée.

Cette preuve doit rejoindre le même modèle de trace que l'exécution et le change.

L'incident reviewer peut alors passer de :

« Que s'est-il passé ? »

à :

« Quelle policy a autorisé cette action, sous quel état et pourquoi ? »

C'est une question beaucoup plus utile.

Les failure modes se répètent

Sans executable policy, les échecs sont familiers.

Policy-in-a-wiki. La règle existe, tout le monde l'accepte, mais le runtime ne la lit jamais.

Policy-in-a-prompt. La règle existe, mais le système contraint est aussi responsable de l'interpréter et de l'obéir.

Split enforcement. Un tool vérifie la policy et un autre chemin atteint le même effet sans check.

Stale state. La décision est logiquement correcte contre un état incomplet ou dépassé.

Silent exception. Un override existe sans owner, expiration ni trace.

Mutable policy. Une règle change in-place et personne ne peut prouver quelle version gouvernait la décision d'hier.

Evidence-free deny. Le système bloque le travail mais ne peut pas expliquer quelle règle a déclenché.

Evidence-free allow. L'action réussit mais personne ne peut prouver pourquoi elle était autorisée.

Le pattern commun est simple.

La policy existait comme intention.

Elle n'existait pas comme contrôle exécutable.

Ordre pratique de construction

Ne commencez pas par encoder tout le manuel de gouvernance.

Choisissez un chemin d'action important et rendez le contrôle réel.

1. Définir une intention structurée

Choisissez une action matérielle : deploy, écriture de données client, rotation d'un secret ou invocation d'un tool production.

Représentez l'action avec des champs typés, pas avec de la prose.

2. Placer un Policy Decision Point hors du modèle

Le modèle propose.

L'évaluateur décide.

Gardez l'autorité d'enforcement hors du composant probabiliste.

3. Placer un Enforcement Point avant l'effet

Un deny doit empêcher l'exécution.

Ne comptez pas sur un refus coopératif.

4. Ajouter le minimum d'état runtime

Identity, action, target, environment, autonomy tier, budget state, policy version et exception state suffisent pour commencer.

Ajoutez des attributs quand une vraie décision les exige.

5. Émettre la preuve de décision

Donnez un ID à chaque verdict important et reliez-le à la trace d'exécution.

Allow, deny et approval doivent être explicables.

6. Versionner et tester le policy bundle

Exécutez des tests déterministes et rejouez des traces récentes.

Traitez le bundle comme un artefact de production.

7. Shadow, canary et promote

Observez ce que ferait la nouvelle policy avant qu'elle contrôle tout.

Déployez progressivement et gardez le rollback simple.

Cet ordre est volontairement petit.

Le but n'est pas de construire un empire de policies.

Le but est d'établir un passage fiable entre intention de gouvernance et comportement runtime, puis de l'étendre.

Conclusion

La partie la plus difficile de la gouvernance de l'IA n'est pas d'écrire la règle.

C'est de faire en sorte que la règle survive au contact de l'exécution.

Policies, principes, review boards et matrices d'approbation comptent. Mais ils deviennent gouvernance seulement lorsque le système peut les évaluer contre l'action sur le point de se produire, appliquer le verdict et conserver la preuve.

C'est l'Executable Policy Layer.

Elle se place entre comportement probabiliste et effets réels.

Elle donne une voix à l'état runtime.

Elle rend les exceptions visibles.

Elle rend les policy changes déployables et réversibles.

Et elle permet de répondre à la question importante pendant un incident :

« Pourquoi cette action a-t-elle été autorisée ? »

Si la réponse est « parce que nous avions demandé à l'agent de bien se comporter », la couche policy manque encore.

Si la réponse pointe vers une règle versionnée, évaluée contre un état enregistré, enforced avant l'effet et liée à une trace, la gouvernance a enfin atteint le runtime.

La gouvernance n'est pas ce que dit la policy. C'est ce que le runtime peut enforce et prouver.

Le prochain article se rapproche encore de l'agent : les prompts sont trop vagues pour porter toute la relation entre humains, agents et tools.

Prochaine partie : AI Agents Need Contracts, Not Better Prompts.

Publié initialement par Reza Arani sur Medium le 18 mai 2026. Adapté pour Aipolix comme quatrième partie de la série AI Governance in an AI-Native Software Development Company.