How to choose an AI implementation partner in the UK: partner, in-house or systems integrator, and what the engagement must contain

An AI implementation partner is a firm you appoint to take a defined AI use case into production inside your business and to be accountable for the result. Choosing one is a different decision from choosing an AI consultancy in general. Our guide to choosing an AI consultancy in the UK covers the firm: who has shipped what, how they price, who pays them, who does the work, and when they would walk away. This guide covers the engagement: whether a partner is the right route at all, what the delivery work must contain, what it costs in the UK in 2026, what you should own at the end, and the red flags and questions that apply to implementation specifically. This guide refers to those seven questions rather than restating them.

The reason a separate guide is needed is that, in our experience, most disappointing AI projects were scoped badly rather than built badly. A buyer who can read a proposal and see that it lacks acceptance tests, an evaluation plan, a running-cost model or an ownership clause will avoid most of the failures that give AI implementation a bad name. None of that requires technical knowledge. It requires knowing what to look for.

What an AI implementation partner is, and is not

An implementation partner delivers a working, supported system in your environment and is accountable for it working. That is a different job from three things it is often confused with. A strategy consultancy produces a roadmap and a business case and stops there; it tells you what to build. A software vendor sells a product and its interest is in that product fitting your problem. A training or enablement provider helps your staff use tools that already exist. A partner takes a use case that has been chosen, and may have been piloted, and does the engineering, integration, evaluation and deployment needed to make it dependable, then hands it over.

The word "partner" is used loosely in this market, so test it against the work. If the proposal is for a report, a workshop series or a licence, it is not an implementation engagement whatever the firm calls itself. If it is for a working system with written acceptance criteria, a deployment plan and a handover, it is. Our AI implementation consultants page describes what we mean by the term and what an engagement with us contains.

Implementation partner, in-house team or systems integrator: how to decide

There are three ways to get an AI system built, and the right one depends on how central the system is to your business, how many systems and countries it touches, and how quickly you need a first production result. Most UK SMEs and mid-market firms are best served by a partner for the first production system and an in-house owner to run it afterwards, but the other two routes are right in defined cases.

Route	Choose it when	Strengths	Watch for
In-house team	AI is part of your commercial product, or you have a pipeline of internal use cases that will keep engineers busy for years.	The skills and the institutional memory stay in the business; priorities are set by you.	Engineers with production LLM experience are hard to recruit; the first system takes longest; one departure can stall the programme.
Systems integrator	A multi-country programme tied to an ERP or platform migration, with procurement and vendor relationships already in place.	Bench depth, programme management, familiarity with enterprise procurement.	Priced for programmes; the AI work can be a small part of a larger contract and treated accordingly. The firm-level checks are in the consultancy guide.
Implementation partner	A first production system, a stalled pilot, or a defined workflow across several systems, with a fixed scope and price and a handover.	Speed to a first result; the people who scope the work also deliver it; handover built into the engagement.	Continuity rests on a small team, so agree who covers if a named person is unavailable, and make sure what you keep is written down.

Three decision rules follow. First, if you cannot yet name the workflow, the systems it touches and the measure of success, you are not ready for any of the three; a readiness assessment is the cheaper first step. Second, if the system is core to your product, plan for an in-house team even if a partner builds the first version, and write the knowledge transfer into the engagement. Third, if the scope is a single workflow, a systems integrator's cost structure is unlikely to be proportionate; a partner or a hire usually is.

What a delivery engagement must contain

Whatever route you choose and whichever firm you appoint, an AI implementation engagement should contain the following ten things. A proposal that omits any of them is incomplete, and the omission is usually where overruns and stalled rollouts start.

