The EU AI Act and the European Regulatory Landscape

This chapter gives architects a working map of the law that governs AI in Europe. It is not legal advice but a description of the obligations that shape architecture, attributed to the instruments and articles that create them. It covers the risk-based structure of Regulation (EU) 2024/1689, the AI Act, its roles, timeline, conformity assessment and standards, how it interlocks with adjacent European instruments, and who supervises it, and it ends with a codified regulatory position that Chapters 8 to 11 make executable.

The European regulatory landscape around an AI system: the AI Act at the centre, related instruments around it, supported by harmonised standards and supervisory authorities

Figure 3.1: The AI Act sits at the centre of a landscape in which the GDPR, DORA, NIS 2, the Data Act and the Cyber Resilience Act apply alongside it, harmonised standards give a presumption of conformity and the AI Office and national authorities supervise. Its four tiers are described in the text.

Why architects need their own map

Legal teams read regulation to determine liability; architects read it to determine structure: which components must exist, which records must be kept and which decisions must be reviewable. The AI Act is written in the style of European product safety law: it defines a product category, assigns obligations to economic operators by role, requires conformity assessment before market placement, and establishes market surveillance afterwards (1, European Union, 2024). That style is foreign to most software architects, so reading the Act as a product safety law is the first step to reading it well.

The risk-based structure

Prohibited practices

Article 5 prohibits a short list of practices outright, including manipulative or deceptive techniques that cause significant harm, exploitation of vulnerabilities due to age or disability, social scoring leading to detrimental treatment, certain predictive policing based solely on profiling, untargeted scraping of facial images, emotion recognition in workplaces and education except for medical or safety reasons, and most real-time remote biometric identification in public spaces for law enforcement. The intended-purpose statement of every system, and the prohibited-uses list in every agent manifest, must therefore be checked against this list at intake, and the check recorded.

High-risk AI systems

Article 6 defines high-risk systems in two ways. Annex I covers AI that is, or is a safety component of, a product already subject to EU harmonisation legislation with third-party conformity assessment, such as medical devices and toys; the Digital Omnibus on AI moved machinery to Section B of Annex I, where only a few provisions of the Act apply (27, European Union, 2026). Annex III lists stand-alone use cases: biometrics, critical infrastructure, education, employment, access to essential private and public services including creditworthiness and public benefits, law enforcement, migration, and justice and democratic processes. Article 6(3) allows a provider to conclude that an Annex III system is not high-risk where it performs a narrow procedural task or does not materially influence a decision, provided that assessment is documented and the system registered. The requirements of Chapter III, Section 2 are architectural before they are legal, as Table 3.1 shows.

AI Act requirement Architectural component Evidence produced
Article 9 risk management Risk register as code, re-evaluated on model or data change Register versions, pipeline gate results
Article 10 data governance Data contracts, lineage, bias examination in the data pipeline Lineage graphs, bias reports
Article 11 technical documentation Architecture repository generating Annex IV documentation Generated documentation with commit references
Article 12 record-keeping Audit log with retention Immutable logs, retention policy
Article 13 transparency Model and system cards, API contracts with provenance Published cards, contract versions
Article 14 human oversight Approval gates, interruption paths, role model Approval records, oversight configuration
Article 15 accuracy and robustness Evaluation suite, adversarial testing, security controls Evaluation reports, red teaming results

Transparency obligations

Article 50 applies regardless of risk tier, covering interaction with an AI system, synthetic content, deep fakes, and AI-generated text published on matters of public interest, each needing a disclosure, a marking or both, so it reaches far more systems than the high-risk regime does. Chapter 10 places disclosure and marking in the architecture.

General-purpose AI models

Chapter V regulates general-purpose AI models at the level of the model provider. Article 53 requires technical documentation, information for downstream providers, a copyright policy and a public summary of training content, and Article 55 adds evaluation, adversarial testing, incident reporting and cybersecurity for models with systemic risk, presumed above a compute threshold set in Article 51. The General-Purpose AI Code of Practice of July 2025 offers providers a route to demonstrate compliance (14, European Commission, 2025). For most readers the implication is downstream: you depend on the provider's Article 53 documentation to meet your own Articles 10 and 11 obligations, so your vendor assessment must check that it exists.

Roles and why they move

The AI Act assigns obligations by role, 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; importers, distributors and authorised representatives complete the chain.

