FERPA-safe AI: what to settle before a student-facing assistant ships

Why this needs its own governance conversation

FERPA obligations shape what a student-facing AI tool is allowed to access and retain — this isn't a general data-privacy afterthought, it's a design constraint that has to be settled before build starts: define which student records a tool may access, how long it retains them and who reviews automated output — before build starts.

Governance: what to define up front

• Scope of access. Exactly which student records (enrollment, engagement, assessment, support-ticket history) the assistant may read — and which it explicitly may not.
• Retention. How long any conversation or derived data is kept, and the deletion process.
• Human oversight. Where a human reviews or can override the assistant's output, especially for anything that affects a student's academic standing or support pathway.
• Vendor/model boundaries. Whether any underlying AI model is trained on student data — ABM's stated position is "no training on client data without written agreement."

Data handling

Minimum-necessary access, explicit retention limits, and documented data flow between the assistant and any system of record it touches (SIS, LMS, advising platform). This mirrors the FERPA-aware data-boundary approach already stated for EdTech work generally.

Vendor questions to ask before selecting a tool or partner

• What student data does the assistant access, and can that scope be restricted per use case?
• Where does data reside, and is it used to train any model beyond this engagement?
• What's the retention and deletion policy, and can it be configured to match institutional policy?
• Is there a human-in-the-loop path for consequential outputs?
• What's the audit trail — can the institution review what the assistant saw and said?

Human oversight

Any output that could affect a student's academic standing, financial aid, or support pathway should have a defined human-review point — the assistant should escalate, not decide unilaterally, on anything consequential.

Risks to plan for

• Scope creep: an assistant originally scoped to FAQ-style questions gradually being given access to more sensitive records without a corresponding governance review.
• Vendor data-use terms that don't match institutional policy — this needs verification before selection, not after deployment.
• Absence of an audit trail, making it hard to demonstrate FERPA-consistent handling if questioned.

Practical checklist

• Data-access scope defined and documented
• Retention and deletion policy defined
• Human-review point(s) identified for consequential outputs
• Vendor/model data-use terms reviewed against institutional policy
• Audit trail available
• General counsel has reviewed the above before launch

Next step

Describe the student-facing use case you're considering and what systems it would need to touch. We'll help you work through the governance checklist above before any build conversation starts.