A pseudonimização reduz a ligação imediata entre informação e identidade, mas a sua eficácia depende de separar mais do que duas colunas numa folha de cálculo. É necessário controlar quem acede aos identificadores, à informação adicional e ao conjunto utilizado na análise. Também é preciso verificar se o restante conteúdo permite reconhecer pessoas sem consultar a correspondência.
Este método permite desenhar um fluxo com pseudónimos, escolher a técnica e preparar verificações de acesso, reidentificação autorizada e eliminação. O exemplo é fictício e acompanha uma análise de pedidos de apoio. O objetivo é preservar a utilidade necessária com menor exposição de identidades, mantendo as obrigações aplicáveis ao tratamento.
Definir o resultado de proteção pretendido
O artigo 4.º, n.º 5, do RGPD descreve a pseudonimização através da impossibilidade de atribuir dados a uma pessoa sem informação suplementar, mantida separadamente e protegida. A técnica é reconhecida no regulamento como uma possível medida de proteção. Não constitui, por si só, fundamento para recolher ou reutilizar dados.
Comece por identificar de quem pretende impedir ou limitar a identificação: analistas internos, prestadores ou pessoas que possam obter uma exportação. Um analista que também conserva acesso ao CRM original pode reconstruir a identidade apesar de a sua tabela usar códigos. A separação deve ser efetiva para o cenário que pretende proteger.
A classificação contextual de dados pessoais ajuda a avaliar as diferentes perspetivas, incluindo os limites de conclusões sobre destinatários. Para o responsável que mantém a ligação, retirar o nome do conjunto de análise não elimina as suas obrigações. Não utilize a palavra «anónimo» como sinónimo comercial de «com códigos».
Escolher o conjunto mínimo antes da transformação
Retire campos que não são necessários. Pseudonimizar o nome não justifica conservar uma morada exata se a análise só precisa de uma zona. Reduza também datas, localizações e descrições livres quando a precisão não for necessária. Uma narrativa com uma ocorrência rara pode identificar alguém sem qualquer nome.
Defina se precisa de ligar respostas da mesma pessoa ao longo do tempo. Se o objetivo é contar pedidos por categoria num único período, um identificador estável de cliente pode ser desnecessário. Se precisa de medir repetição de pedidos, a ligação longitudinal pode ser útil, mas deve ficar limitada ao projeto e ao período pertinentes.
A auditoria de minimização precede a escolha criptográfica. Uma boa técnica aplicada a um conjunto excessivo mantém riscos que poderiam ter sido eliminados de forma mais simples. A ficha do projeto deve explicar que ligações são necessárias e quais devem ser impedidas.
Comparar técnicas sem confundir os seus efeitos
O relatório da ENISA sobre técnicas e boas práticas de pseudonimização analisa técnicas, modelos de ameaça e limitações. A escolha depende da utilidade, da possibilidade de recuperação e da resistência a tentativas de associação. Não existe uma técnica única adequada a todos os cenários.
| Abordagem | Utilidade possível | Questão que precisa de controlo |
|---|---|---|
| Código aleatório e tabela de correspondência | Ligação controlada entre registos e identidade | Proteção da tabela e do serviço que a consulta |
| Transformação determinística com chave secreta | Comparar o mesmo identificador dentro de um âmbito definido | Proteção da chave e limitação de ligações entre projetos |
| Cifragem de identificadores | Recuperação autorizada do identificador original | Acesso à chave e separação das funções |
| Resumo criptográfico sem segredo | Comparação técnica de valores | Valores previsíveis podem ser testados e reconhecidos |
Uma função de resumo não torna automaticamente um endereço de correio irreconhecível. Quem conhece uma lista de endereços candidatos pode comparar os resultados. A utilização de um valor adicional público também não impede todas essas tentativas. Quando o desenho exige uma transformação com segredo, use mecanismos adequados e revistos, sem inventar um algoritmo próprio.
A cifragem integral de uma base protege situações específicas, mas não equivale necessariamente à separação funcional pretendida na pseudonimização. Se a aplicação decifra tudo para qualquer analista, a identidade continua disponível nesse percurso. O plano de cifragem e gestão de chaves deve acompanhar a arquitetura de acessos.
Exemplo preenchido: análise de pedidos de apoio
Uma empresa fictícia quer perceber se determinadas categorias de pedido originam contactos repetidos. A equipa de análise precisa de relacionar pedidos do mesmo cliente, mas não precisa de saber o nome ou o contacto. O projeto utiliza um código aleatório próprio e separa o serviço de correspondência.
| Componente | Decisão fictícia |
|---|---|
| Origem | Sistema de apoio, com identificação acessível apenas às funções operacionais autorizadas |
| Transformação | Serviço restrito atribui um código de projeto e remove identificadores diretos |
| Conjunto analítico | Código, categoria, semana do pedido e estado de resolução |
| Texto livre | Excluído porque a finalidade inicial pode ser respondida sem o conteúdo integral |
| Correspondência | Tabela separada, com acesso limitado e pedidos justificados |
| Analistas | Recebem o conjunto de projeto, sem acesso corrente à tabela nem ao CRM original |
| Relatórios | Resultados agregados sujeitos a revisão de grupos pequenos |
| Encerramento | Rever a necessidade do conjunto, da ligação e das cópias segundo regras próprias |
A decisão de conservar a correspondência deve ter uma razão. Se não existe qualquer necessidade de voltar a identificar pessoas, avalie uma abordagem de anonimização adequada em vez de manter uma chave indefinidamente «por precaução». A destruição da correspondência, contudo, não garante anonimato quando o conteúdo continua identificável por outros meios.
Organizar o serviço de reidentificação autorizada
Quando a reidentificação é necessária, defina os motivos admissíveis e quem pode aprová-la. No exemplo, uma correção de dados pode exigir localizar os registos da pessoa no conjunto analítico. Isso não significa que um gestor possa pedir identidades para contactar comercialmente clientes com determinada classificação.
O pedido deve indicar finalidade, âmbito e responsável. O serviço devolve apenas o necessário e conserva um registo proporcional da operação. Para operações mais sensíveis, pode ser adequada uma separação entre quem pede e quem autoriza. Essa escolha depende do risco e da organização, não de uma obrigação universal de duas assinaturas.
Proteja também interfaces e contas técnicas. Uma tabela bem restringida perde utilidade se uma API permite consultar livremente qualquer código. Revise as permissões dos administradores, o acesso de assistência e os meios de recuperação. As cópias de segurança da correspondência precisam de controlos equivalentes aos do sistema principal.
Limitar ligações entre projetos e destinatários
Um pseudónimo estável utilizado em todos os projetos facilita cruzamentos que podem não ser necessários. Avalie códigos próprios por projeto ou destinatário e documente quando a ligação entre conjuntos é permitida. A equipa não deve juntar duas bases apenas porque partilham um identificador técnico compatível.
Uma transferência para um destinatário externo exige avaliar finalidade, papéis, garantias e eventual transferência internacional. A pseudonimização pode reduzir riscos, mas a eficácia depende de quem possui informação adicional e do conteúdo enviado. Não assuma que qualquer conjunto com códigos pode circular livremente fora da organização.
A avaliação do impacto das transferências permite examinar o papel de medidas suplementares num fluxo internacional. O anexo técnico deve explicar a separação real, a possibilidade de acesso à informação adicional e os riscos remanescentes. Uma promessa contratual genérica de não tentar identificar não substitui uma arquitetura que limite os meios disponíveis.
Verificar a proteção com cenários plausíveis
Faça uma revisão com dados sintéticos que representem os formatos e as combinações relevantes. Confirme que o analista não acede à correspondência, que uma conta sem autorização não a consulta e que o relatório não transporta colunas ocultas ou identificadores originais. Verifique o percurso de exportação, não apenas a vista apresentada na aplicação.
Depois, procure possibilidade de reconhecimento pelo conteúdo: um pedido numa data rara, uma zona com poucos clientes ou uma combinação única de atributos. A avaliação de anonimização e risco de ligação oferece perguntas úteis, embora o objetivo do projeto possa continuar a ser pseudonimização e não anonimato.
Teste colisões e erros de associação na medida pertinente à técnica. Se dois clientes forem ligados ao mesmo código por falha de implementação, a análise pode tornar-se inexata e uma operação de reidentificação pode afetar a pessoa errada. A proteção da identidade deve coexistir com a integridade e a possibilidade de corrigir erros.
Documentar versões e reagir a uma falha
Guarde a descrição da técnica, a versão, o âmbito dos códigos, os acessos, as verificações e as limitações conhecidas. Não coloque a chave secreta no documento que descreve o controlo. Uma mudança de método pode afetar a possibilidade de comparar resultados antigos e precisa de um plano que preserve apenas as ligações necessárias.
Se a chave ou a tabela for comprometida, avalie os dados abrangidos, os destinatários e os efeitos sobre as pessoas. A existência de pseudónimos não exclui automaticamente uma violação de dados nem as obrigações pertinentes. Pode ser necessário restringir acessos, substituir segredos, rever códigos e tratar cópias já distribuídas.
As orientações 01/2025 disponibilizadas pelo CEPD na página de consulta pública devem ser lidas com atenção ao estatuto e à evolução interpretativa; o fecho da consulta não equivale, por si só, a uma versão final. Para executar o projeto, mantenha a decisão ligada ao texto legal, à técnica utilizada e à verificação efetiva de quem consegue reconstituir a identidade.