How to Write an AI Vendor Exit and Data Deletion Plan for Universities

Why Universities Need a Formal Exit Process for AI Vendors

Universities now route admissions review, advising communication, research workflows, and administrative functions through third-party AI vendors. Each of these integrations typically involves API keys, service accounts, or AI agents with standing access to student information systems, research repositories, or learning management platforms. When a vendor relationship ends, many institutions lack a defined process to confirm that access has actually been revoked and that data has actually been destroyed.

Without a formal exit plan, the university is left depending on the vendor's own claims rather than institutional evidence. This creates exposure under FERPA's school-official provisions, which require that any party granted access to personally identifiable information from education records remain under the institution's direct control regarding use, maintenance, and redisclosure of that data. An enforceable exit plan closes this gap by treating offboarding as a controlled, evidenced process rather than a contractual afterthought.

Defining the Scope: What the Plan Must Cover

A university AI vendor exit and data deletion plan should address three categories of data separately:

• Student education records covered by FERPA
• Research data that may carry retention or deletion terms set by external grants
• Administrative or operational data generated by the vendor's system itself, including logs and derived outputs

FERPA does not prescribe a specific technical deletion standard, so the institution must define destruction and return-of-records obligations through its own contract terms and internal policy, rather than assuming a default standard applies. The plan should also explicitly cover AI agent components: any autonomous or semi-autonomous processes the vendor operates against university systems, including their credentials, tool-call permissions, and integration points, since these often persist independently of the vendor's primary user-facing application.

Access Revocation and Agent Identity Deprovisioning

Revocation should begin at university-controlled systems. Disable vendor accounts, API keys, and OAuth tokens at the identity provider first, then confirm corresponding disablement inside the vendor application. Service accounts and AI agent identities should be deactivated through the university's own IAM system so agent credentials, tool-call permissions, and integration points do not outlive the contract.

Structuring Audit Logs and Access Records for Exit Verification

Audit evidence is only useful if it survives the vendor relationship. Audit and accountability controls call for generating, protecting, and retaining records sufficient to support after-the-fact investigation of security-relevant events, which means logs cannot depend on continued vendor cooperation to remain accessible.

Universities should store audit logs covering vendor and AI agent authentication events, data access calls, and tool invocations in infrastructure the institution controls, separate from the vendor's environment. Where AI agents are integrated with student information systems, routing that access through university-managed identity and access management, rather than vendor-issued credentials, makes it possible to review authentication and permission history directly rather than requesting it from the vendor after the relationship has ended. This structure also supports the accountability and documentation practices described in NIST's AI Risk Management Framework for managing third-party AI system risk across the full lifecycle, including at exit.

FERPA and Data Classification Considerations

Because FERPA's school-official exception requires that vendor access to education records remain under institutional control, the exit plan should explicitly state how deletion obligations map to different data types.

• Student education records fall under FERPA control requirements.
• Research data may be governed by separate grant-imposed retention or deletion terms that do not align with FERPA timelines and should be addressed independently in the plan.
• Administrative data generated by the AI system itself, including logs the vendor retained for its own operational purposes, should also be identified so the university knows whether that data is subject to the same destruction commitment as the underlying education records.

Documenting this classification before termination begins prevents disputes over what data was actually in scope for deletion.