A few weeks ago, I was excited when Claude Cowork came out. Finally, I could sort my iCloud Drive and MacBook. Ten years of personal documents, no taxonomy, sitting in a single folder structure I had given up on.
Then I read the fine print. Cowork made clear that giving it access to sensitive files meant those files would be processed in the cloud. The mainstream alternatives all did the same. For my own data, that was a no. Think Tax returns, Scanned IDs, Healthcare records and Family financial history.
So I built it locally. A small model, a vector index, a search interface. None of it on the cloud. Everything ran on the laptop. Ollama running Qwen 2.5 7B and Qwen 2.5 VL, with nomic-embed-text feeding ChromaDB, served through a FastAPIlocalhost UI. Entirely on a 32 GB M-series MacBook, zero cloud calls.
That night I realized something. The wrong problem is “where does our data live.” The right problem is “what gets to read it.” And almost every enterprise AI privacy strategy I see is solving the first one.
I was actually stumbling into the question every enterprise leader I talk to is going to face within the next two years.
The privacy frame is wrong
When most leaders think about AI privacy, they think about storage. Where does the data live. Who can see it at rest. What the contract says about retention.
That is not the right frame anymore.
Storage in an encrypted cloud you trust is one decision. Processing by a service you do not control is a different one. The moment you point a frontier AI service at sensitive data, the encryption stops at the API boundary. Whatever reads the file to classify, summarize, or search has the file. This distinction is going to redraw the AI buying pattern of the next five years.
What is actually shifting
The dominant assumption in 2026 is that serious AI work happens in the cloud. The frontier models, the infrastructure, and the economics are all there.
That assumption is correct for most workloads. It is wrong for the workloads that matter most to most enterprises. What I call Enterprise Context: regulated data, contractual IP, customer information, strategic decisions.
Something has changed in the last eighteen months that most enterprise leaders have not absorbed yet. Open-weight models in the 7B to 70B range are now genuinely capable for classification, retrieval, and generation against proprietary data. Apple Silicon and equivalent enterprise hardware can run those models at production speeds. And the orchestration tooling around vector databases, embedding pipelines, and retrieval frameworks has matured enough that a competent integration team can stand up a private inference stack in weeks rather than quarters.
The implication is more subtle than “data leaves the cloud.” The default shifts. For workloads that are regulated, contractual, or strategic, local or in-tenant inference becomes the obvious answer. Hyperscalers will sell into both worlds. The enterprises that win will be the ones who learn which workload belongs where.
What enterprises should be building
The right question is not whether to use AI. It is which workloads belong close to the data, and what the architecture looks like when local inference is the default rather than the exception.
The answer is what I call the Enterprise Orchestration layer. A modular layer that sits inside the enterprise tenant and routes workloads intelligently. Frontier cloud for general reasoning. On-tenant for sensitive processing. Edge for latency-critical decisions. What you are building is not a model. You are building the system that decides which model handles what.
Three properties make this layer work. The data does not cross an API boundary you do not control. The underlying models can be swapped as the open-weight frontier moves, without re-platforming. Every inference is logged against the data it touched and the model that ran.
Sovereignty, interchangeability, auditability. Build for those and you own your AI trajectory. Skip them and you keep paying for the same data to be re-uploaded, re-processed, and re-licensed by someone else.
How I advise clients to think about this
Three questions, in order.
One. Which of your workloads are touching data you cannot afford to release? Not data you would prefer not to release. Data where the cost of a leak, a subpoena, or an unintended training signal is unacceptable.
Two. For those workloads, what is the gap between what your current AI vendors offer and what an in-tenant alternative would deliver? In my experience, the gap is smaller than the vendors suggest.
Three. What would it cost to close that gap? Not in licensing. In the operating muscle to run inference, manage models, and govern outputs inside your own walls.
That third question is where most enterprises get stuck. The hardware and models exist. The gap is organizational.
The bet
The enterprises that win the next five years will not be the ones with the biggest cloud AI bills and token costs. They will be the ones who figured out early which workloads belong close to the data, and built the muscle to run them there.
A claims-adjudication model. A contract-review pipeline. A trading-desk research assistant. A reservoir-engineering copilot trained on proprietary subsurface data. These belong inside the enterprise, not on someone else’s infrastructure & model.
This is the conversation I am having with clients across industries. The interesting work in 2026 is not picking a model. It is designing the architecture that decides which model runs where, on whose hardware, against whose data, under whose control.
That architecture may be the enterprise AI strategy of the next five years. The companies that own it will compound their advantage.