Arquitetura combina atestação remota, enclaves, TPUs Trillium, canais criptografados e execução efêmera para processar consultas sensíveis do Gemini fora do dispositivo.
| Componente | Private AI Compute, infraestrutura de processamento de IA em nuvem baseada em TPUs Trillium, Titanium Intelligence Enclaves e nós confiáveis com TEE baseada em hardware AMD. |
| Vetor | Consultas de usuários são encaminhadas do cliente para um ambiente atestado, com conexão Noise, sessão Oak criptografada de ponta a ponta, canais ALTS internos e validação mútua entre cargas de trabalho. |
| Impacto | O desenho busca manter dados pessoais inacessíveis fora do ambiente protegido, inclusive para administração operacional comum, embora a avaliação externa tenha identificado risco baixo de canal lateral temporal no relé de ocultação de IP e problemas de atestação com potencial de negação de serviço. |
| Prioridade | Equipes que avaliam uso corporativo de IA devem revisar garantias de atestação, descarte de dados de sessão, separação entre autenticação e inferência, dependência de hardware proprietário e mitigação dos achados ainda em tratamento. |
| Artefatos | Noise protocol, Oak, ALTS, Confidential Federated Compute, autorização binária, IOMMU, relés de ocultação de IP operados por terceiros e Anonymous Tokens. |
| Limites | A arquitetura permanece centralizada em Borg Prime e depende de hardware proprietário; a própria avaliação registrou que a proteção contra exposição a processamento inesperado ou a terceiros é limitada se a organização inteira decidir alterar esse comportamento. |
O Private AI Compute foi apresentado como uma camada de computação confidencial para levar consultas de inteligência artificial ao poder de modelos Gemini em nuvem sem abandonar garantias semelhantes às de processamento local no dispositivo. A proposta é executar dados sensíveis em uma área de nuvem isolada, validada criptograficamente e projetada para reduzir o número de sistemas e operadores que precisam ser confiados para manter a confidencialidade. A base técnica combina TPUs Trillium, Titanium Intelligence Enclaves e nós confiáveis em uma TEE baseada em hardware AMD, com memória cifrada e separada do host.
A arquitetura não é descrita como simples criptografia de tráfego entre cliente e servidor. O fluxo envolve atestação do ambiente, validação de identidade do servidor, credenciais de carga de trabalho, canais internos protegidos e autorização binária para restringir o código autorizado. O objetivo operacional é que entradas de usuário, inferências de modelo e computações associadas existam apenas durante a sessão e sejam descartadas quando o processamento termina. Esse desenho limita a utilidade de acesso privilegiado tardio, porque dados anteriores não deveriam permanecer disponíveis para coleta retrospectiva.
A avaliação externa feita entre abril e setembro de 2025 encontrou pontos relevantes para análise de risco. Um canal lateral baseado em temporização no componente de relé de ocultação de IP poderia, em certas condições, ajudar a identificar usuários. O risco foi tratado como baixo porque o funcionamento multiusuário adiciona ruído e dificulta a correlação entre consulta e origem específica. Também foram identificadas três falhas na implementação de atestação com potencial de negação de serviço e ataques de protocolo, com mitigações ainda em andamento.
O caminho de uma consulta começa no cliente do usuário, que estabelece uma conexão criptografada pelo protocolo Noise com um servidor de frontend. Nesse estágio, ocorre atestação bidirecional, de modo que o cliente não apenas cifra o transporte, mas também valida se está se comunicando com um serviço esperado. A identidade do servidor é verificada por meio de uma sessão Oak criptografada de ponta a ponta e atestada, reduzindo a chance de envio de dados para um componente modificado ou não autorizado dentro da cadeia.
Depois da entrada no frontend, o servidor cria canais internos com outros serviços da linha de inferência usando ALTS. Esses serviços se comunicam com servidores de modelo executados na plataforma TPU reforçada. A comunicação entre nós confiáveis também usa atestação ponto a ponto e criptografia: cada carga de trabalho solicita e valida credenciais criptográficas da outra antes de aceitar a conexão. As credenciais só são emitidas quando a atestação do nó passa por comparação com valores internos de referência; falha nessa validação impede a formação do canal.
O isolamento depende de controles de execução e de infraestrutura. Apenas cargas de trabalho atestadas podem operar nos nós confiáveis, o acesso administrativo direto às cargas de trabalho é bloqueado e proteções físicas são citadas para reduzir risco de extração de dados. Entre as defesas aparecem criptografia de memória e proteções de IOMMU, usadas para limitar leitura indevida por componentes externos ao ambiente de execução. A autorização binária restringe o software e as configurações em execução ao que foi assinado, autorizado e validado na cadeia de suprimentos.
A privacidade de origem da requisição também é tratada separadamente. Relés de ocultação de IP operados por terceiros tunelam o tráfego de entrada e procuram impedir que a infraestrutura de inferência veja diretamente a origem real do pedido. A autenticação e a autorização são isoladas da etapa de inferência por meio de Anonymous Tokens, separando a capacidade de validar acesso da capacidade de vincular identidade a conteúdo processado. Esse ponto é central para ambientes que precisam reduzir correlação entre usuário, sessão e dado enviado ao modelo.
A superfície principal é formada por clientes que enviam dados sensíveis para experiências de IA, serviços de frontend, pipeline escalável de inferência, servidores de modelo em TPU e componentes auxiliares de privacidade, como relés de ocultação de IP e emissão de tokens anônimos. A exposição não é descrita como vulnerabilidade única em produto final, mas como um conjunto de garantias arquiteturais que precisam funcionar em conjunto: atestação, criptografia, isolamento de memória, validação de binário, descarte de sessão e separação entre identidade e inferência.
A avaliação também delimita dependências importantes. O ambiente usa hardware proprietário e está centralizado em Borg Prime. Isso não invalida as garantias técnicas apresentadas, mas define o limite de confiança: a proteção é forte contra componentes não autorizados e contra insiders maliciosos dentro do modelo descrito, enquanto decisões coordenadas da organização como um todo permanecem fora do escopo de isolamento técnico. Para adoção corporativa, esse limite deve entrar na análise de governança, privacidade e contratos de tratamento de dados.
- Consultas de IA contendo dados pessoais ou sensíveis processadas fora do dispositivo em ambiente de nuvem protegido.
- Nós confiáveis baseados em CPU e TPU com TEE de hardware AMD, memória cifrada e isolamento em relação ao host.
- Pipeline de inferência com frontend, serviços internos protegidos por ALTS e servidores de modelo na plataforma TPU reforçada.
- Relés de ocultação de IP e Anonymous Tokens usados para reduzir correlação entre origem, identidade e conteúdo processado.
Como o anúncio descreve uma arquitetura gerenciada, o hunting direto dentro dos componentes internos depende de telemetria oferecida pela própria plataforma e de documentação operacional associada. Para equipes consumidoras, a análise deve se concentrar em evidências de que as sessões usam atestação, que falhas de validação interrompem conexões, que a autenticação não é reutilizada na inferência e que políticas de retenção confirmam o descarte de entradas, inferências e computações ao fim da sessão. O ponto defensivo não é procurar um IoC específico, mas validar controles e exceções.
Em ambientes empresariais, a telemetria de borda deve registrar quais integrações enviam conteúdo a experiências de IA, quais classes de dados são permitidas, quais usuários ou aplicações acionam o serviço e quais políticas de privacidade se aplicam. Como a arquitetura prevê relés de ocultação de IP, logs de rede podem não refletir de forma simples a origem final vista pelo serviço de inferência. Por isso, inventário de integrações, trilhas de auditoria de identidade e registros de consentimento ou autorização de uso de dados devem ser correlacionados no lado do cliente e do tenant.
Os achados de avaliação externa também sugerem áreas de observabilidade para fornecedores e avaliadores independentes. Falhas de atestação que causem negação de serviço podem se manifestar como recusas de conexão, degradação de disponibilidade, reinicialização de sessão ou falhas repetidas na negociação de credenciais de carga de trabalho. Ataques de protocolo, mesmo sem exploração confirmada no contexto, exigem validação de transcriptos criptográficos, rejeição de mensagens fora de ordem e testes de robustez para condições em que um nó não apresenta credenciais coerentes com os valores de referência.
- Falhas ou recusas de atestação entre cliente, frontend, nós confiáveis e cargas de trabalho internas.
- Eventos de indisponibilidade associados a validação de credenciais de carga de trabalho ou estabelecimento de canais protegidos.
- Diferenças entre identidade autenticada e sessão de inferência, com atenção a qualquer correlação indevida entre usuário e conteúdo.
- Evidências de descarte de dados após a sessão, incluindo ausência de retenção operacional de entradas, inferências e computações.
- Padrões anômalos de temporização em relés de ocultação de IP quando houver capacidade legítima de medição defensiva.
A mitigação para organizações que pretendem usar processamento de IA com dados sensíveis começa por uma avaliação de arquitetura, não por bloqueio genérico de nuvem. O primeiro passo é mapear quais dados serão enviados, quais fluxos exigem processamento local, quais fluxos podem aceitar processamento confidencial remoto e quais controles contratuais ou regulatórios precisam acompanhar a decisão. A existência de TEE, atestação e criptografia reduz risco técnico, mas não substitui classificação de dados, governança de uso de IA e validação independente das garantias prometidas.
Controles de adoção devem exigir evidência de que somente cargas assinadas e autorizadas executam no ambiente, que a atestação falha de modo fechado, que administradores não conseguem acessar diretamente cargas de trabalho com dados de usuário e que as chaves ou credenciais de sessão não permitem reprocessamento de dados antigos. Também é importante acompanhar a conclusão das mitigações para os problemas de atestação e ataques de protocolo identificados, porque esses pontos afetam disponibilidade e integridade da negociação entre componentes confiáveis.
Para defesa operacional, políticas de DLP e CASB devem ser ajustadas para distinguir uso permitido de IA, dados bloqueados e exceções aprovadas. Registros de identidade, consentimento, finalidade de processamento e integração de aplicações devem ser preservados no ambiente do cliente. Se a organização trata dados regulados, a decisão deve incluir análise sobre relés de ocultação de IP, separação entre autenticação e inferência, coleta agregada via Confidential Federated Compute e limites do modelo centralizado. A validação final precisa testar falha de conexão, recusa de atestação e comportamento de retenção após encerramento de sessão.
- Classificar os dados que podem ser enviados ao processamento de IA e bloquear categorias que exigem permanência exclusiva no dispositivo.
- Exigir documentação de atestação remota, autorização binária, descarte de sessão e isolamento entre autenticação e inferência.
- Acompanhar a correção dos problemas de atestação com potencial de negação de serviço e ataques de protocolo.
- Validar trilhas de auditoria no cliente para uso de IA, identidade, finalidade de processamento e exceções autorizadas.
- Revisar o limite de confiança associado a hardware proprietário, Borg Prime e decisões organizacionais fora do isolamento técnico.
0 Comentários