How to choose an AI automation partner in the UK

The right AI automation partner is the one you could part with safely: the team that scoped the build also wrote the code, the price was fixed against your measured manual baseline, and at handover you hold the code, the prompts and the data, with documentation another team could operate from. Those conditions can be tested before a contract is signed, and this guide sets out the tests. Apply them to every supplier you speak to, including us.

Who scopes the work, and who builds it?

In many agencies the person who wins the work never touches it again: a senior consultant runs the scoping conversation, then delivery passes to whoever is free on the bench. The gap between those two people is where assumptions break and scope drifts. Ask directly who will write the code, and ask to meet them before signing. The strong answer is that the people who scoped the build are the people who will build it.

The same question surfaces subcontracting. A partner reselling another firm's delivery cannot answer detailed build questions in the room, and the extra margin has to come from somewhere. Neither arrangement is automatically disqualifying, and you are entitled to know which one you are buying.

How do they justify the price?

The first test is whether the supplier asks for your numbers before offering theirs. A build quoted against your measured manual baseline, the loaded hours plus the work the process currently loses, can be judged as a payback period. A quote with no baseline behind it can only be judged as a lump sum, and our guide to what AI automation costs in the UK sets out the four drivers any quote should be itemised against.

Fee structure is the second test. For a scoped workflow, a fixed fee means the supplier has done the estimating and carries the consequence of getting it wrong; a day rate on the same scoped work moves that consequence to you. Day rates have a legitimate home in genuinely exploratory work, and a supplier should be able to say which kind of work yours is.

Then ask for evidence, and be precise about what counts. A logo wall proves that sales happened; a reference client who can state what was measured before and after the build proves that results happened. Two or three referenced outcomes with numbers attached are worth more than any slide of brand marks.

What do you own at handover?

Handover should transfer the repository, the prompts, the configuration and the data, and the contract should say so before the build starts. A supplier who keeps the prompts, or hosts the system somewhere you cannot inspect, has converted a project into a dependency. Alongside ownership, put the data questions in writing: our guide to whether your data is safe with AI lists the ones worth asking, from where the data goes to whether it trains anyone else's models.

Ask what happens after deployment as well. The healthy structure is a choice: continue on an optional retainer for tuning and new workflows, or take the repository and run the system in-house. Any arrangement you cannot leave without losing the system is lock-in, whatever name it carries in the proposal.

Is the governance built or promised?

Ask where the controls sit in the build plan itself: approval gates on actions that move money or messages, logging on every action, monitoring against a baseline, and reporting a non-technical director can read. A supplier who schedules these for a later phase is telling you the first version will run without them, and later phases have a way of never arriving.

The same conversation should cover model errors. The credible answer describes an exception queue, where the system parks anything it cannot handle confidently for a person to decide, and our insight on why we build the exception queue first explains the pattern in detail. A supplier who claims the model rarely gets things wrong has not run one in production for long; a supplier who can show you an anonymised exception log from a previous build has. The four controls a board should require are set out in our board guide to governing AI, and a capable partner will recognise all four on sight.

Which kind of supplier fits which situation?

A freelancer is the cheapest route to a single integration, and where the job is one connection between two systems with no governance requirement, a good freelancer is often the right call. The trade-offs are continuity and controls: one person carries all the knowledge, and approval gates, logging and reporting are rarely part of the deal.

A large consultancy fits a multi-year transformation programme across many departments, where the work is as much organisational change as engineering and the budget supports a programme office. The weakness is anything small: a single workflow does not need a steering committee, and the day rates make short work expensive.

A specialist build partner covers the ground between the two: a working, governed system inside weeks, quoted as a fixed fee against your baseline, with ownership handed over at the end. That is the ground we occupy, which is exactly why the tests in this guide should be applied to us as firmly as to anyone else.

Run every candidate through the same eight questions: who builds, what baseline, what ownership, what governance, what happens on error, what evidence, what fee structure, and what happens after go-live. The supplier who answers all eight in writing, without being chased, is the one to shortlist.