Detecção e mascaramento de PII em pipelines de IA

O artigo executivo "Privacidade de dados na era da IA" trata da decisão: quais dados a empresa pode expor a um modelo, sob qual base legal, e quem responde se algo vazar. Este texto trata da implementação: como um pipeline detecta, mascara e — quando autorizado — reidentifica dados pessoais antes e depois da inferência.

O problema não é achar PII óbvia

CPF, e-mail e telefone são fáceis. O risco real está no que passa despercebido: nome próprio em texto livre, endereço em um campo de observação, número de cartão fragmentado em duas colunas, ou um ID interno que, cruzado com outra base, reidentifica alguém. Um pipeline de proteção de PII precisa de camadas, não de uma lista de regex.

Camada 1 — Regex e padrões estruturados

Regex ainda é a primeira linha de defesa para campos com formato conhecido: CPF, CNPJ, cartão de crédito, e-mail, telefone, CEP, placas de veículo. É rápido, determinístico e barato de rodar em volume.

CPF:      \b\d{3}\.?\d{3}\.?\d{3}-?\d{2}\b
CARTAO:   \b(?:\d[ -]*?){13,19}\b
EMAIL:    [a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}

O problema de regex isolado: falso positivo (um número de pedido de 11 dígitos parece CPF) e falso negativo (CPF sem formatação em meio a texto). Por isso regex nunca deve ser a única camada em dados que alimentam decisão automatizada.

Camada 2 — Validação por checksum

Documentos como CPF, CNPJ e cartão de crédito têm dígito verificador. Aplicar o algoritmo de checksum depois do match de regex elimina boa parte dos falsos positivos sem custo de modelo:

def cpf_valido(cpf: str) -> bool:
    digitos = [int(d) for d in cpf if d.isdigit()]
    if len(digitos) != 11 or len(set(digitos)) == 1:
        return False
    for i in (9, 10):
        soma = sum(d * (i + 1 - idx) for idx, d in enumerate(digitos[:i]))
        resto = (soma * 10) % 11
        if resto == 10:
            resto = 0
        if resto != digitos[i]:
            return False
    return True

O mesmo vale para cartão (algoritmo de Luhn) e CNPJ. Um candidato de regex que falha no checksum é descartado ou rebaixado de confiança antes de chegar à camada de NER.

Camada 3 — NER para texto livre

Nome, endereço, cargo e outras PII sem formato fixo exigem reconhecimento de entidades nomeadas. Um modelo de NER (spaCy, um modelo transformer fine-tuned, ou um serviço gerenciado) roda sobre campos de texto livre — descrição de ticket, transcrição de atendimento, campo de observação — e marca spans com tipo de entidade e score de confiança.

Ponto de atenção de engenharia: NER tem custo de latência e de infraestrutura muito maior que regex. A prática recomendada é rodar regex+checksum primeiro sobre todo o volume, e reservar NER para os campos identificados como texto livre e para amostragem de auditoria sobre campos estruturados, evitando rodar o modelo pesado em tudo.

Pseudonimização reversível vs. irreversível

Depois de detectada, a PII precisa ser tratada de acordo com o uso posterior:

A regra prática: se o caso de uso não precisa do dado original, não use uma técnica reversível. Pseudonimização reversível é responsabilidade adicional — cofre de chaves, controle de acesso, log de quem reidentificou o quê e quando.

Mascaramento antes da inferência

O ponto de decisão mais importante do pipeline é: o mascaramento acontece antes de o dado sair da borda de confiança da empresa ou depois? Para chamadas a modelos de terceiros (LLM como serviço, API de terceiro), a resposta correta é sempre antes. O fluxo típico:

1. 1.Dado bruto chega ao pipeline.
2. 2.Camada de detecção (regex + checksum + NER) marca spans de PII.
3. 3.Camada de mascaramento substitui os spans por token reversível (se o caso de uso exigir religar a resposta ao registro original) ou por rótulo fixo.
4. 4.O texto mascarado é o que vai para o modelo — interno ou de terceiro.
5. 5.Se a resposta do modelo precisa ser reassociada ao registro original, a reidentificação acontece depois, dentro da borda de confiança, nunca no provedor externo.

Reidentificação controlada

Reidentificação não deve ser uma função disponível para qualquer serviço que consome o pipeline. Trate como uma operação privilegiada:

• Autorização explícita por papel — não por posse de token.
• Registro de toda reidentificação: quem, quando, qual registro, qual justificativa.
• Expiração do vínculo token → valor original quando o prazo de retenção do dado se esgota.

Minimização e retenção

Detectar PII não é desculpa para guardá-la "só por garantia". Dois princípios de engenharia:

• Minimização na entrada: se o campo não é necessário para o caso de uso, ele nem entra no pipeline — filtro na ingestão, não na saída.
• Retenção com expiração automática: cada dado pseudonimizado carrega uma data de expiração vinculada à finalidade que justificou sua coleta. Job de expurgo roda periodicamente e remove tanto o dado quanto o vínculo de reidentificação.

Atendimento a direitos do titular (LGPD/GDPR)

Um pipeline bem desenhado responde a três pedidos sem intervenção manual em cada registro:

• Acesso: localizar todos os registros pseudonimizados associados a um titular, dado seu identificador original.
• Correção: atualizar o valor original sem quebrar o vínculo de tokens já emitidos.
• Eliminação: apagar o valor original e invalidar todos os tokens associados, mantendo o rastro de que uma eliminação ocorreu (sem manter o dado em si).

Isso só é viável se o índice de tokenização for desenhado desde o início com a chave de titular como campo de busca — não como algo adicionado depois que o primeiro pedido de acesso chegar.

O que fazer na segunda-feira

• Levante os campos de texto livre em produção e rode um teste de amostragem com NER para medir quanta PII não estruturada está passando despercebida hoje.
• Adicione validação de checksum a qualquer detector de CPF/CNPJ/cartão já existente — é a mudança de menor esforço com maior redução de falso positivo.
• Confirme se alguma chamada a LLM de terceiro está enviando campos não mascarados; se estiver, isso é prioridade de correção antes de qualquer outro item desta lista.
• Documente, para cada tipo de PII em uso, se a pseudonimização aplicada é reversível e quem tem autorização para reidentificar.

Leitura complementar

Trilha executiva:

• Privacidade de dados na era da IA: LGPD e GDPR na prática — a leitura de negócio deste mesmo tema.