There is a kind of configuration change that never shows up in your change log, because you are not the one making it: the one the vendor makes inside a control you signed off on months ago. Between late October and mid-November 2026, Microsoft converts legacy Teams retention policies into Teams-only policies. Teams content stays exactly as it was. Copilot conversations, which many of those policies had been keeping without anyone asking them to, fall outside. The notice is called MC1481313, it was published on 28 September, and it does not name a single one of your policies.
What the notice says, and what it leaves to you
The text is short and it does not hide. Legacy Teams retention policies "that currently affect both Teams and Copilot data will be treated as Teams-only policies", and from then on "Copilot interactions will no longer be retained or deleted through these legacy Teams retention policies". The rollout is "beginning in late October 2026 and expected to complete by mid-November 2026". The matching roadmap entry, 571306, was published ten days earlier, on 18 September, and carries the same sentence in one line: Teams policies covering Copilot become Teams-only.
What the notice does not do is the hard part. It does not tell you how many policies in your tenant are affected, or which. It asks you to "review existing Microsoft Purview retention policies to identify policies that may currently apply to Copilot interactions". The verb is yours. And it is worth reading the consequence both ways, because almost everyone is reading it one way: if your policy was retain, you stop keeping something you believed was kept; but if it was retain then delete, or delete-only, what you stop doing is deleting. Some companies are going to find out in November that they are still holding conversations they promised to remove after thirty days.
Why Copilot was in there without you putting it there
The location where you ticked the box was called, literally, "Teams chats and Copilot interactions". And Microsoft's documentation explains why without decoration: Copilot messages "were automatically included" there "because they were retained and deleted by using the same mechanisms". And then comes the sentence that should make anyone who signs off a compliance plan look up: "Users didn't have to be using Teams for the retention policy to apply to Copilot."
In other words: the coverage was never a product decision. It was a side effect of the plumbing. Teams and Copilot store their compliance copy in the same place — a hidden folder in the user's Exchange mailbox — and that is why one policy reached both. Coverage that exists because two things share a pipe ends the day the pipes are separated, and the vendor picks that day. Separating the locations is the right call, too; Copilot is not Teams, and treating them as if it were was the workaround. So we are not saying the change is badly made. We are saying the control you had was not the one you thought you had, and that the only place this is announced is a message centre post with an expiry date.
Where there was one checkbox there are now eleven names
New policies no longer have an AI location: they have three groups, with eleven applications named one by one. Under Microsoft Copilot experiences: Microsoft 365 Copilot, Security Copilot, Copilot in Fabric and Copilot Studio. Under Enterprise AI apps: Entra-registered AI apps, ChatGPT Enterprise and Microsoft Foundry. And under Other AI apps: ChatGPT, Google Gemini, the consumer Copilot and DeepSeek. The fact that ChatGPT, Gemini and DeepSeek now appear in your tenant's retention picker says a fair amount about where Microsoft thinks the compliance problem will be in 2027, and we do not think they are wrong.
Before anyone gets excited about the list, read the sentence that bounds it, because it is harder than it looks. The retention policy on its own reaches prompts and responses for two of those eleven: Microsoft 365 Copilot and Copilot Studio. The other nine — Security Copilot, Copilot in Fabric, Entra-registered apps, ChatGPT Enterprise, Microsoft Foundry, ChatGPT, Gemini, the consumer Copilot and DeepSeek — only come in "when they have a collection policy with the setting to capture content". Which means another piece on top, and it is not a checkbox, it is an assembly. Ticking the location and considering the job done is exactly the mistake that has just cost half the world its Copilot coverage.
The clock does not start when you think, or end when you think
If you are going to create the new policy, it is worth knowing what you are buying. Behind every Copilot interaction there is a timer job from the Exchange service that "typically takes 1-7 days to run", an intermediate folder called SubstrateHolds where the message sits "for at least 1 day", and another pass of the same job for permanent deletion. Microsoft adds it up for you with its own example: a delete-after-one-day policy "could take 16 days" before the message stops coming back in an eDiscovery search. We wrote about that arithmetic when we explained why Teams chats are not in your backup, and it applies here too.
And a warning the documentation flags in a call-out of its own, which invalidates the verification method everyone is about to use: "Messages visible in your AI apps are not an accurate reflection of whether they are retained or permanently deleted for compliance requirements." Opening Copilot and checking whether the conversation is still there proves nothing, either way. The valid check is an eDiscovery search.
The backup does not cover it either, and it does not find out
The natural reaction is "fine, I will put it in the backup". You cannot. Microsoft 365 Backup protects three workloads — OneDrive, SharePoint and Exchange Online — with a window configurable to 3 months, 6 months, 1 year or 2 years, at $0.15 per GB per month with restores included. Copilot is not on that list. Neither is Teams, which is what we covered at the time.
There is another line on that same page which we already quoted in August, when writing about archiving, and which changes meaning here: retention and deletion policies "don't affect the backup recovery window, which remains fully isolated from those policies". It is a good sentence — it protects you from a policy-driven deletion emptying your backup — and at the same time it is the whole diagnosis: retention and backup are two systems that do not talk to each other. What retention keeps is not in the backup; what the backup keeps does not obey retention. If your compliance plan assumes one backs up the other, the plan has a hole that does not surface until somebody asks for a specific record. The immutability caveat runs the same way, and it is declared here with a candour that is not common: the product "follows that definition except for disallowing deletion", with a fixed 90-day grace period after offboarding. Append-only is not immutable, and the vendor says so.
Our Backup 365 service exists precisely because of this gap, and the rule we apply is the same one we use outside the cloud: 3-2-1 and immutable copies, because Microsoft 365 does not back itself up for you. Translated into what we do when we come into a tenant: list which workload has a backup, which has retention, which has both and which has neither. The most common mismatch is not a missing backup; it is that the company assumed retention was the backup. And who holds the key matters too, which is what we found when we wrote about how your Microsoft 365 backup comes in with a key you do not hold.
The other clocks you did not start either
Microsoft 365 does not have "a retention". It has several independent counters, with different deadlines, started by different actions and stopped by different people. This is what there is today, with the numbers from the official documentation:
Two sentences in that documentation do not fit in a cell. One: "The Recycle Bin isn't indexed and therefore searches don't find content there. This means that an eDiscovery hold can't locate any content in the Recycle Bin in order to hold it." Mind what that says and what it does not: a hold that was already in place does govern, and the same page spells it out — a OneDrive under an eDiscovery hold is not deleted until the hold is removed. What you cannot do is place a new hold on something that has already dropped into the Recycle Bin, because search cannot find it in there. Put differently: the 93 days are not a hole, they are a window during which the decision to retain had to have been made already. The second sentence left us staring at the screen for a while: "After 12 month of Unpaid storage/archive the OneDrive Data might be deleted regardless of Retention settings, retention policies, eDiscovery, and all holds." Read it again — the missing "s" is theirs. An unpaid invoice outranks a legal hold, and no Purview policy fixes that. It is the kind of small print that shows up the day somebody stops paying for an archive nobody remembered switching on.
The pattern repeats outside Microsoft 365, incidentally: your log window almost never covers the incident window, which we measured when we wrote about how the advisory came 47 days late and your logs last 30. The useful question is not "do I have retention?", it is "how many days, counted from which act, and who can stop it?".
What we would not do, even if it costs us a sale
If in your company Copilot conversations are not business records — nobody will ask for them in an audit, they do not underpin a decision, there is no regulator behind them — the right answer to MC1481313 is not to create the new policy, and to write down why. Creating a just-in-case retention over AI interactions is not free: what you retain you must be able to find and hand over, and you have just added eleven data sources to your next eDiscovery. A control you have not decided on is a liability that looks like an asset.
Nor are we going to sell the easy remedy here. There is no product we can put on top that turns a conversation with an assistant into a business record if your company has not first decided that it is one. That decision belongs to the board, not to the sysadmins, and once it is made the technical part is almost boring. When it is not made, no tool substitutes for it.
Six checks before mid-November
- Pull the list with PowerShell, not the portal, and with the right switch. In Security & Compliance PowerShell:
Get-RetentionCompliancePolicy -DistributionDetail | Format-List Name,*Location*. The-DistributionDetailswitch is not cosmetic: without it, the documentation itself warns thatDistributionStatusand the*Locationproperty values "will be inaccurate". And do not trust theWorkloadcolumn in the default output: it shows every workload, not the one the policy actually applies to.-TeamsPolicyOnlynarrows the search. - For each one, decide what you wanted to happen with Copilot. Retain, delete, or nothing? If the honest answer is "we had not thought about it", that is a valid answer: write it down and sign it. What is not valid is leaving it unanswered.
- If the answer is retain or delete, create the policy for the Copilot location BEFORE mid-November. Between the conversion and your new policy there is a window where none applies, and that window is yours, not Microsoft's.
- Check the opposite direction. If the policy was delete, it no longer applying means the data is now kept. If you promised someone — a client, a committee, a data protection officer — that this was removed after X days, that commitment breaks on its own.
- Find out who switched on Copilot Studio, Security Copilot or Entra-registered AI apps. They are separate locations with their own policy, IT rarely asked for them, and they are almost certainly not covered.
- Do not verify by opening the app. Microsoft flags it in a call-out of its own: what you see in Copilot does not reflect what is retained or deleted. The valid check is an eDiscovery search, and it is worth running one before the change so you have something to compare against afterwards.
What we actually take away from this notice
It is not Copilot. It is that a compliance control can stop applying without anyone in your company touching anything, and that the only place it is announced is a message centre post which expires in the inbox of an administrator who may no longer work here. That is not a Microsoft failure: it is how software as a service works, and it is better to accept it than to pretend your controls are static. The part that is yours is having written down what you expect from each control, and reviewing that list when the vendor moves something. If your answer to "how is retention configured in your Microsoft 365?" is "we set it up back in the day", this month is a reasonable moment to look at it.
We run that review as part of managing Microsoft 365 and of our compliance and continuity work, and it usually fits in one afternoon: pull the policies, cross them against what the company thinks it has, and hand over the list of the ones that do not match. If you want us to do it on your tenant before mid-November — or just to tell you which of your policies are on the affected list — let us talk.
Sources. The change: Microsoft 365 message centre post MC1481313, "Microsoft Purview | DLM: Legacy Teams retention policies that cover Copilot will be treated as Teams-only", published 28 September 2026, source of the quotations about being treated as Teams-only policies, "Copilot interactions will no longer be retained or deleted through these legacy Teams retention policies", the "beginning in late October 2026 and expected to complete by mid-November 2026" window, and the required action of reviewing existing policies; and entry 571306 of the Microsoft 365 roadmap, published 18 September 2026, with general availability set for October 2026. The mechanics and timings: Microsoft Learn, "Learn about retention for Copilot and AI apps" (read 25 October 2026), source of the legacy "Teams chats and Copilot interactions" location, "Users didn't have to be using Teams for the retention policy to apply to Copilot", the list of three groupings and eleven applications, that the retention policy on its own only reaches Microsoft 365 Copilot and Copilot Studio while the other nine applications also need a collection policy with content capture, storage in a hidden Exchange mailbox folder, the 1-7 day timer job, the one-day minimum in SubstrateHolds, Microsoft's own 16-day example, and the call-out warning that what is visible in the app does not reflect compliance state. The backup: Microsoft Learn, "Overview of Microsoft 365 Backup" (page updated 18 September 2026), for the three workloads, the 3-month, 6-month, 1-year or 2-year window, the $0.15 per GB per month with free restores, the isolation between retention policies and the recovery window, and the caveat that the product "follows that definition except for disallowing deletion" with the 90-day grace period. The other counters: Microsoft Learn, "Recoverable Items folder in Exchange Online" (updated 22 October 2026) for the 14-day default and 30-day maximum; "OneDrive retention and deletion" (updated 23 June 2026) for the 30-day default on a deleted user's OneDrive, Set-SPOTenant -OrphanedPersonalSitesRetentionPeriod, the counter starting only when the account is deleted in Entra ID, the 93 days in the site collection recycle bin, automatic archiving on the 93rd unlicensed day, the line about the Recycle Bin not being indexed and eDiscovery, and the one about 12 months of unpaid archive (the "12 month" typo is the documentation's own); and "Microsoft Entra Backup and Recovery overview" (updated 30 June 2026) for the daily backup, the seven days of history, the P1 or P2 licensing requirement and the non-recovery of hard-deleted objects. What we are not claiming: we have not watched the conversion run in any tenant — the rollout starts now — we give no figure for how many organisations are affected because nobody has published one, and we have not measured the timer job ourselves: those are the numbers Microsoft documents.
Microsoft 365
ES 
CAT 
EN