How to Design an AI System

Every AI-architecture question — in an exam, an interview, or a real design review — is the same question wearing different clothes: given this organization, this data, and this risk, what do you build and why? You do not need a new answer each time. You need a repeatable design method you can run out loud, in order, with confidence. This lesson is that method. The two worked designs that follow apply it end-to-end.

The five-step method

1. Clarify requirements, users, and risk level. Who uses the system, what does "correct" mean for them, and what happens when the system is wrong? A wrong movie recommendation is noise; a wrong benefits-eligibility answer is a lawsuit. The risk level you name here drives every later decision — say it explicitly, because graders score it.
2. Identify the data — freshness and sensitivity. Where does the ground truth live? How often does it change (freshness), and who is allowed to see it (sensitivity)? Data that changes weekly rules out fine-tuning as the knowledge store; data containing PII constrains where models can run. Most bad designs die here, at step two, by skipping it.
3. Choose the pattern. Only now pick the architecture: classical ML for structured prediction at scale, RAG for grounded answers over changing documents, fine-tuning for style and format (not facts), an agent only when the task genuinely needs multi-step tool use. The pattern is a consequence of steps one and two, never the starting point.
4. Design the guardrails. For the risk level you named: grounding with citations, output validation, fail-closed refusal when evidence is weak, and human-in-the-loop (HITL) escalation for consequential actions. This platform itself demonstrates the shape — evidence grading with refusal, deterministic guardrails around a probabilistic core.
5. Design the operations. A golden-set evaluation run before every change, telemetry with per-call records, and a cost model (tokens × volume, plus embedding refresh). A design with no evaluation plan is the single most common failing answer.

Say the trade-offs aloud

At each step, name what you gave up: "RAG over fine-tuning because the content changes weekly — the cost is retrieval latency and index maintenance." Graders and interviewers are not scoring the pattern you picked; they are scoring whether you knew the alternatives and chose deliberately. An adequate design with explicit trade-offs beats a clever design presented as the only option.

Make it a reflex

Run the five steps on everyday systems until the sequence is automatic: a hospital triage bot, a council planning portal, an internal HR assistant. Requirements → data → pattern → guardrails → operations, trade-offs at every step. When the exam scenario lands, you will not be inventing an answer — you will be executing a method you have already rehearsed a dozen times.