Artificial intelligence is no longer just a standalone product. For many organisations, it has become embedded in the day-to-day delivery of services, raising difficult questions about what contractual protections those organisations can, and should, impose on their suppliers. We have had lots of questions from clients on these issues and set out our key observations below.
Establishing a principled approach to AI contracting
Even businesses that would not describe themselves as “AI companies” now use a growing range of AI-enabled tools in their day-to-day operations – such as chatbots, research tools, document review solutions, or workflow solutions. Some tools are specifically badged as AI; others are long-standing enterprise platforms that have added AI capabilities.
From a client perspective, the concerns about the use of AI and the instinct to regain control is entirely understandable. Few organisations are comfortable with AI operating as a black box within their supplier ecosystem. Doing so is harder than it might first appear. Getting AI provisions right requires balancing a range of competing pressures (operational, regulatory, commercial and practical) that do not always pull in the same direction. What works in one supplier relationship may create inconsistencies elsewhere in the supply chain. What looks robust in a template may prove very difficult to negotiate in practice, particularly with larger technology providers.
A principled, standardised approach is therefore essential: one flexible enough to evolve alongside the technology, calibrated to actual risk rather than abstract concern, and grounded in what the parties can realistically commit to. A common failure is to treat AI as a discrete, optional component of the service when, in practice, it is woven into the delivery model itself. Contractual requirements can then become misaligned with operational reality, making them difficult to negotiate and, in some cases, counterproductive for both parties.
Consent requirements: Why blanket consent rarely works
A common source of tension is the requirement for prior client consent for any use of artificial intelligence. On paper, this seems to offer a high degree of control. In practice, however, it often proves unworkable. These tools are not always optional add-ons that can easily be switched off. They sit at the core of modern delivery models, supporting scalability, cost efficiency and consistent quality across engagements.
Consent mechanisms necessarily mean that AI usage must be identified, isolated, switched off, or approved on a tool-by-tool basis, whereas, in many cases, AI features are embedded in standard platforms, updated frequently, and tightly integrated into everyday workflows.
Requiring consent for each use of AI can quickly lead to operational deadlocks. Suppliers may struggle to determine which tools are permitted, under what conditions, and for how long. It can also increase costs, if delivery models must be redesigned, slower manual processes reintroduced or parallel non-AI toolsets maintained solely to remain contract-compliant.
More fundamentally, consent-based approaches often focus on abstract conceptions about AI, rather than the actual risks created by its use. They rarely distinguish between AI uses that materially increase exposure (for example through use of insecure tools or direct publication of AI outputs) and those that simply support productivity or quality within a controlled environment.
Practical tips for clients:
- Avoid blanket “no AI without consent” wording. Instead, define categories of AI use and apply proportionate controls to each category.
- Consider the specific risks raised in the context of the relevant service. Evaluate if the existing contractual protections (e.g. confidentiality, quality, intellectual property) adequately address those risks, or can be adapted to address the risk.
- Only require consent where strictly necessary. For example, higher risk uses, such as AI that generates client facing outputs with limited human review or drives automated decisions on your behalf.
“Incidental use” and closed AI systems as workable carve-outs
As set out above, the key question is not whether AI is used, but which uses of AI genuinely warrant heightened contractual control. This is where concepts such as incidental use and closed AI systems come into play.
“Incidental use” – This is generally intended to capture situations where AI is utilised as a tool as part of the delivery of the service (e.g. supporting research, document production or quality checks) without being the object of the service itself or a feature made available to the client. Critically, the qualification turns not on the tool but on how it is used. Many common tools (e.g. Copilot) can function in both an incidental and non-incidental capacity depending on the nature of the output they generate.
As a working distinction, AI use should be considered “incidental” where it supports routine activities in the delivery of the services and does not result in the provision to the client of a standalone AI-generated output or AI-driven solution. In contrast, it should be considered “non-incidental” where the tool is used to generate a deliverable, or a substantial part of one, that is provided to the client without meaningful human input or transformation.
From a risk perspective, this type of internal and ancillary use does not normally raise the same concerns as AI systems that autonomously generate client-facing outputs, drive decisions on the client’s behalf, or perform a core function with limited human validation. When clauses treat these incidental uses in the same way as outcome-driving AI systems, they risk over-regulating the service, creating compliance friction without materially improving protection.
Closed AI systems – This concept addresses a different concern: control over data. A closed AI tool operates within the supplier’s own segregated environment. This means customer data is not shared with third parties and is not accessible outside that environment, including for training or improving underlying AI models. From a customer perspective, this mitigates a number of core risks, such as data leakage, external reuse or uncontrolled model training.
Taken together, these controls often mean a binary “AI allowed / AI prohibited” approach is not needed. They allow continued use of standard AI-enabled tools within a controlled environment, while reserving consent requirements or heightened safeguards for uses of AI that genuinely increase risk.
Practical tips for clients:
- Consider an “incidental use” carve out to permit internal, ancillary AI uses. Defining exactly what “incidental” use means will always be a challenge but the carve-out should reference objective criteria (such as whether the output is provided to the client and the degree of human oversight involved in its production) rather than specific tools.
- Require “closed system” safeguards. These should supplement any confidentiality obligations by preventing confidential information from being shared with third party AI service providers.
- Focus controls. Apply stricter requirements (such as prior approval, testing, documentation and human oversight) where AI directly generates outputs relied on by you or makes decisions that affect your business.
Training restrictions: What should and should not be prohibited
Similar issues arise with prohibitions on the use of client data to “train, develop or improve” AI models. Usually, the underlying objective is to prevent the use of client data to train underlying AI models, which could undermine the confidentiality of that data and provide an unwarranted economic benefit to the model provider. That objective is legitimate and widely shared. The challenge lies in how these prohibitions are drafted and interpreted.
Most AI tools used in service delivery rely on an underlying foundation model, often a large language model developed by a third party. This model is then integrated into an application or system developed or configured by the service provider, which determines how the model is used in practice.
In a closed system, client data is not used to train or fine-tune the foundation model itself. That risk simply does not arise. However, client data used within the system may still lead to improvements, such as refining prompts, enriching internal knowledge bases, adjusting workflows or improving the relevance and consistency of a given tool.
These improvements do not alter the underlying model and do not involve reuse of client data outside the supplier’s environment. Clauses that prohibit any form of “training or improvement”, without distinction, may inadvertently prevent the use of client data within AI systems altogether. This can undermine the efficiency, scalability and quality gains that AI-enabled delivery models aim to achieve.
Practical tips for clients:
- Be specific about “training”. This should generally prohibit using your data to train or fine tune underlying models for general purposes, or for the benefit of other clients or third parties.
- Consider allowing confined optimisation. This might include internal tuning or configuration of tools using your data, provided this (i) does not change the underlying model, (ii) does not allow other clients to benefit from your data, and (iii) remains within a closed system.
- Ask for a simple explanation. Require the provider to explain, in plain language, how your data interacts with their AI tools, for example, “no model training”, “configuration only”, “no sharing with third parties”.
Beyond simple risk management
It is also worth considering the impact on other commercial and regulatory points. The first is whether the contract should have additional flexibility and/or gainshare mechanisms. The capabilities of these systems continue to develop rapidly (particularly agentic agents) which could lead to significant additional efficiencies. From a commercial perspective, you might want to require your supplier to explain how they are utilising this technology to deliver those efficiencies, and apply a gainshare mechanism to ensure you benefit from those efficiencies. You may even want the flexibility to terminate if you can replace your supplier with a bot.
It is also important to carefully consider, and comply with, any regulatory requirements. For example, a contract for a “high-risk” system under the EU AI Act should (in due course) address a full range of issues such as the provision of “instructions for use”, the availability of logging functionality, the extent to which the system allows human oversight, etc.
However, it is also important these obligations are only imposed where appropriate and necessary. A blanket requirement to – for example, report serious incidents or conduct fundamental rights impact assessments – will generally be unnecessary and disproportionate for non-high-risk “incidental use” of an AI tool. Beyond this, AI will also require the careful reassessment of many existing contractual clauses on issues such as liability, intellectual property and data protection.
Conclusions
The genie is now out of the bottle as AI becomes increasingly embedded in almost all forms of service delivery. Contracts that fail to reflect this may look robust on paper, yet introduce friction, inefficiencies, or constraints that undermine delivery in practice. The real challenge is to design AI clauses that manage risk without weakening the delivery models that clients ultimately depend on. This should involve:
- Reviewing existing template AI clauses, e.g. identify blanket consents or over broad training prohibitions and consider whether they map to actual risks.
- Classifying AI uses, e.g. ask suppliers to help categorise AI uses (incidental vs outcome driving; open vs closed systems) and align controls accordingly.
- Standardising your approach where possible, e.g. develop a short internal AI clause “playbook” so that your teams negotiate consistent, risk based AI provisions across suppliers.
Authors:
- Marion Barbezieux, Linklaters
- Sonia Cissé, TMT Partner, Paris at Linklaters
