How Schools Can Use AI Without Violating FERPA

Say a fifth-grade teacher wants to try an AI tool that turns a reading passage into a differentiated worksheet, sorted by a class roster's reading levels. FERPA does not forbid that; it puts four specific conditions on how the school hands data to that vendor, and skipping any one of them is what actually creates a violation.

Use a signed contract, minimize individual student accounts, document retention terms in writing, and re-verify the vendor every year, and a school stays inside FERPA's rules while still moving at the pace teachers actually want to move.

Quick Answer: FERPA does not ban AI in the classroom. It regulates how a school discloses education records to any outside vendor, AI included, under the "school official" exception (20 U.S.C. § 1232g; 34 CFR § 99.31(a)(1)). A rollout stays compliant when four conditions hold: a signed contract, direct district control, purpose limitation, and no unauthorized redisclosure. This guide turns that four-part legal test into a six-step rollout sequence a district, or a single teacher piloting a tool, can actually follow.

This is a workflow, not a legal primer. For the full breakdown of what FERPA and COPPA require and why no vendor can be "certified" under either law, see EduGenius's AI, FERPA & COPPA: The Complete School Data-Privacy Guide (2026). What follows is the practical sequence for actually rolling a tool out without tripping over the rules that guide explains.

Where FERPA's Rules Actually Apply Once AI Enters the Classroom

FERPA governs one specific thing: what a school may disclose from a student's education record, and to whom, once that data leaves the classroom for an outside system, according to the U.S. Department of Education's Student Privacy Policy Office. Adding an AI tool does not expand that scope. It just adds a new kind of third party a school has to evaluate the same way it would evaluate a student information system or a gradebook vendor.

The Four Conditions a Vendor Has to Meet

FERPA's "school official" exception, at 34 CFR § 99.31(a)(1), is the mechanism that lets a school share data with a vendor at all without collecting individual parental consent for every disclosure. It only applies when all four conditions are met:

• The vendor performs a service the school would otherwise do itself.
• The school keeps direct control over how the vendor uses and stores the data.
• The vendor uses the data only for the purpose the school authorized.
• The vendor is contractually barred from redisclosing the data without permission.

A public terms-of-service page does not satisfy this test. Only a signed, district-specific agreement does.

Getting this wrong carries real, if slow-moving, consequences. FERPA's enforcement runs through the U.S. Department of Education, which can, after giving a school a chance to fix the problem, terminate its eligibility for federal funding, a penalty the Department has authority to impose but has never actually used. There is also no private right of action; the Supreme Court settled that in Gonzaga University v. Doe, 536 U.S. 273 (2002).

The more immediate risk sits elsewhere. PowerSchool's December 2024 breach, traced to a single compromised support-portal credential, exposed data on more than 62 million students, a reminder that a vendor's contractual promises are only as good as the security practices behind them (TechCrunch, 2025).

What Counts as an Education Record When AI Is Involved

A quiz an AI tool grades and stores against a named student is an education record. The same content, generated and reviewed without ever attaching a student's identity to it, generally is not. That distinction is why a rollout plan should ask, before anything else, whether a given AI workflow needs a student's name attached at all, or whether a teacher can run it against a class roster in the aggregate.

Consider two versions of the same tool. One generates a worksheet from a class profile, grade level, subject, ability range, with no student name ever entered; the output is a teaching material, not a record about a specific child. The other logs each student's individual responses, times, and scores against their name for the teacher to review later; that log is squarely an education record.

Same category of tool, two very different FERPA footprints, depending entirely on how the rollout configures it.

The Six-Step Rollout Sequence for a FERPA-Safe AI Tool

A compliant rollout is a sequence, not a single approval meeting. Skipping straight to "the teacher likes it, let's use it" is exactly how shadow AI use starts. CoSN's 2025 National Student Data Privacy Report, based on a nationally representative survey of 401 district technology leaders, found that most districts still lack basic written privacy policies and staff training specifically covering how new tools get vetted (CoSN, 2025).

Part of the problem is sheer volume: districts have access to an average of nearly 3,000 distinct edtech tools in a given year, according to Instructure's LearnPlatform usage data, far more than any privacy office can vet one at a time without a repeatable sequence (Instructure, 2025). The six steps below are that sequence.

1. Inventory what's already in informal use. Before writing any new policy, find out which AI tools teachers have already adopted on personal or district accounts.
2. Classify each tool by data sensitivity. Does it ever touch an identifiable student's name, work, or performance data, or does it stay generic (lesson plans, rubrics)?
3. Request the DPA before real student data touches it. Treat a vendor's inability to produce a signed agreement as a blocker for anything beyond a no-data pilot.
4. Configure the account structure to minimize student logins. A teacher-mediated workflow is easier to keep inside FERPA's "direct control" requirement than a tool where every student signs up individually.
5. Document the retention and deletion terms in writing, matching whatever the DPA actually says, not what a sales page implies.
6. Set an annual review date, not just a one-time approval, since vendor terms and model providers both change.

The three phases below group the six steps by what's actually at stake in each one, useful as a quick reference once the detailed steps are underway.

Before You Sign Anything

