AI Vendor Contracts for Schools: 10 Clauses to Check

Two professionals reviewing paperwork at a conference table with a laptop during an education technology procurement meeting

An AI tutor, writing assistant, assessment generator or classroom chatbot is not just another software subscription. It may process student prompts, essays, grades, voice recordings, disability-related information and interaction histories. The contract decides what the provider may do with that information, which other companies can access it, how long it remains stored and what happens when the school wants to leave.

That is why AI vendor contracts for schools deserve a separate review before a tool is approved for students. A product can look useful in a demonstration and still have terms that leave a school with little control over student data.

A timely development makes this issue more concrete. Beginning 1 November 2026, Microsoft says US school districts can add the AFT/UFT AI Safety & Privacy Standard to new or existing Microsoft agreements, without waiting for renewal or renegotiating the full contract. The protections become contractually enforceable when incorporated into the agreement. This is a significant vendor-specific step, not a rule that automatically covers every AI provider or every school worldwide. (Microsoft fact sheet; full 31-page standard)

Why school AI procurement is now a governance issue

The contract question is not simply whether a provider says it is secure. Schools need to know what data enters the system, why it is processed, whether prompts or outputs can be used to improve models, which subprocessors receive information, and whether administrators can verify the answers.

Research on educational technology procurement has repeatedly identified a gap between adopting tools and governing their data practices. A peer-reviewed study in the Journal of Consumer Affairs found a privacy-security chasm in K–12 technology adoption, drawing on interviews and public state reports. The authors argue that schools’ technology decisions can expose children to risks that are not always visible to the people selecting the products. (Walker et al., 2023)

A 2024 study of Canadian colleges and universities found that privacy, security, accessibility and care-of-data practices were important procurement considerations, but standards were not yet used in a consistently structured way. Its sample was small—10 institutions across six provinces—so it should be read as an exploratory environmental scan, not a representative estimate of every institution. (Ali, Prompiengchai & Joordens, 2024)

The practical implication is straightforward: schools should turn broad privacy promises into written, testable obligations. The following ten clauses provide a starting checklist for reviewing an AI data processing agreement (DPA), licensing agreement or procurement addendum.

10 clauses to check before signing an AI vendor contract

1. Define exactly what counts as school and student data

Do not define protected information as names and grades alone. AI products can process prompts, uploaded files, generated answers, voice and video, interaction logs, device identifiers, location information, saved memories and metadata. A student’s essay may contain personal details even when the student has not typed a name.

Ask the vendor for a data map that lists each category collected, its purpose, where it is processed, who can access it and how long it is kept. The contract should also distinguish genuinely de-identified operational telemetry from information that can still be linked to a learner. If the provider cannot explain the data flow in plain language, the school cannot meaningfully assess the risk.

2. Restrict purposes and prohibit model training on covered data

Write down the only purposes for which the provider may process school data: delivering the contracted service, maintaining security and other specifically authorised functions. Avoid vague permissions such as “improving our services” unless the agreement defines exactly what that means.

For student and educator information, request an explicit prohibition on using prompts, uploads, responses, records or derived data to train, fine-tune, benchmark or otherwise improve general AI models. The AFT/UFT standard takes this approach, with a narrowly defined exception for certain safety and security processing. If a vendor needs an exception, the contract should limit it to the minimum necessary data, a specific safety purpose, a defined retention period and auditable records. It must not become a back door for general model improvement.

3. Establish data ownership and the school’s legal role

State who owns student work, educator-created materials, prompts, outputs and institutional records. The provider should receive only the limited rights needed to deliver the service; it should not gain a broad licence to sell, advertise with, disclose or reuse school content.

The agreement should also identify the parties’ roles under the applicable privacy regime—for example, whether the school is the controller and the provider is a processor, or whether the provider determines some purposes independently. Those roles cannot be settled by a label alone: they must match what the parties actually do. Have the school’s data protection officer or qualified counsel review the lawful basis, notices and any required consent arrangements in the relevant jurisdiction.

4. Minimise collection and control high-risk features

The product should collect only the information necessary for the educational task. Ask whether optional features such as persistent memory, behavioural profiling, biometrics, precise location tracking, emotion inference or continuous attention monitoring can be disabled.

For younger learners, require age-appropriate settings and a clear explanation of how parental notice or consent is handled where the law requires it. A feature that is switched on by default can still create risk even if a school never intended to use it. Specify which settings the school administrator controls and whether the provider can change them remotely.

5. Name subprocessors and disclose data locations

Many AI services depend on external model providers, cloud hosts, analytics services and content-safety vendors. The school should receive a current list of subprocessors, what each one does, which data categories each receives and the countries or regions where data is stored and processed.

Require every subprocessor to be bound by protections at least as strong as the main contract. The provider should give advance notice before adding or replacing a subprocessor, explain material changes and offer a workable objection or termination route where the change creates a legitimate privacy or security concern. A statement that data may be shared with “trusted partners” is not enough.

6. Set retention, export and deletion rules—including backups

Specify retention periods for prompts, outputs, uploaded files, account records, safety logs, memory files and backups. Define what happens when a student leaves, a class ends, the pilot expires or the school terminates the service. Require export in a usable, documented format and written confirmation when deletion is complete.

Do not assume that pressing a delete button removes every copy. The AFT/UFT standard, for example, sets a defined deletion process and allows up to 180 days for deletion from active systems and backup copies in specified circumstances. That is a feature of that particular agreement, not a universal best-practice deadline. Schools should negotiate a period proportionate to the data and service, and clarify exceptions for legal holds or narrowly limited security investigations.

7. Make security and breach response measurable

Replace general assurances such as “industry-standard security” with evidence and obligations: encryption in transit and at rest, role-based access, least-privilege permissions, multi-factor authentication for privileged access, independent penetration testing, vulnerability management and a documented incident-response plan.

