Dados de teste sem pessoas reais: porque é que o pseudonimizado continua pessoal e o sintético não

Copiar a produção é um tratamento, não um atalho

O reflexo compreende-se. Os dados reais têm a forma que os dados reais têm: nomes de todos os comprimentos, moradas que não cabem no formulário, encomendas com quarenta linhas, a cliente cujo apelido tem um apóstrofo que partiu tudo em março passado. Um dump de produção restaurado é o conjunto de teste de maior fidelidade que existe, e custa um comando. O problema é que esse comando é um tratamento em sentido jurídico, e o Regulamento tem algo a dizer sobre isso.

Dois dos princípios do artigo 5.º aplicam-se-lhe direta e autonomamente. A limitação das finalidades, artigo 5.º, n.º 1, alínea b), exige que os dados pessoais sejam recolhidos para finalidades determinadas, explícitas e legítimas e não sejam tratados posteriormente de forma incompatível com essas finalidades. A morada foi recolhida para entregar uma encomenda. Reproduzir um erro de apresentação não é essa finalidade, e saber se é compatível com ela é uma pergunta real com uma resposta real que alguém tem de construir — o Regulamento dá critérios para a avaliação da compatibilidade, não um sim ou um não. A minimização, artigo 5.º, n.º 1, alínea c), exige que os dados sejam adequados, pertinentes e limitados ao necessário relativamente às finalidades. Uma cópia integral de todos os clientes, para testar uma página de pagamento, é difícil de descrever como limitada ao necessário.

Há uma dimensão prática que nada tem a ver com o direito e tudo a ver com o que corre mal de facto. Um ambiente de testes não tem os controlos de acesso da produção, nem a sua monitorização, nem as suas regras de retenção de cópias. Está num portátil, num contentor que alguém levantou, num instantâneo dentro de um bucket que ninguém se lembra de ter criado. O envio de correio costuma continuar configurado, e foi assim que uma execução em pré-produção escreveu uma vez a uma lista de clientes reais. A obrigação de proteger os dados não enfraquece porque a máquina se chama pré-produção, e a exposição prática é maior aí do que em produção. Os dois argumentos apontam no mesmo sentido.

O pseudonimizado continua pessoal — é aqui que as pessoas se enganam

O artigo 4.º, n.º 5, define pseudonimização como o tratamento de dados pessoais de forma que deixem de poder ser atribuídos a um titular sem recorrer a informações suplementares, desde que essas informações suplementares sejam mantidas separadamente e sujeitas a medidas técnicas e organizativas. Leia-o uma vez: as palavras decisivas são sem recorrer a informações suplementares. Essas informações suplementares existem. São guardadas nalgum sítio. A ligação continua lá; tornou-se mais difícil de seguir, não foi removida.

O considerando 26 tira a conclusão explicitamente: os dados pessoais que tenham sido pseudonimizados e que possam ser atribuídos a uma pessoa singular mediante o recurso a informações suplementares devem ser considerados informações sobre uma pessoa singular identificável. Por outras palavras, os dados pseudonimizados são dados pessoais, dentro do âmbito, com todas as obrigações associadas: direitos de acesso e apagamento, dever de notificação de violações, regras de transferência. As Orientações 01/2025 do Comité Europeu para a Proteção de Dados, adotadas em 16 de janeiro de 2025, formulam a mesma conclusão no seu resumo executivo e acrescentam um ponto a reter: vale mesmo que os dados pseudonimizados e as informações suplementares não estejam nas mãos da mesma pessoa.

