Voltar ao BlogGDPR & Conformidade

Por que sua ferramenta de detecção de PII é apenas...

Um Steuer-ID alemão, NIR francês e Personnummer sueco exigem diferentes lógicas de detecção.

March 3, 202610 min de leitura
multilingualGDPRNLPPII detectionEuropean compliancespaCyXLM-RoBERTa

A Lacuna Oculta de Conformidade com o GDPR

O GDPR não tem preferência por idioma. O Artigo 4(1) define "dados pessoais" sem referência ao idioma em que aparecem. Um Steuer-ID alemão é tão protegido quanto um Número de Seguro Social dos EUA. Um NIR francês é tão regulado quanto um número de Seguro Nacional do Reino Unido.

Mas a maioria das ferramentas de detecção de PII foi construída para o inglês.

Pesquisas publicadas na ACL 2024 descobriram que abordagens híbridas de PLN alcançam pontuações F1 de 0,60-0,83 para locais europeus — mas ferramentas apenas em inglês aplicadas a texto não inglês pontuam quase zero para identificadores nacionais estruturados. A implicação prática: uma ferramenta de anonimização implantada em uma organização multinacional pode estar detectando 95% da PII em inglês enquanto perde 40-60% da PII alemã, francesa, polonesa ou holandesa no mesmo conjunto de dados.

Esta é uma lacuna sistemática de conformidade com o GDPR que afeta virtualmente toda empresa multinacional que utiliza ferramentas de anonimização centradas no inglês.

Por que a PII é Específica de Idioma

A detecção de PII tem dois componentes: detecção baseada em padrões (identificadores estruturados como IDs fiscais, formatos de telefone) e detecção baseada em NER (entidades contextuais como nomes de pessoas, nomes de organizações, endereços).

Ambos os componentes são profundamente específicos de idioma.

Identificadores Estruturados Diferem Radicalmente por País

PaísIdentificador FiscalFormatoRequisito de Detecção
AlemanhaSteuer-ID11 dígitos, algoritmo de verificaçãoValidação Modulo-11
FrançaNIR15 dígitos + chave de 2 dígitosValidação do algoritmo INSEE
SuéciaPersonnummer10 dígitos, indicador de séculoValidação Luhn
PolôniaPESEL11 dígitos, data de nascimento codificadaValidação Modulo-10
Países BaixosBSN9 dígitos, elfproef (11-check)Algoritmo Elfproef
EspanhaDNI/NIE8 dígitos + letraValidação Modulo-23
ItáliaCodice Fiscale16 alfanuméricosVerificação complexa

Um padrão regex apenas em inglês para SSNs (formato: NNN-NN-NNNN) não corresponderá a nenhum desses identificadores. Cada um requer lógica regex específica do país, além da validação de verificação.

O Reconhecimento de Entidades Nomeadas Requer Modelos Nativos de Idioma

Nomes de pessoas em alemão seguem padrões diferentes dos nomes em inglês. "Hans-Dieter Müller" e "Anna-Lena Schreiber-Koch" são reconhecíveis como nomes alemães pelo contexto — mas um modelo treinado principalmente em texto em inglês frequentemente os perde ou os classifica incorretamente.

Mais problemático: falsos positivos em um idioma podem se tornar falsos negativos em outro. O rastreador de problemas do GitHub do Microsoft Presidio documenta falsos positivos sistemáticos para palavras alemãs sendo classificadas incorretamente como PII em inglês. A mesma palavra "Null" (alemão para "zero") aciona falsos positivos de detecção de nomes em modelos treinados em inglês. Isso inflaciona as taxas de falsos positivos para 3 erros por 1 entidade real em ambientes de produção multilíngues (Alvaro et al., 2024).

A Exposição Regulatória

As autoridades de proteção de dados da UE estão cada vez mais cientes dessa lacuna. Vários DPAs nacionais emitiram orientações ou ações de fiscalização que implicam processamento multilíngue:

