Buying AI: five questions that should shape the contract

AI contracting discussions often focus on three familiar issues: whether customer data can be used to train or fine-tune a model, who bears the risk of third-party IP claims, and who owns AI-generated outputs. Those issues matter, but they are only part of the AI procurement question.

A better starting point is how the system actually works: what it does, what it can access, where the supplier adds value, how it connects to other tools and data sources, and whether the contract framework fits together.

1. What role will the AI system play?

AI contracting should not be one-size-fits-all. Applying use-case-agnostic template clauses to every solution can create negotiation friction and miss the issues that matter most for the particular AI tool and context.

An AI tool summarising internal documents has a different risk profile from an AI system embedded in a customer-facing product, regulated workflow or agentic system that can trigger actions elsewhere.

That role should shape the contractual focus. Internal-only outputs carry one risk profile; a regulated or customer-facing context shifts the focus towards testing, oversight, auditability and escalation.

2. Where does the supplier add value?

AI contracting often majors on whether customer data can be used to train or fine-tune models. However, as AI models increase in power and capability, AI services may not depend on fine-tuning at all.

Instead, suppliers may use off-the-shelf models, with their value sitting elsewhere in the stack: prompt engineering, retrieval-augmented generation, knowledge bases, embeddings, integrations, guardrails or workflow design.

Buyers need to understand which part of the system is being adapted, what data is used at each layer, and what rights apply to prompts, retrieval sources, embeddings, feedback data, telemetry, analytics and other artefacts.

A clause dealing only with model training may miss how the service works in practice.

3. What is dealt with in the contract, and what belongs in governance?

A contract is not the only tool for managing AI risk. Where responsibilities sit on the customer side, governance may be the more effective mitigation strategy.

For example, suppliers will often expect the customer to review AI outputs before relying on them. Where that is the case, contractual protections need to be supported by governance controls: user training, permitted-use rules, human oversight and escalation routes.

However, governance should not become a substitute for supplier accountability. The contract still needs to support the customer’s governance framework through appropriate disclosures, documentation, cooperation, records, technical controls and clear limits on how the service may change over time.

4. What happens when the AI system connects to other tools and data sources?

AI procurement is increasingly moving beyond standalone tools. Agentic AI and MCP-style architectures, which standardise how AI systems connect to external tools and data sources, mean a system may not only generate outputs but retrieve information, call tools and trigger workflows across connected systems.

For example, the supplier may provide the AI layer, but the customer may decide what the system connects to, what permissions it has and what actions it can take. In those cases, important parts of the risk are set by deployment configuration, not just by the supplier contract.

The legal questions therefore move beyond what the supplier does with customer data. Buyers also need to understand what the system can access once connected, what actions it can take, what approvals or human checks are required, and who is responsible for each connection.

We explore these contractual considerations further in our agentic AI series – see here.

5. Does the contract work as a whole?

AI terms rarely operate in isolation. Sometimes they sit within a wider suite: master terms, product terms, data protection terms, acceptable use policies, AI addenda and upstream model-provider terms incorporated by reference.

That can create a “Russian doll” problem. For example, the AI addendum may say customer inputs will not be used for training, while product-improvement, service-improvement, analytics or intellectual property provisions elsewhere give the supplier wider rights. An output indemnity may look broad but be limited by caps, exclusions or carve-outs in another document.

AI terms need checking against the whole contractual framework that governs them, or the customer may negotiate the visible protections while the operative risk allocation sits elsewhere.

A system-led approach to AI procurement

The contractual focus should be organised around the system itself: what it does, where the supplier adds value, what sits in governance, how it connects, and whether the framework holds together.

That approach helps ensure that the contract supports safe deployment, effective governance and a credible response if the system is later challenged. More fundamentally, it helps ensure that the contract addresses the risks most likely to arise in practice.