传统企业缺的不是模型，是一套新的操作系统What traditional companies lack isn't a model — it's a new operating system

I recently gave a talk on AI to a room of owners and senior executives. Afterwards, the question I got more than any other was this:

"We bought the tools. We pay for the subscriptions. We've met several vendors. So why does nothing feel different?"

I understand that question completely. It isn't a complaint — it's genuine confusion. The money was spent, the people were assigned, and on paper "we're doing AI" is entirely true. Yet the business runs exactly as it did before.

To answer it, we need to look at something that happened a hundred years ago.

The lesson of the electric motor: the technology was never the hard part

This isn't an anecdote. It's one of the most thoroughly studied cases in economics. In 1990, the Stanford economic historian Paul David published a well-known paper in the American Economic Review called "The Dynamo and the Computer," using the spread of electric power to explain the puzzle of the day: computers everywhere, and no productivity growth to show for it.

The numbers go like this: the light bulb was invented in 1879, yet by 1900 only about 3% of homes had electric lighting, and electric motors accounted for under 5% of mechanical drive in factories. Roughly forty years passed between the invention and the payoff.

Why so slow? Not because the motors were inadequate. Because at first, factories did exactly one thing: they ripped out the steam engine and dropped an electric motor in its place.

The old factory ran on group drive. One steam engine turned a line shaft running the length of the shop floor, and rows of belts and pulleys distributed power to individual machines. Machines had to cluster near the shaft, because the further out they sat, the more power was lost — the layout of the floor was dictated by how power was delivered, not by how the work flowed. Swap in a motor and the shaft is still there, the belts are still there, only the power source has changed. Output, naturally, did not move.

The real turn came in the 1920s, when factories moved to unit drive — a dedicated motor on each machine, no shared shaft. For the first time a plant could be laid out around the production process itself, and buildings could be lighter and more modular. Production lines, flow assembly, the modern factory as we recognize it — all of it starts here.

David makes a specific point about why this took so long: not because the technology was immature, but because the details had to be worked out industry by industry and site by site, and because a generation of factory designers and engineers who understood electricity had to come up first.

The hard part was never the motor. It was redesigning the entire factory around the logic of electricity.

AI sits in exactly this position now. Plenty of companies have bought the tools and pay for the subscriptions and see no return, because they are doing the same thing: plugging AI into the old process.

Which raises the real question — what exactly needs redesigning?

That is what I actually want to talk about. The traditional companies I've seen were never short of a model. Models are everywhere now, and they have been good enough for a while. What's missing is the three things below.

One: a data foundation — so AI has usable input

AI needs something it can consume. Definitions have to be consistent, systems have to be connected. Everyone understands this in principle.

But there is one warning I'd add, and it is the most expensive trap I've seen:

Don't start by building a big central data platform.

I've watched too many companies where the moment AI gets approved, the first move is to launch a data platform project. The reasoning is perfectly sound: govern all the data first, and everything afterwards gets easier. And then? Two years on, the platform is still under construction, the business side has seen no output, and the executive who approved the budget may well have moved on.

The problem is the sequence. "Govern all the data first, then use it" does not survive contact with reality, because the only thing that motivates governance is use. Without a concrete scenario forcing the issue, you have no way of knowing which field actually matters or which definition is genuinely ambiguous — and a table nobody uses will get dirty again no matter how clean you make it.

The right approach inverts it: connect by scenario, govern as you go, one scenario at a time.

If you're doing production scheduling, connect only the data on that path — work orders, equipment status, materials, delivery dates. Just those. Get it running. Once it runs, the bad data surfaces on its own, and what you fix then are real problems.

So the question becomes: which scenario first?

I have exactly one criterion: pick a scenario where you can state the KPI today. Not "improve efficiency" — a number you could type into a cell. What is on-time delivery for scheduling right now, and what do you want it to be?

Why that criterion? Because without a KPI there is no finish line. You have no standard for when the data is clean enough, and governance quietly turns back into an endless engineering project. A scenario with a stated KPI tells you the opposite: which tables to connect, to what precision, and when you can stop.

Two: an org structure — so someone owns the outcome

The second thing is people.

First, you need someone doing this full time, not moonlighting from IT. Part-time means it permanently ranks below "keep the systems up," and early-stage AI delivery needs someone thinking about it every day.

Second — and this is the part most easily overlooked — AI delivery requires three responsibilities that did not previously exist.

To be clear: I'm talking about responsibilities, not headcount. Companies with the resources can staff each one; companies without can have one person carry two or three. Either works. But if any one of the three goes unclaimed, the project dies there.

• AI product manager: defines what this AI is actually solving and what "good" looks like. Without this role, the requirement is whatever the boss said in one sentence, and what gets built goes unused.
• AI engineer: connects models, data, tooling and business systems. Note this is not the same job as traditional backend development — it sits closer to orchestration than to coding.
• AI BP: the one I consider most critical, and the least often considered at all.

