Skip to main content

​
Portal autoservicio DSAR de principio a fin

Devotel Orbit acepta solicitudes de interesados por dos vías de entrada: las que sus operadores presentan en nombre del interesado y un portal público que el propio interesado utiliza. Una sola cola alimenta ambas. Esta guía recorre la vía del portal desde la publicación del enlace hasta el cumplimiento, y muestra cómo se combina con la entrada de operadores. La referencia DSAR (EN) documenta la superficie de endpoints y la máquina de estados pública e-mail/teléfono; esta página es el runbook desde el que usted opera.
Cada control aquí es responsabilidad del tenant: usted publica el enlace, usted gestiona la cola, usted decide y cumple. Orbit aloja el portal, prueba la identidad con un OTP de dos factores y sigue los plazos legales — el deber de responder permanece en usted, el responsable del tratamiento. Confirme sus obligaciones con su asesor legal.

​
1. Dos vías de entrada, una cola

Entrada por operador. Su equipo presenta una solicitud con POST /compliance/dsar o el diálogo Create DSAR en Settings → Compliance → DSAR. Una solicitud presentada así empieza como verification_status: pending — ningún worker de exportación o borrado la toca hasta que un operador apruebe o rechace la revisión de identidad. Esta vío encaja actualmente con: sujetos que usted ya conoce (un cliente con sesión, un contacto en su workspace), y los derechos que el formulario público no puede canalizar (correction, limit-sensitive-PI, non-discrimination). Portal público de autoservicio. El interesado presenta su solicitud él mismo a través de la página pública alojada — sin cuenta, sin API key, sin sesión. La página verifica su identidad con un OTP de dos factores e-mail + SMS antes de que nada entre en su cola, de modo que una solicitud de portal llega pre-verificada y el worker de exportación o borrado arranca ya. Opere ambas. El portal lleva el volumen de consumidor hasta cero toques de operación; la entrada por operador cubre los casos límite que el portal no puede. Toda solicitud de cualquier vía aterriza en la misma lista Settings → Compliance → DSAR y la misma respuesta GET /compliance/dsar — una cola, un banner SLA, una cadena de auditoría.

​
2. Recorrido del portal

​
Publicar el enlace

Aloje el portal como el enlace “Presentar una solicitud de privacidad” en su política de privacidad, el pie de página o el centro de privacidad dentro del producto:
<locale> es el mismo prefijo de locale que lleva cada página web de Orbit (en, fr, de, …). La página renderiza un formulario de identificadores en dos pasos tras una comprobación anti-bot de Cloudflare Turnstile: el interesado introduce su e-mail y teléfono (E.164), elige un tipo de solicitud, y la prueba de identidad comienza.

​
El requisito previo del remitente de e-mail

Decida de qué dirección salen los códigos de verificación del portal antes de que el enlace esté en vivo — un remitente no configurado deja al portal fallando en cerrado en público. Dos remitentes a nivel de plataforma se configuran una vez en su entorno de API: Sin remitente SMS y sin fallback de plataforma, el paso de teléfono devuelve 503 y el portal muestra un mensaje “temporalmente no disponible”; sin clave de entrega de e-mail, el paso de e-mail falla igual. En producción el primer paso además necesita un token Turnstile — configure DEVOTEL_TURNSTILE_SECRET_KEY en la API y NEXT_PUBLIC_DEVOTEL_TURNSTILE_SITE_KEY en el despliegue web, desde el panel de Cloudflare (Turnstile → Add site). Los códigos de verificación por SMS viajan por el softswitch de Devotel como OTPs de plataforma — no son tráfico facturable al tenant.

​
Qué ve el interesado

El interesado completa una reclamación de cinco pasos; nada se encola hasta que ambas pruebas están archivadas:
  1. Begin — e-mail, teléfono (E.164), tipo de solicitud. Un OTP de e-mail se envía inmediatamente.
  2. Verify email — un código de e-mail de 6 dígitos (TTL de 10 minutos, 3 intentos, enfriamiento de reenvío de 60 segundos).
  3. Send phone code — un OTP de SMS al mismo teléfono (enfriamiento de 60 segundos entre envíos).
  4. Verify phone — un código SMS de 6 dígitos.
  5. Submit — la solicitud entra en su cola solo cuando ambas pruebas existen. La reclamación completa tiene un TTL total de 30 minutos.
Los tipos amigables que el interesado elige se mapean sobre el enum de operador: Si los identificadores no coinciden con ningún contacto de su workspace, el paso de submit sigue respondiendo igual — el portal nunca revela si existe un contacto — y la fila de auditoría se escribe a nivel de plataforma para que la pista forense sobreviva al caso sin coincidencia.

​
La jurisdicción se mapea sobre la cuenta SLA

