O que é a LGPD? Proteção de dados para desenvolvedores

A LGPD deixou de ser assunto exclusivo do jurídico e virou parte do dia a dia de quem desenvolve software. Coletar um e-mail, gravar um log com IP ou integrar um serviço de analytics são decisões com implicações legais diretas. Neste artigo você vai entender, do ponto de vista de quem programa, o que a lei exige e como transformar seus princípios em código e arquitetura — não como uma camada de burocracia colada por cima, mas como parte do design.

O que é a LGPD

A Lei Geral de Proteção de Dados Pessoais — Lei nº 13.709/2018 (Brasil, 2018) — é a legislação brasileira que regula o tratamento de dados pessoais, tanto por empresas quanto por órgãos públicos. Inspirada no GDPR europeu, ela entrou em vigor em 2020 e criou a ANPD (Autoridade Nacional de Proteção de Dados), responsável por fiscalizar e aplicar sanções.

O ponto central para o desenvolvedor é entender que a lei se aplica a qualquer operação de tratamento de dados pessoais: coleta, armazenamento, uso, compartilhamento, e até a eliminação. Se o seu código toca dados que identificam uma pessoa, a LGPD se aplica. Não importa se você é uma startup de dois fundadores ou uma multinacional: o critério é o tratamento de dados, não o porte da empresa.

Vale destacar dois papéis que a lei define, porque eles aparecem o tempo todo em discussões de conformidade:

• Controlador: quem decide por que e como os dados são tratados. Normalmente é a empresa dona do produto.
• Operador: quem trata os dados em nome do controlador. Um provedor de nuvem, um serviço de e-mail transacional ou um gateway de pagamento costumam ser operadores.

Para o time técnico, essa distinção importa porque cada fornecedor que você integra é, juridicamente, alguém com quem você compartilha dados. Isso tem consequência contratual (precisa de cláusula adequada) e técnica (precisa de controle sobre o que sai do seu sistema).

Dado pessoal e dado sensível

A lei distingue dois conceitos que mudam o nível de cuidado necessário:

• Dado pessoal: qualquer informação relacionada a uma pessoa natural identificada ou identificável. Inclui o óbvio (nome, CPF, e-mail) e o menos óbvio (endereço IP, identificador de dispositivo, cookies, localização). Se um dado, sozinho ou combinado com outros, permite chegar a um indivíduo, ele é pessoal.
• Dado pessoal sensível: subcategoria que exige proteção reforçada — origem racial ou étnica, convicção religiosa, opinião política, dado de saúde, vida sexual, dado genético ou biométrico.

Essa distinção tem consequência prática direta no design do banco de dados. Dados sensíveis costumam exigir cifragem em repouso, controle de acesso mais estrito e, muitas vezes, segregação física. Tratar um dado biométrico com o mesmo descaso de um nome de usuário é um erro de conformidade e de engenharia.

Um ponto que confunde muita gente: o caráter "identificável" é contextual. Um IP isolado pode parecer inofensivo, mas combinado com timestamps e logs de navegação ele identifica alguém. Por isso, na prática, trate qualquer identificador que você consiga cruzar com outra fonte como dado pessoal. A pergunta certa não é "este campo tem o nome da pessoa?", e sim "consigo, combinando o que tenho, chegar a uma pessoa específica?".

As bases legais

Você não pode tratar dados pessoais "porque sim". A LGPD exige uma base legal para cada tratamento, e o consentimento é apenas uma das dez bases previstas. Outras importantes incluem o cumprimento de obrigação legal, a execução de contrato, o legítimo interesse e a proteção da vida.

Para o desenvolvedor, a lição prática é: antes de coletar um dado, alguém precisa ter definido por que ele está sendo coletado e qual base legal o autoriza. Se ninguém sabe responder, o dado provavelmente não deveria estar sendo coletado. Isso evita o reflexo comum de "vamos guardar tudo, pode ser útil depois", que é justamente o oposto do que a lei pede.

Algumas bases têm impacto técnico muito concreto:

