StrategyCore

// Sovereignty & portability

Global technology, local control.

Sovereignty covers three areas: where the data lives, where the models run, and where security operates. Buyers here evaluate all three before they buy.

// Residency & privacy

Where the data lives is part of the sale.

Japanese buyers answer to real instruments before they can adopt a foreign product. Meeting them is a deployment decision, and it is one you can settle in your favour by running the workload in country.

01/

APPI Article 28: sending personal data to an overseas third party needs prior consent and disclosure of where it goes, unless the destination sits on the adequacy list. Run the workload in Japan and that transfer question closes. The regulator is the Personal Information Protection Commission.

02/

Sector rules sit on top. FISC for finance, the 2G3M guidelines for medical information, ISMAP and Government Cloud for the public sector, Article 4 secrecy of communications for telecom. Each one pushes sensitive data toward controlled, in-country hosting.

03/

EU and Japan hold mutual adequacy under Decision 2019/419, so EU personal data flows to Japan without standard contractual clauses. One Japan deployment can serve your European data too.

04/

We minimise what gets collected in the first place. Email authentication holds no personal data at rest, and the data engine keeps records where residency requires them.

// Sovereignty by design

Where your product has to land

Sovereign boundary · Japan

SC-BD-01 · REV A · 2026.07

Your jurisdiction · Japan
In-country

data · at rest

data.at-rest

model · self-hosted

llm.self-hosted

keys · KMS

keys.kms

logs · immutable

logs.immutable

sources · in region
weights & data never leave
prompts · policy-gated
Outside the boundary

hosted API

llm.hosted-api

external SaaS

saas.external

Boundary diagram. Data at rest, a self-hosted model, KMS-held keys, and immutable logs sit inside the Japanese jurisdiction. In-region sources flow in and prompts are policy-gated, while weights and data never cross the boundary to hosted APIs or external SaaS.

// Where lock-in hides

Lock-in has moved up the stack.

Changing cloud provider is routine. The harder dependency sits higher up. When one provider holds the model, the knowledge extracted from a customer's documents, and the learned state their systems build over time, switching provider means rebuilding those layers. Buyers here ask how portable they are before they commit.

01/

Model lock-in. Prompts, tools, and fine-tunes built for one provider's API rarely transfer cleanly to another.

02/

Knowledge lock-in. The structured knowledge a system extracts from a customer's content is often held in the provider's own format.

03/

Behavioural lock-in. The learned state a system builds over time is the hardest part to export.

// The sovereignty stack

The twelve layers of a sovereign deployment.

People reduce sovereignty to one question: where does the data sit. That is one layer. Control runs across all twelve, spanning the data itself, the AI built on top of it, and the security wrapped around both.

01/Data

Data

Where a customer's data physically lives, and whose law governs access to it.

02/Data

Infrastructure

Whose hardware runs the workload, and under which jurisdiction it operates.

03/Data

Privacy

Whose personal data is collected, how much of it, and how it is minimised, masked, and retained under the customer's law.

04/AI

Model

Which model answers, whether the customer can inspect it, and whether it can be replaced.

05/AI

Knowledge

The structured knowledge extracted from a customer's content, and the format it is held in.

06/AI

Learned state

The memory a system builds of how a customer's business works over time, and who holds it.

07/AI

Workflow

The processes and tools the AI is wired into, and whether they move with the customer.

08/AI

Evaluation

How quality is measured, and whether the tests and benchmarks stay with the customer.

09/Security

Security

Whether the controls that protect the data, and the signal they generate, run in country or report to an external cloud.

10/Security

Audit & assurance

The record of who did what, and the evidence an auditor or the board relies on, held where the customer can produce it.

11/All

Regulatory

Which regimes bind the workload, from APPI to sector rules, and whether the deployment can satisfy them without exception.

12/All

Localization

Whether the system works in Japanese, on local business norms, without translation loss.

// The portability ladder

Portability has levels, and most vendors only cover the first.

Every provider offers data export. Fewer let a customer take the knowledge and learned state built on that data. The more of these a product supports, the less a customer depends on any one provider.

Data portability

Export the raw data the customer put in. The baseline, and where most guarantees end.

Knowledge portability

Take the structured knowledge derived from a customer's content, in an open format they can reuse.

Learned-state portability

Carry the learned state of a customer's business between systems, so a change of model does not reset it.

Behavioural portability

Reproduce how a system acts, its decisions and defaults, on different infrastructure.

Model portability

Swap the underlying model without losing the knowledge, learned state, and behaviour above it.

// Deployment levels

Five deployment levels, from hosted to sovereign.

These five levels describe where the model runs, from a hosted frontier API to fully self-hosted open weights. Sovereignty is not all-or-nothing, so buyers place each workload on this scale by its data sensitivity, weighing reach and cost against control. The data layer is separate: it can run in-country on hardware the customer controls at any of the five levels.

Level 1: Frontier API

A hosted frontier model answers over an API. The fastest path to capability. Even here, the major providers do not train their models on business API data by default: OpenAI, Anthropic, Amazon Bedrock, and Google Vertex AI all confirm this in their commercial terms. This is the floor of sovereignty, not the ceiling.

Level 2: Customer-owned account

The same frontier models, run inside the customer's own cloud account and keys. Data stays in infrastructure the customer controls and pays for directly.

Level 3: In-region enterprise inference

Models served through enterprise cloud platforms with regional controls. Amazon Bedrock keeps data encrypted with customer-managed keys and does not share it with model providers. Google Vertex AI lets customers restrict data storage to locations they select.

Level 4: Sovereign open weights

Open-weight models run on infrastructure the customer owns, or that a trusted domestic operator runs, under Japanese jurisdiction. The model, the data, and the learned state all stay in country. Nothing leaves for an external provider.

Level 5: Multi-model sovereign routing

Sensitive workloads run on sovereign open weights. Less sensitive work can use frontier APIs where they are the best tool. Traffic is routed by the sensitivity of the data, so the customer gets frontier capability and sovereign control at once.

Providers not training on business API data is the baseline. The strongest option is full sovereignty, where the model, the knowledge, and the learned state stay on infrastructure the customer controls. Most enterprises run several levels at once, matched to the workload.

// Interactive · trade-offs

See the trade-off at each level.

Select a level to see how portability, control, cost control, and speed to start rebalance. Moving from a frontier API toward sovereign raises control and portability, and trades against speed to start.

Level 1: Frontier API

A hosted frontier model answers over an API. The fastest path to capability. Even here, the major providers do not train their models on business API data by default: OpenAI, Anthropic, Amazon Bedrock, and Google Vertex AI all confirm this in their commercial terms. This is the floor of sovereignty, not the ceiling.

PortabilityVery low
ControlVery low
Cost controlLow
Speed to startVery high

Relative and illustrative, not measured benchmarks. The right level differs per workload, and one deployment often mixes several.

// The evidence

The technical case for sovereign weights, grounded in research.

A model behind a stable API name can be re-tuned under your product with no notice. A quantized copy is a measurably weaker model. Even identical weights diverge across hardware. We set out the primary research, and what it means for how your product runs models in production.

Plan where each workload runs.

We work through the split with you: which parts of your product run on a frontier API, which stay sovereign for local buyers, and how the two connect without lock-in. Delivered in Japanese, to the standard local buyers expect.