AI deployment in Japan: the constraint is people, not law
Japan is the clearest case in this set of a market where the legal regime is not the binding constraint. The AI Promotion Act, in force since 1 September 2025, puts statutory footing under an approach built on promotion and principles rather than on prohibitions with penalties, and the rules that actually bind a given project come from its sector and from existing law. What constrains deployment is reported consistently to be people: specifically, the scarcity of individuals who combine real workplace experience with enough understanding of a system to shape it, which is the profile a deployment needs on the customer side and cannot substitute for. That reframes the planning question. In most markets the first question is what is allowed. Here it is who inside the organisation is going to carry this, and the answer determines the timeline more than anything a vendor controls.
Japan, in short
Voluntary framework| Instrument that binds | The AI Promotion Act, in force since 1 September 2025, which gives statutory footing to a promotion-oriented approach |
|---|---|
| Population adoption | The AI Index does not publish a figure for this country. That is an absence of data, not a low number. |
| What differs here | The reported obstacle is not appetite or regulation but people who can carry a deployment inside an operating team, which makes the internal owner the scarce input rather than the technology. |
| Working language | Japanese, including internal documentation |
Legal position checked 2026-09-24. This is a starting point for a question to a local lawyer, not an answer. No compensation figures: see methodology.
The profile that is scarce, and why substitutes do not work
The person a deployment needs on the customer side is not a data scientist and not a project manager. It is someone who has done the work being automated, knows the exceptions that are written down nowhere, and understands the system well enough to say when it is wrong for a reason that matters.
Vendors routinely try to substitute for this with their own people. It does not work, and the reason is structural rather than about skill: the exceptions that matter are not knowable from outside on the timescale of a project. An external engineer discovers them one incident at a time, over months, which is exactly the delay the substitution was meant to avoid.
The practical response is to make identifying this person the first deliverable rather than a staffing detail. A project that starts without one is not slower by a margin, it is running a different and much longer process, and the difference is usually attributed afterwards to technology or to culture.
Consensus changes where the time sits, not how much there is
The pattern reported by teams working across both markets is close to a mirror image. In markets where a decision is made quickly by a sponsor, the build is fast and adoption is a prolonged fight with people who were not consulted. Here, the decision takes longer because more people are genuinely brought into it, and then implementation meets much less resistance.
Plans built for the first pattern misjudge both halves. They allocate too little time before the build and too little to adoption afterwards, on the assumption that the second phase is where the effort goes. A schedule that front-loads the alignment work and treats adoption as comparatively cheap fits what actually happens.
There is an advantage in this for anyone whose project survives the first phase. Once a decision is genuinely taken, the thing gets used, which is not true everywhere and is worth a great deal.
Language is not an interface question
Japanese is the working language of the deployment, including internal documentation and the evaluation set. This is more consequential than in Latin-script markets, and not only for the obvious reason.
A system handling Japanese text has to deal with mixed scripts, with no reliable word boundaries, and with document conventions that do not resemble the ones most systems were tuned on. Retrieval and chunking behave differently. A pipeline that performs well on English documents cannot be assumed to transfer, and finding out that it has not is a stage-three discovery that should have been a stage-one test.
The corresponding discipline is to build the evaluation set from real Japanese documents before anything else, and to test retrieval on them first. This costs a week and removes the most common cause of a project that looked fine in a pilot.
What to ask before scoping a Japanese project
Who, by name, will own this inside the operating team, and what else are they responsible for this quarter. Whether the documents involved are digital or scanned, because the second case adds an extraction stage that is frequently discovered late. And how decisions of this size are normally taken here, which is the question that tells you whether your timeline is built for the right pattern.
The five stages do not change. Stage one takes longer and produces a much more durable agreement; stage four is easier than the plan assumes. Getting that trade the wrong way round is the characteristic error of teams arriving from markets that work the other way.