1. A written scope that names the maturity level. A demonstration, a prototype, a pilot with real data and a production system are four different things at four different prices. The proposal should say which one you are buying and what "done" means for it. Our implementation page sets out the four levels and what each proves.
2. A data audit before design. The quality, accessibility and legal status of your data decide what can be built. The engagement should start by examining the data, not by recommending a model, and should produce a documented data classification and an exclusions list.
3. Written acceptance tests drawn from your real tasks. A vendor demonstration does not count. A held-out set of real examples, agreed before build, against which the finished system is measured. If the proposal has no acceptance tests, there is no agreed definition of success.
4. An integration design. Which systems the model will read from and write to (Microsoft 365, the CRM, the finance system, document stores), by what method (connectors, APIs, a retrieval pipeline), on what access scopes, and with what audit logging. For most business workflows the integration is the project and the model is a component.
5. An evaluation harness. Pass-fail rates, hallucination checks, prompt-injection defence and, where the use case warrants, data-leakage testing, run before go-live and recorded as acceptance evidence. Our guide to LLM evaluation for UK businesses explains what good looks like.
6. A staged deployment with monitoring and a cost cap. A pilot cohort, then a function, then the organisation, with monitoring, alerting and a budget cap on any step the model takes on its own, from the first production user.
7. A runbook, an acceptable use policy and trained administrators. The documentation and training needed for your own people to run the system, delivered before the wider rollout rather than promised afterwards.
8. A post-launch support period. A defined window after go-live, with review calls, in which the supplier fixes what real usage finds. Ours is 30 days. Ask what response times apply within it and what happens after it.
9. A running-cost model. Model usage, platform subscriptions, hosting and support, estimated at realistic volumes in pounds per month. Usage-based pricing means the bill scales with adoption, and a build quote without a running-cost model is an incomplete quote.
10. An ownership clause. Who owns the code, the prompts, the configuration and the data, and in whose name the accounts and repositories sit. The next section covers what it should say.

What AI implementation costs in the UK in 2026

Price ranges for AI implementation vary with the maturity level, the number of systems involved and the regulatory perimeter. The figures below are the ranges we publish; treat them as a reference for reading other firms' proposals rather than as a market survey.

• Entry point. Implementation engagements start from GBP 5,000 for straightforward deployments such as a customer-facing chatbot or a document-processing pipeline, delivered in two to four weeks.
• Medium implementations. Multi-system integration, a retrieval pipeline over a defined corpus or a bespoke workflow with approvals typically costs GBP 15,000 to GBP 50,000 over four to eight weeks.
• Fixed packages. Our published packages are a two-week Readiness Sprint from GBP 3,500, a four-to-eight-week Discovery and Pilot from GBP 15,000, and an eight-to-sixteen-week Build and Embed from GBP 40,000 with a 30-day post-launch support window, invoiced against milestones (typically 30 per cent at kick-off, 40 per cent at mid-point and 30 per cent on delivery).
• All-in cost. A single production deployment for a UK SME typically costs GBP 15,000 to GBP 150,000 once everything is counted. The published vendor fee is usually the visible part; data preparation, the UK regulatory overlay, change management, the run-rate and IR35 considerations routinely add 30 to 100 per cent on top. Our guide to how much AI implementation costs in the UK sets out the four-phase cost model and the hidden categories.
• Day rates. Where a scope is too open-ended for a fixed quote, our day rate is GBP 950 to GBP 1,500 depending on seniority, billed monthly in arrears against a timesheet. When comparing day rates between firms, ask who is delivering: a junior consultant's day rate is not comparable with a senior lead's.

All figures exclude VAT. Two reading rules help. A quote well below the entry point for a production system often describes a demonstration or a prototype, whatever it is called. A quote with no running-cost line is not comparable with one that has it, so ask for the missing line before you compare totals.

Who owns the code, prompts and data

You should own them, and the statement of work should say so before build starts, when it costs nothing to agree. The clause has four parts. Your data remains yours throughout and is processed under a data processing agreement (the processor terms and DPIA questions are covered under question six of the consultancy guide). Licences and tenancies (a Claude or ChatGPT workspace, a Microsoft tenancy) sit in your company's name and are paid by you to the vendor. Cloud accounts and code repositories are set up in your name, so that the supplier's access can be revoked without the system stopping. And the engagement ends with the code, prompts, configuration, documentation and operational runbook handed over, so the system runs without depending on the supplier.

