AI Assurance Must Test Value as Well as Risk
What Australia’s emerging AI delivery model and the World Economic Forum’s financial-services playbook tell us about turning responsible AI into an operating capability
Enterprise AI has reached an important point. The discussion is moving beyond access to tools and experimentation with use cases. Governments and financial institutions are now confronting the harder questions: how AI should be selected, delivered, assured, owned and measured once it becomes part of everyday work.
Three recent developments help bring that challenge into focus.
On 28 July, the Australian Department of Finance made the practical application of the National Framework for the Assurance of Artificial Intelligence in Government more visible. The framework itself was agreed and released on 21 June 2024, so it ain't exactly new. What is relevant now is the renewed focus on translating Australia’s AI Ethics Principles into practical assurance across development, procurement, deployment and operation.
On 29 July, Finance published its AI Transparency Statement. It describes an AI Delivery and Enablement function—AIDE—responsible for driving the APS AI Plan, accelerating adoption, addressing common barriers, monitoring implementation, coordinating Chief AI Officers and developing measures for successful AI adoption and use A big annoicement for big move for an Australian government entity.
The World Economic Forum’s AI Playbook for Financial Services, published with Accenture in June 2026, provides the industry perspective. Drawing on more than 150 senior leaders across 100 institutions, it examines the strategy, governance, data, workforce and operating changes required to move AI from experimentation into secure, scaled use.
Taken together, these papers signal something more significant than another governance framework.
They show that responsible AI now needs a delivery system.
My view is that the emerging model is missing the next step, that next step being: Risk-based assurance is a necessary anchor. It is not, on its own, a sufficient basis for deciding whether an AI initiative deserves investment or should remain in operation.
Risk determines how much assurance an AI initiative requires. Value determines whether the initiative should exist at all.
Risk-based assurance is a solid foundation—but it is not the whole decision
The Australian framework gets an important point right: different AI use cases require different levels of scrutiny. A low-risk productivity tool should not be forced through the same assurance path as a system influencing an administrative decision, a customer outcome or access to an essential service.
The practical guidance is also stronger on benefits than many discussions of AI governance. It asks governments to document the purpose and expected outcomes of a use case, consider whether AI is preferable to non-AI alternatives, determine whether there is a clear public benefit and assess whether the benefits outweigh the risks. It also calls for testing, verification and continuous monitoring.
That creates a good foundation. The opportunity is to make benefit and strategic alignment as operational as risk.
An AI initiative may be technically feasible, legally permissible and controllable within the organisation’s risk appetite, yet still be a poor investment. It may automate a low-value activity, reproduce an already fragmented process, shift work rather than remove it, or create operating costs that exceed the benefit.
This is why assurance should test four questions together:
Is the use case aligned with strategy and a genuine organisational priority?
Can the expected benefit be clearly articulated and measured against a baseline?
Are the risks understood, controlled and proportionate to that benefit?
Does the evidence continue to support investment once the capability is operating?
A simple portfolio view makes the required decision clearer:
Expected benefit | Risk after controls | Appropriate response |
High | Low | Accelerate within the agreed control environment |
High | High or uncertain | Test carefully, strengthen controls and limit autonomy until the evidence supports expansion |
Low | Low | Challenge the business case; retain only where there is a deliberate learning or capability objective |
Low | High | Stop, redesign or select a non-AI alternative |
This is not an argument for slowing AI delivery. It is an argument for making faster, better investment decisions. Organisations should be able to accelerate worthwhile, lower-risk use cases while applying greater scrutiny to initiatives with more significant consequences.
Assurance needs a delivery function with the authority to challenge
Finance’s AIDE function is therefore an important development. Its remit recognises that principles, policy and governance do not implement themselves. Agencies need support to remove common barriers, coordinate delivery, build capability, monitor implementation and share lessons.
Why is delivery important? their assurance when applied too late becomes a hurdle. Teams make decisions about data, architecture, vendors, access, workflow and human oversight long before a final governance review. If assurance enters only near deployment, the organisation either discovers expensive problems late or accepts risks because too much time and money have already been committed.
The better approach is to design assurance into delivery from the beginning. When it can...obviously.
A central delivery-and-enablement function should not merely help teams move faster. It should work with governance, risk, technology, data and business leaders to challenge three things throughout the lifecycle:
Readiness: Are the data, workflow, people, access, operating support and acceptance conditions in place?
Control: Are risks, permissions, human interventions, escalation paths and evidence appropriate to the use case?
Value: Is the initiative still strategically relevant, and is it producing a benefit worth its full cost and residual risk?
Program and transformation leaders are responsible for momentum, but we are also stewards of the business. Delivery speed and quality matter. So do strategic alignment, responsible investment and the willingness to stop work that no longer makes sense.
A delivery function without the authority to challenge becomes a coordination office. An assurance function disconnected from delivery becomes a policy office. Enterprise AI needs the two designed as one operating capability.
Build AI into existing governance—do not create a parallel enterprise
The WEF playbook reaches a similar conclusion from a financial-services perspective. Scaling AI is not simply a technology deployment. It requires changes to workflows, decision rights, leadership, workforce capability, data foundations and risk management. Responsible AI must operate through the way the institution already makes decisions and delivers work.
I agree with that direction. Organisations should expand their existing governance, risk, portfolio, delivery and operational functions to include AI rather than establish a disconnected structure that tries to own everything associated with it.
The existing functions will need to change. Portfolio governance will need to assess variable AI costs and continuing value. Risk functions will need to consider changing models, data, tools and autonomy. Delivery teams will need stronger evaluation practices. Technology and data leaders will need to manage permissions, logs and dependencies. People functions will need to address role redesign, capability and the redistribution of work. The accountability model should remain clear:
Role | Primary accountability |
Executive Committee | Enterprise AI strategy, investment priorities, risk appetite and the outcomes expected across the organisation |
Business executive | The business outcome, process redesign, benefits and consequences of the AI-enabled service or workflow |
Named managerial owner | The day-to-day performance of a dedicated agent, quality of its outputs, appropriate use and escalation of exceptions |
Central AI delivery and enablement function | Enterprise delivery pathways, common controls, capability, reusable platforms, cross-functional barriers and implementation assurance |
Risk, legal and compliance | Independent challenge, control expectations, regulatory interpretation and escalation where residual risk is unacceptable |
Technology, security and data | Architecture, approved data and tool access, resilience, logging, monitoring and change control |
Finance and portfolio governance | Full operating cost, benefit baselines, investment trade-offs and continuation decisions |
People and change functions | Job and workflow redesign, consultation, training, adoption and workforce impacts |
The central function can coordinate these responsibilities, but it cannot become the owner of every AI outcome. ExCo should own the enterprise strategy. Business executives should own the outcomes in their areas. Every operational agent should have a named manager who is answerable for how it performs.
Human accountability should not become a broad statement that everyone is responsible. If ownership is distributed without being made explicit, it is diluted.
What enterprise enablement looks like in practice
The WEF playbook was informed by senior industry contributors, including Julie Gerdeman, Global Head of Data and Analytics at BNY. It would be inappropriate to attribute any specific recommendation in the report to an individual contributor without further evidence. However, my own experience at BNY provides useful colour on what enterprise enablement begins to look like in a regulated institution.
AI adoption was not treated as simply releasing a tool and waiting for value to appear. Champion networks helped build capability and identify practical opportunities. Governance, training and access to supported tools mattered. Simpler use cases could be explored and developed through working groups, while more complex initiatives had a path to specialist regional support.
Those mechanisms did not guarantee an outcome, but they created an environment in which people could discover useful applications without every idea being dependent on a single central team.
I have also seen the implementation friction more directly through project-support agent work.
The agent reduced manual effort in collecting updates, reviewing project information and preparing material for a project manager. It did not remove the need to follow up poor-quality data. In fact, one of its most useful contributions was exposing where updates lacked the detail required to support a reliable view of delivery.
The technology needed to be trained and refined. So did the stream leads interacting with it.
Access was another practical constraint. An agent intended to support project delivery may need controlled access to email, Teams, project plans, RAID logs and reporting sources. Many project managers had not previously treated those access dependencies as formal delivery-stage requirements.
User behaviour also mattered. Some stakeholders did not respond to an agent with the same seriousness they would give a project manager. That is not a minor adoption issue. It affects data timeliness and quality, which then affects the reliability of the agent’s output. At times, a human still needed to set the expectation with another humanThe result was valuable, but the value came from redesigning the work around the agent—not from pretending the agent had eliminated the work.
That experience reinforced four practical acceptance criteria I would expect before describing an AI capability as operational:
its outputs are subject to defined quality assurance;
a named owner is accountable for its operation and outcomes;
usage and performance are reviewed regularly; and
benefits are measured against the full effort and cost required to operate it.
Adoption is useful evidence, but it is not value
Finance’s transparency statement says it monitors adoption, training completion, productivity impacts and AI-related incidents. That is a sensible set of starting measures. AIDE will also develop measures for successful AI adoption and use across the APS.
Usage can show that people have access to the tools, feel sufficiently confident to try them and are discovering use cases beyond a central innovation team. Those are meaningful indicators of organisational capability. They are not proof that a dedicated agent or AI-enabled workflow is creating value.
Usage tells you whether people touched the tool. It does not tell you whether the enterprise should continue investing in it.
For a general-purpose tool, measures such as access, active users, training and employee confidence can help assess enterprise enablement. For a dedicated operational agent, the standard should be higher. It should be managed against a defined purpose and scorecard.
Dimension | Evidence expected |
Strategic contribution | The objective supported, strategic alignment and original value hypothesis |
Business benefit | Baseline and target for time, cost, revenue, quality, customer or public outcomes, or risk reduction |
Output quality | Accuracy, completeness, consistency, exception rate, rework and comparison with an appropriate human or process baseline |
Human judgement | Acceptance, amendment and rejection rates; reasons for overrides; quality of escalation and hand-off |
Operational performance | Task completion, latency, reliability, access failures, unsuccessful hand-offs and recovery |
Risk and control | Incidents, near misses, inappropriate actions, unauthorised access and compliance with autonomy limits |
Workforce impact | Time released, how capacity was redeployed, workflow changes, user confidence and unintended workload |
Economics | Benefits measured against development, platform, model, assurance, support and change costs |
Continuing improvement | Evaluation results, recurring defects, production feedback, regression testing and completed improvement actions |
Lifecycle decision | Evidence supporting expansion, restriction, redesign, suspension or retirement |
Surveys belong in this model, but they should be combined with observed performance. People may report that they like an agent while repeatedly correcting its work. Others may remain cautious even when the evidence shows that it performs consistently. Both findings matter, and the gap between perception and performance often tells leaders where training, workflow design or trust needs attention.
Approval is a point-in-time decision; assurance is a continuing capability
Both the Australian guidance and the WEF playbook recognise the need for continuing monitoring. This is particularly important for agents because their operating conditions can change after approval.
A different model may be introduced. A prompt or workflow may be revised. A new data source or tool may be connected. Permissions may expand. User behaviour may change. The process around the agent may be redesigned. Any one of these changes can weaken the evidence on which the original approval relied.
The NIST AI Risk Management Framework Playbook reinforces this lifecycle view. It calls for regular evaluation, production monitoring, comparison between pre-deployment and real-world performance, defined human oversight and feedback from users and affected groups. Emerging agent-engineering practice similarly turns production traces and human feedback into reusable evaluations so changes can be tested against what the organisation has learned. OpenAI’s agent improvement loop is one practical example of that approach.
For enterprise leaders, this translates into several useful practices:
Pre-production evaluation sets — Test representative tasks, known failure modes and edge conditions before release. Keep those tests so future changes can be checked for regression.
Trace-based evaluation — Review how the agent used data, tools, permissions and hand-offs, not just whether its final response appeared convincing.
Production sampling — Select real outputs for regular review by people with the domain expertise and authority to judge quality.
Human-agent disagreement analysis — Track when people accept, amend, reject or override an output. Examine whether the human or the agent was ultimately correct and use the result to improve both the system and the workflow.
Shadow and controlled-release modes — Allow an agent to recommend an action before it is authorised to execute it. Increase autonomy only when performance and consequence justify it.
Drift and material-change monitoring — Identify changes to data, models, tools, prompts, permissions and operating context that require reassessment or reapproval.
An enterprise agent register — Record each agent’s purpose, owner, model and workflow dependencies, permissions, controls, current status and next review date.
Formal performance and lifecycle reviews — Make a deliberate decision to expand, restrict, redesign, suspend or retire the agent. Do not allow continued operation to become the default simply because no one has reviewed it.
These practices move assurance away from a document completed before deployment and toward an evidence loop connecting real behaviour, human judgement, control performance and improvement.
A practical mandate for an AI delivery-and-assurance function
The Australian government model is promising because it brings delivery and enablement into the same conversation as assurance. The test will be how the function operates and what evidence it can produce.
Whether in government, financial services or another regulated enterprise, an effective function should be able to:
Manage the AI portfolio by selecting use cases according to strategic value, feasibility, risk, readiness and full operating cost.
Embed assurance from initiation by defining the required evidence, controls, acceptance authority and review path before development or procurement begins.
Remove shared delivery barriers involving data, access, architecture, procurement, skills, policy and change across the enterprise.
Industrialise successful use cases by moving validated experiments into supported, monitored and maintainable production services.
Coordinate decision rights so business, technology, data, finance, risk, people functions and managerial owners understand their responsibilities and intervention authority.
Measure operational outcomes through workflow change, quality, decision effectiveness, workforce impact, risk, cost and realised benefit—not usage alone.
Maintain continuing assurance by monitoring performance, incidents, control effectiveness and material change, with the authority to require improvement, restrict operation or recommend suspension.
The existence of a framework, a central function, a Chief AI Officer network or a secure experimentation environment is encouraging. None of them, by itself, proves that responsible AI has become operational.
The proof will be visible in the evidence: prioritised use cases connected to strategy; named owners; risk-tiered delivery pathways; benefit baselines; auditable decisions; monitored production performance; effective interventions; changed workflows; and deliberate decisions to scale or stop.
The real test is stewardship
The three papers point in the same direction. AI is moving out of experimentation and into the operating fabric of institutions. Assurance therefore cannot remain a specialist review performed at the edge of delivery. It has to shape the decisions, work products, controls and evidence produced throughout delivery and operation.
At the same time, value cannot be treated as someone else’s responsibility. A use case that is safe but strategically weak is not a success. An agent that is widely used but produces unmeasured rework is not proven. A capability that saves time without showing where that capacity went has not yet demonstrated a business outcome.
The mature question is not simply, “Can we control this AI?” It is, “Should we continue investing in it, at this level of risk and cost, based on the outcomes it is producing?”
That is why AI assurance needs a delivery function—and why that function needs a mandate to challenge readiness, control and value.
Assurance without delivery becomes policy. Delivery without assurance scales risk. Delivery without measurable value simply scales activity.
About Steven Gabris
Steven Gabris is an enterprise delivery, governance and transformation leader with experience across financial services, payments, government and technology consulting. His work focuses on turning strategy and governance expectations into practical delivery systems, accountable operating models and measurable outcomes. He is the founder of Gabris Group Advisory.
Comments