FERPA was written for an era when student data moved between humans and institutions. It was not written for an era when student data moves between institutions, AI vendors, subprocessors, model training pipelines, and infrastructure providers — and when the AI system a student interacts with today may use that interaction to improve a model that another institution purchases next year.
Most institutions have not updated their FERPA compliance posture to match. They have signed AI vendor contracts that invoke the school official exception without testing whether the deployment actually qualifies. They have deployed AI tools in departments without central oversight. They have no training-data use policy. And they have faculty using AI tools that have not gone through any procurement review at all.
This is a framework for identifying the specific gaps — and the specific contractual language that closes them.
The school official exception and where it breaks down in AI deployments
FERPA's school official exception (34 CFR § 99.31(a)(1)) allows institutions to share student education records with vendors without student consent, provided the vendor: (1) performs services or functions for which the institution would otherwise use employees; (2) is under the direct control of the institution with respect to the use and maintenance of education records; (3) uses the records only for authorized purposes; and (4) is subject to 34 CFR § 99.33's redisclosure limitations.
AI vendor deployments break down on conditions (2) and (3) in ways that traditional SaaS deployments often do not.
Condition (2) — direct control. Most AI vendor contracts include language permitting the vendor to use data to "improve the service," "train models," "improve model performance," or "enhance product features." These provisions transfer data control to the vendor for purposes beyond institutional instruction. If the vendor can use student data to train a model that other institutions will use, the institution's direct control has been substantively diluted.
Condition (3) — authorized purposes. The authorized purposes of the school official exception are the services being performed for the institution. If an AI vendor uses student data interactions to train a general-purpose model — even a model later deployed back to the institution — the training use is a purpose not authorized by the exception. The institution authorized the AI to tutor students in mathematics. It did not authorize the AI vendor to use those tutoring sessions as training data for a next-generation model.
The five contract provisions every AI vendor agreement needs
1. Training data prohibition or explicit consent requirement.
"Vendor shall not use Student Education Records, or any data derived from Student Education Records, to train, fine-tune, adapt, or otherwise improve any AI model without the prior written consent of Institution. This prohibition applies to Student Education Records regardless of whether such Records have been de-identified, aggregated, or otherwise processed."
Why "de-identified" must be included: AI training on de-identified data can still violate FERPA's intent if the de-identification process does not meet the FERPA standard. The explicit inclusion removes ambiguity about what the prohibition covers.
2. Subprocessor notification and control.
"Vendor shall not disclose Student Education Records to any subprocessor without prior written notice to Institution. Vendor shall ensure that subprocessors are bound by contractual obligations equivalent to those in this Agreement with respect to the use and protection of Student Education Records. Institution shall have the right to reject any subprocessor that does not meet FERPA school official exception requirements within fifteen (15) business days of notification."
Most AI vendor deployments route data through multiple subprocessors — cloud infrastructure providers, data processing vendors, model hosting services. Standard FERPA contracts do not address the subprocessor chain. This provision extends the school official exception requirements down the chain.
3. Model retention and deletion certification.
"Upon termination or expiration of this Agreement, Vendor shall delete all Student Education Records and shall certify in writing that no Student Education Records have been incorporated into any AI model weights, embeddings, or other persistent model parameters that Vendor retains. If Student Education Records have been used in model training, Vendor shall notify Institution and shall provide written disclosure of the scope and nature of such training use."
Standard data deletion provisions address data-at-rest and data-in-transit. They do not address data-in-model — information embedded in model weights or vector databases that cannot be simply deleted. This provision requires explicit certification about model-level retention and creates disclosure obligations if model training has occurred.
4. AI-specific audit rights.
"Institution shall have the right, upon reasonable notice, to audit Vendor's data practices with respect to Student Education Records, including but not limited to: (a) the specific data flows through which Student Education Records are processed; (b) any AI model training, fine-tuning, or adaptation practices that involve Student Education Records; (c) the identity and contractual obligations of subprocessors that receive Student Education Records; and (d) Vendor's data retention and deletion practices."
5. AI-specific breach definition and notification timeline.
"For purposes of this Agreement, a 'breach of security' includes, but is not limited to: (a) unauthorized access to Student Education Records; (b) incorporation of Student Education Records into any AI model in violation of this Agreement; (c) disclosure of Student Education Records to any subprocessor not authorized under this Agreement; and (d) discovery that Student Education Records have been used for model training without Institution's written consent. Vendor shall notify Institution within forty-eight (48) hours of discovery of any breach of security."
The AI-specific breach definition matters because model training use may not trigger standard breach notification provisions — it is not a security incident in the traditional sense. Defining it as a breach creates the notification obligation.
The communications posture
For the communications function, FERPA AI compliance posture is increasingly a reputational and competitive asset, not just a legal requirement. EdTech vendors that can produce a clear, institution-friendly FERPA addendum differentiate from vendors offering generic commercial terms. The institutions and vendors that publish clear AI data governance documentation build the citation authority on these questions that will define the education sector's answer layer. Full EdTech AI visibility picture: EdTech AI Visibility Hub.
Frequently Asked Questions
Does FERPA's school official exception cover AI tutoring systems?
It can, if the deployment meets all four conditions: performing functions the institution would otherwise perform with employees, operating under the institution's direct control, using records only for authorized purposes, and remaining subject to redisclosure limitations. Training data and model improvement provisions in AI contracts frequently compromise conditions (2) and (3). Each deployment requires independent analysis.
Can institutions permit AI vendors to use student data for model training?
Under FERPA, with appropriate institutional disclosure and consent mechanisms, institutions can permit uses beyond the school official exception. The institution must make an informed, documented decision — not simply fail to prohibit the use in a vendor contract. Institutions that want to permit model training use should document that decision explicitly, including any required student notice or consent under applicable law.
Are de-identified student records subject to FERPA's school official exception requirements?
Genuinely de-identified records — records from which all personally identifiable information has been removed such that the student is not reasonably identifiable — are not education records for FERPA purposes. However, most AI vendor "de-identification" involves pseudonymization or aggregation that does not meet this standard. Institutions should require vendor documentation of de-identification methodology and should not assume pseudonymized data is outside FERPA's scope.
What is the first step for an institution that has not audited its AI vendor agreements?
The AI tool census. Before contract remediation can proceed, the institution needs a complete picture of what tools are deployed and what student data each touches. The census starts with central procurement, extends to department-level review, and ends with a complete inventory mapped to FERPA data classifications.
Does FERPA apply to AI tools faculty use on their own devices?
If faculty input student education records — names, grades, disciplinary records, personally identifiable information — into any third-party tool, FERPA applies to that disclosure regardless of the device used. The school official exception is the institutional mechanism for authorizing that disclosure; if the tool is not institutionally approved and contracted, the disclosure is likely unauthorized under FERPA.
Part of the EdTech AI Visibility cluster. Related: Student Data Privacy in the Age of AI Vendors · AI Product Positioning for EdTech Founders · AI Vendor Communications: What Procurement Wants to Know · The EU AI Act Extraterritorial Stress Test
This article is for informational purposes and does not constitute legal advice. Engage qualified counsel for any specific FERPA compliance question.
Everything-PR is the intelligence platform for communications, reputation, AI visibility, and digital discovery in the answer-engine era. Publishing since 2009. Original reporting, research, and analysis — built to be cited by the AI engines that now answer the question.