• Consentimento. Precisa ser livre, informado e inequívoco. Tecnicamente, isso significa que você precisa registrar quando, como e para quê a pessoa consentiu — um checkbox marcado por padrão não vale, e um consentimento sem trilha de auditoria é difícil de provar. Consentimento também é revogável: o titular pode retirar a qualquer momento, e seu sistema precisa respeitar isso.
• Execução de contrato. Cobre os dados necessários para entregar o serviço contratado. O e-mail para fazer login, o endereço para entregar a compra. Não cobre, porém, usar esse mesmo e-mail para marketing.
• Legítimo interesse. É a base mais flexível e a mais perigosa de usar mal. Exige um teste de proporcionalidade entre o interesse da empresa e os direitos do titular. Antifraude e segurança costumam caber aqui; vigilância injustificada, não.

Na prática, é útil manter um pequeno registro de operações de tratamento (o "ROPA", record of processing activities): uma planilha ou tabela que lista, para cada conjunto de dados, qual é a finalidade, qual é a base legal e qual é o prazo de retenção. Esse documento não é só burocracia — ele é o mapa que o time técnico usa para saber o que pode apagar, o que precisa cifrar e o que jamais deveria ter sido coletado.

Princípios que viram requisitos técnicos

A LGPD lista princípios que parecem abstratos, mas se traduzem em decisões concretas de arquitetura. Três se destacam para quem programa:

• Minimização (necessidade): colete apenas os dados estritamente necessários para a finalidade. Na prática, isso significa formulários enxutos e schemas de banco sem colunas "por garantia".
• Finalidade: use o dado só para o propósito informado. Reaproveitar um e-mail coletado para suporte numa campanha de marketing fere esse princípio.
• Segurança: adote medidas técnicas e administrativas para proteger os dados. Aqui a lei conversa diretamente com as boas práticas de engenharia.

Esse último princípio é onde a conformidade encontra a segurança técnica. Frameworks como o do NIST (2024), o Cybersecurity Framework 2.0, oferecem um vocabulário para estruturar essas medidas em funções como Protect e Detect. A LGPD diz o que proteger; frameworks de segurança ajudam a definir como.

Há ainda outros princípios que valem como gatilhos de design. A transparência exige que o titular saiba o que acontece com seus dados — o que se materializa numa política de privacidade legível e numa interface que não esconde coletas. A prevenção pede que você antecipe danos, o que é, na prática, segurança proativa. E a responsabilização (accountability) exige que você consiga demonstrar que cumpre a lei — daí a importância de logs, registros de consentimento e documentação de decisões.

Direitos do titular e o que eles exigem do sistema

A lei garante ao titular (a pessoa dona dos dados) uma série de direitos, e cada um deles vira um requisito funcional do seu software:

• Acesso: o titular pode pedir uma cópia dos seus dados. Seu sistema precisa conseguir localizar todos os dados de uma pessoa — o que é difícil se eles estão espalhados sem rastreabilidade.
• Correção: ele pode corrigir dados incompletos ou desatualizados.
• Eliminação: ele pode pedir a exclusão dos dados tratados com base no consentimento. Isso exige uma estratégia de exclusão que alcance backups, logs e réplicas.
• Portabilidade: ele pode pedir os dados em formato estruturado para levar a outro fornecedor.

Implementar esses direitos depois que o sistema já está em produção é doloroso. Por isso, "privacidade desde a concepção" (privacy by design) recomenda pensar nesses fluxos antes de modelar o banco. Antecipar "como vou apagar todos os dados desta pessoa?" é, no fundo, o mesmo exercício de pensar como um atacante no threat modeling: você simula um cenário futuro para corrigir o design hoje.

Na prática, atender a esses direitos tende a exigir uma decisão de arquitetura recorrente: centralizar a identidade do titular. Se cada microserviço guarda dados pessoais em colunas próprias sem uma chave comum, responder a um pedido de acesso vira uma caçada manual. Uma abordagem comum é ter um identificador estável por pessoa e um índice que mapeie onde, em cada serviço, existem dados ligados a ela. Esse índice é o que torna possível responder, em minutos, à pergunta "quais dados desta pessoa existem no sistema inteiro?".

A eliminação merece atenção especial porque tem armadilhas técnicas. Apagar a linha da tabela principal não basta se os dados também vivem em:

• réplicas de leitura e standby de banco;
• backups (que têm seu próprio ciclo de retenção);
• caches e filas de mensagens;
• data warehouses e pipelines de analytics;
• logs de aplicação.

Uma estratégia pragmática é distinguir exclusão imediata (dados operacionais, que somem na hora) de expiração de backups (dados que saem naturalmente quando o backup antigo é descartado, conforme uma política documentada). O importante é que essa política exista e seja defensável — não que tudo seja apagado no mesmo milissegundo.

