The first call with an AI vendor usually goes well. The demo is polished, the use case maps onto something on your priority list, and the pricing seems manageable. What you probably don’t do at that stage is ask whether your client data will be used to train their models, or what happens to your data if you want to leave. Those questions tend to come later, and sometimes too late.
What does a good AI vendor selection process actually involve?
A vendor selection process is the structured sequence you use to check whether an AI supplier can deliver for your business before you are committed to a contract. It covers four things at minimum: defining what you need the AI to achieve, screening for data safety and regulatory fitness, evaluating the vendor’s track record on comparable work, and running a time-limited pilot with clear criteria for going further.
What UK government guidance on SME AI adoption makes clear is that projects stall when objectives are vague from the start. A measurable goal is what your evaluation, your pilot, and your contract will all hinge on. Without one, you end up with a vendor proposal you cannot fairly assess, a contract you cannot hold anyone to, and a pilot that runs indefinitely without producing a clear answer.
The Local Government Association’s guide to buying AI, written for English councils but practical for any buyer, frames the decision in three phases: define the problem, assess the supplier, and govern the outcome. That structure holds for any owner-managed services firm.
Why does getting vendor selection wrong matter more than you’d expect?
A poor vendor choice tends not to show itself immediately. The first few weeks of a new AI tool typically feel productive. The problems arrive when you realise client data has been processed through servers you cannot locate, the system won’t connect to the platform you’ve relied on for years, or the vendor’s pricing was structured to make switching expensive.
Three risks stand out in the UK context.
Data controller liability sits with you, not the vendor. The ICO makes clear that if you appoint an AI vendor as a data processor under UK GDPR, you remain responsible for ensuring they handle personal data lawfully. Signing their standard terms of service does not transfer that accountability.
Lock-in is a documented policy concern. The Competition and Markets Authority’s 2023 review of AI foundation models flagged concentration risk and stressed interoperability and switching as principles for a healthy AI market. Smaller buyers tend to have less bargaining power when extracting themselves from a vendor relationship.
The consequences of poor AI decisions can also be public and severe. The Ofqual grading algorithm in August 2020 downgraded around 39% of predicted A-level grades in England and was scrapped after widespread backlash. The relevant lesson for any buyer is that accountability needs to be established before deployment, not after an incident.
What does a practical four-step selection process look like?
A workable process runs from problem framing to contract in roughly six to twelve weeks. Begin by defining one to three concrete outcomes with measurable targets. Pre-screen vendors on three non-negotiables: data residency, training-data policy, and UK regulatory literacy. Evaluate a shortlist of two to four suppliers across business fit, integration, and pricing. Close with a paid, time-limited pilot before any longer commitment.
The first step is to define the problem before selecting a product. What specific outcome do you want? Cutting email response time by 25%, or reducing invoice errors by half? The UK government’s research on AI in UK businesses cites vague use-cases as a primary reason SME pilots stall. A measurable target gives your evaluation and your contract something concrete to hold against.
The second step is pre-screening. Before investing time in a formal evaluation, ask every candidate three questions: Where will my data be stored and processed? Will my prompts or documents be used to train your models? Can you walk me through your security approach in relation to NCSC guidance? Drop any vendor who is vague. The NCSC’s paper on secure use of AI services specifically flags that generative AI APIs can expose inputs to model training unless contracts restrict this.
The third step is a structured evaluation across four axes: business fit and client references, technical and integration fit, compliance documentation, and pricing with exit terms. A scoring matrix prevents the choice from hinging on whoever gave the most polished demo.
The fourth step is a paid pilot, six to twelve weeks, with two or three quantified KPIs, defined data access boundaries, and explicit criteria for going further or stopping. The CDDO’s Algorithmic Transparency Recording Standard provides a practical template for documenting what you’ve deployed, even in a simplified form.
When does a full selection process make sense, and when can you simplify it?
A structured vendor process is proportionate to the risk involved in what you’re building. If you are handling personal data, working in a regulated sector, or deploying anything that affects client-facing decisions, the full process is worth the time. For low-risk internal experiments on non-sensitive materials, a lighter check of the vendor’s published policies may be sufficient for the purpose.
Three situations suggest a lighter approach is reasonable. If you’re testing AI tools on genuinely internal materials with no personal data involved, the published terms of major platforms may be enough. OpenAI’s API terms, for example, do not use submitted data for model training by default, and this is documented and verifiable.
If your firm has strong internal technical capability, building directly on commodity APIs under your own governance may make more sense than engaging an external vendor for each use-case.
Where regulation is still evolving, over-committing to a vendor-specific approach before the rules are settled carries its own risk. That argues for keeping model choice flexible even when you’re outsourcing implementation and integration work.
The clearest signal that you need the full process is that your clients’ data is involved, or that your sector has a named regulator who has expressed a view on AI.
What terms should you understand before you engage a vendor?
You don’t need a legal background to buy AI well, but five terms come up in almost every serious vendor conversation. Knowing what they mean before the first call means you can ask the right questions, assess the answers honestly, and spot the vendors who are glossing over things they’d rather you didn’t ask about.
Under UK GDPR, when you use an AI vendor to process personal data, you are the data controller and they are the processor. The accountability sits with you. The ICO’s guidance on AI and data protection sets out what this means in practice: you must vet the vendor, sign a data-processing agreement, and ensure they can meet your obligations toward your clients and regulators.
Data residency means where your data is physically stored and processed. For many UK firms handling client data, UK or EU residency is a baseline requirement. Ask for it in writing, not verbally.
A DPIA, or data protection impact assessment, is required when a new AI system involves high-risk processing, such as automated decisions about individuals. Your vendor should be prepared to support you in completing one where relevant.
At contract stage, two further terms matter. Your SLA sets the floor on uptime, response times, and remedies when the system fails. Sub-processors are the other suppliers your vendor uses to deliver the service. You have a right to know who they are, what data they can access, and how they are contractually bound.
When you can answer basic questions about all five of these terms, you’re ready to evaluate a vendor proposal with some confidence. That’s the point at which buying AI stops feeling like a leap of faith.
