Por que o sistema legado, não a plataforma nova, expõe o dado do contribuinte

Quando uma prefeitura substitui o sistema de tramitação e, pouco depois da mudança, um CPF completo ou o endereço residencial de um contribuinte aparece exposto numa certidão emitida pelo novo ambiente, o primeiro instinto é apontar a plataforma nova como origem do problema. Na maioria dos casos esse diagnóstico está errado: o dado já saía exposto do mesmo jeito pelo cadastro legado que a plataforma nova apenas passou a consultar — a diferença é que agora a tela em que isso acontece tem mais gente olhando.

A tela nova só tornou visível um problema que já existia

Cadastros imobiliários e tributários legados, em muitos municípios, foram construídos numa época em que consultar um imóvel por número de matrícula ou inscrição significava trazer o registro inteiro — nome completo, CPF, endereço do titular e do imóvel — porque a tela era operada só por servidor autenticado, dentro de um sistema interno que ninguém de fora via. Sob essa lógica, ninguém tratou aquilo como problema. Se essa mesma consulta hoje ainda devolve CPF sem máscara e endereço residencial completo, ela sempre devolveu.

O que muda quando uma plataforma nova integra esse cadastro para preencher automaticamente um formulário ou compor uma certidão pública é a superfície de exposição, não a existência do dado exposto. Antes, só quem tinha login no sistema legado via aquele campo. Depois da integração, o mesmo campo pode aparecer num documento que o próprio requerente baixa, ou numa tela acessada por muito mais gente do que os poucos servidores que operavam o sistema antigo. O vazamento não nasceu na integração — ele só deixou de ser invisível.

Integrar não transfere a responsabilidade, ela soma

A Lei Geral de Proteção de Dados não isenta quem recebe um dado pessoal por integração da responsabilidade sobre como esse dado é tratado a partir daquele momento. O princípio da necessidade, previsto no art. 6º da Lei nº 13.709/2018, exige que o tratamento se limite ao mínimo necessário para a finalidade pretendida — e “a integração trouxe assim” não é uma finalidade, é ausência de filtro.

Isso significa que, na prática, não existe a defesa de “o problema é do sistema antigo, não do nosso”. A partir do momento em que a plataforma nova processa, exibe ou gera documento a partir de um dado pessoal recebido de outro sistema, ela também responde pelo tratamento daquele dado — inclusive pela decisão de não ter filtrado o que não precisava aparecer.

Filtrar na tela não resolve o que nasce na fonte

A correção mais comum é errada por ser incompleta: ocultar o campo na tela final, sem alterar o que a consulta ao sistema legado efetivamente retorna. Isso resolve a exposição naquele ponto específico, mas deixa a mesma informação disponível em qualquer outro lugar que consulte a mesma fonte — um relatório, uma exportação, uma segunda tela que ninguém lembrou de revisar.

Tratar isso na camada de integração, filtrando ou mascarando o dado sensível no momento em que ele entra na plataforma nova — e não apenas no momento em que aparece para alguém —, é o que impede o mesmo problema de reaparecer em outro fluxo. É trabalho de mapeamento, não de configuração pontual: exige listar cada campo sensível que o sistema legado devolve e decidir, campo a campo, se aquele dado precisa mesmo compor um documento público ou uma tela de preenchimento automático.

Conclusão

Antes de decidir se a plataforma nova é a origem de um vazamento, vale auditar o que o sistema que ela substitui já devolvia sem controle — porque, na maioria dos casos, a mudança apenas trouxe mais luz para um problema que já existia. Essa auditoria também é o que sustenta uma governança de dados capaz de identificar risco antes que ele apareça num documento público, e se conecta ao mesmo cuidado que já vale para quem acessa cada processo sigiloso dentro do fluxo tributário. Para entender como estruturar essa camada de integração com sistemas legados sem herdar as falhas deles, agende uma demonstração da Aprova.