How to choose an AI engineering consultancy

The three kinds of 'AI consultancy' — and which you need

The first kind is the strategy or slideware consultancy. It produces roadmaps, opportunity assessments, maturity models, and readouts. This work has real value when the question is genuinely strategic — market positioning, portfolio prioritisation, board education. It has almost no value when your actual problem is that a model needs to run reliably in production and nobody on the team has shipped one before. The tell is the deliverable: if the engagement ends with a document and no running system, you bought strategy, whatever the title said.

The second kind is the staff-augmentation body shop. It sells you contractors by the hour or the month. This is the right instrument when you have a working system, a clear plan, and simply need more hands that fit your existing process. It is the wrong instrument when you need judgement about an architecture you have never built, because you are paying for hours, not outcomes, and the ownership of the design sits nowhere. The tell is that you are managing the work and carrying the risk; they are supplying capacity.

The third kind is the engineering partner. It is a small team of senior engineers who embed with yours, make architectural decisions with you, and ship production code, infrastructure, evals, and runbooks that your team keeps and can maintain after they leave. You are buying an outcome and a capability transfer, not a document and not raw hours. This is the right choice for the most common situation an engineering leader faces: a hard, unfamiliar production AI problem, a real deadline, and a team that will own it forever but has never built one before.

Most confusion — and most disappointment — comes from buying one kind while needing another. Decide which shape your problem actually is first. If you cannot yet tell, that is itself a signal you may want a short, scoped engineering engagement rather than a big strategy one.

What a real AI engineering partner actually does

Strip away the category and the work is concrete production engineering. The recurring pieces are the same across most serious engagements. Cost engineering: instrumenting token and call spend, routing each request to the cheapest model that passes your quality bar, caching and batching so an agent loop does not quietly go quadratic. Evaluation harnesses: the regression suites and golden datasets that let you change a model or a prompt without shipping a silent quality drop — the single most under-built part of most AI stacks.

Then the plumbing that makes a demo into a system. Productionisation: retries, timeouts, fallbacks, observability, load behaviour, and the difference between a notebook that worked once and a service that holds at 3am. MCP and tool integration: wiring models to your real data and actions through the Model Context Protocol and typed tools, with the access controls that implies, instead of pasting context by hand. Agent-readiness of your own codebase: whether your repo, docs, and CI are structured so that both your engineers and coding agents can move through it safely — the golden paths, the guardrails, the readiness work that determines how fast everything after this goes.

The distinguishing feature is what is left behind. When a real engineering partner finishes, you have running code in your repository, tests and evals in your CI, dashboards on your infrastructure, and runbooks your on-call can follow — plus engineers on your side who understand all of it because they built it alongside the partner. The deliverable is a system your team owns and a team that can now own it.

How to evaluate one without being dazzled

Ask for proof of work, not case-study logos. Open-source contributions, public repos, technical writing with real detail, or a scoped paid pilot tell you more than a client list you cannot verify. You are hiring engineering judgement; make them show engineering. A firm that cannot point at anything it has actually built should worry you.

Meet the people who will do the work. A common bait-and-switch is a senior partner in the sales meeting and junior contractors on the delivery. Insist on talking to the actual engineers, and confirm the ratio of engineers to account managers and analysts. In a real engineering partner, the people billing you write code.

Make ownership and handoff explicit in the contract. Who owns the IP, the model artefacts, the evals, and the prompts — you should. Is there a written handoff plan and a defined end state, or an open-ended dependency? A good partner is trying to make itself unnecessary; a body shop is trying to stay embedded. Check vendor-neutrality: are they recommending the model, cloud, and tools that fit your problem, or the ones they resell? Reselling incentives quietly distort architecture.

Probe the security and data posture early. Where does your data flow, which providers see it, how are secrets and model access controlled, and can they speak fluently about data residency and GDPR — not as a checkbox but as a design constraint. If a firm gets vague when you ask where the data physically goes, that is a red flag regardless of how good the demo looked.

Consultancy vs hiring in-house — the honest version

Hiring in-house is usually the better long-term answer, and any honest partner will tell you so. AI is becoming core to most engineering orgs, and core capability belongs on your payroll where it compounds, builds institutional memory, and is not a recurring line item. If your AI work is central, ongoing, and you can attract and afford the talent, hire — and a partner who pushes back on that is optimising for their revenue, not your org.

The catch is timing and the current market. Senior AI engineers who have actually shipped production systems are scarce and slow to hire; a good search can take six to twelve months, and you may not yet know enough to interview well or to onboard the first hire into an empty greenfield with no patterns to follow. Meanwhile the deadline does not move. That gap — real problem now, right hire much later — is exactly where a partner earns its keep.

So the sharpest use of a partner is rarely instead of hiring; it is to de-risk the hard first phase and to build the thing your first hires will inherit. Bring in a partner to establish the architecture, the evals, the golden paths, and a working production system, then hire into a codebase that already has shape and standards — and have the partner help you interview and onboard, because they now know exactly what "good" looks like for your stack. Pairing a partner with your first hires, in that sequence, tends to beat either alone.

Be equally honest about when not to bring anyone in. If the problem is genuinely exploratory with no deadline, if you have capable people who just need time and cover to learn, or if the work is small enough to absorb, an external engagement can be overkill. A partner is worth it when the cost of getting the production architecture wrong — in spend, in rework, in a stalled launch — clearly exceeds the cost of the engagement.

UK and EU considerations: residency, GDPR, timezone

For UK and EU buyers, where a partner sits and where your data goes are not cosmetic. Under UK GDPR and the EU's regime, personal data flowing into an AI system carries obligations about lawful basis, data residency, sub-processors, and international transfers — and the EU AI Act adds risk-tiered duties that a partner building your system should be able to design around, not discover later. A partner fluent in this treats residency and data-flow mapping as an architectural input from day one, which is cheaper than retrofitting compliance onto a system that already leaks data to the wrong region.

Locality helps here in practical, unglamorous ways. A partner operating under the same UK/EU legal framework as you, able to keep data in an aligned jurisdiction and to reason about GDPR and the AI Act as a peer, removes a class of friction that an offshore or US-only firm can create. We are a UK, Scotland-based practice, so this alignment is native for us — but the honest point is to test it, not to assume it: ask any candidate firm where data resides and how they handle transfers, and judge the answer.

Timezone and working-hours overlap matter more than they seem. Embedded engineering is high-bandwidth — pairing, incident response, fast review cycles — and a full working-day overlap with a UK or European team makes that rhythm possible in a way a twelve-hour offset does not. None of this makes distant firms bad; it makes overlap and legal alignment worth pricing into the decision rather than ignoring.

Questions to ask, and red flags to walk away from

Ask these directly. Who exactly writes the code, and can I meet them? Can you show me something you have built or contributed to? Who owns the IP, evals, and models at the end? What does handoff look like and when are you done? How do you keep model and tooling recommendations vendor-neutral? Where does our data physically go and how do you handle GDPR and transfers? How do you measure whether the system is actually working — what does your eval setup look like? Clear, specific answers are the product you are buying.

The red flags are consistent. Guaranteed outcomes and no talk of evaluation — anyone promising accuracy figures without a way to measure them is selling, not engineering. Slides where you expected a system, or a refusal to do a small scoped pilot before a large commitment. Senior faces in the pitch, juniors in delivery. Lock-in by design: proprietary wrappers you cannot maintain, IP that stays theirs, or an engagement with no defined end. Reselling dressed as advice, where every recommendation happens to be a product they partner on. And vagueness about data and security the moment you get specific. Any one of these is a conversation to have; several together is a reason to keep looking.