What Does an AI Consultant Actually Do?

A developer builds what you specify; a consultant works out what should be specified. That distinction sounds academic until you have paid for the wrong thing. If you walk into a development shop and ask for a chatbot, you will get a chatbot — a good one, on time, on budget — and it may not touch the problem that made you want a chatbot, which might have been that nobody answers the phone after 4pm. A consultant should ask why you want it, look at where your enquiries actually come from, examine what happens to them now, and quite possibly tell you that the chatbot is the third-best use of your money. Then, if the diagnosis holds, the building happens. The distinction matters most when you are not sure what the problem is. It matters least when you know exactly what you want built, in which case a developer is cheaper and you should hire one. Some firms, including ours, do both — but they are genuinely different activities and it is worth knowing which one you are buying.

Almost nothing that looks like AI. The first week is watching how work actually happens, which is nearly always different from how anyone describes it and always different from what the process document says. That means sitting with the people doing the job, following a single item — an enquiry, an invoice, an application — all the way through the business, and asking why at every step. You will hear "we do it that way because of a decision made in 2019" more than once, and that is precisely the information you came for. In parallel: an honest inventory of what data exists, in what state, in which systems, and whether those systems can be integrated. The gap between believed data and actual data is the single biggest source of failed AI projects, and it is discoverable in the first week for a fraction of what it costs to discover it after a six-figure implementation. If a consultant spends week one presenting to you rather than asking you things, that is the engagement you are going to get.

Something you can keep and act on without the consultant, and that test filters out most of the bad ones. From a diagnostic engagement: a written map of your workflows, the systems and data behind them, the constraints attached to each — regulatory, technical, political — and a ranked shortlist of what to do first with realistic effort and payback, including the recommendations to do nothing. Good ones name what they examined and rejected, because the rejections are informative. From an implementation engagement: something running in production, plus documentation, plus access, plus someone in your business who can maintain it. What you should not accept as a deliverable is a relationship. If the answer to "what do I keep if we stop here?" is "our ongoing partnership", you have bought a subscription. The artefact test is simple: could you take the deliverable to a completely different firm and have them act on it? If yes, it is real.

Four things, and it is worth being blunt about all four. They cannot make you compliant — no consultant can take on your obligations under the Privacy Act, a prudential standard, a professional code or an assurance framework, and anyone offering to has misunderstood how accountability works. They cannot know your business better than you; process knowledge is yours and no amount of interviewing fully transfers it, which is why the good engagements feel collaborative rather than delivered. They cannot make change happen without you; if the people who would have to change their day are not on board, the technology is irrelevant, and consultants have been failing on that rock since long before AI existed. And they cannot make the technology do things it cannot do — if your data cannot support the model you want, no amount of expertise fixes it, and the honest consultant tells you that early rather than discovering it slowly on your budget.

Often by whether anyone in the room has shipped anything. A management consultancy that has added an AI practice brings genuine strengths: structured thinking, stakeholder management, change capability, and experience navigating large organisations — which is real work and is frequently the hard part in an enterprise. What they may not bring is anybody who has watched an AI system meet real users and fall over in the specific ways they do. That gap shows up as recommendations that are strategically coherent and practically unbuildable: the roadmap assumes an integration that the vendor does not permit, or a data quality that does not exist. The reverse failure exists too — technically excellent people who build the wrong thing beautifully because nobody diagnosed. Neither is a bad profession. The diagnostic is the failure question: ask what they have deployed that broke. People who have shipped answer immediately and in detail.

A free initial consultation first: a conversation about what is actually breaking, not a demo. A meaningful proportion end with us saying the timing is wrong, the business is too small, or an off-the-shelf tool and no consultant is the right answer — usually where a business is under about 20 staff. If there is a real opportunity, the AI Opportunity Audit at around $3,000 produces the written map: workflows, systems, data, constraints, and a ranked shortlist with realistic effort and payback. You keep it regardless, and plenty of clients take it and do the work themselves, which is a legitimate outcome. Where it stacks up, we build and ship the first workflow into production and stay involved while it beds in — because the first fortnight after real users arrive is where the actual design problems appear, and being absent for it is how consultants get their reputation. We are Melbourne-based and work with businesses Australia-wide, remotely.