ai compliance privacy

Is SchoolAI FERPA Compliant?

EduGenius Team··16 min read

Watch the EduGenius tutorials playlist

Feature walkthroughs, setup help, and practical learning workflows connected to this article.

Open Tutorials

Is SchoolAI FERPA Compliant?

SchoolAI states on its own Trust & Safety pages that it is FERPA compliant, but that phrase is a self-description, not a government certification, because FERPA (20 U.S.C. § 1232g) issues no certificate to any vendor. The law regulates schools and districts directly. Whether a specific classroom's SchoolAI use actually satisfies FERPA depends on one thing: whether the district has a signed agreement in place that gives it "direct control" over the data, the exact condition FERPA's school-official exception requires.

Quick Answer: SchoolAI's FERPA claim is self-attested; no vendor can be independently "FERPA certified" because the law has no such program for any company. SchoolAI structures its practices around FERPA's school-official exception (34 CFR § 99.31(a)(1)), which works only when a district, not an individual teacher, has signed a data agreement giving it direct control over student data. A teacher's personal SchoolAI signup, done without district review, sits outside that structure entirely, regardless of what SchoolAI's privacy page states.

Say you're a curriculum coordinator evaluating SchoolAI for a district-wide pilot, and your superintendent asks a direct question in a planning meeting: "Is this thing FERPA compliant, yes or no?" The honest answer is more useful than a yes or no.

This article narrows specifically to the FERPA question: how SchoolAI's licensing structure interacts with the school-official exception, what "direct control" actually requires, and what separates a real signed agreement from a self-reported claim. For the fuller picture that also covers COPPA and SchoolAI's security certifications side by side, see Is SchoolAI Safe for FERPA and COPPA?, which this article deliberately doesn't repeat.

What FERPA Actually Requires From a Classroom AI Tool

FERPA makes the school or district, not the software vendor, legally responsible for protecting a student's education record. Written in 1974, long before generative AI existed, the law regulates AI tools indirectly, through the same "school official" exception that has governed textbook publishers, grading software, and student information systems for decades.

That exception lets a district share education records with an outside vendor like SchoolAI without individual parental consent, but only when specific conditions hold:

  • The vendor performs an institutional service the school would otherwise perform itself.
  • The district retains "direct control" over how the vendor uses and maintains the data.
  • The vendor uses the data only for the authorized purpose, not a separate commercial goal.
  • The vendor doesn't redisclose the data to further third parties without permission.

There is no FERPA seal, badge, or certificate a vendor can earn, a distinction worth repeating because it's so often obscured by marketing language. When SchoolAI states it's "FERPA compliant," that's a description of its own practices measured against the law, not a credential the Department of Education issued. The compliance obligation itself sits with the district that signs the contract, not with SchoolAI.

What Counts as an "Education Record" Inside SchoolAI Specifically

A chat transcript between a student and SchoolAI's assistant, Dot, can qualify as an education record the moment it's tied to an identifiable student and retained by the school, the same trigger that applies to a graded paper or a report card. That's a broader category than it might first appear, and it's worth being specific about what falls inside it versus outside it.

  • A transcript tied to a student's roster identity, viewable inside a teacher's Mission Control dashboard, is squarely an education record.
  • A flagged-conversation alert, retained for safety-review purposes and linked to a specific student, carries the same FERPA protection as the underlying transcript.
  • Aggregate, de-identified usage statistics, like how many Spaces a grade level used in a month with no student-level detail, generally sit outside the definition.

That distinction matters because a conversational AI tool generates far more identifiable records per class period than a static worksheet or quiz platform does, simply by the nature of open-ended chat. A district's FERPA review should account for that volume, not just the existence of a signed agreement in the abstract.

Why FERPA Doesn't Have a "Safe Harbor" Option the Way COPPA Does

This is the single most important structural fact for evaluating SchoolAI's FERPA claim, and it's easy to miss if you've already read about SchoolAI's COPPA posture. COPPA has a real, government-recognized certification path: a small set of FTC-approved Safe Harbor organizations, including iKeepSafe, PRIVO, and kidSAFE, that independently review a vendor's practices. Is SchoolAI COPPA Compliant? covers that mechanism, and SchoolAI's position relative to it, in full.

