Edition 1 · 03 / 08
Your Supplier Contract May Describe Yesterday's Service
The product may look unchanged while its delivery model, data flows and human oversight have shifted.
A long contract can outlive the delivery model it was written for. A service originally supported by experienced engineers in an internal environment may now depend on coding agents, external models and connected tools.
The customer still sees the same product. The information flows, permissions and review arrangements may be different. This makes the supplier review a question about how the service is delivered, as well as what it delivers.
Begin with the information
Contracts should be checked against the actual categories of information exposed. Personal data is one category. Source code, architecture, credentials, research, security information and commercial plans may need protection even when they are not personal data.
A broader contractual definition of Customer Information can address that commercial concern. It does not make every confidential asset subject to data protection law. It gives the parties a way to define permitted use, access, retention and downstream disclosure for valuable information more generally.
Existing duties and proposed rights
The ICO’s Article 28 guidance sets out requirements where a controller appoints a processor. These include written terms and controls over subprocessors. The guidance describes prior specific or general written authorisation, notification and an opportunity to object under general authorisation, and equivalent data protection obligations downstream.
Those duties do not create a universal approval right over every supplier AI tool. Whether a provider is a processor or subprocessor depends on the processing arrangement. Commercial protections for other information need to be considered in the relevant contract.
Define Material Delivery Change
This publication proposes Material Delivery Change as a contractual trigger for a change that materially alters customer exposure. Examples could include broader access to sensitive information, new production permissions, a material downstream provider or a substantial reduction in expert review.
The trigger should be proportionate. Requiring approval for every minor software update would create noise and delay. A change that affects confidentiality, security, resilience or accountability deserves a more deliberate assessment.
A long contract should preserve a meaningful conversation when the delivery model changes.
A workable sequence is notice, sufficient disclosure, reassessment, agreed safeguards and acceptance. Where risk cannot be resolved, the parties may need renegotiation or an orderly exit. Those rights require appropriate drafting; they are not presented here as automatic statutory entitlements.
Make the response usable
For a critical service, abrupt termination can create its own harm. Agree how transition support, exports, access withdrawal and continuity will work. Align AI provisions with existing confidentiality, security, liability and incident clauses so obligations remain coherent.
Ask your commercial and legal teams to walk through a real proposed change: an agent gaining write access to a customer repository, for example. Can the contract tell everyone when notice is required, what evidence must be supplied and how an objection is resolved?
That exercise is more revealing than adding a general promise to use AI responsibly.
References
- ICO: What needs to be included in the contract?. Statutory context for personal data processing. Material Delivery Change and broader Customer Information protections are proposals for qualified legal review.