How to choose an AI consultant.
You are choosing someone to understand a business problem, test an approach and help your team use the result. A good buying process makes those responsibilities explicit.
Choose an AI consultant by the relevance of their experience, the clarity of their proposed scope and how they will demonstrate a useful result. Ask about data access, evaluation, recurring costs, ownership and support. Credentials can support the conversation, but they do not replace evidence for the work you need.
Do they understand the job before naming the tool?
Describe the process and listen to the questions. A useful conversation should cover the people doing the work, the inputs, the exceptions and what happens after an output is produced. The supplier should be willing to explain when a simpler process change or existing product could be sufficient.
Ask for a plain-English description of the first engagement. If the proposal is for discovery, what decision will it help you make? If it is a build, what will your team actually be able to do at handover?
- Which part of our problem needs AI, and why?
- What would you investigate before committing to this approach?
- What is the smallest useful first scope?
Ask for evidence relevant to your requirement
A demonstration can show an interaction; a case study should explain a real engagement. Ask which is being presented. For a production example, look for the problem, the consultant’s actual contribution, the constraints and the evidence behind any claimed outcome.
Check credentials through the issuing organisation where possible and read their exact titles. A course completion, learning badge and professional certification are different things. More useful than a long logo strip is an explanation of how the person will handle the specific work in your brief.
Find out how they will prove it works
Ask to agree representative test cases and acceptance criteria before development. Include ordinary tasks, incomplete inputs and examples that should be declined or handed to a person. The evaluation should cover the surrounding workflow as well as the model’s answer.
For a system that can take actions, ask which permissions are granted and how approval is enforced. For a knowledge assistant, ask how access restrictions, outdated sources and deleted documents are tested. A promise to monitor the system later does not replace a launch evaluation.
| Area | Ask the supplier |
|---|---|
| Scope | What is included, excluded and dependent on us or another supplier? |
| Quality | Which examples will we test, and who decides whether they pass? |
| Access | Which information and actions can the system use? |
| Failure | What will users see when an answer or integration fails? |
| Cost | What do we pay initially and as usage grows? |
| Handover | What accounts, code, documentation and training will we receive? |
Compare the cost of owning the result
Separate consultancy and development from model usage, hosting, licences, maintenance and future changes. Ask what usage assumptions inform the estimate and how costs will be monitored. Be clear about who pays third-party suppliers and owns the relevant accounts.
Understand how you can export data, change provider or hand support to another team. Ownership and access terms belong in the proposal. A low initial quote can be difficult to assess if the ongoing operating responsibilities are unclear.
Buy a clear next step
Where uncertainty is high, a scoped assessment can be the right first purchase. Where the task and inputs are understood, a limited pilot can provide direct evidence. Either way, agree what happens at the review point and avoid treating expansion as automatic.
Bring your priorities, representative examples and known constraints to the conversation. The goal is a shared brief that lets you judge the result and gives the supplier enough information to make a responsible recommendation.