Every vendor will answer these questions, and answer them fluently. That is the problem: the question set is the easy part, and reading the answer is the skill. This page pairs each question with the plausible, confident, evasive reply most buyers accept and the specific reply that should reassure them, across six themes from accountability to exit. Put every question in writing, ask for the artefact rather than the assurance, and treat any answer that names a certification instead of a control as a finding.
Model behaviour changes under you, and lock-in is assembled quietly out of your own prompts and evaluation work. Both are cheap to settle before signature and close to impossible afterwards, which is why they belong in the first conversation and not the renewal.
The weak answer is that they continuously improve the model, so you are always on the best available version at no extra cost. The strong answer is pinned versions you choose, a notice period written into the contract, a published changelog and behavioural diffs between versions on a standard suite.
A status page and a developer newsletter are not commitments. What you want is a minimum support window stated in months, a period where both versions run, migration support, and a documented right to stay on the old version until your revalidation finishes. Retirement of a model you depend on should not arrive as a newsletter item.
Exporting your data through the API is not an exit. Ask for an enumerated package: records, prompt and configuration history, evaluation sets and results, embeddings, logs, and either the fine-tuned weights or a clear statement that they cannot leave. Ask what cannot be exported and treat that list as the true cost of switching.
Read the consent language rather than the marketing. A training default that a setting can switch off is a commercial position, not a control, so the no-training term belongs in the agreement.
Scope is the whole question. A certificate covering a corporate management system tells you nothing about the product you are buying, so ask for surveillance audit dates and any open non-conformities too.
Your cases, your graders, your rubric, and results you keep whatever they show. Make that right explicit in the trial agreement, since a guided proof of concept on a curated dataset proves nothing.
What it covers, whether output is included as well as the service, the cap, the conditions that void it, and who controls defence. Ambiguity here is always resolved against the buyer.
Ask for one artefact in the meeting rather than after it. The documentation index, the certificate scope statement, the eval suite, the indemnity clause. A vendor who has done the engineering can show at least one of them on screen within minutes. One that is always a week away has given you the answer.
Rarely, and it is worth pressing. Placing a system on the EU market or using its output in the EU pulls a provider in regardless of establishment. Article 50 transparency duties have applied since 2 August 2026 and were not delayed, and the December 2027 date they will cite covers Annex III high-risk obligations only.
It is evidence of information security controls, which is not the same thing. It says nothing about training data provenance, evaluation practice, model change notice or human oversight. Accept it for what it covers and ask separately for the documentation index, the eval results on your cases and the version policy.
More than most buyers attempt, and the asks that succeed are specific ones. No training by default, a named notice period for model changes, a minimum support window in months, an enumerated exit package with formats, and audit rights that survive termination. Vague commitments to best-efforts support are what get conceded instead.
Output is provided as-is, the customer is responsible for reviewing it, and total liability is capped at twelve months of fees. That is the market default and it is negotiable. Look for carve-outs on the failure modes that matter to you, a separate sub-cap or super-cap, and a review obligation scoped to defined decision types.
This one points outward at vendors. AI Governance: An Engineering Reference is the same subject turned inward, with the controls and artefacts you build yourself, AI Governance Under Regulation covers which duties bind you and by when, and Benchmarking AI Governance scores where you currently stand.
Whoever owns the decision the system will influence, plus someone who can read a contract and someone who can read an eval. Procurement alone gets fluent answers accepted. The combination catches the gap between what the product does and what the agreement obliges the vendor to keep doing.
Drop your details and we'll send AI Governance: What Buyers Should Ask straight to your inbox - no spam, unsubscribe anytime.
Put this question set to our engineering leads in a working session, and judge the answers by the artefacts rather than the badges. A vendor due diligence review, on us. SECTION 7 - FAQ - 5 to 8 questions
Book a due diligence review