LGPD pelo olhar do desenvolvedor: o que muda de verdade

Introdução: por que desenvolvedores precisam entender LGPD

Quando o assunto é LGPD, geralmente quem aparece na frente é o jurídico. Vemos termos como base legal, encarregado, controlador, operador, relatório de impacto. Tudo isso é importante. Mas, no fim do dia, quem decide o que o sistema realmente faz com os dados pessoais é o time técnico.

É o desenvolvedor que define quais campos vão no formulário. É o arquiteto que escolhe como os dados serão armazenados. É o time de API que decide quais informações vão trafegar entre sistemas. Se LGPD não chega nesse nível, ela vira só um documento bonito, sem efeito prático.

Este artigo é um convite para olhar a LGPD com o olhar de quem escreve código e desenha fluxos. Vamos falar, em linguagem prática, sobre tipos de dados pessoais, coleta mínima, base legal, logs, retenção, descarte, anonimização e como tudo isso se traduz em decisões concretas de telas e APIs.

A ideia não é transformar dev em advogado. A ideia é fazer com que, na hora de implementar uma feature, você consiga se perguntar: "do ponto de vista da LGPD, o que estou fazendo aqui faz sentido?"

---

Tipos de dados pessoais e dados sensíveis na prática do código

A LGPD fala de alguns conceitos que parecem teóricos, mas aparecem o tempo todo no código:

• Dado pessoal: qualquer informação relacionada a pessoa identificada ou identificável (nome, e-mail, CPF, telefone, placa, IP em certos contextos, etc.).
• Dado pessoal sensível: informações sobre saúde, religião, opinião política, origem racial, biometria, entre outros.
• Anonimização: processo que remove a possibilidade de identificar a pessoa, de forma irreversível ou extremamente difícil.

Na prática do desenvolvimento, isso significa:

• Campos como cpf, email, telefone, placa_veiculo, geo_location não são "só strings", são dados pessoais.
• Campos como religiao, diagnostico, resultado_exame, deficiencia, orientacao_sexual são dados pessoais sensíveis e exigem ainda mais cuidado.
• IDs técnicos (por exemplo, id_usuario numérico) não são dados pessoais em si, mas podem se tornar se for fácil relacionar com a pessoa.

Uma boa prática é marcar, no código ou na documentação, quais campos são dados pessoais e quais são sensíveis. Isso ajuda a tomar decisões sobre criptografia, logs, mascaramento e retenção.

---

Coleta mínima e finalidade: o que realmente precisa estar na tela e na API

Um dos princípios mais importantes da LGPD é a minimização de dados: coletar apenas o que for necessário para a finalidade declarada.

Na prática, isso gera perguntas incômodas para o time de produto e desenvolvimento:

• Este campo é realmente necessário para o serviço funcionar?
• Estamos pedindo essa informação só porque "sempre pedimos" ou porque realmente precisamos?
• Dá para tornar opcional?
• Dá para armazenar de forma menos identificável?

Alguns exemplos práticos:

• Em um formulário de contato, será que precisamos de CPF? Muitas vezes, nome e e-mail já são suficientes.
• Em um cadastro de usuário, precisamos guardar a data de nascimento completa ou só o ano (para fins estatísticos)?
• Em uma API entre sistemas internos, faz sentido trafegar nome completo, ou um ID interno já resolve?

Desenvolvedores ajudam muito a LGPD quando questionam requisitos do tipo "coloca mais esse campo no formulário". Não é ser chato. É ser responsável.

---

Base legal e consentimento vistos do ponto de vista técnico

LGPD fala de bases legais. Consentimento é apenas uma delas. Do ponto de vista técnico, o que importa é:

• Saber por que estamos tratando determinado dado (qual base legal justifica).
• Saber como isso impacta as telas, APIs e registros.

Algumas situações comuns:

• Execução de contrato: o usuário se cadastra para usar o serviço. Dados como nome, e-mail de acesso e CPF para faturamento podem ser tratados sem depender de um botão de "aceito" específico, desde que estejam ligados ao contrato.
• Cumprimento de obrigação legal: emissão de nota fiscal, guarda de registros por prazos definidos em lei, etc.
• Consentimento: por exemplo, para enviar newsletter, usar cookies analíticos ou compartilhar dados com parceiros para fins de marketing.

No código, consentimento costuma aparecer como:

• Campos de checkbox com registro da escolha (data/hora, origem, versão do texto apresentado).
• Flags na base indicando se o usuário permitiu ou não determinados usos.
• Lógica para não executar certas ações (ex.: não enviar e-mail de marketing) se o consentimento não existir.

O papel do dev é garantir que:

• A escolha do usuário seja efetivamente respeitada no fluxo.
• Exista rastreabilidade: dá para provar que a pessoa consentiu? Dá para provar que revogou?
• Não haja "gambiarras" que ignorem a escolha para facilitar uma campanha.

---

Retenção e descarte de dados: prazos, anonimização e pseudonimização

Outro ponto central da LGPD: dados pessoais não devem ficar guardados para sempre só por conveniência. É preciso definir prazos de retenção.

Na prática técnica, isso significa planejar:

• Tabelas com datas de criação e de última atividade.
• Campos/flags para indicar que um dado foi anonimizado ou bloqueado para novos usos.
• Rotinas (jobs, lambdas, scripts) que fazem limpeza ou anonimização periódica.

Três estratégias comuns:

