Your AI assistant wants a memory. Who holds the key?
The most useful assistant is the one you do not have to brief from scratch every morning.
It remembers that the Tuesday meeting moved. It knows which client prefers a concise update, which project is waiting for approval and where you left the draft you opened on another device.
That continuity is becoming one of the next big product battles in AI. It also creates a much less glamorous question: where does all that memory live?
On 23 September, Google described a planned persistent memory layer for Private AI Compute. The proposal is technically interesting because it tries to combine cloud-scale models with a privacy property normally associated with local processing. Personal context would be stored in encrypted, per-user databases. The keys needed to unlock it would remain on the user's devices. When the model needs the information, an authenticated encrypted connection would send it into a protected cloud environment for temporary processing.
Google says the design is intended to keep the data inaccessible even to Google. It also plans a public record of server software so devices can verify the code before sending personal information, plus updated technical documentation and an independent security audit.
Those are serious engineering choices. They are not the same thing as a complete answer to whether a business should let an assistant remember everything.
Memory changes the job
Most AI interactions are still treated like isolated transactions. A prompt arrives, a response leaves and the next conversation begins with limited context.
That works for rewriting a paragraph. It works less well for assistants expected to follow a project across email, documents, meetings and devices.
Persistent memory turns an AI tool from a clever visitor into something closer to a long-term colleague. The assistant can reduce repeated explanation, notice unfinished work and connect information across time. The value is obvious.
So is the risk.
A forgotten conversation is inconvenient. An inaccurate memory that quietly influences future work can be worse. A sensitive memory retained for longer than expected creates another problem. A perfectly secure memory can still be used in an unhelpful way if the system remembers the wrong detail, applies it in the wrong context or gives the user no practical way to correct it.
Privacy is not only about preventing an attacker from reading a database. It is also about deciding what enters the database, why it is there, how long it stays and who can make it disappear.
Encryption solves one part of the problem
Google's architecture addresses a difficult technical tension.
Running a model entirely on a phone or laptop gives the device strong control over the data, but frontier models often need more computing power. Sending information to an ordinary cloud service provides scale, but requires greater trust in the service operator and its controls.
Secure enclaves try to create a protected room inside cloud infrastructure. Data travels through encrypted channels, is decrypted only inside hardware-isolated memory for processing, then is encrypted again. Remote attestation lets a device check that the expected software is running before it shares the data.
Adding device-held keys to persistent storage is an important extension. The server can retain encrypted context without holding the only thing that can unlock it.
That does not make the system magic. Businesses still need to understand what happens if a device is lost, how keys are recovered, how shared accounts behave, which administrators have control and whether deletion covers backups and derived information. The answers may vary by product and deployment.
The useful lesson is broader than Google's implementation: “encrypted” is the beginning of a procurement conversation, not the end.
A memory needs an editor
The best AI memory will not be the one that stores the most.
It will be the one that makes memory visible and manageable.
Users should be able to see what the assistant believes about them, identify the source, correct an error and remove an item without hunting through settings. Memory should have categories, retention periods and clear boundaries between personal, team and client context.
A design studio might want an assistant to remember approved brand rules but forget early visual experiments. A sales team might retain a customer's stated preferences while excluding speculative internal notes. A developer may want project conventions remembered, but never credentials copied from a terminal.
These are editorial choices as much as security choices. Somebody must decide which facts deserve to influence the next answer.
That is why a short list of remembered “facts and preferences” has always been a limited solution. Real work contains changing states, conflicting instructions, permissions and expiry dates. “The client likes orange” may be true for one campaign, wrong for another and actively misleading six months later.
Memory needs provenance. It needs scope. It needs a delete button that means something.
Five questions before enabling persistent memory
Businesses do not need to reject useful memory features. They do need to ask better questions before switching them on.
What is remembered? Separate user preferences from business records, client data, conversation history and inferred information.
Where are the keys? Find out whether the provider, the user device or the organisation controls decryption and recovery.
Who can inspect and edit memory? A hidden memory is difficult to govern, even when it is well encrypted.
How does forgetting work? Check retention defaults, deletion, backups, account closure and the treatment of information derived from stored context.
Where can the memory be used? Context collected for one task should not quietly influence another without a clear reason and permission.
For small businesses, this can become a simple operating rule: do not give an assistant a memory until you know how to review it.
Continuity should not require blind trust
Google's proposal matters because it recognises that useful AI and private AI cannot remain separate product categories. People will expect capable assistants to remember work across devices. They will also expect personal and commercial information to remain under meaningful control.
The cryptography and hardware are essential. The product controls will decide whether the promise works in daily life.
An assistant that remembers everything may feel impressive for a week. An assistant that remembers the right things, shows its working and forgets on command will be useful for much longer.
That is the standard worth asking for.
Sources
1. Google DeepMind, “Advancing Private AI Compute with secure, server-side memory”, 23 September 2026: https://deepmind.google/blog/advancing-private-ai-compute-with-secure-server-side-memory/
2. Google, “Private AI Compute: our next step in building private and helpful AI”, 11 November 2025: https://blog.google/innovation-and-ai/products/google-private-ai-compute/
