Controlador × operador, retenção, DSAR, exclusão

Selo de estado: Preview (teto atual do produto) · Curso ACD-240 — Administração, segurança e governança · Aula 9 de 10 · Atualizado em 2026-10-04.

Objetivo#

Ao final desta aula você vai executar DSAR; explicar fronteira — gerando o relatório de acesso e portabilidade de um titular e dizendo, sem hesitar, quem responde por qual dado.

Vídeo#

Identificador no manifesto: acd-240-09-lgpd-operacional · duração-alvo 8 min · tela do produto: /governanca.

Roteiro de gravação (6 capítulos):

Conteúdo#

A fronteira: quem responde por qual dado

Esta é a primeira coisa a aprender, porque muda quem atende o titular:

• A ingestia.io é OPERADORA do datalake (BigQuery/GCS): o dado de negócio que o cliente ingere pertence ao cliente, que é o controlador. Um titular final do cliente-do-cliente é atendido pelo próprio cliente, com as ferramentas de exportação por conta de serviço e de eliminação do datalake.
• A ingestia.io é CONTROLADORA dos dados de conta e operação: autenticação, membros, trilha de auditoria, leads de marketing e recibos de entrega. É sobre estes que a plataforma responde diretamente.

Na prática: "o CPF do meu cliente está no datalake" é pedido do controlador (a empresa); "quais ações minhas estão registradas na plataforma" é pedido atendido pelo DSAR.

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

Os prazos são declarativos e auditáveis, com finalidade e base legal — e a política é a verdade única que alimenta o expurgo:

Um recurso sem política definida nunca expira por engano — é o caso da credencial da Ingestia Academy, que é registro público verificável e vive até a revogação.

O DSAR: acesso e portabilidade

O relatório DSAR reúne, por e-mail do titular, tudo o que o banco de controle guarda ligado a ele — e cada seção declara a fonte (tabela + campos), o critério de casamento e a data da coleta. É isso que o torna verificável, em vez de um despejo de dados.

Ele cobre o cadastro de login, a participação no workspace, as ações auditadas do titular (sem o SQL cru, que pode conter dado de terceiros), comentários e menções, visões pessoais de dashboard, recibos de entrega, eventos de alerta e contatos de marketing. Em grupo próprio vem a Ingestia Academy (base global do titular, fora do workspace): perfil do aprendiz, matrículas, progresso agregado por curso, tentativas de exame (data, certificação, status e nota — nunca o formulário, as respostas ou o gabarito), submissões de desafio e credenciais (código público, certificação, emissão, validade, revogação).

A saída é JSON (portabilidade) e Markdown (leitura do titular). E o que nunca entra: segredos (senha, semente TOTP, hash) e o SQL cru. O datalake do cliente está fora do escopo — ele é do controlador.

A exclusão, passo a passo

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) cancelar a assinatura no provedor de pagamento; (2) apagar o datalake do workspace (Bronze/Silver/Gold); (3) remover o banco de controle (dashboards, queries, fontes, relações e o próprio workspace); (4) erasure do titular, quando pedido — e aqui está o detalhe fail-closed: na mesma transação, as credenciais da Academy são anonimizadas e só então o usuário é apagado; se a anonimização falhar, o usuário não é apagado e o passo fica marcado para reprocesso; (5) registrar na auditoria (account.deleted).

Sobre a credencial da Academy, o comportamento merece ser dito em voz alta porque parece um bug e não é: a credencial pertence à pessoa, e a página pública de verificação precisa continuar respondendo depois que a conta sai — um "não encontrado" falso diria a um empregador que a credencial nunca existiu. Por isso, na exclusão, cada credencial é anonimizada e revogada, não apagada: o nome vira "Titular removido", deixa de ser exibido, a credencial é marcada como revogada por conta_excluida e perde o vínculo com a conta. Perfil, matrículas, progresso, tentativas e submissões são apagados junto com o usuário. Independentemente da exclusão, o titular pode ocultar o nome na página pública; publicar o nome exige consentimento explícito na emissão.

