How Should Schools Handle Student Data in Generative AI Tools?
Decide when to exclude student data, transform an AI task or use a specifically approved protected workflow in your school.
In this article7 sections
- Start with the information movement, not the tool name
- Choose between exclude, transform and protected workflow
- Removing a name may not remove identifiability
- Redesign the task before moving the data
- Test the choice against familiar school tasks
- Use a protected workflow only when the task genuinely needs linked data
- Decide before you upload
A member of staff is drafting a message to a parent about a pupil’s behaviour. The notes are in the school’s system, and they want help making the message calm and clear. Pasting those notes into a generative AI service can feel like the quickest option.
Stop before you paste. The writing task is not the same as the student record. Ask AI for the structure of a sensitive parent message without sharing the pupil’s name, class, behaviour history or family context. Add the facts later, inside the school’s approved communication system. The message still gets written, but the record stays where it belongs.
This guide offers a practical starting point, not legal advice. The law, policy and approval route will depend on the school’s jurisdiction and setting.
Start with the information movement, not the tool name
Student data can enter an AI workflow in more ways than a name in a prompt. It may be in copied text, a document, spreadsheet, image, recording, browser assistant, connected drive or saved conversation. The service may also process technical details such as location, IP address, browser or system information.
The Department for Education’s guidance for schools in England warns that some generative AI tools collect and store more than the text entered by a user. It advises schools to check with their data protection officer or IT lead about what is acceptable in their setting.
So the first question is not, “Is this an education tool?” or “Do we have a paid account?” Neither tells you whether this task, information, connection or configuration is suitable.
Look at the record first. What is the staff member trying to do? Do they need the record itself to enter another service? Often, they only need a structure, method or way of phrasing something. The student-specific facts can stay in the school system.
Choose between exclude, transform and protected workflow
Before anything moves, choose one of three starting points. TopSchool has drawn these options from the practical issues in the cited guidance. They are not an official DfE, ICO or UNICEF framework.
| Option | When it fits | Benefit | Trade-off and caution |
|---|---|---|---|
| Exclude | Use this when the task does not need the record or the information is too sensitive for the proposed service. Pause if it involves safeguarding, health, SEND, behaviour case notes, credentials or precise location. | The record stays in the existing school system. | You may lose the shortcut or need a non-AI process. Treat this as a cautious starting point, not a universal legal list. |
| Transform | Use a generic instruction, synthetic example, broad pattern or local template when it can do the job. | You keep much of the practical value without moving the original record. | A weak transformation may still identify a student. It may also remove detail the task truly needs. |
| Protected workflow | Use student-linked information only when the task truly needs it and the exact use, information scope and technical route are specifically approved. | Necessary detail stays available within agreed controls. | This needs the strongest assurance. A familiar product or paid account is not the same as approval. |
If the task may need a protected workflow, follow the school’s recorded approval route. Our guide to AI governance roles and decision rights explains where that wider decision belongs.
Removing a name may not remove identifiability
Taking out a student’s name helps, but it does not prove the remaining material is anonymous. A rare medical need, exact date, distinctive family situation, small group, photograph, voice, filename or recognisable piece of work may still identify the student to someone with local knowledge.
In the UK, the Information Commissioner’s Office distinguishes pseudonymisation from anonymisation. Pseudonymised data remains personal data when it can be connected to a person using additional information. Replacing a name with a number, initials or another label can reduce risk, but it does not necessarily take the information outside data protection law.
Context matters too. “One Year 8 pupil” may sound broad until the incident date, subject, support need and family circumstance make only one person possible. The same transformed record may be difficult for an external party to identify but obvious inside the school community.
A generic redaction checklist cannot settle this for you. Look at what remains, who might recognise the student and what other information they could reasonably use. Only then can the school judge whether the material is suitable for the service.
Redesign the task before moving the data
Often, the best first step is to redesign the task. Ask what help the staff member needs, then separate that need from the record. This reflects the purpose-specific approach in the ICO’s UK guidance on data minimisation in AI, which says organisations should consider whether they can achieve the same outcome with less personal data. That ICO guidance is currently under review following changes in UK law, so schools should check the latest local position before relying on it.
TopSchool developed the six patterns below as an editorial synthesis. They can reduce or avoid information movement, but none guarantees anonymity or approval.
| Pattern | What changes | School example | Failure to watch for |
|---|---|---|---|
| Identity last | Keep student facts out of the AI step and add them afterwards in the approved school system. | Ask for the structure of a parent message, then complete the factual details locally. | Dates, behaviour details or local context may identify the pupil even without a name. |
| Synthetic substitute | Use an invented case that keeps only the type of problem you need to test. | Test instructions against a fictional learner profile. | A lightly altered real case may still be identifiable. |
| Aggregate | Use broad totals, ranges or patterns instead of student-level rows. | Explore ways to present year-group attendance bands. | Small groups and rare combinations may reveal individuals. |
| Generalise the task | Ask for a method, template, question set or sentence bank rather than an answer based on a record. | Request a report-comment framework instead of uploading completed reports. | A follow-up prompt can drift back towards real examples. |
| Local redaction | Remove unnecessary material and check the whole file before uploading it. | Prepare a document used only to test layout or readability. | Names can remain in headers, comments, metadata, images or filenames. |
| Keep it inside | Use the existing approved school system or a non-AI process. | Review a safeguarding chronology without exporting it. | Pressure to save time can lead to an unrecorded workaround. |
The DfE gives an England-specific example of the identity-last pattern. An administrator asks for help drafting a parent email without including personal data, then adds the pupil’s details afterwards. This is a useful pattern, but it does not mean every task becomes safe when identifiers are added later.
Test the choice against familiar school tasks
There is no single right route for every task. The answer depends on the information involved and how easily someone could recognise the student. These examples show where to start. They do not approve any particular use.
| Task | Routine starting route | What changes the decision | Caution |
|---|---|---|---|
| Parent message from behaviour notes | Transform. Request a generic structure, then complete the facts locally. | A specifically approved communication workflow may permit defined information. | Behaviour details and dates can identify a pupil without a name. |
| Translation of individual report comments | Transform. Translate generic sentence banks without student records. | Real comments require an approved route that covers their content and configuration. | Attainment, behaviour, SEND needs and personal situations may identify the student. |
| Safeguarding, health or SEND material | Exclude from an unknown or public service. | Only a defined protected workflow with the required specialist confirmation changes the route. | Redaction is not a shortcut around the sensitivity of the record. |
| Themes across student work | Transform. Develop the analysis method using synthetic material first. | Use of real work requires a separate decision about the material and route. | Work may contain personal experiences, handwriting, voices, images, metadata and intellectual property. |
| Illustration from a pupil photograph | Transform. Use a generic description or synthetic reference. | An approved use would need to cover the image, purpose and technical route. | Cropping a face or changing a filename may not remove identifiability. |
The DfE’s position on generative AI in education applies to England and treats data privacy and intellectual property as relevant considerations. Schools elsewhere can use those principles as a reference, but should follow the law, policy and specialist advice that apply locally.
Use a protected workflow only when the task genuinely needs linked data
A protected workflow is not blanket permission to use student data with a familiar product. It is approval for one use case, one information scope and one technical route.
Before using it, the school should be able to explain the purpose and why exclusion or transformation would not work. It should know what information enters the workflow, which systems and connections are involved, who can access it and which local owners have confirmed the conditions. Depending on the setting, that may include data protection, IT and safeguarding advice.
The DfE guidance for England tells schools to seek advice from their data protection officer or IT lead and to understand how an approved tool uses personal data. UNICEF’s Guidance on AI and Children adds a global child-centred privacy perspective, but it is a policy framework rather than national law or a school operating procedure.
Approval does not automatically carry over to the next use. A different connector, model, feature, retention setting, user group or type of information can change the decision. Our AI vendor evaluation guide covers the separate job of checking supplier and configuration evidence.
Decide before you upload
Before a staff member uses AI with student-related information, ask four questions:
- Does the task need the source record? Start with the job to be done, not the material you happen to have.
- Can generic, synthetic or aggregate material meet the purpose? If so, transform the task before using AI.
- Could the remaining details, files or local context still identify a student? Look beyond names and obvious identifiers.
- If linked data is genuinely required, has the school approved this exact use and route? Pause and seek the relevant local decision if the answer is unclear.
Start with one real staff task. Redesign it before any information leaves the school system. Put the lasting rule in the school’s AI acceptable use policy, then use teacher AI literacy guidance to help staff recognise when to stop and ask.
