Most AI vendor questionnaires I see are the old security questionnaire with “AI” added to nine questions. Fifty-plus items, weeks of back and forth, and at the end of it nobody knows whether the product works.
The problem is that conventional due diligence tests availability and security. Those matter. But an AI system that is perfectly secure, fully available and quietly wrong 8% of the time will cost you far more than an outage, and no standard questionnaire will find it.
Here is what I actually ask.
The five questions that predict failure
1. How does this product fail?
Ask it directly, and listen to the shape of the answer. A vendor who has measured their failure modes answers specifically: accuracy degrades on documents under 200 words, error rate on this class of input runs around 4%, here is how customers typically notice. A vendor who says the system is highly accurate and rarely makes mistakes has either not measured or is choosing not to tell you.
This one question sorts the field faster than the other forty-nine combined.
2. What happens when you change the model?
Almost every AI product is a wrapper around a foundation model the vendor does not control. When that model is deprecated or upgraded, the product’s behaviour changes, sometimes materially, and often without notice. Ask what their model change process is, whether you get notice, and whether you can test before the swap. Most vendors have no answer because they have never been asked, and the ones who have thought about it will say so immediately.
3. Does our data train your models, and how is that enforced?
Not “do you train on customer data” as a yes or no. Ask whether the opt-out is a contractual obligation or an account setting, whether it applies to their subprocessors and their model provider, and what happens to data used for abuse monitoring or quality review. The gap between “we don’t train on your data” in marketing and what the terms of service actually permit is where most of the risk sits.
4. Where does inference physically run?
Where the company is incorporated is irrelevant. Where the tokens are processed determines your cross-border disclosure position under APP 8 and any sector residency requirement. Many providers route dynamically for capacity and describe onshore processing as a preference. If it matters to you, it needs to be a contractual commitment with a named region, not a statement of intent.
5. How do we measure whether it is working, six months in?
AI performance degrades. Input distributions shift, the underlying model changes, edge cases accumulate. A vendor with a mature product has a monitoring answer: quality metrics you can see, drift detection, a review cadence. A vendor whose answer is “our customers tell us if there’s an issue” has designed for the demo, not the third year.
The contract clauses buyers keep missing
| Clause | What to ask for | Why it matters |
|---|---|---|
| Training opt-out | Contractual, extending to subprocessors and model providers | A settings toggle can change; a contract cannot, quietly |
| Processing location | Named regions, with notice before change | APP 8 cross-border disclosure and sector residency rules |
| Subprocessor change | Notice period and a right to object | Your data’s path changes without your involvement otherwise |
| Model change | Notice, plus a testing window before a swap | Product behaviour changes when the underlying model does |
| Data export on exit | Usable format, defined window, deletion certificate | Lock-in is the most common and least discussed AI vendor risk |
| Output liability | Explicit allocation, not blanket disclaimer | Standard AI terms disclaim everything; that is negotiable at size |
| Price escalation | Cap, or at minimum notice | Token costs and infrastructure obligations are both moving |
Output liability deserves a note. Almost every AI vendor’s standard terms disclaim responsibility for the accuracy of output entirely, on the reasonable argument that they cannot control what a customer does with it. At small contract values you will not shift this. At meaningful values you can usually negotiate something narrower: warranties on a defined accuracy metric, or a service credit regime tied to quality rather than uptime. The mistake is not failing to shift it. The mistake is not knowing you did not.
Frameworks: useful floor, insufficient ceiling
Three are worth naming in an RFP.
ISO/IEC 42001 defines requirements for an AI management system. Certification tells you a vendor has documented processes and someone audited them. Genuine positive signal about maturity, no evidence at all about whether a specific product works on your data.
NIST AI Risk Management Framework gives a voluntary structure for identifying, measuring and managing AI risk. Useful shared vocabulary in a vendor conversation, and a decent template if you are writing your own assessment.
OWASP Top 10 for LLM and Generative AI Applications is the practical one for anything with an agent or a tool-calling surface: prompt injection, supply chain exposure, excessive agency. If your vendor has not read it and their product calls tools on your behalf, that tells you something. I have covered the agent security controls this maps onto in more detail.
Use all three as the floor for a serious vendor. Then test the product against your own data anyway, because none of them are evidence of fitness for your purpose.
The Australian layer
Four things specific to buying here.
Privacy Act. If the system contributes to a decision that affects an individual, the automated decision-making provisions are in scope, including transparency about the use of personal information in that decision. I have written on what the Privacy Act reforms require of automated decisions.
APP 8. Offshore inference is a cross-border disclosure. You remain accountable for what happens to the information. This is why question four above is not a technicality.
Sector regulators. APRA for financial services, ASIC for advice and disclosure, the TGA for anything approaching clinical use. These have not waited for AI-specific legislation and their existing obligations already bite.
Government flow-down. From 15 June 2026, Commonwealth agencies operate under mandatory AI requirements including impact assessments and procurement guidance, with full compliance due 10 December 2026. If you sell to government, expect those obligations in your contract. If you buy from a vendor who sells to government, they should already be able to answer all of this.
Run the pilot before the paperwork
The most useful due diligence I have ever done took four days and no questionnaire.
Take 200 real examples from your own process, with known correct answers. Run them through the vendor’s product during a trial. Count the errors, classify them, and look at what the failures have in common. You will learn more about whether the product works for you in that exercise than in six weeks of document exchange, and you will walk into the commercial conversation knowing something the vendor’s other prospects do not.
Then do the paperwork, because the contract terms above still matter and are far harder to fix afterwards. But do it knowing whether the thing works.
The failure I see most often is the reverse order: a rigorous procurement process, an impeccable security review, a signed three-year agreement, and the first honest accuracy measurement happening in month five. By then the sunk cost is doing the arguing.