Dados sintéticos e anonimização costumam ser tratados como sinônimos, e não são. Um registro anonimizado começou como dado real e passou por alguma transformação; um registro sintético nunca pertenceu a ninguém. A diferença decide o que você pode fazer com o conjunto, quanto ele custa para manter e o que ele é capaz de provar em uma auditoria. Neste texto, comparamos as quatro abordagens que aparecem na prática e mostramos quando cada uma faz sentido.
As quatro abordagens em uma frase cada
Antes de comparar, vale fixar o vocabulário, porque a confusão entre esses termos é a origem de quase todo o problema:
- Dados sintéticos. São gerados por algoritmo. Não derivam de nenhum registro real, e por isso não têm vínculo com pessoas.
- Dados anonimizados. Começaram como dados reais e passaram por transformações destinadas a impedir a reidentificação. O resultado deveria ser incapaz de apontar para alguém.
- Dados pseudonimizados. Também começaram como dados reais e tiveram os identificadores diretos substituídos, mas existe uma chave que permite voltar à pessoa. Continuam sendo dados pessoais.
- Dados mascarados. São dados reais com parte do conteúdo oculta na exibição, como os últimos dígitos de um documento. O valor original continua existindo atrás da máscara, e o conjunto não perdeu nenhum vínculo.
Duas dessas quatro abordagens preservam a ligação com pessoas, e é aí que mora o risco.
Por que apagar o nome não anonimiza nada?
Porque a identificação não depende do nome. Ela depende da combinação de características. Um conjunto sem nomes, mas com data de nascimento, código postal, profissão e local de trabalho, pode ser suficiente para apontar para uma única pessoa, porque essa combinação específica raramente se repete.
Esse efeito é conhecido na literatura de privacidade e aparece com nomes diferentes: reidentificação por combinação de campos, ou simplesmente o fato de que atributos quase únicos funcionam como um identificador na prática. Quanto mais detalhado o dado, maior o risco. Uma data de nascimento completa é mais identificadora do que um ano; um código postal completo é mais identificador do que uma região.
É por isso que anonimizar de verdade é difícil. A pergunta não é o que foi removido, e sim se ainda existe alguma combinação capaz de reencontrar a pessoa, com esforço razoável, no contexto em que o conjunto será usado.
Posso tratar dados pseudonimizados como anônimos?
Não. A pseudonimização substitui os identificadores diretos por um valor de referência, mas mantém uma forma de reencontro. Enquanto a chave existir, o dado continua ligado a uma pessoa, e as obrigações de proteção continuam valendo: finalidade, minimização, prazo de armazenamento, segurança e assim por diante.
A confusão acontece porque o conjunto pseudonimizado parece anônimo à primeira vista: os nomes não estão lá, e nada nele é obviamente pessoal. O que mudou foi a aparência, não a natureza. Se o objetivo é um conjunto que não carregue obrigação alguma, o caminho mais simples é não partir de dados reais.
Comparando as quatro na prática
| Abordagem | Vem de dados reais | Ainda aponta para alguém | Serve para demonstração pública | Manutenção |
|---|---|---|---|---|
| Sintético | Não | Não | Sim | Baixa |
| Anonimizado | Sim | Isso é o que se tenta evitar | Depende do caso | Alta |
| Pseudonimizado | Sim | Sim, se a chave existir | Não | Média |
| Mascarado | Sim | Sim, o valor original existe | Não | Baixa |
A coluna da manutenção costuma ser ignorada e é decisiva. Um conjunto anonimizado precisa ser reavaliado toda vez que novas fontes de dados se cruzam com ele, porque a combinação que parecia segura pode deixar de ser. Um conjunto sintético não tem esse problema, porque não existe nada a proteger nele.
Em ambiente de teste, a escolha que dá menos trabalho é o dado sintético. Ele cumpre a função técnica de preencher campos, cobre casos de borda que o dado real não tem e pode ser versionado, compartilhado e descartado sem consequência. O gerador de identidade desta página produz registros completos por país, e os valores servem apenas para testes: não podem ser usados para se passar por outra pessoa nem são aceitos em nenhuma verificação de identidade.
Para quem desenvolve: reprodutibilidade e prova
Duas propriedades separam um conjunto sintético bem construído de um punhado de valores sorteados:
- Reprodutibilidade. O mesmo parâmetro precisa produzir o mesmo conjunto. Isso permite guardar um caso de teste com um registro estável e reproduzir uma falha relatada por outra pessoa. Uma chave de identidade resolve o problema.
- Distribuição plausível. Os valores precisam se parecer com dados reais sem vir de dados reais: comprimentos variados, nomes de origens diferentes, datas espalhadas em uma faixa razoável. Um conjunto com todos os nomes do mesmo tamanho esconde defeitos de layout.
Sobre a prova de que não há dado real, o argumento mais forte não é uma declaração, e sim a origem: um conjunto cuja geração pode ser reproduzida a partir de um parâmetro conhecido, sem nenhuma etapa de importação, não tem por onde carregar registros de pessoas. Vale documentar isso onde o conjunto é guardado, junto da instrução de como reproduzi-lo, e vale manter a rotina de geração no mesmo repositório dos testes.
Por fim, uma recomendação de sequência: decida primeiro se o conjunto pode conter dado pessoal. Se não pode, a discussão sobre anonimização deixa de existir e o caminho fica mais curto.
Próximos passos
Reveja hoje os conjuntos que hoje derivam de dados reais e verifique se algum deles é usado fora do ambiente controlado. Substitua os que forem por dados gerados no gerador de identidade e documente a origem sintética junto do conjunto. Se o seu caso envolve um ambiente de desenvolvimento compartilhado, o texto sobre dados de teste e GDPR complementa essa decisão com as práticas de isolamento e retenção.