An assistant that picks up on your laptop where a conversation on your phone left off needs somewhere to keep that context. Cloud storage makes the handoff practical. It also raises a question: who can read the memories after you leave?
Google DeepMind’s September 23, 2026 announcement proposes an answer for Private AI Compute. Under its design, persistent memories sit in encrypted, per-user cloud storage, while the keys needed to unlock them remain on the user’s devices. When an assistant needs a memory, it processes the data temporarily inside an isolated cloud environment.
Google has described the architecture, a way for devices to check server software, and independent audit results. It has not announced when consumers can use this memory capability. Readers can examine the privacy design, but they cannot turn it on as a Gemini setting today.
Why Persistent Memory Changes the Privacy Problem
Google describes its existing Private AI Compute approach as stateless: context used for a task is discarded when that task ends. That limits what remains in the cloud. It also makes it harder for an assistant to resume a complex exchange across devices without a protected way to retain the relevant history.
Google gives the example of finding instructions on a laptop that were previously viewed through smart glasses. A useful assistant might also need to retain preferences or details from earlier conversations. As those details accumulate, they can reveal routines, relationships, or plans.
Keeping all processing and storage on one device would avoid some cloud risks, but it would make cross-device access harder and could limit access to cloud-scale AI models. Google’s proposal separates where memory is stored from where its decryption keys are kept. The path a request takes between the two is central to the design.
How a Request Would Reach Stored Memory
Google’s description of the proposed data path begins with a dedicated, encrypted database for each user. The company says the keys required to decrypt that memory are held exclusively on the user’s personal devices, rather than stored alongside the database in ordinary cloud infrastructure.
When a task requires past context, the device would connect through an authenticated, end-to-end encrypted channel to a hardware-isolated cloud environment, often called a secure enclave. Within that environment, the relevant data would be decrypted temporarily for processing. New context would be encrypted before it is saved to persistent storage.
If the system works as designed, someone who obtains a copy of the stored database should not be able to read the memories from that copy alone. Google also does not propose giving its regular cloud services a standing copy of each user’s decryption keys. Its stronger claim, that the data is inaccessible even to Google, depends on the protected processing environment and its controls working as intended.
The phrase end-to-end encrypted needs a qualification here. The protected channel ends at a cloud environment that must access plaintext to do the work. Memory does not remain encrypted throughout processing, and readable information is not confined to the user’s devices. The design aims to limit that exposure to an approved, isolated environment.
The Threat Model Has More Than One Boundary
The architecture addresses risks from someone who steals encrypted storage or an administrator with access to conventional cloud systems. Neither should thereby gain readable memory. Hardware isolation is intended to keep surrounding infrastructure from inspecting the data while an authorized request runs.
Other boundaries remain. A compromised phone or laptop could put keys or requests at risk before data reaches the protected channel. A flaw in enclave hardware or software could expose plaintext during processing. A legitimate assistant could reveal something sensitive in its answer if it retrieves the wrong memory or follows an unsafe instruction. Encrypting stored records does not settle those questions.
Persistent memory also raises operational questions. How are additional devices enrolled without handing the provider a usable key? What happens if someone loses every enrolled device? How can a user inspect, correct, or delete a memory, and what happens to copies retained for recovery? Google’s announcement explains the broad architecture but does not specify consumer controls or a recovery process for this capability.
The privacy claim has limits. Protecting memory contents does not automatically hide that a request occurred, which account made it, or other information a service might need to operate. The announcement does not provide enough detail to assess the full treatment of that metadata. Those questions belong in a deployed service’s technical documentation; they do not, on their own, show that the proposed content protections fail.
What Verification and Audits Can Establish
Google says it is publishing a public record of its server software. Devices running Private AI Compute will be able to check whether the software they are connecting to is authentic and unaltered before sending personal data. Device-held keys offer less reassurance if a secure channel delivers access to memory to software the user did not intend to trust.
Assuming the verification is implemented and enforced correctly, the check can help a client reject server software that does not match what Google has identified as approved. It cannot establish that approved software has no vulnerabilities, that every memory is selected appropriately, or that a user’s own device is secure.
Google’s announcement also points to updated technical materials and results from an independent security audit. Reporting on the accompanying materials describes published audit summaries. Their value depends on what the reviewers examined, which implementation was assessed, what they could test, and which findings remained open. An audit provides evidence about a defined scope, not a permanent certificate of safety.
For readers assessing Google’s claims, the question is whether a shipping client actually checks the right software before releasing access to memory, and whether the reviewed system matches the one handling requests. The announcement lays out a mechanism for that scrutiny. A future deployment would have to put it into practice.
No Consumer Rollout Has Been Announced
Google says it will bring secure server-side memory to Private AI Compute. Its announcement gives no launch date, names no first consumer product, and describes no enrollment process for users. Coverage of the update also describes a planned addition, not a generally available Gemini memory feature.
Frequently Asked Questions
4 questions
1Can I Use Google’s Private AI Compute Memory Now?
Google has not announced consumer availability for the persistent memory capability. Its September 23, 2026 announcement describes how Private AI Compute would retain and use context across devices, but gives no launch date or first supported consumer product. It is not a memory setting readers can enable today.
2
Sources
- Google DeepMind’s September 23, 2026 announcementdeepmind.google
- Reporting on the accompanying materialsunite.ai
