Zum Hauptinhalt springen
Die erste Frage eines Auditors lautet nie „Haben Sie eine Policy?” — sie lautet „Zeigen Sie mir Klausel für Klausel, welche Kontrolle sie erfüllt, und beweisen Sie, dass sie lief.” Eine Control-Matrix beantwortet genau das: eine Zeile pro in-scope-Klausel, die Ebene, auf die sie abbildet, das Live-Policy-Objekt, das sie durchsetzt, und ob diese Kontrolle covered, noch im observe, eine offengelegte gap oder owner-attested ist. OrcaRouter baut diese Matrix für Sie aus den Packs, die Sie installieren — dasselbe Mapping, das den signierten Report antreibt, sodass die Readiness-Ansicht und der Nachweis niemals auseinanderdriften können. Diese Seite zeigt, wie Sie die KI-Compliance-Control-Matrix für Ihren Workspace lesen und zusammenstellen, mit einer konkreten Klausel von Anfang bis Ende durchgegangen. Für das, was ein Pack tatsächlich enthält, folgen Sie den Links am Ende.

​
1. Was eine KI-Compliance-Control-Matrix hier ist

Die Matrix ist die Vereinigung zweier Listen pro Framework:
  • die Klauseln, die ein installiertes Pack abdeckt — jede verbunden mit der exakten Guardrail- oder Firewall-Policy, die die Installation materialisiert hat;
  • die Klauseln, die niemals am Gateway automatisiert werden können — Mitarbeiterschulung, Business-Associate-Agreements, physischer Zugang — als ehrliche gaps verfasst, sodass die Matrix sie offenlegt, statt ein falsches 100 % zu implizieren.
Die Matrix ist eine Ansicht, keine zweite Engine. Jede covered-Zeile zeigt auf eine echte, editierbare Guardrail-Regel oder Firewall-Policy, die Ihnen bereits gehört — öffnen Sie sie, lesen Sie sie, tunen Sie sie. Die Matrix zeichnet nur auf, welche welche Klausel beantwortet.
Jede Klausel bildet auf genau eine von zwei Ebenen ab:

Guardrail-Ebene

Content-Klauseln — vertrauliche PII, Secrets, erforderliche Disclosures — bilden auf eine Guardrail-Regel mit einer block-, mask- oder flag-Aktion ab.

Firewall-Ebene

Aktions-Klauseln — exzessive Handlungsfreiheit, gefährliche Tool-Calls, Egress — bilden auf eine Firewall-Regel mit einem allow- / audit- / deny-Verdikt auf der inbound-, response-, mcp- oder egress-Surface ab.

​
2. Die Readiness-Status, die eine Zeile tragen kann

Jede Matrix-Zeile trägt einen Status. Dies sind die Wörter, die ein Auditor liest, also bedeuten sie genau, was sie sagen:
StatusWas er bedeutet
coveredEine Pack-Kontrolle ist installiert und setzt die Klausel durch.
observeInstalliert, aber log-only — sammelt would-have-blocked-Nachweise, setzt noch nicht durch.
gapKeine installierte Kontrolle deckt die Klausel ab (oder sie ist organisatorisch und kann es nicht).
attestedEine organisatorische Klausel, die ein Admin owner-attestiert hat, statt sie zu automatisieren.
Eine gap ist kein Versagen — sie ist Ehrlichkeit. Eine organisatorische Klausel wie HIPAA 45 CFR §164.308(a)(5) Mitarbeiterschulung kann niemals von einem Proxy durchgesetzt werden, also führt die Matrix sie als offengelegte Lücke auf (oder, sobald ein Admin das Ownership attestiert, als attested), statt vorzugeben, das Gateway decke sie ab.
Es gibt auch ein drift-Overlay: Wenn das Mapping eines installierten Packs der aktuellen Katalogversion hinterherhinkt, rendern seine Zeilen als drift, sodass Sie wissen, dass Sie neu installieren sollten, bevor Sie sich auf den Nachweis verlassen.

​
3. Die Matrix lesen (ein konkreter Call)

Der Readiness-Endpunkt gibt die gesamte Matrix zurück — Abdeckungsprozentsätze pro Framework, die gerankten Top-Risiken über das Fenster und einen coverage_rows-Eintrag pro Klausel. Die Readiness zu durchsuchen ist für jedes Workspace-Mitglied offen und kostenlos, sodass Ihre Sicherheits- und Audit-Prüfer die Matrix ohne Schreibzugriff beobachten können. Die Konsole steuert diese Management-Route unter Ihrer Session — Sie übergeben einer Compliance-Route niemals einen Relay-sk-orca-…-Key: 
GET /api/compliance/readiness?window=30d
Authorization: Bearer <your console session>
Eine einzelne covered-Zeile sieht so aus — Klausel, Ebene, Status und die Live-Policy-ID, mit der sie verbunden ist: 
{
  "framework": "soc2",
  "control_id": "soc2.confidentiality",
  "clause": "TSC CC6.1 Logical access controls",
  "reference": "https://www.aicpa-cima.com/resources/...",
  "plane": "guardrail",
  "state": "covered",
  "guardrail_id": 41,
  "observe_count": 0,
  "organizational": false
}
Die guardrail_id (oder firewall_policy_id auf der Firewall-Ebene) ist das tragende Feld: Es bindet die Klausel direkt an ein Objekt, das Sie in der Konsole öffnen und wie jedes andere bearbeiten können. Das ist die Lineage, die ein Auditor abschreitet — Klausel → Control-ID → durchsetzende Policy → die Matches, die sie produziert hat.
Die Matrix zu lesen ist eine kostenlose Member-Fähigkeit. Sie zu bauen — ein Pack zu installieren, damit seine Kontrollen die Zeilen füllen — ist eine Workspace-Admin-Aktion auf einem kostenpflichtigen Plan, und der Server setzt beides durch. Ein Viewer oder ein kostenloser Workspace kann keine Abdeckung materialisieren, indem er die API direkt aufruft. Siehe Plan-Gating.

