AI Memory at Work: What Persists, Who Can Delete It, and Where It Lives

An employee pastes a client's salary figures into an assistant, regrets it, and deletes the chat. At 3 of the 4 major enterprise assistants, that deletion does not remove what the assistant remembered from it. AI memory is now a separate store with its own lifecycle, and most retention policies written in 2024 and 2025 do not mention it.

What AI memory means in an enterprise workspace

AI memory is any information an assistant stores from one conversation and applies to a later one without being asked. That is different from chat history, which is the record of the conversations themselves. The distinction is the whole subject of this post.

Vendors now ship two kinds of memory. Explicit or saved memories are discrete facts the assistant writes down, such as "prefers British spelling" or "works on the Acme account". Inferred memory draws on past chats at answer time, either by summarising them or by searching them.

Both kinds create a copy of user content that sits outside the conversation it came from. Your retention schedule, your legal hold and your deletion procedure were all written around conversations. Memory is the part they miss.

The vendor-wide view of how long conversation data is kept is covered in the ranking of AI vendor data retention policies. This post looks only at the memory layer, because it behaves differently enough to need its own rules.

AI memory controls compared across four vendors

The table below is built only from each vendor's own admin and privacy documentation, read on 9 October 2026. Where a document is silent, the cell says so rather than guessing.

Sources: OpenAI Help Center, Anthropic support and privacy centres, Google Workspace Admin Help, Microsoft Learn. All read 9 October 2026. OpenAI pages were read through search-index extracts because the help centre refused direct automated access, which is the weakest sourcing in this table.

Read across the rows rather than down the columns. No two vendors give the same answer to the same question, which means a single "AI memory policy" cannot be a single sentence. It has to be a short table of its own, one row per tool you have approved.

Deleting the chat does not delete the memory

This is the finding that should change your deletion procedure. Three of the four vendors document that a saved memory survives the deletion of the conversation that produced it.

ChatGPT: delete the memory and the chat, separately

OpenAI's Memory FAQ tells users that removing remembered information means deleting the saved memory and also the chat where it was first shared. It adds that OpenAI may keep logs of deleted saved memories for up to 30 days for safety and debugging. Turning off reference chat history schedules remembered information for deletion within the same 30-day window.

The practical consequence is a two-step deletion. A user who deletes only the chat has left the fact in memory. A user who deletes only the memory has left it in the chat, where reference chat history can find it again.

Claude: memory entries outlive expired chats

Anthropic rebuilt Claude's memory on 10 July 2026, replacing a daily summary with individual topic entries. Under the old system, deleted conversations dropped out of the summary within 24 hours. Under the new one, Anthropic's support article states that memory entries generated from a deleted or expired conversation are not removed.

That reversal matters if your security team approved Claude memory in late 2025. The behaviour they reviewed no longer exists. A user must now delete individual topic entries, or reset memory entirely, to remove what a deleted chat taught the assistant.

Copilot: saved memories stay, inferred details fade

Microsoft separates the two memory types cleanly. Saved memories are retained until the user explicitly deletes them in Settings, and deleting a chat does not remove them. Details inferred from chat history behave better: once every chat mentioning a fact is deleted, traces of it are removed within 7 days.

So Copilot gives you a predictable clock for inferred memory and no clock at all for saved memory. That asymmetry is the right design in my view, and it is also the one most likely to surprise an employee.

What the admin off switch actually does to AI memory

Every vendor offering memory gives admins a way to turn it off. They do not mean the same thing by "off", and the difference decides whether switching off is a reversible pause or a destructive act.

Claude treats off as delete

Anthropic's documentation for Team and Enterprise owners is blunt. Turning memory off at organisation level deletes all existing memory entries for all users immediately and permanently. The change is logged, though individual member edits to their own memories are not.

This is the strongest privacy guarantee in the group and also the most dangerous button in it. An owner testing the setting on a Friday afternoon can erase months of context for every employee, with no undo. I would require a second approver before anyone touches it.

Copilot treats off as pause

Microsoft's Enhanced personalization control is on by default and is configured through Microsoft Graph. Turning it off stops Copilot applying saved memories and custom instructions, but Microsoft states it does not remove them. Only chat-history details are deleted, after 30 days.

So a Copilot admin who switches memory off to "clear" it has done no such thing for saved memories. They are still sitting in each user's mailbox, waiting for the control to be turned back on. Microsoft also states that admins cannot restrict what type of information is added to memory.

OpenAI's workspace settings let admins enable shared memory and improved memory per role, with improved memory switching on by default for eligible workspaces after early access unless an admin opts out. What switching off does to memories already saved is not stated in the material available for this post, so ask before you assume.

AI memory sits outside the retention policy you already set

Most organisations that deployed an assistant set a conversation retention period. Memory is where that period quietly stops applying.

