AI governance after the AI policy

Most Australian universities now have established AI policies. These policies typically set out what staff and students can and cannot do with AI, and many were developed in response to academic integrity concerns and guidance from the Tertiary Education Quality and Standards Agency (TEQSA).

But over the past year, university leaders have increasingly shifted their focus from AI use towards broader strategic and governance questions. This reflects a recognition that AI is less a tool for staff and students to use, and is instead a technological and social force driving meaningful change across teaching, research and operations.

Putting enterprise AI governance into practice is a significant challenge in higher education, particularly:

1. establishing clear accountability for AI across a distributed institution;
2. applying existing risk frameworks to AI with enough precision to support real decisions; and
3. maintaining assurance once AI is deployed and continues to change.

This article examines each of these challenges and recommends practices to address them, drawing on TEQSA guidance, regulatory obligations and lessons from other highly regulated sectors, particularly financial services. Addressed together, these foundational areas can allow universities to move quickly where risk is low without over-governing, focus investment where AI creates value, and demonstrate that AI is operating within agreed limits.

Area one: Accountability

Accountability for AI is a foundational principle of good governance. In practice, it is uniquely challenging for universities. Two common scenarios illustrate this challenge:

• AI vendor updates. Existing platforms are increasingly activating AI capabilities – often with minimal or no notice. In the case of a student management system that turns on AI capability to summarise student case notes, IT might manage the platform and student services may own the overall process. But no single person decided to adopt the feature, which in turn opens questions about who is answerable.
• AI and data security. An AI assistant rolled out to all staff can search the university’s document systems. Over-sharing of information is a risk that pre-dates generative AI, but was considered a lower-risk issue. AI can now find over-shared files instantly, which changes the risk profile. Responsibility may be split between IT, which runs the AI system, and the many data owners who set the permissions.

Both of these examples highlight new accountability issues raised by AI adoption, and both reflect the unique nature of universities. Authority is deliberately distributed across faculties, the Academic Board, management and Council – and a single AI system can cut across the institution. Diffuse accountability is not new, but the pace and scale of AI deployment amplify it significantly.

Recommended practices

Addressing accountability gaps requires that leaders make ownership explicit within existing structures. Emerging practice across the sector is a layered model with three elements:

(1) Executive accountability

A single executive should be answerable to the Vice-Chancellor and Council for AI strategy (including the adoption, development and deployment of AI across the institution), risk and assurance. Comparable roles are increasingly common: for example, every non-corporate Commonwealth entity is now required to appoint a chief AI officer under Government policy, and many large financial institutions have also appointed a Chief AI Officer or equivalent. Within the higher education sector, one university reported to TEQSA in 2024 that the Vice-Chancellor was the executive sponsor for AI governance. Executive accountability gives AI governance the authority it needs to compete with the university’s many other priorities.

(2) AI owners

Executive accountability must be matched by operational for each AI system and use case.

• The AI system owner typically sits in digital or IT and is responsible for the platform, including its data, security, vendors and technical controls. They are also responsible for monitoring when new features come online and notifying other staff accordingly.
• The use case owner sits in the faculty or business unit. They are responsible for a particular use: its purpose, its performance, the people it affects, and ensuring it is risk assessed before deployment and when it changes. They have authority to pause or suspend it.

Both owners are recorded in the AI Register (a single view of all AI in the university), which should operate as a gate to support safe use and compliance with the university’s AI policy. In the vendor update example above, the Register as a gate would require the AI capability to have a defined accountable owner, and would likely require some type of assessment before it is used (see section 2 below). The register also becomes the inventory the university will need for the automated decision-making transparency obligations that commence on 10 December 2026 under the Privacy Act Reforms.

Recording each use case’s purpose and expected benefit also gives leaders a view of where AI investment is going, where effort is duplicated across faculties, and which uses are worth scaling.

AI lifecycle decision rights

