Data Readiness: Why Most Businesses Aren't Ready for AI Yet

Most businesses that want to use AI are not held back by the AI.

The models are widely available, increasingly capable and, for many tasks, inexpensive. What holds them back is their data: customer records duplicated across three systems, product information that differs between the website and the warehouse, years of documents in shared drives with no clear owner, and permissions so loosely managed that an AI assistant could surface salary details to anyone who asks.

Data readiness is the degree to which your data is accessible, accurate, well organised, properly governed and connected enough for AI to use it safely and produce reliable results. It is not about having enormous volumes of data or a sophisticated data platform. It is about whether the specific data a particular AI use case depends on is fit for that purpose.

The good news is that you do not need to fix all of your data before starting. The businesses that succeed with AI typically pick a specific, valuable use case, prepare the data that use case needs and expand from there. This guide explains what AI-ready data means in practice, why so many AI projects stall on data problems, how to recognise the warning signs, how to assess your own readiness and how to make progress without launching a multi-year data programme.

What AI-ready data actually means

There is no universal standard for AI-ready data, because readiness depends on what you want the AI to do. A system that forecasts demand needs consistent historical sales data. A customer service assistant needs accurate, current policy documents and product information. A tool that scores sales leads needs reliable records of which past leads converted. The same organisation can be well prepared for one of these and completely unprepared for another.

It helps to distinguish between two broad kinds of AI use.

Predictive and analytical AI, such as forecasting, risk scoring, recommendations and anomaly detection, learns patterns from structured data: rows and columns in databases, spreadsheets and business systems. Here, readiness depends on whether you have enough relevant historical data, whether it is accurate and consistently defined, and whether it reflects the situations the model will face in future.

Generative AI, such as assistants that answer questions, draft documents or summarise information, relies heavily on unstructured content: documents, emails, wikis, contracts, support tickets and chat histories. Most business applications of generative AI do not train a new model. Instead, they retrieve relevant content from your own sources and give it to a general-purpose model as context, an approach often called retrieval-augmented generation. Readiness here depends on whether the right content exists, is current, is findable and is protected by the correct access permissions.

Across both kinds, AI-ready data tends to share a few characteristics. It is accessible to the systems that need it. It is accurate and complete enough for the task. It carries enough context, such as definitions, labels and metadata, for its meaning to be clear. It is governed, meaning someone is accountable for it and access is appropriately controlled. And it can be kept up to date through reliable processes, rather than one-off manual exports.

It is also worth being clear about what data readiness is not. It is not the same as having a data warehouse, and it is not a single project that ends. Data that is fit for purpose today will drift as systems change, people leave and business processes evolve. Readiness is maintained, not achieved once.

The evidence: why AI projects stall on data

Research from several independent sources points in the same direction. AI projects often fail to reach production or deliver value, and data problems are among the most frequently cited reasons.

In 2024, the RAND Corporation published a study based on interviews with experienced data scientists and engineers. It estimated that more than 80 percent of AI projects fail, roughly twice the failure rate of IT projects that do not involve AI. Among the root causes it identified were organisations lacking the data needed to train effective models, alongside misunderstanding the problem to be solved and focusing on technology rather than real business needs.

Gartner has made similar observations. In mid-2024, it predicted that at least 30 percent of generative AI projects would be abandoned after the proof-of-concept stage by the end of 2025, citing poor data quality, inadequate risk controls, escalating costs and unclear business value. In early 2025, it went further, predicting that through 2026, organisations would abandon 60 percent of AI projects that are not supported by AI-ready data. A widely discussed 2025 report from MIT's NANDA initiative claimed that the large majority of enterprise generative AI pilots it studied were delivering no measurable financial return, although its methodology has been debated.

These figures should be read with care. Definitions of failure differ, samples vary and some predictions come from organisations that also sell advisory services. The consistent message, though, is credible and matches practical experience: the hard part of applying AI in business is usually not the model but everything around it, and data is central to that.

