Enterprise RAG for Publishers: Build vs. Buy, Page Citations and Access Tiers

Enterprise RAG is a production system that retrieves passages from an organization's own documents and has a language model answer only from those passages, under the organization's access, security and quality rules. The basic pattern comes from a 2020 paper by Lewis and colleagues, which described models that "combine pre-trained parametric and non-parametric memory for language generation": the model's built-in knowledge plus a searchable store of documents.

"Enterprise" adds the requirements that a research pattern does not address. For a publisher or standards body, that list usually includes:

• Access control by tier. Public, member, corporate and add-on content must stay with the people entitled to it.

• Provenance. Each claim should point to a document, an edition and a page. The original RAG paper itself named "providing provenance for their decisions" as an open problem for language models.

• Honest limits. The system must decline when the content does not cover a question, instead of filling in from general training.

• Evaluation and release gates. A fixed set of questions should run before any change goes live.

• Security and audit. Every query, answer and tool call should be logged and exportable to your security tools.

• Deployment control. Many organizations need to choose where it runs and which model provider writes the answers.

If you want the conceptual foundation first, our explainer on what grounding in AI means covers how grounded answers stay tied to the source page.

Enterprise RAG differs from a RAG prototype in what happens when things go wrong: wrong person, wrong edition, missing content, a changed model. A prototype optimizes for good answers to known questions. An enterprise system optimizes for safe, testable behavior on unknown ones. If you only need the short version, the table below summarizes the gap.

An enterprise RAG architecture has seven layers: ingestion, indexing, access, retrieval, generation, policy and evaluation, with audit running across all of them. Each layer has a failure mode that shows up in production, so it helps to design them separately.

Ingestion and parsing

Ingestion turns your source files into clean text with structure intact. Standards and manuals are hard: multi-column layouts, tables, figures, footnotes and running headers. Keep the page number of every passage. Without it, page-level citations are impossible later.

Indexing and metadata

Indexing splits documents into chunks, usually by section, and stores them with metadata: document code, edition or revision, page, section number and access tier. Metadata is what lets the system answer "which edition?" and enforce "who may see this?" without guesswork.

Retrieval

Retrieval finds the passages most relevant to the question. Most production systems blend semantic search, which matches meaning through embeddings, with lexical search such as BM25, which matches exact words and codes. Anthropic's September 2024 report on contextual retrieval found that combining contextual embeddings with contextual BM25 reduced the top-20 retrieval failure rate by 49%, and adding reranking reduced it by 67%. For technical content full of section numbers and standard codes, the lexical half matters a great deal.

Access enforcement

The access layer decides which documents a person's search may touch. The safe pattern is to apply it before retrieval, as a filter on the index, so locked passages are never candidates. We cover the reasoning in the access section below.

Generation with citations

The model writes the answer only from retrieved passages, attaching a citation to each claim. The citation must come from the retrieval step, not from text the model generates, because NIST's Generative AI Profile notes that models can produce "confabulated logic or citations."

Policy

The policy layer applies your organization's rules: attach a warning to a topic, refuse a class of question, redact personal data, or block legal and tax advice. Policies need owners, and the owners are usually content or member services staff, not engineers.

Evaluation, gaps and audit

Evaluation runs a test set of real questions with expected behaviors before every release. Gap logging captures questions the library could not answer. Audit records every query, answer and action. Together they turn the system from a model you hope is right into one you can show is right.

Putting a whole library in a long context window does not replace retrieval, because accuracy, access control and cost all get worse as the context grows. Long context windows are useful, but they solve a different problem.

Three reasons stand out:

• Accuracy drops in the middle. The "Lost in the Middle" study by Liu and colleagues, published in Transactions of the Association for Computational Linguistics, found that model performance "significantly degrades when models must access relevant information in the middle of long contexts." A 300-page standard is mostly middle.

• Access control gets harder. If the whole library is in the prompt, every tier is in the prompt. You can no longer guarantee a public visitor's answer was not shaped by member content.

• Citations get looser. Retrieval gives you a known set of passages with page numbers. A long context gives you a model's recollection of where something was.

Long context is still useful after retrieval: once the right ten or twenty passages are found, a generous context lets the model read them in full.

You enforce access tiers in enterprise RAG by checking each person's grants before retrieval, so the search only runs over documents they are entitled to. Filtering after generation is weaker, because locked text may already have shaped the answer by the time you remove it.

The OWASP Top 10 for LLM Applications (2025) lists this risk as LLM08, Vector and Embedding Weaknesses. It warns that "inadequate or misaligned access controls can lead to unauthorized access to embeddings containing sensitive information," and that where several classes of users share one vector database, "there's a risk of context leakage between users or queries." Its recommended mitigation is "fine-grained access controls and permission-aware vector and embedding stores."

