FERPA's "School Official" Exception Has an AI-Sized Loophole. Here's How to Close It in Your Vendor Contract.

The exception your vendor contract actually runs on

Every school or college that hands student data to an outside dashboard, portal, or AI tool is leaning on one clause: FERPA's "school official" exception. It's the reason a vendor can touch education records at all without parental consent for each disclosure. The exception has four real conditions, not one:

• The vendor performs a service the institution would otherwise perform itself.
• The institution keeps "direct control" over the data — not the vendor.
• The data is used only for the purposes the institution authorized.
• The vendor doesn't redisclose it without permission.

Most procurement conversations stop at "do you comply with FERPA," get a yes, and move on. That question has no wrong answer — FERPA doesn't certify vendors, and there's no compliance badge to check. The actual compliance work happens in the contract language, and that's exactly where institutions tend to under-negotiate.

What "direct control" has to mean in writing

The Department of Education has said a written contract is the clearest way to demonstrate control, even though the regulation doesn't technically mandate one. In practice, "direct control" breaks down into things you can point to in a document:

• The institution — not the vendor — decides how long data is retained and when it's deleted.
• The vendor can't unilaterally change its privacy policy or data-handling terms without notifying (ideally, getting sign-off from) the institution.
• Deletion means deletion, with some way to verify it, not a policy page that says data "may be removed at our discretion."

If your vendor's standard terms let them update their privacy policy whenever they want, or delete data on their own schedule with no notice to you, you don't have direct control — you have a vendor who's being polite for now. That gap doesn't show up in a product demo. It shows up during a data breach investigation or a parent complaint, when someone asks who was actually in charge of the data and the honest answer is "unclear."

Where AI breaks the old assumptions

FERPA and most district vendor agreements were written assuming data gets stored, used, and eventually deleted. Model training doesn't work that way. If a vendor's AI feature is trained on student records your institution shared under the school official exception, and that training happens before the contract ends, deleting the underlying records afterward doesn't undo the training. The data's influence persists in model weights that outlive the data itself. A deletion clause that doesn't explicitly address training data is a deletion clause that doesn't actually apply to the thing you're most worried about.

This isn't a hypothetical gap — it's gotten enough attention that it produced a real contractual response. In September 2026, Microsoft signed a binding agreement with the National Academy for AI Instruction and the American Federation of Teachers establishing an AI Safety and Privacy Standard for generative AI products marketed to schools. Starting November 1, 2026, participating districts can require Microsoft to fold those protections — including restrictions on model training — into their existing agreements, with contractual enforcement rights behind them. The scope is narrow (it covers education-specific generative AI products, not general productivity tools), and it's one vendor, not an industry norm. But it's a signal of where institutional buyers are starting to push, and a template for the kind of specificity your own contracts should have regardless of which AI vendor you're using.

What to actually put in the contract

If you're evaluating a dashboard, portal, or AI tool that touches student records, the questions that matter aren't "are you FERPA compliant" — they're these, and you want the answers in the signed agreement, not a sales call:

• Training use. Does the vendor train any model — their own or a third party's — on your institution's student data? If yes, under what terms, and can you opt out while still using the product?
• Deletion mechanics. What does "delete" mean operationally, who initiates it, how is it verified, and does it cover data baked into a trained model, not just rows in a database?
• Redisclosure and secondary use. Is the data ever used for anything beyond the contracted service — ad targeting, building a profile, selling aggregated insights? Several state laws (California's SOPIPA is the most cited) prohibit this outright regardless of what FERPA alone would allow.
• Change notification. Does the vendor need your sign-off, or even just advance notice, before changing its privacy terms or data practices?
• A standard baseline. The Student Data Privacy Consortium's National Data Privacy Agreement (NDPA) is the most widely adopted framework for exactly these terms, and most vendors serving K-12 and higher ed are familiar with it. If a vendor balks at using it or a comparable document, that's information too.

The takeaway

A vendor saying "we're FERPA compliant" tells you almost nothing — FERPA compliance lives in your contract's specific language about control, retention, deletion, and now, AI training, not in a marketing claim. Before signing anything that touches student records, get explicit written answers to the five questions above, and treat a vendor's reluctance to put them in writing as the actual answer.