The previous chapter built a working system. Everything here is what separates that from something you can put in front of an organisation — and almost none of it is about models.

In a demo everyone sees everything. In a company, an HR investigation, a redundancy list, a salary band and a board pack all sit in systems your index would happily read. Retrieval does not inherit your access control. Somebody implements it, per query, per user.

Pre-filtering is the correct default, and it has one requirement: every chunk must carry the groups permitted to read it, captured at ingestion and indexed so it can be filtered on cheaply. The query then intersects the asking user's group memberships with that field, as in the SQL in the previous chapter.

• Store group identifiers, not user identifiers. Groups change far less often than membership, so a joiner or leaver becomes a change in your identity provider rather than a re-index of the corpus.
• Resolve the user's groups at query time, from the identity provider or a short-lived cache — not from a session token issued hours ago.
• Deny rules need explicit handling. Many source systems have them; a simple ‘allowed groups’ array cannot express them. Decide deliberately whether to model denials or to exclude documents that carry them, and write the choice down.
• A late authority check — re-verifying the final few chunks against the source system before they enter the prompt — is the belt-and-braces option. It costs latency on a handful of documents rather than thousands, and it closes the window between a permission changing and your index learning about it.

Demos ingest a folder of PDFs. Production ingests systems that were not designed to be ingested.

An index is a copy of your data, and copies drift. Four things need an owner, and if you can answer these four questions you have a real system:

• Freshness. How long between a document changing and the index reflecting it? Nightly is usually fine for policy; near-real-time is needed for anything operational. Use the source system's change feed rather than re-crawling everything — Graph delta queries, database change tracking, webhooks.
• Deletion. When a document is deleted or reclassified, what removes it, and how fast? This is the question that fails audits, because deletion is almost never implemented at the same time as ingestion.
• Reindexing. Changing the embedding model means re-embedding everything. Plan for it: build so you can index into a new table and switch over, rather than mutating the live one.
• Right-to-erasure. If a person can demand deletion of their data, you must be able to find and remove every chunk derived from it. That requires the link from chunk back to source record — which is a schema decision, made at the start or not at all.

A production retrieval system is usually four services, and naming them separately is worth doing because they scale and fail differently:

• The ingestion workers — scheduled, batch, tolerant of being slow. This is where most of the code lives and most of the bugs.
• The store — vectors, text, metadata and access control together.
• The retrieval service — takes a question and a user identity, returns ranked permitted chunks. Keep this separate from generation; it is independently testable, independently useful, and the thing you will replace least often.
• The generation service — assembles the prompt and calls the model. Behind an AI gateway if you have one.

Log the retrieved chunk identifiers alongside every answer. Without them you cannot reproduce a bad answer, and reproducibility is the fifth of the five audit questions in the foundations chapter. It is one column, added at the beginning or painfully later.

Every major cloud sells a managed version, and there are dedicated products. The decision turns almost entirely on connectors and permissions rather than on retrieval quality.

Retrieval costs are usually dominated by things people do not expect:

• Embedding the corpus once is a real but one-off cost, and it is small compared with re-embedding it every time someone changes the model.
• Query-time embedding is trivial. One short embedding per question.
• The generation call dominates, and its cost is driven by how much context you paste in. Retrieving 20 chunks instead of 5 quadruples your bill and usually makes answers worse, because the relevant passage gets buried. Reranking is a cost reduction as well as a quality gain.
• Storage is cheap; RAM is not. See the internals chapter — keeping a graph index resident is the constraint that decides your hosting bill.

• Permissions bolted on afterwards. The pilot ignores them, then adding them means re-ingesting everything and the project restarts.
• Obsolete documents cited confidently. No date filtering, no date shown.
• No evaluation set, so every change is argued about rather than measured.
• Retrieval quality blamed on the model. Months spent switching models when recall@10 was 0.6 the whole time.
• Deletion never implemented. Discovered by an auditor.
• Everything indexed because it was possible. A larger index is not a better one — it is more chances to retrieve something irrelevant, and a larger surface to govern. The best-performing systems are usually the ones with the most restraint about what went in.
• Retrieved text treated as trusted input. It arrives in the same channel as your instructions, so a document containing instructions is an attack — see prompt injection. If the corpus contains anything user-submitted, this stops being theoretical.