Insights/16 Sep 2026

Borenius’ Tech Blog: Contracting for AI

Part 1 of 2 – Definitions, data rights and AI Act compliance

Every major change in enterprise technology – outsourcing, cloud, SaaS – has eventually forced contracts to evolve. Artificial intelligence just moves faster and has raised the stakes for both buyers and suppliers.

An AI system interprets inputs, draws inferences, and generates outputs that may vary even for the same input. How it arrives at those outputs is often difficult to explain or audit, and the supplier may use the data it processes to retrain or improve its models. These characteristics challenge contract structures that were not initially designed for them.

This is the first of two posts examining the contract areas that deserve particular attention when AI is involved.

Definitions

Terminology in the AI contracting space remains inconsistent, which makes it important to define clearly what falls within scope.

A clear, technology-neutral definition should be broad enough to cover the system as it evolves over the term. However, it should be specific enough to be meaningful.
It matters whether the contract covers a standalone AI system or a broader IT service that incorporates AI as one component, as this shapes how far the AI-specific terms need to reach.
Where third-party AI is incorporated into the supplier’s product, the contract should define what constitutes third-party AI and address how responsibility for those components is allocated.

A point increasingly seen in practice: a schedule listing the specific models or components in use, updated as the system changes, alongside the definition itself.

Data rights and ownership

An AI model trained on customer data learns from it, which may inform outputs delivered to other customers. This shifts the central question in data provisions from storage and access to control over who captures the value the data creates.

Buyer side: Break “data” into distinct categories, e.g. input, output, training, derived, aggregated, and metadata, as each category raises different ownership and usage questions. Input data should expressly remain the buyer’s. Before feeding data into the system, the buyer should verify internally that it has the necessary rights to the data and that no restrictions prevent or limit its use for that purpose. The supplier should be prohibited from using the buyer’s data for training or improvement without prior written consent.
Supplier side: The product should work fully without relying on any individual buyer’s data, since the supplier may not obtain the right to use it. Where the supplier wishes to use buyer data beyond core service delivery, the contract should include an express grant of that right. Still, buyers who do not grant it need to receive a fully functional product.

Granular consent for training use is increasingly the default negotiating position on the buyer side, including in standard-form arrangements rather than only in custom deployments.

AI Act compliance and risk classification

The EU AI Act classifies AI systems by risk level and imposes obligations that follow the system through the value chain. In a typical supplier-customer relationship the supplier is the provider and the customer the deployer, but the allocation is not fixed. A deployer that rebrands a high-risk system, substantially modifies it, or changes its intended purpose can become the provider, inheriting the provider’s obligations.

Buyer side: The starting point is understanding how the system is classified under the AI Act. While lower-risk systems mainly carry transparency obligations, high-risk systems carry significantly heavier ones – including human oversight, operational monitoring, log retention, and incident reporting. The contract should require the supplier to deliver the instructions for use, technical documentation, and ongoing cooperation the buyer needs to comply with its duties.
Supplier side: The supplier’s main risk is losing control of its own compliance position. Where the role flip described above happens, the original supplier is released from provider status for that specific system in relation to that buyer but must still cooperate and provide technical access. Contracts should define the intended purpose and permitted modifications to avoid unintended support obligations.

It is also worth noting that where a high-risk AI system incorporates a third-party AI model or component, the AI Act requires a written agreement specifying the information, technical access and assistance the supplier needs from that third party to meet its own compliance obligations. The same logic applies upstream: the buyer-supplier contract should secure equivalent commitments for the buyer as deployer.

Final thoughts

Definitions and provisions related to data usage set the foundation for the rest of the contract, including the compliance obligations the AI Act adds on top.

Stay tuned for the second post of this series, which covers contractual provisions governing intellectual property, liability and risk allocation, and term and termination.

If you have questions about any of the matters discussed here, or need assistance negotiating or reviewing an AI contract, please do not hesitate to contact us.