Por que resolver homônimo de servidor com e-mail completo viola a LGPD

Mostrar o e-mail completo de um servidor para diferenciar dois nomes iguais no mesmo sistema resolve o problema de identificação, mas cria outro: expõe um dado pessoal a qualquer usuário com acesso àquela lista, sem que a instituição tenha decidido, de fato, que esse nível de exposição era necessário. A LGPD não proíbe identificar pessoas — proíbe usar mais dado pessoal do que a finalidade exige, e homônimo se resolve com bem menos do que um endereço de e-mail completo.

O problema nunca foi identificar a pessoa, foi diferenciar duas pessoas parecidas

Sistemas de tramitação de instituições públicas de médio e grande porte lidam, quase sempre, com mais de um servidor de mesmo nome — quanto maior o quadro de pessoal, maior a chance de dois José da Silva ou duas Maria Oliveira aparecerem na mesma lista de encaminhamento. Quando isso acontece, quem desenha o fluxo do sistema — muitas vezes sem nenhuma decisão formal de governança envolvida — precisa escolher um dado que diferencie um do outro na hora de rotear um processo ou um despacho.

A escolha mais rápida é também a mais expositiva: mostrar o e-mail completo. Ele é único, geralmente já revela nome e sobrenome pelo padrão institucional ([email protected]) e resolve a ambiguidade numa linha só, sem exigir tela nova nem campo de configuração adicional. É prático — e é exatamente por ser a solução mais prática, não a mais necessária, que ela costuma passar sem nenhum questionamento.

O erro de raciocínio está em tratar “diferenciar dois nomes” e “expor o e-mail de todo mundo para todo mundo” como a mesma decisão. Não são. A primeira é uma necessidade funcional do sistema. A segunda é uma política de privacidade que ninguém redigiu, aprovou ou revisou — ela só aconteceu, como efeito colateral de uma tela de autocomplete.

Minimizar dado pessoal não é escondê-lo, é escolher o que resolve o problema

O princípio da necessidade, previsto no art. 6º, inciso III, da Lei Geral de Proteção de Dados (Lei nº 13.709/2018), limita o tratamento de dado pessoal ao mínimo necessário para a finalidade pretendida. A finalidade de uma lista de encaminhamento é garantir que o processo chegue ao destinatário certo — não é dar a qualquer servidor com acesso à lista uma forma de descobrir o e-mail de qualquer colega.

Minimizar não significa esconder o dado de quem precisa dele. O administrador do sistema, o setor de recursos humanos ou o suporte técnico têm motivo legítimo para acessar o e-mail completo de um servidor. Já um analista que só precisa encaminhar um processo para “o Carlos da Secretaria de Obras, não o Carlos da Fazenda” não precisa do e-mail — precisa de um identificador que resolva a ambiguidade sem carregar dado pessoal desnecessário: setor, cargo ou matrícula funcional.

A distinção entre esconder e minimizar é o que separa um sistema em conformidade de um sistema que trata privacidade como tudo ou nada. Minimizar é desenhar o campo certo para cada papel: o e-mail continua existindo no banco de dados, mas só aparece para quem tem finalidade legítima de vê-lo — não para quem só quer resolver uma tarefa que nada tem a ver com esse dado.

Toda lista de destinatários é uma política de acesso, mesmo quando ninguém decidiu isso de propósito

O e-mail numa lista de encaminhamento é só um exemplo de um padrão mais amplo: toda vez que um sistema expõe uma lista de pessoas — distribuição institucional, grupo oficial de comunicação, catálogo de contatos num portal de atendimento —, alguém está, na prática, definindo quem vê o quê sobre quem. Na maioria dos casos, ninguém tratou essa exposição como decisão de governança; ela nasceu de uma escolha técnica de interface e se tornou política de acesso de fato, sem o escrutínio que qualquer outra política receberia.

Isso importa mais numa instituição pública do que em outros tipos de organização, porque o dado pessoal em jogo é de servidores que não escolheram estar naquele cadastro. O mesmo raciocínio que já orienta quando um secretário deveria — ou não — acessar um processo sigiloso vale aqui: hierarquia e conveniência técnica não substituem uma decisão explícita sobre quem precisa ver o quê. O ponto de partida prático é revisar, campo a campo, quais permissões cada perfil de usuário realmente precisa ter dentro do sistema de tramitação — perguntando, de cada dado exposto, se ele resolve o problema ou só era o mais fácil de mostrar.

Conclusão

Resolver homônimo com e-mail completo não é falha de segurança da informação no sentido tradicional — não há invasão, não há vazamento técnico. É falha de design que trata a exposição de dado pessoal como consequência inevitável de uma função útil, quando na verdade é uma escolha entre várias soluções possíveis. A LGPD aplicada à rotina de uma prefeitura não pede perfeição — pede que cada exposição de dado pessoal tenha sido, de fato, decidida, e não apenas herdada da opção mais rápida de implementar. Auditar as pequenas listas de encaminhamento e contato antes que um apontamento externo obrigue a isso é a diferença entre tratar a LGPD como rotina e tratá-la como crise. Para ver como o Aprova estrutura permissionamento por papel dentro do fluxo de tramitação, agende uma demonstração.