Every AI tool on campus comes with fine print about student data, and few institutions have read it. This Cybersecurity Awareness Month, skip the generic advice. We break down the three things that decide whether an AI tool is safe for student records, plus a checklist your team can use this week.
When an AI tool processes a student record, the data leaves your systems and goes to the vendor's cloud. There it may be stored, logged, reviewed by vendor staff or used to train future models. AI data security in higher education comes down to three controls: where the data is processed, whether it is retained or used for training, and who can access it.
October is Cybersecurity Awareness Month, and this is the student data privacy question presidents and boards are putting to CIOs. In an EDUCAUSE survey of 1,960 higher education employees published in January 2026, 94% said they use AI tools for work, 56% use tools their institution does not provide, and only 54% know of a policy that guides that use. Student data is already moving. What matters is whether you can see where it goes.
Where student data goes when an AI tool reads it
An advisor pastes a degree audit into a chatbot and asks for a summary. Here is what happens next.
- The prompt, with the student's name, ID and grades, leaves the browser and travels to the vendor's API.
- The model processes it on the vendor's infrastructure, or on a cloud provider the vendor rents from, in a region you may not have chosen.
- The prompt and the response are written to logs. Retention can run from zero days to indefinitely, depending on the product tier.
- Depending on the terms, the content may be sampled for human review or added to training data.
- Sub-processors that handle hosting, monitoring or safety filtering may also receive it.
With a free or personal account, no contract with your institution governs any of this. With an enterprise or education agreement, most of it can be controlled. The same model can be a compliance problem or a managed service, depending on how it was bought.
What FERPA does and does not say about AI tools
Questions about FERPA and AI start from one fact: the law was written in 1974 and does not mention AI. It still applies, because a prompt that contains personally identifiable information from an education record is a disclosure.
What it says. An institution can disclose records without consent to a vendor that qualifies as a school official. The Student Privacy Policy Office sets out the conditions:
- The vendor performs a function the institution would otherwise use employees for.
- The vendor is under the institution's direct control with respect to the use and maintenance of the records.
- The vendor uses the data only for the purpose for which it was disclosed.
- The vendor meets the legitimate educational interest criteria in your annual FERPA notification.
What it does not say. FERPA sets no technical standard. It does not tell you which region is acceptable, how long logs may be kept, or whether model training is an allowed purpose. You establish direct control through contract terms and configuration. A vendor's "FERPA compliant" badge does not do it for you.
Two practical consequences follow:
- A staff member who puts student records into a personal AI account has no contract behind that disclosure, so the school official exception is hard to claim.
- Financial aid data carries added obligations under the GLBA Safeguards Rule, so AI tools that touch it belong in your written information security program.
This is general information, not legal advice. Involve counsel before you set policy.
The three controls that matter for AI data security in higher education: residency, retention, access
Residency: where the data is processed
Know the cloud provider, the region and the sub-processors. Ask whether the model runs in a shared multi-tenant service or in an environment dedicated to you. Public institutions may also face state rules on where data can sit.
Retention: what is kept, and whether it trains a model
Separate three things: prompt and output logs, uploaded files, and training use. Each can have a different default. Aim for the shortest retention that still supports your audit needs, a written exclusion from model training, and deletion on request and at contract end.
Access: who can see it
Access has two sides. On the vendor side, ask which employees can view prompts and under what conditions. On your side, the AI tool should inherit existing permissions. If an advisor cannot see financial aid data in the SIS, the assistant should not surface it. Agents that can write to systems need tighter limits than assistants that only read, as we cover in Guardrails for Autonomous Agent Tool Execution.
Privacy-first AI architecture: keeping sensitive data inside your environment
Policy tells people what not to do. Architecture makes the safe path the easy one. Four patterns do most of the work:
- Private deployment. Run the model inside your own cloud tenant or through a dedicated enterprise endpoint, so prompts stay within your security boundary.
- Data minimization. Mask or tokenize names, IDs and other identifiers before the prompt is sent. Restore them in the response only when needed.
- Permission-aware retrieval. When the AI pulls records to answer a question, it checks the user's role first and returns only what that user is entitled to see.
- Central logging. Route AI traffic through one gateway so you have a single record of who asked what, which data was used and which model answered.
In higher education, sensitive data sits mainly in three places: the SIS, the LMS and the CRM. Governance designed around those systems is easier to enforce than a generic AI policy. That is how the Talentus Global EdTech practice approaches its higher education technology services. Our earlier post, FERPA-Compliant AI: A Guide for CDOs, goes deeper on the technical side.
A data governance checklist for AI
Data governance for AI does not need a separate process. AI governance in higher education works best as an extension of programs you already run. The 2026 EDUCAUSE Top 10 makes the same point under "Knowledge Management for Safer AI", and the NIST AI Risk Management Framework offers a voluntary structure built on four functions: Govern, Map, Measure and Manage.
For institutions that need help putting these controls into operation, Talentus Global's AI practice offers AI governance and security services: responsible AI frameworks, model monitoring, data privacy controls and guardrails.
Five questions to ask any AI vendor
- Where is our data processed and stored, and which subprocessors receive it?
- Are our prompts, files, outputs or logs used to train or improve models? Show us the contract clause.
- How long do you retain prompts and outputs, and can we set that period to zero?
- Which of your employees can access our data, under what conditions, and how is that access logged?
- Will you sign as a school official under FERPA, accept our direct control over education records, and delete our data when the contract ends?
If a vendor cannot answer all five in writing, do not send it student data.
Next step
For a wider view of where AI is heading on campus, the "Agentic AI in Higher Education" report is available on the Talentus Global EdTech site.
Writing or revising your policy this quarter? Talk to an EdTech specialist about your AI data policy.
