Module 1 of AI Risk Management Pro: what an EU AI Act compliance programme must actually produce, who owns it, the Art. 4 literacy baseline, and why the role determination under Art. 3(3), 3(4) and 25 is step zero.

The obligations in the AI Act are not evenly difficult. Reading them takes an afternoon; producing the records they imply takes a programme. This module is about the programme: what it must be able to put on a table, who owns each part, and the two determinations that have to be settled before any artefact is worth building.

The file is the deliverable

It helps to invert the usual framing. Rather than asking "what does the Regulation require?", ask "what will I be asked to produce, and by whom?" There are only four kinds of asker, and they want overlapping things:

Everything they ask for reduces to a small set of artefacts. A programme that produces those artefacts and keeps them current is compliant in the only sense that can be demonstrated; a programme that produces presentations about them is not.

Artefact Anchor Who typically owns it
AI system inventory with derived classification Art. 6, Annex I/III, Art. 6(3)-(4) Programme owner
Risk register, maintained Art. 9 Model/system owner, reviewed by risk
Data governance evidence Art. 10 Data owner
Annex IV technical documentation Art. 11 Engineering, assembled by programme owner
Instructions for use (as provider) / held copy (as deployer) Art. 13 Product
Human oversight arrangement and competence record Art. 14, Art. 26(2) Business line
Logs and retention Art. 12, Art. 19, Art. 26(6) Platform/engineering
Post-market monitoring plan and incident log Art. 72, Art. 73 Programme owner
AI literacy measures record Art. 4 HR with programme owner

Nine rows. If you can name an owner and a location for each, you have a programme. If you cannot, you have a reading of the Regulation.

Step zero: which obligations are actually yours

Every artefact above is conditional on a role, and the role is not self-evident. Two definitions do the work.

Art. 3(3) — provider. A person that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark, whether for payment or free of charge. Note what is absent: nothing about writing the code, and nothing about selling. A model built by your own team and used only internally has a provider, and it is you.

Art. 3(4) — deployer. A person using an AI system under its authority, except where used in a personal non-professional activity. This is most organisations for most systems.

Then the trap, and it is the single most consequential provision in this module:

Art. 25 — you can become a provider without deciding to. A deployer (or distributor or importer) is treated as the provider of a high-risk system if it puts its own name or trademark on it, makes a substantial modification to it, or modifies the intended purpose of a system — including a general-purpose system not classified as high-risk — such that it becomes high-risk. When that happens, the original provider ceases to be the provider for that system but must, under Art. 25(4), cooperate and supply information.

The practical shape of Art. 25: a deployer who fine-tunes a vendor model on its own data, rebrands a vendor system in its own interface, or points a general-purpose tool at a hiring decision can acquire the full Chapter III obligation set — the Annex IV file included — with no procurement event to trigger a review.

So the role determination is not a one-off. It has to be re-run whenever a system is modified or repurposed, which is why Module 2 treats classification as a process rather than a project.

The literacy baseline, and what it is not

Art. 4 requires providers and deployers to take measures to ensure a sufficient level of AI literacy among staff and other persons dealing with the operation and use of AI systems on their behalf. It is in force, it applies regardless of risk tier, and it is the one obligation essentially every organisation in scope already owes.

Three things practitioners get wrong:

  1. It binds the organisation, not the individual. No person can be "AI Act certified" — conformity assessment and notified bodies in this Regulation apply to systems, not people (Art. 3(20)-(22), Art. 48).
  2. Since the Digital Omnibus it asks for measures, not an outcome. Regulation (EU) 2026/1744 rewrote Art. 4 on exactly this point with effect from 27 July 2026. A programme that promises a guaranteed level of literacy is promising more than the law asks and more than it can evidence.
  3. There is no Art. 4 fine. Art. 4 appears in no paragraph of Art. 99. The real exposure is Art. 26(2) — oversight assigned to people without the necessary competence, training and authority — which sits in the Art. 99(4) band.

What to keep: a curriculum by role, a dated training register with names, and a coverage figure you can recompute. That is a measure, it is evidence, and it is cheap.

Writing the mandate

A programme mandate is one page and settles five things. Written down, it ends most of the arguments that otherwise recur monthly.

  1. Scope. Which legal entities, which jurisdictions, and whether non-EU group systems serving EU users are in (Art. 2 extraterritorial reach generally means yes).
  2. The accountable owner, by name, with budget authority.
  3. Artefact owners, by name, for the nine rows above.
  4. Risk tolerance. The band inside which a residual risk may be accepted without escalation, and who escalates. Module 3 depends on this existing.
  5. Cadence. When the inventory is re-swept, when registers are reviewed, when the literacy register is recomputed. Module 8 turns this into a calendar.

The fifth is the one most often left out, and its absence is what turns a programme into a project that finishes.

What this buys you under the deadlines

The timetable is not evenly spread, and after the Omnibus it is not what most 2025 slide decks say:

The high-risk dates look comfortable. They are not, because the artefacts in the table cannot be produced retrospectively: Art. 10 data governance evidence for a dataset assembled without it, and an Annex IV file for a system built without documentation discipline, are rework rather than writing. A programme started in late 2027 does not arrive in time for December 2027.

Check yourself

  1. We buy all our AI, so Chapter III does not apply to us. — Check Art. 25 first. Rebranding, substantial modification, or repurposing toward a high-risk use makes you the provider.
  2. We built a model for internal use only and never sell it. — Putting into service includes own use. You are its provider under Art. 3(3).
  3. Art. 4 could fine us 15 million. — No. Art. 4 is in no paragraph of Art. 99. The route to a fine is Art. 26(2), in the Art. 99(4) band.
  4. Our programme has an owner and artefact owners, so the mandate is done. — Not until a risk tolerance and a review cadence are written down. Module 3 cannot define "accepted" without the first; Module 8 cannot build a calendar without the second.

Next: Module 2 — Inventory and classification as a process →

Frequently Asked Questions

The Regulation does not prescribe a function, so the answer is organisational rather than legal. What it does prescribe is that someone can produce the records: Art. 11 and Annex IV require technical documentation to exist before a high-risk system is placed on the market, Art. 9 requires a risk management system to be maintained across the lifecycle, and Art. 26(2) requires deployers to assign human oversight to people with the necessary competence, training and authority. In practice the programme needs a single accountable owner with budget, and named artefact owners in engineering, data and the business line.

Yes. Art. 4 binds providers and deployers of AI systems generally, not only high-risk ones, and it is in force. Since the Digital Omnibus — Regulation (EU) 2026/1744, in force 27 July 2026 — it asks for measures supporting AI literacy rather than a guaranteed level of it. There is no dedicated fine in Art. 99 for Art. 4; the exposure runs through Art. 26(2), which carries the Art. 99(4) band.

An inventory of AI systems with a derived risk classification and the reasoning behind it; for each high-risk system, a maintained risk register, data governance evidence and an Annex IV file; a record of the human oversight arrangement and the logs it rests on; and a record of the AI literacy measures taken. Everything else is apparatus around those.