Arizona State University signed an enterprise agreement with OpenAI in January 2024, becoming the first university to partner with the company for campus-wide access to ChatGPT. The deal was announced as a productivity play: course design help and grant writing support. But the first question from privacy officers was not what the tool could do. It was where the prompts went.

That question now defines university AI administrative rollouts. Admissions offices, financial aid, the registrar, human resources, and campus IT are testing AI assistants for routine work. Each pilot brings a new vendor, a new data-flow diagram, a new set of user permissions, and a new decision about whether student or employee records can leave institutional control.

University of Michigan took a different route in 2023, building its own generative AI tools on Microsoft Azure so that data stays inside the university's tenant. That approach reduces one risk but still leaves contract terms, access controls, and retention schedules to be written.

The vendor contract is the privacy policy that matters

Most administrators think about privacy as a policy document. The binding decisions happen earlier, in procurement. A vendor's terms of service often say it can use inputs to improve models, retain data for up to two years, rely on subprocessors in other countries, and process support tickets through third-party tools. A university privacy office can strike those clauses, but only if someone sends the contract for review before the pilot starts.

A registrar's office manager at a large European university (call her Ms. V) told me her team's new AI chatbot for enrolment questions was already live when the data protection officer found the vendor had subprocessors in four countries. The university paused the rollout for six weeks to sign a data processing agreement. The chatbot stayed paused, and the office went back to email tickets.

That is the pattern privacy officers describe: review lags deployment. The exception is the university with a standard AI addendum that fixes data retention, prohibits training on customer data, requires breach notification within 72 hours, and lists all subprocessors. If a vendor will not sign it, the tool does not launch.

FERPA and GDPR are older than the tools, not weaker

The legal framework is not new. In the United States, the Family Educational Rights and Privacy Act (FERPA) protects education records and generally requires written consent before student records are shared with a third party, unless a school-designated exception applies. Vendors receiving data under the school official exception must be under the university's direct control. The word 'control' is doing heavy work when an AI vendor uses prompts to tune models or keeps data for its own purposes.

In the European Union and the United Kingdom, the General Data Protection Regulation (GDPR) requires a lawful basis for processing personal data, a Data Protection Impact Assessment (DPIA) for high-risk processing, contractual clauses that bind processors, and a record of processing activities. A serious GDPR violation can cost an institution up to 20 million euros or 4 percent of annual global turnover, whichever is higher. That is a ceiling, not a normal fine. But the assessment that would have caught the problem costs a small fraction of a breach response.

The U.S. Department of Education's Student Privacy Policy Office maintains guidance on FERPA and AI in schools, while the European Commission's data protection pages detail transfer rules that apply to many cloud AI services.

What campuses are actually rolling out

Administrative AI covers more ground than the public ChatGPT interface. Financial aid offices use document-reading models to flag incomplete files. HR departments test resume ranking tools. The registrar applies natural language processing to transcript questions. Campus security departments pilot pattern recognition on building access logs.

OpenAI's ChatGPT Edu product, launched in 2024, is pitched directly to universities with the claim that conversations and data are not used to train models. That contractual framing matters, but it does not answer where the data sits during processing or which subprocessors handle a support ticket.

At Arizona State, the rollout started with course-facing uses and then moved into administrative tasks such as grant proposal drafting. Other campuses began with IT helpdesk tickets, where the risk is lower because the data is mostly device and service information. The higher-risk placements are in admissions and financial aid, where small errors have legal consequences.

Academic integrity policies are already splintering on the instructional side, as this publication detailed in its look at AI academic integrity rules. Administrative rollouts are repeating the same pattern, but with student financial and immigration records in the prompt window, the cost of a mistake is higher.

Five questions that should stop a pilot

• Will the vendor use university data to train or improve its models, now or later?
• Where is data stored during processing, and in which countries do subprocessors operate?
• What is the retention period for uploaded documents and conversation logs?
• Which staff are authorised to see prompts, outputs, and support tickets containing student data?
• What happens to university data if the vendor is acquired or terminates the contract?

Any answer that is absent, vague, or contradicted by the vendor's privacy page is a reason to stop the procurement review until the legal office resolves it. Universities that move forward without written answers are accepting vendor defaults, and vendor defaults rarely favour the data subject.

Why a paused rollout is not a failure

Pausing a vendor is often framed as administrative delay. It is better understood as the system working. Ms. V's pause is not rare. Procurement offices have begun inserting AI-specific addenda that require vendors to list every subprocessor, to keep university data out of model training, to return or delete records at contract end, and to notify the university within a set number of hours of a breach.

Those addenda are sometimes called Data Protection Addenda or AI Processing Exhibits. A university that has one is easier to audit, because the obligations are explicit. A university without one will discover midway that the vendor's privacy page said one thing and the order form said another.

Legal teams at several institutions now insist on a documented data flow diagram before any pilot. That diagram answers four questions: what data enters the tool, where the data is stored, who can see it, and how long it is kept. If the vendor cannot produce the diagram, the review stops.

In Canada, the analysis runs through provincial legislation, including British Columbia's and Ontario's Freedom of Information and Protection of Privacy Acts, which impose similar controls on public bodies storing personal information outside the country. A vendor hosted only in the United States can trigger a separate review north of the border.

In July 2024, the U.S. Department of Education's Office of Educational Technology issued a developer guide that called for trust and safety practices in AI tools used in education. The guidance put the burden on vendors to explain data use, not on schools to excavate it from a 40-page terms-of-service document.

What this means for your lab or office

The fix is not a policy document. It is a sequence of small checks before and after adoption. If your department is piloting an AI tool, read the vendor's terms for four clauses: use of inputs for training, retention period, subprocessor list, and breach notification deadline. Ask your institutional privacy office whether a review has been completed. If the vendor will not sign the university's standard addendum, that is a finding, not an obstacle to be ignored.

A lab manager I worked with (call him Dr. P) kept a one-page sheet for every new online service: data categories, access level, deletion schedule, and retention owner. When his university rolled out an AI note-taking assistant for research meetings, he filled out the sheet in ten minutes and refused to upload student records because the retention clause said indefinite. The rollout continued for non-record data, and the legal office amended the contract.

The same habit works in a research group. One shared folder, one data inventory, one retention note, and one person responsible for checking the next vendor. It takes the abstract question of whether an AI tool is safe and turns it into something inspectable.

A concrete next step

Pick one administrative process you control, such as admissions email triage or transcript question routing. Write down the data categories involved and whether FERPA, GDPR, or a provincial privacy law such as British Columbia's FIPPA applies. Then ask the vendor one question in writing: will you use our data to train or improve your models? Keep the answer in the procurement file. If the answer is yes, or the vendor will not answer, the next move is a contract clause, not a policy speech.

Photo by Steve A Johnson on Unsplash