The data protection officer of a school board with nine schools receives an email from the vendor of the pupil tracking system: from the new school year it includes 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-material tool. The pupil tracking system is not in it, because it was not an AI tool when the register was made.
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 weigh 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 it too. And a board with several schools records per row at which school the tool is used, because otherwise a decision holds at one location and not at another.
Which AI runs at a school?
Three groups, and most registers know only the first.
The general tools: Copilot through the school account, ChatGPT, Gemini, Claude, a translation tool. These are in almost every register, though the account type is often missing, and that is exactly the field that matters.
The education tools: tools for lesson material, test questions, differentiation and feedback, such as MagicSchool and SchoolAI. They usually start on a free account of one enthusiastic teacher and spread through the department, not through IT.
The AI features inside existing learning tools: the pupil tracking system that drafts report comments, the adaptive practice software that sets a level per pupil, the assessment environment that marks open 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 that agreement then needs to say is in do 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 counts 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 covenant |
| Purpose | What the application is used for, in one sentence | Feedback on an essay is not the same as summarising a care note |
| School and owner | At which school, and which role manages the row | With several schools a decision otherwise does not hold 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, care and home situations weighs more |
| 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 note. It is not a tick box. A tool that generates lesson material 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 returns 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 gets most often: may pupil data go in here? The answer depends on the agreement. Dutch schools sign processing agreements under the model of the education privacy covenant; a tool with such an agreement can process pupil data within what was agreed, 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.
In an appendix, nobody looks it up. As a dated field in the register, the owner sees at review time whether the agreement still covers what the tool now does. The record of processing activities under Article 30 GDPR stays a separate document; the AI register points to it for every application that processes personal data, and the other way round.
How do you keep it across several schools?
One register, one owner for the whole, and per row a school and a role. That is the layout that lasts longest at boards. The data protection officer owns the register; decisions on general tools are taken by the board for all schools at once; the owner of a row sits at the school where the tool is used.
What goes wrong is predictable. The board from the opening decides that Copilot through the school account is allowed and ChatGPT only without pupil data. A survey across the nine schools, three months later, adds seven tools: two for lesson material, a transcription tool for parent meetings, a presentation tool, and three AI features inside learning tools the schools already had. Four of the seven appear nowhere. At one school the head has already allowed the transcription tool; at another nobody knows it exists.
That is not an incident. It shows that a survey is a snapshot of one moment, and that nine schools have nine moments. Why surveying more often does not fix that is in keeping an AI register current.
How does observed use feed the register?
The register needs a second source next to the survey: which AI tools are actually opened at the schools. Not who, not what is typed, only which tools. The difference between that list and the register is the owner's backlog: tools that need a row, at no decision yet, with the date.
BeeSensible links a catalogue of 865 AI tools, each with vendor, country, certifications, training policy, whether a data processing agreement is available and a risk score across six dimensions, to the use observed in the organisation. The extension reports only the domain of an opened AI tool, at most once per day per device, without a user id and without content. An admin sees which tools have no decision yet and records that decision; the board decides, not the product. More on how that works is on the page about AI tools.
