McKinsey’s new report on the AI operating system gives CEOs a rule that sounds simple: own the context, and rent or replace the technology.
The reasoning is sound. What makes a company distinctive is its institutional knowledge, the definitions, rules, relationships, and judgment built up over decades. Models will keep changing. Vendors will rise and fall. If that knowledge is trapped inside one vendor’s environment, the company has quietly handed over the thing an AI operating system is supposed to protect. The report goes further and warns that companies which let model providers train on their data may slowly lose their enterprise’s brain to the models themselves.
Two pages later, the same report gives a second rule that pulls the other way. Limit operating system sprawl. The point of an AI operating system is an integrated view of the business, and that view falls apart if every function builds its own system or every use case gets its own stack. McKinsey suggests most enterprises should allow no more than one to three.
For a global OEM with a central architecture team, those rules fit together. The report describes one that standardized on open formats for its architecture and ontologies, then built the system itself. For a $500 million manufacturer or a regional insurer with an IT team of twenty, the two rules look like a trap. Avoiding vendor lock-in seems to mean assembling the stack from parts. Avoiding sprawl seems to mean buying one integrated platform. You cannot do both.
I think you can, and the reason is the most useful idea in this half of the report.
Integration and ownership are separable. Lock-in does not come from buying an integrated platform. It comes from where your context lives, what form it takes, and who controls it. Mid-enterprise companies should buy integration and insist on ownership, rather than giving up one to get the other.
The premise worth questioning
The premise behind most AI architecture debates is that independence requires assembly. If you want to stay in control, choose the best component for each layer, connect them yourself, and keep every piece replaceable. An integrated platform, in this view, is a convenience you pay for with your freedom.
That premise deserves more credit than vendors usually give it.
The case for building it yourself
Enterprise software has earned its reputation. A generation of companies customized ERP systems so deeply that upgrades became multi-year programs. Data warehouses stored information in proprietary formats and charged to move it out. Marketing clouds made exit so painful that renewal was not really a decision. Leaders who lived through those contracts are right to be suspicious of anyone promising a complete platform.
The AI market adds a new reason for caution. Models are improving and changing price every few months. A component that was the best choice in January can be the second-best choice by June. Assembling the stack yourself means you can swap the model, the vector database, or the agent framework as the market moves, without waiting on a vendor’s roadmap.
McKinsey’s case studies point in this direction too. The US manufacturer in the report did not want a black box embedded in a vendor platform. It built on its existing technology, designed every component to be swappable, and wrapped the whole thing in a governance harness of its own. That is a credible model, and it worked.
If you have the team to do it, building it yourself is a defensible choice.
That last condition is where the argument starts to break down.
The lock-in nobody budgets for
Assembled stacks do not eliminate lock-in. They move it.
In an assembled stack, the context ends up scattered across components. Some business definitions live in the semantic model of a BI tool. Some live in the prompt templates of an agent framework. Some are embedded as chunks in a vector store, stripped of the relationships that gave them meaning. Access rules are reimplemented in three places and drift apart. The glue holding it together is integration code written by a small number of engineers.
That is lock-in, just to a different landlord. Instead of depending on a vendor, the company depends on the people who understand how the pieces fit. When two of them leave, the context is still technically owned by the company, but nobody can find it, change it safely, or move it.
Assembled stacks also tend to multiply. Finance builds one pattern, operations builds another, and a promising pilot in customer service builds a third. Each makes sense locally. Together, they produce exactly the sprawl McKinsey warns against, and the integrated view of the business never arrives.
The manufacturer in the report succeeded because it had the people to avoid both problems. It connected about 100 data sources and had its first phase running in roughly 16 weeks with a team dedicated to the work. Most mid-enterprise companies do not have that team, and the ones that do would rather point it at business problems than at plumbing.
Where ownership actually lives
If assembly does not guarantee ownership and integration does not prevent it, the question becomes what ownership actually consists of. In my experience, it comes down to five tests. Each one applies to any platform, built or bought.
Does your data have to move? If a platform requires copying data into its own storage before it can work, every year of use raises the cost of leaving. McKinsey’s guidance is to leave data where it already lives and connect it to the semantic layer. A platform that reads from source systems in place leaves the exit door where it was.
Is your context legible and portable? Business definitions, relationships, and rules should exist as explicit, inspectable objects that the company can read, review, and export. If they exist only as weights inside a model or as behavior buried in code, the company does not own them in any practical sense.
Can you change models without rebuilding? The report recommends sourcing models from multiple providers and choosing among them by problem. That only works if the context sits above the model rather than inside it. Swapping a model should be a configuration change, not a migration.
Does anyone else learn from your data? This is McKinsey’s sharpest warning. Every contract in the stack should make clear that your data and your context are not training someone else’s product.
Who controls access and governance? If per-user permissions, policies, and audit trails live in the platform, the company should set them, see them, and be able to prove what happened. Governance that only the vendor can inspect is not governance the company owns.
None of these tests asks whether the platform is integrated. A well-designed integrated platform can pass all five. A carefully assembled stack can fail three of them without anyone noticing.
The economics belong inside the system
The report makes a point about cost that most AI strategy discussions skip. Token prices have fallen by more than 95 percent, yet AI spending at many companies has more than tripled. Cheaper intelligence has not produced cheaper AI.
McKinsey’s explanation is that cost now depends on choices made deep in the system: which model handles a task, how the work is structured, how much reasoning it consumes, and how much human review it needs. The cheapest model is not always the cheapest outcome, because a low-quality answer that leads to a bad decision can cost far more than the tokens saved. The report’s recommendation is to build these economics into the operating system itself, so leaders can see the real trade-offs behind each decision.
This is another place where assembly and sprawl quietly hurt. When every team picks its own models and routes its own requests, nobody can see total cost per business outcome, and nobody can make a deliberate trade-off between a fast, cheap model and a slower, more careful one. Cost becomes something finance discovers in an invoice rather than something the business manages.
An operating system that sits between every request and every model can do better. It can route routine work to efficient models, send high-stakes work to stronger ones, have one model check another where the risk justifies it, and report what each use case actually costs. Those are only possible when one layer sees all the traffic.
What this requires architecturally
At Datafi, we designed the platform around the separation of integration and ownership. It is integrated where integration creates value and open where ownership matters.
Data stays in the customer’s environment. Datafi reads live from source systems, including ERP, TMS, policy administration, on-premises databases, and file shares, without copying or migrating them. No AI tool reaches that data directly; every connection runs through Datafi, with per-user, row-level access checks so an AI never sees more than the person asking.
The business context layer holds definitions, metrics, and relationships as explicit objects the customer defines and can inspect, rather than knowledge hidden inside a model. That context sits above the model layer, which is why people can keep working in Copilot, ChatGPT, Claude, or Gemini, and why organizations can also bring their own or fine-tuned models. Changing models does not mean rebuilding what the company knows.
Control Tower governs every connection, logs every question, answer, and agent step, and provides the observability and token optimization that let leaders see what AI is doing and what it costs. Studio and Runtime handle the parts that would otherwise become custom glue: building apps and agents, and coordinating multi-step work across systems.
The result is one operating system rather than three, which addresses McKinsey’s sprawl warning, and a context the customer owns rather than rents, which addresses the lock-in warning. It is also something a mid-enterprise team can stand up on live data in days, not a program that needs a dedicated architecture group for a quarter.
The question to ask every vendor, including us
McKinsey frames this as a CEO decision, and it should be. The choice of AI operating system will shape how the company’s knowledge is stored and governed for years.
The most useful thing a CEO can do is stop framing the decision as platform versus best-of-breed. That framing hides the real risk. Ask instead whether the company’s context will be legible, portable, and governed by the company, whatever architecture is chosen. Ask how many AI operating systems the organization will end up with in three years if each team keeps choosing for itself. Ask who will be able to see the cost of each decision the system helps make.
Run the five ownership tests on every option, including Datafi. Any vendor that cannot answer them clearly is asking you to rent your own brain.
In the final post in this series, I turn to the part of McKinsey’s report that will matter most to how companies actually run: management by intervention instead of by calendar, and organizations with far fewer layers. I argue that none of it is safe until governance becomes infrastructure, because you cannot delayer what you cannot govern.
Datafi is the operating system for business AI. We help mid-enterprise organizations unify their data, deploy governed AI agents, and deliver measurable outcomes in weeks rather than years, without migrating off the systems that already run the business.
The Second Brain: Bringing the AI Operating System to the Mid-Enterprise
Part 1: Why AI Adoption Isn’t Becoming AI Value
Part 2: Own the Context, Rent the Stack
Part 3: You Can’t Delayer What You Can’t Govern
Written by Vaughan Emery, Co-Founder & Chief Product Officer at Datafi
Source: “The AI operating system: A new way for CEOs to run the enterprise,” QuantumBlack, AI by McKinsey, October 2026.
