How to choose an AI vendor without getting it wrong
The questions that separate a serious technology partner from a well-produced demo, and the contract clauses worth reviewing before signing.
The AI market is saturated with proposals, and presentation quality doesn't correlate with delivery quality. The good news is that a short set of questions separates them fairly well.
The five questions to ask
1. Can we run a trial on our data?
The most revealing question. A demo on prepared data proves little. A solid vendor will process a real sample and show results, including the cases where it fails.
If the answer is no, for whatever reason, that's a strong signal.
2. Who will actually work on the project?
The gap between the sales team and the delivery team is often large. Meet the people who will be involved, their experience, and how much time they'll dedicate.
3. Where is our data processed and stored?
On which infrastructure, in which jurisdiction, for how long, and whether it's used to train models. The answer belongs in the contract, not in an email.
4. What happens if we stop working together?
What we take with us: data, configuration, code, documentation. In what format. How long migration takes. A vendor who hasn't thought about this, or avoids it, is building dependency.
5. What are the solution's limitations?
A vendor who answers "none" or retreats into generalities either doesn't understand their product or won't explain it. The one who names concrete limitations and how they handle them is usually the one who has been through real implementations.
The three vendor profiles
The AI specialist. Technical depth, strong model results. The risk is integration: many deliver an excellent solution that connects to nothing.
The technology integrator. Knows your systems and how to connect them. The risk is shallowness on the AI side, which can produce a correct but ineffective solution.
The product vendor. Sells a configurable tool. Lower cost, lower flexibility. Works when the use case is standard.
None is better in the abstract. What matters is matching the profile to the problem: if the challenge is integration, the second weighs more; if the challenge is output accuracy, the first does.
References worth taking
Asking for references is standard; what matters is what you ask. Three useful questions for a previous client:
- What turned out differently from the plan, and how was it resolved?
- How much internal team time did it actually consume?
- If you started again, what would you do differently?
The answers to those three say more than any published case study.
The clauses that matter
Before signing, review four points:
Ownership. Of specific developments, of configuration, of data generated during use.
Confidentiality and data use. Explicit: your data isn't used to train third-party models.
Service levels. Incident response times, availability, consequences of failure.
Exit. Portability in a standard format, transition assistance period, and what happens to your data afterwards.
A practical way to decide
Contract a small scope first. A four to six week project, with a concrete deliverable and a bounded payment, teaches more about a vendor than any evaluation process.
You observe what actually matters: whether they meet deadlines, how they communicate problems, whether the assigned team is the one promised, and whether the result resembles what they described.
With that information, the decision on a larger contract rests on evidence rather than a presentation.
Frequently asked questions
What should we ask a vendor before contracting?
A trial on your own data, references from clients with similar cases, clarity on where data is processed, and exactly what happens to the solution if the relationship ends.
Should we pick an AI specialist or a general technology provider?
It depends on the case. For a narrow, specific project a specialist brings depth. For a solution that must integrate with several systems, integration experience matters more than model expertise.
What are the warning signs that a vendor isn't right?
Refusing a trial with real data, being unable to explain the solution in plain language, avoiding any discussion of limitations, or not providing verifiable references.