Every failed data initiative I have ever examined has the same scene somewhere in its history. Something breaks: a pipeline drops a field, a table drifts out of date, a corpus fills with obsolete documents. The AI system downstream degrades. And when someone finally asks “who owns this data?”, the room goes quiet. IT says the business owns it, since they create it. The business says IT owns it, since it lives in their systems. The data team says they just move it. Everyone is partly right, which is exactly the problem: shared ownership is unowned.
This article is about closing that gap, because in the AI era the gap has become intolerably expensive. When root-cause analyses of failed AI deployments keep surfacing the same culprits (insufficient data access, evaluation drift, nobody accountable for the inputs), they are describing ownership failures. The most quoted framing of the year puts it well: the deployments that fail almost never lost the model fight; they lost the scoping and ownership fight. Meanwhile the four preceding articles in this track have each ended at the same doorstep. Readiness decays without an owner. Governance labels need someone to apply them. Quality contracts need someone to answer the page. Corpora need a curator. This is the article about who.
Why ownership breaks down
It is worth understanding why data ownership fails so universally, because the causes point at the fix.
Data crosses boundaries by nature. A customer record is created by sales, enriched by service, billed by finance, and analysed by marketing. No single function experiences itself as the owner, because each sees only its segment of the lifecycle. Structural, not cultural: you cannot exhort your way out of it.
Creation and consumption are strangers. The team entering the data (often under time pressure, in a CRM they resent) never meets the team whose model just degraded because a field went unfilled. No feedback loop, no felt consequence, no improvement. The cost of bad data lands far from where the data is made.
Ownership was assigned to systems, not data. Most organisations do have owners: system owners. Someone owns the CRM platform. But owning the platform is not owning the accuracy of the records inside it, and platform owners are measured on uptime and licence cost, not on whether the industry codes are right.
“Everyone’s responsibility” was the official answer. Data quality as a shared value, in the town-hall sense. Shared values without named accountability produce exactly what you would predict, and now the predictable result feeds customer-facing AI.
The data product idea, minus the ideology
The most useful corrective to emerge from the last several years of data thinking is the concept of the data product, popularised by the data mesh movement. I am going to borrow the concept and leave the movement, because full data mesh (domain-decentralised everything, federated computational governance, the whole apparatus) is a major transformation most organisations neither need nor survive. The kernel of the idea, though, is portable and immediately useful.
A data product is a dataset treated the way you treat software in production. It has a named owner. It has consumers, and the owner knows who they are. It has an interface contract: schema, definitions, quality thresholds, freshness guarantees, permitted purposes. It has monitoring against that contract, and someone is paged when it breaches. It has a lifecycle: versions, deprecation notices, a roadmap. In short: someone runs this dataset as a thing people depend on, because people do.
Notice how the previous four articles snap onto this frame. The readiness dimensions become the product’s quality contract. The governance labels (sensitivity, permitted AI purposes) become product metadata. The semantic layer holds the product’s published definitions. A curated document corpus is simply a data product whose contents happen to be unstructured. One organising idea carries the whole stack.
Figure 1 shows the anatomy: what a data product actually consists of, and the roles around it.
The role at the centre of Figure 1 deserves precision, because titles blur. The data product owner is accountable for the product meeting its contract: a business-side role requiring domain knowledge and authority, not a heroic engineer. Around them: data stewards doing the operational curation (definitions, quality triage, corpus pruning), and the platform team providing the shared rails (the lakehouse, the semantic layer, the monitoring tooling) so each product team is not rebuilding infrastructure. Owner decides, steward maintains, platform enables. Three roles, cleanly separated, and the majority of ownership confusion dissolves once they are named.
Assigning ownership without an org redesign
Now the practical question: who should own what? The principle I recommend is ownership follows domain knowledge, funded by consumption value. Unpacking that:
The owner should sit where the knowledge to judge correctness lives. The claims data product belongs in claims, not in IT, because only claims people know whether the loss codes reflect reality. The policy corpus belongs with the policy team. This usually means business ownership with technical support, which is the reverse of most organisations’ default, and the single most important reversal in this article.
The funding should follow the value the product unblocks. This solves the eternal objection: “we don’t have capacity to own data too.” Correct, and unfunded mandates fail. But recall how this track has priced things: data work is justified per use case, by the value it unblocks. The same fix list that says “these three fixes unblock $4M of use cases” also funds the ownership of those three datasets. Data products are not a tax; they are line items in the business cases they enable.
And critically: do not productise everything. The failure mode of enthusiastic adopters is declaring four hundred data products in a quarter, appointing owners who were not asked, and watching the whole scheme become a spreadsheet of fictional accountability. Sequence by the AI portfolio, as always. Your top five use cases probably depend on eight to twelve critical datasets. Those become your first data products. Real owners, real contracts, real monitoring. Everything else waits its turn, earning productisation when a funded use case needs it.
Figure 2 lays out this rollout: portfolio-driven selection, the ownership assignment flow, and the expansion loop as new use cases arrive.
One subtlety in Figure 2 worth calling out: the assignment step includes a negotiation, not an announcement. An owner who inherits accountability without resources or authority will fail and resent it. The negotiation covers the contract (what quality, what freshness, what the product does not promise), the resourcing (steward time, platform support), and the escalation path when upstream systems cause breaches the owner cannot fix alone. Ownership that skips this negotiation is ceremony.
Making it stick
Structures decay without reinforcement, so four mechanisms that keep ownership real.
Put products in the path. Platform rule: production AI systems consume only contracted data products, not raw tables. This makes ownership load-bearing rather than decorative, and it is the enforcement counterpart of the side-door pattern warning from the architecture article. Exceptions exist, in writing, with expiry dates.
Close the feedback loop. Consumers can see the contract, the monitoring dashboard, and a channel to the owner. When the downstream model degrades, the conversation happens in hours with the accountable person, not in weeks with a ticket queue. The strangers, creator and consumer, finally meet.
Measure owners on the contract. Product health (contract compliance, incident count, consumer satisfaction) enters the owner’s actual objectives. What is not in someone’s objectives is a hobby.
Review the portfolio quarterly. Products with no consumers get retired; datasets newly critical to the AI roadmap get productised. The estate should track the strategy, and the strategy canvas review is the natural moment: Box 4 now reads as a list of data products and their health, which is a far more honest data position than any maturity adjective.
The payoff
Let me total the account, because this article completes the data arc of the track. Five articles ago, data was the number one cause of AI failure: unready, ungoverned, architecturally scattered, mostly unstructured and invisible, and owned by no one. The arc’s answer, compounded: readiness assessed per use case, governance embedded in platforms, a foundation with meaning built into it, the unstructured estate curated into corpora, and now every critical dataset run as a product by someone whose name is on it.
Organisations that do this work are the 12x cohort. Not because any single piece is brilliant, but because AI systems are relentless consumers of data, and relentless consumers need suppliers who answer the phone.
With the foundations set, the track turns to choosing what to build on them. Next: prioritising your AI use-case portfolio, and the value-versus-feasibility discipline that turns a forty-item wish list into a sequenced plan.