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:
- a market surveillance authority under Art. 74, which may request documentation and, under Art. 92 for GPAI, far more;
- a notified body, where Annex VII applies;
- a customer's procurement or risk function, which increasingly asks deployers for the provider's Art. 13 instructions and the deployer's own oversight arrangement;
- your own internal audit, which is the only one of the four you can schedule.
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:
- 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).
- 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.
- 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.
- Scope. Which legal entities, which jurisdictions, and whether non-EU group systems serving EU users are in (Art. 2 extraterritorial reach generally means yes).
- The accountable owner, by name, with budget authority.
- Artefact owners, by name, for the nine rows above.
- Risk tolerance. The band inside which a residual risk may be accepted without escalation, and who escalates. Module 3 depends on this existing.
- 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:
- 2 August 2026 — Art. 50 transparency duties apply. Not deferred.
- 2 December 2026 — content marking for systems already on the market, and the new Art. 5 prohibition.
- 2 December 2027 — the high-risk regime for standalone Annex III systems.
- 2 August 2028 — Annex I embedded products.
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
- 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.
- 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).
- 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.
- 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 →
AI Act meets DORA and NIS2
Is your organisation subject to both the AI Act and DORA? The two regulations intersect on the operational resilience of financial AI systems. Our sister site regulation-dora.eu covers DORA in depth — including what the AI Act adds on top of an existing DORA programme.
The AI Act for financial institutions ↗ Explore regulation-dora.eu ↗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.