A anonimização é uma afirmação diferente e bastante mais exigente. O considerando 26 diz que os princípios da proteção de dados não devem aplicar-se às informações anónimas, ou seja, informações que não digam respeito a uma pessoa singular identificada ou identificável, nem aos dados tornados anónimos de tal modo que o titular não seja ou já não possa ser identificado. Mas o mesmo considerando fixa o critério: para determinar se uma pessoa é identificável devem ter-se em conta todos os meios que seja razoavelmente provável virem a ser utilizados, considerando fatores objetivos como o custo e o tempo necessários. Um conjunto em que os nomes foram substituídos mas em que permanecem códigos postais, datas de nascimento e históricos de encomendas falha muitas vezes esse critério, porque a combinação reidentifica. Uma anonimização que aguente o escrutínio implica normalmente destruir a própria estrutura que o ambiente de testes devia reproduzir.

Os dados sintéticos escapam ao raciocínio inteiro por nunca entrarem nele. Uma linha montada a partir de uma lista fixa de nomes próprios, uma lista fixa de apelidos e uma lista fixa de cidades não diz respeito a uma pessoa singular identificada ou identificável, porque não há pessoa nenhuma por trás nem informação suplementar que levasse a uma. O artigo 4.º, n.º 1, define dados pessoais como qualquer informação relativa a uma pessoa singular identificada ou identificável; se nada se refere a ninguém, a definição não se cumpre, e o Regulamento simplesmente não alcança o conjunto. Sem fundamento jurídico, sem avaliação de compatibilidade, sem prazo de conservação, sem qualquer pedido de apagamento que possa alguma vez chegar. É uma diferença de categoria, e é a razão para gerar.

O que este gerador produz realmente, medido

A ferramenta bebe de seis conjuntos por país — França, Reino Unido, Alemanha, Espanha, Itália e Portugal —, cada um com trinta e dois nomes próprios, trinta e dois apelidos e doze cidades. São 192 nomes próprios, 192 apelidos, 72 cidades e 6144 nomes completos distintos em todo o espaço, e uma linha aguenta-se: uma persona de Lisboa recebe um nome português e uma parte local de correio derivada dele, não um apelido alemão sobre um telefone francês. Medido em quatrocentas tiragens, cem linhas dão 99,2 nomes distintos em média e mil linhas dão 922,5. O primeiro nome repetido aparece por volta da linha 100, que é o limite do aniversário sobre um espaço de 6144 e não um defeito.

Os endereços de correio nunca colidem, porque não ficam ao acaso. Cada execução guarda as partes locais já distribuídas e acrescenta um contador a uma repetição: a segunda Marie Martin recebe marie.martin2 como parte local. Dez mil linhas dão dez mil endereços distintos, e duzentas mil dão duzentas mil: medido sobre a função que constrói as linhas, já que o formulário pára às mil linhas por execução. O índice UNIQUE que rejeitava a importação a meio, deixando uma tabela meio cheia, já não tem nada para apanhar. Vale a pena conhecer dois limites dessa garantia. O contador vive o tempo de uma execução, por isso duas exportações separadas ainda se podem repetir — guarde um conjunto num só ficheiro, ou dê a cada lote o seu prefixo. E o número de nomes distintos não é o de endereços distintos: uma consulta que conte clientes por nome em vez de por endereço fica um pouco abaixo do seu número de linhas, cerca de oito por cento às mil linhas.

Cada endereço termina em example.com, example.net ou example.org, e em mais nada. Os três estão reservados pela RFC 2606 para servirem de exemplo, e os três publicam um registo MX nulo — o 0 . da RFC 7505, um domínio que declara no DNS não aceitar correio nenhum —, por isso um remetente pára antes de abrir uma ligação. É o emparelhamento das duas coisas que conta, e é mais estrito do que parece. Um domínio que simplesmente não tem servidor de correio não é seguro: a RFC 5321 faz o remetente que não encontra MX recair no registo de endereço, pelo que um domínio com ar de documentação, com um A vivo e sem MX, continua a ser um alvo de entrega. Reservado mais MX nulo é o que fecha a porta, e é a razão para não inventar um domínio de exemplo próprio.

