Which AI use case first is the wrong question for enterprise AI strategy

The harder and more useful question is which data a system can safely touch today.

The standard opening move for a new Chief AI Officer is a quarter spent stack-ranking AI opportunities: order management, service scheduling, supplier risk, three dozen more, scored on value and feasibility. The board approves the top five. Then the delivery team discovers that the highest-scoring use case depends on a customer record that is correct in one system, partly correct in a second, and absent from a third, with nobody sure which version is authoritative. The use case was never wrong; there was simply no data underneath it safe enough to run on.

Why GenAI operations stall on data, not imagination

Most enterprise AI roadmaps rest on the wrong assumption: that imagination is the limiting resource, and the job is ranking use cases by value to pick the top few. That assumption sits behind nearly every AI opportunity catalog built for a large operator these past two years, yet the evidence says the constraint sits elsewhere. MIT's NANDA initiative found 95% of generative AI pilots at large companies show no measurable profit-and-loss impact; BCG separately reports 74% of enterprise AI projects show no measurable value at all. Neither number is about which use case a company chose, but about what happened once someone tried to build it.

An honest audit of a large operator's own AI catalog usually turns up the same pattern. Across a recent multi-domain review of dozens of proposed use cases inside a global operations organization, only a small fraction had data clean, owned, and current enough for an AI system to touch safely today. Not because the ideas were bad, but because the data behind them sat scattered across unreconciled systems, defined differently by different teams, on refresh schedules no live agent could rely on.

What safe to point AI at means for enterprise AI agent deployment

Safe to point AI at is a more specific bar than most people assume when they hear governance. It is more demanding than a policy document, though nearly every large enterprise already has one. Someone has to name who owns a dataset and stand behind its accuracy. The field an agent reads needs one definition across every system that touches it, not five versions inherited from five reorganizations. And there has to be a trail showing where a number came from and what changed it last, so a questioned answer traces to a source instead of a shrug.

That last part is where enterprise data governance quietly breaks down. Policy is usually espoused clearly: a steward is named, a standard documented, an approval chain living on a slide. Enforcement is different, and in audit after audit it turns out to be manual: a person checking a spreadsheet before a report goes out, not a rule the system enforces on its own. That gap, governance espoused versus governance enacted, is what blocks enterprise AI agent deployment at scale, echoing what IDC's 2026 research names as the real blockers: data quality, integration complexity, change management, and unclear ownership, not model capability.

What an honest readiness map looks like

A readiness map differs from a use-case catalog. Instead of asking what an AI system could theoretically do, it asks, domain by domain, whether the data underneath is trustworthy enough for an agent to act on and auditable enough for a person to check afterward. In one recent engagement, three separate reporting tools inside the same operations function calculated the same core efficiency metric three different ways, and leadership could not agree which number was correct, so there was no way to tell an AI agent which one to trust either. The dispute underneath was about who owned the metric's definition, not data science.

The fix is not waiting for perfect data everywhere; that day never comes. It is running agents first in a sandbox against domains that already pass the readiness bar, every action logged and auditable against a signed-off baseline. That is a narrower, more honest start than a multi-year modernization plan, producing proof, inside weeks rather than years, that an agent's output can be trusted before it earns access to the next domain.

How readiness reorders an enterprise AI strategy roadmap

Once a readiness map exists, a roadmap's sequencing changes on its own. The more useful move is finding the one or two data domains gating the most high-value workflows and fixing those first, rather than chasing the single highest-value use case regardless of what it depends on. A 12-week cycle is long enough to close a real gap in ownership, definitions, or audit trail in one domain, and short enough that leadership sees the fix land before attention moves elsewhere. Future Works, an AI-native transformation engine, structures its engagements around AI agents plus named experts, a pod of senior specialists orchestrating fleets of agents, fees outcome-staked so a third rides on a value target the client's finance team must validate before final payment.

In the first 12-week cycle of a recent program, a Fortune 100 healthcare manufacturer saw measurable working-capital and freight outcomes, verified by its own finance team rather than by the vendor that built the system. That verification, done against the client's own baseline, is what earns trust in an agent's output. It matters more than which model the agent runs on.

The use-case list still has a job: it shows where value could exist. But treating it as the starting document instead of the ending one is why pilots die quietly after the first demo, undone less by a bad idea than by data that was never ready. A readiness map is also a harder sell in a steering committee than five exciting use cases on a slide, since the first funded project is often not the flashiest one on the list. It is, however, usually the one that makes the next four possible.

Future Works starts engagements at the data question, not the use-case list: see how at future.works.