Anonimização versus pseudonimização

Vale separar com clareza dois termos que a lei trata de forma muito diferente, porque a confusão entre eles é fonte de erro de conformidade.

• Pseudonimização: substituir identificadores diretos por referências, mantendo em algum lugar a chave que permite reverter. Trocar o nome por um user_id numérico é pseudonimização se a tabela usuarios ainda liga aquele ID a uma pessoa. Dado pseudonimizado ainda é dado pessoal e continua sob a LGPD.
• Anonimização: transformar o dado de forma irreversível, a ponto de não ser mais possível identificar a pessoa, considerando meios técnicos razoáveis. Dado verdadeiramente anonimizado sai do escopo da lei.

A consequência prática é dura: anonimizar de verdade é difícil. Remover o nome mas manter CEP, data de nascimento e gênero pode permitir reidentificação por cruzamento. Por isso, na maioria dos sistemas, o que você consegue de fato é pseudonimizar — e deve continuar protegendo o dado como pessoal que ele é.

Segurança: o capítulo técnico da LGPD

A lei exige "medidas de segurança, técnicas e administrativas aptas a proteger os dados pessoais de acessos não autorizados". Ela não prescreve tecnologias específicas, mas as boas práticas são bem conhecidas. Algumas com impacto direto no código:

• Nunca armazene senhas em texto puro. Use funções de hash adequadas com salt. Vale revisar segurança de senhas com hashing, salt e bcrypt, porque um vazamento de senhas mal protegidas é exatamente o tipo de incidente que dispara sanções.
• Cifre dados sensíveis em repouso e em trânsito. Entender o que é criptografia — simétrica, assimétrica e hashing é pré-requisito para escolher a proteção certa para cada tipo de dado.
• Controle o acesso aos dados. Aplique o princípio do menor privilégio: cada serviço e cada pessoa acessa apenas o que precisa.
• Proteja as portas de entrada. A maioria dos dados pessoais hoje trafega por APIs; reforçar a segurança de APIs e proteger seus endpoints é parte indissociável da conformidade.

Esses controles dependem de saber separar quem é o usuário de o que ele pode fazer. Por isso, dominar a diferença entre autenticação e autorização é fundamental: um titular acessando os dados de outro por falha de autorização é, simultaneamente, um bug e uma violação da lei.

Um padrão que ajuda a materializar a minimização no código é cifrar dados sensíveis em nível de campo e mascará-los por padrão na borda do sistema. Considere o esqueleto abaixo, em pseudocódigo, de uma camada que decide o que pode ser exposto:

# Mascarar dados pessoais por padrão; expor o valor cheio só com base legal explícita
def serializar_usuario(usuario, contexto):
    saida = {
        "id": usuario.id,
        "nome": usuario.nome,
        # CPF nunca vai inteiro para o cliente sem necessidade real
        "cpf": mascarar(usuario.cpf),  # "***.***.789-00"
    }
    if contexto.tem_base_legal("exibir_cpf_completo"):
        saida["cpf"] = usuario.cpf
    return saida


def mascarar(valor):
    if not valor:
        return None
    return "***.***." + valor[-6:]

A ideia é que o caminho fácil (o default) seja o caminho seguro: expor o dado cru exige uma decisão consciente, não acontece por descuido. Esse mesmo princípio se aplica a logs, mensagens de erro e respostas de API.

Incidentes e notificação

Quando ocorre um incidente de segurança que possa acarretar risco aos titulares, a LGPD exige comunicação à ANPD e aos afetados em prazo razoável. Para o time técnico, isso significa que logs, monitoramento e capacidade de detecção não são opcionais: você precisa saber que houve um vazamento, quais dados foram expostos e quem foi afetado. Um sistema que não consegue responder a essas perguntas não tem como cumprir a obrigação de notificar.

É aqui, mais uma vez, que a conformidade jurídica e a segurança operacional se encontram. A capacidade de detectar e responder a incidentes — funções centrais do framework do NIST (2024) — é o que viabiliza o cumprimento da exigência legal de notificação.

Na prática, prepare-se com antecedência respondendo a três perguntas antes que o incidente aconteça:

