Vai al contenuto principale
Quando un soggetto dei dati invoca il proprio diritto all’oblio, ti servono due cose: una copia portabile dei suoi dati, e una cancellazione irreversibile che raggiunga davvero ogni superficie toccata dalla sua attività — non solo la riga utente. OrcaRouter rende entrambe in self-service. Un account loggato può esportare i propri dati e schedulare la propria cancellazione; la cancellazione gira come una finestra di grazia di 30 giorni seguita da uno scrub PII che purga a cascata i record di observability legati a quell’account. Questa pagina copre il flusso di cancellazione osservabile dal cliente. Per dove vivono gli artefatti di evidenze, vedi Data residency; per quanto a lungo i log delle richieste persistono indipendentemente dalla cancellazione, vedi Retention.

​
1. cancellazione gdpr llm: il flusso DSAR self-service

Tre azioni di console coprono una richiesta di accesso del soggetto dei dati end to end. Ciascuna è una rotta UserAuth sotto /api/user/* — guidata dalla tua sessione di console, mai una chiave di relay (sk-orca-…):

Export

Scarica una copia JSON portabile dei tuoi dati personali prima di eliminare.

Delete

Soft-delete immediato; schedula lo scrub irreversibile a +30 giorni.

Cancel

Ripristina l’account in qualsiasi momento dentro la finestra di grazia.
L’export è portabilità dei dati — la metà di accesso di una DSAR. Il delete è la metà di cancellazione. Esegui prima l’export; una volta che lo scrub si attiva, non resta nulla da esportare.

​
2. Esporta i tuoi dati (un flusso concreto)

Dalla console, apri Account → Privacy e scegli Export my data. La console guida questa rotta di lettura con la tua sessione: 
GET /api/user/self/export
Authorization: Bearer <your console session>
La risposta è un documento JSON scaricabile del tuo profilo e dei dati personali non segreti. L’export è una allow-list esplicita — non include mai il tuo hash di password, il tuo system access token, i segreti OAuth, le credenziali webhook/notifica, o i corpi del payload dei log delle richieste.
L’export resta disponibile durante la finestra di grazia. Un account schedulato per la cancellazione è soft-eliminato ma può ancora raggiungere export e cancel — la portabilità è l’intero punto di tenere quella porta aperta finché lo scrub non gira.

​
3. Schedula la cancellazione

Account → Privacy → Delete my account soft-elimina l’account immediatamente e schedula lo scrub PII per now + 30 days: 
DELETE /api/user/self
Authorization: Bearer <your console session>
Content-Type: application/json

{ "password": "<current password>" }
La risposta porta la data dello scrub schedulato. Si applicano alcuni guard:
Gli account con password devono fornire la loro password corrente sulla richiesta di delete — difesa contro una sessione dirottata che distrugge permanentemente i dati. Gli account solo-OAuth non hanno password; la sessione autenticata è la prova.
Se sei l’unico owner di un workspace di team condiviso che ha ancora altri membri, il delete è rifiutato — altrimenti i compagni di team erediterebbero un workspace senza owner. Trasferisci prima l’ownership o archivia il workspace.
L’account root dell’istanza è rifiutato — auto-cancellarlo lascerebbe il deployment senza super-admin. Cedi prima il ruolo root.
Chiamare di nuovo delete mentre è già pending restituisce una risposta amichevole “già schedulato” anziché un errore.
Una volta schedulata, la tua sessione è ristretta agli endpoint cancel ed export per il resto della finestra di grazia — un cookie tenuto non passa più l’auth sul resto di /api/user/*. Cancellare rimuove la restrizione e ripristina l’accesso completo senza un re-login.

​
4. La finestra di grazia di 30 giorni

La finestra di grazia è un buffer di undo deliberato. Finché non trascorre l’account è soft-eliminato, non cancellato, e una sola chiamata lo ripristina: 
POST /api/user/self/deletion/cancel
Authorization: Bearer <your console session>
Se un cancel atterra nella corsa tra lo sweep che seleziona il tuo account e lo scrub che gira, l’account ora attivo non viene anonimizzato — lo scrub guarda uno stato ancora-pending e salta qualsiasi cosa sia stata rianimata.
Tratta i 30 giorni come il tuo buffer di SLA di adempimento DSAR. Un soggetto che cambia idea, o una richiesta sollevata per errore, è del tutto recuperabile finché la finestra non si chiude — dopodiché lo scrub è irreversibile by design.

​
5. Lo scrub PII e il suo purge a cascata

Quando la finestra di grazia trascorre, uno sweep esegue lo scrub. Non si limita a nascondere una riga — rimuove gli identificatori diretti e purga a cascata i record che la tua attività ha lasciato su ogni superficie di observability:
SuperficieCosa fa lo scrub
AccountIdentificatori diretti anonimizzati; credenziali, chiavi, binding OAuth, passkey e 2FA hard-deleted
Log delle richiestePurgati dallo store dei log delle richieste
Righe di accounting / usageUsername redatto e IP cancellato sulle righe conservate per il billing
Match dei guardrailPurgati — incluse eventuali sottostringhe grezze intercettate
Eventi del firewallPurgati — nomi di tool, IP, e request ID attribuiti a te
I campi dell’account sono anonimizzati in place (username ed email riscritti a un placeholder deleted-…, status disabilitato), così le righe di accounting e audit che hanno una base legale per persistere mantengono la loro forma pur perdendo i dati personali incorporati. Tutto ciò che porta credenziali è hard-deleted — vera cancellazione, non un soft-delete che si limita a nascondere.
Il cascade raggiunge le stesse tre superfici che leggi altrove nella console: match dei Guardrail, eventi del Firewall, e log delle richieste. Dopo lo scrub, nessuno di essi risolve di nuovo alla persona eliminata. È questo che rende la cancellazione simmetrica attraverso il content layer, l’action layer e il log.
Nota la distinzione dal contenuto grezzo intercettato. I match dei guardrail archiviano una sottostringa intercettata solo quando il toggle Log raw content di quel guardrail è attivo (disattivato di default). In ogni caso, lo scrub purga interamente quei record — quindi il toggle cambia cosa è stato mai registrato, non cosa sopravvive a una cancellazione.

​
6. Cancellazione vs retention

Cancellazione e retention sono due orologi diversi — non confonderli:
  • La retention fa invecchiare i log delle richieste su una finestra mobile per tutti — un default di 30 giorni, server-clamped a un massimo massimo di 180 giorni. Vedi Retention.
  • La cancellazione è un evento una tantum, con scope sull’account, attivato da una DSAR: la finestra di grazia di 30 giorni, poi lo scrub.
I log di un soggetto possono essere già invecchiati ed usciti sotto la retention prima ancora che presenti una DSAR; lo scrub gira comunque contro qualsiasi cosa rimanga e redige le righe di accounting conservate.

​
7. Dove si colloca

Il diritto alla cancellazione è un pezzo dei tuoi obblighi verso il soggetto dei dati. Abbinalo a evidenze region-stamped e al loop di compliance più ampio:

Retention

La finestra mobile dei log delle richieste — default di 30 giorni, clamp a 180 giorni — che gira indipendentemente dalla cancellazione.

Data residency

La regione sotto cui i tuoi report di compliance firmati sono archiviati e serviti.

Pack GDPR

Installa i controlli e spedisci evidenze GDPR firmate a un auditor.

Responsabilità condivisa

Cosa cancella il gateway per te e cosa resta una tua decisione.
Il gateway ti dà una DSAR self-service che raggiunge ogni record che possiede. Decidere quando una cancellazione è richiesta, e rispettare qualsiasi scadenza specifica della giurisdizione, resta una tua scelta — la finestra di grazia di 30 giorni è il tuo buffer per farlo.