Apresentando o OpenAI Privacy Filter

• Um modelo de pesos abertos que realiza detecção e mascaramento de informações de identificação pessoal em texto não estruturado, podendo ser executado localmente para que os dados não saiam do dispositivo antes da filtragem
• Combina classificação bidirecional de tokens com span decoding para rotular a entrada inteira de uma vez e foi projetado para reconstruir rapidamente spans de PII em contextos de até 128.000 tokens
• Diferentemente de abordagens baseadas em regras que dependem de formatos como telefone ou e-mail, distingue melhor entre informações públicas e dados que precisam ser mascarados com base em linguagem e contexto
• Foi treinado com dados públicos e sintéticos, alcançou F1 de 96% no PII-Masking-300k e F1 de 97,43% na versão corrigida, enquanto a adaptação de domínio subiu de 54% para 96% mesmo com poucos dados
• Não é uma ferramenta de anonimização nem substitui certificações de conformidade; em áreas altamente sensíveis, revisão humana, avaliação por domínio e ajuste fino adicional continuam sendo importantes

---

Visão geral do produto e forma de distribuição

• Um modelo de pesos abertos especializado em detecção e mascaramento de informações de identificação pessoal, capaz de encontrar PII em textos para mascarar ou remover
• Suporta execução local, permitindo que os dados não saiam do dispositivo antes da filtragem e reduzindo o risco de exposição em comparação com o envio a um servidor para desidentificação
• Foi projetado para processar entradas longas rapidamente e pode decidir o que deve ser mascarado em uma única passagem
• Desenvolvedores podem executá-lo em seu próprio ambiente e ajustá-lo para seus casos de uso, adicionando proteção de privacidade mais forte a pipelines de treinamento, indexação, logging e revisão
• Foi publicado sob licença Apache 2.0 no Hugging Face e no GitHub, pensando em experimentação, customização e implantação comercial

O que muda em relação às abordagens existentes

• Ferramentas tradicionais de detecção de PII frequentemente dependem de regras determinísticas para formatos como números de telefone ou endereços de e-mail
• Esse tipo de abordagem pode funcionar bem em cenários mais restritos, mas tende a deixar passar informações pessoais mais sutis e tem dificuldade com contexto
• O Privacy Filter consegue detectar uma gama mais ampla de PII em texto não estruturado com base em uma compreensão mais profunda de linguagem e contexto
• Foi projetado para distinguir melhor entre informações públicas que devem ser preservadas e informações ligadas a uma pessoa que precisam ser mascaradas ou removidas
• Foi desenvolvido com o objetivo de elevar o padrão de privacidade além do nível atual, e uma versão ajustada também está sendo usada em fluxos internos de preservação de privacidade

Arquitetura do modelo e escopo de detecção

• Usa uma estrutura que combina um modelo bidirecional de classificação de tokens com span decoding
• Parte de um checkpoint pré-treinado autoregressivo e depois é adaptado como classificador de tokens sobre um esquema fixo de rótulos de privacidade
• Em vez de gerar o texto token por token, rotula toda a sequência de entrada de uma só vez e depois reconstrói spans consistentes com um procedimento Viterbi restrito
• Graças a essa estrutura, apresenta características de alta velocidade e eficiência, rotulando todos os tokens em um único forward pass
• Pode identificar spans de PII usando o contexto ao redor, e o modelo publicado suporta contexto de até 128.000 tokens
• É possível ajustar o equilíbrio entre revocação e precisão de acordo com o ambiente operacional
• O modelo divulgado tem 1,5 bilhão de parâmetros no total, com 50M de parâmetros ativos
• As categorias previstas são 8: private_person, private_address, private_email, private_phone, private_url, private_date, account_number e secret
• account_number é usado para mascarar vários tipos de números de conta, incluindo cartões de crédito e contas bancárias, enquanto secret cobre itens como senhas e chaves de API
• Os rótulos são decodificados como tags de span BIOES, criando limites de mascaramento mais limpos e consistentes

Processo de treinamento e resultados de avaliação

• Primeiro foi criada uma taxonomia de privacidade para definir os tipos de span que o modelo deveria detectar
  • Inclui identificadores pessoais, informações de contato, endereços, datas privadas, vários números de conta incluindo dados de crédito e banco, e secrets como chaves de API e senhas
• O language modeling head do modelo de linguagem pré-treinado foi substituído por um token-classification head, seguido por treinamento supervisionado com objetivo de classificação
• O treinamento combinou dados públicos e sintéticos para capturar ao mesmo tempo textos realistas e padrões de privacidade mais desafiadores
  • Em dados públicos, partes com rotulação incompleta tiveram sua cobertura ampliada com anotação assistida por modelo e revisão
  • Exemplos sintéticos foram usados para aumentar a diversidade de formatos, contextos e subtipos de privacidade
