LGPD para times de tecnologia: o que o jurídico não resolve por você

LGPD costuma chegar para o time de engenharia de uma das duas formas: como demanda do jurídico às vésperas de um contrato enterprise, ou como notificação de incidente. Em ambos os casos, a percepção é a mesma — é um problema do time de compliance, não de engenharia.

Essa percepção é cara. A Lei Geral de Proteção de Dados (Lei nº 13.709/2018) tem implicações técnicas concretas que nenhum documento de política interna resolve: dados pessoais em logs, retenção sem critério, ausência de controle de acesso granular, pipelines de dados sem mapeamento de origem. Esses são problemas de arquitetura — e quem tem que resolver é o time de produto.

Este artigo é para CTOs e Heads de Engenharia que querem sair do modo reativo com LGPD e transformar conformidade em decisão de design, não em remediação de última hora.

1. O que a LGPD exige do time de tecnologia — na prática

A LGPD define dado pessoal como qualquer informação que identifique ou possa identificar uma pessoa natural. Nome e CPF são óbvios. Mas endereço de IP, cookie de sessão, geolocalização, identificador de dispositivo e padrão de comportamento de navegação também se enquadram — e esses existem em praticamente todo sistema web em produção.

Os cinco pontos que mais impactam times de engenharia diretamente:

2. Os 5 gaps técnicos mais comuns em times sem política de dados

Em auditorias e diagnósticos de conformidade com times de produto, os mesmos problemas aparecem repetidamente. Não por negligência — mas porque LGPD raramente estava no radar quando o sistema foi desenhado.

Gap 1: dados pessoais em logs de aplicação

Logs são necessários para observabilidade. O problema é quando logs incluem dados pessoais por conveniência de debug — nome completo, e-mail, CPF, número de cartão mascarado de forma insuficiente. Logs têm retenção longa, geralmente vão para sistemas de terceiros (Datadog, Elastic, Grafana Loki) e frequentemente têm acesso mais amplo do que o necessário.

# Problemático — dados pessoais em log
logger.info(f"Usuário {user.name} ({user.email}) realizou login. CPF: {user.cpf}")

# Correto — identificador interno, sem PII
logger.info(f"Login realizado. user_id={user.id} session_id={session.id}")

Gap 2: ausência de mapeamento de dados (ROPA)

O Registro de Operações de Tratamento de Dados (ROPA) é o inventário de onde dados pessoais existem no sistema, por que estão lá, quem tem acesso e por quanto tempo ficam. Sem esse mapeamento, é impossível responder a uma solicitação de titular ou avaliar o impacto de um incidente.

Gap 3: retenção sem política e sem execução

A maioria dos sistemas não deleta dados — arquiva ou desativa. Um usuário que cancela a conta continua existindo no banco de dados, no data warehouse, nos backups e nos logs. LGPD exige que dados sejam deletados quando a finalidade se encerra ou quando o titular solicita — o que requer uma arquitetura de exclusão que muitos sistemas simplesmente não têm.

Gap 4: consentimento sem granularidade ou revogação

Coletar consentimento em um checkbox genérico no cadastro não é consentimento válido para LGPD. O consentimento precisa ser específico por finalidade, livre (sem coerção), informado e revogável a qualquer momento com a mesma facilidade com que foi dado. Isso exige uma camada de gerenciamento de consentimento no produto — não só no texto de política.

Gap 5: acesso não controlado a dados pessoais internamente

Em times pequenos é comum que todos os desenvolvedores tenham acesso ao banco de produção. Para LGPD, acesso a dados pessoais precisa ser controlado por princípio do menor privilégio — quem processa o dado acessa apenas o necessário, e todo acesso é auditável.

3. Mapeamento de dados pessoais: por onde começar

O primeiro passo não é tecnológico — é de descoberta. O time precisa responder: onde existem dados pessoais no nosso sistema?

A resposta raramente é óbvia. Dados pessoais existem no banco relacional principal, mas também em filas de mensagens, em eventos de analytics, em cache Redis, em arquivos de export, em logs de aplicação, em tabelas de auditoria e em backups. Cada um desses é um ponto de risco.

