> ## 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.
# Política de retención de datos por dominio
> Configure ventanas de redacción del cuerpo de mensajes, eliminación definitiva de conversaciones cerradas y purga de registros de auditoría por dominio — la superficie de limitación de almacenamiento del GDPR Art. 5(1)(e) propiedad del inquilino
# Política de retención de datos por dominio
La política de retención de datos decide cuánto tiempo permanecen intactas
en su espacio de trabajo tres clases de registros antes de que barridos
programados los redacten o los eliminen. Son tres **dominios independientes**
detrás de un par de endpoints — redacción del cuerpo de mensajes,
eliminación definitiva de conversaciones cerradas y purga de registros de
auditoría — cada uno con su propia ventana y sus propios valores mínimo y
máximo permitidos. Los tres dominios están **desactivados por defecto**: un
espacio de trabajo que nunca toca esta superficie no tiene ningún
comportamiento de retención automático.
```
GET /api/v1/compliance/data-retention
PUT /api/v1/compliance/data-retention
```
Esta página describe los controles de plataforma de Orbit. **No es
asesoría legal.** Cuánto tiempo puede o debe conservar mensajes,
conversaciones y evidencia de auditoría depende de sus reguladores, sus
contratos y de la lectura que su asesor legal haga de ellos. Confirme los
detalles con asesoría legal calificada.
***
## Los tres dominios
Cada dominio responde a una pregunta de limitación de almacenamiento, y
usted puede habilitar cualquier combinación de ellos.
### Redacción del cuerpo de mensajes (`messages`)
Tras el número de días que configure, un barrido programado reemplaza el
cuerpo del mensaje y los identificadores de destinatario/remitente con un
marcador redactado. Los metadatos de calidad de facturación — estado,
conteo de segmentos, precio, error del operador — y la traza de recibos de
entrega y de auditoría sobreviven intactos, de modo que la revisión
retrospectiva financiera y de disputas sigue funcionando sobre filas
redactadas. Establezca la ventana en `0` para desactivar el barrido;
cualquier valor habilitado debe situarse dentro de los límites permitidos.
* Ventana permitida: **7 a 3650 días** (o `0` para desactivar).
### Eliminación definitiva de conversaciones cerradas (`conversations`)
Cuando está habilitado, un barrido programado elimina definitivamente una
fila de conversación una vez que ha estado **cerrada** más tiempo que su
ventana. Las filas de mensajes adjuntas a la conversación no se eliminan
con ella, de modo que los metadatos de facturación y de auditoría
sobreviven a la purga. Solo las conversaciones cerradas son elegibles; un
hilo abierto nunca se barre.
* Ventana permitida: **30 a 3650 días**. El piso de 30 días evita una
purga de una conversación que se cerró hace solo horas.
* Si habilita este dominio sin una ventana, se aplica el valor
predeterminado de la plataforma de **180 días**.
### Purga de registros de auditoría (`audit_logs`)
Cuando está habilitado, un barrido programado elimina definitivamente las
entradas del registro de auditoría más antiguas que su ventana. Los
registros de auditoría son la traza de evidencia de cada cambio de
configuración en su espacio de trabajo, por lo que este dominio lleva un
piso regulatorio.
* Ventana permitida: **365 a 3650 días**. El piso de 365 días protege la
ventana de examen de SOC 2 — nunca puede purgar evidencia de auditoría
de menos de un año.
* Si habilita este dominio sin una ventana, se aplica el valor
predeterminado de la plataforma de **2190 días** (seis años), dirigido
a la expectativa de retención de HIPAA.
La eliminación por DSAR es independiente de esta política basada en
antigüedad. Una solicitud del sujeto de datos delimitada a un contacto
ejecuta su propio flujo de trabajo independientemente de estas ventanas
de toda la organización — consulte
[Data Subject Requests](/compliance/dsar).
***
## Lectura de la política resuelta
```bash theme={null}
curl https://api.orbit.devotel.io/api/v1/compliance/data-retention \
-H "X-API-Key: dv_live_sk_..."
```
```json theme={null}
{
"data": {
"messages": { "redact_body_after_days": 90 },
"conversations": { "enabled": true, "delete_closed_after_days": 180 },
"audit_logs": { "enabled": false, "delete_after_days": 2190 },
"bounds": {
"messages": { "redact_body_min_days": 7, "redact_body_max_days": 3650 },
"conversations": { "delete_closed_min_days": 30, "delete_closed_max_days": 3650 },
"audit_logs": { "delete_min_days": 365, "delete_max_days": 3650 }
}
}
}
```
La respuesta siempre devuelve el valor resuelto para cada dominio, además
de un objeto `bounds` que lleva la ventana mínima/máxima permitida para
cada uno — los mismos valores que el panel usa para limitar las entradas.
La lectura la puede hacer cualquier rol autenticado; un espacio de trabajo
nuevo devuelve los valores predeterminados anteriores con los tres dominios
desactivados.
***
## Escritura de la política
Las escrituras requieren una clave de API o un rol de panel de **propietario
o administrador** — la retención es un control regulatorio, así que la
puerta refleja el resto de la superficie de escritura de cumplimiento.
Cualquier otro rol recibe `403`.
La escritura es **merge-on-write**: cada bloque de dominio es opcional, y
un bloque que omita conserva su valor almacenado. Envíe solo los dominios
que pretenda cambiar.
```bash theme={null}
curl -X PUT https://api.orbit.devotel.io/api/v1/compliance/data-retention \
-H "X-API-Key: dv_live_sk_..." \
-H "Content-Type: application/json" \
-d '{
"messages": { "redact_body_after_days": 90 },
"conversations": { "enabled": true, "delete_closed_after_days": 180 }
}'
```
Reglas con las que construir:
* **Proporcione al menos un dominio** — un cuerpo vacío devuelve `422
VALIDATION_ERROR`.
* **Los valores dentro del rango se validan estrictamente.** Un valor
habilitado de `redact_body_after_days` fuera de los límites, o una
ventana fuera de su mínimo/máximo, devuelve `422` con un error por
campo.
* **La resolución es permisiva al habilitar sin ventana.** Para
`conversations` y `audit_logs`, enviar `enabled: true` sin una ventana
se resuelve al valor predeterminado de la plataforma (180 y 2190 días
respectivamente); los valores resueltos son los que usan los barridos, y
la respuesta de una escritura es la misma vista resuelta que la de `GET`.
* **Cada cambio se registra.** Cada escritura queda en su registro de
auditoría con los dominios cambiados y el actor, conservando la traza de
gobernanza de la propia política.
***
## Modelo de ejecución: barridos, no eliminación inmediata
El endpoint solo registra la política. Escribir una ventana de 90 días
**no** redacta nada en el momento en que la guarda — la ejecución corre en
barridos programados en segundo plano que aplican su política resuelta en
su propia cadencia. Planifique su runbook en consecuencia:
* Un registro más antiguo que su ventana se vuelve elegible para el
barrido, y se redacta o se elimina en la siguiente ejecución del barrido
— no en el instante en que cruza la ventana.
* Endurecer una ventana (por ejemplo, de 365 días a 90 días) pone en cola
los registros recién por encima de la ventana para el siguiente barrido.
No es una purga síncrona.
* Aflojar o desactivar una ventana detiene los barridos futuros de redactar
o eliminar más allá de lo que la nueva política permite; los registros
ya redactados o eliminados no se restauran.
Lea la política de vuelta con `GET` para confirmar los valores resueltos
antes de apoyarse en ellos en un procedimiento interno.
***
## GDPR Art. 5(1)(e): por qué existe la política
El artículo 5(1)(e) del GDPR enmarca la limitación del almacenamiento: los
datos personales deben conservarse en una forma que permita la
identificación de los sujetos de datos **durante no más tiempo del
necesario** para los fines para los que se recopilaron. Para un operador
CPaaS, los registros que atraen este principio son exactamente los tres
dominios de esta página — los cuerpos de mensajes llevan contenido del
cliente, las conversaciones llevan el historial del hilo y los registros de
auditoría llevan la traza del espacio de trabajo.
La política por dominio existe para que usted pueda expresar una postura de
limitación de almacenamiento como configuración: ventanas cortas donde la
minimización importa (cuerpos de mensajes), ventanas más largas donde un
piso regulatorio argumenta lo contrario (registros de auditoría), y cada
dominio alcanzado de forma independiente porque un TTL global único nunca
se ajusta a los tres. El piso de auditoría de 365 días es un ejemplo de la
plataforma manteniendo un **mínimo regulatorio** por usted — evita que una
ventana mal configurada destruya evidencia de SOC 2, no un límite sobre lo
agresiva que puede ser su postura en otros lugares.
Su asesoría legal decide las ventanas. La plataforma las hace cumplir y
registra cada cambio de la propia política.
***
## Interacción con la retención legal y la exportación de archivo
Los barridos de retención son maquinaria de eliminación, por lo que
comparten espacio con dos controles de preservación:
* **[Retenciones legales](/compliance/legal-hold).** Una retención sobre
una conversación exime a ese hilo de la maquinaria de retención mientras
la retención esté en vigor — el barrido lo omite. Una retención es la
postura de preservación por litigio; la política de retención es la
postura de operación normal, y la retención gana mientras esté en vigor.
Establezca la política como valor predeterminado del espacio de trabajo y
use las retenciones para las excepciones.
* **[Exportación de archivo inmutable](/compliance/archival-export).** El
archivo copia mensajes y grabaciones de llamadas en un paquete a prueba
de manipulación en su propio almacén WORM o S3. Si sus obligaciones
sobreviven a sus ventanas de retención, archive **antes** de que los
barridos empiecen a eliminar — la retención responde "cuánto tiempo
conserva Orbit esto", el archivo responde "cómo conservo mi propia
copia".
* **Solicitudes de eliminación.** La eliminación por DSAR se ejecuta de
forma delimitada a contactos y de manera independiente de esta política
basada en antigüedad; reconcilie las solicitudes de eliminación abiertas
contra las retenciones como parte de su proceso de DSAR en lugar de
esperar que las ventanas de retención las satisfagan.
***
## Su postura de retención sigue siendo suya
La política de retención por dominio es un **control propiedad del
inquilino**: Orbit proporciona las ventanas, los barridos y la traza de
auditoría — cuáles son las ventanas y qué dominios se aplican a su postura
son decisiones suyas. Los tres dominios permanecen desactivados hasta que
usted los habilite, y cada habilitación, cambio y desactivación es una
decisión que sus propietarios y administradores tomaron, registrada en su
registro de auditoría. Para el ensamblaje más amplio — registros de
consentimiento, admisión de DSAR, el registro, el dossier de evidencia —
recorra la [guía de postura de GDPR](/compliance/gdpr-posture-guide).
***
## Relacionados
El mapa de ciclo de vida entre almacenes que esta página de postura asume — la ventana de cada almacén, el comportamiento de expiración y los controles de preservación.
Exima una conversación de los barridos de retención para la preservación por litigio.
Copie registros en un paquete a prueba de manipulación antes de que los barridos los eliminen.
Ensamble la postura completa de GDPR — consentimiento, DSAR, el registro y el dossier.
Acceso y eliminación delimitados a contactos, y cómo reconciliarlos con las retenciones.