Skip to main content

​
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.
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.

​
Lectura de la política resuelta

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.
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.
Los barridos de retención son maquinaria de eliminación, por lo que comparten espacio con dos controles de preservación:
  • Retenciones legales. 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. 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.

​
Relacionados

Ventanas de retención y eliminación

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.

Retenciones legales

Exima una conversación de los barridos de retención para la preservación por litigio.

Exportación de archivo inmutable

Copie registros en un paquete a prueba de manipulación antes de que los barridos los eliminen.

Guía de postura de GDPR

Ensamble la postura completa de GDPR — consentimiento, DSAR, el registro y el dossier.

Data Subject Requests

Acceso y eliminación delimitados a contactos, y cómo reconciliarlos con las retenciones.