AI Act Audit Readiness: What a Market-Surveillance Authority Can Actually Ask For
AI Act audit readiness: the evidence a market-surveillance authority can demand under Article 74 — inventory, Annex IV docs, logs, FRIA, registration.
Audit readiness is not a statutory obligation. It is a practice — the discipline of keeping the evidence a regulator can demand in a state where you could hand it over in days, not months. The EU AI Act, Regulation (EU) 2024/1689, gives market-surveillance authorities real investigatory teeth under Article 74 and the surrounding Chapter IX provisions: they can request documentation, access your technical records, and require you to demonstrate conformity. "Audit-readiness" is simply organising the artefacts the law already requires so that a request does not turn into a fire drill.
The point worth internalising up front: every item below is something you must produce anyway if you operate a high-risk system. Readiness changes the timeline, not the obligation.
Who audits you, and under what power
The Act does not create routine "AI audits" the way financial law mandates annual accounts. Instead, Article 74 empowers national market-surveillance authorities to supervise systems on the market, and Article 21 obliges providers to cooperate with competent authorities on request. An authority acts on a complaint, a serious-incident report (Article 73), a thematic sweep, or a referral. When it does, it can require you to demonstrate that a high-risk system meets the Chapter III requirements — and it can ask for the underlying records.
A practitioner's framing: treat the request as inevitable for any Annex III system, and build the pack while you build the system. The cost of assembling evidence retrospectively — reconstructing a risk file, back-filling logs you never kept — is where teams actually fail.
The evidence pack: what to keep ready
This is the core of the practice. For a high-risk system, an authority can reasonably expect each of the following. Note which are provider duties and which are deployer duties — they are not the same.
| Evidence item | Statutory basis | Held by |
|---|---|---|
| AI system inventory + risk classifications (with the reasoned Article 6(3) assessment where you claim an exemption) | Art 6, Art 49 | Provider & deployer |
| Annex IV technical documentation | Art 11, Annex IV | Provider |
| Conformity assessment record + EU Declaration of Conformity | Art 43, Art 47, Annex V | Provider |
| Automatically generated logs / record-keeping | Art 12 (design), Art 19 (retention) | Provider keeps >=6 months; deployer keeps logs under its control |
| Risk-management system records | Art 9 | Provider |
| Fundamental Rights Impact Assessment (where applicable) | Art 27 | Deployer (public-body / credit / insurance) |
| Instructions for use | Art 13 | Provider supplies; deployer retains |
| Registration in the EU database | Art 49, Annex VIII | Provider (and deployer for public-authority use) |
| Post-market monitoring records + any serious-incident reports | Art 72, Art 73 | Provider |
Keep the documentation current — Article 11 documentation must reflect the system as it actually runs, and a substantial modification (Article 3(23)) can reset your obligations. Technical documentation must be retained for 10 years after the system is placed on the market (Article 18).
Provider vs deployer: who holds which file
The single most common readiness error is a deployer assuming it must produce the provider's technical file. It does not. As a deployer (Article 26), your evidence is narrower: that you used the system per the instructions for use, ran the human oversight the provider specified (Article 14), kept the logs under your control, monitored operation, and — where you fall in scope — completed a FRIA (Article 27). The Annex IV technical file, the conformity assessment and the Declaration of Conformity belong to the provider (Article 16). If you build or substantially modify a system under your own name, Article 25 flips you into the provider role and the heavier file becomes yours. Knowing which column you sit in tells you which evidence you must be able to produce. See provider versus deployer roles.
The deadline that governs the file
Most of this evidence only becomes mandatory once the high-risk regime applies. Stand-alone high-risk Annex III systems now apply from 2 December 2027 (with Annex I product-embedded systems at 2 August 2028), under the Digital Omnibus deferral, which is formally adopted — the European Parliament passed it on 16 June 2026 and the Council on 29 June 2026, pending only Official Journal publication, expected before 2 August 2026. Two duties bind regardless of that date and belong in any readiness file now: Article 4 AI literacy (in force since 2 February 2025) and the Article 5 prohibitions.
Worked example: a deployer prepares for a request
Personalkraft GmbH, a ~210-employee staffing firm near Stuttgart with roughly EUR 46M turnover, deploys a third-party CV-screening tool — an Annex III point 4 high-risk use. It is a deployer, not the provider. When its national market-surveillance authority opens a thematic review of recruitment AI, Personalkraft's readiness pack contains: its AI inventory listing the tool with the high-risk classification; the provider's instructions for use and Declaration of Conformity (obtained at procurement); evidence of the human-oversight step a recruiter performs before any rejection (Article 14); the operational logs it retained; its Article 27 FRIA — completed because certain employment uses pull deployers into FRIA scope alongside the statutory credit and insurance cases; and its Article 4 literacy briefing. It does not hold the Annex IV technical file — that is the provider's. Because Personalkraft assembled this during procurement and operation, the authority's request becomes a retrieval exercise, not a reconstruction.
How Confir helps
Confir keeps the readiness file assembled as a by-product of normal compliance work: it registers each AI system, records the classification and the reasoned Article 6(3) assessment, derives your role, generates the Article 11 / Annex IV documentation and the Article 47 / Annex V Declaration of Conformity, runs the Article 27 FRIA where it applies, and holds an immutable audit log. The engine is deterministic and rule-based — the same intake always produces the same record — so when an authority asks, the evidence is current and exportable rather than scattered.
Frequently asked questions
Does the EU AI Act require an annual AI audit?
No. The Act does not mandate a recurring statutory audit the way financial law requires annual accounts. Instead, market-surveillance authorities can investigate under Article 74, and providers must cooperate under Article 21. "Audit readiness" is the voluntary practice of keeping the evidence those powers can demand — the technical file, logs, risk records and conformity documents — in a state you can hand over quickly.
What can a market-surveillance authority request?
For a high-risk system, an authority can require you to demonstrate conformity and produce the supporting records: the Annex IV technical documentation, the conformity assessment and Declaration of Conformity (Articles 43, 47), Article 12 logs, the Article 9 risk-management records, instructions for use, registration details (Article 49) and any serious-incident reports (Article 73). It acts on complaints, incident reports or thematic reviews, not a fixed calendar.
Do deployers need the technical documentation?
No. The Annex IV technical file, the conformity assessment and the Declaration of Conformity are provider duties (Article 16). A deployer's evidence is narrower under Article 26: use per the instructions, the human-oversight step, the logs under its control, monitoring records, and a FRIA where Article 27 applies. If you build or substantially modify a system under your own name, Article 25 makes you the provider and the heavier file becomes yours.
How long must AI Act records be kept?
Technical documentation must be retained for 10 years after the system is placed on the market (Article 18). Providers keep automatically generated logs for at least six months unless other law requires longer (Article 19); deployers keep the logs under their control. Post-market monitoring records (Article 72) and serious-incident documentation (Article 73) should be retained as part of the file.
When do these audit obligations start?
The underlying high-risk duties now apply from 2 December 2027 under the Digital Omnibus deferral (Annex I product-embedded systems at 2 August 2028), which is formally adopted — the European Parliament passed it on 16 June 2026 and the Council on 29 June 2026, pending only Official Journal publication, expected before 2 August 2026. Article 4 literacy and the Article 5 prohibitions already apply and belong in your file now.
Is audit readiness a legal requirement?
No — it is a governance practice, not a statutory term. The underlying records it organises (technical documentation, logs, risk files, FRIA, registration) are legally required for high-risk systems, but "audit readiness" itself is the discipline of keeping those artefacts current and retrievable so a regulator's request is a retrieval exercise rather than a reconstruction.
Related guides
- Provider versus deployer roles
- Annex IV technical documentation
- Conformity assessment, defined
- Article 27: the Fundamental Rights Impact Assessment
- EU AI Act audit preparation
- Market surveillance under the EU AI Act
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 14-day free trial.
Start free trial →