Nine Questions to Ask an AI Supplier Before You Sign Anything

The demo was impressive. Of course it was — that's what demos are for. Now there's a proposal in front of you, a monthly figure, and a friendly person waiting for a decision.

You don't need technical knowledge to make a good decision here. You need nine questions, and the willingness to notice when an answer is a non-answer. Take these into the next call.

About the work itself

1. "Show me it failing."

Ask to see what happens when the AI doesn't know, or gets it wrong. Every good supplier has a ready answer, because they've thought hard about the failure path — usually a clean handover to a human with the context attached. A supplier who deflects this, or who implies it doesn't really happen, either hasn't built for it or isn't being straight with you. Failure handling is most of the engineering in a system like this.

2. "What's the boundary, in writing?"

Which jobs is it explicitly not going to do? You want this named in the proposal, not agreed verbally. Scope creep in AI projects doesn't usually come from the vendor — it comes from things going well and everyone assuming the system will now handle the next case too. A written boundary protects both sides.

3. "Who does this on your side after go-live?"

Sales, implementation and support are often three different groups, and the quality gap between them can be enormous. Ask who you'll actually be dealing with in month four, and how you reach them. If the answer is a generic ticket queue, price that in.

About your data

4. "Where does our data go, and who else can see it?"

Specifically: is it stored, where, for how long, and is it used to train anything shared with other customers? These have clear yes/no answers and any competent supplier can give them immediately. Hesitation here is a genuine red flag — not because the answer is always bad, but because it means nobody has asked before.

5. "What happens to it when we leave?"

Deletion on request, in what timeframe, confirmed how. Ask now, while you have leverage, because the conversation is much harder once you're mid-contract and unhappy.

6. "Can we get our data out in a usable form?"

Conversation logs, records, configurations, whatever the system accumulates. If the answer is "you can view it in the dashboard," that's a no. Data you can't export is data that keeps you where you are.

About the money and the exit

7. "What's the total cost in year two?"

Not the headline monthly figure — the whole thing. Setup, per-user or per-conversation charges, the usage tier you'll be in once it's actually busy, support, and any charge for changes. Ask specifically: if usage doubles, what does the bill do? Volume-based pricing that's cheap at pilot scale can be startling at real scale, and that's the moment you're most locked in.

8. "What does a change cost, and how long does it take?"

You will want changes. Your prices will move, your process will shift, a new question will start coming up. If every adjustment is a paid change request with a three-week lead time, the system will drift out of date within a year — this is the most common way a working setup quietly becomes a wrong one.

9. "What do we own?"

If something is being built for you, is the configuration, the prompt library, the integration work yours? Or is it the supplier's, with you licensing access to your own process? Neither answer is automatically wrong, but the price should reflect which one you're getting, and plenty of proposals are silent on this deliberately.

What a bad answer sounds like

Three patterns are worth learning to hear.

The redirect. You ask about data deletion and get an answer about how secure the platform is. Security and deletion are different questions. Ask again, once, plainly.

The reassurance without a mechanism. "Don't worry, our accuracy is very high." Accuracy compared to what, measured how, on whose cases? A supplier who has done this before will happily talk about how they measure it. One who hasn't will talk about how they feel about it.

The future tense. "That's on the roadmap." Fine — but buy what exists today. Roadmaps slip, and yours is not the only customer whose feature is on it. If the thing you need isn't built, that's a reason to wait, not a reason to sign.

The one thing to do before any of this

Write down, on one page, what you want the system to do, what it must not do, and how you'll know in ninety days whether it worked. Take that page into every conversation.

It does two useful things. It makes suppliers answer your question rather than pitch their product. And it protects you from the most expensive mistake in this market, which isn't picking the wrong supplier — it's buying something impressive before you'd decided what problem you were solving. That's how businesses end up with a capable system nobody uses.

If it helps, our free AI-readiness audit produces roughly that page for you, in a few minutes, with no obligation to work with us. Our pricing is published for the same reason — you should be able to compare without booking a call, and our security page answers questions four to six about us before you have to ask them.

At BuildPulse, we'd rather you asked us all nine.