Plan and Design AI Solutions
Start every design from the business outcome, not the model. A defensible plan names the user, the decision or task being assisted, the success metric, and the failure cost. Distinguish deterministic automation (rules, lookups) from generative or predictive AI; many requirements that look like AI are better served by deterministic logic, and exam items often reward the simpler design.
Know the core design vocabulary: use-case fit (classification, extraction, summarization, retrieval-augmented generation, agentic task execution), data readiness (availability, quality, labeling, freshness, licensing), and non-functional constraints (latency, throughput, cost per request, availability, explainability, residency). Model selection is a trade-off exercise: capability vs. latency vs. cost vs. context window. Prefer the smallest model that meets the quality bar, and plan an evaluation set before committing.
Traps to watch for:
- Choosing a complex agentic design when a single retrieval-grounded prompt satisfies the requirement.
- Ignoring data governance (PII, retention, licensing) until after architecture is fixed.
- Treating a prototype's demo quality as evidence of production readiness.
- Forgetting human-in-the-loop for high-cost or regulated decisions.
Rule of thumb: if you cannot state the metric that proves the solution works and the guardrail that stops it from causing harm, the design is not finished. Worked example: a request to "auto-approve expense reports" should decompose into extraction, policy retrieval, a confidence threshold, and human review for low-confidence or high-value cases - not a single free-form prompt that decides payment.
Document assumptions, constraints, and rejected alternatives; exam scenarios frequently test whether you can justify a design choice against stated constraints.