AI budgets are getting scrutinized, and the question has shifted from "how do we start?" to "where did the returns go?" For most enterprises, the answer is buried in an architecture decision nobody made explicitly: that data should be moved to the intelligence, rather than the other way around.

We proved the latter works. At Duke Health, we deployed Trase OS directly inside its clinical environment, processing tens of thousands of documents across multiple high-volume workflows without a single byte of patient data leaving Duke's environment. Turnaround times dropped by more than 98%. Eighty-six percent of the work that previously required human intervention — including routing, triaging, chasing down administrative context, and other tasks that keep clinical staff from patients — was handled autonomously. The system escalated only the cases that required clinical judgment, ultimately resulting in thousands of staff hours being recovered. And, best of all, the compliance posture never changed, because it didn't have to. The data never moved.

That result did not come from a better model. There is no magical model that solves this. It came from a different architecture, one that brings intelligence to where data already lives rather than requiring a purpose-built AI stack from scratch. And that architecture is what the rest of this post is about.

The Data Gravity Problem Nobody Priced In

The last decade of cloud migration built something genuinely valuable: scalable infrastructure, elastic compute, and a foundation that made modern software possible. The challenge GenAI introduces is not a cloud problem. It is a data gravity problem that no platform, cloud or otherwise, fully anticipated.

Your most valuable data, whether clinical records, proprietary research, operational history, or regulated financial data, is heavy. As AI workloads scale, moving petabytes of it away from where it was created to run inference creates friction at three layers simultaneously: egress costs, sync latency, and the security exposure that comes from duplicating controlled environments. This friction compounds at enterprise scale regardless of which infrastructure you are running on. Gartner projects global AI spending will reach $2.5 trillion this year. A recent CXOTalk study found that only 5 to 6% of companies are generating measurable value from AI at scale. The delta is not a capability problem. It is a cost structure problem that the industry is only now beginning to solve.

McKinsey's State of AI tells the same story in a different way: 88% of organizations now use AI in at least one business function, but only 7% have scaled it enterprise-wide. The majority are still stuck at the experimentation or piloting stage. The most common culprit isn't the model. It's the plumbing. The budget is consumed by data infrastructure before the intelligence has a chance to prove itself.

Sovereignty Is Not a Premium Feature

The technical industry has been treating data sovereignty as a specialized requirement, something banks and healthcare systems need, rather than a default architectural standard. That framing is wrong, and it's expensive.

If your AI strategy requires moving your proprietary data into a provider's environment you don't fully control, you are compromising intellectual property for convenience. The good news is that CIO.com has documented a significant market shift: organizations are moving from "bring data to AI" to "bring AI to governed data," a trend known as "geopatriation." The enterprises getting this right are reporting up to five times the ROI of their peers. They're not fixing compliance after the fact. They're building on a foundation where data residency is the default, not a configuration option.

Sovereignty in 2026 is not a feature request, and it is not something you can bolt on after the fact. It has to be built from the ground up, as a foundational property of how your AI systems are designed. An AI strategy that treats governance as an add-on will eventually hit a wall, because the architecture underneath was never built to hold it.

What "Run AI In Place" Actually Means

The practical path forward is to layer intelligence directly onto your existing storage, access controls, and security posture. Not adjacent to it. On top of it and integrated into it.

When you do this, the AI inherits the governance you've already built, not a copy of it. Critically, your existing processes do not need to change. That matters more than it sounds. Process change creates a domino effect across teams, systems, and compliance obligations that is expensive to manage and easy to get wrong. The right question is not how to redesign your workflows around AI. It is how to integrate AI into your existing systems and processes with the least disruption and the highest return. In-place AI answers that question by design.Permissions don't need to be rebuilt. Data lineage doesn't need to be reconstructed. Compliance posture doesn't need to be re-established in a parallel environment. Cost predictability follows structurally. You eliminate egress fees, redundant storage, and the latency cost of round-tripping data to a remote inference environment and back. Regulatory compliance becomes simpler to demonstrate, not harder. Whether the requirement is the EU AI Act, HIPAA, or FedRAMP, keeping data where it lives means your audit surface doesn't expand every time you add a new AI workflow.

What the Duke Health Deployment Taught Us

Healthcare is one place the "move data to AI" model breaks down most visibly. Moving petabytes of patient records is technically possible. The real problem is that no healthcare organization with serious governance standards is willing to lose control of that data the moment it enters a third-party environment. Custody, auditability, and the ability to govern what happens to patient data mid-inference are not negotiable in a regulated setting. But that constraint, which most platforms treat as a blocker, is actually the clearest illustration of why the architecture has to change for everyone.

At Duke, we deployed intelligence directly on top of their existing clinical data infrastructure. The agents operated as credentialed participants inside Duke's own environment, subject to Duke's access controls, logging against Duke's audit systems, and running against data that never left the perimeter. What we built was not a product that plugged into their stack. It was a governance layer running inside it and integrated into their systems quickly without requiring a heavy lift.

The outcome across high-volume clinical workflows was a step change, not an incremental improvement. Throughput scaled, with tens of thousands of clinical documents containing patient PHI data and other sensitive information being handled safely and securely, all within Duke’s environment. Processing times that had run for days compressed to minutes. The autonomous handling rate exceeded expectations, with the agent managing the overwhelming majority of volume without human escalation. Where humans were needed, the system surfaced exactly the right cases with the context to act immediately. Documented labor savings ran into thousands of staff hours recovered which can now translate to more time spent on patient care.

The core insight is the same one that applies well beyond healthcare: When AI runs inside your governance layer rather than outside it, you eliminate the most expensive part of enterprise deployment. You stop rebuilding access controls in a second environment. You stop paying the latency and egress cost of round-tripping data to inference. You stop creating compliance surface area every time you add a new workflow. And the whole system gets faster, cheaper, more secure, and easier to audit at the same time.

That is what in-place AI actually looks like in production.

The Architecture Shift

Our role as technology leaders has changed. We are not just cloud orchestrators anymore. We are responsible for the governance layer that sits between AI systems and the enterprise data they operate on.

The 2026 mandate is not complicated: We must stop moving the data. The cost is too high and the risk is too real. Build for intelligence to travel to data, not the other way around. Keep your security posture intact. Keep your access controls where they are. Layer the intelligence on top, with governance baked in from the start.

That is the path from AI experimentation to profitable enterprise deployment. Not faster models, but better architecture.