FERPA and AI in EdTech: The Student Privacy Compliance Checklist Founders Must Run Before Selling to Schools

If you are building an EdTech product with AI features — adaptive learning engines, AI tutoring chatbots, automated grading tools, or predictive analytics dashboards — and you plan to sell to U.S. school districts, FERPA is the first legal gate you must pass through. Most founders we talk to have heard of FERPA in passing but treat it as a school-side obligation that does not directly bind the vendor. That is partially correct and partially dangerous. FERPA itself does not create a private right of action against EdTech companies, but it creates a web of contractual requirements that flow down from schools to vendors through the "school official" exception — and a growing number of state student privacy laws impose direct obligations on EdTech companies that go beyond what FERPA requires.

The U.S. Department of Education has signaled that AI in education is a priority area. Its AI guidance page and the Privacy Technical Assistance Center (PTAC) provide the regulatory framework schools use to evaluate whether an EdTech vendor qualifies as a "school official" under FERPA. At the same time, the FTC finalized significant amendments to the COPPA Rule in April 2025, expanding the definition of personal information to include biometric identifiers and requiring written data retention policies. And state laws — including Texas SB 1792 and California's AB 1584 — impose direct vendor obligations that can sink a district deal if your product is not built for compliance from day one.

This is the compliance checklist we walk every EdTech founder through before they pitch their first school district. For a broader overview of children's privacy obligations beyond FERPA, see our guide on state kids' online safety laws and our COPPA 2025 amendments compliance guide.

What FERPA Actually Covers — and Why EdTech Vendors Should Care

FERPA (the Family Educational Rights and Privacy Act, 20 U.S.C. § 1232g) protects the privacy of student "education records" — records that are directly related to a student and maintained by an educational agency or institution receiving federal funding. The law gives parents (and eligible students over 18) the right to inspect and amend education records and to control their disclosure. FERPA is enforced by the U.S. Department of Education's Student Privacy Policy Office, which can terminate a school's federal funding for violations — which is why schools are extremely cautious about vendor agreements.

The key question for EdTech founders is this: when your AI-powered product processes student data — grades, assessment responses, learning patterns, behavioral data — is that data part of a "education record" under FERPA? If a school provides student data to your platform for educational purposes, that data is almost certainly part of the student's education record. The school can disclose it to you without parental consent, but only under the "school official" exception — and that exception comes with strings attached.

The "School Official" Exception: The Four-Prong Test EdTech Vendors Must Satisfy

Under 34 CFR § 99.31(a)(1), a school may disclose personally identifiable information (PII) from education records without parental consent to a contractor, consultant, or other outside party — but only if that party qualifies as a "school official." According to PTAC's official guidance, an outside party qualifies as a school official if it meets four criteria:

• Performs an institutional service or function for which the school would otherwise use employees. Your AI tutoring tool must be providing a service the school would otherwise perform with its own staff — not just collecting data for your own purposes.
• Is under the direct control of the school with respect to the use and maintenance of education records. This is the "direct control" prong, and it is the one most EdTech founders underestimate. The school — not the vendor — must control how student data is used, stored, and deleted.
• Is subject to the use restrictions in 34 CFR § 99.33(a). PII from education records may be used only for the purposes for which the disclosure was made — meaning if the school discloses student data so your AI grading tool can score assignments, you cannot use that same data to train a model for a different product or to improve your general-purpose AI.
• Meets the criteria in the school's annual FERPA notification for being a school official with a legitimate educational interest.

The § 99.33(a) use restriction is the provision that creates the most exposure for AI-powered EdTech companies. It states that the party receiving PII "may use the information, but only for the purposes for which the disclosure was made." If your platform uses student interaction data — prompts, responses, learning patterns — to train or fine-tune your AI models for use in other products or for other school districts, you may be violating this restriction. The school's contract with your company must spell out the specific purposes for which data will be used, and you must build your product architecture to enforce those limits.

When AI Features Trigger FERPA: Tutoring, Adaptive Learning, and Automated Grading

Not every AI feature in an EdTech product triggers FERPA. The trigger is whether the feature processes data that constitutes part of a student's education record. Here is how the most common AI features in EdTech products map to FERPA:

AI Tutoring and Chatbot Features

