Vai al contenuto principale
Quando attivi la cattura dei log delle richieste per il troubleshooting, stai archiviando i corpi di prompt e risposta — esattamente i dati che una regolamentazione sulla privacy ti chiede di conservare non più a lungo del necessario. OrcaRouter ti dà una singola manopola per-workspace per questo: una finestra di retention con un default sensato e un tetto massimo che il server applica, così una cattura che dimentichi invecchia ed esce anziché accumularsi per sempre. Questa pagina copre come funziona quella manopola e come si lega alla cancellazione. Per la storia più ampia delle evidenze, parti dalla Panoramica sulla compliance.

​
1. Perché la retention dei log LLM conta su un gateway

La cattura dei log delle richieste è opt-in, disattivata finché non la abiliti esplicitamente, e gestita dietro un acknowledgment di consenso registrato — perché attivarla persiste il testo completo di prompt e risposta. Una volta attiva, la domanda che gli auditor pongono non è se logghi, ma per quanto tempo lo conservi. Un default di 30 giorni mantiene una traccia di troubleshooting utile; un tetto di 180 giorni applicato dal server significa che nessuna richiesta del client, per quanto manomessa, può tenere i corpi oltre il tuo cap di compliance.
La retention si applica ai log delle richieste catturati (i corpi prompt/risposta opt-in). I record di metering e billing, e i report di compliance firmati descritti in Report firmato, seguono i propri cicli di vita — questa pagina riguarda l’orologio dei log catturati.

​
2. I due numeri

Default: 30 giorni

Una cattura appena abilitata conserva i corpi per 30 giorni. Lascia il campo di retention non impostato e ogni workspace eredita questo.

Massimo massimo: 180 giorni

Il server clampa qualsiasi retention richiesta a 180 giorni. Chiedi di più e il valore viene silenziosamente ridotto al cap — non è un errore, è un tetto.
Il tetto massimo è 180 giorni: un valore sopra 180 si limita a 180, e un valore di 0 (o non impostato) significa eredita il default — che si risolve in 30 giorni. I default e il tetto live sono leggibili dal payload pubblico di status così un pannello di impostazioni può rendere i limiti giusti: 
GET /api/status
La risposta porta request_log_default_retention_days, request_log_max_retention_days e request_log_default_enabled — i limiti effettivi che la tua console legge prima di mostrare l’input.

​
3. Impostare la retention (un flusso concreto)

La retention è un’impostazione di workspace, configurata dalla console sotto Settings → Privacy. Qualsiasi membro può leggerla; cambiarla richiede il ruolo Admin del workspace. La console guida questa rotta di management con la tua sessione (una rotta UserAuth — non una chiave di relay), così non metti mai una chiave sk-orca-... in una chiamata di impostazioni: 
PUT /api/workspaces/:id/request-log-settings
Authorization: Bearer <your console session>

{
  "request_log_enabled": true,
  "request_log_retention_days": 60
}
Alcune regole che il server applica su questa chiamata:
request_log_enabled è un toggle a puntatore. Omettilo e il valore archiviato è lasciato intatto; invia true/false per transizionarlo. Attivare la cattura on richiede un acknowledgment di consenso corrente e non revocato — il record di consenso è server-authoritative e non viene mai letto dal JSON del client. Vedi Consenso.
request_log_retention_days è un intero di giorni interi, clampato a [1, 180]. Uno 0 significa “lascia il valore esistente” (o eredita il default di sistema a valle); 200 diventa 180.
Non c’è nulla da eseguire su uno schedule. I corpi catturati oltre la finestra di retention sono rimossi dal gateway; tu configuri la finestra, il gateway la applica.
La postura a rischio più basso è quella ovvia: lascia la cattura off a meno che tu non stia attivamente facendo troubleshooting, e quando la abiliti, imposta la retention più breve che copre comunque il tuo loop di debugging. Il default di 30 giorni è già conservativo.

​
4. Retention vs. cancellazione

La retention fa invecchiare i log catturati nel corso ordinario. La cancellazione è il percorso on-demand per una richiesta del soggetto dei dati (DSAR) o una chiusura di account — e si spinge oltre l’orologio dei log:
TriggerFinestraPoi
Log catturato oltre la retentionfino a 180 giornilog rimosso
Self-delete dell’accountgrazia di 30 giorniscrub PII + purge a cascata
Un self-delete soft-elimina l’account immediatamente e schedula uno scrub PII irreversibile per 30 giorni dopo. Durante quella finestra di grazia l’account può ancora essere ripristinato e i suoi dati esportati; una volta chiusa la finestra, lo scrub gira e il cascade purga log delle richieste, match dei guardrail, eventi del firewall e nodi di trace dell’agent legati al soggetto. Il diritto alla cancellazione non è quindi un’impostazione di retention separata — è un purge più forte, iniziato dal soggetto, che supera la finestra basata sul tempo.
La grazia di cancellazione di 30 giorni è una finestra di recupero, non retention dei log extra. I dati al suo interno sono soft-eliminati ed esportabili, ma sono su un percorso a senso unico verso lo scrub. Pianifica gli export prima che la finestra si chiuda.
Vedi Diritto alla cancellazione per l’intera meccanica DSAR — grazia, scrub, e cosa tocca il cascade.

​
5. Come questo soddisfa un framework

La maggior parte dei regimi di privacy chiede due cose dimostrabili: un periodo di retention definito e un percorso di cancellazione funzionante. La manopola di retention e il cascade di cancellazione sono esattamente quei due controlli, e un pack di compliance li mappa nelle evidenze del framework così un report può leggerne lo stato. Installa un pack e lo stesso comportamento di retention e cancellazione è referenziato nella tua vista di readiness — nessuna configurazione separata.

Installa un pack

Materializza i controlli di un framework; retention e cancellazione fanno parte della storia di privacy che si aspetta.

Framework

Il catalogo live — GDPR, CCPA, HIPAA, e i regimi di privacy regionali che fissano la retention.

​
6. Dove si colloca

Diritto alla cancellazione

Self-delete, la grazia di 30 giorni, lo scrub PII, e il cascade di purge.

Consenso

L’acknowledgment registrato richiesto prima che la cattura dei log delle richieste si attivi.

Data residency

Dove le evidenze di compliance firmate sono archiviate e servite — un controllo di regione separato dalla retention.

Responsabilità condivisa

Il gateway applica la retention che imposti; scegliere la finestra e la cadenza di cancellazione resta tuo.
La retention su OrcaRouter è una manopola onesta con un default e un tetto massimo: abilita la cattura solo quando ti serve, mantieni la finestra breve, e lascia che il gateway faccia invecchiare i corpi — con la cancellazione pronta per il momento in cui un soggetto ti chiede di dimenticarlo del tutto.