Copilot Model Governance: How to Choose OpenAI vs. Claude

Copilot model governance just became a standing item on the CIO agenda. On November 5, 2026, Charles Lamanna announced on the Microsoft Copilot Blog that Claude models in Microsoft Copilot are coming into the EU Data Boundary by the end of 2026, so EU and EFTA customers will no longer have to choose between Claude and the regional processing commitments they rely on. It is a meaningful step, but it is a commitment rather than a live state, and it does not cover the United Kingdom.

For CIOs, IT directors, and AI-program leaders, the announcement confirms something bigger: model choice inside Microsoft Copilot and Copilot Studio is now a decision your organization owns, not a vendor default you inherit. The question is no longer whether you can use a different model. It is which model you allow, for which workload, under which data terms, and who decides.

TL;DR

Copilot model governance is the practice of deciding which AI models your organization allows in Microsoft Copilot and Copilot Studio, for which workloads, under which data terms, and who owns that decision. It takes a per-workload selection standard, a clear position on each model's data terms, and an operating model that stops makers from silently choosing models under conflicting terms.

Key Takeaways

Model choice is a governance decision, not a maker preference. Once makers can pick a model per agent, someone has to own which model is allowed for which workload.
Terms follow the operator, not the brand. OpenAI and Claude models can each sit under different terms, depending on who operates them. Microsoft-operated models, AI subprocessors, and independent processors are three different risk positions.
The EU Data Boundary change is a commitment, not a live state. Microsoft still documents Claude as excluded today. The change is due by the end of 2026 for the EU and EFTA, and it does not cover the UK.
Disabling a provider has side effects. Copilot Studio agents fall back to the default model, but Word, Excel, and PowerPoint Agents stop working without Anthropic.
Admin controls work at the provider level. The Microsoft 365 admin center scopes access to a provider, not a single model, so an approved-model list still needs policy behind it.
Cost is now a design constraint. About one in five McKinsey respondents say AI operating costs have constrained their organization's AI use.

Why Copilot Model Governance Became a Decision You Can't Avoid

For most of Copilot's history, the model underneath was Microsoft's decision. That changed in September 2025, when Microsoft expanded model choice in Microsoft 365 Copilot and added Anthropic to Copilot Studio. Anthropic became a Microsoft subprocessor in January 2026, and in July 2026 Microsoft added OpenAI-operated models alongside the Azure OpenAI models it runs itself.

Each change is a genuine capability gain, because different models have different strengths. But the moment a platform gives makers a dropdown across providers with different data-processing terms, the organization acquires a new decision surface. That surface touches residency, compliance, and cost at the same time.

Microsoft is candid about the limits of what it can decide for you. Its Copilot Studio announcement says no single model fits every agent and that the right choice depends on your use case. Microsoft supplies the controls and the defaults, but it cannot supply your per-workload policy, and that policy is the heart of Copilot model governance.

The Three Tiers of Model Data Terms Every Leader Should Know

The most consequential fact about multi-model governance on the Microsoft stack is that terms follow who operates the model, not whose name is on it. "OpenAI" and "Claude" are not single categories. Microsoft's own classification has three tiers: models it hosts and operates, AI subprocessors, and AI independent processors.

Three tiers of Copilot model data terms, compared

Tier 1: Microsoft-operated models (such as Azure OpenAI)

Legal framework: Microsoft Product Terms and Data Protection Addendum (DPA), plus enterprise safeguards.
Who processes data: Microsoft. Models are hosted on Azure and data does not leave Microsoft.
Data retention: Governed by Microsoft's enterprise terms.
EU Data Boundary: Already processing data within the boundary.
Default state: On, and unaffected by the OpenAI subprocessor setting.
Governance stance: Baseline tier; govern by workload.

Tier 2: AI subprocessors (Anthropic and OpenAI-operated models)

