A board with six schools assigns Copilot licences to its staff after the summer. In the first week, a form tutor asks Copilot what is known about a pupil, to prepare for a meeting with the parents. The answer is tidy, with citations, and includes a passage from a care meeting report that sits in a team site open to all staff.
Nothing was hacked and nothing was broken. That is exactly why the licence is the beginning, not the end. Beyond the licence, an education organisation arranges four things: which variant staff use, the permissions on the places where pupil data sits, which data and connections may go in, and what has been decided about the AI tools teachers use next to Copilot. The general version of those decisions is in Microsoft Copilot governance; this piece is about what is different in a school.
Which Copilot do staff get?
Three services are called Copilot. The consumer version on copilot.microsoft.com, without a school account, runs under consumer terms. Microsoft 365 Copilot Chat, signed in with the school account, falls under Microsoft's enterprise data protection but does not reach into mail and files by itself. The paid Microsoft 365 Copilot does, through Microsoft Graph: mail, calendar, Teams, SharePoint, OneDrive. The facts per variant are in the privacy risks of Copilot.
For a school that means two decisions. Who gets the paid variant and who works with Copilot Chat: a special needs coordinator with access to care files is a different user from a teacher preparing lesson material. And what is the status of the consumer version, which a teacher was already using at home on a personal account before the licence existed? Whether pupils get a variant too is a decision of its own, with Microsoft's own terms, and falls outside this piece.
Where do the pupil files really live?
Formally in the pupil tracking system, and that is usually a separate environment Copilot does not search. In practice a second layer sits in Microsoft 365: the care meeting report in a team site, the development plan as a Word file in OneDrive, the grade export as an email attachment, the notes of the pupil review in a channel. That layer grew without anyone labelling it a file.
Copilot does not break permissions. It searches with the user's permissions, and that is the problem: a team site opened to "all staff" in 2022 because something had to be shared quickly was protected by nobody knowing the report was there. An assistant searches by meaning, everywhere at once, and summarises. What changes is not the access but the effort. How that mechanism works is in Copilot and SharePoint, and it is why Microsoft puts cleaning up oversharing first in its own deployment guidance, before assigning licences.
Two questions come on top for a school that matter less in an office. Who may see a care file: the care team, the form tutor, or everyone who teaches the class? And what happens to the files of pupils who have left, in sites that were never archived? Both questions existed already; the assistant makes them urgent.
Which data and connections may go in?
Microsoft 365 Copilot does not use prompts, responses or Graph data to train its models. That says something about what Microsoft does once the data has arrived, not about what may be sent. May a form tutor have a care note summarised for a parent meeting? In an environment with the school account and a data processing agreement the answer is often yes, under conditions, and those conditions need to be written down somewhere.
What already exists is the DPIA that SURF published with SLM Rijk on Microsoft 365 Copilot: in December 2024 with four high risks and the advice not to use the service for the time being, downgraded to amber after Microsoft's changes in September 2025, with two residual concerns. That DPIA describes the service. It does not describe the permission structure of your sites, the connections and agents your administrators switch on, or the tools in use next to it; what the board adds itself is in a DPIA for Microsoft Copilot.
| Decision | The question for a school board | What you record |
|---|---|---|
| Variant and users | Who gets the paid variant, who Copilot Chat, what applies to the consumer version | A status per variant, with the reason |
| Permissions on pupil data | Which team sites and folders with care reports, development plans and grade exports are open to more people than intended | A permissions report with a date, and who cleaned it up |
| Data in the prompt | May a care note, a grade list or a meeting report go in, and under which condition | One line per category |
| Connections and agents | Which connectors and agents are on, and who signed off | A list with an owner per connection |
| Tools next to Copilot | What status ChatGPT, MagicSchool, the extensions and the grading tool have | A register with four statuses |
| Measurement | Do staff follow the preferred route, without you tracking people | Counts per tool, no names |
Which tools run next to it?
Assigning a licence rarely means all AI use runs through Copilot. At the board from the first paragraph, a spring inventory shows that next to Copilot, the free version of ChatGPT, MagicSchool and an extension that summarises lesson videos are in use, plus a grading tool at one school. No decision was ever taken on three of them. Why teachers do that is a question of its own; for the board what counts is that it happens and that the Copilot policy says nothing about it.
The decision is not which tools you ban, but that every tool in use gets a status: allowed, limited use, no decision yet or not allowed. Naming Copilot with the school account as the preferred route is a decision too. BeeSensible links a catalogue of AI tools to the use observed in the organisation: only the domain, at most once per day per device, with no user id. An administrator sees which tools have no decision yet and records that decision; consumer and business variants of the same service are separate rows.
