If you’re an admin in the Microsoft 365 world, you already know that the compliance stakes are higher than ever. With Microsoft Copilot and other AI-powered tools now baked directly into M365, retention policy management isn’t just a check-the-box affair—it’s core to keeping your organization safe, compliant, and audit-ready.

Copilot doesn’t just look at documents or emails. It engages with your data in new ways that introduce unique data lifecycle, governance, and legal risks. What’s changed? A lot. Classic retention controls that worked for Exchange or SharePoint need to evolve to cover how Copilot stores, reuses, and deletes interaction data. Ignoring this can expose you to legal risk, data leaks, or regulatory violations.

Admins today must align retention policies in Copilot not only for data protection and compliance audits, but also to avoid nasty surprises like shadow data or unnoticed policy gaps. Effective Copilot governance strategies and secure technical enforcement can help you roll out AI safely, with strong contracts, access controls, and automated compliance built in. Let’s break down what makes retention in Copilot different—and why you can’t afford to leave it to chance.

9 Surprising Facts about Copilot and Retention Policies

1. Retention can affect model suggestions: Where and how long code or prompt history is retained can change the context Copilot uses, altering its suggestions even for identical prompts.
2. Enterprise retention might be longer than you expect: Organizational logs and telemetry tied to Copilot can be retained for compliance reasons for months or years, not just transient debugging windows.
3. Personal vs. organizational data separation isn’t absolute: Even when Copilot separates personal data and org data, retention systems and backups can create overlapping copies that need policy controls.
4. Retention policies impact legal discovery: Data kept by Copilot (code snippets, prompts, chat history) can be discoverable in litigation or audits if retention policies preserve them.
5. Short retention reduces model "learning" visibility: Aggressive deletion windows can limit ability to audit why Copilot made particular recommendations, complicating debugging and safety investigations.
6. Retention settings can be attack vectors: Misconfigured retention (too long or accessible) increases exposure of proprietary code, secrets, or PII that Copilot may have seen or logged.
7. Retention interacts with fine-tuning and telemetry: Data retained for telemetry or fine-tuning pipelines can influence future model behavior unless explicitly excluded by policy.
8. Different Copilot features have different retention rules: Code completion, chat transcripts, feedback, and telemetry often follow separate retention schedules and legal treatment.
9. Retention policy choices affect user trust and adoption: Transparent, restrictive retention dramatically increases developer willingness to use Copilot in sensitive projects, while lax retention reduces enterprise adoption.

Understanding Retention Policies in Microsoft Copilot

Retention policies have always been a foundation for compliance in Microsoft 365, but Copilot shakes things up. Unlike classic files just sitting around, Copilot generates, processes, and stores new interaction data with every user prompt and AI-generated response. Suddenly, data isn’t just something that’s created and forgotten—it’s an active part of the workflow, constantly flowing through new data paths.

So, what’s the big deal? Copilot interacts with data in ways that break the traditional mold. Not only are admin-driven controls needed for emails or docs, but also for user chat histories, AI-generated text, and the context Copilot pulls together. The usual retention timers? They apply here too—but you need to know exactly when and how those clocks start, especially when generative AI is involved.

With all this movement, it’s no longer enough to set one catch-all retention policy. Now, you need a strategy that accounts for the cross-platform nature of Copilot, the different data types in play, and the complexity of timing—when does retention start, and when should deletion be forced? Think of this as a new layer in your Microsoft 365 governance that requires ongoing attention and deliberate configuration.

In the next sections, you’ll see exactly what Copilot retention policies look like, learn their key principles, and discover how lifecycle management works from start to finish. This is your guide to getting out in front of policy gaps, ensuring nothing slips through the cracks, and making sure your AI-powered environment is actually as secure and compliant as you need it to be.

Core Concepts of Copilot Data Retention Policies

