From Data Quality to AI Value

01 / UK evidence

Three questions, three different measures

DSIT’s AI Adoption Research, updated in 2026, reports 3,500 interviews conducted from February to May 2025. It targeted private-sector businesses with at least five employees in selected sectors and weighted results by size and sector. Sixteen per cent used AI; lack of identified need and limited skills were the most common adoption barriers. Among 700 adopter respondents, 75% reported improved workforce productivity, but 77% reported no revenue change since adoption. These are self-reports, not audited causal estimates; the survey also does not capture shadow AI. [1], executive summary; methodology; Figures 24-25

The Bank of England/FCA’s 2024 survey received 118 financial-services responses; 75% reported using AI. Four of the five leading perceived current risks concerned data: privacy and protection, quality, security, and bias and representativeness. This is evidence of sector-specific concern, not proof that data quality causes a particular share of failed projects. [2], key findings; sections 1.2 and 4.2

The two adoption percentages should not be plotted as a time trend or treated as directly comparable estimates. Their populations, survey designs and dates differ. Neither supplies a current adoption rate for every UK organisation.

An “ROI gap” needs a definition

Unchanged revenue is not equivalent to no return. A business can reduce costs, improve service or release capacity without increasing sales. Equally, employees reporting faster work does not establish profitability once licences, integration, review and maintenance are included. A defensible article must specify which outcome is missing before calling the difference an ROI gap.

This changes the diagnosis. An organisation with no worthwhile use case needs a different response from one whose promising workflow fails because the underlying records disagree. Cleaning data before deciding what decision it must support risks improving the wrong asset.

02 / Research findings

How data problems reach the workflow

Several research traditions explain why data deserves attention. They offer different kinds of evidence, and should not be treated as interchangeable proof of financial impact.

Organisational mechanisms

Sambasivan and colleagues interviewed 53 AI practitioners working in India, the United States, and East and West African countries. Their CHI study describes “data cascades”: accumulating downstream problems associated with neglected data practices. It highlights incentives and coordination as well as technical issues. The qualitative design illuminates mechanisms; its sample cannot establish their prevalence in UK enterprises. [4], sections 3 to 4

Documented production experience

Breck and colleagues describe a data-validation system deployed within Google’s TFX platform. Their production examples include detecting data errors, improving model quality and reducing debugging effort. One example explains how a serving-system bug can introduce a technically valid but erroneous feature value that later enters training data. This is concrete evidence of a failure pathway and an engineering response, not a transferable estimate of UK business ROI. [5], introduction; production experience

System-level maintenance

Sculley and colleagues identify data dependencies, feedback loops and changing external conditions as sources of technical debt in machine-learning systems. Their engineering analysis supports considering costs beyond initial model development. It does not quantify an economy-wide return from data cleaning. [6], sections 3 to 4 and 9

The model remains part of the problem

Liu and colleagues found that the position of relevant information affected performance on long-context question-answering and retrieval tasks in the models they tested. Correct information being present was not sufficient for reliable use. This 2024 study motivates context-sensitive evaluation; it should not be read as a benchmark of every model available in 2026. [7], abstract; experiments

The resulting practical inference is to diagnose before prescribing. A missing field, irrelevant retrieved passage and incorrect model inference may produce the same wrong answer, but they demand different fixes. A cleaner database cannot by itself guarantee that the model follows the right evidence.

03 / Proposed framework

Trace a defect to a business outcome

The Government Data Quality Framework defines quality through fitness for purpose and identifies completeness, uniqueness, consistency, timeliness, validity and accuracy. It emphasises ongoing management rather than one-off cleaning. [3], data quality dimensions; principles Those dimensions help describe a defect; the next step is to specify why it matters for the task.

The table below is a proposed practitioner framework, developed for this article. Each row is a hypothetical causal pathway to test, not an observed effect or a validated prediction. The same defect may have no measurable consequence in another workflow.

Start with one consequential pathway. Define the affected population, an authoritative source, the expected failure and an accountable owner. Then record a baseline. A check that reduces duplicate rows is not yet evidence that it reduces incorrect matches: the second relationship needs its own test.

Do not compress away the important failure

