Resumo Técnico: SurrogateShield

Definição do Problema

Assistentes de Large Language Models (LLMs) transmitem consultas de usuários de forma literal para endpoints de APIs de terceiros, expondo Informações de Identificação Pessoal (PII) a riscos de violações de dados, intimações judiciais ou mudanças de políticas. A mitigação predominante, a redação por placeholders (ex: substituir "João Silva" por [PESSOA]), preserva a privacidade por construção, mas destrói a coerência semântica. Essa degradação estrutural força o LLM a processar consultas "estruturalmente degradadas", resultando em respostas correspondentemente degradadas e perda mensurável de utilidade em tarefas downstream. O desafio central é evitar que PII real atravesse o limite da rede sem sacrificar a utilidade semântica necessária para interações de alta qualidade com LLMs.

Metodologia: SurrogateShield

O SurrogateShield é um proxy do lado do cliente que intercepta consultas de LLM, substitui PII detectado por valores substitutos (surrogates) gerados localmente e consistentes em tipo, e restaura transparentemente os valores originais na resposta antes da exibção. O sistema opera sobre três princípios de design:

1. Nenhuma PII atravessa o limite da API: A aplicação ocorre na camada de transporte local antes da construção da requisição HTTP.
2. Substitutos preservam a utilidade: Valores falsos (ex: nomes, SSNs) são realistas, consistentes em tipo e estatisticamente não vinculados ao original, preservando a estrutura de frase e a concordância gramatical.
3. Restauração transparente: Os valores originais são restaurados na resposta do LLM via um ResolvePass de três passagens antes que o usuário veja a saída.

Arquitetura do Sistema

O pipeline consiste em quatro componentes primários:

1. SentinelLayer (Cascata de Detecção de Três Estágios)
A detecção ocorre através de uma cascata sequencial onde cada estágio mascara spans de caracteres reivindicados para evitar o processamento duplo:

• PatternScan: Aplica expressões regulares ordenadas por prioridade com validadores de checksum (Luhn para cartões de crédito, ABA para números de roteamento) para detectar 16 tipos estruturados de PII (ex: SSN, e-mail, endereços de cripto).
• EntityTrace: Utiliza spaCy (en_core_web_lg) para Reconhecimento de Entidades Nomeadas (NER) no texto restante. Classifica entidades em "confirmadas" (score ≥0,85) e "limítrofes" (0,60–0,85). Inclui lógica de reclassificação (ex: promover organizações a entidades geopolíticas se houver preposições de localização) e blocklists para suprimir falsos positivos comuns.
• ContextGuard: Executa um modelo NER DistilBERT hospedado localmente (dslim/distilbert-NER) para verificar entidades limítrofes e detectar entidades omitidas. Este estágio roda inteiramente offline após o download inicial do modelo.

2. Inteligência de Consulta de Serviço e Risco de Quase-Identificador

• ServiceQueryDetector: Distingue entre consultas onde a localização é o tópico (ex: "restaurantes perto de X") versus consultas onde a localização identifica o usuário. Para consultas de serviço, aplica anonimização proporcional (ex: deslocando números de residência em ±2–8) em vez de substituição total para manter a utilidade.
• Quasi-Identifier Risk Detector: Baseado no framework de k-anonimato de Sweeney, detecta combinações de campos (ex: CEP + Data de Nascimento + gênero) que poderiam reidentificar estatisticamente um usuário, mesmo que os campos individuais não sejam PII tradicionais.

3. MimicGen (Geração de Substitutos)
Gera substitutos consistentes em tipo usando a biblioteca faker e lógica customizada. Garante resistência a colisões dentro de uma sessão e valida formatos (ex: checksums Luhn válidos para cartões de crédito, codificação Base58 para endereços de Bitcoin).

4. ShadowMap & ResolvePass