1. Defining Retention Policies for Copilot: Retention policies dictate how long Copilot keeps user prompts, AI-generated outputs, and interaction metadata. They're designed to ensure data isn’t held longer than necessary for compliance, security, or organizational policy reasons.
2. Types of Copilot Data Covered: Common data types include user queries, Copilot’s AI-generated responses, underlying context collected for processing, and sometimes summarized or referenced document content. Retention applies to all these, not just chat logs.
3. When Do Retention Policies Start? The retention clock usually starts at creation—when a Copilot interaction occurs, or when data is stored in an associated hidden mailbox folder or application data repository. This timing is crucial for deletion scheduling.
4. Principles of Retention Policy Timing: Copilot retention periods mirror those of the M365 service it's integrated with—such as Exchange, SharePoint, or Teams—but unique Copilot artifacts may require their own explicit timing rules to avoid overlap and confusion.
5. Policy Enforcement and Overrides: Retention policies can be set to retain-only, delete-only, or retain-and-then-delete. Copilot data must respect these, but admins can enforce overrides for legal holds or compliance situations—often via Purview or related controls.
6. Real-World Example: Suppose your org has a 7-year legal hold on financial emails. Copilot-generated summaries or recommendations based on those emails become subject to the same retention. If Copilot interacts with data from multiple workloads, cross-platform alignment is essential to prevent gaps.
7. Integration with Broader M365 Governance: Retention policies for Copilot aren’t isolated; they work in tandem with SharePoint, OneDrive, and Exchange settings. Misalignment can create compliance risks, so policies should be revisited and tested as Copilot features evolve.

The Data Lifecycle Management Process for Copilot

1. Prompt Capture: The lifecycle begins when a user interacts with Copilot—typing a query, generating a document, or asking for a summary. That input, and any content Copilot pulls in, is captured as a record within the relevant workload (like Exchange or SharePoint).
2. Data Storage: After capture, the interaction data is stored—often in a hidden mailbox folder or encrypted database tied to the user or workload. The storage location affects how retention policies are applied and reviewed.
3. Retention Period: Once stored, Copilot data “waits out” the mandated retention period. This can be set in Purview, with specific durations for each content type. During this time, data may be discoverable for investigations or audits but is protected against premature deletion.
4. Ongoing Management and Monitoring: Admins can monitor lifecycle status through compliance dashboards, audit logs, and timer jobs that flag upcoming retention expirations, giving time to intervene if a legal hold or manual override is necessary.
5. Permanent Deletion: When the retention period expires, and there are no overrides or holds, a background job (like a timer job in Exchange or SharePoint) flags the Copilot data for permanent deletion. This deletion is irreversible, which supports data minimization and privacy compliance.
6. Lifecycle Visualization: Think of Copilot data flowing through a policy-driven “river”—entering at prompt capture, pausing at storage islands, lingering during retention, and finally reaching the deletion waterfall. Each step is controlled for compliance.
7. Lifecycle Interventions: Admins can intercept or pause the lifecycle at key points by applying holds, correcting policy misconfigurations, or generating reports for compliance tracking. This delivers both flexibility and assurance, critical for regulated industries. For a broader perspective on Microsoft 365 governance discipline, check out this discussion.

Copilot Data Storage and Security Practices Explained

It’s one thing to have data, but quite another to keep it safe and properly managed. When you bring Microsoft Copilot into your environment, you’re not just introducing a clever AI assistant—you’re introducing new data, new storage locations, and new security considerations that you probably haven’t dealt with before.

Copilot data lives in places that might fly under the radar: hidden mailbox folders, embedded application storage, or encrypted databases linked to users and workloads. Data residency (where it’s stored geographically) is more than a technical detail—it can determine your compliance with everything from US law to GDPR.

For security, Microsoft’s approach goes beyond basic encryption. They’ve layered in access controls, employee restrictions, and strict protection for sensitive data labels. Third-party sharing is a hard “no” for Copilot content by default, but you’ll want to know exactly how this is audited and enforced—especially as new integration points roll out.

In the sections that follow, you’ll see where Copilot data is physically stored, how Microsoft keeps it locked down, and what you should know about employee access, external sharing, and protection against leaks. With Copilot’s architecture differing from classic Exchange or SharePoint workloads, understanding these changes isn’t optional—it’s essential for any admin managing risk and compliance today.

Copilot Data Storage Locations and Geographic Considerations

Where Copilot data ends up isn’t just an afterthought—it’s central to addressing compliance and regulatory risks. Microsoft Copilot stores most interaction data in user- or workload-specific repositories that are often “hidden” from direct user access. For instance, when Copilot works with Outlook or Teams, interaction logs and generated outputs are usually stored in Exchange Online hidden folders or in application-specific databases linked to user accounts.

Data residency matters here. According to Microsoft documentation, Copilot data is stored in the same regional datacenter as the originating M365 workload. So, if your org’s Exchange data sits in a US datacenter, Copilot’s Exchange-linked data will, too. A recent Gartner report found that 67% of enterprises ranked data residency as a top AI compliance concern for 2024, especially when dealing with sensitive US patient or financial information.

