How to Evaluate AI Tools for Your School: A Procurement Checklist

The number of AI products marketed at UK schools has grown rapidly over the past two years. Chatbots, homework helpers, attendance predictors, timetabling assistants and parent communication platforms are all competing for attention — and for budget. For school leaders and IT managers, the challenge is no longer whether to consider AI, but how to evaluate competing products rigorously and responsibly. Ask.School is an AI-powered parent communication platform for UK schools, with transparent pricing, a 14-day free trial, and no hidden fees. This guide, however, is not about any single product. It is a vendor-neutral procurement checklist that any school can use when evaluating AI tools of any kind.

Procurement in schools has always been complex. Budgets are tight, technical expertise varies, and the consequences of getting it wrong — particularly where safeguarding or data protection are concerned — can be severe. AI tools add a further layer of complexity because the technology is unfamiliar to many decision-makers, vendor claims can be difficult to verify, and the regulatory landscape is still evolving. Schools need a structured, repeatable process for evaluating AI vendors that covers compliance, cost, integration, and exit provisions.

Ask.School has compiled a structured process to help. It is organised around six evaluation areas, each with specific questions to ask vendors and criteria to assess. At the end, there is a consolidated checklist table that school leaders can use as a working document during procurement. The guidance draws on the requirements set out in Keeping Children Safe in Education (KCSIE), the Generative AI Product Safety Standards, the DfE guidance on generative AI in education, and ICO guidance on data protection.

Why does AI procurement require a different approach?

Schools are experienced at procuring technology. Management information systems, parent payment platforms, website providers and communication tools have been part of school operations for years. However, AI tools introduce considerations that do not apply to conventional software.

First, AI systems can generate content. A traditional software tool displays information that has been entered by a human. An AI chatbot, by contrast, generates responses dynamically. This means the school cannot review every response in advance. The tool’s behaviour depends on the underlying model, the training data, the prompt engineering, and the guardrails the vendor has put in place. Evaluating an AI tool therefore requires understanding not just what it does, but how it decides what to do.

Second, AI tools interact with vulnerable users. If a school deploys an AI chatbot that parents or students can access, that tool is interacting with children and families. The safeguarding implications are significant. A well-designed chatbot needs robust safeguards to provide accurate information, escalate safeguarding concerns appropriately, and prevent inappropriate content. These risks do not exist with a static FAQ page or a conventional parent portal.

Third, the regulatory framework is specific. The UK government’s Generative AI Product Safety Standards set out 14 requirements that AI products used in education must meet. These are not guidelines or suggestions — they represent the government’s expectations for safe AI in schools. Schools that reference these standards during procurement are well placed to demonstrate due diligence. For a full breakdown, see the Ask.School guide to the Generative AI Product Safety Standards.

Fourth, AI vendors vary enormously in maturity. Some are established education technology companies that have added AI features to existing products. Others are startups with limited track records. Some are general-purpose AI companies that have repackaged consumer products for the education market. The procurement process needs to distinguish between these different types of vendor and assess each one appropriately.

What safeguarding checks should schools carry out?

Safeguarding is the first and most important evaluation criterion. No AI tool should be deployed in a school without a thorough assessment of its safeguarding provisions. This applies whether the tool is used by staff, students, parents, or all three.

KCSIE compliance

Part 2 of Keeping Children Safe in Education (KCSIE) 2025 sets out the requirements for filtering and monitoring of school IT systems. While KCSIE was written primarily with internet access and device management in mind, its principles apply equally to AI tools. Any AI system that students or parents can interact with must have appropriate content filtering and must not be capable of generating harmful, inappropriate or misleading content.

Schools should ask vendors the following questions:

Content filtering: How does the tool prevent harmful or inappropriate content from being generated? Is filtering rule-based, model-based, or both? How is it updated as new risks emerge?
Age-appropriate design: Has the tool been designed for use in an education setting? Is the content and language appropriate for the age group that will use it?
Safeguarding escalation: What happens if a user discloses abuse, self-harm, or another safeguarding concern? Does the tool escalate to a human? Does it alert the school’s designated safeguarding lead? Ask.School’s safeguarding alerts show how this works in practice.
Anthropomorphism: Does the tool present itself as a person, use a human name, or encourage emotional attachment? The Generative AI Product Safety Standards explicitly prohibit this.
Audit trail: Can the school’s safeguarding team access full conversation logs? Are logs retained for an appropriate period?

