Saltar para o conteúdo principal
Quando você liga a captura de log de requisição para diagnóstico, você está armazenando corpos de prompt e resposta — exatamente o dado que uma regulação de privacidade pede que você mantenha por não mais tempo do que precisa. O OrcaRouter te dá um único controle por-workspace para isso: uma janela de retenção com um padrão sensato e um teto rígido que o servidor aplica, de modo que uma captura que você esquece expira em vez de acumular para sempre. Esta página cobre como esse controle funciona e como ele se liga ao apagamento. Para a história de evidência mais ampla, comece pela Visão geral de compliance.

​
1. Por que a retenção de log de llm importa em um gateway

A captura de log de requisição é opt-in, desligada até você habilitá-la explicitamente, e gated atrás de um reconhecimento de consentimento registrado — porque ligá-la persiste o texto completo de prompt e resposta. Uma vez ligada, a pergunta que os auditores fazem não é se você registra, mas por quanto tempo você o mantém. Um padrão de 30 dias mantém uma trilha de diagnóstico útil; um teto de 180 dias aplicado pelo servidor significa que nenhuma requisição de cliente, por mais adulterada que seja, pode manter corpos além do seu limite de compliance.
A retenção se aplica aos logs de requisição capturados (os corpos opt-in de prompt/resposta). Os registros de medição e billing, e os relatórios de compliance assinados descritos em Relatório assinado, seguem seus próprios ciclos de vida — esta página é sobre o relógio do log capturado.

​
2. Os dois números

Padrão: 30 dias

Uma captura recém-habilitada retém os corpos por 30 dias. Deixe o campo de retenção não definido e todo workspace herda isso.

Máx rígido: 180 dias

O servidor limita qualquer retenção solicitada a 180 dias. Peça mais e o valor é silenciosamente reduzido ao limite — não é um erro, é um teto.
O teto rígido é 180 dias: um valor acima de 180 limita em 180, e um valor de 0 (ou não definido) significa herdar o padrão — que resolve para 30 dias. Os padrões e o teto ao vivo são legíveis a partir do payload de status público para que um painel de configurações possa renderizar os limites certos: 
GET /api/status
A resposta carrega request_log_default_retention_days, request_log_max_retention_days e request_log_default_enabled — os limites efetivos que seu console lê antes de mostrar o input.

​
3. Definindo a retenção (um fluxo concreto)

A retenção é uma configuração de workspace, configurada a partir do console em Settings → Privacy. Qualquer membro pode lê-la; alterá-la exige o papel de Admin do workspace. O console conduz essa rota de gerenciamento com a sua sessão (uma rota UserAuth — não uma chave de relay), então você nunca coloca uma chave sk-orca-... em uma chamada de configurações: 
PUT /api/workspaces/:id/request-log-settings
Authorization: Bearer <your console session>

{
  "request_log_enabled": true,
  "request_log_retention_days": 60
}
Algumas regras que o servidor aplica nessa chamada:
request_log_enabled é um toggle de ponteiro. Omita-o e o valor armazenado fica intocado; envie true/false para transicioná-lo. Ligar a captura exige um reconhecimento de consentimento atual e não-revogado — o registro de consentimento é autoritativo no servidor e nunca é lido do JSON do cliente. Veja Consentimento.
request_log_retention_days é um inteiro de dias inteiros, limitado a [1, 180]. Um 0 significa “deixe o valor existente” (ou herde o padrão do sistema downstream); 200 vira 180.
Não há nada para rodar em uma agenda. Os corpos capturados além da janela de retenção são removidos pelo gateway; você configura a janela, o gateway a aplica.
A postura de menor risco é a óbvia: deixe a captura desligada a menos que você esteja diagnosticando ativamente, e quando você de fato habilitá-la, defina a retenção mais curta que ainda cubra seu loop de debug. O padrão de 30 dias já é conservador.

​
4. Retenção vs. apagamento

A retenção expira os logs capturados no curso ordinário. O apagamento é o caminho on-demand para uma requisição de titular de dados (DSAR) ou um fechamento de conta — e ele alcança mais longe do que o relógio do log:
GatilhoJanelaEntão
Log capturado além da retençãoaté 180 diaslog removido
Autoexclusão de contacarência de 30 diasscrub de PII + purga em cascade
Uma autoexclusão faz soft-delete da conta imediatamente e agenda um scrub de PII irreversível para 30 dias depois. Durante essa janela de carência a conta ainda pode ser restaurada e seus dados exportados; uma vez que a janela fecha, o scrub roda e o cascade purga os logs de requisição, as correspondências de guardrail, os eventos de firewall e os nós de trace de agente ligados ao titular. O direito ao apagamento não é, portanto, uma configuração de retenção separada — é uma purga mais forte, iniciada pelo titular, que se sobrepõe à janela baseada em tempo.
A carência de exclusão de 30 dias é uma janela de recuperação, não retenção de log extra. Os dados dentro dela têm soft-delete e são exportáveis, mas estão em um caminho de mão única para o scrub. Planeje os exports antes que a janela feche.
Veja Direito ao apagamento para a mecânica completa de DSAR — carência, scrub e o que o cascade toca.

​
5. Como isto satisfaz um framework

A maioria dos regimes de privacidade pede duas coisas demonstráveis: um período de retenção definido e um caminho de apagamento funcional. O controle de retenção e o cascade de exclusão são exatamente esses dois controles, e um pack de compliance os mapeia na evidência do framework para que um relatório possa ler seu estado. Instale um pack e o mesmo comportamento de retenção e apagamento é referenciado na sua visão de prontidão — sem configuração separada.

Instale um pack

Materialize os controles de um framework; retenção e apagamento fazem parte da história de privacidade que ele espera.

Frameworks

O catálogo ao vivo — GDPR, CCPA, HIPAA e os regimes regionais de privacidade que fixam a retenção.

​
6. Onde isto se encaixa

Direito ao apagamento

Autoexclusão, a carência de 30 dias, o scrub de PII e o cascade de purga.

Consentimento

O reconhecimento registrado exigido antes de a captura de log de requisição ligar.

Residência de dados

Onde a evidência de compliance assinada é armazenada e servida — um controle de região separado da retenção.

Responsabilidade compartilhada

O gateway aplica a retenção que você define; escolher a janela e a cadência de apagamento continua sendo seu.
A retenção no OrcaRouter é um controle honesto com um padrão e um teto rígido: habilite a captura só quando você precisa, mantenha a janela curta e deixe o gateway expirar os corpos — com o apagamento de prontidão para o momento em que um titular pede que você o esqueça inteiramente.