Case studies show that organizations with strict US-only data residency requirements can rely on Microsoft’s geo-fencing commitments for Copilot services; however, admins should double-check workload residency settings for SharePoint, OneDrive, or Teams to avoid accidental data spills across regions. The physical storage approach for Copilot can differ from classic SharePoint/OneDrive repositories—application-specific data could be more segmented, which helps with data minimization but may complicate eDiscovery.

Experts recommend reviewing Microsoft’s regional storage commitments annually, as the architecture can shift with new features or regulatory changes. Ultimately, Copilot data storage is architected to align with your tenant settings, but the admin’s job is to validate and monitor for exceptions—especially when integrating with cross-border teams or sensitive regulated industries.

Sensitive Data Protection and Employee Access Controls

1. Sensitivity Labels for Copilot Content: Microsoft extends sensitivity labels from Purview to Copilot-generated and referenced content. If a user’s prompt or Copilot’s answer touches confidential data, sensitivity labels restrict what can be done—blocking forwarding, copying, or even read access except for authorized staff.
2. Limited Employee Access at Microsoft: Backend engineers and data center staff at Microsoft do not have standing access to tenant Copilot data. Emergency access follows strict “break-the-glass” protocols, is audited, and must be explicitly authorized. This reduces the risk of insider leaks.
3. Role-Based Access Control (RBAC) and Entra ID: Admins can fine-tune who at your organization can access Copilot data using Entra ID and RBAC. This covers not just end-user data, but also admin audit trails and eDiscovery exports, locking down access during onboarding, role changes, or exit events.
4. Encryption of Copilot Data: All Copilot data at rest and in transit is encrypted with enterprise-grade algorithms. Even if an unauthorized party tried to intercept the content, it would be mathematically unusable.
5. Automated Auditing and Alerting: Microsoft logs every access to Copilot data—whether by users, admins, or automated processes—so you have a defensible audit trail in case of investigation. For more insights on granular data security and automation best practices, see Dataverse security strategies.
6. Preventing Unauthorized Disclosures: Controls are in place to prevent the accidental release of Copilot-generated sensitive outputs, including policy-driven restrictions, DLP rules, and alerting on anomalous access patterns, ensuring your sensitive data doesn’t walk out the virtual door.

Managing Third-Party Sharing and Application Data Handling

• No Default Third-Party Sharing: By default, Copilot data is not made available to external parties or apps outside Microsoft 365. This policy keeps user prompts and responses in-house, reducing the risk of leaks.
• Strict Application Data Handling: Copilot’s app data stays confined to the relevant M365 service with explicit application boundaries, ensuring it’s not inadvertently exposed via Teams bots, API calls, or connectors.
• Auditing External Access Requests: You can use enhanced auditing to monitor and flag any attempts at unauthorized or risky third-party sharing, much like advanced SharePoint/OneDrive controls described here.
• Admin-Driven Restrictions: Admins have the tools to lock down sharing further—issuing new policies, disabling risky connectors, and proactively reviewing sharing audit logs for Copilot workloads.

Compliance and Regulatory Requirements for Copilot Data

If you’re aiming for full compliance in the Microsoft Copilot era, you can’t just assume your old policies will cover you. Regulatory demands around AI and user-generated content are only getting stricter—especially for US public sector, healthcare, or financial organizations. Copilot brings in a whole new class of data, and that means rethinking both your policy enforcement and your auditing game.

This section will give you the lay of the land for regulatory standards like GDPR, HIPAA, and more, showing where Copilot fits and what changes. You’ll get clarity on how to align Copilot’s controls with enterprise-wide legal holds, privacy protections, and audit requirements. It’s not just about making sure policies exist—it’s about executing them properly at every step, and being able to prove it to auditors or regulators.

We’ll also explore how tools like Purview and Defender for Cloud can unify compliance monitoring and continuous reporting, so you’re not stuck playing catch-up when an audit comes your way. If you want to dig deeper on common pitfalls in retention and compliance drift, check out this episode on Microsoft 365 compliance drift—it’s an eye-opener.

Read on to see which major regulations matter for Copilot, how Microsoft maps controls for each, and how to supercharge your eDiscovery and audit workflows to keep your organization safe if the lawyers—or the regulators—come calling.

Meeting US Compliance and Global Regulatory Standards

