AI Governance in Higher Education: Security and Student Data Readiness

AI is already normal on campus

The clearest fact about AI in higher education is that the adoption curve is already ahead of the policy curve. Lumina Foundation and Gallup's 2026 State of Higher Education research found that 57% of U.S. associate and bachelor's degree students use AI daily or weekly for schoolwork, while only 13% say they never use it.¹²³

The same study found that 53% of students say their institution discourages or prohibits AI use in coursework, and 52% report that at least some classes lack clear guidance on specific use policies. That gap matters because students are already using AI for exactly the workflows where clarity is needed: understanding difficult material, checking answers, improving writing, summarizing notes, and generating ideas.¹²³

The staff side shows the same pattern. A 2026 EDUCAUSE survey of 1,960 higher education respondents found that 94% had used AI tools for work in the previous six months, but only 54% were aware of policies and guidelines meant to guide that use. Sentiment is not anti-AI: 81% reported enthusiasm or a mix of caution and enthusiasm. The operational problem is uneven governance.¹²³

The governance gap is measurable

EDUCAUSE's 2025 AI Landscape Study shows that campus leaders are moving AI from experimentation into strategy. In a summary of the study, GovTech reported that 57% of nearly 800 higher education respondents said their institution considers AI a strategic priority, up from 49% the prior year.⁴

The same report shows why governance cannot be treated as an afterthought. More than half of institutions were already using AI to support curriculum design (54%) and administrative workflow automation (52%), but only 39% had AI-related acceptable use policies. Only 9% said their cybersecurity and privacy policies adequately address AI-related risks.⁴

That is the core governance issue: AI usage is no longer theoretical, but the policy stack around access, privacy, prompt behavior, approved use cases, and human review is still catching up. For student-success software, that gap has to be closed inside the product and the implementation model, not left to a broad AI policy document alone.

The security issue is a new control surface

AI assistants and agents inherit the old security problems - privacy, access control, data retention, vendor review, credential misuse, and human error - and add LLM-specific risks. OWASP's 2025 Top 10 for LLM and generative AI applications includes prompt injection, sensitive information disclosure, supply chain risk, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption.⁵⁶⁷

The practical lesson is that a prompt is not a security boundary. The UK National Cyber Security Centre warns that current LLMs do not enforce a hard separation between instructions and data inside a prompt, and that prompt injection may not be fully mitigated the way SQL injection can be. The mitigation strategy is therefore to reduce likelihood and impact with secure design, deterministic safeguards, monitoring, and constrained tool access.

This matters in higher education because the underlying cybersecurity environment is already sensitive. Verizon's 2025 Data Breach Investigations Report lists 1,075 Educational Services incidents and 851 confirmed data-disclosure breaches; System Intrusion, Miscellaneous Errors, and Social Engineering represent 80% of Educational Services breaches. AI governance has to account for that reality: identity, permissions, staff mistakes, phishing, and privileged workflows are part of the AI risk surface.⁵⁶⁷

• Prompt injection and jailbreaks: a student, staff member, or retrieved document may try to override instructions or expose hidden context.
• Sensitive information disclosure: a model may reveal private student data through responses, logs, summaries, or tool outputs if access is too broad.
• Over-scoped retrieval: an AI assistant connected to too much institutional data can retrieve information that the current user should not see.
• Excessive agency: an AI system with broad permission to send messages, update records, or trigger workflows can create real operational harm if it is manipulated.
• Misinformation: plausible but wrong advising, financial aid, or policy answers can damage student trust and create compliance risk.

For student data, FERPA sets the operating model

For higher education, AI security starts with student data governance. Department of Education guidance on the school official exception says a third party handling education records must perform an institutional service, remain under the institution's direct control for use and maintenance of records, and use personally identifiable information only for the purpose for which it was disclosed.

The Department also warns that online tools can introduce security or privacy vulnerabilities and should be reviewed with IT before use. That maps directly to AI procurement: a school should know what data enters the system, who can access it, whether it is used for model training, how long it is retained, how deletion works, and what the vendor is prohibited from doing with it.

The safest pattern for student-facing communication is governed autonomy. AI can help classify, summarize, draft, and triage. The institution's policy controls and human workflows should decide higher-impact actions, especially when a message points to financial stress, wellness concerns, academic confusion, belonging risk, or stop-out intent.