An overall quality percentage can be misleading. A thousand missing optional fields may matter less than one wrong field used in an important decision. Report rule-level results and task-level consequences together. Thresholds should reflect the use case, not a universal target such as “95% clean”.

Documentation makes this test easier to interpret. Gebru and colleagues propose datasheets describing a dataset’s purpose, composition, collection and recommended uses. [8] Applied here, a short record should explain where the data came from, what one row represents, its known exclusions and who maintains it. Documentation supports investigation; it does not certify correctness.

For generative systems, distinguish training data from the documents retrieved at use time. Updating a knowledge source and retraining a model are different interventions. For predictive systems, check whether training inputs match the information actually available when a decision must be made.

04 / Worked example

A valid record can still be wrong

Consider a fictional service business using AI to draft account replies. It must retrieve the current contract before answering a question about an account. The miniature dataset below is synthetic and deliberately incomplete; it is a reasoning exercise, not evidence from a deployment.

Inspect before correcting

C101 is a duplicate candidate if the table is intended to hold one current row per account. If it is an event log, repeated account identifiers may be legitimate. C102 cannot support a task requiring its contract start date. C103 contains an impossible date; its plan spelling may be normalised only after confirming the allowed categories. C104 needs a freshness check, but an old verification timestamp does not prove its contract is wrong.

No row passes an accuracy test merely because its fields look plausible. A real date may refer to the wrong agreement. A complete customer record may belong to the wrong person. Some checks require comparison with an authoritative source and a reviewer’s judgement.

Give validation a consequence

A practical SQL or Python pipeline could check required fields, parse dates, validate category values and find repeated business keys. It should return record identifiers, failed rules and reasons. Missing contract information could route a case to review; a harmless spelling variation could be normalised through an approved mapping.

Keep the original values and a transformation log. Do not fill a missing date with a convenient guess or silently delete every repeated identifier. If the problem originates in a source-system export, fixing only a downstream copy leaves the defect ready to return in the next batch.

A useful outcome is therefore not simply “five rows became four”. It is that the assistant has fewer opportunities to issue an unsupported account-specific answer, while the team can inspect the cases it could not safely complete. Whether that improves cost or service must still be measured.

05 / Transparent economics

Calculate the improvement you need

A business case should expose its assumptions. The scenario below values labour capacity in a fictional support workflow. It does not estimate what UK businesses typically save, and it assumes all cases are ultimately resolved to the same accepted standard.

Monthly volume is 10,000 tasks. The existing process takes six minutes per task at a loaded labour cost of £24 an hour. The assisted process requires two minutes of routine review for every task, plus ten additional minutes for each failed task. Model and platform costs are £4,000 a month. Failure rates are independent assumptions.

Calculation. Let N be monthly tasks, w the hourly labour cost, t_base baseline minutes, t_review review minutes, t_fix extra correction minutes, f the failure fraction, and C monthly platform costs. Estimated monthly benefit is:
B = N × (w / 60) × (t_base − t_review − f × t_fix) − C.

Now assess only the incremental data intervention. Assume it costs £12,000 upfront and £1,000 each month to maintain. If failures fall from 15% to 5%, correction capacity worth £4,000 is released monthly. After maintenance, the incremental benefit is £3,000 a month; simple payback is four months.

Across twelve months, gross incremental benefit is £48,000 and intervention cost is £24,000. Simple first-year ROI is (£48,000 − £24,000) / £24,000 = 100%. This excludes discounting, ramp-up and taxes. It is scenario arithmetic, not a forecast or observed causal effect.

Capacity value becomes a cash saving only if expenditure is actually avoided or reduced. Add training, integration, residual mistakes and transition costs where relevant. Do not count the same released time as both a labour saving and a separate productivity benefit. If success rates differ, compare cost per accepted task and report unresolved cases explicitly.

06 / Evaluation

Test the causal link, not just the dashboard

The strongest business evidence measures work completed in context. Brynjolfsson, Li and Raymond studied a staggered rollout of an AI assistant involving 5,172 customer-support agents. Their published study reports a 15% average increase in issues resolved per hour, with substantial differences across workers. Less experienced workers benefited more; some quality measures declined among highly experienced workers. [9] This is evidence about a particular AI-assisted workflow, not the effect of a data-cleaning intervention or a UK-wide return.