A coluna do telefone é o único sítio onde a ferramenta responde a uma pergunta deixando um campo vazio. A França reserva números para a ficção: o plano nacional de numeração atribui as raízes 01 99 00, 02 61 91, 03 53 01, 04 65 71, 05 36 49 e 06 39 98 às obras audiovisuais, e 06 39 98 é a única móvel, por isso uma linha francesa leva +33 6 39 98 seguido de quatro algarismos ao acaso e mais nada. O Ofcom põe de lado 07700 900000 a 07700 900999 para a ficção de televisão e rádio, pelo que uma linha britânica leva +44 7700 900 e três algarismos. A Bundesnetzagentur publicou dois blocos móveis para produções de media, 0171 3920000 a 3920099 e 0176 04069000 a 04069099, e uma linha alemã sai de um deles. Espanha, Itália e Portugal não publicam nada equivalente, por isso as suas linhas saem com o campo do telefone vazio. Os países são sorteados uniformemente, o que quer dizer que cerca de metade das linhas tem um branco ali — 49,99 % em duzentas mil linhas — e uma nota por baixo do formulário diz porquê, porque uma coluna vazia sem explicação parece uma ferramenta avariada.

Uma regra aplicável, e onde ela pára

Gere, não copie, e faça com que os dados gerados sejam obviamente falsos. Use um domínio reservado para cada endereço em vez de uma mistura, ponha na parte local um prefixo que nenhuma conta real levaria, e escolha uma raiz telefónica que o seu país reserve para a ficção, se é que tem alguma. Esse «se é que tem alguma» merece resposta, porque para metade dos mercados deste site a resposta é não. A França, o Reino Unido e a Alemanha publicam cada um o seu bloco; Espanha, Itália e Portugal não publicam nenhum. O que esses três têm em vez disso é espaço não atribuído por agora, que é uma promessa bem mais fraca: um regulador que ainda não distribuiu uma gama pode distribuí-la para o ano, e um conjunto de testes escrito hoje estaria a ligar a alguém. Onde exista uma gama reservada, use-a; onde não exista, a saída honesta é não pôr número, que é o que esta ferramenta agora faz. A questão não é jurídica — os dados sintéticos ficam fora do âmbito, tenham o aspeto que tiverem —, é que uma pessoa que olhe de relance para um pedido de apoio ou para uma linha de registo possa ver num segundo que a linha não é um cliente. Um dado com ar de verdadeiro é tratado como verdadeiro, e é assim que uma morada de teste acaba numa lista de distribuição.

Onde a geração pára mesmo é no defeito que só se reproduz num registo. Às vezes a falha está nos dados daquele cliente e em mais lado nenhum, e nenhuma linha sintética a mostrará. Esse caso não se resolve a fingir, resolve-se a apertar. Extraia o registo único e não a tabela, leve só os campos que o defeito toca, trabalhe numa máquina com os mesmos controlos da produção, registe o acesso, e apague tudo quando acabar. Isso é um tratamento documentado, minimizado e limitado no tempo, com uma finalidade que consegue escrever — coisa completamente diferente de um dump noturno para um cluster de pré-produção partilhado — e é a forma que o seu encarregado de proteção de dados reconhecerá, porque é aquela que o Regulamento foi feito para acomodar.

Perguntas frequentes

Os dados pseudonimizados continuam a ser dados pessoais ao abrigo do RGPD?

Sim. O artigo 4.º, n.º 5, define pseudonimização como o tratamento de dados pessoais de forma que deixem de poder ser atribuídos a um titular sem recorrer a informações suplementares, e o considerando 26 declara que os dados pseudonimizados que possam ser atribuídos a uma pessoa singular mediante o recurso a essas informações suplementares devem ser considerados informações sobre uma pessoa singular identificável. O Comité Europeu para a Proteção de Dados repetiu-o nas suas Orientações 01/2025 sobre pseudonimização, adotadas em 16 de janeiro de 2025, acrescentando que vale mesmo quando os dados pseudonimizados e as informações suplementares não estão nas mãos da mesma pessoa. A pseudonimização é uma garantia que o Regulamento incentiva, pode reduzir o risco e apoiar uma avaliação de compatibilidade, mas não tira um conjunto de dados do âmbito de aplicação.

