Zum Hauptinhalt springen
Wenn ein Auditor fragt „beweisen Sie, dass diese Kontrollen tatsächlich durchgesetzt wurden”, überlebt ein Screenshot Ihrer Konsole keine Prüfung — er ist unsigniert, er gehört Ihnen, und er ist editierbar. OrcaRouter erzeugt einen signierten Compliance-Report: ein in sich geschlossenes Nachweis-Pack, das aus Ihren Live-Gateway-Kontrollen geschnappschusst, mit SHA256 gehasht und mit Ed25519 signiert wird, sodass jeder, der den Report hält, verifizieren kann, dass er von OrcaRouter produziert und seither nicht verändert wurde. Diese Seite durchläuft den Anwendungsfall von Anfang bis Ende — Report erzeugen, übergeben und den Auditor unabhängig verifizieren lassen. Für den Framework-Katalog und worauf jedes Pack abbildet, siehe Frameworks und Pack-Inhalte.

​
1. Was der signierte KI-Compliance-Report enthält

Ein Report wird pro Framework über ein von Ihnen gewähltes Zeitfenster erzeugt und schnappschusst acht Nachweis-Abschnitte zum Erzeugungszeitpunkt, sodass das Artefakt gültig bleibt, selbst nachdem die zugrunde liegenden Logs unter Ihrer Aufbewahrungs-Policy altern.
Jeder Report deckt dieselben geordneten Abschnitte ab, sodass zwei Reports vergleichbar sind:
  • Coverage — auf welche Framework-Kontrollen Ihre installierten Packs abbilden, jede getaggt covered / observe / gap / attested.
  • Enforcement — die Guardrail-Matches und Firewall-Verdikte (allowed / blocked / audited), die tatsächlich im Fenster aufgezeichnet wurden.
  • Consent — aufgezeichneter Einwilligungsstatus für den Zeitraum, klassifiziert valid / stale / revoked / none.
  • Change Log — Guardrail-History und Workspace-Audit-Zeilen über das Fenster.
  • Admin Access — wer Admin hielt und welche privilegierten Aktionen liefen.
  • Gaps — Kontrollen, die nicht abgedeckt sind, einschließlich organisatorischer (Personen/Prozess-)Klauseln, die niemals am Gateway automatisiert werden können. Der Report legt diese als ehrliche Lücken offen, statt 100 % automatisierte Compliance zu implizieren.
  • AI Supply Chain — die Upstream-Anbieter (Subprozessoren) und Modelle, die der Workspace erreichen kann, um gegen Ihre DPAs zu belegen.
  • Access Reviews — die API-Keys des Workspaces und das Roster privilegierter Mitglieder für die Key-Rotations-Hygiene.
Das kanonische Nachweis-JSON wird mit SHA256 gehasht (Kleinbuchstaben-Hex). Dieser Content-Hash wird mit Ed25519 signiert, und die Signatur plus eine kurze Key-ID (z. B. orca-…) sind in das Artefakt eingebettet. Ändern Sie ein Byte des Nachweises, und der Hash stimmt nicht mehr; fälschen Sie den Hash, und die Signatur verifiziert nicht mehr gegen OrcaRouters öffentlichen Schlüssel.
  • PDF — die menschenlesbare Auditor-Übergabe, mit der Signatur und der Key-ID darauf gedruckt.
  • JSON — der maschinenlesbare Nachweis-Export. (Die Signatur wird über eine kanonische Form des Nachweises berechnet, nicht über die rohen Datei-Bytes, also verifizieren Sie sie über den öffentlichen Verify-Endpunkt, statt das Artefakt selbst neu zu hashen — siehe Einen Report verifizieren.)
  • CSV — flacher tabellarischer Export für Tabellenkalkulationen und GRC-Tooling.
Standardmäßig werden Member- und Akteur-E-Mails in jedem Export maskiert. Aktivieren Sie unredigierte PII explizit pro Report, wenn Ihr Auditor sie braucht.
Reports sind region-gestempelt. Jedes Artefakt wird unter der deklarierten Datenresidenz-Region Ihres Workspaces gespeichert und ausgeliefert (us / eu / uk / ap / cn / global); ein für eine Region produzierter Report wird nicht unter einer anderen ausgeliefert. Setzen Sie die Residency, bevor Sie erzeugen, wenn sie für Ihre Verpflichtungen zählt.

​
2. Wer einen erzeugen kann

Das Durchsuchen des Framework-Katalogs, der installierten Packs und der Readiness ist für jedes Workspace-Mitglied offen und kostenlos. Einen Report zu erzeugen erfordert Workspace-Admin, und der Export ist plan-gated:
  • Der kostenlose Plan enthält einen PDF-Report, sodass Sie das Artefakt vorführen können.
  • CSV-/JSON-Export und weitere Reports erfordern einen kostenpflichtigen Plan.
