What happened with Ruby
On 6 November 2026, iTnews reported that NAB had deployed an internal AI tool called Ruby for staff, built on an Anthropic platform. NAB CEO Andrew Irvine said more than 40,000 employees would have access to it for personal productivity. The disclosure was made during a media call alongside the bank’s FY26 results announcement, and the report does not describe Ruby’s full feature set or a separate launch date.
For most organisations, the material point is not the name of the tool. It is the operating model behind giving a large workforce access to AI without treating it as an uncontrolled experiment.
Staff access is the last step, not the first
The iTnews report describes work over the preceding 12 months where NAB established a single AI platform and governance foundations. In parallel, it established around 50 business-led, cross-divisional teams working with strategic partners including Anthropic and AWS.
The timing matters. Broad access is easier to manage when it sits on top of a governed platform and a defined process to prioritise, build and review use cases. Without it, “AI for everyone” just means that no one is accountable.
A material detail in the NAB approach
The squads are described as business-led and aligned to business priorities. That framing moves AI out of IT project governance and into operational ownership, where outcomes can be measured in timelines, quality and customer impact.
For organisations looking to replicate the discipline on a smaller scale, the operative question is: who owns the workflow outcome, and who owns the platform controls? When those responsibilities are explicit, it is easier to connect AI work to measurable ROI and avoid fragmented experimentation.
Select use cases that sit inside existing workflows
One example in the report is assisting business bankers to write credit memos, with the stated aim of reducing processing time. Whether or not your organisation writes credit memos, the pattern is transferable: start with work that already has a defined input, a review step and a documented definition of accepted outputs.
This differs from deploying a generic chatbot and relying on teams to identify value themselves. You are assigning an AI assistant to an established workflow, then determining which steps can be accelerated while retaining human review where sensible.
In mid-sized organisations, good starting points are typically workflows such as drafting and summarising client communications, preparing internal briefs, generating first-pass reports or knowledge retrieval from approved internal sources. The common factor is that the work already carries accountability, and quality can be measured.
Treat NAB’s metrics as reference points, not targets
NAB cited an 18% increase in its change-delivery cycle and a 20% reduction in the time required to approve business loans, plus faster access to insights for personalised customer service.
For medium-sized businesses, the practical takeaway is not “target 20%”. It is that you need a measurement framework before you let every employee have access to your new AI tool. If you cannot articulate how you will assess improvement, you will struggle to separate better outcomes from short-term novelty.
What to measure before you open up accessibility
Start with baseline measures that correspond to the workflow you are building. In most back-office and customer-facing processes, the most useful baselines are turnaround time and error rates. If staff continue to review outputs, and in most cases they should, you also need to understand the time it takes to complete reviews and the different types of errors.
These baselines allow you to test whether AI is increasing throughput without adding more rework, increasing risk or errors that your customers see.
Define “value” in commercial terms early on: time returned to teams, reduced backlog, improved conversion through faster follow-up, fewer escalations or a lower cost of delivery. Without that connection, adoption can appear successful while the business case remains unproven.
A proportionate pilot plan for mid-sized teams
NAB’s scale is unique, but the structure can be adapted. A sensible starting point is a small portfolio of cross-functional use cases tied to operational objectives, with clear ownership and oversight.
In practice, that means selecting a workflow where:
- Staff already spend time producing or summarising written material
- There is an established approval or review step
- Turnaround time and quality can be measured reliably
- Data access can be controlled and audited
From there, plan who gets access in phases. Validate the new workflow with a small group, document the performance standard, then extend access using the same controls.
For organisations moving beyond experimentation, this is where a combined strategy-and-delivery approach matters: define the use case, build the workflow integration and instrument it so performance can be monitored and continuously improved.
Governance is not administrative overhead if it prevents avoidable risk
The report highlights that NAB built governance foundations alongside its platform. Organisations outside banking are often inclined to defer this step and rely on informal guidelines. The problem is that broad staff access raises predictable questions you need resolved before it becomes an issue.
Before scaling, you need a few guardrails on data access, privacy, security and vendor arrangements. You also need clarity on where staff approvals remain mandatory.
What a governed platform means in operational terms
At a minimum, it should be unambiguous which tool is approved, what data can be used and who is accountable for decisions when a use case becomes business as usual. That accountability keeps AI adoption aligned to business priorities rather than a series of experiments.
In practical terms, governance should also cover logging and auditability, role-based access, prompt and data handling standards and a defined escalation path when outputs don’t meet the required standard. These controls are not there to slow down delivery. They are there to make adoption sustainable.
The lesson from Ruby is operational discipline
Ruby is a useful Australian case study because it combines three elements that are often separated: broad staff access, business-led use cases and central governance.
Key takeaways: build the platform and oversight controls, start with a small set of workflows tied to operational objectives, set baselines and only then expand who gets access. That is how you transition from AI experiments to operational improvements.
For organisations assessing their options, the objective is to improve specific business outcomes with controlled conditions; select the workflows that carry real commercial weight, integrate an AI assistant where it reduces cost or bottlenecks, measure the impact and continue improving workflows over time.
