ISACA AAIR common mistakes
ISACA AAIR · Understand the traps and how to avoid them.
Answering governance questions with the technically 'best' control (e.g., choosing a robust bias-mitigation technique) when the stem asks who is accountable for approving the AI use case.
Candidates with engineering, audit, or data-science backgrounds default to solution-mode. AAIR governance items test accountability structures, decision rights, and oversight bodies, not technique selection, so the appealing technical answer is a distractor.
What to do instead
Before answering, classify the stem: is it asking 'who decides/owns/approves' (governance), 'what could go wrong and how do we treat it' (life cycle risk), or 'how do we run the program' (program management)? If the stem names a decision, approval, or escalation, eliminate any option that is a tool or technique and choose the option that names the accountable role or body.
Treating AI governance as a standalone new discipline and selecting answers that create a parallel AI-only policy framework disconnected from existing enterprise risk, privacy, and third-party management.
Exam prep material often emphasizes what is novel about AI (model opacity, emergent behavior), leading candidates to assume existing governance cannot apply. In practice, exam items reward integration with existing ERM, procurement, and data governance structures.
What to do instead
When an option proposes a brand-new siloed function versus extending an existing governance body or policy, favor the integrated option unless the stem explicitly describes a gap that existing structures cannot cover. Memorize the principle: AI governance is a specialization within enterprise governance, not a replacement for it.
Selecting 'implement a control' as the first response to a newly identified AI risk, skipping the step of determining risk appetite and whether the risk is acceptable or must be avoided.
Control-first thinking is drilled into auditors and risk practitioners. But risk treatment follows evaluation against appetite; jumping to mitigation can mean spending on a risk the organization would have accepted, or missing that the correct response is to not deploy.
What to do instead
Use a fixed sequence for treatment questions: identify and assess the risk, compare to approved risk appetite/tolerance, then select avoid/mitigate/transfer/accept. If an option says 'accept' or 'do not deploy' and the stem shows the risk exceeds appetite, that option often beats a control option.
Applying a single risk assessment at project approval and assuming it stays valid, rather than recognizing that AI risk must be reassessed at defined life cycle gates and on material change (retraining, new data source, model swap, changed use context).
Traditional IT project risk is often assessed once at business-case stage. AI systems change behavior after deployment through retraining and data drift, so static assessment is a classic trap; distractors offer 'annual review' when the stem describes a model update.
What to do instead
Anchor on the principle that AI risk assessment is continuous and event-driven. When a stem mentions retraining, a new vendor model, expanded user population, or new geography, the correct answer is a triggered reassessment, not the next scheduled review.
Confusing model risk with AI risk: choosing an answer that addresses only statistical model performance (accuracy, drift metrics) when the stem's harm is to people, rights, or regulatory standing (e.g., discriminatory denial of service).
Model risk management frameworks (validation, backtesting, monitoring) are familiar and feel rigorous. Candidates map every AI question onto them, missing that AI risk includes ethical, legal, reputational, and human-rights dimensions that performance metrics do not capture.
What to do instead
Ask 'what is the harm and to whom?' If the harm is to individuals or society, look for answers involving impact assessment, stakeholder consultation, fairness testing, or human review. Reserve pure model-performance answers for stems about predictive accuracy or stability.
Choosing 'add a human in the loop' as a universal fix, without checking whether the stem requires meaningful human judgment with authority and information to override the system.
Human oversight is the most-repeated AI safeguard, so it becomes a reflex answer. Exam items test whether the candidate understands that nominal oversight (a reviewer who rubber-stamps outputs, lacks context, or cannot stop the process) does not reduce risk and can create automation bias.
What to do instead
Accept a human-oversight option only if it specifies authority to intervene, sufficient information and time to evaluate, and defined escalation. If a distractor offers oversight that is purely formal, prefer an option that changes the system's decision rights or blocks the action.
Treating third-party or foundation-model risk as covered by the vendor's assurances, rather than requiring independent due diligence, contractual allocation of responsibilities, and monitoring of the vendor's model changes.
Candidates assume a reputable provider's certification or terms of service transfer risk. In AI supply chains, the deploying organization retains accountability for outcomes, and provider model updates can silently change behavior.
What to do instead
For any stem involving a purchased model, API, or pretrained component, select answers that include pre-contract due diligence, contractual rights to notification and audit, and post-deployment monitoring. Reject options that rely solely on vendor claims or generic SLA language.
Mixing up program-level roles: assigning execution of risk assessments to the AI governance committee, or assigning policy approval to the data science team, when the stem tests segregation of duties.
In small organizations the same people do everything, so candidates import that blur into answers. Exam items test the principle that those who build and operate AI should not be the sole assessors or approvers of its risk.
What to do instead
Map roles explicitly before answering: governing body sets policy and appetite; management owns and operates controls; independent review (second or third line) provides assurance. If an option has developers approving their own model for high-risk use, eliminate it regardless of how efficient it sounds.
Selecting the most comprehensive-sounding metric or KRI (e.g., 'number of models deployed') instead of a metric that is tied to a specific risk and has a defined threshold and response.
Candidates equate breadth with rigor. Program monitoring items reward indicators that are actionable: linked to a risk statement, with a tolerance level and a pre-agreed escalation path, even if narrow.
What to do instead
Test each metric option against three questions: does it measure the risk in the stem, does it have a threshold, and does breaching it trigger a defined action? Choose the option satisfying all three, even if it is less impressive than a dashboard of counts.
Ignoring the 'FIRST' or 'MOST' qualifier and picking a correct-but-later step (e.g., reporting to the board) when the stem asks for the immediate next action of the risk practitioner.
Multiple options are often true statements in the abstract. Under time pressure, candidates pick the most authoritative-sounding action rather than the earliest one in the proper sequence.
What to do instead
Underline the qualifier in the stem before reading options. For 'FIRST' items, order the plausible options chronologically and choose the earliest valid action. For 'MOST' items, choose the option with the greatest risk-reduction or governance impact, not the most detailed one.