AI practice
AI consulting in Australia: what you are buying, and how to tell if it is real
Most AI consulting in Australia is sold on a promise and priced on a slide. The useful question is narrower: which tasks your team repeats every week, working on which records, with what check by a human, at what cost per week, and what happens when it is wrong. This page is the buying guide we would want on your side of the table: the four things sold under the same name, the tests a workflow must pass, what Australian privacy law means for where the data goes, and the questions that separate a practitioner from a reseller.
One warning before the list. The word consulting is doing a lot of work in this market. A firm that sells an AI strategy deck, a firm that builds a custom assistant on your own records, a firm that embeds a vendor's model into your CRM, and a firm that resells a product with an implementation day attached can all describe themselves the same way on the same page, and the price difference between them is not a markup on the same service. It is a different service. Getting that clear first saves most of the money that gets wasted in this category.
What "AI consulting" is sold as in Australia
There are four arrangements, and they are not interchangeable.
- Advisory. Somebody interviews your team, produces a map of candidate use cases, scores them and hands over a roadmap with a business case attached. The deliverable is a document and, done well, a decision. No system changes, and nobody outside the room is affected.
- Custom build. A studio scopes one workflow, builds it against your systems and your data, puts it in front of your team, and then maintains it. The deliverable is working software with a named owner.
- Platform integration. A consultancy that already runs your CRM, ERP or field service platform adds model calls and automation inside it. The advantage is that the data is already there and permissions are already defined. The risk is that the firm's strength is the platform, not the model, and you find that out late.
- Product with an implementation wrapper. A vendor sells a defined AI capability, sometimes packaged as a set of agents or an answering service, and a partner configures it for you. The capability is fixed, the configuration is variable, and your process either fits the product or it does not.
The failure mode is almost always a mismatch, not incompetence. A business that needs one workflow rebuilt buys a roadmap. A business that needs a decision buys a build. A business whose process is genuinely unusual buys a product and spends three months discovering the edges it cannot reach. Before you talk to anyone, write one sentence that names the arrangement you want and the workflow it applies to, and put that sentence in the first email.
Three tests a workflow has to pass before anyone builds anything
Most disappointing AI projects in this market were the wrong project, started competently. Three tests catch that before it costs anything.
Does the task have a trigger and a finish?
An enquiry arrives and a quote goes out. A job is completed and an invoice is raised. A delivery is booked and the customer is told the window. Those are workflows: something starts them, something ends them, and you can point at both ends. "Improve the customer experience" is not a workflow. "Reduce admin" is not a workflow. If nobody can name the first event and the last artefact, the scope is a theme and it will expand until the budget runs out.
Can a person check the output in under a minute?
This is the test that decides whether you can put something into production safely. A drafted reply against a known service list is checkable at a glance. A summary of a job history is checkable against the job. A pricing recommendation on a bespoke build is not checkable at a glance, which means it needs a different design: constrained options, visible working, and a person who owns the number.
What does a wrong answer cost, and who catches it?
Ask what happens on the worst plausible day. If a wrong draft goes to a customer, it is embarrassing and fixable. If a payment goes to the wrong account, or a compliance date is filed incorrectly, the design has to prevent the error rather than review it afterwards. Where the cost of a mistake is not recoverable, the human does not approve the output at the end, the human takes the decision and the system assembles the evidence.
There is a fourth, quieter test: frequency and monotony. A task that happens twice a week is a process problem. A task that happens forty times a week, the same way, with the same fields, is where automation pays. Volume is what turns a clever prototype into something with a return.
What a scoped engagement looks like from your side
A good engagement has a shape you can see from the client chair, and it does not start with a model.
- One workflow, written down, with a definition of a good output. Before anybody touches a model, the two sides agree in writing what a correct result looks like, and on a set of real examples that includes the awkward ones. If that definition is vague, every later disagreement is unresolvable.
- Built against real records, including the messy ones. Data from your systems as they actually are: the duplicate customer, the job with no address, the enquiry that arrived as a photo. A build that only works on tidy examples has not been built yet.
- Run beside your team, with a person approving. The system drafts, a person checks, and that stays the arrangement until the output is demonstrably reliable. The approval step is not a sign of immaturity; it is how you learn what the system gets wrong while the cost of being wrong is still zero.
- Support and extend, in that order. Once the first workflow is settled, the next one is scoped. Programmes that begin with a roadmap across ten workflows usually stop at the first pilot, because ten half-built things produce nothing you can measure.
What you should be able to ask for at any point: the names of the people on the project, the single workflow in scope, the date the first version goes in front of a real user, the definition of done, and the test set the output is measured against. If those five things do not exist, the engagement is being run on enthusiasm. The AI practice page sets out how we structure that work, and the automation engagement page covers the commercial shape in more detail.
Data, privacy and the Australian operating context
The Privacy Act 1988 and the Australian Privacy Principles apply to personal information whether or not a model is involved. Putting an AI system in the middle of a workflow does not create an exemption, and it does not move responsibility to the vendor. Three things follow, and they come up in every serious conversation.
Cross border disclosure. If prompts, documents or records are sent to a provider that processes them outside Australia, that is generally a disclosure for the purposes of Australian Privacy Principle 8, and you need to know where inference physically runs, which entities are involved, and what the contract says about it. "The model is hosted overseas" is not the same answer as "your customer records are stored in Sydney and only the instruction text leaves". Get the specific answer in writing, and do not accept a data residency claim that has not been mapped to the actual flow.
Retention and training. Ask whether your inputs are retained, for how long, whether they are used to improve a model, and what deletion of a record actually removes. Ask which subprocessors sit behind the primary provider. Those answers change the design: if retention cannot be switched off, the workflow should not carry sensitive records, and it may need redaction before the model sees anything.
Sensitive information and decisions about people. Health information, biometric data and anything used to make a decision about a person's employment deserves a higher standard than an internal summary. Where a workflow touches rostering, performance, entitlements under an award, or any Fair Work obligation, the decision stays with a person and the system assembles the material. An audit trail that shows who decided, on what evidence, is worth more than a percentage of time saved.
The Privacy Act 1988, the Australian Privacy Principles (including APP 8 on cross border disclosure) and the Notifiable Data Breaches scheme are published by the Office of the Australian Information Commissioner at oaic.gov.au. Nothing on this page is legal advice; how the principles apply depends on what information your workflow handles.
What you are actually paying for
AI work gets quoted in three shapes, and it helps to know which one you are looking at before you compare numbers.
- Fixed scope discovery. A short, priced piece of work that ends in a written recommendation: the workflow, the definition of done, the systems involved, the risks and an estimate. Worth paying for when you have several candidate workflows and no agreement on which one matters.
- Per workflow build. A price for taking one workflow into production, including integration, testing and the first round of correction. Ask what is included when the workflow changes in month two, because it will.
- Run and support. A monthly arrangement for monitoring, corrections, model or vendor changes and small extensions. Ask what volume it assumes and what happens when volume triples.
The money does not mostly go into the model. It goes into the unglamorous parts: reading and writing to the systems that already hold the records, permissions, the awkward records that break the happy path, the evaluation set, and the change to how a person does their job on a Tuesday. A proposal that shows a large line for "AI" and nothing for integration is either a very small workflow or an incomplete estimate.
Watch for three things in a quote. Usage based model pricing with no ceiling, which puts your cost at the mercy of a vendor's rate card. A pilot with no success criteria, which cannot end. And a scope that quietly requires a new system of record, because that is a different project with a different budget. If your workflow lives in a CRM, the integration work is the project, and it is worth reading how we approach Salesforce work before you assume that part is trivial.
How to tell a practitioner from a reseller
These are the questions that separate a team that has shipped from a team that has presented. They are cheap to ask and hard to fake for long.
- Show me one workflow you have taken into production, and what it got wrong in the first month.
- What is your definition of done, and who signed it off on the last project?
- Which records does the system read, and which systems does it write to?
- How do you test output before it reaches a customer, and can I see the test set?
- What happens when the model changes underneath you?
- Where does inference run, and what do my provider terms say about retention?
- Who is on my project, for how many hours a week, and are they employees or contractors?
- What would you tell me not to automate?
The last one matters more than it looks. A practitioner has a list of things they refuse to hand to a model, and can explain why in plain language. A reseller says yes to everything, because the selling is the job and the delivery is somebody else's problem.
What to have ready before the first conversation
You do not need a strategy document to start. You need five things, and most of them already exist inside your business.
- The workflow, described in one paragraph, with the event that starts it and the artefact that ends it.
- Twenty to fifty real examples, including the ones that went wrong, redacted as needed.
- Access to a test environment or a read only copy of the data, so the build is not a guess.
- The person who owns that process, for an hour a week. Not a delegate. The person who knows the exceptions.
- An honest count of what it costs today, in hours per week and in the cost of a mistake.
With those five things, a first conversation is a scoping conversation. Without them, it is a capability presentation, and you will be asked to buy a discovery phase to produce the list above.
When AI is the wrong answer
Some of the most useful consulting in this category is a decision not to build. If a workflow is failing because a field is not captured, adding a model in front of it makes the failure faster. If the rule is deterministic, a rule beats a model on cost, latency and explainability every time. If the real problem is that nobody owns the process, a system will document that problem rather than fix it.
The honest test is whether the work is repetitive, the output is checkable, the volume justifies the build, and somebody inside the business will own it afterwards. Where those four hold, AI work tends to pay. Where one of them is missing, the cheaper fix is usually a form, a rule, a report or a person, and a consultant who will say so is worth more than one who will not.
Questions we get asked about AI consulting in Australia
What does AI consulting cost in Australia?
There is no meaningful benchmark without a scope, and any single number quoted before discovery is a guess dressed up as a price. What drives the number is the number of systems the workflow touches, how clean the records are, how much of the work is integration rather than prompt design, and whether you need a person in the loop on every output or only on exceptions. The useful comparison is not two day rates, it is two definitions of done. Ask each firm what is included at the end, and what they would charge to change the scope in month two.
Do we have to send data overseas to use AI?
Not necessarily, but you do have to know the answer for your specific stack. Some providers offer Australian processing regions, some route through the United States or Singapore, and some offer no residency commitment at all. The question to ask is where inference runs and where records are stored, as two separate answers, and then to check whether the contract supports what the salesperson said. Where the answer is not acceptable, the design changes: redaction before the model sees a record, a narrower instruction, or a smaller model that runs inside your own environment.
How long before we see something working?
A well bounded workflow, on data you can already access, can be in front of real users in weeks rather than quarters. Anything that needs a new integration to a system nobody has documented, or a data cleanup before the records are usable, is a project and takes longer. The reliable signal is not the timeline in the proposal, it is whether the first milestone is a working draft on real data or a document about working drafts.
Should we build an internal AI team instead?
If you have steady demand for this work across several years, an internal capability is usually the right end state, and an external team should be building towards it rather than around it. What you need internally is somebody who owns the workflow, can read the output critically, and can hold a vendor accountable, not necessarily a machine learning specialist. Many Australian businesses are better served by one internal owner plus an external build team than by hiring a team and giving it no defined work for the first six months.
Start with the workflow, not the technology
If you take one thing from this page, take the order of operations. Pick one workflow, write down what a good output looks like, check that a person can verify it quickly, confirm the volume justifies the build, and only then talk about models. Everything expensive in this category comes from doing those steps in a different order.
If you would rather have that scoping done with you than read about it, that is what the first conversation is for. Find out what to automate first takes a few minutes, and it ends in a shortlist rather than a proposal. If your workflow sits inside Salesforce or another platform we already work in, the studio covers how the practices fit together.