LGPD em sistemas legados: o problema que ninguém quer abrir — e como começar a abrir

Adequar um sistema novo à LGPD é fácil. Adequar um sistema com 12 anos de operação, três bancos de dados, integrações com seis parceiros e nenhum dicionário de dados, isso é a parte complicada — e é onde a maioria das organizações está. Não tem como reescrever; não dá para parar; o relógio do prazo regulatório não para de andar.

A boa notícia: existe um caminho. A má: ele exige começar pela parte que dá mais trabalho — saber o que se tem.

A primeira pergunta sem resposta: que dado pessoal você processa, exatamente?

Em sistemas legados é comum descobrir, em diagnóstico, que o órgão ou a empresa não sabe enumerar os dados pessoais que armazena. Há campos obs, extra1, historico_texto onde, ao longo dos anos, gente colocou CPF, endereço, prontuário, foto. Há tabelas de log que guardam o payload completo de requisições — incluindo o que veio de formulário externo. Há dumps esquecidos em pastas de rede.

O primeiro entregável de qualquer adequação séria é um mapa de dados pessoais que responde, para cada base:

• Que dados pessoais existem? (nome, CPF, contato, dados sensíveis)
• De onde vieram? (formulário, integração, importação histórica)
• Para que são usados? (finalidade, em que processo)
• Quem tem acesso? (papéis, sistemas, integrações)
• Quanto tempo ficam? (retenção real vs. retenção formal)
• Como saem? (relatórios, exportações, integrações de saída)

Sem esse mapa, qualquer projeto de adequação é especulativo.

Os quatro problemas que aparecem em quase todo legado

Em diagnósticos de campo, vemos repetidamente os mesmos quatro padrões:

1. Coleta excessiva por inércia

O formulário pede 23 campos porque "sempre pediu". Metade não é usada por ninguém. A LGPD pede adequação e necessidade: só pode coletar o que tem finalidade. Reduzir o formulário é frequentemente o primeiro patch barato e de impacto alto.

2. Dados pessoais em logs

Logs guardam payloads completos para "facilitar debug". Eles vivem em sistemas que não foram desenhados como base de dados pessoais — sem políticas de retenção, sem controle de acesso fino, sem capacidade de atender pedido de exclusão. Ou se redacta na origem, ou se trata o sistema de logs como base sensível.

3. Backups que ressuscitam dados excluídos

Usuário pede exclusão. O dado some da base. Volta no backup do mês seguinte. A LGPD não exige reescrever backups, mas exige política documentada sobre como pedidos de exclusão são tratados em backups (geralmente: marca-se para não restaurar individualmente; o ciclo natural de rotação remove em prazo definido).

4. Integrações sem contrato de tratamento

O sistema manda CPF para um parceiro há oito anos. Nunca houve avaliação de base legal, finalidade compartilhada ou contrato de operador. Essa é tipicamente a parte que mais dá trabalho — porque envolve renegociar com terceiros — e a que mais aparece em fiscalização.

A estratégia que funciona em legado: anel concêntrico

Tentar resolver tudo de uma vez paralisa. O que vemos funcionar é um modelo de anéis concêntricos — começa pelo núcleo e expande:

1. Anel 1 — Pessoas e processos (semanas 1–4): nomeia DPO, define canal de titular, formaliza processo de pedido de exclusão/portabilidade. Mesmo que manual no início. Isso já cumpre exigências mínimas e reduz risco regulatório imediato.

2. Anel 2 — Mapa de dados (semanas 4–12): mapa documentado das bases principais. Não precisa ser exaustivo no v1 — precisa ser começado.

3. Anel 3 — Coleta e logs (mês 3 em diante): redução de coleta excessiva nos formulários ativos; redacção de PII em logs nas integrações novas e nas mais críticas.

4. Anel 4 — Backup e retenção (mês 4 em diante): política formal, ajuste técnico onde for possível.

5. Anel 5 — Integrações com terceiros (mês 6 em diante): renegociação de contratos de operador, com base legal documentada.

A ordem importa: cada anel reduz risco residual mesmo que o próximo demore. Quem tenta começar por terceiros antes de mapear, na prática não termina nenhum.

Por que faz sentido buscar ajuda externa nesse tipo de projeto

Equipes internas conhecem o sistema, mas têm dois obstáculos típicos: viés de proximidade (não veem o que está debaixo do nariz há anos) e conflito de prioridade (o backlog de funcionalidades novas sempre vence o de adequação). Um terceiro com método e sem o histórico interno consegue, em quatro a oito semanas, entregar o mapa de dados e o anel 1 estruturado — depois disso a equipe interna assume com base sólida.

Se a sua organização ainda está nas perguntas básicas — onde estão os dados, qual a finalidade, quem responde por isso — fale com a gente em /contato. Conduzimos diagnóstico e mapa nas primeiras semanas, e devolvemos um plano com prioridades, prazos e custos estimados para os anéis seguintes.

Auditabilidade contratual e LGPD se sobrepõem: vale ler também Auditabilidade de software contratado — boa parte das exigências de LGPD só se cumpre se o contrato com o fornecedor previu antes.