Data sovereignty is an architecture

Trace the routes a hosting label leaves out

A database stays in-country while a support ticket copies a customer prompt elsewhere. A regional model uses a different geography during failover. These illustrative paths expose the gap in a hosting label: the service boundary extends beyond its main endpoint. Executives need an enforceable account of where information goes, who can use it and what happens when the normal route fails.

The European Commission's official overview describes mechanisms for international personal-data transfers, including adequacy and safeguards. It does not establish a universal requirement that every European workload remain inside one national boundary. ¹ Equally, meeting an international-transfer condition does not answer every question about lawful processing, security or sector requirements. A procurement team should avoid compressing these separate issues into a single sovereign or compliant checkbox.

Start with the business information, affected people, jurisdictions and consequences of lost control. Separate mandatory conditions from commercial preferences. A public-information assistant and a confidential employee service may justify different designs. That distinction prevents investment in a restrictive deployment that still leaves the material exposure unresolved.

Map the whole service from intake to deletion

Create a flow inventory from intake through deletion. Include uploaded files, extracted text, embeddings, prompts, generated responses, cached results, evaluation examples and operational logs. Record where each item is stored, where it is processed and which actors can access it. Distinguish the intended path from emergency behavior. A failover arrangement that silently changes processing geography can invalidate the assumptions behind an otherwise carefully designed service.

Microsoft's current Foundry documentation differentiates processing locations for Standard, Global and DataZone deployment types and separately describes storage geography. Stateful features and abuse monitoring also have documented handling arrangements. These are vendor statements about specified services and configurations, not independent verification of a customer's implementation. ² Their value is to show why a cloud resource's region label cannot stand in for a full processing map.

Place shared services on the map. A global observability platform may receive prompts through diagnostic logging. A development team may copy an incident into a ticket. An evaluation service may retain examples long after the production cache expires. These are illustrative pathways to investigate, not claims about every supplier. The data owner should be able to explain which pathways exist, why they are needed and how their configuration was verified. Unknown pathways should remain explicit procurement and engineering questions.

Separate location, authority, keys, continuity and evidence

mayden proposes a five-layer sovereignty map: location, authority, key control, continuity and evidence. Location concerns processing and retention. Authority concerns who may administer or compel access under the applicable arrangements. Key control concerns who can authorize cryptographic use. Continuity concerns the ability to operate or exit under supplier disruption. Evidence concerns the records that support these claims. The framework is original synthesis, not a legal definition or a validated scoring system.

Google Cloud's KMS documentation distinguishes key-management roles, access controls, logs and geographic handling. ³ The management implication is to ask which operation a customer-controlled key actually governs. Control of storage encryption does not automatically mean that a service can perform useful inference without processing readable information. Evaluate the precise threat model, service design and contractual commitment. Claims about encryption become meaningful when the protected asset and access scenario are specified.

Confidential computing addresses a different exposure from encryption at rest. Google's technical documentation describes hardware-based trusted execution environments that protect data while it is being processed. ⁸ That capability belongs in an architecture assessment, but it does not replace an assessment of who can invoke the service, what leaves the protected environment or which laws and contractual terms apply.

Ask suppliers to demonstrate the complete path with an actual workload: entry, processing, output, diagnostics and recovery. Specify which components are attested and which are outside that boundary. mayden proposes treating each unprotected path as an explicit design decision with an owner. A protected computation that sends unrestricted output into a support log has not resolved the whole confidentiality problem.

AWS's Bedrock data-protection guidance emphasizes identity permissions and secure transport, among other protections. ⁴ These controls belong alongside location requirements. A locally hosted service with broad internal permissions can expose information through authorized accounts; a geographically distributed service may enforce narrower access. The architecture decision should compare the relevant risks without treating geography as a substitute for identity design. Each layer needs its own owner, evidence and exception process.

Attach each legal obligation to a specific flow

The EU and Saudi Arabia are separate regulatory contexts. The European Data Protection Board's adopted recommendations address supplementary measures supporting transfer tools. ⁵ SDAIA's current Knowledge Center provides the Kingdom's transfer regulation and standard contractual clauses. The transfer text sets conditions; the clauses describe one form of appropriate safeguard and obligations for the parties. ⁶⁷ These instruments should be interpreted for the specific controller, processing purpose and transfer, with relevant sector rules considered.

