Como anonimizar dados antes de enviar para um LLM: CPF, telefone e e-mail

Como anonimizar dados antes de enviar para um LLM: CPF, telefone e e-mail

Para anonimizar dados antes de enviar para um LLM, coloque uma camada entre a fonte do texto e o modelo que detecta CPF, telefone e e-mail e os troca por marcadores como [CPF_1]. Regex com validação resolve bem os formatos fixos, mas erra em texto sujo, em transcrições de áudio e em nomes de pessoas, onde um detector especializado ajuda. O ponto central é guardar a tabela de correspondência fora do modelo e testar a camada com mensagens reais antes de confiar nela.

Principais pontos

• Mascarar esconde o dado, pseudonimizar troca por um marcador reversível, anonimizar de verdade exige que não haja caminho de volta. Cada opção serve a um uso diferente.
• Regex com validação dos dígitos verificadores funciona bem para CPF, CNPJ e e-mail, e de forma apenas razoável para telefone.
• Texto digitado por humanos, áudio transcrito e OCR quebram os padrões. Nesses casos, um detector especializado ou uma segunda checagem é necessária.
• A tabela que liga marcador e dado original fica em um sistema controlado pela empresa, nunca no prompt nem nos logs enviados ao fornecedor.
• A qualidade da camada se mede com um conjunto de testes de mensagens reais (já tratadas) e com foco no que escapou, não no que foi mascarado a mais.

Mascarar, pseudonimizar ou anonimizar: qual a diferença?

Os três termos são usados como sinônimos em reuniões, mas têm efeitos diferentes. Escolher o errado leva a uma falsa sensação de segurança.

Mascarar é ocultar parte do dado, por exemplo mostrar só os dois últimos dígitos de um CPF. É útil para exibir informação a uma pessoa, mas ainda deixa pistas, e o resto do texto pode identificar o titular.

Pseudonimizar é trocar o dado por um marcador consistente, como [CPF_1] ou [EMAIL_2], e guardar a correspondência separada. O modelo consegue raciocinar ("o cliente [EMAIL_1] pediu segunda via") e a sua aplicação consegue reverter a troca na resposta. Pela lógica da LGPD, dado pseudonimizado ainda pode ser associado a uma pessoa por quem tem a informação adicional, então continua exigindo cuidado.

Anonimizar é remover a possibilidade razoável de identificar o titular, sem tabela de volta. Para texto livre isso é difícil, porque nome, cargo, cidade e o contexto da conversa também identificam. Na prática, a maioria dos projetos de LLM fica na pseudonimização bem feita, e isso já reduz muito a exposição. Confirme o enquadramento jurídico com quem cuida de privacidade na sua empresa, pois a classificação final depende do caso.

Que dados brasileiros costumam aparecer no texto?

Antes de escrever qualquer regra, faça o inventário do que realmente chega ao modelo. Em atendimento por WhatsApp, e-mail e formulários, os itens mais comuns são:

• CPF e CNPJ, com ou sem pontuação, às vezes com espaços no meio.
• Telefone, com DDD, com 9 na frente, com +55, com parênteses, ou colado a outro número.
• E-mail, o formato mais regular de todos.
• Nome completo, endereço, CEP, data de nascimento e RG.
• Chave Pix, que pode ser CPF, telefone, e-mail ou chave aleatória.
• Número de pedido, protocolo e placa, que não são sempre dados pessoais, mas se confundem com eles.

Esse inventário também define o que o modelo não precisa receber. Para resumir uma reclamação, o CPF quase nunca é necessário. Para consultar um pedido, a consulta pelo CPF deve acontecer em uma ferramenta determinística da sua aplicação, não dentro do prompt.

Até onde o regex chega e onde ele erra

Regex é o ponto de partida correto: barato, rápido, auditável e executável localmente. Mas cada tipo de dado tem um limite.

CPF: o formato 000.000.000-00 é fácil de capturar, porém o padrão sozinho gera falsos positivos, porque qualquer sequência de onze dígitos parece um CPF. A correção é validar os dois dígitos verificadores e descartar sequências repetidas (como todos os dígitos iguais). Com isso, o número de acertos falsos cai bastante. O que o regex não pega: CPF escrito por extenso, com letras no meio, com espaço ou quebra de linha entre os blocos, ou com um dígito errado digitado pelo cliente (que falha na validação e escapa, embora ainda seja um dado pessoal quase completo). Para essa segunda situação, vale uma regra mais frouxa: se a sequência tem o formato mas falha na validação, mascare mesmo assim. Aqui é melhor errar para o lado da proteção.

