Além dos SSNs: anonimizar os identificadores internos da sua organização
A sua ferramenta RGPD remove endereços de e-mail. Remove números de telefone. Remove nomes. Você passa as exportações de tickets de suporte por ela. Depois partilha o resultado com a sua equipa de análise.
Os números de conta dos clientes ainda estão em todos os tickets. Os IDs de encomenda também. Os IDs de utilizador interno também.
Estes IDs parecem inofensivos por si só. Sem uma tabela de referência, não identificam ninguém. Mas a sua equipa de análise tem essa tabela. O seu CRM tem. A sua base de dados de suporte tem. Qualquer pessoa com acesso pode encontrar a pessoa em segundos.
Isto é uma falha de pseudonimização ao abrigo do RGPD. A ferramenta não falhou. Nunca lhe foi dito para procurar os seus IDs.
O que as ferramentas PII padrão detetam
As ferramentas PII padrão cobrem formatos universais. Capturam o que qualquer organização utiliza.
As ferramentas padrão detetam:
- Números de segurança social (SSNs dos EUA, NINOs do Reino Unido, formatos nacionais da UE)
- Endereços de e-mail
- Números de telefone
- Números de cartão de crédito
- Nomes
- Números de passaporte e carta de condução
As ferramentas padrão não detetam:
- IDs de funcionário no formato EMP-XXXXX
- Números de conta de cliente no formato ACC-XXXXXXXX-XX
- IDs de encomenda no formato ORD-XXXXXXX
- IDs de utilizador interno em formatos UUID ou personalizados
- Códigos de referência específicos de parceiros
As ferramentas padrão encontram padrões universais. Os seus IDs internos não são universais. Precisam de configuração personalizada para serem detetados.
O risco de re-identificação
Uma empresa exporta tickets de suporte para revisão de qualidade. A remoção PII padrão elimina nomes, e-mails e números de telefone. Os números de conta no formato ACC-XXXXXXXX-XX não são tocados.
A exportação vai para a equipa de análise. Um analista faz uma junção entre a tabela de tickets e a base de dados de clientes pelo número de conta. A pessoa é encontrada imediatamente. Não é precisa nenhuma técnica especial. É uma junção SQL de rotina.
O Artigo 4(5) do RGPD define a pseudonimização como o tratamento em que os dados «deixam de poder ser atribuídos a um titular de dados específico sem recorrer a informações adicionais». Os números de conta não passam nesse teste. As informações adicionais — a sua base de dados de clientes — estão ali mesmo na sua organização.
A exportação «anonimizada» não era anónima.
Criar padrões de entidades personalizados
A configuração de entidades personalizadas é rápida. As equipas de conformidade podem fazê-lo sem ajuda técnica.
Passo 1: Listar os seus formatos de ID.
Escreva cada um. Por exemplo: conta ACC-XXXXXXXX-XX, encomenda ORD-XXXXXXX, funcionário EMP-XXXXX.
Passo 2: Descrever o formato em linguagem simples.
«Os números de conta começam com ACC, depois um traço, depois 8 dígitos, depois um traço, depois 2 letras maiúsculas.»
A geração de padrões assistida por IA devolve: ACC-\d{8}-[A-Z]{2}
Passo 3: Testar com dados de amostra.
Carregue 20 a 30 documentos. Confirme que todas as ocorrências são encontradas. Confirme que não aparecem falsos positivos.
Passo 4: Escolher um método.
Para IDs usados como chaves de junção, onde a análise precisa de ligar registos:
- Pseudonimizar. Substituir ACC-00123456-AB por ACC-99876543-XY cada vez. A mesma entrada dá sempre a mesma saída. As junções continuam a funcionar. O valor original não pode ser recuperado sem a chave.
Para IDs desnecessários na análise:
- Redigir. Substituir por [REDACTED]. Simples. Permanente.
Passo 5: Guardar como predefinição partilhada.
Guarde a entidade personalizada — ou um conjunto delas — como uma predefinição partilhada. A configuração aplica-se a todos os usos: uploads em lote, chamadas API, interface de navegador. Os novos membros da equipa obtêm a configuração completa de imediato.
Caso de estudo: 180.000 tickets de suporte
Uma empresa encontrou 180.000 tickets de suporte no seu armazém de análise. Nomes e e-mails tinham sido removidos. Números de conta não. Cada ticket ainda tinha um valor ACC-XXXXXXXX-XX ativo.
Cronograma de resolução:
- O responsável de conformidade define o padrão ACC — 15 minutos
- Testa em 30 tickets de amostra — 20 minutos
- Confirma a precisão — 10 minutos
- Processa 180.000 tickets em lote durante a noite
- Substitui as tabelas do armazém pelas versões limpas
Tempo total do responsável de conformidade: 45 minutos. Sem deteção de entidades personalizadas, a correção teria precisado de um pedido de engenharia, revisão de código e uma implementação. Isso leva semanas, não horas.
Para saber como os IDs personalizados criam riscos nas ferramentas de IA de suporte, consulte o guia RGPD para IA de suporte.
Onde os IDs internos se propagam
Os IDs internos aparecem em mais lugares do que a maioria das equipas espera.
Documentos internos:
- Notas de reunião com referências a contas ou encomendas
- Tópicos de e-mail sobre casos de clientes
- Apresentações com dados de casos reais
Partilhados com terceiros:
- Relatórios a reguladores com números de referência
- Documentos de auditoria com referências de clientes
- Ficheiros de fornecedores com IDs de clientes
Investigação e análise:
- Conjuntos de dados de percurso do cliente
- Exportações de revisão de qualidade de suporte
- Dados de treino para modelos ML internos
Cada contexto precisa da mesma configuração de entidades personalizadas para produzir resultados verdadeiramente anónimos.
Pseudonimização vs. anonimização
O RGPD traça uma linha clara.
A pseudonimização substitui IDs por substitutos. A pessoa original pode ser encontrada novamente se alguém tiver a tabela de referência. Estes dados continuam a ser dados pessoais. O risco diminui. As suas obrigações ao abrigo do RGPD não desaparecem.
A anonimização remove a capacidade de re-identificar. Os dados anónimos não são dados pessoais. O RGPD não se aplica a eles.
Números de conta e de encomenda são pseudónimos quando existem tabelas de referência. Substituí-los por substitutos fixos reduz o risco, mas o RGPD continua a aplicar-se. Substituí-los por tokens aleatórios — e eliminar a chave — remove a obrigação do RGPD, mas impede a análise baseada em junções.
Para partilha com terceiros que não têm as suas tabelas de referência: a pseudonimização pode ser suficiente. Para análise interna, é necessária anonimização completa ou controlos de acesso rigorosos. O guia de conformidade legal explica como documentar cada abordagem para o seu registo de atividades de tratamento.
Conclusão
A lacuna não é uma falha da ferramenta. É uma lacuna de configuração. Nenhuma ferramenta pode conhecer o formato do seu número de conta se não lhe disser.
A configuração de entidades personalizadas fecha a lacuna em horas. As equipas de conformidade definem os formatos, testam-nos com dados de amostra e aplicam-nos em todos os modos de utilização. Não é necessária ajuda técnica.
Os 180.000 números de conta não redigidos não estavam lá porque a ferramenta falhou. Estavam lá porque nunca foi dito à ferramenta para os procurar.