AI Procurement for Schools: Vendor Review Guide

Document:

• the problem, affected users, frequency, and current owner
• how the work is handled today
• the time, cost, delay, error, access barrier, or quality problem to improve
• reasonable non-AI alternatives
• the smallest use case that could produce useful evidence
• what would count as success, failure, or no meaningful change

“Save teachers time” is not a sufficient objective. “Reduce the median time participating teachers spend converting an approved unit outline into a first-draft lesson structure, without reducing rubric scores or accessibility checks” is testable.

The baseline protects the district from buying a product whose activity is easy to count but whose value is not. Logins, prompts, and generated documents measure use. They do not prove learning, service quality, time savings, trust, or operational improvement.

R — Require rights, data, and access terms

Map the complete data path before the vendor receives real district information. Include prompts, uploads, student or staff records, generated outputs, feedback, logs, identifiers, analytics, model-training uses, integrations, backups, subprocessors, and support access.

The U.S. Department of Education's Privacy Technical Assistance Center provides guidance on the responsibilities of third-party service providers under FERPA. District counsel and privacy leaders should determine how applicable requirements apply to the facts of the proposed service; a vendor's generic “FERPA compliant” statement is not that determination.

Put the district's requirements in the agreement. At minimum, resolve:

• permitted purpose and prohibited secondary uses
• district ownership and control of inputs, outputs, records, and derived data
• whether district data may train, tune, evaluate, or improve a model
• retention, deletion, backup, and legal-hold behavior
• subprocessors, hosting locations, and advance notice of material changes
• role-based access, multifactor authentication, audit logs, encryption, and support access
• incident notice, investigation support, evidence preservation, and corrective action
• accessibility conformance and district testing rights
• data export, deletion verification, transition support, and contract exit

Also define who in the district may connect a data source or enable a feature. A good contract can be undermined if any account administrator can turn on a new model, integration, or student-facing capability without review.

Use the district's AI accessibility review and AI security evaluation as companion gates rather than burying those questions in a general vendor questionnaire.

O — Obtain evidence for the intended use

Ask the vendor to substantiate each material claim in the context where the district will use the tool.

For quality and performance claims, request:

• the exact task, dataset, population, product version, and conditions tested
• the comparison or baseline used
• raw counts and denominators behind percentages
• known failure modes and performance limits
• results across relevant grades, languages, disabilities, devices, and user conditions
• independent evaluation where the consequence warrants it
• evidence that the current product—not an earlier model or custom demonstration—produced the result

For claimed time savings, ask what work was included. A tool may reduce drafting time while increasing verification, correction, formatting, training, or support time. Measure the whole workflow.

For student outcomes, distinguish a product study from a model benchmark, customer story, satisfaction survey, or research about a different intervention. If the vendor has no outcome evidence, the district can still consider a bounded low-risk pilot, but it should describe the purchase honestly as an evaluation rather than an evidence-backed scale decision.

NIST's AI Risk Management Framework Core calls for performance or assurance criteria to be measured in conditions similar to deployment, with privacy, fairness, security, safety, transparency, and accountability risks examined and documented. The framework is voluntary, but its govern-map-measure-manage structure gives districts a strong way to organize vendor evidence and local validation.

V — Verify the real workflow

Do not let the vendor control the entire demonstration. Give every finalist the same district-authored scenarios, source materials, user roles, and time limits.

A useful demonstration script includes:

1. A normal task using approved information.
2. An incomplete or ambiguous request that should trigger caution.
3. An incorrect premise that the system should not repeat as fact.
4. Sensitive information that should be blocked, minimized, or handled under a defined rule.
5. A user who attempts an action outside the approved role.
6. An accessibility or language scenario representative of the district.
7. A model error that a reviewer must find and correct.
8. A service interruption, disabled integration, or unavailable reviewer.
9. A request to retrieve, export, correct, or delete information.
10. A material model or feature update that requires change review.

Observe the people as well as the product. Record how long review takes, what expertise is needed, where users over-trust the output, which exceptions require support, and whether the non-AI fallback still works.

Include the actual owners: technology, privacy, accessibility, curriculum or program leadership, business operations, communications, school-based users, and legal review as appropriate. For student-facing or community-visible uses, include structured input from affected people before scale. A procurement committee should not have to guess how the workflow feels to the people expected to use or experience it.

E — Establish monitoring, renewal, and exit

The contract should turn promises into observable obligations.

Create a schedule for monitoring:

• performance and error measures tied to the approved use
• human overrides, corrections, complaints, and appeals
• usage by role, school, and approved purpose
• accessibility, privacy, security, and inappropriate-use incidents
• model, feature, subprocessor, and terms-of-service changes
• total licensing, integration, training, support, and review cost
• effect on the original baseline and district objective

Require advance notice of material changes and give the district the right to retest, restrict, pause, or terminate affected functions. A vendor should not be able to transform the risk profile of an approved product through an automatic update while the district remains locked into the original decision.