Microsoft is the clearest case because it says so directly. Its Learn page states that retention policies and labels configured in Purview do not apply to Copilot memory, and that no admin control enforces retention specifically for memory. A three-month deletion rule on Copilot chats leaves memories untouched.

Microsoft's roadmap item RM569612 targeted September 2026 for Purview retention of Copilot memory, aimed at preserving historical versions of memory items for investigations. The Learn page, updated 2 September 2026, still describes the old behaviour. Treat the roadmap as intent until your tenant shows the setting.

Anthropic takes the opposite route. Memory follows your chat retention policy, but memory is not available at all to organisations with HIPAA, public-sector or custom data retention agreements. If you negotiated a custom retention window, you have already opted out of Claude memory, whether or not anyone noticed.

Google avoids the problem by not shipping memory on work accounts. Its Gemini app conversation history is kept for 3, 18 or 36 months, with 18 as the default, and only admins can change it. With history switched off, Google may still hold conversations for up to 72 hours to provide the service.

Where AI memory lives, and which region it sits in

Location answers two separate questions: which system holds memory, and in which country that system sits. The vendors answer the first far better than the second.

Microsoft gives the most concrete answer. Copilot memories sit in a hidden folder in each user's Exchange mailbox, so they inherit mailbox encryption and Customer Lockbox. Microsoft's privacy page states that Copilot is covered by the EU Data Boundary, though it also notes that models from Anthropic as a subprocessor are currently excluded from it.

OpenAI's data residency article lists ChatGPT memory among the features stored at rest in the selected region, for new workspaces. The same article says improved memory is not supported under data residency, while standard saved memories remain available. If residency is a hard requirement, the newer memory mode is the one you give up.

Anthropic's regional compliance page offers residency in Europe, the United States, Canada and Asia-Pacific, but every route it names runs through AWS Bedrock, Google Cloud Vertex or Microsoft Foundry. It does not describe residency for the Claude app itself, and it does not mention memory. Google's Workspace pages are similarly silent on where Gemini app data is stored.

The broader question of keeping AI workloads inside EU and Indian borders is worked through in the analysis of AI data residency for the EU and India. For memory specifically, the honest summary is that two vendors document it and two do not.

Where this comparison is weakest

This post compares documentation, not behaviour. Nobody here tested whether a deleted Copilot memory is gone in 7 days, or whether a Claude switch-off really clears every backup. Vendor documentation is a commitment you can hold a vendor to. It is not proof.

The OpenAI column rests on thinner sourcing

OpenAI's help centre refused automated access during research for this post. Its memory and data residency statements here come from search-index extracts of OpenAI's own pages, not from a page opened directly. The wording matches across several extracts, but treat that column as one tier below the others and check the live articles before relying on it.

The documents move faster than the policies

Anthropic replaced its memory architecture in July 2026 and flipped Team and Enterprise defaults in August. Microsoft labels memory a preview with a pending retention feature. A comparison like this one has a shelf life of months. That is an argument for a quarterly review, and also a fair argument against building a policy on any single row.

There is also a reasonable counter-view on the whole subject. Memory is user content that users can see and edit, and most of it is mundane: preferred formats, project names, writing tone. A security team could fairly decide that the risk is smaller than the friction of governing it. I disagree for regulated data, but for a 40-person agency writing marketing copy, that position is defensible.

An AI memory policy you can set this quarter

Your memory policy needs three decisions per approved tool: whether memory is on, who can delete it, and what happens when someone leaves. Each decision maps to a setting the vendor documents.

Decide memory per data class, not per tool

Turn memory off for teams that handle regulated or client-confidential data, and leave it on where the content is low risk. Every vendor that ships memory supports some form of scoped control, whether by role, group or organisation. The way permissions travel through connected tools is covered in the comparison of Glean and Copilot permission handling.

Write the contract clause before the renewal

Ask each vendor to state in writing whether memory is covered by your retention commitment and your residency commitment. Put the answer into the data processing agreement, using the structure in the guide to AI clauses in a data processing agreement. If memory is excluded, that is fine, as long as it is excluded on paper.

Unmanaged personal accounts sit outside all of this, since none of these admin controls reach them. That exposure is measured in the analysis of AI use on personal accounts. Wider admin differences between the three main enterprise plans are compared in the review of ChatGPT, Claude and Gemini enterprise governance.

Frequently asked questions

Where to start

Open the admin console for each assistant you have approved and write down one thing: is memory on, and for whom. Most teams that do this find at least one tool where the answer is "on, by default, for everyone", which is Copilot's documented default.

Then change one sentence in your staff guidance. Replace "delete the chat" with "delete the memory, then the chat". It costs nothing, it is accurate for three of the four vendors, and it closes the most common gap this research found.

Related reading