Data sovereignty was built around storage and transfer. Where does the data live, who can compel access to it, under which legal instrument does it cross a border. Those questions were hard but they were at least static — a database sits somewhere, and you can point at it. Agents break that framing quietly. An agent acting on company data is not storing it; it is reading it, reasoning over it, and producing something new somewhere else. The regulated content may never move, and the sovereignty position may still have failed.
Sovereignty frameworks ask where the data rests. An agent's entire value lies in what it does while the data is in motion, which is the one state nobody wrote rules for
Here is what a sovereignty requirement for agents actually has to cover.
The four flows that matter
Inference. Where the model runs and who operates it. Content sent to a model for processing has left your environment even if the record of origin never moved, and this is the flow most organisations assess last. Context assembly. What gets gathered and sent with a request. An agent retrieving from five systems may compose a payload that is more sensitive than any of its sources, and no classification scheme covers the composite. Output persistence. Where the agent's result lands, how long it stays, and whether it inherits the classification of what produced it. Usually it does not, which is how regulated content acquires an unregulated copy. Memory. Anything the agent retains between interactions is a new data store that nobody registered, nobody classified and nobody set retention on.
| Flow | Record to maintain |
|---|---|
| Inference | Processing location, operator and routing controls. |
| Context assembly | Permitted source systems and composite sensitivity. |
| Output persistence | Destination, inherited classification and retention. |
| Memory | Registered store, owner and expiry rules. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The harder question underneath
Agents act. An agent that reads a record and updates a system is performing a processing operation, and someone is responsible for it under whichever framework applies. Naming that party is straightforward in the contract and genuinely difficult in practice when the model is one vendor's, the orchestration another's and the data yours. The practical rule is that the organisation whose data it is remains accountable regardless of how the stack is assembled, which means the contractual work must produce evidence rather than indemnities.
What to actually require
A stated inference location per agent, with the ability to enforce it. A record of what context may be assembled and from where. Classification inheritance on outputs. Explicit retention on memory. And logging that is sufficient to reconstruct what an agent saw and did — which is also the only way to answer a regulator's question after the fact.
Practical Guidance for Agent Data Governance Review
- Record the inference location for each agent, and verify it.
- Define the permitted context scope per agent, not per user.
- Make outputs inherit the classification of their inputs.
- Set retention on agent memory at creation.
- Log what was read and what was done, durably.
- Name the accountable party for each agent's actions.
- Treat composite context as its own classification problem.
- Re-review when the model provider changes, including silently.
The Regional Angle
The first regional issue is that residency commitments in the Gulf were written for storage and are being read across to inference without anyone examining the fit. A commitment that customer data remains within the country was understood to mean the database; whether it constrains sending that data to a model hosted elsewhere for processing is genuinely unsettled, and organisations are resolving the ambiguity in their own favour by default. Financial institutions under supervisory expectations should get this addressed explicitly rather than inferring an answer. The second concerns the availability of compliant inference in the region, which has improved but remains uneven. Sovereign cloud regions and locally hosted model options exist in Saudi Arabia and the Emirates, and national artificial intelligence programmes have produced models that can be run domestically — but capability, language coverage and cost differ materially from the frontier options, and the gap is the real constraint on regional agent deployment. The honest approach is to segment workloads by sensitivity rather than to pretend one provider satisfies everything. The third is about agents acting across entity boundaries, which is the common regional structure. A group with entities in several Gulf states plus a European subsidiary will deploy one agent across all of them, and that agent becomes a data flow between jurisdictions that no transfer assessment covers because nothing was transferred in the traditional sense. Scoping agents to entities is unglamorous and is the single most effective control available.
The objection worth taking seriously
The strongest objection is that this is regulatory theatre applied to a technical detail. The data is processed for milliseconds, retained by nobody, and returned; treating a model invocation as a transfer that requires assessment would make any cloud service impossible under the same reasoning, and the industry has long since accepted that transient processing is not the thing sovereignty rules were aimed at. Building an agent governance programme around inference location produces documentation, not protection. The point about transient processing is fair and the analogy to cloud services is not frivolous. But two things distinguish agents from the transient case. The first is that transience is a claim, not an observable property — whether a provider retains inputs, uses them for evaluation, or routes them through regions is a contractual assertion you cannot verify from outside, and several providers have changed those terms with limited notice. The second is that agents accumulate. Memory, logs, cached context and generated outputs mean that the aggregate of what persists after a year of operation is substantial even if each individual call was transient. The governance requirement is not aimed at the millisecond; it is aimed at the residue, which is real, growing and currently unregistered in most organisations.
Common Questions
Does using a local model solve this?
It resolves inference location and nothing else. Context assembly, output persistence and memory remain, and they are where most of the actual exposure sits.
Should agent outputs be classified automatically?
Yes, by inheritance from inputs, imperfect as that is. The alternative is a growing body of derived content with no classification at all.
Who is accountable when an agent acts wrongly?
You are, in every framework that has addressed it. Contracts allocate cost, not accountability.
What should we expect over the next twelve months?
Expect supervisors to start asking where inference happens. Expect inference location to appear as a contractual term rather than a configuration setting. Expect agent memory to be the first thing a regulator asks about that nobody has documented. And expect workload segmentation by sensitivity to become standard regional practice.
Agent Data Governance Review — we map inference, context, output and memory for each agent, because the residue is where the exposure actually lives.