Rejeu déterministe des décisions d'agents d'IA

Trois choses que l’on appelle rejeu¶

Les équipes emploient le mot pour trois opérations différentes. Nommez celle que vous visez dans le plan d'audit, car chacune prouve autre chose.

Ce qui se rejoue de façon déterministe et ce qui ne se rejoue pas¶

Une règle de politique qui compare un montant à un seuil, vérifie un rôle ou teste un champ par rapport à une liste donne la même réponse pour les mêmes entrées. Elle est donc rejouable, à condition que les entrées et la version exacte de la règle soient enregistrées.

Un modèle de langage hébergé peut renvoyer un texte différent pour le même prompt d'un appel à l'autre et d'une mise à jour du modèle à l'autre. Abaisser la température d'échantillonnage réduit la variation sans la supprimer, et certains modèles actuels n'acceptent pas de réglage de température. Traitez la sortie du modèle comme une entrée enregistrée : stockez ce que le modèle a renvoyé et rejouez la décision à partir de là.

Un juge IA, c'est-à-dire un modèle chargé de classer ou de comparer du texte au sein d'un contrôle de politique, pose le même problème. Enregistrez son verdict avec le fournisseur, le modèle, la version du prompt et les empreintes de ce qu'il a comparé. Un rejeu peut alors vérifier le reste de la décision autour de ce verdict enregistré.

Les systèmes externes évoluent. Un dossier client, une liste de sanctions ou un solde de compte lu au moment de la décision sera différent une semaine plus tard. Rejouez à partir de la lecture enregistrée, avec la version de sa source, et jamais à partir d'une nouvelle requête.

• Déterministe : contrôles de seuil, de rôle, d'appartenance à une liste et de schéma ; ordre de priorité des résultats entre allow, warn, require_approval et block ; routage vers un rôle d'évaluateur.
• Enregistré et réutilisé : sortie du modèle, verdicts du juge IA, résultats de récupération, résultats d'outils, décisions humaines, horodatages utilisés par les règles.
• Jamais répété : écritures, paiements, messages, déclarations et tout autre appel ayant un effet externe.

Quoi enregistrer pour que le rejeu fonctionne¶

La plupart des rejeux qui échouent s'expliquent par un seul élément manquant. Le tableau liste ce dont un rejeu de décision a besoin, avec des exemples de noms de champs.

Exemple détaillé : rejouer une décision de crédit synthétique¶

L'agent de crédit d'une banque fictive a demandé une décision d'octroi de 24 000 EUR pour un demandeur travailleur indépendant. La politique credit-disposition-policy 4.2.1 a renvoyé require_approval au titre de la règle manual-review-above-20000. L'auditeur rejoue la décision deux fois : avec la version enregistrée, puis avec un brouillon 4.3.0 qui ajoute un blocage pour les travailleurs indépendants au-delà de 15 000 EUR. Tous les identifiants et toutes les valeurs sont inventés, et les empreintes sont abrégées.

{
  "run_id": "run_syn_0418",
  "replay_scope": "deterministic-only",
  "recorded": {
    "policy_id": "credit-disposition-policy",
    "policy_version": "4.2.1",
    "policy_pack_hash": "sha256:a4fc…278a",
    "decision": "require_approval",
    "matched_rules": ["manual-review-above-20000"],
    "occurred_at": "2026-10-02T10:02:11.204Z"
  },
  "replayed": [
    {
      "policy_version": "4.2.1",
      "decision": "require_approval",
      "matched_rules": ["manual-review-above-20000"],
      "delta": "none"
    },
    {
      "policy_version": "4.3.0-draft",
      "decision": "block",
      "matched_rules": ["block-self-employed-above-15000"],
      "delta": "require_approval -> block"
    }
  ],
  "not_replayed": [
    {
      "gate": "memo-consistency-check",
      "reason": "needs_original_text"
    }
  ]
}

