Zum Hauptinhalt springen
Eine Framework-Checkliste ist eine Liste von Klauseln. Ein Compliance-Pack ist dieselbe Checkliste, bei der jede Klausel mit einer Kontrolle verdrahtet ist, die tatsächlich auf dem Gateway läuft. Wenn Sie ein Pack installieren, liest OrcaRouter sein Klausel-zu-Kontrolle-Mapping und materialisiert echte, editierbare Policy-Objekte in Ihrem Workspace — sodass „SOC 2 CC6.1” aufhört, eine Zeile in einer Tabelle zu sein, und zu einem Guardrail wird, das vertrauliche PII blockiert, bevor sie das Modell erreicht. Diese Seite erklärt, was ein KI-Compliance-Pack enthält, wie seine zwei Enforcement-Ebenen auf Klauseln zurückbilden und die Provenienz-Lineage, die einen Auditor jede Klausel bis zur exakten durchsetzenden Policy zurückverfolgen lässt. Für den Install-Ablauf und den signierten Report folgen Sie den Links am Ende.

​
1. Ein Pack ist ein Klausel-zu-Kontrolle-Mapping, keine neue Durchsetzung

Ein Pack liefert keine neue Runtime-Engine. Jede Kontrolle, die es trägt, verwendet dieselbe Guardrails- und Firewall-Maschinerie wieder, die Sie bereits von Hand konfigurieren — ein Pack ist das verfasste Mapping, das sagt, welche existierende Kontrolle welche Klausel erfüllt. Jedes Pack umspannt zwei Enforcement-Ebenen:

Guardrail-Ebene

Die Text-/Daten-Kontrollen — Klauseln über vertrauliche Daten, PII-Offenlegung, Injection-Abwehr oder erforderliche Offenlegungen bilden auf Guardrail-Regeln (pii, regex, llm_judge und Verwandte) mit einer block-, mask- oder flag-Aktion ab.

Firewall-Ebene

Die Tool-Call-Kontrollen — Klauseln über exzessive Handlungsfreiheit, gefährliche Aktionen oder Egress bilden auf Firewall-Regeln mit einem allow- / audit- / deny-Verdikt auf der inbound-, response-, mcp- oder egress-Surface ab.
Die Installation des Packs führt seine ausgewählten Kontrollen in ein Guardrail und eine Firewall-Policy zusammen, getaggt mit der Provenienz des Packs, sodass sie über den normalen Resolver gemeinsam durchsetzen und jeder existierende Anhängungs- und History-Pfad weiterhin funktioniert.
Ein Pack deckt nur am Gateway durchsetzbare Kontrollen ab. Organisatorische Klauseln — Mitarbeiterschulung, Business-Associate-Agreements, physischer Zugang — können niemals von einem Proxy durchgesetzt werden, daher legt der Report sie als Lücken offen (oder als Owner-attestiert), statt falsche Abdeckung zu behaupten. Siehe die Control-Matrix.

​
2. Eine Klausel, von Anfang bis Ende — ein konkretes Beispiel

Nehmen Sie das SOC-2-Pack. Es ordnet drei Trust-Services-Klauseln drei Live-Kontrollen zu:
KlauselEbeneKontrolle
CC6.1 Logischer Zugangguardrailvertrauliche PII in Prompts blockieren
CC7.2 System-Monitoringguardrailjede Guardrail-Entscheidung als Nachweis aufzeichnen
CC7.2 Anomalieerkennungfirewalljeden Tool-Dispatch auditieren
Sie installieren es aus der Konsole — Compliance → Catalog → SOC 2 → Install —, was nur Workspace-Admin ist und unter Ihrer Konsolen-Session POST /api/compliance/packs/soc2/install für Sie aufruft. Sie übergeben einer Konfigurationsroute niemals einen Relay-sk-orca-…-Key; Content und Policy leben vollständig hinter Ihrem Konsolen-Login. Nach der Installation ist die CC6.1-Zeile keine Prosa mehr — sie ist eine Guardrail-Regel, die Sie öffnen, lesen und wie jede andere tunen können.

​
3. Provenienz-Lineage — Klausel zur durchsetzenden Policy