Posso copiar a base de dados de produção para pré-produção se a apagar depois?

Apagar depois não torna a cópia lícita; limita quanto tempo dura o tratamento, que é outra questão. A cópia é um tratamento a partir do momento em que acontece, precisa de um fundamento jurídico e tem de passar o teste de limitação das finalidades do artigo 5.º, n.º 1, alínea b) — o Regulamento pergunta se a nova finalidade é compatível com aquela para a qual os dados foram recolhidos e dá critérios para o avaliar. O artigo 5.º, n.º 1, alínea c), aplica-se autonomamente: levar uma tabela inteira quando três campos chegariam não está limitado ao necessário. Este é exatamente o juízo para o qual existe um encarregado de proteção de dados, e a resposta depende do seu setor, da sua informação de privacidade e do que está a testar de facto. Pergunte antes de lançar o restauro, não depois.

Os dados sintéticos estão mesmo fora do RGPD?

Quando são genuinamente sintéticos, sim — mas a palavra está a trabalhar. Dados montados a partir de uma lista fixa de palavras, sem qualquer entrada de um registo real, não dizem respeito a uma pessoa singular identificada ou identificável, logo o artigo 4.º, n.º 1, não se cumpre e o Regulamento não se aplica. O considerando 26 diz que os princípios da proteção de dados não devem aplicar-se a informações que não digam respeito a uma pessoa singular identificada ou identificável. A ressalva é que nem tudo o que se chama sintético é construído assim: um conjunto gerado por um modelo treinado com registos reais é outra coisa, porque o modelo viu os originais e o resultado pode reter o bastante para isolar alguém. Se o seu gerador lê da produção, a análise recomeça do zero. Se lê uma lista fixa de cento e noventa e dois nomes próprios que nunca foram de ninguém em concreto, não.

Pode mesmo ser entregue alguma coisa aos endereços de correio gerados?

Não, e a razão vale a pena copiá-la para os seus próprios conjuntos de teste. Cada endereço usa example.com, example.net ou example.org. A RFC 2606 reserva os três como nomes de exemplo, por isso ninguém pode registar um e pôr-se a receber correio nele, e os três publicam um registo MX nulo: a forma 0 . definida pela RFC 7505, ou seja, um domínio que anuncia no DNS não aceitar correio. Um remetente conforme lê aquilo e pára sem abrir ligação. O emparelhamento importa: um domínio sem MX não é equivalente, porque a RFC 5321 faz o remetente recair no registo de endereço, de modo que um domínio verosímil que resolve mas não tem servidor de correio continua a ser um alvo de entrega. Se escrever o seu próprio gerador, use os nomes reservados em vez de inventar um que pareça reservado — e bloqueie também o correio de saída ao nível do ambiente, coisa que já devia estar a fazer.

Quantas linhas posso gerar antes de os nomes começarem a repetir-se?

Os nomes começam a repetir-se por volta da linha 100; os endereços de correio, nunca. Os conjuntos têm trinta e dois nomes próprios e trinta e dois apelidos para cada um dos seis países, ou seja 6144 nomes completos distintos, e o limite do aniversário num espaço desse tamanho põe a primeira colisão perto das cem extrações, medida em 99,6 sobre três mil execuções. Com cem linhas obtém 99,2 nomes distintos em média; com mil linhas, 922,5. Os endereços são outra história: a um nome repetido é acrescentado um contador na parte local, por isso dez mil linhas dão dez mil endereços distintos e um índice UNIQUE sobre a coluna de correio não tem nada a rejeitar. Um limite a isso: o contador vale para uma execução, e o formulário gera no máximo mil linhas de cada vez, por isso se precisar de mais, volte a correr com outra semente e acrescente o seu prefixo por lote em vez de assumir que as duas exportações não se podem sobrepor.