When we started building dodoAI in 2024, the market had largely made up its mind. AI automation meant cloud. You sign up for an API key, wire your workflows to a shared inference endpoint, and your data flows out every time the model runs. For consumer applications, this is a reasonable trade. For enterprise process automation — the kind that touches purchase orders, vendor contracts, employee records, and compliance decisions — we think this is the wrong direction entirely.
This is not a contrarian position for its own sake. It is a practical engineering conclusion. When we mapped the data that flows through a typical approval workflow at a mid-size Japanese enterprise, we found that meaningful competitive intelligence exits the network with every API call. Vendor pricing. Payment terms. Sourcing geography. Headcount requests. These are not abstract privacy concerns. They are operational secrets that companies have spent years negotiating.
What "Cloud AI" Actually Means for Your Data
The phrase "cloud AI" is slippery. Most enterprise IT teams understand what it means in theory — model inference happens on infrastructure owned by a third party — but the practical implication during workflow execution is rarely examined closely.
Consider a procurement approval workflow. An employee submits a purchase order for raw materials at a specific unit price from a named supplier. An AI system evaluates whether that PO meets policy — spending limits, preferred vendor lists, budget period alignment. Every field in that PO that gets sent to a cloud model is now a data point on the provider's infrastructure. Under most shared-service agreements, that data is used to improve model quality. Even if it isn't, it is sitting on servers you don't control, logged in inference records you cannot inspect, processed in an environment where co-tenant separation depends entirely on the provider's assurances.
Providers say this data is never read by humans, never used for training without consent, and is deleted after a retention window. These statements may be entirely accurate. The point is that compliance auditors and information security teams at regulated enterprises cannot verify them. They cannot perform a forensic audit of a shared cloud endpoint. They cannot produce evidence of data handling for a regulator. They can only produce a vendor contract that says the right things.
The Sovereignty Question Is Structural, Not Just Legal
Discussions about data sovereignty tend to orbit legal frameworks — GDPR, APPI, sector-specific regulations. Those frameworks matter enormously, and we will address Japan's APPI specifically in a later post. But the sovereignty question goes deeper than compliance. It is fundamentally about who controls the operating conditions of a system that makes consequential decisions on your behalf.
An on-premises AI agent runs on infrastructure your team manages. You control the model version. You control the inference parameters. You control the log retention policy. You control who has access to the execution environment. When something goes wrong — and in enterprise automation, edge cases are how most things eventually go wrong — your team can examine the full execution trace without requesting it from a vendor, waiting for a support ticket, or hoping that the relevant logs haven't aged out.
We are not saying cloud infrastructure is inherently insecure or that cloud providers operate in bad faith. Most large providers have security postures that exceed what mid-size enterprises could build themselves for general workloads. The issue is that "secure" and "sovereign" are different properties. A cloud environment can be highly secure and simultaneously be an environment over which you have minimal operational sovereignty. For general SaaS applications, that trade-off is fine. For AI systems that make approval decisions, it deserves much more careful consideration than the market has applied so far.
Why the Industry Is Moving the Wrong Direction
The dominant narrative in enterprise AI through 2023 and into 2024 has been cloud-first with API-based consumption. The model providers have genuine incentives to promote this model: it generates predictable API revenue and keeps enterprises dependent on the provider's model updates. System integrators have incentives to build on shared cloud because it reduces deployment complexity for them. The enterprise buyer, not the vendor or integrator, bears the sovereignty cost.
This pattern is not new. It mirrors the early SaaS era, when enterprises moved critical data to shared cloud applications before anyone had fully mapped the implications. Some of those migrations created data management problems that IT teams are still untangling. AI automation is moving faster, and the sensitivity of the data involved — operational decisions, not just stored records — makes the exposure surface larger.
There is an argument that on-premises deployment is only feasible for the largest enterprises with significant IT infrastructure. This was true in 2019. It is no longer accurate. Container-based deployment, pre-packaged model weights, and modern inference runtimes mean that a well-designed on-premises AI agent can run on modest hardware — a dedicated VM cluster or even a properly provisioned bare-metal server — without requiring a specialized AI infrastructure team. The deployment complexity has dropped considerably.
What Sovereign Deployment Actually Requires
Deploying AI agents inside your perimeter means accepting a different operational model than cloud API consumption. You are responsible for model updates. You need infrastructure capable of running inference at the scale your workflows demand. You need an agent runtime that was designed for air-gapped or network-isolated environments, not one that was retrofitted for on-prem after the fact.
The last point matters more than it sounds. Most AI orchestration frameworks were built with cloud connectivity as the default. They call out to external services for logging, monitoring, model registry updates, and sometimes for core inference routing. When you deploy these in a restricted network environment, you discover the connectivity assumptions embedded throughout the stack. APIs fail silently. Monitoring dashboards stop working. Update mechanisms break. The agent technically runs, but not in the configuration it was designed for.
When we built dodoAI, we started from the other direction: assume no outbound connectivity. Every component of the runtime — inference, logging, audit trail, escalation routing, policy enforcement — is designed to operate without calling home. External connectivity is an opt-in for specific integrations the customer controls, not a baseline assumption baked into the core. This design choice costs us some development velocity. Certain managed services that would simplify our operations are off the table. We accept that cost because the alternative — an agent runtime that only truly works when it can reach external endpoints — is not something we would put inside a Japanese enterprise network.
The Practical Starting Point
For enterprises evaluating AI automation for back-office processes, the starting question should not be "which cloud AI vendor has the best accuracy benchmark?" It should be "what data will flow through this system, and where will it go?" Map the data at the workflow level. Identify which fields carry competitive sensitivity. Then evaluate whether the deployment model you are considering gives you the controls you would need to answer a data subject access request, a security audit, or an incident investigation.
For many standard workflows — content generation, knowledge retrieval, customer-facing chatbots — cloud is a reasonable choice and the sovereignty trade-off is acceptable. For back-office process automation that touches procurement, compliance, vendor management, and financial approvals, we believe the case for on-premises deployment is strong enough that it should be the default assumption, not a niche requirement.
The convenience of cloud AI is real. The cost of that convenience, when you account for the operational data that exits your network with every inference call, is higher than most procurement evaluations reflect. Getting that accounting right at the start is considerably easier than revisiting the deployment model after a workflow is in production.