Roles move, and this is where architecture programmes are caught out. 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, so an organisation that fine-tunes a vendor's model for creditworthiness assessment is very likely a provider of a high-risk system. An AI Decision Record, which extends the architecture decision record that Nygard proposed (78, Nygard, 2011), states which role the organisation occupies for each system and why. Deployer obligations under Article 26 are substantial too: use in accordance with instructions, competent human oversight, relevant input data, monitoring, log retention for at least six months, and informing affected workers and persons. Public bodies deploying high-risk Annex III systems, other than those in critical infrastructure (point 2), must also carry out a fundamental rights impact assessment under Article 27 and register under Article 49, as Chapter 17 describes.

Across the usage modes

The usage modes of Chapter 2 (usage-mode matrix) indicate the usual role, though they do not replace the analysis.

Mode Usual AI Act role Obligations that most often apply
Mode 0 – Ambient AI Deployer, where used under the organisation's authority Article 4; Article 50(4) if generated text is published to inform the public
Mode 1 – Conversational assistants Deployer Article 4; Article 50(4); the GDPR for personal data in prompts
Mode 2 – Embedded workplace assistants Deployer Article 4; use for an Annex III purpose can make it a provider under Article 25(1)(c)
Mode 3 – Agentic work tools Deployer of the tool Article 4; generated code is not itself an AI system unless it implements one
Mode 4 – Built AI applications Provider and deployer of what it builds; downstream provider of integrated models Articles 9 to 17 and 43 if high-risk; Article 50(1) and (2)
Mode 5 – Autonomous production agents As Mode 4 As Mode 4, with Article 14 oversight design and Article 26 monitoring for high-risk uses

Classification follows purpose, not mode: an embedded assistant used to rank job applicants is high-risk under Annex III point 4 however it was procured. What the mode changes is who designed the system; under Article 3(11), putting a system into service for the organisation's own use is enough to make it the provider of a system it built (1, European Union, 2024).

Timeline of application

The AI Act entered into force on 1 August 2024 and applies in stages under Article 113: the prohibitions and Article 4 literacy from 2 February 2025; general-purpose AI obligations, governance provisions and most penalties from 2 August 2025; and most remaining provisions, including Article 50, from 2 August 2026. The Digital Omnibus on AI, 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, replacing the Commission's proposal of November 2025 to tie them to the availability of standards (27, European Union, 2026). General-purpose AI models placed on the market before August 2025 are covered from 2 August 2027. The architectural point does not depend on the dates, however: the controls in Table 3.1 take longer to build than any plausible delay.

Conformity assessment and harmonised standards

Before placing a high-risk system on the market, a provider must pass a conformity assessment under Article 43 and complete the declaration, CE marking and registration of Articles 47 to 49; for most Annex III systems this is internal control, as Chapter 11 describes. Substantial modification triggers reassessment, so the model lifecycle must define what counts as substantial. Under Article 40, conformity with a harmonised standard published in the Official Journal creates a presumption of conformity. CEN and CENELEC are developing these standards through Joint Technical Committee 21 (24, CEN-CENELEC, n.d.); until they appear, ISO/IEC 42001 and ISO/IEC 23894 are the closest references. Design the evidence pipeline so that the mapping from control to clause is data, not prose; when the standards arrive, you then change the mapping, not the architecture.

Interplay with adjacent instruments

The AI Act does not affect the GDPR and is without prejudice to other Union rules on consumer protection and product safety (Article 2(7) and (9)), so the architecture must satisfy several instruments from one set of controls.

The GDPR

Regulation (EU) 2016/679 applies whenever personal data is processed in training, evaluation, inference, logging or caching. Articles 5 and 6 require a lawful basis and purpose limitation, Article 9 restricts special categories, Article 22 restricts decisions based solely on automated processing with legal or similarly significant effects, and Article 35 requires a data protection impact assessment (DPIA) for high-risk processing (2, European Union, 2016). Because the fundamental rights impact assessment is designed to complement the DPIA, the sensible architecture runs them as one pipeline with two outputs. The AI Act's Article 12 record-keeping and the GDPR's storage limitation pull in opposite directions; a retention policy that keeps the required logs and minimises the personal data in them resolves the conflict.

DORA and NIS 2

