GenAI on AWS for legal — accuracy, privilege, and the reference architecture.

IWhy legal GenAI is different — accuracy and privilege come first

Generative AI in a legal setting is governed by two constraints that override everything else: an answer has to be correct and verifiable, and the data behind it has to stay confidential and privileged. Get those wrong and the tool is not merely unhelpful — it is a malpractice and disclosure risk. Every architecture decision on this page flows from those two constraints.

In most domains a generative-AI feature that is right 90% of the time is a clear productivity win. In law it can be unacceptable, because the 10% includes confidently-worded answers about obligations, deadlines, liability, and case law that a lawyer may rely on. The widely-reported incidents of practitioners citing cases that a model simply invented are the canonical failure mode: a fluent, authoritative-sounding answer with no basis in any real source. The legal profession's response — and the only defensible engineering response — is that a legal GenAI system must ground every answer in authoritative source material and cite it, and a qualified human must remain accountable for the output. The model drafts and retrieves; the lawyer decides.

The second constraint is confidentiality and privilege. Client documents, matter files, deal-room contents, and work product are confidential, frequently privileged, and often subject to contractual or regulatory data-handling obligations. A system that sends these to a third party that trains on them, or that stores them where they can leak across matters or clients, breaches the duty of confidentiality before it answers a single question. This is exactly why so many legal and legaltech teams build on Amazon Bedrock: prompts and outputs are processed inside your own AWS account and Region, are not used to train the base models, and are not shared with the model providers — so the foundation model can read a privileged contract without that contract leaving your control or improving someone else's model.

The third, quieter constraint is auditability. Regulators, courts, clients, and the firm's own risk function increasingly expect to know how an answer was produced: which documents informed it, who reviewed it, and when. On AWS this is native — AWS CloudTrail records every model call and Bedrock model-invocation logging can capture the full prompt and response — so the firm can answer "where did this come from and who signed off" rather than pointing at an opaque black box.

The rest of this page is the legal-specific reference for satisfying those constraints: the use cases that pay off (§II), the accuracy and hallucination-control discipline (§III), the confidentiality and privilege controls (§IV), why human-in-the-loop is non-negotiable (§V), the end-to-end reference architecture (§VI), the build-vs-buy decision for legaltech (§VII), and what it costs (§VIII).

IIThe legal GenAI use cases that actually return value

The productive applications of GenAI in legal work are well established and they share a shape: they retrieve from a defined body of documents and produce a cited, reviewable output, rather than answering open-domain legal questions from a model's memory. Five recur across firms and legaltech products.

Each use case below is, under the hood, retrieval-augmented generation pointed at a legal corpus — which is why the same AWS building blocks (parsing, retrieval, generation, Guardrails, citations) serve all of them. What differs is the corpus, the prompt, and the reviewer workflow.

IIIAccuracy and hallucination control — the non-negotiable for legal AI

Hallucination — a fluent answer with no basis in any real source — is the single biggest barrier to legal AI adoption, and the failure that has produced sanctioned filings and disciplinary headlines. The engineering response is not "use a smarter model"; it is a stack of controls that keep the system grounded, cited, and honest about what it does not know.

Five controls compose into a defensible accuracy posture. None is sufficient alone; together they make a confident fabrication about a legal point very hard to produce and easy to catch.

