RAG for Legal Documents: Search and Summaries With Expert Review

A legal-document RAG assistant can help a team locate the current clause, policy, precedent note or matter record and prepare a cited summary for a qualified reviewer. It must not decide legal meaning, approve a contract, advise a client, or treat a retrieved passage as a conclusion. The safe output is an evidence packet: the request, the permitted sources, exact locators, uncertainty and a route to the responsible expert.

This article describes LEGAL-EVIDENCE-9, a narrow engineering contract for controlled legal-document retrieval. It is not legal, compliance, privacy or professional advice. Requirements depend on the organization, matter, jurisdiction and professional obligations. For the broad retrieval architecture, see the RAG systems service; for project evidence and delivery boundaries, see case studies.

Start with a legal workflow, not a document dump

“Search all legal documents” is not a pilot scope. A useful scope names the user, the permitted corpus, the question type, the reviewer and the stop condition. For example: help an in-house team find the latest approved supplier-template clause and produce a comparison draft with citations. It does not decide whether that clause is appropriate for a transaction.

This boundary makes the system useful without disguising model fluency as professional judgment. It also gives reviewers a practical way to challenge the draft: open the source, inspect its revision and see what the system did not find.

The industry process: intake, evidence, review and record

Legal work often begins with a request that is incomplete: a business owner asks what a clause means, whether a template applies, or what changed between two versions. Documents may be matter-specific, privileged, confidential, versioned, signed, scanned or subject to a retention rule. Retrieval therefore needs a process before it needs ranking.

LEGAL-EVIDENCE-9 uses nine stages:

1. Receive a request with authenticated actor, matter or workspace, purpose, jurisdiction label where applicable and requested document type.
2. Scope the permissible corpus using server-trusted role, matter membership, ethical-wall or confidentiality policy, and retention state.
3. Register sources with immutable ID, owner, version, effective period, status, access class and stable page or clause locator.
4. Retrieve only eligible passages; preserve their source identity and revision rather than copying unsupported context into the prompt.
5. Compose a bounded evidence packet that distinguishes quotation or summary, uncertainty and missing sources.
6. Check citation coverage, conflicts, superseded versions, access state and whether a request crosses into a legal conclusion.
7. Route the packet to the named qualified reviewer, or return no-answer / access-denied / conflict route.
8. Record a minimal review receipt: sources used, policy version, reviewer decision and unresolved questions.
9. Reconcile source changes, revocations, deletions and evaluation failures before later reuse.

request + trusted matter scope
  -> permitted source registry
  -> versioned retrieval with locators
  -> cited evidence packet
  -> legal-review / no-answer / denied route
  -> minimal review receipt and lifecycle reconciliation

The source registry is the key control. A document’s title alone is not enough: two files with the same template name can have different effective dates, owners, audiences or replacement state. The separate guide on RAG index updates, versions and removal explains why a deletion in a source system must become an observable retrieval change.

Where RAG can help in a legal-document process

Start with tasks that create inspectable preparation work. The following seven use cases are examples to prioritise with the team that owns the documents and legal risk; they are not a claim that every organization should deploy them.

The first pilot should normally choose one of these lanes, one document family and a small reviewer group. A broad search across all contracts, email attachments and matter folders makes access, lifecycle and evaluation too difficult to prove at once.

Data and integration contracts

The technical design needs four explicit contracts.

1. Identity and matter scope. The browser must not choose a tenant, matter or privilege flag. A trusted server resolves actor, role, workspace, matter membership and any declared boundary before retrieval. A model never authorises its own context.
2. Source lineage. Every candidate needs a source ID, content revision or hash, owner, lifecycle state, document type, access class, effective dates and a stable locator. The index stores enough information to reproduce which version supplied a passage.
3. Evidence packet. The output keeps source citations separate from generated prose. It labels direct extract, paraphrase, unresolved conflict and missing evidence. It contains no automatic destination write.
4. Review receipt. The application records the review decision and policy or source version in a controlled system of record. It does not keep a full sensitive prompt transcript merely because it is convenient for debugging.

