The EU AI Act and the European Regulatory Landscape

All courses / AI Governance / Module 1 / Chapter 3

Learning objectives

After the lesson the participant can:

Explain the risk-based structure of the AI Act: prohibited practices, high-risk AI systems, transparency obligations and general-purpose AI models.
Determine whether an organisation is provider or deployer of a system and identify what would move the role under Article 25.
Map the requirements of Articles 9 to 15 to architectural components and the evidence each produces.
Draft a regulatory position record for one AI system.

Key concepts

Product safety law: The style in which the AI Act is written: it defines a product category, assigns obligations to economic operators by role, requires conformity assessment before market placement and establishes market surveillance afterwards. Reading it this way is the first step to reading it well.
Provider and deployer: Roles defined in Article 3. The provider develops a system and places it on the market or puts it into service under its own name; the deployer uses a system under its authority in a professional context.
Roles that move: Under Article 25 a deployer becomes a provider if it puts its name on a high-risk system, substantially modifies it, or changes its intended purpose so that it becomes high-risk.
Presumption of conformity: Under Article 40, conformity with a harmonised standard published in the Official Journal creates a presumption of conformity. The chapter advises keeping the mapping from control to clause as data, so that new standards change the mapping and not the architecture.
Regulatory position: A versioned record in the architecture repository stating, for one system, the AI Act role and rationale, risk tier, applicable articles, GDPR lawful basis, sector instruments, supervisors and the triggers for the next review.

Interactive exercises

Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.

Interactive exercise 1 · Match

From requirement to architectural component

Match each requirement for high-risk AI systems with the architectural component that Table 3.1 assigns to it.

Interactive exercise 2 · Scenario

A fine-tuned model and a role that moves

Apply the chapter's account of roles under the AI Act. The scenario describes an architectural implication, not legal advice.

Teaching plan

10 min	Opening: why architects need their own map. The teacher contrasts reading law for liability with reading it for structure: components, records and reviewable decisions.
20 min	Teacher presentation of the four tiers, Table 3.1 from requirement to component to evidence, the roles and the timeline of application including the Digital Omnibus on AI.
10 min	Group work on adjacent instruments: each group takes the GDPR, DORA and NIS 2, or the Data Act and Cyber Resilience Act, and names one control that serves both it and the AI Act.
25 min	Exercise: participants draft a regulatory position record for one system, modelled on the benefits-eligibility-support example.
10 min	Debrief: pairs exchange records and check that every applicable article has a mapped control and a stated review trigger.

Discussion

Which ordinary technical decision in your organisation, such as fine-tuning, rebranding or reusing a system for a new purpose, could move you from deployer to provider without anyone noticing?
The chapter says the controls in Table 3.1 take longer to build than any plausible delay of the high-risk obligations. How should that shape planning after the postponement to December 2027?
Hansa Mutual applies AI Act controls as policy where the law does not yet require them. What are the arguments for and against doing so in a group that spans the Union, the EEA, the United Kingdom and Switzerland?

Written exercise

Exercise · 25 minutes

Codify a regulatory position

Choose one AI system in your own organisation, or take Nordvik Region's procured benefits-triage system. Write its regulatory position as a structured record with the fields of the chapter's example: the AI Act role and a one-line rationale, the risk tier and, if relevant, the Annex III area, the applicable articles, whether a fundamental rights impact assessment and registration are required, the GDPR lawful basis and whether special categories are processed, the Article 22 safeguard, sector instruments such as NIS 2 or DORA, the supervisors that may read the record, and the events that trigger the next review. Then list one pipeline check that should fail if the record is incomplete.

Deliverable: A completed regulatory position record for one system and one proposed pipeline check with the condition that makes it fail.

Your work

Self-test

Choose an answer to see whether it is right, or open the answer below each question.

Under the Digital Omnibus on AI, as the chapter reports it, from which date do the Annex III high-risk obligations apply?
Show the answer
C. 2 December 2027
Regulation (EU) 2026/1744 moved the Annex III high-risk obligations to 2 December 2027 and those for products under Annex I to 2 August 2028.
How does the chapter propose to resolve the pull between Article 12 record-keeping in the AI Act and storage limitation in the GDPR?
Show the answer
B. By a retention policy that keeps the required logs and minimises personal data in them
The two obligations pull in opposite directions. The chapter's resolution is architectural: a retention policy that keeps the logs the AI Act requires while minimising the personal data they contain.
Where the regulatory map meets engineering, how does the chapter divide the work?
Show the answer
D. Governance owns the requirement and engineering owns the means
Governance states the obligation, threshold and acceptable evidence in the obligation mapping; the platform team demonstrates that its mechanism produces that evidence. Left implicit, the interface fails in one of two ways the chapter describes.