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:

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:

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:

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:

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:

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:

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.

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:

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:

Erros comuns de desenvolvedores

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

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

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