Most institutions still treat AI vendor data governance as a legal afterthought. A data governance checklist for AI vendors in higher education typically shows up after the pilot has already launched, when IT or general counsel is asked to review a contract that a department has already fallen in love with. By then, the leverage is gone. This article reframes data governance as a gate at the procurement stage, not a compliance chore bolted on after the demo, and gives administrators a checklist they can actually use before a signature.
AI Vendor Data Governance in Higher Education: Why It Belongs in Procurement, Not Compliance
Procurement teams at most universities are staffed and trained to evaluate FERPA compliance for a student information system. They are not staffed to evaluate what happens when a chatbot vendor trains a foundation model on transcripts of student advising conversations.
That gap matters because AI tools are being adopted faster than governance processes can keep pace. A VP of Student Affairs wants a 24/7 advising assistant live by the fall term. A provost wants an AI writing tool rolled out before accreditation review. The sales cycle moves in weeks. A proper data governance review, done well, takes longer than that, which is exactly why it gets skipped or rubber-stamped.
EDUCAUSE has been explicit about this risk in its ongoing AI governance work: institutions need structured frameworks for evaluating AI tools before adoption, not retrospective audits after a tool is embedded in daily operations. The same logic that applies to a student information system vendor, financial exposure, reputational risk, regulatory obligation, applies with more urgency to AI vendors, because the data flows are less visible and the failure modes are less familiar to procurement staff. Strong AI vendor data governance in higher education depends on getting this sequencing right from the start.
This is also where shadow AI becomes a real problem. A single department adopts a tool without procurement review because it solved an immediate need. No one evaluates the data governance terms because no one in central IT knows the tool exists. Multiply that across a campus of a few hundred departments and the institution has dozens of undocumented data relationships it cannot account for in a breach investigation or a FERPA audit.
The Data Governance Checklist for AI Vendors in Higher Education: What to Ask Before You Sign
An effective AI procurement checklist for universities needs to be specific enough to survive a sales conversation. Vague questions get vague answers. Here is what belongs on the list, with the follow-up that actually tests the answer.
Where is student data stored, and for how long? Get the physical or cloud region, not just "secure servers." Ask for the data retention schedule in writing, and confirm it matches your institution's own retention policy, not the vendor's default.
Does the vendor train models on institutional data? This is the single most consequential question on the list. Ask directly whether student interactions, prompts, or uploaded materials are used to train or fine-tune any model, including aggregate or "de-identified" training. Then ask whether that use can be contractually prohibited, not just disabled by a settings toggle the vendor controls.
Who has access to raw conversation or interaction logs? Named roles, not job categories. Is there a signed data processing agreement (DPA) that specifies subprocessors, and does the vendor disclose every subprocessor with access to that data?
What happens to data if the contract ends or the vendor is acquired? Mergers and acquisitions are common in the ed-tech and AI vendor space. Ask for a data destruction clause with a specific timeline, and ask what contractual protections survive a change of ownership. A verbal assurance does not survive an acquisition. A clause does.
Is there a documented incident response process, and has it been tested? Ask for the vendor's most recent breach notification timeline commitment in writing, and ask when they last ran a tabletop exercise. "We have a plan" without a test date is not a plan.
Is the tool designed to minimize data collection in the first place? Some vendors reduce institutional risk by design rather than by policy. For instance, a PHI-free design for SMS channels is one example of architecture that avoids collecting protected health information rather than relying solely on a policy promise to protect it (see Confide's approach to student health and support services). That distinction, risk reduced by design versus risk managed by policy, is worth asking every vendor to address directly.
FERPA, State Privacy Laws, and Where AI Vendors Fall Short
FERPA was written for a world of paper records and school-operated databases. It still applies to third-party vendors acting as "school officials" with a legitimate educational interest, which is the legal basis most AI vendors operate under. But FERPA's framework assumes a defined, auditable data relationship. Generative AI tools complicate that assumption because the vendor may not be able to specify exactly how a given input influences model behavior, which makes the "legitimate educational interest" boundary harder to enforce in practice. State law has moved faster than federal law here. California's Student Online Personal Information Protection Act (SOPIPA) and its successor amendments restrict targeted advertising and profiling based on student data. Colorado's Student Data Transparency and Security Act requires specific data privacy agreements between institutions and vendors, with public disclosure requirements. Other states have adopted similar statutes with different enforcement mechanisms and different definitions of what counts as covered student data.
The practical problem for administrators: an AI vendor compliant with FERPA is not automatically compliant with every state law that applies to your student population, especially for institutions enrolling students across state lines or operating online programs. NIST's AI Risk Management Framework is increasingly used by institutions as a structuring tool here, not because it is legally binding, but because it offers a common vocabulary for assessing AI-specific risk categories (data governance, transparency, accountability) that FERPA and state statutes don't fully anticipate. Mapping a vendor against NIST's framework alongside your FERPA and state law obligations gives procurement a more complete risk picture than checking FERPA compliance alone, and it strengthens overall AI vendor data governance in higher education settings where multiple state jurisdictions may apply.
Red Flags: Vendor Answers That Should Stop a Deal
Certain answers should end a procurement conversation regardless of how strong the product demo was.
A vendor that cannot name its subprocessors, or treats subprocessor disclosure as proprietary, is a red flag. Your institution is contractually responsible for data handling even when a breach occurs at a subprocessor three steps removed from the vendor you signed with. A vendor that describes its data use policy only in marketing language ("we take privacy seriously") rather than contract language is a red flag. Marketing language is not enforceable. Only the contract is. A vendor that cannot produce a DPA, or asks the institution to rely on a general terms-of-service agreement instead, is a red flag. General terms are written to protect the vendor, not the institution. A vendor that hedges on whether institutional data trains their models, rather than giving a direct yes or no, is a red flag. Hedging here usually means the answer is yes, and the vendor knows it's a liability. A vendor with no documented incident response timeline, or one that has never tested that process, is a red flag. An untested plan is a hope, not a control.
Building Accountability After the Contract Is Signed
A signed contract is not the end of governance, it's the start of an operational relationship that needs monitoring. Assign a named owner, not a committee, responsible for tracking vendor compliance against the contract terms on a recurring schedule, not just at renewal.
Build a lightweight audit into the relationship: request an annual attestation that the vendor's data practices still match what was contracted, and reserve the right to request a third-party security assessment. Track every AI vendor relationship in a central registry, not departmental spreadsheets, so the institution has one place to answer the question "which vendors have access to student data" during an audit or after a public incident. This is the operational core of AI vendor data governance in higher education: ongoing tracking, not a one-time review.
Review the contract against new state legislation annually. Student data privacy law is one of the fastest-moving areas of state legislation right now, and a contract signed two years ago may no longer reflect current obligations.
Administrators evaluating a new advising or support tool can use this same framework to compare vendors side by side before a contract is drafted. Some platforms are built around a data-minimized approach to student support, and reviewing one as a reference point, among others, can help clarify what design-level risk reduction looks like in practice.
