Bringing AI into the classroom: a guide for schools

The schools that have introduced AI successfully did not start with the tool. They started with three questions: what is our assessment policy now that generated text exists, where does student data go, and what will actually run on our devices?

Answer those first and the tool choice becomes obvious. Skip them and you will be unwinding a rollout in the second term.

Step 1 — Settle the assessment question

Before any tool is deployed, departments need a shared answer to: which assessments assume unaided production, and how do we know they still measure what we think?

The practical resolutions schools land on are usually some mix of moving high-stakes writing in-class, weighting process and drafts alongside the final artefact, and being explicit per-assignment about what help is permitted. A blanket ban is not enforceable and a blanket permission is not defensible.

Step 2 — Do the data-protection work properly

If a tool transmits student work to a third party, you need to know the processor, the retention period, whether the data trains models, the lawful basis, and what you are telling parents. That is a real piece of work and it is the most common place rollouts stall.

On-device tools change the shape of this problem. If inference happens on the school laptop, there is no transfer, no processor to add to the register and no retention clause to negotiate. The review shrinks from weeks to a conversation.

Step 3 — Be honest about the devices

The last one catches people. A cloud tool that works beautifully in a pilot with four teachers can be unusable with a full year group on the same connection.

• What is the actual RAM on the oldest device in the fleet still in service?
• Is the network filtered in a way that will block model downloads or a tool’s API?
• Can IT pre-load software and models onto the device image, or does each student install?
• What is the bandwidth cost of thirty students hitting a cloud API simultaneously in period three?

Step 4 — Train staff on judgement, not features

Feature training ages out in a term. What lasts is teaching staff where these tools are reliable and where they are not: that they fabricate citations confidently, that they are strong at rephrasing and weak at arithmetic-heavy reasoning, and that anything reaching a report needs a human read.

The most effective single training session is usually a live demonstration of a model getting something plausibly and confidently wrong.

Step 5 — Start with teacher workload, not student use

Rolling out to staff first gets you three things: a group of teachers who understand the tool before students ask them about it, immediate visible benefit in differentiation and feedback, and a low-stakes environment to find the failure modes.

Student-facing use lands far better in term two, led by teachers who have already formed judgement about it.

A rollout order that works

1. Agree the assessment position. Department by department, decide which assessments assume unaided production and what changes.
2. Complete the data review. Establish where student work goes. Prefer on-device processing to shorten this dramatically.
3. Pilot with staff. Six to ten teachers, one term, focused on differentiation and feedback rather than lesson plans.
4. Train on limitations. Run the session where the model gets something wrong. Publish an internal one-page guide.
5. Open to students with explicit per-assignment rules. Every assignment states what help is permitted. Ambiguity is what produces integrity cases.
6. Review at the end of term. Ask what actually saved time and what created work. Drop what did not earn its place.