LGPD na prática: o que precisa existir dentro do software

A maioria dos times trata LGPD como assunto jurídico: alguém escreve uma política de privacidade, coloca um banner de cookies, e a pasta é considerada resolvida.

A resposta curta de quem constrói software: a LGPD é, na prática, uma lista de requisitos de engenharia. Política de privacidade é o documento que descreve o que o sistema faz. Se o sistema não faz, o documento é ficção — e é justamente a diferença entre os dois que aparece quando um titular exerce um direito, quando um cliente grande manda o questionário de segurança ou quando acontece um incidente.

Este artigo não é consultoria jurídica. É a tradução das obrigações da lei em decisões concretas de produto, banco de dados e operação — o que a gente aplica em projeto.

O primeiro passo não é técnico: saber que dado você tem

Não existe conformidade sem inventário. Antes de qualquer controle, o time precisa conseguir responder, para cada dado pessoal que o sistema guarda:

• Qual dado? Nome, e-mail, CPF, telefone, endereço, IP, geolocalização, foto. E se há dado sensível: saúde, biometria, origem racial, opinião política, dado de criança ou adolescente — categorias com exigências mais duras.
• Por quê? A finalidade específica. "Pode ser útil um dia" não é finalidade, e é o motivo mais comum de coleta indevida.
• Com que base legal? Consentimento é apenas uma das hipóteses, e frequentemente a pior escolha: ele pode ser revogado a qualquer momento, e aí você precisa parar de tratar. Execução de contrato, obrigação legal e legítimo interesse costumam sustentar melhor o que o produto realmente faz.
• Por quanto tempo? Todo dado precisa de prazo. Dado sem prazo de descarte é passivo acumulando.
• Quem acessa? Internamente e externamente — incluindo cada fornecedor que recebe esse dado.

Esse inventário vira documento vivo, e é o que sustenta as decisões técnicas de todo o resto do artigo. Sem ele, cada controle implementado é chute.

Coleta de dado sem finalidade declarada não é recurso do produto. É risco no balanço.

Direitos do titular são funcionalidade, não e-mail

Aqui está a parte que mais surpreende times de produto. A lei dá ao titular um conjunto de direitos — e cada um deles, para funcionar de verdade, precisa existir como capacidade do sistema:

Direito do titular	O que precisa existir no software
Confirmação e acesso	Consulta que reúne tudo que existe sobre uma pessoa, em todas as tabelas
Correção	Edição pelo titular ou fluxo interno com registro de quem alterou
Eliminação	Exclusão real, com tratamento do que a lei obriga a reter
Portabilidade	Exportação em formato legível por máquina
Informação sobre compartilhamento	Lista de com quem aquele dado foi compartilhado
Revogação de consentimento	Desligamento efetivo do tratamento, não só uma flag

O teste é simples e desconfortável: quanto tempo o seu time levaria, hoje, para atender um pedido de acesso completo de um titular? Se a resposta envolve alguém rodando consultas manuais em várias tabelas e cruzando planilha, você tem um processo que não escala e que erra.

O detalhe que quase todo produto erra é a eliminação. Exclusão não pode ser só marcar um campo deletado = true se o sistema continua usando o dado — mas também não pode apagar tudo cegamente, porque parte da informação tem retenção obrigatória por outras leis, como registros fiscais. O desenho correto separa o que é identificação pessoal (que sai ou é anonimizada) do que é registro obrigatório da operação (que fica, sem identificar).

O que isso vira no banco de dados

Minimização de verdade. Cada campo de formulário é uma decisão de risco. Se você não consegue dizer para que serve, ele não deveria existir. A pergunta a fazer em toda tela de cadastro: o que acontece com o produto se este campo não for coletado? Se a resposta for "nada", tire.

Separação por sensibilidade. Dado sensível não deveria estar na mesma tabela solta com o resto, acessível por qualquer consulta da aplicação. Separar permite controle de acesso mais restrito e criptografia específica.

Criptografia em repouso e em trânsito. Trânsito é o básico que todo mundo já tem. Repouso, incluindo backups, é o que costuma faltar — e backup vazado é vazamento igual.

