LGPD-GDPR (Proteção de Dados)

A LGPD, Lei Geral de Proteção de Dados, e o GDPR, General Data Protection Regulation europeu, são as leis de proteção de dados pessoais que definem as regras de tratamento em Brasil e União Europeia, com forte influência mútua e desenho muito parecido. Para arquitetura de produção, elas deixam de ser tema de jurídico no momento em que determinam localidade de dados, retenção, máscara em logs, exclusão em sistemas distribuídos e fluxos de portabilidade. O descumprimento gera sanções financeiras relevantes e, pior para operação, bloqueio de tratamento de dados, que é funcionalmente uma parada do negócio. Cumprir exige que o sistema saiba que dados pessoais tem, onde estão, por quanto tempo ficam e como apagá-los, e essas perguntas têm resposta arquitetural, não jurídica. Este arquivo cobre bases legais, princípios, direitos do titular, dados em logs e backups, anonimização, localidade, incidentes e as implicações práticas para quem desenha o sistema.

Conceito e escopo das leis

Dado pessoal é qualquer informação relacionada a pessoa natural identificada ou identificável, direta ou indiretamente, o que inclui nome, CPF, endereço IP, identificador de dispositivo e geolocalização. Dado pessoal sensível é a categoria especial com proteção reforçada, cobrindo origem racial, convicção religiosa, opinião política, saúde, biometria e dados genéticos. As duas leis se aplicam a qualquer organização que trate dados de titulares em seu território, com extraterritorialidade clara no GDPR e abrangência ampla na LGPD para operações com dados coletados no Brasil. Dado anonimizado, quando irreversível, fica fora do escopo; dado pseudonimizado, que pode ser reversível com chave ou tabela auxiliar, continua sendo dado pessoal e permanece no escopo.

As diferenças existem, mas o desenho arquitetural que atende o GDPR atende a LGPD na prática, porque as exigências de fundo, finalidade, minimização, direitos do titular e responsabilidade, são as mesmas. Sistemas multirregionais precisam apenas mapear as variações de prazo e de agência no plano de resposta a incidente.

Um detalhe de vocabulário define responsabilidades: o controlador decide as finalidades e os meios do tratamento, e o operador trata dados em nome do controlador, sob suas instruções. SaaS, fornecedores de observabilidade e processadores de pagamento atuam como operadores, com contrato que define escopo, segurança e subcontratação. A cadeia de operadores precisa ser mapeada, porque a responsabilidade de informar e notificar permanece do controlador, mesmo quando a falha foi do fornecedor.

Bases legais para tratamento

Todo tratamento de dados pessoais precisa de uma base legal, e a existência dessa base define o que o sistema pode fazer com o dado. As bases da LGPD incluem consentimento, execução de contrato, cumprimento de obrigação legal ou regulatória, proteção da vida, tutela da saúde, legítimo interesse, crédito e cumprimento de políticas públicas. A escolha é decisão de negócio com consequência técnica: consentimento precisa ser granular, registrável e revogável, o que exige trilha por titular e desligamento funcional por finalidade; legítimo interesse exige documentação de teste de equilíbrio, o que exige inventário de finalidades por fluxo.

A base legal mais comum em produto digital é a execução de contrato, porque cobre o tratamento necessário para entregar o serviço comprado. O erro clássico é usar consentimento como base para tudo, porque consentimento criado assim é inválido, já que o usuário não pode recusar e continuar usando o serviço essencial. A consequência arquitetural direta é a modelagem de finalidades como entidade de primeira classe, com cada campo de dado pessoal associado a uma finalidade e a uma base legal.

A revogação de consentimento merece desenho próprio, porque precisa ter efeito prático imediato. A implementação usual é uma tabela de consentimentos por titular e finalidade, consultada no caminho de tratamento, com cache de leitura e invalidação rápida; revogar muda o registro e o pipeline cessa o tratamento na próxima verificação. O histórico de concessão e revogação precisa ser auditável, porque prova do consentimento é requisito do controlador, e consentimento que não pode ser provado não vale como base.

Princípios de minimização e finalidade