For a detailed analysis of how KCSIE applies to AI tools, see the Ask.School guide on how schools can meet KCSIE requirements when using AI tools.

Generative AI Product Safety Standards

The UK government’s Generative AI Product Safety Standards set out 14 specific requirements for AI products used in education. Schools should ask vendors to confirm compliance with each standard. The 14 requirements cover:

Transparency and children’s safety prioritised in design
Technical and operational mitigations for identified risks
Testing with diverse and realistic user groups
Effective content filtering for harmful material
Age-appropriate safeguards
Anthropomorphism prohibited
Progressive disclosure of information
Mental health safeguards and escalation to human support
No manipulative strategies (sycophancy, dark patterns, social pressure)
Transparent reward systems
Robust activity logging
Safeguarding alerts for concerning patterns
Clear privacy notices in age-appropriate language
Data Protection Impact Assessment completed

A vendor that cannot demonstrate compliance with all 14 standards should not be deployed in a school. For the full breakdown of what each standard means in practice, see the Ask.School guide to the Generative AI Product Safety Standards.

Safeguarding evaluation table

Safeguarding Question	What to Look For	Red Flag
How is harmful content filtered?	Multi-layered filtering (model + rules), education-specific, regularly updated	“We use the default model filters” or inability to explain the approach
What happens with safeguarding disclosures?	Automatic escalation to DSL, clear protocol documented	No escalation process, or responses handled entirely by AI
Does it anthropomorphise the AI?	Clear labelling as AI, function-based naming, no human persona	Human name, avatar, or conversational style that implies personality
Can safeguarding staff access conversation logs?	Full audit trail accessible via dashboard, retention period specified	Logs not available to schools, or no logging at all
Has it been designed for education?	Built for schools from the outset, not adapted from a consumer product	“We serve multiple industries” with no education-specific safeguards
Does it meet all 14 AI Product Safety Standards?	Vendor can map their product against each standard with evidence	Vendor is unaware of the standards, or cannot demonstrate compliance

What data protection checks are required?

Data protection is the second critical evaluation area. Schools are data controllers under UK GDPR and the Data Protection Act 2018. When a school introduces a new AI tool, it is introducing a new data processor — and the school remains responsible for ensuring that processing is lawful, fair and transparent.

Schools should evaluate AI tools against the core principles of UK GDPR:

Lawfulness, fairness and transparency: Is there a clear legal basis for processing? Are users informed about what data is collected and how it is used?
Purpose limitation: Is data collected only for the stated purpose? Is it used for anything else, such as model training or marketing?
Data minimisation: Does the tool collect the minimum amount of data necessary? Does it require user accounts, or can it operate without collecting personal data?
Storage limitation: How long is data retained? Is there a clear retention policy?
Integrity and confidentiality: Is data encrypted in transit and at rest? What security measures are in place?
Accountability: Can the vendor demonstrate compliance? Do they have appropriate policies and documentation?

Data hosting and international transfers

Where data is stored matters. UK GDPR requires that personal data transferred outside the UK is subject to appropriate safeguards. Schools should ask:

Where is data hosted? Look for UK-based hosting on infrastructure with recognised certifications (ISO 27001, Cyber Essentials Plus, or equivalent).
Is data transferred internationally? If data is processed in the US, EU, or elsewhere, the vendor must demonstrate appropriate transfer mechanisms (adequacy decisions, standard contractual clauses, or binding corporate rules).
Which sub-processors are involved? AI vendors often rely on third-party services for hosting, model inference, analytics, and other functions. Each sub-processor introduces additional data protection considerations.

Data Protection Impact Assessment

The ICO guidance on Data Protection Impact Assessments (DPIAs) makes clear that a DPIA is required when processing is likely to result in a high risk to individuals. AI tools used in schools almost always meet this threshold, particularly where children’s data is involved.

Schools should ask vendors two questions:

Has the vendor completed a DPIA for this product? A credible vendor will have a DPIA that covers the risks of AI processing, the mitigations in place, and the residual risks. They should be willing to share this document or at least a summary.
Does the school need to complete its own DPIA? As the data controller, the school may need to carry out its own assessment. This is especially important where the tool will process children’s data or where the school is introducing AI for the first time.

For step-by-step guidance on completing a school-level DPIA, see the Ask.School guide on data protection and AI in schools: a practical DPIA guide.

Data processing agreement

Before deploying any AI tool, the school must have a Data Processing Agreement (DPA) in place with the vendor. This is a legal requirement under Article 28 of UK GDPR. The DPA should specify:

The nature and purpose of processing
The type of personal data processed
The categories of data subjects
The obligations of the processor
Sub-processor arrangements
Data breach notification procedures
Data deletion or return on contract termination

If a vendor is unwilling to enter into a DPA, or if they do not have a template DPA available, that is a significant red flag.

Model training and data usage

One of the most important questions to ask any AI vendor is whether conversation data, user data, or school data is used to train or improve AI models. Many consumer AI tools use this data by default. For schools, this is unacceptable.

The Generative AI Product Safety Standards explicitly state that personal data must not be collected for commercial purposes such as model training without explicit consent. Even where a vendor claims that data is anonymised before being used for training, the risk of re-identification — particularly with small datasets from individual schools — means schools should treat model training with user data as a red line.

Ask the vendor directly:

Is any data from our school used to train AI models?
Is any data from our school used to improve your product?
Can we opt out of any data sharing arrangements?
What happens to our data if we terminate the contract?

For a broader overview of data protection considerations, see the Ask.School guide on data protection and AI: what schools need to get right.

Data protection evaluation table

Data Protection Question	What to Look For	Red Flag
Where is data hosted?	UK-based, ISO 27001 or Cyber Essentials Plus certified	Data hosted outside UK with no adequacy decision or transfer mechanism
Is data used for model training?	Explicit “no”, documented in DPA	Vague answer, “anonymised data may be used”, or no clear policy
Has the vendor completed a DPIA?	DPIA available on request, covers AI-specific risks	No DPIA, or vendor is unfamiliar with the requirement
Is a Data Processing Agreement available?	Template DPA provided, covers Article 28 requirements	No DPA available, or vendor resistant to signing one
What data is collected from users?	Minimal data collection, no account required for end users	Requires personal data from parents or students to function
How long is data retained?	Clear retention policy, data deleted on contract termination	Indefinite retention, or no clear policy
Who are the sub-processors?	Transparent list of sub-processors with locations and purposes	Vendor cannot or will not disclose sub-processors

How should schools assess cost and pricing transparency?

Cost evaluation for AI tools requires more scrutiny than for conventional school software. AI pricing models are often complex, and schools have reported unexpected costs from usage-based pricing, overage charges, and hidden fees for features that were assumed to be included.

Pricing models

AI tools for schools typically use one of the following pricing models:

Pricing Model	How It Works	Advantages	Risks
Per-student, per-year	Fixed annual fee based on school roll	Predictable, easy to budget	May overpay if usage is low
Per-conversation or per-query	Charged per interaction	Only pay for what you use	Costs can spike unexpectedly, difficult to budget
Tiered subscription	Monthly or annual fee for a set of features/usage limits	Moderate predictability	Overage charges if limits exceeded, features may require upgrades
Free with premium upsell	Basic version free, advanced features paid	Low barrier to entry	Free tier may lack safeguarding features, lock-in risk
Per-seat (staff)	Charged per staff user	Predictable for small teams	Expensive at scale, may limit adoption

Schools should ask for a total cost of ownership over three years, not just the headline price. This should include:

Setup and onboarding fees: Are there one-off costs for implementation, training, or data migration?
Annual licence or subscription fees: What is included? What costs extra?
Usage overage charges: If there are usage limits, what happens when they are exceeded?
Support and maintenance: Is support included, or is there a separate charge for premium support?
Integration costs: Are there additional fees for connecting to existing school systems?
Price escalation: Is the price fixed for the contract term, or can it increase? By how much?

Hidden costs to watch for

Schools should be alert to several common hidden costs in AI procurement:

