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 would be inaccurate to describe it as new. What matters 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
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.
These papers come at the question from different directions, but they point to the same delivery problem. Principles and experimentation are no longer enough. Organisations now need a practical system for choosing AI initiatives, delivering them responsibly, judging whether they work and deciding whether they should continue.
My view is that the emerging model is sound, but it needs to go one step further. Risk-based assurance is a sensible anchor. It tells us how much scrutiny a use case needs. It does not tell us whether the work is worth doing in the first place. That second question must be answered through strategy and measurable benefit. If leaders cannot explain what an AI initiative is expected to improve, how that improvement will be measured and why it matters to the organisation, the initiative is not ready for investment—however interesting the technology may be.
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 I would expect assurance to 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 |
The intention is not to slow delivery. It is to make better investment decisions earlier. Worthwhile, lower-risk use cases should have a shorter path. Initiatives with serious consequences, unclear controls or weak benefits should face more challenge before the organisation commits further time and money.
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.
That delivery role matters because assurance 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. 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 that cannot challenge weak readiness, control or value will struggle to do more than coordinate. Equally, an assurance function that only appears at approval time will spend too much of its effort reviewing decisions that have already been made. The two need to work as one operating capability while retaining clear independence where independent challenge is required.
Challenge without creating another bottleneck
There is an obvious risk in this model. A central AI function can become another layer of approval, duplicate existing forums and slow low-risk work while it tries to review everything. Expanding existing governance to cover AI will only help if the organisation also removes duplication and makes decision rights clear.
The central function should set common evidence standards, provide reusable delivery paths and work with risk and governance to challenge initiatives. It should not take every decision away from the accountable business executive. Standing approvals and pre-agreed patterns should allow low-risk uses to move quickly. Higher-impact uses should receive more scrutiny, limited autonomy and clearer acceptance authority.
Where delivery and assurance disagree, the issue should not disappear into a committee. The organisation needs a defined escalation path. If a proposal sits outside risk appetite or mandatory control requirements, the appropriate risk or accountable authority must be able to prevent deployment. If the disagreement concerns value, priority or readiness within risk appetite, the accountable business executive or portfolio forum should make the decision and record the rationale.
The central AI function should supply evidence and challenge; it should not become an unaccountable owner of business risk or investment.
This distinction matters. Good assurance should shorten the route for known, low-risk patterns and concentrate senior attention where the consequence or uncertainty is genuinely higher.
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 a project-support agent trial. It covered three projects, 28 project resources and a further 14 stakeholders. The agent collected project status and RAID updates, reviewed the submissions and prepared information for the project manager. It saved at least three hours of project-management effort each fortnight.
The time saving was useful, but it was not the most important result.
The agent consistently called out updates that were incomplete, too general or otherwise inadequate for reliable reporting. That gave the project manager a targeted basis for quality discussions instead of requiring them to work through every submission manually. The agent did not solve poor data by itself. It made the problem visible, identified where follow-up was needed and helped focus human attention on the inputs that mattered.
The trial therefore changed more than the reporting process. It led us to double down on standardising the quality expected from status and RAID responses through the project management Community of Practice and the enterprise PMO. What initially looked like an efficiency use case exposed an enterprise delivery-discipline issue.
The agent also needed to be refined as it encountered real work. So did the way people interacted with it. Stream leads needed clearer guidance on the level of detail expected, and the project manager still needed to intervene when a stakeholder did not respond with sufficient care. At times, a human had to set the expectation with another human.
Access was another practical constraint. An agent supporting project delivery may need controlled access to email, Teams, project plans, RAID logs and reporting sources. Those are delivery dependencies, not technical housekeeping to be considered after the use case has been approved. Without the right access, the agent can only provide a partial view and may create another manual reconciliation step.
The trial reinforced my view that a dedicated agent needs to be managed as an operational resource. I do not mean that it becomes accountable in the way a person is. Accountability remains with its manager. I mean that it needs a clear role, performance expectations, feedback, quality review and continuing improvement. If its outputs fall below standard, the response should be deliberate: coach the users, improve the instructions or workflow, restrict the task, retrain or reconfigure the agent, or remove it from service.
Continuous improvement was not a separate technical exercise at the end of the trial. It became part of the operating process. The manager reviewed what the agent was finding, the Community of Practice improved the response standard, and the ePMO reinforced the expectation across projects. That is much closer to how an organisation manages a capable employee than how it installs a piece of software.
This example also illustrates the distinction I explored in Deploying AI Is Getting Easier. Making It Operational Is Not. Deployment gives people access to a capability. Operationalisation establishes the ownership, data, workflow, controls and improvement cycle required to rely on it. For readers who want to start with a contained project-delivery use case, Your First Project Management Agent sets out a practical starting point.
Before I would describe an AI capability as operational, I would expect four things to be true:
defined quality assurance is being applied to its outputs;
a named manager is accountable for its operation and outcomes;
usage, performance and exceptions are reviewed regularly; and
benefits are measured against the full effort and cost required to operate it.
A delivery path program leaders can use
The detail will vary according to the use case, but the evidence should build through the normal delivery lifecycle. Program leaders do not need a completely separate method for AI. They need to expand the method they already use so AI-specific questions are answered before they become late delivery surprises.
Delivery point | What the program leader should establish |
Initiation | Strategic objective, accountable business owner, expected benefit, baseline, non-AI alternatives and initial risk tier |
Planning | Evidence requirements, data and access dependencies, full operating-cost estimate, decision rights and benefit-review dates |
Build or procurement | Representative evaluation set, quality thresholds, controls, human review, escalation boundaries and acceptance authority |
Controlled release | Limited permissions, production monitoring, support model, sampled output review and clear conditions for expanding autonomy |
Operation | Quality, overrides, incidents, reliability, user feedback, workforce impact, costs and realised benefits |
Lifecycle review | A recorded decision to expand, restrict, redesign, suspend or retire the capability |
This sequence is deliberately familiar. The work still needs an owner, a plan, evidence, acceptance criteria and a decision. AI adds new forms of uncertainty; it does not remove the disciplines of good delivery.
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.
The distinction between adoption and value is important. 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.
High usage may give an executive confidence that the organisation can experiment and discover opportunities. It may also conceal a great deal of correction, duplicated effort or activity with no connection to a priority. The useful management question is not simply how many people used the tool. It is what changed in the work and whether that change was worth the cost.
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.
Benefits need an owner and a review date
Benefits realisation should begin before a pilot, not after a positive demonstration. The business owner and finance or portfolio partner should agree the current baseline, target, measurement method, review period and full-cost assumptions. The measures should reflect the reason the initiative exists. That might be cycle time, cost, quality, revenue, customer outcome, control effectiveness or capacity released for higher-value work.
The baseline does not have to be perfect. It does need to be credible enough to support a decision. In the project-support agent trial, the observed saving of at least three hours a fortnight was one measure. The improvement in the quality of status and RAID inputs, the number of inadequate responses identified and the follow-up effort required were also relevant because the use case was partly about the reliability of reporting.
I would review benefits at three points: after the controlled trial, after an agreed period in operation, and at regular portfolio or quarterly reviews thereafter. The decision should compare realised benefit with the complete operating cost, including licences, model use, assurance, support, change, human review and the work created by exceptions. Leaders should also ask where released capacity went. Time saved is only a business benefit when the organisation can explain how that time was redeployed or what outcome improved because of it.
The original business case should include continuation thresholds. If quality remains below the accepted level, costs rise beyond the expected range or the strategic need changes, the agent should be restricted, redesigned or retired. Continued operation should be a decision supported by evidence, not the result of nobody reopening the business case.
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 whether leaders are prepared to act on the evidence
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 question for an executive is therefore broader than “Can we control this AI?” It is: “At this level of risk and cost, is it producing an outcome that still justifies our investment?”
Answering that question requires more than an approval paper. It requires delivery evidence, operational data, clear ownership and leaders who are prepared to act when the evidence is weak. Sometimes the right action will be to move faster. Sometimes it will be to improve the workflow or tighten a control. Sometimes it will be to stop.
That is the practical role of AI assurance. It should help the organisation make those decisions earlier, with better evidence, and continue making them for as long as the capability remains in operation.
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