LGPD no produto digital: checklist do que não pode faltar

LGPD dentro de um produto digital não se resolve com banner de cookie e um texto genérico copiado de outro site. Resolve-se desenhando o sistema para que todo dado pessoal tenha dono definido, finalidade clara, prazo de retenção e um caminho real de exclusão quando necessário.

O advogado da empresa define a política de privacidade. A engenharia implementa o controle técnico que sustenta essa política na prática. Os dois precisam conversar diretamente — política sem controle técnico correspondente é apenas um documento bonito e vulnerável.

Comece pelo inventário, mesmo que simples no início

O primeiro passo real, antes de qualquer outra ação, é listar:

• Quais dados pessoais entram no sistema, especificamente.
• De onde eles vêm — formulário preenchido pelo usuário, importação de planilha, integração com outro sistema.
• Quem, dentro do time e dentro do próprio sistema, tem acesso a cada tipo de dado.
• Por quanto tempo esses dados permanecem armazenados.
• Com quais fornecedores externos (provedores) esses dados são compartilhados, mesmo que indiretamente.

Sem esse inventário básico, qualquer alegação de "estamos em conformidade com a LGPD" é discurso de marketing, não realidade verificável.

Consentimento e base legal não são a mesma tela nem o mesmo conceito

Nem todo tratamento de dado pessoal depende de consentimento explícito do titular — existem outras bases legais previstas na lei. Mas quando o tratamento depende de consentimento, o produto precisa, tecnicamente:

• Registrar exatamente o que foi aceito pelo usuário, com data e contexto.
• Permitir que esse consentimento seja revogado a qualquer momento, de forma simples.
• Não amarrar uma funcionalidade essencial do produto a um botão opaco de "aceito tudo" que o usuário precisa clicar só para conseguir usar o serviço básico.

Para o site institucional e para a operação de anúncios, a política de privacidade precisa refletir exatamente o que o código do produto realmente faz — nunca o contrário, prometendo no texto algo que o sistema não cumpre na prática.

Controle de acesso é, na prática, privacidade

Se toda a equipe de suporte consegue visualizar dado de todos os clientes, indiscriminadamente, isso é um problema estrutural de produto — não apenas uma questão de treinamento de RH. Papéis de acesso bem definidos, auditoria de quem acessou dado sensível e o princípio do menor privilégio necessário fazem parte do próprio desenho do sistema, alinhados com o que detalhamos em autenticação e permissões: erros caros que nascem 'só por enquanto'.

Retenção de dado: o "apagar" que de fato apaga

Um botão de "excluir conta" que só esconde o registro da interface, sem removê-lo de fato do sistema, não atende ao espírito nem à letra da lei. É preciso definir com clareza:

• A diferença entre exclusão lógica (soft delete, o registro fica marcado como excluído mas permanece no banco) e exclusão física (hard delete, o dado realmente deixa de existir).
• O que permanece em backup, e por quanto tempo esse backup é retido depois da exclusão solicitada.
• Como, na prática, o sistema atende a um pedido formal do titular do dado — seja de exclusão, seja de exportação.

Manter backup eterno de tudo "porque um dia pode precisar" entra em conflito direto com o princípio de minimização de dado previsto na lei. Isso se conecta com a lógica de backup que precisa realmente poder ser restaurado, mas com o cuidado adicional de que retenção infinita de dado pessoal é, ela mesma, um risco.

Fornecedores e subprocessadores de dado

Hospedagem, provedor de e-mail transacional, ferramenta de analytics, AdSense, CRM — cada um desses fornecedores processa dado pessoal em algum nível, mesmo que a empresa não pense neles dessa forma no dia a dia. Documentar quem são esses fornecedores, escolhê-los com critério de segurança, e evitar espalhar a base de clientes em cinco ferramentas diferentes sem contrato formal de processamento de dado é parte essencial do trabalho.

Logs e atendimento de suporte

Um log de sistema que registra CPF completo e token de sessão em texto plano é uma bomba-relógio esperando para explodir num incidente de segurança. Mascaramento de dado sensível em log, retenção curta especificamente para log que contém informação sensível, e acesso restrito ao ambiente de produção são investimentos baratos comparados ao custo real de um incidente de vazamento.

O que um banner de cookie nunca vai resolver sozinho

• Treinar a equipe para nunca exportar a base de clientes para o e-mail pessoal, por conveniência.
• Nunca usar dado de produção real em ambiente de teste sem antes anonimizá-lo.
• Nunca prometer no site algo que o produto, na prática, não cumpre tecnicamente.

Checklist enxuto antes de qualquer lançamento (go-live)

• Inventário de dados pessoais atualizado e revisado
• Bases legais de tratamento mapeadas junto ao time jurídico
• Política de privacidade alinhada de fato com o que o produto faz
• Papéis de acesso e permissões revisados recentemente
• Fluxo de exclusão e exportação de dado testado na prática, não só documentado
• Lista de fornecedores externos com responsável interno definido

Próximo passo

Se o produto já está no ar sem essa estrutura montada, priorize primeiro o inventário de dados e o controle de acesso. Só depois disso, política de privacidade e banner de cookie. Fazer na ordem inversa produz um documento bonito e um risco real permanecendo por baixo dele.

Para desenhar esses controles no seu sistema: fale com a Auryx.