• ShadowMap: Um dicionário em memória por conversa que mapeia substitutos para originais, persistido como um arquivo binário criptografado via AES-256-GCM. As chaves são derivadas via HKDF-SHA256 de um segredo de nível de dispositivo.
• Dual History: O sistema mantém dois históricos de mensagens: api_messages (apenas substitutos, enviados para a API) e messages (valores reais restaurados, mostrados ao usuário). Isso evita o acúmulo de PII em contextos de múltiplos turnos.
• ResolvePass: Restaura os originais na resposta do LLM usando três passagens: correspondência exata (primeiro a mais longa), correspondência de componente (para uso parcial de nomes) e correspondência difusa (usando rapidfuzz).

Principais Contribuições

1. Sistema SurrogateShield: O primeiro proxy end-to-end do lado do cliente implementando substituição de substitutos consistentes em tipo com mapeamento criptograficamente seguro e reconstrução de resposta transparente.
2. Cascata de Detecção: Um pipeline novel de três estágios combinando regex, spaCy NER e DistilBERT NER local, aumentado por uma suíte de pós-processamento para deduplicação e filtragem tópica.
3. Validação de Utilidade Empírica: Demonstração de que a substituição por substitutos supera significativamente a redação por placeholders em utilidade semântica, medida via BERTScore.
4. Robustez Adversária: Evidência empírica de que mensagens substituídas por substitutos resistem à recuperação adversária baseada em LLM, enquanto tokens de placeholder expõem as localizações dos slots para inferência.
5. Análise de Ablação: Quantificação da contribuição marginal de F1 de cada estágio de detecção, identificando o papel específico do PatternScan (PII estruturado), EntityTrace (entidades nomeadas) e ContextGuard (localizações limítrofes).

Resultados Experimentais

Avaliado em um corpus de 1.124 consultas anotadas (sintéticas, mas estruturalmente realistas):

• Qualidade de Detecção: A cascata completa alcançou um F1 score de 98,87%. O SurrogateShield igualou ou excedeu o Microsoft Presidio em todos os 11 tipos de entidades comparáveis, com ganhos significativos em identificadores estruturados como Carteiras de Motorista dos EUA (+50,00 pp F1) e endereços de Cripto (+45,45 pp F1).
• Utilidade Semântica: O SurrogateShield preservou 94,85% da utilidade semântica (BERTScore F1), comparado a 81,59% para a redação por placeholder (uma melhora de 13,26 pontos percentuais, $p < 0,001$).
• Garantias de Privacidade:
  • Taxa de Vazamento de PII: 0,00% (nenhuma PII real chegou à API no corpus de 1.124 consultas).
  • Taxa de Vazamento de Resolução (Resolve-Leak): 0,00% (nenhum substituto permaneceu não restaurado na exibição final).
  • Recuperação Adversária: Em um teste de 100 consultas contra um adversário de LLM instigado (Claude Haiku), a taxa de recuperação para mensagens com substitutos foi de 0,00%, comparado a 1,53% para mensagens com redação por placeholder.
• Performance: O overhead total de processamento local foi de 25,89 ms por consulta (dominado pelo spaCy NER com 24,60 ms), o que é insignificante comparado às latências típicas de APIs de LLM (600–2.000 ms).

Significância e Alegações

O artigo argumenta que o trade-off entre privacidade e utilidade em interações com LLM não é fundamental. O SurrogateShield demonstra que a privacidade requer a ausência de valores de PII reais, não a ausência de uma estrutura de formato PII.

Ao substituir valores reais por substitutos consistentes em tipo, o sistema satisfaz a restrição de contenção (nenhuma PII real sai do dispositivo) enquanto preserva a integridade estrutural e semântica necessária para respostas de alta qualidade do LLM. Os autores alegam que este é o primeiro sistema a validar empiricamente que esse espaço de design é viável, alcançando maior utilidade e maior resistência adversária do que a abordagem de redação por placeholder predominante, operando inteiramente de forma local com overhead de latência mínimo. O trabalho desafia a suposição de que a degradação semântica é um custo necessário para interações com LLM que preservam a privacidade.