Legal framework: Microsoft Product Terms and DPA, plus Enterprise Data Protection.
Who processes data: The third-party provider, on Microsoft's behalf and under Microsoft oversight.
Data retention: Covered by Microsoft's DPA and Enterprise Data Protection; review provider-specific exclusions.
EU Data Boundary: Claude is excluded today and moves in for the EU and EFTA by the end of 2026. OpenAI-operated models are included, with documented exceptions.
In-country processing: Both are currently excluded from in-country processing commitments.
Default state: Claude is on for most commercial tenants and off in the EU, EFTA, and UK. OpenAI-operated models are on for eligible commercial customers.
Governance stance: Allow after a residency and compliance check.

Tier 3: AI independent processors ("Anthropic models with Data Retention")

Legal framework: Anthropic's Commercial Terms and DPA, outside your Microsoft Customer Agreement.
Who processes data: Anthropic, as an independent processor.
Data retention: Anthropic stores most inputs and outputs for up to 30 days. Flagged content can be kept for up to two years, and classification scores for up to seven.
EU Data Boundary: Outside Microsoft's commitments.
Default state: Off in every region. An admin must opt in and choose which users get access.
Governance stance: Block by default; allow only by documented exception.

The practical reading is straightforward. Tiers 1 and 2 keep your content under Microsoft's enterprise commitments, although their residency positions differ. Tier 3 is different in kind: Microsoft's documentation says this data is stored by Anthropic and is not subject to your Microsoft Customer Agreement.

A model's name alone will not tell you its tier. Microsoft notes that some Fable-class models run under the subprocessor tier for eligible organizations, while others arrive as Anthropic models with Data Retention. Mistral and xAI bring their own arrangements too, and Microsoft tells admins to review provider-specific guidance before enabling them.

A Per-Workload Framework for Choosing Which AI Model to Use in Copilot

"It depends" is an unsatisfying answer because most organizations never turn it into a repeatable rule. The fix is to stop choosing models per request and start choosing them per workload archetype. A small number of patterns cover most enterprise use, and each has a defensible default once you weigh data sensitivity, residency, retention, latency, and cost.

The goal is not to pick a single best model. It is to define which models are pre-approved for which kinds of work, so makers operate inside guardrails instead of guessing. Copilot Studio's model tags are a useful first filter: General models are lowest on latency and cost, Deep models are highest, and Auto models vary by turn.

Model selection by workload archetype

Conversational FAQ and employee self-service

Typical data sensitivity: Low to moderate; grounded in published internal knowledge.
Residency and retention priority: Moderate; keep within Microsoft enterprise terms.
Latency priority: High; users expect fast, conversational responses.
Cost priority: High; volume makes token cost the dominant variable.
Default recommendation: The default model or another fast General model under enterprise terms.

Compliance, policy, and contract interpretation

Typical data sensitivity: High; touches regulated or confidential material.
Residency and retention priority: Very high; must stay inside documented data-boundary and retention commitments.
Latency priority: Low; accuracy matters more than speed.
Cost priority: Moderate; lower volume tolerates a more capable model.
Default recommendation: A Tier 1 or Tier 2 model chosen for reasoning quality, never a data-retention variant. Check certifications first, because Microsoft says PCI DSS coverage does not apply when Anthropic or xAI models in Copilot Studio handle cardholder data, and those models are not FedRAMP authorized.

Deep reasoning and research

Typical data sensitivity: Variable; depends on the sources fed to the task.
Residency and retention priority: High when sources are sensitive.
Latency priority: Low; multi-step work is expected to take longer.
Cost priority: Moderate to high; reasoning-heavy tasks consume more tokens per run.
Default recommendation: The strongest reasoning model available in Tier 1 or Tier 2, pinned rather than left on the default.

High-volume production agents

Typical data sensitivity: Variable; often reaches systems of record.
Residency and retention priority: High; agents acting on real data need tight terms.
Latency priority: High; throughput and responsiveness drive the experience.
Cost priority: Very high; at volume, model choice is a major cost lever.
Default recommendation: Pin a specific, generally available model in Tier 1 or Tier 2 and treat any change as a governed migration.

Pinning matters for more than cost. Copilot Studio's default model is periodically upgraded, so an agent left on the default can shift behavior without a release event on your side. We cover that discipline in why you must retest Copilot Studio agents after a model update.

Model choice stopped being a maker preference the moment two providers with different legal terms showed up in the same dropdown.

Where the Controls Actually Live on the Microsoft Stack

