Procurement's AI Questionnaire Era: What Due Diligence Now Asks, and How to Answer It
The AI questionnaire is now a standard item in technical due diligence. It sits alongside the SOC 2 and the DPA as a precondition for vendor onboarding, and it is filling up with questions that did not exist eighteen months ago. The pattern is consistent across enterprise buyers: training-data provenance, evaluation practices, incident disclosure, and model-dependency mapping are the four sections where answers trip vendors up.
This piece lays out what those sections actually demand, how prepared vendors are demonstrating competence, and how buyers should read answers that are short, polished and empty.
Section 1: Training-data provenance
The question is not “does your model infringe copyright.” That question is unanswerable from the outside. The question is “can you document where your training data came from, and what controls stop customer data from entering it.”
A credible vendor answer includes a sourced inventory of training corpora with licences, an explicit statement that customer inputs are excluded from training (or a defensible opt-in regime), and a named internal owner for data provenance. The document should carry a version and a date. An undated policy page on the trust centre is not an answer to the questionnaire.
Red flags in the answer: “we comply with all applicable law” with no specifics; claims that provenance is impossible to track at scale; or refusal to disclose even the class of sources used. Vendors whose answers degenerate to hand-waving on this section usually fail the later ones too.
Section 2: Evaluation practices
The buyer wants to know whether the AI feature in the product was ever tested against realistic data before it shipped, and whether that testing is repeatable. The demands to make:
- A named evaluation suite covering the feature’s primary tasks
- The threshold that fails the build, stated as a number
- A recent regression incident, described, with the fix
- Who owns evals inside the engineering organisation
Vendors with mature evaluation programmes answer this section easily. The answers tend to be short, specific, and unglamorous. Vendors without them produce long prose that describes testing in the abstract without ever naming a suite, a threshold, or a past failure. Length in this section is inversely correlated with maturity.
Section 3: Incident disclosure
Incidents happen. The questionnaire exists to find out how they are handled. The demands:
- A published incident-response policy covering AI-specific failure modes: hallucination-led data corruption, agent runaway, prompt injection through third-party content
- A commitment to notify affected customers within a defined window for defined severity classes
- At least one retrospective example, post-incident, describing what broke and what changed
A vendor that has never had an AI incident is either not logging or not disclosing. Both are disqualifying for production use. The right answer candidly describes past failures and the corrective actions that followed.
Section 4: Model-dependency mapping
Few vendors build on a single model. Production agent systems route across providers, fallback tiers, and cached responses. The questionnaire asks for the map: which providers the product depends on, for which features, with what fallbacks, and what happens to your data at each hop.
A credible answer names the providers in the critical path, the regions data traverses, and the retention policies at each external API. The vendor that cannot name its own model dependencies is not practicing due diligence on its supply chain, and should not be trusted to practice it on yours.
How vendors should prepare
The questionnaire is a writing exercise, not a legal one. Preparation is mostly assembling evidence the engineering organisation already has.
| Evidence | Where it usually lives | Turnaround problem if it does not |
|---|---|---|
| Training-data inventory | MLOps or research team wiki | Weeks of reconstruction |
| Eval suite + thresholds | CI pipeline configs | None — if it exists, it’s queryable |
| Incident retrospectives | Postmortem docs | Impossible to invent convincingly |
| Model-dependency map | Infrastructure documentation | Needs an actual architecture review |
| AI-specific incident policy | Legal/security overlap | One meeting; not a project |
The two pieces of evidence that cannot be assembled retroactively are eval history and incident retrospectives. If the organisation lacks either, build them now and accept that this year’s answers will be thinner than next year’s.
How buyers should read the answers
The grading rubric is simpler than procurement usually admits. Score each section on three checks.
- Specificity. Numbers, dates, and named artefacts over prose.
- Consistency. The answer in section 2 should not contradict the answer in section 4.
- Freshness. Documents dated within the last six months, signed by an owner who is still at the company.
Any section that fails two of three checks goes back for clarification. Sections that fail all three are the ones the deal should not survive.
What this changes
The AI questionnaire is doing for AI vendors what the security questionnaire did for cloud vendors a decade ago. It is forcing the discipline that should have existed anyway, and it is punishing the ones who have been shipping theatrics over engineering. The vendors who invest now will treat the questionnaire as a reusable asset. Everyone else will keep writing long, apologetic answers that lose deals in the final review round.