El interesado elige la jurisdicción bajo la que cae su solicitud, y esa elección decide tanto la cuenta legal que la fila lleva como qué valores de request_type puede contener la cola: Acertar la combinación importa: opt_out_sale y limit_sensitive_pi no tienen equivalente GDPR, y la jurisdicción por defecto del operador es gdpr — configúrela expresamente en consumidores de California. Una solicitud de portal de opt_out pone la jurisdicción por defecto en CCPA/CPRA precisamente porque el valor por defecto GDPR sería inválido. Una mala elección del interesado es corregible: reclasifique la jurisdicción desde la cola y el badge SLA se re-ancla.

​
3. Qué ven los operadores tras una solicitud

Una solicitud de portal que coincide con un contacto aterriza en Settings → Compliance → DSAR junto a las solicitudes de operadores. Porque el OTP ya probó identidad, llega como verification_status: verified — ninguna puerta de aprobar/rechazar la bloquea.
  • Estado y deadline. La fila lleva el estado de ciclo normal y un badge SLA Day X of N anclado a la ventana de la jurisdicción; cualquier brebre dispara el banner SLA a nivel workspace. GET /compliance/dsar/sla ofrece la misma imagen por API.
  • Solicitudes de borrado. Un interesado que eligió “delete” aparece en la sección de portal del tab Erasure requests (Art. 17), con su badge SLA al lado, antes de la ventana de enfriamiento de 7 días por defecto.
  • Cumplimiento. Una solicitud de acceso o portabilidad llega a Completed con una export_url firmada; la acción Download decrypted construye la exportación en claro para un operador. Un borrado ejecutado ofrece el certificado Proof of deletion y Propagate hacia sus destinos conectados.
  • Cadena de auditoría. Begin, ambas verificaciones y submit escriben filas con identificadores hasheados (nunca en claro), IP de origen y user agent — el registro del que su folder de evidencias (EN) tira cuando un regulador pregunta cómo se estableció la identidad.

​
4. Qué no hace Orbit

El portal es maquinaria de entrada y prueba de identidad; las decisiones legales siguen siendo suyas:
  • Orbit nunca decide la validez. Nunca acepta o rechaza una solicitud en base legal. Las filas en verification pending esperan a su decisión de aprobar/rechazar; las filas verificadas se cumplen porque usted lo permite, no porque la plataforma juzgó la reclamación.
  • Orbit nunca auto-cumple un veredicto del operador. En una solicitud de operador no se produce exportación ni se borra nada mientras verification_status: pending siga. Una solicitud del portal se salta la puerta solo porque su OTP ya probó identidad.
  • El borrado respeta su ventana de enfriamiento. El default de 7 días (sobrescrito por tenant) le da la ventana para rechazar, retener o exonerar antes de la destrucción.
  • Decirle qué ley se aplica sigue siendo tarea de su asesor legal. Orbit ancla la cuenta SLA a la jurisdicción que el interesado eligió y usted confirmó.
  • El portal expone el subconjunto amigable de derechos — un interesado que necesita un derecho solo de operador (correction, limit-sensitive-PI, non-discrimination) se presenta a través de su equipo.

​
5. Ejemplo trabajado — una solicitud GDPR de acceso de extremo a extremo

Una clienta en Berlín abre su política de privacidad, toca el enlace del portal y pide todo lo que usted guarda. La secuencia:
  1. Begin. Introduce su e-mail, su teléfono en E.164 (+4915…), elige access y supera la comprobación Turnstile. El portal devuelve una id de reclamación; el OTP de e-mail ya está en camino.
  2. Verify email. Lee el código de 6 dígitos (TTL de 10 minutos, hasta 3 intentos) y supera el primer factor.
  3. Send phone code, Verify phone. El segundo factor se repite por SMS — con 60 segundos de enfriamiento entre envíos — y ambas pruebas quedan archivadas.
  4. Submit. El portal presenta la solicitud. Como su e-mail y teléfono coinciden con un contacto en su workspace, la fila se encola como know bajo gdpr y devuelve una referencia dsar_pub_….
  5. En su cola. La fila muestra Day 1 of 30 — verification_status: verified — y el worker de exportación ya la tiene. Nadie de su equipo toca la triaje.
  6. Cumplir. El worker compila la exportación y marca la fila como Completed con export_url y tables_exported. Un operador entrega el enlace de descarga (una copia en claro solo para operadores está a un clic de Download decrypted).
  7. Sobre la línea SLA. Si la fila sigue abierta cuando expira la ventana GDPR de 30 días, el banner SLA del workspace la señala — y si en la entrada eligió mal la jurisdicción, la reclasificación desde la cola corrige la cuenta reactivamente.
Tiempo desde la primera presentación del formulario del interesado hasta la solicitud encolada: los dos recorridos OTP. Toques de operador: cero.

​
Referencias relacionadas