The change is easy to misread as a naming cleanup. It is a workload separation with a direct effect on preservation and deletion schedules. An organization that set a seven-year retention period—or a 30-day deletion policy—through the older Teams chats and Copilot interactions location could find that rule continuing for Teams while no longer applying to Copilot conversation data.
Microsoft’s roadmap lists the feature as “In development,” targets general availability in October, and limits the initial rollout to Worldwide Standard Multi-Tenant tenants. It does not give a precise deployment date, say whether administrators will receive a tenant-specific Message Center notice, or explain whether Purview will provide a migration report identifying the policies affected. Those omissions mean compliance teams should treat October as a deadline for an inventory, rather than wait to see whether the policy behavior changes in production.
The old combined policy is being retired in practice
Microsoft Learn documentation confirms the historical arrangement behind the roadmap item. Microsoft 365 Copilot and Microsoft 365 Copilot Chat messages were automatically included in the retention location called “Teams chats and Copilot interactions,” despite Copilot use not requiring Teams. The shared behavior existed because Teams and Copilot messages used the same retention and deletion mechanisms.
That design is already obsolete for newly created policies. Purview now exposes Teams chats and Microsoft Copilot experiences as separate locations, and its current guidance says new retention policies must use the newer locations. Microsoft’s September roadmap entry goes further: rather than merely preventing edits to old combined policies, it says those legacy Teams policies will be converted to Teams-only treatment.
The practical point is that a Teams retention policy is no longer evidence that Copilot interactions are governed. Administrators must check for a policy that explicitly covers Microsoft Copilot experiences, rather than infer coverage from a Teams chats setting, a Teams retention report, or a policy name written before the workload split.
Microsoft’s current configuration documentation still says an existing combined policy can be separated manually with PowerShell. For an older policy, Microsoft documents the User:TeamsChatUserInteractions application value to retain the Teams side, while User:M365Copilot is used to add Microsoft 365 Copilot interaction coverage to an eligible policy. The October roadmap item indicates Microsoft is now planning to make the Teams-only result automatic for the legacy policies it identifies.
That documentation and roadmap timing should not be treated as contradictory. The configuration article, last updated June 9, describes today’s administrative options; the roadmap, created September 18, announces the coming service-side treatment. But it does expose a reporting gap: Microsoft has not yet published a detailed migration procedure matching the announced automatic conversion.
Copilot retention means prompts and responses, not every file Copilot touches
The separation matters because Copilot interactions are a distinct category of compliance data. In Purview, retention for Microsoft Copilot experiences covers user prompts and AI responses, including response text, links, and references. Microsoft’s documentation also says Copilot responses in Teams chats and channels can include threaded summaries.
Those interaction records are not simply normal Teams chat objects with a new label. Microsoft stores copies of generative-AI messages in a hidden folder in the Exchange mailbox of the user who ran the AI application. Compliance administrators search that preserved content through eDiscovery rather than by opening a visible Copilot chat history.
Files referenced by Copilot require separate thinking. A retention policy for Copilot interactions preserves the interaction data; it does not turn every underlying file into a retained record merely because Copilot cited or used it. Microsoft says retention labels can be configured to retain the version of a cloud attachment or link referenced in Microsoft 365 Copilot, but that is a separate capability and configuration decision.
This distinction is important for legal, financial, and regulated organizations. A policy designed to retain conversations may preserve what a user asked Copilot and what it returned, while a SharePoint, OneDrive, Exchange, or records-management policy controls the source document itself. Treating the new Copilot policy as a replacement for file retention would leave the governance model incomplete.
The risk runs in both directions: under-retention and over-retention
The obvious failure mode is accidental under-retention after the conversion. If a company needs to preserve Copilot prompts and responses for investigations, regulatory obligations, records schedules, or internal review, then leaving a legacy Teams rule unmodified will no longer do that work once the change reaches the tenant.
The less obvious failure mode is deleting Copilot content too soon. Organizations using delete-only or retain-then-delete Teams policies may have expected a defined Copilot cleanup period as part of their privacy or data-minimization program. When Copilot drops out of the inherited Teams scope, those interactions will no longer follow that deletion rule unless a separate Copilot policy replaces it.
Microsoft’s retention model can also produce the opposite outcome—content remaining longer than the policy owner expects. Where multiple retention policies or eDiscovery holds apply to the same data, Purview’s retention principles resolve conflicts in favor of retention. Microsoft specifically says permanent deletion of AI interaction data is suspended when the mailbox is covered by another applicable retention policy, Litigation Hold, delay hold, or eDiscovery hold.
That means administrators should not duplicate a broad Teams policy as a Copilot policy without examining all policies already targeting the same users. A new longer retention period can preserve data that a short deletion policy was intended to remove; a new deletion rule can be blocked by a longer rule or legal hold. The desired outcome must be tested as a policy combination, not assumed from the behavior of one rule.
What Purview administrators should do before October
The immediate task is an inventory of policies created under the older combined Teams-and-Copilot location. Purview’s Policy lookup can identify retention policies assigned to a particular user, site, or Microsoft 365 group, although policy owners should also review their PowerShell-managed configurations and internal policy documentation because old policy names often conceal the workloads they cover.
For every legacy policy that currently reaches Copilot, teams should document its user scope, retention period, trigger, retention-versus-deletion action, exclusions, adaptive-scope behavior, and the business owner who approved it. That baseline is what makes it possible to prove that the new Copilot policy actually matches the intended schedule.
Administrators should then create or validate a separate retention policy using the Microsoft Copilot experiences location. Microsoft describes that location as covering built-in and custom Copilot experiences, including Microsoft 365 Copilot, Security Copilot, Copilot in Fabric, and Copilot Studio. If the objective is specifically Microsoft 365 Copilot interactions, the scope and user targeting should be checked carefully rather than accepting a broad default selection.
A few operational constraints deserve attention:
- Microsoft says creating retention policies that include Copilot and AI-app locations requires pay-as-you-go billing to be set up, even though it says there is no charge for Microsoft 365 Copilot interactions themselves.
- A submitted Purview retention policy can take up to seven days to distribute and apply, so waiting until the October rollout has begun leaves little room to troubleshoot deployment failures.
- Retention behavior should be validated with eDiscovery and policy status, not the messages that remain visible in Copilot. Microsoft warns that what a user sees in the app is not an accurate indication of whether data is retained or permanently deleted for compliance purposes.
- Expired AI interaction data can remain searchable while it passes through hidden Exchange mailbox folders before permanent deletion. Microsoft says the timing is driven by Exchange timer jobs that typically run within one to seven days, with at least one additional day in the SubstrateHolds folder.
Teams remains covered, but the policy boundary has changed
The October change does not retire Teams retention. The converted legacy policies will continue to operate as Teams-only rules, covering the Teams workload for which they were originally created. Microsoft’s newer configuration choices distinguish Teams chats from Teams channel messages, and organizations with private-channel history need to account for Microsoft’s separate migration treatment for those messages as well.
For Copilot governance, however, the old convenience of inheriting Teams retention is ending. The timing is particularly awkward for organizations that deployed Copilot gradually: a Teams policy created years ago may be quietly governing a much larger Copilot population today than the policy owner ever anticipated.
Microsoft has provided the direction of travel but not the tenant-level migration detail. Before October 2026, the defensible move is to identify every legacy Teams chats and Copilot interactions policy, decide explicitly how long Copilot prompts and responses should be retained or deleted, deploy the dedicated policy early enough to verify it, and preserve evidence of that decision.