Deployment-Muster und Einrichtung

Die KLA Control Plane ist eine Schicht für Laufzeitsicherheit, Audit und Governance, die Enterprise-KI-Agents direkt vor Ort steuert (govern in place). Sie instrumentieren die Agents und APIs, die Sie bereits betreiben (LangChain, FastAPI oder eigenen Code), anstatt sie neu zu plattformieren. KLA unterstützt zwei Integrationsmuster, die Sie innerhalb eines einzigen Deployments kombinieren können: Govern in Place umhüllt Ihre bestehende Laufzeit mit dem OpenTelemetry SDK, während Run through KLA die Ausführung über einen verwalteten Proxy mithilfe der Executions API leitet. Diese Seite vergleicht beide Ansätze, zeigt, wie sie jeweils funktionieren, und hilft Ihnen bei der Auswahl.

Topologievergleich

Muster 1: Govern in Place

Ihre Agents laufen weiterhin in ihrer eigenen Umgebung. Das KLA SDK sendet OpenTelemetry-Spans asynchron an die Control Plane, sodass die Telemetrie niemals im Request-Pfad liegt. Die Durchsetzung erfolgt an Checkpoints: Stellen in Ihrem Code, an denen Sie KLA fragen, ob eine Aktion erlaubt ist, bevor Sie sie ausführen. An jedem Checkpoint gibt die Policy-Engine eines von vier Ergebnissen zurück, ausgewertet in Vorrangreihenfolge: allow, warn, require_approval oder block. Ein Ergebnis von require_approval pausiert die Ausführung und leitet eine Escalation an das Decision Desk weiter, die Oberfläche von KLA für die menschliche Prüfung, auf der ein Prüfer über die Decision Request entscheidet.

flowchart LR
  A["Ihre Agent-App (SDK-umhüllt)"] --> B["LLM-Provider"]
  A -->|checkpoint| C{"Policy-Entscheidung"}
  C -->|allow / warn| A
  C -->|require_approval| D["Decision Desk"]
  C -->|block| E["Aktion abgelehnt"]
  A -. async spans .-> F["KLA Control Plane"]

Einrichtungsanleitung

1. Installieren Sie das SDK für die Sprache Ihrer Anwendung (Python oder Node.js).
2. Initialisieren Sie das SDK am Einstiegspunkt Ihrer Anwendung, damit die Spans an die Control Plane fließen.
3. Umhüllen Sie sensible Tool-Aktionen oder Modell-Completions mit einem KLA-Checkpoint.

# Govern in Place: evaluate an action at a checkpoint
from kla_sdk import KLACheckpoint

checkpoint = KLACheckpoint(agent_id="agt_9f81a7")

# If policy returns require_approval, this blocks and opens an
# Escalation on the Decision Desk until a reviewer resolves it.
decision = checkpoint.evaluate_action(
    tool="process_refund",
    context={"amount": 1250.00},
)

if decision.outcome == "allow":
    execute_refund()
else:
    raise PermissionError(f"Refund {decision.outcome} by governance policy")

Muster 2: Run through KLA

Hier sendet Ihr Client Requests an die Executions API, anstatt direkt einen Modellprovider aufzurufen. KLA löst die Provider-Anmeldedaten aus dem Secrets Vault auf, wendet die Policy inline an, führt den Agent gegen das Modell aus und zeichnet den Lineage Record auf, alles in einem konsolidierten Schritt. Da die Durchsetzung inline erfolgt, stoppt ein block-Ergebnis den Request, bevor irgendein Tool ausgeführt wird.

flowchart LR
  A["Client-Frontend (Chat-UI)"] -->|Executions API| B["KLA Control Plane"]
  B --> C{"Policy-Entscheidung"}
  C -->|allow / warn| D["LLM-Provider"]
  C -->|require_approval| E["Decision Desk"]
  C -->|block| F["Request abgelehnt"]
  D --> B
  B -->|response + Lineage Record| A

Einrichtungsanleitung

1. Hinterlegen Sie die Anmeldedaten Ihres Modellproviders im Secrets Vault.
2. Registrieren Sie den Agent mit seinen Systemanweisungen, Parametern und Tools im Agent Registry.
3. Richten Sie Ihren Client auf die Executions API aus, statt auf OpenAI oder Anthropic.

curl -X POST https://api.kla.digital/v1/executions \
  -H "Authorization: Bearer $KLA_ACCESS_TOKEN" \
  -H "x-tenant-id: $KLA_TENANT" \
  -H "Content-Type: application/json" \
  -d '{
    "agentId": "agt_9f81a7",
    "input": { "prompt": "Summarize outstanding contracts" }
  }'

Ein Ergebnis von require_approval gibt eine Escalation-Referenz und einen ausstehenden Status zurück; pollen Sie die Ausführung oder abonnieren Sie Decision-Desk-Ereignisse, um fortzufahren, sobald ein Prüfer zustimmt.

Auswahl eines Musters

Für Entwickler und Integratoren mit einem bestehenden produktiven Agent, etwa einem LangChain-Workflow zur Schadenstriage, der bereits Traffic bedient, ist Govern in Place der schnellste Weg: Fügen Sie das SDK und einige Checkpoints hinzu, ändern Sie kein Routing und halten Sie Ihr Latenzbudget intakt. Für Plattformbetreiber, die einen Greenfield-Agent oder eine Standard-Chat-Oberfläche aufbauen, beseitigt Run through KLA den meisten Code, da KLA Credential-Injection, Inline-Durchsetzung und Trace-Kompilierung hinter einem einzigen Endpunkt übernimmt. Für Compliance- und Risikoverantwortliche ist die Entscheidung beruhigend neutral: Beide Muster speisen dieselbe Policy-Engine und dieselbe Pipeline für versiegelte Nachweise, sodass Ihre Control Pack-Exporte und Sealed Evidence Bundles identisch aussehen, unabhängig davon, wie der Agent angebunden ist. Die meisten Unternehmen betreiben beides: Sie instrumentieren Legacy-Systeme vor Ort, während sie neue Agents über KLA leiten, und steuern sie alle von einer einzigen Control Plane aus.