ISACA AAIA: Auditing AI with Defensible Evidence

A bank deploys a machine-learning service to flag suspicious transactions. An internal auditor receives a vendor assurance report and a dashboard showing high model accuracy. Both documents look reassuring, but neither explains whether training data was representative, whether analysts can override incorrect alerts, or who reviews model behavior after a silent vendor update. An AI audit must connect control objectives to evidence of what the system actually does. ISACA's Advanced in AI Audit (AAIA) certification addresses that challenge for experienced audit and advisory professionals.

ISACA positions AAIA as an advanced credential for qualified audit practitioners, not a general entry-level AI qualification. Eligibility involves holding CISA or certain other recognized audit/advisory designations in qualifying circumstances. The official examination has 90 questions across AI Governance and Risk (33%), AI Operations (46%) and AI Auditing Tools and Techniques (21%). Those domains reward the ability to design assurance around real AI behavior while understanding the governance and technical systems that produce it. The published official outline should remain the reference for current exam details.

Establish audit criteria before requesting model evidence

An audit opinion needs criteria against which the system can be judged. Begin with business purpose, regulatory obligations, internal policy, risk appetite and the technical capabilities actually deployed. A model used to prioritize customer support tickets has different assurance needs from one used to influence credit decisions. Identify the scope of the AI system, including data preparation, training, retrieval, model provider, application controls, tool integrations and downstream human action. Failure to define scope can produce an apparently clean report that silently excludes the component responsible for the greatest risk.

For the bank's transaction model, identify who owns the decision to block or review a transaction, what data can be used and what false-positive and false-negative consequences are acceptable. Obtain an architecture and decision-flow diagram before drawing samples. A vendor certificate may help evaluate provider governance but does not prove correct customer-side permissions or scenario-specific fairness. The auditor should document control objectives in language that can be tested: access restrictions, traceable model changes, reliable alert escalation and evidence retention. technology governance risk provides context, but AI assurance still needs tailored criteria.

Review AI governance, accountability and risk ownership

AI governance covers who authorizes use cases, assesses potential harms, manages vendors, approves models and responds to emerging risk. Examine whether a responsible body has authority to stop a deployment or require remediation, and whether decisions are documented. Policy text alone is not enough. A risk register should connect the actual system and users to measurable controls and residual exposure. Privacy, bias, security, safety and unreliable output may all be relevant, but the combination varies by product and affected population.

Test a new procurement request for a generative assistant that can search customer accounts. Ask who classified the data, approved access scope, considered vendor training terms and assessed whether automated responses might mislead users. Follow one decision through approval records, technical implementation and monitoring. If governance identifies a restriction that engineering never enforced, the control is ineffective regardless of the committee minutes. AI lifecycle governance provides a framework for analysis, but auditors must test that the organization's local execution matches its own commitments.

Analyze data, provenance and model-development controls

Model outputs depend on source quality, labeling, transformation, sampling and the validity of training/evaluation splits. Audit evidence should address provenance, permission to use data, data completeness, potential leakage and retention. A dataset can be large yet systematically exclude a population critical to the decision. For generative systems, the retrieved context and prompt assembly can introduce risks even when the underlying foundation model is unchanged. The auditor should distinguish the model's internal characteristics from the surrounding application that selects data and presents conclusions.

Examine a historical fraud dataset containing only cases that prior investigators chose to review. Its labels may reflect earlier detection policy, not all actual fraud. Ask how this selection affects evaluation and which independent evidence could reveal blind spots. Review change control for features and training datasets, not merely for executable code. Confirm that approved model versions can be traced to their validation results. When evidence is incomplete, state the limitation instead of claiming that a favorable benchmark proves deployment risk is low.

Test AI operations and continuous monitoring

ISACA gives AI Operations the largest AAIA weighting. Operational assurance includes development lifecycle, deployment, change management, ongoing supervision, testing, incident response and emerging threats. An AI system may drift as customer behavior changes, even if its code and model version remain identical. A provider's new model or retrieval configuration can also shift output behavior suddenly. Auditors should examine thresholds, alerts, approval gates, rollback capabilities and whether decision-makers actually act on negative signals. Monitoring quality must be demonstrated through cases, not simply by showing that graphs exist.

