Why Is Data the Bottleneck in AI Initiatives?
One of the more dangerous assumptions related to AI is the idea that a sufficiently intelligent system can somehow compensate for poor-quality data. In practice, AI is dependent on the data and context it is given.
People can often spot a figure in a report that simply cannot be correct. They recognise anomalies based on experience, additional knowledge and tacit understanding of the situation. With AI, this kind of healthy scepticism cannot be taken for granted. If a system is provided with incorrect information, it may use that information as part of its reasoning just as readily as accurate information. This becomes especially evident when an AI solution consists of multiple sequential steps or agents: an error at the beginning of the process can propagate through the entire chain, making it difficult to trace its origin.
Another common challenge is missing data. An organisation may have been operating in the same business for years or even decades, but that does not necessarily mean there is historical data available for AI to use. Information may be scattered across systems, stored in inconsistent formats, or simply exist in people’s heads. If the required data has never been collected, AI cannot retrospectively create missing history from nothing.
Data Volume Alone Is Not Enough
When discussing data quality, attention is often focused on accuracy and completeness. From the perspective of AI solutions, equally important considerations include data coverage, historical depth and, above all, meaning.
A very limited or fragmented dataset can steer AI in the wrong direction, even when individual records are accurate. If the objective is to identify patterns or build a comprehensive view from multiple sources, the breadth of the data also matters.
Even more important is the semantic context. For people within an organisation, the meaning of a particular data field, term or system may seem self-evident. For AI, it is not. The same concept may mean different things in different systems, system changes may alter the meaning of data over time, and a technical table name may reveal very little about what the information actually represents in the business.
This is where metadata, documentation and commonly defined concepts become important. Their role is not only to help people find information, but also to make the meaning of data sufficiently explicit for a system that has no knowledge of the organisation’s history or ways of working.
Tacit Knowledge Is Invisible to AI
Organisations rely heavily on tacit knowledge that is not recorded in systems or documentation. Experienced experts know what a report actually tells them, which figures require interpretation, when a system was changed and who to ask if a piece of information appears unusual.
This way of working may function for years because people compensate for shortcomings in the data through their own expertise. The adoption of AI often exposes the weakness of this approach. AI does not know what it has not been told in one way or another.
For this reason, one of the key tasks in data development is to move essential knowledge out of people’s memories and turn it into documented, machine-usable context. The more independently AI is expected to operate across different data sources, the more important this becomes.
When Is Data Good Enough?
The pursuit of perfect data can also become an obstacle. If an AI initiative cannot begin until all organisational data is clean, documented and standardised, the first experiment may be postponed indefinitely.
There is no universal threshold for data quality. What is good enough in one use case may be entirely inadequate in another.
The key question is how accurate the outcome needs to be for the solution to create value. A traditional deterministic system can be built to produce a precisely defined result. The strength of AI often lies elsewhere. If solving a complex problem through traditional methods would require numerous integrations and a lengthy development project, but AI can quickly provide a sufficiently accurate directional result, lower precision may be an acceptable trade-off. In use cases that require exact figures, that same level of accuracy is naturally insufficient.
This is why data quality should be evaluated in relation to the use case, the associated risks and the intended outcome. The question is not simply whether the data is abstractly good or bad, but whether the solution built on that data can deliver what is expected of it.
Test First, Improve Afterwards
A practical way to approach the issue is through iteration. Define a use case, test it using the existing data and evaluate the result. If the outcome is not good enough, identify the reasons why and improve the aspects of the data that prove to be relevant for that specific use case.
This does not mean that data quality should not be improved systematically. Quite the opposite. Data quality is an ongoing process because business needs also evolve. A new use case may create a need for richer metadata, a longer historical record or entirely new datasets.
An iterative approach helps avoid situations where an organisation attempts to solve every possible data issue in advance without knowing which of them actually prevent value creation. Ultimately, the decisive test is a practical one: does the implementation meet the need and create value?
The architecture of the solution also affects how good the data needs to be. If AI provides information to support an expert’s decision-making and a person reviews the outcome, the system can tolerate greater uncertainty than a solution that makes decisions automatically.
Data Governance Must Not Remain Disconnected
In AI initiatives, data quality is not merely a technical issue. Different people may be responsible for different aspects of the same data: one for content, another for quality, a third for security and a fourth for the systems themselves. This division of responsibilities is not inherently problematic as long as responsibilities and operating models are clearly defined.
The challenge arises when these perspectives only come together during a specific AI initiative. A use case may be valuable from a business perspective but problematic from a security perspective. Conversely, an overly heavy or unclear approval process may prevent valuable experiments from getting started at all.
Data quality and security can be managed separately from an organisational perspective, but in practice they share many dependencies. What matters is that the organisation understands under what conditions data may be used, what quality requirements apply to it and who has the authority to make the necessary decisions without every new use case having to restart the discussion from scratch.
Sensitive Data Requires a Conscious Choice
Not all data can naturally be handled in the same way. When designing a solution, it is important to understand how valuable or sensitive the data is and what the consequences would be if it ended up in the wrong place.
Customer and order data, for example, may require a very different level of care than public or otherwise low-risk information. It should also not be assumed that information entered into a public large language model service remains under the same level of organisational control as data stored in internal systems.
There are multiple alternatives. Models can be run in private environments if required by the use case, although this introduces additional costs and technical expertise requirements. In other situations, data can be modified before using an external model so that the sensitive content itself is not exposed. A practical example is the automatic obfuscation of technical names and structures before data is processed by a public language model, with the original values restored afterwards. This makes it possible to take advantage of the model’s capabilities without exposing the original content.
Successful security, however, is not determined by architecture alone. If secure operating practices are too difficult, slow or unclear for employees, people will naturally look for ways around them. This is why practical operating models, training and easy-to-use tools play such an important role.
AI Can Also Improve Data Quality
The relationship between AI and data does not flow in only one direction. High-quality data helps build better AI solutions, but AI can also be used to monitor data quality.
Traditional testing usually checks for issues that someone has foreseen or that have already been encountered before. The number of potential anomalies may be so large, however, that it is not practical to create a separate rule or validation for every possible scenario.
In this type of environment, AI can act as an additional set of eyes. For example, it can review large numbers of tables or data structures and identify situations where something is completely missing, where a structure differs significantly from previous versions, or where a value is on an entirely different scale than expected. The goal is not to replace deterministic controls or build a one hundred percent quality assurance process, but to identify rare issues that no one thought to define in advance.
This can be particularly valuable when data moves quickly into use by customers or other end users. If an anomaly is detected before incorrect information spreads further, even a small additional layer of validation can have a significant impact.
People Remain at the Centre of Decision-Making
AI can significantly reduce the cognitive load on employees. It can retrieve information, combine data sources, identify anomalies and prepare material needed for decision-making. This can free up experts to focus on situations that require broader context, experience and judgement.
It is not sensible, however, to transfer significant decision-making directly to AI. The greater the consequences of a decision, the more important human evaluation and validation become.
This also changes the way AI solutions are procured. In a traditional IT system, a supplier can often demonstrate clearly that a specific calculation or process functions according to the specification. With AI solutions, the organisation using the solution often needs to determine for itself whether the output actually serves the intended purpose.
For this reason, AI cannot be outsourced in exactly the same way as some traditional technologies. Organisations need sufficient internal understanding to evaluate how a solution operates, recognise its limitations and validate its results. At the same time, this expertise supports the broader adoption of AI throughout the organisation.
AI Raises the Bar for Data Quality
The growing adoption of AI may also change our perception of what constitutes acceptable data quality. Many current data issues remain hidden because people have learned to live with them.
One person knows that a certain report always contains a specific error. Another knows where the correct information can be found. A third knows whom to notify when an anomaly occurs. In practice, the organisation maintains low-quality data through human experience and manual corrective actions.
As AI becomes more widely used, these hidden dependencies become problems. AI does not automatically know who in the organisation understands a particular anomaly or why a legacy system produces data with different naming conventions. As a result, the threshold for acceptable data quality may rise significantly.
This does not mean every organisation should immediately build an entirely new data architecture. Requirements vary greatly depending on the use case. For many organisations, it is more important to begin transforming existing data into a format that is easier to access, understand and use with AI, while continuously improving quality over time.
At the same time, organisations should invest in skills development early. Even a modest but continuous investment in data and AI capabilities may be preferable to a situation where the need becomes urgent in a few years’ time and both technology and expertise are found to be lagging behind.
Start with Small Use Cases
When an organisation wants to realise value from AI quickly, the first question should not necessarily be: What could we use AI for? A better starting point is to clarify the problem that needs to be solved.
In many cases, the best first step is a small, focused use case through which the organisation can learn both about the technology and about its own data. In customer service, for example, AI can retrieve relevant information from customer history, compile KPI data and identify trends before a customer interaction. This reduces the need for customer service representatives to manually review extensive historical information, while the final interaction and judgement remain the responsibility of the human.
This type of use case is on a completely different scale from, for example, optimising an entire production process from material sourcing to delivery. A large objective may be worthwhile, but as a first AI project it introduces a vast number of challenges simultaneously, many of which the organisation may have little experience dealing with.
Part of AI’s most interesting potential lies in problems that were previously not considered worth solving. If an expert spends two days each month on simple manual work, building a traditional automation solution might never have delivered a sufficient return on investment. AI can change that equation.
When multiple small improvements accumulate, their combined impact can be far greater than that of a single high-profile AI initiative. The goal does not need to be replacing people, but rather freeing time from repetitive work so that employees can focus on tasks where human expertise creates greater value.
A Good AI Initiative Starts with Data, but Does Not End There
Data quality is one of the key prerequisites for successful AI adoption, but it should not be viewed as a separate preliminary project that must be completed before anything else can begin.
A better approach is to connect data development directly to concrete use cases. Select a real problem, define the required level of accuracy, test with existing data and validate the outcome. In the process, organisations learn what data is missing, where context is unclear and what needs to be improved next.
In this way, AI initiatives and data quality improvement support one another. Organisations do not wait for perfect data, but neither do they build AI solutions blindly on top of an inadequate foundation.
And perhaps that is the most important change of all: AI forces organisations to make visible the issues they have previously simply learned to live with.
