RAG is not a product.

A technical flow is not a user outcome

RAG answers whether relevant information can be retrieved and supplied to a model. The user asks whether they can reach the right information, with the right permission, and trust it enough to make a decision.

The gap is defined by product choices: scope, freshness, refusal behaviour and the feedback path when the system is wrong.

Think of an assistant that answers HR policy questions. It takes the question, finds the right document and writes the answer. But when an employee asks "can I carry over my annual leave?", which location and which contract type does that answer apply to? If the flow does not know, the answer can be technically correct and still wrong for that user.

Enterprise knowledge is more than content

Access to a document does not mean every fragment should be visible to everyone. Permissions may be required at user, group, source or sensitive-section level.

Security is therefore not a filter added at the end; it is a starting condition of the product experience.

This is usually where RAG projects get stuck. Everyone says "let us load the documents", but nobody is quite sure who can open that document today and with what permission. Accidentally including a folder with the salary sheet is enough to end trust in a RAG project in a single day.

What contracts taught me: data preparation is the real work

We went through this while working on contracts. In the pilot, with a few clean contracts, everything was great. When we moved to a wider set of data, we found Word files, signed PDFs and contracts that had been renewed for years whose linked information was nowhere in the shared folders. Even when information was missing, the model tried to give an answer; in other words, it guessed.

The fix was not a different model. We prepared the data first: we collected files from the shared folders, checked them against our criteria and cleaned them, with help from the models. We revisited the chunk settings and built separate processing for PDFs and for Word and Excel files. That was the longest part. Going live turned out to be the easiest.

Attribution is only the beginning of trust

Users should see which source and passage support an answer. Attribution, however, is not a guarantee of truth. Stale, conflicting or ownerless content can still lead to a wrong decision even when it is retrieved correctly.

A RAG initiative is also a knowledge ownership and content-lifecycle initiative.

An old document leads to a wrong outcome even when it is retrieved correctly. That is why every source needs an owner and a last-updated date. If the source list cannot answer "who owns this document?", my advice is to leave that source out of scope.

The product begins after the answer

A technical flow starts becoming a product when quality evaluation, feedback, access policy, cost, latency, monitoring and operational ownership become visible.

The first question should therefore not be which vector database to use, but whose decision we are helping make more reliable.

For me the first question is still the same: whose decision does this system make easier? If the answer is "everyone's every question", the scope is too wide. Starting with a narrow goal, like the sales team finding the pricing policy while preparing an offer, makes both measurement and trust easier.