A memória do Google Private AI Compute desafia o modelo de privacidade sem estado da nuvem
O Google adicionou memória persistente no servidor ao Private AI Compute, indo além do design sem estado que antes definia a IA em nuvem focada em privacidade. O sistema foi concebido para lembrar contexto entre dispositivos, mantendo as chaves de descriptografia em hardware controlado pelo usuário.
Essa é uma mudança significativa para a memória do Google Private AI Compute. Até agora, Google e Apple tratavam o esquecimento como uma proteção central de privacidade. Cada solicitação em nuvem entrava em um ambiente isolado, recebia uma resposta e saía sem contexto pessoal persistente.
O Google agora argumenta que um assistente não pode se tornar verdadeiramente contínuo se seu ambiente em nuvem esquece tudo após cada solicitação. Sua resposta proposta é um cofre de memória criptografado que permanece na nuvem, mas não pode ser aberto sem chaves derivadas do dispositivo.
A arquitetura cria uma tensão direta entre continuidade e minimização de dados. Lembrar mais pode tornar um assistente mais útil, mas também cria um alvo duradouro que os sistemas sem estado foram projetados para evitar.
Google está dando memória ao Private AI Compute
O Google está transformando um serviço de inferência privada em uma camada persistente de computação pessoal.
O Google DeepMind divulgou a arquitetura em 23 de setembro de 2026. Sua atualização técnica descreve uma camada de memória que reterá contexto pessoal entre sessões e dispositivos.
O Private AI Compute originalmente ampliava o trabalho exigente de IA para além de um telefone. Um dispositivo podia enviar uma solicitação criptografada à infraestrutura protegida do Google quando um modelo local não tinha capacidade computacional suficiente.
Esse ambiente em nuvem processava a solicitação dentro de sistemas isolados por hardware. Em seguida, retornava o resultado sem reter o contexto pessoal da sessão.
O Google chama esse design anterior de sem estado. Em termos práticos, o serviço podia ajudar com uma solicitação, mas não podia continuar com segurança a mesma experiência posteriormente.
A nova camada de memória muda essa limitação. O contexto pessoal pode permanecer em um banco de dados por usuário após o fim de uma solicitação de inferência. O Google afirma que as informações armazenadas permanecem criptografadas e que as chaves necessárias para desbloqueá-las ficam nos dispositivos do usuário.
Quando um modelo autorizado precisa desse contexto, o dispositivo estabelece uma conexão autenticada e criptografada de ponta a ponta com um ambiente isolado na nuvem. Esse enclave seguro descriptografa temporariamente as informações necessárias em memória protegida.
Um enclave seguro é uma área imposta por hardware que isola código e dados do restante do servidor. Mesmo softwares de infraestrutura privilegiados não deveriam poder inspecionar livremente a memória ativa do enclave.
Depois de processar uma solicitação, o sistema pode atualizar o contexto retido. Em seguida, ele criptografa esse contexto novamente antes de devolvê-lo ao armazenamento.
Essa estrutura viabiliza experiências que eram difíceis sob um modelo sem estado. Uma conversa iniciada em um telefone poderia continuar em um laptop sem que seu contexto precisasse ser reconstruído manualmente.
O Google também oferece um exemplo envolvendo óculos inteligentes. Uma pessoa poderia ver instruções pelos óculos e depois recuperar o contexto relevante em outro dispositivo.
A empresa não anunciou, na divulgação, uma data para lançamento amplo ao consumidor. Ela descreve a arquitetura como uma capacidade que permitirá futuras experiências de memória persistente.
Essa distinção importa. O Google revelou o modelo de segurança, mas os leitores ainda não têm uma lista completa de produtos nem controles padrão para inspecionar memórias armazenadas.
O anúncio ainda representa uma mudança estratégica. O Google não trata mais a inferência privada em nuvem e a personalização persistente como problemas separados.
Sua plataforma anterior de Private AI Compute concentrava-se em executar cargas de trabalho maiores do Gemini sem aplicar padrões convencionais de acesso à nuvem a solicitações sensíveis. A memória persistente amplia a responsabilidade do sistema para além do momento da inferência.
Agora, o serviço precisa proteger informações durante a transmissão, o processamento ativo, o armazenamento de longo prazo, a recuperação posterior e a exclusão. Cada etapa adicional cria outro ponto em que erros de design podem afetar a privacidade.
Essa responsabilidade ampliada é a verdadeira história. O Google propõe que a IA em nuvem possa se lembrar de uma pessoa ao longo do tempo sem dar ao operador acesso comum a essa memória.
Por que a IA em nuvem sem estado chegou ao seu limite
O recurso de privacidade que tornou mais fácil confiar em IA confidencial na nuvem também a tornou menos capaz como assistente pessoal.
O processamento sem estado minimiza a quantidade de informações pessoais deixadas em um servidor. Ele também limita a continuidade, porque o modelo inicia cada sessão protegida sem um registro duradouro de interações anteriores.
Desenvolvedores podem contornar esse problema salvando preferências selecionadas em outro lugar. Um assistente pode reter o idioma preferido de um usuário, restrições alimentares ou destinos frequentes.
No entanto, uma lista de fatos isolados não reproduz uma conversa em evolução. Ela não consegue representar plenamente trabalho inacabado, prioridades em mudança ou relações entre atividades concluídas em dispositivos diferentes.
Os usuários então enfrentam uma escolha repetitiva. Podem explicar novamente o mesmo contexto, permitir que uma conta comum em nuvem o armazene ou aceitar um assistente menos personalizado.
A memória do Google Private AI Compute pretende eliminar essa escolha. Ela separa o armazenamento persistente criptografado das chaves necessárias para tornar as informações legíveis.
Essa separação importa porque modelos avançados de IA ainda exigem recursos substanciais de servidor. Telefones e laptops podem executar modelos locais cada vez mais capazes, mas não conseguem realizar com eficiência todas as tarefas em escala de fronteira.
A infraestrutura de nuvem oferece modelos maiores, aceleradores especializados e mais memória disponível. Ela também leva informações sensíveis para um ambiente controlado por outra organização.
A computação confidencial busca reduzir essa lacuna de confiança. Ela protege dados enquanto estão sendo usados, e não apenas enquanto estão armazenados ou em trânsito pela rede.
A criptografia convencional protege dados em repouso e em trânsito. Um servidor comum ainda precisa descriptografar essas informações em algum lugar antes que um modelo possa processá-las.
Um ambiente de execução confiável, ou TEE, restringe essa etapa exposta. Código aprovado opera sobre informações legíveis dentro de um limite isolado, enquanto o host ao redor continua incapaz de inspecioná-las diretamente.
O Google Cloud descreve a computação confidencial como uma forma de proteger cargas de trabalho sensíveis durante o processamento. Suas aplicações incluem análises, aprendizado de máquina e colaboração entre conjuntos de dados protegidos.
Essa abordagem não elimina todas as premissas de confiança. Ela muda quais componentes precisam ser confiáveis e fornece aos dispositivos evidências técnicas sobre o ambiente que recebe seus dados.
A memória persistente aumenta a importância dessas garantias. Uma única solicitação de inferência expõe uma parcela limitada de contexto por um período limitado.
Uma memória duradoura de IA pode acumular conversas, preferências, documentos, localizações e padrões comportamentais. Seu valor para o assistente também a torna valiosa para invasores.
Trabalhadores do conhecimento reconhecerão o apelo. Um assistente pessoal se torna mais útil quando consegue conectar reuniões, arquivos, decisões e tarefas inacabadas ao longo do tempo.
O mesmo princípio sustenta uma base de conhecimento pessoal. Uma recuperação útil depende de contexto persistente, propriedade clara e controles que impeçam o acesso de pessoas não relacionadas.
O Google está tentando aplicar esses princípios em escala de nuvem. Ele precisa preservar a continuidade sem transformar o provedor no guardião de históricos pessoais legíveis.
Essa pressão vai além do Google. Todos os grandes fornecedores de assistentes querem contexto mais duradouro, porque a continuidade melhora a conclusão de tarefas e reduz a repetição de prompts.
A questão difícil não é mais se os assistentes devem se lembrar. É se os usuários podem obter memória útil sem aceitar a visibilidade convencional no lado do servidor.
Como funciona a memória do Google Private AI Compute
O design coloca memórias criptografadas na infraestrutura do Google, mantendo sua autoridade prática de desbloqueio vinculada a dispositivos pessoais.
O Google descreve o armazenamento de memória como um cofre digital seguro. Cada usuário recebe armazenamento isolado, protegido com criptografia associada aos dispositivos desse usuário.
A arquitetura usa uma chave de criptografia de dados, comumente chamada de DEK, para criptografar a memória armazenada. Uma segunda chave protege essa DEK, de modo que o banco de dados não mantenha um segredo de desbloqueio diretamente utilizável.
O diagrama do Google identifica essa segunda camada como um arranjo de chave de criptografia de chave. O dispositivo participa da derivação ou proteção do material de chave necessário para desembrulhar os dados armazenados.
Esse design significa que roubar o banco de dados criptografado não deveria ser suficiente para revelar seu conteúdo. Um invasor também precisaria acessar o caminho de chave autorizado e um ambiente de processamento aprovado.
Quando o assistente precisa de contexto, o cliente primeiro verifica o ambiente remoto. Esse processo é chamado de atestação remota.
A atestação remota permite que um dispositivo verifique alegações sobre o hardware e o software em execução no servidor antes de liberar informações sensíveis. Um relatório válido deve mostrar que código aprovado está operando dentro do enclave esperado.
O dispositivo então cria um canal criptografado para esse ambiente. A memória é descriptografada apenas dentro da memória isolada após o sistema passar pelas verificações exigidas.
O modelo pode usar o contexto para responder a uma solicitação. Ele também pode produzir novas informações que o serviço de memória armazena para uma interação posterior.
O Google afirma que nem administradores nem serviços comuns de nuvem podem inspecionar essas informações. A empresa afirma ainda que a arquitetura torna os dados inacessíveis até mesmo ao Google.
Essa afirmação depende de mais do que criptografia. O dispositivo deve verificar corretamente o servidor, o enclave deve impor isolamento e o software deve evitar vazamento de dados por suas saídas.
O gerenciamento de chaves também se torna central. Um sistema privado ainda pode falhar se a recuperação de conta, a substituição de dispositivos, a sincronização ou a revogação introduzirem discretamente uma rota alternativa de acesso.
O Google não detalhou completamente esses cenários do ciclo de vida do usuário em seu anúncio público. Eles influenciarão o quanto o sistema implantado corresponde à sua promessa arquitetural.
Por exemplo, perder todos os dispositivos confiáveis cria uma escolha difícil. Chaves fortes apenas no dispositivo poderiam tornar a memória permanentemente irrecuperável.
Um mecanismo conveniente de recuperação controlado pelo provedor reduziria esse risco. Ele também poderia criar outro caminho pelo qual alguém que não seja o usuário obtivesse acesso.
Adicionar um novo telefone apresenta uma questão relacionada. O sistema precisa transferir autoridade para esse dispositivo sem revelar chaves a um intermediário nem aceitar um cadastro não autorizado.
A exclusão também deve abranger mais do que remover uma entrada de memória visível. Os usuários precisam confiar que chaves desativadas, réplicas, backups, caches e contexto derivado não poderão posteriormente restaurar informações supostamente excluídas.
Esses são requisitos operacionais normais, não evidências de que o design do Google seja defeituoso. Eles mostram por que a memória privada de IA envolve mais do que colocar um banco de dados atrás de um enclave.
O próprio caminho de inferência contém vários componentes. Uma avaliação independente anterior descreveu conexões de cliente criptografadas, serviços de frontend, sistemas de orquestração, módulos de segurança de IA e infraestrutura de TPU reforçada.
Esses componentes autenticam uns aos outros e usam atestação para estabelecer caminhos de comunicação aprovados. Cada serviço adicional precisa permanecer dentro do limite de privacidade pretendido.
O Google também planeja publicar um registro resistente a adulterações do software dos servidores. Um cliente pode comparar a medição atestada do software do servidor com um registro público antes de enviar dados pessoais.
Esse mecanismo aborda um risco sutil da nuvem. Um provedor pode publicar código seguro para análise, mas operar software diferente em produção.
Um registro de transparência somente de acréscimo torna substituições não detectadas mais difíceis. Pesquisadores podem inspecionar as compilações listadas, enquanto dispositivos rejeitam ambientes que não correspondem a medições autorizadas.
O mecanismo não prova que todas as compilações autorizadas estejam livres de vulnerabilidades. Ele fornece evidências de que o software inspecionado corresponde ao que os dispositivos têm permissão para confiar.
Essa distinção é importante. A transparência torna o escrutínio possível, mas o escrutínio ainda exige artefatos acessíveis, pesquisadores capacitados e tempo.
A Promessa de Privacidade Ainda Tem um Limite de Hardware
O Google pode reduzir o poder dos administradores de nuvem, mas não pode eliminar toda dependência de hardware e software projetados pelo Google.
O Google contratou a NCC Group para avaliar partes selecionadas do Private AI Compute a partir da primavera de 2025. Dez consultores dedicaram, segundo relatos, 100 dias-pessoa a análises de arquitetura e componentes.
A análise independente examinou a biblioteca criptográfica Oak Session, a atestação remota, o relay de ocultação de IP, o registro de transparência e código selecionado do servidor. Esse trabalho oferece mais substância do que uma alegação de produto sem auditoria.
No entanto, seu escopo importa. Uma análise de componentes selecionados não certifica todos os futuros recursos de memória, implementações de cliente, revisões de hardware ou procedimentos operacionais.
A avaliação também identifica um limite fundamental. Atualmente, a inferência prática de IA opera sobre dados legíveis dentro de algum sistema físico de computação.
Portanto, as informações criptografadas tornam-se texto simples dentro do processador protegido durante o processamento. O hardware e o código aprovado podem acessá-las porque precisam realizar o trabalho solicitado.
O relatório da NCC observa que projetistas de hardware mantêm a capacidade teórica de criar um caminho de exfiltração em seus chips. O Private AI Compute depende, em última instância, de que a plataforma TPU reforçada do Google se comporte conforme descrito.
Essa limitação se aplica amplamente à computação confidencial. Enclaves reduzem a exposição a hipervisores, administradores e software do host comprometido, mas não tornam a computação física livre de confiança.
Ataques de canal lateral criam outra preocupação. Esses ataques inferem informações protegidas a partir de comportamentos observáveis, como tempo de execução, acesso à memória, contenção de recursos ou consumo de energia.
Plataformas confidenciais adicionam continuamente mitigações, mas novas vulnerabilidades de hardware podem alterar premissas de segurança anteriores. Portanto, o argumento de privacidade de um sistema precisa evoluir com o panorama de ameaças.
O software dentro do enclave também pode cometer erros. Um modelo ou serviço de apoio pode expor detalhes sensíveis em uma saída, mesmo que o armazenamento subjacente permaneça protegido criptograficamente.
A injeção de prompt apresenta um desafio relacionado. Conteúdo malicioso pode manipular um assistente para recuperar ou revelar informações que o usuário não pretendia compartilhar naquele contexto.
O enclave não pode decidir automaticamente se uma solicitação representa a intenção real do usuário. Ele executa software autorizado sob as políticas implementadas pelos desenvolvedores.
O contexto persistente aumenta os riscos porque mais informações podem estar disponíveis durante uma interação comprometida. Os controles de acesso devem limitar quais memórias cada recurso pode recuperar.
O sistema também precisa de salvaguardas contra inferências a partir de metadados. Tamanho do armazenamento, frequência de acesso, temporização do dispositivo e padrões de rede podem revelar informações sem expor o conteúdo exato da memória.
A arquitetura anterior do Google inclui um relay de ocultação de IP projetado para separar a identidade do usuário das solicitações. O sistema persistente deve preservar proteções semelhantes em leituras e atualizações de memória.
Pesquisadores propuseram abordagens mais abertas para IA confidencial. O artigo OpenPCC de 2026 argumenta que os primeiros sistemas do Google e da Apple dependem fortemente de infraestrutura proprietária.
Seus autores construíram um protótipo de código aberto usando ambientes de execução confiáveis comercialmente disponíveis. A crítica deles destaca uma questão-chave de verificação para o Google.
Pesquisadores externos precisam de código, medições e ferramentas suficientes para testar as alegações de privacidade relevantes. Um registro público, por si só, não cria reprodutibilidade completa.
O Google afirma que está publicando detalhes atualizados de arquitetura, provas de segurança, protocolos de verificação e resultados de auditoria. A profundidade dessa divulgação determinará o quanto pesquisadores poderão avaliar independentemente a camada de memória.
Portanto, os usuários devem interpretar “inacessível até mesmo ao Google” como um objetivo de segurança sustentado por controles em camadas. Não é uma alegação que dispense qualquer confiança no Google.
A arquitetura reduz o número de pessoas e sistemas capazes de visualizar o contexto pessoal. Ela também torna o acesso não autorizado tecnicamente mais difícil e mais detectável.
Esse é um padrão mais robusto do que um banco de dados comum na nuvem, protegido principalmente por políticas e controles de acesso administrativos. Ainda assim, não equivale a manter todas as informações em hardware desconectado.
O Modelo Sem Estado da Apple Agora É o Principal Contraponto
O Google aposta que a persistência privada pode superar o esquecimento rigoroso sem enfraquecer o limite efetivo de privacidade do usuário.
O Private Cloud Compute da Apple oferece a comparação mais clara. A Apple construiu o PCC em torno de processamento sem estado, acesso administrativo limitado, impossibilidade de direcionamento e transparência verificável do software.
Sua arquitetura de segurança afirma que os dados do usuário não devem permanecer depois que uma solicitação é concluída. As chaves de criptografia do volume de dados de um nó mudam na reinicialização e não são retidas.
A Apple também remove ferramentas interativas de depuração e registros de uso geral dos nós PCC. Seu modelo público trata a incapacidade de preservar dados do usuário como uma propriedade passível de imposição.
O Google compartilhava grande parte dessa filosofia sem estado quando o Private AI Compute foi lançado. A memória persistente no lado do servidor agora cria uma divisão visível entre as duas abordagens.
O modelo da Apple minimiza o estado durável na nuvem. O novo design do Google aceita estado criptografado durável porque considera a continuidade entre dispositivos essencial para a IA pessoal.
Nenhuma das posições resolve todos os problemas. O processamento sem estado protege contra o acúmulo de longo prazo, mas limita a capacidade de um assistente de retomar o trabalho naturalmente.
A memória criptografada persistente oferece suporte a uma personalização mais rica. Ela cria um ciclo de vida maior envolvendo criação, recuperação, modificação, transferência, retenção e exclusão.
A comparação não é simplesmente Google contra Apple. Ela representa duas definições do que a IA privada em nuvem deveria garantir.
Uma definição diz que a computação privada deve esquecer após cada tarefa. A outra diz que ela deve lembrar, mas apenas por meio de chaves e software autorizados pelo dispositivo do usuário.
A Apple também expandiu o PCC para a infraestrutura do Google Cloud em cargas de trabalho exigentes. Ela afirma que dispositivos Apple ainda confiam apenas em software aprovado criptograficamente pela Apple.
Essa parceria mostra que a propriedade do hardware e o controle de privacidade nem sempre pertencem à mesma organização. A atestação de software pode permitir que uma empresa imponha requisitos à infraestrutura de outra empresa.
Ainda assim, a Apple continua descrevendo o PCC como sem estado. A camada persistente do Google, portanto, vai além da propriedade que a Apple apresenta como uma salvaguarda central.
A diferença se tornará tangível por meio do comportamento dos produtos. Um assistente sem estado precisa de contexto do dispositivo ou de um armazenamento separado controlado pelo usuário toda vez que entra na nuvem.
A abordagem do Google permite que o ambiente de nuvem protegido recupere diretamente o contexto anterior após a autorização do dispositivo. Isso pode reduzir a latência, transferências repetidas e lacunas entre produtos.
Ela também pode aumentar a dependência do formato de memória do Google e do sistema de cadastro de dispositivos. Os usuários podem ter dificuldade para inspecionar ou transferir um histórico otimizado para um assistente interno.
A portabilidade não é abordada no anúncio. Tampouco são os formatos padrão de exportação, padrões de retenção ou a capacidade de executar serviços de memória compatíveis em outro lugar.
Essas questões afetam a concorrência tanto quanto a privacidade. Uma memória útil torna-se um ativo personalizado que melhora com o tempo.
Se esse ativo permanecer vinculado a um único assistente, trocar de serviço significa perder o contexto acumulado ou expô-lo durante a migração. A criptografia, por si só, não impede a dependência de fornecedor.
O Google pode fortalecer sua posição ao fornecer aos usuários controles claros de inspeção, exportação, correção e exclusão. Também pode documentar como a memória se move quando as pessoas trocam de dispositivo ou conta.
A Apple, por sua vez, enfrenta pressão para mostrar que seu design sem estado pode oferecer continuidade comparável. Ela pode depender mais do armazenamento criptografado no dispositivo e sincronizar apenas o contexto mínimo necessário para cada solicitação.
Outros fornecedores de assistentes enfrentam a mesma decisão. Eles podem manter a memória em bancos de dados convencionais de contas, adotar infraestrutura confidencial ou deixar o contexto de longo prazo em dispositivos controlados pelo usuário.
O design do Google faz o armazenamento comum no lado do servidor parecer menos defensável para assistentes altamente pessoais. Uma vez que controles mais robustos existem, usuários preocupados com privacidade podem perguntar por que concorrentes não os utilizam.
O Que Usuários e Pesquisadores Devem Observar a Seguir
A arquitetura conquistará confiança por meio de controles implantados e escrutínio externo, não apenas por seu diagrama.
O primeiro sinal é o lançamento do produto. O Google precisa identificar quais experiências do Gemini usam memória persistente do Private AI Compute e quais continuam usando outros sistemas de armazenamento.
Um indicador visível deve informar os usuários quando uma solicitação entra no ambiente protegido. O Google já fornece informações de rede do Private AI Compute em dispositivos Pixel compatíveis.
A memória persistente precisa de controles igualmente claros. Os usuários devem poder ver o que foi retido, por que foi recuperado e qual dispositivo autorizou a operação.
Essa interface revelará se a privacidade da memória de IA do Google é compreensível fora de um artigo de segurança. Memórias ocultas ou excessivamente amplas enfraqueceriam o valor prático da arquitetura.
O segundo sinal é a verificação independente. Pesquisadores precisam de registros de software utilizáveis, ferramentas de inspeção, evidências de atestação e documentação para os novos componentes de memória.
O registro de transparência do Google deve abranger todos os serviços críticos para a segurança que podem recuperar ou atualizar contexto persistente. Uma cobertura parcial poderia deixar código importante fora do escrutínio público.
Avaliações futuras devem testar o caminho de memória implantado, e não apenas a infraestrutura sem estado anterior. Elas devem examinar o tratamento de chaves, o cadastro de dispositivos, a exclusão, a recuperação e a resistência a entradas maliciosas.
A pesquisa pública sobre vulnerabilidades será mais importante do que o número de documentos publicados. Descobertas confiáveis, correções e cronogramas de divulgação mostrarão como a plataforma se comporta sob pressão.
O terceiro sinal é a resposta competitiva. O compromisso da Apple com o processamento sem estado agora serve como uma alternativa clara pela qual o design do Google pode ser avaliado.
Se o Google oferecer continuidade útil entre dispositivos sem falhas materiais de privacidade, o modelo estritamente sem estado pode começar a parecer desnecessariamente limitador. Os concorrentes enfrentariam pressão para adicionar persistência protegida.
Se a recuperação, a exclusão ou a verificação se mostrarem opacas, a arquitetura da Apple, baseada em esquecer primeiro, ganhará respaldo. O mesmo resultado favoreceria assistentes que mantêm as memórias localmente.
Compradores corporativos também devem acompanhar se o Google adapta o sistema para dados organizacionais. Chaves pessoais de dispositivos não se encaixam facilmente em rotatividade de funcionários, retenção legal ou espaços de trabalho compartilhados.
Uma empresa pode precisar que administradores recuperem registros ou removam acessos. Essas exigências podem entrar em conflito com a promessa de que nem mesmo o provedor consegue descriptografar o contexto armazenado.
Desenvolvedores devem examinar o futuro modelo de acesso. Uma camada privada de memória precisa de permissões restritas para que um aplicativo não possa recuperar o contexto criado para uma finalidade não relacionada.
Os usuários não devem presumir que todos os recursos de IA do Google recebem automaticamente essas proteções. Private AI Compute é uma arquitetura específica, não um rótulo universal para todo processamento em nuvem.
A documentação do produto deve informar quando o sistema é ativado e o que acontece quando ele não está disponível. O comportamento de contingência pode comprometer a privacidade se as solicitações forem transferidas silenciosamente para um serviço menos protegido.
A memória do Google Private AI Compute aborda uma fragilidade real dos assistentes privados em nuvem. Sistemas sem estado protegem os usuários ao esquecer, mas têm dificuldade para dar suporte ao trabalho contínuo entre dispositivos.
A alternativa do Google é tecnicamente ambiciosa e conceitualmente direta. Armazenar o contexto remotamente, manter as chaves com o usuário e descriptografar apenas dentro de software verificado.
A parte difícil começa depois que esse projeto sai do diagrama. Recuperação de conta, migração de dispositivo, limites de acesso, transparência, exclusão e falhas de software determinarão seu nível real de privacidade.
Para os usuários, a ação imediata é simples. Verifique se futuros recursos de memória do Gemini identificam o Private AI Compute, exibem o contexto retido e oferecem controles diretos de exclusão.
Para pesquisadores, o teste é mais rigoroso. Especialistas independentes conseguem verificar o software em produção, reproduzir a cadeia de confiança e encontrar vulnerabilidades relevantes antes dos invasores?
O Google propôs que os assistentes em nuvem não precisem mais escolher entre memória e privacidade. As próximas versões precisarão mostrar se uma memória segura no servidor pode sustentar essa promessa ao longo do tempo.