Set a clear breach-notification deadline, explain when the clock starts, identify the contacts who must be notified and require updates while the incident is investigated. The AFT/UFT standard specifies notification within 72 hours after awareness of a confirmed or reasonably suspected breach involving covered data. A school should use the applicable legal deadline where it is stricter, and should not treat 72 hours as a universal legal rule.

8. Keep people responsible for consequential decisions

AI may help teachers organise information or generate suggestions, but the contract should not allow the system to make consequential decisions about discipline, placement, special-education referrals, student risk classifications or employee evaluation without meaningful human review and authority to override the result.

Require the provider to explain the system’s intended use, known limitations, likely failure modes and the evidence behind high-impact claims. Define who investigates a disputed output, how it can be corrected and how affected learners or families can raise a concern. If the product includes agentic features that can send messages, submit work or take other actions, specify which actions are disabled by default and which require explicit approval.

9. Require transparency, accessibility and evidence of fairness

Ask for a plain-language explanation of how the AI feature works, what data it uses, what it cannot reliably do and how users can recognise AI-generated output. Require accessible design, including support for assistive technologies, captions, keyboard navigation and appropriate language support.

For systems used with diverse learners, request evidence about accuracy and performance across relevant groups, including students with disabilities and multilingual learners. The contract should provide a channel for reporting bias, accessibility failures or harm, and a process for the provider to investigate and remedy them. UNICEF’s 2025 Guidance on AI and Children places privacy, safety, fairness, transparency, inclusion and children’s best interests among its core requirements.

10. Control product changes, audits, exit and remedies

An AI product can change after procurement: the provider may switch models, introduce memory, add a chatbot, connect a new subprocessor or change how prompts are retained. Require advance notice of material changes and a right to review the privacy impact before those changes are enabled for students. The school should be able to disable a feature or pause deployment while a serious concern is assessed.

Include audit or assurance rights proportionate to the service, access to relevant certifications and reports, data portability, transition assistance and termination rights for material or repeated breaches. The provider should remain responsible for its subprocessors. Make sure the contract identifies which document prevails if the main terms, privacy addendum and product terms conflict.

Questions to send to an AI vendor

Before approving a tool, ask the provider to answer these questions in writing and attach the answers to the procurement record:

What exact student, educator and institutional data does the product collect, including prompts, outputs, logs and memory?
Will any covered data be used to train, fine-tune, evaluate or improve a model? If an exception exists, what precise purpose and controls limit it?
Which model providers and subprocessors receive the data, and where is it processed?
How long are active data, logs and backups retained, and how is deletion certified?
Can the school disable memory, profiling, tracking and agentic actions?
What independent security evidence, accessibility testing and fairness evaluations can the vendor provide?
What happens if the product changes materially, suffers a breach or fails to meet the contract?
Can the school export its records and leave without a technical or financial penalty?

If the answers are vague, inconsistent with the privacy policy or available only in marketing material, treat the issue as unresolved. A pilot should not be used to bypass procurement: where student data is involved, the necessary privacy and security terms should be in place before the data is uploaded.

How the checklist fits different legal systems

The Microsoft/AFT example is a useful contract model, but it is specific to participating products and US school agreements. Other jurisdictions should adapt the clauses to their own laws rather than copy US terminology.

European Union: the European Commission’s Public Buyers Community provides model contractual clauses for high-risk AI and a lighter, customisable version for non-high-risk AI. These are procurement templates, not a substitute for legal review or the EU AI Act and data-protection obligations. Explore the EU model clauses.
United Kingdom: the Department for Education’s EdTech procurement guidance, updated on 14 October 2026, recommends early DPO involvement, data minimisation, impact assessment for high-risk processing and clear contractual responsibilities for subprocessors, deletion, breach notification and staff access. Read the guidance.
Morocco: on 8 June 2026, the Higher Council for Education, Training and Scientific Research published a recommendation calling for a national framework to guide AI use in education, training and research. It highlights institutional responsibility, equity, learning quality and the human role in education; it is a policy recommendation, not itself a vendor-contract law. Read the Council’s recommendation.
Internationally: UNESCO’s guidance on generative AI in education and research and UNICEF’s child-centred AI guidance provide principles for privacy, age-appropriate use, human agency and children’s rights that can inform local procurement requirements.

A practical approval sequence for schools

Define the use case. Identify the learning or administrative problem and the people who will use the system.
Map the data. List what students and staff may enter, what the tool generates, and where each item goes.
Review the contract. Have procurement, IT/security, the DPO, safeguarding staff and educational leaders review the same written terms.
Test with dummy data first. Check usability and educational value without exposing identifiable student information.
Approve a limited pilot. Set success criteria, approved users, age groups, data limits, human oversight and a review date.
Reassess after changes. Keep a record of model, feature, subprocessor and retention changes, and renew staff guidance when the product changes.

Schools should also connect procurement with their wider AI use policy, their process for evaluating AI learning tools and safeguards for AI monitoring of teachers. A contract cannot decide whether a tool improves learning, but it can establish the boundaries within which a school tests that question responsibly.

The bottom line

A school AI contract should be judged by what it makes enforceable, not by how reassuring the vendor’s privacy page sounds. Define the data, limit its use, control subprocessors, set deletion rules, require security evidence, preserve human oversight and secure a practical exit route. The November 2026 Microsoft/AFT development shows that these protections can be written into commercial agreements. The next step for every school is to make its own requirements explicit before student data enters an AI system.

This article is an educational procurement checklist, not legal advice. Contract language, consent, data residency and retention requirements must be reviewed against the laws and procurement rules that apply to the school.

AI Vendor Contracts for Schools: 10 Clauses to Check Before Signing