Chapter 21: Multiple Markets — First edition

Once an organization serves several markets, some of its placement rules become conditions that no commercial agreement can change, and two locations with the same machines stop being interchangeable. The earlier examples kept those privacy, sector, and infrastructure rules in the background. Scale makes them harder to coordinate, but a small business using an overseas provider meets them too. Before moving work between locations, the capacity team needs to know which ones its specialists have cleared, and on what conditions.

The example organization from this book has run a European operation for years, under its own budget and its own agreement with Provider B, which is why Volume I, Chapter 1’s ledger leaves it out. That bill put the web workers on Provider A, the serving layers behind the data platforms and AI assistant on Provider B, and the customer and order records in the organization’s own data center. European customers are served from Provider B’s European regions, chosen partly because its data-residence terms satisfied legal review, while Provider A keeps serving the Americas. The same React application, the same tier structure, the same databases behind it, and a topology that looks arbitrary until somebody asks why the European workers cannot simply fail over to Virginia. The duplicated stack shows up in the bill long before anyone mentions the law.

How to read this chapter

This chapter treats jurisdiction as a property of capacity.

Sovereignty in this context — authority over data, and the rules that set placement conditions.
Which models may be consumed where — model controls and Foundry processing boundaries.
The same workload, different rules — following the data flow, access included.
Location is a capacity property — qualifying locations before comparing prices.
The commitments split by market — separate entities, and discounts that may not follow a move.
Consider segmentation by market — what separation buys and what still connects the segments.
Segmentation costs utilization — duplicated minimums and regulation-driven overlap.
The monthly review across markets — market boundaries in the efficiency numbers.
One practice or two — segmented reviews under one roll-up.
One register, not a private law firm — specialists’ conditions, kept without interpreting the law.

The lesson to carry: jurisdiction turns topology into a legal fact; segmentation by market can make the resulting constraints easier to manage, at a cost in duplicated capacity and operations.

Sovereignty in this context

In this book, data sovereignty means the legal authority and operational control that can be exercised over data and the systems holding it. Location matters, but so do the organizations operating the service, the people who can reach it, and the laws that reach those organizations. Storing records in Frankfurt does not, on its own, establish that only German and European authorities can compel access: the US CLOUD Act reaches data in a provider’s possession, custody, or control wherever it is stored, when the provider is subject to US jurisdiction.¹

Privacy rules are one source of these conditions. GDPR applies to processing in the context of an EU establishment and, in specified circumstances, to organizations elsewhere that offer goods or services to people in the Union or monitor their behavior there; nationality is not the test.² Its transfer mechanisms change. The Court of Justice struck down the first two EU–US arrangements, in 2015 and 2020. The third, the 2023 Data Privacy Framework, survived the General Court in 2025 but is under appeal. In July 2026 the European Data Protection Board asked the Commission to assess whether the framework still functions after a US Supreme Court ruling on the independence of the Federal Trade Commission, which the adequacy decision cites.³ Flows that depend on the framework with no workable alternative are where a legal change becomes a capacity question.

AI regulation has its own scope. Article 2 of the EU AI Act reaches providers placing AI systems or general-purpose models on the Union market, deployers in the Union, and certain providers and deployers elsewhere whose systems’ output is used there. The obligations depend on the actor, the system, its use, and dates that move: in July 2026 the EU deferred most high-risk obligations to December 2027 or August 2028.⁴ The capacity team’s question is what they mean for placement, access, logging, and recovery. Often the answer is storage, since a deployer of a high-risk system must keep the logs it controls for at least six months. The scope provision does not require hosting every AI workload in Europe.

Sovereignty also arrives as infrastructure policy. Public programs such as EuroHPC’s AI factories allocate computing to eligible users by application, which makes them conditional supply rather than something to buy on demand.⁵ Sovereign-cloud products sell operating conditions: AWS says its European Sovereign Cloud, generally available since January 2026, runs separately from its other regions and will be operated only by EU residents in the EU.⁶ Neither label qualifies a location until someone checks the terms against the workload.