For personal or confidential material, decide the purpose, permitted fields, retention, deletion and vendor boundary before ingestion. Data minimisation and appropriate security are legal and organizational questions, not features a vector store confers automatically. The NIST AI RMF is a voluntary risk-management reference; its Govern guidance is useful for defining human oversight roles and maintaining auditability, but it does not replace a legal assessment.

A concrete input/output example

INPUT
Actor: authenticated in-house procurement counsel
Matter: supplier-renewal-2026 (server-resolved)
Question: What changed between the approved DPA template rev. 18 and rev. 19?
Allowed output: comparison draft with page locators; no approval recommendation

OUTPUT EVIDENCE PACKET
Sources: DPA-TPL-018 p.4-7; DPA-TPL-019 p.4-8; policy PRIV-12 rev.6
Observed changes: three cited text differences, each linked to its source page
Uncertainty: no approved negotiation note found for this supplier
Route: assigned counsel review before any external communication or redline

Notice what is absent: a conclusion that the new terms are safe, a decision to sign, a claim about the other party’s obligations, or a message sent to a counterparty. If the source set conflicts, a locator is broken, a document is superseded or the request lacks scope, the correct answer is not a smoother summary. It is a review, no-answer or fail-closed route.

Risks and limits that belong in the design

The main risk is not only hallucination. A perfectly quoted passage can be wrong for the matter, out of date, unavailable to the requester, incomplete in context or subject to a boundary the system did not model. Design for these failure modes:

• Wrong version: old template remains in the index after a replacement. Keep lifecycle state and test revocation retrieval.
• Wrong scope: a user sees a document from another matter or restricted workspace. Apply server-trusted access filtering before ranking and test denied retrieval separately.
• Lost context: a clause is summarized without its definitions, schedule or exception. Attach document and clause locators; let reviewers open the surrounding source.
• OCR or ingestion loss: scanned page numbers, tables or signatures are misread. Quarantine low-quality extraction and expose source-image review instead of treating parsed text as authoritative.
• Privilege or confidentiality boundary: a copied export crosses a policy line. Make the corpus allowlist and data path reviewable before ingestion.
• Over-reliance: a reviewer treats the draft as a conclusion because it reads confidently. Put uncertainty, citations and a named reviewer route in the interface.
• Silent lifecycle drift: a source is deleted or a policy changes after an answer is drafted. Revalidate source state before any reuse or external action.

These controls do not certify compliance or legal accuracy. They turn risks into testable system behavior and make it easier for the organization’s legal, privacy and security owners to set the real boundary.

A simple pilot ROI model without invented promises

Use a transparent estimate instead of a promise. Let N be reviewed requests per month, M the median minutes currently spent locating permitted documents, m the median minutes after the evidence packet, and R the monthly cost of review, maintenance and evaluation. The estimated capacity change is:

estimated_minutes_released = N × max(0, M - m)
pilot_value_question = estimated_minutes_released - R_in_minutes_equivalent

Measure this only from a defined pilot and keep the result separate from legal quality. A faster draft that causes more rework, wrong-scope retrieval or poor reviewer trust is not a useful gain. Track reviewer acceptance, cited-claim coverage, no-answer quality, denied-access tests, stale-source findings and time to correct a source issue.

Pilot acceptance criteria

Before expanding the corpus, test known-answer requests, no-answer requests, documents with revoked access, superseded templates, matter boundaries, conflicting versions, scanned documents and reviewer override cases.

The NIST AI RMF Playbook treats governance, documentation and evaluation as ongoing activities. That is a helpful engineering principle here: review and monitoring are part of operation, not a final checkbox.

Choose one controlled legal-document pilot

Choose a process where a qualified owner already reviews an output, the initial source set can be explicitly approved, and a no-answer is acceptable. Create a source registry, matter-scope rule, evidence-packet design, evaluation set, reviewer matrix, failure log and rollback plan. Only add more document families or integrations after the team can demonstrate correct scope, current citations and useful reviewer interaction.

If your team wants to scope an AI retrieval pilot around one controlled process, prepare a project brief. For a broader technical architecture conversation, see RAG systems. The goal is not a generic legal chatbot; it is a reviewable information workflow that helps experts find evidence while preserving their authority.