Does this story sound familiar?

A team deploys a churn prediction model. Accuracy looks great at launch. The executive dashboard goes green. Everyone moves on.

Six months later? The model is still running on last year’s product catalog. Two new pricing tiers were added in March. The predictions are wrong. Confidently, quietly, expensively wrong. This is where many organizations still struggle. 

The project mindset made sense when data was a tactical side mission: one business question, one report, and one handoff. “Done” is the most dangerous word in a data team’s vocabulary.

But data is no longer a side mission. It is the mission. And the project model was not built for it.

Competitive organizations are building something different: a data product. Owned, versioned, contracted, and built to last.

The data product mindset

A data product is a reusable, active, standardized data asset (dataset, model, or pipeline) designed to deliver measurable value to internal or external consumers. It carries metadata, governance policies, data quality rules, and a data contract. It follows FAIR principles:  findable, accessible, interoperable, and reusable. Ownership is tied to a specific domain. The difference between project thinking and product thinking sounds subtle. In practice, it changes everything about how data gets built, owned, and trusted. 

What separates AI Leaders from AI laggards 

The bad news first: MIT reports 95% of generative AI (GenAI) initiatives deliver zero ROI, and Gartner predicts 40% of agentic AI projects will be canceled by the end of 2027. The cause is often the same: poor data quality, absent governance, siloed assets, and a lack of context.

The good news: A 2026 BARC study commissioned by Actian shows what is helping leaders realize AI success. Organizations with company-wide data products are 3.4 times more likely to successfully move AI projects into production. For agentic AI: 77% with enterprise data products have agents in production vs. 23% without. It’s no wonder then that adoption of data products jumped 21 points from 48% to 69% in just 13 months. Bad data and lack of context don’t just slow down AI. They make AI untrustworthy at scale, and that’s a business risk, not a technical one.

A common language for data products and data contracts 

You do not need to invent your own format or negotiate a proprietary standard. Two open standards already exist. The Open Data Contract Standard (ODCS) and the Open Data Product Standard (ODPS) are both maintained by Bitol, a Linux Foundation project.

ODCS started as PayPal’s internal data contract template. Now at v3.1.0, it covers schema, data quality, service level agreements (SLAs), team ownership, and infrastructure across more than 20 server types. The upcoming release will add support for more semantic and context information, further strengthening the data foundation that AI systems rely on to reason and act reliably. 

Adoption is accelerating. According to the same BARC study, 41% of data contract practitioners already use ODCS (the other 59% use mostly home-grown formats). The standard is finding its way into production, one contract at a time. ODPS v1.0.0 is the product wrapper. It adds lifecycle states, input and output ports (each backed by an ODCS contract), a data pipeline materialized by a software bill of materials (SBOM), and governance checkpoints.

Most organizations discover metadata management the hard way: after the AI model fails, after the migration breaks, after the disastrous audit finds gaps no one knew existed. Data contracts and data products flip that script. They embed metadata from day one: lineage, quality rules, ownership, SLAs, and semantic context, all versioned and machine-readable. You don’t bolt governance onto chaos; you build on a foundation that was governed from the start. And you evolve with it.

That’s not a theoretical distinction: It’s the difference between successful organizations and those that struggle. Actian has been in the metadata business for over 40 years. We know what it takes to make data not just stored, but understood.

ODCS defines the promise. ODPS defines the delivery. Both are free to use. 

Getting started: 5 steps to your first data product 

Skip the framework, and start with the data contract. You don’t need both data contracts and data products on day one. Here is what actually works.

1. Pick your three most-consumed data assets: Assign a human owner (not a team) to each. If a person who can take accountability does not exist, you do not have a data asset; you have a liability.
2. Write a minimal ODCS contract for each: It’s about clarity, speed, and iterability. It can be as simple as five fields and one table. And in under 30 minutes, you get both a contract and a product.
3. Graduate to ODPS: Once contracts are stable, add the ODPS wrapper for lifecycle management, port definitions, and full product governance.
4. Store it in Git next to your pipeline code: The contract belongs in version control next to the pipeline that produces it. Schema drift becomes visible. Change history is auditable, exactly like code.
5. Measure consumption: Not just production. Track reuse, downstream adoption, and business impact: every new consumer is proof that your organization is building a data culture, not just a data catalog.

The regional divide: Different pace, same destination 

North America leads Europe in data product adoption and AI deployment. According to the same BARC survey, only 70% of European respondents have shipped an AI project vs. 86% in North America. This gap has been consistent since the earliest days of the GenAI wave.

The reasons are structural as much as cultural. As someone who holds both a French and an American passport, I’ve seen these instincts from the inside. European organizations operate under heavier regulatory frameworks (GDPR, the EU AI Act, sector-specific mandates) that reward thoroughness over speed: govern before scaling, design before shipping. North American teams, shaped by lighter regulatory pressure and stronger venture-backed urgency, favor a different rhythm: ship something small, own it, improve it. Both instincts are rational, and the best organizations borrow from each. 

Globally, the industries with the strongest compliance cultures like insurance (64%) and financial services (57%), are leading the adoption of data products. Compliance turned out to be an accidental data product accelerator, and data governance might become an unexpected competitive advantage.

The takeaway for any organization, regardless of geography or industry, is that deliberate governance and a bias toward action are not mutually exclusive. The data product model demands both.

The bottom line

Organizations treating data as a product ship more AI, trust their data more, and outperform peers.

The tooling exists, from startups to recognized leaders. The standards are open. What is missing is not permission; it is the decision to start. Once you create your first data contract and data product, everything else follows from there.

A data contract is not a bureaucratic artifact. It is a promise, made explicit, versioned, and enforced by tooling rather than by trust. 

About the Author:

Jean-Georges “jgp” Perrin is passionate about data. He is a member of Actian’s CTO Office and provides thought leadership on data contracts, data products as well as emerging database innovations.

As chair of the Linux Foundation’s Bitol project, he leads the development of open global standards for modern data engineering, including the Open Data Contract Standard (ODCS) and the Open Data Product Standard (ODPS).

With more than 25 years of IT experience, Jean-Georges is the author of multiple O’Reilly and Manning titles on data mesh, Apache Spark, and architecture modernization, and is currently completing Building Data Products (O’Reilly). He has been recognized as a Lifetime IBM Champion and has spoken at more than 190 international conferences.