Microsoft’s EU Data Boundary is a provider commitment specific enough to plan against. For in-scope Azure services, Microsoft commits to store and process Customer Data and pseudonymized personal data within the EU and EFTA countries, subject to documented transfers, with regional services deployed in boundary regions and non-regional services configured for it.⁷ The workload’s condition still decides. The boundary is the EEA plus Switzerland, which matters if a contract says “EEA,” and a boundary spanning many countries does not satisfy a requirement to stay in one.

I would keep conditions like these in a constraint register, one entry per workload and data flow, with the specialists’ condition, its source and date, and its consequence for capacity. The last section shows sample entries.

Which models may be consumed where

Model availability deserves entries of its own. A team may be able to buy hardware in a location and still be unable to obtain a particular model there, use it for a particular purpose, or move its weights there. Statutory restrictions, provider availability, license terms, and proposals not yet in force have different owners, and I would keep any scenario built on a proposal apart from the rules in force.⁸

Export controls show how date-sensitive the entries are. The US AI Diffusion Rule of January 2025 tightened licensing for advanced chips and added a control on the weights of the most advanced closed models. In May 2025 the Bureau of Industry and Security said it would not enforce the rule and would rescind it; a year later the Government Accountability Office noted that the rule was still in the Code of Federal Regulations.⁹ An announcement, a non-enforcement policy, and a published rule are different legal states, and an entry should say which one it relies on.

Product configuration matters independently of the law. Of the Foundry deployment types in Volume I, Chapter 7, Global ones may process inference in any Azure region, Data Zone ones stay within a Microsoft-defined zone (the EU zone follows the EU Data Boundary), and the regional ones, named Standard and Regional Provisioned, stay within the resource’s geography. New models reach Global deployments first and geography-based ones last, with no guaranteed date, and Microsoft can add regions to a data zone without notice. When provisioned capacity runs out in a region, Microsoft’s troubleshooting advice is another region or a Global Provisioned deployment, advice a workload confined to the EU zone can follow only as far as the next EU region. A spillover target needs the same check, because it has a deployment type, and so a boundary, of its own.

Check the register against what is deployed rather than the resource’s region:

az cognitiveservices account deployment list \
  --name <foundry-resource> --resource-group <resource-group> \
  --query "[].{name:name, type:sku.name, model:properties.model.name, spillover:properties.spilloverDeploymentName}" \
  --output table

A GlobalStandard row serving a workload confined to the EU zone is a finding, and Azure Policy can deny that type outright.¹⁰

The same workload, different rules

Follow the full data flow. Where the customer is, which entity serves them, what processing happens where, and who can reach the data can all affect which rules apply. A customer record written by the web tier, copied to analytics, indexed for search, and retrieved by an assistant crosses several systems whose placement and access need checking; give the specialists that flow, not a country label.¹¹

Access belongs in the flow, because data can cross a border without moving. Under EDPB guidance, remote access from outside the EEA by a separate controller or processor can be a transfer even if the data is only displayed on a screen, and Microsoft describes its own personnel’s access from outside the EU Data Boundary that way. In 2025 the Irish Data Protection Commission fined TikTok €485 million over transfers that consisted of remote access, by group staff in China, to European users’ data stored elsewhere.¹² The capacity team can give counsel the inventory of who can reach each market’s data, from where, employed by which entity, through which tools. If counsel concludes that some data may be reached only from inside a market, that market’s on-call rotation, support desk, and administrative tooling become part of its capacity.

The questions go beyond privacy: records that must stay in-country, sector rules on placement or audit, export controls or sanctions on the purchase. Each answer belongs in the register with its scope, source, and review date, where the specialists can correct it.

Location is a capacity property

Once placement is constrained, geography becomes part of what “capacity” means. The tested worker capacity is unchanged, but the locations are no longer interchangeable: a region that could absorb the web tier’s failover traffic may be unable to hold the data the tier serves. Chapter 18 asked what a reserve is available for, and each candidate location answers differently. Capacity counts toward a workload only where it is permitted, available, and tested.

Then price the permitted arrangements, including quoted rates, chargeable data transfers, and the standby or duplicated services each topology requires. Volume I, Chapter 1’s “where it runs” view was drawn with two providers and a data center; I would add permitted locations and their conditions to it before comparing costs, so that the cheapest row is also one we could operate.

Placement becomes usable capacity only when specialist conditions, service configuration, and operational readiness agree. Compare prices among those qualified arrangements, and retain each condition’s review date.

