Google está tornando a IA privada prática com criptografia homomórfica

A iniciativa do Google de usar criptografia homomórfica totalmente homomórfica (FHE) para “IA privada” busca permitir que modelos em nuvem operem sobre dados criptografados pelo usuário, de modo que os provedores nunca vejam o texto claro, potencialmente liberando casos de uso regulados em saúde, finanças e outros domínios sensíveis. Os comentaristas reconhecem a solidez criptográfica e o valor de nicho da FHE, mas enfatizam sua severa sobrecarga de desempenho — frequentemente de ordens de grandeza — e observam que executar modelos localmente ainda é a forma mais direta de obter privacidade. Muitos também são céticos de que uma empresa orientada por publicidade como o Google implantará essa tecnologia de maneiras que realmente priorizem a privacidade do usuário em vez da coleta e monetização de dados.

Sentimento geral

  • Misto a negativo em relação ao Google como guardião; mais positivo em relação à criptografia subjacente.
  • Muitos veem isso como tecnicamente impressionante, mas comercialmente de nicho e potencialmente mal enquadrado como “IA privada” enquanto mantém o controle na nuvem.

Confiança, motivações e enquadramento de privacidade

  • Forte desconfiança do Google como empresa de publicidade; receio de que a FHE seja usada para justificar um uso de dados mais disseminado (“nós nunca vemos seus dados, apenas os sinais”).
  • Alguns argumentam que o projeto é open source, então a tecnologia pode beneficiar outros e não precisa depender de confiar no Google.
  • Vários observam que a criptografia só resolve a confidencialidade; ainda se perde disponibilidade/controle se a conta for bloqueada ou o serviço for encerrado.

O que a FHE realmente fornece (e o que não fornece)

  • A FHE permite que servidores computem sobre texto cifrado sem ver o texto claro, assumindo hipóteses padrão de dificuldade (por exemplo, LWE/RLWE).
  • Ela garante o sigilo das entradas/saídas, mas não que o servidor executou a computação pretendida. Computação verificável/atestada é um problema separado.
  • Esclarecimentos de que a FHE adequada ainda pode satisfazer indistinguibilidade de ruído (IND-CPA); vários comentaristas corrigem mal-entendidos aqui.

Desempenho e praticidade

  • Custos adicionais citados variam de ~10×–100× (otimista para ML ajustado) até 10³–10⁶× em muitas configurações reais; latências benchmarkadas vão de segundos a minutos por inferência ou operação.
  • Ordenação, ramificações e divisão são particularmente lentas; álgebra linear e cargas de trabalho simples de adição/multiplicação são relativamente mais favoráveis.
  • Trabalho contínuo em aceleração por GPU e ASIC é mencionado, mas muitos ainda veem isso como longe de ser viável para LLMs grandes.

Casos de uso vs. computação local

  • Aplicações sugeridas: autenticação biométrica, verificação de vazamento de senhas, consultas médicas e de DNA, detecção de fraude financeira, transferências entre bancos, publicidade privada direcionada, verificações no estilo “have I been pwned”.
  • Alguns argumentam que a maioria desses casos é melhor resolvida por computação local, TEEs ou controles legais/contratuais, especialmente dado o custo.
  • Outros observam que a FHE pode viabilizar cargas de trabalho reguladas (saúde, finanças) em que a computação local ou on-prem nem sempre é viável ou em que a agregação de dados entre múltiplas partes é necessária.

Modelos alternativos e ecossistema

  • Comparações com enclaves seguros/TEEs: mais baratos e rápidos, mas dependem da confiança no fornecedor de hardware e no operador, e são frequentemente quebrados por canais laterais.
  • Vários veem isso como pesquisa necessária de “criptografia programável”, mesmo que a implantação de curto prazo seja limitada. Outros descartam isso como “teatro de pesquisa” do Google para impressionar executivos focados em IA.