Have it in hand for your first AI audit.
No score. What to ask when you audit an AI system, which evidence supports which conclusion, and which signs will mislead you — on one page. This is the list our audit team uses in the field, written for internal audit, compliance and risk teams.
Last reviewed 15 September 2026. A practitioner's summary, not legal advice.
Get the PDF to keepWhich evidence reaches which rung
The strength of an audit finding depends not on how many questions were asked but on the rung the evidence stands on. There are three, and only the top one can carry a positive conclusion.
| Level | What it means | Typical evidence |
|---|---|---|
| Declared | The auditee's word. No criterion is "met" on a declaration alone — however many people were asked. | A manager's email, meeting notes, "we do this", a questionnaire answer. |
| Documented | A reference to a document identified by code and version. The document was seen to exist; it was not seen to operate. | Policy, procedure, model card, supplier contract, risk register, training plan. |
| Verified | The auditor checked against the source or re-performed the control. The only level that can carry a positive conclusion; who examined how many items from which population is recorded. | Log sample, recalculation, observation in the system, configuration read directly. |
Ten questions for a first AI audit
Asked in order; each answer sets the scope of the next. When the answer is "yes, we have that", the second question is always the same: show me.
- 01
How many AI systems does the organisation have?
Who keeps the list, when was it last updated, from what source? Without a population, scope is a declaration and the audit cannot start there.
- 02
Who owns each system?
A named person, not a department. A system without an owner has a risk nobody has accepted.
- 03
Which risk tier, and who decided?
Is the reasoning written down; was it checked against Annex III? The tier follows from intended use, not architecture.
- 04
Where does the data come from?
Source of training and input data, how representativeness was tested, who signed it off.
- 05
When did the model or the prompt last change?
Is there a change record; is the report you hold from before or after that change?
- 06
Is human oversight a number or a sentence?
How many decisions were overridden, how many stopped? "There is a mechanism" is not a number.
- 07
If a third-party model is used, what does the contract say?
Commercial use, sub-licensing, data retention; what happens when the provider changes the model?
- 08
Is synthetic content marked in a machine-readable way?
EU AI Act Art. 50(2): a visible footer does not discharge the obligation; the mark must be embedded and robust.
- 09
How many incidents in the last 12 months?
Wrong outputs, complaints, rollbacks — who reported to whom, when? Zero incidents usually means zero records.
- 10
What was looked for and not found?
If it is in the report, the scope is visible; if not, the search is indistinguishable from one never made. Only then can an audit committee ask what was not covered.
Who owes what under the EU AI Act
One organisation can hold both roles: provider of the system it built, deployer of the model it bought. The audit asks about the role, not the system.
| Obligation | Provider | Deployer |
|---|---|---|
| Art. 4 — AI literacy (staff) | Yes | Yes |
| Art. 5 — Prohibited practices | Yes | Yes |
| Art. 9–12 — Risk management, data governance, technical file, logging (high-risk) | Yes | Log retention (Art. 26(6)) |
| Art. 13–14 — Transparency and human oversight (high-risk) | By design | In operation (Art. 26) |
| Art. 26 — Use per instructions, competent oversight, input data, monitoring, informing workers | — | Yes |
| Art. 27 — Fundamental rights impact assessment (FRIA) | — | Public bodies; credit and insurance pricing |
| Art. 50 — Transparency: (1) interaction notice, (2) synthetic-content marking, (3) emotion recognition / biometric categorisation notice, (4) deep-fake disclosure | 50(1) and 50(2) | 50(3) and 50(4) |
| Art. 72–73 — Post-market monitoring, serious-incident reporting | Yes | Reporting (Art. 26(5)) |
Art. 25: a deployer becomes a provider by putting its own name on the system, substantially modifying it, or changing its purpose so that it becomes high-risk.
What applies since when
The Regulation entered into force on 1 August 2024 and applies in stages. An audit report cannot call something "not met" without knowing which obligation was live on which date.
Art. 4 AI literacy and Art. 5 prohibited practices.
General-purpose AI model obligations (Chapter V) — on model providers.
General application date: Art. 50 transparency obligations. Annex III high-risk obligations did NOT start on this date.
End of the 50(2) marking transition for generative systems placed on the market before 2 August 2026 (Art. 111(4)).
General-purpose models placed on the market before 2 August 2025 (Art. 111(3)); national sandboxes operational (Art. 57(1)).
Annex III — Chapter III obligations for standalone high-risk systems (Art. 113(3)(c)(i)).
Annex I — obligations for high-risk systems embedded in product legislation (Art. 113(3)(c)(ii)).
Dates follow the text as amended by Regulation (EU) 2026/1744 (Digital Omnibus on AI, in force 27 July 2026), which deferred the Annex III and Annex I dates. State which text applies before relying on a date in an audit report.
Five signs that will mislead you
All five look "good" in an audit file. All five open with the same question: based on what?
A "maturity score", but no sample.
A number that does not say how many records were examined for what is an opinion, not a measurement.
Exclusions not written down.
Scope is known to the extent its exclusions are. A report that does not say what it did not cover reads as if it covered everything.
Evidence dated after the question.
A document produced after the audit began was produced for that day. It does not show the control operated before it.
"Met" on a single declaration.
However many people were asked or questionnaires filled — a declaration is a declaration. An unverified positive conclusion is not positive.
The model changed, the report did not.
A report must carry the version it assessed. A report without a version does not know which system it audited.
Get the PDF to keep
Two pages, A5, print-ready. Leave your email; the PDF opens at once and your request reaches us. We use the address only for occasional audit-related writing from Atheros AI.
About the sheet
What is the AI audit cheat sheet?
A one-page working reference for internal auditors and compliance teams: the three levels of audit evidence (declared, documented, verified), ten questions to ask in a first audit of an AI system, how EU AI Act obligations split between provider and deployer, the application dates, and five signs that mislead an auditor. It produces no score or maturity rating.
What are the three levels of audit evidence?
Declared is the auditee's word and meets no criterion on its own. Documented is a reference to a document identified by code and version; it shows the document exists, not that it operates. Verified is evidence the auditor checked against the source or re-performed, and it is the only level that can carry a positive audit conclusion.
Which standards is the sheet aligned with?
The sufficiency and appropriateness of evidence under the IIA Global Internal Audit Standards, the AI management system requirements of ISO/IEC 42001, the assurance approach of ISAE 3000, and the article numbers and dates of Regulation (EU) 2024/1689, the EU AI Act. It is not legal advice.
Why do you ask for an email to get the PDF?
The full content of the sheet is readable on this page; the email is only for the print-ready PDF copy. The address is used to send the sheet and occasional audit-related writing from Atheros AI; consent is withdrawn on request and the data deleted.
This sheet is not an assessment tool and produces no score. Atheros AI does not issue certificates, affix CE marking or sign declarations of conformity. Atheros AI home