By now most Microsoft 365 administrators know that Copilot respects user permissions. It will not surface content that a user doesn't already have access to. That single fact has driven a wave of permissions reviews across organisations preparing to roll out Copilot — cleaning up overly permissive sharing, auditing group memberships, fixing broken inheritance, making sure the permissions model actually reflects who should see what.
That work is important and the right place to start. But permissions are only one layer of the governance picture. As Microsoft prepares to flip Copilot in SharePoint from opt-in to opt-out in mid-June 2026, there are governance decisions at a deeper level that many organisations haven't addressed yet — decisions that go beyond who can see what, into how data is processed, where it goes, and who in your organisation has the authority to make changes to how AI behaves on your sites.
This post is about those decisions.
What Is Copilot in SharePoint?
Copilot in SharePoint is the AI experience built into SharePoint sites. It allows users to have natural language conversations with their site content, generate documents, build and run Skills (repeatable multi-step workflows stored as Markdown files), and create reports and dashboards from SharePoint data. It runs inside any site where a Copilot-licensed user is active and the feature is enabled.
From mid-June 2026, it switches from opt-in to opt-out for every tenant with Microsoft 365 Copilot licences. If your organisation has Copilot licences and you do nothing before mid-June, the floating Copilot button appears in the lower right of SharePoint pages for every licensed user.
That's the context. Here are the governance decisions.
Decision 1 — Opt-in or Opt-out?
This is the most immediate decision and it needs to be made consciously, not by default.
If you do nothing, Copilot in SharePoint rolls out to all your Copilot-licensed users across all sites in mid-June. For organisations that have been preparing for this, that may be fine. For organisations that haven't, it means a significant capability lands in users' hands without any communication, training, or governance framework in place.
The PowerShell to opt out is straightforward — tenant-wide, or scoped to exclude specific sensitive sites. For the technical setup detail, Microsoft MVP Daniel Anderson's Copilot in SharePoint 2026 practitioner guide covers the full admin configuration including the PowerShell commands and rollback playbook.
The governance question to answer: has your organisation made a deliberate decision about this rollout, or is it going to land by default? If your governance group hasn't discussed it, that conversation needs to happen before mid-June.
Decision 2 — Anthropic On or Off? (Especially Critical for EU/UK)
This is the decision that catches most organisations off guard — and for EU and UK organisations, it has direct GDPR implications.
During the current public preview, Microsoft gives admins the option to enable Anthropic as an AI sub-processor. When enabled, the full Copilot in SharePoint experience runs on Anthropic Claude — which provides stronger multi-step reasoning, more reliable Skill execution, and more thorough analytical output.
Sounds straightforward. But here is what the admin toggle doesn't make obvious:
Anthropic is currently excluded from EU data boundary commitments.
For EU and UK tenants, Microsoft has disabled Anthropic by default — a deliberate choice to avoid data leaving the EU boundary without explicit administrator consent. If an EU/UK admin enables Anthropic without understanding this, they are potentially routing organisational data outside the EU data boundary. Under GDPR, that is a data transfer that requires a legal basis, documentation, and in most cases awareness from your data protection team or compliance officer.
The Microsoft documentation is clear on this but it's buried in the setup guides. The toggle is just a toggle in the admin center — it doesn't surface a GDPR warning.
For EU/UK organisations the governance checklist is:
- Is Anthropic currently enabled in your tenant? Check: Microsoft 365 admin center → Copilot → Settings → Data access → AI providers
- If it is enabled, does your data protection team or compliance officer know? Was it a deliberate decision or did an admin enable it without understanding the data boundary implications?
- If it is disabled (the default for EU/UK), is the fallback model sufficient for your use case?
The good news for EU/UK organisations sitting this one out: from the mid-June opt-out rollout, Copilot in SharePoint switches to OpenAI's GPT-5.4 Reasoning model regardless of the Anthropic setting. The Anthropic decision becomes less critical for the SharePoint experience specifically from GA onwards — though it continues to affect the Word, Excel, and PowerPoint Copilot agents.
For non-EU/UK tenants, Anthropic is likely already enabled by default. If you're running the preview, you're probably already on Claude. The data boundary concern is less acute but your DPO should still be aware that Anthropic operates as a Microsoft sub-processor under Microsoft's contractual safeguards — not directly under your own Data Processing Agreement (DPA) with Anthropic.
Decision 3 — Flex Routing During Peak Load Periods
While you're in the admin center reviewing the Anthropic setting, there's another setting worth checking that has similar data boundary implications — Flex routing during peak load periods.
This setting allows Microsoft 365 Copilot to route LLM inferencing outside the EU Data Boundary during periods of peak demand, in order to maintain a consistent Copilot experience. It is enabled by default.
The key details from Microsoft's own description:
- LLM inferencing can occur outside the EU during peak load
- Data at rest continues to be stored inside the EU Data Boundary
- A limited amount of pseudonymised data may be stored outside the EU for security and operational purposes
For most organisations this is an acceptable trade-off — the data itself stays in the EU, only the processing temporarily moves outside. But for organisations with strict data sovereignty requirements or sector-specific regulations, even temporary processing outside the EU may be a compliance concern that needs to be documented and approved.
You'll find this setting at: Microsoft 365 Admin Center → Copilot → Settings → View all
The governance question: is your organisation aware this setting is on by default? Has the decision to allow or disallow flex routing been made deliberately by the right people — not just left as the default? Like the Anthropic decision, this one belongs in your data protection documentation.
Decision 4 — Who Can Create Skills?
Skills are one of the most powerful capabilities in Copilot in SharePoint — and for that reason, one of the most in need of a clear governance framework. A Skill is a Markdown file stored at /Agent Assets/Skills/<name>/SKILL.md on a SharePoint site. It defines a multi-step workflow that any site user with the right permissions can run on demand.
The governance gap here is that Skills can be created by any site user with edit permissions. There is no approval workflow, no governance group sign-off, no central registry of what Skills exist across your tenant.
Consider what a Skill can do:
- Query and summarise sensitive documents
- Generate content that gets published to SharePoint pages
- Process data from lists and libraries at scale
- Run multi-step workflows that touch multiple content areas
A poorly written Skill — or a deliberately manipulative one — can cause real problems at scale. And once a Skill is in the Agent Assets library, it's available to everyone on that site.
The governance framework needed:
- Define who is authorised to create and publish Skills — not just anyone with edit permissions
- Require Skills to be reviewed before they're made available to other users
- Maintain a registry of approved Skills and what they do
- Include Skills in your change management process — a new Skill touching sensitive content should go through the same approval as any major change
This mirrors the principle in enterprise governance documents that Copilot agents require explicit governance group approval before deployment. Skills are agents. They need the same treatment.
Decision 5 — What Goes in SharePoint.md?
Every SharePoint site can have a SharePoint.md file in the root of its Agent Assets library. This file loads automatically into every Copilot chat on that site — it tells Copilot what the site is for, what naming conventions to follow, what rules to apply.
But it's more than a helpful configuration file. As Microsoft MVP Daniel Anderson describes it, the SharePoint.md file is a governance instrument — the mechanism by which a site owner controls how Copilot behaves on their site. You write the rules in it, and Copilot follows them on every chat on that site, automatically, without the user having to re-explain anything.
What it can govern:
- Naming conventions — "all policy documents must follow the format POL-NNN-Title"
- Content boundaries — "only reference content from the Policies library, not the Archive folder"
- Language and tone — "responses should be in formal English and French"
- Process rules — "when creating a new document, always use the approved Policy template"
- Restrictions — "do not summarise or reference documents with a Draft status"
- Site purpose — what the site is for, who uses it, what kinds of requests are appropriate
In governance terms, the SharePoint.md file is where site-level Copilot policy lives. Just as your permissions model controls who can access content, the SharePoint.md controls what Copilot does with that content and how it behaves when users interact with it.
The governance risk if it's unmanaged: if any site member with edit permissions can write whatever they want in the SharePoint.md file without oversight, they can inadvertently — or deliberately — configure Copilot to behave in ways that conflict with your organisation's broader policies. A poorly written file could instruct Copilot to ignore classification rules, bypass naming conventions, or reference content it shouldn't.
The governance framework needed:
- Treat the SharePoint.md file like a site policy document — it should be owned, versioned, and reviewed
- Only site owners should have permission to edit it — not general site members
- It should be reviewed as part of the regular site governance review cycle
- Changes to it should go through the same change management process as any other site configuration change
- For larger organisations, a central template or set of approved instructions should be provided so site owners aren't writing governance rules from scratch
The SharePoint.md file is one of the most powerful governance tools Copilot in SharePoint gives you. Used well, it makes Copilot behave consistently and correctly on every site. Left unmanaged, it becomes a governance gap.
Decision 6 — Permissions Reviews Before the Rollout
Back to where we started — because this step can't be skipped even if the others are handled.
Copilot respects permissions. That's the feature, not a workaround. But it means Copilot is only as trustworthy as your permissions model. If your permissions are overly permissive — if users have access to content they shouldn't have because inheritance was never broken, or because someone added them to a group years ago and nobody reviewed it — Copilot will surface that content to them.
The mid-June rollout is a forcing function for a permissions audit if you haven't done one. Before Copilot goes live for your users:
- Review group memberships — particularly Site Owner and Site Member groups
- Check for broken inheritance that may have created unintended access
- Review external sharing settings — are there sharing links that should have expired?
- Check for inactive users with active permissions
- Review sites where sensitive content lives — HR, legal, finance — and ensure those permissions are tight
Microsoft's SharePoint Advanced Management (SAM) provides the tooling for this — permissions reports, inactive site detection, and restricted content discovery for sites that should never be surfaced by Copilot regardless of permissions.
The June Deadline
Mid-June 2026 is not a recommendation — it's when the rollout starts. Once it begins, Copilot in SharePoint appears for every Microsoft 365 Copilot licensed user in your tenant unless you've actively opted out.
The minimum governance actions before that date:
- Make the opt-in/opt-out decision — explicitly, as a governance decision, not by default
- Check Anthropic status — especially for EU/UK tenants. Is it on? Does your data protection team know?
- Check flex routing status — is it on by default? Has the decision been made deliberately and documented?
- Define who can create Skills — add it to your permissions and change management framework
- Assign ownership of SharePoint.md files — at least for your highest-traffic sites
- Run a permissions review — on sites where sensitive content lives
None of these require deep technical implementation. They require governance conversations that most organisations simply haven't had yet because the June deadline has only recently come into focus.
If your intranet or SharePoint governance document doesn't yet include a section on Copilot, now is the time to add one. The baseline governance questions — who can do what, what requires approval, what happens with the data — apply to AI capabilities just as they apply to permissions and content management.