• Campaigns should be approved and purpose-bound before outreach starts.
• Student replies should be logged with context, not scattered across personal inboxes.
• Opt-outs, sensitive topics, and high-risk language should trigger deterministic handling rather than free-form AI discretion.
• AI-generated sentiment, summaries, and suggested next steps should remain reviewable by authorized staff.
• No high-stakes student outcome should depend on an unreviewed AI output.

How Edvise mitigates the risks

Edvise approaches AI security as an engineering control problem, not a disclaimer problem. Our mitigation model starts with the assumption that AI will be useful only if the institution remains in control of student data, staff permissions, outbound actions, and review workflows.

The practical mitigation stack has four layers: data governance, access control, AI workflow constraints, and operational assurance. That means we are not relying on a model prompt to protect sensitive records. We pair AI features with conventional security controls and product-level workflow boundaries.

• Data governance: Edvise acts as a school official under FERPA when handling education records, keeps student data under institutional control, and uses data for the approved institutional service rather than unrelated commercial purposes.
• Purpose limitation: implementations are tied to approved workflows such as advising, retention, enrollment outreach, case coordination, and student-success analytics.
• Least-privilege access: role-based access, SSO support, scoped permissions, and institution-specific configuration limit which staff can see which student context.
• Scoped AI context: AI workflows are designed around the minimum context needed for the task, such as a Pulse reply, advisor summary, risk signal, campaign workflow, or case handoff. AI does not need unrestricted campus-wide data access to be useful.
• Retrieval controls: when knowledge retrieval is used, the retrieval surface should be constrained by the user's permissions, the approved use case, and the configured knowledge sources.
• Deterministic safety rules: opt-outs, sensitive topics, and high-risk language should trigger predefined handling and escalation paths rather than free-form model discretion.
• Human review: Edvise treats AI outputs as decision support. Staff retain authority over high-impact recommendations, student-facing escalations, advising decisions, financial aid routing, and care coordination.
• Action constraints: AI-assisted drafts, classifications, and suggested next steps are separated from higher-impact actions that require policy checks or human approval.
• Auditability: conversation history, AI analysis, staff activity, access events, and AI-assisted workflow actions should be reviewable by authorized teams.
• Security basics: encryption in transit and at rest, documented retention and deletion expectations, exportable records, vendor-security review materials, and a public Trust Center support institutional due diligence.

Responsible AI is a lifecycle, not a launch checklist

NIST's Generative AI Profile reinforces a core principle: AI risk management has to span design, deployment, measurement, and ongoing governance. In higher education, that means the control model cannot stop after procurement. Schools need to know how the system behaves after launch, who reviews outputs, where escalations go, and how issues are reported.

For Edvise, that lifecycle shows up in product and operating decisions: visible conversation history, reviewable AI analysis, controlled handoffs, security documentation, issue reporting, and a public Trust Center. Security should not be something a school discovers only during procurement. It should be easy to inspect from the first website visit.

The questions schools should be able to answer

A strong AI governance conversation should become specific quickly. The goal is not to slow down useful AI adoption. The goal is to make sure adoption is legible to IT, legal, security, advisors, student-success leaders, and the teams accountable for student outcomes.

• What student data does the system need, and what data is explicitly out of scope?
• Is student data used to train general models, or only to provide the approved institutional service?
• How are roles, permissions, and least-privilege access enforced?
• What happens when a student asks a sensitive question or expresses crisis-level need?
• Can the institution review conversation history, AI summaries, prompts, tool use, and workflow actions?
• What actions can the AI take automatically, and which require human approval?
• How do retention, deletion, exports, and incident response work?
• Where can IT, legal, and security teams review documentation before procurement?

The standard we are building toward

The data points in one direction: AI is already part of higher education, and campus sentiment is more nuanced than simple enthusiasm or rejection. Students and staff are using it because it helps them move faster, understand material, summarize information, and reduce administrative drag. Institutions are still working through the rules.

That is the standard Edvise is building toward: AI that helps staff move faster without weakening the institution's control over student data. Pulse, advising workflows, analytics, and retention operations should all be more useful because they are governed, reviewable, and bounded by the institution's operating rules.

This article is operational guidance, not legal advice. Schools should validate FERPA, procurement, and security decisions with their own IT, legal, and compliance teams.