Policy Builder

Policy Builder ist der Autorenarbeitsplatz der KLA Control Plane, erreichbar unter der Route /policy-studio. Die KLA Control Plane ist eine Govern-in-Place-Schicht für Laufzeitsicherheit, Audit und Governance von KI-Agenten im Unternehmen: Sie instrumentieren Ihre bestehenden Agenten, statt sie auf eine neue Plattform zu migrieren. Im Policy Builder schreiben Sie die Regeln, die festlegen, was diese Agenten tun dürfen. Jede folgenreiche Agentenaktion, sei es das Auslösen einer Rückerstattung, das Versenden eines Dokuments zur Prüfung oder der Aufruf einer externen API, wird vor der Ausführung gegen die Richtlinie geprüft, die Sie hier veröffentlichen. Diese Seite beschreibt, wie Sie eine Richtlinie einrichten, welche zwei Möglichkeiten der Bearbeitung es gibt, wie eine Simulation ihr Verhalten vor der Veröffentlichung nachweist und was ein signiertes Policy Pack ist.

Wer es nutzt

Policy Builder ist gemeinsame Grundlage für zwei Rollen. Compliance-, Risiko- und Audit-Verantwortliche besitzen die Absicht (was genehmigt werden muss, was blockiert werden muss, wo die Schwellenwerte liegen) und verfassen Regeln zunehmend selbst. Entwickler und Integratoren besitzen die Präzision: die exakten Attribute, Bedingungen und Reason Codes, die die Runtime auswertet. Der Arbeitsbereich ist so aufgebaut, dass beide am selben Entwurf arbeiten können, ohne sich gegenseitig zu blockieren: Eine nicht-technische Autorin kann eine Absicht formulieren, und eine Entwicklerin kann die zugrunde liegende Bedingung verfeinern.

Absichtsgeleitete Einrichtung

Sie beginnen nicht mit einer leeren YAML-Datei. Policy Builder öffnet sich mit Absichtskategorien: Ausgangspunkte in klarer Sprache, die eine funktionierende Regel als Gerüst erzeugen, die Sie anschließend feinjustieren.

• Nach Sensibilität steuern: Aktionen mit höherem Risiko über einen strengeren Pfad leiten.
• Genehmigung bei risikoreichen Vorgängen verlangen: eine Aktion für eine menschliche Entscheidung anhalten.
• Eine Tool-Aktion blockieren: eine bestimmte Fähigkeit vollständig verweigern, etwa einen Datenbankschreibvorgang.
• Datengrenzen durchsetzen: regulierte Daten innerhalb einer genehmigten Region oder eines genehmigten Systems halten.

Jede Absicht erzeugt eine Entwurfsregel mit der richtigen Struktur und sinnvollen Standardwerten. Sie hängen die für Ihren Anwendungsfall relevanten Geschäftsattribute an, etwa Transaktionsbetrag, Kundenstufe und Dokumentklassifizierung, und legen die Schwellenwerte fest.

Visueller Editor oder rohes YAML der Regel

Policy Builder bietet Ihnen zwei synchronisierte Ansichten derselben Regel:

• Visueller Bedingungseditor: Bedingungen aus Feldern, Operatoren und Werten zusammenstellen, ohne YAML zu schreiben. Ideal für schnelles Verfassen und für Prüfer, die die Absicht statt der Syntax lesen möchten.
• Roher YAML-Editor: die zugrunde liegende Regeldefinition direkt bearbeiten, für vollständige Ausdrucksstärke, einschließlich zusammengesetzter Bedingungen, Runtime-Prüfungen, Reason Codes, Remediation und Genehmigungspfade.

Beide Ansichten schreiben in denselben Entwurf, sodass Sie eine Absicht visuell skizzieren und zur Fertigstellung in YAML wechseln können.

# Entwurfsregel (illustrativ): hochwertige Rückerstattungen werden für eine menschliche Entscheidung angehalten
rule: high-value-refund
when:
  tool: execute_refund
  amount: "> 100.00"
then:
  decision: require_approval
  reasonCode: REFUND_OVER_THRESHOLD
  route: Decision Desk

Die Entscheidung require_approval weist KLA an, die Ausführung anzuhalten und die Aktion an das Decision Desk weiterzuleiten. Eine Entscheidung block würde die Aktion vollständig stoppen.

Vor der Veröffentlichung simulieren

Ein Entwurf gelangt nie direkt in die Runtime. Sie führen eine Simulation durch: einen Richtlinien-Testlauf, der repräsentative Decision Requests (eine Aktion samt ihrem Kontext) gegen den Entwurf abspielt und zeigt, wie jede aufgelöst wird. Das Entscheidungsmodell von KLA kennt vier Ergebnisse in der folgenden Vorrangordnung:

Mit der Simulation bestätigen Sie, bevor irgendetwas live ist, dass eine Rückerstattung über $420 pausiert und eine Rückerstattung über $40 durchgeht, ohne ein laufendes System anzutasten. KLA blockiert die Veröffentlichung jedes Entwurfs, der das Linting nicht besteht, sodass ein Ergebnis require_approval oder block ohne seinen Reason Code oder seine Remediation-Hinweise hier abgefangen wird, nicht erst in der Produktion.

Kompilierte, signierte Policy Packs

Wird ein validierter Entwurf veröffentlicht, kompiliert KLA ihn in ein signiertes Policy Pack: ein versioniertes, kryptografisch signiertes Bündel, das die Runtime lädt, um Richtlinien auszuwerten. Die Signatur macht die Auswertung manipulationssicher, da die Runtime nur Packs durchsetzt, die sie verifizieren kann, und die Versionierung bedeutet, dass jede Entscheidung auf die exakte Richtlinie zurückgeführt werden kann, die sie hervorgebracht hat. Die Kompilierung macht die Auswertung außerdem schnell genug, um im Pfad von Live-Agentenaktionen zu liegen.

flowchart LR
  A["Absicht oder YAML-Bearbeitung"] --> B["Richtlinienentwurf"]
  B --> C{"Simulation"}
  C -->|Ergebnisse falsch| B
  C -->|Ergebnisse korrekt| D["Veröffentlichen"]
  D --> E["Signiertes Policy Pack"]
  E --> F["Runtime-Durchsetzung"]

Wie es zusammenhängt

Policy Builder ist die Quelle der Regeln; zwei weitere Module sind die Orte, an denen diese Regeln wirksam werden.

• Policy-Gated Execution ist der Laufzeitmechanismus, der jeden Decision Request gegen Ihr veröffentlichtes Pack auswertet und eines der vier Ergebnisse zurückgibt. Die Richtlinien, die Sie hier verfassen, sind genau das, was er durchsetzt.
• Decision Desk ist der Ort, an dem ein Ergebnis require_approval landet. Wenn eine Regel eine Aktion pausiert, öffnet KLA eine Escalation und leitet sie dorthin, damit ein autorisierter Prüfer genehmigen oder ablehnen kann.

Verfassen Sie die Regel im Policy Builder, weisen Sie sie in der Simulation nach, veröffentlichen Sie das signierte Pack, und die Runtime regelt von diesem Moment an jede passende Aktion.