Why most generative AI applications expire shortly after the project that built them wraps up
A Data Project is a time-boxed initiative that delivers a dataset or a pipeline for a specific use case and is considered done once it ships. A Data Product is a data asset with a permanent domain owner, an explicit quality and freshness contract, and a stable, discoverable consumption interface.
Enterprise LLM systems, especially RAG systems and AI agents, need Data Products, not Data Projects, because they depend on source data staying fresh, correct, and accessible on an ongoing basis, long after the team that built the pilot has moved on to something else.
This paradigm shift is the same one at the heart of the Data Mesh approach: treat data as a product with real consumers, not as the by-product of a project that’s already been closed out.
A generative AI pilot doesn’t stop working because the model gets worse. It stops working because the data feeding it keeps aging after the project has already been closed.
It’s common for a company’s first generative AI pilot to work well. Someone hand-picked the right documents, cleaned them up, and built an index that answered demo questions reasonably well. The problem shows up six months later: the source documents have changed three times, nobody has regenerated the index, and the system’s answers start drifting quietly out of date, until a customer or an employee notices before anyone else does.
The pilot didn’t fail because of the model. It failed because no one was formally responsible for keeping the data current once the project was over.
Before generative AI, this same pattern (data prepared for a one-off project that degrades over time) already existed, but its consequences were less visible: an outdated dashboard is noticed the moment someone looks at it; an outdated knowledge base inside a RAG system generates incorrect answers with the same confidence as correct ones, something we covered in detail when we looked at the most common mistakes when implementing generative AI in companies. Generative AI doesn’t create this problem: it makes it visible, expensive, and, in regulated industries, potentially serious.
A Data Project is an initiative with a start date and an end date, aimed at delivering a specific outcome: a pipeline, a clean dataset, a first index for a RAG pilot. Its typical characteristics:
None of this is an execution error: it’s simply what a project is, by design. The problem shows up when a project’s output is expected to behave like permanent infrastructure without having been designed as such.
A Data Product is a data asset managed with the same discipline as a software product: it has an owning team, treats its consumers as internal customers, and carries an explicit commitment to its quality and availability. Its defining characteristics:
A RAG system is only as good as the index it retrieves from. If that index was built once, for a pilot, and no one has the formal responsibility to regenerate it as source documents change, answer quality degrades silently: the system keeps responding with the same confidence, but with increasingly outdated information.
Once an organization starts building several agents or generative AI applications, it’s common for multiple ones to need the same knowledge base: internal policies, product catalog, support documentation. If that base was treated as the output of an isolated project, every new consumer adds a fragile dependency on something no one actively maintains; if it was treated as a Data Product, every new consumer simply plugs into a stable, already-governed interface.
The team building agents or generative AI applications is rarely the natural owner of the source data (HR, sales, support, legal). When maintaining that data isn’t assigned to a domain owner, it ends up falling, in an unplanned way, on the AI team, which has neither the business context nor should be spending its time on data quality work instead of building capabilities.
Do your agents or generative AI applications depend on data no one is formally responsible for maintaining?
At Galde, we help turn critical data sources into Data Products with ownership, a quality contract, and a stable consumption interface, built to sustain generative AI use cases over the long term.
Through data governance, we help define ownership, quality contracts, and cataloging so critical data sources stop depending on any one person’s memory.
Through generative AI, we design RAG systems and agents to consume those Data Products through stable interfaces, instead of coupling directly to source systems.
And through data platforms, we build the infrastructure (pipelines, versioning, consumption monitoring) that makes it possible to keep those Data Products alive without maintenance falling informally on a single team.
The difference between an organization that scales its generative AI and one that collects pilots that stopped working rarely comes down to the model. It comes down to whether the data feeding those systems is managed as a Data Product, with an owner, a contract, and a stable interface, or as the already-closed output of a Data Project no one has a mandate to keep maintaining. Adopting the product paradigm isn’t a theoretical naming exercise: it’s what determines whether an enterprise LLM system is still reliable a year from now.
A Data Project has a delivery date and is considered finished once it’s completed. A Data Product has a permanent owner, an explicit quality and freshness contract, and is maintained and evolved continuously, just like a software product.
No. You can start by treating your two or three most critical data sources for generative AI as products (assigning an owner, a contract, and a catalog entry) without redesigning your entire data organization around all four Data Mesh principles from day one.
Because the index they retrieve from degrades silently as source documents change and no one has the formal responsibility to regenerate or update it. The system keeps responding with the same confidence, but with increasingly outdated information.
Ideally, someone from the business domain that naturally generates or manages that data (HR for internal policies, support for product documentation), not the AI or data team, which are consumers of the product, not its source of business knowledge.
A simple question reveals it: if the data source changes tomorrow, is there someone with explicit responsibility for updating it and notifying whoever consumes it? If the answer is no, or “depends on someone remembering,” it’s still a Data Project.
