What is an AI consultant? Role, day-rates, and what good practice looks like in the UK

The role, simply

An AI consultant is a practitioner (or practice) hired to help an organisation figure out whether AI should be applied to a specific problem — and if so, how. The work includes:

• Diagnosis: mapping current workflows, identifying where time and money are leaking, assessing which leaks AI can reliably fix.
• Decision support: build vs buy, which vendor or model fits the data-sensitivity and cost constraints, what the integration landscape looks like.
• Scoping: translating a diagnosis into a deliverable — what gets built, in what order, at what cost, with what success criteria.
• Build (in practitioner-led practices): writing the production code, building the integrations, deploying the system, and handing it over with documentation.

The last point matters: not all AI consultants build. Advisory-only consultants hand their diagnosis to an in-house team or a separate engineering firm. Practitioner consultants run the full engagement — from discovery to deployed system. For UK mid-market operators without an in-house engineering capability, the practitioner model is almost always more efficient.

What they don't do

A genuine AI consultant is not:

• A vendor salesperson pointing you at a SaaS product.
• A prompt engineer who has configured an off-the-shelf chatbot and labelled it "AI implementation".
• A generalist management consultant who has added "AI" to their service list without engineering capability behind it.
• A technology journalist or analyst who writes about AI trends without having built production systems.

The fastest way to tell the difference is to ask for production code from a live build. An advisory-only consultant may not have it. A prompt-repackager definitely won't. A practitioner engineer-consultant will show you a GitHub repository with named client work within a few minutes.

The advisory-only vs practitioner spectrum

UK market context

The AI consulting market in the UK covers a wide range of practice sizes and models: large management consultancies (McKinsey, Deloitte, PwC) with dedicated AI practices; boutique AI agencies (10–50 people) focused on specific verticals or technologies; and independent practitioner consultants running one-person or tight-team practices. For UK mid-market operators — typically £1m–£20m revenue, founder-led, without in-house engineering — the independent practitioner or tight-team model usually delivers the fastest, most cost-effective builds.

The large consultancies and mid-size agencies bring breadth and brand credibility but price at a level designed for enterprise procurement budgets. For a £50k–£150k bespoke AI system, their overhead structure means a significant portion of the fee is paying for people who are not writing code. For that scope, a senior practitioner is both cheaper and technically more appropriate.

What a good discovery process looks like

A well-run AI consultant's discovery process produces a costed bottleneck map — a clear breakdown of the operational problems worth solving, what a system to solve each would look like, and what it would cost. It should be specific to your operation, not generic.

Red flags that a "discovery call" is actually a sales call:

• It ends with a proposal document rather than a diagnosis document.
• The consultant talks more than they listen in the first half.
• The output is the same regardless of what you describe — a recommendation for the thing they already sell.
• There is no "this is what you should NOT build" moment. A genuine diagnostic process always surfaces scope that is not worth the investment.

The why discovery before build guide covers what a properly structured diagnostic process looks like and what you should walk away with.

The five tests for a genuine consultant

Before engaging any AI consultant — advisory or practitioner — apply these five tests, covered in full detail in the how to evaluate an AI consultant guide:

1. Production code: Ask to see a real deployed system, not a demo environment.
2. Data handling: Ask how they would handle your specific data-sensitivity constraints (ICO, GDPR, regulated data).
3. What not to build: Ask what they would tell you not to build, and why. This is the clearest indicator of genuine diagnostic capability.
4. Integration depth: Ask for the integration list on their last comparable build and what was technically hard about it.
5. Code ownership: Ask whether you will own the code, run it independently, and bring in any other developer to maintain it. Non-ownership is a lock-in signal.

A genuine practitioner answers all five clearly. The weaker the answers to 1 and 4, the more advisory-only (or prompt-relabelling) the practice is.