An administrator at a housing association has assigned the Copilot licences, cleaned up the SharePoint permissions and turned off flex routing. The management meeting has "have we sorted AI now?" on the agenda, and the honest answer is: the technology, yes. What is still missing is a handful of decisions that no setting takes for you.
Copilot governance is that set of decisions: who may use which variant, which data may go in, which connections are on, who reviews a new use case, what you do about the AI tools in use next to it, and how you see whether any of this is followed in practice. The technical setup is one part of it, and usually the part that gets finished first.
Which Copilot do we actually mean?
Three services carry the name Copilot, and they differ on exactly the point that matters for governance. The consumer version on copilot.microsoft.com, without a work account, runs under consumer terms and has no enterprise data protection. Microsoft 365 Copilot Chat, signed in with a work account, does run under that protection, but does not reach into mailboxes and files by itself. The paid Microsoft 365 Copilot does, through Microsoft Graph: email, calendar, Teams, SharePoint, OneDrive.
The facts per variant are worked out in the privacy risks of Copilot. For the decision you take here, this is enough: an employee who opens "Copilot" can open three different things, and only the signed-in variants belong to the policy you paid for. The gap between a personal and a business account is as wide for Copilot as it is for any other AI tool.
So the first decision has two halves. Who gets a licence for the paid variant, and who works with Copilot Chat? And does the consumer version count as not allowed, with a reason attached, or is that left to each user's intuition?
Which data may go in?
Microsoft 365 Copilot does not use prompts, responses or Graph data to train its underlying models. That is a strong commitment, and it answers a different question from the one an organisation has to ask. The commitment is about what Microsoft does with the data once it has arrived. The decision you take yourself is about what may be sent there at all.
That decision splits in two. The first half is the prompt: may an employee paste a client file to summarise it, a job application to assess it, a medical report to turn it into a letter? In a business environment with a data processing agreement the answer is often yes, under conditions, and those conditions have to be written down somewhere.
The second half is what Copilot retrieves on its own. The paid variant searches with the user's permissions through everything that user can open, and summarises it. That makes years of oversharing in SharePoint findable in a single question. The mechanism is the same as for any assistant that searches your own documents: what lands in the answer is decided by the reach of the search, not by the prompt. That is why Microsoft puts permission cleanup at the front of its own deployment guidance.
Which connections are switched on?
A Copilot environment grows. Connectors to external sources, agents built in Copilot Studio, third-party plug-ins, and features that arrive with a monthly update without anyone asking for them. Every connection widens what Copilot can read or do, and therefore what can end up in an answer.
The decision here is not "connections yes or no", but who switches them on and where that is recorded. In many organisations the answer to the first is "whichever admin happened to have the rights", and to the second "nowhere". A list of active connections, with the source each one opens up and who signed off on it, is a small document that prevents a lot of questions.
Who reviews a new use case?
A department wants to build an agent that pre-processes purchase invoices. A team lead wants Copilot to summarise Teams meetings, including calls with external parties. HR wants job applications summarised. Those are three uses of the same licence, with three very different consequences for personal data.
Who says yes or no to that? A new vendor goes past the privacy officer and information security, with a standard questionnaire. A new use of an existing licence often goes past nobody, because "we already assessed Copilot". That is where governance quietly stops: the assessment covered the service, not the use.
Since February 2025 the AI Act asks organisations to work on the AI literacy of people who work with AI systems. What that involves is for the organisation to decide. An agreement on who reviews a new use case, and where an employee can take that question, is a concrete and demonstrable part of it.
Which other AI tools are used next to it?
Buying Copilot rarely means all AI use runs through Copilot. People use ChatGPT for text, Perplexity for research with sources, Gamma or Canva for presentations, and specialist tools nobody had on the radar. Why they do that is a question of its own; for governance what counts is that it happens, and that a Copilot policy says nothing about it.
A municipality that had allowed Copilot commissioned an inventory. Next to Copilot, Perplexity, ChatGPT and three specialist tools turned out to be in use, two of which were not in the AI register. Nobody had broken policy, because no policy existed for those two. The inventory was already incomplete on the day it was delivered, because another tool had appeared that same week.
The decision here is not which tools to forbid, but that every tool in use gets a status: allowed, limited use, no decision yet, or not allowed. Copilot then becomes one row in that register, with an explicit status, and the other tools sit below it with theirs. Even "no decision yet" is then visible rather than silent.
The decisions in one table
| Decision | The question you answer | What you record |
|---|---|---|
| Variant and users | Who works with Copilot Chat, who with the paid variant, what applies to the consumer version | A status per variant, with the reason |
| Data in the prompt | Which categories may go in, and under which condition | One short line per category |
| Reach of the search | Were permissions cleaned up before licences were assigned | A permissions report, with a date |
| Connections | Which connectors, agents and plug-ins are on, and who signed off | A list with an owner per connection |
| New use cases | Who reviews a new use of an existing licence | A route, including for "we already have that" |
| Other tools | What status the AI tools next to Copilot have | A register with four statuses |
| Measurement | How you see whether the preferred route is followed, without tracking people | Counts per tool, no names |
How do you see whether it is followed, without tracking people?
The last decision is about measuring, and it contains a line you draw in advance. You want to know whether the share of AI use through the allowed route is growing, which tools are used without a decision, and whether a tool that is not allowed is still being opened. You do not want to know who did that, and certainly not what that person typed.
Those two wishes can be reconciled, provided the measurement is designed at organisation level rather than anonymised afterwards. BeeSensible links a catalogue of 865 AI tools to the use observed in the organisation: only the tool's domain, at most once per day per device, with no user id and no content. An admin sees which tools have no decision yet and records that decision; whoever then opens a tool that has been decided on sees that decision in the browser, with the allowed alternative as the first button. This is what that register looks like:
