How to Choose a Data and AI Consultancy: A Buyer's Checklist

Choose a data and AI consultancy on evidence, not presentation. Ask for the named people who will deliver, a short proof of value on your own data, references you call yourself, written ownership of code and documentation, and a tested handover plan. Firms that resist any of these are telling you how the engagement will run.

Most consultancy selection processes reward the best pitch. The pitch is written by the most senior people the firm has, refined over dozens of bids, and illustrated with the most successful work it has ever done. None of that tells you how your programme will go. This checklist is about replacing presentation with evidence, while you still have the bargaining power to ask for it.

#Why Choosing a Data and AI Partner Is Harder Now

What this means for you: the failure rate in AI programmes is high enough that partner selection is a risk decision, not a procurement formality.

The headline numbers are sobering. MIT's 2025 study of enterprise generative AI found that around 95% of pilots were delivering no measurable impact on the P&L. Gartner, in a June 2025 press release, predicted that over 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls.

Neither figure means the technology fails. Both point to the same weakness: programmes that start with a model or a platform rather than with the data, ownership and operating changes that make the model useful. The question that sits under all of it is set out in why AI pilots stall on the data rather than the model, and a partner who cannot discuss it honestly is a partner to avoid.

The pitch is the best work a firm has ever done. Your programme will get the work it does on an ordinary Tuesday.

The market has also become crowded. Almost every consultancy now describes itself as data and AI led, from the global systems integrators to two-person boutiques. The labels no longer separate anyone, which is why the evidence has to.

#What You Are Actually Buying

What this means for you: define the outcome and the shape of the engagement before you compare firms, or you will compare pitches instead.

A data and AI consultancy sells three different things, often in one contract: judgement about what to build and in what order, engineering capacity to build it, and transfer of capability so your organisation can run it afterwards. Most disappointments come from buying one while assuming you are getting all three.

Be precise about which you need. A firm excellent at data strategy and sequencing may not have the engineering depth to deliver a platform; a strong engineering firm may build exactly what it was told to build without questioning whether it should. Neither is wrong. The mismatch is. Ask whether the firm will produce reference architectures your own team can extend, or only a system it alone understands.

#The Ten Questions to Ask, and the Evidence Behind Each

What this means for you: every claim in a proposal can be tested; this table tells you how, and what a weak answer looks like.

#Red Flags That Predict Delivery Problems

What this means for you: the warning signs are usually visible before contract signature, if you know where to look.

#Senior People Sell, Junior People Deliver

The most common pattern in consultancy disappointment is a change of cast after signature. The architect who impressed you in the bid appears at the steering committee once a quarter, while the work is done by people you never met. Ask for named key personnel in the contract, a minimum time allocation, and a right to approve replacements.

#Logos Instead of Decisions

A slide of client logos says a firm has had contracts, not that it delivered well. Ask instead for the decisions the team made on comparable work: which architecture option it rejected and why, for instance how it settled a choice like Snowflake versus Databricks for a given workload, what it would do differently, and what went wrong. Firms with real experience have scars and will talk about them.

#Accelerators You Cannot Take With You

Reusable frameworks and templates can save weeks. They can also become a quiet dependency if they are licensed rather than handed over, or written in a way only the firm can maintain. Our view on this is set out in who owns an AI system once the consultants leave, and the test is simple: could another firm, or your own team, run it next year?

If you cannot describe how you would leave a partner, you have not finished choosing one.

#Certainty Where There Should Be Doubt

A proposal that promises fixed outcomes on an estate the firm has not yet seen is either padded with contingency or written to win. Good partners state their assumptions, name the unknowns, and propose a short discovery to resolve them before committing to a price.

#Proof of Value: Testing on Your Own Data

What this means for you: a few weeks of work on your data will tell you more about a firm than months of meetings.

A proof of value is a small, paid piece of work on a real problem, using your data and your constraints, with success criteria agreed in writing beforehand. It differs from a proof of concept, which shows that something can work in principle. A proof of value shows whether it works here, and whether this team can make it work.

Keep it narrow: one data domain, one decision or process, a fixed period, and a clear measure. For AI use cases, judge readiness first, using a structure such as the five dimensions of agentic AI readiness, so the proof is not undermined by gaps the partner could not have fixed.

Run the same brief with two firms if the decision is large. Comparing two pieces of real work on the same problem is the most reliable evaluation method available, and the cost is small against the size of most data and AI programmes.

#Ownership, Handover and Exit

What this means for you: the clauses that matter most are the ones nobody looks at until the relationship ends.

Agree ownership of everything produced, including code, configuration, data models, documentation, prompts and the data governance records behind them, and require it to live in repositories and cloud accounts that you control from the first day. Ownership on paper means little if the only working copy sits in the supplier's environment.

