Design a Compliance-Constrained Generation System
Explore how to design generative AI systems that are compliant with legal and medical regulations by enforcing evidence-backed outputs. Learn to architect pipelines that restrict evidence retrieval, generate structured claims, verify support, integrate human oversight, and maintain detailed audit trails, ensuring traceability, security, and policy adherence.
A legal or medical assistant becomes dangerous the moment it states something that cannot be traced to approved evidence. In an interview, that shifts the problem away from building a clever RAG bot and toward building a governed generation pipeline in which unsupported text is mechanically hard to produce.
Designing for evidence first
A compliance-constrained system starts with a simple rule. The model is not the source of truth. The approved corpus is.
That changes the request life cycle. The user does not ask a model for an answer directly. The request first enters policy checks, then retrieval restricted to approved documents, then a generation stage that must stay within those retrieved facts, and then a verification stage that can still reject parts of the draft before release.
Note: Agentic behavior still exists here, but the agent is fenced in by policy, evidence, and review checkpoints.
In practice, this design targets assistants for legal drafting, clinical summarization, benefits explanation, or regulated finance communication. These are not ordinary chat products. The system must reconstruct why a sentence was shown, which source version supported it, which model and prompt were used, and whether a human signed off.
System requirements
Requirements are stricter than normal RAG, so fix them before sizing anything.
Functional requirements
Traceability: Every claim must point to stable source identifiers, versions, and spans.
Source control: Retrieval must exclude unapproved material before ranking or synthesis occurs.
Auditability: Inputs, intermediate artifacts, and release decisions must remain reconstructable later.
Compliance: Policies must enforce disclaimers, jurisdiction limits, and refusal behavior for unsupported requests.
Human oversight: High-risk outputs require reviewer sign-off before release.
Nonfunctional requirements
Latency: Answers without human review return in seconds, and reviewed answers return a pending status instead of blocking.
Scalability: Serve about 20,000 sessions per day, with peaks around 5 times the average.
Availability: Fail toward safe behavior by refusing or holding an answer instead of releasing unverified text.
Reliability: Keep audit logs append-only and tamper-evident, with idempotent review actions.
Security and privacy: Enforce role-based access, encryption, tenant isolation, and minimal prompt exposure of sensitive records.
Cost: Bound verifier calls per answer, since verification can cost more than generation.
A useful mental model is a pharmaceutical label, not a chatbot. Every line needs backing, and every revision needs records.
The design path in interviews should follow a predictable order. We estimate scale first, then restrict retrieval to the approved corpus. After that, the system generates structured claims, binds citations, verifies support, escalates risky cases to humans, and stores an append-only trail for audits. That estimation-first view sets up the sizing discussion next.
Resource estimation
Let' ...