Governança e LGPD — retenção, privacidade, exclusão e exportação

Selo de estado: GA-candidato (política de retenção, DSAR e exclusão provados por testes) · Atualizado em 2026-09-08. Fonte de estado: matriz de estados do produto (LGPD operacional, access review, retenção e DSAR verificável). Limite atual do produto = Preview.

Como o ingestia.io trata dados pessoais: por quanto tempo guarda cada coisa, o que é dado do cliente vs. dado da plataforma, e como atender aos direitos do titular (acesso, portabilidade e eliminação).

Fronteira controlador × operador (leia primeiro)#

Isto muda quem responde por cada dado:

• ingestia.io é OPERADOR do datalake (dados analíticos e área de arquivos): o dado de negócio que o cliente ingere pertence ao cliente (controlador). Um titular final do cliente-do-cliente é atendido pelo próprio cliente, usando as ferramentas de exportação por service account e de eliminação do datalake.
• ingestia.io é CONTROLADOR dos dados de conta/operação: autenticação, membros, trilha de auditoria, marketing (leads) e recibos de entrega. É sobre estes que a plataforma responde diretamente.

Política de retenção (banco de controle)#

Prazos declarativos e auditáveis, com finalidade e base legal:

A política é a verdade única dos prazos; o cálculo do que já venceu alimenta o expurgo. Recurso sem política definida nunca expira por engano.

DSAR — acesso e portabilidade (art. 18, I/II/V)#

O relatório DSAR reúne, por e-mail do titular, tudo que o banco de controle guarda ligado a ele — cada seção declarando a fonte (tabela + campos) e o critério de casamento, com a data da coleta (verificabilidade).

Fontes cobertas: User (cadastro de login), Member (participação no workspace), registro de auditoria (ações do titular — sem o SQL cru), DashboardAnnotation (comentários e menções), UserDashboardView (visões pessoais), DeliveryReceipt, eventos de alerta e contatos de marketing.

• Nunca inclui segredos (senha, TOTP, hash) nem SQL cru (que pode conter dado de terceiros).
• Saída em JSON (portabilidade) e Markdown (leitura do titular).
• Fora do escopo: o datalake do cliente (dado de negócio) — atendido pelo cliente como controlador.

Exclusão de conta e dados (direito de eliminação — art. 18, VI)#

A exclusão orquestra a remoção completa de um workspace, passo a passo e best-effort (uma falha pontual não trava o resto):

1. 1

   Cancelar a assinatura

   Encerra a cobrança no provedor de pagamento.

2. 2

   Apagar o datalake do workspace

   Remove os datasets analíticos (Bronze/Silver/Gold) do workspace no datalake.

3. 3

   Remover o banco de controle

   Apaga dashboards, queries, fontes e relações do workspace, e o próprio workspace.

4. 4

   Erasure do titular (opcional)

   Quando pedido, remove sessões, contas vinculadas e o registro do usuário (User).

5. 5

   Registrar na auditoria

   Grava account.deleted na trilha global (prestação de contas).

Plano e permissões#

• Governança/LGPD operacional: a partir do Business (governança de PII, auditoria) — ver Planos.
• Quem executa: exportar DSAR, revisar acesso e solicitar exclusão são ações de owner do workspace (billing/segurança).

Exemplo#

Um ex-funcionário da Comércio Aurora (fictícia) pede seus dados. Maria (owner) gera o DSAR por ana@example.com: recebe um JSON/Markdown com cadastro, participação, ações auditadas (sem SQL cru), comentários, visões e entregas. Depois, ao encerrar o contrato, solicita a exclusão total do workspace.

Resultado esperado#

• DSAR: relatório verificável com fontes, campos, critérios e data de coleta.
• Exclusão: ok: true com a lista de passos executados; dados removidos.

Segurança e privacidade#

• Minimização: só os campos necessários entram no DSAR; segredos nunca saem.
• Escopo por workspace: DSAR e exclusão operam sempre no workspace da sessão.
• Auditável: a exclusão registra account.deleted.

Limites#

• A retenção/expurgo cobre o banco de controle, não o datalake do cliente (governança do controlador).
• Prazos são conservadores e explicáveis; alterá-los muda a verdade única da política (decisão de produto, não self-service por workspace).
• Exclusão é best-effort por passo: uma dependência indisponível não impede os demais passos, mas pode exigir reprocesso.

Erros comuns e diagnóstico#

Relacionados#

• Logs de auditoria
• Segurança por linha (RLS)
• Usuários, grupos e permissões
• Documentos legais: Privacidade · DPA · Subprocessadores

Última revisão: 2026-09-08.

Estado & evidência: retenção, DSAR verificável e exclusão de dados = GA-candidato (motores puros/orquestração provados por testes). Fonte: matriz de estados do produto.