The commitments split by market

Chapter 20’s discipline — separate the promise to spend from the promise to supply — becomes several parallel disciplines when the markets are separate. A multinational often signs through different legal entities in different markets, and who may discuss a commitment, let alone negotiate it, can differ by entity. Two commitments inside one company can be as separate as two companies’. Finance will also ask which entity pays and how any recharge between entities is priced.

The discount-preservation question from Volume I, Chapter 1 gains a jurisdictional dimension: if one market’s permitted placement changes, how much eligible consumption remains under each agreement, and where can its benefit still apply? Azure’s reservations for provisioned throughput on Foundry models show how literal the answer can be. They are bought per deployment type, and Data Zone and Regional reservations must match the deployment’s region. If counsel requires an assistant serving European customers to move from a Global deployment to the EU Data Zone, the existing reservation does not follow it. The new deployment draws on a separate quota pool, needs capacity the chosen region may not have, and should exist before its reservation is bought, because a reservation fixes a price, not capacity. On October 4, 2026, two Microsoft pages still disagreed about whether the old reservation could be exchanged for the new type.¹³ I would get that answer from the account team in writing; if it is no, cancelling the old reservation counts against the refund limit described in Chapter 20.

I would not try to make the arrangements uniform across markets. The rules being satisfied differ, and a uniform structure relocates the complexity into exceptions. A common process with market-specific evidence holds up better.

Consider segmentation by market

Segmentation is an option to evaluate, not a requirement to infer from a country boundary. I would identify which workloads need separate placement or operations, then look for what still connects them: identity, telemetry, support tooling, backups, and the deployment pipeline can each carry data or access across the line. Separation can limit the effect of a local rule change; it cannot guarantee independence. Where lawful sharing is possible, weigh its savings against the cost of separating later.

Canada and the United States show why a connected deployment needs specific advice. Federal guidance under PIPEDA permits processing across borders, with the transferring organization remaining accountable; it does not require Canadian personal data to stay in Canada.¹⁴ Quebec adds a step: before personal information leaves the province, a business there must complete a privacy impact assessment establishing that it would be adequately protected, and the section says “outside Québec,” not outside Canada.¹⁵ I would keep the ability to separate workloads without treating a future cross-border ban as inevitable.

Segmentation costs utilization

Separated systems will usually not reach the efficiency of one pooled system. That is a fact of life, and it does not contradict the earlier chapters: deliberately unused capacity can protect a service or satisfy a constraint.

The mechanism is the minimum configuration that availability and recovery requirements impose: replicas, standby capacity, test environments, and the people and systems to operate them. If two deployments must stay separate and each needs its own standby, idle capacity in one cannot meet the other’s obligation. Show those duplicated minimums and why they exist. Judging each market against an unconstrained global pool would mistake a placement requirement for an efficiency failure.

In this illustrative arrangement, sharing is prohibited and each market needs its own standby. The unused capacity protects a local recovery obligation; it cannot be counted again as the other market’s reserve.

Regulation can also force a temporary overlap: Volume I, Chapter 13’s double bubble, arriving without a business case. The CCPA gave businesses in scope about eighteen months, from its signing in June 2018 to January 2020, to build the record searches and request workflows that its rights to know and to delete required: engineering work, with no mandate to replace infrastructure.¹⁶ I would treat a runway like that as lead time. Enforcement deadlines can be shorter: the Irish Data Protection Commission’s May 2023 decision against Meta gave five months to suspend the challenged EU–US transfers and six to stop processing, including storage, of data already transferred, without prescribing how.¹⁷ Two months later the Data Privacy Framework gave transfers to certified US organizations a new legal basis. Conditions relax as well as tighten, so a migration planned against a deadline needs a date for checking whether the deadline still applies.

The monthly review across markets

Across markets, the monthly capacity review that Chapter 22 develops has to say which items belong to which market, and where the markets’ constraints make their numbers incomparable.

