A Data Strategy for AI: What to Decide Before You Build

Most organisations that try AI discover the same thing: the model is the easy part. The difficulty lies in finding the right data, getting access to it, cleaning it, proving it may be used and keeping it current. A data strategy for AI addresses these problems deliberately instead of project by project.

This guide is practical rather than theoretical. It assumes you have AI ambitions and some data, and want to know what to decide before building. For choosing the platform that stores the data, see our guide to data lakes, warehouses and lakehouses.

Start from use cases

A data strategy that begins with “collect all our data” usually stalls. Start instead with the two or three AI use cases most likely to create value, and let them define the data needed.

How generative AI changes the picture

Traditional machine learning relied mainly on structured, labelled data. Generative AI applications rely heavily on unstructured content — documents, emails, transcripts, knowledge bases — usually through retrieval rather than training. That shifts the priorities:

• Content quality and currency matter as much as data volume.
• Document permissions must be carried into retrieval so assistants respect who can see what.
• Chunking, metadata and versioning become data engineering tasks.
• Evaluation sets of questions and expected answers become essential data assets.

Assess each data source

Governance that makes data reusable

• Data owners for each domain who decide definitions, quality expectations and access.
• A catalogue recording datasets, descriptions, owners, sensitivity, lineage and permitted uses.
• Quality checks in pipelines: freshness, completeness, validity and uniqueness.
• Access control by role and purpose, with masking or de-identification of sensitive fields.
• Retention and deletion rules that flow through to derived datasets, embeddings and model training data.
• Use approvals for new AI purposes, linked to privacy and responsible AI reviews — see our guide to responsible AI in practice.

Pipelines for AI

AI systems need several data flows, each with different requirements:

Collecting and creating data

• Use what you have, cleaned and joined across systems.
• Instrument products to capture outcomes — whether a suggestion was accepted, whether a case was resolved.
• Label efficiently with clear guidelines, double review for a sample and active learning to focus on uncertain cases.
• Use synthetic data carefully for testing and rare cases, never as a substitute for validating on real data.
• License external data where needed, checking terms for AI use.

Worked example: a B2B distributor

A hypothetical distributor wants an assistant for its sales team and better demand forecasts.

• Assistant: product specifications live in a PIM, pricing in the ERP and application notes on shared drives. The strategy assigns a content owner, removes duplicate documents, adds metadata (product family, region, version) and builds a retrieval pipeline with permission filters. An evaluation set of 150 real sales questions is created with the sales operations team.
• Forecasting: sales history is good, but promotions were tracked in spreadsheets. The strategy reconstructs two years of promotion history, introduces a promotion calendar in the ERP and adds quality checks for missing product hierarchy codes.
• Shared foundation: a customer and product master with consistent identifiers, a data catalogue and quality dashboards benefit both use cases — and the next ones.

Roles and responsibilities

Common mistakes

• Boiling the ocean: a multi-year data programme with no AI use case delivered along the way.
• Ignoring unstructured content: treating documents and knowledge bases as out of scope, then discovering they are what the assistant needs.
• No evaluation data: shipping AI features without a fixed test set, so quality cannot be measured or protected.
• Permissions as an afterthought: building retrieval indexes that ignore who may see which documents.
• One-off cleaning: fixing data for a pilot without fixing the process that created the problems.
• Unclear rights: using customer or third-party data without confirming contracts and consent allow it.

Making the case for data investment

Data foundations compete with visible features for budget. Link them to outcomes: show how missing promotion history limits forecast accuracy, how outdated articles produce wrong assistant answers, or how inconsistent customer IDs block churn analysis. Fund foundations through the first use cases that need them, and reuse them for the next ones.

Measuring data readiness

• Share of priority sources with a named owner and catalogue entry.
• Data quality scores for fields critical to each use case.
• Time to make a new approved dataset available to an AI project.
• Evaluation set size and coverage for each AI feature.
• Share of AI outputs linked to production outcomes.

A 90-day plan

1. Weeks 1–3: choose two or three use cases; inventory and score their data sources; identify legal and privacy constraints.
2. Weeks 4–8: fix the most critical gaps; assign owners; set up the catalogue and quality checks for those sources; build evaluation sets.
3. Weeks 9–12: deliver a pilot for one use case on governed data; measure results; document what to reuse.

Frequently asked questions

Do we need a data warehouse before starting AI?

Not necessarily. Many generative AI pilots start from document sources. You do need governed access, quality checks and clear ownership for the data each use case uses.

How much data does an AI project need?

It depends on the approach. Retrieval-based assistants need good coverage of relevant content rather than volume; predictive models need enough historical examples of the outcomes you want to predict.

Can we use customer data to train or improve AI?

Only where your legal basis, contracts and notices allow it. Check privacy obligations and customer agreements before use.

Who should own the data strategy?

A senior sponsor with data and business owners for each domain. AI teams consume the strategy; they cannot deliver it alone.