Copilot model governance only becomes real when it is enforced in the admin surfaces your team already uses. The primary control is the AI providers operating as Microsoft subprocessors setting in the Microsoft 365 admin center. An AI Administrator or Global Administrator reaches it through Copilot, Settings, and View all.

Scoping is what separates a policy from a toggle. You can assign access to specific users or Microsoft Entra security groups, so a research team gets Claude while the general population does not. Those assignments apply at the provider level, so the admin center can approve Anthropic but not one specific Claude model, and your approved-model list still needs policy and review behind it.

Copilot Studio adds a second gate. Enabling a provider in Microsoft 365 does not automatically make its models available in Power Platform, so a Power Platform admin must also allow them per environment or through environment group rules. A separate setting controls preview and experimental models, which Microsoft says are not for production, so model availability can sit alongside your Power Platform DLP and environment strategy.

Two behaviors are worth committing to memory:

Disabling a provider has side effects. Copilot Studio agents fall back to the default model when a selected model is turned off. But Word, Excel, and PowerPoint Agents use Anthropic exclusively and become unavailable, and Microsoft warns that other features can stop working too.
Defaults vary by region and cloud. Claude is on by default in most commercial tenants and off in the EU, EFTA, and UK, where Microsoft also added a separate Copilot in Microsoft 365 apps with Anthropic models setting. Non-federal GCC customers have their own setting, while federal GCC, GCC High, DoD, and other sovereign clouds have no access.

If you operate across regions, assume your starting posture is inconsistent until you have verified it.

The EU Data Boundary Change: A Commitment, Not a Live State

It is worth being precise about what the November 5, 2026 announcement changes. Claude models are coming into the EU Data Boundary for EU and EFTA customers by the end of 2026. Until then, Microsoft's documentation still lists them as excluded, so your data protection impact assessments should reflect today's state, not the one promised for later.

A few specifics matter for planning:

Existing users: No action is required. Processing moves into the boundary automatically once available.
New users: The setting stays disabled by default in the EU and EFTA, so access remains a deliberate choice.
United Kingdom: The announcement covers the EU and EFTA only, which matters for UK-regulated workloads.
Copilot Studio: The announcement does not name Copilot Studio, and Microsoft's Power Platform documentation still lists Anthropic models there as excluded. Confirm scope before you rely on the change for agents.
In-country processing: The announcement addresses the EU Data Boundary, not in-country processing commitments, which Microsoft still documents as excluded.
Cross-geo tags: Copilot Studio's availability table tags Claude models as cross-geo in Europe, meaning data might be processed outside your region.

Microsoft says it will share more details closer to availability, so treat this section of your standard as provisional.

This is governance of model selection, which is related to but distinct from your regulatory obligations. If your question is what you must do as a deployer, that is a different body of work, covered in our EU AI Act deployer's guide for Microsoft Copilot and AI agents. You need both, and they should reference each other.

Model-Choice Sprawl Is the Next Shadow-AI Problem

Anyone who lived through shadow IT should recognize this pattern. When makers can select a model from a dropdown, some will choose based on which one produced the better demo, not which one carries acceptable data terms. Multiply that across hundreds of agents and you have model-choice sprawl: a tenant where no one can say which workloads run on which terms.

It is a close cousin of shadow AI in Microsoft 365, and the answer is a lightweight operating model rather than a heavyweight committee. Four elements do most of the work:

A single owner. Name one owner for model policy, typically within the AI center of excellence or platform governance function, who maintains the approved-model list.
Default-deny for data retention. Keep Tier 3 models off so they can never be selected without review.
A simple exception process. Give makers with a legitimate need a way to request access with a business justification, rather than routing around the policy.
A periodic review. The best model for a task changes as providers ship, and Microsoft says not every model change gets a dedicated announcement.

Treat Model Cost as a Design Constraint

Model choice is also a cost decision. In The State of AI in 2026, published in August 2026, McKinsey found that about one in five respondents say AI operating costs, including tokens, have constrained their organization's AI use. McKinsey senior partner Lieven Van der Veken adds that the organizations moving fastest treat operating costs as a design constraint.

At low volume, the price difference between models is immaterial and you should optimize for quality. At high volume, model choice becomes a major lever on your Copilot run-rate, and a reasoning-heavy model applied to a simple FAQ is money spent for no added value.

The per-workload framework above is as much a cost-control instrument as a compliance one. It keeps expensive models away from work a cheaper model handles equally well. For the billing mechanics, see our guide to what AI agents actually cost in Microsoft 365.

Putting Copilot Model Governance Into Practice

You do not need a six-month program to get ahead of this. You need a short, deliberate sequence that turns an open decision surface into a governed one.

Inventory current model usage. Identify which agents and experiences use non-default models today, and in which regions, so you know your actual starting posture.
Map each model to a tier. Confirm who operates it and which terms apply, because the brand name alone will not tell you.
Set a default-approved model per workload archetype. Use the framework above to publish a short, opinionated standard rather than leaving every choice open.
Block data-retention models by default. Keep the "Anthropic models with Data Retention" tier off, and allow it only by documented exception.
Scope access with Entra groups. Grant non-default providers to the teams that need them rather than enabling them tenant-wide.
Assign a named owner. Give one person or function accountability for the approved-model list and the exception process.
Schedule a review. Revisit the standard on a fixed cadence, because model capabilities and terms change.

This is unglamorous work, and it determines whether Copilot compounds in value or accumulates risk. At BabyBots, we build governance into Microsoft-stack programs from day one, because model choice is far easier to set early than to claw back later. For the wider agent controls around it, see how to govern AI agents in Copilot Studio.

Frequently Asked Questions

Is Claude in Microsoft Copilot inside the EU Data Boundary today?

Not yet. Microsoft announced on November 5, 2026 that Claude models are coming into the EU Data Boundary for EU and EFTA customers by the end of 2026, and its documentation still lists them as excluded today. The setting stays disabled by default in the EU and EFTA, and the announcement does not cover the United Kingdom, so base any current assessment on today's state.

What is the difference between standard Anthropic models and Anthropic models with Data Retention?

Standard Anthropic models run with Anthropic as a Microsoft subprocessor, covered by Microsoft's Product Terms, DPA, and Enterprise Data Protection. "Anthropic models with Data Retention" run with Anthropic as an independent processor under its own terms, outside your Microsoft Customer Agreement. Anthropic stores most inputs and outputs for up to 30 days and flagged content for up to two years, so most enterprises should leave this tier off by default.

Does model choice change our Copilot data-training exposure?

Microsoft says customer data used with Claude models in Copilot isn't used to train generative AI foundation models, and its documentation says Anthropic doesn't use data retained under the Data Retention tier for training without your express permission. The exposure that changes with model choice is mainly residency and retention. For the wider picture, see whether Microsoft 365 Copilot is safe with your company data.

Who should own model policy in our organization?

A single, named owner, usually within the AI center of excellence or platform governance function, should maintain the approved-model list and run the exception process. Spreading this across every maker is what produces model-choice sprawl. The owner sets the default-approved model per workload, keeps the data-retention tier blocked by default, and schedules periodic reviews.

Does disabling Anthropic break anything?

It can. Copilot Studio agents configured with a Claude model fall back to the default model, but Word, Excel, and PowerPoint Agents use Anthropic exclusively and become unavailable, even for paid Copilot users. Microsoft warns that other features can also become inaccessible, so check which experiences depend on Anthropic before you turn it off.

Does turning off OpenAI as a subprocessor turn off OpenAI models in Copilot?

No. That setting only controls OpenAI models operated by OpenAI, so models Microsoft operates through Azure OpenAI stay available regardless. Features or models that depend on OpenAI-operated models can become inaccessible, so review them before you change the setting.

The Strategic Implication

Model choice will keep expanding. Mistral and xAI already sit beside OpenAI and Anthropic in the Power Platform external model settings, and each addition widens the decision surface your makers face.

The organizations that win will not be the ones that enabled every model fastest. They will be the ones that decided, early and in writing, which model is allowed for which workload, under which terms, and who owns the call when that changes. Copilot model governance is a standing capability, and building it now costs far less than untangling model-choice sprawl later.