The first request in a serious AI compliance audit is never “show us the model.” It is “show us the list.” Auditors open with the inventory because everything downstream hangs on it: risk classification, the evidence request, the sampling plan, the wording of the final opinion. A team that cannot put a defensible list of its AI systems on the table inside a week has already lost control of the date it promised the board.
The short answer: five phases and one evidence trail
An AI compliance audit is a structured examination of the AI systems an organisation builds, buys or operates, tested against a defined set of obligations — most often the EU AI Act (Regulation (EU) 2024/1689), ISO/IEC 42001, or a sector rulebook. It runs in five phases. Scoping fixes the perimeter and your legal role. Evidence collection gathers the artefacts each obligation demands. Testing checks that controls are not merely documented but actually operating. Findings and remediation rank the gaps, assign owners and set dates. Reporting produces a defensible opinion plus a file you can hand to a regulator. The deliverable is not a maturity score. It is a paper trail that holds up when a hostile reader goes through it line by line.
Two of those phases set the calendar. Phase 1 stalls on discovery whenever no inventory exists, and Phase 2 moves at the speed of vendors answering evidence requests. Anyone who quotes you a fixed number of weeks without asking how many systems you run and whether you are a provider or a deployer is guessing.
Before any of it, settle which kind of audit you are running. The word covers four different things here, and mixing them up costs months:
- An internal or second-party audit is your own readiness exercise. Nobody certifies anything; the point is to find your gaps before someone else does.
- A conformity assessment under Article 43 of the AI Act is a legal procedure for high-risk systems, run either by internal control (Annex VI) or with a notified body (Annex VII), ending in an EU declaration of conformity and CE marking.
- A certification audit against ISO/IEC 42001 is carried out by an accredited certification body in two stages — documentation review, then implementation review — and is followed by surveillance audits.
- A statutory bias audit, such as the one New York City’s Local Law 144 requires for automated employment decision tools, is a narrow, independent, publishable test that runs to its own rules.
Settle that question before you write the scope memo. Audits that stall usually stall here: nobody agreed what was being audited, or against what.
Phase 1 — Scoping: the perimeter, your role, the classification
Build the inventory from spend, not from surveys
Ask each department whether it uses AI and the answer will come back short every time. Reconstruct the inventory instead from sources nobody can massage: procurement and vendor contracts, SaaS and cloud spend, single sign-on and OAuth grant logs, browser extension inventories, the DPIA register, model and feature registries, RPA schedulers. For each entry, record the purpose, the business owner, data categories, affected persons, deployment status, vendor and lifecycle stage.
Fix your legal role for every system
Under the AI Act you can be a provider, deployer, importer or distributor, and the obligations differ sharply. Article 25 is where organisations get caught: a deployer becomes a provider if it puts its own name or trademark on a high-risk system, makes a substantial modification, or changes the intended purpose so that the system becomes high-risk. Fine-tuning a general-purpose model on your own data can push you into the provider role as well. That one call decides whether you are running a light deployer review or a full technical-file exercise.
Run the classification gate
Three questions, in order. Does the system fall under the prohibited practices in Article 5? Is it high-risk under Article 6 and Annex III, or as a safety component of a product covered by Annex I legislation? Does it trigger the transparency duties in Article 50 — chatbots, synthetic content, deepfakes, emotion recognition? If you rely on the Article 6(3) derogation to argue that an Annex III system is not high-risk, document that assessment and register the system before it reaches the market. An undocumented “we decided it was low risk” is a finding waiting to happen.
Phase 2 — Evidence: artefacts with dates, versions and owners
Auditors do not accept assurances. They accept artefacts. This is the evidence map most AI Act engagements work from.
| Obligation area | AI Act anchor | What the auditor asks for | Usual owner |
|---|---|---|---|
| Risk management | Art. 9 | Iterative risk file: risks identified, mitigations, residual risk, review dates | Risk / product |
| Data governance | Art. 10 | Data provenance, representativeness and bias examinations, labelling procedures, known gaps | Data / ML lead |
| Technical documentation | Art. 11 + Annex IV | Version-controlled technical file: architecture, design choices, metrics, limitations | Engineering |
| Logging | Art. 12, 19, 26(6) | Automatic event logs, plus evidence that retention really runs to at least six months | Platform / SRE |
| Instructions for use | Art. 13 | Instructions supplied to deployers, accuracy and limitation statements | Product |
| Human oversight | Art. 14, 26(2) | Named, competent, authorised people; an override procedure; records of real interventions | Operations |
| Accuracy, robustness, security | Art. 15 | Test protocols and results, adversarial testing, incident history | Security / QA |
| Quality management system | Art. 17 | Written QMS covering design, verification and post-market activity | Quality |
| Conformity and registration | Art. 43, 47, 48, 49 | Declaration of conformity, CE marking, EU database entry | Regulatory |
| Deployer duties | Art. 26 | Use in line with instructions, input-data relevance, worker information, monitoring records | Business owner |
| Fundamental rights impact assessment | Art. 27 | FRIA where it applies: public bodies, public-service providers, credit scoring, life and health insurance pricing | Compliance / DPO |
| Post-market and incidents | Art. 72, 73 | Monitoring plan, incident register, proof that reports went out inside the deadlines | Compliance |
| AI literacy | Art. 4 | Training records mapped to the roles that actually touch the systems | HR / L&D |
The three tests every artefact has to pass
Existence — the document is real, not a template someone intends to fill in. Currency — it carries a version, a date and a review cycle that has actually run. Linkage — it names the specific system from the inventory. Linkage is where most organisations come unstuck: a polished generic AI policy that nobody can connect to the CV-screening tool running in production this morning.
Check the retention rules early, because they are unforgiving. Providers keep technical documentation, QMS records and the declaration of conformity for ten years after the system is placed on the market (Art. 18). Logs must be kept for at least six months by providers (Art. 19) and by deployers to the extent the logs are under their control (Art. 26(6)). If your platform team rotates logs out after 30 days, you have a gap that no remediation plan can fill after the fact.
Phase 3 — Testing: design versus operating effectiveness
A control that exists on paper and a control that actually works are two different findings, and they need two different fixes. Test for both.
The useful tests are unglamorous. Ask the named human overseer to talk you through the override procedure without notes, then find a log entry showing it was used. Request the log for one specific date six months back. Take a model version from the technical file and confirm that the deployed artefact matches it. Open the live product and look for the Article 50 disclosure in the interface itself, not in the design spec. Ask procurement which contract clauses pass these obligations down to suppliers, and what those contracts say if Article 25 turns you into the provider.
Document the sampling basis. An opinion built on “we looked at some systems” will not survive contact with a regulator; “we tested three of eleven high-risk candidates, selected by user volume and data sensitivity” will.
Phase 4 — Findings and remediation, ranked by exposure
Write every finding in the same shape: condition, criterion (the specific article or clause), cause, consequence, corrective action, owner, due date. Vague findings never get fixed, because nobody can tell when they are done.
Rank by regulatory exposure, not by ease of fixing. The AI Act’s penalty tiers hand you the running order: breaches of the Article 5 prohibitions carry up to €35 million or 7% of total worldwide annual turnover, whichever is higher; most other obligations up to €15 million or 3%; supplying incorrect, incomplete or misleading information to notified bodies or competent authorities up to €7.5 million or 1%. For SMEs and start-ups, the lower of the two figures applies (Art. 99).
Phase 5 — Reporting, and what happens next
The report needs a scope statement, explicit exclusions, the criteria used, the methodology, the sampling basis, the findings register, management responses and a clearly bounded opinion. Say what you did not look at. Auditors get into trouble for coverage they implied far more often than for gaps they declared.
Then the clock keeps running. Post-market monitoring under Article 72 is continuous. Serious incidents must be reported immediately and no later than 15 days after you become aware of them; within 2 days for a widespread infringement or a serious and irreversible disruption to critical infrastructure; within 10 days where a person has died (Art. 73). If you hold ISO/IEC 42001 certification, surveillance audits follow the certification body’s cycle.
How long it takes, and what actually drives it
Treat any headline figure — “an AI Act audit takes N weeks” — as meaningless unless it states the inventory size and the legal role behind it. What actually drives the calendar is whether an inventory already exists, how many systems land in the high-risk bucket, whether you are a provider or a deployer, how fast vendors answer evidence requests, and whether this is a first pass or a repeat.
Two planning rules hold across engagements. First, the bottleneck in Phase 1 is discovery, not analysis; with no inventory to start from, budget more calendar time for finding systems than for classifying them. Second, evidence collection has the longest lead time and it depends on parties you do not control, so send vendor requests on day one, before scoping is finished. Remediation is the phase that gets cut when the calendar slips, which is exactly backwards: it is the only phase that changes your actual exposure.
The statutory dates constrain the plan. The AI Act entered into force on 1 August 2024. Prohibitions and AI literacy obligations applied from 2 February 2025; general-purpose AI, governance and penalty provisions from 2 August 2025. The Article 50 transparency duties have applied since 2 August 2026 — that date held, and the Commission’s enforcement powers over GPAI providers run from the same day. The Digital Omnibus package, finally adopted in June 2026 (European Parliament on 16 June, Council on 29 June), deferred the standalone Annex III high-risk obligations to 2 December 2027 and high-risk AI embedded in Annex I regulated products to 2 August 2028. Verify any date you build a plan around on EUR-Lex and in the Official Journal — the same goes for overlapping regimes such as Colorado’s AI Act, whose start date has already moved once.
Five ways AI audits go wrong
- Auditing models instead of systems. The Act regulates AI systems as they are used, in context. Put the same model in two products and you have two compliance objects, not one.
- Policy without linkage. A governance framework that names no systems proves nothing.
- Treating the vendor’s compliance as yours. Buying a CE-marked system does not discharge your Article 26 deployer duties, and Article 25 can make you the provider outright.
- Leaving shadow AI outside the perimeter. Scope from spend and identity logs, not from a questionnaire.
- No retention plan. Logs rotated out before the audit cannot be recreated.
What to do in the first week
Freeze a dated snapshot of the inventory, incomplete or not, so the scope stops moving. Assign a provider/deployer determination to every entry. Send vendor evidence requests immediately. Pull logs from six months ago and find out whether retention is real. Then take one likely high-risk system and run the full five-phase flow on it, end to end. One completed pilot will tell you more about your real timeline than any published benchmark.
This material is informational and does not constitute legal advice. The law may change — for doubts about a specific situation, consult a lawyer.