From MVP to Product: Why Generative AI Needs a Data Product

Quick Answer

Generative AI and RAG pilots usually work on a static copy of the data, selected and cleaned by hand for the demo. In production they fail because of what the demo does not show: documents change and the index does not, deletions never arrive, source permissions are not respected, nobody measures answer quality and nobody is responsible for maintaining the sources.

To sustain an AI application over the long term, its data sources must be managed as a Data Product: with continuous updates, a clear owner committed to freshness, systematically measured quality, permissions inherited from the source and a versioned index.

It is not a model problem, but a problem of how the data feeding it is managed. That is why it is solved by restructuring that data, not by switching models.

The pilot proved that AI could answer well. Production requires it to keep answering well when the data changes.

The story repeats itself in many companies. In six weeks, a team builds an assistant that answers questions about internal policies, procedures or the product catalogue. The demo impresses, and leadership decides to roll it out to the whole workforce. Three months later, the assistant quotes a policy that was updated in the spring, an employee receives excerpts from another department's document they should not see, the monthly cost has grown and, when something fails, nobody knows whose job it is to fix it.

The model is the same one that shone in the demo. What has changed is everything around it.

A generative AI MVP tests a hypothesis. A product has to keep a promise.

Why So Many Generative AI Pilots Never Reach Production

A pilot is designed to answer one question: can generative AI solve this use case? To answer it quickly, reasonable shortcuts are taken: the document set is exported once, cleaned by hand, indexed and evaluated with a handful of test questions. Those shortcuts are right for an experiment. The problem arises when the experiment simply becomes the system the whole company will use.

We have already looked at the most common mistakes when implementing generative AI in companies and what it takes to put it into production. In most cases, the breaking point is not the model but the data.

What Breaks When a RAG Pilot Moves into Production

The Data Ages and the Index Does Not

The index was built from a snapshot of the documents. Every updated policy, every new product and every revised procedure makes it a little more obsolete, and the system keeps answering confidently from out-of-date information.

Deletions Never Reach the Index

Even when a periodic load of new documents is added, deletions are often forgotten. A document withdrawn at the source stays in the index and keeps appearing in answers, sometimes for months.

Source Permissions Are Not Respected

In the pilot, every user was on the same team and could see everything. In production, each document has its permissions in the source system, and if the index does not inherit them, the assistant becomes a back door to restricted information. It is one of the risks we cover when discussing security and sovereignty in RAG architectures.

Nobody Measures Answer Quality

The pilot was evaluated with a few questions and the approval of test users. In production, there is no stable evaluation set and no metrics to warn if quality drops after a change in the sources or the system.

Nobody Owns the Sources

The team that built the pilot is usually the AI team, which is not the natural owner of HR, Legal or Support documents. When a source degrades, nobody has the formal responsibility to fix it.

Any Change Means Starting Again

Changing the embedding model, the way documents are split or the index structure means reindexing everything. Without versions, that change is made on the index in use, and answers change overnight without anyone being able to compare them or roll back.

What It Means to Manage Your AI's Sources as a Data Product

We have already explained in detail the difference between a Data Product and a Data Project. Applied to generative AI, it translates into five concrete properties:

• Continuous updates: ingestion is incremental and detects additions, changes and deletions at the source, with an agreed maximum delay between a change and its reflection in the index.
• An owner with a service commitment: each knowledge source has an owner in its business domain, who guarantees its freshness and accuracy, not the AI team.
• Measured quality: there is a representative set of evaluation questions and metrics calculated with every change, such as the rate at which the right passage is retrieved, the faithfulness of answers to the sources and the update delay.
• Permissions inherited from the source: each indexed passage keeps its document's permissions, and the system filters what it retrieves according to who is asking.
• Versioned index: changes of model, chunking or structure are built in a new version of the index, evaluated against the previous one and only replace the live version if they improve on it.

None of this requires a different model. It requires treating the data that feeds AI with the same discipline as any product used across the company.

How to Move from Pilot to Product in 60 Days

It is the same approach as our methodology: a production-ready data product in 60 days, with a technical sponsor dedicating two hours a week.

Days 1 to 15: Inventory of Sources and Owners

The sources feeding the pilot are identified, with their source system, their actual rate of change and their permissions, and each is assigned an owner in its business domain.

Days 16 to 30: Incremental Ingestion and Permissions

The manual export is replaced by incremental ingestion that detects additions, changes and deletions, and source permissions are attached to each indexed passage.

Days 31 to 45: Measure Quality

A representative evaluation set is built with users, and the retrieval, faithfulness and freshness metrics are automated so that any change can be compared with the previous situation.

Days 46 to 60: Version and Operate

The versioned index is introduced, along with freshness and quality alerts and the procedure for each owner to fix their source. From here on, the system is run as a product.

Is Your Generative AI Ready for Production?

Five questions are enough to tell:

• If a document changes today, how long does the assistant take to reflect it, and can you measure it?
• If a document is withdrawn at the source, does it also disappear from the answers?
• Does each user receive only information they could see in the source system?
• If you change the embedding model tomorrow, can you compare the answers before and after?
• If a source degrades, is there a person formally responsible for fixing it?

If any answer is no, the system is still a pilot, even if the whole company uses it.

How Galde Can Help Take Your Generative AI into Production

Through generative AI, we redesign the RAG system's architecture for production: incremental ingestion, inherited permissions, a versioned index and continuous evaluation. It is also the foundation for the next step towards agentic RAG.

Through data governance, we assign an owner to each knowledge source, define its freshness and quality commitments and register them in the catalogue.

And through data platforms, we build the pipelines, monitoring and alerts that sustain those commitments without manual intervention.

Conclusion

Most generative AI pilots do not fail because the model falls short, but because their data is still managed like an experiment's. Moving from MVP to product requires sources that update themselves, respect permissions, have an owner and are measured continuously. With that in place, AI stops being a demo that ages and becomes a system that improves over time.