Set the renewal evidence before signing. Renewal should not occur because the budget line already exists or staff have become accustomed to the tool. The owner should show whether the defined problem improved, which risks emerged, what the complete cost became, and whether a lower-risk or lower-cost alternative now exists.

Finally, test the exit. Confirm that the district can export needed records in a usable format, remove accounts and integrations, verify deletion, preserve required documentation, communicate the change, and continue the underlying service without the AI feature.

Put pass/fail requirements before scored preferences

Do not average away a critical failure. Separate mandatory gates from scored criteria.

Pass/fail gates

A proposal should not advance when the district cannot:

• identify a lawful and policy-aligned purpose
• understand the data flow and vendor chain
• prohibit unacceptable data or model-training uses
• provide required accessibility and appropriate access
• maintain meaningful human authority for the consequence tier
• validate a material performance claim
• obtain incident, change-control, audit, and exit terms proportionate to risk
• operate a safe fallback

Scored criteria

After proposals pass the gates, score educational fit, workflow quality, evidence strength, interoperability, usability, implementation support, total cost, and vendor responsiveness. Weight the criteria to the use case rather than using one generic technology rubric for every AI purchase.

This structure prevents a strong interface or low price from compensating for an unacceptable data term or an unsupported consequential use.

Run a 30-day pre-award validation

For a material purchase, use a short, bounded validation before final commitment.

Days 1–7: define and document

Complete the five-field use statement, consequence tier, baseline, success measures, data map, review roles, test scenarios, and pass/fail gates. Identify which terms must be contractual.

Days 8–15: test finalists

Run the same district-authored demonstration with each finalist. Record outputs, errors, review time, accessibility results, blocked actions, support needs, and unanswered questions. Do not use production student data merely to make the demonstration realistic.

Days 16–23: validate operations and terms

Confirm integrations, identity and access controls, logging, incident duties, subprocessor disclosures, change notice, pricing, training, support, data return, and deletion. Resolve exceptions in writing.

Days 24–30: make the decision visible

Produce a one-page decision record showing the problem, alternatives, tier, evidence, test results, required controls, total cost, owners, unresolved risks, public-input needs, monitoring schedule, stop conditions, and exit path. Approve, revise, pilot, defer, or reject the proposal.

If the district proceeds with a pilot, connect the decision record to its low-risk AI pilot process. A pilot should answer specific uncertainties, not delay decisions while normal use expands informally.

Questions for the school board decision brief

The board does not need every technical answer in the meeting packet. It does need the logic of the decision.

Include:

• What district problem is being addressed?
• What non-AI alternatives were considered?
• Who will use the tool, with what data, for what task?
• What may happen after the tool produces an output?
• What evidence supports the proposed use, and what remains uncertain?
• What human review, privacy, accessibility, security, and recourse controls are required?
• What is the full first-year and renewal cost?
• How will families, staff, and students be informed or engaged?
• What measures determine continuation, expansion, pause, or exit?
• Who is accountable after the contract is signed?

This brief complements a district's AI acceptable use policy. Policy establishes boundaries. Procurement translates those boundaries into product requirements, evidence, contract terms, and operating responsibilities.

Where SchoolAmplified fits

AI procurement succeeds only when approved knowledge survives the purchasing process. Staff need to find the current permitted-use statement, review steps, vendor limitations, escalation path, training guidance, and family-facing explanation after the committee has disbanded and the tool is in daily use.

District Assist can help authorized staff work from a district-controlled knowledge layer for approved guidance and recurring questions. SchoolAmplified is not a procurement authority, legal reviewer, or substitute for independent product testing. Its role is to help districts keep trusted knowledge current, make implementation communication clearer, preserve human oversight, and carry approved operating rules consistently across schools.

That matters when a principal asks whether a new feature is permitted, a teacher needs the current review checklist, a family asks what information the tool uses, or a vendor update changes the workflow. The district should be able to answer from the decision record—not reconstruct the answer from emails and meeting notes.

SchoolAmplified's trust approach and implementation model can help districts turn procurement requirements into visible operating practice. The goal is not faster purchasing. It is a purchase the district can explain, govern, measure, and reverse when the evidence changes.

AI procurement checklist for schools

Before signing or renewing, confirm that the district has:

• defined one use case with users, inputs, task, reviewer, and consequence
• documented the current baseline and non-AI alternatives
• assigned a consequence tier and review owner
• mapped data, integrations, subprocessors, access, retention, and deletion
• separated pass/fail requirements from scored preferences
• required evidence for the exact product version and intended setting
• tested district-authored normal, failure, accessibility, and misuse scenarios
• documented meaningful human authority and a non-AI fallback
• put purpose, data, security, accessibility, incident, and change controls in writing
• calculated total cost, including training, review, integration, and exit
• defined monitoring measures, renewal evidence, and stop conditions
• secured usable data return, deletion verification, and transition support
• prepared a concise decision record and stakeholder communication plan

If several of these answers remain “we will decide after purchase,” the district is not buying a finished capability. It is accepting unresolved implementation risk. Good AI procurement makes that uncertainty visible before the contract makes it expensive.