Answer quality is decided in the library, not the model
When a retrieval-augmented system gives a wrong answer, the instinct is to blame the model or switch embedding providers. The mechanism usually sits earlier. Retrieval surfaces whatever in the corpus looks most similar to the question; the model then summarizes it fluently. If the corpus contains three conflicting versions of the travel policy, the system will confidently retrieve one of them, and no model upgrade will fix that. A wrong answer built on the wrong source is a library failure, not an intelligence failure.
The useful discipline is to treat every source as a product decision. Before any platform comparison, ask two questions per document set: is this approved as something the system may answer from, and who is accountable when an answer built on it turns out wrong? A document set that cannot pass both questions does not belong in the index, however rich it looks. A smaller corpus with named owners beats a full intranet crawl, because every bad answer traces back to a source someone can fix. An unowned corpus only produces unownable answers.
The copilot must not know more than the person asking
The classic failure mode has a simple mechanism. The indexing pipeline reads documents with a broadly privileged service account; the query side then answers everyone from the same index. An analyst asks about a pending reorganization and receives a helpful synthesis of documents they could never open themselves. RAG rarely leaks files. It leaks summaries, which are harder to notice and easier to forward. The cost is organizational, not technical: a single incident is enough to put the copilot's legitimacy in question across the company.
Permission-aware retrieval is therefore a first-class design requirement, not a hardening step. Evaluate permissions at query time against the asker's identity, before generation; roles change and documents get reclassified, so permissions frozen at indexing go stale. Filter what is retrieved, not just which links are shown, and design an explicit no-answer path for when everything relevant sits above the asker's clearance. A simple acceptance test: the same question from two accounts with different clearance must produce different behavior.
An answer from last year's policy is a confident lie
Consider a hypothetical HR copilot that answers a remote-work question from version three of the policy while version five is in force. The answer is fluent, cited, and wrong. This is the system at its most dangerous, because the error is discovered only through its consequences. The mechanism is corpus drift: enterprise documents are superseded far more often than they are deleted, and similarity search has no concept of current. Without lifecycle rules, the index quietly accumulates every version ever published.
Every source therefore needs a lifecycle: an effective date, what it supersedes, a review owner, and a review or expiry date. Re-index on change, remove superseded versions from default retrieval while keeping them for audit, and show the document's date inside the answer. Even a one-line note such as ‘based on the procedure dated March 2025’ prompts the user to ask the right question. The decision rule is blunt: if nobody can say which version of a document is authoritative, that document is not ready to be a source.
Citations are the trust interface, not a footnote
Users do not trust a system because it is usually right; they trust it because they can verify it when the stakes are high. That makes passage-level citation part of the core product, not decoration. An answer that cannot be traced to its source is, in an enterprise setting, a well-formatted rumor. Citation is also measurement: heavy click-through to sources early in a rollout signals healthy verification, and declining click-through on stable topics later signals growing trust. Both say more than a satisfaction survey.
Grounding is the matching discipline on the generation side. The system should answer only from what it retrieved, state plainly when evidence is thin, and escalate rather than improvise. 'I found two conflicting procedures; here are both, and here is the content owner' is a more valuable answer than a smooth merge of the two. A refusal that routes the user to the right person beats a fabricated synthesis every time.
Sometimes the right decision is not to build RAG yet
Three conditions disqualify a RAG project honestly. A thin corpus: if the real knowledge lives in a few dozen documents, well-structured search or a maintained wiki page may serve better than a retrieval pipeline. A chaotic corpus: duplicates, conflicting versions, and ownerless content mean RAG will amplify the chaos at conversational speed. And unresolved ownership: if no function will own source approval and corrections, wrong answers have no fix path, and trust collapses within weeks of launch.
None of these are reasons to abandon the goal; they describe the actual first project. Deduplicating content, assigning owners, and writing the access policy is Map and Prioritize work, and it pays off even if a copilot never ships. Building RAG on an ungoverned corpus does not solve a document mess. It converts it into an answer mess with a friendlier interface.
Prove it in one department with a bounded source set
A production-shaped pilot for a knowledge system is narrow on purpose: one department, an approved and bounded source set, real users, and explicit pass criteria. Have the department's experts write the evaluation set before the system exists, using real questions with defined acceptable answers, so quality is judged against the job rather than against demos. Test permission behavior from different roles, and rehearse the escalation path as deliberately as the happy path. The intended system pattern is role-aware, source-citing, and explicit when evidence is insufficient.
Measure behavior, not sentiment: time to reach an answer, resolved-request rate, source-opening patterns, and correction reports, with expert review of critical answers. The next step then follows this article's own argument. Before evaluating a single platform, inventory the candidate corpus, name its owners, and write the access policy. Once those exist, a controlled pilot will tell you quickly and honestly whether the answers earn trust.