Zum Hauptinhalt springen
Wenn ein Betroffener sein Recht auf Vergessenwerden geltend macht, brauchen Sie zwei Dinge: eine portable Kopie seiner Daten und eine irreversible Löschung, die tatsächlich jede Surface erreicht, die seine Aktivität berührt hat — nicht nur die Nutzer-Zeile. OrcaRouter macht beides selbstbedienbar. Ein eingeloggtes Konto kann seine eigenen Daten exportieren und seine eigene Löschung planen; die Löschung läuft als 30-Tage-Gnadenfenster, gefolgt von einer PII-Bereinigung, die die an dieses Konto gebundenen Observability-Datensätze im Cascade löscht. Diese Seite behandelt den kundenseitig beobachtbaren Löschungs-Flow. Für den Ort, an dem Nachweis-Artefakte leben, siehe Datenresidenz; für die Dauer, die Request Logs unabhängig von der Löschung persistieren, siehe Aufbewahrung.

​
1. GDPR-Löschung LLM: der selbstbedienbare DSAR-Flow

Drei Konsolen-Aktionen decken eine Data-Subject-Access-Request von Anfang bis Ende ab. Jede ist eine UserAuth-Route unter /api/user/* — von Ihrer Konsolen-Session gesteuert, niemals von einem Relay-(sk-orca-…)-Key:

Export

Laden Sie eine portable JSON-Kopie Ihrer persönlichen Daten herunter, bevor Sie löschen.

Löschen

Sofort soft-löschen; die irreversible Bereinigung für +30 Tage planen.

Abbrechen

Das Konto jederzeit innerhalb des Gnadenfensters wiederherstellen.
Der Export ist Datenportabilität — die Zugriffs-Hälfte einer DSAR. Die Löschung ist die Löschungs-Hälfte. Führen Sie zuerst den Export aus; sobald die Bereinigung feuert, gibt es nichts mehr zu exportieren.

​
2. Ihre Daten exportieren (ein konkreter Ablauf)

Öffnen Sie aus der Konsole Account → Privacy und wählen Sie Export my data. Die Konsole steuert diese Read-Route mit Ihrer Session: 
GET /api/user/self/export
Authorization: Bearer <your console session>
Die Response ist ein herunterladbares JSON-Dokument Ihres Profils und Ihrer nicht-geheimen persönlichen Daten. Der Export ist eine explizite Allow-List — er enthält niemals Ihren Passwort-Hash, Ihr System-Access-Token, OAuth-Secrets, Webhook-/Notification-Credentials oder Request-Log-Payload-Bodies.
Der Export bleibt während des Gnadenfensters verfügbar. Ein zur Löschung geplantes Konto ist soft-gelöscht, kann aber noch Export und Abbruch erreichen — Portabilität ist der ganze Sinn, diese Tür offen zu halten, bis die Bereinigung läuft.

​
3. Die Löschung planen

Account → Privacy → Delete my account soft-löscht das Konto sofort und plant die PII-Bereinigung für jetzt + 30 Tage: 
DELETE /api/user/self
Authorization: Bearer <your console session>
Content-Type: application/json

{ "password": "<current password>" }
Die Response trägt das geplante Bereinigungsdatum. Ein paar Schutzmaßnahmen gelten:
Passwort-Konten müssen ihr aktuelles Passwort beim Lösch-Request angeben — Verteidigung dagegen, dass eine gekaperte Session dauerhaft Daten zerstört. Nur-OAuth-Konten haben kein Passwort; die authentifizierte Session ist der Beweis.
Wenn Sie der einzige Owner eines geteilten Team-Workspaces sind, der noch andere Mitglieder hat, wird die Löschung verweigert — sonst würden Teamkollegen einen ownerlosen Workspace erben. Übertragen Sie zuerst das Ownership oder archivieren Sie den Workspace.
Das Instance-Root-Konto wird verweigert — es selbst zu löschen würde das Deployment ohne Super-Admin zurücklassen. Übergeben Sie zuerst die Root-Rolle.
Die Löschung erneut aufzurufen, während sie bereits pending ist, gibt eine freundliche „already scheduled”-Response zurück statt eines Fehlers.
Einmal geplant, ist Ihre Session für den Rest des Gnadenfensters auf die cancel- und export-Endpunkte beschränkt — ein behaltenes Cookie passiert die Auth auf dem Rest von /api/user/* nicht mehr. Das Abbrechen hebt die Einschränkung auf und stellt den vollen Zugang ohne erneutes Einloggen wieder her.

​
4. Das 30-Tage-Gnadenfenster

Das Gnadenfenster ist ein bewusster Undo-Puffer. Bis es verstreicht, ist das Konto soft-gelöscht, nicht gelöscht, und ein Call stellt es wieder her: 
POST /api/user/self/deletion/cancel
Authorization: Bearer <your console session>
Wenn ein Abbruch im Rennen zwischen dem Sweep, der Ihr Konto auswählt, und der laufenden Bereinigung landet, wird das nun aktive Konto nicht anonymisiert — die Bereinigung schützt auf einen noch-pending-Zustand und überspringt alles, was wiederbelebt wurde.
Behandeln Sie die 30 Tage als Ihren DSAR-Erfüllungs-SLA-Puffer. Ein Subjekt, das es sich anders überlegt, oder ein versehentlich gestellter Request ist vollständig wiederherstellbar, bis das Fenster schließt — danach ist die Bereinigung per Design irreversibel.

​
5. Die PII-Bereinigung und ihr Cascade-Purge

Wenn das Gnadenfenster verstreicht, führt ein Sweep die Bereinigung aus. Sie versteckt nicht nur eine Zeile — sie streift direkte Identifikatoren ab und löscht im Cascade die Datensätze, die Ihre Aktivität über jede Observability-Surface hinterlassen hat:
SurfaceWas die Bereinigung tut
KontoDirekte Identifikatoren anonymisiert; Credentials, Keys, OAuth-Bindings, Passkeys und 2FA hart gelöscht
Request LogsAus dem Request-Log-Store gelöscht
Accounting- / Usage-ZeilenUsername redigiert und IP geleert auf Zeilen, die für die Abrechnung aufbewahrt werden
Guardrail-MatchesGelöscht — einschließlich aller rohen gematchten Teilstrings
Firewall-EventsGelöscht — Tool-Namen, IPs und Request-IDs, die Ihnen zugeordnet sind
Die Konto-Felder werden an Ort und Stelle anonymisiert (Username und E-Mail zu einem deleted-…-Platzhalter umgeschrieben, Status deaktiviert), sodass Accounting- und Audit-Zeilen, die eine rechtliche Grundlage zum Persistieren haben, ihre Form behalten, während sie die eingebetteten persönlichen Daten verlieren. Alles Credential-Tragende wird hart gelöscht — echte Löschung, keine Soft-Löschung, die nur versteckt.
Der Cascade erreicht dieselben drei Surfaces, die Sie anderswo in der Konsole lesen: Guardrail-Matches, Firewall-Events und Request Logs. Nach der Bereinigung lösen sich keine von ihnen mehr zur gelöschten Person auf. Das ist es, was die Löschung über die Content-Schicht, die Aktionsschicht und das Log hinweg symmetrisch macht.
Beachten Sie die Unterscheidung von rohem gematchtem Inhalt. Guardrail-Matches speichern einen gematchten Teilstring nur, wenn der Log raw content-Toggle dieses Guardrails an ist (standardmäßig aus). So oder so löscht die Bereinigung diese Datensätze vollständig — der Toggle ändert also, was je aufgezeichnet wurde, nicht, was eine Löschung überlebt.

​
6. Löschung vs. Aufbewahrung

Löschung und Aufbewahrung sind zwei verschiedene Uhren — verwechseln Sie sie nicht:
  • Aufbewahrung lässt Request Logs auf einem rollierenden Fenster für jeden altern — ein 30-Tage-Default, serverseitig auf ein 180-Tage-Hartmaximum geklemmt. Siehe Aufbewahrung.
  • Löschung ist ein einmaliges, konto-bezogenes Ereignis, ausgelöst durch eine DSAR: das 30-Tage-Gnadenfenster, dann die Bereinigung.
Die Logs eines Subjekts mögen unter der Aufbewahrung bereits gealtert sein, bevor es überhaupt eine DSAR einreicht; die Bereinigung läuft dennoch gegen das, was übrig bleibt, und redigiert die aufbewahrten Accounting-Zeilen.

​
7. Wo dies hineinpasst

Das Recht auf Löschung ist ein Teil Ihrer Betroffenenpflichten. Kombinieren Sie es mit region-gestempeltem Nachweis und der breiteren Compliance-Schleife:

Aufbewahrung

Das rollierende Request-Log-Fenster — 30-Tage-Default, 180-Tage-Klemmung —, das unabhängig von der Löschung läuft.

Datenresidenz

Die Region, unter der Ihre signierten Compliance-Reports gespeichert und ausgeliefert werden.

GDPR-Pack

Installieren Sie die Kontrollen und liefern Sie einem Auditor signierten GDPR-Nachweis aus.

Geteilte Verantwortung

Was das Gateway für Sie löscht und was Ihre Entscheidung bleibt.
Das Gateway gibt Ihnen eine selbstbedienbare DSAR, die jeden Datensatz erreicht, der ihm gehört. Zu entscheiden, wann eine Löschung erforderlich ist, und jede jurisdiktionsspezifische Frist einzuhalten, bleibt Ihre Entscheidung — das 30-Tage-Gnadenfenster ist Ihr Puffer, um sie zu treffen.