Choosing an AI vendor: 7 questions that matter for SMEs
Published on 10/24/2026
You've received three proposals. All three promise "smart AI solutions that take your business to the next level." All three look professional. How do you tell which provider is serious, and which one is selling you a nice presentation with nothing workable behind it?
That's exactly the question SME decision-makers ask me. And the honest answer is: you don't recognize a good offer by the slides, but by what you get back when you ask the right questions. Below are seven of those questions — with an explanation of why they matter and what a good answer looks like.
Question 1: Can you show me something working — now, not in six weeks?
This is the most direct way to separate the wheat from the chaff. Every serious AI implementation partner has built something before. Ask for a working demo, a live prototype, or a concrete example of a finished project — something you can touch, try out, or at least look at directly.
Why it matters. Building is different from designing or advising. A provider that only runs workshops, presents frameworks, or delivers a roadmap doesn't solve your problem. You need someone who knows how it actually works — including the problems you'll run into along the way.
Good answer: a demo or reference implementation you can see or try. "We built something similar for [type of client], here's where you can look at it." Or: "Our own website already runs on this tech — go ahead and try it."
Red flag: "We'll start with a discovery phase and then put together a roadmap." If nothing concrete is on the table after three conversations, that roadmap is probably the final destination.
Question 2: What happens to my data?
This isn't a tricky question — it's a basic one. Any vendor working with your business data should be able to answer it clearly.
What you want to know: does your data go to a third party's cloud model? Is it used to further train a model? How long is it stored? Who has access to it? Is a data processing agreement (DPA) available?
Why it matters. For many processes it's perfectly fine to use a cloud LLM — provided the right agreements are in place and the data is suitable for it. For sensitive business information, customer data, or personal data, the requirements are different. A good vendor knows that distinction and explains it. (More on the trade-off between local and cloud in: Local LLM or cloud: what really happens to your data?.)
Good answer: a clear explanation of which systems are involved, what data they see, and where the data processing agreement can be found. No vagueness.
Red flag: "That's covered under the terms and conditions of the tool we use." That's not an answer — that's passing your question along.
Question 3: Who owns what gets built?
If a vendor builds something for you — a chatbot, an automation, an AI component in your workflow — who owns that code, that data, and that configuration afterward?
What you want to know: can you continue without the vendor afterward? Do you have access to the source code, the models, the prompts, the connections? Is everything transferred to you, or does it stay in the provider's environment?
Why it matters. Vendor lock-in is a real risk with AI implementations. If everything runs on a platform or in an environment the vendor controls, you're dependent. Want to switch, adjust, or bring it in-house later? That's a new project. Or a new invoice.
Good answer: "Everything we build belongs to you. The code, the configuration, the data. We deliver it in your environment and hand it over fully." And that's preferably written into the contract too.
Red flag: "We build it on our platform, you get access through a license." That's a subscription, not an implementation.
Question 4: How do you handle AI's limits and risks?
AI makes mistakes. Language models can invent things that sound convincing but are wrong — that's called hallucination. AI chatbots open to external users can be targeted for misuse. And not every AI system is suited to every type of decision.
What you want to know: how does the vendor acknowledge these risks, and what do they do about them? Do they build in warnings, moderation, fallbacks? Are they honest about what the system can't do?
Why it matters. A vendor who doesn't name AI's risks probably hasn't accounted for them in the design either. That becomes your problem the moment the system goes live and an employee or customer trusts a wrong answer.
Good answer: a concrete explanation of the system's limitations, how they're communicated to users, and what the fallback is when AI can't answer or gets it wrong. "We always build in an 'I don't know' response and restrict the system to the domain it's meant for."
Red flag: "AI is advanced enough now that this is rarely an issue." That's not an answer, that's hype.
Question 5: What do you measure, and how will I know it's working?
Success isn't a feeling — it's a number, a time measurement, a frequency, something you can compare before and after. Ask the vendor what they'll measure and how they'll make that visible.
What you want to know: how do they define success for your specific situation? What metrics do they propose? How and how often do they report on it?
Why it matters. An AI implementation that "just works" sounds good, but gives you nothing to steer by. Don't know how many questions the chatbot answers correctly? Then you also don't know when to update the documents, when to scale up, or when the system stops performing well. Success without measurement is just an opinion.
Good answer: "We define a success metric together before we start — e.g., X% of questions answered correctly without human intervention. We measure that weekly and report it in a dashboard you can access yourself."
Red flag: "We'll evaluate that after delivery." That means: we have no plan.
Question 6: What happens after delivery — maintenance and adoption?
A system that's finished isn't the same as a system that works. AI applications need maintenance: documents need updating, models get updated, prompts need adjusting as behavior changes, and users actually need to start using the system.
What you want to know: what's the plan after go-live? Is there a maintenance agreement? Who's responsible for updates and outages? How do they make sure people in your organization actually use the system?
Why it matters. The most expensive AI implementation is one nobody uses. That sounds dramatic, but it's one of the most common reasons pilots fail: the technology works, but adoption is zero. A vendor who stops after delivery leaves you with a system that slowly ages.
Good answer: a concrete plan for the period after go-live — who handles support, how staff get trained, what the agreements are on updates and bugs, how long the handover takes. Not "we're reachable if something comes up."
Red flag: the proposal ends at "delivery." Everything after that is extra.
Question 7: Am I dependent on you after this project?
This is the direct version of the vendor lock-in question. Ask it explicitly, even if you've already discussed ownership (question 3). Because dependency takes more forms than just code.
What you want to know: will your staff be able to manage and adjust the system themselves after this project? Or do you need the vendor for every small change? Has the knowledge actually been transferred?
Why it matters. A good partner wants you to come out of the project stronger, not to keep coming back for every adjustment. If a vendor holds back knowledge — deliberately or not — you're building a dependency that's expensive in the long run.
Good answer: "We provide documentation and training so your team can maintain the basics in-house. For extensions we can be available, but the choice is yours." And that's written into the proposal.
Red flag: "AI is complex, you don't want to manage this yourself." That might be true — but it shouldn't become a business model.
Overview: 7 questions for judging an AI vendor
| Question | What it tests |
|---|---|
| Can you show me something working? | Experience vs. theory |
| What happens to my data? | Privacy and transparency |
| Who owns what gets built? | Ownership and exit strategy |
| How do you handle AI risks? | Honesty about limits |
| What do you measure? | Steering by data vs. relying on gut feeling |
| What happens after delivery? | Adoption and sustainability |
| Am I dependent on you afterward? | Independence vs. lock-in |
How do you recognize a trustworthy AI vendor by their answers?
A vendor who answers these questions well will regularly say "it depends." That's not weakness — that's precision. AI works well for well-defined problems and less well for everything at once. A partner who acknowledges that and helps you choose is more trustworthy than one who promises AI will solve all your challenges.
By the way: if you ask these questions and the vendor responds defensively or vaguely, that's already valuable information in itself.
Want to see what a project like this looks like in practice? Read how a chatbot on your own documents works: Chatbot on your own documents: how RAG works for your business. Or first read how to start small and controlled: Starting with AI in SMEs: begin with one boring process. Want to know what the total investment will cost you, including the items vendors rarely mention? Read: What does AI really cost? Every cost for SMEs.
Got proposals on the table and want to know how to compare them side by side? In a free intake I'll look them over with you — no sales pitch, just an honest opinion. Book a free intake.