Most AI vendor due diligence questions you find online are written to look thorough rather than to be useful. They ask for a glossy answer the vendor's sales team has rehearsed. The questions that matter are the unglamorous ones that separate a tool you can defend to a regulator from one you cannot.
This note is the short list we wish more buyers used. It is aimed at regulated and professional-services firms, where a bad answer is not just a wasted subscription. It is an exposure. Each question below comes with the answer you actually want to hear, so a smooth reply does not get mistaken for a good one.
Where does our data go, and does it train your model?
This is the first question because the answer reorders every other one. You want to hear that your data is processed in a known region, is not used to train the vendor's shared model unless you explicitly opt in, and is deleted on a defined schedule when you leave.
The answer to avoid is the warm reassurance with no specifics. "We take security very seriously" is not an answer. A region, a retention period, and a clear statement on model training are answers. If a vendor cannot tell you whether your client data trains a model other customers benefit from, treat that as a no until proven otherwise.
Can you show me the SOC 2 report, not just the badge?
A logo on a marketing page is a claim. The report behind it is evidence. Ask to see the current SOC 2 Type II report under NDA. Vendors that have one will share it, sometimes with a few sections redacted, and that is fine.
A vendor that declines outright, citing their own confidentiality, has told you something useful. It does not always mean the controls are weak. It does mean you are being asked to trust a claim you cannot verify, and you should price that risk in. For a firm that will itself be audited, an unverifiable supplier is a finding waiting to happen.
What happens when the model is wrong, and who is accountable?
Every one of these tools is wrong sometimes. The mature vendors know this and have an answer about logging, human review, and how a customer corrects an error. The immature ones talk as though the tool is not wrong, which is the more dangerous posture because it means they have not designed for the failure.
Ask specifically: is there an audit log of what the system decided and on what input? Can a human override it, and is the override recorded? If something goes wrong in a way that touches a client, what does the vendor's contract say about responsibility? You are not trying to offload all the risk onto the vendor. You are trying to find out whether they have thought about it at all.
How do we leave?
Exit is the question buyers ask last and regret not asking first. You want your data out in a usable format, on a timeline you control, with confirmation it has been deleted from the vendor's systems afterwards.
A vendor confident in their product makes leaving easy, because they expect you to stay for good reasons rather than because the door is welded shut. A complicated, expensive, or vague exit answer tells you how the relationship will feel in year three.