Capítulo 8 — Anonimização de Dados no Pipeline RAG

Oitavo post do passeio capítulo a capítulo pelo LLM Primer III: Aprimorando a IA Empresarial com RAG. Os dados devem ser anonimizados antes do modelo ver, ou antes do usuário ver a saída? A resposta muda tudo sobre o pipeline, e o regime regulatório costuma escolher a resposta por você.

Por que este capítulo existe

O Capítulo 7 respondeu quem pode ver o quê. Assumia que havia algo a bloquear. Mas o Capítulo 6 também mostrou que o embedding não é uma função de mão única — o vector store é uma cópia borrada da fonte, e controle de acesso é só a camada externa. Se o corpus contém CPFs, entradas de prontuário médico, nomes de cliente ou caminhos de código proprietário, a pergunta não é mais só quem tem permissão de recuperá-los. É se eles deveriam ter sido embedados nessa forma para começo de conversa.

Essa é a pergunta da anonimização, e é a decisão de segurança mais pesada em engenharia numa implantação de RAG. A escolha é posicional antes de ser algorítmica: em que estágio o conteúdo sensível é transformado?

8.1 Pré-geração versus pós-geração

A anonimização pré-geração transforma os dados antes de embedar e armazenar. O vector store nunca contém os valores sensíveis originais; mesmo um comprometimento total na camada do modelo não extrai o que nunca esteve lá. É a arquitetura mandatória para muitos RAGs médicos cobertos por HIPAA e várias aplicações jurídicas sob GDPR. O custo é qualidade de recuperação: a query diz "Acme Corp" mas o corpus dizia "[ORG_47]" antes de embedar, e a similaridade densa cai justamente no token mais informativo.

A anonimização pós-geração roda sobre a saída do modelo. Qualidade de recuperação é preservada; a garantia de privacidade é mais fraca porque o dado sensível está no índice. É apropriada quando o modelo de ameaças é vazamento voltado ao usuário em vez de voltado à infraestrutura. A maioria dos sistemas em produção termina usando uma combinação — identificadores diretos e categorias de alto peso regulatório tratados na pré-geração, sensibilidades operacionais de menor peso mascaradas na saída com base no perfil de autorização do usuário. Duas disciplinas de implementação importam: rode anonimização antes do chunking (senão o chunker destrói o contexto que o detector precisa), e mantenha um cofre de detokenização como tabela de mapeamento separada e controlada por acesso, para que um médico com o papel certo ainda consiga ver o identificador do paciente que o índice mascarou.

8.2 Mascaramento, substituição sintética, privacidade diferencial

As técnicas se dividem em três famílias num único botão. Mascaramento de PII detecta entidades (Microsoft Presidio é a implementação aberta mais amplamente implantada) e as substitui por placeholders. Os problemas difíceis são recall — um detector que perde dez por cento dos nomes produz documentos redigidos que um atacante consegue localizar via similaridade de embedding — e supermascaramento, que colapsa o vocabulário e prejudica a recuperação. A disciplina é dupla medição: recall num conjunto rotulado e um benchmark offline de qualidade de recuperação.

Substituição sintética substitui por um valor falso plausível em vez de um placeholder, então "João Silva" vira "Alex Romano" em vez de [NOME]. O embedding fica bem distribuído e lê naturalmente para o modelo. O mapeamento é determinístico — um hash com chave da entidade real para a falsa — para que a mesma entidade real ganhe a mesma falsa ao longo do corpus, e a chave mora no cofre. Substituição sintética ainda vaza contra um adversário com informação auxiliar, mas é uma melhoria significativa em relação ao mascaramento quando qualidade de recuperação importa.

Privacidade diferencial é a família que oferece uma garantia matemática de verdade — um mecanismo é ε-DP se a distribuição da saída muda no máximo por exp(ε) quando um único registro é adicionado ou removido. DP-Prompt perturba os chunks selecionados para o prompt; DP-MLM perturba o passo de embedding do modelo de linguagem mascarada; 1-Diffractor combina DP com reescrita preservadora de semântica. DP é um orçamento, não um interruptor — toda query gasta um pouco, e a disciplina operacional é em grande parte contabilidade de orçamento. As três famílias compõem, e a implantação certa em geral empilha as três.

8.3 O tradeoff utilidade-privacidade

Os tokens mais valiosos para anonimizar são os tokens cuja anonimização mais prejudica a recuperação. A assimetria é infeliz mas não negociável. Mitigações são parciais: substituição sintética preserva mais sinal do que placeholders; placeholders com tipo ([PESSOA chamada Alex] em vez de [PESSOA]) preservam ainda mais, ao custo de mascaramento mais fraco. Corpora anonimizados frequentemente pedem chunks ligeiramente maiores do que os não anonimizados, porque a perda da redação se amortiza sobre mais conteúdo sobrevivente.

O enquadramento honesto é que o tradeoff não é um botão de eixo único, e sim uma superfície bidimensional — o chão regulatório abaixo do qual o sistema é ilegal, o chão de utilidade abaixo do qual usuários abandonam, e a região operacional entre os dois. Às vezes o gap é largo e vários designs funcionam. Às vezes o gap é vazio: o chão regulatório está acima do chão de utilidade, e a coisa mais valiosa que a fase de design faz é reconhecer isso antes de afundar esforço num sistema que não pode ser construído.

8.4 Integração empresarial e como escolher o design

Zilliz Cloud expõe anonimização como transformação de pipeline entre parser e embedder, com hooks em quatro checkpoints (ingestão, recuperação, detokenização, saída). PII Masker tem formato oposto — um bloco focado que times compõem nos próprios pipelines. Implantações maduras frequentemente constroem um serviço centralizado de anonimização com quatro operações: anonimizar um documento parseado, consultar detokenização sob um contexto de autorização, varrer uma string de saída por conteúdo sensível residual, e reportar o orçamento de privacidade consumido.

A decisão de design parte da regulação, não do algoritmo. Safe Harbor do HIPAA mapeia limpo em mascaramento de PII com lista fixa de dezoito categorias. PCI DSS é satisfeito por tokenização — substituição sintética mais cofre. O princípio de minimização de dados do GDPR empurra para pré-geração nas categorias mais sensíveis. Privacidade diferencial não é mandatária em nenhuma grande regulação, mas é a resposta certa quando o modelo de ameaças inclui um adversário sofisticado com dados auxiliares e o corpus contém registros que seriam reportáveis a reguladores se reidentificados.

O que o Capítulo 8 prepara

Os Capítulos 7 e 8 juntos completam a Parte IV. Controle de acesso responde quem pode ver o quê; anonimização responde o que está lá para ver, em primeiro lugar. Os dois são decisões de infraestrutura que o resto do pipeline tem que respeitar, e os dois dependem de escolhas feitas no tempo de parsing e chunking que não dá para reverter barato depois. Com o sistema desenhado e protegido, a próxima pergunta é se ele funciona — e isso exige um jeito de medi-lo.

Próximo — Capítulo 9: A Tríade de Avaliação de RAG. Relevância de contexto, fidelidade e relevância da resposta — três sinais independentes que, juntos, dizem ao operador se o sistema está falhando na recuperação, na geração ou na conexão entre os dois.