Os princípios operacionais que mais afetam arquitetura são finalidade, adequação, necessidade e livre acesso. Finalidade limita o dado ao objetivo declarado, e uso secundário exige nova base; necessidade, o princípio da minimização, manda coletar o mínimo necessário; livre acesso garante ao titular informação clara sobre o tratamento. A minimização muda decisões concretas: o formulário não pede CPF sem justificativa documentada, o log não grava o payload completo, o ambiente de teste não recebe cópia integral de produção. Quem desenha o pipeline decide o que entra, e minimizar na entrada é mais barato que limpar depois.

Retenção é a materialização temporal da minimização. Cada categoria de dado pessoal precisa de prazo de retenção definido e de mecanismo de expiração executado pelo sistema, seja TTL em tabela, política de ciclo de vida em objeto ou job de purga. Dado sem dono de negócio e sem prazo de retenção é passivo de risco acumulado, e esse inventário é justamente o que auditorias pedem primeiro.

Direitos do titular e implicações arquiteturais

Os direitos do titular transformam requisitos de privacidade em requisitos de API, e cada um deles tem custo arquitetural que precisa estar previsto desde o desenho.

O direito que mais doerá arquiteturalmente é a exclusão, porque sistemas distribuídos copiam dados por design. Caches, índices de busca, warehouses, filas com retenção longa e snapshots de banco são todos alvos da exclusão, e a ausência de um deles já é descumprimento. A resposta madura é manter um mapa de dados pessoais, o rota de dados, com todos os stores onde o titular pode existir, e um processo orquestrado de exclusão que percorre esse mapa e registra o resultado por titular.

A portabilidade revela um requisito menos visível: a exportação precisa cobrir não só a API principal, mas o dado derivado, como histórico de interações e preferências aprendidas. Sistemas que não sabem enumerar os dados de um titular descobrem a lacuna justamente quando recebem a primeira solicitação, com prazo correndo. O endpoint de exportação deve ser tratado como requisito de produto, com formato definido, rate limit e autorização reforçada, porque resposta completa só existe com inventário confiável por trás.

Dados pessoais em logs, backups e ambientes de teste

Logs são o vazamento mais frequente de dados pessoais em produção, porque escrevem payloads inteiros, tokens e cabeçalhos sem que ninguém perceba. A prática sólida é estruturar logs com esquema definido, proibir campos sensíveis por política e aplicar redação na camada de logging, e não na inspeção posterior. A redação precisa cobrir também correlação legítima, substituindo identificadores diretos por pseudônimos estáveis, que permitem rastrear a sessão sem expor o titular. Logs com retenção longa herdam o problema: cada dia adicional de retenção amplia o acervo de dados pessoais sem finalidade.

Backups contêm dados pessoais e são alvo do direito de exclusão, o que gera o conflito conhecido entre backup imutável e direito ao esquecimento. O tratado prático é registrar a exclusão em um registro permanente, o registro de exclusões, e reaplicar as exclusões sobre qualquer backup restaurado, além de encurtar a retenção de backups com dado pessoal completo. Ambientes de teste devem receber dado sintético ou anonimizado, porque a conveniência da cópia de produção cria exposição real em ambiente com controle de acesso mais fraco, e isso é achado clássico de auditoria e de incidente.

A política de logging abaixo materializa o controle no ponto de escrita, onde é executável e verificável, e serve como contrato entre produto, engenharia e o encarregado.

# Política de redação aplicada na camada de logging
version: 1
campos_proibidos:                # Nunca entram no log, em hipótese alguma
  - cpf
  - cartao_numero
  - senha
  - token_acesso
substituicoes:                   # Pseudônimos estáveis para correlação
  email: "{{hash_sha256_com_sal}}"
  telefone: "{{hash_sha256_com_sal}}"
tratamento_padrao:
  payload_completo: false        # Proibido logar payload inteiro
  nivel_erro: mensagem_e_stack   # Sem variáveis locais e sem corpo de request
  retencao_dias: 30              # Retenção curta por padrão, ampliada caso a caso

A verificação de aderência à política entra na esteira de CI, com linter de logs que reprova código registrando campo proibido. Controle que depende de review manual de cada linha de log não escala, e o linter converte política em gate objetivo.

Anonimização e pseudonimização

Anonimização é o processo irreversível que elimina a possibilidade de identificação, inclusive com uso de meios razoáveis pelo controlador, e dado anonimizado sai do escopo da lei. Pseudonimização substitui identificadores diretos por pseudônimos, mantendo reversibilidade com chave ou tabela auxiliar, e por isso o dado permanece pessoal, apenas com proteção reforçada. A distinção é jurídica e técnica: k-anonimato, agregação e generalização aproximam dados de anonimização, enquanto hash sem sal, que permite dicionário e força bruta, não é anonimização de forma alguma.

