A school registrar's office is, in a very literal sense, the custodian of a permanent record — grades, disciplinary notes, accommodation plans, correspondence with parents, all of it building a file that follows a student for years and that the institution has a distinct legal obligation to protect, not merely a general ethical one. Automating this administrative layer — enrollment processing, transcript requests, routine parent correspondence — offers the same efficiency case that appears throughout this series. It also sits squarely inside the Family Educational Rights and Privacy Act, a statute old enough to predate the internet as most people use it today, and specific enough that a general-purpose AI tool rarely fits its requirements without deliberate adaptation.
1. FERPA's Scope and the "Education Record" Concept
FERPA, codified at 20 U.S.C. § 1232g and implemented through 34 CFR Part 99, protects the privacy of "education records" — a deliberately broad category covering records directly related to a student and maintained by an educational institution or a party acting on its behalf. The breadth of this definition is exactly where AI automation creates risk: a workflow tool that summarizes a disciplinary file, drafts a response to a parent inquiry about grades, or processes a transcript request is handling education records under FERPA's definition, and the institution's disclosure obligations attach to that handling regardless of how routine the underlying task felt to the staff member who initiated it.
FERPA generally prohibits disclosure of education records without consent, subject to a set of specific exceptions — including a "school official" exception that allows disclosure to parties, including vendors, performing an institutional service or function the school would otherwise perform itself, provided the vendor is under the school's direct control regarding the use and maintenance of the records. An AI vendor processing education records needs to fit within this exception cleanly, with a written agreement establishing the school's direct control, or the disclosure to that vendor is not obviously authorized under the statute at all.
2. The Vendor Control Problem
The "direct control" requirement is where many well-intentioned AI adoptions in education run into trouble, because it demands something more specific than a generic data-processing agreement — it requires the institution to actually be able to demonstrate meaningful control over how the vendor uses and maintains the records, not merely a contractual promise that the vendor will behave appropriately. A general-purpose AI tool whose standard terms permit broad use of submitted content for model improvement is difficult to reconcile with this requirement, because "we may use your data to improve our models" is close to the opposite of "the school maintains direct control over use and maintenance."
Institutions evaluating an AI vendor for any workflow touching education records should treat this specifically, asking not just whether a data-processing agreement exists, but whether its actual terms establish the kind of control FERPA's school-official exception contemplates, or whether the vendor's standard commercial terms would need to be specifically renegotiated to fit.
3. State Student-Privacy Statutes Layered on Top
Beyond the federal floor, states have adopted their own student-data-privacy statutes — California's Student Online Personal Information Protection Act among the most prominent — that impose additional, more specific restrictions on how education technology vendors may use student data, including outright prohibitions on using student data for targeted advertising or building non-educational profiles. These statutes generally apply to the vendor directly, not merely to the institution, which means an AI vendor serving education customers needs its own compliance posture under these statutes, not just a general commitment to protect data on the institution's behalf.
Institutions should treat a vendor's silence or vagueness about these state-specific obligations as a meaningful gap, not a minor administrative detail, because the institution's own reputational and, in some cases, contractual exposure follows from selecting a vendor that has not actually built for this layer of the compliance stack.
4. Architecture as the Practical Answer
A fully on-premises or edge deployment, keeping education records inside the institution's own infrastructure entirely, sidesteps much of the vendor-control analysis above, because there is no third-party vendor in the data path receiving education records at all for that specific workflow — the school-official exception's requirements simply do not need to be satisfied for data that never left the institution's own systems. A masked secure-cloud deployment remains appropriate for genuinely non-education-record workloads — general facilities scheduling, non-student-specific administrative correspondence — where FERPA's specific protections do not attach in the first place.
The classification discipline that makes this work is distinguishing, deliberately and in writing, between workflows that touch education records under FERPA's definition and those that do not, because the two categories warrant genuinely different deployment postures, and treating every administrative workflow identically — either over-restricting the non-sensitive ones or under-restricting the sensitive ones — serves the institution poorly in either direction.
5. Parents, Students, and the Right of Access
FERPA also grants parents, and students themselves once they reach a certain age or enroll in postsecondary education, the right to inspect and review their own education records, and to request correction of records they believe are inaccurate. An AI-assisted workflow that summarizes or synthesizes information across multiple source documents needs to preserve enough traceability back to those source documents that the institution can still honor this access-and-correction right meaningfully — a summary that cannot be traced back to its underlying records defeats the purpose of the access right, because the parent or student reviewing it cannot verify its accuracy against the actual record it was derived from.
This is a specific, practical design requirement that general-purpose summarization tools rarely address by default, and institutions should treat traceability back to source records as a non-negotiable feature of any AI tool applied to a FERPA-covered workflow, not an optional nicety.
6. Conclusion
Education administration automation touches some of the most consistently protected records in U.S. privacy law, under a statute whose vendor-control requirements are genuinely more specific than the general data-protection language most commercial AI tools are built to satisfy. An architecture that keeps education-record-touching workflows fully local, or that only routes them through a vendor relationship specifically structured to satisfy FERPA's school-official exception, is what allows an institution to modernize its administrative operations without quietly creating an unauthorized-disclosure problem in the process.