AI, FERPA & COPPA: The Complete School Data-Privacy Guide (2026)
No AI vendor can be "FERPA certified" or "COPPA certified," because neither law offers a certificate for software companies to earn. FERPA (20 U.S.C. § 1232g) makes schools and districts the legally responsible party for student education records. COPPA, enforced by the Federal Trade Commission under 16 CFR Part 312, regulates how online services collect data from children under 13 and requires verifiable parental consent. A vendor claiming either compliance is either self-describing its own practices or has signed a Data Processing Agreement (DPA) with a district, not holding a government-issued seal.
Quick Answer: FERPA governs what schools may disclose from a student's education record and to whom; it binds the school, not the software vendor. COPPA governs what any online service, AI tools included, may collect from children under 13 and requires verifiable parental consent, usually satisfied in schools through the district acting as the parent's agent for a strictly educational purpose. Neither law has a vendor-certification program. A district's real protection comes from a signed DPA, a clear data-retention policy, and knowing exactly what an AI tool's underlying model provider does with student input, not from a badge on a pricing page.
That distinction, certification versus contract, is the single most important fact in this guide, and it is worth sitting with before anything else. A remarkable amount of AI-in-education marketing leans on the word "compliant" as if it were a stamp a product either has or doesn't. It isn't. This guide walks through what FERPA and COPPA actually require, how AI tools specifically complicate both laws, a practical checklist for evaluating a new AI product, and where EduGenius's own architecture fits into that picture.
The State of AI and Student Data Privacy in Schools Today
Classroom AI adoption has outpaced most districts' privacy paperwork, and the data shows both sides of that gap clearly. Understanding the scale of the mismatch explains why "certification" language spreads so easily on vendor pages, and why it deserves more scrutiny than a quick skim.
On the adoption side, RAND's 2025 survey of U.S. teachers and principals found that roughly a quarter of teachers used AI tools for instructional planning during the 2023-2024 school year, while 70% of principals cited data privacy concerns as a major or minor factor shaping their AI purchasing decisions (RAND, 2025). Instructure's LearnPlatform data adds scale to that picture: districts now have access to an average of nearly 3,000 distinct edtech tools in a given year, far more than any privacy office can individually vet line by line (Instructure, 2025).
Families are not fully reassured, and their skepticism has numbers behind it too. Common Sense Media's 2025 family research found that 84% of parents and 76% of children reported concern about AI tools misusing student data, while 83% of parents said their child's school had not communicated with them about generative AI use at all (Common Sense Media, 2025). That communication gap sits directly on top of the legal one: a district can be technically compliant on paper and still leave families feeling uninformed.
A costly reminder of what is actually at stake arrived via PowerSchool's December 2024 breach, which TechCrunch's reporting traced to a single compromised support-portal credential and which affected more than 62 million students and 9.5 million teachers, exposing names, addresses, and in many cases Social Security numbers (TechCrunch, 2025). PowerSchool is a student information system rather than an AI product, but the breach underscores that a vendor's privacy promises are only as strong as the security practices behind them, an issue that applies equally to any AI tool handling identifiable student data.
What FERPA Actually Requires
FERPA is a 1974 federal law that gives parents and eligible students rights over a student's "education records" and restricts when a school may disclose those records without consent. It does not regulate software companies directly; it regulates the schools and districts that use them.
Who FERPA covers
FERPA applies to "educational agencies and institutions" that receive funding through a program administered by the U.S. Department of Education, according to the Department's Student Privacy Policy Office (studentprivacy.ed.gov), the office that administers and enforces the law. In practice, that means nearly every public K-12 school and district in the country, along with most colleges and universities.
FERPA grants parents (or eligible students 18 and older) three core rights:
- The right to inspect and review the student's education records maintained by the school.
- The right to request amendment of records the parent believes are inaccurate or misleading.
- The right to control disclosure, meaning the school generally needs consent before releasing personally identifiable information from those records to a third party.
What counts as an "education record"
An education record is broadly defined as anything directly related to a student and maintained by the school or a party acting for the school, grades, transcripts, disciplinary files, health records maintained by the school, and, increasingly, the outputs and interaction logs a classroom AI tool generates about a specific, identifiable student. A quiz an AI tool grades and stores against a student's name can be an education record; the same content, fully anonymized, generally is not.
How a vendor is allowed to touch that data
Schools cannot hand education records to an AI vendor just because it's convenient. FERPA's regulations, at 34 CFR § 99.31(a)(1), carve out a "school official" exception that lets a school share records with an outside vendor without individual parental consent, but only when four conditions are all met:
- The vendor performs an institutional service the school would otherwise perform itself.
- The school retains "direct control" over how the vendor uses and maintains the data.
- The vendor uses the data only for the purpose the school authorized, not its own separate goals.
- The vendor is contractually barred from redisclosing the data without permission.
That four-part test is the actual legal mechanism, and it only exists on paper if a signed contract, not a click-through terms-of-service agreement, puts it in writing.
What happens if a school violates FERPA
FERPA's enforcement mechanism is unusual: there is no private right of action. The U.S. Supreme Court settled this in Gonzaga University v. Doe, 536 U.S. 273 (2002), ruling that FERPA's provisions do not create individually enforceable rights a student or parent can sue over directly. Instead, enforcement runs through the Department of Education, which can, after a period allowing the school to voluntarily correct the problem, terminate a school's eligibility for federal funding.
That penalty is severe on paper and rarely used in practice; the Department has never actually cut off a school's federal funding over a FERPA violation, though the threat itself, combined with reputational damage and state-law penalties layered on top, is what drives district-level compliance behavior.
FERPA and COPPA are frequently mentioned in the same breath, but they regulate different parties in different ways. Seeing them side by side clarifies why an AI vendor needs a different kind of answer for each one.
| Dimension | FERPA | COPPA |
|---|---|---|
| Who it legally binds | Schools and districts receiving US Dept. of Education funding | The vendor/operator directly, regardless of school involvement |
| What it protects | Personally identifiable information in a student's "education record" | Personal information collected online from children under 13 |
| Consent mechanism | School consent generally required before disclosure to a third party | Verifiable parental consent, often satisfied via school-as-agent for educational use |
| Regulator | US Dept. of Education, Student Privacy Policy Office | Federal Trade Commission |
| Vendor certification program | None; vendors participate only via signed contract | None from the government directly; voluntary, FTC-approved Safe Harbor programs exist |
| Typical penalty | Loss of federal funding eligibility (never actually imposed); no private right of action | Civil penalties assessed per violation, enforced directly against the operator |
What COPPA Actually Requires
COPPA is a 1998 federal law, enforced by the Federal Trade Commission, that regulates operators of online services directed at children under 13, or with actual knowledge they are collecting personal information from a child under 13. Unlike FERPA, COPPA regulates the vendor directly, not just the school, which is why it shows up constantly in AI-tool privacy conversations.
Who COPPA covers and what it requires
COPPA requires covered operators to provide clear notice of what data they collect and why, and, critically, to obtain verifiable parental consent (VPC) before collecting personal information from a child under 13. It also requires data minimization, reasonable security, and a parent's ongoing right to review or request deletion of their child's data.
Schools occupy a special position here. Longstanding FTC guidance allows a school to act as the parent's agent and consent on a family's behalf, but only when the AI tool is used strictly for an educational purpose the school has authorized, the data isn't used for commercial purposes like targeted advertising, and the school has been notified of what's collected. That "school-consent" pathway is exactly why most K-12 AI tools can operate with elementary-age students without collecting a signed form from every family individually, but it depends entirely on the vendor's practices matching what the pathway actually permits.
What changed in the FTC's 2025 COPPA amendments
The FTC published its first COPPA Rule amendments since 2013 in the Federal Register on April 22, 2025, with the rule taking effect June 23, 2025, and most substantive provisions requiring compliance by April 22, 2026 (FTC, 2025). The changes tighten several areas that matter directly for AI tools processing student data.
| Requirement area | Before the 2025 amendment | After the 2025 amendment |
|---|---|---|
| Third-party data sharing consent | A single bundled consent could cover both collection and third-party disclosure | Separate, standalone verifiable parental consent is required specifically for disclosure to third parties, including for targeted advertising |
| Data retention | No explicit limit; vendors could retain data indefinitely if not otherwise restricted | Data may be kept only as long as reasonably necessary for its original purpose, under a written, published retention policy |
| Vendor security vetting | Reasonable security procedures required, but with limited specificity on subprocessors | Operators must take documented steps to verify that third parties receiving children's data can maintain adequate security, with written assurances required |
| Privacy notice content | General description of data practices | Must name the categories of third parties receiving data, the purposes for sharing, and the retention timeline explicitly |
Penalties for COPPA violations
COPPA violations carry civil penalties assessed per violation, adjusted periodically for inflation under federal law; a single enforcement action against a company with millions of child users can run into the tens of millions of dollars in aggregate once every affected account is counted. Unlike FERPA, COPPA enforcement does not run through a school's funding, it runs through the FTC directly against the operator, which is part of why COPPA exposure sits primarily with the AI vendor rather than the district, even though the district still bears responsibility for choosing that vendor.
The Single Most Important Fact: There Is No FERPA or COPPA "Certification"
Read this section even if you skip everything else. No government body issues a "FERPA Certified" or "COPPA Certified" seal to a software company. When a vendor's pricing page says "FERPA and COPPA compliant," it is making one of three different claims, and they are not equally strong.
| Claim type | What it actually is | How strong is it as evidence |
|---|---|---|
| Self-attestation | The company describes its own practices as compliant, based on its own internal legal review, with no outside party checking the claim | Weakest; the most common form and the easiest to write regardless of actual practice |
| Signed Data Processing Agreement | A binding contract between the vendor and a specific district, locking in the confidentiality and use restrictions FERPA's school-official exception requires | Enforceable, but only for the district that signed it, and only as strong as the contract's actual language |
| FTC-approved Safe Harbor program | Independent review by an FTC-approved self-regulatory organization under 16 CFR § 312.11, such as iKeepSafe, PRIVO, or kidSAFE, covering COPPA-specific practices | Strongest available signal, though still a private organization's seal operating under FTC oversight, voluntary, and specific to COPPA, not FERPA or state law |
COPPA does have one real, government-recognized mechanism among these three: the Safe Harbor program described in the table above. A vendor that has joined one has been reviewed by an outside party, not just the FTC directly, and participation is entirely voluntary. FERPA has no equivalent at all, not even a voluntary one, since it legally binds the school rather than the vendor, leaving nothing for a vendor to get certified against in the first place. Any FERPA claim from a vendor, no matter how it's phrased, ultimately reduces to "we offer a contract your district can sign," full stop.
This is not a minor technicality or a gotcha. It reflects how both laws were actually written: FERPA in 1974, long before third-party software vendors existed as a procurement category, and COPPA in 1998, before generative AI existed at all. Neither law anticipated a marketplace of AI vendors selling directly to teachers, which is exactly why the contract, not the marketing claim, has to do the legal work.
How AI Tools Specifically Complicate FERPA and COPPA
Generative AI adds two problems neither law was written to anticipate: model training on inputs, and a chain of subprocessors sitting behind the product a district actually contracted with. Both change what "compliant" needs to mean in practice.
The training question
A traditional edtech tool stores data; an AI tool can also learn from it. When a vendor states a tool "doesn't train on student data," that sentence needs to be read carefully; a no-training claim is a promise about future model updates, not a description of whether the data is processed at all, since every AI response requires processing the input to generate an output. The promise only becomes enforceable once it appears in the signed DPA rather than just the public privacy page.
The subprocessor problem
Most classroom AI tools are not themselves foundation-model builders. A district that contracts with a mid-size AI platform is often, in practice, also relying on whatever OpenAI, Anthropic, or Google has separately agreed to for that platform's underlying model calls. A no-training commitment that doesn't explicitly extend through that entire chain, model provider included, has a gap exactly where a district most needs it closed.
Questions worth asking any AI vendor directly:
- Which foundation model or models power this product, and does the vendor's no-training commitment bind that provider too, in writing?
- Is there a signed DPA available for district review, separate from the public-facing terms of service?
- What is the data retention and deletion timeline, and does it match the written policy the 2025 COPPA amendments now require?
- Does the tool require individual student accounts, or can a teacher generate content from a class profile without students logging in directly?
- Has any FTC-approved Safe Harbor organization reviewed the product's COPPA practices, and can the vendor name it specifically?
State law adds a third layer
FERPA and COPPA are the federal floor, not the ceiling. More than a dozen states have their own student-data-privacy statutes layered on top, including California's Student Online Personal Information Protection Act (SOPIPA, 2014) and Illinois's Student Online Personal Protection Act (SOPPA, 2021), both of which restrict vendor use of student data more tightly than federal law alone. A contract that satisfies FERPA and COPPA is not automatically sufficient in a state with its own, stricter statute.
A Practical Checklist for Evaluating a New AI Tool
Before adopting any AI tool that will touch student data, work through these questions in order, and get written answers, not verbal reassurances, for each one.
- Does a signed DPA exist, or can one be executed before rollout? If the answer is no and the vendor points only to a public terms-of-service page, treat that as a blocker, not a formality.
- Does the tool require students to hold individual accounts, or does a teacher generate content on their behalf? Fewer student-facing accounts generally means a smaller COPPA and FERPA exposure surface to manage.
- Is the underlying model provider named, and does the no-training commitment cover that provider explicitly? A vague answer here is itself informative.
- What is the written data-retention and deletion policy, and does it comply with the 2025 COPPA amendment's requirement for a specific, published timeline?
- Has an FTC-approved Safe Harbor organization reviewed the product, or is the compliance claim entirely self-attested?
- Does the vendor's claim account for your state's specific student-privacy statute, not just FERPA and COPPA at the federal level?
- Who signs off internally? Route the contract through legal or a designated student-data-privacy officer, not procurement alone, before a pilot becomes district-wide.
| Vendor answer you hear | What it actually tells you | Follow-up question |
|---|---|---|
| "We're FERPA and COPPA compliant" | A self-description, not third-party verified | "Can I see the signed DPA, and has any outside body reviewed this claim?" |
| "We don't train on your data" | A promise about the vendor's own layer only, unless stated otherwise | "Does that commitment extend to your underlying model provider, in writing?" |
| "We have a SOC 2 report" | Verified security controls, encryption, access management | "Does SOC 2 say anything about data training or retention specifically? (It usually doesn't.)" |
| "We're a certified COPPA Safe Harbor participant" | Real, FTC-approved third-party review, the strongest signal on this list | "Which organization, iKeepSafe, PRIVO, or kidSAFE, and can you confirm the program listing?" |
Getting Started: A Step-by-Step Rollout Plan
Turning this checklist into an actual district policy is a sequencing problem more than a legal one. The order below reflects how privacy offices and curriculum teams typically move from "teachers are already using this informally" to a defensible, documented policy.
- Inventory what's already in use. Before writing any policy, find out which AI tools teachers have already adopted, on district accounts or personal ones, and with what kind of student data. Most districts are surprised by how much shadow adoption has already happened.
- Triage by risk, not by popularity. A lesson-planning tool that never touches identifiable student data needs a lighter review than one where students type directly into a chat interface. Sort the inventory into tiers before assigning review effort.
- Request the DPA for anything in the higher-risk tier. Route it through legal or a designated student-data-privacy officer, not procurement alone, and treat a vendor's inability to produce one as disqualifying for that tier.
- Document the retention and deletion policy for each approved tool, matching the specificity the 2025 COPPA amendments now require of the vendor itself.
- Name the sanctioned tier publicly and train staff on it. Most AI-related privacy incidents happen because a well-meaning teacher didn't realize a personal account wasn't the approved one, not because anyone was trying to cut corners.
- Set a review date, not a one-time approval. Model providers change, retention defaults shift, and a policy frozen at rollout drifts out of date within a year; put an annual re-verification step on the calendar before the first approval is even finalized.
Common Challenges and How Schools Overcome Them
Most FERPA and COPPA problems in AI adoption are not malicious; they are the predictable result of moving faster than a district's paperwork.
- Shadow AI use. Teachers experimenting with a personal ChatGPT or similar account, outside any district contract, is the single most common way student information ends up somewhere no DPA covers. The fix is a named, sanctioned tier teachers are trained to use instead, not just a policy banning the alternative.
- Vendor sprawl. Districts routinely have access to thousands of nominally available edtech tools in a given year, according to Instructure's LearnPlatform usage data (Instructure, 2025), far more than any privacy office can individually vet. A tiered review process, lightweight for low-risk tools, thorough for anything touching identifiable student data, keeps the workload realistic.
- Ambiguous under-13 triggers. A tool built for upper grades that a younger sibling class also starts using can silently cross into COPPA territory if nobody re-checks its age assumptions. Age-banding a tool at adoption time, and revisiting that band annually, closes the gap.
- Fourth-party risk nobody asked about. A vendor's own subprocessor, the model provider behind its product, changing its data policy doesn't automatically show up on a district's radar unless the DPA specifically requires notice of subprocessor changes.
- Retention policies that exist on paper but aren't implemented technically. The 2025 COPPA amendments require a written retention policy; several districts discover during an audit that the policy exists but the vendor's system has no actual deletion mechanism behind it.
- Treating a pilot's paperwork as permanent. A trial agreement that expires quietly, while classroom use continues past that date, leaves a district using an AI tool with no active contractual protection at all.
EduGenius's Privacy Posture
EduGenius does not claim a FERPA or COPPA "certification," because, as this guide has explained, no such certification exists for either law. What can be verified is the platform's architecture, and how that architecture shapes its actual data-privacy exposure.
EduGenius is built as a teacher-side content generator, producing quizzes, worksheets, flashcards, and other instructional materials for Grades KG-9 from a class profile a teacher configures with grade level, subject, and ability range, rather than as an open-ended chat tool students interact with directly. Personally identifiable student information is kept in server-only data collections rather than ones exposed to the client, and the assignment and sharing flow does not expose student names to public access by default, with sharing set to private unless a teacher deliberately changes that. That design choice narrows the data footprint compared with a tool that requires every student to hold an individual account and converse with a model directly.
None of that substitutes for a district's own due diligence. A school adopting EduGenius, or any AI tool, should still request a written DPA before using it with identifiable student data at scale, confirm current data-retention and deletion practices directly with the vendor, and apply the same checklist above rather than taking any vendor's self-description, this one included, as the final word.
Key Takeaways
- There is no government FERPA or COPPA certification for software vendors. Any "compliant" claim is either a self-description or a signed contract, never a government-issued seal, with one narrow exception: COPPA's voluntary, FTC-approved Safe Harbor programs (iKeepSafe, PRIVO, kidSAFE).
- FERPA (20 U.S.C. § 1232g) binds schools and districts, not vendors directly; a vendor participates only through a signed Data Processing Agreement under the "school official" exception (34 CFR § 99.31(a)(1)).
- COPPA (16 CFR Part 312) binds the vendor directly and requires verifiable parental consent for children under 13, though schools can often consent on a family's behalf for a strictly educational purpose.
- The FTC's 2025 COPPA amendments, effective June 23, 2025 with an April 22, 2026 compliance deadline, added separate consent for third-party data sharing, written data-retention limits, and stricter vendor security vetting.
- FERPA's real penalty is loss of federal funding, a sanction the Department of Education has authority to impose but has never actually used, and FERPA carries no private right of action after Gonzaga University v. Doe (2002).
- AI adds a subprocessor layer most districts overlook: a vendor's no-training promise is only as strong as whether it explicitly extends to the foundation-model provider behind the product.
- State laws like California's SOPIPA and Illinois's SOPPA can require more than federal law alone, so a FERPA- and COPPA-satisfying contract may still fall short of a specific state's statute.
- A written checklist beats a website skim: ask for the DPA, name the model provider, confirm the retention policy, and check for third-party Safe Harbor participation before signing anything.
- EduGenius's architecture (teacher-managed class profiles, server-only PII, private-by-default sharing) reduces exposure surface but is not a substitute for a district's own signed agreement and configuration decisions.
Frequently Asked Questions
Is FERPA a certification a software vendor can earn?
No. FERPA is a federal law that legally binds schools and districts, not software companies, so there is no certificate, badge, or seal a vendor can obtain to become "FERPA compliant" on its own. A vendor's real compliance posture depends on whether it has signed a Data Processing Agreement with the specific district using it.
What's the core difference between FERPA and COPPA?
FERPA regulates what a school may disclose from a student's education record and requires the school's consent decisions to follow specific rules. COPPA regulates what any online service may collect directly from a child under 13 and requires verifiable parental consent. FERPA binds schools; COPPA binds the vendor operating the service.
Can students under 13 use an AI tool without individual parental consent?
Often yes, if the school itself provides consent as the parent's agent for a strictly educational purpose, the data isn't used commercially, and families are notified, a pathway longstanding FTC guidance permits. That depends entirely on the vendor's actual practices matching what the pathway allows, which is why a signed DPA still matters.
What is a Data Processing Agreement, and why does every AI vendor need one?
A Data Processing Agreement (DPA) is a binding contract between a school or district and a vendor that specifies how student data may be used, stored, and protected, satisfying FERPA's "school official" exception. Unlike a public privacy policy, a DPA is enforceable and specific to that district, which is why it, not marketing language, is the real compliance mechanism.
What actually happens if a school violates FERPA?
The Department of Education can, after giving a school the chance to voluntarily fix the problem, terminate its eligibility for federal funding, though that sanction has never actually been imposed on any institution. FERPA carries no private right of action following the Supreme Court's 2002 ruling in Gonzaga University v. Doe, so individuals cannot sue directly under the law.
Is EduGenius FERPA and COPPA compliant?
EduGenius does not claim a government certification, because none exists for either law. Its architecture, teacher-managed class profiles, server-only handling of personally identifiable student information, and private-by-default sharing, is designed to reduce data exposure, but any district should still request a signed DPA and apply its own review before using it with student data at scale.