The cost of poor data is not new, either. Gartner research has estimated that poor data quality costs organisations an average of 12.9 million dollars a year, through wasted effort, bad decisions and missed opportunities. AI tends to magnify these costs, because it acts on data at speed and scale. A human analyst might notice that a customer's recorded age of 212 is obviously wrong. An automated system will simply use it.

You may also have read that data scientists spend 80 percent of their time preparing data. That figure is repeated often but is hard to trace to a robust source. Surveys such as Anaconda's annual State of Data Science reports have suggested that data preparation and cleaning take up a substantial share of practitioners' time, often well over a third. The exact number matters less than the point: preparing data is routinely one of the largest parts of any AI project, and it is frequently underestimated in budgets and timelines.

Warning signs your business is not ready yet

Data problems are rarely hidden. They show up in everyday frustrations long before anyone tries to build an AI system. If several of the following sound familiar, your data probably needs attention before AI can deliver reliable results.

Different reports give different answers. If finance and sales produce different revenue figures for the same month, or two dashboards disagree on the number of active customers, the underlying definitions and sources are inconsistent. An AI system trained or grounded on that data will inherit the confusion.

Key information lives in spreadsheets and inboxes. When important processes depend on spreadsheets maintained by one person, or knowledge that exists mainly in email threads, the data is hard to access, hard to trust and easy to lose.

Nobody can say who owns a dataset. If no one is accountable for the accuracy of customer, product or supplier data, errors accumulate and nobody fixes them.

Getting data out of a system takes weeks. If extracting data requires a vendor support ticket, a manual export or a developer's time, connecting AI tools to that data will be slow and fragile.

Documents are outdated or duplicated. Shared drives full of files named "final", "final v2" and "final USE THIS ONE", or policies that have not been reviewed in years, are a serious problem for generative AI. An assistant will happily quote the wrong version.

Access permissions are loose. If many people can see folders, sites or records they should not, an AI assistant connected to those sources may expose sensitive information simply by answering a question. This is one of the most common issues raised when organisations deploy workplace AI assistants.

There is little history of the outcome you want to predict. If you want AI to predict customer churn but have never recorded consistently why or when customers left, there is nothing for a model to learn from.

None of these problems is unusual. They are the normal result of businesses growing, adding systems and prioritising getting work done over tidy records. The point is not to feel behind, but to recognise that these issues need to be addressed, at least for the data that matters to your first AI use case.

The five foundations of data readiness

It is useful to think about data readiness in terms of five foundations. Weakness in any one of them can undermine an AI project, even if the others are strong.

1.Availability and access

The data a use case needs must exist and be reachable by the systems that will use it. That sounds obvious, but in many businesses, important data is locked in legacy systems without usable APIs, stored in personal drives or held by third-party providers who make exports difficult. Start by identifying where the relevant data lives and how it can be accessed reliably, ideally through an integration rather than manual exports. When choosing new software, the ability to get your data out easily should be a selection criterion.

2.Quality

Data quality is commonly described in terms of several dimensions, including accuracy, completeness, consistency, timeliness, validity and uniqueness. In practical terms: are the values correct, are important fields filled in, do the same things have the same names and formats everywhere, is the data current, does it follow expected rules and are there duplicates? You do not need perfect data. You need data that is good enough for the decision the AI will support, and you need to know where its weaknesses are. A demand forecast can tolerate some missing values. A system that sends invoices cannot tolerate wrong addresses.

3.Structure and context

Data needs meaning as well as values. A column called "status" with values 1 to 5 is useless without knowing what each number means. Context comes from clear definitions, consistent categories, labels, metadata such as dates and owners, and documentation of how fields are calculated. For generative AI, context includes knowing which document is the current version, who wrote it, when it was last reviewed and what it applies to. Shared definitions of key business terms, such as what counts as an "active customer", are especially valuable because they prevent different systems giving different answers.

4.Governance, security and privacy

