A school AI tool checklist: accounts, privacy, access and supervision

A school AI tool checklist should help leaders decide whether a proposed use is suitable for a specific group, task and account arrangement. A familiar product name is not enough. The same service may offer different access conditions, settings and features depending on how the school obtains and configures it.

The review needs both educational and operational questions. What will pupils learn? Who supervises the activity? What information enters the service? What happens if a learner sees an unsuitable response or cannot access the interface? Those questions should be answered before a classroom depends on the tool.

This guide gives adult school staff a practical assessment structure. It is not legal advice or a product approval list. Conditions change, and the relevant school, trust, local authority or national arrangements must guide the actual decision.

Start with a defined educational use

Describe the proposed activity in ordinary language. “Use AI in lessons” is too broad to assess. “A teacher displays a prepared response so pupils can compare it with a checked source” has a clear user, information flow and learning purpose.

Identify who operates the tool. Teacher-led display, staff preparation and pupil interaction are different uses. Approval for one should not silently become approval for another. Record the proposed level of independence and whether any output will affect assessment, feedback or a decision about a pupil.

State why the tool is needed. Some learning outcomes can be achieved with prepared examples or existing resources. An account-free activity may be preferable where live access adds little educational value or introduces unresolved conditions. The alternative should be considered as a genuine design option.

Agree who owns the educational judgement. Technical availability does not establish that an activity is appropriate for a particular class. The relevant teachers and leaders need to consider the content, reading demand, curriculum purpose and pupils' needs alongside the technical review.

Record the exact product and account configuration

Write the product name, service edition, account type and proposed features. Include the date of the check and the official documentation used. A general statement that “the school has access” may conceal important differences between staff accounts, pupil accounts and optional connected services.

Check current eligibility and age-related conditions for the actual arrangement. Do not rely on a remembered minimum age or assume every institutional account has the same permissions as a consumer product. Provider rules and administrator controls need a current review by the responsible staff.

For example, Google's education account information for Gemini and age-based service controls are relevant where that ecosystem is proposed. They are references to inspect, not a recommendation that the service is suitable for every school activity.

Record any uncertainty as an unresolved item with an owner. If a supplier's public information is unclear, obtain clarification through the appropriate school route. Do not fill the gap by treating an enthusiastic demonstration or an answer from the tool itself as authoritative evidence of its terms.

Map what information enters and leaves

List the inputs: typed requests, uploaded files, images, account details and any information supplied through connected services. Then list the outputs and where they may be stored or shared. A simple diagram can reveal a connection that is easy to overlook in a classroom demonstration.

Ask whether the activity needs personal information at all. Synthetic examples and prepared source packs can often meet the learning aim. Removing names from a real case is not automatically sufficient if contextual details could still identify a person.

Review the relevant data arrangements with the school's responsible lead. Identify the provider's role, the applicable contract or terms, retention, access and any approved configuration. The DfE school AI data-protection guidance provides context for England; other settings need their applicable framework.

Keep the assessment proportionate but explicit. A teacher displaying a prepared fictional example and a system processing individual pupil records have different information risks. The review should explain the actual use rather than copying a generic approval that does not describe what will happen.

Check supervision and safeguarding arrangements

Identify who supervises the activity and what they can see. A teacher needs a practical way to pause the exercise, respond to a concern and switch to an alternative. A promise that the tool has safety features does not remove the need for the school's own arrangements.

Review how unsuitable or unexpected output would be handled. Prepare a simple staff response consistent with school policy and identify the relevant reporting route. Avoid asking pupils to investigate harmful material or deliberately provoke a live service as part of a general literacy exercise.

Agree boundaries for personal questions. A classroom tool should not be presented as a substitute for a trusted adult or appropriate support. Use fictional scenarios where discussion is useful, and keep any actual disclosure within the school's established safeguarding process.

If an external provider is involved, confirm roles in writing. School staff retain their agreed responsibilities for pupils; the provider delivers within the approved scope. Preparation should identify supervision, visitor arrangements and the handling of concerns, rather than assuming a technology workshop sits outside normal school procedures.

Test access and accessibility with the real setup

Use school-managed devices and the actual network to test the proposed activity. Check filtering, sign-in, file access and any redirects. A service working on a trainer's personal laptop does not establish that it will be available or appropriate on the school network.

Consider keyboard access, screen readers, text size, captions and the reading demand of the interface. The W3C accessibility introduction provides useful background, but the school needs to evaluate the actual task and relevant learner needs.

Check what happens when a pupil cannot use the interface. Provide an equivalent activity that addresses the same learning outcome, such as reviewing a prepared response with a source pack. An alternative should allow meaningful participation rather than simply occupying the pupil while others use the tool.

Document practical limits such as shared devices, session length and support availability. These details affect whether the lesson can run as planned. If the proposed activity requires every pupil to troubleshoot an account, it may not be a sensible use of the available teaching time.

Use an account-free alternative as a planned option

A teacher can display a prepared answer and ask pupils to identify claims, missing information and suitable evidence. This approach can teach useful AI literacy without creating pupil accounts or relying on live generation. It also makes the example stable enough for staff to check in advance.

Prepared materials should be labelled accurately. If an answer was written for teaching rather than produced by a named service, say so in the staff pack. The activity should not imply that a fabricated output is evidence about a particular provider's behaviour.

