AIAC-AUDFAssurance
Certified AI Audit Fundamentals
Audit planning and scoping · 20% of the paper
For internal and IT audit functions that must plan, execute, and report an audit of an AI system, and stand behind the finding.
Audit
Auditing AI systems
IIA Standard 13.3 — Engagement Objectives and Scope
"Audit our AI" is not a scope. Standard 13.3 requires engagement objectives and a scope that follows from the engagement risk assessment in 13.2, which 13.6 then turns into a work programme. For an AI system the difficult part is the boundary: what belongs to the model, what belongs to the process around it, and how many model versions the period actually contains.
§ 1 — When it applies
Which edition applies
9 January 2024
The date the Global Internal Audit Standards, 2024 edition, were published. This identifies the current edition and is not a compliance deadline: the Standards state no effective date of their own, and the 2017 framework they replaced is no longer effective.
§ 2 — In practice
From risk assessment to work programme
The three standards form a chain, and the chain is the point. Standard 13.2 calls for an engagement risk assessment; 13.3 for objectives and a scope that follow from it; 13.6 for a work programme. An objective with no step against it is an intention, and a step with no objective above it is fieldwork looking for a home. On AI engagements the chain usually breaks at the first link, because the risk assessment was performed at the level of "the AI system" while the objectives were written at the level of individual controls, with nothing joining the two.
The boundary is the planning decision that determines what the engagement is worth, and it is four decisions rather than one: the model artefact and which of its versions, the environment it runs in, the pipeline feeding it, and the human decision that follows its output. Draw the line around the model alone and most of what can go wrong falls outside — the oversight arrangement, the input controls and the escalation route belong to the deployer, as Article 26 sets out at length. Draw it around everything and the work never finishes. The memorandum states where the line fell and what fell beyond it.
Period is the other place AI planning departs from habit. A quarter is a period for a ledger; for a model it is a set of versions, and where the system was retrained twice the engagement covers three configurations whose behaviour cannot be assumed identical. Exclusions carry the same discipline: which systems the risk assessment considered and set aside, and on what basis. That record matters more than it looks, because engagements fail less often on a bad test than on a system left out at planning because the proof looked hard to get — a judgement Standard 14.1 requires to be made out loud.
§ 3 — Who it binds
When the duty arises
Internal audit function
Planning for any engagement with an AI system in its subject matter, including one where the AI is a component of a wider process being audited rather than the headline. Standard 13.3 binds the internal audit function, and applies whether the work was requested by management, drawn from the audit plan, or triggered by an incident.
§ 4 — What discharges it
What the planning file must show
The artefacts an assessor asks to see, and what makes each one sufficient rather than merely present.
01
An engagement risk assessment naming the AI systems excluded
The systems considered and set aside, each with a reason. Inclusions justify themselves; exclusions are where the scope was actually settled, and they are almost never written down.
02
A scope memorandum stating the versions and the period
Named system, the versions in service across the window, the environment they ran in, and the dates. A scope expressed only as a calendar quarter cannot tell a reader how many configurations the conclusion covers.
03
A boundary statement separating the model from the process around it
What sits inside the engagement: artefact, pipeline, environment, and the human step after the output. Findings land badly where the line was never drawn, because the control that failed turns out to sit just beyond it.
04
A work programme with a step against each objective
Read in both directions. Every objective reaches at least one procedure, and every procedure serves a stated objective; the orphans in either direction are what the closing meeting will surface.
§ 5 — Worked example
Worked example — three models in one quarter
A retailer’s audit committee asks internal audit to "review the AI in pricing". The team finds a demand-forecasting model, a markdown-optimisation model, and a third-party recommendation service embedded in the storefront. The forecasting model was retrained in February and again in April. The plan drafted after the walkthrough covers "pricing AI, Q1 to Q2", with four objectives and no exclusions recorded.
What has this scope left undecided?
Almost everything the fieldwork will run into. Three systems sit in the subject matter and the plan names none of them, so nobody outside the team can tell whether the recommendation service — the one the retailer does not operate and cannot obtain records from — is in or out. Two retrainings inside the window mean the forecasting model is three configurations, and a conclusion drawn on March data says nothing about the version live in June. Nothing fixes the line between the models and the pricing process they feed, so a finding about an unreviewed markdown override will arrive alongside an argument about whether it was ever in scope. And with no exclusions written down, a decision to leave the third-party service alone will look, six months later, exactly like a decision nobody made.
§ 6 — What a weak answer looks like
A technology is not a scope
A scope naming a technology instead of a system. "AI in the customer operations division" reads like a boundary and works as none: it does not say which models, which versions, which decisions, or what happens at the edges. The team then discovers its own scope during fieldwork, which is why the engagement overruns, and the report covers whatever it happened to reach. Nobody can tell afterwards whether a system was examined and passed or was never opened at all.
§ 7 — Elsewhere
The programme around the engagement
Where another instrument addresses the same obligation. These are correspondences, not comparisons — the Council does not rank one framework against another.
ISO 19011
ISO 19011:2026 clause 6 addresses conducting an audit from initiation through to follow-up, with preparation as a distinct step. It reaches the same planning territory from the management-system audit side.
A correspondence indicates that two instruments address the same underlying obligation. It is not a mapping endorsed by either body, not a statement that one satisfies the other, and not a judgement about which is more demanding.
§ 8 — Where this is assessed
Where this is assessed
Examined in one credential, in the domains named on each card.
§ 9 — provenance
The provision itself
This page sets out what the instrument requires and what discharges it. The official text is the authority — these go straight to it.
§ 10 — Also read