Operating-model transition

The problem this quarter

A year ago, most of your AI activity ran through one central team. That team built the first models, vetted the first tools, and could plausibly tell you who owned what. That arrangement is now failing in one of two directions.

If you kept it centralised, the AI team is a bottleneck. Every business unit with a use case queues behind it. Shadow AI grows in the gaps, because a marketing lead who can get a usable result from a chatbot in an afternoon will not wait six weeks for a committee.

If you let it go federated, you have the opposite problem. Use cases are spawning faster than anyone can see them. Nobody can answer the question a regulator, an auditor, or your own board will now ask: who is accountable for this specific AI system, and what happens when it gets a decision wrong?

That question is no longer rhetorical. For non-corporate Commonwealth agencies, the DTA’s Policy for the responsible use of AI in government v2.0 (effective 15 December 2025) carries a Standard for accountability: each in-scope AI use case must have a designated accountable owner, supported by a maintained use-case register. The accountable-owner requirement runs on a roughly 12-month clock — so the practical deadline lands around December 2026. If you have not assigned owners by then, you are non-compliant, not merely untidy.

So the operating-model question stops being an org-chart preference and becomes a control. This is the quarter to fix it deliberately, before the deadline forces a rushed answer.

The method

Three moves, in order: pick an operating model that fits AI specifically, define decision rights as a matrix, then name and brief accountable owners. Sequence matters — if you assign owners before you have decided how decisions get made, you have named people who cannot actually decide anything.

Pick a model that fits AI, not generic IT

The three options are familiar, but AI changes their trade-offs.

Model	What it is	AI-specific upside	AI-specific failure mode
Centralised Centre of Excellence	One team builds, approves and runs AI	Consistent risk classification; deep scarce skills pooled	Becomes the bottleneck; shadow AI in the business; owners feel no ownership
Fully federated	Each business unit runs its own AI	Speed; domain context lives with the use case	No shared guardrails; duplicated risk work; no one can see the use-case portfolio
Hub-and-spoke (“thin CoE + embedded owners”)	Small central team sets guardrails and standards; business units own and run use cases within them	Speed and control; one place to classify risk, many places to deliver	Only works if decision rights are explicit; a thin CoE with no teeth is just federation with extra meetings

For AI specifically, the hub-and-spoke model is usually the right destination. AI risk classification, model assurance and the accountability register genuinely benefit from a single consistent method — that is the hub. But the people who understand the business consequence of a wrong output sit in the business — that is where ownership has to live. A centralised model cannot scale to dozens of use cases; a fully federated one cannot give you one defensible answer about your AI portfolio.

Define decision rights before you define teams

The recurring fight in AI governance is not “should we do this use case” — it is “who gets to say yes”. Make that explicit by separating five distinct decisions across the lifecycle:

• Propose — who can put an AI use case forward
• Risk-classify — who assigns the risk tier (this should be a single consistent function, not each team marking its own homework)
• Approve — who authorises the use case to proceed at its tier
• Operate — who runs it day to day, including human oversight
• Assure — who independently checks it still behaves and stays in tier

Note that approve and risk-classify must not be the same role for higher-tier use cases. If the team proposing a use case also rates its own risk and approves it, you have no control — you have a rubber stamp. The AI6 guidance (NAIC/DISR, 21 October 2025) and the voluntary AI safety standard (VAISS) both put accountability and human oversight at the centre for exactly this reason: someone identifiable must be answerable, and a human must be able to intervene.

Name and brief the accountable owners

An accountable owner is not a mailing list. It is one named person who can describe what the AI system does, what tier it sits in, what could go wrong, and what they would do about it. Brief them on three things: the specific use case and its risk tier, their authority to pause or withdraw it, and the review cadence. If an owner cannot pause their own system, they are not accountable — they are a contact name.

A worked example

Tanami Mutual Bank is a fictional mid-sized AU mutual bank, around 900 staff, with a small data-science team that has spent two years as the de facto owner of everything AI: a fraud-scoring model, a contact-centre summarisation tool, two LLM pilots in lending operations, and a growing list of business-unit requests it cannot get to.

The symptoms are textbook. The data-science lead is the single point of approval and is now the bottleneck for the whole organisation. Meanwhile, three teams have quietly bought AI features inside SaaS tools the central team has never seen. When the board’s risk committee asks for a list of “every AI system that touches a customer decision and who owns it,” nobody can produce one in under a week.