Two further points belong in the same clause. Model providers deprecate and retire versions on published schedules, so the statement of work should say who is responsible for migrating to a replacement model and whether that is inside the fee or a chargeable change. And if the supplier uses any component it owns (a framework, a library, a prompt pack), the clause should say what licence you hold to it after the engagement ends. Our screening guide on whether an AI assistant rollout needs a DPIA covers the data protection side in detail.

Red flags specific to implementation partners

The firm-level red flags (a model recommended before anyone has looked at your data, case studies with no work described, no written answer on vendor payments, named people in the pitch and unnamed people in the statement of work, accounts in the consultancy's name, a retainer before a scoped first phase) are in the consultancy guide. These are the ones specific to delivery engagements.

• A demonstration or a prototype described as production, or a proposal that never names the maturity level.
• No written acceptance tests, or acceptance defined as "the client is satisfied".
• A custom model or fine-tuning proposed for an SME workflow before configured options (a Claude or ChatGPT workspace, a connector, a retrieval pipeline) have been tried and ruled out.
• Go-live planned as a single switch-over to every user, with no staged rollout, monitoring or cost cap.
• No running-cost model, or one that assumes usage stays at pilot levels.
• Evaluation described as "we test thoroughly", with no named metrics and no held-out examples.
• No handover plan, or a handover that consists of a final presentation.
• Nothing said about who migrates the system when the model version is retired, or whether that is inside the fee.

Eight questions to ask an implementation partner

Put these to any firm, including us, and ask for the answers in writing. They sit alongside, not instead of, the seven in the consultancy guide.

1. Which maturity level is this quote for, and what does "done" look like for it? A direct answer names one of demo, prototype, pilot or production and attaches acceptance criteria.
2. What will the acceptance tests be, and where will the examples come from? The answer should be your real tasks, held out from anything used to build the system.
3. Which systems will the model read from and write to, and on what permissions? A good answer names the systems, the method and the scopes, and says what is excluded.
4. How will you evaluate it before go-live, and will we see the results? Expect pass-fail rates on real tasks and the specific checks for your risk profile.
5. How will you deploy it, and what controls are in place from the first user? Staged rollout, monitoring, alerting, a cost cap and human approval on any step that changes a record or contacts a customer.
6. What does it cost to run each month at realistic volumes? A running-cost model in pounds, not a shrug about usage-based pricing.
7. Who owns the code, prompts and configuration, and who migrates the system when the model version is retired? The answer to the first part should be you, in writing, before build starts; the second should say whether migration is inside the fee.
8. What happens after go-live, and what will our own team be able to do without you? A defined support period, a runbook, trained administrators and a clear statement of what remains with the supplier (ideally nothing you need).

How The AI Consultancy answers

Our answers are on the AI implementation consultants page and on pricing, so they can be checked against what we say on a call. In short: every engagement is classified as demo, prototype, pilot or production at the outset; acceptance tests are drawn from your real tasks and written into the statement of work; the integration design comes before the model choice; the evaluation harness, staged deployment with monitoring and a cost cap, the runbook, the acceptable use policy and role-specific training are standard deliverables; post-launch support runs for 30 days with a final ROI report; running costs are modelled before you sign; and ownership of data, licences, accounts, code, prompts and documentation is written into the statement of work before build starts. We take no referral, reseller or deployment income from any vendor, which is set out on our independence page. For how our delivery model relates to the forward deployed engineering teams the AI labs now run, see our article on forward deployed engineering for UK SMEs.

Where to start

If you have proposals in hand, check each against the ten contents above and ask the eight questions in writing; the gaps will show quickly. If you are earlier than that, our guides to what AI implementation costs and to building versus buying AI cover the decisions that usually come first, and a readiness assessment is the lowest-cost way to find out whether an implementation engagement is the right next step at all.

Sources

• The AI Consultancy, AI implementation consultants, pricing and how much does AI implementation cost in the UK, as published on 8 November 2026.
• UK GDPR, Articles 28 (processors) and 35 (data protection impact assessment); Information Commission guidance on data protection impact assessments and on controllers and processors.

This article is general information for UK businesses, not legal or procurement advice. Prices and terms change; confirm the current position before relying on it.