• GDPR Compliance: Copilot must ensure EU residents’ data is processed lawfully, stored with clear purpose limitations, and can be deleted or exported upon request. Data residency and consent are critical for GDPR compliance.
• HIPAA Safeguards for Healthcare Data: For US healthcare providers, Copilot interactions involving protected health information (PHI) must follow HIPAA security and privacy rules. Data transmissions are encrypted and access controls are enforced to keep PHI safe.
• US-Specific Compliance Management: Federal, state, and local agencies need Copilot to support FedRAMP, CJIS, and other US-specific compliance frameworks. Data is stored domestically, with audit trails and incident reporting requirements met by native Microsoft controls.
• Cross-Border and Multi-Regional Footprints: Multinational organizations must ensure Copilot doesn’t create accidental policy misalignment between EU, US, and APAC regions. Tenant configuration and policy review are crucial to prevent data residency or access conflicts.
• Best Practices for Regulatory Alignment: Use a combination of Purview DLP, auto-labeling, RBAC, and audit reporting to bridge gaps between Copilot and workloads like Exchange or SharePoint. This unified approach is essential for holistic compliance. For continuous monitoring and automated remediation, check out compliance management with Defender for Cloud.
• Policy Documentation and Evidence Collection: Keep full documentation of Copilot policy design, enforcement, and incident handling for audits. Test policies proactively and maintain a clear map of responsibility across global business units.

Enabling eDiscovery and Audit Capabilities for Copilot

• eDiscovery Integration: Copilot-generated content, prompts, and responses are indexed for compliance eDiscovery—allowing legal, HR, or security teams to run searches across user interactions just like with emails or chats.
• Legal Hold Workflow: When a legal hold is enacted, Copilot data subject to that hold is flagged and preserved regardless of other retention settings. Content isn’t deleted until the hold is lifted, reducing legal exposure.
• Purview Audit Trail Management: Every Copilot interaction can be tracked with audit logs—documenting user actions, admin changes, and background retention/deletion jobs. Teams using Purview Premium have extended retention and forensic tracking capabilities. Curious about advanced audit practices? See Purview Audit’s deep dive.
• Defensible Reporting for Regulators: eDiscovery and audit tools help counsel and compliance admins produce time-stamped, tamper-evident reports—key for satisfying regulator or court demands with confidence.
• Proactive Compliance Monitoring: Automated alerts and ongoing policy checks catch potential policy drift before it becomes a business problem. Integration with SIEM/SOAR tools ups the game for forensic readiness and real-time risk detection.
• Data Lifecycle Audit Visualization: Dashboards and logs let admins step through the lifecycle of Copilot data from prompt to deletion, showing retention triggers, holds, and deletion schedules at a glance.

Data Deletion and User Offboarding in Copilot

Setting up a solid workflow for data deletion and user offboarding in Copilot is crucial. Data doesn’t delete itself, and ex-employees’ content can easily linger—turning into a compliance time bomb or a liability if not handled right. Copilot, like the rest of Microsoft 365, gives you several policy-driven tools to ensure information is wiped when the time is up, or retained if the lawyers say so.

What matters most is understanding how deletion works in Copilot’s world. It’s about more than emptying a recycle bin. Data retention overrides, timer jobs, and content path reviews all play a part in making sure content gets cleaned up—no exceptions. Policy timing becomes a tactical consideration: when does the clock start for Copilot artifacts, and what can you do if something needs removing sooner (or holding on longer) than usual?

Offboarding, meanwhile, means crossing your T’s and dotting your I’s as staff leave—making sure access is revoked, data is retained or deleted according to policy, and compliance is checked every step of the way. Overlooking even one mailbox or hidden folder can come back to bite you in the audit, or worse, during litigation.

We’ll step you through how to set up delete policies, overrides, and tailored workflows for key Copilot scenarios. You’ll also get a checklist of best-practice offboarding moves to keep your org clean, legal, and ready for whatever comes next.

How to Configure Data Deletion and Retention Overrides