FERPA has no equivalent at all, not even a voluntary one. Because FERPA legally binds the school rather than the vendor, there's nothing for a vendor to get independently certified against in the first place. That means the evidence ladder for SchoolAI's FERPA claim has only two real rungs, not three:

Evidence tierWhat it isCeiling
Self-descriptionSchoolAI's own account of its practices on its Trust & Safety pagesThe floor; not independently verified by anyone
Signed district agreement (DPA)A binding contract specifying data use, retention, and control termsThe actual ceiling; there is no stronger FERPA-specific option available

Unlike the COPPA analysis, there's no third row here for an independent reviewer. A signed agreement is as strong as FERPA compliance gets for any vendor, SchoolAI included.

SchoolAI's FERPA Claim Is a Self-Attestation, Not a Certification

SchoolAI's Trust & Safety materials describe the platform as fully FERPA compliant, structured around the school-official exception. That's a legitimate, common way for an edtech vendor to describe itself, and it isn't inherently suspect. It's simply a different category of evidence than an independent audit, and it's worth naming plainly rather than letting the word "compliant" do more work than it should.

Two of SchoolAI's other published claims do carry real third-party weight, which makes a useful contrast:

  • SOC 2 Type II is an independent security audit covering controls like encryption and access management, verified by an outside auditor.
  • 1EdTech TrustEd Apps Certified is a third-party certification against a defined data-privacy and security rubric.

FERPA compliance isn't in that category, and it structurally can't be, for the reason described above: there's no independent body positioned to certify it. That doesn't make SchoolAI's claim false. It means the claim's strength depends entirely on whether your specific district backed it with a real agreement, not on anything SchoolAI itself can unilaterally provide.

The School-Official Exception and What "Direct Control" Means for SchoolAI

"Direct control" is the condition that does the most legal work in this entire analysis, and it's also the one most likely to be silently missing in an informal classroom rollout. A district doesn't satisfy this requirement just because SchoolAI is a well-known, widely used platform. It satisfies it by actually reviewing and signing an agreement that governs SchoolAI's use of student data.

Picture a 7th grade science teacher who wants to run a guided review session using an AI Space before a unit test. Two very different scenarios can produce that same classroom activity:

  1. The district has a signed agreement with SchoolAI specifying data use, retention, and deletion terms. The teacher's classroom use sits inside a structure the district has already vetted, and FERPA's direct-control requirement is genuinely satisfied.
  2. The teacher signed up independently with a personal account and started rostering students informally. The district has no contractual mechanism governing what happens to that data, regardless of what SchoolAI's own privacy page promises elsewhere.

Both scenarios can look identical from inside the classroom. Only one of them actually satisfies FERPA.

Personal Teacher Accounts vs. District-Provisioned Accounts

This distinction matters more for SchoolAI than it does for many classroom tools, because SchoolAI allows an individual teacher to sign up directly, without district involvement, in a way some institutionally licensed products don't. That flexibility is genuinely useful for a teacher who wants to pilot a tool informally. It's also the exact scenario where FERPA's protections can quietly go missing.

Account typeWho reviewed the data termsFERPA "direct control" satisfied?
Personal teacher signup, no district reviewNobody at the institutional levelNo; the district has no contractual mechanism in place
District-provisioned account under a signed DPADistrict IT/legal, before rolloutYes, assuming the agreement's terms are actually followed
District-provisioned account, agreement expired or never finalizedReviewed once, but not currently activeAmbiguous; treat as unresolved until confirmed

A small, informal pilot with one class isn't inherently reckless. The problem is treating that pilot's data handling as FERPA-equivalent to a fully vetted district rollout, when the two are legally different situations wearing the same interface.

What SchoolAI States vs. What's Independently Verified

Laid out side by side, the pattern in SchoolAI's own published claims is consistent: security and certification claims tend to carry outside verification, while legal-compliance claims tend to be self-reported. Neither category is dishonest; they're just different kinds of evidence, and a district's job during procurement is to know which is which.

