The last twelve months moved AI in the classroom from a research topic to an operational one. Districts are procuring AI-tutoring products, AI-personalized-learning features, AI-content generation, AI-grading assistants, and AI-driven adaptive assessments, often several of them, from different vendors, running against overlapping student data. The questions that landed on district compliance officers in the 2026-27 school year are not the questions that landed on them in 2024. This is the framework for answering them.
The vendor conversation has shifted with it. "Are you FERPA-compliant?" is no longer the beginning and end of the discussion. The 2026 version starts with "we understand you have AI features. Walk us through what data reaches which model, under what consent basis, with what human decision authority, and what happens when the model gets something wrong." That is a framework question, not a checkbox question. The vendors that can answer it in a district procurement meeting close the contract. The ones that cannot get filtered out before the pilot.
Why the old framework does not fit
Before generative AI landed in the classroom, the vendor's compliance story rested on three surfaces: data-at-rest encryption, access controls, and a written FERPA-compliance attestation. Those three still matter. They stopped being sufficient the moment AI features started routing student data to third-party models, generating novel content addressed to individual students, and taking pedagogical actions (recommending, grading, tutoring) that used to require a licensed teacher.
The gap the old framework leaves is not about student data protection in the traditional sense. It is about the answers to questions the old framework never asked:
- When your AI feature sends a student's writing sample to a third-party model for grammar coaching, who is receiving that data? Under what contract? For how long?
- If the third-party model provider trains on customer data by default, and a district's students are the customer's users, is student data training the model? Under what parental-consent basis?
- When your AI tutor gives an answer that is wrong, what is the pedagogical record? Who reviews it? What is the audit trail if a parent complains three months later?
- When an AI feature makes an inference about a student (struggling with fractions, disengaged during class, at risk of failing), is that inference an educational record under FERPA? Who has access to it?
None of those questions have obvious answers. The FTC, the Department of Education, individual state agencies, and district legal counsel are all working through the same ambiguity. The vendor that arrives with a written framework beats the vendor that arrives with a policy document.
The six dimensions
The framework has six dimensions. Each one has an answer the vendor needs to be able to give, in writing, before the district procurement conversation moves forward. Districts that have implemented AI review boards (a growing number, driven by state guidance and community pressure) walk vendors through these six in almost this exact order.
1. Data flows
What student data reaches which model, under what mechanism, at what frequency, from which vendor endpoint. This is the map that every subsequent answer sits on top of. The artifact districts want is a table with columns: AI feature, model provider, data category, retention window, purpose of use, and subprocessor status.
Vendors that skip this and jump to "we do not sell student data" are giving the answer to a different question. Districts already assumed you do not sell student data. They want to know where it goes, because that is the thing they cannot verify without you telling them.
2. Consent posture
For each AI feature, on what consent basis is student data routed to the model? Three options are common; each has different scope and different documentation obligations. School-authorization under COPPA's Rule 312.5(c)(6) covers use for educational purposes on the school's direction. It is narrow, does not cover marketing or model-training use, and requires the school (not the parent) to make the call. Direct verifiable parental consent is required whenever the feature falls outside the school-authorization exception (which is more often than most vendors assume). Classroom-use-only carveouts apply in some states and are the most fragile: they typically require you to document exactly what "classroom use" means and what happens if a student uses the feature at home.
A district compliance officer expects each AI feature in your product to have a named consent-basis entry, not a general policy statement. If your product has ten AI features and ten different vendors, they expect ten rows. The general policy sentence is what most vendors ship. The row-per-feature answer is what wins the contract.
3. Training data attestation
Does the model provider use student data to train models? If yes, under what consent basis? If no, is that contractual or default?
This is the question that surprises most edtech vendors, because the answer depends on the AI vendor's default terms and how the edtech vendor's account is configured. Enterprise API endpoints from major model providers typically default to "no training on customer data." Consumer endpoints (the ones a startup wired in a hurry with an individual account) frequently default to "yes." The vendor that assumed the enterprise default without verifying it has an FTC compliance problem waiting to happen, because "we do not use student data for training" was communicated to the district as a fact and was actually a hope.
The district wants a written attestation from the AI vendor covering this exact question. Some AI vendors provide it in their DPA; some require it on request; some refuse. The last category should not be in your product architecture at all.
A common failure pattern in 2026: edtech vendor's marketing page says "we do not use student data to train models." What they mean is "we do not ourselves train models." What the district hears is "no student data flows to any model that gets trained on it." The gap is that the AI subprocessor may or may not train on the data, and the edtech vendor did not check. Districts are now asking about the AI subprocessor specifically because they got burned by this pattern in 2025.
4. Human decision authority
For each AI feature, who has the pedagogical decision authority? The AI, or the teacher? This is where most 2026 AI-in-classroom disputes actually land. A district is generally comfortable with AI features that propose (a hint, a suggested next problem, a draft summary) and require the teacher to accept, modify, or reject. They are much less comfortable with AI features that decide (auto-grade, auto-route to intervention, auto-flag a student as struggling) without a human review step.
The answer the district wants: which of your AI features are advisory (teacher decides), which are automated (AI decides), and for the automated ones, what is the override mechanism and how often is it used? The vendor that ships "AI decides" features by default and offers "you can turn it off" as a settings toggle has the answer backwards. Advisory-by-default with an explicit opt-in for automation is the posture that survives district review.
This maps onto a broader agent-governance discipline: the same pattern we apply to autonomous operations on our own platform. The runtime asks the actor to propose, and a computable check outside the actor decides whether to allow. The vendor that has thought about this in their product architecture is orders of magnitude further along than the vendor that has thought about it only in their marketing copy.
5. Auditability
When your AI feature generates output for a student (a hint, a graded response, a personalized lesson recommendation, a summary of a written work), is there a record of what the AI produced, why, and when? Can a district compliance officer or a parent request that record and receive it in a defensible format?
The district position on this has hardened through 2025-26. Educational-record obligations under FERPA arguably attach to AI-generated pedagogical outputs, meaning the auditability question is not "would we like to have this?" but "are we required to have this?" A vendor that cannot produce the AI-output record on request is exposed on the same terms as a vendor that cannot produce a grade record on request.
What "auditability" means in practice: per-student, per-AI-feature output logs with timestamps, input snapshots, model identifiers, and the reasoning surface (if any) the model produced. Retention aligned with the district's own retention policy for that data category. Retrievable through a documented workflow, not a customer-service Slack request.
6. Incident response
When an AI feature produces harm (a factually wrong answer taught as fact, a hallucinated summary that misrepresents a student's work, an inappropriate response to a student prompt, a personalized-learning recommendation that routes a student wrong), what is the vendor's incident-response playbook, and who owns the district communication?
This is the newest of the six dimensions and the one most vendors have not thought through. A general cybersecurity incident-response plan does not cover AI-output incidents; they are a different failure mode with different remediation, different communication requirements, and different regulatory reporting considerations. Districts that have suffered an AI-output incident in the 2025-26 school year universally report that the vendor's response was ad-hoc, delayed, and defensive. The vendors that came prepared with a written AI-incident-response workflow moved from vendor to trusted partner in a single incident cycle.
Districts that have adopted AI review boards (California SDPC, several state consortiums, most large urban districts) increasingly use a scoring rubric across these six dimensions. The vendor that scores 3/6 with a written answer beats the vendor that scores 6/6 with a marketing claim. The scoring is on the presence and quality of the artifact, not the aspirational answer.
A worked example
Consider a mid-sized edtech vendor with three AI features that shipped in the 2026 product cycle: an AI-tutoring assistant, an AI-generated practice-problem generator, and an AI-powered writing-feedback tool. The vendor's original compliance posture was a single sentence in the DPA: "The Company may use artificial-intelligence-based features to enhance the student learning experience. Student data is protected under our standard FERPA and COPPA compliance." That sentence was fine in 2023. It fails the 2026 district review board on all six dimensions.
The framework-based rewrite:
The rewrite is 400 words instead of a single sentence. It is also the answer that gets the district to yes.
The operational discipline
The vendors that will win the 2026-27 school year are not the ones with the best AI features. They are the ones with the framework answer for every AI feature they ship, updated every time the feature changes, retrievable on demand for any district that asks. This is not a marketing problem. It is an operational discipline, and it requires the same thing every operational discipline requires: a system that maintains the answers as the product changes, an owner who verifies them, and a documented workflow for when they need to be produced.
The operational muscle looks like this. Every new AI feature ships with a completed six-dimension entry before it goes to production. Every model-vendor change triggers a review of the data-flow and training-data rows. Every quarter, a rotation of features gets a re-verification pass (the same discipline any evidence-collection program runs). District questionnaire responses are generated from the maintained framework, not authored fresh from memory. The framework is versioned; district legal counsel can request the version that applied when their contract was signed.
None of this requires new tooling that does not exist. It requires the discipline to treat AI features as a distinct compliance surface with its own maintenance cycle, not as a footnote inside the general vendor risk file. The vendors that have this discipline are visibly different in a district review; the ones that do not are equally visible.
What districts are doing on their side
The complementary shift on the district side is the emergence of the AI review board: a cross-functional group (typically CIO, legal counsel, curriculum director, parent-community representative) that reviews AI features in vendor products before approval. Not every district has one; the districts that do drive the standards the rest of the market eventually adopts. The vendor that fits the AI-review-board process at Chicago, Los Angeles Unified, Fairfax County, Miami-Dade fits everyone downstream.
The AI-review-board questions are the six above, plus two operational questions that show up specifically in the district-side review: what is your process for notifying the district when you add or change an AI feature, and what is the sunset process for an AI feature you discontinue (do the AI-generated records get exported to the district, deleted, or archived)? These map onto the DPA amendment lifecycle any competent vendor already runs; they just get more granular for AI features.
Beyond the six dimensions above, expect: (1) a written process for notifying the district when you add or change an AI feature (many DPAs now require 30-day advance notice for material changes to AI features specifically); (2) a documented sunset process for AI features you discontinue, including what happens to the AI-generated records. Both are DPA-amendment-adjacent, both are increasingly non-negotiable.
Where FERPA and COPPA fit inside this
The framework does not replace FERPA or COPPA compliance. It sits on top of them and answers the questions those two frameworks were not written to answer. FERPA still governs educational records (and AI-generated pedagogical outputs likely qualify). COPPA still governs under-13 data handling (and AI features touching under-13 users still trigger verifiable parental consent obligations). State privacy laws still apply on their own terms.
What changes is the vendor's obligation to demonstrate compliance with the underlying frameworks in the context of individual AI features. A general FERPA-compliance statement covers general educational records. It does not answer whether the AI feature's output logs are FERPA-covered records with the associated access, correction, and disclosure obligations. A general COPPA-compliance statement covers under-13 data handling. It does not answer whether the AI subprocessor's training-data usage is a COPPA-disclosable subprocessor relationship.
The framework is what maps the specific to the general. Districts increasingly ask for it because their own counsel cannot map it in the vendor's absence. If you can produce the map, you save the district's counsel a week of work per feature, and that saves your sales cycle a month.
For the underlying frameworks themselves: the FERPA compliance checklist for edtech startups covers the FERPA-specific dimensions, and the COPPA compliance checklist for edtech (under-13) covers the COPPA-specific ones. Both were refreshed for the 2026-27 school year with the AI-feature considerations layered in.
Where this leaves the industry
The gap between the vendors that have this framework and the vendors that do not is going to widen. Districts are consolidating vendors as their AI-review boards mature, and the consolidation almost always eliminates the vendor that could not produce a framework answer. The market share moves toward the vendors who invested in the operational discipline early, not toward the vendors with the biggest AI feature set or the loudest AI marketing.
The other direction the industry is moving: AI-specific insurance products (AI security riders, AI sublimits on cyber policies) are pricing this exact question. Vendors that can answer the six dimensions coherently price out better than vendors that cannot, on the same premium logic that carriers are already applying to non-AI cyber posture. The compliance framework and the insurance framework are converging on the same evidence, which means investing in either one buys you both.
The vendors that will look back at the 2026-27 school year as an inflection point are the ones that treated it as an operational discipline conversation, not a marketing message conversation. The framework above is the working outline of the discipline. Every district that matters will eventually ask for it. The ones asking now are the tell.
How vCISO Lite runs this in production for EdTech teams
The six dimensions above are the reference. Running them across a real product with real district customers is a platform question. vCISO Lite tracks each AI subprocessor as a first-class vendor in the vendor-risk register, records the consent basis (school-authorization vs. direct parental consent vs. training-data opt-out) per feature, and produces the district-questionnaire responses that answer the six-dimension read without a founder having to reconstruct it at midnight before a call. See the EdTech industry page for how it fits together across the buying cycle.
The relevant reference material for the underlying frameworks: the FERPA compliance guide and the COPPA compliance guide, both refreshed for the 2026-27 school year with a seven-item September action list. If you're heading into a district procurement cycle in the next 30-60 days, walk both action lists alongside the six-dimension framework above — the districts asking the compliance questions are the districts asking the AI-governance questions, and the answers travel together.