AI Tool Procurement Criteria for K-12 District Technology Committees

AI procurement in K-12 is harder than buying software ever was, because districts no longer buy software, not exactly. A reading app, a gradebook, an assessment platform: all of it can wake up one morning with a new AI feature bolted on, and the data it collects and what it does with that data can change without a new purchase order ever crossing a desk.

A large urban school district found this out the expensive way. The teachers' union responded by demanding real consultation and collective bargaining over any AI tool that comes next, a reasonable ask after watching a flagship purchase collapse that fast.

None of this is an isolated bad call by one district. Lawmakers are moving, just not together, and not at the speed vendors ship product updates.

A few states have built real scaffolding. Most states have done none of this yet. A technology committee in a state with no guidance is on its own, building a vetting process from scratch while the vendor on the other side of the table has done this pitch a hundred times.

Free trials deserve the same scrutiny as six-figure contracts. Vetting a free trial with the same rigor simply delays the inevitable reckoning.

Why Layered Frameworks Beat Flat Checklists

A checklist treats every criterion as equally weighted and independently scored, which lets a vendor's strength in one area paper over a disqualifying weakness in another. Score both on a flat checklist and the strong integration score can make the whole package look fine on paper, when one of those two facts should have ended the conversation before the other was ever discussed.

The procurement journey runs through four stages: needfinding, evaluation, piloting, purchase. The kind of evidence that matters, and how much weight it deserves, shifts at each stage. The 2026 District EdTech Procurement Checklist reflects this directly: it organizes its terms by the phase where each one actually matters, the same logic a layered framework runs on.

Some criteria are binary. Three states passed enforceable vetting laws in a single legislative session this cycle, showing how fast binary pass/fail logic is becoming statutory. A vendor either clears the gate or the rest of the framework never needs to run.

Layer One: Data Privacy and Legal Compliance

Before anyone asks whether a tool works, someone has to confirm the vendor is legally allowed to touch student data, and that the contract protecting that data holds up on its own merits.

FERPA sets the floor. The 2026 procurement checklist puts this at the very start of Phase 1, called Regulatory Foundation, for a plain reason: no school-official relationship means no lawful basis for sharing data, and nothing past that point matters until it's fixed.

COPPA tightened considerably as of April 22, 2026. Documented Verifiable Parental Consent is required. The biometric piece already has real consequences on the ground: five New Mexico districts and one charter school walked away from an AI-powered reading assessment over concerns about collecting students' voice data, which pushed the state to issue guidance letting districts skip the voice-recording feature entirely or swap in a different assessment. Any tool with voice, video, or biometric input needs a specific answer about how the vendor handles the COPPA school-permission exception, where the school consents on a parent's behalf for educational purposes, and whether that exception covers the features the district plans to use.

The Data Privacy Agreement is the legal document that makes any of this enforceable. It is a binding contract, not a pledge the vendor signs in good faith and might honor. Most districts now require a signed DPA that explicitly bans the use of student data to train AI models, and a vendor that won't sign one gets disqualified before the committee spends another minute on the product.

The National Data Privacy Agreement, now in its second version from the Student Data Privacy Consortium, standardizes this across the market. California runs a similar mechanism through its Student Privacy Alliance: a statewide agreement vendors sign alongside local education agencies, plus a searchable database showing who has already signed, so a district does not have to reinvent the negotiation from scratch.

Ask for the sub-processor list too, including cloud hosting, analytics, and whatever AI model sits underneath the product, and make sure each one is bound to the same FERPA obligations as the main vendor, because the model doing the actual work might belong to a company the district has never heard of and whose data practices are invisible in the primary contract. Ask for SOC 2 Type 2 certification, or its equivalent, and confirm it through documentation.

A vendor that does not clear every piece of this layer does not receive partial credit. Allentown School District built its contracts around exactly this logic on data ownership and training prohibitions, and that model works because the gate functions as a real barrier to failing vendors.

Layer Two: Evidence That the Tool Works

Clearing the privacy gate only answers whether a tool is legal to use. It says nothing about whether the tool actually improves learning outcomes. Most AI tools entering K-12 right now carry efficacy claims that no one outside the company has checked, and a committee that skips this layer is making a purchasing decision based entirely on the vendor's own marketing.

Fewer than one in ten AI tools in education have gone through independent validation. Adoption is sprinting ahead of proof, and most of what is being sold runs on vendor-reported studies that the vendor also designed and paid for.

Require third-party, independent validation as a mandatory submission in the RFP itself. Vendor-sponsored research and testimonials from other districts do not count as evidence. If a vendor cannot produce independent validation, the procurement committee should ask whether the vendor is willing to be upfront about that gap, which signals how honest they will be later when something goes wrong.

