By the Shadow AI Policy team
**Most schools and universities are writing AI policies that cover students but completely ignore the employees — and that's where the real FERPA liability lives.** This post covers what a staff-facing AI acceptable use policy needs to address in an educational institution: FERPA obligations when employees use AI tools with student data, how to separate administrative from academic AI use, what to require from third-party AI vendors, and how to protect research data. It's written for HR managers, compliance leads, and operations staff — not lawyers.The biggest compliance gap in education AI policies isn't students using ChatGPT to write essays — it's a financial aid administrator pasting student records into an AI tool that has no FERPA-compliant data agreement in place. Write your staff policy to close that gap first.
The Family Educational Rights and Privacy Act (FERPA), 20 U.S.C. § 1232g and its implementing regulations at 34 CFR Part 99, restricts the disclosure of personally identifiable information (PII) from student education records. When a staff member pastes a student's name, ID number, grades, financial aid status, or disciplinary record into an AI tool, they are disclosing that data to a third party. FERPA applies.
There are two ways an AI vendor can lawfully receive FERPA-protected data. First, as a "school official" under 34 CFR § 99.31(a)(1) — meaning the vendor has a legitimate educational interest, is under the institution's direct control with respect to the data, and is bound by the institution's FERPA policies. Second, with a specific exception such as a lawfully issued subpoena. A vendor's standard commercial terms of service do not satisfy either path. You need a signed data processing agreement that explicitly designates the vendor as a school official and restricts secondary use of student data.
The practical implication: before any staff member uses an AI tool that could touch student records — even for summarizing meeting notes about a student — that tool's vendor must have a qualifying data agreement in place. No agreement, no student data goes in. That rule needs to be written into your policy and enforced at the department head level, not left to individual judgment.
A workable staff AI policy for education distinguishes between use cases that carry compliance risk and those that don't. Not every AI use touches student data. A faculty member using an AI tool to draft a syllabus outline or summarize a journal article carries minimal institutional risk. The same faculty member using an AI tool to draft individual student feedback with names and grades attached is a different situation entirely.
Structure your guidelines around data sensitivity, not job function. The relevant categories are:
Faculty also need explicit guidance on AI use in grading and assessment workflows. If an instructor uses AI to assist in evaluating student work, the institution needs a clear position on whether that's permissible and under what conditions — because it directly affects academic integrity, not just compliance. Establish that position in the policy rather than leaving it to each department to figure out ad hoc.
For a broader framework on how employees adopt AI tools outside sanctioned channels, see our guide on what shadow AI is and why it happens — the same dynamics that drive shadow AI in corporate settings apply in academic institutions.
Research data sits in a different regulatory lane than student education records, and your policy needs to treat it that way. Depending on the research, you may be dealing with IRB-approved protocols under 45 CFR § 46 (the Common Rule), data governed by federal funding agency requirements (NSF, NIH, DoD), HIPAA if the research involves patient data, or export control regulations under the Export Administration Regulations (EAR) or International Traffic in Arms Regulations (ITAR) if the research involves controlled technology.
The core rule for research data and AI tools: the data classification that governs the research governs the AI tools that can touch it. If a research dataset requires IRB-level protections, those protections don't disappear because a researcher wants to use an AI tool to analyze it. The AI tool must meet the same security and access control requirements as any other system handling that data.
Practically, this means your policy should require researchers to route AI tool use on research data through your research compliance or IRB office — not IT alone, and not ad hoc. The question isn't just "is this tool secure?" but "does using this tool constitute a disclosure that our IRB protocol or data use agreement prohibits?"
Every AI tool that staff want to use needs to go through a vendor review before student or research data touches it. The review process doesn't need to be slow, but it does need to happen. Here's what the review needs to cover:
Build an approved tool list and keep it current. Staff should never be guessing whether a tool is cleared. If it's not on the list, it doesn't get used with protected data — period. For help building the policy framework around tool approval tiers, the AI acceptable use policy template guide covers how to structure tiered approval processes.
Administrative AI use (financial aid processing, HR workflows, facilities management, student records) and academic AI use (instruction, research, assessment) carry different risks and need different rules. Lumping them together in a single policy produces guidance that's either too restrictive for low-risk academic uses or too permissive for high-risk administrative ones.
The table below shows how the risk profile and applicable rules differ by use category:
| Use Category | Typical AI Tasks | Primary Compliance Risk | Vendor Agreement Required? |
|---|---|---|---|
| Administrative | Financial aid decisioning, student records queries, HR data analysis | FERPA, Title IX, state privacy laws | Yes — mandatory before any PII is processed |
| Academic (student-facing) | Grading assistance, personalized feedback, learning analytics | FERPA, academic integrity, bias in assessment | Yes — if student PII is involved |
| Academic (faculty-only) | Curriculum design, lecture drafting, literature review | Minimal if no student data is involved | No — if work product contains no PII |
| Research | Data analysis, literature synthesis, grant writing | IRB protocols, funding agency requirements, HIPAA, export controls | Yes — and IRB/compliance office review required |
Administrative staff typically handle the highest-risk data — student financial records, disciplinary files, health information — but they're often the least likely to have received formal compliance training on AI tools. Academic staff are more likely to have heard about AI policy through faculty governance conversations, but they may underestimate the compliance implications of using AI in grading or advising. Address both audiences explicitly in your training, not just in the written policy.
A policy that only restricts students while leaving staff AI use ungoverned isn't an AI policy — it's a gap waiting to become a breach notification.
An education institution staff AI policy doesn't need to be a 40-page document. It needs to answer four questions clearly for every employee who reads it: What can I use AI for without restriction? What requires an approved tool? What is always prohibited? And who do I ask when I'm not sure?
The policy should designate a specific person or office — not a generic "IT department" — as the point of contact for AI tool approvals and FERPA questions. It should include a current approved tool list with links, not just a promise that one exists. It should explain the vendor review process briefly so staff understand why ad hoc tool use isn't acceptable, rather than just telling them it isn't. And it should include an academic integrity section that states the institution's position on AI use in assessment — because that question will come from faculty, and the policy needs to give them an answer.
If you need a starting point that's already structured around these requirements, you can generate a tailored policy kit that covers data classification tiers, vendor review requirements, and staff-facing acceptable use language.
About Shadow AI Policy: We build AI acceptable use policy tools for HR and operations teams at 50–500 person companies. We publish guides on shadow AI, acceptable use policies, and AI governance, updated as regulations and AI tools change.
Under FERPA (20 U.S.C. § 1232g and 34 CFR Part 99), a violation occurs when an institution discloses personally identifiable information from a student's education record to a third party without a lawful basis. Pasting student names, IDs, grades, or disciplinary information into an AI tool whose vendor has no qualifying data agreement is a disclosure to a third party — and that's a FERPA violation regardless of whether any harm results. The test isn't whether the data was "misused"; it's whether it was disclosed without authorization.
De-identified data significantly reduces FERPA risk, but "de-identified" has to mean genuinely de-identified — no student ID numbers, no unique descriptors that could identify a specific individual, no combinations of data points (course section + grade + demographics) that make re-identification easy. If the data is truly stripped of all FERPA-covered identifiers, the FERPA concern drops substantially. That said, institutions still need a clear policy position on AI-assisted grading for academic integrity reasons, separate from the compliance question. Write both rules down so faculty aren't guessing.
At minimum, the agreement needs to designate the vendor as a school official under 34 CFR § 99.31(a)(1), restrict the vendor from using student data for any purpose other than the contracted service (no model training, no secondary analytics), specify data residency and subprocessor restrictions, include a breach notification timeline, and commit to data deletion on contract termination. A vendor's standard commercial terms of service almost never satisfy all of these. Request a FERPA-specific data processing addendum — most major enterprise AI vendors have one, but you have to ask for it.
FERPA protections attach to education records, not to students as individuals. Once a student graduates, their records remain subject to FERPA — the protection doesn't expire at graduation. An AI tool that processes alumni records containing academic history, disciplinary records, or financial aid data is still handling FERPA-protected information. The same vendor agreement requirements apply. The exception is data the institution collects post-graduation for alumni relations purposes that was never part of the education record — that data wasn't covered by FERPA to begin with.
Tailored to your industry and the AI tools your team uses. Free preview, $79 one-time or $149/mo with monthly updates.
Generate my policy kit →