Data quality is the real GenAI bottleneck
Blaming the model is easier
Blaming the model is easier because the model is visible. When an AI assistant gives a wrong answer, teams adjust the prompt, switch providers, or increase the context window. Those changes can help, but many failures begin in the information supplied to the model. Customer records conflict across systems, policies have several active-looking versions, product names are inconsistent, and important fields are missing or delayed. Retrieval then returns weak evidence, and the model produces a fluent response around it. The same problem affects predictive and agentic systems. No model can reliably decide from data that is unavailable, ambiguous, or governed differently in every source.
Data quality is not a one-time cleaning project. It is a continuing relationship between data and the decisions it supports. Accuracy, completeness, freshness, consistency, uniqueness, and validity matter in different proportions for different use cases. A delayed field may be acceptable for monthly reporting but unsafe for a real-time service action. A duplicated customer may distort analytics and cause an agent to contact the same person twice. Teams need to translate product consequences into explicit quality expectations. This gives data owners a reason to prioritise issues and gives application teams a clear behaviour when a threshold is not met, such as requesting review, using a fallback, or declining to act.
What good foundations look like
Good foundations begin with ownership and meaning. Critical data elements should have clear definitions, accountable owners, authoritative sources, and documented consumers. Lineage should show how information moves from origin to model or application. Access policies and classifications need to remain consistent along that path. Data contracts can define schema, freshness, volume, and semantic expectations between producers and consumers. These practices make quality observable before a user reports a wrong answer. They also help teams distinguish a source problem from a transformation, retrieval, or model problem. Diagnosis becomes faster when the system can explain which data was used and what checks it passed.
Metadata is part of quality because context determines interpretation. A value without its unit, time period, source, or business definition may be syntactically valid and still misleading. Documents need effective dates, version status, owners, and permission information. Structured data needs keys, relationships, and measure definitions that are consistent across tools. For generative AI, chunking and indexing add another quality layer. A source can be correct while the retrieval unit removes the condition that makes a statement true. Evaluation should therefore test the entire path from source to retrieved evidence to final response, rather than assessing the model in isolation.
Fix it in the flow, not once
Quality should be fixed in the flow where data is created and transformed. Central clean-up teams can correct symptoms, but recurring issues return unless producers receive feedback and controls are placed close to the source. Validation at entry, reference checks, standard identifiers, schema enforcement, and clear exception workflows prevent defects from spreading. Pipeline observability can detect freshness failures, unexpected volumes, distribution shifts, and broken dependencies. When an issue is found, the system should identify affected products and decisions through lineage. This supports targeted response instead of broad uncertainty. It also makes the business impact of data work visible.
AI applications can contribute to this loop. User corrections, low-confidence retrieval, failed validations, and escalation patterns can reveal where data needs attention. These signals should be categorised and routed to the right owner rather than stored as unstructured feedback. Some corrections may improve metadata or search relevance, while others require changes to a source process or policy. Teams should avoid silently patching answers in the application because local fixes create another inconsistent layer. The preferred remedy is the earliest governed point that can improve all downstream uses. Product, data, and domain teams need a shared backlog so quality work competes on impact rather than technical visibility.
The payoff
The payoff appears in reliability, speed, and reuse. AI teams spend less time debugging inconsistent examples and more time improving the user outcome. Evaluations become more stable because source changes are visible. Users receive answers with stronger evidence and fewer contradictory results. New products can reuse trusted datasets, document pipelines, and semantic definitions instead of starting another reconciliation exercise. Governance becomes more practical because ownership and lineage are connected to live use cases. These improvements also benefit analytics, automation, and operational systems, making AI investment a catalyst for a broader data capability rather than a separate technical island.
A pragmatic programme starts with the data path behind one important AI use case. Identify the decisions, sources, critical elements, permissions, and failure consequences. Measure current quality and define thresholds that the product can enforce. Add controls at ingestion and transformation, expose quality signals to the application, and build an escalation route for unresolved cases. Monitor production behaviour and use failures to refine both the data controls and the evaluation set. Then turn the successful patterns into shared services and standards. The bottleneck is rarely solved by cleaning everything. It is solved by making quality accountable, observable, and continuously connected to the outcomes the organisation values.
Leaders can keep the programme grounded by asking four questions in every review. Which decision is affected by this defect? Where was the defect introduced? Who can correct the source or process? How will the team know that the correction remains effective? The answers should connect product traces, lineage, quality checks, and ownership. Avoid broad quality scores that average away critical failures. A small number of consequence-based indicators is more useful than a long dashboard of generic rules. Track the age and recurrence of critical defects so temporary workarounds do not become invisible operating practice. Over time, this discipline changes data work from reactive clean-up to sustained and systematic prevention. It also creates a common language through which business and technical teams can prioritise the same backlog.
