Policy-gesteuerte Ausführung

Wenn ein Enterprise-KI-Agent versucht, etwas Folgenreiches zu tun (eine Rückerstattung auslösen, ein Dokument zur Prüfung weiterleiten, eine externe API aufrufen), prüft KLA Control Plane diese Aktion gegen die Richtlinien, bevor sie ausgeführt wird. KLA Control Plane ist eine Govern-in-Place-Schicht für Laufzeitsicherheit, Audit und Governance von KI-Agenten: Sie instrumentieren Ihre bestehenden Agenten, anstatt sie auf eine neue Plattform umzustellen. Die Policy-gesteuerte Ausführung ist der Mechanismus, der in Echtzeit entscheidet, ob eine Aktion fortgesetzt wird, mit einer Warnung fortgesetzt wird, für eine menschliche Entscheidung pausiert oder gestoppt wird. Diese Seite erklärt das Entscheidungsmodell und wie aus einer pausierten Aktion eine Escalation wird, die an den Decision Desk weitergeleitet wird.

Die vier Entscheidungsergebnisse

Jede Richtlinienprüfung in KLA löst sich zu genau einem Ergebnis auf. Die Ergebnisse sind nach Vorrang geordnet: Wenn mehrere Regeln auf eine Aktion zutreffen, gewinnt das stärkste anwendbare Ergebnis.

Der Vorrang macht das Modell fail-closed und vorhersehbar. Wenn eine allgemeine Regel allow besagt, eine engere Regel mit höherem Vorrang jedoch require_approval, wird die Aktion pausiert. Ein einziges block an irgendeiner Stelle der zutreffenden Regelmenge stoppt die Aktion, unabhängig davon, wie viele allow-Regeln ebenfalls zutreffen.

flowchart LR
  A["Agentenaktion"] --> B{"Entscheidung der Policy Engine"}
  B -->|allow| C["Ausführen"]
  B -->|warn| D["Ausführen und Hinweis erfassen"]
  B -->|require_approval| E["Escalation erstellen"]
  E --> F["Decision Desk"]
  F -->|approved| C
  F -->|rejected| G["Aktion stoppen"]
  B -->|block| G

Wie eine Aktion geprüft wird

Der Agent (oder das KLA SDK in seinem Auftrag) übermittelt einen Decision Request: die Aktion samt ihrem Kontext. Der Kontext umfasst den aufrufenden Agenten, das aufgerufene Tool, die Parameter und alle Geschäftsattribute, die Sie anhängen (Transaktionsbetrag, Kundenstufe, Dokumentenklassifizierung). KLA prüft diese Anfrage gegen die aktuell für Ihren Tenant veröffentlichten Richtlinien und gibt eines der vier Ergebnisse zurück.

curl https://api.kla.digital/v1/decisions.evaluate \
  -H "Authorization: Bearer $KLA_ACCESS_TOKEN" \
  -H "x-tenant-id: acme" \
  -H "Content-Type: application/json" \
  -d '{
    "agent": "claims-triage",
    "action": "execute_refund",
    "attributes": { "amount": 420.00, "customer_tier": "standard" }
  }'

Eine require_approval-Antwort enthält die Kennung der eröffneten Escalation, sodass Ihre Integration dem Endnutzer anzeigen kann, dass die Aktion auf eine Prüfung wartet, statt fehlzuschlagen.

{
  "outcome": "require_approval",
  "reasonCodes": ["REFUND_OVER_THRESHOLD"],
  "remediation": "Refunds above $100 require a reviewer. This request was routed to the Decision Desk.",
  "escalationId": "esc_01HZ8K..."
}

Reason Codes und Remediation

Jede Entscheidung außer allow trägt neben dem Urteil zwei Dinge: einen oder mehrere Reason Codes und eine Remediation-Anleitung. Ein Reason Code ist eine stabile, maschinenlesbare Kennung (zum Beispiel REFUND_OVER_THRESHOLD), die erklärt, warum das Ergebnis erreicht wurde. Die Remediation-Anleitung ist eine kurze, menschenlesbare Anweisung, was als Nächstes zu tun ist.

Diese Kombination dient allen drei Lesergruppen. Entwickler verzweigen anhand von Reason Codes, statt Fließtext zu parsen. Prüfer am Decision Desk sehen den Kontext der vor ihnen liegenden Aktion in verständlicher Sprache. Compliance-Verantwortliche erhalten ein einheitliches Vokabular, das sich sauber auf Kontrollrahmenwerke abbilden lässt. Reason Codes und Remediation sind bei den Ergebnissen warn, require_approval und block verpflichtend, damit keine Ablehnung oder Pause jemals in einer stillen Sackgasse endet.

Die Policy Engine

KLA prüft Richtlinien auf der Anwendungsebene, nah an der Agentenaktion und ihrem geschäftlichen Kontext. Die Policy Engine kombiniert zwei Arten von Prüfungen:

• Zugriffsprüfungen entscheiden, ob der Aufrufer das Tool, die Datenquelle, den Workflow oder die Aktion überhaupt nutzen darf.
• Laufzeitprüfungen bewerten die Aktion im Kontext (das Tool und seine Argumente, sein Ziel, die Modell-Metadaten und die von Ihnen angehängten Geschäftsattribute) gegen das von Ihnen veröffentlichte Policy Pack.

Beide Arten von Prüfungen lösen sich zu denselben vier kundenseitigen Ergebnissen auf: allow, warn, require_approval oder block. Das stärkste zutreffende Ergebnis gewinnt, sodass eine Laufzeitprüfung eine Aktion auch dann pausieren oder stoppen kann, wenn der Aufrufer das Tool ansonsten nutzen darf.

# Policy rules (illustrative): refunds over $100 pause for review
- rule: low-value-refund
  when:
    tool: execute_refund
    amount: "<= 100.00"
  then:
    decision: allow
    reasonCode: REFUND_WITHIN_THRESHOLD

- rule: high-value-refund
  when:
    tool: execute_refund
    amount: "> 100.00"
  then:
    decision: require_approval
    reasonCode: REFUND_OVER_THRESHOLD
    route: Decision Desk

In diesem Beispiel trifft eine Rückerstattung von $420 auf die zweite Regel zu und löst sich zu require_approval auf, pausiert die Ausführung und eröffnet eine Escalation. Eine Rückerstattung von $40 trifft auf die erste Regel zu und wird fortgesetzt.

Wohin Genehmigungen gehen

Ein require_approval-Ergebnis erstellt eine Escalation: eine pausierte Arbeitseinheit, die auf eine menschliche Entscheidung wartet. Escalations landen im Decision Desk, wo ein autorisierter Prüfer die Aktion, ihre Attribute, die Reason Codes und die Remediation-Anleitung sieht und anschließend genehmigt oder ablehnt. Eine Genehmigung setzt die ursprüngliche Ausführung genau an der Stelle fort, an der sie pausiert wurde; eine Ablehnung stoppt sie. Die gesamte Abfolge (die Anfrage, die Entscheidung, die Escalation und das Urteil des Prüfers) wird als Lineage Record erfasst und liefert Ihnen für jede richtliniengesteuerte Aktion einen belastbaren Nachweispfad.

Die Richtliniendurchsetzung bei KLA liegt auf der Anwendungsebene, nah an der Agentenaktion, wo geschäftlicher Kontext wie Betrag und Kundenstufe verfügbar ist. Zulassungskontrollen auf Infrastrukturebene können Richtlinien zusätzlich an der Plattformgrenze durchsetzen, aber das hier beschriebene Laufzeit-Gating ist das, was das Verhalten von Agenten an Ort und Stelle steuert.