Data Strategy for AI

Before reading on, make a prediction. Over two years, the data-quality researchers Tadhg Nagle, Thomas Redman and David Sammon asked 75 executives to run a simple test. Each one gathered the last 100 records their own team had created, chose 10 to 15 attributes that mattered, and marked every obvious error. A record counted only if it had no errors at all. The researchers set the bar for “acceptable” at 97 clean records out of 100. What share of the scores do you think cleared it? Write your number down.

The answer was 3 percent. That figure counts teams’ scores. Counted record by record instead, 47 percent of newly created records had at least one critical error on average¹.

The sample was small and self-selected, so treat the exact figures with care. The direction is hard to argue with. Every one of those teams had data. It lived in their systems and fed their reports. Very little of it would have passed if an AI system had been asked to act on it at scale.

Having data is not enough

The argument of this chapter fits in one sentence. For enterprise AI, having data is not enough. The advantage comes from usable data, for the outcomes the strategy has already chosen.

Usable means four things at once: the right data, with the context that gives it meaning, reachable by the right people and systems, under the right controls. Notice what the sentence leaves out. It does not say build a data lake, or train a model on everything the company owns, or make all enterprise data perfect before starting. Those are programs. A strategy chooses.

The reason data has become the binding constraint is simple. Capable models can now be bought, rented or swapped, and your competitors have the same access you do. What they cannot buy is your operating history, what it means and who is allowed to use it. Marco Iansiti and Karim Lakhani, describing the firms that run on AI, put the data pipeline first among the four components of what they call the “AI factory”, ahead of the algorithms themselves². The model is the visible part. The data is the part that has to be built.

Most large organizations already have an enterprise data strategy: platforms, analytics, master data and governance, usually run by a chief data officer. A data strategy for AI should not compete with it. It adds the requirements AI brings, such as company knowledge held in documents, the context that makes records interpretable, the data used to test AI systems, and rules for what an AI may reach. Starting a separate “AI data platform” by default duplicates the foundation and splits the people who know it best.

Start from the outcome, not the data estate

One of the most expensive questions in this field is “How do we make all our data AI-ready?” It sounds responsible, and it turns into a multi-year modernization program with no customer.

A better question runs in the other direction, starting from an opportunity the AI strategy has already chosen. How those opportunities are found and ranked is the work of Finding Strategic AI Opportunities; this chapter takes the shortlist as given.

The list that results is short, specific and fundable, which is the difference between a strategy and a program.

Starting from the outcome also tells you how good the data has to be. That turns out to be the most useful thing a data strategy can know.

Data that exists is not data you can use

Status reports about data usually stop at existence: the data is in a system, it shows up in a dashboard. For an AI system, existence is only the visible tip. Whether the data is usable depends on questions that rarely appear in a status report.

Access asks whether the systems that need the data can reach it, through a supported route rather than an export someone runs by hand. Quality asks whether it is accurate and complete enough. Freshness asks whether it is current enough for this use: a weekly load is fine for planning and useless for a same-day decision. Context asks whether a system, or a new employee, can tell what a value means. Lineage asks where the data came from and what happened to it on the way. Permissions ask whether it may be used for this purpose, by this person. Ownership asks who is accountable when any of the others fail.

Quality deserves a closer look, because it is where well-meant programs go wrong. In a study still cited three decades later, Richard Wang and Diane Strong asked data users what quality meant to them. Their answer was that quality is fitness for use, and that its dimensions fall into four groups: intrinsic qualities such as accuracy, contextual ones such as relevance and timeliness, representational ones such as interpretability, and accessibility³. The contextual group is the one that matters most here. The same data set can be good enough for one purpose and unacceptable for another. For example, customer addresses that are 90 percent correct may be fine for regional demand forecasting and dangerous for automated contract notices.

That is why “clean all the data first” is the wrong instruction. Set the minimum bar the chosen use case needs, test against it, and improve the data where the value requires it. Why quality matters more than sheer volume in how models learn is covered in Data, Models and Compute; the strategic point is that the use case, not a general standard, sets the bar.

Rate the gap: green, amber or red

Once each chosen opportunity has a list of the data it needs, every item on the list gets a simple rating. The scale is deliberately coarse: its job is to make the constraint visible to an executive committee.

Two rules keep the rating honest. First, rate against the use, not in general: “the customer master is amber for the service assistant” is useful, while “the customer master is amber” starts an argument. Second, a red rating is not always a funding request. Sometimes the cheapest response is to change the scope, for example by launching first where the data is already good enough, so that the gap shrinks to something the team can fix.

The output is a short list of gaps, each tied to the value it blocks. Funding the gap that blocks the most value first is the core discipline of a data strategy for AI.

Records, documents and the test set

Enterprise data comes in three broad shapes: structured records such as transactions and sensor readings, logs and events, and unstructured material such as contracts, manuals, emails and recordings. Prediction and optimization systems still run mostly on the first two. Generative AI has made the third far more valuable, because so much company knowledge lives in documents that no system could use well before.

