Data, Models and Compute Across Borders: Control and Dependence

“The data stays locally” sounds like a complete answer until a buyer asks who can access it, which service processes it, who controls the model and what happens during an outage. A single country label cannot describe every dependency in an AI service.

Our view is that control should be discussed as a set of specific rights and practical capabilities. The commercial question is what the customer and its partners can inspect, authorise, change and continue operating when conditions change.

Draw the service before choosing a label

Begin with one use: for example, employees querying internal documents through an AI application. Trace the information from upload through storage, retrieval, model processing, logging and support. Identify the parties involved and the decisions each controls. The application vendor, model provider, infrastructure operator and local support partner may be different organisations.

NIST’s cloud definition distinguishes service models with different divisions of capability, including software, platform and infrastructure services. That is a useful conceptual starting point; the 2011 definition does not verify any present supplier’s offering. NIST, The Definition of Cloud Computing.

For procurement, ask who can change each layer and who must approve that change. A customer may control which documents are uploaded but have little influence over an upstream model’s retirement. A local partner may manage user accounts without being able to investigate the underlying service. These are different forms of control and should be described separately.

Give localisation a testable meaning

When a buyer requests a local or sovereign AI solution, ask what condition the phrase is meant to satisfy. It may refer to where particular data is stored, where processing occurs, which personnel can administer the service, who holds relevant rights or whether service can continue without a particular external dependency. Establish the buyer’s intended meaning rather than treating these labels as a universal standard.

Next classify each requirement: an identified legal obligation, an internal procurement policy, an operational preference or a supplier’s marketing claim. The distinction affects who must confirm it and what evidence is needed. A business preference can be negotiated; a legal requirement needs an accurate jurisdiction-specific interpretation. Neither should be inferred from a slogan.

ASEAN’s 2021 Model Contractual Clauses provide voluntary templates for cross-border personal-data transfers and direct users to relevant national and sector requirements. They are a contractual resource, not region-wide approval of an AI architecture. ASEAN, Model Contractual Clauses.

A hypothetical local deployment with external dependencies

Imagine a hypothetical Singapore enterprise buying a document assistant from an overseas supplier through a local partner. The supplier proposes local document storage, an external model API and a support team in another country. This scenario describes no actual provider and makes no compliance finding.

The customer initially interprets “local deployment” as control over all processing and access. The supplier means that the document repository is hosted locally. The partner assumes that its role is limited to onboarding. All three can be acting in good faith while expecting different services.

Before proceeding, they need an agreed account of what information reaches the model service, what is retained, how support obtains access and who can authorise changes. If the buyer’s requirement concerns processing location as well as storage, the proposed service may need revision. If it concerns continuity, geography alone will not answer the question: the parties need a practical fallback and someone responsible for operating it.

Use a control-and-dependency record

The following is our proposed commercial decision tool. Technical owners should validate its contents; entries identify questions for review rather than prove security or compliance.

Scroll the table horizontally, or focus it and use the arrow keys.

Ask both the entrant and the local counterpart to complete the same record. Disagreement is valuable: it reveals where a promise has travelled further than the authority or resources required to fulfil it.

Make an alternative path credible

A statement that a service “can move” is incomplete. The buyer needs to know what can move, what must be rebuilt, which rights are required, who will do the work and what capability will be unavailable meanwhile. An export function may preserve documents while leaving integrations and evaluation work to be repeated.

Consider a bounded rehearsal before relying on an alternative: use non-sensitive test material, define the workflow to preserve and have the relevant technical team estimate the work. This is our recommendation for improving commercial understanding, not a claim that every buyer needs a second full deployment.

Some dependencies may be worth accepting because they provide capability, support or economic value. Acceptance becomes more informed when the consequence is visible. Revisit the record when service terms, model sources, support arrangements or intended uses change. Cross-border flexibility depends on understood rights and operational options as well as the locations marked on a map.

Sources

• NIST: The Definition of Cloud Computing, 2011 — foundational service-model distinctions; not a description of current vendor products.
• ASEAN: Model Contractual Clauses for Cross Border Data Flows, January 2021 — voluntary contractual templates with national and sector-specific limitations.