DORA, Regulation (EU) 2022/2554, requires financial entities to manage ICT risk, report major incidents, test resilience and govern ICT third-party providers (3, European Union, 2022). An AI service supporting a critical function is ICT, its model provider is a third party, and the AI Act's post-market monitoring (Article 72) and incident reporting (Article 73) run alongside DORA's incident regime. NIS 2, Directive (EU) 2022/2555, imposes cybersecurity risk management under Article 21 on essential and important entities (4, European Union, 2022). The AI Act's Article 15 is therefore an AI-specific layer on top of sector obligations, and one set of security controls should serve both.

Data, products and principles

The Data Act, Regulation (EU) 2023/2854, gives users of connected products rights to access and share their data, and its Chapter VI requires data processing services to remove obstacles to switching, which makes it a sovereignty control as well as a commercial one (5, European Union, 2023). The Data Governance Act, Regulation (EU) 2022/868, establishes data intermediation services and data altruism, which can enable European data spaces (28, European Union, 2022). The Cyber Resilience Act, Regulation (EU) 2024/2847, imposes cybersecurity requirements on products with digital elements (6, European Union, 2024); where a high-risk AI system is such a product, meeting them is deemed to satisfy the cybersecurity requirements of Article 15 of the AI Act, provided the EU declaration of conformity demonstrates the level Article 15 requires (Article 12 of the Cyber Resilience Act), so one secure development lifecycle and one software bill of materials extended to models should serve both. Finally, the Council of Europe's Framework Convention, opened for signature in September 2024, is the first binding international treaty on AI, committing parties to transparency, accountability, equality, privacy and reliability, in particular for public authorities (21, Council of Europe, 2024), and the OECD Recommendation supplies the definition that Article 3(1) of the AI Act closely follows (22, OECD, 2019). Neither binds an organisation directly, but both shape how authorities interpret the AI Act and anchor the principles of Chapter 4.

Supervision: the AI Office and national authorities

The European AI Office, within the Commission, supervises general-purpose AI models directly, coordinates enforcement and supports the European Artificial Intelligence Board (15, European Commission, n.d.). Each member state designates under Article 70 at least one notifying authority and one market surveillance authority, often splitting supervision between data protection, sector and digital agencies, and Article 57 requires at least one regulatory sandbox by 2 August 2027, a date the Digital Omnibus on AI moved back by a year. A Swedish bank's credit-scoring model may thus answer to the financial supervisor, the data protection authority and a market surveillance authority, so the evidence pipeline of Chapter 11 must produce views of the same records for each.

How this book uses the map

Part II reads the map from the supply side, turning Articles 25, 53 and 55, Article 28 of the GDPR and DORA's third-party rules into model-origin assessments, contract clauses and exit plans; Part III reads it as controls, from Chapter 8's executable risk tiers to Chapter 11's evidence; and Part IV reads it as an allocation of accountability, since Articles 4, 26 and 27 presuppose named roles with authority and competence.

Where the map meets engineering, governance owns the requirement and engineering owns the means. Article 12 requires traceable logs but does not name a telemetry stack, and Article 15 requires appropriate robustness but does not prescribe the evaluation harness. Governance therefore states the obligation, threshold and acceptable evidence in the obligation mapping, and the platform team demonstrates that its mechanism produces that evidence. Left implicit, the interface fails: engineering misses a control the law requires, or governance approves a system on a policy that no component enforces.

Codifying the regulatory map

Each system's position on the map belongs in the architecture repository; Appendix A extends the excerpt below into a full obligation mapping.

apiVersion: ai-architecture.example.org/v1
kind: RegulatoryPosition
metadata:
  system: benefits-eligibility-support
  decision_record: ADR-0207
  reviewed: "2026-09-15"
spec:
  ai_act:
    role: deployer
    role_rationale: Vendor model used within intended purpose; no substantial modification
    risk_tier: high-risk
    annex_iii_area: 5a essential public services and benefits
    applicable_articles: [26, 27, 49, 50]
    fria_required: true
    eu_database_registration: required
  gdpr:
    lawful_basis: Article 6(1)(e) public task
    special_categories: true
    article_22_safeguards: human decision by case officer recorded per case
    dpia_reference: DPIA-2026-014
  sector:
    nis2_entity_type: essential
    dora_applicable: false
  supervisors:
    - national market surveillance authority
    - data protection authority
  next_review_trigger: model change, data source change, or legal update