BfDI alemão: Esclareceu que o Artigo 5(1)(f) do GDPR (integridade e confidencialidade) se aplica a dados em todas as formas de processamento, incluindo dados não ingleses processados por ferramentas de terceiros.

CNIL francês: O Relatório Anual da CNIL de 2024 observou preocupações crescentes sobre ferramentas de IA que processam dados em francês sem capacidades de detecção de PII em francês.

DPAs europeus em geral: Sob o Artigo 25 do GDPR (Privacidade por Design), as medidas técnicas devem ser apropriadas para os dados reais sendo processados — o que inclui PII não inglesa em implantações multinacionais.

O risco prático: uma organização pode demonstrar 95% de eficácia na detecção de PII em conteúdo em inglês durante uma auditoria do GDPR, mas se também processar conteúdo em alemão, francês e polonês com a mesma ferramenta, a auditoria pode revelar lacunas sistemáticas para esses idiomas.

A Abordagem em Três Níveis para Detecção Multilíngue de PII

Pesquisas acadêmicas e implantações de produção convergiram em uma arquitetura híbrida em três níveis como a abordagem mais eficaz para a detecção multilíngue de PII:

Nível 1: Modelos spaCy Nativos de Idioma (Idiomas de Alto Recurso)

O spaCy fornece componentes de pipeline treinados para 25 idiomas, incluindo alemão, francês, espanhol, português, italiano, holandês, russo, chinês, japonês, coreano, polonês e outros. Esses modelos são treinados em corpora de língua nativa e entendem a morfologia, sintaxe e padrões de entidades de cada idioma.

Para o alemão: o modelo de_core_news_lg do spaCy entende substantivos compostos, flexão de caso e padrões de nomes alemães. Para o francês: fr_core_news_lg lida com padrões de entidades francesas, incluindo títulos, nomes de lugares e formatos de organizações.

Modelos nativos de idioma alcançam precisão e recall significativamente mais altos para detecção de nomes do que modelos cross-lingual aplicados a idiomas específicos de alto recurso.

Nível 2: Stanza (Idiomas Adicionais)

A biblioteca Stanza da Stanford fornece NER para idiomas adicionais não cobertos pela oferta comercial do spaCy, incluindo croata, esloveno, ucraniano e outros. Isso estende a cobertura a idiomas com populações de falantes da UE menores, mas ainda significativas.

Nível 3: XLM-RoBERTa (Cobertura Cross-Lingual)

Para idiomas onde nem o spaCy nem o Stanza fornecem modelos NER treinados, o XLM-RoBERTa fornece transferência cross-lingual. Treinado em dados do Common Crawl em 100 idiomas, o XLM-RoBERTa alcança 91,4% de F1 cross-lingual para detecção de PII (HuggingFace 2024), permitindo uma detecção razoável para idiomas de menor recurso.

O modelo cross-lingual lida com code-switching (texto em idiomas mistos) particularmente bem — uma propriedade que se torna crítica para organizações internacionais onde um único documento pode conter texto em vários idiomas.

Tipos de Entidades Específicas de Idioma

Além do modelo de detecção, a conformidade com o GDPR requer cobertura de tipos de entidades para identificadores específicos do país. Uma ferramenta multilíngue precisa:

Identificadores Nacionais da UE:

  • DE: Steuer-ID, Sozialversicherungsnummer, Personalausweisnummer
  • FR: NIR, SIREN, SIRET, número de telefone
  • PL: PESEL, NIP, REGON
  • NL: BSN, BurgerServiceNummer
  • SE: Personnummer, Samordningsnummer
  • ES: DNI, NIE, NIF, CIF
  • IT: Codice Fiscale, Partita IVA

Formatos de Números de Telefone: Cada país da UE tem estruturas de prefixo móvel únicas, formatos de código de área e convenções de discagem local. +49 (Alemanha), +33 (França), +48 (Polônia) exigem validação específica do país.

Formatos de Endereço: Os formatos de código postal diferem radicalmente — PLZ alemão (5 dígitos), código postal francês (5 dígitos começando de 01-99), postcode do Reino Unido (alfanumérico, múltiplos formatos), código postal espanhol (5 dígitos 01000-52999).

