LGPD para desenvolvedores: privacidade que vira código, não só cláusula de contrato

Um usuário mandou um e-mail pedindo, com base na LGPD, que a empresa apagasse todos os seus dados. O jurídico respondeu que sim, é um direito, e repassou para a engenharia executar. Foi aí que a coisa desandou. O dado do usuário estava na tabela principal — fácil. Estava também em três tabelas relacionadas, num índice de busca replicado, no cache que espelhava o perfil, nos logs de aplicação dos últimos noventa dias, em quatro backups diários retidos por meses, numa réplica de leitura, e num data warehouse que alguém tinha configurado para copiar tudo diariamente para análise. "Apagar os dados" tinha virado um problema de arquitetura distribuída que ninguém havia projetado para resolver. A empresa cumpriu o pedido no papel e continuou tecnicamente de posse do dado em meia dúzia de lugares.

A LGPD é frequentemente vista como assunto de advogado, e boa parte dela é. Mas uma fração enorme das suas exigências só se cumpre em código, com decisões que o desenvolvedor toma ao modelar tabelas, escrever endpoints, configurar retenção e desenhar pipelines. Este artigo trata dessa fração — a privacidade como problema de engenharia.

O que a LGPD é para quem implementa#

A Lei Geral de Proteção de Dados regula o tratamento de dados pessoais de pessoas no Brasil. Para o desenvolvedor, o conceito central é o de dado pessoal: qualquer informação relacionada a uma pessoa identificada ou identificável. Isso é mais amplo do que parece — não é só nome e CPF; é e-mail, IP, identificador de dispositivo, cookie, geolocalização, qualquer coisa que, sozinha ou combinada, aponte para um indivíduo. Uma subcategoria, o dado pessoal sensível (origem racial, convicção religiosa, opinião política, dado de saúde, biometria, orientação sexual), recebe proteção reforçada e restrições maiores de tratamento.

Reconhecer o que, no seu sistema, é dado pessoal é o primeiro passo, porque tudo o mais decorre disso. Um campo que você trata como "só um identificador técnico" pode ser dado pessoal aos olhos da lei, e portanto sujeito a todas as obrigações que seguem.

Bases legais: consentimento não é a única, nem sempre a melhor#

Um mito comum entre desenvolvedores é que todo tratamento de dado pessoal exige consentimento explícito do usuário. A LGPD prevê várias bases legais, e o consentimento é apenas uma delas — e frequentemente a mais frágil, porque pode ser revogado a qualquer momento, obrigando você a parar o tratamento. Outras bases costumam ser mais adequadas: a execução de um contrato (você precisa do endereço para entregar o produto que a pessoa comprou), o cumprimento de obrigação legal (guardar nota fiscal), o legítimo interesse (com o devido teste de proporcionalidade). Escolher a base legal correta para cada tratamento é uma decisão de design que afeta o que o sistema precisa oferecer — se você se apoia em consentimento, precisa de mecanismo para coletá-lo granularmente, registrá-lo e permitir sua revogação.

Privacy by design e by default#

Dois princípios da lei se traduzem quase diretamente em arquitetura. Privacy by design diz que a proteção de dados deve ser considerada desde a concepção do sistema, não remendada depois — o que significa pensar em quais dados você coleta, por quê, por quanto tempo e quem acessa, no momento de desenhar a feature, e não quando o encarregado de dados cobra. Privacy by default diz que a configuração padrão deve ser a mais protetiva: o perfil nasce privado, o compartilhamento vem desligado, a coleta opcional não vem pré-marcada. O usuário que nunca mexe em nada deve estar, por padrão, no estado de maior privacidade.

Minimização: só colete o que você usa#

O princípio de minimização é o mais subestimado e o mais poderoso, porque resolve o problema pela raiz: dado que você não coleta não pode vazar, não precisa ser protegido, não precisa ser deletado e não aparece num incidente. A pergunta a fazer para cada campo de cada formulário é "eu realmente uso isto?". Coletar a data de nascimento completa quando você só precisa saber se a pessoa é maior de idade; guardar o endereço inteiro quando bastava a cidade; registrar o IP em todo log quando ele só importa em eventos de segurança — cada excesso é um passivo que você carrega sem ganho. Minimizar coleta é a decisão de engenharia que mais reduz risco de privacidade por unidade de esforço.

Finalidade e retenção: apague quando não precisar mais#

A lei exige que o dado seja tratado para finalidades específicas e informadas, e que não seja mantido além do necessário para essas finalidades. Traduzido em sistema, isso significa que retenção não é "guardar para sempre por via das dúvidas" — é uma política explícita, idealmente automatizada, que elimina ou anonimiza o dado quando a finalidade se esgota. Um carrinho abandonado não precisa ser guardado por anos; um log de acesso tem prazo; um cadastro de usuário inativo há muito tempo é candidato a eliminação ou anonimização. Sistemas que nunca deletam nada acumulam um passivo crescente de dados pessoais que só serve para ampliar o estrago do próximo vazamento.

Os direitos do titular viram endpoints#