Tanami moves to a thin CoE plus federated owners over a single quarter:

1. Weeks 1-3 — Stand up the thin CoE. Three roles, not a department: a risk-classification function, an assurance reviewer, and a standards owner who maintains the guardrails and the register. The CoE stops being the place use cases get built and becomes the place they get classified, approved and assured.
2. Weeks 3-6 — Build the matrix and the register. Decision rights are written down (below) and the existing four-or-five systems are entered into an accountable-owner register. Every live use case gets a named owner in the business — the fraud model goes to the head of financial crime, the contact-centre tool to the customer-operations lead.
3. Weeks 6-10 — Migrate, don’t freeze. This is the part most transitions get wrong: they pause all AI delivery while reorganising and lose three months. Tanami keeps in-flight pilots running under their existing approvals, and applies the new decision rights only to new use cases and to renewals. Existing systems are migrated into the new model at their next scheduled review, not all at once.
4. Weeks 10-12 — Brief owners and close the loop. Each named owner gets a 30-minute briefing on their authority to pause, their tier, and their review date. The CoE runs its first portfolio review.

The outcome is not fewer use cases — it is more, moving faster, with a single person answerable for each and one register the risk committee can read in five minutes.

The template

Two artefacts, both copyable today.

AI decision-rights matrix (decision × role; R = responsible, A = accountable, C = consulted, I = informed):

Decision	Business owner	Thin CoE (classify/standards)	Risk & assurance	Approver (per tier)	Exec sponsor
Propose use case	R/A	C	I	I	I
Risk-classify	C	R/A	C	I	I
Approve (low tier)	C	C	I	R/A	I
Approve (high tier)	C	C	C	R	A
Operate / human oversight	R/A	I	I	I	I
Assure (ongoing)	C	I	R/A	I	I
Pause / withdraw	R/A	I	C	I	C

The load-bearing cells: risk-classification is owned by the CoE so it is consistent, approval authority rises with tier, and the business owner holds both day-to-day operation and the power to pause. One accountable (A) per row — never two.

Accountable-owner register (the artefact the DTA register requirement maps onto):

Use case	Business owner (named)	Risk tier	Approved by	Human-oversight method	Next review
Fraud transaction scoring	Head of Financial Crime	High	Exec sponsor + approver	Analyst review of flagged cases	Quarterly
Contact-centre summarisation	Customer Ops Lead	Medium	Tier approver	Agent edits before send	6-monthly
Lending-ops LLM assistant (pilot)	Lending Ops Manager	High	Exec sponsor + approver	Human decision on all outcomes	Quarterly

Keep the register to one row per use case and one named human per row. The moment a cell reads “the AI team” or “TBC”, you have found your accountability gap.

What changes when the regulation moves

Treat the operating model as something that has to absorb regulatory movement without being rebuilt each time.

• DTA accountable owner and accountability Standard. For Commonwealth agencies, the register above is not optional documentation — it is how you evidence the designated-owner requirement before the ~December 2026 mark. Foundational AI training is mandatory for all APS staff, which means your accountable owners are not the only ones who need to understand the basics; build the briefing into onboarding, not a one-off.
• NSW digital work systems duties. The Work Health and Safety Amendment (Digital Work Systems) Act 2026 (assented 18 February 2026; commencement by proclamation, not yet in force) places duties on PCBUs — employers — that use a “digital work system” (an algorithm, AI, automation or online platform) to allocate or manage work. When AI is allocating, scheduling or managing people, accountability shifts onto the employer as a work-health-and-safety duty. If you have AI in workforce management, the accountable owner for that use case carries a WHS dimension, not just a technical one. Flag those use cases in the register now so you are ready when it commences.
• ISO/IEC 42001:2023. If you are pursuing certification of your AI management system, leadership accountability and defined roles are explicit requirements. The decision-rights matrix and owner register are most of the evidence an auditor will want — built once, they serve both the regulator and the certification.

The design principle holds across all three: a named human, an explicit decision right, and a review date. When the regulation moves, you update tiers and add columns — you do not rebuild the operating model.

Where this connects

• Use the risk classifier to make the risk-classify decision consistent across every owner.
• Check where you sit on the Business Architecture axis with the maturity assessment.
• Ground the obligations above in the regulatory canon.
• See how this fits the broader practice in the model.