What AI consulting actually delivers.

Two providers quote for "AI consulting". One comes back with a six-week engagement and a number. The other comes back with a four-month engagement and a much larger number. The buyer concludes that the second is expensive. Often the second is the only one of the two that was quoting for the thing the organisation actually needs.

This is not usually anyone behaving badly. It is a naming problem. AI consulting is advisory and delivery work that helps an organisation decide what to do with AI and then do it, and that description covers at least five distinct services with different deliverables, different durations and different prices. Until you know which one is on the table, you are not comparing quotes. You are comparing categories.

The five kinds of work sold as AI consulting.

In practice the phrase covers at least five distinct services: strategy and roadmap, readiness and feasibility assessment, build and delivery, embedded engineering capability, and governance and assurance.

1. Strategy and roadmap. Where AI fits in the business, which capabilities are worth developing, what the sequence is over 12 to 24 months, and what it costs. The deliverable is a decision document for an executive or a board. It is genuinely useful when the organisation has competing internal views and no agreed direction. It is close to worthless when everyone already agrees what to do and the blocker is execution.
2. Readiness and feasibility assessment. Whether a specific use case can actually be built on the data and systems you have. This is evidence work, not opinion work - it means profiling real source systems rather than asking people how confident they are. We have written about how to run an AI readiness assessment and about what should happen after one.
3. Build and delivery. Data pipelines, models, agents, the integration into the system of record, the monitoring, and the handover. This is the only category that produces something a user touches. It is also where the cost sits, which is why a strategy quote and a build quote look so different.
4. Embedded engineering capability. Senior engineers working inside your team on your backlog, rather than delivering a defined scope from outside it. Priced as capacity over time. Appropriate when the work is real but the shape of it changes weekly, and when you want the capability to stay behind.
5. Governance and assurance. Approval gates, model risk, audit logging, privacy position, and - for regulated entities - how the whole thing lands against your obligations. Frequently bought last, after something has already gone live, which is the expensive order to buy it in.

Why the distinction is a commercial problem, not a semantic one.

It depends entirely on which of the five kinds of work you are buying, which is why quotes so often look incomparable. A focused readiness assessment of a single business domain is a two to four week engagement. A strategy and roadmap piece is similar in duration but produces a different artefact. A build engagement is priced against a defined scope and runs in months, and embedded engineering is priced as capacity over time. A provider who gives you one number without naming the category has not scoped the work.

The failure mode this produces is predictable. An organisation buys strategy when it needed feasibility, gets a roadmap built on assumptions about data nobody checked, and discovers at build time that the first three items on the roadmap are not possible. The roadmap was not wrong. It was answering a different question.

What an engagement should give you, whichever kind it is.

Regardless of category, four things: a written scope that says what is in and what is out, a named person on the client side who owns the outcome, a price with a duration attached, and a defined end state that lets you stop. An engagement that cannot describe its own finish line is a retainer wearing a project's clothes.

The third of those is where most disputes start and the fourth is where most budgets quietly die. A duration without an end state means the work continues until someone loses patience. Ask, before you sign, what has to be true for the engagement to be finished, and get the answer in writing.

How to tell which one you need.

A short diagnostic, in the order we would run it.

• Can you name the workflow? If you cannot name a specific decision or process with a business owner and a measurable baseline, you need strategy or assessment, not build.
• Has anyone looked at the data? Not "do we have a warehouse" - has anyone profiled the actual tables the use case needs, in the last six months. If not, feasibility comes before anything else.
• Is the scope stable? A defined scope points to a build engagement. A backlog that changes weekly points to embedded capability, and forcing it into a fixed-scope project will produce change requests instead of software.
• Are you regulated, or handling personal information at volume? Then governance is not a later phase. It is a constraint on the design and it belongs in the first conversation.

Most organisations that think they have an AI problem have a data problem first. If the data the use case needs is not accessible, not agreed and not measured for quality, no amount of model selection will help. A competent AI consultant will tell you this and scope the data work honestly, rather than selling a model on top of foundations that will not carry it. It is also worth knowing in advance where AI agents do not work yet, so that a category error does not get discovered at build time.

Who is doing the work.

The question that matters is not the size of the firm but whether the people doing your work have seen the specific constraints you operate under: Privacy Act obligations on customer data, APRA expectations if you are regulated, and the practical reality of a data team of six rather than sixty. Ask who will actually be on your engagement and what comparable work they have delivered locally.

That last part is worth being concrete about, because it is checkable and most claims in this market are not. RUBIX has been doing data and AI work in Australia since 2011 - fifteen years - which matters less as a credential than as a source of priors: an engineer who has watched the same integration constraint play out at several Australian enterprises scopes it differently from one meeting it for the first time. The evidence is in the delivered work rather than in anything we could assert about ourselves, and the same test should be applied to every firm you shortlist, including us.

If you are weighing up local and offshore or global options, the specific trade-offs are set out in more detail on our AI consulting in Australia page and, for Victorian organisations, AI consulting in Melbourne.

Questions buyers ask.

What is AI consulting?

AI consulting is advisory and delivery work that helps an organisation decide what to do with AI and then do it. In practice the phrase covers at least five distinct services: strategy and roadmap, readiness and feasibility assessment, build and delivery, embedded engineering capability, and governance and assurance. They have different deliverables, different durations and different prices, so the first useful question to ask any provider is which of the five they are quoting for.

How much does AI consulting cost in Australia?

It depends entirely on which of the five kinds of work you are buying, which is why quotes so often look incomparable. A focused readiness assessment of a single business domain is a two to four week engagement. A strategy and roadmap piece is similar in duration but produces a different artefact. A build engagement is priced against a defined scope and runs in months, and embedded engineering is priced as capacity over time. A provider who gives you one number without naming the category has not scoped the work.

What should an AI consulting engagement deliver?

Regardless of category, four things: a written scope that says what is in and what is out, a named person on the client side who owns the outcome, a price with a duration attached, and a defined end state that lets you stop. An engagement that cannot describe its own finish line is a retainer wearing a project's clothes.

Do I need AI consulting or data consulting?

Most organisations that think they have an AI problem have a data problem first. If the data the use case needs is not accessible, not agreed and not measured for quality, no amount of model selection will help. A competent AI consultant will tell you this and scope the data work honestly, rather than selling a model on top of foundations that will not carry it.

Should I use an Australian AI consulting firm or a global one?

The question that matters is not the size of the firm but whether the people doing your work have seen the specific constraints you operate under: Privacy Act obligations on customer data, APRA expectations if you are regulated, and the practical reality of a data team of six rather than sixty. Ask who will actually be on your engagement and what comparable work they have delivered locally.

General information only, not legal or regulatory advice. Current as at September 2026.