What is an AI BP? Everyone knows the HR business partner and the finance business partner — embedded in a business unit, fluent in both the specialty and the business, translating in both directions. AI needs someone doing the same job: turning the language of the business into requirements AI can act on, and turning AI's capabilities back into something the business understands.

Why does someone have to do this? Because when the business says "I want it to be smarter," the AI team can't act on it; and when the AI team says "this scenario needs structured labeling," the business can't parse it. There's a wall between the two sides, and with nobody in the middle the project dies against it. That wall is the real bottleneck in most traditional-enterprise AI work — a hundred times more consequential than which model you pick.

Whether it deserves its own headcount depends on the company. For most mid-sized firms the realistic answer is that the AI product manager covers it, since that person has to live with the business anyway. Splitting the role is a resource question; the work is the same work. So the thing to watch for isn't "we don't have an AI BP role" — it's that nobody has claimed the work.

Last comes data ownership: every important data domain needs a clearly named owner, and that owner sits on the business side.

This isn't my invention. Data governance has long separated the responsibility into three layers: who decides (sets definitions, settles disputes), who maintains day to day, and who runs the platform and access — the first two on the business side, only the third in IT. The internationally used DAMA framework draws it this way, and the most thorough implementation I know of in China is Huawei's: every category of data gets an owner, drawn from the business unit, paired with the principle that whoever produces the data answers for its quality.

Which clears up a common misreading: it isn't that IT doesn't handle data — IT handles the other half. IT can guarantee the number is stored, not lost, not accessed by the wrong people. But what it ought to be — what this field actually means, whose definition wins when two departments disagree — IT has no authority to adjudicate, and shouldn't.

There's a very practical test: ask "why don't these two systems agree on this metric," and watch who everyone in the room turns to. If they all turn to IT, that data domain has no real owner — only someone to blame.

One aside, since it's the concern I hear most: at this stage AI is mostly displacing repetitive entry-level white-collar work — data entry, basic copy, junior analysis. For the overwhelming majority of roles it augments rather than replaces. So the new responsibilities above often aren't about hiring more people but about rearranging the people you have — putting a strong business person on the AI BP work usually pays off faster than hiring one from outside.

Three: a method — so insight becomes action

The third is the vaguest and the most fatal.

Once AI produces an insight: who turns it into an action? Who decides? How do you verify there was any gain?

If nobody picks this up, everything upstream was wasted.

I've seen beautifully built forecasting models — high accuracy, excellent dashboards — that nobody opened after three months, because not one person's work had changed on account of the model. What it computed never became an instruction.

So the third thing is a method: running plan → execute → report back → review as a genuine closed loop.

Of the four, "report back" is the one most often dropped. The system made a recommendation — was it acted on? What happened? Did that result make it back into the system? Without the report-back the loop is broken, and the model never gets more accurate either.

On the other two: planning and review both require deep business participation.

• Planning is what keeps AI on target — with the business in the room, you don't end up with something technically impressive and operationally useless.
• Review is really where the next round of priorities gets set — what worked, what didn't, what's next.

Plenty of companies turn the review into an upward report, which wastes it. A review should produce a new to-do list, not a slide deck.

Together, these three are an operating system

A data foundation, an org structure, a method.

For a company to genuinely run on AI, what it needs is not a particular model or tool or vendor, but these three in place at the same time.

AI isn't installing a feature in your company. It's installing a new operating system. Miss any one of the three and it doesn't matter how strong the model is.

This also explains why the three traps from my previous piece keep recurring:

• The AI project becomes a political mandate — what's missing is org structure: nobody genuinely accountable for the outcome, only someone issuing the instruction.
• No baseline, no way to say whether it worked — what's missing is method: without report-back and review, there's no gain to show.
• Chasing whatever technology is fashionable — what's missing is the discipline of the data foundation: starting from a buzzword instead of from a scenario with a stated KPI.

The three traps are symptoms. These three missing pieces are the cause.

Finally: six questions to run past yourselves

I'll leave you with six questions. Take an hour behind closed doors with your core team — the ones you can't answer are the gaps you need to close:

1. Can you name one AI scenario currently in flight, along with its KPI and its pre-launch baseline?
2. Is the data that scenario needs already connected, or is it "we'll have it once the platform is built"?
3. Do you have someone on AI full time, or is it hanging off IT as a side duty?
4. Between the business and the AI team, is there one person fluent in both?
5. For your most important data domains, who owns each one? When two systems disagree on a definition, who has the authority to decide — the business owner, or does it end up pushed to IT?
6. The last insight your AI produced — did it ever become an instruction anyone actually carried out?

If three or more of the six go unanswered, this isn't a model problem, and it isn't a budget problem.

The operating system hasn't been installed yet.