Beide Regeln werden serverseitig durchgesetzt — es gibt keine reine Client-Umgehung.
Erzeugen Sie aus der Konsole: Öffnen Sie Compliance → Reports, wählen Sie Framework und Zeitfenster, wählen Sie ein Format und klicken Sie auf „Generate”. Die Erzeugung ist asynchron — die Report-Zeile erscheint als pending, wandert zu generating und landet bei ready (oder failed, ohne partielles Artefakt). All dies läuft gegen die /api/compliance/*-Routen unter Ihrer Konsolen-Session — kein Relay-(sk-orca-…)-Key ist beteiligt.

​
3. Ein konkreter Durchlauf

Ein SOC-2-Auditor will Enforcement-Nachweise für Q1. Der Workflow:
1

Das Framework installieren (einmalig)

Installieren Sie als Admin auf einem kostenpflichtigen Plan das SOC-2-Pack aus Compliance → Frameworks. Die Installation materialisiert die Guardrails und Firewall-Policies, die auf die Kontrollen des Frameworks abbilden. Siehe Ein Pack installieren.
2

Den Report erzeugen

Wählen Sie in Compliance → Reports soc2, setzen Sie den Zeitraum auf Ihr Q1-Fenster, wählen Sie PDF und erzeugen Sie. Warten Sie, bis die Zeile ready erreicht, dann laden Sie herunter.
3

Dem Auditor übergeben

Senden Sie ihm das PDF (oder prägen Sie einen Read-only-Auditor-Share-Link, sodass er es selbst ziehen kann). Die Signatur und die Key-ID sind auf den Report gedruckt.
4

Er verifiziert ihn unabhängig

Der Auditor muss Ihrer Konsole niemals vertrauen. Er hasht den Nachweis neu, holt OrcaRouters öffentlichen Schlüssel und prüft die Signatur — alles gegen öffentliche, nicht authentifizierte Endpunkte (nächster Abschnitt).

​
4. Wie ein Auditor ihn verifiziert

Die Verifizierung braucht kein Konto und keinen Relay-Key — sie läuft gegen zwei öffentliche Endpunkte auf api.orcarouter.ai. Holen Sie zuerst den aktiven öffentlichen Schlüssel: 
curl https://api.orcarouter.ai/api/public/compliance/pubkey
# => { "algo": "ed25519", "key_id": "orca-…", "public_key": "<base64>" }
Übermitteln Sie dann den Content-Hash, die Signatur und die Key-ID des Reports: 
curl -X POST https://api.orcarouter.ai/api/public/compliance/verify \
  -H "Content-Type: application/json" \
  -d '{
    "content_hash": "<sha256-hex from the report>",
    "signature":    "<base64 Ed25519 signature>",
    "sig_key_id":   "orca-…"
  }'
# => { "valid": true, "key_id": "orca-…" }
Ein valid: true bedeutet, dass der Nachweis-Hash von OrcaRouter signiert wurde und sich seither nicht geändert hat. Ein Auditor, der unseren Endpunkt gar nicht aufrufen möchte, kann den veröffentlichten öffentlichen Ed25519-Schlüssel nehmen und die Signatur über den Hash mit jeder Standard-Crypto-Bibliothek verifizieren — der Report ist offline verifizierbar.
Möchten Sie das PDF lieber nicht als Anhang senden? Prägen Sie stattdessen einen Read-only-Auditor-Share-Link — eine tokenisierte URL, die den Report (und seine Signatur) direkt ausliefert, ohne Login. Siehe Nachweise exportieren.

​
5. Wo dies hineinpasst

Der signierte Report ist das Artefakt am Ende des Compliance-Flows. Die Teile drumherum:

Frameworks

Der vollständige Katalog — SOC 2, HIPAA, GDPR, EU AI Act, ISO 27001/42001, NIST AI RMF, PCI DSS, OWASP LLM Top 10 und der regionale Satz.

Ein Pack installieren

Materialisieren Sie die Guardrails und Firewall-Policies eines Frameworks, bevor Sie darüber berichten.

Datenresidenz

Stempeln und pinnen Sie die Region, unter der Ihr signierter Report gespeichert und ausgeliefert wird.

Einen Report verifizieren

Der Verifizierungs-Flow im Detail — öffentlicher Schlüssel, Hash und Offline-Prüfungen.
Der Nachweis im Report stammt aus den Kontrollen, die Sie konfiguriert haben. Um zu stärken, was berichtet wird, tunen Sie Ihre Guardrails und Ihre Firewall und prüfen Sie die Grenze dessen, was das Gateway attestieren kann und nicht kann, in Geteilte Verantwortung.