The school AI procurement questions vendors hope you do not skip

Quick answer

School AI procurement should evaluate the complete service, not just the model response. Districts should ask who controls the classroom workflow, what data enters each system, whether prompts or outputs train models, which subprocessors receive content, how long records persist, what teachers can see, how accessibility is tested, what evidence supports learning claims, how incidents are handled, and how data and services are exited at contract end.

The demo is the least hostile environment the product will ever see

Vendor demonstrations are curated. The prompt is clean, the network works, the content is familiar, and nobody is trying to bypass a guardrail five minutes before lunch. Procurement must evaluate the system that will exist after thousands of students, teachers, assignments, accommodations, devices, and edge cases collide with it.

That means separating model quality from product quality. A strong underlying model does not create district identity management, assignment controls, usable teacher visibility, clear retention, accessible interfaces, support ownership, or a defensible incident process.

Start with the educational job

Before reviewing features, require the district sponsor to name the educational problem. "We need AI" is not a use case. "Students need guided algebra practice outside class while teachers need to see common misconceptions" is a use case that can be tested.

The vendor should explain where the AI is expected to help, where it should refuse or defer, and what teachers and students must still do. A product that cannot articulate those boundaries is selling capability without an instructional theory.

• What student or educator problem is this deployment intended to improve?
• Which users, grades, subjects, and assignments are in scope?
• What should the AI never do in this workflow?
• What evidence would show that the product is not helping?
• What non-AI alternative remains available?

Follow the data through every system

Ask the vendor to draw the data flow. Prompts may move through the application database, a model provider, safety services, observability tools, support systems, backups, and analytics. Uploaded documents and outputs may follow different paths. A single sentence about encryption does not answer where the content goes.

The district should know what is collected by default, what is optional, what is derived, who can access each category, where it is stored, how long it remains, how it is deleted, and whether any copy is used to train, fine-tune, evaluate, or improve a model or product.

1. Inputs

Prompts, files, assignments, identifiers, metadata, device information, and teacher configuration.

2. Outputs

Responses, scores, summaries, flags, classifications, recommendations, and generated artifacts.

3. Derived records

Usage analytics, risk labels, embeddings, profiles, and aggregate or de-identified datasets.

4. Recipients

Model providers, hosting providers, safety vendors, support tools, analytics services, and human reviewers.

5. Lifecycle

Creation, active use, archive, backup, export, deletion, and post-contract disposition.

Interrogate model and product change

AI services change faster than traditional curriculum software. A vendor may switch models, alter system prompts, add memory, enable web access, change moderation, introduce a new subprocessor, or expand data use without changing the product name.

The contract and governance process should define which changes require notice, re-review, consent, or the ability to disable a feature. Ask how the vendor tests releases against educational guardrails and whether the district can remain on a stable configuration during the school year.

Test teacher control and meaningful visibility

"Teacher dashboard" is not a specification. Ask what the teacher can set per class and assignment, what students see, what activity is retained, how summaries are produced, what creates a flag, and whether the teacher can inspect the underlying context before acting.

Visibility should help instruction rather than manufacture surveillance labor. The vendor should demonstrate how a teacher identifies a class-wide misconception, reviews a significant safety or integrity event, and avoids reading routine conversations one by one.

• Can teachers define allowed assistance for a specific assignment?
• Can the system explain why it refused, redirected, or flagged an interaction?
• Can teachers distinguish an aggregate pattern from an individual concern?
• Are alerts configurable and auditable?
• Can the district export the evidence needed for a fair review?

Require proof for security, accessibility, and claims

Ask for independent security documentation, incident history, authentication options, role design, logging, vulnerability management, and breach-notification commitments appropriate to the risk. Then test the actual product configuration the district will use rather than accepting a document about a different enterprise tier.

Accessibility also needs product evidence. Request a current VPAT or equivalent documentation, keyboard and screen-reader testing, caption and contrast support, language-access information, and a process for remediating barriers. For learning claims, request study design, population, comparison condition, duration, outcome definition, and limitations.

Procure the exit before signing the entrance

A district should know how it will leave before it arrives. Require export formats, deletion timelines, transition support, treatment of backups and derived data, account closure, return or destruction certification, and continued access to records needed for complaints or audits.

Also ask what happens if the model provider disappears, pricing changes, a core feature is removed, or the service no longer meets the district's instructional or legal requirements. The right to terminate is less useful if the district cannot recover its data or continue the school year.

Turn answers into scored evidence

Use a written rubric with pass, conditional, and fail criteria. Record the evidence supporting each answer, unresolved risks, responsible owner, required contract language, approved scope, settings, and renewal date. Do not let a charismatic demonstration overwrite a missing control.

The best procurement record is useful after purchase. It becomes the implementation checklist, configuration baseline, incident reference, and renewal standard.

Frequently asked questions

What is the most important question to ask a school AI vendor?

Ask the district and vendor to define the exact educational use case, then trace the data, controls, evidence, and risks for that use. A generic product-level approval is too broad to be meaningful.

Should districts ask whether student data trains the AI model?

Yes, but they should ask more precisely about training, fine-tuning, evaluation, product improvement, safety review, human inspection, derived data, model providers, and whether those uses are on or off by default.

What should cause an AI vendor to fail review?

Examples include unclear or unauthorized data use, inability to delete or export records, unacceptable security gaps, inaccessible core workflows, missing teacher controls, misleading learning claims, or refusal to accept enforceable contract terms.