• Version enregistrée : le rejeu avec la 4.2.1 renvoie require_approval avec la même règle. La décision enregistrée découle des entrées enregistrées.
• Version brouillon : le rejeu avec la 4.3.0 renvoie block. L'écart montre l'impact du brouillon sur ce run avant sa mise en production.
• Non rejoué : une porte utilisait un juge IA sur le texte d'une note qui n'a pas été stocké. Le rejeu la signale sous needs_original_text et l'exclut de la comparaison.
• Non démontré : le fait que le core banking ait enregistré la décision d'octroi. Le reçu de l'outil et l'enregistrement du core banking répondent à cette question.

Une décision rejouée ne prouve pas une action externe¶

Un rejeu conforme montre que la politique, appliquée aux entrées enregistrées, donne le résultat enregistré. Il ne montre pas que le système en aval a accepté l'appel, appliqué la modification, l'a appliquée une seule fois ou l'a conservée. Un paiement peut être rejeté après le retour de l'appel de l'agent. Un enregistrement peut être modifié par un autre processus une minute plus tard.

La preuve d'un effet externe vient du système externe : un reçu en aval, une empreinte de l'état après l'action, une référence d'effet que le système de référence peut résoudre, ou un extrait de rapprochement. L'enregistrement d'exécution des agents d'IA les présente sous la forme tool_calls[].result_digest et downstream_effects[], avec les empreintes de l'état avant et après. Un auditeur les teste indépendamment du rejeu.

Le rejeu ne doit jamais créer un second effet. Une clé d'idempotence par action permet à un appel relancé ou repris de renvoyer le résultat stocké. Lorsqu'un appel a été envoyé sans qu'aucun résultat ne soit enregistré, l'issue est inconnue : la bonne réponse est un rapprochement avec le système de destination, et un rejeu ne peut pas trancher.

Ce que nous avons appris en construisant le rejeu de décision¶

Nous avons d'abord proposé la simulation de politiques au moyen de cas de test construits à la main. L'utilisation du produit en interne en octobre 2026 a rendu le problème évident : un responsable de la conformité ne rédigera pas un cas de test de plusieurs dizaines de champs pour vérifier une modification de politique. Sa question est de savoir ce que la modification aurait changé aux décisions récentes, par exemple combien de cas supplémentaires partiraient en revue humaine. C'est la question à laquelle répond notre rejeu d'impact, en exécutant un brouillon sur les runs récents enregistrés et en listant chaque run dont le résultat changerait.

Le rejeu ne fonctionne que sur des entrées enregistrées dès le départ. Nous avons commencé à stocker le contexte de décision évalué dans chaque enregistrement de décision le 23 septembre 2026. Les décisions enregistrées avant cette date ne peuvent pas être rejouées ; le rejeu d'impact les comptabilise sous no_recorded_context et ne les compte jamais comme conformes.

Comparez les règles déclenchées en plus des résultats. Pour une démonstration de libération de paiements retenus préparée pour un briefing d'analystes en octobre 2026, sur données synthétiques, nous avons exécuté cinq simulations de politique. Chaque résultat enregistrait le résultat attendu et le résultat obtenu, les ID des règles déclenchées, l'ID et la version de la politique, ainsi qu'un ID de preuve, et les cinq étaient conformes. Le résultat block pour une correspondance confirmée sur une liste de sanctions indiquait deux règles déclenchées, l'arrêt pour sanctions et la règle générale d'approbation de libération, avec un seul code motif. Une comparaison limitée aux résultats n'aurait pas montré que les deux règles s'étaient déclenchées. Une simulation antérieure du même travail avait échoué en mode fermé parce que l'entrée de son outil n'avait pas de validation de confiance ; nous avons réécrit la règle pour qu'elle lise les champs du work item du Process, et le run en échec reste dans l'historique d'audit.