Steps one through three happen before a single piece of real student work touches the tool. Run a low-risk pilot with generic content, a sample lesson plan, a hypothetical worksheet topic, while the DPA moves through legal or a designated student-data-privacy officer. A pilot without a signed DPA should never graduate to real student data, no matter how well it's working in testing.

At Rollout

Steps four and five happen once the contract is signed and the tool goes live with an actual class. This is where account structure decisions get made permanently, and permanent is the right word: migrating a district off individual student accounts after a semester of use is far harder than starting with a teacher-mediated design from day one.

After Rollout

Step six is easy to forget because nothing forces it. Put the review date on the same calendar as budget renewals, so a policy set at rollout does not silently drift out of date as retention defaults and model providers shift underneath the product.

What to Ask the Vendor During Step 3: Training and Subprocessors

Step three, requesting the DPA, is where most of the real vetting happens, and it's also where a generic contract review misses questions specific to AI. Two issues rarely come up in a standard edtech vendor review: whether the model trains on what teachers and students enter, and who else touches that data before it comes back as an answer.

A "we don't train on your data" claim is a promise about the vendor's own layer only, unless the contract says otherwise. Most classroom AI products are not themselves foundation-model builders; a mid-size AI platform is often, in practice, also relying on whatever its underlying model provider, commonly OpenAI, Anthropic, or Google, has separately agreed to. A no-training commitment that doesn't explicitly extend through that full chain has a gap exactly where a rollout most needs it closed.

Build these questions into step three of the sequence, not as an afterthought after the contract is already signed:

• Which foundation model or models actually power this product, named specifically?
• Does the no-training commitment bind that model provider too, in writing, not just the vendor's own marketing language?
• What is the documented data-retention and deletion timeline, and does it match what the FTC's 2025 COPPA amendments now require in writing for any tool touching under-13 users (FTC, 2025)?
• Beyond FERPA and COPPA, does the state your district operates in have its own student-data statute layered on top? The Future of Privacy Forum counts more than 128 state student-privacy laws nationwide that can intersect with a single procurement decision (FPF, 2025).

A vendor that answers all four in writing, before rollout, has just cleared the hardest part of step three.

Teacher-Mediated vs. Student-Direct Access: Two Rollout Patterns Compared

The single biggest decision in any AI rollout is who actually holds the account: the teacher, generating content on behalf of a class, or each student individually. That choice shapes almost every other compliance question that follows.

Neither pattern is automatically compliant; both still need a signed DPA and a documented retention policy. But a teacher-mediated design removes several open questions before they're ever asked.

A content-generation tool built around a class profile, the way EduGenius is, lets a teacher set grade level, subject, and ability range once and generate a differentiated worksheet without any student creating an account at all. That is one practical way a rollout sidesteps most of the direct-collection questions COPPA and FERPA both raise.

When Teacher-Mediated Wins

For worksheet generation, quiz creation, flashcards, and lesson materials, a teacher-mediated workflow is almost always the lower-friction choice. It shrinks the FERPA "direct control" question down to a single admin account per classroom instead of thirty.

When Direct Student Access Might Still Be Necessary

Adaptive tutoring tools, writing-feedback chatbots, and some accessibility supports genuinely need a student typing directly into the system. For those, age-gating, individual consent tracking, and a much stricter DPA review become non-negotiable, not optional.

In that pattern, step three of the rollout sequence carries more weight than usual. A district should expect, and document, a clear answer on exactly what a student's inputs are used for, whether accounts are tied to a real name or a district-issued identifier instead, and what happens to a transcript of the interaction once the school year ends. None of that makes student-direct access off-limits; it just means the paperwork has to work harder to keep the same four-part test satisfied.

A Rollout Scenario: Grade 5 Social Studies AI Worksheets

Say you teach Grade 5 social studies and want to try an AI tool that generates differentiated reading passages about state history, sorted by reading level. Here is how the six-step sequence plays out in that specific case.

• Step 1 (inventory): You check with your building's tech coordinator and learn two other teachers already use the same tool informally, on personal accounts.
• Step 2 (classify): The tool only needs grade level and topic, not student names, so it falls into the lower-sensitivity tier.
• Step 3 (DPA): Your district's technology office requests a DPA before rollout beyond a single-class trial; the vendor provides one within a week.
• Step 4 (account structure): You generate content from a single teacher account tied to a class profile, so no student ever logs in.
• Step 5 (retention): The signed DPA specifies a 90-day retention window with automatic deletion, which your district documents in its approved-tools list.
• Step 6 (review date): The district sets a one-year re-verification reminder, tied to the contract's renewal date.

Nothing about that sequence required a lawyer sitting in the classroom. It required someone asking the right six questions, in order, before the tool touched a real gradebook. The whole process, from first inventory check to a signed DPA landing in the technology office's files, took about three weeks in this scenario, mostly waiting on the vendor's legal team, not on anything the teacher had to redo.

Related Reading

• AI, FERPA & COPPA: The Complete School Data-Privacy Guide (2026)
• Diffit and Student Data Privacy: What Teachers Should Know
• A FERPA Compliance Checklist for AI Tools in Schools
• SOC 2 and AI in Education: A Guide for Administrators
• FERPA-Compliant AI Tools for Teachers: A 2026 Checklist
• SchoolAI vs Khanmigo: Which Is Better for Teachers?