Can You Actually Run an LLM Inside Japan? What the Providers' Own Docs Say

Hello, this is Ryuta Hamamoto from TIMEWELL.

An IT manager at a manufacturer asked me this recently: "We want to use cloud AI, but our internal policy says data cannot leave Japan. Picking the Tokyo region covers that, right?"

I could not answer on the spot. More precisely, I thought I could, and then I checked, and the answer changed.

Reading the providers' own documentation, "available in the Tokyo region" and "processed only in the Tokyo region" turn out to be very different claims. The gap between them seems to be widening.

So this piece lays out what AWS, Microsoft, Google and Fireworks AI actually write in their docs, quoted as they wrote it. Then it goes through which rules genuinely require data to stay in Japan. One thing up front: the reason most companies give, personal data protection law, is not the one that holds.

Model availability moves. Everything here reflects documentation retrieved on 5 September 2026, so check the current version before you decide anything. If you want a read on where your own organisation stands first, we have a free AI readiness check.

What "available in Tokyo" does not mean

Amazon Bedrock publishes a model card for every model. Each card sets out the three shapes in which you can call it: In-Region (requests never leave the region you name), Geo (routing that stays within a defined geography) and Global (routing worldwide)¹.

A Japanese company only needs to read two columns. Is Tokyo (ap-northeast-1) listed under In-Region, and does the Geo column carry an ID beginning with jp.? That prefix is cross-region inference confined to Japan, routing between Tokyo and Osaka. I opened the cards one at a time and checked those two things.

Model	In-Region, Tokyo	Japan Geo (jp.)	Global
Anthropic Claude Opus 5	✗	none	✓
Anthropic Claude Sonnet 5	✗	none	✓
Anthropic Claude Sonnet 4.5	✗	yes	✓
Anthropic Claude Haiku 4.5	✗	yes	✓
Amazon Nova 2 Lite	✗	yes	✓
DeepSeek V3.2	✓	not supported	not supported
Qwen3 32B	✓	not supported	not supported
gpt-oss-120b	✓	not supported	not supported

The top half and the bottom half say opposite things.

Start with the Anthropic rows. Their In-Region field reads "N/A" outright, meaning no region at all, not just Tokyo. Keeping the work in Japan therefore depends on the jp. Geo profile. Now look at the newest generation. Opus 5 and Sonnet 5 list us., eu. and au. and nothing else. There is no jp. The previous generation, Sonnet 4.5 and Haiku 4.5, has one.

Read that again in plain terms. If you want Anthropic's models with the processing kept inside Japan, the model you can have is a generation behind. Take the newest and you leave the country; stay in the country and you drop back a generation. Amazon's own Nova 2 Lite showed the same shape, with an ✗ for In-Region in Tokyo and the jp. Geo profile as the way to stay onshore.

Then the bottom three. DeepSeek V3.2, Qwen3 32B and gpt-oss-120b all carry a ✓ for In-Region in Tokyo, with Geo and Global marked "not supported". Turn that around and it means they cannot leave Tokyo. Judged purely on whether the work stays inside one region, the cleanest option on the menu right now is open weights.

I had expected the opposite before I started reading. My assumption was that open weights would be the afterthought and the commercial flagships would be distributed generously. It runs the other way. Proprietary frontier models have every reason to pool their capacity, and open weights are far easier to park in a single region. That asymmetry is what shapes the choices available in Japan today.

I should say I do not read this as negligence on AWS's part. The GPUs behind frontier models are scarce and demand arrives everywhere at once. Concentrating that capacity gives better latency and better stability. It is a sound call. It is also a call whose logic sits entirely on the provider's side of the table, not the customer's.

On related ground, I wrote about running Claude Code securely across Bedrock and Vertex in a piece on secure architecture. Reading both should give you a feel for where the boundary really falls. Which models you can actually call in Tokyo, and which entries carry a Japan ML-processing commitment, turn out to be two different lists. I put them side by side in a piece on Vertex AI's Tokyo region.

Microsoft writes that regional access is not being expanded

Azure's documentation goes further. Microsoft Learn (updated 4 September 2026) splits availability into Standard regions, Data Zone and Global².

