ML in Production: Why Most ML Models Never Reach Production

Ask any data team who owns a particular dataset and you’ll get one of three answers. A name that no longer works at the company. A shrug. Or a fifteen-minute conversation that ends with “it depends.”

That’s the state of data ownership in most organisations. Not malicious, not unusual — just broken in a way that’s become so normal it stopped feeling like a problem.

It is a problem. And it compounds quietly until something goes wrong.

What ownership actually means

Data ownership is not the same as data access. Anyone with the right permissions can access a dataset. Ownership is something different — it means someone is accountable for the data being accurate, up to date, properly documented, and fit for the purpose it’s being used for.

When ownership is clear, there’s a person or team you can go to when a number looks wrong. Someone who knows where the data comes from, what transformations it goes through, and what it should and shouldn’t be used for. Someone who gets paged when a pipeline breaks.

When ownership is unclear — which is most of the time — none of that exists. Questions bounce between teams. Incidents have no clear owner. Data quality issues get discovered by the wrong people at the wrong time, usually in a dashboard during a business review.

Why it breaks down

Data outlives the people who created it. A table gets created by an engineer building a feature. That engineer moves to another team, or leaves the company. The table stays. Nobody inherits ownership explicitly, so ownership becomes whoever happens to remember what it does — until they leave too.

Ownership is assumed, not assigned. Most organisations never formally assign data ownership. It’s assumed that the team who produces the data owns it. But the team who produces the data is often thinking about the system that generates it, not about the downstream consumers who depend on it. Two different things can both be true: the producing team feels no responsibility for how it’s used, and the consuming team has no authority to change it.

Data crosses team boundaries constantly. A Kafka event produced by the payments team gets consumed by the analytics team, transformed by a dbt model owned by the data engineering team, and queried by the finance team for reporting. Who owns the accuracy of the final number? Everyone has a piece of it. Nobody owns the whole thing.

Nobody is measured on data quality. Engineers are measured on feature delivery. Data scientists are measured on model accuracy. Analysts are measured on insight quality. Data quality — the accuracy, completeness, and timeliness of the underlying datasets — is rarely a metric anyone’s performance is tied to. So it gets treated as someone else’s problem.

What broken ownership looks like in practice

The symptoms are usually visible long before anyone names the underlying cause.

Analysts spend more time validating data than analysing it. The same question asked to two different dashboards returns two different answers. A NULL value appears in a field that shouldn’t allow NULL, and nobody knows why or when it started. A pipeline fails silently and the first sign of it is a business metric moving in the wrong direction. An audit asks for the lineage of a particular figure and the answer takes two weeks to reconstruct.

None of these feel like an ownership problem in the moment. They feel like data quality problems, or pipeline problems, or tooling problems. But trace any of them back far enough and the root cause is the same: nobody was accountable for this data end to end.

What teams that get it right do differently

They treat data ownership as an explicit assignment, not an assumption. Every dataset has a named owner — a team, not just a person — and that ownership is recorded somewhere findable, whether that’s a data catalog like Atlan, a dbt model description, or even a simple wiki page.

They separate producer ownership from consumer ownership. The team that generates the data owns the accuracy and reliability of what they produce. The team that transforms it owns the transformation logic. Both are accountable for their piece, and the contract between them is explicit.

They make ownership visible at the point of use. When an analyst opens a table in their query tool, they can see who owns it, when it was last updated, and what it’s intended to be used for. Ownership information doesn’t live in a separate document nobody reads — it lives where the data is.

They review ownership regularly. Teams change, systems change, priorities change. A dataset that was actively maintained last year might be abandoned now. Regular audits of data ownership catch the gaps before they cause incidents.

Data ownership is not a glamorous problem. There’s no exciting architecture diagram, no new tool that solves it, no conference talk that makes it sound interesting. It’s fundamentally a people and process problem, and those are slower to fix than technical ones.

But the cost of ignoring it is real. Every hour an analyst spends chasing down the source of a wrong number is an hour not spent on analysis. Every incident traced back to an unmaintained dataset is a trust problem that takes months to recover from.

Ownership is the foundation that everything else in a data organisation builds on. Get it wrong and the rest of it — the tooling, the models, the dashboards — sits on sand.