On October 8, the UK Information Commissioner’s Office opened a call for evidence on how data protection law applies to agentic AI, running until November 20. The areas it covers include security, transparency, accountability, automated decision-making, fairness, purpose limitation, and the lawfulness of processing. One theme stands out for anyone who buys AI services. When several organisations, models, and tools share an agent workflow, responsibility can shift from step to step, and the regulator wants to understand how firms allocate roles and how their contracts reflect that allocation.
Pull out the contract behind almost any enterprise AI service signed in the last two years and read it with one question in mind: if something goes wrong with this system next quarter, what does this document entitle us to? In many cases the honest answer is less than the business assumes. The contract was drafted from a software-as-a-service template, and that template was written for a different kind of system.
The template assumed the vendor’s system did not learn from the customer’s data, behaved the same way unless a release was announced, and only displayed information for people to act on. AI services break all three assumptions: they may be improved using customer inputs, their behaviour can change when the underlying model is updated, and agents take actions on the customer’s behalf.
None of this makes AI services unsafe to buy. It makes the contract a more important control, because several key risks sit outside the enterprise’s own systems.
This blog is for procurement leads, general counsel, risk officers, and AI programme owners reviewing or renewing AI contracts. It is not legal advice; contract terms should be drafted and reviewed with qualified counsel in the relevant jurisdiction.
Why The Gap Exists
The gap persists for understandable reasons: AI arrives inside existing subscriptions, business teams move faster than legal review, and the language for model changes and agent actions is still settling. The result is that the enterprise’s own governance questions are often not answered in the one document that binds the vendor.
The Six Clauses
Six clauses close most of the gap. Each answers a question the enterprise’s risk function is already asking internally.
The first is data use and training rights. The contract should state plainly whether customer inputs, outputs, documents, and conversation records may be used to train or improve the vendor’s models or services, and on what terms. The defensible default for enterprise data is no use for training beyond the customer’s own service without explicit, specific opt-in. The clause should also cover derived data — embeddings, logs, evaluation results — and sub-processors, so that permissions do not leak through the supply chain.
The second is residency and processing location. The contract should specify where customer data is stored, where it is processed, including where inference runs, and where logs and backups reside. It should require notice before any change to those locations or to the sub-processors involved. For Gulf enterprises, this is where data residency commitments become enforceable rather than assumed.
The third is audit and evidence access. Internal governance depends on evidence: logs of what the system did, records of evaluation and testing, documentation of controls. The contract should entitle the customer to the evidence it needs to meet its own obligations — access to activity logs in a usable format, reasonable audit rights or independent assurance reports, and cooperation with regulator enquiries. A vendor whose system the customer cannot evidence is a vendor whose system the customer cannot defend.
The fourth is model-change and incident notification. Because AI behaviour can change when the underlying model or configuration changes, the contract should require advance notice of material changes, a description of what changed, and — for critical uses — a window to test before the change applies or an option to remain on the prior version for a period. Alongside it sits incident notification: prompt notice of security incidents, data exposure, and material malfunctions, with defined timelines and the information the customer needs to respond.
The fifth is responsibility for agent actions. Where a vendor’s agent takes actions on the customer’s behalf, the contract should define the boundaries: which actions the agent may take, what authorisation limits apply, how actions are logged, and how responsibility is allocated when an action is erroneous because of a defect in the vendor’s system versus a misconfiguration by the customer. Boundaries are far easier to agree before an incident than after.
The sixth is exit and data return. The contract should guarantee that the customer can leave with what it needs to keep operating: its data, its configurations, its agent definitions, prompts and policies, and its evaluation sets, returned in documented, usable formats within a defined period — followed by certified deletion. Exit terms are the contractual expression of the portability the architecture should already provide, and they are the clause most often missing entirely.
Using The Clauses In Practice
Tier the requirements by use. An internal drafting assistant does not need the same terms as an agent that initiates payments or handles customer data. A short risk tiering — by data sensitivity and by the autonomy of the system — tells procurement which clauses are mandatory and which are negotiable.
Link each clause to an internal control. Audit rights are only useful if someone exercises them; model-change notice is only useful if it triggers re-evaluation. Each clause should map to an owner and a process inside the enterprise.
Review the renewal pipeline, not just new contracts; many AI capabilities arrive through renewals.
The Gulf Compliance View
For Gulf enterprises, two regional considerations sharpen these clauses. Data protection and sector requirements in the UAE and Saudi Arabia place weight on where personal and regulated data is held and processed, which makes the residency clause a practical necessity rather than a preference. And the region’s e-invoicing programmes add a record-keeping dimension: where an AI service touches invoices or tax records — extracting supplier invoices, preparing transmissions, reconciling — the contract should ensure that the records and audit trails the enterprise must retain are accessible to it and survive the end of the relationship.
With UAE e-invoicing mandatory for the first in-scope businesses from January 1, 2027, and ZATCA’s Wave 25 deadline on February 1, 2027, many new service agreements are being signed this quarter — the right moment to include these clauses.
What Inspires Us At Lynt-X Global
At Lynt-X Global, we read the ICO’s call for evidence as a hopeful signal rather than a warning. A regulator asking open questions, inviting evidence, and aiming for clarity is exactly how a new technology earns lasting trust. Clear expectations make it easier for enterprises to adopt agents with confidence, and easier for responsible builders to show their work.
What excites us is that the contract is becoming part of the architecture conversation. When legal, procurement, risk, and engineering teams sit down together to ask what data an agent touches, what it may do, and how the enterprise would leave, they almost always design a better system as a result. Good contracts and good architecture reinforce each other.
For the Gulf, we see momentum building in the right direction. The UAE and Saudi Arabia have placed clear emphasis on data protection, residency, and structured record-keeping, and the e-invoicing programmes have made machine-to-machine accountability tangible for thousands of businesses.
What we are watching next: the outcome of the ICO’s consultation and the guidance that follows, how regional regulators frame agent accountability, and whether standard AI contract clauses begin to settle into industry-wide templates that make good terms the default rather than the exception.
The Compliance Read
Regulators are now asking directly how responsibility is allocated, and written down, when agents act across organisational boundaries. Most enterprise AI contracts were drafted from software templates that assumed systems did not learn from customer data, did not change between releases, and did not act on the customer’s behalf. AI services do all three, which makes the contract a primary control for risks that sit outside the enterprise’s own walls.
Six clauses close most of the gap: data use, residency, evidence, change and incident notice, agent actions, and exit. Tier them by sensitivity and autonomy, link each to an internal owner, and work through renewals as well as new agreements — with qualified counsel doing the drafting.
“AI contracts are still being signed on software templates written for systems that did not learn from customer data, did not change between releases, and did not act on anyone’s behalf. AI does all three. Data use, residency, evidence, change notice, agent actions, and exit are the six clauses that turn governance from an internal intention into an enforceable commitment.”