Log de acesso a dado pessoal. Quem consultou o quê, quando. Isso serve para duas coisas: investigar incidente e responder à pergunta "quem acessou meus dados". Vale especialmente para telas administrativas, onde um usuário interno enxerga dados de muitos titulares.

Retenção automática. Prazo definido no inventário precisa virar rotina que executa: descarte, anonimização ou arquivamento. Política de retenção que depende de alguém lembrar é política que não existe.

Ambientes de teste sem dado real. Copiar a base de produção para o ambiente de desenvolvimento é uma das práticas mais comuns e mais indefensáveis. Use dado sintético ou base mascarada.

Consentimento e banner de cookies: o que realmente vale

Banner de cookies virou teatro na maior parte dos sites brasileiros, e o teatro tem custo quando alguém olha de perto.

Um consentimento que se sustenta é específico, informado, livre e comprovável:

• Específico: separado por finalidade. Marketing, analytics e funcionalidade essencial são escolhas diferentes, não um botão só.
• Livre: recusar precisa ser tão fácil quanto aceitar. Botão "Aceitar" destacado com "Gerenciar preferências" escondido em cinza é exatamente o padrão que a autoridade classifica como problemático.
• Prévio: scripts de rastreamento não disparam antes da escolha. É o erro técnico mais frequente — o banner aparece, mas as tags já carregaram.
• Comprovável: registro de quem consentiu, quando, a qual versão do texto e por qual meio. Consentimento sem registro é consentimento que você não consegue demonstrar.
• Revogável: precisa existir um lugar visível para mudar de ideia depois, não apenas no primeiro acesso.

E o principal: se a base legal correta não é consentimento, não peça consentimento. Pedir permissão para algo que você faz por execução de contrato cria a expectativa de que o titular pode negar — e quando ele nega, você fica numa posição pior do que se tivesse declarado a base certa desde o começo.

Fornecedores: o risco que você assume sem perceber

Todo serviço que recebe dado dos seus usuários é uma extensão do seu tratamento. Analytics, e-mail transacional, gateway de pagamento, hospedagem, monitoramento de erro — e, cada vez mais, provedores de modelos de IA.

Para cada um, três perguntas que deveriam estar respondidas por escrito:

1. Que dado pessoal ele recebe, e esse dado é o mínimo necessário?
2. Onde esse dado é armazenado, e existe transferência internacional?
3. Existe contrato que trate proteção de dados, com obrigações de segurança e de notificação de incidente?

O ponto de atenção novo e que quase ninguém revisou ainda: ferramentas de IA. Enviar conteúdo de clientes para um modelo de terceiro é compartilhamento de dado. Antes de ligar qualquer integração assim, verifique o que o provedor faz com o conteúdo enviado, se há retenção e se há uso para treinamento — e trate isso no inventário como qualquer outro fornecedor.

Um erro clássico de arquitetura, especialmente em ferramenta de monitoramento de erro: capturar a requisição inteira no log de exceção. O rastreamento sai do seu servidor carregando CPF, endereço e telefone do usuário para dentro de um serviço externo, sem ninguém ter decidido isso. Filtrar campos sensíveis antes de enviar é um ajuste de minutos que quase nunca é feito.

Incidente: o plano que precisa existir antes

Incidente de segurança com dado pessoal exige comunicação à autoridade e, dependendo do risco, aos titulares afetados. E a comunicação precisa dizer quais dados, quantas pessoas e o que foi feito — informação que só existe se o sistema foi construído para produzi-la.

O mínimo que precisa estar pronto antes:

• Log que permita reconstruir o que foi acessado e por quem
• Capacidade de identificar rapidamente quais titulares foram afetados
• Responsável designado e caminho de decisão definido, não improvisado no dia
• Rotina de rotação de credenciais
• Registro do próprio incidente e das medidas tomadas

Descobrir na hora do incidente que os logs não guardam o suficiente é a pior forma possível de aprender essa lição.

Checklist mínimo de LGPD no produto

