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 version, which data may go in, which connections are on, who reviews a new use case, what you do about the AI tools in use alongside 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. Outside Outlook it works with the web and with whatever the user adds. Inside Outlook it can use email, calendar, meetings, chats and a bounded set of OneDrive and SharePoint files, even without a licence (Microsoft Learn, Microsoft Copilot Chat Privacy and Protections, checked 25 October 2026). The paid Microsoft 365 Copilot reaches everything the user has access to through Microsoft Graph: email, calendar, Teams, SharePoint, OneDrive. Our article on Copilot Chat without a licence sets out exactly what the free version sees.
The facts for each version are set 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 versions are covered by what 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 version, 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 also falls into two parts. The first 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 (DPA), the answer is often yes, with conditions, and those conditions have to be written down somewhere.
The second is what Copilot retrieves on its own. The paid version searches everything the user can open, using that user's permissions, and summarises it. That makes years of oversharing in SharePoint findable with 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 saves a lot of questions later.
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 is checked by the privacy officer and information security, using a standard questionnaire. A new use of an existing licence is often checked by nobody at all, 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 has required organisations to work on the AI literacy of people who work with AI systems. What that involves is for the organisation to decide. Deciding who reviews a new use case, and where an employee can take that question, is a practical part of it, and one you can demonstrate.
Which other AI tools are used alongside 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 their 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. Besides Copilot, it found Perplexity, ChatGPT and three specialist tools 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 |
|---|---|---|
| Version and users | Who works with Copilot Chat, who with the paid version, what applies to the consumer version | A status per version, with the reason |
| Data in the prompt | Which categories may go in, and under what conditions | 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 review procedure, including for "we already have that" |
| Other tools | What status the AI tools alongside Copilot have | A register with four statuses |
| Measurement | How you see whether people use the preferred tool, without tracking them | Counts per tool, no names |
How do you see whether it is followed, without tracking people?
The last decision is about measuring, and it involves a line you draw in advance. You want to know whether the share of AI use through allowed tools 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 over 1,000 AI tools to the use observed in the organisation: only the tool's domain, at most once per day per device, without a user ID or any content. An admin sees which tools have no decision yet and records one. Anyone who then opens a tool with a decision sees it in the browser, with the allowed alternative as the first button. This is what that register looks like:
