Does Microsoft Copilot respect existing document permissions?

It is designed to honour the permissions already set in your tenant, which is a genuine architectural strength over building retrieval yourself. The catch is that it inherits whatever your permissions actually are rather than what you believe them to be. Broad link sharing and over-permissive site access that nobody noticed while people browsed manually become newly discoverable once a system can search across everything at once.

Is Copilot data used to train Microsoft's models?

Enterprise agreements exclude tenant data from training, and that exclusion is one of the main things the commercial tier buys you. The questions worth pressing in procurement are the adjacent ones: what is retained and for how long, where processing occurs, who can access data during an incident, and what survives contract termination.

When is Copilot the right choice over a private LLM?

When your work already lives in Microsoft 365, when the tasks are general knowledge work rather than regulated decisioning, and when contractual data terms satisfy your risk function. In that situation Copilot delivers value in weeks with no infrastructure to operate, and building a private equivalent would be a large expense to reach a similar place.

When does Copilot not fit?

When data is prohibited from leaving your boundary by law, regulation or contract; when the workload must run disconnected; when you need to reproduce a specific output months later for audit and cannot depend on a model version remaining available; or when the material is privileged or trade secret and contract terms do not transfer that risk acceptably.

That is the common outcome in large Microsoft estates. Copilot for general productivity across the majority of staff, a private deployment for the specific regulated or sensitive workloads that cannot use it. What this requires is a written classification rule telling people which system a given piece of work belongs in, otherwise everything drifts to whichever is more convenient.

Private LLM vs Microsoft Copilot: What Each Actually Gives You

In most large organizations running Microsoft 365, Copilot is not one option among several. It is the default assumption, because it is already in the agreement and already in the applications people use.

That makes the useful question narrower than "which is better". It is: which workloads can Copilot carry, and which ones need somewhere else to live?

What Copilot is actually good at

Copilot's real advantage is not the model. It is proximity to your data and to the applications where work already happens.

It sits inside Word, Outlook, Teams and SharePoint, it reaches your tenant's content without a retrieval system you have to build, and it applies the permissions already configured there. For a large class of work, summarising a thread, drafting from an existing document, finding something across a corpus nobody has organised, that combination is difficult to beat by building.

It also arrives quickly. Deployment is mostly licensing, identity and policy rather than infrastructure, so a pilot group can be productive in weeks.

The permissions point worth understanding

Copilot honours the permissions in your tenant, which is architecturally sound and better than most retrieval systems built in-house.

The subtlety is that it honours the permissions you have, not the ones you think you have. Documents shared with broad links, SharePoint sites with inherited access nobody reviewed, folders opened up years ago for a project that ended: none of that mattered much while people navigated manually, because discovery was effectively limited by knowing where to look.

A system that can search everything at once removes that friction. The exposure was always there. Copilot makes it findable.

This is not an argument against Copilot. It is an argument for a permissions review before rollout, and it applies equally to any retrieval system you build yourself.

Where a private LLM is genuinely required

Contract terms cover a great deal. Three things they cannot provide:

The data physically staying inside your boundary. If a law, regulation, accreditation or customer contract prohibits the data leaving, no commercial terms satisfy that. This is the constraint that most often settles the decision.

Control over model versioning. If you need to explain months later why a system produced a particular output, you need that model version to still exist. Hosted providers deprecate on their own schedule. In regulated decisioning this alone frequently forces self-hosting.

Independence from the provider's roadmap. Pricing, packaging, model availability and feature deprecation are all outside your control. For a capability that becomes load-bearing, that is a dependency your risk function will eventually ask about.

The comparison in practice

| | Microsoft Copilot | Private LLM | |---|---|---| | Fits best | General knowledge work inside Microsoft 365 | Regulated, sensitive or disconnected workloads | | Data location | Microsoft infrastructure under contract | Inside your boundary | | Permissions | Inherits your tenant's, for better and worse | Whatever you build, which is a real burden | | Time to value | Weeks | Weeks to months, longer on-premise | | Cost shape | Per seat, predictable | High fixed cost, flat with usage | | Model control | Microsoft's roadmap | Yours | | Operational burden | Minimal | Significant and ongoing | | Works disconnected | No | Yes, if built for it |

How to decide

Run the constraint test before the cost comparison, because a binding constraint makes the cost comparison irrelevant:

Does any law, regulation or accreditation prohibit the data leaving a defined boundary?
Do customer or partner contracts restrict processing to named infrastructure?
Would exposure breach privilege, trade secret protection or a confidentiality undertaking?
Must it work without external connectivity?
Do you need to reproduce a specific output months later for audit?

Any yes points at private deployment for that workload class. All no, and Copilot is likely the faster and cheaper route for that class of work.

Notice the framing: per workload class, not per organization. That is the answer most large Microsoft estates arrive at, and it is usually correct, because it matches control to actual exposure rather than applying the strictest requirement to everything.

The governance requirement this creates

Running both means someone has to know which system a given piece of work belongs in. Without a written, enforced classification rule, everything drifts to whichever tool is closer to hand, which is exactly how shadow AI starts, only this time with sanctioned tools.

Write the rule, make it short, and make sure the sanctioned path for sensitive work is genuinely usable. A rule that sends people somewhere slower and worse will be ignored.

Where to go next

For the underlying decision framework see Private LLM vs ChatGPT Enterprise, and for the definitional groundwork what a private LLM actually is. The permissions issue is covered in depth in permission-aware retrieval.