Model upgrade charges: Some vendors charge extra when they upgrade the underlying AI model. This can result in unexpected invoices for improvements the school did not request.
Data export fees: If the school wants to export its data (for example, to switch to a different vendor), are there charges? This is particularly concerning if data export is technically complex.
Training and CPD: Some vendors provide initial training free but charge for ongoing professional development or for training new staff members.
Feature gating: Features that appear to be standard — such as safeguarding dashboards, analytics, or multi-language support — may only be available on higher-priced tiers.
API or integration charges: Connecting the AI tool to other school systems (MIS, website, calendar) may require a more expensive plan or separate API access fees.

Cost evaluation table

Cost Question	What to Look For	Red Flag
What is the total annual cost?	Clear per-student or per-school pricing, no hidden fees	Complex pricing requiring custom quotes, or reluctance to provide written pricing
Are there usage limits?	Unlimited or generous limits appropriate for school use	Low conversation limits with high overage charges
What happens at renewal?	Fixed pricing or capped increases for the contract term	No price guarantee, or vendor reserves right to change pricing
Is there a setup fee?	No setup fee, or modest one-off charge clearly stated	Large implementation fees, or fees that are only mentioned late in the process
What does support cost?	Support included in the subscription	Premium support tiers, or charges for phone/email support
Can the school export its data?	Free data export in standard formats at any time	Data export charged, or only available in proprietary formats

What integration requirements should schools consider?

An AI tool that does not integrate with existing school systems creates additional work rather than reducing it. Integration should be a core evaluation criterion, not an afterthought.

Management information system (MIS) integration

Most schools use a management information system — such as Arbor, Bromcom, SIMS, or ScholarPack — as their primary source of truth for student data, attendance records, staff information, and school structure. An AI tool that can integrate with the MIS can automatically access up-to-date information without requiring manual data entry.

Schools should ask:

Does the tool integrate with our MIS?
Is the integration read-only, or does it write data back to the MIS?
How frequently is data synchronised?
What happens if the MIS changes (for example, if the school switches from SIMS to Arbor)?

For an example of how MIS integration works in practice — including automatic user sync and leaver deactivation — see the guide on how to connect your school MIS to Ask.School.

School website integration

For AI chatbots that will be used by parents or the public, website integration is essential. The chatbot needs to be embedded on the school website in a way that is accessible, clearly labelled as AI, and consistent with the school’s branding.

Key questions include:

How is the chatbot embedded on the website? Is it a simple script tag, an iframe, or a more complex integration?
Can the school customise the appearance to match its branding?
Is the chatbot accessible (WCAG 2.1 AA compliant)?
Does embedding affect website performance or page load times?

Calendar and events integration

Schools that want their AI tool to provide information about term dates, events, parents’ evenings, and other calendar items need to check whether the tool can pull data from existing calendar systems.

Does the tool integrate with Google Calendar, Microsoft 365, or the school’s existing calendar system?
Can it pull events from the school website?
How are changes to events reflected in the AI’s responses?

Single sign-on and authentication

For staff-facing AI tools, integration with the school’s existing authentication system reduces friction and improves security.

Does the tool support single sign-on (SSO) via Google Workspace, Microsoft 365, or another identity provider?
Is multi-factor authentication (MFA) supported? Ask.School’s security and 2FA documentation explains how this is handled.
Can user access be managed through existing directory services?

Integration evaluation table

Integration Question	What to Look For	Red Flag
Does it integrate with our MIS?	Direct integration with major UK MIS providers (Arbor, Bromcom, SIMS) — see Ask.School’s Wonde integration guide for an example	No MIS integration, or requires manual data entry
How is website embedding handled?	Simple embed code, customisable, accessible	Complex integration requiring developer support, or inaccessible design
Does it sync with school calendars?	Automatic calendar sync with common providers	Manual calendar management within the tool
Is SSO supported?	Google Workspace and/or Microsoft 365 SSO	Separate login credentials required for all users
What APIs are available?	Documented API for custom integrations	No API, or API only available on premium plans
How is the knowledge base updated?	Schools can update content directly, changes reflected promptly	Vendor must make changes, or long delays before updates take effect

