LGPD completa oito anos e, sinceramente, o que mais me impressiona é a distância entre o discurso corporativo de “compliance” e o que efetivamente roda em produção. Já vi sistemas onde o time de segurança jurava que estava tudo em conformidade enquanto os logs do backend despejavam CPF e e-mail em texto puro para o CloudWatch. Nesta análise direto ao ponto, quero mostrar o que a Lei nº 13.709/2018 mudou de verdade para quem escreve código — e o que ainda continua errado na maioria dos repositórios que eu revisito como consultor.
Segundo o Olhar Digital, a entidade completou aniversário nesta sexta-feira (14) com um diagnóstico interessante: muitas empresas trataram a LGPD como projeto jurídico nos primeiros anos, e só agora começam a integrar proteção de dados em decisões de tecnologia. Concordo com Carlos Lima, do Failla Lima Riva Advogados, quando ele diz que “já não basta ter um programa de privacidade; é preciso demonstrar que ele funciona”. No código, isso significa evidências técnicas — não PDFs bonitos armazenados no SharePoint.
O que a LGPD realmente obriga um desenvolvedor a fazer
Quando comecei a implementar LGPD em sistemas reais, percebi que a maioria dos devs pensa em três coisas apenas: cookie banner, política de privacidade e DPO. Erro. A lei toca em camadas profundas do software:
- Coleta mínima: pedir só o necessário (princípio da necessidade, art. 6º, III).
- Finalidade explícita: cada campo de formulário precisa ter um propósito documentado, não inferido.
- Transparência no fluxo: o titular tem direito de saber para onde os dados vão, inclusive subcontratados.
- Segurança desde o design (privacy by design): pseudonimização, criptografia, controle de acesso granular.
- Direitos do titular: acesso, correção, eliminação, portabilidade, revogação de consentimento — todos implementáveis via API.
Privacy by Design não é slogan de PPT
Na minha experiência, o erro mais caro é tratar LGPD como checklist de formulário. Privacy by Design significa escolher antes de escrever a primeira linha de código: esse campo vai para o banco? Vai para o Redis? Vai virar log? Se você não respondeu isso na sprint de modelagem, vai responder mais tarde em formato de auto de infração. A ANPD já multou empresas por manter dados antigos além do prazo, e isso geralmente vem de bancos que ninguém lembra que existem — backups esquecidos, tabelas de auditoria que ninguém limpa, filas de mensagens com retenção eterna.
Na prática: três implementações que vão mudar sua forma de codar
1. Máscara de dados sensíveis antes de logar
Esse é o erro clássico. Você usa console.log(user), logger.info(req.body) ou print(request.data) e acabou de vazar CPF, e-mail e token de cartão para o Datadog, Sentry ou CloudWatch. Crie um wrapper de log que aplica máscara antes de serializar:
// logger.js
const SENSITIVE_FIELDS = ['cpf', 'cnpj', 'email', 'password', 'cardNumber', 'cvv', 'token'];
function maskSensitive(data) {
if (data === null || typeof data !== 'object') return data;
const masked = Array.isArray(data) ? [] : {};
for (const key of Object.keys(data)) {
const lowerKey = key.toLowerCase();
if (SENSITIVE_FIELDS.some(field => lowerKey.includes(field))) {
masked[key] = '***REDACTED***';
} else {
masked[key] = maskSensitive(data[key]);
}
}
return masked;
}
const logger = {
info: (msg, meta = {}) => {
console.log(JSON.stringify({
level: 'info',
msg,
meta: maskSensitive(meta),
timestamp: new Date().toISOString()
}));
},
error: (msg, meta = {}) => {
console.error(JSON.stringify({
level: 'error',
msg,
meta: maskSensitive(meta),
timestamp: new Date().toISOString()
}));
}
};
module.exports = logger;
Quando uso isso em produção, removo cerca de 90% dos vazamentos que vejo em logs. O resto vem de exceções serializadas — bibliotecas que jogam o objeto inteiro no stack trace. Para esses casos, configure o Sentry com beforeSend para aplicar a mesma máscara.
2. Endpoint de exclusão de dados (direito ao esquecimento)
O titular pode pedir a eliminação dos dados “desnecessários, excessivos ou tratados em desconformidade”. Seu sistema precisa responder a isso em até 15 dias. Implemente um serviço de anonimização que preserva integridade referencial:
# gdpr_service.py
import hashlib
from datetime import datetime
class DataErasureService:
ANONYMIZED_VALUE = "ANONIMIZADO"
def __init__(self, db, audit_log):
self.db = db
self.audit_log = audit_log
def erase_user(self, user_id: int, request_id: str) -> dict:
user = self.db.users.find_by_id(user_id)
if not user:
raise UserNotFound(user_id)
# Campos que devem ser anonimizados
pii_fields = ['name', 'email', 'phone', 'cpf', 'address', 'birthdate']
# Campos que precisamos manter por obrigação legal (art. 16)
preserved = {
'id': user.id,
'created_at': user.created_at,
'erased_at': datetime.utcnow(),
'erasure_request_id': request_id
}
update_payload = {field: self.ANONYMIZED_VALUE for field in pii_fields}
update_payload.update(preserved)
self.db.users.update(user_id, update_payload)
# Mantém registro da operação para auditoria (sem dados pessoais)
self.audit_log.record({
'event': 'DATA_ERASURE',
'user_id': user_id,
'request_id': request_id,
'executed_at': datetime.utcnow(),
'fields_affected': pii_fields
})
return {
'status': 'success',
'user_id': user_id,
'fields_anonymized': pii_fields,
'preserved_for_legal_obligation': list(preserved.keys())
}
Esse padrão me economizou horas de discussão com clientes. A chave é diferenciar “deletar” de “anonimizar”. Você não apaga tudo — você remove a possibilidade de associar os dados à pessoa, mas mantém integridade contábil e fiscal conforme o art. 16 da LGPD.
3. Consentimento granular versionado
Esqueça aquele checkbox único no rodapé do formulário. A ANPD exige que o consentimento seja específico, informado e granular. Cada finalidade pede seu próprio aceite, e você precisa guardar a versão exata do texto que o usuário viu:
-- Schema sugerido para auditoria de consentimento
CREATE TABLE consent_records (
id BIGSERIAL PRIMARY KEY,
user_id BIGINT NOT NULL,
purpose VARCHAR(100) NOT NULL, -- 'marketing_email', 'analytics', 'data_sharing'
granted BOOLEAN NOT NULL,
consent_text_version VARCHAR(20) NOT NULL, -- 'v1.2-2024-08'
consent_text_hash CHAR(64) NOT NULL, -- SHA256 do texto exato
ip_address INET,
user_agent TEXT,
granted_at TIMESTAMPTZ DEFAULT NOW(),
revoked_at TIMESTAMPTZ NULL
);
CREATE INDEX idx_consent_user_purpose ON consent_records(user_id, purpose);
CREATE INDEX idx_consent_active ON consent_records(user_id, purpose) WHERE revoked_at IS NULL;
Quando o usuário revoga, você não apaga o registro — marca revoked_at. Isso te dá trilha de auditoria e proteção contra questionamentos futuros.
Erros comuns que devs cometem em projetos “em conformidade”
Erro 1: Achar que bcrypt resolve tudo
Criptografia de senha é uma camada. LGPD fala de todos os dados pessoais: nome, e-mail, endereço, IP, geolocalização, preferências. Você precisa criptografar em repouso (AES-256 no banco), em trânsito (TLS 1.3) e, idealmente, aplicar criptografia homomórfica ou tokenização para campos que precisam ser consultados sem expor o valor real.
Erro 2: Coletar dados “porque pode ser útil depois”
Já vi formulários pedindo estado civil, profissão da mãe e nome do animal de estimação “para enriquecer perfil”. Isso é exatamente o oposto do princípio da necessidade. Cada campo a mais é vetor de ataque, custo de storage e responsabilidade legal. Na dúvida, não colete.
Erro 3: Não documentar o fluxo de dados (ROP)
O Registro de Operações de Tratamento (art. 37) é obrigatório para muitas empresas. Como dev, você pode gerar isso automaticamente instrumentando o código com OpenTelemetry ou middleware que registra cada leitura/escrita de campo sensível. Já fiz deploy disso e a área de compliance chorou de alegria — pela primeira vez tinham um inventário vivo, não uma planilha estática desatualizada.
Erro 4: Compartilhar com terceiros sem contrato e sem cláusula de proteção
Se você envia dados para AWS, Google Analytics, Hotjar, RD Station, Intercom e mais cinco SaaS, cada um deles é um operador (art. 5º, VI). Você precisa de contrato com cláusula de proteção de dados, DPA assinado, e configuração técnica que limite o que eles veem. Analytics sem anonimização de IP é um clássico.
Erro 5: Ignorar a IA que está treinando com seus dados
Esse ponto merece destaque. Muitos times estão alimentando bases inteiras em LLMs sem filtrar PII. Se você usa OpenAI, Anthropic ou um modelo on-premise, implemente um gateway que detecta e mascara dados pessoais antes de enviar. Bibliotecas como Microsoft Presidio fazem isso bem.
# Presidio gateway
from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine
analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()
def sanitize_for_llm(text: str) -> str:
results = analyzer.analyze(text=text, language='pt')
anonymized = anonymizer.anonymize(text=text, analyzer_results=results)
return anonymized.text
# Exemplo de uso
user_input = "Meu CPF é 123.456.789-00 e moro na Rua das Flores, 123"
safe_input = sanitize_for_llm(user_input)
# Resultado: "Meu CPF é <CPF> e moro na <LOCATION>, <LOCATION>"
TSE, deepfakes e o novo campo de batalha da LGPD
A pauta do TSE sobre deepfakes discutida recentemente também passa pela LGPD. Quando um vídeo sintético é criado para difamação, há tratamento de dados biométricos (imagem, voz) sem consentimento. Isso é infração grave. Para quem desenvolve com biometria facial, autenticação por voz ou sistemas de verificação de identidade, é hora de revisar se o consentimento de uso biométrico cobre o contexto de treinamento de modelos generativos — geralmente não cobre.
LGPD na stack de IA: o que ainda vai mudar
A ANPD publicou entendimentos sobre IA e está construindo regulação específica. O que já está claro: treinar modelo com dados pessoais sem base legal válida é infração. As três bases mais usadas no Brasil são:
- Consentimento — o mais frágil, precisa ser específico e revogável.
- Legítimo interesse — exige teste de balanceamento documentado.
- Execução de contrato — só se aplica se o dado for essencial ao serviço contratado.
Quando uso essas bases em produção, sempre documento em qual categoria cada dataset se encaixa. Para datasets de treinamento de modelo, legítimo interesse raramente sobrevive ao teste — a tendência é exigir consentimento explícito ou dado anonimizado.
FAQ — Perguntas que devs realmente fazem
Preciso ter DPO se sou uma startup pequena?
A lei exige encarregado (não necessariamente um DPO certificado) para a maioria dos controladores. Pode ser alguém do próprio time, desde que tenha conhecimento sobre a lei e acesso ao canal de comunicação com a ANPD. Em startups que assessoro, normalmente o CTO acumula — mas isso só funciona até certo porte.
Como sei se minha retenção de dados está correta?
Mapeie cada tabela e arquivo. Para cada campo pessoal, defina prazo de retenção baseado na finalidade. Conta de usuário sem atividade há 5 anos? Anonimize. Logs de auditoria? Mantenha por 6 anos (SOX/receita federal). Carrinho abandonado? 90 dias no máximo. Sem prazo documentado, você está retendo por tempo indefinido — infração.
Multa da ANPD é mesmo aplicada?
Sim. A ANPD já aplicou sanções administrativas desde agosto de 2021 — incluindo advertências, multas e bloqueio de banco de dados. O valor pode chegar a 2% do faturamento do grupo, limitada a R$ 50 milhões por infração. Pequenas empresas têm sanções proporcionais, mas isso não significa impunidade.
Anonimização e pseudonimização são a mesma coisa?
Não. Anonimização remove qualquer possibilidade de reversão — dado anonimizado sai do escopo da LGPD. Pseudonimização substitui o identificador direto por um indireto (hash, token), mas ainda permite re-identificação com chave adicional. A LGPD incentiva pseudonimização como medida de segurança, mas dado pseudonimizado continua sendo dado pessoal.
Stacktrace com dado pessoal pode virar processo?
Sim. Se um stacktrace com CPF, e-mail ou token vaza para Sentry, Datadog, Slack ou GitHub Issues (público), há vazamento de dados pessoais. Implemente filtros beforeSend, scrubber de logs e nunca cole stacktrace em issue pública sem sanitizar.
Oito anos depois, o que falta
A LGPD amadureceu o mercado jurídico, mas o mercado técnico ainda engatinha. Vejo com frequência: cookies sem banner funcional, formulários pedindo dados demais, logs despejando tudo, integrações com SaaS sem DPA, IA treinando com base inteira de clientes. O divisor de águas que o advogado mencionou existe — e passa por quem escreve código. Mais do que nunca, privacidade é responsabilidade de engenharia, não só do jurídico.
Se você chegou até aqui, considere revisar três coisas esta semana: seus logs (existe dado pessoal ali?), seus formulários (cada campo é necessário?) e seus contratos com terceiros (todos têm cláusula de proteção de dados?). Se encontrar problema, parabéns — encontrou antes da ANPD.
Referências: reportagem do Olhar Digital sobre o aniversário da LGPD; Lei nº 13.709/2018; comunicados da ANPD sobre sanções administrativas e IA.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.