Telefone: é o mais ambíguo. Números de protocolo, códigos de rastreio e valores podem ter o mesmo comprimento de um celular. Use o contexto (DDD plausível, presença do 9 inicial no celular, prefixo +55, palavras próximas como "whatsapp" ou "me liga") e aceite que haverá casos duvidosos. Em atendimento, pergunte-se qual erro custa mais: mascarar um protocolo à toa costuma custar menos que deixar passar um telefone.

E-mail: o regex funciona bem para endereços normais. Falha em versões escritas para driblar filtros, como "fulano arroba empresa ponto com", comuns em conversa informal.

Nome e endereço: regex não resolve. Não existe padrão para um nome, e listas de nomes geram falsos positivos com palavras comuns ("Rosa", "Vitória", "Cidade"). Esse é o território dos detectores especializados.

Texto vindo de áudio ou imagem: uma transcrição pode trazer "meu cpf é um dois três ponto quatro cinco seis". O regex numérico não vê nada. Se você transcreve áudios, vale ler o artigo sobre transcrição de áudio de WhatsApp com IA, porque a anonimização precisa rodar depois da transcrição e, de preferência, também sobre ela.

Quando usar um detector especializado

Um detector especializado de dados pessoais combina regras, validadores e modelos de reconhecimento de entidades para achar o que o regex não alcança, principalmente nomes, endereços e dados descritos em linguagem natural. Existem bibliotecas de código aberto para isso, como o Presidio, que permite criar reconhecedores próprios (por exemplo, um para CPF com validação). Confira na documentação oficial da ferramenta que você escolher o suporte real ao português do Brasil, pois isso varia por versão e por modelo de linguagem usado dentro dela.

Um guia de decisão simples:

• Só e-mail, CPF e CNPJ em campos de formulário: regex com validação basta.
• Telefone em texto livre: regex com contexto, mais revisão por amostragem.
• Nomes, endereços ou dados de saúde e financeiros em texto livre: detector especializado, mais teste com mensagens reais.
• Áudio, imagem ou PDF escaneado: primeiro transcrição ou OCR, depois detecção, e uma checagem extra, pois o erro do OCR vira erro de detecção. O artigo sobre extração de dados de PDF com IA trata dessa conferência.
• Dados sensíveis em grande volume: considere não enviar ao fornecedor externo e rodar um modelo local dentro da sua infraestrutura.

Um detector também erra. Ele é uma segunda rede de proteção, não um certificado de que o texto está limpo. Por isso, a regra de ouro é combinar camadas: regex para o que tem formato, detector para o que tem contexto, e limites de acesso para o resto.

Passo a passo para montar a camada de anonimização

Este é um roteiro que serve para um agente de atendimento, uma automação de e-mail ou uma ferramenta interna.

• Mapeie o fluxo: de onde vem o texto, para onde vai, quem vê o prompt e quais logs guardam o conteúdo. Inclua o fornecedor do modelo e o local onde ele processa os dados.
• Defina o que o modelo precisa saber: para cada tarefa, liste quais campos são indispensáveis. O resto não entra.
• Escreva as regras de detecção: regex com validação para CPF, CNPJ, e-mail e telefone, mais um detector para nomes e endereços quando a tarefa pedir.
• Troque por marcadores consistentes: o mesmo CPF vira sempre [CPF_1] dentro da conversa. Não use dado falso que pareça real, pois pode coincidir com um documento verdadeiro.
• Guarde a tabela fora do modelo: em banco ou cofre da aplicação, com acesso restrito e prazo de retenção definido. Se precisar de um identificador estável entre conversas, use uma função com chave secreta (HMAC) em vez de hash simples, porque o espaço de CPFs e telefones é pequeno e hashes comuns podem ser revertidos por tentativa.
• Reverta só na saída, só quando necessário: a aplicação troca os marcadores pelos dados reais na resposta ao cliente, depois de validar o conteúdo. Veja também guardrails para agentes de IA para checar a saída.
• Aplique a mesma limpeza aos logs: de nada adianta mascarar o prompt se o log guarda a mensagem original no mesmo fornecedor.
• Teste com um conjunto de mensagens reais já tratadas ou sintéticas, inclusive as bagunçadas, e registre o que escapou. Reveja as regras a cada ajuste de fluxo.

