FERPA-Compliant AI Tools for Teachers: A 2026 Checklist

There is no such thing as a "FERPA-compliant AI tool" in the way there's a UL-certified appliance; FERPA (20 U.S.C. § 1232g) regulates schools, not vendors, so no product earns a compliance seal on its own. What a teacher or district can do is run any AI tool through a consistent checklist of vendor questions, on data training, contracts, retention, admin controls, and age-gating, before trusting it with student information.

Quick Answer: No AI vendor is inherently "FERPA compliant." Instead, vet any AI tool with a checklist: does it train on your data by default, is a signed data privacy agreement (DPA) available, is there a district admin console, what's the retention and deletion policy, and does it age-gate users under 13. A tool that clears all five gives your district the contractual foundation FERPA actually requires.

This checklist is the practical companion to EduGenius's AI, FERPA & COPPA: The Complete School Data-Privacy Guide (2026). Rather than evaluating one named vendor, as our companion articles on ChatGPT and Claude do, this piece gives you the reusable questions to ask any AI tool, general-purpose or education-built, before it touches a classroom.

---

The 2026 FERPA AI Vendor Checklist, at a Glance

Print this table, or paste it into your procurement template. Every item below maps to something FERPA, COPPA, or basic data-governance practice actually requires; none of them are arbitrary.

A tool that passes items 1 through 5 has cleared the practical minimum. Items 6 through 8 are what a thorough legal review adds on top, mapping directly to FERPA's four-part "school official" test (34 CFR § 99.31(a)(1)): legitimate purpose, direct control, purpose limitation, and no redisclosure.

---

What Each Checklist Question Actually Means

1 and 2: Training defaults and the data privacy agreement

A vendor's default training setting tells you who benefits from your data, and a signed DPA tells you whether that default is legally binding on them. These two questions go together because a favorable default without a contract is just a promise, and a contract without knowing the default doesn't tell you what you're contracting for.

Ask specifically:

• Is training on or off by default for our account type (not just "in general")?
• Can our district turn training off centrally, or does it depend on each individual user's settings?
• Will you sign a DPA, or only offer standard consumer terms of service?
• Does the DPA reference our specific product tier, or a broader agreement that might not cover every feature we use?

3: The admin console, and why "everyone has their own login" is a red flag

A district that can't see or control who has an account isn't demonstrating "direct control," which is one of FERPA's four required conditions. A tool where each teacher independently signs up with a personal email, no domain verification, no central roster, makes it functionally impossible for a district to prove it controls data access if ever asked.

Look for:

• Single sign-on (SSO) tied to district identity systems.
• A roster or provisioning system an administrator manages, not each teacher individually.
• Visibility into which accounts exist and what they've accessed.

4: Retention and deletion, the clause everyone skips

"We don't use your data to train models" answers one question and leaves several others open: how long is it kept, who can access it internally, and what happens when the contract ends. A checklist that stops at the training question is only half a checklist.

A complete retention answer specifies:

1. A defined retention window (30 days, 12 months, until contract termination, etc.), not "as long as necessary."
2. What happens to data when a student leaves the district or a contract lapses.
3. Whether deletion is automatic or requires the district to request it.

5: Age-gating and the COPPA overlay

