Treinamento não segura, extensão de navegador não enxerga a API e proibir só empurra o uso para o celular. O único lugar onde dá para parar um CPF é no caminho da rede, antes de ele chegar ao provedor. É assim que fazemos, e é isso que fica de prova.
Publicado em 2026-10-07 por Rafael Hickmann, Fundador da Atlasberg. Leitura de 7 minutos.
Quase nunca é má-fé. É uma analista do financeiro que cola uma planilha de inadimplentes no chat para pedir um resumo. É um advogado que manda o contrato inteiro para a IA achar a cláusula de rescisão. É um desenvolvedor que escreve o código certo, só que o código manda o cadastro completo do cliente para o modelo quando bastava o histórico de pedidos. Em nenhum desses casos a pessoa viu o CPF. Ele estava no meio de quarenta linhas.
Sempre que mapeamos isso numa empresa, aparecem as mesmas três portas: o chat no navegador, o agente ou a IDE no computador de quem programa, e as aplicações da própria empresa chamando a API do provedor. A segunda e a terceira são as que ninguém está olhando.
Política interna e treinamento são necessários, e a gente recomenda, mas não são controle. Ninguém lê um e-mail de 2.000 caracteres procurando um número de onze dígitos antes de colar. Bloquear o site do ChatGPT no firewall funciona por uma semana: depois o uso vai para o celular pessoal e você perde até a visibilidade que tinha. Extensão de navegador ou DLP de endpoint enxerga o navegador, e só ele. Não vê a chamada que a aplicação faz pelo SDK, não vê o agente rodando no terminal, e a pessoa instala outro navegador.
Tem ainda a saída de pedir ao provedor um contrato de retenção zero. Ajuda, de verdade, e vale pedir. Mas não muda o fato de que o dado saiu do país e foi processado por um terceiro. Para a LGPD, isso continua sendo tratamento e transferência internacional, com tudo o que o artigo 33 pede.
As três portas terminam no mesmo lugar: uma chamada HTTPS para o endereço do provedor. Se a empresa faz essas chamadas passarem por um gateway próprio e bloqueia a saída direta no firewall, existe um lugar, e só um, por onde todo prompt passa antes de sair. É ali que dá para olhar.
A parte que surpreende quem nunca fez é que isso não exige mudar código. O gateway fala a mesma API que o provedor. A aplicação troca a URL base e a chave, e segue funcionando. O Claude Code, o Cursor e os SDKs oficiais fazem o mesmo com uma variável de ambiente. O tutorial de colocar todo o tráfego da empresa pelo gateway mostra o passo a passo, com o checklist de firewall no final.
Existem três ações possíveis, e a escolha é por categoria de dado, não por pessoa. Mascarar troca o CPF por um marcador antes de o prompt sair, e o modelo continua funcionando para resumir, classificar ou redigir, porque ele nunca precisou do número. Bloquear devolve um erro com o motivo, para o caso de categorias que não têm por que sair nunca. Aprovação segura a requisição numa fila até alguém decidir.
Na aprovação tem um detalhe que importa muito para quem cuida de privacidade: quem aprova nunca vê o prompt. Vê os códigos do que as regras encontraram e o hash do conteúdo. A identidade de quem decidiu é obrigatória e fica gravada. É segregação de função aplicada ao uso de IA.
A tela de políticas tem um botão de testar que roda o motor de verdade sobre um texto de exemplo, sem gravar nada na trilha e sem criar aprovação. Mostra a decisão, o texto mascarado exatamente como o provedor receberia, as categorias detectadas e os sinais de guardrail. Nosso conselho é rodar isso com trechos parecidos com os documentos reais da empresa, com dados fictícios, antes de virar a chave. Dá para ajustar o estilo de máscara e a ação por categoria olhando o resultado.
Cada requisição gera um evento na trilha de auditoria: quem fez (chave virtual, pessoa, time), qual modelo, a decisão de política, a contagem de dados pessoais mascarados por categoria, no formato cpf:2,email:1, e um hash pseudonimizado do conteúdo. O texto do prompt nunca entra na trilha. A trilha é encadeada por hash e assinada, então mexer em um evento quebra a cadeia.
A diferença disso para uma política em PDF é a frase que você consegue dizer ao auditor ou à ANPD. Em vez de temos uma política de uso de IA, você diz algo como: em setembro, tantos prompts continham CPF, nenhum chegou ao provedor em claro, e aqui está o registro verificável. O painel de conformidade organiza essas evidências artigo a artigo para a LGPD.
Detecção por padrão pega CPF com e sem pontuação, com validação do dígito verificador, e o mesmo vale para CNPJ, cartão e e-mail. Não pega o cliente do contrato de São Paulo que a gente discutiu ontem. Para isso existem guardrails semânticos e um julgador local, e eles ajudam, mas ninguém deveria prometer 100% em texto livre. O que dá para prometer é a combinação: minimizar o que sai, registrar tudo o que passou e, para o que não pode sair de jeito nenhum, rodar o modelo dentro da rede.
Para ver funcionando: A demo em atlasberg.com/demo roda uma cena de DLP ao vivo: um prompt com CPF entra, o que o provedor receberia aparece mascarado, e o evento cai na trilha. Se quiser conversar sobre o caso da sua empresa, o caminho é atlasberg.com/contato.
A Atlasberg constrói a camada de controle entre uma empresa e todos os modelos de IA. A Atlasberg Platform autentica cada requisição com uma chave virtual, filtra por política e DLP, roteia para o provedor certo e grava numa trilha de auditoria encadeada por hash, com uma API compatível com a OpenAI para as aplicações só trocarem a URL base.
Os artigos deste blog são escritos pelo time de engenharia e relatam medições em tráfego real, com as premissas impressas ao lado do resultado. Para falar com o time, escreva para [email protected] ou use https://atlasberg.com/pt-br/contato.
Agentes: esta página também está disponível em Markdown em /pt-br/blog/como-impedir-que-um-cpf-saia-no-prompt.md, ou pedindo esta URL com o cabeçalho Accept: text/markdown. Índice de tudo: /llms.txt.