How to choose an AI implementation partner
Choose the partner whose normal project looks like yours, who shows you the people doing the work, and who agrees in writing that you own the code, prompts and evaluation data. Size match matters more than brand. The questions, red flags and pilot design below help you test a shortlist in two or three conversations.
Match the partner to your size first
A firm's typical project tells you how yours will be treated. A global integrator is organised around programmes with dozens of people. An AI-native consultancy is organised around teams of four to ten engineers for several months. A boutique studio is organised around a handful of senior people on a few projects at a time.
If your project is smaller than a firm's usual one, you tend to get junior staff and slow answers. If it is larger than its usual one, the firm will struggle to staff it. Ask each candidate for the size and duration of its median engagement, then compare that with your own plan.
Questions to ask every candidate
- Which systems like ours have you put into production, and are they still running today?
- Who exactly will work on our project, and how much of their week do we get?
- How do you test output quality before launch, and how do you track it afterwards?
- What happens when the model vendor changes or retires a model we depend on?
- Which parts of the solution are your reusable components, and under what licence do we get them?
- Where will our data be processed and stored, and who at your firm can see it?
- What does the system cost to run each month at our expected volume?
- Which of our ideas would you advise against building, and why?
Red flags
| What you hear or see | Why it matters |
|---|---|
| A demo built on sample data, with no plan for your systems | Integration and permissions are where most of the effort sits |
| No mention of evaluation or test sets | Without measured quality, nobody can say whether a change made things better |
| Senior people in the pitch, unnamed staff in the proposal | The team that sold the work may not be the team that does it |
| Prompts and configuration described as the firm's proprietary asset | You could be locked in to the partner for every small change |
| A large contract proposed before any pilot | You carry the risk before seeing results with your own data |
| Every problem answered with an agent | Simple automation or a search feature is often cheaper and more reliable |
Design the pilot so it can fail honestly
A pilot is a test, so it needs a pass mark set in advance. Write down one measurable outcome, such as time saved per case, share of requests handled without rework, or error rate against a human baseline. Agree on it with the partner before the build starts.
Use real data and real users from the start, even if the group is five people. Keep the scope to one process and limit the pilot to a fixed number of weeks. Ask for a short written recommendation at the end: go to production, change direction, or stop. A partner who is willing to recommend stopping is worth keeping.
Who owns the IP, the prompts and the data
Settle ownership in the contract before work begins. The default you should ask for is simple: everything built for you and paid for by you belongs to you.
- Code and configuration. Custom code, workflow definitions and infrastructure scripts are assigned to you and stored in your repository.
- Prompts and system instructions. These are part of the product. They should be versioned in your repository, not kept in the partner's tooling.
- Evaluation sets. The test cases and expected answers used to measure quality are yours, because you will need them to check every future change.
- Fine-tuned models and embeddings. Anything trained or indexed on your data stays in your accounts.
- Partner components. Pre-existing libraries may stay with the partner, but you need a perpetual licence to keep using them if the relationship ends.
- Accounts and keys. Model, cloud and tool accounts are opened in your name, with the partner given access.
Check how the handover works
Ask what you receive on the last day: documentation, a runbook for common faults, access to monitoring, and training for the people who will own the system. Ask whether the partner offers a run phase and what it covers. Then call one reference client and ask a single question: what happened in the three months after launch.
Common questions
How many partners should we shortlist?
Three is enough. Pick them from the tier that matches your size, send each the same one-page brief, and compare how they scope the first project. More than three mostly adds meeting time.
Should we run a paid pilot with more than one partner?
Only if the project is large enough to justify it. Parallel pilots double the demand on your own staff. A paid assessment from two firms is a cheaper way to compare thinking before you commit to one build.