Exemplo: a Aurora atendendo dois pedidos

Um ex-funcionário da Comércio Aurora pede os próprios dados. Maria (owner) gera o DSAR por ana@example.com e entrega o JSON e o Markdown — com cadastro, participação, ações auditadas (sem SQL cru), comentários, visões e entregas. Dias depois chega um pedido diferente: um cliente da Aurora quer a exclusão do próprio CPF. Esse não é um DSAR da plataforma: o CPF está no datalake, a Aurora é a controladora, e o atendimento é feito por ela. Encerrado o contrato, Maria solicita a exclusão total do workspace — e exporta antes o que precisa guardar.

Erros comuns

• DSAR "vazio". Titular sem registros nas fontes: é esperado, e a ausência é, ela própria, evidência verificada.
• Reclamar que o DSAR não traz o SQL. Omissão proposital — o SQL pode conter dado de terceiros.
• Esperar o dado de negócio no DSAR. O datalake é do controlador; o cliente atende.
• Revelar PII sem registro. Ligar viewPII sem decisão escrita é o caminho mais curto para um incidente; a revelação é auditada por desenho.
• Apagar antes de exportar. A exclusão é definitiva.
• Tratar a credencial da Academy que ainda responde como vazamento. É comportamento esperado: ela aparece revogada, sem nome e sem vínculo com a conta.

Estado do produto

Política de retenção, DSAR verificável e exclusão são provados por testes (motores puros e orquestração); o teto público é Preview. Dois limites de escopo: a retenção/expurgo cobre o banco de controle, não o datalake do cliente; e os prazos são decisão de produto, não self-service por workspace. A exclusão é best-effort por passo — uma dependência indisponível não impede os demais passos, mas pode exigir reprocesso (é o caso de academy-anonymize:error com db-user:skipped, em que o usuário foi preservado de propósito). Por plano, governança/LGPD operacional começa no Business. Vale lembrar o limite da política de PII: hoje ela vale nas telas, exportações e envios do ingestia — levá-la para dentro do datalake, valendo para quem consulta as tabelas por fora, ainda não está disponível.

Faça você mesmo#

No workspace de treino Aurora Varejo (abra /governanca no console):

1. Escreva, em duas linhas, a fronteira controlador × operador — e classifique dois pedidos: "quais ações minhas a plataforma registrou" e "apague o CPF do meu cliente".
2. Em /governanca, localize o mapa de colunas PII marcadas e anote em qual camada cada marcação foi feita.
3. Anote a diferença entre ocultar (coluna não aparece), mascarar (aparece sem valor) e negar (acesso recusado).
4. Gere o DSAR por ana@example.com e abra as duas saídas (JSON e Markdown).
5. No relatório, confirme três coisas: cada seção declara fonte e critério, as ações auditadas vêm sem o SQL cru, e nenhum segredo aparece.
6. Localize o grupo da Ingestia Academy no DSAR e anote o que vem das tentativas de exame — e o que nunca vem.
7. Liste os cinco passos da exclusão e aponte em qual deles está o fail-closed da credencial da Academy.
8. Responda por escrito: por que a URL pública de verificação continua respondendo depois da exclusão da conta?

Você terminou quando tiver o DSAR de Ana gerado nos dois formatos, com as três conferências do passo 5 anotadas, e conseguir explicar a fronteira controlador × operador usando os dois pedidos do passo 1.

Checagem rápida#

Três perguntas no final da aula, corrigidas no servidor. A aula só conta como concluída depois da checagem.

Documentação relacionada#

• administracao/governanca-lgpd
• administracao/auditoria
• administracao/usuarios-grupos-permissoes

Capacidades ensinadas#

C11.6 — o selo exibido na aula é sempre o estado mais conservador entre as capacidades citadas; nada aqui é "GA".