Zum Hauptinhalt springen
Sie setzen einen KI-Agenten vor Kundendaten, und Ihr Auditor will wissen, welche Trust-Services-Klauseln Sie tatsächlich belegen können. Auf einem gehosteten Gateway lautet die ehrliche Antwort: die Klauseln, die auf eine Kontrolle abbilden, die auf dem Request-Pfad läuft — logischer Zugang, Monitoring und Tool-Call-Audit — plus die organisatorischen Klauseln, die ein Proxy niemals durchsetzen kann und als gaps offenlegen muss. Diese Seite ist der SOC-2-KI-Durchlauf: welche TSC-Klauseln das SOC-2-Pack abdeckt, die eine Kontrolle, die es für Vertraulichkeit materialisiert, und wie der resultierende Nachweis signiert wird. Für den Install-Flow und das Report-Format im Detail folgen Sie den Links am Ende — diese Seite ist die SOC-2-spezifische Karte, nicht die vollständige Compliance-Referenz.

​
1. Was das SOC-2-KI-Pack abdeckt

Das SOC-2-Pack mappt die AICPA Trust Services Criteria auf Kontrollen, die auf jedem gateway-überquerenden Request laufen. Drei Klauseln bilden auf Live-Durchsetzung ab; zwei sind organisatorisch und werden als gaps offengelegt, statt behauptet.
TSC-KlauselEbeneKontrolle
CC6.1 Logische Zugangskontrollenguardrailvertrauliche PII in Prompts blockieren
CC7.2 System-Monitoringguardrailjede Guardrail-Entscheidung als Nachweis aufzeichnen
CC7.2 Anomalieerkennungfirewalljeden Tool-Dispatch auditieren
CC8.1 Change Management und CC3.1 Risikobewertung sind Personen-und-Prozess-Klauseln. Ein Proxy kann sie nicht durchsetzen, also führt das Pack sie als offengelegte gaps (oder owner-attestierte Zeilen) sowohl in der Konsole als auch im Report auf — niemals als automatisierte Abdeckung. Ehrliche gaps sind das, was den Rest des Nachweises vertrauenswürdig macht. Siehe die Control-Matrix.
Die zwei Enforcement-Ebenen sind dieselbe Guardrails- und Firewall-Maschinerie, die Sie von Hand konfigurieren. Das Pack ist das verfasste Mapping, das sagt, welche existierende Kontrolle welche Klausel erfüllt — es liefert keine neue Runtime-Engine. Siehe Pack-Inhalte für die vollständige Anatomie.

​
2. Das Pack installieren — ein konkretes Beispiel

