AAI-M common mistakes
AAI-M · Understand the traps and how to avoid them.
Treating 'AI', 'machine learning', 'deep learning', and 'generative AI' as interchangeable terms when answering definitional items, and picking whichever option sounds most modern.
Candidates learn the vocabulary from marketing material where the terms are used loosely, so they never build the nested set relationship (AI ⊃ ML ⊃ DL, with generative AI cutting across as a capability rather than a sibling category).
What to do instead
Before the exam, write out the nesting hierarchy once by hand with one concrete example per level, and for any terminology item ask 'is this a superset, subset, or cross-cutting capability?' before reading the options.
Selecting the most capable-sounding technique (e.g., a large neural network or an LLM) for a scenario that describes small, tabular, labelled data with clear business rules.
Candidates equate 'more advanced' with 'better answer', and exam scenarios that mention AI prime them to reach for the most AI-flavoured option rather than fitting the method to the data.
What to do instead
For every technique-selection item, first extract three facts from the stem: data volume, data type (tabular/text/image), and whether labels exist. Then eliminate any option that cannot work with that data profile before comparing the survivors.
Confusing data quality dimensions with each other - labelling a duplicate-customer-record problem as 'accuracy' instead of 'uniqueness', or a missing-value problem as 'completeness' when the stem describes inconsistent formats.
The dimensions overlap in everyday speech ('the data is wrong' covers all of them), so candidates map the scenario to a general impression of badness rather than to the specific dimension the stem is illustrating.
What to do instead
Memorise a one-line test per dimension (completeness = is it there; accuracy = does it match reality; consistency = do sources agree; uniqueness = one row per entity; timeliness = is it current; validity = does it fit the allowed format/range) and apply the test literally to the stem's example.
Answering data-splitting and evaluation items with the training set, or accepting a high accuracy figure on an imbalanced dataset as evidence the model works.
Candidates conflate 'the model performed well' with 'the model generalised', and default to accuracy as the headline metric without checking the class balance described in the stem.
What to do instead
For any evaluation item, circle the words identifying which dataset is being measured (train/validation/test/production) and check the stem for class balance; if classes are skewed, expect precision, recall, F1, or AUC to be the intended answer over accuracy.
Treating overfitting and underfitting as opposites to be guessed from the model's name or complexity alone, rather than from the described train-versus-validation performance gap.
Textbook definitions ('overfitting = too complex') get memorised without the diagnostic signature, so candidates cannot interpret a scenario that says training accuracy is 99% and validation accuracy is 61%.
What to do instead
Drill the two signatures until automatic: large gap with high training score = overfitting (fix: more data, regularisation, simpler model, early stopping); both scores low and close = underfitting (fix: more capacity, better features, longer training).
Assuming an LLM's confident, fluent output is evidence of correctness, or attributing to the model capabilities it does not have (real-time knowledge, guaranteed factual recall, deterministic output).
Fluent prose is a strong social cue for competence, and candidates transfer their trust in human experts onto the model without accounting for training cutoffs, hallucination, and sampling randomness.
What to do instead
Adopt a standing rule for generative AI items: fluency is not accuracy, and any option that promises guaranteed factual correctness, live knowledge, or identical output for identical prompts is wrong unless the stem specifies retrieval, tools, or temperature zero.
Choosing retrieval augmentation, fine-tuning, or prompt engineering interchangeably for a scenario, without matching the intervention to the described problem (stale knowledge, wrong format/style, or missing private context).
All three are presented in vendor material as generic 'ways to improve an LLM', so candidates pick the one they have heard most recently rather than reasoning from the failure the stem describes.
What to do instead
Map problem to fix explicitly: missing or changing factual/private knowledge → retrieval augmentation; wrong tone, format, or task behaviour → fine-tuning or few-shot prompting; unclear instructions → prompt engineering. Answer the stem's stated failure, not the general goal of 'better output'.
Evaluating an AI use case on technical feasibility alone and ignoring whether the value is measurable, who bears the cost of errors, and whether a human must review the output.
Candidates default to 'can it be built?' because that is what technical study emphasises, and skip the business-case and risk framing that the use-case domain is actually testing.
What to do instead
For every use-case item, run a three-part check before choosing: is there a measurable business metric, what is the cost of a wrong answer, and does the workflow require human oversight. Eliminate options that score well on capability but fail any of the three.
Treating fairness as a single property to be certified, and picking 'remove the protected attribute from the data' as the fix for bias.
Candidates look for a clean technical remedy and are unaware that excluded attributes are often reconstructed from correlated proxies, so the intuitive answer is the classic trap.
What to do instead
Answer bias items by naming the specific harm and the specific mitigation stage (data collection, labelling, feature selection, evaluation across subgroups, post-processing, human review), and reject any option claiming bias is fully solved by deleting a field or by a one-off audit.
Conflating governance artefacts - answering a question about accountability or oversight with 'privacy policy', 'model card', or 'DPIA' regardless of which control the stem describes, and treating compliance as a one-time sign-off.
The documents and controls are learned as a list of names rather than as distinct functions, so candidates pattern-match on the word 'governance' instead of on the control's purpose.
What to do instead
Build a purpose-keyed table (who is accountable → roles/RACI and sign-off; what the model does and its limits → model card; personal-data risk assessment → DPIA; ongoing monitoring → audit logging and drift review) and answer from the stem's described purpose, not its vocabulary.
Assuming a deployed model keeps performing as it did at launch, and failing to connect monitoring, drift, and retraining triggers to the operations questions.
Project-delivery material front-loads build and launch, so candidates picture deployment as the finish line and underestimate how data and behaviour change after go-live.
What to do instead
For lifecycle and operations items, ask 'what changes after deployment?' and expect answers involving performance monitoring, data drift detection, defined retraining triggers, rollback plans, and ownership of the model in production.