Pulling the fine-tuning table:

Model	Standard regions	Data Zone	Global
gpt-5 (2025-08-07)	North Central US / Sweden Central	US	✓
o4-mini (2025-04-16)	East US2 / Sweden Central	US	✓
Qwen-32B	Not supported	US	✓
Llama-3.3-70B-Instruct	Not supported	US	✓
gpt-oss-20b	Not supported	US	✓

For the flagship models, in-region deployment exists in a handful of US and Nordic regions. Japan is not among them. Then look at the open-weight rows. Qwen, Llama and gpt-oss all read "Not supported" under Standard regions. The in-region option is not narrow for those models. It does not exist.

The same page adds:

Global training provides more affordable training per token, but doesn't offer data residency.

That sentence sits in the fine-tuning section, but it is the provider stating the trade plainly: Global is cheaper, and it does not offer data residency. How far a Data Zone deployment actually keeps things in Japan, and where storage and inference part company, is in a separate piece on Azure's Data Zone.

One more line stopped me:

At this time, access to o1-mini standard (regional) deployments isn't being expanded.

It refers to one model, so I do not want to over-read it. Still, anyone waiting for regional coverage to fill in over time is waiting on something the documentation does not promise. I came away thinking this is not a problem that patience solves.

Google writes that endpoints guarantee nothing

Google Cloud's documentation is the most direct of the three. Two sentences from the Vertex AI generative AI locations page³:

Important: Endpoints don't guarantee data residency or in-region ML processing.

Don't use the global endpoint if you have ML processing requirements, because you can't control or know which region your ML processing requests are sent to when a request is made.

Read the first one plainly and it says choosing an endpoint guarantees neither data residency nor in-region ML processing. It sits as a general note about endpoints, not a caveat limited to the global one. The second says that with the global endpoint you can neither control nor know where processing happens.

Back to the question I opened with. This is why I could not answer it. Region selection and data location are not bound together as tightly as most people assume. The providers write that down, so this is not a matter of me reading against the grain.

To be fair to Google, none of this is hidden. Publishing it is the honest thing to do. The trouble is what happens when the note goes unread and "we set the region to Tokyo, so everything stays in Japan" becomes the accepted story internally. That is the sentence that gets picked apart in an audit or a vendor review.

Region pinning now has a price

There is a second shift worth watching. Fireworks AI's pricing page carries this line⁴:

Region-restricted deployments are priced at a 1.5x premium.

A 1.5x multiplier, applied to on-demand deployments. The same page lists GPU rates of $7.00–8.00/hr for an H100 80GB, $10.00–13.00/hr for a B200 180GB and $18.00–20.00/hr for a GB300 288GB.

What that line really marks is region pinning moving from a configuration setting to a billable item. Anything billable gets raised the moment someone builds a cost comparison. When performance and price are on the same slide, not many teams can defend a 1.5x uplift.

This is where I think the real difficulty lies. Nothing here is technically impossible. It becomes "possible but expensive" and "possible but a generation behind", and then quietly stops being chosen. That path is slower than a ban and much harder to notice. By the time anyone looks up, the domestic-only architecture cannot reach the current models.

So where does the requirement actually come from?

If all of that has you reaching for a domestic-region policy, one correction first. The reason most often cited, Japan's personal data protection law, does not support it.

The Personal Information Protection Commission's Q&A 7-53 addresses whether using a cloud service counts as provision under Article 27. Where the provider is contractually not handling the personal data and appropriate access controls are in place, no personal data has been provided, so consent is not required⁵.

Q&A 7-54 continues: since there is no provision, the supervision duty for delegated handling under Article 25 does not arise either⁶. Your own security measures remain necessary, of course. That is a separate question from whether a server sits inside Japan.

Leaving this fuzzy and writing "personal data, therefore domestic region" into internal policy costs you twice. You narrow your model choices for no reason, and you cannot answer when someone asks what the policy rests on. The second cost is the worse one, in my view. Rules without a stated basis get quietly ignored on the floor. The wider frame, including Article 28 and cross-border provision, is worked through from the statute in a piece on passing personal data to an LLM API.