Governance answers the questions of who owns each important dataset, who can access it, how it may be used and how long it is kept. For AI, this matters in two ways. First, data protection laws such as the UK GDPR and EU GDPR apply when AI processes personal data, so you need a lawful basis, appropriate transparency and controls on how data is used. Second, permissions determine what an AI system can see and reveal. An AI tool that respects existing permissions is only as safe as those permissions are accurate. (Internal link suggestion: an article on AI ethics and data privacy for businesses.)

5.Infrastructure and pipelines

Finally, data needs to flow reliably from source systems to wherever the AI uses it, and stay current. That may mean scheduled integrations, a central data store such as a data warehouse or lakehouse, or connectors that let AI tools retrieve information from business systems directly. Pipelines need monitoring, so that a broken integration does not silently leave an AI system working from stale data for weeks.

Unstructured data, generative AI and the permissions problem

Generative AI has changed what data readiness means for many businesses. Traditional data work focused on structured databases. Generative AI assistants draw much of their value from unstructured content, which in most organisations has had far less care.

Why document quality now matters

When an AI assistant answers a question such as "what is our refund policy for business customers?", it searches your documents for relevant passages and uses them to compose an answer. If the shared drive contains three versions of the policy, written in different years, the assistant may retrieve the wrong one, combine conflicting versions or confidently present an outdated rule. The model is doing what it was asked; the problem is the content it was given.

Preparing unstructured data for AI usually involves a few practical steps. Identify the authoritative sources for each important topic and retire, archive or clearly mark outdated versions. Add basic metadata, such as owner, last reviewed date and status. Break very long documents into well-structured sections with clear headings, which helps retrieval find the relevant part. Convert scanned documents and images to searchable text where they contain important information. And set a review cycle, so that content does not quietly become stale again.

The permissions problem

AI assistants connected to workplace content, such as tools built into productivity suites or custom assistants connected to shared drives, generally respect the access permissions of the person using them. That sounds reassuring, and it is an important safeguard. But it means the assistant can surface anything that person technically has access to, including content they would never have found by browsing.

In many organisations, permissions have drifted over years. Folders are shared with "everyone in the company" for convenience, links are set to "anyone with the link", and former project members keep access indefinitely. Before AI, this oversharing was largely hidden by obscurity. With an assistant that can search everything instantly, a question like "what are the salaries in the marketing team?" may return an answer from a spreadsheet nobody realised was widely accessible. Oversharing has become one of the most commonly reported concerns when organisations roll out workplace AI assistants.

Before connecting AI to internal content, review sharing settings for sensitive areas such as HR, finance, legal and executive files. Remove company-wide and public links where they are not needed, apply sensitivity labels where your tools support them and consider starting with a limited set of approved sources rather than connecting everything at once.

How to assess your data readiness

A data readiness assessment does not need to be a long consulting exercise. For a small or mid-sized business, a focused review of the data behind one or two candidate use cases can be done in a few weeks and gives far more useful answers than a general audit of everything.

Start from the use case

Pick one AI use case you are seriously considering, and describe it in a sentence: for example, "automatically categorise and route incoming customer emails" or "predict which invoices are likely to be paid late". Then list the data that use case would need. For email routing, that might be past emails with the categories and teams they were eventually assigned to. For late payment prediction, it might be invoice history, payment dates, customer details and credit terms.

Score the data against the five foundations

For each data source, ask practical questions. Can we access it automatically, and who controls access? How accurate and complete is it, based on a sample check rather than assumptions? Are the key fields consistently defined, and is there enough history? Who owns it, and are there privacy or contractual restrictions on using it for this purpose? How will it be kept current?

A simple rating, such as ready, needs work or major gap, for each foundation and source is usually enough. The aim is to see where the biggest obstacles lie, not to produce a precise score.

Check a sample, not just the documentation

System documentation and people's descriptions of data are often more optimistic than reality. Pull a real sample, perhaps a few hundred records or a representative set of documents, and look at it. Count missing values, look for duplicates and obvious errors and check whether categories are used consistently. For documents, check how many are current and whether the authoritative version is clear. This step regularly reveals problems that would otherwise surface only after a project has started.