Build a sample of model changes covering routine release, emergency hotfix and third-party upgrade. Confirm whether each used appropriate evaluations and decision approval. Inspect a period of live alerts to see how exceptions were triaged and whether investigators had enough context. Ask what happens when a high-risk output cannot be explained or verified. A change report containing no incidents may be good news, or may reveal that the monitoring program does not detect relevant failures. The auditor's task is to distinguish those explanations with evidence.

Evaluate security threats and misuse pathways

AI threat models can include data poisoning, prompt injection, model extraction, insecure tool calls, excessive permissions, unauthorized information retrieval and misuse by internal users. Traditional access and vulnerability controls still matter, but the model's ability to interpret untrusted content as instructions creates additional boundaries. An audit should identify who can supply prompts, modify retrieval sources, invoke connected tools and approve actions. Do not treat a red-team report from a single test environment as blanket proof that every deployment is safe.

For a customer service agent, insert a harmless test instruction into an authorized support document and see whether the model improperly treats it as system authority. Examine the surrounding application controls that should keep documents as data. Inspect tool permissions and logs if the agent attempts a prohibited action. The auditor should request permissioned tests that avoid production harm and preserve sensitive data. AI security controls may be technically complex, but the audit conclusion should explain the violated trust boundary and accountable owner in language the business can act upon.

Design sampling and evidence collection fit for AI

AI outputs may be nondeterministic, context-dependent and sensitive to prompt construction. Audit sampling therefore needs a documented method, representative cases, conditions, evaluation criteria and repeatability limits. Select samples from important user groups, edge conditions, high-risk scenarios and actual production traffic where authorized. Avoid choosing only easy prompts that are likely to pass. Evidence can include datasets, model documentation, approval records, configuration state, output traces, logs and human-review outcomes, subject to confidentiality constraints.

Suppose 98% of overall model predictions are satisfactory, but a vulnerable subgroup has materially worse outcomes. Aggregate accuracy does not resolve that concern. Design a stratified review with meaningful denominators, confidence and acknowledged limitations. Compare human reviewer decisions against model recommendations, but account for possible reviewer bias. A sample that excludes disputed decisions cannot establish how the escalation control works. An experienced auditor makes the uncertainty of measurement visible and describes what additional evidence would change the conclusion.

Report findings through consequences and control failures

Audit findings should state the condition observed, the criterion not met, supporting evidence, cause where established, risk or impact and recommended remediation. AI reports can become vague when they describe 'lack of explainability' without identifying which actual decisions cannot be reviewed. Translate technical details into consequences: unauthorized data exposure, unsupported automated action, biased outcomes, inaccurate compliance reporting or an inability to investigate an incident. Management responses should assign ownership and deadlines; a promise to 'improve responsible AI' is not a corrective action.

For the bank, report whether transaction blocks were traceable to the approved model version, whether affected customers had a review path and whether monitoring detected elevated false positives. Keep severity aligned with actual decision impact, not only engineering complexity. Different teams may own data, model behavior, application authorization and business policy. A useful recommendation names the responsible boundary and calls for re-testing after remediation. The audit should improve accountability rather than create a long list of abstract principles.

Practice one complete AI assurance engagement

A strong AAIA case begins with audit charter, scope, applicable requirements and stakeholders. Build an AI system inventory, evaluate governance decisions, inspect data provenance and change control, design output tests, sample production behavior and review incident handling. Record evidence identifiers and limitations throughout. Then draft a management finding and the follow-up test that would prove remediation. The case should contain at least one conflicting result: a clean provider assurance report but weak customer-side permissions, or strong average metrics hiding a poor outcome for a subgroup.

AAIA validates advanced audit reasoning where familiar IT controls intersect with unfamiliar, changing AI behavior. It does not eliminate the need for technical specialists or qualified legal interpretation. The successful candidate knows which conclusions evidence supports, which remain uncertain and which additional test would provide useful assurance. That discipline is the difference between collecting impressive AI documentation and delivering an audit conclusion that management can responsibly rely upon.