Most data protection addenda in force today were drafted for a supplier that stores your records and occasionally processes them in a predictable way. They allocate responsibility for storage location, subprocessing and deletion, and they do it reasonably well. Then the supplier adds a model feature, and three of the addendum's assumptions quietly stop holding: that processing happens where storage happens, that the list of parties is stable, and that deleting the data removes your exposure.
Your addendum tells you where the data rests. The sovereignty question is where it is being thought about, and almost no contract in force answers that
Here are the clauses worth adding, in the order they matter.
The five that change your position
Inference location, named and bound. Not "the Services will be provided from" — an explicit statement of the region or regions in which model inference occurs, with change subject to notice. This is the single most important addition and vendors resist it because their own model providers vary it. Model provider identity and change control. Which upstream model, whose, and what happens if the vendor switches. A vendor changing from one model provider to another has changed your processing chain without a contractual event under most current terms. Training exclusion, defined broadly. Not just training: fine-tuning, evaluation, abuse monitoring with human review, and product improvement. The usual denial covers the first and leaves the rest available, and human review of outputs is the one that surprises people. Deletion that reaches derived artefacts. Embeddings, indexes, caches and logs of prompts and outputs are copies of your data in a form most deletion clauses do not name. Ask what survives termination and require it in the schedule. Evidence, not assertion. A right to receive, on request, a current statement of processing locations and subprocessors in the model chain. Without this, every other clause is unverifiable.
What you will actually get
Be realistic. Large vendors will concede the training exclusion readily, concede deletion of derived artefacts with drafting effort, negotiate on evidence, resist naming inference regions, and refuse liability for outputs entirely. That is the current market and it moves at renewal, not mid-term. The practical strategy is to spend your negotiating capital on inference location and derived-artefact deletion, because those are the two that determine whether you can answer a regulator.
The clause nobody drafts and everybody needs
A change notification obligation with a corresponding right to suspend the feature. Model features change more often than contracts are reviewed. If the vendor can alter the processing chain silently, the rest of the addendum describes a state of affairs that expired months ago.
Practical Guidance for AI Contract Review
- Name the inference region explicitly; do not accept service-provision language.
- Require notice on model provider change and a right to suspend.
- Define training exclusion to cover evaluation and human review.
- List derived artefacts in the deletion schedule.
- Secure a right to current processing evidence on request.
- Spend leverage at renewal, not mid-term.
- Prioritise two clauses rather than negotiating ten badly.
- Check the reseller can bind the principal vendor.
The Regional Angle
The first practical obstacle in this market is that the contracting party is frequently not the vendor. A great deal of enterprise software in the Gulf is purchased through a local partner or systems integrator, and the sovereignty clauses you negotiate bind an entity with no ability to control where inference runs or which model provider is used. The result is a well-drafted addendum that is unenforceable in substance. Insist on a direct addendum with the principal, or written confirmation that the partner is authorised to give these specific commitments — and treat a refusal as a material finding rather than a procedural inconvenience. The second concerns what regional regulators are actually likely to ask. Saudi and Emirati data protection regimes, and the sectoral frameworks applying to banks, insurers and healthcare providers here, ask where personal data is processed and transferred rather than where it is stored, which is exactly the question an inference clause answers and a hosting clause does not. Regional supervisors are also accustomed to requiring named accountability, so a clause obliging the vendor to identify its model chain on request maps directly onto how a supervisory enquiry will arrive. Draft to that question, because it is the one that will be asked. The third is about language and governing law, which regional contracts handle in a way that can undermine careful drafting. Where an agreement exists in Arabic and English with the Arabic version governing, sovereignty clauses drafted in English and translated loosely can lose precision at exactly the terms that matter — inference, derived artefacts, evaluation. Have the Arabic rendering of those specific definitions reviewed by someone who understands the technical meaning, not only the legal one. A translated "processing" that does not distinguish inference from storage puts you back where you started.
The objection worth taking seriously
The strongest objection is that this is unenforceable in practice. You will not know if a vendor routes inference to a different region, you cannot audit whether embeddings were deleted, and no enterprise has ever meaningfully verified a subprocessor list. Adding five clauses to an addendum produces a document that satisfies your legal team and changes nothing about what actually happens inside the vendor's infrastructure — the real protection is choosing vendors whose architecture makes the wrong behaviour impossible, not writing prohibitions against it. That is largely accurate about verification, and contracts have always been weak instruments for controlling what happens inside someone else's systems. What they do reliably is two things. First, they create a disclosure obligation — a vendor contractually required to notify a model provider change will generally do so, because the cost of being found to have concealed it exceeds the cost of an email. Second, they determine who bears the consequence when a regulator asks and the answer is unsatisfactory. Neither requires audit capability. And the exercise of asking for these clauses is itself diagnostic: vendors that cannot say where inference runs are telling you something true about their control of their own supply chain, which is information you cannot get any other way and which should influence the purchase regardless of what the final document says.
Common Questions
Will vendors accept an inference location clause?
Some will, with regional scope rather than a single named data centre. Many will not yet, and the refusal is informative.
Are embeddings personal data?
Treat them as derived from it and name them in the deletion schedule. The theoretical argument is unresolved; the practical drafting answer is not.
What if we cannot renegotiate mid-term?
Ask for a written statement of current processing locations and model providers. It is not a contractual right, but it is evidence, and it costs the vendor nothing to refuse or provide.
What should we expect over the next twelve months?
Expect standard addenda from major vendors to add artificial intelligence schedules, mostly weak on inference location. Expect derived-artefact deletion to become standard drafting. Expect the first regulatory enquiries in this region to concern processing location rather than training. And expect model provider changes to keep outpacing contract review cycles.
AI Contract Review — we spend your negotiating capital on the two clauses that decide whether you can answer a regulator.