O uso arquitetural correto é em camadas. Pseudonimização protege o uso analítico e a correlação interna, com chave guardada em serviço separado, e é a técnica padrão para ambientes de teste e data lake. Anonimização, quando tecnicamente honesta, viabiliza analytics sem controles adicionais, mas exige avaliação de reidentificação por combinação de campos, pois zip code, data de nascimento e gênero, juntos, identificam pessoas reais em bases de população.

A escolha da técnica por camada precisa estar registrada no mapa de dados, porque a mesma informação pode ser pessoal na aplicação, pseudônima no data lake e anônima no relatório executivo. Cada transição é um pipeline, e cada pipeline é ponto de controle: quem executa a pseudonimização tem acesso à chave, quem acessa a chave consegue reidentificar, e esse acesso deve ser restrito e auditado com a mesma seriedade do acesso ao dado original.

Localidade de dados e transferência internacional

O GDPR restringe transferência de dados pessoais para fora do Espaço Econômico Europeu, admitindo quando o destino tem decisão de adequação ou quando existem garantias apropriadas, tipicamente cláusulas contratuais padrão, as SCCs. A LGPD regula transferência internacional com mecanismo análogo, hoje sob regulação da ANPD, e o desenho muda pouco: dados europeus tratados na Europa, dados brasileiros sob análise de garantia quando saem do país. A consequência arquitetural é a pinagem de região, com partição de dados por residência e processamento local, o que interfere em topologias multirregionais, replicação global de banco e cache de CDN.

O detalhe incômodo é que ferramentas cotidianas violam localidade sem que ninguém perceba: observabilidade que replica logs para SaaS global, helpdesk com base de clientes no exterior, analytics com eventos contendo identificadores. O mapeamento de fluxos de dado pessoal, incluindo fornecedores, é requisito das duas leis, e a revisão de contratos desses fornecedores com cláusulas de tratamento é parte do desenho, não papelada acessória.

Em topologias multirregionais, a partição por residência costuma vencer a replicação global: o banco europeu serve usuários europeus, o banco brasileiro serve os brasileiros, e a camada de roteamento decide por geolocalização no ingresso. Réplica global e replicação cross-region de dados pessoais exigem avaliação legal por fluxo, e o padrão conservador é replicar apenas dado pseudônimo ou agregado entre regiões, mantendo o dado pessoal identificado na região de origem.

Direito ao esquecimento em event sourcing e backups

Event sourcing guarda a história completa de eventos imutáveis, e o direito de exclusão entra em conflito direto com a imutabilidade. As soluções conhecidas são a cripto-fragmentação, o crypto-shredding, em que os campos sensíveis de cada evento são cifrados com chave por titular, e a exclusão efetiva se dá pela destruição da chave; o evento permanece, mas o conteúdo se torna ilegível para sempre. A alternativa é o tombstone com compactação, onde o evento de exclusão sinaliza a remoção no reprocessamento, exigindo que todos os consumidores respeitem a marca. A escolha depende de quão profundo o dado pessoal está no modelo de eventos, e a decisão precisa ser tomada antes do primeiro evento ser escrito.

Em pipelines de processamento, o risco é a recriação de dados apagados a partir de fontes antigas: replay de tópico, reprocessamento de data lake e restauração de snapshot recriam o titular excluído. O registro permanente de exclusões por titular precisa ser consultado por qualquer processo que reconstrua estado, e a verificação periódica de ausência de titulares excluídos nos derivados é o controle de fechamento.

Em Kafka, a combinação usual é tópico com compactação, evento tombstone por exclusão e políticas de retenção curtas para tópicos com dado pessoal; o reprocessamento consulta o registro de exclusões e descarta eventos do titular removido. A chave do desenho é a unicidade do identificador do titular em todos os tópicos e stores, porque exclusão por identificador inconsistente deixa fragmentos, e fragmentos de dado pessoal são exatamente o que a solicitação pretendia eliminar.

Violação de dados e notificação