Comptez les codes motifs avant d'expliquer un taux. Lors d'un benchmark interne d'un contrôle par juge IA en septembre 2026, une variante de politique semblait intervenir à tort dans 98 % des cas. Les codes motifs ont montré que ces interventions étaient 565 résultats judge_unavailable causés par une troncature des entrées, identiques d'un modèle à l'autre. Nous avions d'abord mis en cause la logique de correspondance. Une variante ultérieure, qui ne comparait que l'instruction et l'action en cours, ne présentait aucune troncature.

Comment KLA rejoue les décisions aujourd'hui¶

KLA enregistre chaque décision de politique avec l'ID de la politique, sa version, l'empreinte du policy pack, les règles déclenchées, les codes motifs, le résultat et l'heure, et conserve une copie masquée des entrées de la décision pour le rejeu. Les enregistrements de décision écrits avant que KLA ne conserve cette copie sont signalés comme non rejouables.

Rejeu par run. KLA réévalue les entrées de décision enregistrées d'un run avec les contrôles par juge IA et les garde-fous désactivés, sans créer d'approbation. La réponse porte le libellé deterministic-only et liste, porte par porte, la décision précédente et la nouvelle.

Rejeu d'impact. Une Simulation réévalue une version de politique choisie, généralement un brouillon, sur les 50, 200 ou 1 000 derniers runs enregistrés dans le périmètre de la politique (200 par défaut) et liste chaque run dont le résultat enregistré et le résultat du brouillon diffèrent. Elle ne lit que les enregistrements de décision et ne crée ni preuve, ni approbation, ni enregistrement de décision. Chaque run qu'elle ne peut pas rejouer est comptabilisé sous un seul motif : no_recorded_context, input_not_stored, tool_schema_changed, decided_by_safeguard ou needs_original_text.

Contrôles par juge IA. KLA enregistre pour chaque contrôle par juge le fournisseur, le modèle, la version du prompt, les empreintes des opérandes comparés, le verdict, le niveau de confiance et la méthode. Le rejeu n'appelle pas de nouveau le juge ; les runs qui en dépendent sont signalés sous needs_original_text.

Configuration de l'agent. Chaque exécution référence une empreinte du manifeste de l'agent, et l'historique des manifestes conserve le manifeste complet : fournisseur et nom du modèle, instructions et outils.

Effets de bord. Le runtime indexe chaque action d'outil gouvernée par tenant, exécution et porte. Une relance renvoie le résultat validé. Un appel dont l'intention est enregistrée sans résultat s'arrête avec « execution outcome is unknown; operator reconciliation is required ».

Relecture. Lineage Explorer et la vue du runtime de l'agent montrent la séquence enregistrée d'un run. Ils ne la réexécutent pas.

Limites. KLA ne réexécute ni les appels au modèle ni les outils dans le cadre du rejeu. La documentation du vérificateur de preuves indique que ses contrôles prouvent le lien entre les décisions enregistrées, « not downstream tool execution ».

Le rejeu comme procédure d'audit¶

Utilisez le rejeu de décision comme test de réexécution sur un échantillon. Consignez chaque résultat dans le dossier de travail ; le dossier de travail d'audit des agents d'IA complété comprend une ligne de rejeu dont la limite est indiquée.

• Sélectionner : tirez l'échantillon de la population rapprochée, en incluant des résultats block et require_approval ainsi que des runs proches de modifications de politique.
• Figer : associez la version de politique et l'empreinte du pack enregistrées à l'archive des versions publiées.
• Rejouer : réexécutez la décision sur les entrées enregistrées, sans accès aux outils.
• Comparer : confrontez le résultat et les règles à l'enregistrement. Classez chaque écart : modification de règle, entrée non stockée, changement de schéma, dépendance au juge ou au modèle, ou divergence inexpliquée.
• Tester les effets séparément : suivez chaque action exécutée jusqu'au système en aval et rapprochez-la.
• Indiquer les limites : précisez quelles portes ont été exclues et pourquoi, et n'étendez pas la conclusion du rejeu aux effets externes.