ClaimSchoolAI's stated positionIndependent backing
FERPA complianceFully compliant, structured around the school-official exceptionNone possible by design; FERPA has no vendor-certification path for any company
SOC 2 Type IIIndependently audited security controlsVerified by a third-party auditor
1EdTech TrustEd Apps CertifiedCertified against a data-privacy and security rubricVerified by 1EdTech, a named certification body
ESSA Tier 3 ValidatedMeets the evidence tier for promising, research-based practicesVerified under the ESSA evaluation framework
No training on student dataData never sold or used to train models; subprocessor contracts prohibit itContractual and self-reported; confirm in your district's DPA

Reading down that table, exactly one row, FERPA, has no independent-verification path available at all, by the structure of the law itself. That's worth remembering the next time a vendor comparison chart lists "FERPA compliant" next to "SOC 2 Type II" as if they were the same kind of claim.

A FERPA Verification Checklist for SchoolAI

Before treating SchoolAI as approved for a district-wide or grade-wide rollout, work through these steps directly with the vendor and your own technology office.

  1. Request the signed Data Protection Agreement, ideally through the Student Data Privacy Consortium's National Data Privacy Agreement framework, rather than relying on a summary page.
  2. Confirm which accounts in your building are personal signups versus district-provisioned, since only the latter sits inside the school-official exception's direct-control requirement.
  3. Ask who at the district owns the SchoolAI relationship, so a renewal or a policy change doesn't slip past everyone's notice.
  4. Get the AI subprocessor list in writing, and confirm the no-training commitment explicitly extends to whichever foundation model SchoolAI uses behind the product.
  5. Set an annual re-verification date, not a one-time signoff, since default settings and subprocessor relationships can change between renewals.
  6. Check your state's own student-privacy statute, since FERPA is a federal floor and states including California, Colorado, and New York impose their own additional requirements.

Picture a district technology director running this checklist during a two-week pilot with two classrooms before recommending SchoolAI school-wide. That window is enough time to request the DPA, confirm which accounts are personal versus provisioned, and get the subprocessor list in writing, all before a single additional classroom joins the rollout.

Rollout stageFERPA statusWhat to do next
A teacher's personal, informal pilotOutside the school-official exceptionTreat findings as informal; don't scale without a district agreement
District has requested a DPA, not yet signedIn progressHold off on wider rollout until the agreement is executed
District has a signed, current DPASatisfies direct control, assuming terms are followedProceed, with an annual review date on the calendar

How This Differs From SchoolAI's COPPA and Safety Questions

FERPA, COPPA, and product-safety design are three separate questions that happen to involve the same platform, and conflating them is the most common mistake in this whole conversation. This article has stayed narrowly on FERPA on purpose.

  • The COPPA question (verifiable parental consent for under-13 students, and whether SchoolAI participates in an FTC-approved Safe Harbor program) is covered in full in Is SchoolAI COPPA Compliant?. Unlike FERPA, COPPA does have a real Safe Harbor certification path, and SchoolAI is not currently listed as a participant in one.
  • The combined legal picture, including SchoolAI's SOC 2 and 1EdTech certifications alongside both FERPA and COPPA claims in one comparison, lives in Is SchoolAI Safe for FERPA and COPPA?.
  • Product-safety design, meaning content filtering and Mission Control's real-time monitoring dashboard, is a genuinely different question from data-privacy law, covered separately for readers evaluating whether SchoolAI's chat experience itself is appropriate for their students.

Keeping these three questions distinct matters practically: a district can have a fully signed FERPA agreement and still want to evaluate SchoolAI's safety design separately, since one doesn't imply the other.

Pro Tips for a Curriculum Team Evaluating SchoolAI

  • Ask for the DPA before the pilot, not after it goes well. Retrofitting a legal agreement onto a tool teachers already depend on is a much harder conversation than reviewing it up front.
  • Inventory personal SchoolAI accounts already in use at your school. Shadow adoption is common with any free-tier AI tool, and you can't govern what you don't know exists.
  • Put the no-training commitment in the DPA itself, not just in an email thread with a sales representative, since only the signed document is actually enforceable.
  • Revisit the agreement at each renewal, treating it as a recurring compliance task rather than a one-time approval.

