Many AI initiatives start successfully: a convincing use case, a functioning prototype, initial automations. And then the problem arises that organizations are forced for the first time to agree on a binding operational reality.
AI makes chaos visible: for the first time, contradictions that were previously bridged by human interpretation become operationally relevant. That is why an organization needs clarity that it has never had to explicitly define before.
Data quality is not a prerequisite for AI, but rather a by-product. Only when it has been determined which decisions should be made and how can it be defined which data is “correct.” “AI-ready” therefore does not describe the maturity of a model, but rather a company's ability to clearly map its own processes.
Only then does AI begin to scale.
Data quality in companies is not a showcase project, but an ongoing issue
Data quality is often treated like a cleanup project: clean up once, migrate once, introduce a platform once. After that, the AI should run reliably. In practice, however, deviations, queries, and manual checks arise again after a short time.
A brief example illustrates this: A medium-sized machine manufacturer wants to prioritize requests for quotes automatically. The AI should recognize which requests have a high probability of being concluded. The prototype works. Historical quote data is imported, the model recognizes patterns, and delivers plausible evaluations. So far, so good.
However, a problem arises during operation: sales employees maintain closing reasons differently, some not at all. Projects are sometimes marked as “won” and sometimes as “completed” in the ERP system. Discounts are sometimes entered as free text and sometimes in a field. After a few weeks, the AI's recommendations no longer correspond to reality. The result: the AI works correctly from a technical standpoint, but it follows a logic that the organization has never agreed upon. That's why it seems “wrong.”
The problem is not that no one can formulate a definition. It fails because every definition creates winners and losers and is therefore avoided for organizational reasons. And it's not uncommon for AI to remain a data problem as a result.
Poor data: uncertainty instead of automation
However, the consequences of poor data are, so to speak, preprogrammed: the system consistently prioritizes the wrong requests, attractive projects are processed too late, and unpromising offers tie up capacity. Sales loses deals without recognizing the reason, the order situation becomes unpredictable, and the organization begins to doubt its own figures. Decisions are once again made based on gut feeling, only this time with the deceptive impression that they are data-driven. The fact is that it is not poor data that leads to wrong decisions, but a lack of agreement on what a good order actually is. AI forces us to address this question.
Because this is exactly where manual rework begins again in companies. Offers are additionally evaluated, reports are questioned, forecasts are relativized. AI continues to run, but it no longer makes decisions. Automation therefore fails not because of the technology, but because of the data chaos in everyday life. Efficiency gives way to inefficient processes again because employees have to verify results they do not trust.
The three structural causes: silos, semantics, responsibility
Most companies assume that data quality is primarily a question of diligence. In practice, however, the question of structure is more relevant. Three mechanisms occur almost everywhere at the same time, regardless of industry, size, or systems used. Not because employees work inaccurately, but because organizations are structured functionally.
1. Silos – multiple truths within the same company
Sales, service, and accounting work with the same customers, but not with the same information. The CRM knows the contact person, the ERP knows the billing address, and the service department keeps its own notes in tickets or Excel lists. Each view is correct in itself. This is not critical for operational work. But it is for automation. As soon as decisions need to be made systematically, the organization needs a binding version of reality. This is precisely what is difficult to define within departmental boundaries, because each view fulfills legitimate requirements.
This is manageable for humans. But AI needs a clear reality. Without a single source of truth, it learns contradictory patterns and appears unreliable, even though it is working correctly.
2. Semantics – same key figure, different meaning
It becomes even more difficult with terms. What is an “active customer”? For sales, it is someone with ongoing communication; for accounting, it is someone with annual sales; for service, it is someone with an open ticket. The data is complete, but at the same time it is not unambiguous. Without common definitions, a model cannot identify reliable correlations. And these definitions cannot be enforced technically. They are the result of technical coordination. As long as departments pursue different goals—sales revenue, controlling comparability, service documentation—the meaning of key figures will also remain different. AI makes these differences visible.
3. Responsibility—data without owners
Data flows across the organization and does not belong to anyone in particular. Every department uses it, changes it, or evaluates it, but no one makes a binding decision about its accuracy.
The result: corrections are made locally, and quality remains random. Without clear data ownership, there is no stable state, but rather a permanent negotiation process. And AI can only work as stably as the reliability of the processes that generate its data. Data quality rarely fails due to a lack of understanding, but rather because several departments would have to adapt their working methods at the same time.
Why tools don't solve the problem
Once the challenges in AI projects have been identified, the response is almost always the same: a new system: data warehouse, CRM relaunch, data platform, AI tool. In the short term, the situation may actually improve. Data is more structured, evaluations are clearer, and the model is more stable. But after a few months, the same effects reappear, only now in the new system. The reason is simple: software processes data. It does not define it.
When terms are understood differently, responsibilities are unclear, and processes vary, a new tool merely transfers the existing ambiguity to a more modern interface.
The turning point: Deriving data requirements from decisions
The key question is not what data is already available, but what decisions need to be made reliably in the future. Only when specific AI use cases are prioritized—such as bid evaluation, capacity planning, or maintenance recommendations—can it be determined what information must be clearly available. An AI roadmap therefore begins with the relevant decision-making processes and not with a list of data fields.
This shifts the starting point: data-driven decisions only become reliable when it is clearly defined what information is collected, maintained, and reviewed, and in what form. Organizations that achieve real business value through AI first define the decision and then derive data requirements, responsibilities, and controls from it, not the other way around by collecting as much data as possible.
Conclusion
The difference between a functioning prototype and productive use only becomes apparent in everyday use. A pilot project can work with prepared data. However, as soon as AI supports operational processes—such as prioritization, planning, or scheduling—it must be reliably embedded in the AI organization.
Only when responsibilities, processes, and coordination are bindingly regulated can AI be scaled. Many organizations fail not because of ignorance, but because of structure: every clear definition changes responsibilities, evaluation authority, and conflicts of interest between departments. As a result, the necessary clarification is often not provided – and AI appears to be a data problem. This applies not only to systems, but also to working methods: priorities, handover between departments, and the way results are evaluated. Without accompanying change management for AI, its use remains limited to individual experiments, even if the technical solution works.
FAQs
How does data quality influence the success of AI projects?
The model quality depends directly on the underlying information. If data is contradictory or incomplete, AI will deliver results, but the organization will not trust them. The decisive influence of data quality on AI is therefore less evident in the technology than in AI trust: without reliable data, automation will not be used.
What are the risks of poor data quality in AI?
Poor data leads to systematic biases and, as a result, to wrong decisions in planning, sales, or service. If such results are reused, this can lead to economic damage, reputational risks, and, in regulated areas, compliance risks because decisions are not traceable.
Why is a new AI tool without a data structure usually not enough?
A tool processes data, it does not organize it. Without clear data management, coordinated data processes, and governance, the system will inherit existing inconsistencies. Only structured responsibilities and continuous maintenance (DataOps) make results reliable; otherwise, the tool remains just another system that needs to be checked.
Posted by:
Jens is the co-founder of bakedwith, a boutique consultancy firm specialising in smart automation and AI. He helps medium-sized companies and corporations to optimise processes, reduce manual work and achieve growth through efficient workflows. Previously, he was Growth Lead at OMR and worked as a freelancer, helping numerous companies optimise their CRM and automation systems. Jens is passionate about combining growth and efficiency to enable teams to focus on what matters most.