Suppose the organization starts measuring the reuse of AI infrastructure across markets, and maximizing reuse becomes a success criterion. Capacity that looks idle on one market’s chart may be unavailable to another, and a criterion written as if the deployment were unified will mark correctly segmented systems as failures. So the review keeps the constraint register beside the efficiency numbers, with specialists confirming the conditions behind any cross-market comparison. When a rule or interpretation changes, note its effective date, the options it removes or adds, and the time needed to respond, so nobody discovers an expired condition during a failed recovery or a purchase review.

One practice or two

Every multi-market organization eventually decides, deliberately or by drift, whether these problems belong to one practice or several. Segmenting the analysis and review meetings by jurisdiction or region is legitimate; for markets that barely interact, a unified view adds overhead without adding information.

One requirement usually survives: a combined view for high-level reporting, because executives, Finance, and the board need the total. One workable arrangement is segmented analysis underneath and unified totals on top, each market keeping its own review, evidence, and constraint register. What makes it work is keeping the seam visible, knowing which numbers were summed across jurisdictions and which could not be. Currency is the seam Finance will notice first: a euro invoice translated at this month’s rate can rise in dollars while European consumption falls, so the roll-up should state its exchange rate and show constant-currency change beside the reported figure.

Separate market reviews can feed one company view. Compatible cost or consumption units can be summed; capacity comparisons must preserve the placement, quality, and recovery conditions that make each market’s numbers meaningful.

One register, not a private law firm

Keeping a register of constraints is sometimes confused with defining or interpreting them. The capacity team keeps the register current and knows what to ask, of whom, and by when; compliance, legal, and governance professionals decide what goes in it. A capacity team that treats its own reading of a regulation as settled advice has left its lane, and so has a compliance function that dictates topology without understanding what the service needs to do.

In the illustrative entries below, the second column comes from the specialists and the third is the capacity team’s translation; none is a legal conclusion.

Workload and data flow	Condition and source	Capacity consequence	Review when
EU customer records: web tier, analytics copy, backups	Store and process in EU regions; transfers out only under a mechanism counsel approves (privacy counsel; provider terms)	EU failover and backups stay in EU regions; the US pool is not EU reserve	Transfer mechanism or provider terms change
EU support assistant	Inference within the EU data zone (privacy counsel)	Data Zone quota, capacity, and reservation in an EU region; spillover target checked; new models may arrive late	Model launches; reservation renewal; zone membership changes
Production access to EU data	Remote access only by the EU entity’s staff, from inside the EEA (privacy counsel)	EU on-call rotation and support tooling sized for EU incidents	Reorganization; new support vendor

A real entry also names who gave the condition, the document it rests on, and its date.

Relationships with the right specialists have to exist before the capacity team negotiates and signs agreements; an agreement checked against regulation after signature is waiting to be incompatible with it. The capacity team earns its place by holding a working conversation with audit, research and development, and the people who run data platforms about what each needs and why, early, while the choices are still open. The difficult discussion is usually a rule stated without its implementation consequences, or a deployment decision made without the legal conditions, and showing the data flow, the recovery dependency, and the cost of the alternatives gives both sides something concrete.

The surprise I would most want to avoid is building in a location and discovering later that the service cannot legally operate there. The response might be restricted processing, a replacement deployment, data remediation, or an interruption. If overlap is permitted, both environments need funding while the replacement is qualified, and Volume I, Chapter 13’s distinction between the overlap bill and the incremental cost of delay applies in full.

I have not reproduced the European operation’s ledger. The arithmetic would repeat Volume I, Chapter 1’s; what multiple markets add is that one decision needs several sets of evidence and several authorities whose answers cannot substitute for one another. That is the relationship problem Part IV has been building toward, and it ends the same way: find out who can change which condition before the commitment is signed and the build begins.

Chapter 24, the book’s last, turns to the markets forming around compute itself. Read this chapter as their other face: the same forces that make a public price for compute difficult — heterogeneity, jurisdiction, and the fact that capacity is never quite the same product twice — are the forces the enterprise has been managing all along, one market at a time.

Notes and sources