Districts evaluating an interactive chat tool like SchoolAI alongside a content-generation platform should apply this same direct-control logic across categories. EduGenius, for instance, generates quizzes, worksheets, and other instructional materials from a teacher-configured class profile rather than open-ended student chat, but the same underlying question, is there a signed agreement giving the district direct control, still applies before either tool is adopted at scale.

What to Avoid

  1. Treating "FERPA compliant" on a vendor's website as equivalent to a SOC 2 badge. One is independently audited; the other cannot be, by the structure of the law itself.
  2. Assuming a personal teacher account inherits the district's compliance posture. It doesn't, unless a district-level agreement actually exists and covers that specific use.
  3. Skipping the annual review because the initial approval "already happened." Subprocessor relationships and default settings can shift between renewals without an obvious announcement.
  4. Confusing SchoolAI's FERPA claim with its COPPA claim. They're governed by different laws, different consent mechanisms, and, critically, different available evidence: COPPA has a Safe Harbor option, FERPA does not.

Key Takeaways

  • SchoolAI's FERPA claim is a self-attestation, because FERPA (20 U.S.C. § 1232g) offers no certification program for any vendor to earn, unlike COPPA's narrow Safe Harbor option.
  • A signed district agreement, not a personal teacher signup, is what actually satisfies FERPA's "direct control" requirement under the school-official exception (34 CFR § 99.31(a)(1)).
  • SchoolAI allows individual teacher signup, which is convenient for informal piloting but creates a real gap if that pilot scales into full classroom use without a district-level agreement ever being signed.
  • SOC 2 Type II and 1EdTech TrustEd Apps Certified are independently verified; SchoolAI's FERPA and no-training claims are self-reported and confirmed only through your own district's DPA.
  • There is no FERPA equivalent of COPPA's Safe Harbor programs, so a signed DPA is the strongest possible evidence for any vendor's FERPA posture, not just the strongest of several options.
  • The FERPA, COPPA, and product-safety questions are separate; this article stays on FERPA specifically, with Is SchoolAI COPPA Compliant? and Is SchoolAI Safe for FERPA and COPPA? covering the rest.
  • A district's own verification checklist, DPA request, account-type inventory, subprocessor list, annual review, matters more than any single claim on a vendor's homepage.

Frequently Asked Questions

Is SchoolAI FERPA compliant?

SchoolAI states on its Trust & Safety pages that it is fully FERPA compliant and structured around the school-official exception. There is no government FERPA certification any vendor can hold, so the real answer depends on whether your specific district has a signed agreement giving it direct control over the data, not on SchoolAI's self-description alone.

Can a teacher legally use SchoolAI without district approval?

A teacher can create a personal account, but doing so outside a district-level agreement means FERPA's "direct control" condition, the requirement that actually makes the school-official exception apply, likely isn't satisfied. For anything beyond a very small, informal test, route the decision through IT and legal first.

Does SchoolAI's SOC 2 certification also cover FERPA?

No. SOC 2 Type II verifies security controls like encryption and access management; it doesn't evaluate FERPA-specific legal compliance, which depends on a signed data agreement between SchoolAI and your district, not a security audit.

Why doesn't FERPA have a certification program the way COPPA does?

FERPA was written in 1974 to regulate schools and districts directly, not the vendors they contract with, so there was never a mechanism built for a vendor to get independently certified. COPPA regulates the vendor (the "operator") directly, which is why the FTC created an approved Safe Harbor program; FERPA has no equivalent path for any company, SchoolAI included.

What's the single most important document to request before approving SchoolAI district-wide?

A signed Data Processing Agreement, ideally through the Student Data Privacy Consortium's National Data Privacy Agreement framework, specifying data use, retention, deletion, and subprocessor terms. That document, not SchoolAI's marketing page, is what actually satisfies FERPA's school-official exception for your district.

Does the FERPA analysis change for a K-9 building compared with a high school?

Not in its legal mechanics: FERPA's school-official exception applies the same way across every grade band, since the law centers on education records, not student age. A K-9 building is often newer to AI chat tools, though, so a curriculum team should treat the signed agreement and account-type inventory as a genuine first review, not an assumption already covered elsewhere.

#administrators#data-privacy#ai-tools