Decision Desk | Developer Docs

Der Decision Desk (/approvals-inbox) ist der Ort, an dem Menschen die Entscheidungen treffen, die Maschinen nicht allein treffen sollten. Wenn die KLA Policy Engine eine require_approval-Entscheidung zurückgibt, wird die Aktion des Agenten nicht ausgeführt. Die Ausführung wird angehalten, und KLA öffnet eine Escalation, ein Objekt für manuelle Eingriffe, das alles enthält, was ein Prüfer zum Handeln benötigt. Das Arbeitselement, das der Prüfer letztlich auflöst, ist eine Decision Request. Der Decision Desk ist die Warteschlange, die Prüfoberfläche und der Prüfnachweis für jeden dieser Momente.

Das ist wichtig, weil require_approval eines der vier Richtlinienergebnisse von KLA ist, in Vorrangreihenfolge: allow, warn, require_approval, block. Die ersten beiden lassen die Arbeit fortlaufen; block stoppt sie vollständig. Nur require_approval übergibt die Entscheidung an einen Menschen, und der Decision Desk ist der Ort, an dem dieser Mensch steht.

ℹ️ Note

Der Decision Desk erstellt nicht die Regeln; diese liegen im **Policy Builder**. Er ist das Laufzeitziel für Aktionen, die eine Richtlinie bewusst an Menschen weitergeleitet hat, anstatt sie automatisch aufzulösen.

Wie eine Escalation zum Desk gelangt

flowchart LR
  A["Agentenaktion"] --> B{"Richtlinienentscheidung"}
  B -->|allow / warn| C["Fortsetzen"]
  B -->|block| D["Stoppen"]
  B -->|require_approval| E["Escalation öffnen"]
  E --> F["Decision-Desk-Warteschlange"]
  F --> G{"Prüfer handelt"}
  G -->|approve| H["Ausführung fortsetzen"]
  G -->|deny| I["Lauf beenden"]
  G -->|re-route| J["Leitender Prüfer"]
  J --> G

Der Lauf des Agenten wird angehalten, nicht abgebrochen, während die Escalation wartet. Der instrumentierte Agent (über das Govern in Place SDK) oder der verwaltete Proxy (Run through KLA) blockiert bei der ausstehenden Entscheidung, sodass kein Seiteneffekt eintritt, bis eine Person sie auflöst.

Die Warteschlange abarbeiten

Der Posteingang ist für die Triage bei hohem Aufkommen konzipiert. Prüfer filtern und sortieren über vier Dimensionen:

Dimension	Funktion
Priorität	Stellt kritische Escalations vor routinemäßige, `warn`-nahe Prüfungen.
Team	Leitet Elemente an die richtige Warteschlange weiter (Schadensfall-Triage, Erstattungsgenehmigung, Dokumentenprüfung), damit die Finanzabteilung niemals die Arbeit der Rechtsabteilung sieht.
Agent	Isoliert jede ausstehende Aktion eines einzelnen Agenten, nützlich, wenn sich ein Agent unerwartet verhält.
Status	Trennt offene Decision Requests von der aufgelösten Historie für Prüfung und Trendanalyse.

Weiterleitungsregeln werden in der Richtlinie deklariert, sodass eine Escalation standardmäßig vor dem Team landet, das dieses Risiko verantwortet, statt in einem gemeinsamen Stapel.

Eine Decision Request prüfen

Das Öffnen eines Elements gibt Prüfern den vollständigen Kontext hinter der angehaltenen Aktion, ohne Werkzeugwechsel und ohne Raten:

Prompt und Anweisungen: die Eingabe, die die Aktion ausgelöst hat, einschließlich genai.system.instructions, sodass der Prüfer sieht, was dem Agenten aufgetragen wurde.
Tool-Payload: der genaue genai.tool.name und genai.tool.parameters, die der Agent aufrufen wollte (der Erstattungsbetrag, der zu schreibende Datensatz, das zu sendende Dokument).
Auslösende Regel: die spezifische Richtlinie, die require_approval zurückgegeben hat, mit ihren Reason Codes, sodass die Entscheidung auf einer benannten Kontrolle beruht und nicht auf einer Vermutung.
Lineage-Verknüpfung: ein direkter Sprung in den Lineage Explorer, um den vollständigen Lineage Record bis zu diesem Schritt erneut abzuspielen.

Von hier aus ergreift der Prüfer eine von drei Aktionen:

Approve: hebt die Sperre auf; der Agent setzt genau dort fort, wo er angehalten wurde.
Deny: beendet den Lauf; die Aktion wird niemals ausgeführt.
Re-route / eskalieren: übergibt die Decision Request an einen höherrangigen Prüfer oder ein anderes Team, ohne den Kontext zu verlieren.

SLA und der Prüfaspekt

Jede Decision Request trägt Zeitangaben. Prüfer sehen, wie lange ein Element bereits gewartet hat, und überfällige Escalations werden gegen ihr Service-Level-Ziel sichtbar, damit nichts in der Warteschlange verrottet. Diese Zeitangaben sind Teil des Nachweises, nicht nur eine betriebliche Annehmlichkeit.

🛡️ Important

Jede Entscheidung ist ein Nachweis. Jedes Approve, Deny und Re-route wird als OpenTelemetry-Span erfasst, vom KLA Collector redigiert und in das kryptografische ImmuDB-Ledger geschrieben. Der Prüfer, die Aktion, die auslösende Regel und der Zeitstempel fließen allesamt in **Sealed Evidence Bundles** und **Control Packs** ein.

Das Ergebnis ist eine belastbare Antwort auf die schwierigste Frage des Prüfers, wer hat dies auf welcher Grundlage und wann genehmigt, ohne dass jemand es nachträglich rekonstruieren muss. Menschliches Urteilsvermögen wird zu einem erstklassigen, manipulationssicheren Bestandteil des Governance-Nachweises.

💡 Tip

Kombinieren Sie den Decision Desk mit dem **Assurance Center**. Eine steigende Rate von `require_approval`-Escalations bei einem Agenten ist oft ein frühes **Assurance Alert**, ein Signal, die Richtlinie oder den Agenten zu überprüfen, bevor die Prüfer ertrinken.