Enterprise data teams can spend years measuring quality without ever answering the question that matters most. Is this information reliable enough for the decision someone needs to make? For technology vendors, the difference is fundamental. The buyer is not necessarily purchasing a cleaner database. They are trying to make a consequential decision, deliver a service, reduce risk or put AI into production.
In October 2026 UK data leadership discussions, several participants argued for prioritising critical data elements and the business use of data, rather than treating every defect as equally urgent. One described reframing a data-quality requirement so that the measure reflected operational usefulness, rather than a blanket notion of perfection. Another described the journey from repairing a failed reporting programme to accumulating more data-quality rules than the organisation could sensibly manage. The warning for vendors is clear. More rules can create more work without creating more value.
The quality score can become the problem
A dashboard saying that 97 per cent of records meet a standard can look impressive. It can also conceal a serious problem if the remaining 3 per cent contains the customers, financial transactions or regulated records that matter most. Equally, a field that is incomplete across a large portion of the estate may be harmless for a particular business process. Quality has to be judged against purpose, consequence and tolerance, not simply volume.
The UK discussion challenged the instinct to fix everything in one large remediation programme. Participants spoke about identifying high-impact domains, clarifying what constitutes adequate quality and routing faults into practical triage processes. A healthcare example emphasised beginning with a few consequential issues, rather than launching an all-encompassing scheme that could become difficult to sustain. A participant working with critical data elements described the importance of linking standards to remediation tickets, so a metric leads to action.
That puts pressure on product demonstrations. A vendor should be able to show not only how its platform detects duplicate records or null fields, but also how it distinguishes a tolerable issue from an operational incident. Can the customer configure quality thresholds by purpose? Can a steward see the downstream consequence? Can a process owner approve an exception with an audit trail? If the platform cannot connect detection to decisions, it risks becoming another source of noise.
AI raises the cost of getting priorities wrong
When inaccurate data enters an AI workflow, the result is not confined to an ugly chart. A retrieval system may cite the wrong policy; an agent may act on an obsolete account status; an analytics assistant may confidently explain a number built from inconsistent definitions. That raises the stakes, but it does not make universal perfection achievable.
UK participants described the need for shared business definitions, lineage, catalogues and stewardship networks as AI use expands. A semantic layer was raised as a way to maintain consistent definitions across functions. Data moving between suppliers and internal platforms makes this harder still. The failure point may sit upstream of the tool that finally exposes the error.
Vendors selling AI-readiness should therefore resist vague promises to make an enterprise’s data ‘AI-ready’. Buyers need a narrower answer. Which datasets feed this use case? What controls apply to them? Which issues would stop the process? Who owns the definition? How will an exception be handled before an incorrect output reaches a user or downstream system?
Governance must follow the process, not the project plan
The strongest UK examples centred on enduring ownership. A participant described assigning global data leads to work with business process owners, while another described domain-level ownership across suppliers, customers, consumers, materials and products. These were not portrayed as quick software deployments. They required sustained effort to define standards and move accountability into everyday operations.
A project can temporarily fund a cleanup. It cannot guarantee that new data arrives correctly next month. Unless the originating process changes, the same defects return. The commercial implication is uncomfortable for vendors whose pitch ends at implementation. Buyers may be better served by capabilities that make ownership visible, connect findings to workflow and let teams demonstrate a reduction in recurring defects over time.
This is also where executive sponsorship matters. The roundtable included experiences of persuading regional and operational leaders to accept stewardship roles. Governance can remain theoretical until business leaders recognise that data quality affects their own outcomes. Technology should make that accountability easier to exercise, not transfer it to a central data team that lacks authority over the source process.
What a credible data-quality business case looks like
A stronger proposal starts with a specific operational consequence: a delayed regulatory report, unreliable customer segmentation, repeated manual reconciliation or an AI initiative unable to move out of testing. The vendor then identifies the critical elements behind that outcome and establishes a baseline. The baseline might be the number of exceptions requiring human repair, the proportion of unusable records in a critical process or the time taken to resolve a source-system defect.
Next comes a workable operating model. The buyer should see which owner accepts each metric, which steward can investigate it, how the supplier integrates with the existing catalogue and ticketing tools, and what happens when a rule generates too many false positives. The product’s technical sophistication is relevant only insofar as it improves this chain of action.
Finally, a vendor should explain what will not be solved in phase one. That is not a weakness. It is evidence of a commercially mature prioritisation strategy. The most persuasive offering may begin with ten important data elements rather than ten thousand indiscriminate rules.
The critical-data-element test changes the order of work
Imagine two requests landing on a data-quality team’s desk. One asks for a campaign-preference field to be made more complete. The other concerns a customer identifier used to match payments to an account. A generic quality score might rank the first problem higher because it affects more rows. A business-led model could reasonably rank the second first because an incorrect match can create a financial or customer-service consequence. Neither outcome is automatic. The point is that a rule only becomes useful when its business purpose is understood.
The UK discussions supplied a particularly telling example of a participant revisiting what quality meant for a critical data element. By testing whether the information was fit for its actual use rather than mechanically applying an abstract standard, the organisation arrived at a much more meaningful measure. Another participant recounted years of evolution from reporting failures to an excessive catalogue of quality rules. Together, those experiences challenge vendors whose propositions begin and end with the number of automated checks a platform can execute.
A useful assessment should distinguish the source system, the critical element, its accepted definition, the downstream business process and the person empowered to make a decision. These are five different things. An alert attached only to a dataset may have no practical owner. An alert connected to an actual process owner can become an item that someone is accountable for resolving. The product should make the connection visible rather than rely on a slide explaining that governance is important.
For a vendor meeting, this creates an opportunity to demonstrate prioritisation rather than coverage. Show three defects with different business consequences, then explain why one should be escalated, one watched and one accepted. Buyers can judge a platform’s decision support far more readily from this exercise than from a catalogue of features.
How to keep a quality programme from becoming another reporting factory
The operational trap is familiar. Teams deploy quality dashboards, create hundreds of rules and celebrate a better-looking control framework. Yet the recurring defects remain because the upstream business process that creates them has not changed. The UK participants described both the necessity of business stewards and the challenge of persuading operating teams to own data. A vendor cannot cure that organisational tension with a new scorecard, but it can either intensify or reduce it.
The practical response is to design a closed loop. A failed quality rule should identify the affected decision or workflow. It should route to a person or queue that has authority to act. The owner should be able to accept, investigate, correct or document an exception, with enough lineage to understand where the problem originated. If an error keeps returning, reporting should surface the source-process failure, not simply count repeated tickets as independent successes.
This is an area where integration matters more than a polished dashboard. Large organisations already operate catalogues, service-management tools, data platforms and specialist governance applications. The buying question is whether a proposed quality layer can fit into that operating environment without forcing employees to work in yet another isolated queue. Vendors should explain how the product uses source metadata, exposes decisions to existing workflow tools and keeps a record of who accepted the risk.
That approach also changes the vendor’s success measures. Rules configured, datasets scanned and defects detected are implementation measures. Repeat-incident reduction, faster resolution of genuinely critical issues, fewer downstream reconciliation steps and higher confidence in a named decision are outcome measures. The second group matters when the initial project budget is exhausted and the sponsor decides whether the service is worth renewing.
A practical pilot for buyers who are tired of enterprise-wide promises
A credible pilot could begin with one process where the business owner already feels the pain. Select a limited set of critical data elements. Document the rules, their business rationale and the consequences of failure. Establish how many issues occur today, which ones are material and how long it takes to resolve them. Then introduce the tooling without rewriting the entire governance programme. The vendor should explain which part of the improvement is attributable to the product and which depends on changes in process or ownership.
It is equally important to test an exception. Not all data can be complete at the moment it is captured; not every apparent inconsistency needs immediate repair. If a customer service team accepts a temporary gap, the platform should record the basis of that decision and any conditions under which the exception expires. Risk-based tolerance is not permission to ignore problems. It is a way to make the trade-off explicit and reviewable.
For AI-related use cases, add a second test. Trace a disputed answer back through its data sources and definitions. The UK sessions raised the complication of data moving between suppliers and the need for consistent semantic meaning. Ask how a change in an upstream definition would be detected before an assistant or agent relies on it. A platform that can expose that chain has a more differentiated commercial story than one claiming generically to make all data AI-ready.
The final buyer discussion should establish an expansion threshold. What specific improvement would justify adding another domain? A pilot that cannot answer that question risks becoming an indefinite proof of concept. A vendor prepared to define a stopping rule, a narrow baseline and a credible cost of ongoing operation is more likely to be regarded as a partner in business prioritisation than a seller of perpetual remediation.
The questions vendors should be ready to answer
- Which business decisions would be materially affected by the data defects we can detect?
- Can quality thresholds vary by use case, risk and acceptable tolerance?
- How do we distinguish critical records from low-consequence noise?
- Can a process owner see, acknowledge and resolve the issue in their normal workflow?
- How will lineage and semantic definitions help prevent downstream AI errors?
- What measurable operating cost or business risk should improve after deployment?
The real sale is confidence in an outcome
The provocation is not that data quality is unimportant. It is that undirected data-quality spending can be expensive and self-perpetuating. The UK discussions point towards a more demanding buyer: one who expects the supplier to understand business criticality, not merely count defects. Vendors that arrive with a prioritisation method, a practical stewardship model and evidence of operational impact have a stronger story than those promising perfect data.
For vendors: The Data Leadership Board connects solution providers with senior enterprise data leaders confronting these challenges. If your proposition can help buyers make trusted decisions rather than simply produce more quality reports, connect with our team to discuss relevant enterprise decision-maker access.