Ten Questions a School Should Ask Before Buying an AI Tool

AI tools are unusually easy to demonstrate. A vendor can produce a personalised worksheet, summary or chatbot response in seconds. School procurement requires a different standard: does the product create educational value without introducing risks the school cannot manage?

• What precise learning or operational problem is this tool solving?
• What evidence supports the claimed benefit?
• What student and staff data is collected?
• Where is data stored, how long is it retained and who can access it?
• Is student data used to train or improve external models?
• What safeguards apply to minors and age-appropriate use?
• How does the tool handle bias, harmful output and incorrect answers?
• Can teachers understand and override consequential recommendations?
• Is the tool accessible to students with different needs and devices?
• What happens to data and workflow if the school stops using the product?

UNICEF's 2026 EdTech for Good Framework emphasises transparency, safety, educational soundness, contextual appropriateness and accessibility. Its child-centred AI guidance adds privacy, fairness, human oversight and accountability. These are useful procurement categories even when a local legal review requires different specific obligations.

Ask for evidence in school language

Avoid broad statements such as 'improves outcomes' without asking which outcome, in which population, over what period and measured how. A small pilot with clearly defined success and stop criteria is safer than an immediate whole-school rollout.

Do not confuse security language with educational value

A product can have strong technical controls and still be a poor learning tool. It can also be pedagogically interesting and mishandle data. Schools need both lenses.

Run the demo with a deliberately difficult case

Vendor demonstrations naturally use happy-path examples. Ask the product to handle an ambiguous prompt, a wrong student assumption, an accessibility need or a scenario where it should refuse to act. The school learns more from how the system behaves at the edge than from a perfectly prepared sample lesson.

Ask the vendor to distinguish product capability from research evidence. 'Our tool can personalise questions' is a feature statement. 'Our tool improves learning outcomes' is an evidence claim that should come with a study, population, measure and limitations. This distinction keeps procurement conversations precise.

Pilot before you standardise

• Choose one grade or use case rather than whole-school deployment.
• Define what success and unacceptable failure look like in advance.
• Collect teacher workload and student-experience feedback, not only usage counts.
• Test data deletion/export before the contract becomes hard to unwind.
• Review whether the tool changed learning practice or merely added another login.

A successful pilot can justify scale. An unsuccessful one can still save the school money and risk. Procurement should be designed to learn before it locks in.

Include the exit test in procurement

Before signing a long contract, ask the vendor to demonstrate export and deletion. Can the school retrieve its data in a usable format? Can administrators delete test accounts? What happens to student information after termination? A product that is easy to enter and hard to leave creates operational risk even if the demo is excellent.

Also ask how the product communicates material model or policy changes. AI systems evolve rapidly; the school needs a route to review changes that affect safety, privacy, output quality or classroom expectations.