Deterministischer Replay von Entscheidungen von KI-Agenten

Drei Bedeutungen von Replay¶

Teams verwenden das Wort für drei verschiedene Vorgänge. Benennen Sie im Prüfungsplan den gemeinten Vorgang, denn jeder belegt etwas anderes.

Was sich deterministisch nachspielen lässt und was nicht¶

Eine Richtlinienregel, die einen Betrag mit einem Schwellenwert vergleicht, eine Rolle prüft oder ein Feld gegen eine Liste testet, liefert bei gleichen Eingaben dieselbe Antwort. Damit ist sie nachspielbar, sofern die Eingaben und die genaue Regelversion aufgezeichnet sind.

Ein gehostetes Sprachmodell kann für denselben Prompt über mehrere Aufrufe und Modellaktualisierungen hinweg unterschiedlichen Text liefern. Eine niedrigere Sampling-Temperatur verringert die Streuung, beseitigt sie aber nicht, und manche aktuellen Modelle akzeptieren keine Temperatureinstellung. Behandeln Sie Modellausgaben als aufgezeichnete Eingabe: Speichern Sie, was das Modell zurückgegeben hat, und spielen Sie die Entscheidung von dort aus nach.

Ein KI-Judge, also ein Modell, das innerhalb einer Richtlinienprüfung Text klassifiziert oder vergleicht, hat dasselbe Problem. Zeichnen Sie sein Urteil mit Anbieter, Modell, Prompt-Version und Hashes der verglichenen Inhalte auf. Ein Replay kann dann den Rest der Entscheidung rund um dieses aufgezeichnete Urteil prüfen.

Externe Systeme verändern sich. Ein Kundendatensatz, eine Sanktionsliste oder ein Kontostand, zum Entscheidungszeitpunkt gelesen, sieht eine Woche später anders aus. Spielen Sie den Replay aus dem aufgezeichneten Lesevorgang mit seiner Quellversion nach und nie aus einer neuen Abfrage.

• Deterministisch: Schwellenwert-, Rollen-, Listen- und Schemaprüfungen; die Rangfolge der Ergebnisse allow, warn, require_approval und block; die Weiterleitung an eine Prüferrolle.
• Aufgezeichnet und wiederverwendet: Modellausgaben, Urteile von KI-Judges, Retrieval-Ergebnisse, Tool-Ergebnisse, menschliche Entscheidungen, von Regeln verwendete Zeitstempel.
• Nie wiederholt: Schreibvorgänge, Zahlungen, Nachrichten, Meldungen und jeder andere Aufruf mit externer Wirkung.

Was aufgezeichnet sein muss, damit der Replay funktioniert¶

Die meisten gescheiterten Replays gehen auf ein einziges fehlendes Element zurück. Die Tabelle listet, was ein Entscheidungs-Replay braucht, mit Beispielfeldnamen.

Durchgerechnetes Beispiel: Replay einer synthetischen Kreditentscheidung¶

Der Kredit-Agent einer fiktiven Bank beantragte eine Verfügung über 24.000 EUR für einen selbstständigen Antragsteller. Die Richtlinie credit-disposition-policy 4.2.1 lieferte require_approval nach der Regel manual-review-above-20000. Der Prüfer spielt die Entscheidung zweimal nach: unter der aufgezeichneten Version und unter einem Entwurf 4.3.0, der für Selbstständige oberhalb von 15.000 EUR eine Sperre ergänzt. Alle Kennungen und Werte sind erfunden, die Digests gekürzt.

{
  "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"
    }
  ]
}

• Aufgezeichnete Version: Der Replay unter 4.2.1 liefert require_approval mit derselben Regel. Die aufgezeichnete Entscheidung folgt aus den aufgezeichneten Eingaben.
• Entwurfsversion: Der Replay unter 4.3.0 liefert block. Das Delta zeigt die Auswirkung des Entwurfs auf diesen Lauf, bevor er ausgerollt wird.
• Nicht nachgespielt: Ein Gate nutzte einen KI-Judge für einen Memo-Text, der nicht gespeichert war. Der Replay meldet es unter needs_original_text und lässt dieses Gate beim Vergleich aus.
• Nicht gezeigt: ob das Kernbankensystem die Verfügung verbucht hat. Das beantworten die Tool-Quittung und der Datensatz im Kernbankensystem.

Eine nachgespielte Entscheidung belegt keine externe Aktion¶