Der Grund, warum ein Pack auditierbar ist, ist, dass die Verbindung zwischen einer Klausel und der sie durchsetzenden Policy aufgezeichnet, nicht impliziert ist. Jede Kontrolle, die das Pack materialisiert, trägt:
Eine stabile control_id (z. B. soc2.confidentiality) und den wortgetreuen Klauseltext (TSC CC6.1 Logical access controls), plus einen offiziellen Quell-Link, sodass ein Auditor die Regulierung liest, nicht nur unsere Paraphrase.
Ob die Kontrolle auf der guardrail- oder firewall-Ebene lebt, und die ID der exakten Guardrail- oder Firewall-Policy, die die Installation materialisiert hat. Diese ID ist es, die eine Zeile im Report mit einem lebenden, editierbaren Objekt in Ihrem Workspace verknüpft.
covered, observe, gap oder attested — und, über den Report-Zeitraum, wie oft diese Kontrolle tatsächlich gefeuert hat. Eine Klausel mit null Matches und eine Klausel, die 4.000 Requests blockiert hat, lesen sich für einen Auditor unterschiedlich, und der Report zeigt beide.
Jedes Pack trägt eine MappedBy-Zeile — wer das Klausel-zu-Kontrolle-Mapping verfasst hat, seine Version und den ehrlichen Disclaimer, dass es nur am Gateway durchsetzbare Kontrollen abdeckt und selbst keine Zertifizierung ist. Diese Zeile wird auf das Deckblatt des signierten Reports gestempelt.
Zusammengenommen ist dies die Lineage, die ein Auditor abschreitet: Klausel → Control-ID → durchsetzendes Guardrail oder Firewall-Policy → die Matches, die sie in diesem Zeitraum produziert hat → wer das Mapping verfasst hat. Kein Schritt wird erschlossen.
Dieselbe Abdeckungsmatrix treibt sowohl die Konsole als auch den Report an, sodass die beiden niemals stillschweigend auseinanderdriften können. Eine Klausel, die das Framework erwartet, die aber kein installiertes Pack abdeckt, rendert auf beiden Surfaces immer als offengelegte Lücke.

​
4. Erst beobachten, dann durchsetzen

Ein Pack beginnt nicht in dem Moment, in dem Sie es installieren, Traffic zu blockieren. Installationen landen im Observe-Mode: Guardrail-Aktionen werden auf flag gezwungen und die Firewall-Policy läuft im Shadow (log-only). Das Pack produziert „would-have-blocked”-Nachweise, sodass Sie genau sehen können, was es gegen echten Traffic täte, bevor es das tut. Wenn Sie zufrieden sind, ruft ein Workspace-Admin Go-Live auf, was die deklarierten Aktionen der Kontrollen (mask / block / deny) wiederherstellt und optional die materialisierten Policies zum Workspace-Default befördert. Dies ist dieselbe Observe-dann-Enforce-Disziplin, beschrieben in Observe vs. Enforce.
Das Durchsuchen des Katalogs, der installierten Packs und der Readiness ist für jedes Workspace-Mitglied offen und kostenlos. Ein Pack zu installieren und live zu gehen sind Workspace-Admin-Aktionen, die einen kostenpflichtigen Plan erfordern — der Server setzt beide Gates durch, sodass ein Viewer oder ein kostenloser Workspace keine Durchsetzung materialisieren kann, indem er die API direkt aufruft. Einen Report zu erzeugen ist ebenfalls Admin: Der kostenlose Plan enthält einen PDF-Report, während CSV-/JSON-Exporte und weitere Reports einen kostenpflichtigen Plan erfordern. Das Setzen der Datenresidenz ist ebenfalls Workspace-Admin, aber selbst nicht hinter einer Paywall.

​
5. Was ein Pack nicht enthält

Um die Grenze ehrlich zu halten:
  • Keine Zertifizierung. Ein Pack ordnet Ihre Gateway-Kontrollen den Klauseln eines Frameworks zu und produziert signierte Nachweise. Es ist kein Audit, keine Attestierung Ihrer gesamten Organisation und keine Rechtsberatung.
  • Keine organisatorischen Kontrollen. Personen-und-Prozess-Klauseln werden als offengelegte Lücken oder Owner-Attestierungen aufgeführt, niemals als automatisierte Abdeckung.
  • Kein Zauberkatalog. Die Frameworks im Katalog sind die mit einem verfassten Mapping — SOC 2, HIPAA, GDPR / UK GDPR, der EU AI Act, ISO 27001 / 42001, NIST AI RMF, PCI DSS, die OWASP LLM Top 10 und die regionalen Datenschutzgesetze. Durchsuchen Sie den Live-Satz unter Frameworks.

​
6. Wohin als Nächstes

Ein Pack installieren

Der vollständige Install-Ablauf — Kontrollen auswählen, Observe-Mode und Go-Live.

Der signierte Report

Was der Ed25519-signierte Nachweis-Report enthält und wie die Lineage für einen Auditor rendert.

Control-Matrix

Jede Klausel, ihre Ebene und ob sie covered, observed, eine Lücke oder attested ist.

Guardrails vs. Firewall

Die zwei Ebenen, in die ein Pack schreibt, und wie der Resolver sie zusammen ausführt.
Ein Compliance-Pack ist die Brücke zwischen der Sprache eines Regulierers und der Durchsetzung des Gateways: Es ordnet jede Klausel einer echten Kontrolle zu, materialisiert diese Kontrolle in eine Policy, die Ihnen gehört und die Sie tunen können, und zeichnet die Lineage auf, damit der Nachweis einer Prüfung standhält.