Framework
Auditing AI systems
What an audit of an AI system actually requires: how the engagement is scoped, what it is measured against, what counts as sufficient evidence, and how a finding is written when the thing that failed is probabilistic. Anchored in the audit standards, not improvised.
§ 1 — Orientation
How the audit standards fit together
There is a widespread assumption that auditing an AI system is a method nobody has written down yet. It is not. The engagement is governed by the same instruments that govern every other internal audit — the IIA Global Internal Audit Standards for the conduct of the work, ISO 19011 for the programme around it — and those standards are specific at exactly the points practitioners believe they are silent. What is genuinely new is narrower than it looks: the evidence is harder to obtain and harder to reproduce, and the criteria to audit against frequently do not exist yet.
That second problem has a stated answer. Where the criteria management has set are inadequate, the auditor does not report that there was nothing to audit against — Standard 13.4 requires them to identify appropriate criteria with the board or senior management, and names authoritative industry frameworks as an acceptable source. And where evidence cannot be obtained at all, Standard 14.1 is explicit that the auditor must consider whether the absence is itself a finding. Both are routinely read the other way round.
The evidence problem is where AI departs from ordinary audit practice, and the departure is not the one people expect. Sufficiency, under both 14.1 and 14.6, is a reperformance test: could a competent person work from this file and reach the same conclusion? For a probabilistic system that makes the model version, the inference parameters and the date load-bearing evidence rather than metadata, because without them nothing in the file reperforms. These pages set out what each standard requires, who it binds, and the artefacts an assessor asks to see — which the standards themselves do not specify, because they state outcomes and leave the evidence to practice.
§ 2 — By who it binds
Obligations by role
On the provider
Whoever develops the system, or places it on the market under their own name — including a deployer that rebrands or substantially modifies one.
- Annex VII, points 4.3 to 4.5Conformity based on an assessment of the quality management system and an assessment of the technical documentation
Annex VII sets out what a notified body may demand when it assesses a high-risk AI system’s technical documentation.
§ 3 — By when it applies
Obligations by date
The date each obligation first bites, earliest first. Where a provision applies on more than one date, the earliest is shown.
9 Jan 2024
9 Jan 2024
9 Jan 2024
IIA Standard 14.1 — Gathering Information for Analyses and Evaluation
9 Jan 2024
9 Jan 2024
IIA Standards 14.2 and 14.3 — Analyses and Potential Engagement Findings; Evaluation of Findings
9 Jan 2024
9 Jan 2024
31 Jul 2025
27 May 2026
27 May 2026
27 May 2026
2 Aug 2026
§ 4 — Elsewhere
The same ground, cut differently
Certification
Assessed on the same standard of evidence
Every Council credential is examined on applied judgement against a published anchor, set out the way the obligations on this page are. The Certified Applied AI Associate, the Council’s flagship, is open to any adult today, its fee waived by a coupon code from the AI-Readiness Check, and the register lists what is open for enrolment.