Ein übereinstimmender Replay zeigt, dass die Richtlinie, angewandt auf die aufgezeichneten Eingaben, das aufgezeichnete Ergebnis liefert. Er zeigt nicht, dass das nachgelagerte System den Aufruf angenommen, die Änderung ausgeführt, sie genau einmal ausgeführt oder sie beibehalten hat. Eine Zahlung kann abgelehnt werden, nachdem der Aufruf des Agenten zurückgekehrt ist. Ein Datensatz kann eine Minute später von einem anderen Prozess geändert werden.

Den Nachweis einer externen Wirkung liefert das externe System: eine nachgelagerte Quittung, ein Digest des Zustands danach, eine Wirkungsreferenz, die das führende System auflösen kann, oder ein Abgleichsauszug. Der Ausführungsdatensatz für KI-Agenten zeigt diese als tool_calls[].result_digest und downstream_effects[] mit Digests des Zustands davor und danach. Ein Prüfer testet sie getrennt vom Replay.

Ein Replay darf außerdem nie eine zweite Wirkung erzeugen. Ein Idempotenzschlüssel pro Aktion sorgt dafür, dass ein wiederholter oder fortgesetzter Aufruf das gespeicherte Ergebnis zurückgibt. Wurde ein Aufruf gesendet, aber kein Ergebnis aufgezeichnet, ist das Ergebnis unbekannt: Die richtige Reaktion ist ein Abgleich mit dem Zielsystem, und ein Replay kann die Frage nicht klären.

Was wir beim Aufbau des Entscheidungs-Replays gelernt haben¶

Zunächst boten wir Richtliniensimulation über von Hand gebaute Testfälle an. Als wir das Produkt im Oktober 2026 selbst einsetzten, wurde das Problem offensichtlich: Eine Compliance-Beauftragte schreibt keinen Testfall mit Dutzenden Feldern, um eine Richtlinienänderung zu prüfen. Ihre Frage lautet, was die Änderung mit den jüngsten Entscheidungen gemacht hätte, zum Beispiel wie viele Fälle zusätzlich in die menschliche Prüfung gingen. Diese Frage beantwortet unser Impact-Replay: Er lässt einen Entwurf über die jüngsten aufgezeichneten Läufe laufen und listet jeden Lauf, dessen Ergebnis sich ändern würde.

Replay funktioniert nur mit Eingaben, die von Anfang an aufgezeichnet wurden. Seit dem 23. September 2026 speichern wir den ausgewerteten Entscheidungskontext in jedem Entscheidungsdatensatz. Entscheidungen von vor diesem Datum lassen sich nicht nachspielen; der Impact-Replay zählt sie unter no_recorded_context und nie als Übereinstimmung.

Vergleichen Sie neben den Ergebnissen auch die zutreffenden Regeln. Für einen Showcase zur Freigabe zurückgehaltener Zahlungen, den wir im Oktober 2026 für ein Analysten-Briefing auf synthetischen Daten vorbereitet haben, führten wir fünf Richtliniensimulationen durch. Jedes Ergebnis enthielt das erwartete und das tatsächliche Ergebnis, die IDs der zutreffenden Regeln, die Richtlinien-ID und -Version sowie eine Nachweis-ID, und alle fünf stimmten überein. Das Ergebnis block für einen bestätigten Sanktionstreffer listete zwei zutreffende Regeln, den Sanktionsstopp und die allgemeine Freigaberegel, mit einem einzigen Begründungscode. Ein Vergleich nur der Ergebnisse hätte nicht gezeigt, dass beide Regeln gegriffen haben. Eine frühere Simulation in derselben Arbeit schlug sicher fehl (fail closed), weil ihrer Tool-Eingabe die vertrauenswürdige Validierung fehlte; wir schrieben die Regel so um, dass sie Felder des Process-Arbeitselements liest, und der fehlgeschlagene Lauf bleibt in der Audit-Historie.

Zählen Sie die Begründungscodes, bevor Sie eine Quote erklären. In einem internen Benchmark einer KI-Judge-Prüfung im September 2026 schien eine Richtlinienvariante in 98 % der Fälle zu Unrecht einzugreifen. Die Begründungscodes zeigten, dass es sich um 565 Ergebnisse judge_unavailable handelte, verursacht durch abgeschnittene Eingaben und über alle Modelle identisch. Zuerst hatten wir die Abgleichslogik verdächtigt. Eine spätere Variante, die nur die Anweisung mit der aktuellen Aktion verglich, hatte keine abgeschnittenen Eingaben.

Wie KLA Entscheidungen heute nachspielt¶