Violação de dados pessoais é o acesso, perda, alteração ou divulgação não autorizada, e o prazo é o elemento que transforma plano de papel em requisito de engenharia: o GDPR exige notificação à autoridade em até 72 horas, quando há risco aos titulares, e comunicação aos titulares quando o risco for alto; a LGPD exige comunicação à ANPD e aos titulares em prazo razoável, definido em regulamento. Responder em 72 horas exige ter, antes do incidente, inventário de dados, trilha de acesso, plano de resposta testado e plantão que funcione. A avaliação de risco ao titular, o que define a notificação, é responsabilidade do controlador e precisa de procedimento documentado.

A detecção depende de observabilidade de segurança: alertas de acesso anômalo, exportação em massa, privilégio elevado fora de padrão. Um incidente descoberto pelo titular, pela imprensa ou por notificação de terceiro é o pior cenário possível, porque destrói a credibilidade do prazo de 72 horas e a confiança no controlador.

A resposta ao incidente pede também disciplina forense: preservar logs e trilhas antes da limpeza por retenção, documentar linha do tempo com hora e fonte, e estimar alcance por titular para sustentar a avaliação de risco. O relatório final do incidente alimenta o inventário de dados e o DPIA, fechando o ciclo entre resposta técnica e conformidade documental.

Inventário documental e provas de conformidade

A conformidade demonstrável se apoia em um conjunto documental definido: o registro das operações de tratamento, a lista de atividades com finalidade e base legal, os contratos de operador, as avaliações de impacto e os registros de violações e respostas. Nenhum desses itens é opcional em auditoria, e todos derivam de informação que a arquitetura já produz, como diagramas, catálogos de dado e configurações de retenção. O esforço real de compliance é baixo quando esses artefatos existem como subproduto do desenho, e alto quando precisam ser reconstruídos sob prazo.

DPO e relatório de impacto

O encarregado, DPO ou Data Protection Officer, é o ponto de contato entre organização, titulares e autoridade, e atua como ponte entre jurídico e engenharia nas decisões que envolvem dado pessoal. Em times maduros, o DPO participa de design review de funcionalidades que tocam dado pessoal, o que antecipa problemas que custariam refatoração depois. O relatório de impacto, RIPD na LGPD e DPIA no GDPR, é obrigatório para tratamento de alto risco, como larga escala, dados sensíveis, monitoramento sistemático e decisões automatizadas com efeito significativo, e documenta risco, necessidade, medidas de mitigação e salvaguardas.

Para a arquitetura, o DPIA é uma oportunidade, porque exige exatamente o material que um sistema bem desenhado já produz: diagrama de fluxo de dados, inventário de stores, política de retenção e controles de acesso. Preparar o relatório é resposta a perguntas que já deveriam ter respostas documentadas, e time que mantém esse material vivo reduz o esforço de compliance a atualização, não a levantamento.

Erros comuns

• Coletar tudo por segurança, violando minimização: dado não coletado não precisa de base legal, retenção, exclusão nem proteção.
• Usar consentimento como base universal: consentimento inválido contamina todo o tratamento derivado dele.
• Gravar payload completo em logs: o log vira base de dados pessoais sem finalidade e sem retenção definida.
• Copiar produção para ambiente de teste: exposição de dado real em ambiente de controle mais fraco é achado clássico.
• Tratar pseudonimização como anonimização: hash reversível ou sem sal mantém o dado no escopo da lei.
• Ignorar caches, índices e derivados na exclusão: o titular some da API principal e continua vivo em cinco lugares.
• Descobrir o fluxo de dado pessoal no dia do incidente: sem mapa e sem trilha, o prazo de notificação não é cumprido.

Boas práticas

• Manter um mapa vivo de dados pessoais, com finalidade, base legal, local de armazenamento e prazo de retenção por categoria.
• Modelar finalidade e consentimento como entidades do sistema, com trilha auditável e corte funcional por finalidade na revogação.
• Aplicar redação na camada de logging, com pseudônimos estáveis para correlação, e política explícita de campos proibidos.
• Implementar exclusão orquestrada que percorre todos os stores, incluindo caches e índices, com registro permanente por titular.
• Usar crypto-shredding quando dado pessoal estiver dentro de eventos imutáveis, planejando as chaves por titular desde o início.
• Fixar dados por região quando a localidade for requisito, revisando fornecedores de observabilidade e suporte no mesmo critério.
• Produzir DPIA e RIPD com material que a engenharia já mantém, integrando o relatório ao processo de design, não a um documento paralelo.