What should a trial and contract look like?

Trial and contract terms have significant implications for the school’s flexibility and risk exposure.

Trial provisions

Schools should always test an AI tool before committing to a contract. A meaningful trial should include:

Sufficient duration: A minimum of 14 days, though 30 days is preferable for tools that require setup and configuration.
Full feature access: The trial should include all the features that would be available under the paid plan. A trial that restricts access to safeguarding features or analytics is not a genuine test of the product.
No payment required: The trial should not require credit card details or a purchase order. Schools should be able to evaluate the tool without any financial commitment.
Realistic testing conditions: The school should be able to test with real content (or representative sample content) and with the user groups that will use the tool in practice.
Support during trial: The vendor should provide support during the trial period to help the school set up and evaluate the tool.

Contract terms

When moving from trial to contract, schools should negotiate terms that protect the school’s interests:

Contract length: Annual contracts are standard. Multi-year contracts may offer discounts but reduce flexibility. Schools adopting AI for the first time should prefer shorter initial terms.
Termination provisions: What notice period is required? Can the school terminate early if the tool does not meet expectations? Are there penalties for early termination?
Data portability: What happens to the school’s data when the contract ends? The vendor should commit to providing all school data in a standard, usable format within a reasonable timeframe.
Data deletion: The vendor should confirm that all school data will be deleted from their systems (including backups) within a specified period after contract termination. This is a UK GDPR requirement.
Service level agreements (SLAs): What uptime is guaranteed? What happens if the service is unavailable? Are there penalties for failing to meet SLAs?
Price protection: Is the price fixed for the contract term? If not, what are the limits on price increases?

Exit planning

Exit planning should begin at the point of procurement, not at the point of termination. Schools should consider:

Switching costs: How difficult would it be to switch to a different vendor? Are there technical, contractual, or operational barriers?
Data format: Can data be exported in formats that another vendor could import? CSV, JSON, and standard API exports are preferable to proprietary formats.
Knowledge base portability: If the school has built up a knowledge base within the tool (FAQs, school information, policies), can that content be exported?
User communication: If the tool is parent-facing, what is the plan for communicating a change to parents? Schools should consider the reputational impact of switching.
Transition period: Does the vendor provide a transition period during which the old and new tools can run in parallel?

Trial and contract evaluation table

Trial/Contract Question	What to Look For	Red Flag
Is a free trial available?	14+ days, full features, no payment required	No trial, or trial requires credit card or purchase order
What is the contract length?	Annual, with option to extend	Multi-year lock-in with no early exit clause
What is the termination notice period?	30 to 90 days	6+ months, or automatic renewal without adequate notice
What happens to data on termination?	Data exported in standard formats, then deleted	Data retention after termination, or no export facility
Are there early termination penalties?	No penalties, or reasonable and clearly stated	Punitive exit fees, or fees that are not disclosed upfront
Is the pricing fixed?	Fixed for the contract term, or capped annual increases	Uncapped price increases, or pricing that changes at vendor’s discretion

How should schools structure the evaluation process?

Having covered the six evaluation areas — safeguarding, data protection, cost, integration, trial, and contract — schools need a process for applying these criteria to actual vendor evaluations.

Step 1: Define requirements

Before approaching any vendor, the school should document its requirements. This should include:

The problem the school is trying to solve (for example, reducing phone calls to the office, improving parent access to information, or automating routine enquiries)
The user groups who will interact with the tool (staff only, parents, students, or all three)
The systems the tool must integrate with
The budget available
The timeline for deployment
Any specific regulatory requirements (for example, if the school has been advised by its DPO to carry out additional checks for AI tools)

Step 2: Create a shortlist

Research the market and create a shortlist of 3-5 vendors. Consider:

Vendors recommended by other schools or trusts
Vendors that appear in DfE-endorsed resources or guidance
Vendors that are members of relevant trade bodies (EdTech UK, BESA)
Vendors whose products have been independently reviewed or certified

Step 3: Issue a request for information

For each shortlisted vendor, issue a structured request for information based on the evaluation criteria above. Ask vendors to provide:

Written responses to safeguarding and data protection questions
A copy of (or access to) their DPIA
Detailed pricing, including total cost of ownership over three years
Integration documentation
References from other UK schools
A copy of their standard contract and DPA

Step 4: Evaluate responses

Score each vendor against the evaluation criteria. The checklist table at the end can be used as a scoring framework. Consider involving:

The headteacher or a member of the senior leadership team (strategic fit)
The IT manager or network administrator (technical evaluation)
The designated safeguarding lead (safeguarding assessment)
The school business manager (cost and contract evaluation)
The DPO or data protection lead (data protection compliance)

Step 5: Run trials

For the top 1-2 vendors, run a structured trial. Define in advance what success looks like:

How many enquiries should the tool handle correctly?
How do users (staff, parents) rate the experience?
Does the tool integrate successfully with existing systems?
Are there any safeguarding or data protection concerns that emerged during the trial?

Step 6: Make a decision and document it

Document the evaluation process and the reasons for the final decision. This documentation serves several purposes:

It demonstrates due diligence to governors, trustees, and auditors
It provides evidence for Ofsted that the school has evaluated AI tools against safeguarding requirements
It creates a reference point for future procurement decisions
It supports the school’s DPIA process

Schools looking for a platform that meets these criteria can explore Ask.School, which offers a 14-day free trial with full feature access and no payment required. The getting started guide walks through the onboarding process step by step.

What questions should schools ask at each stage?

This section consolidates the questions from across the guide into a structured format that schools can use at each stage of the evaluation process.

Questions for initial vendor screening

These questions can be asked via email or a web form to quickly filter vendors before investing time in detailed evaluation:

Is your product designed specifically for UK schools, or is it a general-purpose product adapted for education?
Can you confirm compliance with all 14 of the UK government’s Generative AI Product Safety Standards?
Where is data hosted, and is any data transferred outside the UK?
Is any school data used to train or improve AI models?
Do you offer a free trial with no payment required?
Can you provide references from UK schools currently using your product?

A vendor that cannot answer “yes” to questions 1, 2, and 6 — or that answers “yes” to question 4 — should not proceed to detailed evaluation.

Questions for detailed evaluation

These questions should be explored in a demonstration meeting or through a detailed written response:

Safeguarding

Walk us through what happens when a user types a safeguarding concern into your chatbot.
How do you filter harmful content? Can you show us examples of content that would be blocked?
Does your tool alert our designated safeguarding lead? How?
Can our safeguarding team access full conversation logs?

Data protection

Can we see your DPIA?
Who are your sub-processors, and where are they based?
What is your data retention policy?
Can you provide a copy of your standard Data Processing Agreement?

Cost

What is the total cost for our school over three years, including all fees?
Are there any usage limits? What happens if we exceed them?
What is included in the price, and what costs extra?
Is the price fixed for the contract term?

Integration

How does your tool integrate with [specific MIS]?
Can we see a demonstration of the website embedding?
Does the tool support SSO via [Google Workspace / Microsoft 365]?
How do we update the knowledge base?

Contract

What is the minimum contract term?
What is the termination notice period?
What happens to our data when the contract ends?
Can we export our data in standard formats?

Questions for reference schools

When speaking to schools that already use the product:

How long have you been using this tool?
What problem were you trying to solve?
How was the implementation process?
Have you had any safeguarding concerns related to the tool?
Has the vendor been responsive to issues or feature requests?
What do parents think of the tool?
Would you choose this vendor again?

Consolidated procurement checklist

The following table brings together all evaluation criteria into a single checklist. Schools can use this as a working document during procurement, scoring each vendor against each criterion.

Safeguarding

#	Criterion	Pass	Fail	Notes
S1	Tool designed specifically for education use
S2	Effective content filtering for harmful material
S3	Age-appropriate design and language
S4	Safeguarding disclosure escalation to DSL
S5	No anthropomorphism (no human names, personas)
S6	Full conversation audit trail accessible to school
S7	Mental health safeguards (detects distress, directs to human support)
S8	No manipulative strategies (dark patterns, sycophancy, social pressure)
S9	Complies with all 14 Generative AI Product Safety Standards
S10	Vendor provides evidence of safeguarding testing

Data protection