-- Levantamento inicial: tabelas com campos potencialmente PII
SELECT
    table_name,
    column_name,
    data_type
FROM information_schema.columns
WHERE table_schema = 'public'
  AND column_name ILIKE ANY(ARRAY[
    '%email%', '%cpf%', '%telefone%', '%phone%',
    '%nome%', '%name%', '%endereco%', '%address%',
    '%ip%', '%document%', '%birth%', '%nascimento%'
  ])
ORDER BY table_name, column_name;

Para cada dado identificado, documente:

4. Direitos dos titulares: implementação técnica

Direitos dos titulares não são promessas de política interna — são funcionalidades que o sistema precisa suportar. Cada direito tem implicações de implementação específicas.

Direito de acesso e portabilidade

O titular pode solicitar quais dados o sistema possui sobre ele e recebê-los em formato estruturado e interoperável. A implementação mais direta é um endpoint autenticado que agrega e retorna todos os dados do usuário.

# Endpoint de exportação de dados do titular
GET /api/v1/users/me/data-export

# Response
{
  "exported_at": "2026-07-31T10:00:00Z",
  "profile": { "name": "...", "email": "...", "created_at": "..." },
  "activity": [...],
  "preferences": {...},
  "consents": [
    { "purpose": "marketing", "granted_at": "...", "status": "active" },
    { "purpose": "analytics", "granted_at": "...", "status": "revoked" }
  ]
}

Direito de exclusão

O direito mais complexo tecnicamente. "Excluir" não pode ser só marcar um registro como deletado — precisa propagar para backups, logs, data warehouse, filas de eventos e integrações de terceiros.

Revogação de consentimento

A revogação precisa ter o mesmo fluxo simples que o consentimento original. E precisa ser propagada para todos os sistemas que usam esse dado — não só registrada num campo de banco.

5. Privacy by Design: como isso se traduz em decisões de arquitetura

Privacy by Design é o princípio de que privacidade não é adicionada depois — é considerada desde o design inicial. Para times de produto, isso significa quatro mudanças concretas no processo de desenvolvimento:

1. Coleta mínima como padrão de design. Na definição de qualquer feature que envolva coleta de dados, a pergunta padrão é: qual é o mínimo de dado necessário para esta funcionalidade? Esse questionamento elimina a maioria dos dados desnecessários antes mesmo de existirem no sistema.

2. Criptografia em repouso como padrão, não como opcional. Dados pessoais em banco de dados devem ser criptografados em repouso. Campos especialmente sensíveis (CPF, dados financeiros, dados de saúde) devem ter criptografia em nível de coluna.

3. Logs sem PII como regra de linting. Estabelecer uma regra de lint ou hook de pré-commit que detecta padrões de PII em mensagens de log antes do merge.

4. DPIA para features de alto risco. Data Protection Impact Assessment obrigatório para sistemas de decisão automatizada, monitoramento em larga escala ou processamento de dados sensíveis.

6. Incidente de dados: o que o time precisa ter pronto

LGPD exige que a ANPD e os titulares sejam notificados sobre incidentes de segurança que possam acarretar risco ou dano. O prazo orientado pela ANPD é de 72 horas após o conhecimento do incidente para notificação preliminar.

72 horas é pouco tempo para um time que não tem processo. O que precisa estar pronto antes do incidente acontecer:

• Runbook de resposta a incidente de dados — quem é acionado, qual é o fluxo de decisão, quando aciona o jurídico, como se avalia o risco para os titulares afetados.
• Inventário de dados atualizado — sem o ROPA, é impossível saber quais titulares foram afetados e qual dado vazou.
• Logs de acesso auditáveis — para reconstruir o que aconteceu e quando. Logs sem PII, mas com identificadores de sessão e ação.
• Lista de integrações e suboperadores — se dados foram compartilhados com terceiros, eles precisam ser notificados. Saber quem são rapidamente é crítico.