1. Como vamos saber? Alarmes em acessos anômalos, monitoramento de exfiltração, alertas de configuração indevida.
2. O que foi exposto? Logs estruturados e um inventário de dados permitem dizer quais campos de quais titulares estavam no escopo do incidente. Sem isso, você é forçado a assumir o pior cenário.
3. Quem precisamos avisar e como? Um runbook com o passo a passo de notificação evita decisões improvisadas sob pressão.

Erros comuns de desenvolvedores

Alguns deslizes aparecem com frequência e valem como checklist:

• Logar dados pessoais sem necessidade. CPF, e-mail e tokens em logs de texto puro são um vazamento esperando para acontecer.
• Enviar dados a terceiros sem base legal. Integrar um analytics ou um chat de suporte significa compartilhar dados; isso precisa estar coberto.
• Guardar dados para sempre. A lei pede que dados sejam eliminados quando a finalidade se encerra. Defina políticas de retenção.
• Confundir anonimização com pseudonimização. Substituir o nome por um ID não anonimiza nada se o mapeamento ainda existe.

Vale acrescentar outros que aparecem em revisões de código:

• Coletar dado sensível por hábito. Pedir gênero, raça ou data de nascimento num cadastro "porque o template tinha" é tratar dado sensível sem finalidade. Se não há uso claro, não colete.
• Mandar dado pessoal para serviços de terceiros sem perceber. Mensagens de erro com payload do usuário enviadas a um agregador de logs externo, ou IPs cheios despachados para uma ferramenta de monitoramento, são compartilhamentos invisíveis.
• Tratar "deletar conta" como flag de status. Marcar um usuário como inativo sem efetivamente eliminar ou anonimizar seus dados não cumpre o direito de eliminação.
• Expor dados de um titular a outro por falha de autorização. É o clássico acesso indevido por ID sequencial (IDOR) — um bug de segurança que, com dados pessoais, é também violação da lei.

Perguntas frequentes

A LGPD se aplica a um projeto pessoal ou um MVP pequeno? Sim. O critério é o tratamento de dados pessoais, não o tamanho do projeto. Há flexibilizações de obrigações para agentes de pequeno porte definidas pela ANPD, mas os princípios continuam valendo desde o primeiro usuário.

Preciso pedir consentimento para tudo? Não. O consentimento é só uma das bases legais, e muitas vezes não é a melhor. Dados necessários para entregar o serviço normalmente se apoiam na execução de contrato; segurança e antifraude costumam caber no legítimo interesse. Forçar consentimento onde outra base se aplica complica sua vida, porque consentimento é revogável.

Logs de servidor com IP são dados pessoais? Em geral, sim, porque o IP é identificável quando combinado com outros registros. Isso não proíbe ter logs — eles têm base legal de segurança —, mas pede política de retenção e acesso restrito.

Dados de empresa (CNPJ, razão social) entram na LGPD? A LGPD protege dados de pessoa natural. Dados puramente de pessoa jurídica não são o foco, mas atenção: o nome e o e-mail do contato dentro daquela empresa são dados pessoais.

Usar um serviço de IA com dados de usuários muda algo? Muda. Enviar dados pessoais para uma API de terceiros é compartilhamento e tratamento. Você precisa de base legal, do contrato adequado com o fornecedor e de cuidado para não vazar dado sensível em prompts.

Conclusão

A LGPD não é um obstáculo ao desenvolvimento — é um conjunto de princípios que, quando incorporados ao design, produzem software mais seguro e confiável. Coletar menos, proteger melhor, saber onde cada dado está e ser capaz de apagá-lo: essas práticas beneficiam a conformidade e a engenharia ao mesmo tempo. O melhor momento para pensar em privacidade é antes de escrever o schema, não depois de receber uma notificação da ANPD. Mapeie suas bases legais, minimize a coleta, registre consentimentos, defina retenção, cifre o que é sensível e tenha um plano de incidente. Trate dados pessoais como o ativo sensível que eles são, e a conformidade deixa de ser um susto para virar uma consequência natural do seu jeito de construir.

Referências

• Brasil (2018). Lei nº 13.709/2018 — Lei Geral de Proteção de Dados Pessoais (LGPD). Diário Oficial da União.
• NIST (2024). The NIST Cybersecurity Framework (CSF) 2.0. NIST.
• ANPD (2023). Guia Orientativo sobre Hipóteses Legais de Tratamento de Dados Pessoais. Autoridade Nacional de Proteção de Dados.