COPPA (the Children's Online Privacy Protection Act, enforced by the FTC under 16 CFR Part 312) is a separate law from FERPA, and it specifically covers any online service that collects personal information from children under 13. A tool can clear every FERPA-relevant checkbox and still create a COPPA problem if young students interact with it directly, unsupervised, without proper consent mechanisms.

The FTC's COPPA Rule requires "verifiable parental consent" before collecting personal information from a child under 13, and a set of amended rules that took effect June 23, 2025 expanded the accepted verification methods. In a school setting, the school itself can sometimes provide that consent on behalf of parents for a legitimate educational purpose, but only if the vendor's data use is genuinely limited to that purpose, which loops back to checklist items 1, 2, and 6.

For tools aimed at younger grades, the safest pattern is one where the teacher, not the individual student, is the account holder and the one interacting with the AI directly, generating materials the teacher then distributes. That structure sidesteps most of COPPA's direct-collection triggers entirely.

6 through 8: The three items a legal review adds on top

Items 6, 7, and 8 are less visible in a vendor's marketing than the training and retention questions, but they map directly onto FERPA's actual regulatory text, so a district's legal or compliance office should push for specific written answers on all three before a contract is signed, not just a verbal assurance from a sales call.

• Purpose limitation (item 6). FERPA's school-official exception only holds if the vendor uses student data solely to provide the contracted service, not for its own separate business goals like building a general-purpose analytics product. Ask the vendor to name, specifically, every purpose the data can be used for under the contract.
• No unauthorized redisclosure (item 7). A vendor might not train on your data itself, yet still share it with subprocessors, analytics partners, or other third parties unless the contract explicitly forbids it. Ask for a list of subprocessors and confirm the contract requires the same protections to flow down to them.
• Breach notification (item 8). FERPA doesn't set a specific breach-notification timeline the way some state laws do, but a defined contractual window (commonly somewhere between 24 and 72 hours in comparable enterprise agreements) gives a district a concrete standard to hold the vendor to, rather than an open-ended "as soon as reasonably possible."

A vendor that resists putting specific answers to these three items in writing, while still offering reassuring language elsewhere in the contract, is worth a second look before signing.

---

Red Flags That Mean "Walk Away"

Some answers should stop a pilot before it starts, regardless of how good the tool's classroom features look:

• "We don't really have a written DPA, but our terms of service cover it." Consumer terms of service are not the contract FERPA's school-official exception requires; they're written to protect the vendor in a lawsuit, not to grant your district the specific controls FERPA needs.
• No answer, or a vague answer, on data retention. If a vendor can't tell you a specific retention window, they likely haven't built the internal controls to enforce one, which means they can't credibly promise deletion either.
• Data use rights broad enough to cover "product improvement" without definition. That phrase can quietly include model training, analytics sold to third parties, or marketing use, depending on how loosely it's written.
• No way for the district to see or manage individual accounts. If IT can't answer "who currently has access," that's a direct-control gap that undermines any FERPA claim the vendor makes.
• Under-13 users can create accounts with no adult involvement at all. Even a checkbox that says "I am over 13" isn't verifiable parental consent under COPPA; it's just a checkbox.
• The vendor won't name its subprocessors. If a company can't or won't tell you which other companies touch the data downstream, item 7 on the checklist (no unauthorized redisclosure) can't actually be verified, no matter what the contract's headline language promises.

None of these red flags mean a vendor is acting in bad faith. Plenty of AI companies are still building out the institutional-grade contracting infrastructure that FERPA-serious districts need, and a vendor that can't answer today may well be able to in six months. The point of the checklist is simply to make "not yet" visible, rather than letting an enthusiastic pilot quietly become permanent district infrastructure before those gaps are closed.

---

Applying the Checklist: General-Purpose Chatbots vs. Education-Built Platforms

The checklist above applies identically to every category of AI tool, but the starting point differs quite a bit between a general-purpose chatbot repurposed for classrooms and a platform built for education from the ground up.

Neither column is automatically "compliant" without checking the actual checklist items above; the table just describes where each category tends to start. A general-purpose chatbot's institutional tier, like the ones covered in our reviews of ChatGPT and Claude, can clear every item on the checklist. So can a platform built for classrooms. The checklist, not the category, is what tells you which specific product does.

Purpose-built classroom tools tend to have an easier path through items 3 and 5 in particular, since a bounded, teacher-managed workflow is closer to how they're designed to work by default rather than a feature bolted on afterward. EduGenius, for example, is structured around class profiles that a teacher sets up (grade level, subject, ability range) and uses to generate quizzes, worksheets, and other materials, which means students generally don't need individual accounts or direct model access at all, a structural difference worth weighing alongside the checklist rather than a claim of compliance in itself.

For a deeper look at tools specifically chosen because they avoid training on student data as a design principle, see AI Tools That Don't Train on Student Data, and for how two K-12-native platforms stack up against each other on these same dimensions, see SchoolAI vs Khanmigo: Which Is Better for Teachers?

---

How to Run This Checklist During a Pilot

1. Send the checklist to the vendor in writing before the pilot, not after. A vendor's sales team can usually answer these eight questions directly; if they can't, that delay is itself informative.
2. Get the DPA reviewed by legal or your student-data-privacy officer before any student data touches the tool, even during a "just testing it out" phase.
3. Limit the pilot's data scope on purpose. Start with non-identifiable content (generic lesson plans, not student work) until the contract is fully signed and admin controls are configured.
4. Document the answers to all eight checklist items in one place, so the next department considering the same tool, or the next audit, doesn't have to redo the research.
5. Set a calendar reminder to re-run the checklist annually. Vendor terms change; a tool that passed in 2025 may have altered its training default or retention window since, exactly as happened with more than one major AI vendor in that same year.
6. Assign one owner for the checklist itself. Without a named person, usually someone in IT, legal, or a dedicated student-data-privacy role, the checklist tends to get run informally by whichever department is most excited about a new tool, and the paper trail disappears when that person moves on.

A pilot that follows this sequence produces something more valuable than a green light: a documented, repeatable record that any future auditor, school board member, or concerned parent can be shown directly, rather than a verbal assurance that "we looked into it."

---