The data protection officer at a school board with nine schools gets an email from the vendor of the pupil tracking system: from the new school year, it will include an AI assistant that drafts report comments. The board's AI register is a spreadsheet with four rows: Copilot, ChatGPT, a translation tool and a lesson materials tool. The pupil tracking system is not on it, because it was not an AI tool when the register was drawn up.
An AI register for an education organisation has the same fields as any AI register: vendor, purpose, owner, data, risk assessment, decision, date and review. Three things matter more at a school. The processing agreement is a field, not an appendix, because without an agreement no pupil data goes in. AI features inside learning tools the school already had belong in the register too. And a board with several schools records, for each row, which school uses the tool; otherwise a decision applies at one site and not at another.
What AI is in use at a school?
Three groups, and most registers only cover the first.
General tools: Copilot on the school account, ChatGPT, Gemini, Claude, a translation tool. These appear in almost every register, though the account type is often missing, and that is precisely the field that matters.
Education tools: tools for lesson materials, test questions, differentiation and feedback, such as MagicSchool and SchoolAI. They usually start on one enthusiastic teacher's free account and spread through the department, not through IT.
AI features inside existing learning tools: the pupil tracking system that drafts report comments, the adaptive practice software that sets a level for each pupil, the assessment platform that marks open-ended questions. These are not new vendors. A processing agreement is already in place, and yet something changes: pupil data flows to an AI feature that did not exist when the agreement was signed. What the agreement then needs to cover is explained in our article on whether you need a data processing agreement for an AI tool.
The third group is the one the register misses, because nobody reports it as AI. To the teacher it is simply the pupil tracking system.
Which fields does a school need?
| Field | What you record | Why it matters at a school |
|---|---|---|
| Vendor and account | Name, country, processing location, whether input is used for training; school account or personal account | A free account has no agreement and falls outside the Privacyconvenant, the education sector's privacy agreement with suppliers |
| Purpose | What the application is used for, in one sentence | Feedback on an essay is not the same as summarising a pupil support note |
| School and owner | At which school, and which role manages the row | Otherwise, with several schools, a decision does not apply everywhere |
| Processing agreement | Yes or no, under which model, with a date | No agreement, no pupil data |
| Pupil data | Which categories go in, and which explicitly do not | Data about minors, their support needs and home situations carries extra weight |
| Decision | Allowed, limited use, no decision yet, not allowed, with the condition | This is what a teacher has to be able to find |
| Review | When, and which event triggers an earlier one | A learning tool gaining an AI feature is such an event |
The pupil data field deserves a word of explanation. It is not a tick box. A tool that generates lesson materials processes no pupil data until a teacher pastes an essay into it. So the field says two things: which data the application needs, and which data the decision keeps out. The second is the sentence that reappears in the policy and that the teacher gets to see.
Why is the processing agreement a field and not an appendix?
Because the register has to answer the question a school hears most often: can pupil data go in here? The answer depends on the agreement. Dutch schools sign processing agreements based on the model in the Privacyconvenant; a tool with such an agreement can process pupil data within what was agreed, and a tool without one cannot. Article 28 of the GDPR requires that agreement as soon as a vendor processes personal data on the school's behalf, and for a free chatbot that question is answered quickly: there is no agreement, so no pupil data.
Nobody looks it up in an appendix. As a dated field in the register, it shows the owner at review time whether the agreement still covers what the tool now does. The record of processing activities under Article 30 GDPR remains a separate document; the AI register refers to it for every application that processes personal data, and vice versa.
How do you maintain it across several schools?
One register, one overall owner and, for each row, a school and a role. That is the set-up that lasts longest at school boards. The data protection officer owns the register; the board decides on general tools for all schools at once; the owner of a row is based at the school where the tool is used.
What goes wrong is predictable. The board in the opening example decides that Copilot on the school account is allowed, and ChatGPT only without pupil data. Three months later, a survey across the nine schools adds seven tools: two for lesson materials, a transcription tool for parents' meetings, a presentation tool and three AI features inside learning tools the schools already had. Four of the seven are not recorded anywhere. At one school the head teacher has already allowed the transcription tool; at another, nobody knows it exists.
That is not an incident. It shows that a survey captures a single moment, and that nine schools have nine different moments. Why surveying more often does not fix that is explained in our article on keeping an AI register current.
How does observed use feed the register?
The register needs a second source alongside the survey: which AI tools are actually opened at the schools. Not who opened them, not what was typed, only which tools. The gap between that list and the register is the owner's backlog: tools that need a row, set to "No decision yet", with the date.
BeeSensible matches the use observed in the organisation against a catalogue of over 1,000 AI tools, each with its vendor, country, certifications, training policy, whether a data processing agreement is available and a risk score across six dimensions. The extension reports only the domain of an AI tool that is opened, at most once a day per device, with no user ID and no content. An admin sees which tools have no decision yet and records one; the board decides, not the product. How that works is explained on the page about the AI register.
