Every university is under pressure to deploy AI in student services. Students expect instant answers at 2 a.m. Staff are stretched thin. Vendors promise assistants that can handle registration questions, financial aid status, and advising in one conversation. The technology is ready. The compliance thinking, in many institutions, is not.
The Family Educational Rights and Privacy Act (FERPA) has governed student education records in the United States since 1974. It was not written with generative AI in mind, but it applies to AI systems just as fully as it applies to filing cabinets and student information systems. The institutions that treat FERPA as a design input, rather than a legal review at the end, will deploy faster and with far less risk.
Where AI Assistants Meet Education Records
Not every student services assistant touches education records. The risk depends on what the assistant can access and what it can say:
- General knowledge assistants answer questions from public or institution-wide content: deadlines, policies, how-to guides. These carry the lowest FERPA risk, provided the underlying content contains no student-specific information.
- Authenticated personal assistants answer questions about a specific student's own records: "What is my registration hold?" These can be compliant, but only if identity verification and access controls are airtight.
- Staff-facing assistants help advisors and administrators work with student data. These must enforce legitimate educational interest, meaning each staff member sees only what their role requires.
The question is not whether your AI assistant is FERPA compliant. It is whether your architecture makes non-compliance difficult.
Five Design Principles
1. Keep the knowledge layer clean. Retrieval-based assistants index content. If any indexed article, ticket, or document contains student-identifiable information, the assistant can surface it to anyone. Audit indexed sources and exclude case records, tickets, and free-text fields unless access control flows through to retrieval.
2. Let identity drive access, every time. When an assistant retrieves student-specific data, it must do so as the authenticated user, with the same permissions they would have in the source system. Shared service accounts that can read every student's record, filtered only by the assistant's instructions, are not a control. Prompts are not access control.
3. Treat the AI provider as part of your data flow. If education records are sent to a model provider, the institution needs a contract that establishes appropriate controls over that data, including restrictions on use for training, retention limits, and security requirements. Review this with counsel under the school official provisions your institution relies on.
4. Handle directory information deliberately. Some students opt out of directory information disclosure. An assistant that answers "Is this person enrolled?" must respect those flags. Test for it explicitly.
5. Log, review, and be ready to explain. Maintain logs sufficient to show who accessed what through the assistant and why. Decide retention in advance. Conversation logs that contain education records are themselves sensitive and must be protected accordingly.
Special Cases Worth Planning For
Dual credit and dual enrollment. High school students taking college courses create layered privacy questions involving parents, school districts, and the college. Rights and approval workflows here need to be documented before development, not discovered during testing.
Parents and third parties. Once a student is in postsecondary education, FERPA rights transfer to the student. An assistant must not disclose records to a parent simply because they ask, unless a valid consent or exception applies.
Escalation to humans. When an assistant hands a conversation to staff, the transcript moves with it. Make sure the receiving queue has the same or stricter access controls.
Put It in the Architecture Document
The most common gap we see is simple: FERPA is not mentioned in the architecture decision document at all. Compliance is assumed to be someone else's job. Make it explicit. Document which data sources are in scope, how identity is enforced, what the model provider may do with data, and who reviews it. That single section will prevent more problems than any post-launch audit.
Generative AI can make student services dramatically better. Done with privacy as a design principle, it can also make them more trustworthy. That is a goal worth building toward, and it pairs naturally with the governance framework in our research on Responsible AI in Higher Education.
This article is for general informational purposes and is not legal advice. Consult your institution's counsel on FERPA obligations specific to your environment.
Nya Akoma. Take Heart.