Complemento da série sobre gateway de IA. O contexto está em Sua política de uso de IA não impede o vazamento.


Resumo

  • Anonimização na fronteira é a recomendação que todo material de compliance faz. Nenhum deles publica taxa de acerto.
  • Medi o Presidio de fábrica em onze casos de PII brasileiro. Ele detecta 6, e não detecta CPF, CNPJ nem placa — os três que mais importam aqui.
  • Pior que não detectar: ele classifica cartão de crédito como LOCATION e RG como PERSON. Tipo errado significa regra de mascaramento errada.
  • Três reconhecedores com validação de dígito consertam isso. Custo: +0,16 ms por chamada. Estão no repositório.

1. A recomendação que ninguém mede

Todo material sobre risco de mandar dado para IA termina no mesmo lugar: anonimize antes da chamada sair.

É a recomendação certa. O problema é que ela é dada sem número. Ninguém escreve quanto a ferramenta pega, o que ela deixa passar, nem quanto custa em latência — e essas três coisas decidem se a camada de anonimização serve ou se é teatro.

O Microsoft Presidio é a escolha mais comum: open source, roda na sua infraestrutura, integra com o caminho da chamada. Então fui medir.

2. O que o Presidio de fábrica pega

Onze casos, construídos com os formatos que aparecem em atendimento, contrato e cadastro no Brasil. Motor spaCy pt_core_news_sm, idioma português.

caso detectou como classificou
CPF formatado 529.982.247-25 não
CPF sem máscara 52998224725 não
CNPJ formatado 11.222.333/0001-81 não
CNPJ sem máscara 11222333000181 não
placa Mercosul BRA2E19 não
telefone (54) 99251-3223 sim PHONE_NUMBER
e-mail sim EMAIL_ADDRESS, ORGANIZATION, URL
CEP 95020-000 sim LOCATION
RG 12.345.678-9 sim PERSON
cartão 4111 1111 1111 1111 sim LOCATION
nome próprio sim PERSON

Seis de onze. E os cinco que faltam são justamente os identificadores nacionais.

O problema não é só o que ele perde

Repare nas duas linhas em negrito.

Cartão de crédito classificado como LOCATION. Se a sua política mascara CREDIT_CARD com um formato e LOCATION com outro — ou não mascara localização de jeito nenhum, o que é comum — o número do cartão sai inteiro.

RG classificado como PERSON. Mesma coisa: a regra que você escreveu para nome de pessoa vai ser aplicada a um número de documento.

Detecção com tipo errado é pior que não detecção, porque não aparece no relatório como falha. O contador de PII detectado sobe, o dado sai mesmo assim, e ninguém procura.

3. Os reconhecedores que faltam

CPF e CNPJ têm dígito verificador. Isso importa: um reconhecedor que só casa "onze dígitos" acusa número de pedido, código de rastreio e identificador interno. Com validação de dígito, ele só acusa o que é.

class CPFRecognizer(PatternRecognizer):
    PATTERNS = [
        Pattern("CPF mascarado", r"\b\d{3}\.\d{3}\.\d{3}-\d{2}\b", 0.6),
        Pattern("CPF cru",       r"\b\d{11}\b",                     0.3),
    ]
    CONTEXT = ["cpf", "documento", "contribuinte", "titular"]

    def validate_result(self, texto):
        n = "".join(c for c in texto if c.isdigit())
        return _dv_cpf(n) if len(n) == 11 else False

Dois detalhes de desenho valem explicação.

A confiança do padrão sem máscara é mais baixa — 0,3 contra 0,6. Onze dígitos soltos são ambíguos; com a máscara, quase nunca. O CONTEXT recupera a diferença: se a palavra "CPF" aparece perto, a confiança sobe.

O validate_result é o que evita o falso positivo. Sem ele, todo número de onze dígitos vira PII, e aí o time desliga a anonimização inteira porque ela atrapalha mais do que ajuda.

O mesmo para CNPJ, e um terceiro para placa nos dois formatos — Mercosul e o antigo.

4. O que muda depois

caso antes depois
CPF formatado não BR_CPF
CPF sem máscara não BR_CPF
CNPJ formatado não BR_CNPJ
CNPJ sem máscara não BR_CNPJ
placa Mercosul não BR_PLACA
111.111.111-11 (inválido) não não — dígito rejeita
52998224726 (não é CPF) não não — dígito rejeita

As duas últimas linhas são o ponto. Detectar CPF é fácil; detectar CPF sem acusar todo número de onze dígitos é o que faz alguém deixar a anonimização ligada.

5. O custo em latência

Essa é a parte que decide onde a anonimização entra no caminho.

texto sem os reconhecedores com os três
curto (~55 caracteres) 4,48 ms 4,64 ms
longo (~3.240 caracteres) 89,6 ms

Os três reconhecedores custam 0,16 ms. São regex mais uma validação aritmética; o custo é irrelevante perto do resto.

O que custa é o Presidio em si, e ele escala com o tamanho do texto: 4,5 ms num trecho curto, quase 90 ms num texto de três mil caracteres. Isso é análise de linguagem natural, não casamento de padrão.

E aí está a implicação prática. No post sobre o overhead do gateway eu medi cerca de 10 ms de camada. Somar anonimização num prompt longo pode adicionar quase dez vezes isso, e passa a ser o item mais caro do caminho antes do modelo.

Duas consequências:

  • Anonimize a rota, não tudo. Ligue no que carrega dado de cliente; deixe fora do resto. No gateway isso é uma linha por alias.
  • Meça no seu tamanho de prompt. 90 ms veio de três mil caracteres. Se o seu prompt tem vinte mil, o número é outro.

Condições da medição: máquina de desenvolvimento Linux, spaCy pt_core_news_sm, 200 execuções para o texto curto e 50 para o longo, uma rodada. Ordem de grandeza, não medição citável.

6. O que anonimização não resolve

Vale repetir, porque é o mal-entendido mais caro do tema.

Anonimização remove identificador. Ela funciona bem para CPF, e-mail, telefone, nome — dado pessoal, que é o que a LGPD trata.

Ela não resolve segredo industrial. Não existe como anonimizar a lógica de um algoritmo proprietário, uma especificação de engenharia ou uma estrutura de custo sem destruir a pergunta que você está fazendo ao modelo. Se o problema é esse, a resposta é modelo local, não redação.

E ela não é garantia. É redução de risco medida — que é melhor que política escrita, e menos que dado que não sai.

7. Onde isso entra

No gateway, como guardrail em modo pre_call, ligado por chave virtual. A aplicação não muda; a rota que precisa de anonimização recebe uma chave que a tem, e as outras não.

Os três reconhecedores estão em redaction/ no repositório aberto, junto com o script de diagnóstico e o stack do gateway.

Antes de ligar em qualquer lugar, rode nos seus dados. Onze casos construídos medem cobertura de formato, não recall em texto real de produção — e o seu domínio tem formato que o meu não tem.

Como ajudamos times a adotar IA

Trabalhamos com times de engenharia que buscam incorporar IA ao dia a dia de desenvolvimento — não como experimento, mas como parte real do fluxo de trabalho.

Isso passa por escolher as ferramentas certas para o contexto do time, configurá-las de forma que façam sentido para a política de dados da empresa e garantir que os desenvolvedores saibam usá-las de um jeito que realmente aumente a produtividade, em vez de gerar mais fricção.

Se você tem um time de desenvolvimento e está tentando colocar IA para trabalhar de forma séria, fale com a gente.