Saltar para o conteúdo principal
Quando um titular de dados invoca seu direito de ser esquecido, você precisa de duas coisas: uma cópia portável dos dados dele, e uma exclusão irreversível que de fato alcance cada superfície que a atividade dele tocou — não apenas a linha de usuário. O OrcaRouter torna ambos self-serve. Uma conta logada pode exportar seus próprios dados e agendar sua própria exclusão; a exclusão roda como uma janela de carência de 30 dias seguida por um scrub de PII que purga em cascade os registros de observabilidade ligados àquela conta. Esta página cobre o fluxo de apagamento observável pelo cliente. Para onde os artefatos de evidência residem, veja Residência de dados; para por quanto tempo os logs de requisição persistem independentemente do apagamento, veja Retenção.

​
1. gdpr erasure llm: o fluxo de DSAR self-serve

Três ações de console cobrem uma requisição de acesso de titular de dados de ponta a ponta. Cada uma é uma rota UserAuth sob /api/user/* — conduzida pela sua sessão de console, nunca por uma chave de relay (sk-orca-…):

Exportar

Baixe uma cópia JSON portável dos seus dados pessoais antes de excluir.

Excluir

Soft-delete imediato; agende o scrub irreversível para +30 dias.

Cancelar

Restaure a conta a qualquer momento dentro da janela de carência.
O export é portabilidade de dados — a metade de acesso de um DSAR. A exclusão é a metade de apagamento. Rode o export primeiro; uma vez que o scrub dispara, não há mais nada para exportar.

​
2. Exporte seus dados (um fluxo concreto)

A partir do console, abra Account → Privacy e escolha Export my data. O console conduz essa rota de leitura com a sua sessão: 
GET /api/user/self/export
Authorization: Bearer <your console session>
A resposta é um documento JSON baixável do seu perfil e dados pessoais não-secretos. O export é uma allow-list explícita — ele nunca inclui o hash da sua senha, seu token de acesso de sistema, segredos de OAuth, credenciais de webhook/notificação ou corpos de payload de log de requisição.
O export permanece disponível durante a janela de carência. Uma conta agendada-para-exclusão tem soft-delete mas ainda pode alcançar o export e o cancelamento — a portabilidade é o ponto inteiro de manter essa porta aberta até o scrub rodar.

​
3. Agende a exclusão

Account → Privacy → Delete my account faz soft-delete da conta imediatamente e agenda o scrub de PII para agora + 30 dias: 
DELETE /api/user/self
Authorization: Bearer <your console session>
Content-Type: application/json

{ "password": "<current password>" }
A resposta carrega a data agendada do scrub. Algumas proteções se aplicam:
As contas com senha devem fornecer sua senha atual na requisição de exclusão — defesa contra uma sessão sequestrada destruir dados permanentemente. As contas só-OAuth não têm senha; a sessão autenticada é a prova.
Se você é o único owner de um workspace de equipe compartilhado que ainda tem outros membros, a exclusão é recusada — caso contrário, os colegas herdariam um workspace sem owner. Transfira a propriedade ou arquive o workspace primeiro.
A conta root da instância é recusada — autoapagá-la deixaria o deployment sem super-admin. Repasse o papel de root primeiro.
Chamar a exclusão novamente enquanto já está pending retorna uma resposta amigável de “já agendado” em vez de um erro.
Uma vez agendada, sua sessão é restrita aos endpoints de cancel e export pelo resto da janela de carência — um cookie mantido não passa mais na auth do resto de /api/user/*. Cancelar levanta a restrição e restaura o acesso completo sem um re-login.

​
4. A janela de carência de 30 dias

A janela de carência é um buffer deliberado de desfazer. Até que ela decorra, a conta tem soft-delete, não é apagada, e uma chamada a restaura: 
POST /api/user/self/deletion/cancel
Authorization: Bearer <your console session>
Se um cancelamento cai na corrida entre o sweep selecionar sua conta e o scrub rodar, a conta agora ativa não é anonimizada — o scrub protege contra um estado ainda-pending e pula qualquer coisa que tenha sido revivida.
Trate os 30 dias como seu buffer de SLA de cumprimento de DSAR. Um titular que muda de ideia, ou uma requisição levantada por engano, é totalmente recuperável até a janela fechar — após o que o scrub é irreversível por design.

​
5. O scrub de PII e sua purga em cascade

Quando a janela de carência decorre, um sweep roda o scrub. Ele não apenas esconde uma linha — ele remove identificadores diretos e purga em cascade os registros que sua atividade deixou em cada superfície de observabilidade:
SuperfícieO que o scrub faz
ContaIdentificadores diretos anonimizados; credenciais, chaves, vínculos OAuth, passkeys e 2FA hard-deleted
Logs de requisiçãoPurgados do armazenamento de log de requisição
Linhas de accounting / usoUsername redigido e IP limpo nas linhas retidas para billing
Correspondências de guardrailPurgadas — incluindo quaisquer substrings brutas correspondidas
Eventos de firewallPurgados — nomes de ferramenta, IPs e request IDs atribuídos a você
Os campos da conta são anonimizados in place (username e email reescritos para um placeholder deleted-…, status desabilitado), de modo que as linhas de accounting e auditoria que têm uma base legal para persistir mantêm sua forma enquanto perdem o dado pessoal embutido. Tudo que carrega credencial é hard-deleted — apagamento verdadeiro, não um soft-delete que apenas esconde.
O cascade alcança as mesmas três superfícies que você lê em outros lugares no console: correspondências de Guardrail, eventos de Firewall e logs de requisição. Após o scrub, nenhum deles resolve de volta para a pessoa excluída. Isso é o que torna o apagamento simétrico entre a camada de conteúdo, a camada de ação e o log.
Note a distinção em relação ao conteúdo bruto correspondido. As correspondências de guardrail só armazenam uma substring correspondida quando o toggle Log raw content daquele guardrail está ligado (desligado por padrão). De qualquer forma, o scrub purga esses registros inteiramente — então o toggle muda o que foi algum dia registrado, não o que sobrevive a uma exclusão.

​
6. Apagamento vs retenção

Apagamento e retenção são dois relógios diferentes — não os confunda:
  • Retenção expira os logs de requisição em uma janela rotativa para todos — um padrão de 30 dias, server-clamped a um máximo rígido de 180 dias. Veja Retenção.
  • Apagamento é um evento único e com escopo de conta disparado por um DSAR: a janela de carência de 30 dias, depois o scrub.
Os logs de um titular podem já ter expirado sob a retenção antes mesmo de ele abrir um DSAR; o scrub ainda roda contra o que quer que reste e redige as linhas de accounting retidas.

​
7. Onde isto se encaixa

O direito ao apagamento é uma peça das suas obrigações de titular de dados. Combine-o com evidência carimbada por região e o loop de compliance mais amplo:

Retenção

A janela rotativa de log de requisição — padrão de 30 dias, limite de 180 dias — que roda independentemente do apagamento.

Residência de dados

A região sob a qual seus relatórios de compliance assinados são armazenados e servidos.

Pack GDPR

Instale os controles e entregue evidência GDPR assinada a um auditor.

Responsabilidade compartilhada

O que o gateway apaga por você e o que continua sendo sua decisão.
O gateway te dá um DSAR self-serve que alcança cada registro que ele possui. Decidir quando uma exclusão é exigida, e cumprir qualquer prazo específico de jurisdição, continua sendo sua decisão — a janela de carência de 30 dias é o seu buffer para tomá-la.