## 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.
   En la anonimización y la eliminación, la solicitud permanece en **Procesando** hasta que el gateway de WhatsApp
   confirma la eliminación del titular en los grupos en los que participó. La parte local ya está completada en ese
   momento, y el aviso bajo el estado explica la espera. La plataforma reintenta automáticamente todos los días, sin
   que tengas que hacer nada, y la solicitud solo aparece como **Completada** después de esa confirmación.

## 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 sigue en "Procesando" con un aviso de espera**: la parte local ya se hizo y falta confirmar la
  eliminación en los grupos de WhatsApp. La plataforma reintenta automáticamente todos los días; no crees una nueva
  solicitud para el mismo titular.
- **Una solicitud quedó en "Falló"**: lee el aviso que aparece bajo el estado. Para una exportación, crea una nueva
  solicitud. Si la eliminación en los grupos fue rechazada, contacta al soporte, porque esa solicitud todavía no se
  puede reprocesar desde la pantalla. 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)