• Inventário de dados pessoais com finalidade, base legal e prazo de retenção
• Cada campo coletado tem justificativa de existência
• Consulta que reúne todos os dados de um titular em um lugar
• Exportação em formato legível por máquina
• Exclusão que separa identificação pessoal de registro de retenção obrigatória
• Criptografia em repouso, incluindo backups
• Log de acesso a dado pessoal, principalmente em telas administrativas
• Rotina automática de descarte ou anonimização por prazo
• Ambientes de teste sem dado real de produção
• Consentimento granular, prévio, revogável e registrado com versão
• Nenhum script de rastreamento disparando antes da escolha do usuário
• Contrato de proteção de dados com cada fornecedor que recebe dado pessoal
• Filtro de campos sensíveis antes de enviar a ferramentas externas
• Plano de incidente escrito, com responsável definido
• Política de privacidade que descreve o que o sistema faz de fato

Vale checar também o que o seu site já expõe hoje do lado de fora: o Raio-X do Site roda de graça uma verificação de HTTPS, cabeçalhos e fundamentos técnicos em 10 segundos.

Perguntas Frequentes

O que a LGPD exige na prática de um software?

Exige que o sistema consiga demonstrar controle sobre o dado pessoal: saber quais dados coleta, com qual finalidade e base legal, por quanto tempo retém e quem acessa. Na prática isso vira funcionalidades — consulta unificada por titular, exportação, exclusão com tratamento de retenção obrigatória, log de acesso, criptografia em repouso e descarte automático por prazo. Política de privacidade descreve esses controles, mas não os substitui.

Preciso de consentimento para tratar qualquer dado pessoal?

Não. Consentimento é apenas uma das bases legais previstas, e frequentemente não é a mais adequada, porque pode ser revogado a qualquer momento. Execução de contrato, cumprimento de obrigação legal e legítimo interesse sustentam melhor boa parte do que um produto faz. Pedir consentimento para algo cuja base correta é outra cria uma fragilidade desnecessária.

Como atender a um pedido de exclusão de dados sem quebrar o sistema?

Separando identificação pessoal de registro de operação. Os dados que identificam a pessoa são removidos ou anonimizados; os registros que outras leis obrigam a reter, como documentos fiscais, permanecem sem vínculo identificável. Exclusão que apenas marca um campo de inativo, mantendo o dado em uso, não atende ao direito do titular.

Banner de cookies é obrigatório no Brasil?

O que a lei exige não é o banner em si, e sim base legal válida para o tratamento e transparência sobre ele. Na prática, quando há rastreamento não essencial, isso se resolve com um mecanismo de escolha granular, prévio ao disparo dos scripts, com recusa tão fácil quanto a aceitação e com registro do consentimento. Banner que já carrega as tags antes da escolha não cumpre a finalidade.

Usar ferramentas de IA com dados de clientes viola a LGPD?

Não automaticamente, mas configura compartilhamento de dado pessoal com um terceiro e precisa ser tratado como tal: entrar no inventário, ter base legal, estar coberto por contrato e ser informado ao titular. Os pontos a verificar com o provedor são retenção do conteúdo enviado, uso para treinamento e local de armazenamento. Enviar apenas o mínimo necessário, sem identificadores diretos, reduz bastante a exposição.

Startup pequena também precisa se preocupar com LGPD?

Sim. A lei não cria isenção por porte, e o custo de implementar os controles é incomparavelmente menor quando o produto está sendo construído do que quando já existe uma base grande. Além do aspecto legal, há um efeito comercial concreto: questionário de segurança é etapa padrão em venda para empresa média ou grande, e não conseguir respondê-lo trava negócio.

O momento certo de resolver isso é antes

Quase tudo neste artigo custa pouco quando é decidido junto com a arquitetura e custa caro quando é retrofit. Separar dado sensível, definir retenção, registrar acesso e desenhar a exclusão são decisões de modelagem — mexer nelas depois significa migração de dados com sistema em produção, que é exatamente o tipo de trabalho que ninguém quer fazer.

E existe um retorno comercial direto que costuma passar despercebido: empresa que consegue responder um questionário de segurança rapidamente fecha contrato que a concorrente perde por demora.

Na Alienhub a gente trata proteção de dados como requisito de arquitetura, não como camada colada no fim — desde a modelagem do banco até o que sai nos logs. Se você precisa colocar o seu produto nesse padrão, fala com a gente ou veja como conduzimos arquitetura de software e consultoria técnica.