Outcomes-based contracts give this layer teeth. Maryland's MSDE offers a standardized AI Tools Evaluation Rubric built for exactly this kind of vetting, and it is a usable starting template for any committee that does not have the time or staff to build a rubric from scratch.

Layer Three: Teacher Control and Transparency

A tool can clear the privacy gate and show solid efficacy data and still do damage in the classroom if its design cuts teachers out of the loop or lets students complete assignments without learning the underlying material.

Human-in-the-loop design should be the standard, not the exception. Feedback, generated content, and assessments should all pass through a teacher who can review and adjust before anything reaches a student. The AI's role is to support a teacher's judgment, not substitute for it. Contracts need to spell out explicitly that staff can monitor student interactions with the tool, because leaving that to product defaults creates a gap that surfaces later.

There is a real concern that some tools create an illusion of learning, where a student completes an assignment without understanding the material behind it. That is a design flaw as much as a policy failure, visible in how easy an interface makes it to skip the reasoning process and arrive at an answer.

Teacher input belongs in the procurement process itself, not in a courtesy memo after the decision has been made. The LAUSD situation, where the union ended up demanding formal consultation and bargaining rights over future AI tools, was a predictable result of leaving teachers out of the evaluation. Build teacher review into the pilot phase as a structured step with documented findings that actually shape the purchase decision.

Vendor transparency about its own AI use is also a legitimate question, including how any model underneath the product was trained and on what population of data. Asking whether AI drafted the vendor's RFP response is a way of gauging how honest the vendor plans to be about its own practices for the life of the contract.

Layer Four: Accessibility and Equity Across Populations

A tool built for the average student can still exclude students with disabilities, multilingual learners, and students from groups underrepresented in whatever data trained the underlying model, and those failures tend to become visible only after the tool is already live in classrooms.

A state department of education recommends that AI tools meet IDEA, ADA, and Section 504 standards, and advises bringing special education and multilingual learner support staff into the procurement process from the start as core evaluators rather than secondary sign-offs. Ask vendors directly what populations their training data represents, how the model was tested for bias across different student groups, and what process exists for identifying and correcting a biased output once one appears.

Multilingual learners face a related risk. A tool tested only in English, or whose outputs were never checked for quality in other languages the district actually serves, can produce results that are inconsistent or inaccurate for exactly the students who need the most support. Some districts are also building age-differentiated access into their equity framework directly, which is a safety decision as much as an equity one.

Layer Five: Technical Integration at Scale

A tool can pass every privacy check, show solid evidence, respect teacher judgment, and serve every student population fairly, and still fail completely if it cannot connect to what the district already runs. A separate login with no connection to the LMS and no support for the district's device fleet can kill adoption even when every other criterion is met, and a tool nobody uses delivers no benefit regardless of the research behind it.

Learning Tools Interoperability, the standard protocol maintained by 1EdTech (formerly IMS Global), is what makes integration with platforms like Canvas, Schoology, D2L, and Moodle possible without custom engineering work on the district's end. Require LTI compliance as a stated technical specification in the RFP. A vendor's claim that its proprietary integration works just as well should not substitute for a documented standard, because that claim comes from a vendor in the middle of a sales process.

Confirm single sign-on support as well. A browser extension that only works in one browser creates a real access gap in a district running a mixed fleet of Windows, Mac, and iOS devices.

Layer Six: Contract Terms and Ongoing Oversight

A contract that does not nail down data ownership, use limits, breach notification, exit terms, and performance accountability leaves room for a vendor to change how it operates after signing, and a district with no oversight mechanisms built into the agreement has very little recourse once that happens.

A few contract terms should not be negotiable. The 2026 procurement checklist places all of this in Phase 3, Contract Terms, and Allentown School District's approach to data ownership and training prohibitions is a workable model to borrow from directly.

Maryland's MSDE guidance builds in the same idea: structured evaluation criteria and contractual protections before adoption, plus a standardized rubric for vetting before a pilot gets approved. Committees should build their own post-pilot checkpoint where the contract can still be modified or exited before the tool rolls out district-wide.

Vendor reviews should be a standing responsibility, not a one-time sign-off at contract signing. A certification the vendor held at purchase does not mean much a year later if no one confirms it still applies.

Small and under-resourced districts carry a heavier version of all of this, since verifying compliance and negotiating contract terms takes real staff time that not every district has available. Working the framework in order, gate by gate, prevents a committee from discovering a disqualifying problem only after the money has been spent and the contract has been signed.