Legal currency is itself an evidence problem. Review the authority's current Knowledge Center and confirm the identity of the instrument, rather than relying on a saved document or an ambiguous portal path. The implementing regulation and the transfer regulation answer different questions. An enterprise should retain the reviewed instrument, access date, applicability analysis and legal owner. A policy copied into an architecture slide without a version can remain influential after its basis changes.

Do not assume that an arrangement approved for one entity, data class or country applies to another. A group may contain government-related operations, regulated financial services and ordinary commercial activities. Their constraints may differ even when they share a cloud account. The practical task is to record the applicable obligation beside the affected data flow and control. Where interpretation remains unresolved, restrict that flow while the owner resolves the question. This creates a concrete engineering boundary instead of a vague risk statement.

Compare the cost of architectures that actually qualify

Regional separation can duplicate infrastructure, reduce access to model options and make operations harder. A company that fragments every workflow by country may lose economies of scale and create inconsistent customer experiences. Local operations can also depend on a small pool of expertise, making incident recovery slower. These are real trade-offs. Sovereignty should be evaluated against a specified threat and obligation, with costs made visible. The most restrictive design is not automatically the best design for every process.

Compare complete qualifying options: a shared service with segregation, a regional service or a dedicated environment. Evaluate capability, cost, recovery and residual dependence after the mandatory requirements are met. mayden recommends keeping those dimensions visible rather than collapsing them into an unvalidated sovereignty score.

A selective architecture may therefore be appropriate. Keep sensitive evidence within a controlled environment while allowing approved public information to use broader services. Whether a transformation sufficiently reduces sensitivity requires case-specific assessment; removing names does not necessarily remove identifiability. Treat derived data, summaries and embeddings as separate objects to classify, rather than assuming they are safe because they differ from the original document. The point is to make a defensible decision about each information product.

Share public evidence without opening restricted routes

Consider a fictional manufacturer with an EU customer-support operation and a Saudi operating company. Both want an assistant that searches public product manuals and internal customer correspondence. A single regional hosting claim cannot settle the design. The public manual collection, customer records, extracted summaries and support logs need separate classification. The legal and security teams must establish the applicable conditions for each entity and flow; this example assumes no particular transfer is lawful or prohibited.

Compare a shared service for all material, separate regional services and a split design that shares public evidence while processing restricted records through approved routes. For each option, trace administration, evaluation and failover as carefully as ordinary inference. Estimate operating effort and recovery needs alongside model capability. A cheaper endpoint may create additional review or duplication costs. A more restrictive deployment may still leave an unresolved support-access pathway. The comparison should expose these differences before procurement narrows the choices.

Exhibit 02 follows one restricted customer case through the proposed split design. Its unknown labels are deliberately fictional: classification, derived-data access, inference location, logs, support access, failover and deletion have not been verified. Each has an owner and a restriction. Synthetic material can test routing while those questions remain open; real restricted records cannot enter an unapproved path merely because the public-manual route works. An outage should invoke an approved alternative or a staffed handover, not silently broaden processing geography. Technical blocking and deletion exercises test the configuration; the legal owner must still assess the basis and conditions of actual processing.

Decide by information class. Public manuals may use the shared route after classification; customer correspondence stays restricted until its processing, support and failover conditions are satisfied. Classify summaries and embeddings separately. If routing cannot enforce these distinctions, the split design is not yet an available option. Record that restriction, its owner and the evidence needed to change it.

Approve a control map and prove the exit

Approve three records together: a control map, an exception register and an exit demonstration. The map connects each information product to its processing route and responsible actors. The register gives unresolved conditions an owner, restriction and review date. The demonstration establishes what the business can export and how access ends under the agreed terms.

Assign an executive to resolve trade-offs across legal, security, architecture and operations. Reassess material changes in supplier configuration, subprocessors and processing routes. Keep jurisdiction-specific evidence current. A static approval cannot support a service whose effective boundary has changed.

Test the proposed portfolio capability on one new route: can the organisation classify the information, establish its applicable conditions, enforce the route and operate the fallback without rebuilding the application? Measure that work and the residual dependency. The objective is flexibility within verified arrangements. Where no qualifying route exists, retain a restricted or manual service while the missing condition is resolved.