In late February we attended a closed-door roundtable in Tokyo focused on enterprise process automation. The event was organized by an industry association and brought together IT and operations leads from eight Japanese enterprises — a mix of mid-size manufacturers, logistics companies, and trading houses. The session ran most of a day and was held under Chatham House rules, so I'm writing about what was discussed in aggregate, without attribution to specific organizations or individuals.
I'm publishing this because the conversations confirmed things we believe about the Japanese enterprise AI adoption landscape, complicated a few of them, and surfaced one concern I didn't expect. The market narrative you see in press coverage and analyst reports doesn't always match what operations leads actually say when they're in a room without a vendor agenda. This is my attempt to share what that unfiltered version sounds like.
Data Sovereignty: Present in Every Session
The roundtable was structured around three working sessions: procurement and AP automation, compliance and audit processes, and broader IT governance for AI systems. Data sovereignty came up substantively in all three.
In the procurement session, a logistics group with roughly 12,000 employees described a situation where they had piloted a cloud-based procurement automation tool from a major international vendor. The pilot was technically successful — the automation worked, cycle times improved, the user interface was well-designed. The project stalled when their CISO asked a routine question during security review: where does our vendor data go when the AI processes it? The answer — that data was processed in shared infrastructure in a US data center — ended the pilot. Not because of a specific regulation requiring Japanese data residency, but because the logistics group's board had a standing policy that competitive operational data must remain on infrastructure under their direct control.
This scenario came up in different forms throughout the day. A Tier 1 automotive parts manufacturer with plants in three prefectures described similar dynamics around supplier pricing data. A trading house mentioned concerns about contract terms appearing as training data in future model generations — a risk that cloud AI vendors typically address in their terms of service with data processing agreements, but which the trading house's legal team wasn't comfortable relying on contractually.
What struck me is that none of these organizations cited specific regulatory requirements driving the data sovereignty concern. Japan's APPI imposes certain requirements on personal information, but the specific data these organizations were concerned about — vendor pricing, contract terms, supplier network structure — isn't personal information under APPI. The concern is commercial confidentiality and competitive risk, not regulatory compliance. The organizations making the most aggressive data sovereignty demands are making them as a matter of business policy, not legal obligation.
The "Wrapper" Fatigue Problem
One of the more interesting discussions of the day came from an IT director at a specialty chemicals manufacturer. He described what he called "wrapper fatigue" — his organization had evaluated six different AI automation products in the past eighteen months, and most of them turned out to be workflow orchestration layers built around cloud LLM APIs. They were, in his phrase, "API wrappers dressed as platforms."
His concern wasn't capability — the wrappers worked reasonably well for simple automation tasks. His concern was dependency structure. If the underlying model API changes its pricing, discontinues a model version, or modifies its output format, the entire automation stack breaks. He had seen this happen once already with a tool they were using for document classification — a model version change broke the structured output extraction they relied on, and the vendor's fix required a three-week update cycle during which the automation was unavailable.
Several other participants echoed this. The IT leads in the room were specifically looking for automation tools where the core model dependency was under their control — either running locally, or at minimum running on infrastructure where version and configuration changes required their explicit approval.
We're not saying cloud-based automation tools are the wrong choice for every organization. For organizations without the IT capacity to run local inference, cloud services are often the practical path. But the "wrapper fatigue" observation is a real signal about what enterprise IT teams with operational responsibility are experiencing when they try to depend on cloud AI services for business-critical processes.
Process Documentation as the Limiting Factor
The compliance session surfaced a pattern we see in our own engagements. When the conversation turned to what was actually blocking automation projects, the most common answer wasn't technology — it was documentation. Several participants described approval processes that exist largely as institutional knowledge rather than written procedures. The people who know how the process works are senior employees who have been doing it for years. The written policy document doesn't reflect current practice. Automating the documented process would produce wrong answers.
A large food manufacturer described a compliance check process that had three senior employees who each applied it differently based on their individual interpretation of the same policy document. When asked to agree on a single documented version in preparation for an automation pilot, the process took four months and required intervention from the CFO to resolve the disagreement. The automation project was still on hold waiting for the policy to be officially updated.
This resonates strongly with our rule mapping experience. The technology is rarely the constraint at the start of an engagement. The constraint is usually organizational: getting agreement on what the policy actually says, surfacing the informal exceptions that everyone knows about but nobody has written down, and creating a single authoritative version of the process that can be translated into agent logic.
The roundtable participants who were farthest along in their automation journeys — two of the eight organizations had deployed automation at scale, not just in pilot — shared a common characteristic: they had invested in process documentation before starting the automation work. One of them described it as "paying for the documentation project twice" — once for the internal process improvement benefit, and once as the prerequisite for automation. They considered both investments justified.
Where Human Judgment Stays
The governance session had a useful discussion about where organizations draw the line between automated decisions and required human judgment. The answer varied by organization but showed consistent patterns.
Routine, high-volume, low-value decisions were universally considered appropriate for automation. Processing invoice payments below a defined threshold, routing standard procurement requests that clearly match approved vendor and category combinations, performing document format validation — these were the cases everyone agreed AI should handle autonomously.
High-value decisions — new vendor onboarding above a certain contract value, first-time purchases with sole-source vendors, any transaction involving a supplier in a sanctioned jurisdiction — were universally flagged as requiring human approval. Not AI recommendation plus human confirmation, but genuine human decision-making with the AI providing supporting information.
The interesting cases were the middle tier: moderately complex decisions that happen with medium frequency and have medium stakes. The organizations most advanced in their automation thinking had developed explicit criteria for this tier: the decision goes to automation if it's been handled the same way at least thirty times in the past year with no overrides, and goes to human review if it's a case type that has ever been overridden or escalated. That "override history" heuristic was something I hadn't encountered before, and it struck me as a practical and auditable way to define the automation boundary.
What Wasn't Said
The concern I didn't expect: several participants expressed discomfort with the pace of capability advancement in AI systems and what it means for governance frameworks. The worry isn't that current AI systems are too capable — it's that governance frameworks designed for current AI capabilities may become inadequate as those capabilities increase, faster than organizational governance processes can adapt.
One participant put it plainly: "We are approving automation frameworks based on what the AI can do today. By the time the framework is fully implemented and our employees are trained, the AI will be able to do substantially more. Our internal controls won't cover what we'll actually have deployed."
This is a legitimate concern and one that doesn't have a clean answer. The organizations handling it best seemed to be taking an explicit tiered approach: deploy automation for a narrowly scoped process, evaluate governance adequacy for twelve months, expand scope only after demonstrating governance adequacy at the current tier. Slow, but sustainable.
The roundtable confirmed that the appetite for process automation among Japanese enterprises is real and growing. The constraints are also real: data sovereignty concerns that go beyond regulatory compliance, dependency risk in cloud-based tools, process documentation maturity as a prerequisite, and governance frameworks that need to keep pace with capability growth. None of these are reasons to avoid automation. They are reasons to approach it methodically — which, for better or worse, is exactly what Japanese enterprise IT culture already does.