Estimate the effort to close the gaps

For each significant gap, estimate what it would take to fix: a data clean-up, a new integration, a permissions review, a change to how staff record information or a decision to start collecting data you do not yet have. Some gaps can be closed in days. Others, such as building enough history to predict a rare event, may take months. This tells you whether the use case is viable now, viable after a defined amount of preparation, or better postponed in favour of something else.

Getting ready without a multi-year programme

One of the most common reactions to data readiness problems is to propose a comprehensive data transformation: a new platform, a complete clean-up and a full governance framework, to be finished before any AI work begins. These programmes have their place in large organisations, but for most businesses they are slow, expensive and risk losing momentum before delivering anything visible. A use-case-led approach usually works better.

Prepare the data for one valuable use case

Choose a use case that matters to the business, has a clear measure of success and depends on data you can realistically get into shape within a few months. Fix the data that use case needs, and only that data, to the standard the use case requires. This produces a working result, builds credibility and teaches you what data work really involves in your organisation.

Fix problems at the source

Cleaning data once is useful. Stopping the same errors from reappearing is far more valuable. Where possible, fix the process that creates poor data: add validation rules to forms, make key fields mandatory, standardise picklists instead of free text, and connect systems so that information is entered once rather than retyped. Otherwise, you will find yourself cleaning the same data again before the next project.

Put light governance in place

Governance does not need a committee. Start by naming an owner for each important dataset, such as customers, products and suppliers, who is responsible for its quality and for approving access. Agree definitions for a handful of key business terms. Document where the authoritative version of each important document lives. Review sharing permissions on sensitive content. These steps take little time and remove many of the risks that stop AI projects.

Build reusable foundations as you go

Each use case should leave something behind for the next one: an integration that can be reused, a cleaner customer list, a documented definition, a monitored pipeline. Over several projects, these pieces add up to a solid data foundation, built in step with real business value rather than ahead of it.

Start collecting what you will need later

Some valuable AI use cases are impossible today simply because the data has never been recorded. If you want to predict why customers leave, start recording cancellation reasons consistently now. If you want to automate quoting, start capturing the details of how quotes are put together. Data you begin collecting today becomes the history a future model can learn from.

For many businesses, the most practical path is to combine a short data readiness assessment with a first, well-scoped AI or automation project. An experienced AI and automation partner can help identify use cases that fit your current data, close the most important gaps and build foundations that support the next steps, so that AI investment produces results rather than stalled pilots. (Internal link suggestion: an AI solutions or business automation services page, or a guide to choosing your first AI use case.)

Common data readiness mistakes

Waiting for perfect data. Perfect data does not exist. Holding back all AI work until every dataset is clean means never starting. Aim for data that is fit for a specific purpose, and improve it as you learn.

Treating data preparation as a one-off. Data degrades. People leave, systems change and processes evolve. Without ongoing ownership and monitoring, data that was ready for a project last year may not be ready now.

Buying a platform before defining a use case. A new data warehouse, lakehouse or AI platform can be valuable, but buying one before you know what problems it will solve often leads to an expensive, under-used system. Let use cases shape the infrastructure.

Connecting AI to everything at once. Linking an AI assistant to every drive, inbox and system on day one maximises the risk of outdated answers and oversharing. Start with a curated set of trusted sources and expand deliberately.

Ignoring the people who create the data. Most data quality problems begin when information is entered. If the staff who record data do not understand why accuracy matters, or the systems make it easy to enter rubbish, clean-up efforts will not last.

Overlooking bias in historical data. Historical data reflects past decisions and circumstances. If those were unfair or unrepresentative, a model trained on them can repeat the pattern. Review training data for gaps and skews, particularly where AI influences decisions about people.

Forgetting privacy obligations. Using customer or employee data for a new AI purpose may require updated privacy notices, a data protection impact assessment or a different lawful basis. Check before you build, not after.