University AI governance is an operating discipline, not a list of tools. It gives leaders a repeatable way to decide which uses are appropriate, who is accountable, what evidence is required before a pilot expands, and how people can question a decision. The aim is to enable useful work while keeping academic judgement, student support, and institutional responsibility visible.
This framework is for a university leadership group, faculty governance body, or cross-functional AI committee. For practical teaching, learning, and service applications, see the companion university AI use-cases guide.
Establish decision rights before selecting tools
An institution needs a small group with authority to approve, pause, or retire AI-supported workflows. The group does not need to perform every review itself, but it must know who owns each decision.
| Decision area | Accountable role | Core question |
|---|---|---|
| Educational value | Academic sponsor | Does this solve a defined teaching, learning, or service problem? |
| Day-to-day operation | Process owner | Who monitors outputs and supports users? |
| Data and access | Information-security or privacy lead | What information is necessary, and who may access it? |
| Assessment and integrity | Academic-quality lead | Can the use affect grades, progression, or allegations? |
| Accessibility and inclusion | Accessibility lead with users | Can people use, understand, and challenge the workflow? |
| Procurement | Procurement and legal reviewers | Are terms, retention, support, and exit arrangements understood? |
Name one executive sponsor and one operational owner for every approved use. A committee can approve a direction, but it cannot be the person who checks an inaccurate answer on a student-facing service or explains an escalation. Publish an internal route for staff and students to raise concerns without having to identify the technical team first.
Maintain a use-case inventory and risk tiers
Start with an inventory, including informal pilots. Record the purpose, user group, data involved, supplier or model, human reviewer, and current status. This turns scattered experimentation into something leaders can assess.
A simple tiering model is often enough:
- Low risk: drafting, translation, brainstorming, or summarisation using material that is approved for the tool. Users remain responsible for the result.
- Moderate risk: recommendations, conversational support, or analysis that can influence staff action. A trained person reviews outputs and users can reach a human.
- High risk: uses connected to grades, academic misconduct, progression, admissions, wellbeing, financial hardship, disability support, or other consequential decisions. These need a documented case for use, stronger testing, explicit human decision-making, and a route to challenge outcomes.
Risk is not just a technical label. A tool can be low risk in a lecturer’s private preparation workflow and high risk when its output is shown to students as authoritative advice. Reassess the tier whenever the purpose, data, audience, or integration changes.
Set data, privacy, integrity, and accessibility boundaries
Write the boundary in plain language before a pilot begins. Specify the minimum data needed, which identifiers must be removed or avoided, what users must not enter, where data may travel, and whether outputs are retained. Confirm the supplier’s data-processing terms and the institution’s exit plan; do not assume a consumer setting is suitable for institutional information.
Academic integrity also needs a use-specific response. Define permitted assistance, required disclosure where relevant, and how faculty will explain the boundary in a module. A detection signal or automated flag is not proof of misconduct. Any investigation should be led by people using an established academic process, with context and an opportunity for the student to respond.
Accessibility is equally practical: test whether the workflow works with assistive technologies, supports clear language, offers a non-AI route, and does not exclude users with limited connectivity or confidence. An accessible alternative is part of the service design, not an afterthought.
Role-based permissions are a foundation for this work. The guide to role-based access in schools offers a useful starting point for asking which roles need which records and why.
Make procurement part of the governance gate
Before buying or connecting a tool, require a short procurement brief. It should state:
- the defined institutional problem and intended users;
- the data categories and integrations proposed;
- how access is controlled and reviewed;
- what the provider can retain, use, or share under the agreement;
- support, incident notification, continuity, and termination arrangements;
- how outputs, prompts, and activity can be inspected when needed; and
- who can approve a material change to the service.
Procurement should not be a single approval at the end of a pilot. If a pilot adds a new integration, expands to a different student group, or changes the decision it influences, bring it back through the relevant gate.
Design pilots to learn, not merely to launch
Choose one bounded problem with a baseline. For example: reduce the time spent answering routine enrolment questions while preserving a clear human route, or help lecturers prepare formative practice materials while maintaining review. Avoid beginning with a broad promise to “transform learning.”
For every pilot, write a one-page charter with the following fields:
| Field | What to define |
|---|---|
| Outcome | The user problem and the decision the pilot will inform |
| Scope | Cohort, service, duration, and excluded uses |
| Human oversight | Who reviews, intervenes, and makes final decisions |
| Safeguards | Data boundary, disclosure, accessibility alternative, and escalation path |
| Measures | Usefulness, error patterns, workload, accessibility feedback, and trust |
| Stop conditions | What would pause the pilot immediately |
Invite the people affected to test it early: faculty, students, advisors, service staff, and technical administrators. Test ordinary cases as well as unclear requests, missing data, harmful suggestions, and attempted misuse. A pilot that finds problems before scale has succeeded in one of its most important jobs.
Review results, incidents, and changes continuously
Set a review rhythm before launch. The process owner can check day-to-day exceptions; the governance group can review pilot evidence and material changes on a scheduled cadence. Keep a lightweight register for incidents and concerns: what happened, impact, immediate action, root cause, owner, and follow-up date. Do not treat a user report as a defect in the user.
Change review matters because models, prompts, integrations, and organisational contexts change. Reopen a review when the supplier materially changes the service, a new dataset is connected, the workflow moves into a higher risk tier, or feedback points to unequal outcomes. Scaling should be a positive decision supported by evidence, not the default end point of a pilot.
A practical first 90 days
- Form the accountable group and publish its remit.
- Capture existing AI uses in an inventory and assign preliminary risk tiers.
- Approve a clear baseline policy for data, integrity, accessibility, and human oversight.
- Select one or two bounded pilots with owners and measurable learning goals.
- Run a structured review, document decisions, and share the learning with affected teams.
Connected institutional systems can make governance easier by clarifying ownership, records, and access, but they do not replace governance. The connected-campus management guide explains the operational foundation that supports a more coherent university environment.