​
4. Die Matrix für Ihre Frameworks zusammenstellen

Sie bauen die Matrix, indem Sie Packs installieren. Jede Installation führt ihre Kontrollen in ein Guardrail und eine Firewall-Policy zusammen, getaggt mit der Provenienz des Packs, und ihre Klauseln beginnen, coverage_rows zu füllen:
  1. Wählen Sie Ihre Frameworks. Die Installation läuft aus der Konsole unter Compliance → Catalog, als Workspace-Admin. Der Katalog deckt Sicherheits- und KI-Governance-Regimes ab (soc2, iso_27001, iso_42001, nist_ai_rmf, eu_ai_act, owasp_llm), Branchenregimes (hipaa, pci_dss, glba, nist_800_53) und eine breite Auswahl regionaler Datenschutzgesetze (gdpr, uk_gdpr, ccpa und mehr). Durchsuchen Sie den Live-Satz unter Frameworks.
  2. Erst im Observe installieren. Eine frische Installation landet im Observe-Mode — Guardrail-Aktionen auf flag gezwungen, die Firewall-Policy im Shadow —, sodass jede neue Zeile als observe startet und would-have-blocked-Nachweise produziert, bevor sie durchsetzt.
  3. Beobachten, wie sich die Zeilen füllen. Holen Sie die Readiness über ein echtes Fenster erneut. Covered-Zeilen zeigen ihren observe_count; gaps bleiben offengelegt; organisatorische Klauseln warten auf die Attestierung.
  4. Live gehen. Wenn die Zeilen sauber lesen, geht ein Workspace-Admin live und die observe-Zeilen wechseln zur covered-Durchsetzung.
Die OWASP Top 10 für LLM-Anwendungen ist im Katalog als das owasp_llm-Pack — seine Klauseln (zum Beispiel LLM05:2025 Supply Chain) landen auf dieselbe Weise in der Matrix wie die jedes anderen Frameworks, gemappt auf Live-Kontrollen oder als gaps offengelegt. Siehe OWASP LLM Top 10.

​
5. Von der Matrix zum signierten Nachweis

Die Matrix, die Sie in der Konsole lesen, ist dieselbe Abdeckungsdaten, die der Report serialisiert — sodass, wenn Sie Nachweise erzeugen, der Auditor die identischen Pro-Klausel-Status sieht, plus die Enforcement-Zähler, die jede Kontrolle über den Zeitraum produziert hat. Eine Klausel, die 4.000 Requests blockierte, und eine Klausel mit null Matches lesen sich sehr unterschiedlich, und der Report zeigt beide. Reports sind SHA-256-gehasht, Ed25519-signiert und öffentlich verifizierbar.
Die exakten Guardrail- und Firewall-Objekte, die ein Pack materialisiert, und wie jede Klausel mit ihrer durchsetzenden Policy verbunden ist — siehe Pack-Inhalte.
Warum jede Zeile im Observe startet, was sie loggt und wie Go-Live sie umlegt — siehe Observe vs. Enforce.
Wie die Matrix für einen Auditor rendert, mit Pro-Klausel-Status und Enforcement-Zählern — siehe Signierter Report.

​
6. Wohin als Nächstes

Ein Pack installieren

Der vollständige Install-Flow, der die Matrix füllt — Kontrollen auswählen, Observe-Mode und Go-Live.

Alle Frameworks

Der Live-Katalog der Frameworks, deren Klauseln Sie in die Matrix bauen können.

Guardrails vs. Firewall

Die zwei Ebenen, auf die eine Matrix-Zeile abbilden kann, und wie der Resolver sie zusammen ausführt.

Geteilte Verantwortung

Warum einige Klauseln am Gateway durchsetzbar sind und andere Ihnen bleiben — die Grenze, die jede gap-Zeile widerspiegelt.
Eine Control-Matrix ist die Brücke zwischen der Checkliste eines Regulierers und Ihrem laufenden Gateway: eine Zeile pro Klausel, verbunden mit der Live-Kontrolle, die sie durchsetzt, ehrlich darüber, was ein Proxy nicht abdecken kann, und identisch mit dem signierten Nachweis, den Sie einem Auditor übergeben.