Saltar al contenido principal
Cuando un sujeto de datos invoca su derecho al olvido, necesitas dos cosas: una copia portable de sus datos y una eliminación irreversible que realmente alcance cada superficie que su actividad tocó — no solo la fila de usuario. OrcaRouter hace ambas de autoservicio. Una cuenta con sesión iniciada puede exportar sus propios datos y programar su propia eliminación; la eliminación se ejecuta como una ventana de gracia de 30 días seguida de una limpieza de PII que purga en cascada los registros de observabilidad atados a esa cuenta. Esta página cubre el flujo de borrado observable por el cliente. Para dónde viven los artefactos de evidencia, ver Residencia de datos; para cuánto persisten los registros de solicitud independientemente del borrado, ver Retención.

​
1. borrado gdpr llm: el flujo DSAR de autoservicio

Tres acciones de consola cubren una solicitud de acceso de sujeto de datos de principio a fin. Cada una es una ruta UserAuth bajo /api/user/* — conducida por tu sesión de consola, nunca una clave de relay (sk-orca-…):

Exportar

Descarga una copia JSON portable de tus datos personales antes de eliminar.

Eliminar

Elimina suavemente de inmediato; programa la limpieza irreversible para +30 días.

Cancelar

Restaura la cuenta en cualquier momento dentro de la ventana de gracia.
La exportación es portabilidad de datos — la mitad de acceso de un DSAR. La eliminación es la mitad de borrado. Ejecuta la exportación primero; una vez que la limpieza se dispara, no queda nada que exportar.

​
2. Exporta tus datos (un flujo concreto)

Desde la consola, abre Account → Privacy y elige Export my data. La consola conduce esta ruta de lectura con tu sesión: 
GET /api/user/self/export
Authorization: Bearer <your console session>
La respuesta es un documento JSON descargable de tu perfil y datos personales no secretos. La exportación es una lista de permitidos explícita — nunca incluye tu hash de contraseña, tu token de acceso de sistema, secretos de OAuth, credenciales de webhook/notificación ni cuerpos de payload de registros de solicitud.
La exportación sigue disponible durante la ventana de gracia. Una cuenta programada para eliminación está eliminada suavemente pero aún puede alcanzar la exportación y la cancelación — la portabilidad es todo el punto de mantener esa puerta abierta hasta que la limpieza se ejecute.

​
3. Programa la eliminación

Account → Privacy → Delete my account elimina suavemente la cuenta de inmediato y programa la limpieza de PII para ahora + 30 días: 
DELETE /api/user/self
Authorization: Bearer <your console session>
Content-Type: application/json

{ "password": "<current password>" }
La respuesta lleva la fecha programada de limpieza. Aplican algunas protecciones:
Las cuentas con contraseña deben proporcionar su contraseña actual en la solicitud de eliminación — defensa contra una sesión secuestrada que destruya datos permanentemente. Las cuentas solo de OAuth no tienen contraseña; la sesión autenticada es la prueba.
Si eres el único dueño de un espacio de trabajo de equipo compartido que aún tiene otros miembros, la eliminación se rechaza — de lo contrario los compañeros heredarían un espacio de trabajo sin dueño. Transfiere la propiedad o archiva el espacio de trabajo primero.
La cuenta raíz de la instancia se rechaza — autoborrarla dejaría el despliegue sin super-admin. Entrega el rol raíz primero.
Llamar a eliminar de nuevo mientras ya está pendiente devuelve una respuesta amable de “ya programada” en vez de un error.
Una vez programada, tu sesión queda restringida a los endpoints de cancelar y exportar por el resto de la ventana de gracia — una cookie conservada ya no pasa la auth en el resto de /api/user/*. Cancelar levanta la restricción y restaura el acceso completo sin un reinicio de sesión.

​
4. La ventana de gracia de 30 días

La ventana de gracia es un búfer de deshacer deliberado. Hasta que transcurra, la cuenta está eliminada suavemente, no borrada, y una llamada la restaura: 
POST /api/user/self/deletion/cancel
Authorization: Bearer <your console session>
Si una cancelación cae en la carrera entre el barrido seleccionando tu cuenta y la limpieza ejecutándose, la cuenta ahora activa no se anonimiza — la limpieza se protege con un estado aún-pendiente y omite cualquier cosa que haya sido revivida.
Trata los 30 días como tu búfer de SLA de cumplimiento de DSAR. Un sujeto que cambia de opinión, o una solicitud levantada por error, es totalmente recuperable hasta que la ventana se cierra — tras lo cual la limpieza es irreversible por diseño.

​
5. La limpieza de PII y su purga en cascada

Cuando la ventana de gracia transcurre, un barrido ejecuta la limpieza. No solo oculta una fila — quita identificadores directos y purga en cascada los registros que tu actividad dejó en cada superficie de observabilidad:
SuperficieQué hace la limpieza
CuentaIdentificadores directos anonimizados; credenciales, claves, vinculaciones OAuth, passkeys y 2FA eliminados de forma dura
Registros de solicitudPurgados del almacén de registros de solicitud
Filas de contabilidad / usoNombre de usuario redactado e IP borrada en las filas conservadas para facturación
Coincidencias de guardrailPurgadas — incluyendo cualquier subcadena coincidente cruda
Eventos de firewallPurgados — nombres de herramienta, IPs e ids de solicitud atribuidos a ti
Los campos de cuenta se anonimizan en su lugar (nombre de usuario y correo reescritos a un marcador de posición deleted-…, estado deshabilitado), así que las filas de contabilidad y auditoría que tienen una base legal para persistir mantienen su forma mientras pierden los datos personales incrustados. Todo lo que porta credenciales se elimina de forma dura — borrado verdadero, no una eliminación suave que solo oculta.
La cascada alcanza las mismas tres superficies que lees en otras partes de la consola: coincidencias de Guardrail, eventos de Firewall y registros de solicitud. Tras la limpieza, ninguna de ellas se resuelve de vuelta a la persona eliminada. Esto es lo que hace al borrado simétrico a través de la capa de contenido, la capa de acción y el registro.
Nota la distinción del contenido coincidente crudo. Las coincidencias de guardrail solo almacenan una subcadena coincidente cuando el interruptor Log raw content de ese guardrail está encendido (apagado por defecto). En cualquier caso, la limpieza purga esos registros por completo — así que el interruptor cambia lo que alguna vez se registró, no lo que sobrevive a una eliminación.

​
6. Borrado vs retención

El borrado y la retención son dos relojes diferentes — no los confundas:
  • La retención hace caducar los registros de solicitud en una ventana móvil para todos — un valor por defecto de 30 días, recortado en el servidor a un máximo estricto de 180 días. Ver Retención.
  • El borrado es un evento único, acotado a la cuenta, desencadenado por un DSAR: la ventana de gracia de 30 días, luego la limpieza.
Los registros de un sujeto pueden haber caducado ya bajo la retención antes de que siquiera presente un DSAR; la limpieza igual se ejecuta contra lo que quede y redacta las filas de contabilidad conservadas.

​
7. Dónde encaja esto

El derecho al borrado es una pieza de tus obligaciones de sujeto de datos. Combínalo con evidencia estampada por región y el bucle de cumplimiento más amplio:

Retención

La ventana móvil de registros de solicitud — 30 días por defecto, límite de 180 días — que se ejecuta independientemente del borrado.

Residencia de datos

La región bajo la que se almacenan y sirven tus reportes de cumplimiento firmados.

Pack de GDPR

Instala los controles y entrega evidencia GDPR firmada a un auditor.

Responsabilidad compartida

Qué borra el gateway por ti y qué sigue siendo tu decisión.
El gateway te da un DSAR de autoservicio que alcanza cada registro que posee. Decidir cuándo se requiere una eliminación, y cumplir cualquier plazo específico de la jurisdicción, sigue siendo tu decisión — la ventana de gracia de 30 días es tu búfer para tomarla.