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.
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.
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
- Product managementThe AI data product manager role is not a rebrandData products became AI products, and the product manager who owns them now needs to read model behaviour, not just gather requirements and hold a roadmap.
- Data platformYour Snowflake resource monitor cannot see Cortex AI spendResource monitors track warehouse compute. Cortex AI functions bill on a separate credit type those monitors never query, and closing the gap takes two steps, not one.
- Product managementNine things to settle before you build an AI productProduct managers who approach AI products like traditional software ship disappointing results. Three assumptions stop holding, and the differences are worth settling before design starts.