KLA zeichnet jede Richtlinienentscheidung mit Richtlinien-ID, Version, Hash des Policy Packs, zutreffenden Regeln, Begründungscodes, Ergebnis und Zeitpunkt auf und bewahrt für den Replay eine geschwärzte Kopie der Entscheidungseingaben auf. Entscheidungsdatensätze aus der Zeit, bevor KLA diese Kopie aufbewahrte, werden als nicht nachspielbar gemeldet.

Replay pro Lauf. KLA wertet die aufgezeichneten Entscheidungseingaben eines Laufs erneut aus, mit abgeschalteten KI-Judge- und Guardrail-Prüfungen und ohne Erstellung von Freigaben. Die Antwort ist als deterministic-only gekennzeichnet und listet pro Gate die vorherige und die neue Entscheidung.

Impact-Replay. Eine Simulation wertet eine gewählte Richtlinienversion, meist einen Entwurf, über die letzten 50, 200 oder 1.000 aufgezeichneten Läufe im Geltungsbereich der Richtlinie aus (standardmäßig 200) und listet jeden Lauf, bei dem sich aufgezeichnetes Ergebnis und Entwurfsergebnis unterscheiden. Sie liest nur Entscheidungsdatensätze und erzeugt keine Nachweise, Freigaben oder Entscheidungsdatensätze. Jeder Lauf, den sie nicht nachspielen kann, wird unter genau einem Grund gezählt: no_recorded_context, input_not_stored, tool_schema_changed, decided_by_safeguard oder needs_original_text.

KI-Judge-Prüfungen. KLA zeichnet für jede Judge-Prüfung Anbieter, Modell, Prompt-Version, Hashes der verglichenen Operanden, Urteil, Konfidenz und Methode auf. Der Replay ruft den Judge nicht erneut auf; Läufe, die von einem Judge abhängen, werden unter needs_original_text gemeldet.

Agentenkonfiguration. Jede Ausführung verweist auf einen Hash des Agentenmanifests, und die Manifesthistorie bewahrt das vollständige Manifest: Modellanbieter und -name, Anweisungen und Tools.

Seiteneffekte. Die Laufzeitumgebung schlüsselt jede gesteuerte Tool-Aktion nach Mandant, Ausführung und Gate. Eine Wiederholung liefert das festgeschriebene Ergebnis. Ein Aufruf mit aufgezeichneter Absicht und ohne Ergebnis stoppt mit „execution outcome is unknown; operator reconciliation is required“.

Wiedergabe. Lineage Explorer und die Laufzeitansicht des Agenten zeigen die aufgezeichnete Abfolge eines Laufs. Sie führen ihn nicht erneut aus.

Grenzen. KLA führt Modellaufrufe oder Tools im Rahmen eines Replays nicht erneut aus. Die Dokumentation des Evidence Verifiers hält fest, dass seine Prüfungen die aufgezeichnete Verknüpfung der Entscheidungen belegen, „not downstream tool execution“.

Replay als Prüfungshandlung¶

Setzen Sie den Entscheidungs-Replay als Nachvollzugsprüfung an einer Stichprobe ein. Halten Sie jedes Ergebnis im Arbeitspapier fest; das ausgefüllte Prüfungsarbeitspapier für KI-Agenten enthält eine Replay-Zeile mit ihrer ausdrücklich genannten Einschränkung.

• Auswählen: Ziehen Sie die Stichprobe aus der abgeglichenen Grundgesamtheit, einschließlich der Ergebnisse block und require_approval sowie der Läufe rund um Richtlinienänderungen.
• Festlegen: Lösen Sie die aufgezeichnete Richtlinienversion und den Pack-Hash gegen das Release-Archiv auf.
• Nachspielen: Werten Sie die Entscheidung über die aufgezeichneten Eingaben ohne Tool-Zugriff erneut aus.
• Vergleichen: Gleichen Sie Ergebnis und Regeln mit dem Datensatz ab. Ordnen Sie jede Abweichung ein: Regeländerung, nicht gespeicherte Eingabe, Schemaänderung, Abhängigkeit von Judge oder Modell oder eine ungeklärte Abweichung.
• Wirkungen getrennt testen: Verfolgen Sie jede ausgeführte Aktion bis in das nachgelagerte System und gleichen Sie sie ab.
• Grenzen berichten: Nennen Sie, welche Gates ausgelassen wurden und warum, und übertragen Sie die Schlussfolgerung des Replays nicht auf externe Wirkungen.