The UK AI consultancy market grew faster than it could hire people who actually build production systems. Estimates put the sector at roughly £2.1 billion in 2025, with forecasts pointing well above £3 billion by the end of 2026. That growth attracted genuine practitioners — and a second wave of firms that repackaged existing software delivery or management consulting practices with AI branding and partner logos.
From the outside, the two groups are nearly indistinguishable. Same websites, same partner logos, same case study language. The difference surfaces in the questions you ask before signing a statement of work — and in how the answers hold up under follow-up. This guide gives you ten of those questions, explains what a good answer sounds like, and identifies the patterns in proposals that signal a firm is selling rather than delivering.
Why evaluation is harder in this market than in most
Procurement teams are used to evaluating software vendors and management consultancies. AI consultancy sits awkwardly between the two, and the usual signals don't travel well.
Platform credentials — Microsoft AI Partner, Google Cloud Partner, AWS Partner — are essentially marketing programmes. They require a minimum number of certified staff and some documented projects, but they do not validate delivery quality, engineering rigour, or sector-specific experience. A firm can achieve Partner status without having shipped a single production AI system that a real business depends on daily.
Case studies are written to impress, not to inform. They describe the problem and the outcome in general terms, omit the failures and restarts, and are often constrained by NDA to the point of being unverifiable. "We reduced processing time by 40%" tells you nothing about what was built, how it was integrated, who maintains it, or whether it still runs.
The demos always work. The system built specifically to demonstrate the capability in a controlled setting, with clean data and no edge cases, will perform well in a one-hour meeting. Production is where proposals diverge from reality — when the data turns out to be messier than expected, when the regulatory constraint wasn't accounted for, when the integration with the legacy system takes three times as long as scoped.
The UK market adds specific complexity that a number of AI consultancies — particularly those that have expanded here from the United States — are not well-equipped to handle. GDPR data minimisation obligations, the EU AI Act's applicability to UK firms with EU operations, ICO guidance on automated decision-making, and sector-specific regulation from the FCA, SRA, and others are not optional considerations. They are constraints that need to be built into the architecture from day one, not retrofitted after the system is running.
The ten questions below are designed to surface these distinctions. They are not gotcha questions — a competent firm will answer them readily. What you are listening for is specificity, honesty about limitations, and evidence that the firm has done this before under real conditions. See also our full guide to the UK AI consultancy landscape for broader market context.
The ten questions
1. Can you show me a system you built that is running in production today?
This is the most important question on the list, and the answer quality tells you most of what you need to know. A good answer is specific: the system, the client (or a description of the organisation with enough detail to be credible), the architecture, the integration points, who uses it, and what happens when it fails. A good answer may include a brief demo of the live system, or at minimum a credible account of what running in production actually looks like for this firm.
A bad answer involves case studies, NDAs, or vague descriptions of "a major financial services client." NDA constraints are real — but a firm that has built five or ten production systems can usually point to at least one where enough detail is available to be meaningful. If every engagement is behind an NDA, ask why. Confidentiality agreements typically cover client identity and commercial terms, not architecture or technology stack.
Follow-up question: who owns and maintains the system now? If the answer is always "the client took it in-house with our support model," ask to speak with that client. The handoff is where production AI systems frequently struggle.
2. Who will actually do the work on our engagement?
The bait-and-switch is common enough in professional services that procurement professionals have a name for it. A senior partner with credible experience pitches and wins the work. A team of contractors — often recently onboarded, often working across multiple engagements simultaneously — delivers it. The partner reappears at the monthly review meeting.
Ask for CVs and day-rate bands for everyone on the proposed team. Ask whether any team members are freelancers or sub-contractors rather than employees. In the UK context, this matters for a specific reason: if IR35 applies and the consultancy has not assessed it correctly, the liability sits with the end client in some circumstances. It is a reasonable question about both delivery quality and legal exposure. A firm with nothing to hide will answer it directly.
3. What is your discovery process and what do we receive from it?
Every serious AI engagement begins with discovery. The quality of that process — and the clarity of its output — is a strong predictor of everything that follows. A good discovery process is time-boxed (typically two weeks), fixed-price, and produces named deliverables: a data audit, a technical feasibility assessment, a regulatory considerations document, a scoped proposal for the build phase.
A bad discovery process is an open-ended workshop followed by a proposal. It produces no independent deliverable, creates no obligation on the firm to be specific, and positions the client to spend further money without a clear picture of what they are buying.
The key test: could you take the discovery output to a different firm and use it to brief them? If the answer is no — if the output is only useful in the context of continuing with this consultancy — that is a structural dependency built in from the start.
4. How do you handle UK regulatory requirements?
This question has several sub-parts depending on your sector. The baseline expectation is that any AI consultancy working with UK businesses can speak fluently about GDPR data minimisation obligations in AI systems, ICO guidance on automated decision-making under Article 22, and the EU AI Act's applicability to UK firms operating in or processing data from EU member states. These are not specialist areas — they are the floor.
Above the floor, the questions become sector-specific. Financial services firms need to understand how FCA Consumer Duty obligations apply to AI-assisted customer decisions, and how SR 11/7 model risk management applies to algorithmic systems. Legal firms need to understand SRA guidance on AI in legal practice, privilege considerations, and professional conduct implications. A consultancy that cannot name these frameworks confidently is not thinking about production — it is thinking about the demo.
Not "we take compliance seriously" — but: "For a system like yours, Article 22 automated decision-making provisions would likely apply, which means we need a human review step built into the workflow and a plain-language explanation of any decision that affects your customers. We'd recommend a data protection impact assessment before we touch your data, and we'd want to see your existing data processing agreements before scoping the architecture." If the consultancy can't speak at that level of specificity before the engagement starts, they won't be able to build a compliant system.
5. What does handoff look like — and who owns the system after you leave?
Lock-in is a business model. Some firms build in ways — proprietary tooling, undocumented integrations, opaque model fine-tuning — that make departure expensive. This is not always deliberate, but the effect is the same: the client is dependent on the consultancy for maintenance, updates, and incident response indefinitely.
Ask to see a sample handoff pack from a previous engagement. It should include full technical documentation, architecture diagrams, a runbook for common failure scenarios, training materials for the internal team that will own the system, and a transition support period with a defined end date. If the firm cannot produce an example, ask what they would include in one. The answer reveals how seriously they take knowledge transfer as a deliverable rather than an afterthought.
6. How do you handle scope changes?
Every non-trivial AI engagement encounters scope changes. Data is messier than expected. An integration takes longer. A regulatory requirement surfaces mid-build that changes the architecture. What matters is not whether scope changes happen — they will — but whether the firm has a structured process for managing them.
A good answer describes a named change request process: written scope changes, explicit impact assessment on timeline and cost, client sign-off before proceeding. A bad answer is "we'll figure it out as we go" or "we're flexible" — which in practice means uncontrolled cost increases and delivery delays that are difficult to attribute or contest.
7. What is your data security approach?
This question has become more important as AI systems increasingly touch sensitive data. Specifically: what data leaves your environment, what stays on-premises or in your cloud tenancy, and what sub-processor agreements cover any third-party model providers? If the system uses OpenAI, Anthropic, or any other external model API, a data processing agreement is required under UK GDPR before a single byte of personal data is sent to that provider.
Cloud region matters for some regulated organisations. UK-hosted or EU-hosted infrastructure is a requirement for certain financial services and public sector clients, and the consultancy should be able to tell you upfront which providers they use and where data is processed. "We use best-in-class security practices" is not an answer to this question.
8. Have you worked in our sector — and what are the specific constraints we should know about?
Generic AI experience does not transfer automatically to sector-specific delivery. The constraints in legal are different from the constraints in financial services, which are different again from logistics or healthcare. A firm that answers this question by listing sectors they have "worked across" is describing sales activity, not delivery depth.
A good answer is specific to your sector. It names the regulatory frameworks, describes the data challenges unique to your industry, and — importantly — identifies constraints you might not have considered. A consultancy with genuine sector experience will tell you things that complicate the proposal, not just things that make the sale easier. See our article on the difference between an AI advisory firm and an implementation partner for more on why sector depth matters at the build stage.
9. What does failure look like for this engagement — and what happens then?
Every project has failure modes. A consultancy that cannot articulate theirs has not thought seriously about delivery risk — or is not willing to discuss it with you, which is worse. The failure modes for an AI engagement typically include: data that turns out to be insufficient or too low-quality to train on; an integration that proves technically infeasible within the agreed scope; a regulatory constraint that changes the architecture materially mid-build; or a pilot that does not achieve the stated performance threshold.
"If the data audit in discovery reveals the training data isn't sufficient, we'll tell you before we proceed and refund the remainder of the discovery fee. If the pilot doesn't hit the agreed performance threshold after one iteration cycle, we review together and you decide whether to continue, pivot the scope, or stop. You won't be in a position where you've spent six figures and can't get out."
That is what a good answer sounds like. Silence, vagueness, or "we've never had a failed engagement" are the answers that should concern you most. For a detailed look at why AI pilots fail, see our article on the most common failure modes.
10. What is the total cost of this engagement — including infrastructure, data work, and ongoing model costs?
The headline consulting fee is rarely the total cost of an AI engagement. Data preparation — cleaning, labelling, structuring, and validating the data that the system will depend on — adds 40 to 60 per cent to most project costs, and it is consistently underrepresented in proposals. Infrastructure costs (compute, storage, hosting) and ongoing model API costs (if you are using a third-party model rather than a self-hosted one) recur indefinitely and should be estimated upfront.
Ask for a full-cost estimate that covers consulting fees, data work, infrastructure, third-party model costs, and an estimate of ongoing maintenance and support. A firm that cannot or will not provide this does not understand the full picture of what they are proposing to build — or is deliberately leaving cost components out of the initial conversation. For more detail on pricing structures across the market, see our guide to AI consultancy pricing in the UK.
Red flags in proposals
Beyond the ten questions, there are patterns in written proposals that signal a firm is optimising for the sale rather than the delivery. Team bios that appear before methodology sections suggest the firm's primary argument is credibility rather than process — which is worth examining. Proposals with no fixed-price option anywhere in the document mean you are carrying all the delivery risk. "AI-powered" used as a description without any specifics on the model, the integration, or the data pipeline is a marketing phrase, not a technical one. Platform vendor certifications cited as evidence of expertise — particularly when no production references accompany them — indicate a firm whose investment in AI has been primarily in sales positioning.
None of these signals is disqualifying on its own. A firm might lead with a strong team and follow with a credible methodology. But multiple red flags in a single proposal deserve direct follow-up before you proceed.
What a good engagement looks like from day one
A well-structured AI engagement begins with a fixed-price discovery phase that produces a document you own — data audit, feasibility assessment, regulatory considerations, and a scoped proposal for the build phase. The team is named before the engagement starts, with CVs available on request. You have a clear escalation path if the engagement is not going to plan, and weekly visibility into what is being built — not monthly review meetings where the project has already drifted. Regulatory obligations are addressed before a single line of production code is written, not flagged as a risk at the end of the engagement. The handoff — documentation, training, transition support — is scoped as a deliverable from the start, not negotiated when the project is over.
That structure is achievable. It is how competent firms operate. The ten questions above are designed to help you identify whether the firm you are speaking with actually works this way — or whether they are describing a process they intend to approximate once the contract is signed.
If you want an independent view of where your organisation stands before you brief a consultancy, our AI Audit is a two-week, fixed-price engagement that produces a clear output you own regardless of what you do next. Get in touch to discuss whether it is the right starting point for your situation.