A curriculum director at a K-8 school told me recently that her staff had approved three AI tools in the past year. The process each time: a teacher presented the tool at a staff meeting, colleagues liked the demo, and it went on the approved list. No privacy review. No vendor questions. No DPA.
She wasn't describing negligence. She was describing what most K-8 schools do. The traditional edtech vetting process — check the price, confirm it runs on your devices, make sure kids can log in — was never designed for AI tools. And AI tools are fundamentally different from a reading app or a quiz platform.
The difference is this: a traditional edtech tool uses your data to deliver its service. An AI tool may use your data to improve itself. Student work, queries, and outputs becoming training data is not a theoretical concern — it is a documented practice at multiple consumer AI platforms, and the default setting is often opt-in rather than opt-out. Schools that don't ask the question don't know which side of that line they're on.
"The traditional edtech vetting process was never designed for AI tools. AI tools are fundamentally different — and the questions you need to ask are too."
Here are the seven questions your privacy review must ask before any AI tool is approved for use with student data. For each one: why it matters, what a good answer looks like, and what disqualifies a tool immediately.
Do not accept "we take privacy seriously" or a link to a 40-page privacy policy. Ask the vendor for a written data map: what categories of data are collected, when, and for what purpose. If they cannot produce one, that is your answer.
The categories to ask about explicitly: student names, email addresses, age or grade level, school name, assignment content, query history, usage patterns, device identifiers, and any inferred attributes. Each one is a potential compliance exposure under FERPA and, for students under 13, COPPA.
A written data inventory listing specific categories, collection triggers, and stated purposes — provided in response to your direct question.
A referral to the general privacy policy with no vendor-specific response. Silence is also disqualifying.
This is the question most schools forget to ask — and the most consequential one. Many free and freemium AI tools use input data to improve their underlying models. That means student work, questions, and outputs may become part of a training dataset. This is a FERPA violation if student PII is involved, and a COPPA issue for under-13 students.
The answer must be "no" in writing before the tool can be approved. If the vendor says "yes, but you can opt out," your next question is: what is the opt-out process, does it apply retroactively, and does opting out affect tool functionality? Get every answer in writing.
"No, student data entered into our platform is never used to train AI models." In writing, on vendor letterhead or in the DPA.
"By default, yes — but you can opt out." Any ambiguity here is disqualifying until fully resolved in writing.
A Data Processing Agreement is the legal mechanism that makes a vendor a "school official" under FERPA — giving them legitimate access to student education records under defined, limited conditions. Without a signed DPA, any sharing of student data with that vendor is an unauthorized disclosure under federal law, regardless of how the tool is being used.
This is not negotiable and not optional. If a vendor will not sign a DPA, they cannot be approved for any use involving student personally identifiable information. Full stop. Some vendors — particularly consumer-grade tools not designed for K-12 — will decline. That is your answer.
"Yes, we have a standard DPA for K-12 schools" or "Yes, we will review and sign your school's DPA."
"We don't sign DPAs" or "Our terms of service cover this." Neither is a substitute for a signed DPA.
Data stored indefinitely is data at risk indefinitely. The FTC's 2025 COPPA update — fully effective April 2026 — specifically strengthened limits on data retention, requiring that covered services retain personal information from children only as long as reasonably necessary. Schools should ask for written retention and deletion terms before approving any tool.
Ask specifically: where are servers located, what is the retention period for student data, and what is the deletion process when a school ends its contract or a student leaves?
Specific retention timeframes in writing, a documented deletion process, and confirmation of server location.
"We retain data as long as your account is active" with no further specificity, or no written answer at all.
COPPA applies to online services that collect personal information from children under 13. It requires verifiable parental consent — or a school operator exception — before any personal data is collected. The FTC's 2025 update expanded the definition of personal information and tightened consent requirements, particularly around third-party data sharing.
Many AI tools with chat interfaces, content generation features, or usage analytics are covered under COPPA for elementary-age students. Ask the vendor whether the tool is designed for COPPA compliance, what consent mechanism they use, and whether they have received any COPPA-related enforcement actions. Get it in writing.
Written confirmation of COPPA compliance, the specific consent mechanism used, and a clear statement about third-party data sharing.
"Our tool is intended for users 13 and older" — without a plan for how your K-5 students are excluded or protected.
AI tools are not static. Vendors push feature updates and introduce new AI functionality — sometimes without prominent notice. A tool you approved for lesson planning in September may have a student-facing AI chatbot added in November. If you cannot control which features are active in your environment, you are approving the tool's future state as well as its current one.
Admin-level feature controls give you the ability to pilot carefully, expand deliberately, and respond when something changes that you haven't reviewed. If a vendor cannot offer feature-level control, you are accepting all-or-nothing adoption — rarely the right posture for a K-8 school in year one.
An admin console with documented feature controls, or a written process for disabling specific AI features on request.
"All features are included and cannot be individually disabled." Proceed with heightened caution or not at all.
AI tools can produce biased, inaccurate, or developmentally inappropriate content. A tool that confidently generates a wrong answer looks identical to one that generates a correct one. For K-8 students — particularly grades 3-5 who are developing critical thinking skills — this is a real instructional risk, not just an abstract concern.
The EDSAFE AI Alliance's SAFE framework organizes AI governance around Safety, Accountability, Fairness and Transparency, and Efficacy. Ask vendors whether they have conducted a bias evaluation, what their process is for flagging inaccurate outputs, and whether the tool has been tested with K-8 student populations. A vendor who cannot answer these questions has not done the work.
Documentation of a bias evaluation process, a content safety framework, and evidence of K-12 testing. Willingness to discuss specifics.
"Our AI is powered by [large model name]" with no additional safety or bias evaluation information specific to their implementation.
The Baseline Rule to Post Before Any Tool Is Approved
The seven questions above apply to any tool under formal review. But you need a floor in place even before a single tool has been vetted — a rule that applies immediately, to every staff member, regardless of where the approval process stands.
"Staff and students may not enter student names, contact information, grades, assessment data, discipline records, IEP or 504 information, health information, family information, photos, voice recordings, or other personally identifiable student information into any AI tool that has not been reviewed and approved by the school."
That rule does not require a completed policy. It can go out in a staff email today. It is enforceable immediately. And it covers the most common privacy exposure — a teacher entering student information into a consumer AI tool without realizing the implications — before your formal vetting process is complete.
One Tool at a Time
The instinct when building an approved-tool list is to evaluate everything at once. Resist it. Evaluate one tool for one specific use case, get the DPA signed, document the answers to these seven questions, and approve it for that use. Then do the next one.
A short approved-tool list with documented answers is a defensible governance record. A long list assembled quickly, without documentation, is a liability. School boards, parents, and attorneys will ask different questions depending on which one you have.
The work of building that record is not glamorous. But it is the work that turns "we use AI responsibly" from a statement of intention into a statement of fact.
The vendor vetting checklist, already built and ready to send.
The 90-Day AI Launch Plan includes a one-page vendor review form with all seven questions formatted for vendor response — plus the prohibited-data rule, staff and student acceptable-use policies, family communication template, and the full week-by-week implementation sequence. All editable. All ready for your school's name.
- Vendor review form — 7 questions, formatted for vendor response
- Prohibited-data rule — one sentence, enforceable immediately
- Approved-tool list template — with DPA status tracking
- Staff and student AUP — editable by grade band
- Family privacy communication — plain English, no legal jargon
- 90-day week-by-week roadmap with decision gates