So where is the real requirement? In healthcare, Japan's Ministry of Health, Labour and Welfare has taken its guidelines for the security of medical information systems to a 7th edition (June 2026)⁷. Together with the provider-facing guidelines from METI and MIC, this forms what practitioners call the three-ministry framework, and it imposes obligations specific to medical information. How cloud and AI are actually written up in that 7th edition is in a piece on the medical information guideline. In finance, the FISC security standards play that role; in government procurement, ISMAP does. What the freely readable financial documents will and will not support is in a piece on financial institutions and where the data sits, and the ISMAP programme itself in a piece on ISMAP and the government cloud.

Then there is economic security. Where technical information is processed, and whose legal system it falls under, runs directly into export control and supply-chain management. In that context data location is not a comfort question. It is something you have to be able to explain.

The requirement lives in sector rules, and those rules differ by sector. Until you have settled which ones apply to you, the internal debate cannot really start.

The government does not say "domestic region". It says ISMAP

Worth checking what the Japanese government itself writes, since "the government requires domestic data" gets repeated in a lot of internal policy documents.

The Digital Agency's guideline on procuring and using generative AI in public administration (DS-920), adopted on 12 June 2026, is a normative document: rules to be complied with for government information systems. Sixty-four pages on what each ministry must check when procuring generative AI⁸.

Here is the part that surprised me. The word "region" does not appear in it once. I searched. The government does not pin data location by region name at all.

What it uses instead is ISMAP:

Where a cloud service handling information requiring confidentiality is procured for a generative AI system covered by this guideline, it is to be selected in principle from the ISMAP cloud service list, based on the principle of using ISMAP, and separately handled in accordance with this guideline.

Assurance through a scheme, not through geography. So if someone in your organisation has said "the government requires data to stay in Japan", the source is worth checking. That is not what the document says. And when you go to the scheme that is supposed to carry the weight, a full-text search of the ISMAP control standards does not find it there either. I left the search results in a piece on what ISMAP does not say.

The risk of foreign-hosted servers, though, is stated plainly:

Where server equipment is located outside Japan, local law applies and there is a possibility of censorship or seizure by the local government.

That is the government's stated reason. Not personal data law, but applicable law and the possibility of censorship or seizure by another state. The same guideline asks officials to seek advice from the National Cyber Office before deciding, even where no procurement is involved.

The government's procurement checklist asks for model choice

The part of DS-920 I did not expect sits under avoiding vendor lock-in. These are procurement check items.

Type	Check item
Basic	The generative AI model in use can be identified, including version information
Optional (scored)	Where use of one specific model is not the primary purpose, the technical ability to select or combine the most suitable model from multiple generative AI models
Basic	Architecture and implementation that allow for ease of vendor or system migration
Basic	Risk mitigation for major updates and migration from a generative-AI-specific perspective
Optional (scored)	Output suited to Japan's linguistic and cultural environment

The suggested countermeasures are equally concrete:

Provide an abstraction layer (adapter) that anticipates switching models and vendors, and build the "exit strategy" into the architecture.

Read the Type column carefully, because it matters. Model choice itself is a scored extra, not a requirement. What sits in the mandatory column is being able to state which model version you are running and designing and operating for ease of migration.

That distinction cuts harder, not softer. Saying "we can offer several models" is a configuration claim. Disclosing the version and staying migratable is a demand on the architecture itself. Reading it, I realised the argument I had been making in private meetings was already public policy.

DS-920 runs to 64 pages, and the full checklist and the high-risk determination framework do not fit here. I went through it item by item in a piece on the government's generative AI procurement guideline.

The same test travels to private-sector procurement without modification. Ask whether models can be changed before asking which model to use. Whether versions are disclosed. Whether an abstraction layer exists. Whether history and prompts can be exported. Set against the regional constraints above, an architecture pinned to one model walks itself into a corner with no options left.

One more detail: as evidence for bias controls, the guideline lists documentation on "AI regulation in the country where the provider of the generative AI model is located". A framework for procurement teams to check whose rules a model sits under already exists on paper.