• Retrieval over generation — ground in the firm's own sources — The first and most important control is architectural: answer from retrieved authoritative documents, not from the model's parametric memory. Open-domain legal questions are where invented case citations come from; a RAG system that retrieves from a curated corpus and is instructed to answer only from it cannot cite a case that is not in the corpus. Grounding is the foundation every other control builds on. See RAG on AWS.
• Mandatory citations on every answer — Every answer must carry a citation to the exact source — document, page, and ideally the quoted clause — so a lawyer can verify before relying on it. In legal work, citations are not a nice-to-have; they are the product. Amazon Bedrock Knowledge Bases returns citations natively, and a DIY pipeline produces the same by carrying each chunk's source metadata through to the response. For exact-wording matters (contract terms, statutory language), instruct the model to quote and cite rather than paraphrase.
• Bedrock Guardrails — contextual grounding + relevance checks — Amazon Bedrock Guardrails includes contextual grounding checks that score whether an answer is actually supported by the retrieved source and whether it is relevant to the question, and can block or flag answers that fall below a threshold — a programmatic second line of defence against hallucination on top of prompt discipline. Guardrails also filter harmful content and redact or block sensitive data. See Amazon Bedrock Guardrails.
• Grounding discipline in the prompt — admit uncertainty — The generation prompt must instruct the model to answer only from the supplied passages and to say "I could not find this in the provided materials" when the retrieved context does not contain the answer. In law, an honest "not found" is vastly safer than a confident guess. Passing only high-precision, re-ranked passages keeps the model from being led astray by loosely related text.
• Evaluation — prove faithfulness with a number — Build a fixed evaluation set of real legal questions paired with the correct answer and the source passage, and score faithfulness (does the answer follow from the cited sources without adding unsupported claims?), answer relevance, and retrieval precision/recall on every change. Amazon Bedrock includes RAG evaluation (LLM-as-a-judge over a supplied dataset); open-source frameworks like Ragas do the same for DIY pipelines. A new model or chunk size must prove itself with a score, not a demo.

IVConfidentiality and privilege — keeping client data protected

A legal GenAI system handles privileged, confidential, and often contractually-restricted material. The duty of confidentiality means the architecture must guarantee that client data is not used to train anyone's model, does not leave an approved jurisdiction, is encrypted, and is only ever accessible to those entitled to it. On AWS these are concrete, evidenceable controls rather than promises.

Five controls cover the confidentiality and privilege requirement, and they map directly onto the questions a firm's risk and information-security functions will ask before any matter data touches the system.

• No training on your data — privilege preserved — Amazon Bedrock does not use your prompts or completions to train the base foundation models, and does not share them with the model providers. A privileged contract or memo can be read by the model to answer a question without that content ever improving a third party's model or leaving your control. This is the property that makes sending privileged material to a foundation model defensible — it is processed for your request and not retained for training.
• Data residency — process only in approved jurisdictions — A Bedrock request is processed in the AWS Region you call, so EU matter data stays in EU Regions, UK data in the UK, and so on — which is how cross-border and data-localisation obligations are satisfied. Where cross-region inference is used for capacity, it routes only within a defined geography. Service Control Policies that deny Bedrock outside an approved Region list turn residency from a convention into a hard guarantee.
• Access control — matter and client walls at retrieval — The same system that answers questions about one client's matter must never surface another client's documents — the digital equivalent of an ethical wall. Enforce this at retrieval: tag every chunk with matter/client/role ACL metadata at index time and filter every query by the authenticated user's entitlements, so a user can only ever retrieve what they are cleared to see. Bedrock Knowledge Bases supports metadata filtering; for hard isolation, separate clients into separate knowledge bases or indexes.
• Encryption + key control — Encrypt documents and vector stores with AWS KMS, using customer-managed keys where the firm wants to hold and rotate the keys itself. Keep the original documents in Amazon S3 behind IAM and bucket policies so even a citation deep-link is authorization-checked. Traffic to Bedrock can be kept off the public internet with AWS PrivateLink, which regulated and security-conscious firms frequently require.
• Retention, logging, and auditability — Control what is retained: configure Bedrock model-invocation logging deliberately (capture for audit where required, restrict or disable where retention of privileged prompts is undesirable), and centralize CloudTrail and logs into a locked archive so there is an immutable record of who asked what and which documents were used — the evidence a court, regulator, or client may ask for, and the basis of the firm's own oversight.

VHuman-in-the-loop — why a lawyer stays accountable

No legal GenAI architecture is complete without a human in the loop, and not as a courtesy: a qualified lawyer remains professionally accountable for advice and filings, regardless of what tool produced the first draft. The system's job is to make that review fast and well-evidenced, not to remove it.

The professional reality is that responsibility cannot be delegated to a model. Courts and bar bodies have been explicit that a practitioner who relies on AI-generated content is responsible for verifying it; the sanctioned-filings cases turned on lawyers failing to check what a model produced. So the design goal is not autonomy — it is assisted review: surface a drafted answer or document together with the citations and the source passages, so a lawyer can confirm or correct it in minutes rather than reconstruct it from scratch. The faster and better-evidenced the review, the more value the tool delivers without ever crossing into unsupervised practice.

