Module 7 of the AI Act Compliance certification: what to hold, what to report upward, what to budget, and how to state honestly what is not done.

The programme exists to answer two audiences: a supervisory authority that asks about a system, and a board that asks whether the organisation is exposed. They want different things, and confusing them produces documents that serve neither.

The audit file, per system

The supervisory audience works from a system outward. What they ask for, in roughly this order:

Artefact Source
The register entry Module 2
The classification determination, with reasoning, date and legal baseline Module 2
The Art. 5 check Module 1 sequencing
Instructions for use Art. 13, obtained at the procurement gate
Named human overseers, delegated authority, system-specific training Art. 26(2)
Override rate over time, and a sample of reasoned overrides The evidence oversight is live
Monitoring plan, and at least one worked incident Art. 26(4)
Logs, with retention arrangement and vendor access clause Art. 26(6)
Worker communication, dated before go-live Art. 26(7)
Affected-person notice and Art. 86 response procedure Art. 26(11), Art. 86
Art. 50 notices, and where they appear In force now
FRIA determination, including the negative Art. 27
Literacy register extract for the people touching this system Art. 4 and Art. 26(2)

If you provide the system rather than deploy it, add the Chapter III file: risk management with a dated review log, the Art. 10 data governance record, the Annex IV documentation, the declaration of conformity, the CE marking and registration references, and the post-market monitoring plan with its history.

The test is retrieval time. If producing this for one named system takes a week and four teams, the finding will be about governance rather than about the system.

What is not an audit obligation

Worth stating because programmes are often built around it: the AI Act imposes no periodic audit requirement on providers or deployers. There is no annual certification, no mandatory external review, and for most Annex III systems no notified body.

What the Regulation asks for instead is continuous — risk management as an iterative process, post-market monitoring throughout the lifetime, log retention, and the ability to cooperate. A programme that runs an annual audit and nothing between audits satisfies none of those, however thorough the audit.

An internal audit cycle is still worth having. Present it as assurance over the continuing duties, not as the discharge of one.

The board conversation

Four things, in this order.

1. What we run, and in which roles. A single slide: number of AI systems in the register; how many are Annex III high-risk, transparency-only, or minimal; how many we provide versus deploy; and whether any are prohibited (the answer should be none, and saying so explicitly is worth the line).

2. What is in force now versus what is due later. Boards routinely believe the whole Regulation lands in 2027. Show the split: Art. 5 and Art. 4 since February 2025, Chapter V since August 2025, Art. 50 since August 2026, high-risk from December 2027 and August 2028. The point is that current exposure is not zero and future exposure is not sudden.

3. The two or three real exposures. Not a risk register of forty items. The ones that would actually cost money or credibility — typically: a system whose classification is arguable, a purpose change that has already happened, a vendor who cannot supply Art. 13 instructions, or a literacy position that would not survive a question.

4. What is not done, why, and what it costs. This is the item that distinguishes a report from a reassurance exercise, and it is the reason a board briefing exists at all.

Saying honestly what is not done

The instinct is to report progress. The useful report names the gap, the reason and the decision required:

"Annex IV documentation for the internal underwriting model is not started. We concluded in September that we are its provider under Art. 3(3) because we developed it and put it into service. The obligation applies from 2 December 2027. Producing the file requires design rationale that has to be captured contemporaneously, so starting in 2027 is not viable. Estimated effort: X person-weeks across engineering and compliance, beginning Q1. Decision requested: fund, or withdraw the model from the decision path and use it for analysis only."

That paragraph does four things a status update does not: it states the position, gives the reason, names the constraint that makes delay expensive, and offers a real alternative. Boards can act on it.

Budgeting

The single variable that dominates cost is whether the organisation provides high-risk systems.

A pure deployer with a modest estate: the register, the three governance gates, the literacy programme, and the Art. 26 artefacts per high-risk system. This is weeks of work spread across months, mostly process design plus a per-system tranche. It is largely one-off, with a small continuing load.

A provider of high-risk systems carries Chapter III, and Chapter III is a function rather than a project: risk management running continuously, data governance built into how datasets are assembled, an Annex IV file maintained through the lifecycle, conformity assessment and reassessment on modification, post-market monitoring with a channel to deployers, incident handling with deadlines. Budget it as an ongoing capability with a named owner.

A GPAI model provider carries Chapter V, and if systemic risk applies, an evaluation and mitigation programme with its own specialist staffing.

The cheapest interventions, in order of return: the procurement gate, the purpose-change gate, and the literacy register. All three prevent expensive outcomes rather than remediating them, and none requires a large budget.

The programme in one page

If the whole track reduced to a single page, it would be this:

  1. Know what you run. The register, kept current by triggers rather than by an annual sweep.
  2. Check the prohibitions first. In force, highest band, and they catch ordinary deployments.
  3. Check Art. 50. In force, tier-independent, and probably your only current duty if you have no high-risk system.
  4. Take literacy measures and record them. Cheap, in force, and it feeds the enforceable Art. 26(2).
  5. Gate procurement, purpose and modification. This is where future problems stop being created.
  6. Build the Art. 26 or Chapter III artefacts against the real dates, starting with the ones that must accumulate.
  7. Be able to produce any of it for one named system in an afternoon.

Check yourself

  1. We passed our annual AI audit, so we are compliant.There is no audit obligation. What is asked for is continuous, and an audit with nothing between audits evidences none of it.
  2. The board briefing shows all workstreams green.A report with no gaps is a report that will produce surprises. Name what is not done, with the reason and the cost.
  3. We will start the Annex IV file closer to the deadline.Design rationale and disaggregated evaluation cannot be reconstructed. The parts that must accumulate are the parts to start first.
  4. What is the single cheapest control?The purpose-change gate. Five minutes at the moment of reuse, against the whole of Chapter III if Art. 25(1)(c) fires unnoticed.

Previous: Module 6 — Incidents, complaints and whistleblowing

You have completed the seven modules. Together they cover running the programme rather than performing any single obligation within it — sit the Compliance examination →

Frequently Asked Questions

No. There is no periodic audit obligation on providers or deployers as such. What exists is a set of continuing duties — risk management as a continuous process, post-market monitoring, log retention, cooperation — that are evidenced through artefacts. An internal audit cycle is good practice; it is not what the Regulation asks for, and presenting one as if it were is a weak position.

Four things: what the organisation runs and in which roles; what is in force now versus what is due later; the two or three exposures that are real rather than theoretical; and what is not done, with the reason and the cost. A board briefing that reports only progress is the one that produces surprises.

It depends almost entirely on whether the organisation provides high-risk systems. A pure deployer with a handful of systems is a matter of governance gates, a register, a literacy programme and Art. 26 artefacts — weeks of work spread over months. A provider of high-risk systems carries Chapter III: risk management as a process, Annex IV documentation, conformity assessment, post-market monitoring — an ongoing function rather than a project.

Take compliance further with the AI Act Academy

A free course, a server-graded exam, a verifiable certificate — and the working templates.