When a student interacts with an AI tutor — asking questions, receiving explanations, working through problems — those interactions generate data that is directly related to the student and maintained by the school's contracted platform. That data is part of the education record. If your AI tutor processes student inputs through a third-party LLM API, you need to ensure that the API provider does not retain or train on those inputs, because the school official exception does not authorize your subprocessors to use student data for their own purposes.

Adaptive Learning Engines

Adaptive learning platforms that adjust content difficulty based on student performance are processing education records in real time. The student's response patterns, error rates, and learning trajectories are all PII from education records. Under the school official exception, you can use this data to adapt the learning experience for that student — but you cannot aggregate it across districts to train a general model without explicit contractual authorization and compliance with § 99.33(a).

Automated Grading and Assessment Tools

AI-powered grading tools that score student essays, math problems, or standardized assessments are processing education records. The student's submissions are education records, and the scores your tool generates become part of the education record when the school incorporates them into its systems. The school official exception covers this use, but only if the grading tool's data processing is limited to the scope authorized by the school's contract.

Data Minimization and the Prohibition on Training Models with Student Data

The single most important architectural decision for an EdTech AI product is whether student data is used to train or improve the vendor's AI models. The § 99.33(a) use restriction — "only for the purposes for which the disclosure was made" — creates a hard boundary. If the school's contract authorizes your platform to use student data for "providing adaptive learning services," that does not implicitly authorize using the same data to train a general-purpose model that powers your other products.

This is where many AI-native EdTech startups create compliance problems. The business model for many AI companies depends on using user interaction data to improve models. But in the FERPA context, that model improvement must be contractually authorized and scoped to the specific educational service being provided to the school. If your terms of service or privacy policy contains language about "improving our services" or "training our models" using user data, that language is incompatible with the school official exception unless the school's contract explicitly authorizes that specific use.

The safest approach is to build your product with data segregation at the architectural level: student education records are processed in an isolated environment, are never used to train models for other products, and are deleted (or returned to the school) when the contract ends. If you use a third-party LLM API, ensure the API terms prohibit training on customer inputs — the same principle we recommend for AI vendor agreements generally.

Directory Information Limits and Parent Notification

FERPA distinguishes between "education records" (which require consent or an exception for disclosure) and "directory information" (which schools may disclose without consent if they provide public notice and an opt-out mechanism). Under 34 CFR § 99.3 and § 99.37, directory information typically includes a student's name, address, telephone listing, date and place of birth, participation in activities and sports, and dates of attendance.