Concretely, human-in-the-loop shows up as design decisions throughout the stack. Outputs are framed as drafts and findings, not final advice. Every answer links to its sources so verification is one click, not a re-research. High-stakes actions (sending a draft, finalising an extraction used in diligence) require explicit sign-off, captured in the audit log with the reviewer's identity. Confidence is communicated honestly — including the model declining to answer when grounding is weak — so reviewers focus attention where the system is least certain. The interface is built to make checking the work effortless, because a tool that is hard to verify will either be misused or abandoned.

This is also where the build-vs-buy and partner decisions matter: a well-designed legal GenAI workflow encodes the firm's review process — who approves what, what gets logged, how exceptions are handled — rather than treating oversight as an afterthought. A partner experienced in regulated and legal workflows designs the human checkpoints in from the start, which is both a quality and a defensibility win.

VIThe reference architecture for legal GenAI on AWS

Pulling the use cases, accuracy controls, and confidentiality controls together yields one coherent reference architecture. It is a grounded, cited, access-controlled RAG pipeline over a legal corpus, built on Amazon Bedrock, with Guardrails and human review wrapped around it. The same shape serves contract review, clause extraction, research, diligence Q&A, and drafting — only the corpus and prompt change.

Split the architecture into an offline indexing path (run when documents are added or change) and a real-time query path (run on every question), with governance and human review spanning both. The stages map cleanly onto managed AWS services, and the whole pipeline can be assembled with Amazon Bedrock Knowledge Bases for the managed path or hand-built for control.

VIIBuild vs buy — point solutions, platforms, or your own

Legal teams face a real build-vs-buy choice: adopt an off-the-shelf legaltech product, deploy a horizontal assistant, or build a bespoke system on AWS. The honest answer is a portfolio decision driven by differentiation, data sensitivity, and how much the workflow is your own.

For commodity, horizontal productivity — drafting routine correspondence, summarising a document a user pastes in, general research starting points — buying is often right, and an off-the-shelf assistant or a vetted legaltech point solution gets there fastest. The caution specific to legal is data handling: before sending client material to any third-party product, confirm it does not train on your data, where it processes and stores it, and what its confidentiality and retention terms are. A tool that is convenient but trains on privileged documents is disqualified regardless of features.

For differentiated, proprietary-data, or high-sensitivity work — a firm-specific contract-analytics capability over your portfolio, a research assistant grounded in your own precedent and approved authorities, a diligence platform that must enforce your matter walls and audit requirements exactly — building on Amazon Bedrock is the durable choice. You keep client data in your own account under your own controls, you ground answers in your authoritative corpus rather than a vendor's, and you own the workflow and the roadmap. This is where the reference architecture above earns its keep, and where a vetted AWS partner with legal-domain experience materially compresses the build.

Many legal organisations land on a hybrid: buy for broad productivity, build on Bedrock for the differentiated, confidential, workflow-specific capabilities that are core to the practice — all under one AWS identity, billing, and compliance boundary so confidentiality and audit are consistent across both. The decision rule is the same one that holds across enterprise GenAI; the legal twist is that data sensitivity can force "build" even for a capability that would otherwise be a "buy", because keeping privileged data in your own AWS account is itself a requirement.

VIIIThe legal GenAI cost stack on AWS — where the money goes

A legal GenAI system's bill has the same shape as any document-grounded RAG system, with one line that bites harder in legal: parsing. Contract portfolios and data rooms are large and scan-heavy, so per-page parsing at index time can dominate the upfront cost. Here is the full stack and the lever on each.

The figures below are representative as of 2026 to show the shape of the bill, not a quote — always check the AWS pricing page for current rates. Upfront, parsing and embedding dominate (both scale with corpus size and run mostly once); at steady state, generation tokens and the always-on vector-store baseline dominate. The general levers — model routing, batch (~50% off), prompt caching, and re-ranking to a few tight chunks — all apply; the legal-specific discipline is to match the parsing method to the document so a 50,000-contract portfolio does not get the most expensive parser on every page.