For a live teacher-led demonstration, use the approved account and synthetic material. Prepare for a response different from the one rehearsed. The learning plan should remain workable if the output is unhelpful, the service is unavailable or the teacher chooses to stop the demonstration.

The guide to checking AI answers in class contains original activity structures that can be adapted to these arrangements. Choosing an account-free method is an educational design decision that should be assessed against the intended learning, alongside other delivery options.

Review output quality for the intended subject

Ask the subject teacher to check representative outputs and the planned source material. Look for factual errors, unsupported claims, inappropriate language and explanations that are too complex or misleadingly simplified. A general demonstration cannot establish quality across every curriculum area.

Define what pupils are expected to do with the answer. Reading it critically is different from using it as an authoritative reference or submitting it as work. The activity should make that distinction clear and align with the school's assessment and academic-integrity arrangements.

Include examples where the available evidence is insufficient. Pupils should be able to recognise that an answer cannot be established from the source, rather than learning that every question has a definite result if the prompt is worded correctly.

Record the limits of the review. A small sample supports a decision about a specific activity, not a blanket judgement that the service is accurate. If a future use involves different subjects, information or levels of independence, it needs another appropriate review.

Prepare an incident and outage route

Agree what staff do if the tool becomes unavailable, a sign-in fails or a response makes the planned activity unsuitable. A prepared fallback allows teaching to continue without weakening controls or improvising with personal accounts. Keep the relevant materials accessible without the live service.

Define how technical and information incidents are reported. Staff should know which details to retain and where to share them securely. Avoid copying sensitive screenshots into informal groups simply because they are convenient for troubleshooting.

Review the consequences of an accidental upload. The response depends on the information and applicable arrangements, so use the school's established incident process. A training handout should point to that route rather than offer a universal deletion step that may not address the actual issue.

Practise the simple fallback before relying on it. A printed worksheet that has never been checked may contain missing instructions or require a link blocked on the school network. Readiness comes from a workable alternative, not merely a sentence saying that one exists.

Use a dated approval record

Keep the review in a concise record with the proposed use, responsible staff, evidence checked, restrictions and next review point. Identify the exact version or configuration where relevant. The record should be understandable to another leader covering the role later.

• Educational owner: confirms the learning purpose and suitable activity.
• Information and technical owners: review the relevant data and access arrangements.
• Safeguarding route: confirms how concerns are handled within school procedures.
• Delivery owner: checks supervision, materials, equipment and fallback.
• Review trigger: identifies changes that require reconsideration before reuse.

These are suggested responsibilities, not prescribed job titles. A small school and a large trust may allocate them differently. The important point is that each material question has an accountable answer rather than being assumed to belong to someone else.

For schools in England, review the DfE's AI policy material alongside local arrangements. Record jurisdiction clearly. Approval in one setting should not be copied into another country or school group without examining the differences.

Commission external teaching against the approved use

Give a provider the permitted delivery arrangement, year groups, learning outcomes and relevant access needs. The provider should design within those boundaries. Avoid a booking that promises pupil access to a product before the school has decided whether that access is appropriate.

The 114 Labs school training service can discuss supervised workshops and account-free activities with an adult school representative. Preparation should establish the format and responsibilities before a date is confirmed, with personal pupil details kept out of the initial enquiry.

Ask to review materials in advance and agree how changes are approved. A provider may update a demonstration after a product release, but that does not automatically make it suitable under the school's existing assessment. The agreed learning purpose and information boundaries remain the reference point.

For wider event planning, see the school AI literacy day guide. A tool review is one part of a useful event, alongside timetable, inclusion, teacher involvement and evaluation. None of those elements should be left until the trainer arrives.

Check the communication to families where relevant

Decide through the school's normal process whether families need information about the planned activity. The explanation should describe the learning purpose and actual arrangement, including whether pupils interact with a service or review prepared examples. Avoid a broad message that implies a wider school adoption than has been approved.

Use plain language and a clear route for questions. If an activity has an alternative, explain how it supports the same learning objective without making families or pupils disclose unnecessary personal information. Staff should know who can answer policy, educational and information-handling questions.

Keep the message consistent with the dated approval record. A provider's promotional description may mention features that the school has deliberately excluded. Review any text supplied externally before sharing it so the school's communication reflects the real event and its boundaries.

Record questions that reveal ambiguity in the plan. They may indicate that staff need to explain supervision or account use more clearly before delivery. Resolve material uncertainty through the responsible school lead, rather than relying on an informal assurance from whichever person receives the question first.

Recheck when the use or conditions change

Set a review date and event-based triggers. A changed account arrangement, new connected feature, revised provider condition or different pupil group can affect the decision. Staff need a clear way to identify that the previous approval no longer describes the proposed activity.

Retire outdated instructions from ordinary use. Keep necessary historical records in a controlled place, but avoid leaving several apparently current checklists available to teachers. A concise dated record is easier to apply than a large collection of copied guidance with no owner.

Use classroom observations to improve the assessment. Access problems, unexpected questions and difficult outputs reveal practical issues that a document review may miss. Record them through the agreed route and decide whether the activity, controls or materials need changing.

The checklist should support an informed educational decision. It helps the school know what it has approved, why it is suitable and what remains outside the boundary. That clarity makes future teaching easier to plan as tools and school arrangements evolve.

Checked sources

• Google: Gemini with an education account
• Google Workspace: age-based service controls
• DfE: AI and data protection in schools (England)
• W3C WAI: introduction to web accessibility
• DfE: generative AI in education (England)