For EdTech vendors, the directory information distinction matters in two scenarios. First, if your product only processes directory information — not substantive education records — you may face fewer FERPA constraints, though state privacy laws may still apply. Second, if your product uses directory information to personalize the student experience (e.g., displaying the student's name in the UI), the school must have included that use in its annual FERPA notification and provided parents with an opportunity to opt out.

However, most AI-powered EdTech features process far more than directory information. Adaptive learning data, assessment responses, and behavioral analytics are all non-directory education records, and the school official exception — not the directory information provision — is the disclosure mechanism that governs your access to that data.

State Laws That Impose Direct Vendor Liability

FERPA does not create a private right of action against EdTech vendors. But state student privacy laws increasingly impose direct obligations on EdTech companies — and those laws can create direct liability that FERPA does not.

Texas SB 1792

Texas SB 1792, passed in 2017, applies directly to EdTech vendors contracting with Texas school districts. The law requires that contracts between schools and technology providers include specific data protection provisions. Key requirements include: a prohibition on using student data for targeted advertising, a ban on creating commercial profiles of students for non-educational purposes, mandatory data deletion when a student leaves the district or upon request, and transparent contract terms describing how data is collected, used, and protected. Violations can be enforced by the Texas Attorney General.

California AB 1584

California's AB 1584, codified at Education Code § 49073.1, requires that contracts between local educational agencies and third-party digital education providers include specific mandatory provisions. These include: a statement that pupil records remain the property of and under the control of the LEA, a prohibition against using PII for commercial or advertising purposes, a prohibition against using pupil record data for any purpose other than fulfilling the contract, a description of security measures, procedures for notifying parents in the event of unauthorized disclosure, and a certification that pupil records will not be retained after the contract ends. Critically, a contract that fails to comply with these requirements is voidable — and all pupil records must be returned to the LEA.

For EdTech founders, the practical implication is that your standard SaaS terms of service are unlikely to satisfy these state-specific requirements. You need a dedicated education data privacy addendum (EDPA) that schools can sign alongside your master agreement — and that EDPA must be tailored to the states where your customers operate.

The FTC COPPA Overlay

If your EdTech product is directed to children under 13 — or if you have actual knowledge that you are collecting personal information from children under 13 — COPPA applies in addition to FERPA. The FTC finalized significant amendments to the COPPA Rule in April 2025, with compliance required by April 22, 2026. Key changes include an expanded definition of "personal information" that now encompasses biometric identifiers (fingerprints, voiceprints, facial templates), enhanced notice requirements that mandate identification of third-party recipients by name, and a requirement that operators establish and maintain written data retention policies.

The interaction between FERPA and COPPA in the school context is nuanced. COPPA includes a provision that allows schools to provide consent on behalf of parents for the collection of personal information from children for the use and benefit of the school — but this "school consent" pathway does not override FERPA's use restrictions. If your AI product processes data from students under 13, you must comply with both FERPA's school official requirements and COPPA's parental notice, data minimization, and retention requirements. For a detailed walkthrough, see our COPPA 2025 amendments compliance guide.

Building Your FERPA Compliance Checklist Before the First District Deal

Before you sign your first school district contract, your EdTech product and your legal documentation must be aligned with FERPA's school official requirements, state student privacy laws, and COPPA (if applicable). Here is the checklist we run with every EdTech founder:

1. Map your data flows. Document exactly what student data your AI features process, where it is stored, who has access, and what happens to it after processing. This is the foundation of your FERPA compliance documentation.
2. Segregate training data from education records. Build your architecture so that student education records are never used to train models for other products or other customers. If you must use student interaction data to improve your model, ensure the school's contract explicitly authorizes that specific use.
3. Draft an Education Data Privacy Addendum (EDPA). Your EDPA should address: data ownership (the school owns the data), use limitations (only for the contracted educational purpose), security requirements, breach notification timelines, data deletion on contract termination, and prohibition on commercial use or advertising.
4. Verify your AI subprocessors. If you use a third-party LLM API, confirm in writing that the provider does not train on customer inputs, does not retain data beyond the processing period, and offers a data processing agreement compatible with FERPA's use restrictions.
5. Address state-specific requirements. For each state where you have or plan to have district customers, verify that your EDPA satisfies that state's student privacy law — including Texas SB 1792, California AB 1584, and similar statutes in Colorado, New York, and other states.
6. Implement data deletion capabilities. Your product must be able to delete (or export and return) all student data when a contract ends or when a student leaves the district. Build this capability before the first contract, not after a district requests it.
7. If COPPA applies, build for the 2025 amendments. Expand your definition of personal information to include biometric data, establish written data retention policies, and enhance your parental notice to identify third-party data recipients by name.

Actionable Next Steps

1. Audit your AI data pipeline against the school official exception. Identify every point where student education records enter your product, what happens to them, and whether any of that data is used to train or improve models beyond the scope authorized by the school. If the answer is "we use interaction data to improve our general model," you have a FERPA compliance problem to fix before selling to any district.
2. Draft an Education Data Privacy Addendum. Work with counsel to create an EDPA that satisfies FERPA's § 99.33(a) use restrictions, addresses the four prongs of the school official exception, and incorporates state-specific requirements for Texas (SB 1792), California (AB 1584), and any other states in your go-to-market plan.
3. Verify your AI vendor chain. If your product relies on third-party LLM APIs, obtain written confirmation that those providers do not train on customer inputs and will sign data processing agreements compatible with FERPA. A school official exception that breaks down at the subprocessor level is no exception at all.
4. Build data deletion and export capabilities now. Districts will ask — often during procurement — how you handle data deletion when a contract ends or a student leaves. Having a documented, automated deletion process is a competitive advantage in district sales and a compliance requirement under state law.
5. Map COPPA applicability. If your product serves students under 13, confirm whether you are relying on school consent under COPPA and ensure your data practices comply with the 2025 amendments before the April 2026 compliance deadline.
6. Get legal review before your first district pitch. The cost of building a FERPA-compliant product architecture and EDPA before your first district contract is a fraction of the cost of retrofitting compliance after a district's legal team rejects your agreement — or worse, after a student privacy complaint triggers a Department of Education investigation into your school customer.