Cenário ilustrativo: mensagem de WhatsApp

Cenário ilustrativo: uma loja recebe a mensagem "Oi, sou a Marina Souza, meu cpf 123.456.789-09, o pedido não chegou. Me chama no (11) 91234-5678 ou marina@exemplo.com.br". Antes de chegar ao modelo, a camada gera: "Oi, sou [PESSOA_1], meu cpf [CPF_1], o pedido não chegou. Me chama no [TEL_1] ou [EMAIL_1]".

O modelo resume o problema e propõe a resposta. Para consultar o pedido, a aplicação usa o CPF real, guardado na tabela, em uma chamada ao sistema da loja, sem passar pelo modelo. Na resposta ao cliente, a aplicação reinsere o primeiro nome apenas se o texto exigir.

Agora uma variação: o cliente escreve "cpf 123 456 789 09" e depois "meu zap é onze nove doze trinta e quatro...". O primeiro caso pode ser pego por uma regra tolerante a espaços. O segundo, não. Esse tipo de mensagem deve entrar no seu conjunto de testes, e a decisão de projeto é o que fazer quando a camada não tem certeza: mascarar, pedir que o cliente reescreva ou encaminhar a um atendente.

Como a LGPD entra nessa conversa

A LGPD não proíbe usar LLM com dados pessoais, mas exige finalidade, necessidade, segurança e transparência. Anonimizar antes de enviar atende ao princípio da necessidade: o modelo recebe só o que precisa. Isso não substitui a base legal, o aviso ao titular e o contrato com o fornecedor. Se o fornecedor processa dados fora do Brasil, vale ler sobre transferência internacional de dados com IA e LGPD. A ANPD publica orientações e é a fonte primária para o tema. Para riscos de vazamento de dados em aplicações com LLM, o OWASP Top 10 para LLM é uma boa referência técnica, e o NIST AI Risk Management Framework ajuda a organizar a gestão de risco.

O método que usamos nesse tipo de trabalho segue quatro passos. Mapear o fluxo e o baseline: quais dados circulam hoje e por onde. Limitar dados e ações: o modelo recebe o mínimo e não executa nada irreversível. Pilotar um fluxo real, com logs e uma métrica de sucesso combinada, incluindo a taxa de dados que escaparam da camada. Transferir a operação com regras documentadas e decidir se expande, ajusta ou para.

Perguntas frequentes

Posso confiar só em regex para proteger CPF e telefone? Para CPF, com validação de dígitos, o regex é bom, mas não cobre variações escritas por extenso, dígitos errados ou transcrições de áudio. Para telefone, a ambiguidade com outros números é maior. Use regex como primeira camada e teste com mensagens reais antes de depender dele.

Pseudonimizar é o mesmo que anonimizar para a LGPD? Não. Na pseudonimização existe uma tabela ou chave que permite voltar ao titular, então o dado ainda pode ser considerado pessoal. A anonimização exige que a identificação não seja razoavelmente possível. Peça a validação do enquadramento ao jurídico ou ao encarregado de dados.

O modelo perde qualidade quando recebe marcadores no lugar dos dados? Na maioria das tarefas de atendimento, resumo e classificação, o modelo funciona bem com marcadores consistentes, porque o que importa é o problema descrito. Quando a tarefa depende do dado em si, como validar um CPF, faça isso em código determinístico, fora do modelo.

Preciso anonimizar também os logs e os dados de teste? Sim. Logs com a mensagem original anulam o ganho da camada, e dados de teste com informação real ampliam a exposição. Aplique a mesma limpeza aos logs, defina um prazo de retenção e use dados sintéticos nos testes sempre que possível.

Fontes

• ANPD: Autoridade Nacional de Proteção de Dados
• OWASP Top 10 for LLM Applications
• NIST AI Risk Management Framework