For a publisher or standards body, a practical access model has four parts:

• Tiers on documents. Every document carries a tag such as Public, Member, Corporate or an add-on module.

• Grants on people. Each person holds grants mapped from your membership system, delivered through single sign-on.

• Filter at query time. The search runs only over documents whose tier the person's grants open.

• An access note, not silence. When the answer sits in content the person cannot open, tell them which tier holds it. That is good service and a natural upgrade prompt.

The same rules must hold outside your website. If members can query the library from their own AI tools, each call should run with that person's grants, as shown on our AI tools access page.

The main security risks of enterprise RAG are data leakage across access tiers, prompt injection through documents, and actions taken without human approval. RAG reduces some risks of general chatbots, but it adds new ones because the system now reads your content and may connect to other systems.

• Sensitive information disclosure. OWASP ranks this second (LLM02:2025). In a member library, the most likely form is member content reaching a non-member's answer, which access before retrieval addresses.

• Indirect prompt injection. OWASP's LLM01:2025 entry notes that "indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files," and that research shows RAG does "not fully mitigate prompt injection vulnerabilities." Ingest only content you control, and treat retrieved text as data, not instructions.

• Excessive agency. If the assistant can open a ticket or change a record, a wrong answer becomes a wrong action. Drafted actions held for a named approver keep a person in the loop.

• Weak audit. Without a per-query log you cannot answer a member's complaint or a security review. Make audit export a requirement, not a feature request.

The NIST AI Risk Management Framework (AI RMF 1.0, January 2023) is a useful voluntary structure for organizing this work around its four functions: Govern, Map, Measure and Manage.

You evaluate an enterprise RAG system by running a fixed set of real questions, with the expected behavior for each person and tier, against every version before it goes live. Benchmark scores on public datasets tell you little about how a system handles your standards and your tiers.

1. Collect real questions. Pull 40 to 100 questions from member services, search logs and subject experts, including hard and out-of-scope ones.

2. Define expected behavior per tier. For each question and each type of person, record whether the system should answer with citations, give an access note, attach a warning or refuse.

3. Check every citation by hand once. Confirm the cited page actually supports the claim. This builds the answer key for automation.

4. Automate the run. Score each release on cited pages, refusals and access notes, not on how fluent the answer sounds.

5. Gate the release. If any test fails, hold the release and keep the current version live until it is fixed.

6. Feed gaps into the set. When members ask something the library cannot answer and you add content, add that question to the test set.

This is also the most reliable defense against a RAG hallucination after launch: a new model or prompt that starts guessing will fail a refusal test before members see it. Our guide on how to prevent AI hallucinations describes the full set of controls, and the content gaps page shows how unanswered questions become release tests.

You should build a RAG platform when AI search over your content is a core product you will staff for years, and buy one when you need tiered, cited answers in production without becoming a search engineering team. Most publishers and standards bodies sit closer to the second case, but not all.

Building makes sense when:

• You have a platform team. Engineers who already run search, identity and content pipelines can absorb RAG as another service.

• Your use case is unusual. Highly custom workflows or data types that no product handles may justify building.

• You need full control of every component. Some organizations must own the code for regulatory or strategic reasons.

Buying makes sense when:

• Time matters. Members are already pasting your PDFs into general AI tools, and a year-long build leaves that gap open.

• Access tiers are complex. Tier mapping, single sign-on and membership system integration are often harder than retrieval itself.

• Your team owns content, not infrastructure. The people who should write policies and review gaps are editors and member services staff.

Whichever route you choose, ask these questions of the system: where is access checked, what does a citation point to, what happens when content runs out, how releases are tested, where it is hosted, and which model providers it supports. Our guide to building an AI chatbot with a knowledge base goes deeper on the build path, and our article on AI for publishers covers the commercial side of turning technical content into paid, cited answers.

Chairlift is an AI knowledge assistant built by Sphere for associations, standards bodies and technical publishers, and it packages the enterprise RAG layers described above. Each organization runs on its own instance and database, hosted in its own VPC or on its own servers, with single sign-on and an audit log. Sphere is provider-agnostic: you choose the model provider, including local models. Member tiers are enforced at retrieval, so locked documents are never searched for someone who does not hold them. Every claim is cited to the document and page, with the page beside the answer, as shown on our cited answers page. Content policies can warn, redact or block by topic, keyword or personal data. Requests that would change records become drafted actions with a dry run, held for a named approver. Members can reach the library read-only from their own AI tools through MCP, with their own token and grants. Each release runs a test set and is held if a question fails. The full flow is on how Chairlift works, and the answers to common security-review questions are on our trust and security page.

The organizations that get value from enterprise RAG are not the ones with the cleverest retrieval. They are the ones that decided early who sees what, what a citation means, and what the system says when the library is silent.