Procurement teams are being told that their questions about artificial intelligence are naive, that the technology moves too fast for standard clauses and that the usual due diligence does not apply. The opposite is true. The questions procurement has always asked of a critical supplier are exactly the right questions to ask of an AI vendor. Who owns what we produce together. Where is our data. Who can see it. What happens when we leave. What happens when you fail.
What has changed is the set of acceptable answers. This article sets out the questions a serious buyer should ask, the answers a serious firm should be able to give in writing, and the answers that should end the conversation. It is written for the head of procurement, the general counsel and the chief information officer who will sign the same document, and it assumes the buyer is regulated: a bank, an insurer, a hospital group, a ministry, a listed manufacturer.
Who owns the model
The word "model" hides four things that can be owned separately, and a contract that does not distinguish them will be argued over later.
The base model is the artefact the vendor licensed or trained before you arrived. You do not own it and should not expect to. What you need is the right to use it for the term, and a documented path to replace it.
Fine-tuned weights produced from your data are a different matter. If your documents, transcripts or labelled examples were used to adapt a model, the adaptation carries your information. The buyer should own, or at minimum hold an exclusive perpetual licence to, any weights derived from its data, and the vendor should be prohibited from serving those weights to anyone else.
Prompts, system instructions, retrieval indices and evaluation sets are work product. They embody the buyer's policies, its edge cases and its judgement about what good looks like. They are the buyer's, without qualification, and must be delivered in a readable format on request and at exit.
Outputs are the responses the system produces. The buyer needs an unambiguous assignment of whatever rights exist in them, and an indemnity for third-party claims arising from the vendor's training data, within a negotiated cap.
Where is the training data from
A buyer cannot audit the corpus a frontier model was trained on, and a vendor that claims to have done so is exaggerating. What a buyer can and should demand is a documented position: whether the vendor trained the base model or licensed it; what the licensor has disclosed about data provenance; whether the model has been evaluated for regurgitation of copyrighted or personal material; and who carries the liability if a third party claims infringement.
The EU AI Act adds structure here. Providers of general-purpose models are required to publish a sufficiently detailed summary of training content and to maintain documentation on the model's capabilities and limitations. A vendor building on such a model should be able to point to that documentation. A vendor who cannot is either not paying attention to the law they are selling under, or is building on something they should not be.
For the buyer's own data the question is simpler. Was any of it used to train, fine-tune or evaluate a model that serves anyone else? The only acceptable answer is no, in writing, with a technical description of how that is enforced rather than a promise.
What happens to our prompts
Every prompt is a disclosure. When an analyst pastes a client's financial statement into a system, that statement has been sent somewhere. The buyer must know where, for how long and who can see it.
| Question | Acceptable answer | Answer that should end the conversation |
|---|---|---|
| Are prompts and outputs retained after the response? | No, or only for a fixed abuse-monitoring window that we can shorten or disable | "Retained to improve our services" |
| Where is inference performed? | A named legal territory, fixed by contract | "Globally distributed for performance" |
| Who at the vendor can access our content? | A named role, under a logged process, with access reviewable by us | "Authorised personnel" |
| Are prompts used for training or evaluation? | Never, technically enforced | "Only in anonymised form" |
| Can we hold the encryption keys? | Yes, with a documented effect of revocation | "Our encryption is industry standard" |
The legal frame depends on where you sit. The GDPR and the revised Swiss FADP both treat transfer to another jurisdiction as something requiring a legal basis and safeguards, and both hold the controller responsible for what the processor does. Jordan's Personal Data Protection Law requires a legal basis for processing and places conditions on cross-border transfer. HIPAA requires a business associate agreement with anyone who handles protected health information on a covered entity's behalf. In every case the vendor is a processor or a business associate, and a consumer-grade terms-of-service page does not meet the standard.
Can we leave
Exit is the question buyers ask last and should ask first. AI systems are unusually sticky: the prompts are tuned to one model's habits, the evaluation set encodes one model's failure modes, and the applications above are written against one interface.
A serious firm will offer, in writing, all of the following. Delivery of prompts, instructions, retrieval indices, evaluation sets and any fine-tuned weights in documented, open formats. A transition period during which the service continues at the existing price while the buyer moves. Documentation sufficient for a competent engineer to run the system elsewhere. Deletion of the buyer's data at the end of the transition, certified in writing, including from backups within a stated window.
A serious buyer will also insist on an architecture that makes exit plausible rather than merely permitted. A thin abstraction between the applications and the model interface. Evaluation sets that are model-independent. Retrieval built on the buyer's own infrastructure. These are engineering decisions, and they are cheap when made at the start.
Every clause about exit is a description of bargaining power. The buyer that can leave is the buyer whose problems get solved.
What happens when the model is wrong
The question is not whether the model will be wrong. It will. The question is what the system does when it is, and who is responsible.
Procurement should ask for the vendor's evaluation methodology: what the system was tested on, how the test set relates to the buyer's actual use, what the measured failure modes are and how they are monitored in production. A vendor who answers with a benchmark score has answered a different question. Benchmarks measure a model on tasks the benchmark author chose; the buyer needs to know how the system behaves on its own documents, its own callers and its own edge cases.
The buyer should also ask what the system does when it does not know. The right answer is that it says so, hands over to a person, or refuses. A system that always produces a confident answer is a liability in a regulated context, and a vendor that has not designed for refusal has not designed for you.
Liability follows. The vendor should accept responsibility for the system behaving as documented. The buyer should accept responsibility for how the outputs are used, within the process the two parties designed together. Where a decision affects a data subject with legal or similar significance, both the GDPR and the revised FADP require human involvement to be available, and the contract should say whose job that is.
Who is behind the firm
For a service that will sit inside a regulated process for years, the buyer needs to know the vendor will still exist, still be independent and still have the same people.
Ask who the engineers on the account will be and whether they are employees or subcontractors. Ask for key-person provisions: named individuals, notice of change, an obligation to replace with equivalent seniority. Ask about the vendor's own sub-processors and the notification process when the list changes. Ask about professional indemnity and cyber insurance, and read the exclusions. Ask what happens to the contract, the data and the weights on a change of control, and secure a termination right if the acquirer is unacceptable.
None of these questions are new. They are the questions procurement asks of any supplier of a critical function. They apply without modification.
The questions that end the conversation
Some answers should close the file, politely and without further discussion.
- A refusal to fix the legal territory in which inference runs.
- A licence to use customer content for service improvement that the vendor will not strike.
- A data protection agreement that names the vendor as a controller of the buyer's data rather than a processor.
- An inability to describe what the system does when it does not know.
- Exit terms that deliver "reasonable assistance" without naming the artefacts, the formats or the timeline.
- A key-person answer that names a sales lead and no engineer.
- Sub-processors described as "leading cloud providers" rather than by name and territory.
A firm that gives none of these answers may still be the wrong firm. A firm that gives any of them is.
What to do on Monday
- Take the vendor questionnaire your team already uses for critical suppliers and add one section: ownership of weights, prompts and outputs; retention of prompts; territory of inference; exit artefacts and formats; behaviour when the system does not know.
- Send it to every AI vendor in the current pipeline and rank them by the quality of the written answers, not the demonstrations.
- Ask the general counsel to draft the four clauses that matter most before negotiations begin: no training on customer content, fixed territory of processing, ownership of derived artefacts, and exit with named deliverables.
- Ask the CIO to require a model abstraction layer and model-independent evaluation sets as a condition of any pilot proceeding to production.
- Put key-person and change-of-control provisions into the template now, before the first vendor tells you they are unusual.