Documents bring their own version of the iceberg. A policy manual exists in five versions, and only one is current. A contract was amended by a letter stored somewhere else. For generative AI, company knowledge usually reaches the model through retrieval, where the system finds relevant material and passes it to the model with the question; RAG and Enterprise Knowledge explains how that works. The strategic consequence is that retrieval can only find what is findable, current and clearly authoritative. Deciding which version of each document counts is data work, and someone has to own it.

One more data set belongs in every AI data strategy, and it is often the one missing: evaluation data. These are representative questions or cases, the answers or outcomes a good system should produce, and the edge cases and known failures it must handle. Without them, nobody can show that a system works, compare a cheaper model with the current one, or notice when quality slips. An evaluation set is a strategic asset that improves with every incident. Treat it like one, with a named owner and a budget.

Owners, products and permissions

Data becomes usable when someone is accountable for keeping it usable. The data-management profession has said this for years: the DAMA-DMBOK, the field’s standard reference, treats ownership and stewardship of data domains as foundations of governance, not extras⁴. Zhamak Dehghani’s data mesh pushed the idea further, arguing that the business domains that create data should own it and serve it to others as a product⁵.

You do not have to adopt the whole architecture to use the core idea. Treat each data set that a chosen AI opportunity depends on as a product: a named owner in the business, defined users, stated quality expectations, documentation and a lifecycle. Set standards centrally and leave meaning and ownership in the domains. The AI team consumes these products; it should not quietly become the owner of every domain’s data because it was the first to need it. The shared tooling that serves many teams was the subject of AI Platform Strategy.

Permissions complete the picture. The fact that a system holds data is not permission to use it for a new purpose, and an AI assistant must not show people information merely because it can reach it. How retrieval respects each user’s rights is covered in Privacy and Confidential Data. At the strategic level, purpose is the question to settle early, because it can turn a green data set red overnight.

Story: three years of sensor data at a copper mill

Take the position of a mining executive in 2018. Freeport-McMoRan, one of the world’s largest copper producers, wanted more copper from its mines in North and South America. The conventional route was to build capacity: more crushing equipment, haul trucks and large shovels. By the company’s later estimate, adding about 90,000 tonnes of copper a year that way would have cost 1.5 to 2 billion US dollars⁸.

At its Bagdad mine in Arizona, the concentrating mill had been collecting data for years from thousands of sensors. Imagine three proposals on your desk. The first funds the capacity expansion. The second launches a company-wide program to clean, consolidate and modernize plant data before attempting any analytics. The third picks one mill and one outcome, throughput, and tests whether the data the mill already has can support it. Decide before you read on.

Freeport chose the third route. From 2018, metallurgists, engineers and operators at Bagdad worked with data scientists on three years of data from the mill’s sensors⁸. The data did not need to be made perfect first. It needed context, and the people who ran the mill supplied it. The analysis showed that the mill was processing seven distinct types of ore, and that its standard control settings did not match the properties of all of them. Adjusting settings for each ore type, including the acidity in the flotation tanks, raised Bagdad’s output by about 9,000 tonnes of copper a year⁹.

Then Freeport scaled what had worked. In its results for the end of 2019, it announced a rollout across its North and South American operations, with estimated extra production of about 100 million pounds of copper in 2021 and about 200 million pounds in 2022, for capital of roughly 200 million US dollars¹⁰. Its chief executive, Richard Adkerson, called 200 million pounds an aspirational goal, to be reached “with very little capital investment”⁸. The Bagdad gain is a reported result. The rollout figures are the company’s own targets at the time, set against a conventional expansion costing several times as much; this chapter found no published figure for what the rollout itself delivered.

Three lessons carry beyond mining. The data already existed; what made it usable was a chosen outcome and the context that only operators and metallurgists could add. The scope was one mill, which kept the data question small enough to answer. And the investment in data followed the value: the rollout was funded after one site had shown what the data was worth. Not every data estate is as tidy as a mill’s sensor history, and documents scattered across ten systems are harder. The sequence still applies.

What this means for leaders

A data strategy for AI is not a separate plan sitting beside the AI strategy. It is the AI strategy’s list of chosen opportunities, translated into the data each one needs and the gap that blocks it. That makes it short, specific and fundable. Leaders should expect to see the gaps ranked by the value they block, a named business owner for every data set that matters, an evaluation set for every serious AI system, and the purpose of each use settled before the build begins. They should be wary of any plan whose first milestone is “all data ready”.

Check yourself

1. We need a complete, modernized data platform before we can start with AI.MythFact
2. A data set can be good enough for one use and unacceptable for another.MythFact
3. If a system already holds the data, an AI system may use it.MythFact
4. In a two-year study of 75 executives, only 3 percent of teams’ data-quality scores met the acceptable bar.MythFact
5. The AI team should own the data that its systems use.MythFact
6. Freeport’s copper gains at Bagdad came from cleaning all its plant data before any analysis began.MythFact

Reflection: what is below your waterline?

What comes next

Data and platforms do not build, run or govern anything on their own. Every step in this chapter, from rating a gap to owning an evaluation set, depends on people with the right skills in the right places. The next chapter, AI Talent and Capability Strategy, asks which capabilities to build inside the organization, which to source, and how leaders should plan the workforce their AI strategy needs.