A pipeline stage validates the record, checks that every applicable article has a mapped control, and fails the build if a high-risk public-sector system lacks a fundamental rights impact assessment reference. A change in the law then becomes a change to data that propagates through the pipelines of Chapters 8, 9 and 11 rather than a memo that propagates through meetings.

Nordvik Region and Hansa Mutual

For Nordvik Region the map is complicated but single: the AI Act makes it a deployer of a high-risk system under Annex III point 5(a), with Articles 26, 27 and 49 applying (1, European Union, 2024), beside the GDPR, administrative law and procurement law.

For Hansa Mutual, by contrast, the map is the problem. The AI Act applies directly in its German, Dutch, Swedish and Polish entities, but supervision, sandboxes and penalties are national under Articles 57, 70 and 99 (1, European Union, 2024). Norway follows through the EEA Agreement, where the AI Act is still listed as under scrutiny for incorporation (187, EFTA, n.d.); the UK relies on existing regulators (188, DSIT, 2023); and Switzerland on its revised data protection act (190, Swiss Confederation, 2020). Under the GDPR Hansa has one lead supervisory authority under Article 56, but Articles 9(4) and 88 let national law add conditions for health and employee data (2, European Union, 2016), and DORA binds the EU entities only (3, European Union, 2022). Each Hansa system therefore records where it is used and which instrument applies there, and the group applies AI Act controls as policy where the law does not yet require them.

Summary

The AI Act is a product safety law for AI. It sorts systems into prohibited, high-risk, transparency-bound and general-purpose tiers, assigns obligations by roles that move when a system is modified or rebranded, applies in stages between February 2025 and August 2028, and relies on conformity assessment and harmonised standards to make requirements testable. Around it, the GDPR, DORA, NIS 2, the Data Act, the Cyber Resilience Act and the international instruments impose adjacent obligations that several authorities will read from the same evidence. Recording each system's regulatory position as a versioned artefact is therefore the first step. Chapter 4 now proposes eight principles to guide an architecture that must answer to this map.

Sources

  1. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union. (1, European Union, 2024)
  2. European Parliament and Council of the European Union (2016). Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). Official Journal of the European Union. (2, European Union, 2016)
  3. European Parliament and Council of the European Union (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union. (3, European Union, 2022)
  4. European Parliament and Council of the European Union (2022). Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union. (4, European Union, 2022)
  5. European Parliament and Council of the European Union (2023). Regulation (EU) 2023/2854 on harmonised rules on fair access to and use of data (Data Act). Official Journal of the European Union. (5, European Union, 2023)
  6. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union. (6, European Union, 2024)
  7. European Commission (2025). The General-Purpose AI Code of Practice. European AI Office. (14, European Commission, 2025)
  8. European Commission. European AI Office. Shaping Europe's digital future policy pages. (15, European Commission, n.d.)
  9. Council of Europe (2024). Framework Convention on Artificial Intelligence and Human Rights, Democracy and the Rule of Law (CETS No. 225). (21, Council of Europe, 2024)
  10. Organisation for Economic Co-operation and Development (2024). Recommendation of the Council on Artificial Intelligence (OECD/LEGAL/0449). (22, OECD, 2019)
  11. CEN-CENELEC. Joint Technical Committee 21 – Artificial Intelligence. cencenelec.eu. (24, CEN-CENELEC, n.d.)
  12. European Parliament and Council of the European Union (2026). Regulation (EU) 2026/1744 amending Regulation (EU) 2024/1689 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI). Official Journal of the European Union. (27, European Union, 2026)
  13. European Free Trade Association. EEA-Lex factsheet 32024R1689: the Artificial Intelligence Act. EFTA. (187, EFTA, n.d.)
  14. Department for Science, Innovation and Technology and Office for Artificial Intelligence (2023). A pro-innovation approach to AI regulation (CP 815). UK Government, 29 March 2023. (188, DSIT, 2023)
  15. Swiss Federal Assembly (2020). Federal Act of 25 September 2020 on Data Protection (Data Protection Act, FADP), SR 235.1. Fedlex, in force 1 September 2023. (190, Swiss Confederation, 2020)
  16. Nygard, M. Documenting Architecture Decisions. Cognitect blog, 15 November 2011. (78, Nygard, 2011)
  17. European Parliament and Council of the European Union. Regulation (EU) 2022/868 on European data governance (Data Governance Act). Official Journal of the European Union, 3 June 2022. (28, European Union, 2022)