LLM-Redactor: An Empirical Evaluation of Eight Techniques for Privacy-Preserving LLM Requests

Título: LLM-Redactor: Uma Avaliação Empírica de Oito Técnicas para Solicitações de LLM com Preservação de Privacidade

1. O Problema

Agentes de codificação e aplicações impulsionadas por Grandes Modelos de Linguagem (LLMs) enviam rotineiramente conteúdo potencialmente sensível para APIs de LLM na nuvem. Esses dados podem ser registrados, retidos, utilizados para treinamento de modelos ou sujeitos a ordens judiciais.

• Limitação das Ferramentas Atuais: A proteção existente foca apenas na criptografia de nível de rede (TLS) e em ferramentas de Prevenção de Perda de Dados (DLP) organizacionais. O TLS protege contra observadores passivos, mas não contra o provedor do serviço em nuvem. As ferramentas DLP focam em dados em repouso ou em controle de versão, não no conteúdo transitório das solicitações de API.
• Lacuna: Falta um framework sistemático e uma implementação de referência que atue diretamente no pipeline de solicitações do LLM para proteger o conteúdo das prompts (pedidos) antes de serem enviadas.

2. Metodologia

Os autores desenvolveram o LLM-Redactor, um "shim" (camada de compatibilidade) de código aberto compatível com o protocolo MCP e APIs compatíveis com OpenAI. O sistema implementa e avalia oito técnicas distintas de preservação de privacidade.

As Oito Técnicas Avaliadas:

1. A) Inferência Local: Processamento completo no dispositivo do usuário (sem envio à nuvem).
2. B) Redação com Restauração de Placeholders: Detecção de dados sensíveis (PII, segredos) e substituição por marcadores tipados (ex: <EMAIL_1>), que são restaurados na resposta.
3. C) Reparação Semântica: Reescrita da prompt por um modelo local para remover detalhes identificadores mantendo a questão técnica.
4. D) Inferência Hospedada em TEE (Trusted Execution Environment): Envio de texto plano para um enclave seguro (ex: AWS Nitro) onde o modelo roda.
5. E) Inferência Dividida (Split Inference): Execução das primeiras camadas do modelo localmente e envio apenas das ativações intermediárias para a nuvem.
6. F) Criptografia Homomórfica Total (FHE): Inferência realizada inteiramente sobre dados criptografados.
7. G) Compartilhamento Secreto via Computação Multi-Parte (MPC): Divisão da entrada entre servidores não colusivos.
8. H) Ruído de Privacidade Diferencial (DP): Adição de ruído calibrado a nível de palavra para ofuscar sinais residuais.

Configuração de Avaliação:

• Benchmark: 1.300 amostras com 4.014 anotações de "ground-truth" (dados reais de sensibilidade).
• Classes de Carga de Trabalho:
  1. Prosa rica em PII (nomes, emails, SSN).
  2. Configurações ricas em segredos (chaves de API, tokens).
  3. Prosa com identidade implícita (ex: "o CFO da empresa X cujo cônjuge trabalha na concorrente").
  4. Código proprietário (nomes de funções internas, esquemas de banco de dados).
• Métricas: Taxa de vazamento exato (texto verbatim), taxa de vazamento parcial, latência, custo e utilidade (qualidade da resposta).

3. Principais Contribuições

1. Taxonomia e Comparação: Uma organização clara de oito técnicas baseada em propriedades de privacidade, custo de utilidade e praticidade atual.
2. Modelo de Ameaça Definido: Especificação clara de quais ataques cada técnica mitiga (ex: exfiltração de logs, contaminação de treinamento, vazamento de placeholders).
3. Implementação de Referência: Um shim open-source com todas as opções ativáveis independentemente, suportando tanto MCP quanto HTTP.
4. Benchmark Padronizado: O primeiro conjunto de dados com anotações de ground-truth para comparar empiricamente essas técnicas em um cenário comum.
5. Regra de Decisão Prática: Um guia para profissionais selecionarem a combinação ideal baseada no orçamento de ameaça e na carga de trabalho.

4. Resultados Chave

Desempenho de Vazamento (Leak Rates)

• Nenhuma técnica única domina: O desempenho varia drasticamente dependendo do tipo de dados.
• Combinação Vencedora (Prática): A combinação A + B + C (Roteamento Local + Redação + Reparação Semântica) foi a mais eficaz.
  • PII (Prosa): Taxa de vazamento combinada de 0,6% e 0 vazamentos exatos em 500 amostras.
  • Código Proprietário: Taxa de vazamento de 31,3%.
  • Identidade Implícita: Permanece o maior desafio, com vazamento de 43,6% mesmo com a melhor combinação prática, pois a estrutura semântica que revela a identidade é preservada para manter a utilidade da prompt.
• Tecnologias Criptográficas (D, E, F, G): Oferecem proteção teórica forte (vazamento de 0% de tokens em E, F, G), mas são atualmente inviáveis para uso em escala de chat devido a custos computacionais proibitivos ou complexidade de infraestrutura.

Latência e Custo

• Redação (B): Adiciona <50ms de sobrecarga.
• Reparação Semântica (C): Adiciona ~1-2 segundos (devido à execução de um modelo local de 3B parâmetros).
• Roteamento Local (A): Adiciona ~300ms para classificação.
• Economia de Tokens: A redação (B) reduz o número de tokens enviados à nuvem em 4% a 12%, pois os placeholders são mais curtos que os dados originais.

Utilidade (Qualidade)

• A redação causa uma perda de qualidade moderada. Em avaliações cegas, modelos juízes preferiram a resposta da prompt original em 75-80% dos casos, pois a remoção de contexto (dados sensíveis) pode dificultar respostas específicas. No entanto, para cargas de trabalho focadas em privacidade, essa troca é considerada aceitável.

5. Significado e Conclusão

O artigo estabelece que não existe uma "bala de prata" para a privacidade em LLMs. A estratégia ótima depende do modelo de ameaça:

1. Para tolerância zero a vazamentos: Deve-se combinar Roteamento Local (A) para tarefas simples e Inferência em TEE (D) para tarefas complexas que exigem nuvem, recusando solicitações que não se encaixem em nenhum dos dois.
2. Para a maioria das implementações práticas: A combinação A + B + C oferece o melhor equilíbrio, eliminando vazamentos de PII explícitos com um custo de latência gerenciável.
3. Limitação Fundamental: Técnicas de transformação de conteúdo (redação, reescrita) não conseguem remover "identidade implícita" sem destruir a utilidade da tarefa. Para esses casos, apenas isolamento de hardware (TEE) ou não envio à nuvem são soluções viáveis.

O trabalho fornece ferramentas práticas para desenvolvedores implementarem privacidade no pipeline de LLMs hoje, enquanto destaca a necessidade de avanços em TEEs e criptografia homomórfica para o futuro. O código e os benchmarks estão disponíveis publicamente no GitHub.