US Department of Justice, CLOUD Act Resources, including the Act and an April 2019 white paper; section 103 (18 U.S.C. § 2713) covers data in a provider’s “possession, custody, or control,” whether inside or outside the United States. The definition in the text is a working definition for infrastructure planning.↩︎
European Data Protection Board, Guidelines 3/2018 on the territorial scope of the GDPR, final version, November 2019. Establishment, targeting, and monitoring are distinct grounds; nationality alone is not the test.↩︎
Court of Justice, C-362/14 (2015) and C-311/18 (2020); Commission Implementing Decision (EU) 2023/1795; General Court, T-553/23, 3 September 2025, appealed as C-703/25 P; European Data Protection Board, letter on Trump v. Slaughter, 31 July 2026. Checked October 4, 2026: the framework remained in force, the appeal was pending, and no published Commission response to the Board’s letter was found. The European Commission’s transfer rules page describes the alternatives.↩︎
AI Act Service Desk, consolidated text as at 27 July 2026: Article 2, and Article 26(6) on logs, unless other law provides otherwise. Regulation (EU) 2026/1744 moved Chapter III, Sections 1 to 3, to 2 December 2027 (Annex III) or 2 August 2028 (Annex I). Classification and roles are legal determinations.↩︎
EuroHPC Joint Undertaking, AI Factories FAQs: access by application, eligibility by place of establishment, free of charge. Not evidence that a quantity will be available when needed.↩︎
Sébastien Stormacq, Opening the AWS European Sovereign Cloud, AWS News Blog, January 14, 2026. Vendor description, not a legal conclusion that the product meets any customer’s obligations.↩︎
Microsoft Learn, What is the EU Data Boundary?, checked October 3, 2026: data categories, EU and EFTA geography, configuration requirements, documented transfers. The EEA is the EU plus Iceland, Liechtenstein, and Norway.↩︎
Neither the AI Act nor the AI Diffusion Rule is a current list of allowed models by jurisdiction.↩︎
Bureau of Industry and Security, press release on rescinding the AI Diffusion Rule, May 13, 2025; “Framework for Artificial Intelligence Diffusion,” 90 FR 4544, January 15, 2025, creating ECCN 4E091 for certain closed-weight model weights; Government Accountability Office, B-337935, May 12, 2026. A Federal Register search on October 4, 2026, found no formal rescission or replacement; country-specific rules continue, such as 2026-14132, effective July 10, 2026, giving approved UAE entities license-free access to advanced computing items. None of this settles a particular transaction.↩︎
Microsoft Learn, checked October 3, 2026: deployment types (processing by type, release order, data-zone changes without notice, troubleshooting, an Azure Policy rule on sku.name), spillover, and the CLI deployment reference. As published, the sample policy has no then block and denies nothing until an effect is added.↩︎
European Data Protection Board, Guidelines 3/2018 on the territorial scope of the GDPR, final version, November 2019. Establishment, targeting, and monitoring are distinct grounds; nationality alone is not the test.↩︎
European Data Protection Board, Guidelines 05/2021, version 2.0, 14 February 2023: remote access is a transfer when the three criteria are met, but not when the same controller’s employee reaches its data from abroad (Example 8.1). Microsoft Learn, continuing transfers for EU Data Boundary services, checked October 3, 2026. Irish Data Protection Commission, TikTok inquiry, decision of 30 April 2025 under Article 46(1) GDPR; one company’s facts.↩︎
Microsoft Learn, checked October 4, 2026: provisioned throughput (separate quota pools; quota is not capacity); PTU billing (reservations reserve no capacity; no exchanges between deployment types); and PTU reservations in Cost Management, which lists such exchanges. Treat neither page as the contract.↩︎
Office of the Privacy Commissioner of Canada, Guidelines for processing personal data across borders, on accountability under PIPEDA; they exclude public-sector transfers and provincial private-sector rules.↩︎
Act respecting the protection of personal information in the private sector, CQLR c P-39.1, section 17, which also covers entrusting the information to a person or body outside Quebec and requires a written agreement.↩︎
California Legislature, AB-375, chaptered June 28, 2018, operative January 1, 2020 (Civil Code § 1798.198); California Department of Justice, CCPA, updated August 28, 2026. CPRA amendments took effect in 2023, and the obligations have exceptions; the engineering consequences are planning implications, not measured spending.↩︎
Irish Data Protection Commission, Meta Platforms Ireland transfers inquiry, decision of 12 May 2023, deadlines running from notification; Decision (EU) 2023/1795 followed on 10 July 2023. Historical, not a statement about any current transfer.↩︎