A RACI (responsible, accountable, consulted, informed) matrix should map existing decision rights against each stage of the AI lifecycle. This includes post-deployment, monitoring and retirement – areas where many university AI governance frameworks are currently under-resourced. A strong RACI will include branches for different types of use case: procured, enabled through a vendor update, or built in-house, and make clear which decisions sit with the Academic Board, management and Council. In the second example, the RACI would make fixing over-shared permissions a condition of deployment. The system owner would be accountable for readiness, and data owners responsible for their own files.

Once accountability is clarified, the next question for leaders is: where can AI create the most value, and how much risk are we prepared to accept to realise it?

Area two: AI risk management

Most universities already have an enterprise risk management framework (ERMF) and a Council-approved risk appetite statement (RAS). The challenge is applying these frameworks to AI in a way that enables decision-making by executives and leaders. Common challenges that universities face here include:

1. processes are not proportionate, so lower-risk uses are delayed and over-governed;
2. similar AI proposals receive different risk ratings or approval pathways in different faculties;
3. staff turn to unapproved tools because the approved route is too slow or cumbersome;
4. risk appetite statements are too broad or not relevant to AI (e.g. speaking to reputational or technology risk generally), so decision-makers cannot tell whether a proposal is within appetite; and
5. assessments focus on the system rather than the use, so a platform approved for one purpose is quietly used for others that were never assessed.

The common cause is that risk frameworks have not yet been extended to AI, which creates governance gaps.

Financial services has moved quickly to uplift risk frameworks for AI. The Australian Prudential Regulation Authority’s (APRA) 30 April 2026 letter to industry made clear that existing prudential standards relating to risk management and operational resilience extend to AI. Universities are not APRA-regulated, but the Higher Education Standards Framework 2021 (Cth) (Threshold Standards) require Council to assure itself that material risks are identified and managed. TEQSA’s 2024 toolkit also recommends embedding generative AI risk mitigation within existing governance and quality assurance frameworks.

Recommended practices

(1) Categorise AI risks

AI largely amplifies risks the university already manages. For example, research data entered into an offshore tool raises research integrity and privacy risks, and prompt injection into a student-facing chatbot is a cyber security risk. Updating existing risk categories to address AI allows these risks to be tagged in the risk register and linked to the AI Register, giving the Audit and Risk Committee a consolidated view of AI exposure.

(2) Set clear AI risk appetite and thresholds

The RAS should state AI appetite at the level where decisions are actually made. For example, it might state:

• a low appetite for AI informing adverse decisions about students without meaningful human review;
• a moderate appetite for AI assisting with student feedback, provided an academic reviews it before release; and
• a higher appetite for experimentation in teaching and research within ethics and data constraints.

Appetite can also differ by role within the same activity, for example encouraging responsible AI use by research candidates while prohibiting thesis examiners from using AI to prepare their reports. Appetite settings should be reviewed frequently, and the Australian Signals Directorate has cautioned that AI cyber threats may rapidly invalidate existing risk tolerances, urging boards to test whether appetite remain appropriate at frequent intervals.

(3) Tier AI use cases via a threshold assessment

Every new AI system or use case should pass a short threshold assessment that assigns it a risk tier. In addition, any material change (which may include a feature switched on through a vendor update) will also trigger a re-assessment. The questions should be simple, such as:

• Does the use make or inform a decision about a person?
• Does it use personal or sensitive information?
• Is it student-facing?
• Can it act autonomously?
• How reversible would an error be?

The tier then sets the depth of further assessment, the approval level, the testing required and the monitoring cadence.

Area three: Monitoring and assurance

What happens after deployment is often where AI governance gaps are widest. In universities, distributed ownership, committee-based decision-making and limited central visibility of faculty-level systems can lead to undetected risks and unrealised benefits.

AI also challenges traditional assurance models, which were designed for deterministic systems that behave predictably and change only when upgraded. AI is probabilistic, its behaviour can shift as models, data and uses change, and agentic systems can act autonomously with minimal or no real-time review. A tool assessed as low-risk at approval may behave quite differently a semester later.