A LGPD concede à pessoa uma série de direitos sobre seus dados, e cada um deles, para ser cumprido em escala, precisa virar funcionalidade. O direito de acesso e de portabilidade significa poder exportar, num formato utilizável, tudo o que você tem sobre aquela pessoa — o que exige saber onde esse "tudo" está. O direito de correção significa poder atualizar dados incorretos. O direito de eliminação é o mais tecnicamente espinhoso, como o exemplo de abertura mostrou.

O problema técnico de deletar de verdade#

Deletar dado pessoal soa trivial — um DELETE — e é, na tabela principal. O desafio é que dado pessoal se espalha: réplicas, caches, índices de busca, filas, logs, data warehouses e, sobretudo, backups. Um backup por definição preserva o estado passado, incluindo o dado que você acabou de deletar. Resolver isso exige projeto: mapear onde o dado de uma pessoa reside (o que só é viável se você minimizou e centralizou), propagar a eliminação para os sistemas derivados, e ter uma política de backup que, embora não possa deletar cirurgicamente de um backup imutável, garante que o dado deletado não retorne à vida num restore e que os backups antigos expiram num prazo definido. A anonimização entra como alternativa pragmática quando a eliminação total é inviável — transformar o dado de modo que ele deixe de identificar a pessoa.

Anonimização versus pseudonimização#

Esses dois termos são frequentemente confundidos e têm consequências jurídicas opostas. Pseudonimização substitui identificadores diretos por uma referência (um token, um ID) mas mantém, em algum lugar, a chave que permite reverter — o dado ainda é pessoal, ainda está sob a lei, só está mais protegido. Anonimização, feita corretamente, é irreversível: não há como, por meios razoáveis, voltar ao indivíduo, e o dado anonimizado sai do escopo da LGPD. A distinção importa muito na prática, porque times frequentemente acham que "anonimizaram" quando apenas pseudonimizaram — trocaram o nome por um ID mantendo a tabela de-para que reverte tudo. Anonimização de verdade é difícil (dados aparentemente inócuos, combinados, reidentificam pessoas) e merece cuidado real, não um hash do e-mail que qualquer um reverte por força bruta.

Onde os dados moram e quando o incidente acontece#

Duas obrigações restantes têm forte componente técnico. Transferência internacional de dados é regulada, então onde seus dados fisicamente residem — em qual provedor, em qual região — é uma decisão com implicações legais, não só de latência. E, quando um incidente de segurança acontece, a lei prevê comunicação à autoridade e aos titulares afetados em prazo razoável, o que pressupõe que você seja capaz de detectar o incidente e determinar quais dados e quais pessoas foram afetados — de novo dependente de bom logging, bom inventário de dados e boa detecção. Um relatório de impacto à proteção de dados (o DPIA) pode ser exigido para tratamentos de maior risco, e produzi-lo obriga a mapear fluxos de dado que o time raramente documenta de outra forma.

Cookies, tracking e o consentimento que o front implementa#

A camada de front carrega parte da conformidade. Cookies e tecnologias de rastreamento que coletam dado pessoal geralmente exigem base legal e, quando é consentimento, um mecanismo real de coleta — não o banner que "consente" no clique em qualquer lugar da página, mas uma escolha granular, com opção de recusar tão fácil quanto a de aceitar, e que efetivamente não dispara o tracking antes do aceite. Muitos banners implementados por aí são teatro de conformidade: pedem consentimento e carregam os rastreadores de qualquer jeito. Fazer certo é decisão de implementação no front.

O ângulo que a IA acrescenta#

Modelos de IA colidem com a LGPD em pontos novos e delicados. Treinar um modelo com dados pessoais é um tratamento que precisa de base legal, e o modelo treinado pode memorizar e vazar fragmentos desses dados, o que complica tanto a minimização quanto o direito à eliminação — como você "deleta" o dado de uma pessoa que já foi absorvido nos pesos de um modelo? Decisões automatizadas que afetam significativamente as pessoas (aprovar crédito, filtrar currículo) trazem o direito à explicação e à revisão, o que impõe requisitos de transparência e de rastreabilidade sobre como o sistema decidiu. Se você constrói features de IA sobre dados de usuários, essas questões deixam de ser hipotéticas: entram no design desde o primeiro dia, sob pena de construir um sistema que é, por arquitetura, impossível de tornar conforme depois.

O resumo do desenvolvedor#

A LGPD, para quem escreve código, se destila em um punhado de hábitos de engenharia. Saiba o que no seu sistema é dado pessoal e sensível. Escolha a base legal certa para cada tratamento em vez de reflexivamente pedir consentimento. Colete o mínimo — o dado não coletado é o único que nunca vaza. Defina e automatize retenção, apagando quando a finalidade se esgota. Projete os direitos do titular como funcionalidades reais, encarando de frente a dificuldade de eliminar dado espalhado por réplicas, caches e backups. Entenda a diferença entre anonimizar e pseudonimizar, e não se engane sobre qual você fez. E, ao construir IA sobre dados de pessoas, trate memorização, explicabilidade e eliminação como requisitos de projeto. Privacidade não é uma cláusula que o jurídico redige e o dev ignora — é um conjunto de decisões que só existem no código, tomadas por quem o escreve.