#	Criterion	Pass	Fail	Notes
D1	Data hosted in the UK or country with adequacy decision
D2	No school data used for model training
D3	Vendor DPIA completed and available on request
D4	Data Processing Agreement provided
D5	Minimal personal data collection (no accounts required for end users)
D6	Clear data retention policy
D7	Sub-processors disclosed with locations
D8	Data encrypted in transit and at rest
D9	Data deletion confirmed on contract termination
D10	Compliant with UK GDPR and Data Protection Act 2018

Cost and pricing

#	Criterion	Pass	Fail	Notes
C1	Clear, transparent pricing (no custom quotes required)
C2	Total cost of ownership documented over 3 years
C3	No hidden fees (setup, support, integration, export)
C4	Pricing fixed or capped for contract term
C5	No punitive overage charges
C6	Free data export in standard formats

Integration

#	Criterion	Pass	Fail	Notes
I1	Integrates with school MIS (Arbor, Bromcom, SIMS, or equivalent)
I2	Simple website embedding (accessible, customisable)
I3	Calendar integration
I4	SSO support (Google Workspace and/or Microsoft 365)
I5	Documented API for custom integrations
I6	School can update knowledge base directly

Trial and contract

#	Criterion	Pass	Fail	Notes
T1	Free trial (14+ days, full features, no payment required)
T2	Annual contract (no multi-year lock-in required)
T3	Reasonable termination notice period (90 days or fewer)
T4	Data export and deletion on termination
T5	No early termination penalties (or reasonable, clearly stated)
T6	UK school references provided

Scoring guidance

Schools may wish to assign weights to different categories depending on their priorities. A suggested weighting for a school procuring an AI chatbot:

Category	Suggested Weight	Rationale
Safeguarding	30%	Non-negotiable — any fail in this category should be disqualifying
Data protection	25%	Legal requirement — failures create regulatory and reputational risk
Cost and pricing	15%	Important but secondary to compliance
Integration	15%	Affects operational efficiency but can be worked around
Trial and contract	15%	Affects risk exposure and flexibility

Key principle: Safeguarding and data protection criteria should be treated as pass/fail. A vendor that fails on any item in S1-S10 or D1-D10 should not be considered, regardless of how well they perform in other areas.

What does good look like in practice?

A well-evaluated AI tool for schools will typically share the following characteristics:

Built for education from the start: Not a consumer product repurposed for schools. The vendor understands the education sector, the regulatory environment, and the specific needs of school staff and parents.
Transparent about its AI: Clearly labelled as AI, with no attempt to mimic a human. Users understand they are interacting with a machine.
Minimal data collection: Does not require parents or students to create accounts or provide personal information. Processes the minimum data necessary to function.
UK data hosting: All data stored in the UK on certified infrastructure. No international transfers without appropriate safeguards.
No model training with school data: Conversation data is used only to provide the service, not to train or improve AI models.
Clear, predictable pricing: Per-student or per-school pricing with no hidden fees, no overage charges, and no price escalation clauses.
Easy to integrate: Works with existing school systems without requiring specialist technical knowledge.
Easy to leave: Data can be exported at any time, contracts can be terminated with reasonable notice, and there are no punitive exit fees.
Proven in schools: References from UK schools that have used the product and can speak to its effectiveness, reliability, and the vendor’s responsiveness.

Conclusion

Procuring AI tools for schools requires a structured approach that prioritises safeguarding and data protection above all other considerations. The evaluation criteria covered above — safeguarding, data protection, cost, integration, and trial/contract provisions — provide a comprehensive framework that schools can apply to any AI vendor.

The regulatory landscape for AI in education is still developing, but the core requirements are clear. The Generative AI Product Safety Standards, KCSIE, UK GDPR, and the Data Protection Act 2018 together set the minimum bar for any AI product used in a school. Vendors that cannot meet these requirements should not be in contention, regardless of their pricing, features, or marketing claims.

Schools that follow a structured procurement process — defining requirements, shortlisting vendors, evaluating responses against clear criteria, running meaningful trials, and documenting decisions — will be better placed to choose AI tools that genuinely support their goals while protecting their school community.

Start a 14-day free trial with no payment required at ask.school/register.