Handover should be a planned phase with named receivers on your side, not a final week of documentation. A useful test is a period where your team runs the system while the partner only observes. If that period cannot be scheduled, the handover is not real.

Exit planning matters for the same reason. Define what happens if the relationship ends early: what is handed over, in what form, within what time, and at what cost. The governance evidence that a regulator would expect, described in the EU AI Act operating model for GenAI, also needs to remain with you, not with the supplier.

#Pricing Models and When Each Fits

What this means for you: the right pricing model follows the certainty of scope; the wrong one transfers risk to whoever understands it least.

Fixed price suits well-defined scope with known inputs, such as a migration of a catalogued set of reports. Time and materials suits discovery and work where the scope will change as you learn. Outcome-based pricing can align incentives, but only where the outcome is measurable, attributable to the partner's work, and not dependent on decisions the partner does not control.

Be wary of any firm that offers a single model for every kind of work. Fixed price on an uncertain scope produces change requests or quiet corner-cutting; open-ended time and materials on a well-understood scope produces drift. The cost of automating existing processes is a useful example of how hard scope can be to estimate, as the analysis of what replacing RPA with AI agents really costs shows.

For UK public bodies, the Procurement Act 2023, in force since 24 February 2025, adds structure: contracts above £5 million generally require at least three published key performance indicators, assessed at least annually. Private-sector buyers can borrow the same discipline.

#When a Formal Partner Evaluation Is the Wrong Approach

What this means for you: a heavy selection process can cost more than the risk it removes.

Not every engagement deserves ten questions, two proofs of value and a reference programme. For a short, bounded piece of work, such as an architecture review or a two-week assessment, a lighter process is better: one conversation with the people who will do it, a written scope, and a clear deliverable. Over-engineering the selection delays the very insight you were buying.

A formal evaluation is also the wrong tool when the real problem is internal. If ownership of data is contested, sponsors disagree on priorities, or nobody can say what success looks like, no partner will fix that from the outside. Resolve the AI readiness and data ownership questions first, then select a partner against a brief you believe in.

#Where to Start: A Six-Week Selection Plan

What this means for you: a structured, time-boxed process protects both your budget and your relationship with the eventual partner.

Week one: write the brief, including the outcome, the constraints, the scoring guide for the ten questions and the exit expectations. Week two: run conversations with four to six firms, insisting on meeting the people who would deliver. Week three: shortlist two or three on written answers and evidence, not on presentation.

Weeks four and five: run a paid proof of value with one or two firms on the same brief, and call references you selected yourself. Week six: negotiate the contract around the evidence, with key personnel, ownership, handover and exit clauses written in, and record why you chose as you did. If the work spans several functions, frame it as one transformation programme with clear sequencing rather than a set of separate purchases.

The scope of this plan is the selection decision, not the programme. It typically suits engagements large enough that a wrong choice would cost far more than six weeks.

#Frequently Asked Questions

#What should I look for in a data and AI consultancy?

Look for evidence rather than presentation: named people who will deliver the work, decisions they made on comparable engagements, a paid proof of value on your own data, references you choose and call yourself, written ownership of all code and documentation, and a dated handover plan. A firm that offers these without resistance is usually one that delivers the way it sells.

#How do I avoid senior people selling and juniors delivering?

Write key personnel into the contract. Name the lead and core team, set a minimum time allocation for each, and require your approval before anyone is replaced. Meet the delivery team before signature, not only the bid team, and ask each named person to describe a comparable problem they solved and what they would do differently.

#Should I pay for a proof of value?

Usually, yes. A paid proof of value on your own data, with success criteria agreed in writing beforehand, buys the attention of the actual delivery team and gives you ownership of everything it produces. Free proofs tend to be run by sales-focused teams on sample data, which tells you little about how the real programme would go.

#Who should own the code when a consultancy builds a data platform?

The client should own everything produced, including code, configuration, data models, documentation and prompts, and it should live in repositories and cloud accounts the client controls from the first day. Watch for reusable accelerators licensed rather than handed over, since they can create a dependency that makes changing partner later slow and expensive.

#Fixed price or time and materials for a data and AI project?

Match the model to how certain the scope is. Fixed price suits well-defined work with known inputs, such as a catalogued migration. Time and materials suits discovery and work that will change as you learn. Outcome-based pricing fits only where the outcome is measurable and depends mainly on the partner's own work rather than your decisions.

Unolabs is a Data and AI first engineering consultancy, headquartered in the United Kingdom with engineering operations in Pune and active engagements across the UK, Australia, and Hong Kong. We help enterprises build the architectural foundation for autonomous AI execution — governed data platforms, semantic intelligence, and agentic systems that enterprises can stand behind.

If you are weighing which data and AI partner to trust with your programme, book a discovery call and we will work through it with you.