The surrounding legal scaffolding has also filled in. Japan has an act on promoting research, development and use of AI-related technology (Act No. 53 of 2025), a cabinet-approved AI Basic Plan of 23 December 2025 (since superseded by a new plan approved on 14 July 2026, with the Cabinet Office now listing the December version as a past plan), guidelines on ensuring appropriateness adopted by the AI Strategy Headquarters on 19 December 2025, and the AI Business Operator Guidelines now at version 1.2 (31 March 2026)⁹. Within about a year, the set of documents you are expected to reference has come together. What actually changed between 1.1 and 1.2 is in a piece on the AI Business Operator Guidelines.

Explaining this to a head office outside Japan

A pattern I see often, since a good share of the people asking me this work for the Japanese arm of a foreign group: the local team knows the constraint is real, and the head office hears "Japan wants something special again."

That conversation goes better with artifacts than with adjectives. Four are usually enough.

The first is the per-model availability table for the provider you already use, with the date you retrieved it. Not a summary. The actual table, showing that the model your group standardised on has an ✗ in the In-Region column for Tokyo. A head office that has never had to think about this tends to assume region selection is a dropdown that always works, because in their own geography it usually does.

The second is the endpoint note in the provider's own words. Google's "Endpoints don't guarantee data residency or in-region ML processing" carries more weight in a group-wide architecture review than any local memo, precisely because it is not a local memo.

The third is the specific rule that applies to your business, named. Not "Japanese regulation" as a category, but the guideline edition and the year: the medical information guidelines at their 7th edition of June 2026, the FISC standards, ISMAP for public-sector work. Vague appeals to national regulation invite the response that every country says that. A named document with a version number does not.

The fourth is the one people skip, and it is the one that makes the argument credible: state plainly where the constraint does not apply. If your workload is not in healthcare, finance or public procurement, say so. Cite the personal data position honestly, including that Q&A 7-53 does not require a domestic region. A local team that concedes the parts that do not apply gets believed on the parts that do.

I have watched both versions of this meeting. The one that opens with "Japanese law requires data to stay in Japan" ends with someone asking for the article number, and the room going quiet. The one that opens with a table showing an ✗ next to the model everyone uses ends with a decision.

Five things I check

Here is what I look at when choosing a platform. Not an abstract checklist, but which page of which document to open.

First, whether the model you want is offered In-Region, checked against each provider's availability table. Not the line in a sales deck that says "available in Tokyo" but the per-model table. As we have seen, the answer changes model by model inside the same region.

Second, if a cross-region or global endpoint is in play, whether you can identify where processing happens. When the documentation says you can neither control nor know, that is the same as saying you cannot explain it in an audit.

Third, whether region pinning carries a cost, checked on the pricing page. Sometimes it is stated outright, as with Fireworks AI's 1.5x. Sometimes it just shows up as a shrinking menu.

Fourth, how well the platform keeps up with new models. Whether today's frontier model runs there matters less than whether the one shipping in six months will run there on the same terms. Microsoft's "not being expanded" line is worth reading with this in mind.

Fifth, settle which regime applies to you before anything else. Healthcare, finance, government procurement, economic security. Or possibly none of them, in which case compare the cost of staying domestic against the cost of not reaching the current models, honestly and in the open.

For the record, I do not buy "domestic, therefore safe" as an argument. What makes a setup defensible is the contract, the access controls and the records that let you explain both. But I do think not being able to choose is its own risk. When your architecture decides which models you may use, you inherit every advance you cannot reach.

What is happening right now is that running inside Japan and running the newest models have become hard to do at once. It looks like a choice between two things. I do not think it has to be one.

Working out which regime applies to you, and whether the model you use today is genuinely processed in Japan, changes the quality of the conversation on its own. We work on enterprise AI architecture through ZEROCK, so if you want to talk through a specific setup, get in touch. On the models themselves, the DeepSeek V4 benchmark piece and Qwen's open-weight strategy are useful companions.

Footnotes

