Jashan.
← All writing
Data platform2 min read

Bad data does not slow you down. It scales your mistakes.

Teams invest in models and underinvest in the data feeding them, then wonder why outputs feel off. AI did not create the problem. It removed the human who used to catch it.

data-qualitydata-governancedbt

Dashboards hid bad data for two decades. A number came out wrong, someone eyeballed it against their expectation, and if it looked plausible it went into a deck. The feedback loop between a broken transformation and a human noticing ran in weeks, and it ran through a person who was sanity-checking by instinct.

AI removed the pause. A retrieval system with a stale column does not produce an obviously wrong number that someone questions. It produces a fluent answer built on the stale column, delivered with the same confidence as a correct one, at whatever rate your users ask questions.

The data was always this bad. The consequences changed.

DASHBOARD ERAbad valueone outputanalyst noticesAI ERAbad valueno expectation left to violate
One bad value used to produce one wrong number that an analyst questioned. The same value inside a retrieval corpus reaches every answer touching that topic, and nothing has an expectation left to violate.

The investment mismatch

The pattern I see in most teams: heavy investment in model selection, evaluation harnesses, and prompt iteration. Light investment in the pipelines feeding them. Then confusion about why outputs feel unreliable in a way the evals did not predict.

The evals did not predict it because the evals ran against a curated set. Production runs against the warehouse.

What works

Four things, in rough order of return:

Treat data quality as a product, not a chore. It gets a roadmap, an owner, and a budget, or it gets whatever time is left after feature work, which is none. The teams that made progress here staffed it deliberately.

Assign single ownership per domain. Shared accountability produces no accountability. One named person owns customer data quality. When something breaks, there is no routing discussion.

Measure trust the way you measure revenue. Freshness, completeness, and schema stability per critical table, tracked over time and reviewed on a cadence. If nobody looks at the number weekly, it is decoration. In dbt this means tests that fail builds rather than tests that log warnings someone filters out.

Fix upstream. A patch in the reporting layer buries the problem where the next team will rediscover it. Push the correction to the source system, or as close as the organisation will let you get.

The part that changed with AI

Two shifts worth naming.

Errors compound rather than sitting still. A wrong value in a warehouse table is one wrong value. The same value inside a retrieval corpus becomes context for every generated answer that touches that topic, and none of those answers carry a marker saying which fact was suspect.

And speed removed the human checkpoint. The analyst who used to notice that a figure looked wrong has been replaced in the loop by a system that has no expectation to violate.

If your AI outputs are inconsistent, the model is the third thing I would look at. Check what it is reading first.

Related reading