Tem um momento na vida de toda software house brasileira que dá certo: o primeiro cliente europeu. Um SaaS que decola, uma fintech que expande, uma startup que capta lá fora. E junto com o contrato chega um anexo de trinta páginas em inglês jurídico pedindo “GDPR compliance” — e a pergunta silenciosa do time de engenharia: o que exatamente eu preciso construir?
Este post é a resposta técnica. Não é palestra de advogado nem checklist genérico de blog. É o que um time de engenharia no Brasil, que já convive com a LGPD e agora atende a União Europeia, precisa entregar em código e infraestrutura para os dois regulamentos ao mesmo tempo. A boa notícia: LGPD e GDPR são primos próximos, e quem constrói para um cobre quase tudo do outro. A má notícia: “quase” é onde moram os prazos, as bases legais e as multas.
LGPD e GDPR: o que muda para engenharia
LGPD e GDPR são leis de proteção de dados pessoais que exigem base legal para tratar dado, direitos garantidos ao titular e responsabilização documentada de quem processa. A LGPD (Lei 13.709/2018) foi escrita espelhando o GDPR europeu — os princípios são praticamente os mesmos.
Para engenharia, isso é uma vantagem enorme: você não implementa dois sistemas. Você implementa um conjunto de controles que satisfaz ambos, e ajusta parâmetros (prazos, bases, regras de transferência) por jurisdição. O texto da LGPD está no portal do Planalto; o do GDPR, em gdpr.eu. Ler os artigos que viram requisito — e não só resumos — evita retrabalho caro.
As diferenças que realmente exigem código
A maior parte do texto é convergente. O que diverge e vira tarefa concreta:
- Bases legais. GDPR (Art. 6) e LGPD (Art. 7) listam hipóteses parecidas, mas não idênticas. Seu sistema precisa registrar qual base sustenta cada tratamento — consentimento, execução de contrato, legítimo interesse. Sem esse campo, você não consegue defender a coleta.
- Prazos de resposta ao titular. O GDPR pede resposta em até um mês. A LGPD tem prazos próprios por tipo de pedido. Seu fluxo de atendimento precisa de SLA e cronômetro.
- Transferência internacional. É aqui que o cliente europeu mais aperta. Mandar dado de um titular da UE para um servidor no Brasil é transferência internacional — e precisa de salvaguarda válida (Art. 33 da LGPD).
Entregável 1: RoPA técnico (o mapa de dados)
Antes de qualquer controle, você precisa saber onde os dados pessoais estão. O RoPA (Records of Processing Activities), exigido pelo Art. 30 do GDPR e pelo Art. 37 da LGPD, costuma virar uma planilha jurídica esquecida. A versão que serve para engenharia é um inventário vivo, por sistema.
Um RoPA técnico responde, para cada base de dados e serviço:
| Campo | Exemplo |
|---|---|
| Que dado pessoal existe aqui | e-mail, CPF, geolocalização, IP |
| Categoria | comum, sensível (Art. 11 LGPD / Art. 9 GDPR) |
| Base legal | consentimento, contrato, legítimo interesse |
| Onde reside | Postgres users, S3 uploads, log do provedor X |
| Retenção | 24 meses após inatividade |
| Com quem é compartilhado | Stripe, provedor de e-mail, BI |
| Transfere para fora do país? | sim — servidor US-East |
Esse mapa é a fonte de verdade de tudo que vem depois. Sem ele, “deletar todos os dados do usuário” é chute, e resposta a incidente vira arqueologia. Se você trata dado sensível, vale aprofundar em arquitetura segura para dados sensíveis antes de escalar.
Entregável 2: DPA e o inventário de subprocessadores
O DPA (Data Processing Agreement) é o contrato entre controlador e operador que o GDPR (Art. 28) exige — e a LGPD pressupõe na relação controlador/operador. Do ponto de vista de engenharia, o DPA não é só papel: ele obriga você a manter um inventário de subprocessadores atualizado.
Todo terceiro que toca dado pessoal é subprocessador: Stripe, SendGrid, AWS, um serviço de analytics, aquele microserviço terceirizado. O cliente europeu vai querer a lista, e vai querer ser avisado quando ela mudar. Na prática:
- Mantenha a lista versionada no repositório, não numa planilha perdida.
- Cada item aponta que categoria de dado recebe e sob qual salvaguarda.
- Trocar de provedor de e-mail é uma mudança de subprocessador — tem processo, não é só um deploy.
Entregável 3: retenção e ciclo de vida do dado
Guardar dado “para sempre por precaução” é violação de princípio — tanto a minimização quanto a limitação de finalidade pedem que o dado morra quando a finalidade acaba. Isso vira código concreto: jobs de expiração.
Defina uma política de retenção por categoria e implemente rotinas que a executam de verdade:
- Log de acesso: retenção curta, purga automática.
- Conta inativa: anonimização ou deleção após X meses.
- Backup: retenção definida e documentada — inclusive backups precisam expirar.
O erro clássico é definir a política no documento e nunca escrever o job. Auditoria descobre isso em cinco minutos: basta pedir um registro de dois anos atrás que “deveria” ter sumido. Definir esses ciclos cedo evita a dor descrita em riscos de publicar apps em produção.
Entregável 4: direito ao esquecimento em código
O direito à eliminação (Art. 18 da LGPD, Art. 17 do GDPR) é o entregável mais subestimado — e o que mais quebra em produção. “Deletar o usuário” soa como um DELETE FROM users. Não é.
O dado de uma pessoa está espalhado: banco principal, réplicas de leitura, backups, logs de aplicação, cache Redis, filas de mensagem, data warehouse, e cada subprocessador. Um fluxo de esquecimento sério precisa:
- Orquestrar a deleção em todos esses lugares, não só no primário.
- Tratar integridade referencial. Onde deletar quebra o modelo (um pedido precisa existir para a contabilidade), use anonimização irreversível em vez de deleção.
- Propagar para terceiros via API de deleção de cada subprocessador.
- Registrar prazo e confirmação. O titular tem direito à resposta; você precisa provar que cumpriu.
- Gerar trilha de auditoria — sem manter, ironicamente, o dado que você deletou.
Anonimização bem feita é sua aliada: um dado verdadeiramente anônimo sai do escopo da lei. Mas “anônimo” tem régua alta — se dá para reidentificar cruzando campos, ainda é dado pessoal.
Um detalhe que derruba muita implementação: o esquecimento não pode ser síncrono e frágil. Se o pedido do titular dispara uma cadeia de chamadas a cinco sistemas e uma delas falha, você fica num estado meio-deletado, sem saber o que sobrou. O padrão robusto é assíncrono e idempotente: registre o pedido, processe cada destino de forma que possa ser repetida com segurança, e só marque como concluído quando toda a cadeia confirmar. Assim, uma falha de rede vira uma retentativa, não um dado órfão que reaparece no relatório do trimestre seguinte.
Entregável 5: logs de consentimento
Quando a base legal é o consentimento, ele precisa ser demonstrável. Não basta o checkbox: você tem que provar quem consentiu, para quê, quando e sob qual texto. Isso é um log imutável de consentimento.
Um registro de consentimento decente guarda:
- Identificador do titular e timestamp.
- Finalidade específica (não “aceito os termos”, e sim “aceito receber marketing”).
- Versão do texto/política apresentada.
- Canal e ação (opt-in ativo, nunca pré-marcado).
- Evento de revogação — retirar consentimento tem que ser tão fácil quanto dar.
O antipadrão é tratar consentimento como um booleano true. No dia da fiscalização, consent = true não prova nada. Um log versionado prova tudo.
Entregável 6: minimização e criptografia
Os dois pilares de segurança que aparecem em toda auditoria — e que times atrasam por parecerem “óbvios”.
Minimização é decisão de design, não de infra. Todo campo que você coleta é um passivo. Aquele formulário que pede data de nascimento “porque pode ser útil” é risco sem finalidade. A pergunta certa em cada campo novo: qual base legal e qual finalidade justificam isso? Se não há resposta, o campo não entra. Vale a mesma disciplina de escopo que defendemos em MVP do zero à produção: menos superfície, menos dívida.
Criptografia é obrigatória em dois estados:
- Em trânsito: TLS em tudo, sem exceção — inclusive entre serviços internos.
- Em repouso: banco, backups e object storage criptografados; segredos em cofre (nunca no código ou em variável de ambiente exposta).
Mas atenção ao mito: criptografia não é conformidade. Ela protege o dado que você tem o direito de ter. Coletar dado demais e criptografar continua sendo coletar dado demais. Cripto é o cadeado; base legal é o direito de guardar aquilo no cofre.
Checklist de entregáveis técnicos
Antes de assinar o DPA com o cliente europeu, seu time deveria conseguir marcar:
- RoPA técnico vivo, por sistema, com retenção e transferências mapeadas
- Inventário de subprocessadores versionado no repositório
- Base legal registrada por tratamento, não implícita
- Jobs de retenção rodando de verdade — inclusive em backups
- Fluxo de esquecimento que alcança réplicas, backups, logs e terceiros
- Log de consentimento imutável, com finalidade e versão do texto
- Minimização aplicada campo a campo
- TLS em trânsito e criptografia em repouso, com segredos em cofre
- SLA de resposta ao titular com cronômetro e trilha de auditoria
- Salvaguarda de transferência internacional definida (Art. 33 da LGPD)
- Runbook de incidente com prazo de notificação à autoridade
Se metade estiver vazia, você não tem um problema jurídico — tem um backlog de engenharia. E é mais barato construir isso na arquitetura do que retrofitar depois de um incidente. Times que tratam conformidade como custo recorrente, à moda de custo de IA em produção, sofrem menos que os que tratam como projeto único.
Onde isso costuma dar errado
Três padrões de falha que vemos repetir:
Conformidade tratada como documento, não como sistema. A política de retenção existe no PDF e não no código. Passa em revisão de contrato e falha na primeira auditoria técnica.
Transferência internacional ignorada. O time sobe tudo num provedor US-East porque é o default, sem salvaguarda para o dado europeu. O cliente descobre no due diligence e o contrato trava.
Esquecimento pela metade. Deleta do banco primário e esquece réplica, backup e o CRM terceirizado. O dado “deletado” reaparece num relatório seis meses depois.
Nenhum desses é problema difícil de tecnologia. São problemas de disciplina e sequência — decididos na arquitetura, não no fim do projeto. Se o seu time atende a Europa e precisa transformar esse checklist em entregáveis reais, é exatamente o tipo de trabalho que fazemos em desenvolvimento web.
Perguntas frequentes
Qual a diferença prática entre LGPD e GDPR para quem programa?
Os princípios são quase os mesmos: finalidade, minimização, segurança, direitos do titular. A LGPD (Lei 13.709/2018) foi inspirada no GDPR, então quem já implementou um cobre 90% do outro. As diferenças que exigem código são as bases legais, os prazos de resposta e as regras de transferência internacional — não a arquitetura em si.
Preciso cumprir GDPR se minha empresa é brasileira?
Sim, se você processa dados de pessoas na União Europeia — mesmo remotamente, mesmo sem escritório lá. O GDPR tem alcance extraterritorial (Art. 3). Se você tem clientes, usuários ou funcionários na UE, o regulamento se aplica ao seu software independentemente de onde o servidor ou a empresa estejam.
O que é um RoPA técnico?
RoPA (Records of Processing Activities) é o registro das operações de tratamento exigido pelo Art. 30 do GDPR e pelo Art. 37 da LGPD. A versão técnica mapeia, por sistema, quais dados pessoais existem, onde ficam, por quanto tempo e com quem são compartilhados. É a fonte de verdade que torna auditoria e resposta a incidente possíveis.
Como implemento o direito ao esquecimento em código?
Você precisa de um fluxo de deleção que alcance todas as cópias do dado: banco principal, réplicas, backups, logs, caches, filas e serviços de terceiros. Na prática, isso vira uma rotina orquestrada com prazo, confirmação e trilha de auditoria. Anonimização irreversível costuma ser aceitável quando a deleção total quebra integridade referencial.
Criptografia sozinha me deixa em conformidade?
Não. Criptografia em trânsito (TLS) e em repouso é um controle de segurança essencial, mas conformidade exige também base legal, minimização, retenção definida, atendimento a direitos do titular e registro de tratamento. Cripto protege o dado que você tem o direito de ter — ela não legitima a coleta.
Onde leio o texto oficial da LGPD?
No portal do Planalto: a Lei 13.709/2018 está publicada em planalto.gov.br. Para o GDPR, o texto consolidado e navegável está em gdpr.eu e no EUR-Lex. Evite depender só de resumos de fornecedor — os prazos e definições que viram requisito de código estão no texto legal.