AB-100 common mistakes
AB-100 · Understand the traps and how to avoid them.
Selects a specific AI technology or product before documenting the business outcome, affected users, and success metric.
Candidates anchor on familiar tools from prior experience and treat the exam scenario as a product-selection question rather than an outcome-design question.
What to do instead
Write a one-sentence outcome statement and measurable KPI first, then map each requirement to capabilities, constraints, and only afterward to candidate technologies.
Treats the whole organization or workflow as a single user group instead of segmenting by role, task frequency, risk level, and data sensitivity.
Scenarios often describe a broad business problem, and candidates collapse distinct personas into one assistant or solution scope.
What to do instead
Build a persona-and-task inventory with columns for task, frequency, decision risk, data class, and desired autonomy; use it to define scoped use cases.
Assumes existing data is ready for AI because it exists in a system of record, without assessing quality, access rights, residency, or ownership.
Candidates focus on model capability and skip the planning work of data discovery and governance.
What to do instead
Create a data-source inventory covering quality, freshness, classification, residency, access owner, and integration path; flag gaps as planning risks.
Designs one monolithic assistant that handles every request instead of decomposing into bounded use cases with defined intents, fallbacks, and handoffs.
A single assistant feels simpler on paper, and candidates underestimate ambiguity, safety boundaries, and maintainability.
What to do instead
Decompose the solution into use cases, define supported intents and out-of-scope requests, and specify fallback and escalation behavior for each.
Omits human-in-the-loop review or escalation for high-impact decisions such as financial approvals, customer commitments, or regulated advice.
Candidates equate automation value with full autonomy and do not classify decisions by risk.
What to do instead
Create a risk-tier matrix and specify which decisions require human approval, which require review-after-action, and which can be fully automated.
Specifies prompts, models, or agents without an evaluation dataset, acceptance criteria, or grounding strategy.
Candidates design the happy-path interaction and treat quality as something to test after deployment.
What to do instead
Define evaluation questions, expected answers, grounded sources, quality metrics, and pass thresholds before finalizing the design.
Ignores nonfunctional requirements such as latency, throughput, cost per interaction, availability, and compliance obligations.
Candidates concentrate on functional capability and do not translate business constraints into architecture requirements.
What to do instead
Maintain an NFR table with target and tolerance for latency, volume, cost, availability, and compliance; use it to justify design tradeoffs.
Mixes platform responsibilities, such as putting governance, orchestration, and user experience in the wrong layer or duplicating capabilities across tools.
Product boundaries overlap, and candidates rely on surface-level familiarity instead of assigning each concern to an owning layer.
What to do instead
Draw a responsibility matrix for experience, orchestration, model, data, security, and governance; assign one primary owner per concern and note integrations.
Plans go-live as a single big-bang release without a pilot group, rollback path, or post-deployment telemetry.
Candidates treat deployment as a technical publish step rather than an operational transition with business risk.
What to do instead
Define a phased rollout with pilot users, success gates, rollback triggers, and telemetry for usage, quality, cost, and incidents.
Defers identity, licensing, data-loss prevention, environment strategy, and CI/CD until after the solution is built.
Candidates focus on the AI feature and underestimate how security, licensing, and application lifecycle management constrain deployment.
What to do instead
Use a deployment readiness checklist covering identity and permissions, licensing, DLP, environment separation, pipeline promotion, and operational ownership before build completion.