For a business considering the framework in this article, the next step is a focused evaluation. The following design is a proposal, not an experiment already conducted.

1. Define success and the counterfactual

For an account reply, success might require the correct contract, a supported answer, no unauthorised disclosure and reviewer acceptance. Compare the proposed workflow with the existing process or a simpler rules-based alternative. Keep the task mix and acceptance standard comparable; an assistant that declines difficult cases should not appear better merely because those cases disappear from its denominator.

2. Isolate the intervention where practical

Create a representative evaluation set with independently checked answers, including missing, conflicting and recently updated records. Compare the same cases before and after the data intervention while keeping the model version, prompt and retrieval settings fixed. Record repeated runs where outputs vary. Use blinded review where feasible and reserve a separate set for final evaluation.

For a live pilot, random allocation of eligible cases or teams can strengthen attribution where operationally appropriate. If only a before-and-after comparison is feasible, document changes in staffing, demand, case difficulty and model versions. Such a comparison may reveal improvement without establishing that the data change caused it.

3. Measure the whole task

Record accepted completions, unresolved cases, error severity, review time, correction time and operating cost. Examine consequential subgroups as well as averages. Report uncertainty rather than a single overprecise effect; choose sample size based on the smallest improvement that would change the investment decision.

4. Decide using benefits and failure costs

Use the measured effect and its plausible range in the financial model. A project that looks attractive only at the most optimistic estimate needs further evidence. Stop or revise it if quality deteriorates, even when average handling time improves. Continue checking outcomes after launch because the source data and operating conditions can change.

07 / Interpretation & method

What this review can support

For UK businesses, the defensible conclusion is conditional. Data quality can be a binding constraint when a worthwhile AI task depends on information that is incomplete, contradictory or unsuitable. It is not a substitute for a clear use case, adequate skills, a capable model or a workflow that people can operate.

The contribution of this article is the connection between diagnosis and investment: identify the defect, test its effect on accepted work, price the consequence and compare improvement costs. This makes a proposal falsifiable. If an intervention improves a technical check but does not improve the task, the claimed business pathway needs reconsideration.

The remaining evidence gap is specific. The sources reviewed here do not establish the average causal financial return of a defined data-quality intervention across UK enterprises. That is a limit of this review’s evidence base, not a claim that no such research exists. Better studies would report the intervention, comparator, task outcomes, full costs and conditions under which the results hold.

Research method and selection

This selective narrative review was assembled on 17 October 2026. Searches combined UK AI adoption, barriers, data quality and business productivity terms, with targeted searches for data cascades, production validation, ML technical debt, dataset documentation and long-context evaluation. Searches used web search with GOV.UK and Bank of England filters, publisher and conference repositories, and author-hosted papers.

Sources were selected for a clear method or identifiable engineering contribution, direct relevance and accessible primary material. The nine retained works comprise UK official evidence and guidance, peer-reviewed research, and a published engineering analysis. Publication years range from 2015 to 2026. Earlier technical work supplies mechanisms, not a claim about current model rankings.

Unverified commercial percentages, news summaries without an inspected underlying report, and unrelated sector claims were excluded from the argument. There was no exhaustive database search, preregistered protocol, dual screening, formal risk-of-bias instrument or meta-analysis. Selection and publication bias remain possible. This is not a systematic review.

Transparency and use

No original business dataset was analysed and no company was interviewed for this article. The framework, data and financial tables are proposed or synthetic illustrations. The interactive exercises make the evidence and assumptions inspectable. References identify the source for empirical claims; interpretation and recommendations are the author’s synthesis.

Author: Rahul Agrawal is an MSc AI & Data Science student at St Mary’s University, Twickenham, with experience in data analytics.
Editorial assistance: AI-assisted research, drafting and formatting were used in preparing this edition.
Suggested citation: Agrawal, R. (2026). From Data Quality to AI Value: What the Evidence Shows for UK Businesses. Independent research-led essay, interactive web edition, 17 October. Not peer reviewed.

References / 1 of 2

UK evidence and data-quality research

References / 2 of 2

Systems, documentation and productivity

All sources accessed 17 October 2026. Links lead to original reports, papers or DOI records. Publication dates and fieldwork dates are distinguished in the text.