AAIA Practice Questions: AI Governance and Risk Domain

A is best because it provides direct, case-level evidence that reviewers exercised judgment and followed escalation criteria in actual decisions. For operating effectiveness, documented execution of the control is stronger than evidence that staff were trained, outcomes were favorable, or system functionality existed. The key distinction is between the presence of an oversight capability and evidence that meaningful oversight occurred.

Why the other options are weaker:
B) Training records support control readiness more than operating effectiveness; training does not prove analysts actually challenged or escalated AI outputs.
C) Outcome metrics like complaints and approval rates are useful contextual evidence but indirect — they may not reveal whether the required human review control operated.
D) Permission to override supports control design or system capability, but it does not demonstrate that analysts performed meaningful oversight.

A is most appropriate because the core issue is lack of traceable, authorized residual risk acceptance for a high-impact AI use case, along with no formal mechanism to track open remediation. B may improve documentation quality, C may improve monitoring, and D may show discussion occurred, but none addresses the need for formal approval by the proper risk owner.

A is the most significant deficiency because the core objective of change management is to ensure production changes are authorized, approved, and traceable. If deployed versions cannot be matched to approved records, the control is not operating effectively. B focuses on outcomes rather than authorization, C is a secondary reporting weakness, and D is related to access monitoring but does not address the fundamental break in change approval traceability.

D is correct because the defined risk threshold was breached and the system continued operating without the required independent exception or escalation process. That indicates a failure of risk appetite governance and operating effectiveness of the exception control. A is secondary because remediation tracking matters only after the threshold breach is handled through proper governance. B may weaken a compensating control, but it does not outweigh the failure to follow approved escalation and exception authority. C is not the core deficiency; continuing to monitor accuracy is not itself improper, and positive metrics do not offset a material fairness threshold breach.

A is correct because the scenario shows a design gap in incident classification and escalation: an AI-related event involving customer information and external routing was treated only as a routine IT incident. The control improvement needed is formal AI-specific escalation, governance reporting, and risk register tracking. B is not best because expanded SLA reporting improves operational visibility but does not ensure governance review. C addresses technical recurrence risk, not the core control weakness in incident governance. D is weaker because management attestations do not create a formal taxonomy, escalation trigger, or governance reporting process.

A is correct because the primary issue is a governance design gap: without formally defined approval roles, decision rights, and accountable ownership, the organization cannot demonstrate authorized deployment or valid risk acceptance. B is not best because post-deployment monitoring is important only after foundational pre-deployment governance is established. C is incorrect because favorable business outcomes do not substitute for documented approval authority. D is incorrect because operational evidence of human intervention does not resolve the absence of named accountability and formal approval control.

B is correct because the scenario indicates a governance design gap: AI systems are in production, ownership is unclear, and policy does not define AI-specific accountability. The auditor should first determine whether formal ownership and approval authority exist, because those controls establish who can accept risk, approve deployment, and receive escalations. A is less appropriate because performance metrics do not address whether governance authority exists. C is weaker because user satisfaction is an outcome measure, not evidence of accountability or control design. D is relevant to oversight activity, but regular committee updates do not by themselves establish formal ownership, decision rights, or approval thresholds.

A is best because repeated harmful outputs raise a governance question first: whether the organization has defined what constitutes an AI incident, when escalation is required, and who can contain or suspend the tool. B, C, and D are useful supporting activities, but they depend on having clear incident criteria and authority in place.

C is the most significant deficiency because production use of generative AI requires a clearly accountable business owner with authority to accept residual risk. Security participation and informal governance discussions do not substitute for documented decision rights. A is a documentation weakness, B is a review-sequencing concern, and D reflects stakeholder engagement issues, but each is secondary to the absence of formal accountability for deployment approval.

A is best because the conclusion requires evidence of both completeness and authorization: the auditor must know what was actually deployed and whether each material release had committee approval. Reconciling change tickets to deployment logs, then tracing them to approvals, provides that assurance. B is weaker because a representation letter is not independent evidence of actual deployments. C may show that some changes were discussed, but it does not demonstrate that all material deployed changes were approved. D reflects planned activity rather than what was actually released, so it cannot support a conclusion that no unauthorized changes occurred.