> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Portal autoservicio DSAR de principio a fin

> Combina las solicitudes de operadores con las del portal público, publica el enlace del portal con los remitentes configurados, recorre la verificación de e-mail + SMS OTP que completa el interesado y atiende la solicitud verificada en su cola de operador con la cuenta atrás legal.

# 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)](/compliance/dsar)
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.

<Note>
  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.
</Note>

***

## 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:

```
https://orbit.devotel.io/<locale>/dsar
```

`<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:

| Variable                        | Se usa para                            | Fallback                                                      |
| ------------------------------- | -------------------------------------- | ------------------------------------------------------------- |
| `DEVOTEL_DSAR_PROOF_FROM_EMAIL` | Dirección remitente del OTP de e-mail. | ninguna — la entrega además necesita `DEVOTEL_RESEND_API_KEY` |
| `DEVOTEL_DSAR_PROOF_SMS_FROM`   | Remitente E.164 del OTP de SMS.        | `DEVOTEL_PLATFORM_DEFAULT_FROM`                               |

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:

| El interesado elige | `request_type` de operador |
| ------------------- | -------------------------- |
| `access`            | `know`                     |
| `delete`            | `delete`                   |
| `portability`       | `portability`              |
| `opt_out`           | `opt_out_sale`             |

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:

| Jurisdicción            | Código   | SLA de respuesta |
| ----------------------- | -------- | ---------------- |
| UE/EEE GDPR             | `gdpr`   | 30 días          |
| California CCPA         | `ccpa`   | 45 días          |
| California CPRA         | `cpra`   | 45 días          |
| Brasil LGPD             | `lgpd`   | 15 días          |
| Singapur/Tailandia PDPA | `pdpa`   | 30 días          |
| Canadá PIPEDA           | `pipeda` | 30 días          |
| India DPDP              | `dpdp`   | 30 días          |

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)](/guides/compliance-evidence-binder) 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

* [Referencia DSAR (EN)](/compliance/dsar) — la superficie completa
  de endpoints de operador y pública, límites contra abuso y niveles
  de severidad SLA.
* [Designación de DPO y representante UE/RU (EN)](/compliance/dpo-representative) —
  las designaciones Art.37/Art.27 que su aviso de privacidad debe
  nombrar.
* [Registro de tratamiento GDPR (ROPA + DPIA) (EN)](/compliance/privacy-register) —
  el inventario Art.30 guardado antes de que llegue cualquier
  solicitud.
* [Folder de evidencias de compliance (EN)](/guides/compliance-evidence-binder) —
  las filas de auditoría que una solicitud de portal deja.
* [Completar una DSAR y operar el registro de incidentes de breach (EN)](/guides/compliance-dsar-breach-register) —
  el recorrido de operador de la cola que su portal alimenta.
* [Montar una postura GDPR de principio a fin (EN)](/compliance/gdpr-posture-guide) —
  dónde se sitúa la entrada del portal en la secuencia completa.