1. Identify Copilot Data Content Paths: Before configuring deletion, map where Copilot data resides—hidden mailbox folders, Teams chats, application databases, or SharePoint-integrated files. Use Purview and compliance dashboards to ensure no data path is missed.
2. Set Up Delete-Only Policies: For scenarios where retention isn’t required, configure delete-only policies in Purview or via PowerShell. Define clear triggers and timeframes, such as deleting Copilot prompts after 30 days if they contain no regulated data.
3. Apply Retain-and-Then-Delete Controls: In regulated industries, combine retention and deletion—set a mandatory retention period, then list the specific conditions under which Copilot data should be permanently purged. Confirm timer jobs are enabled to initiate deletion automatically when the retention window closes.
4. Leverage Retention Overrides: When legal or compliance demands change, apply policy overrides at the data container or user level. An override can pause deletions (using a legal hold) or extend retention for specific records. Overrides are visible in audit trails for defensibility.
5. Monitor Deletion Workflows: Use activity logs and timer job reports to track when Copilot data is scheduled for deletion, and validate that removal actually occurs. Test policies by running review jobs and spot-audits to ensure compliance isn’t theoretical.
6. Customizing for Unique Copilot Scenarios: For Copilot features integrated with multiple workloads, ensure policy alignment across all relevant platforms (Exchange, Teams, SharePoint) to avoid retention gaps or conflicts—a key cross-platform governance step.
7. Example in Action: Let’s say a departing manager’s Copilot prompts reference sensitive HR documents. You’d review content paths, apply any required legal holds, and queue prompts for scheduled deletion, using a “retain-then-delete” policy to close the loop and protect your organization.

User Offboarding and Copilot Data Retention Strategies

• Policy-Driven Data Retention for Departing Staff: Apply retention (or deletion) policies to Copilot data tied to ex-employees’ accounts and ensure ex-staff mailboxes (including hidden folders) are properly flagged.
• Automated Access Revocation: Use Entra ID or PowerShell to disable and remove access to Copilot workloads during offboarding, closing down any vectors for accidental or malicious exposure.
• Audit and Document Offboarding Actions: Keep detailed logs of policy applications, deletions, and access removal to defend your process in regulatory reviews. For tips on securing guest and ex-staff accounts, see this guide to handling M365 guest accounts.
• Legally Defensible Recordkeeping: Ensure all offboarding steps can be audited, verified, and reproduced for compliance evidence in the case of litigation or a data subject access request.

Copilot Data Processing and Use in AI Training

One question that’s top of mind for many admins: where does Copilot data go after you hit “Enter,” and is it being used to feed Microsoft’s AI models? Understanding Copilot’s technical approach to data processing is critical—not just for compliance, but for privacy and user trust. Data isn’t just processed and tossed aside. It can move into log files, hidden folders, and, depending on policy, might even be considered for future AI training if certain safeguards aren’t in place.

Microsoft walks a tightrope between enabling Copilot to learn and improve, and making sure user data is not misused or inadvertently exposed to machine learning outside your organization. There’s a robust framework in place that triggers further scrutiny depending on the data’s sensitivity, origin, or user consent settings.

The next two sections will demystify how Copilot handles user input—from intake to secured storage—and lay out the exact policies Microsoft applies to ensure most Copilot data stays out of the AI training pool by default. Admins will also get insight into responsible AI guardrails, opt-out mechanisms, and what the inclusion/exclusion process means for real-world deployments.

With regulators focusing more each year on AI transparency and model training data hygiene, knowing these flows isn’t just technical trivia—it’s key to defending your AI posture if privacy questions (or auditors) ever come knocking.

Technical Details of Copilot Data Processing

Copilot processes user prompts by ingesting the text you type, pulling associated context from connected workloads, and generating results via secure servers. User prompts and generated responses are captured as structured records, often stored in hidden mailbox folders or dedicated databases depending on the M365 workload involved. Data is encrypted at rest and in transit to prevent unauthorized access.

Retention logic is built into the data processing pipeline. Once the prompt and response are created, timer jobs or policy engines determine how long the interaction stays stored before it’s deleted per your organization’s retention policy. Copilot itself does not process or store data outside authorized environments to ensure compliance boundaries are respected.

Policies on AI Training Data and Data Usage Restrictions

1. Default Exclusion from AI Model Training: By default, Copilot in Microsoft 365 does not use organizational user data—prompts, responses, or context—for training public or shared AI models. This protects sensitive business and personal information from being reused for AI model improvements outside your tenant.
2. AI Training via Explicit Consent Only: In special programs or by admin-driven exception, certain Copilot data may be considered for AI improvements, but only after explicit user or org consent is granted. Opt-in banners and policy settings make this process transparent and auditable.
3. Responsible AI Guardrails: Data flagged as sensitive or labeled with high confidentiality tags is automatically excluded from any training pool, no matter individual user settings. Microsoft enforces this with a combination of policy logic, technical controls, and compliance audits.
4. Auditing and Oversight for Data Usage: Admins can review AI training inclusion logs and opt-out status per user or workload. Reports help compliance officers prove, if needed, that sensitive Copilot interactions have never left organizational boundaries. For a real-world perspective on Responsible AI, check out the role of governance boards in AI risk management.
5. Dynamic Policy Adjustments: Sensitivity labels, risk analytics, and lifecycle triggers can automatically adjust whether certain Copilot data is considered for AI learning. If a user’s role changes, or data is reclassified, retention and AI inclusion policies can adapt on the fly, maintaining compliance in evolving environments.
6. Exclusion from Third-Party Model Training: Copilot data is never shared with third-party AI platforms—like ChatGPT Enterprise or external Microsoft Foundry models—unless very explicit, contractual opt-ins are given and logged. Most organizations, by default, will never see their Copilot data leave Microsoft’s secure clouds.
7. Continuous Policy Oversight: Governance boards and control-plane policies are vital for monitoring and enforcing responsible usage. As discussed at length in this guide on safe AI governance, it’s not just about the technical configuration, but ongoing review, separation of operational and control planes, and proactive mitigation of AI risks.