1. Amazon Web Services, "Amazon Bedrock model cards", Amazon Bedrock User Guide. The table above was built by opening each model card individually on 6 September 2026 and reading, for the bedrock-runtime endpoint, the In-Region endpoint URL, the Geo inference IDs, the Global inference ID and the ap-northeast-1 (Tokyo) row of the Regional Availability table. Definitions of the profiles (In-Region meaning requests never leave the region you specify, Geo meaning routing confined to a defined geography) come from the Inference options section of the same guide. https://docs.aws.amazon.com/bedrock/latest/userguide/models-region-compatibility.html ↩

2. Microsoft Learn, "Foundry Models sold by Azure" (updated 4 September 2026). Availability of fine-tuning models across Standard regions, Data Zone and Global, plus the statements "Global training provides more affordable training per token, but doesn't offer data residency.", "At this time, access to o1-mini standard (regional) deployments isn't being expanded." and "Open-source models (Ministral-3B, Qwen-32B, Llama-3.3-70B-Instruct, gpt-oss-20b) are only supported on Foundry resources and in the new Foundry UI." https://learn.microsoft.com/en-us/azure/ai-foundry/openai/concepts/models ↩

3. Google Cloud, "Locations", Gemini Enterprise Agent Platform documentation. Source of "Important: Endpoints don't guarantee data residency or in-region ML processing." and "Don't use the global endpoint if you have ML processing requirements, because you can't control or know which region your ML processing requests are sent to when a request is made." https://docs.cloud.google.com/vertex-ai/generative-ai/docs/learn/locations ↩

4. Fireworks AI, "Pricing". Source of "Region-restricted deployments are priced at a 1.5x premium." and the GPU hourly rates cited (H100 80GB $7.00–8.00/hr, B200 180GB $10.00–13.00/hr, GB300 288GB $18.00–20.00/hr). https://fireworks.ai/pricing ↩

5. Personal Information Protection Commission, Q&A on the Guidelines for the Act on the Protection of Personal Information, Q7-53. Where the cloud service provider does not handle the personal data in question, there is no provision under Article 27 and consent is not required. https://www.ppc.go.jp/all_faq_index/faq1-q7-53/ ↩

6. Personal Information Protection Commission, same Q&A, Q7-54. Where there is no provision under Article 27, no supervision duty over the cloud service provider arises. https://www.ppc.go.jp/all_faq_index/faq1-q7-54/ ↩

7. Ministry of Health, Labour and Welfare, "Guidelines for the Security Management of Medical Information Systems, 7th edition (June 2026)". https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html / Ministry of Economy, Trade and Industry, "Security Management Guidelines for Providers of Information Systems and Services Handling Medical Information, version 2.0" (revised March 2025). https://www.meti.go.jp/policy/mono_info_service/healthcare/teikyoujigyousyagl.html ↩

8. Digital Agency, "Digital Society Promotion Standard Guidelines DS-920: Guideline for the Procurement and Utilization of Generative AI for the Evolution and Innovation of Public Administration", adopted 12 June 2026 by the Steering Committee of the Digital Society Promotion Council. Normative document, 64 pages; first edition 27 May 2025. The ISMAP principle, the note on servers located outside Japan, and the procurement check items cited above are from this guideline. Quotations are the author's translation from the Japanese original. https://www.digital.go.jp/assets/contents/node/information/field_ref_resources/decb64eb-f26e-41cb-8d37-f3dd173108b8/59054b35/20260612_resources_standard_guidelines_guideline_01.pdf (English announcement: https://www.digital.go.jp/en/news/decb64eb-f26e-41cb-8d37-f3dd173108b8 ) ↩

9. Ministry of Internal Affairs and Communications and Ministry of Economy, Trade and Industry, "AI Business Operator Guidelines (version 1.2)", 31 March 2026. https://www.soumu.go.jp/main_content/001064279.pdf / Act on the Promotion of Research, Development and Utilization of AI-Related Technology (Act No. 53 of 2025); AI Basic Plan (cabinet decision, 23 December 2025; the current plan is the one approved on 14 July 2026); Guidelines on Ensuring the Appropriateness of Research, Development and Utilization of AI-Related Technology (AI Strategy Headquarters, 19 December 2025). All are cited in Chapter 1 of DS-920. ↩