A equipe de engenharia da Meta publicou um relato arquitetural do Private Processing, o sistema de computação confidencial que está sendo estendido do WhatsApp e do app Meta AI para os AI Glasses, descrevendo como a empresa pretende executar cargas de trabalho de IA stateful e personalizadas — transcrição em streaming, busca contextual, memória de longo prazo — na nuvem sem que a própria Meta consiga ler os dados subjacentes. O post, assinado por Pritam Shah e Oskar Linde no blog de engenharia da Meta, expõe o problema de forma direta: os óculos não conseguem hospedar localmente modelos grandes o suficiente para esses recursos, então o processamento precisa migrar para a nuvem, e a nuvem precisa ser redesenhada para não conseguir ver o que está processando.

O mecanismo se apoia em trusted execution environments, ou TEEs — hardware presente em determinadas CPUs e GPUs que criptografa a memória de uma máquina virtual confidencial (CVM) sob uma chave mantida por silício dedicado, nunca revelada ao sistema operacional host, ao hypervisor ou ao operador da infraestrutura. O post da Meta cita as três garantias do Confidential Computing Consortium para esse modelo: confidencialidade dos dados (ninguém fora da CVM pode ler a memória em uso), integridade dos dados (ninguém de fora pode alterá-la) e integridade do código (ninguém pode modificar o código em execução). Antes de um dispositivo de óculos enviar qualquer contexto pessoal, ele realiza uma atestação remota via TLS — exigindo um certificado assinado por hardware do TEE do servidor e, em seguida, verificando os hashes binários do TEE em relação ao que a Meta chama de um registro de transparência público e independente. Se a verificação do certificado do fornecedor falhar ou o hash não corresponder ao registro, afirma o post, o handshake falha e o dispositivo não se conecta.

A camada de roteamento foi construída para impedir que a própria infraestrutura da Meta associe uma solicitação a uma identidade. Segundo o post, os dispositivos usam credenciais anônimas — tokens assinados cegamente (blind-signed), obtidos em cronogramas randomizados — de modo que o serviço de autenticação não consiga vincular uma solicitação a uma conta, conectando-se então por meio de um relay OHTTP de terceiros (o post cita Fastly ou Cloudflare) para selecionar um nó TEE usando heurísticas que não identificam o usuário. Essa é a propriedade de "não rastreabilidade" ("non-targetability") que a Meta lista como um dos cinco requisitos de engenharia do sistema, ao lado de isolamento de hardware, garantias de fail-closed, verificabilidade pública e armazenamento criptografado.

A memória persistente — o recurso que permite a um assistente lembrar algo de uma sessão anterior — é tratada colocando-se o mecanismo de armazenamento dentro do próprio TEE, em vez de em um banco de dados criptografado externo. O post da Meta argumenta que essa escolha de design é imposta por dois modos de falha identificados na abordagem convencional: o vazamento de padrão de acesso, em que mesmo bancos de dados fortemente criptografados ainda revelam quando e com que frequência um usuário faz consultas, mapeando o comportamento diário apenas por meio de metadados; e o colapso de escalabilidade, em que a busca vetorial semântica ou junções entre múltiplas sessões sobre armazenamento criptografado exigem transferir o texto cifrado pela rede e descriptografá-lo a cada consulta, causando "picos de latência" à medida que o contexto cresce. Colocar a execução e o estado lado a lado dentro da memória criptografada pelo processador, diz o post, significa que as leituras nunca cruzam uma fronteira de rede externa.

O custo operacional desse design aparece na observabilidade, e o post é franco a respeito. Os diagnósticos de engenharia padrão não funcionam dentro de um TEE: não é possível anexar um debugger, gerar memory dumps em caso de falha, nem inspecionar o payload que causou o erro. A Meta afirma que construiu seu monitoramento apenas em torno de sinais agregados de integridade — utilização de CPU, alocação de memória, latência de rede e taxas de falha de hardware —, o que significa que os engenheiros resolvem problemas em um sistema de produção para consultas dos AI Glasses sem nunca ver uma solicitação que falhou.

O post não cita números de benchmark, dados de latência, custo ou contagens de parâmetros para os modelos que rodam dentro dessas CVMs — uma omissão notável para um texto voltado a afirmações de escala. O que ele de fato assume é a validação por terceiros: a Meta diz que faz parceria com empresas de segurança independentes, incluindo a NCC Group, para auditar a lógica de atestação e o modelo de isolamento, e está expandindo seu programa de Bug Bounty para cobrir explicitamente o Private Processing nos AI Glasses, fornecendo a pesquisadores externos binários de CVM e documentação para testar a cadeia de atestação. O post também sinaliza onde o design ainda é aspiracional, e não algo já entregue: descreve o Private Processing, até o momento, como capaz de lidar com "tarefas discretas, como resumir uma mensagem", ao mesmo tempo em que enquadra o uso multissessão e agentivo — um agente mantendo estado sensível em contextos do mundo real — como uma extensão futura que exige atestação entre CVMs (inter-CVM) ainda não totalmente especificada aqui.

Para equipes que constroem inferência dividida entre dispositivo e nuvem para wearables, a lição operacional está menos nos primitivos criptográficos e mais no custo de depuração: se sua fronteira de confiança exclui os próprios engenheiros da inspeção de payloads em tempo real, a resposta a incidentes precisa ser redesenhada em torno de telemetria agregada antes do lançamento, não depois da primeira falha em produção.