Zum Hauptinhalt springen
Wenn Ihre LLM-App EU-Personendaten verarbeitet, landen drei GDPR-Pflichten auf dem Request-Pfad selbst: personenbezogene Daten auf das Minimum beschränken, das das Modell braucht (Art. 5), belegen, wohin der Tool-Egress sie sendet (Art. 44), und das Recht eines Betroffenen auf Löschung wahren (Art. 17). Das GDPR-Pack verwandelt diese in durchgesetzte Kontrollen, die Sie in einem Call installieren — kein Policy-Verfassen von Grund auf. Diese Seite ist die GDPR-LLM-Landung: was die Installation des Packs tatsächlich materialisiert, ein konkreter Install-Flow und wie die Löschung von Anfang bis Ende funktioniert. Für die vollständige Content- und Aktionsschicht-Referenz folgen Sie den Links, statt sie hier erneut zu lesen.

​
1. Was das GDPR-Pack installiert

Das Durchsuchen des Katalogs ist für jedes Workspace-Mitglied kostenlos; das Installieren ist eine Aktion auf kostenpflichtigem Plan und Workspace-Admin (dasselbe Gate wie das Live-Gehen — siehe Plan-Gating). Eine Installation materialisiert echte, editierbare Guardrail- und Firewall-Zeilen, gemappt auf GDPR-Artikel:
Ein PII-Guardrail, das den Request blockiert, wenn EU-Identifikatoren (IBAN, UK-NHS-Nummer, deutsche Steuer-ID, französische NIR) erkannt werden, sodass regulierte Daten niemals den Upstream-Anbieter erreichen. Es läuft auf dem input-Stage. Siehe Guardrails für die Entitätsliste und Pro-Entity-Aktions-Overrides — Sie können eine abgedeckte Entität nach der Installation von block auf mask umschalten.
Ein breiteres PII-Guardrail, das Requests hart ablehnt, die E-Mails, Telefonnummern, SSNs, Kreditkartennummern oder IPs enthalten, sodass Sonderkategorie- und gewöhnliche personenbezogene Daten zusammen abgefangen werden.
Ein Logging-Guardrail, das jede Guardrail-Entscheidung als Verarbeitungs-Nachweis aufzeichnet — speist den signierten Report, den Ihr Auditor liest.
Eine Firewall-Egress-Regel, die die ausgehenden Ziele auditiert, die Ihre Tools dem Gateway melden, sodass eine Übermittlungsbewertung einen echten Trail hat, wohin Daten gingen. Siehe Firewall für das Egress-Matching.
Das Pack ist ein Ausgangspunkt, der Ihnen gehört, keine Blackbox. Jede Regel, die es schreibt, ist eine gewöhnliche Guardrail- oder Firewall-Zeile, die Sie anschließend in der Konsole bearbeiten, umordnen oder deaktivieren können.

​
2. Das GDPR-Pack installieren (ein konkreter Ablauf)

Installieren Sie aus der Konsole unter Compliance → Packs, eingeloggt als Workspace-Admin auf einem kostenpflichtigen Plan. Die Konsole steuert die Management-Route für Sie mit Ihrer Session — dies ist eine UserAuth-Route, niemals ein Relay-(sk-orca-…)-Key: 
POST /api/compliance/packs/gdpr/install
Authorization: Bearer <your console session>
Bevor Sie sich festlegen, sagt Ihnen der Katalog genau, auf welches Framework Sie mappen — öffnen Sie ihn zuerst als Member: 
GET /api/compliance/catalog
Authorization: Bearer <your console session>

{
  "key": "gdpr",
  "name": "GDPR",
  "framework": "EU General Data Protection Regulation",
  "jurisdiction": "EU/EEA"
}
Installieren Sie zuerst in observe. Die materialisierte Firewall-Egress-Regel kann audit-only laufen, sodass Sie echte Übermittlungsziele eine Woche lang beobachten, bevor irgendeines davon abgelehnt wird — siehe Observe vs. Enforce.

​
3. PII-Kontrollen auf dem Request

