Short answer
Ask who owns the code, what happens when the model is wrong, whether it works on mobile data, and what maintenance costs. Vague answers on ownership and accuracy are the two reliable warning signs.
1. Who owns the result?
Get this in writing before anything else. You should own the code, the prompts, the trained artefacts and the data. If a vendor keeps ownership, you are renting something you paid to build, and switching later means starting over.
2. What happens when it is wrong?
Every AI system is wrong sometimes. The question is what the system does about it. Ask to see the failure path. If the answer is that it "rarely happens", the failure case has not been designed, it has been hoped away.
3. Can I see it fail?
Ask for a demo with a question outside its knowledge. A well-built tool says it cannot help. A poorly built one produces something confident and unfounded. This single test tells you more than an hour of polished demonstration.
4. Where does our data go?
Which provider processes it, in what country, retained for how long, and is it used for training. For anyone handling client files or personal data this is not optional, and the vendor should answer without hesitating.
5. Does it work on mobile data?
Ask them to open it on a phone on a normal connection, not office wifi. Plenty of tools that feel fast in a meeting are unusable in the field. See building for a slow connection.
6. What does it cost to keep running?
Separate the build price from the running cost. Model usage, hosting and maintenance are ongoing. A quote without a monthly running estimate is incomplete, and the gap tends to appear after launch.
7. Who maintains it in a year?
Models get deprecated, APIs change, your business changes. Establish whether you are buying an asset you can hand to any competent developer, or a dependency on one supplier. Ask for documentation as a deliverable, not a favour.
8. What would you not build for us?
The most revealing question on the list. A vendor who will build anything you describe is selling capacity, not judgment. A good answer names something specific they think is a bad idea and explains why. See when you do not need AI.
Warning signs
Ownership left vague. No answer on data residency. Accuracy described in percentages with no measurement method. A fixed quote given before anyone has looked at your data. Any claim that the system is never wrong.
Frequently asked questions
What should I ask an AI vendor before hiring them?
Cover ownership of the code and data, what happens when the system is wrong, where data is processed and whether it is used for training, performance on mobile data, ongoing running costs, and who maintains it after launch.
Should we own the code from a custom AI project?
Yes. You should own the code, prompts, artefacts and data. If the vendor retains ownership you are renting something you paid to build, and moving to another supplier means starting again.
How can I tell if an AI demo is misleading?
Ask it something outside its knowledge during the demo. A well-built system says it cannot help; a weak one answers confidently and wrongly. Also ask how accuracy was measured rather than accepting a percentage.