What is an AI consultant? Role, day-rates, and what good practice looks like in the UK
By Dean Griffiths · · Updated
An AI consultant diagnoses which problems AI should solve in your operation, advises on build vs buy, and (in practitioner-led practices) builds and deploys the system. UK day-rates run £600–£1,400/day depending on whether the consultant is advisory-only or builds production code. For UK mid-market operators, the clearest sign of a genuine consultant is a discovery call that produces a costed bottleneck map rather than a sales proposal.
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
| Model | Typical deliverable | UK day-rate 2026 | Best for |
|---|---|---|---|
| Advisory only | Strategy document, vendor selection, programme plan, business case | £600–£1,200/day | Large organisations with in-house engineering who need strategic framing before committing resource |
| Practitioner consultant | Discovery, scoping, production code, integrations, deployed system, documentation | £800–£1,400/day | UK mid-market operators without in-house AI engineering who need diagnosis and build in one engagement |
| Agency-billed engineer | Same as practitioner, through a multi-person firm with account management, PM, and strategy overhead | £1,200–£2,000/day | Larger enterprise scopes where parallel workstreams and formal process compliance are worth the overhead cost |
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 — 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:
- Production code: Ask to see a real deployed system, not a demo environment.
- Data handling: Ask how they would handle your specific data-sensitivity constraints (ICO, GDPR, regulated data).
- What not to build: Ask what they would tell you not to build, and why. This is the clearest indicator of genuine diagnostic capability.
- Integration depth: Ask for the integration list on their last comparable build and what was technically hard about it.
- 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.
Common questions on this topic
An AI consultant diagnoses which operational problems AI can solve, assesses build-vs-buy decisions, recommends the right tools and architecture for the problem, and (in some practices) builds and deploys the system. On a typical engagement: they run a discovery session to map where time and money are leaking in your operations; they map the data flows and integration landscape; they produce a costed recommendation with a clear build/no-build conclusion. The scope varies — some consultants only advise, others write the production code.
Not necessarily, though the best ones are. An advisory-only AI consultant may not write code — their value is in diagnosis, strategy, and vendor selection. A practitioner consultant both diagnoses and builds. For UK mid-market operators considering a bespoke AI system, a practitioner consultant (who can run discovery AND write production code) is almost always the more efficient model — you avoid the handoff from advisory to build, which is where scope gets diluted.
Day-rate ranges for 2026: advisory-only consultants typically £600–£1,200/day. Senior engineer-consultants (who build as well as advise) typically £800–£1,400/day. Larger agencies bill £1,200–£2,000/day for the same senior engineer time, with account-management and PM overhead stacked on top. For a UK mid-market build scoped at £50k–£150k, the total cost difference between the consultant model and the agency model is typically 30–60% on equivalent scope.
Three signals: (1) You have a clear operational bottleneck costing measurable time or money, but you do not know whether the fix is a voice agent, a CRM replacement, a document automation pipeline, or something else. (2) You have evaluated SaaS AI tools and they do not fit your workflow precisely enough. (3) You want the system's code to belong to your business, not a vendor's subscription. Any one of these usually justifies a discovery conversation.
Five tests: (1) Ask to see production code from a live build — not a demo, not a screenshot. (2) Ask how they would handle your specific data-sensitivity constraints. (3) Ask what they would tell you NOT to build. (4) Ask for the integration list on their last build. (5) Ask whether you will own the code. A genuine practitioner answers all five clearly and quickly. Someone repackaging AI tools as consulting fails one or more in the first ten minutes. See the full evaluation guide at the link below.
A well-run discovery call is a 45–60 minute technical conversation, not a sales pitch. The consultant maps your current workflows, identifies where time and money are leaking, assesses which of those leaks AI can fix, and produces a costed bottleneck map with a clear build/no-build recommendation. You should walk away with useful information regardless of whether you engage further — if the call is designed to produce a proposal rather than a map, that is a sales call, not a discovery call.
Still have a question? Book a discovery call — direct line to me, Dean.
Related capabilities
How to evaluate an AI consultant →
Five concrete tests that filter genuine engineers from prompt-slingers.
AI consultant vs AI agency →
Once you know you want a consultant, decide between independent and agency.
AI consultant vs AI engineer →
How the consultant and engineer roles differ, and when you need both.
Why discovery before build →
What a well-run discovery process looks like and what you get from it.
Book a discovery call →
See what a real discovery conversation looks like in practice.
Want to apply this to your operation?
A 45–60 minute discovery call. Map the bottlenecks. Get a costed bottleneck map — whether we build or not.
Book a Discovery Call