Responsible AI in schools: a practical starting framework

Begin with a task that can be checked

AI is too broad a purchasing objective. Define a task such as suggesting alternative wording for a general letter or producing a first draft of non-personal teaching material. Decide what a good result looks like and who has the knowledge to check it. A tool that creates plausible text quickly may still increase work if every sentence requires correction.

Distinguish staff-facing assistance from pupil-facing use. The people, safeguards and potential effects differ. A school should not treat approval for a teacher to draft a generic resource as permission for pupils to use an unrestricted conversational service.

The DfE's generative AI guidance and product safety standards are useful references for settings in England. They address responsibilities around safety, privacy and the quality of outputs. Other UK settings should also check their own education guidance and policies. This guide proposes a practical evaluation process; it does not certify a tool as safe.

Agree what information may be entered

Start a pilot with material that does not identify pupils, families or staff. Remove more than names: combinations of class, circumstances and events can still identify someone. Keep confidential school information out of unapproved tools.

Ask the data protection lead and IT support to assess any proposed use of personal information before it begins. Establish what the service stores, whether inputs or outputs may be reused, where information is processed and how deletion works. A paid account is not automatically suitable, and an education label is not a substitute for checking the contract and configuration.

Consider intellectual property separately. Teaching resources and pupil work may carry rights that are not resolved by a data protection agreement. Staff need a clear rule about uploading third-party material and about checking the origin and permitted use of generated content.

Keep human judgement attached to the output

Give the reviewer a short, task-specific checklist. For a teaching resource, check factual accuracy, age suitability, curriculum fit, accessibility and assumptions about pupils. For a school letter, check dates, promises, tone and whether it asks families to do something the school can actually support.

Do not allow fluent wording to stand in for evidence. An AI-generated citation or description of a policy needs verification against the actual source. If the reviewer cannot confidently check the subject matter, choose a different task or involve someone who can.

Keep decisions about individual pupils, safeguarding or other high-impact matters within appropriate professional processes. A general-purpose model should not become an unreviewed decision maker because its output appears structured or authoritative.

Assess pupil-facing use separately

If a school considers a pupil-facing tool, review the intended age group, supervision, account arrangements, filtering and monitoring, and how concerns will be reported. Test likely failure cases as well as the ideal demonstration. Consider whether the interaction supports the learning objective or allows pupils to avoid the thinking the task is meant to develop.

Explain the activity and expectations in understandable language. Pupils need to know when AI assistance is permitted, how to identify their own contribution and where to seek help if the tool produces something upsetting or inappropriate. Parent communication should describe the actual use rather than a vague promise of innovation.

Update the filtering and monitoring review when new AI features change what pupils can access. A previously approved application may introduce capabilities that need another assessment.

Run a bounded pilot

Choose a small group, a short period and a named owner. Record the original task, preparation time, checking time and final quality. Count the whole workflow when evaluating workload: a quick draft followed by lengthy verification may not save time.

Collect examples of failure without storing unnecessary personal or confidential information. Ask users what they changed and why. Review whether the output introduced repetition, errors or inaccessible material that would otherwise have been avoided.

Decide in advance what would stop the pilot, such as an unresolved safeguarding concern, unacceptable data handling or no clear benefit. Stopping a trial can be a useful outcome when it prevents a wider commitment to an unsuitable process.

Make approval a maintained decision

Record the approved purpose, configuration, responsible owner and review date. Make it easy for staff to request a new use case rather than quietly extending the original approval. Reassess significant changes to terms, features or data use.

Include training and subscription costs in the school IT budget. A sustainable approach uses evidence from real school tasks, keeps professional accountability visible and gives staff clear boundaries they can apply without interpreting a long policy on every occasion.