• Na inferência, previsões por token são convertidas em spans consistentes por meio de decodificação de sequência restrita
• Foram realizadas avaliações em benchmarks padrão e também avaliações sintéticas e em formato de chat voltadas a casos mais difíceis e sensíveis ao contexto
• No PII-Masking-300k, registrou F1 de 96%, precisão de 94,04% e revocação de 98,04%
• Na versão corrigida, que reflete problemas de anotação do dataset identificados durante a revisão, registrou F1 de 97,43%, precisão de 96,79% e revocação de 98,08%
• Mesmo com poucos dados, a adaptação de domínio avançou rapidamente, e no benchmark avaliado o F1 subiu de 54% para 96%
• O model card também inclui testes de estresse para detecção de secrets em codebases e exemplos multilíngues, adversariais e dependentes de contexto

Limitações e cuidados de uso

• Não é uma ferramenta de anonimização, não é uma certificação de conformidade e não substitui revisão de políticas em ambientes de alto risco
• É apenas um componente dentro de um sistema mais amplo com design centrado em privacidade
• Seu comportamento é influenciado pela taxonomia de rótulos usada no treinamento e pelos limites de decisão adotados
• Como cada organização pode querer políticas diferentes de detecção e mascaramento, pode ser necessária avaliação no domínio ou ajuste fino adicional
• O desempenho pode variar em idiomas, sistemas de escrita, convenções de nomes e domínios diferentes da distribuição de treinamento
• Pode deixar passar identificadores raros ou referências pessoais ambíguas e, especialmente quando o contexto é limitado, como em sequências curtas, pode mascarar demais ou de menos
• Em áreas altamente sensíveis, como direito, saúde e finanças, revisão humana, avaliação específica de domínio e ajuste fino continuam sendo importantes

Intenção da publicação e próximos passos

• A proteção de privacidade é tratada como um desafio contínuo que atravessa pesquisa, design de produto, avaliação e implantação
• Isso reflete a importância de modelos pequenos e eficientes que entregam desempenho de nível frontier em tarefas reais definidas de forma estreita
• A publicação segue o objetivo de tornar a infraestrutura de preservação de privacidade mais fácil de auditar, executar, adaptar e melhorar
• O modelo é apresentado como uma ferramenta para ajudar sistemas a aprender sobre o mundo sem aprender informações privadas de indivíduos
• Esta prévia pública também é uma etapa para receber feedback da comunidade de pesquisa e privacidade e melhorar ainda mais o desempenho

[GN⁺]

Comentários do Hacker News

• Esse tipo de recurso já foi implementado anos atrás, e o resultado deixou algumas coisas bem claras
  A sanitização de PII precisa ser revertida no cliente para manter a UX. Por exemplo, se o nome é John e ele foi ocultado como [NAME], quando o modelo responder Hi [NAME], isso precisa ser restaurado para Hi John antes de mostrar ao usuário
  No fim, a camada com a qual o usuário interage precisa de um mecanismo de substituição reversa
  Além disso, dados de PII mascarados são quase inúteis para a maioria dos objetivos. O modelo precisa de algum nível de dados reais para funcionar, e há tantos itens classificados como PII que um chat simples até funciona, mas quando o usuário precisa interagir de forma complexa com o LLM a dificuldade aumenta muito. Pode simplesmente não funcionar ou gerar hallucination
  Por isso existe suporte em nível de plataforma, mas na prática é pouco usado por causa dessas limitações
  A abordagem mais realista, na minha visão, é remover só parte das PII com maior risco de segurança e usar um modelo confiável que descarte a PII o mais rápido possível. Para isso, a arquitetura do sistema também precisa mudar bastante
• Estou criando o https://github.com/KevinXuxuxu/anon_proxy, uma espécie de proxy de anonimização colocado na frente do provedor de LLM
  Ele usa detecção baseada em modelo junto com regex PII detection e faz substituição e restauração nos dois sentidos, tanto nas requisições quanto nas respostas da API. Se o modelo de detecção for hospedado localmente, a PII não sai do ambiente local
  Foi especialmente útil ao lidar com documentos sensíveis como os de direito, impostos e imigração
  • O lado bom dessa abordagem é que ela pode ser conectada a qualquer modelo
    Ainda assim, o contexto inteiro da conversa continua visível para o modelo e para o operador
    Por isso eu prefiro uma abordagem como a do Confer, da Moxie https://confer.to/, que criptografa tudo para que ninguém além do usuário final possa ver o texto em claro
  • Fico curioso sobre como funciona a restauração do lado da resposta
    Se o documento foi mascarado na entrada, a saída do LLM também vai conter o conteúdo mascarado; então não entendo bem como isso continua depois