1. Anonimização: remover ou embaralhar dados de forma que não seja mais possível identificar a pessoa. Ex.: apagar nome, e-mail e CPF, mas manter estatísticas agregadas.
2. Pseudonimização: substituir identificadores diretos por códigos internos, reduzindo exposição, mas mantendo a possibilidade de reidentificar em casos específicos. Ex.: em vez de expor CPF em todos os relatórios, trabalhar com um id_pseudonimo.
3. Exclusão lógica ou física: exclusão lógica significa marcar o registro como inativo/anonimizado, mantendo parte dos dados. Exclusão física significa remoção completa da linha ou do arquivo.

Como dev, você ajuda a LGPD quando projeta o banco e os jobs já pensando em ciclos de vida dos dados (criação, uso, arquivamento, descarte) e não só em "inserir e nunca mais mexer".

---

Logs e rastreabilidade sem exagerar nos dados pessoais

Logs são fundamentais para diagnosticar problemas e investigar incidentes. Mas podem virar um risco de privacidade se tudo for jogado ali sem critério.

Boas práticas para devs:

• Evitar registrar dados altamente sensíveis em logs (senha, token, dados de saúde, documentos completos).
• Quando precisar logar algo relacionado a uma pessoa, preferir identificadores internos (ex.: user_id) em vez de nome e CPF.
• Mascarar informações quando realmente for necessário vê-las (ex.: ***.***.***-** em logs de CPF).
• Cuidar com logs de erro que imprimem payloads completos de requisição.

Exemplo clássico de problema:

{
  "nome": "João da Silva",
  "cpf": "123.456.789-00",
  "email": "joao@example.com",
  "senha": "minhaSenha123"
}

Ser logado como request_body inteiro em caso de erro. Do ponto de vista da LGPD e de segurança, isso é péssimo.

O ideal é:

• Fazer parsing do erro.
• Registrar apenas o que é necessário para diagnosticar.
• Tratar campos de forma específica (ex.: nunca logar o campo senha).

---

Como lidar com solicitações de titulares dentro do sistema

A LGPD dá a cada titular (o dono dos dados) direitos como:

• Acessar seus dados.
• Corrigir informações incorretas.
• Solicitar exclusão em alguns casos.
• Portar dados para outro fornecedor.
• Revogar consentimento.

Do ponto de vista técnico, isso significa que o sistema precisa viabilizar essas ações. Alguns exemplos:

• Tela onde o próprio usuário consiga ver e atualizar seus dados cadastrais.
• Um fluxo para solicitar exclusão de conta, que acione as rotinas de descarte/anonimização.
• Exportação de dados em formato estruturado (ex.: JSON ou CSV) para portabilidade.
• Mecanismo para revogar consentimentos marcados anteriormente.

Mesmo quando a empresa decide tratar essas solicitações via e-mail ou canal de atendimento humano, em algum momento alguém vai precisar mexer no sistema. Se não existir API, script ou processo técnico preparado, tudo vira operação manual, sujeita a erro.

Como dev, você pode:

• Propor endpoints ou rotinas internas para facilitar esses atendimentos.
• Garantir que as ações sejam registradas ("dados exportados em tal data", "consentimento revogado em tal data").

---

Boas práticas de design de telas e APIs com LGPD em mente

Algumas decisões simples no design já aproximam muito o sistema da LGPD:

Nas telas:

• Explicar de forma clara por que aquele dado está sendo pedido (finalidade).
• Destacar campos realmente obrigatórios e evitar "obrigatoriedade forçada" em campos desnecessários.
• Usar textos de consentimento objetivos, sem caixa de seleção pré-marcada para finalidades opcionais (como marketing).

Nas APIs:

• Não retornar mais dados do que o necessário para cada consumidor.
• Evitar endpoints "genéricos" que retornam todos os dados da pessoa quando o cliente da API só precisa de um subconjunto.
• Padronizar respostas de erro sem expor detalhes sensíveis.

Na documentação:

• Indicar quais campos são pessoais ou sensíveis.
• Indicar se há algum campo que não deve ser armazenado ou logado.
• Sinalizar restrições de uso (ex.: campo que só pode ser usado para determinada finalidade).

Essa combinação de tela + API + documentação bem pensada reduz muito o risco de uso indevido de dados pessoais.

---

Checklist de cuidados de LGPD para devs em cada nova feature

Para fechar, um checklist rápido que pode ser usado a cada feature que envolva dados pessoais:

1. Coleta e campos

• [ ] Esta feature coleta novos dados pessoais? Quais?
• [ ] Todos esses campos são realmente necessários para a finalidade?
• [ ] Há algum dado sensível? Precisamos mesmo dele?

2. Base legal e consentimento

• [ ] A equipe definiu qual é a base legal para tratar esses dados?
• [ ] Se for consentimento, existe registro claro da escolha do usuário (data/hora, texto apresentado)?
• [ ] Existe forma de revogar esse consentimento?

3. Armazenamento e logs

• [ ] Onde esses dados serão armazenados (tabela, bucket, serviço externo)?
• [ ] Dados sensíveis são criptografados ou minimamente protegidos?
• [ ] Logs evitam registrar dados desnecessários (especialmente senhas e informações sensíveis)?

4. Retenção e descarte

• [ ] Há decisão sobre por quanto tempo esses dados serão mantidos?
• [ ] Existe rotina planejada para anonimização/exclusão ao fim do prazo ou quando o usuário solicitar?

5. Direitos do titular

• [ ] O usuário consegue ver, atualizar ou solicitar remoção de seus dados relacionados a essa feature?
• [ ] Existe alguma forma (tela, API, script interno) de atender pedidos de acesso, correção, exclusão ou portabilidade?

Se esse tipo de checklist fizer parte do processo de desenvolvimento, LGPD deixa de ser um fantasma distante do jurídico e passa a ser parte natural do trabalho de desenvolvimento. E o sistema deixa de ser apenas "funcional" para ser também responsável com os dados das pessoas.