FAQ: microsoft 365 copilot and retention policies

What is the relationship between Microsoft 365 Copilot and retention policies?

Microsoft 365 Copilot uses content that lives in Microsoft 365 services, so retention policies and retention labels configured in Microsoft Purview still apply to content Copilot can access. Retention for Copilot means the underlying items (emails, SharePoint files, Teams chats and Copilot interactions) remain subject to retention and deletion rules, and a retention policy is configured and enforced through the Microsoft Purview portal to meet compliance requirements and prevent unwanted data loss.

How do retention policies for Copilot affect Teams chats and Copilot interactions?

Retention policies for Teams can include Teams chats, channels, and meeting recordings; when Copilot in Teams generates or stores interaction content, that content is subject to the same retention policies for teams. If a retention policy is configured to retain and then delete, the Copilot-related content will be preserved for the retention period and then deleted at the end of the retention period, ensuring compliance while reducing over-retention.

How do I create and configure a retention policy for Copilot data?

To create a retention policy, go to the Microsoft Purview portal and create and configure retention policies targeting locations where Microsoft 365 Copilot data resides (Exchange, SharePoint, OneDrive, Teams). Use static policy scopes for retention or include specific Microsoft 365 groups and mailboxes. Configure the policy actions (retain only or retain and then delete), set retention periods, and release the policy for retention when ready. Learn about retention on Microsoft Learn for step-by-step guidance.

How long does it take for retention to start working after a policy is applied?

Retention works as soon as the retention policy is published, but practical application can take time: policies may take up to 24 hours or longer to fully apply across all locations. The retention period usually starts when the item is created or modified, depending on policy configuration—so understand when you start the retention period and how multiple retention settings (labels and policies) interact in your tenant.

What happens if multiple retention policies or labels apply to the same Copilot content?

When multiple retention policies apply, Microsoft 365 retention logic chooses the most restrictive setting that preserves content longest. If a retention label is applied to content and a retention policy also covers the same item, policies that retain longer or prevent deletion will usually take precedence. You can review policy conflicts in the Microsoft Purview portal to ensure the desired outcome for Copilot content and learn about retention policies for Microsoft 365 to plan single retention policy or multiple retention scenarios.

Can Copilot access content that is subject to a retention hold or litigation hold?

Yes, Copilot can access content for generation and summarization if a user has permission to that content, but retention holds and litigation holds prevent deletion and preserve content in place. Holds are separate from retention policies and are part of Microsoft 365 security and compliance controls; if content is subject to retention or legal hold, it will remain available to meet compliance requirements and will not be removed by retention deletion actions.

How do retention policies and data loss prevention (DLP) work together with Copilot?

Retention policies focus on preserving or deleting content based on compliance rules, while data loss prevention and data loss controls prevent sensitive data exposure. For Copilot and AI apps, combine retention policies for Microsoft 365 Copilot data with DLP policies to reduce data loss risks: configure DLP rules for Teams chats and Copilot interactions, restrict sharing, and monitor Copilot usage. Use Copilot Studio and governance controls to limit what Copilot can ingest and ensure compliance requirements are enforced.

Where can admins learn about retention for Copilot and verify policy configuration?

Admins should use Microsoft Learn and the Microsoft Purview portal to learn about retention policies, retention and deletion, and retention policy location specifics. In the Purview portal you can create a retention policy, verify that a retention policy is configured correctly, view which items are subject to retention, and monitor policy deployment. For Copilot-specific guidance, reference documentation for copilot for Microsoft 365 and copilot studio to understand how Microsoft 365 Copilot data is handled and how retention policies for Copilot integrate with existing compliance workflows.