Die Installation materialisiert das Mapping in eine Guardrail-Policy und eine Firewall-Policy in Ihrem Workspace, jede getaggt mit der Provenienz des Packs. Sie tun dies aus der Konsole, nicht mit einem Relay-Key: Compliance → Catalog → SOC 2 → Install Das ist eine Workspace-Admin-Aktion auf einem kostenpflichtigen Plan, und der Server setzt beides durch. Unter der Haube ruft Ihre Konsolen-Session auf: 
POST /api/compliance/packs/soc2/install
Übergeben Sie einer Konfigurationsroute niemals einen Relay-sk-orca-…-Key. Die /api/compliance/*-Routen authentifizieren sich mit Ihrer Konsolen-Session, nicht mit dem Relay-Key — nur /v1/*-Modellaufrufe nutzen sk-orca-…. Das Durchsuchen des Katalogs, der installierten Packs und der Readiness ist kostenlos und für jedes Workspace-Mitglied offen; Install, Go-Live, Report und Residency sind die gegateten Admin-Aktionen.
Nach der Installation hört die CC6.1-Zeile auf, Prosa zu sein. Die Vertraulichkeits-Kontrolle wird eine echte pii-Guardrail-Regel — Aktion block, Stage input —, die Sie wie jede andere Regel öffnen, lesen und tunen können. Die CC7.2-Monitoring-Kontrolle zeichnet jede Guardrail-Entscheidung als Nachweis auf, und die Firewall-Kontrolle setzt jeden Tool-Dispatch auf das audit-Verdikt.
Diese Kontrolle handelt auf dem Request: Vertrauliche PII wird auf dem Input-Stage blockiert, bevor das Modell sie sieht. Die Live-Output-/Streaming-PII-Behandlung ist auf der Roadmap, also ist für die Output-Seite der Monitoring-Nachweis das, was ein Auditor für CC7.2 über den Report-Zeitraum liest.

​
3. Erst beobachten, dann live gehen

Eine SOC-2-Installation beginnt am ersten Tag nicht, Traffic zu blockieren. Installationen landen im Observe-Mode: Guardrail-Aktionen werden auf flag gezwungen und die Firewall-Policy läuft im Shadow (log-only). Sie erhalten „would-have-blocked”-Nachweise gegen echten Traffic, bevor irgendetwas durchsetzt. Wenn der Nachweis stimmt, befördert ein Workspace-Admin das Pack zum Go-Live, was die deklarierten Aktionen wiederherstellt — die CC6.1-Kontrolle beginnt zu blockieren, die Firewall-Kontrolle auditiert weiter — und optional die materialisierten Policies zum Workspace-Default befördert. Dies ist dieselbe Disziplin, beschrieben in Observe vs. Enforce.

​
4. Signierter Nachweis, den Ihr Auditor verifizieren kann

Der Sinn des Packs ist der Report. SOC-2-Nachweis wird als Ed25519-signierter Report mit einem SHA256-Content-Hash erzeugt, exportierbar als CSV, JSON oder PDF und öffentlich verifizierbar — Ihr Auditor prüft die Signatur ohne OrcaRouter-Login.
Jede TSC-Zeile trägt ihren Status — covered, observe, gap oder attested — und wie oft die Kontrolle tatsächlich über den Zeitraum gefeuert hat. Eine CC6.1-Kontrolle, die 4.000 Requests blockierte, liest sich für einen Auditor anders als eine mit null Matches, und der Report zeigt beide.
Jede materialisierte Kontrolle zeichnet ihre control_id (z. B. soc2.confidentiality), die wortgetreue Klausel (TSC CC6.1 Logical access controls), die Ebene und die ID des durchsetzenden Live-Policy-Objekts auf — sodass der Auditor Klausel → Kontrolle → durchsetzende Policy → Matches abschreitet, ohne erschlossenen Schritt.
Holen Sie den öffentlichen Signing-Schlüssel unter GET /api/public/compliance/pubkey, übermitteln Sie den Report an POST /api/public/compliance/verify oder öffnen Sie einen gescopeten Auditor-Share-Link unter GET /api/public/compliance/share/:token. Kein Konto erforderlich.
Siehe den signierten Report für das vollständige Cover-bis-Footer-Layout und Einen Report verifizieren für den Verifizierungs-Durchlauf.

​
5. Stempeln Sie Ihren SOC-2-Nachweis mit einer Region

SOC-2-Reports werden unter Ihrer deklarierten Residency-Region gespeichert und ausgeliefert — us / eu / uk / ap / cn / global —, und ein Report wird nur unter einer übereinstimmenden Region ausgeliefert; regionsübergreifende Lesezugriffe werden zurückgehalten. Ein Workspace-Admin setzt sie via PUT /api/compliance/residency.
Die Residency hier ist die Region des Nachweis-Artefakts — wo signierte Reports leben und ausgeliefert werden. Es ist kein Inferenz-Daten-Geo-Pinning. Siehe Datenresidenz und Regionsübergreifend für die Grenze.
Request Logs haben standardmäßig eine 30-Tage-Aufbewahrung (serverseitig auf ein 180-Tage-Hartmaximum geklemmt), und eine Nutzerlöschung läuft als 30-Tage-Gnadenfenster, dann eine PII-Bereinigung — beides relevant, wenn ein Auditor nach Ihrer Aufbewahrungshaltung fragt. Siehe Aufbewahrung und Recht auf Löschung.

​
6. Wohin als Nächstes

Pack-Inhalte

Die vollständige Anatomie eines Packs — beide Ebenen, Status und Provenienz.

Ein Pack installieren

Der End-to-End-Install-Flow, Observe-Mode und Go-Live.

Signierter Report

Was der Ed25519-signierte Nachweis-Report enthält.

Control-Matrix

Jede Klausel, ihre Ebene und ob sie covered, observed oder eine gap ist.

Frameworks

Der vollständige Katalog — HIPAA, GDPR, der EU AI Act, ISO 27001 und mehr.

Guardrails vs. Firewall

Die zwei Ebenen, in die ein SOC-2-Pack schreibt, von einem Resolver betrieben.
SOC 2 auf einem gehosteten Gateway ist die Disziplin, präzise zu sein: Mappen Sie die Klauseln, die ein Proxy durchsetzen kann, auf Live-Kontrollen, legen Sie die offen, die er nicht kann, und signieren Sie den Nachweis, sodass die Linie zwischen beiden einer Prüfung standhält.