Die Datenminimierung ist die tragende GDPR-Kontrolle, und auf dem Gateway ist sie ein PII-Guardrail. Standardmäßig blockiert das Pack den Request auf dem input-Stage, wenn EU-Personendaten erkannt werden — der Request wird abgelehnt, bevor das Modell ihn sieht, sodass regulierte Daten niemals den Upstream-Anbieter erreichen. Über die gebündelten EU-Entitäten hinaus können Sie das Guardrail tunen, das das Pack installiert hat: genau wählen, welche Entitäten abzudecken sind, eine abgedeckte Entität von block auf mask umschalten und Ihre eigenen benutzerdefinierten Entitätsmuster hinzufügen. Die vollständige Entitätsliste, die Pro-Entity-Aktions-Overrides und die Custom-Entity-Optionen leben in der Guardrails-Referenz.
Wenn Sie eine Entität auf mask umschalten, ist diese Maskierung live auf dem input-Stage, aber sandbox-ausgewertet auf dem output-Stage — die Live-Maskierung von Modell-Responses ist auf der Roadmap. Ein output-Block wird sowohl auf Streaming- als auch auf Non-Streaming-Responses durchgesetzt. Planen Sie Ihre Minimierung um den input-Stage herum, wo sowohl block als auch mask vollständig live sind.

​
4. Residency für Ihren GDPR-LLM-Nachweis

GDPR-Auditoren fragen, wo der Nachweis lebt. OrcaRouters Datenresidenz-Einstellung stempelt jeden signierten Compliance-Report mit einer Region (us / eu / uk / ap / cn / global) und hält jeden Report zurück, dessen gestempelte Region nicht mehr mit dem Workspace übereinstimmt. Für ein EU-Programm deklarieren Sie eu bevor Sie die Reports erzeugen, auf die sich Ihr Auditor verlassen wird: 
PUT /api/compliance/residency
Authorization: Bearer <your console session>
Content-Type: application/json

{ "region": "eu" }
Die Residency regelt das Report-Artefakt, nicht, wo die Inferenz läuft. Sie ist kein Geo-Pinning von Modell-Traffic. Die dedizierte Seite Datenresidenz behandelt die Unterscheidung und was passiert, wenn Sie die Region ändern, nachdem Reports existieren.

​
5. Recht auf Löschung (Art. 17)

Eine echte GDPR-App braucht einen echten Löschungspfad, kein Versprechen. Auf OrcaRouter läuft die Konto-Selbstlöschung als Gnade-dann-Bereinigung-Flow:
SchrittWas passiert
RequestKonto sofort soft-gelöscht; Login blockiert.
GnadeEin 30-Tage-abbrechbares Fenster vor der irreversiblen Bereinigung.
BereinigungPII bereinigt; Cascade-Löschung von Request Logs, Guardrail-Matches und Firewall-Events.
Das Gnadenfenster ist abbrechbar — und ein Nutzer kann seine Daten während ihm noch exportieren, bevor die Bereinigung feuert (Datenportabilität, Art. 20). Nach dem Fenster ist die Bereinigung irreversibel und kaskadiert über die Datensätze, die direkte Identifikatoren tragen.
Request Logs werden separat von der Löschung geregelt: Die Default-Aufbewahrung ist 30 Tage, serverseitig auf ein 180-Tage-Maximum geklemmt. Sie zu senken verkleinert das Fenster, in dem personenbezogene Daten überhaupt in Logs sitzen — siehe Aufbewahrung.

​
6. Beweisen Sie es mit einem signierten Report

Sobald das Pack live ist, erzeugen Sie einen Compliance-Report: Er ist SHA-256-gehasht und Ed25519-signiert, sodass ein Auditor verifizieren kann, dass er von OrcaRouter produziert und nicht verändert wurde — öffentlich, ohne Login. 
POST /api/compliance/reports
Authorization: Bearer <your console session>
Content-Type: application/json

{ "framework": "gdpr" }
Jeder kann die Signatur gegen den öffentlichen Schlüssel verifizieren, und Sie können einem Auditor einen gescopeten, zeitbegrenzten Share-Link übergeben. Die Mechanik lebt in Signierter Report und Einen Report verifizieren.

​
7. Wo dies hineinpasst

GDPR ist ein Framework in der breiteren Compliance-Schleife — ein Pack installieren, es beobachten, durchsetzen, Residency deklarieren, dann signierten Nachweis ausliefern.

Recht auf Löschung

Der Gnade-dann-Bereinigung-Flow und die Cascade-Löschung in vollem Umfang.

Datenresidenz

Region-gestempelter Nachweis und warum er kein Inferenz-Geo-Pinning ist.

Compliance-Überblick

Die vollständige Schleife — installieren, beobachten, durchsetzen und signierten Nachweis ausliefern.

Guardrails

Die Content-Schicht-Referenz — PII-Entitäten, Maskierung und Overrides.
Für die Grenze zwischen dem, was das Gateway garantiert, und dem, was Ihnen unter GDPR bleibt — Residency deklarieren, Ihre Daten klassifizieren, Löschungen auslösen — stellt die Karte Geteilte Verantwortung das GDPR-Pack in den Kontext.