## Visión general

El módulo **Gobernanza y LGPD** reúne, dentro de la Configuración de la cuenta, todo lo que la
operación necesita para cumplir LGPD/GDPR en el día a día: el **registro de consentimiento** de los
contactos, las **solicitudes de titulares de datos** (exportar o anonimizar/eliminar los datos de un
contacto), la **retención central** de mensajes, los **datos del DPO** (Encargado de Datos) y el
**registro de auditoría nativo**. También aloja el
[Modo Presentación](/hc/ajuda/articles/administration-modo-apresentacao-es), que difumina datos
sensibles para demos y grabaciones de pantalla.

## Requisitos previos

- Perfil de **Administrador** (o un rol personalizado con los permisos de gobernanza — gestión de
  gobernanza, exportación de datos, eliminación de datos y visualización de auditoría).
- La función **Gobernanza y LGPD** habilitada en la cuenta. La pestaña **Auditoría** requiere
  además la función **Registro de Auditoría (Nativo)**. Si el área no aparece, habla con el
  responsable de la cuenta.

## Paso a paso

1. Abre **Configuración → Gobernanza y LGPD**.
2. En la pestaña **LGPD**, completa el **nombre y correo del DPO** y, si lo deseas, activa
   **solicitar y registrar automáticamente el consentimiento inbound**. Configura el mensaje global,
   las sustituciones por canal, la URL de privacidad y las respuestas afirmativas/negativas aceptadas.
3. Define la **retención de mensajes (días)**: los mensajes de conversaciones **resueltas** más
   antiguos que el límite se redactan automáticamente cada día (0 lo desactiva).
   La **retención de conversaciones (días)** elimina conversaciones resueltas e inactivas en lotes pequeños;
   los contratos vinculados y las retenciones legales activas siempre suspenden la eliminación. El registro
   canónico de auditoría se conserva.
   La **retención de payloads de comercio (días)** elimina datos identificativos del comprador en eventos antiguos
   y conserva los valores agregados de ingresos.
4. Define la **retención del registro de auditoría (días)** — los eventos más antiguos se podan.
5. Para atender a un titular: busca el contacto en la sección **Solicitudes de titulares** y elige
   **Exportar datos** (genera un paquete JSON con el perfil del contacto —incluyendo CPF/CNPJ
   enmascarado, país, dirección y dirección de facturación—, los vínculos y relaciones con empresas,
   el historial de consentimiento, las conversaciones, los mensajes y el manifiesto de adjuntos, y
   envía una notificación por correo; no incluye negocios del CRM, pagos, tareas, contratos ni reservas) o
   **Anonimizar** (elimina los datos de identificación —nombre, correo, teléfono, identificador,
   atributos, documento fiscal, dirección y los vínculos/relaciones con empresas— preservando el
   historial de conversaciones).
6. Sigue el avance en la lista **Historial de solicitudes**, que se actualiza automáticamente mientras existan
   elementos pendientes o en proceso. Si la carga falla, usa **Intentar de nuevo**. Cuando el paquete esté listo,
   usa **Descargar paquete**: la plataforma vuelve a validar tu permiso y genera un enlace temporal.

## Configuración y opciones

- **Consentimiento manual/API**: desde el panel del contacto, consulta el historial y agrega una declaración —
  finalidad (tratamiento de datos, marketing, cookies, personalizado), canal, otorgado o rechazado y una nota. La
  API también admite evidencia estructurada. El historial es inmutable. Una declaración global (`all`) es el valor
  actual predeterminado; solo declaraciones de canal posteriores por hora/id son reemplazos actuales. Las anteriores
  siguen visibles en el historial.
- **Consentimiento inbound automático**: en el primer inbound de un contacto/canal sin declaración aplicable de
  `data_processing`, la plataforma persiste y envía el mensaje mediante el pipeline normal del canal. El prompt se
  procesa en segundo plano, en paralelo a bots, listeners y automatizaciones: el mensaje entrante nunca lo espera.
  Una respuesta afirmativa o
  negativa configurada crea una declaración con canal, mensaje de respuesta, mensaje del prompt y evidencia. La
  evidencia automática guarda IDs técnicos, el token normalizado reconocido y un hash SHA-256, nunca el texto bruto.
- **Texto del pedido de consentimiento, por idioma**: el prompt automático usa el texto incorporado, pero
  puedes escribir el tuyo — y ahora **por idioma**. El texto se elige por el idioma del **contacto** (con
  retroceso al idioma de la cuenta y, por último, al texto que ya tenías). Un texto único configurado antes
  sigue valiendo para todos los idiomas: no hay nada que migrar. También hay un texto por **canal**, que gana
  sobre el general. Un selector `{x}` inserta los cinco marcadores aceptados — `{{contact_name}}`,
  `{{privacy_policy_url}}`, `{{dpo_email}}`, `{{affirmative_token}}` y `{{negative_token}}`; cualquier otro se
  **elimina** en el envío, y la plataforma rechaza el guardado indicando qué marcador no existe (en cualquiera
  de los idiomas). Un campo vacío muestra el texto incorporado que realmente sale, y **Restaurar
  predeterminado** borra tu versión de ese idioma de verdad (la eliminación llega al servidor, no solo
  desaparece de la pantalla).
- **Vista previa y prueba del pedido**: la vista previa renderiza el texto **por canal**, con el nombre de un
  contacto real y los tokens que el reconocedor acepta; la **prueba** envía de verdad a una conversación que
  elijas. Así validas la redacción sin esperar el próximo inbound.
