Architekturüberblick
Ein mentales Modell auf Produktebene, das zeigt, wie die KLA Control Plane Ihre bestehenden KI-Agenten umschließt, um jede Aktion zu steuern, zu betreiben, abzusichern und nachzuweisen.
Die KLA Control Plane ist eine Schicht für Laufzeitsicherheit, Audit und Governance, die Enterprise-KI-Agenten direkt an ihrem bestehenden Einsatzort steuert ("Govern in place"). "Govern in place" bedeutet, dass Sie die Agenten instrumentieren, die Sie bereits betreiben (LangChain-Chains, FastAPI-Dienste oder vollständig eigenen Code), anstatt sie auf eine neue Laufzeitumgebung zu portieren. KLA umschließt diese Agenten mit einer schlanken Instrumentierungsschicht und einer Reihe stets aktiver Planes, die entscheiden, ob eine Aktion zulässig ist, festhalten, was geschehen ist, und einen kryptografischen Nachweis darüber versiegeln.
Diese Seite beschreibt ein logisches mentales Modell, kein Infrastrukturdiagramm. Sie erläutert die Planes, die ein Entwickler, Betreiber oder Auditor verstehen muss, und wie eine einzelne Agentenaktion durch sie hindurchläuft.
Die Planes auf einen Blick
KLA ist in eine kleine Anzahl zusammenwirkender Planes gegliedert. Jede entspricht einer der vier Produktsäulen: Govern. Operate. Assure. Prove.
| Plane | Aufgabe | Säule |
|---|---|---|
| Instrumentation / SDK | Erzeugt OpenTelemetry-Spans aus Ihrem Agenten und fordert vor riskanten Aktionen Policy-Entscheidungen an | Govern |
| Policy Engine | Bewertet jede Aktion anhand signierter Policy Packs und liefert eines von vier Ergebnissen | Govern |
| Decision Desk | Hält pausierte Aktionen zur menschlichen Prüfung zurück, wenn eine Policy eine Freigabe verlangt | Govern / Operate |
| Collector | Empfängt Telemetrie, schwärzt PII und normalisiert Spans | Operate / Prove |
| Evidence Ledger | Verankert versiegelte Datensätze in einem nur erweiterbaren kryptografischen Ledger | Prove |
| Console-Oberflächen | Die Web-Module, über die Menschen das System steuern und einsehen | Alle vier |
Wie eine Aktion abläuft
Jede gesteuerte Aktion folgt demselben Pfad. Der Agent ruft das KLA SDK auf, bevor er einen sensiblen Schritt ausführt (einen Tool-Aufruf, einen Datenbankschreibvorgang, eine Zahlung). Das SDK öffnet einen OpenTelemetry-Span und übermittelt eine Decision Request an die Policy Engine, die eines von vier Ergebnissen in Vorrangreihenfolge zurückgibt: allow, warn, require_approval oder block. Ein allow oder warn lässt die Aktion fortfahren; ein require_approval pausiert die Ausführung und leitet eine Escalation an das Decision Desk weiter, damit ein Mensch sie genehmigen oder ablehnen kann; ein block stoppt die Aktion vollständig. Unabhängig vom Ergebnis fließt der Span über den Collector in das Evidence Ledger.
flowchart LR
A["Agentenaktion"] --> SDK["KLA SDK<br/>Instrumentierung"]
SDK --> PE{"Policy Engine<br/>Entscheidung"}
PE -->|allow / warn| EX["Aktion ausführen"]
PE -->|require_approval| DD["Decision Desk<br/>menschliche Prüfung"]
PE -->|block| ST["Aktion stoppen"]
DD -->|approved| EX
DD -->|denied| ST
EX --> COL["KLA Collector<br/>PII-Schwärzung"]
ST --> COL
DD --> COL
COL --> LED["Evidence Ledger<br/>Merkle proofs"]
LED --> EB["Sealed Evidence Bundle"]Die Instrumentierungsschicht
Zwei Deployment-Muster verbinden Ihre Agenten mit KLA:
- Govern in Place: Sie fügen das KLA SDK zu Ihrem bestehenden Code hinzu. Es erzeugt asynchrone OpenTelemetry-Spans und führt In-Process-Gates aus, sodass eine Policy-Entscheidung inline vor der Aktion erfolgt. Ihr Agent läuft weiterhin dort, wo er bereits angesiedelt ist.
- Run through KLA: Sie leiten die Agentenausführung über einen verwalteten Proxy mittels der Executions API. KLA beobachtet und steuert jeden Schritt zentral, was nützlich ist, wenn Sie den Code des Agenten nicht ändern können.
Beide Muster erzeugen dieselbe Telemetrie und speisen dieselben nachgelagerten Planes. Spans tragen semantische GenAI-Attribute, die das Verhalten des Agenten lesbar machen: genai.agent.name, genai.system.instructions, genai.tool.name, genai.tool.parameters, genai.cost.usd und genai.token.usage.
from kla import KLA
kla = KLA(api_url="https://api.kla.digital", tenant="acme")
# Vor einem sensiblen Tool-Aufruf eine Entscheidung anfordern.
decision = kla.decide(
agent="claims-triage",
action="execute_refund",
attributes={"amount": 240.00, "currency": "USD"},
)
if decision.outcome == "allow":
issue_refund()
elif decision.outcome == "require_approval":
decision.wait() # Pausiert, bis das Decision Desk die Escalation auflöst.
Die Policy Engine
KLA nutzt die KLA Policy Engine auf der Anwendungsebene, um Decision Requests zu bewerten. Policies sind deklarative Regeln, die festlegen, wer was unter welchen Bedingungen tun darf und welche Laufzeitprüfungen gelten sollen. Sie verfassen sie im Policy Builder, führen vor der Veröffentlichung eine Simulation gegen historischen Datenverkehr aus und kompilieren sie anschließend zu signierten Policy Packs: manipulationssicheren Bundles, die die Engine zur Laufzeit lädt. Jede Prüfung wird auf dasselbe Modell mit vier Ergebnissen aufgelöst, sodass eine Übereinstimmung die Aktion zulassen, eine Warnung aufzeichnen, für eine menschliche Freigabe pausieren oder die Ausführung blockieren kann.
Die Evidence-Pipeline
Der Datenpfad, der den Nachweis erzeugt, ist bewusst linear und einseitig gerichtet:
flowchart LR S["OpenTelemetry-Spans"] --> C["KLA Collector<br/>PII-Schwärzung"] C --> L["ImmuDB-Ledger<br/>nur erweiterbar, Merkle proofs"] L --> B["Sealed Evidence Bundle"] B --> P["Control Pack-Export"]
Spans treffen beim KLA Collector ein, der PII (E-Mail-Adressen, Kartennummern, Secrets) schwärzt, bevor etwas gespeichert wird. Bereinigte Datensätze werden gehasht und in ImmuDB verankert, einem nur erweiterbaren kryptografischen Ledger: Datensätze können nicht bearbeitet, gelöscht oder umgeordnet werden, und jeder ist über einen Merkle proof nachweisbar. Von dort exportieren Auditoren aus dem Evidence Room ein Sealed Evidence Bundle (den überprüfbaren Datensatz eines einzelnen Trace, genannt Lineage Record) oder einen Control Pack (einen auf ein Framework abgebildeten Compliance-Export).
Mandantenfähigkeit und der Datenpfad
KLA ist von Grund auf mandantenfähig konzipiert. Jede Anfrage trägt eine Mandantenidentität, und jeder Datensatz (Decision Request, Lineage Record, Escalation, Evidenzanker) ist auf einen einzelnen Mandanten beschränkt. Aufrufer geben ihren Mandanten bei jedem API-Aufruf an:
curl https://api.kla.digital/v1/decisions \
-H "Authorization: Bearer <token>" \
-H "x-tenant-id: <tenant>"
Die Mandantenisolation wird auf der Datenebene durchgesetzt, sodass die Policies, Traces und Evidenzen eines Mandanten für einen anderen niemals sichtbar sind. Dieselbe Grenze gilt durchgängig: Telemetrie von den Agenten eines Mandanten fließt nur in das Ledger dieses Mandanten und erscheint nur in dessen Console.
Die Console-Oberflächen
Die Planes werden über sieben Web-Module gesteuert und eingesehen, von denen jedes ein Fenster auf einen Teil des Ablaufs ist:
- Command: die Startoberfläche für die Live-Gesundheit der Agenten und die jüngste Aktivität.
- Agents: die Agent Registry und der Lebenszyklus: ein Release (Workflow-Version), ein Rollout (Deployment) und Rollback.
- Policy Builder: Policies verfassen, simulieren und veröffentlichen.
- Decision Desk: pausierte Escalations mit vollständigem Kontext auflösen.
- Lineage Explorer: jeden Lineage Record Schritt für Schritt erneut abspielen.
- Assurance Center: Drift als Assurance Alerts verfolgen und über einen Remediation Plan handeln (die Säule "Assure").
- Evidence Room: Sealed Evidence Bundles und Control Packs exportieren.
Wie es weitergeht
Beginnen Sie mit den beiden grundlegenden Konzepten, die dieser Überblick nur skizziert: Policy-Gated Execution für das Entscheidungsmodell mit vier Ergebnissen und Evidence-by-Default für das kryptografische Ledger. Erkunden Sie anschließend die Module im Detail, Policy Builder, Decision Desk, Lineage Explorer und Evidence Room, oder binden Sie einen Agenten mit dem Python SDK oder Node SDK an.