O Caso de Uso: Documentos Multilíngues de uma Farmacêutica Suíça

Uma empresa farmacêutica suíça processa contratos de trabalho que contêm texto em alemão, francês e inglês dentro do mesmo documento (a Suíça tem quatro idiomas oficiais). Sua ferramenta atual está configurada para o alemão e perde toda a PII da seção em francês.

Um contrato de trabalho para um funcionário baseado em Genebra menciona seu número AVS francês (13 dígitos), seu IBAN de conta bancária suíça, seu cantão de residência e seu nome em formato francês. A ferramenta configurada para o alemão perde o nome em formato francês, falha em detectar o padrão do número AVS francês (diferente do formato do número AHV alemão) e apenas detecta parcialmente o IBAN.

A abordagem em três níveis processa o documento como um todo, detectando automaticamente o idioma para cada segmento de texto, aplicando modelos NER apropriados para o idioma e usando validadores regex específicos do país para cada tipo de identificador nacional — independentemente de em qual seção do idioma ele aparece.

Manipulação de Documentos em Idiomas Mistos

O problema mais difícil de PII multilíngue é mistura de idiomas intra-documento: um documento que contém parágrafos em diferentes idiomas, frases com code-switching ou texto citado em um idioma diferente do contexto circundante.

Exemplos:

  • O contrato em inglês de uma empresa alemã com dados de funcionários alemães (nomes, IDs fiscais)
  • Um formulário de consentimento do GDPR francês que inclui um trecho de política de privacidade em inglês
  • Um registro de chat de atendimento ao cliente multilíngue onde o agente responde em inglês, mas o cliente escreve em árabe

O XLM-RoBERTa lida com isso nativamente: seu treinamento cross-lingual significa que não requer declarações explícitas de idioma e processa texto em idiomas mistos sem exigir segmentação.

Para implantações de produção, a combinação de detecção automática de idioma (aplicada no nível da frase) e inferência cross-lingual do XLM-RoBERTa fornece a manipulação mais robusta de documentos em idiomas mistos.

Orientações Práticas para Implantação

Audite a cobertura de idiomas da sua ferramenta atual: Peça ao seu fornecedor atual de anonimização para fornecer pontuações F1 para os idiomas específicos em seus dados. "Suporta 20 idiomas" muitas vezes significa que a ferramenta passa o texto pelo Google Translate antes de aplicar NER treinado em inglês — o que não é o mesmo que detecção nativa de idioma.

Mapeie seus dados para idiomas: Realize um inventário de dados que inclua a distribuição de idiomas. Uma multinacional com 70% de dados em inglês, 20% em alemão e 10% em francês tem exposição a riscos diferente de uma com 95% em inglês.

Teste com amostras de identificadores nacionais: Crie um conjunto de dados de teste com 10 exemplos de cada um dos identificadores nacionais relevantes para suas operações (Steuer-ID, NIR, PESEL, BSN, etc.) e verifique as taxas de detecção. Esta é uma auditoria mais rápida do que uma avaliação F1 em grande escala.

Revise suas DPIAs: Se você tiver Avaliações de Impacto sobre Proteção de Dados cobrindo suas ferramentas de anonimização, verifique se a análise de cobertura de idiomas está incluída. Uma DPIA incompleta que assume cobertura apenas em inglês pode precisar ser atualizada.


O mecanismo de detecção de PII da anonym.legal usa uma abordagem multilíngue em três níveis: modelos nativos de idioma spaCy para 25 idiomas de alto recurso, Stanza para cobertura de idiomas adicionais e transformadores cross-lingual XLM-RoBERTa para cobertura de 48 idiomas no total. Tipos de entidades específicos do país para todos os estados membros da UE estão incluídos.

Fontes:

Pronto para proteger seus dados?

Comece a anonimizar PII com mais de 285 tipos de entidades em 48 idiomas.