- **Holds legales**: la pestaña **Holds legales** lista las conversaciones que la retención nunca puede
  eliminar: ni por plazo ni por inactividad. Busque la conversación por contacto, número o bandeja de
  entrada, indique el motivo (por ejemplo, una orden judicial) y aplíquelo. Un hold se **libera, nunca se borra**: el registro conserva quién lo
  aplicó, quién lo liberó y cuándo, porque esa es justamente la prueba que un hold legal existe para
  producir. Solo administradores y roles con **gestionar gobernanza de datos** aplican o liberan; quienes
  tienen exportación/eliminación pueden ver la lista para entender por qué una conversación sobrevivió.
- **Sello de consentimiento**: en el panel del contacto, un sello muestra el estado vigente: **Concedido**,
  **Rechazado** o **Pendiente**. Con más de un canal, el sello muestra el peor estado, para que un rechazo nunca
  quede oculto tras una concesión en otro canal; pase el cursor para ver la lectura canal por canal. Un canal en el
  que el contacto nunca declaró nada simplemente no aparece: la ausencia no es pendencia.
- **Respuesta no reconocida**: si el contacto responde algo que no puede leerse como decisión, la plataforma
  **deja de preguntar** y marca la conversación con **Consentimiento pendiente**. Resuélvalo con el contacto y
  registre la declaración manualmente desde el panel.
- **Campañas**: los contactos que rechazaron explícitamente salen de la audiencia. La vista previa informa cuántos
  fueron excluidos, y el aviso solo aparece cuando el rechazo realmente redujo la lista. Quien nunca fue preguntado,
  o cuya concesión expiró, sigue recibiendo: pedir consentimiento es tarea del prompt, no de la campaña.
- **Límite deliberado**: este modo solicita y registra; **no pone el inbound en cuarentena, no pausa las
  automatizaciones hasta la decisión y nunca bloquea outbound**. La interfaz no promete un bloqueo técnico
  inexistente. Si la política legal exige suspender todo tratamiento, aplica esa restricción también en el flujo
  operativo, además de este registro.
- **Personalización segura**: el mensaje puede ser global o específico por canal y solo admite `contact_name`,
  `privacy_policy_url`, `dpo_email`, `affirmative_token` y `negative_token`, cada uno entre llaves dobles. Las
  respuestas se comparan sin diferenciar mayúsculas, acentos ni puntuación en los extremos. Un token afirmativo no
  puede ser también negativo; la API rechaza la ambigüedad y una configuración heredada nunca registra una decisión.
  Los placeholders no compatibles y etiquetas Liquid se rechazan; los valores heredados se eliminan antes del envío.
- **Anonimizar con redacción de mensajes**: opcionalmente la anonimización también redacta el
  contenido de los mensajes recibidos del contacto y elimina los adjuntos.
- **Confirmación obligatoria**: anonimizar/eliminar exige escribir el **id del contacto** — una
  protección contra acciones destructivas accidentales.

## Casos de uso

- Atender una solicitud formal de titular (art. 18 LGPD) con comprobante auditable.
- Higienizar la base periódicamente con la retención central de mensajes.
- Probar la base legal de marketing con el historial de consentimiento por contacto.

## Consejos, límites y buenas prácticas

- La exportación corre en segundo plano; el solicitante recibe un correo que lo lleva al área
  autenticada de Gobernanza. Solo los Administradores y los roles con **exportación de datos** pueden
  generar el enlace temporal del paquete; la gestión de gobernanza o la eliminación de datos, por sí
  solas, no conceden acceso al archivo.
- La anonimización **no** borra la conversación — borra la identidad. Para la remoción total, usa la
  eliminación (borrado del contacto), sabiendo que el historial de conversaciones se elimina con ella.
- Toda acción de gobernanza deja un evento en el registro de auditoría (cuando está habilitado).
- Solicitud, concesión y rechazo generan acciones distintas de auditoría; los reintentos son idempotentes y el
  bloqueo de la fila del contacto evita dos prompts concurrentes.
- **Empresas en el DSR**: la exportación y la anonimización de un contacto **ya incluyen** sus
  vínculos y relaciones con **Empresas** (nombres, roles, fechas y notas). Lo que permanece aparte es
  el enmascaramiento de documentos fiscales (Modo Presentación/RBAC) y la gobernanza de la Empresa
  como entidad — consulta el artículo de Empresas y relaciones.

## Solución de problemas

- **El área no aparece**: la función no está habilitada en la cuenta o tu perfil no tiene permiso.
- **Una solicitud quedó en "Falló"**: revisa el detalle del error en la lista y reintenta; el evento
  de falla también queda registrado en la auditoría.
- **El prompt no se envió**: verifica la función Gobernanza y LGPD, el control de consentimiento inbound y si ya
  existe una declaración global o del canal. Cualquier estado anterior (otorgado o rechazado) evita otro prompt. Si el
  proveedor marca el prompt como fallido, se intenta de nuevo en el próximo inbound, una vez por contacto/canal.
- **La respuesta no fue reconocida**: revisa los tokens configurados; el mensaje debe coincidir con un token
  completo. Agrega las variantes necesarias separadas por comas.

## Ver también

- [Modo Presentación](/hc/ajuda/articles/administration-modo-apresentacao-es)
- [Registros de auditoría](/hc/ajuda/articles/administration-auditoria-es)
- [Roles personalizados y gobernanza (RBAC)](/hc/ajuda/articles/administration-custom-roles-governanca-rbac-es)
- [Empresas y relaciones](/hc/ajuda/articles/contacts-crm-empresas-e-relacionamentos-es)