Governments and regulators across Australia are bringing attention to this issue:

• APRA found in its 30 April 2026 letter to industry that assurance practices are “not keeping pace with the scale, speed and complexity of AI”. It identified weak post-deployment monitoring as a specific gap, and observed that point-in-time and sample-based assurance is ill-suited to probabilistic models that learn, adapt and degrade over time.
• In September, the Prime Minister revealed that an experimental AI agent had gained unauthorised access to a Medicare statistics portal in June. The incident was detected by the developer rather than by government, and was not reported for almost three months. The Government has since said that new standards will require AI incidents to be reported immediately to both the affected organisation and authorities.
• Parliament’s Joint Select Committee on Artificial Intelligence wrote to the Prime Minister on 12 October calling for stronger oversight of AI. Its proposals included a duty for frontier AI developers to monitor risks and report incidents against clear deadlines, and a standing parliamentary committee to receive regular reports on AI incidents, including unintended actions by agents.

Together, these developments show AI's speed, scale, and complexity create particular governance gaps, which require continuous monitoring and ongoing assurance.

In higher education, the Threshold Standards already require academic governance to monitor risks to academic and research integrity. From 1 January 2027, amended standards will also require the Council of each Table A university to be satisfied that incidents, integrity breaches and compliance lapses are monitored and their causes addressed, and that the effectiveness of its risk management and internal controls is evaluated.

The question for Council is therefore whether AI systems remain within appetite once in use – and how to gain assurance that this remains the case. The practices below answer that question in proportion to risk, building on the register, owners and risk tiers set out in Areas One and Two.

Recommended practices

(1) Define triggers for re-assessment

AI approvals cannot be one-off in universities. An AI system or use case must return to the threshold assessment when there is a material change in risk and these triggers must be clearly defined. For example, where there is:

• a new purpose, dataset or cohort of users;
• a material vendor model update;
• a relevant legal or regulatory change; or
• an incident, including one at a supplier or in an analogous system elsewhere in the university.

The system owner’s responsibility for tracking new vendor features (see Area One) is what makes the second trigger workable in practice.

(2) Set monitoring by risk tier

Monitoring requirements should follow the tier assigned at the threshold assessment. For lower-risk uses, a periodic attestation by the use case owner that the use remains as approved may be enough. For higher-risk uses, monitoring may include:

• logging of inputs and outputs sufficient to reconstruct how an output or decision was produced;
• adversarial testing of controls;
• periodic independent human review of outputs against expected performance; and
• a tested ability to pause the system.

At every tier, the use case owner should periodically confirm whether the expected benefits are being realised. In this way, tiering is as much about speed as safety. A fast, light-touch pathway for low-risk uses lets the university capture benefits sooner and reduces the pull towards unapproved tools.

(3) Monitor shadow AI

Not all AI use will reach the register. Periodic surveys of staff and students, and AI questions added to existing student experience surveys, help surface use that has never been assessed. So can existing data such as procurement records and expense claims. The gap between reported and registered use is itself a useful measure of how well governance is working.

(4) Report against appetite

Reporting is what turns monitoring into assurance. Emerging practice is for the Board and/or Audit and Risk Committee to receive a consolidated AI report, covering key areas such as exposure against appetite, incidents, assurance results, and a view of the overall AI portfolio. Over time, this reporting gives Council the evidence to direct investment, including scaling the uses that deliver and retiring those that do not.

From AI policy to effective enterprise governance

Australian universities have done the important early work of setting rules for how staff and students use AI. The harder task now is governing AI as an enterprise, consistent with a clear AI strategy and defined risk appetite.

The three areas outlined in this article are foundational, but highlight the work needed to implement AI governance that is fit-for-purpose, aligned to the unique nature of higher education institutions, and to the specific challenges posed by AI systems.

Enterprise governance as described in this article should not be a handbrake on progress. Instead, clear ownership, proportionate risk settings and ongoing assurance allow universities to move quickly where risk is low, focus investment where AI creates value, and stop what is not working.