AI transformation runs at the speed of data readiness

Every company running an AI transformation has met the same bottleneck. The person hired to drive it can map a workflow, pick the model, and sketch the agent in a week. Then the project sits. Not because the design is wrong, but because the business cannot supply trusted, governed data to run it on. The workflows are designed faster than the data can be made ready. That gap is the program.

Private equity sees this more clearly than most, because it keeps score in public. A buyout creates value three ways: grow revenue, expand margins, expand the multiple a buyer will pay at exit. AI is unusual in that it pulls on all three at once, which is why every operating team now has an AI agenda. It is also why the honest ones have quietly become data teams.

All three value levers now run through AI

Across buyouts, roughly half the value created between entry and exit comes from revenue growth, a seventh from margin expansion, and a third from the multiple. Map an AI program onto those bars. Workflows that sharpen pricing, retention, and sales velocity pull the revenue lever. Workflows that move repetitive work up the judgement curve pull the margin lever. And a demonstrable data asset, canonical models, governed access, an audit trail an acquirer can inspect, pulls the multiple, because the buyer is pricing what they can build on, not just what you earned.

The ideas are not scarce. Ask any operator for AI use cases and you will fill a wall. What is scarce is data that is ready to run them, and that scarcity sets the pace of the whole program. Which raises the real question: if data readiness gates all three levers, how do you measure whether it is working?

Put simply: buyout value creation decomposes into revenue, margin, and multiple, and AI workflows pull all three. The binding constraint on every one of them is whether the data is ready. Fund the constraint, not another workshop of use cases.

One AI program, two scoreboards

An AI program produces two different kinds of value on two different clocks, and grading both on one scoreboard kills the slower one. The AI dividend is the fast clock: workflow wins that land in EBITDA within quarters, priced retention, faster sales cycles, cheaper operations. The data moat is the slow clock: the platform underneath, and it should be measured on its own terms. Time-to-production for the first AI workflow, then for each one after it, in days. The share of AI answers that run through a governed layer with access controls and an audit trail, rather than around it. And how much capability the operating team keeps when the experts leave.

The failure mode is predictable. The platform gets judged by the dividend's clock, shows nothing after two quarters, and gets cut, taking every future workflow's speed with it. The dividend pays for the program. The moat is what the program leaves behind.

Put simply: track the AI dividend in EBITDA on a quarterly clock, and track the data platform on its own scoreboard: time-to-production per workflow, share of answers on governed data, capability retained after handoff. Never grade the moat by the dividend's clock.

The stakes set the readiness bar

"Ready" is not one bar. An internal copilot with a human in the loop tolerates a mostly-right answer. Knowledge search needs citations and access control. A customer-facing workflow adds monitoring, guardrails, and PII handling. A regulated decision needs full lineage and human sign-off, because the wrong answer is a fine, not a typo. The readiness bill scales with what the answer touches, which is why regulated industries feel AI as both their hardest problem and, once solved, their deepest moat: the bar that slows you down is the bar competitors also have to clear.

Wherever a workflow sits on the ladder, four questions are non-negotiable before it goes to production. How do you know the agent sees a unified view of the entity it is reasoning about? Can it show which data it touched on the way to an answer? How do you know it cannot read data it is not authorized to read? And if it writes back, what stops it from polluting the warehouse with its own outputs, compounding misinformation that later answers inherit? If the platform cannot answer all four, the workflow's rung does not matter. For which projects deserve the climb at all, the What deserves AI test still applies.

Put simply: match the readiness bar to the stakes, from copilot to regulated decision, and refuse production until you can answer four questions: unified view, show your work, authorized access, and no write-back pollution. High-stakes verticals pay the steepest readiness bill and earn the deepest moat.

Put a warehouse between the AI and your systems

Most first AI architectures are a hub and spoke: the agent in the middle, wired straight into the CRM, the ERP, the app database, the ticket system. It demos well and degrades badly. On every question the AI must reconstruct a unified picture from raw systems in real time, or proceed without one. That burden is exactly what models are worst at, long-horizon plumbing, so the hub is slow, expensive, error-prone, and ungoverned, and every new spoke makes it worse.

The alternative is boring and proven: put a warehouse in the middle. Pipelines ingest the systems, transformations run ahead of time as version-controlled code, and the output is a canonical model of the business that the AI queries through a governed layer, access-controlled and audit-logged. The intelligence is not less ambitious; it just stops doing plumbing at question time. Ahead-of-time modeling is what shifts outcomes from probabilistic to deterministic, the same stack of non-negotiables that made analytics trustworthy, now doing the same for agents. The model was never the moat. The modeled data is.

Put simply: replace AI-to-everything integrations with sources, pipelines, canonical models, then AI. Do the joining, cleaning, and defining once, ahead of the question, in version-controlled code with tests, access controls, and audit logs. The AI should query one governed layer, never five raw systems.

Building is one step of six

The engagement that makes this durable has six steps, and only the third is building. First, map the pain and the technical gap: where the workflow hurts, what the risk is if the AI gets it wrong, and whether a data platform exists to attach to or a minimum one must be stood up. Second, smoke-test the risk: find the shortest path to proof-of-life, starting with whether the data even exists in raw form, so bad projects die while they are still cheap. Then build, with documentation. Fourth, hand off to a named owner on the operating team, someone accountable for the pipelines end to end, because source data drifts and somebody has to notice. Fifth, measure what actually moved, in numbers and in the operators' own words. Sixth, codify what you learned so the next engagement starts further ahead.

Two steps of disconfirmation, one build, three steps of transfer. Teams that jump straight to the build ship workflows that decay the day the experts leave, the pattern you cannot hand off. The build is the easy sixth. The other five are why it is still running in a year.

Put simply: spend the first two steps trying to kill the project cheaply, build once, then spend three steps making it somebody's job to keep alive: a named data owner, honest measurement, and a written playbook. If a partner's process is all build, the decay is scheduled.

The whole program compresses to one sentence: treat data readiness as the unlock, not the cleanup. The companies that treat it as deferred maintenance will keep designing workflows they cannot run. The ones that treat it as the asset will find the workflows almost easy, this year's in EBITDA, and the platform underneath quietly compounding into the thing the next buyer pays up for. The cleanup, it turns out, was the investment.