• Este release tem várias partes tecnicamente interessantes
  O Privacy Filter é um modelo de classificação de tokens bidirecional com span decoding, e dizem que ele começa de um checkpoint pré-treinado autoregressivo e foi adaptado como classificador de tokens sobre uma taxonomia fixa de labels de privacidade
  Em vez de gerar texto token por token, ele rotula a sequência de entrada de uma vez só e decodifica spans consistentes com um procedimento Viterbi restrito
  O modelo publicado tem 1,5 bilhão de parâmetros no total, com 50M de parâmetros ativos
  Também foi informado que ele foi criado trocando a LM head do modelo de linguagem pré-treinado por uma token-classification head e depois fazendo pós-treinamento com um objetivo supervisionado de classificação
  • Então parece que isso também poderia ser usado para encontrar a posição de informações sensíveis em texto não estruturado, sem depender de outras ferramentas de detecção de PII
    Se você passar o texto original pelo filtro para obter os spans e depois mapear esses spans de volta ao texto original, no fim terá toda a localização da PII
• Não é tão esperto quanto o da OpenAI, mas eu criei o https://tools.nicklothian.com/webner/index.html, que mascara algumas PII no navegador com NER baseado em BERT
  Funcionou muito bem para os usos que testei
  Como o modelo da OpenAI parece pequeno o bastante, estou pensando em acoplar isso também à minha ferramenta
  • Acabei de testar no documento e parece bem difícil de usar por causa da quantidade de false positive
    Coloquei um documento markdown de umas 100 linhas e ele classificou matter como organização por fazer parte de frontmatter, end também como organização por fazer parte de frontend, e MCP igualmente como organização
    Havia muitos resultados gramaticalmente sem sentido, como Following the discussion in , blahblah
    Dá uma sensação de voltar aos tempos do NLP de 10 anos atrás, e isso me fez lembrar de novo como o spaCy foi um projeto tão bom nessa área
• É importante deixar claro que quase todos os modelos desse tipo são ingênuos e básicos
  Para uma mensagem única e neutra como Hi, this is Bob., normalmente já basta, mas quando os dados começam a se acumular eu ainda não vi uma ferramenta de redaction de PII que leve em conta todo o risco de vazamento de identidade
  O problema cresce quando empresas usam isso e passam a acreditar que os dados foram anonimizados. Isso não é anonimização
  Ainda assim, esse tipo de filtragem pode ser bem útil quando não se trata de publicar ou compartilhar os dados diretamente, mas de usá-los em etapas intermediárias de processamento como moderation, human eval e model training
• É um pouco decepcionante que a maioria dos exemplos seja de coisas que regex já pegaria facilmente, mas é bom ver isso sendo lançado como modelo local aberto
  • Para os meus clientes, eu já impeço com expressões regulares que e-mails pessoais ou números de telefone sejam publicados no site
    Mesmo assim, parece razoável rodar um modelo desses junto para ter uma garantia extra
    Não tenho GPU no servidor, mas espero que seja um modelo leve o suficiente para dar conta de inferência só em CPU se for menos de 2k tokens por vez
• Ao clicar no link, ele redireciona para uma versão de tradução automática do site da OpenAI, e o sentido fica completamente arruinado
  redacted foi traduzido pelo polonês redagować, que significa mais editar ou lapidar um texto do que anonimizar
• Fico curioso para saber como isso se compara ao Presidio, que mistura regex e modelo: https://microsoft.github.io/presidio/
  • Acho que talvez desse para colocar esse modelo dentro do Presidio
• Acho que o https://peyeeye.ai resolve literalmente todos os problemas que o pessoal desta thread está comentando
  • Uma empresa que raspou dados dos outros sem permissão fazendo uma ferramenta de privacidade — a ironia é grande demais
• Fico feliz com esta divulgação
  Mesmo fora de setores regulados, há muitos motivos para ter esse tipo de modelo e prática, e em teoria parte disso passa a ser necessário também por causa do EU AI Act
  Eu já coloquei redaction e rehydration no https://grepture.com com um modelo NER especializado, então pretendo adicionar isso ao pipeline também
  Se der para colocá-lo opcionalmente no hot path e realmente mexer nas requisições antes e depois de chegarem ao LLM, isso pode ser bem útil em cenários de compliance ou com entrada direta de usuários