# Regulation AI — EU AI Act Hub — Full Content Export > Source: https://www.regulation-ai.eu > Generated: 2026-10-26 > License: CC BY 4.0 ================================================================================ ## Your EU AI Act Certificate — View, Print and Share URL: https://www.regulation-ai.eu/en/certificate/ Every certificate issued here carries a public id of the form `AI-2026-XXXXXXXX`. Paste it below to open the certificate, print it, or attach it to your LinkedIn profile. If you arrived from a link that already contains an id, the certificate loads on its own. ## What you can do with it **Add it to your LinkedIn profile.** The link fills in the certification name, the issuer, the issue date and the id, and points the credential URL at the [public verification page](/en/verify/) — so a recruiter who clicks through from your profile arrives at proof, not at an advert. **Print it, or save it as a PDF.** The print view is a single A4 landscape sheet with the site furniture removed. **Carry it as an Open Badge.** The assertion is a hosted JSON-LD document following the Open Badges 2.0 specification, readable by badge wallets. Your email address appears in it only as a salted SHA-256 hash. ## What it says, and what it does not The certificate records that you sat an examination on this site and passed it: which course, what score, on what date, under which name. The paper is drawn per candidate from a question bank and graded on our server — the answer key never reaches the browser. It is a private certificate. We are not a notified body, and this is not an accredited certification scheme under Regulation (EU) 2024/1689 — [there is no such thing for individuals](/en/academy/certification/), because the Regulation's conformity assessment applies to AI systems rather than to people. Your identity is verified by email address and the examination is unproctored; both facts are printed on the certificate rather than left for someone to discover. That is the honest description, and it is worth more in a governance file than a claim that does not survive a phone call. -------------------------------------------------------------------------------- ## Privacy Notice — regulation-ai.eu URL: https://www.regulation-ai.eu/en/privacy/ ## The short version This site carries **no advertising trackers** and nothing that follows you to other sites. It does use **Google Analytics** to count visits — and only if you say yes: nothing is requested from Google, and no cookie is set, until you accept in the banner. Decline and the site works exactly the same. We hold personal data only where you have handed it to us: a newsletter subscription, a purchase, an exam attempt, a certificate, or an email you sent us. If you have only read pages, and you declined measurement, we hold nothing about you. ## Cookies and audience measurement | Cookie | Set by | Purpose | Kept | |---|---|---|---| | `rai-consent` (local storage) | This site | Remembers whether you accepted or declined, so you are not asked on every page | 6 months, then you are asked again | | `_ga`, `_ga_G-3FS986W00M` | Google Analytics, **only after you accept** | Tells repeat visits apart so the visit count is not simply the page count | Up to 2 years, or until you decline | `rai-consent` is the record of your own choice and is stored in your browser only — it is never sent anywhere, and it is what the ePrivacy rules exempt as strictly necessary. Google Analytics is loaded by injecting Google's tag **after** the click, not before: if you decline, or ignore the banner, or browse with JavaScript off, your visit produces no request to Google whatsoever. There is no "cookieless ping". Advertising signals (`ad_storage`, `ad_user_data`, `ad_personalization`) are set to denied permanently — we run no advertising. **To change your mind at any time**, use the **Cookies** link in the footer of any page. Declining there also deletes the `_ga` cookies already set. What Google receives when you have accepted: the pages you view, approximate location derived from a truncated IP, browser and device type, and how you arrived. Google Ireland Limited acts as our processor; Google may transfer data to the United States under the EU–US Data Privacy Framework and its standard contractual clauses. ## What we collect, and why | What | When | Why | Kept | |---|---|---|---| | Email address | You subscribe to the newsletter | To send the newsletter | Until you unsubscribe | | Email address, IP address | You submit the subscription form | The IP is recorded with the submission as an anti-abuse measure | Until you unsubscribe | | Email address, purchase reference | You buy a toolkit or a course | To deliver the files, to re-issue your download links, and to honour refunds | As long as needed for accounting obligations | | Email address, answers, score | You sit a certification exam | To grade the paper server-side and to let you review the attempt | Until you ask us to delete it | | Email address, the name you chose, course and score | You are issued a certificate | So the certificate can be publicly verified by its id | Until you ask us to delete it | | Message content, sender address | You write to info@regulation-ai.eu | To answer you | Until you ask us to delete it | The **public certificate check** deliberately returns the holder name, course, score and issue date — and never the email address. That is the whole design: a certificate has to be verifiable by a third party without exposing the holder's address. ## Who else processes it We use four providers, each with its own terms: - **Convex** — the application backend and database, running in the **eu-west-1** region. - **Stripe** — payment processing. Card details never reach this site; they go to Stripe directly. - **AgentMail**, sending through **Amazon SES** — outbound and inbound email for `info@regulation-ai.eu`. - **Google Ireland Limited** — audience measurement through Google Analytics 4, **only for visitors who accepted it**. This is the only provider that receives anything about people who merely read pages, and only after they said yes. We do not sell personal data, and we do not share it for advertising. ## Your rights Consent to measurement can be withdrawn at any time through the **Cookies** link in the footer, with no consequence for using the site. Under the GDPR you can ask us to give you a copy of your data, correct it, delete it, or restrict what we do with it, and you can object to processing. Write to **info@regulation-ai.eu** from the address concerned and say what you want done. We do not charge for this and we do not require a form. If you subscribed to the newsletter, every message carries a one-click unsubscribe link; you do not need to email anyone. You also have the right to complain to your national data protection authority. ## Changes This notice was last updated on **16 August 2026**: Google Analytics 4 was added to the site behind a consent banner, and the sections on cookies and processors were rewritten accordingly. Before that date the site loaded no analytics at all. It was first published on **9 August 2026**. Substantive changes are dated here rather than made silently. ## Contact **info@regulation-ai.eu** -------------------------------------------------------------------------------- ## Verify an EU AI Act Certificate — Public Certificate Check URL: https://www.regulation-ai.eu/en/verify/ Every certificate issued by regulation-ai.eu carries a unique public id. Anyone holding that id — an employer, an auditor, a client — can check it here without an account. The check is deliberately narrow. It confirms what the certificate claims and nothing more: who it was issued to, for which course, with what score, and when. It does not expose the holder's email address, and it does not require the verifier to identify themselves. If you received a certificate id in an application or a governance file, paste it below. -------------------------------------------------------------------------------- ## EU AI Act Certification Exam — Free AI Literacy Certificate (Art. 4) URL: https://www.regulation-ai.eu/en/academy/exam/ The exam covers the five modules of the [AI Act Fundamentals course](/academy/ai-act-fundamentals/): scope and definitions, risk classification, obligations by role, general-purpose AI, and deadlines and enforcement. It is deliberately not a memory test. Most questions put you in a position someone actually occupies — you have licensed a vendor model and rebranded it, your fraud team wants to know if it is high-risk, your fine-tune is finished and you are wondering whose model it is now — and ask what follows. The questions that matter most are the ones where the intuitive answer is wrong. **Fifteen questions · 70% to pass · retake as often as you need.** Answers are graded on our server, not in your browser, which is what makes the certificate mean something. Every answer comes back with the reasoning and the article behind it, whether you got it right or not. ## What the certificate is, and what it is not It **is** documented evidence that you completed structured training on the EU AI Act and passed an assessment on it, with a public id anyone can verify. Art. 4 requires providers and deployers to take measures to support AI literacy among staff who work with AI systems; this is one of them, and it is the kind of artefact that belongs in your governance file. It is **not** an official EU credential — there is no such thing. No certification body has been designated by the EU for the AI Act, and anyone claiming to issue an "official EU AI Act certification" is describing something that does not exist. We are not a notified body and not a supervisory authority. -------------------------------------------------------------------------------- ## EU AI Act Training & Certification — Online Courses for Compliance Teams URL: https://www.regulation-ai.eu/en/academy/ ## EU AI Act training, from first principles to a certificate you can file Art. 4 of the AI Act asks every provider and deployer to take measures supporting the AI literacy of the staff who work with their AI systems. No deadline is attached and no course is prescribed — the obligation runs continuously, and what a supervisor can ask you for is the record of what you actually did. **A dated, nominative certificate is one such record, and this is where you get one for nothing.** The timetable behind it is not evenly spread. The Art. 50 transparency duties have applied since 2 August 2026. Content marking for systems already on the market follows on 2 December 2026, alongside the new Art. 5 prohibition. The high-risk regime for standalone Annex III systems lands on 2 December 2027, and Annex I embedded products on 2 August 2028 — far enough to feel comfortable, close enough that a programme begun in late 2027 will not be ready in time. Everything you can read here is free: 33 modules across five tracks, written against the article numbers rather than around them. What is paid is the examination for the four role certifications — in preparation — and the working files you would otherwise build from a blank spreadsheet. How the Academy works Three moves, in order. Stopping after the first is a legitimate outcome, and for most staff it is the right one. ReadFive modules on the Regulation itself, then a role track if your job touches the obligations directly. Free, no account, no order imposed on you. ProveA paper drawn per candidate and graded on our server. Pass at 70% and a certificate is issued with a unique ID, alongside an Open Badge for LinkedIn. ImplementKnowing the Regulation is not complying with it. The working files turn Art. 9, 10 and 11 into registers you can hand to an auditor. Start here: AI Act Fundamentals Whether you are in scope, and by what. Five modules, about three hours, and the certificate at the end costs nothing — no payment details are collected at any point. Free · certificate included €0 AI Act Fundamentals The foundation course, and one Art. 4 AI literacy measure you can put in the file. It answers the questions that come before every other question: does the Regulation reach us, what are we in it — provider, deployer, both — and what is already due. 5 modules · ~3 hours · 15-question exam · 70% to pass Start module 1 → Skip to the exam No account, no card, no time limit. The certificate carries your name and a public verification link a third party can check. What the AI Act is, and whether it reaches you Art. 2, 3 Risk classification: prohibited, high-risk, GPAI, minimal Art. 6, Annexes I & III Obligations by role: provider, deployer, importer, distributor Art. 16, 26 General-purpose AI models and systemic risk Art. 51–55 Deadlines, enforcement and what a fine is calculated on Art. 99, 113 Then certify the role you actually hold A deployer reading provider guidance is the commonest wasted quarter in this field. Four tracks, 28 modules, written from the seat the obligations are owed from. Every module is free to read; the examination and the certificate are the paid part, and they are not on sale yet. Deployer You buy AI, you do not build it The track for the 95%. Art. 26 taken paragraph by paragraph as an operating procedure, human oversight that survives a supervisory review, logs, and the Art. 25 triggers that quietly turn a deployer into a provider. 7 modules 20 questions bank of 101 Read the modules →Exam soon Provider You place high-risk AI on the market Chapter III end to end: the risk management system, data governance, the Annex IV technical file, oversight by design, conformity assessment, CE marking, registration, and the post-market loop that never closes. 8 modules 25 questions bank of 109 Read the modules →Exam soon GPAI You train, tune or build on a model Chapter V and what builds on it: the model/system boundary, Art. 53 obligations, the 1025 FLOP systemic-risk presumption, codes of practice, and the point at which fine-tuning makes you the provider. 6 modules 20 questions bank of 89 Read the modules →Exam soon Compliance & DPO You run the programme across the firm The transversal function: the inventory and classification register, the Art. 4 literacy programme after its July 2026 rewrite, governance gates at procurement, AI Act against GDPR, incident routes, and the audit file. 7 modules 20 questions bank of 92 Read the modules →Exam soon The five examinations, side by side They are not the same paper at different prices. The free one asks whether you are in scope; the role examinations ask whether you could run the obligation. QuestionsBankModulesWhat it asks Fundamentals · free 15605 Whether you are in scope, and by what Deployer 201017 Whether you could run Art. 26, not name it Provider 251098 Determinations that are unaffordable to reverse late GPAI 20896 Which chapter binds you, which party, which enforcer Compliance & DPO 20927 What is due, what is evidence, what is not owed Every paper is drawn per candidate and stratified so all modules are covered; the order of the options differs between candidates. Grading happens on our server — the answer key never reaches the browser. Each track page carries two sample questions on the same article, one from the free examination and one from its own, so you can see the difference before deciding. The working templates Knowing what Art. 11 requires is not the same as having an Annex IV file. These are the documents a supervisor, a notified body or a customer's procurement team actually asks to see — pre-structured, article-referenced, and yours to fill in. Art. 9 · Annex III AI Risk Register Risk scenarios pre-mapped to the eight Annex III categories, a 5×5 scoring matrix, mitigation tracking, residual risk, and a review schedule aligned to Art. 9(4). XLSXDetails → Art. 11 · Annex IV Technical Documentation File Annex IV section by section — intended purpose, design, training methodology, validation data, metrics, oversight, post-market plan, declaration of conformity — with an evidence owner and a completeness state per element. XLSXDetails → Art. 10 · Art. 53 Data Governance Checklist Training, validation and testing data: relevance, representativeness, completeness, bias examination, and the provenance documentation GPAI providers owe downstream. XLSXDetails → The three together are the AI Act Template Pack — €199 excl. VAT, one named user, downloadable the moment payment clears. Four more files are sold separately or together: transparency (Art. 50), system inventory and classification, vendor due diligence, and the Art. 4 literacy programme. All seven are the Complete Toolkit at €449. See every toolkit → Who this is for The obligations differ by role, so the path through the Academy does too. 🔒 Compliance officers & DPOs Work out which systems in the estate trigger obligations, build the classification register, and evidence the Art. 4 literacy programme. Start with Fundamentals, then the Compliance & DPO track. ⚖️ Legal counsel Map a client's systems to the Annex III categories, screen for Art. 5 prohibitions, and prepare the declaration of conformity. The Provider track covers the determinations that are expensive to reverse. 🏗️ Product & engineering What "human oversight" (Art. 14) and "accuracy, robustness and cybersecurity" (Art. 15) mean as build requirements, and what documentation a system needs before it can be placed on the market. 🏦 Financial institutions In scope of DORA and the AI Act at once: how ICT third-party risk management applies to AI vendors, and how incident reporting interacts under both regimes. See AI Act vs DORA vs NIS2. Workshops, seminars and e-learning for teams Self-study does not scale past a handful of people, and it produces no consistent record. For organisations with several teams touching AI — legal, compliance, product, HR, procurement — the same programme is delivered live and tailored to your own systems and sector. In-house workshopCustomised to your AI inventory, your sector's Annex III categories, and how roles are distributed across your teams.Half-day or full day · on-site or virtual Executive seminarBoard and C-suite briefing: obligations rather than principles, exposure, the decisions that have to be taken now, and what they cost.2 hours Custom e-learningWhite-labelled modules mapped to your own AI governance policy, hosted by you, with a per-participant completion record.Scoped per programme Corporate & executive training → ## Written against the article numbers There is no interpretation layer between the Regulation and what you read. Every module names the provisions it covers, and the templates are annotated the same way, so any field can be checked against the source text. Module 1 — scope and definitions Art. 2, 3 Module 2 — risk classification Art. 6, Annexes I & III Module 3 — obligations by role Art. 16, 26 Module 4 — general-purpose AI models Art. 51–55 Module 5 — deadlines and enforcement Art. 99, 113 One caveat we would rather state than bury: there is no official EU AI Act certification for a person, and there cannot be. Conformity assessment and notified bodies apply to AI systems, not to people (Art. 3(20)–(22), Art. 48). We are not a notified body, this is not an accredited scheme, and no course discharges Art. 4 on your behalf. What a certificate here gives you is a dated, verifiable record of one measure you took. -------------------------------------------------------------------------------- ## AI Act Compliance & DPO Certification Examination URL: https://www.regulation-ai.eu/en/academy/ai-act-compliance/exam/ Twenty questions on running an AI Act programme: what is in force, what the register must hold, what evidences the literacy duty, which gates prevent the expensive failures, where the GDPR and the AI Act pull apart, how a problem reaches a regulator, and what a supervisor asks for. The paper is drawn from a bank of over ninety and stratified across all seven modules. It is graded on our server; the answer key never reaches your browser. **Twenty questions · 70% to pass · every answer returned with its reasoning and its article.** ## Before you start This examination is part of the [AI Act Compliance & DPO track](/en/academy/ai-act-compliance/). The modules are free to read; the examination and the certificate are the paid part, and the address you sit under must be the address the track was bought for. If you have not bought the track, the [free AI Act Fundamentals examination](/en/academy/exam/) uses the same engine and certificate machinery at no charge. -------------------------------------------------------------------------------- ## AI Act Compliance & DPO Certification — Running the Programme URL: https://www.regulation-ai.eu/en/academy/ai-act-compliance/ Somebody in the organisation has to hold the whole picture: which systems exist, which obligations attach to which of them, who owns each, what evidence exists, and what happens next. That is rarely a provider engineer or a deployer business owner. It is usually a compliance officer, a DPO, or in-house counsel who acquired the file because nobody else would. This track is written for that person. It assumes you will not build a model or write a technical file, and that you will be the one asked whether the organisation is compliant — a question you can only answer if the evidence exists in a form you can produce. ## The seven modules **[Module 1 — The map, and the timetable that actually applies](/en/academy/ai-act-compliance/module-1/)** Who owes what across the roles, what is in force today, and why the December 2027 date is not a reason to wait. **[Module 2 — Inventory and classification register](/en/academy/ai-act-compliance/module-2/)** The register that answers the first question a supervisor asks, the fields that cannot be reconstructed, and the shadow-AI problem. **[Module 3 — The Art. 4 literacy programme](/en/academy/ai-act-compliance/module-3/)** What the July 2026 rewrite changed, why evidence shifted from levels to measures, and the register that satisfies it. **[Module 4 — Governance gates](/en/academy/ai-act-compliance/module-4/)** Procurement, purpose change and modification: three gates that between them prevent most of the expensive failures in this Regulation. **[Module 5 — AI Act and GDPR together](/en/academy/ai-act-compliance/module-5/)** DPIA and FRIA, Art. 22 and Art. 86, lawful basis, the Art. 10(5) special-category permission, and where the two regimes genuinely conflict. **[Module 6 — Incidents, complaints, whistleblowing](/en/academy/ai-act-compliance/module-6/)** The routes in and out: Art. 26(5), Art. 73, the Art. 85 complaint right, and the Art. 87 protection for reporting persons. **[Module 7 — The audit file and the board conversation](/en/academy/ai-act-compliance/module-7/)** What to hold, what to report upward, what to budget, and how to say honestly what is not done. ## What the examination asks Twenty questions drawn from a bank, stratified so every module is covered, graded on our server. The pass mark is 70%. ## Before you start This track assumes the [free Fundamentals course](/en/academy/ai-act-fundamentals/). It sits above the [Deployer](/en/academy/ai-act-deployer/) and [Provider](/en/academy/ai-act-provider/) tracks rather than replacing them: this one is about running the programme, those are about the obligations it has to deliver. -------------------------------------------------------------------------------- ## Module 1 — The Map, and the Timetable That Actually Applies URL: https://www.regulation-ai.eu/en/academy/ai-act-compliance/module-1/ Before any gap analysis, two maps: who owes what, and when. Getting the second wrong is the more expensive error, because it sends a programme at the part of the Regulation that is not yet due while the parts already in force go unaddressed. ## The roles, and what each owes | Role | Definition | Core obligations | |---|---|---| | **Provider** | Art. 3(3) — develops or has developed, and places on the market or puts into service under its own name | Art. 16 and the whole of Chapter III: Art. 9-15, 17, 43, 47-49, 72-73 | | **Deployer** | Art. 3(4) — uses under its own authority, other than personal non-professional activity | Art. 26 (twelve paragraphs), Art. 27 FRIA where in scope, Art. 50(3)-(4), Art. 86 | | **Authorised representative** | Art. 3(5) | Art. 22 for systems; Art. 54 for GPAI models | | **Importer** | Art. 3(6) | Art. 23 | | **Distributor** | Art. 3(7) | Art. 24 | | **GPAI model provider** | Chapter V | Art. 53; Art. 55 if systemic risk; Art. 54 if third-country | Two structural facts a compliance officer should internalise. **Almost every organisation is a deployer and nothing else.** Almost all published guidance is written for providers. That mismatch is the single largest source of wasted effort in this area. **Roles are per system, not per organisation.** The same company can be the provider of one system, the deployer of a second, and the distributor of a third. The register in Module 2 records the role per system for exactly this reason. ## The timetable, post-Omnibus Regulation (EU) 2026/1744 — the Digital Omnibus on AI — was published on 24 July 2026 and entered into force on 27 July 2026. It moved dates and rewrote Art. 4. Anything written before then needs re-checking. | Date | What applies | |---|---| | **2 February 2025** | Art. 5 prohibitions; Art. 4 AI literacy | | **2 August 2025** | Chapter V — GPAI model obligations | | **2 August 2026** | Art. 50 transparency duties; Commission enforcement powers over GPAI | | **2 December 2026** | New Art. 5 prohibition (CSAM / non-consensual intimate imagery); transitional deadline for Art. 50(2) marking of generative systems already on the market before 2 Aug 2026 | | **2 August 2027** | Regulatory sandboxes (deferred from 2026) | | **2 December 2027** | Chapter III for standalone Annex III high-risk systems (deferred from 2 Aug 2026) | | **2 August 2028** | Chapter III for AI embedded in Annex I regulated products (deferred from 2 Aug 2027) | Read that table as a compliance officer rather than as a lawyer. Everything above 2 December 2027 is **already enforceable**. Everything at or below it is preparation. ## What the deferral did and did not change **It did not** remove any obligation. Annex III systems are still high-risk; the requirements are unchanged; only the application date moved. **It did not** touch Art. 50, which is why an organisation with no high-risk system at all may still owe something today. **It did** rewrite Art. 4 from a duty of result — ensure a sufficient level of AI literacy — to a duty of means: take measures to support the development of AI literacy, with the text stating expressly that it does not require guaranteeing any specific level for any individual. Module 3 works through what that changes about evidence. **It did** create breathing room that is shorter than it looks. The artefacts required for a December 2027 deadline — a risk management system running as a process, an Annex IV file with contemporaneous design rationale, a monitoring plan with history — cannot be produced in the last quarter before the date. They accumulate or they do not exist. ## Sequencing a programme In order, and justified by the timetable rather than by tidiness: 1. **Inventory.** Nothing else is possible first. Module 2. 2. **Art. 5 across the inventory.** In force since February 2025, highest fine band under Art. 99(3) at 35 million euro or 7%, and it catches ordinary corporate deployments — emotion inference in the workplace above all. 3. **Art. 50 across the inventory.** In force since August 2026, tier-independent, and two of the four duties sit on deployers. 4. **Art. 4 literacy programme and register.** In force, cheap, and it feeds Art. 26(2) later. Module 3. 5. **Classification, written down.** With the date and the legal baseline. 6. **Governance gates.** Procurement, purpose change, modification. Module 4. This is where future problems stop being created. 7. **Chapter III artefacts** for whatever turned out to be high-risk, against December 2027. Steps 2 to 4 are the enforceable exposure today. Step 6 is the highest-leverage work. Step 7 is the largest. ## Enforcement, and who turns up **AI systems** are enforced by the national market surveillance authority designated by each Member State, with the powers of the market surveillance framework behind them. **GPAI models** are enforced centrally by the Commission through the AI Office, with fines under Art. 101 at up to 3% of worldwide annual turnover or 15 million euro. **Individuals** may lodge a complaint with a market surveillance authority under Art. 85, and Art. 87 brings reporting of AI Act infringements within the Union whistleblower protection framework. Module 6 covers both. Fines for other operators sit in Art. 99: 35 million euro or 7% for Art. 5 breaches; 15 million or 3% for the operator obligations including Art. 26; 7.5 million or 1% for supplying incorrect, incomplete or misleading information. **Art. 4 appears in none of those bands** — a fact worth knowing before budgeting a literacy programme on the basis of a fine that does not exist. ## Check yourself 1. *Nothing applies to us until December 2027.* — **Wrong.** Art. 5 and Art. 4 since February 2025, Chapter V since August 2025, Art. 50 since August 2026. 2. *We are a provider because we bought and configured a system.* — **Configuring is not developing.** You are a deployer unless one of the Art. 25 triggers fires. 3. *We should appoint an AI officer because the Regulation requires it.* — **It does not.** Naming an owner is how work happens, not a statutory duty. 4. *Art. 4 carries a large fine, so it is our first priority.* — **Art. 4 carries no fine band of its own.** It is a priority because it is cheap, in force, and feeds Art. 26(2), which does. --- **Next:** [Module 2 — Inventory and classification register →](/en/academy/ai-act-compliance/module-2/) -------------------------------------------------------------------------------- ## Module 2 — The Inventory and Classification Register URL: https://www.regulation-ai.eu/en/academy/ai-act-compliance/module-2/ A supervisor's first question is not about your policy. It is: which AI systems do you use. Everything else in a supervisory conversation branches from the answer, and the answer is a register or it is an anecdote. ## Why the register, not the policy, is the foundational artefact Three reasons. **It is the only artefact that is complete or not.** A policy can be good or bad; a register either lists the systems you run or it does not. That binary is why it is asked for first. **It is the input to every other obligation.** Classification, prohibitions, transparency duties, oversight assignment, log retention — all are per system. Without the list, each is done for whatever comes to mind. **Its gaps are the systems most likely to carry obligations.** A system that went through procurement was probably assessed by somebody. One that arrived on a corporate card was not. ## The fields, and why each is there | Field | Why | |---|---| | System name and description | Identification | | Business process served | Tells you who the affected persons are | | **Internal owner** | Somebody must be accountable; unowned systems drift | | Vendor, contract reference, renewal date | The contractual levers live here | | **Role held** — provider / deployer / both / distributor | Roles are per system, not per organisation | | **Declared intended purpose, quoted** | Answers the Art. 25(1)(c) question later; cannot be reconstructed | | Does output affect natural persons, and how | Gates Art. 26(11), Art. 86, Annex III relevance | | Personal data processed | Links to the record of processing and the DPIA | | **Classification conclusion** | The tier, the Annex III point checked, the carve-out relied on | | **Who decided, when, against which text** | Makes the determination reviewable rather than redoable | | Art. 5 check performed | Prohibitions are in force; evidence you looked | | Art. 50 duties identified | In force; two of four sit on deployers | | Human overseer(s) named | Art. 26(2) | | Log location and retention | Art. 26(6), and whether the vendor holds them | Three of these deserve emphasis. **The quoted intended purpose.** Not a paraphrase, not your understanding of it — the vendor's words. It is the baseline against which purpose creep becomes visible, and it is the field organisations most often skip because it feels like duplication of the contract. **The role held.** Compliance teams frequently write "deployer" across the whole register and then discover an internally built model, which has a provider, and it is them. **The legal baseline of the determination.** The Digital Omnibus rewrote Art. 4 and moved the Chapter III dates in July 2026. A determination that does not say which text it was made against cannot be reviewed — it can only be redone, and redoing sixty determinations is a quarter. ## The shadow-AI problem Every inventory exercise surfaces systems nobody had listed, and they are disproportionately the ones carrying obligations. Practical discovery routes: - **Expense and card data.** Filter for known AI vendors and for small recurring charges. - **Identity provider / SSO app inventory.** Anything OAuth-connected to a corporate account. - **Network egress.** Traffic to known model API endpoints from corporate networks. - **Feature flags in existing systems.** The riskiest category: an AI scoring or ranking feature switched on inside an ATS, CRM or service desk you already own and already registered as non-AI. - **Ask, with an amnesty.** A stated position that declaring a tool now has no consequence, and using an undeclared one later does, produces more disclosures than any technical control. That fourth route is the one technical discovery misses entirely, because there is no new vendor and no new traffic — just a toggle in a product you already have. ## Classification, and writing the negative For each system, record the conclusion **and the reasoning**, including where the conclusion is that nothing applies. A useful determination reads: *"Annex III point 4 considered because the system ranks internal candidates for promotion. Concluded: high-risk, no carve-out available. Art. 6(3) not relied on — the system profiles natural persons, which voids the filter under Art. 6(3). Decided by [name], 12 September 2026, against Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744."* And the negative case is as valuable: *"Annex III point 5(b) considered because the system scores transactions. Concluded: outside 5(b), which expressly carves out AI used to detect financial fraud. Decided by [name], date, against [text]."* Writing negatives down is what stops the same question being re-argued every quarter, and what lets a supervisor see that you looked rather than that you were lucky. ## Keeping it alive A register is current or it is archaeology. Three triggers should update it: **Procurement.** No new system without a register entry. Module 4. **Purpose change.** Any new use case for an existing system, which is the Art. 25(1)(c) gate. **Legal change.** When the law moves — as it did in July 2026 — the determinations with a superseded baseline need review, and the baseline field tells you which those are in one query. An annual review with no trigger-based updates produces a register that is accurate one day a year. ## What good looks like at inspection You can produce, for a named system, within minutes: what it is, who owns it, what role you hold, the classification and its reasoning, the intended purpose as declared, who oversees it, where the logs are and for how long, and which transparency notices apply. If that takes a week to assemble from four teams, the finding will be about your governance rather than about the system. ## Check yourself 1. *Our register lists vendors.* — **Register systems, not vendors.** One vendor may supply three systems in different tiers, and a feature toggle in an existing product is a system you already own. 2. *We recorded the classification but not the reasoning.* — **The reasoning is what makes it reviewable.** Record the Annex III point checked, the carve-out relied on, and the decision date and baseline. 3. *We are a deployer, so the whole register says deployer.* — **Roles are per system.** An internally built model has a provider, and it is you. 4. *Why quote the intended purpose rather than summarise it?* — **Because Art. 25(1)(c) turns on whether you changed it**, and a paraphrase written by you is not evidence of what the vendor declared. --- **Previous:** [Module 1 — The map, and the timetable that actually applies](/en/academy/ai-act-compliance/module-1/) **Next:** [Module 3 — The Art. 4 literacy programme →](/en/academy/ai-act-compliance/module-3/) -------------------------------------------------------------------------------- ## Module 3 — The Article 4 AI Literacy Programme URL: https://www.regulation-ai.eu/en/academy/ai-act-compliance/module-3/ Art. 4 is the obligation most organisations meet first, most often misdescribe, and most cheaply evidence. It is also the one that changed in July 2026, which means most existing positions and most published advice describe a text that no longer applies. ## What changed **Before**, Art. 4 required providers and deployers to take measures to ensure, to their best extent, a **sufficient level** of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf. **After** Regulation (EU) 2026/1744, in force since 27 July 2026, they shall take measures to **support the development** of AI literacy, and the text adds expressly that this **does not require providers or deployers to guarantee any specific level of AI literacy of any individual**. A second paragraph tasks the Commission and Member States with supporting and facilitating those efforts, with particular regard to SMEs. An obligation of result became an obligation of means. ## Why that is good news for the programme, not bad The instinct is to read a softened obligation as a reduced priority. That is the wrong conclusion for two reasons. **What must be proved got easier and more concrete.** Under the old text a defensible position tended toward assessment of attainment — testing people, and being able to say they reached a level. Under the new text the artefact is the **measure**: what you provided, to whom, when, and why it fitted their role. That is something an organisation can actually produce. **The commercial consequence for anyone selling training is the opposite of what it looks like.** If the obligation is to take measures, then a dated, nominative record of measures taken is precisely the evidence. The value of a training register went up, not down. ## Who is in scope "Staff and other persons dealing with the operation and use of AI systems on their behalf" is broader than employees. It reaches contractors, temporary staff, and outsourced operators who run systems for you. It does not reach your customers. The obligation is calibrated: measures shall take into account **technical knowledge, experience, education and training**, the **context** in which the systems are used, and the **persons or groups** on whom they are to be used. That is an instruction to differentiate. A single all-staff module is a measure; it is a weak one, and it is visibly not calibrated to anything. ## A programme that matches the text Four tiers, mapped to how people actually touch AI: **Tier 0 — everyone.** What an AI system is, what the organisation uses, what is prohibited, how to report a concern, and the rule that new use cases go through the gate. Thirty to sixty minutes. **Tier 1 — people who use AI in their work.** The systems they touch, what those can and cannot do, the limits stated in the instructions for use, and what to escalate. Role-specific by function. **Tier 2 — human overseers of high-risk systems.** This is not Art. 4 territory any more; it is Art. 26(2), which requires competence, training, authority and support tied to the specific system. Deeper, narrower, and enforceable. **Tier 3 — the compliance, legal and product people running the programme.** The Regulation itself. The distinction between tiers 1 and 2 is the one that matters most and is most often missed. A general awareness course answers Art. 4, which carries no fine. System-specific overseer training answers Art. 26(2), which carries the Art. 99(4) band. Do not let the first stand in for the second. ## The register One row per person, per measure: | Field | Note | |---|---| | Name and role | Role is what justifies the calibration | | Measure provided | Course, workshop, briefing, written guidance | | Date and duration | The dating is what makes it evidence | | Systems it relates to | Links the measure to the inventory | | Why this measure for this person | The Art. 4 calibration, in one line | | Evidence | Attendance, completion, or a certificate with a verifiable id | | Review trigger | Role change, new system, legal change | The last row matters because Art. 4 is continuous. A register with a single 2025 cohort and nothing since documents a measure taken once, which is not what an ongoing duty looks like. ## What a good record looks like in practice *"J. Okafor, procurement lead. Completed AI Act Fundamentals (5 modules, ~3 hours) and passed the examination on 14 September 2026 — certificate AI-2026-XXXXXXXX, verifiable publicly. Provided because procurement now operates the classification gate for new AI systems. Next review: on any change to the gate procedure or on a material change to the Regulation."* That reads as a measure, calibrated, dated, evidenced and connected to a business reason. It is also two sentences. ## The trap to avoid Do not claim that a course "satisfies" or "meets" Art. 4. Art. 4 binds the organisation, not the individual, and since the rewrite it asks for measures rather than for a guaranteed level. A training provider cannot satisfy an obligation that is not theirs, and claiming otherwise is the kind of statement that reads badly in a supervisory conversation and worse in a consumer-protection one. The accurate formulation is that a course is **one measure the organisation can record** against its Art. 4 obligation. That is both true and sufficient. ## Check yourself 1. *We test everyone and record their score, to prove a sufficient level.* — **The amended text expressly does not require guaranteeing a level for any individual.** Testing is fine; it is no longer what the obligation asks for. 2. *Art. 4 has a 3% fine, so it is our biggest exposure.* — **Art. 4 appears in no Art. 99 band.** The 3% band applies to Art. 26 and the other operator obligations. 3. *Our annual all-staff AI module covers our overseers.* — **It answers Art. 4, not Art. 26(2)**, which needs competence, training, authority and support tied to the specific system. 4. *Our training vendor says its course satisfies Art. 4.* — **A course cannot satisfy an obligation that binds your organisation.** It is one measure you record. --- **Previous:** [Module 2 — The inventory and classification register](/en/academy/ai-act-compliance/module-2/) **Next:** [Module 4 — Governance gates →](/en/academy/ai-act-compliance/module-4/) -------------------------------------------------------------------------------- ## Module 4 — Governance Gates: Procurement, Purpose, Modification URL: https://www.regulation-ai.eu/en/academy/ai-act-compliance/module-4/ Most of the expensive failures in this Regulation are not caused by a decision somebody got wrong. They are caused by a decision nobody made, because the moment at which it should have been made did not look like a decision point. Three gates fix that. They are cheap, they sit inside processes that already exist, and between them they prevent the Art. 25 traps, the shadow-AI problem and the undocumented determination. ## Gate 1 — Procurement **Trigger:** any acquisition or adoption of software with an AI component, including a feature toggle in an existing product and a free tool adopted by a team. **Checks:** 1. **Register entry created**, with the fields from Module 2. 2. **Instructions for use obtained and read.** Art. 13 obliges the provider to supply them; a vendor who cannot is selling something you cannot deploy compliantly for a high-risk purpose. This check alone kills more bad procurements than any other. 3. **Declared intended purpose captured verbatim.** 4. **Vendor's classification obtained**, and independently sanity-checked — you live with the consequences. 5. **Where Art. 6(3) is claimed**, the Art. 6(4) documentation and Art. 49(2) registration reference. If neither exists, the derogation has not been claimed. 6. **Sample Art. 12 log export seen**, so you know what you will be retaining and that you can retain it. 7. **Oversight measures** the provider considers appropriate, per Art. 14. 8. **Contract clauses**: log access and export; Art. 25 cooperation on information and technical access; incident notification with a timeframe connecting their Art. 73 duty and your Art. 26(5) duty; change and deprecation notice. 9. **Art. 5 check.** Is what this system does prohibited. 10. **Art. 50 check.** Which of the four duties will attach, and to whom. Every one of these is close to free before signature and close to impossible afterwards. That asymmetry is the entire argument for the gate. ## Gate 2 — Purpose change **Trigger:** any new use case for a system already in the register. Not a new system — a new *use*. This is the gate that does not exist in most organisations, because reusing a working pipeline is what good engineering practice tells a team to do, and nobody thinks of it as an acquisition. **Checks:** 1. **Compare the proposed use against the declared intended purpose** in the register. 2. If it differs, **re-run classification for the new use**. Would it be Annex III? Prohibited? Does an Art. 50 duty now attach? 3. If the new use makes the system high-risk, **stop**: Art. 25(1)(c) makes you the provider, with the whole of Chapter III attaching. 4. Check the **vendor's acceptable use policy**. A prohibited use puts you outside your licence as well as into Art. 25. 5. **Update the register**, whatever the answer. The worked example from the Deployer track is worth repeating because it is entirely ordinary: an insurer's document-understanding platform, configured by a claims team to score claims for fraud — outside Annex III 5(b), which carves fraud out — and then reused eighteen months later by a pricing team for health insurance risk assessment, which is Annex III 5(c). Two teams reused a pipeline. Nobody rebranded, nobody retrained, and the insurer became the provider of a high-risk system and one of the narrow set of deployers owing an Art. 27 FRIA. One form at the moment of reuse would have caught it. ## Gate 3 — Modification **Trigger:** any change to a system you provide, or any change you make to a system you deploy. **Checks:** 1. **Is this a substantial modification?** A change not foreseen or planned in the initial conformity assessment which affects compliance with the Chapter III requirements, or which results in a modification to the intended purpose. 2. If you are the **provider**: a substantial modification requires a **new conformity assessment** under Art. 43, an updated Annex IV file, a new declaration of conformity, and a database update. Changes **pre-determined at the initial assessment and documented** are not substantial modifications — which is the commercial argument for declaring update behaviour up front. 3. If you are the **deployer** and the modification is yours: **Art. 25(1)(b)** may make you the provider. 4. If you modified a **general-purpose model**: separately ask whether you have become the provider of a model under Chapter V. Different regime, different analysis. 5. **Record the assessment either way.** ## Who owns the gates Not compliance. A compliance function that owns all three gates becomes a queue, and a queue gets routed around. The gate belongs to whoever already owns the process it sits in: procurement owns gate 1, the product or engineering change process owns gate 3, and gate 2 belongs wherever new use cases are approved — usually a product or business owner. The compliance role is to **define what each gate checks**, to **see the exceptions**, and to **audit a sample**. That is a sustainable position; being the bottleneck is not. ## What the gates produce Each gate produces a record, and those records are the programme's evidence base: - Gate 1 → the register entry, the vendor file, the contract clauses. - Gate 2 → the purpose-change determinations, including the negatives. - Gate 3 → the modification assessments, which are also what Art. 17's modification-management element asks a provider to show. An organisation with three working gates can answer almost any supervisory question by pulling records, rather than by reconstructing history. ## Check yourself 1. *We run an annual AI review, which catches purpose changes.* — **Annually is too late.** Art. 25(1)(c) fires at the moment of reuse, and a year of operating a high-risk system without any Chapter III artefact is the finding. 2. *Procurement is a bottleneck; compliance should approve AI purchases directly.* — **That makes compliance the queue.** Define the checks, let procurement run them, and audit a sample. 3. *We fine-tuned a vendor's high-risk system on our data.* — **Gate 3.** Assess it against the definition of substantial modification; Art. 25(1)(b) may make you the provider. 4. *A team switched on an AI ranking feature in our existing CRM.* — **That is gate 1.** A feature toggle is a new system for classification purposes, and it is the category technical discovery misses entirely. --- **Previous:** [Module 3 — The Art. 4 AI literacy programme](/en/academy/ai-act-compliance/module-3/) **Next:** [Module 5 — AI Act and GDPR together →](/en/academy/ai-act-compliance/module-5/) -------------------------------------------------------------------------------- ## Module 5 — AI Act and GDPR Together URL: https://www.regulation-ai.eu/en/academy/ai-act-compliance/module-5/ Every organisation deploying AI on personal data runs two regimes at once, and the commonest failures come from assuming one answers for the other. This module maps where they overlap, where they differ, and the two or three points where they genuinely pull in different directions. ## The relationship, stated once The AI Act is **product-safety legislation**. It asks whether a system may be placed on the market and used, and it regulates the system through its lifecycle. The **GDPR** is data protection law. It asks whether processing personal data is lawful, fair and transparent, and it regulates the processing. The AI Act is **without prejudice** to Union data protection law. Both apply. Neither displaces the other, and neither is *lex specialis* to the other in any general sense. Practically: an AI system can be entirely compliant with the AI Act and unlawful under the GDPR, and vice versa. The two files share evidence; they do not share conclusions. ## DPIA and FRIA | | DPIA — GDPR Art. 35 | FRIA — AI Act Art. 27 | |---|---|---| | Who | Controller, where processing is likely to result in high risk to data subjects | Deployers that are public bodies, private entities providing public services, or deployers of Annex III 5(b) and 5(c) systems | | About | The processing | The deployment of a specific high-risk system in a specific context | | Assesses | Risks to rights and freedoms of data subjects | Risks of harm to fundamental rights of affected categories of persons | | Content | Description, necessity and proportionality, risks, measures | Processes of use, period and frequency, categories of persons affected, specific risks of harm, human oversight measures, measures if risks materialise | | Trigger | High risk to data subjects | Being one of the listed deployers of a high-risk system | Three practical points. **Most private organisations owe a DPIA and not a FRIA.** A private employer deploying Annex III point 4 recruitment screening owes a DPIA if the threshold is met, and no FRIA. Writing that determination down once is worth a quarter of avoided work. **Where both are owed, they complement.** Art. 27 provides that where any of the obligations are already met through the DPIA, the FRIA complements it. Share the evidence base; keep the documents distinct, because they answer different questions and a merged document usually answers neither well. **AI Act Art. 26(9) makes the provider's Art. 13 information feed the DPIA.** That is the practical link: the accuracy figures, limitations and oversight measures the provider must supply are inputs to your data protection assessment. ## Art. 22 GDPR and Art. 86 AI Act These are frequently confused and they are not close. **GDPR Art. 22** applies to a decision **based solely on automated processing**, including profiling, which produces legal effects or similarly significantly affects the data subject. Such decisions are prohibited unless one of three grounds applies — necessity for a contract, authorisation by Union or Member State law, or explicit consent — and where the contract or consent grounds apply, safeguards must include **the right to obtain human intervention, to express one's point of view, and to contest the decision**. **AI Act Art. 86** applies to a decision taken by a **deployer** on the basis of the output of a **high-risk Annex III system**, producing legal effects or similarly significantly affecting the person in a way they consider adversely impacts health, safety or fundamental rights. It gives the right to obtain **clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision**. | | GDPR Art. 22 | AI Act Art. 86 | |---|---|---| | Applies to | Solely automated decisions | Decisions on the basis of a high-risk Annex III system's output | | Human in the loop | Takes it outside Art. 22 (if the involvement is meaningful) | Does **not** switch it off | | Gives | Intervention, view, contestation | Explanation | | Nature | A prohibition with exceptions and safeguards | A right to information | The key operational difference: inserting a meaningful human decision-maker removes a decision from Art. 22, and does **not** remove it from Art. 86 or from Art. 26(11), both of which cover systems that *assist* in decisions. **Build one response procedure** that satisfies the stricter of the two on each element, with a single intake, a named owner and a clock. Two procedures produce inconsistent answers to the same person. ## Lawful basis, and the AI Act's silence The AI Act says nothing about lawful basis. It does not create one, and complying with it does not make processing lawful. Three areas where this bites: **Training data.** Assembling a training set from personal data needs a GDPR basis. The AI Act's Art. 10 governance requirements assume the data is lawfully held; they do not make it so. **Bias testing.** Art. 10(5) permits providers to process **special categories** of personal data exceptionally, to the extent strictly necessary for bias detection and correction, subject to conditions — necessity, technical re-use limits, pseudonymisation and state-of-the-art security, documented access control, no transfer to third parties, deletion once corrected. This is one of the few places the AI Act speaks directly into GDPR territory, and it is narrow. It applies to providers, for bias detection and correction, and nothing else. The Digital Omnibus adjusted its framing in July 2026, so positions written earlier need re-checking. **Logs.** Art. 26(6) requires deployers to keep automatically generated logs for at least six months. Those logs frequently contain personal data. The AI Act creates the retention requirement; the GDPR governs the processing, and "the AI Act made me" is a legal obligation basis for the retention itself but not a licence to use the logs for anything else. ## Where the regimes genuinely pull apart **Minimisation versus evidence.** The GDPR pushes toward collecting less and deleting sooner. The AI Act pushes toward retaining logs, evidencing representativeness, and holding files for ten years. Both are right within their own frame, and the resolution is purpose limitation: retain what the AI Act requires, for the purpose it requires it, and do not repurpose it. **Explainability versus trade secrets.** Art. 86 requires clear and meaningful explanation of the role of the system. Art. 53(1)(b) and Annex XII expressly protect IP and trade secrets on the model side. The reconciliation is that Art. 86 asks about the **role of the system in the decision procedure and the main elements of the decision**, not about model internals. **Automated decision prohibition versus mandated human oversight.** These actually align: Art. 14's oversight requirements and Art. 22's human intervention safeguard push the same way. The trap is assuming that satisfying Art. 14 satisfies Art. 22 — Art. 14 is about the system permitting oversight, Art. 22 is about the individual's right to obtain human intervention on their case. ## The joint file Practically, hold one evidence base and two conclusions: - Shared: the system description, the intended purpose, the categories of persons affected, the data used, the accuracy and limitation figures from Art. 13, the oversight arrangements. - GDPR-side: lawful basis, necessity and proportionality, data subject rights procedures, retention, the record of processing entry, transfers. - AI Act-side: classification determination, Art. 26 artefacts, Art. 50 notices, FRIA determination — including the negative — and the literacy register. ## Check yourself 1. *We did a DPIA, so the FRIA is covered.* — **Different questions.** And most private organisations do not owe a FRIA at all; record why. 2. *A human approves each decision, so Art. 86 does not apply.* — **Art. 86 and Art. 26(11) cover systems that assist in decisions.** Human involvement may take you outside GDPR Art. 22; it does not take you outside these. 3. *We rely on Art. 10(5) to keep a demographic-labelled dataset for future fairness work.* — **The permission is strictly for bias detection and correction, with deletion once corrected.** It is not a general licence. 4. *Complying with the AI Act makes our training data lawful.* — **The AI Act creates no lawful basis.** Art. 10 assumes lawful holding; it does not confer it. --- **Previous:** [Module 4 — Governance gates](/en/academy/ai-act-compliance/module-4/) **Next:** [Module 6 — Incidents, complaints, whistleblowing →](/en/academy/ai-act-compliance/module-6/) -------------------------------------------------------------------------------- ## Module 6 — Incidents, Complaints and Whistleblowing URL: https://www.regulation-ai.eu/en/academy/ai-act-compliance/module-6/ Compliance programmes are usually built around obligations flowing outward. This module is about the routes flowing in: how a problem reaches a regulator, and what has to happen inside the organisation when it does. ## Two internal triggers **Art. 26(5) — the deployer's suspension duty.** Where a deployer has reason to consider that use of a high-risk system in accordance with the instructions may present a risk within the meaning of Art. 79(1), it shall without undue delay inform the provider or distributor and the relevant market surveillance authority, and suspend use. Three features worth naming for a compliance officer: - The threshold is **"reason to consider ... may present a risk"** — not confirmation, not proof. - **Suspension is not optional**, and operationally comes first. - The trigger is risk from use **in accordance with** the instructions. Risk from use outside them is an Art. 26(1) failure and probably an Art. 25 problem. **Art. 20 — the provider's corrective action duty.** A provider that considers, or has reason to consider, that a system it placed on the market is not in conformity must immediately take corrective action — bring it into conformity, withdraw, disable or recall — and inform distributors and, where applicable, deployers, the authorised representative and importers. Where the system presents a risk, it must immediately investigate and inform the market surveillance authorities and, where applicable, the notified body. Both thresholds are low, and both are the kind of decision that stalls without a named owner and a pre-agreed procedure. That is the compliance function's contribution: not making the call, but ensuring the call can be made at 2 a.m. by someone who knows they are allowed to. ## Art. 73 — serious incident reporting The duty sits on the **provider**, reporting to the market surveillance authority of the Member State where the incident occurred. **A serious incident** is defined by consequence: death or serious harm to health; serious and irreversible disruption of the management or operation of critical infrastructure; **infringement of obligations under Union law intended to protect fundamental rights**; or serious harm to property or the environment. That third limb is the one compliance officers should flag internally, because engineering teams read "incident" as "accident". Systematically discriminatory output, with no physical harm at all, can be a serious incident. **Timing.** Immediately after establishing a causal link, or the reasonable likelihood of one, and in any event **not later than 15 days** after becoming aware. Shorter deadlines apply to the gravest categories — widespread infringement, serious and irreversible disruption of critical infrastructure, and death. Where the causal link is not yet established, the initial report is still made within the deadline. **After reporting**, the provider performs the necessary investigations including a risk assessment and corrective action, cooperates with the authorities and, where relevant, the notified body — and must **not alter the system in a way that may affect subsequent evaluation of the causes before informing the authorities**. That constraint runs against every engineering instinct, and it belongs in the incident runbook rather than in a policy nobody reads at the time. **The handover.** If you deploy, your Art. 26(5) notification is what starts the provider's Art. 73 clock. If you provide, you cannot report what your deployers have not told you. Contractual notification commitments with stated timeframes are what make the two duties connect, and they belong in the procurement gate. ## Art. 85 — the right to lodge a complaint Any natural or legal person having grounds to consider that there has been an infringement of the Regulation may **submit a complaint to the relevant market surveillance authority**, which handles it in accordance with its dedicated procedures. Three consequences for a programme. **Expect the route to be used.** It is low-friction, it requires no standing beyond grounds to consider, and it is available to competitors as well as to affected individuals. **Your internal complaint channel is not a substitute**, but it is a mitigation: a person whose concern is answered well internally is less likely to escalate, and an organisation that can show it answered is in a better position when they do. **Keep the log.** Complaints received, when, about what, what you concluded, what changed. It is one of the few artefacts that demonstrates a programme responding rather than merely existing. ## Art. 87 — reporting of infringements and protection of reporting persons **Directive (EU) 2019/1937 applies** to the reporting of infringements of the AI Act and to the protection of persons reporting them. For an organisation already within the scope of the whistleblower directive, this is largely a scoping question rather than a new build: the internal reporting channel, the acknowledgement and feedback timeframes, the confidentiality requirements and the prohibition on retaliation extend to AI Act matters. Two practical points. **Tell people it applies.** A channel nobody knows covers AI concerns will not receive them, and concerns that do not surface internally surface elsewhere. **Retaliation is the risk that materialises.** The commonest failure is not the absence of a channel but a reporting person experiencing consequences — reassignment, exclusion from a project, a poor review — that are hard to distinguish from ordinary management decisions. That is a people-process control, not a compliance document. ## Market surveillance powers, briefly AI systems are supervised by the **national market surveillance authority** designated by each Member State, operating within the Union market surveillance framework. Its powers include requesting information and documentation, and in defined circumstances access to source code, subject to safeguards. Where a system presents a risk, the authority may require corrective action, restrict or prohibit making it available, or require withdrawal or recall. **GPAI models** are supervised centrally by the Commission through the AI Office, with the power to request documentation and information, to conduct evaluations of models, to require measures, and to impose fines under Art. 101. What that means practically: the organisation should know **which authority** supervises it for which systems, and **who** is authorised to respond. An information request answered inconsistently by two teams is a worse start than a slow answer from one. ## The runbook One document, per organisation, covering: 1. **Detection** — from monitoring, from a user, from a complaint, from a whistleblower report. 2. **Triage** — is this an Art. 26(5) risk, an Art. 20 non-conformity, an Art. 73 serious incident, a GDPR personal data breach, or several at once. 3. **Suspension** — who can pull the switch, what happens to work in flight, what the fallback is. 4. **Notification** — templates, recipients, clocks, and the prohibition on altering the system first. 5. **Investigation** — with a note that the AI Act clock does not pause for it. 6. **Record** — what happened, what was decided, what changed. Tested at least once. A runbook that has never been executed is a document. ## Check yourself 1. *Nobody was hurt, so it is not a serious incident.* — **Infringement of Union law obligations intended to protect fundamental rights is one of the limbs.** Discriminatory output can qualify. 2. *We fixed the defect, then notified.* — **Art. 73 prohibits altering the system in a way that may affect subsequent evaluation of the causes before informing the authorities.** 3. *A competitor cannot complain about our AI system.* — **Art. 85 gives any natural or legal person with grounds to consider an infringement the right to complain.** 4. *Our whistleblowing channel is for financial matters.* — **Art. 87 applies Directive (EU) 2019/1937 to AI Act infringements.** Say so, or the reports will go elsewhere. --- **Previous:** [Module 5 — AI Act and GDPR together](/en/academy/ai-act-compliance/module-5/) **Next:** [Module 7 — The audit file and the board conversation →](/en/academy/ai-act-compliance/module-7/) -------------------------------------------------------------------------------- ## Module 7 — The Audit File and the Board Conversation URL: https://www.regulation-ai.eu/en/academy/ai-act-compliance/module-7/ 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](/en/academy/ai-act-compliance/module-6/) You have completed the seven modules. Together they cover running the programme rather than performing any single obligation within it — [sit the Compliance examination →](/en/academy/ai-act-compliance/exam/) -------------------------------------------------------------------------------- ## AI Act Deployer Certification Examination URL: https://www.regulation-ai.eu/en/academy/ai-act-deployer/exam/ Twenty questions on the obligations that attach to an organisation **using** an AI system: Art. 26 paragraph by paragraph, human oversight, logs and incidents, the Art. 25 triggers, the transparency duties you owe directly, and the evidence file. The paper is drawn from a bank of over a hundred and stratified across all seven modules, so every candidate is examined on the whole syllabus. It is graded on our server; the answer key never reaches your browser. **Twenty questions · 70% to pass · every answer returned with its reasoning and its article.** The questions are scenario-based, and the intuitive answer is frequently wrong — which is the point. Knowing that Annex III point 5(b) covers credit scoring is worth little without knowing that it carves out fraud detection; knowing that Art. 27 exists is worth little without knowing that it almost certainly does not apply to you. ## Before you start This examination is part of the [AI Act Deployer track](/en/academy/ai-act-deployer/). The seven modules are free to read. The examination and the certificate are the paid part, and the address you sit under must be the address the track was bought for. If you have not bought the track, start with the [free AI Act Fundamentals examination](/en/academy/exam/) — same engine, same certificate machinery, no charge. ## What the certificate is A private certificate issued by Regulation AI, carrying a public id anyone can verify, plus an Open Badge you can attach to a LinkedIn profile. It is not an official EU credential; no such thing exists for individuals, because the Regulation's conformity assessment applies to AI systems rather than to people. That is printed on the certificate itself. -------------------------------------------------------------------------------- ## AI Act Deployer Certification — For Organisations That Buy AI, Not Build It URL: https://www.regulation-ai.eu/en/academy/ai-act-deployer/ Almost every organisation in scope of the AI Act is a deployer and nothing else. It buys AI, licenses it, embeds it, and puts it to work. It does not train models, does not place systems on the market, and will never affix a CE marking to anything. Almost every piece of published guidance is written for providers. That gap is what this track closes. It works through the obligations that actually attach to the organisation using the system, in the order you meet them, with the carve-outs that decide most real cases — and it is honest about the ones you do not owe, because a compliance programme that does work it does not owe is a programme that will run out of budget before it does the work it does. ## The seven modules **[Module 1 — Are you a deployer, and of what?](/en/academy/ai-act-deployer/module-1/)** Art. 3(4), the inventory, and classification read from the buyer's seat rather than the builder's. Where the Art. 6(3) filter helps you and where it cannot. **[Module 2 — Article 26, paragraph by paragraph](/en/academy/ai-act-deployer/module-2/)** The twelve paragraphs turned into an operating procedure, with the evidence each one produces. **[Module 3 — Human oversight that survives a review](/en/academy/ai-act-deployer/module-3/)** Art. 14 as a design duty on the provider, Art. 26(2) as an assignment duty on you, and automation bias as the thing that quietly voids both. **[Module 4 — Logs, monitoring, suspension, incidents](/en/academy/ai-act-deployer/module-4/)** Art. 12 logging, the six-month retention floor in Art. 26(6), when to stop using a system, and what cooperation under Art. 73 actually asks of you. **[Module 5 — The Article 25 trap](/en/academy/ai-act-deployer/module-5/)** Three triggers, each of which turns a deployer into a provider. How to recognise them before procurement rather than after an audit. **[Module 6 — Transparency you owe directly](/en/academy/ai-act-deployer/module-6/)** Art. 50(3) and 50(4) are deployer duties, in force now. Plus Art. 26(11) information to affected persons and the Art. 86 right to explanation. **[Module 7 — The evidence file](/en/academy/ai-act-deployer/module-7/)** What a supervisor asks for, in what order: the classification record, the FRIA determination, the Art. 4 literacy register, and the vendor file that Art. 13 should have given you. ## What the examination asks Twenty questions drawn from a bank, stratified so every module is covered, graded on our server. The pass mark is 70%. The questions are scenario-based and the intuitive answer is frequently wrong — because in this Regulation it frequently is. A certificate carries a public id anyone can verify, and an Open Badge you can attach to a LinkedIn profile. ## Before you start This track assumes the [free Fundamentals course](/en/academy/ai-act-fundamentals/) — scope, the four tiers, the roles, the timetable. If you cannot yet say whether a given system is Annex III without looking it up, start there. -------------------------------------------------------------------------------- ## Module 1 — Are You a Deployer, and of What? URL: https://www.regulation-ai.eu/en/academy/ai-act-deployer/module-1/ You cannot comply with obligations you have not identified, and you cannot identify them until you know which hat you are wearing for which system. This module is the sorting step. It is unglamorous and it is where most programmes go wrong, because they start from a list of vendors rather than a list of systems. ## What makes you a deployer Art. 3(4) is short: a deployer is a natural or legal person using an AI system **under its own authority**, except where the use is a purely personal, non-professional activity. Two things follow that people miss. **"Under its own authority" is about control, not ownership.** You do not need to own the system, host it, or have paid for it. A team using a free browser extension that summarises customer emails is deploying an AI system under the organisation's authority. So is a department that signed up to a SaaS trial without telling procurement. **The personal carve-out never applies to an organisation.** It exists for an individual using AI in their private life. An employer, a public body, a charity, a sole trader acting professionally — all are deployers. ## You are probably also a provider of something Art. 3(3) defines the provider as whoever 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*. Read that last clause again. Putting a system into service for your own use makes you its provider. So an internal model built by your own data science team, never sold to anyone, has a provider: you. And because you also use it under your own authority, you are its deployer as well. This is not a technicality. It decides whether the technical documentation of Annex IV is someone else's problem or yours. | What you did | Provider? | Deployer? | |---|---|---| | Licensed a vendor system, used as sold | No | Yes | | Licensed it, put your own brand on it | **Yes** (Art. 25) | Yes | | Built it in-house for internal use | **Yes** | Yes | | Built it and sold it to others | Yes | Only if you also use it | | Resold a vendor system unchanged, under the vendor's brand | No — distributor (Art. 24) | No | ## The inventory comes before the classification The instinct is to start with the regulation and look for systems that match. Do the opposite. List what is actually running, then classify. A workable inventory row records: the system, the business process it serves, who inside the organisation is accountable for it, the vendor and contract, whether outputs affect natural persons and how, whether personal data is processed, and — the field everyone forgets — **the intended purpose as the vendor declares it**, quoted from the instructions for use. That last field is what lets you answer the Art. 25 question later, and it is the field you will not be able to fill in retrospectively without going back to the vendor. Expect the inventory to surface systems nobody had listed: a recruitment screening add-on inside the ATS, a scoring feature switched on in a CRM, a transcription tool a team adopted on a company card. These are the ones that carry obligations, precisely because nobody assessed them. ## Classification from the buyer's seat The four tiers are the same whichever seat you sit in — that is [Fundamentals](/en/academy/ai-act-fundamentals/module-2/). What changes is the order in which you should apply them, because a deployer's exposure is not evenly distributed. **First, Art. 5.** A prohibited practice is not a compliance project, it is a stop. And two prohibitions catch ordinary corporate deployments far more often than people expect: inferring emotions in the workplace under Art. 5(1)(f), and untargeted scraping of facial images to build recognition databases. The Art. 5 band under Art. 99(3) is 35 million euro or 7% of worldwide turnover — the highest in the Regulation, and it applies to deployers, not only to providers. **Second, Art. 50.** These duties are in force now, since 2 August 2026. They apply whatever the risk tier, and two of the four sit directly on the deployer. Most organisations owe something here today and owe nothing under Chapter III until December 2027. **Third, Annex III.** Now check the high-risk list, and check the carve-outs before the categories: - Point 1 covers remote biometric identification, but **1:1 verification against a document is excluded** — the KYC selfie check is not caught. - Point 5(b) covers creditworthiness and credit scoring, but **AI used to detect financial fraud is excluded**. - Point 3 covers education and vocational training, including evaluating learning outcomes and monitoring prohibited behaviour during tests. - Point 4 covers employment: recruitment, targeted job advertising, filtering applications, evaluating candidates, promotion and termination decisions, task allocation, and monitoring worker behaviour. **Fourth, everything else is minimal risk**, and minimal risk means no mandatory obligation under this Regulation. It does not mean no obligation at all — the GDPR, sectoral law and your own contracts do not go away. ## Where Art. 6(3) helps you, and where it cannot Art. 6(3) lets an Annex III system be treated as not high-risk when it does not pose a significant risk of harm and meets one of four conditions: it performs a narrow procedural task; it improves the result of a previously completed human activity; it detects decision patterns without replacing or influencing human assessment; or it performs a preparatory task. Two limits matter to a deployer. **The filter is the provider's to invoke.** Art. 6(4) requires the provider claiming it to document the assessment before placing the system on the market and to register the system under Art. 49(2). If your vendor has relied on the derogation, that documentation exists and you should have a copy of it. If the vendor cannot produce it, the derogation has not actually been claimed. **Profiling voids it absolutely.** Art. 6(3) states that a system is always high-risk where it performs profiling of natural persons. No condition survives that. If the system builds or applies a profile of a person to evaluate them, stop looking for a derogation. ## Getting the determination on paper For each system, write down: the tier you concluded, the Annex III point you checked and why it does or does not apply, the carve-out you relied on if any, who decided, and on what date against which text. That last element is doing more work than it looks. The Digital Omnibus rewrote Article 4 and moved the Chapter III dates in July 2026. A determination that does not say which version of the law it was made against cannot be reviewed — it can only be redone. ## Check yourself 1. *We only use AI internally, on our own staff. Are we in scope?* — **Yes.** There is no internal-use exemption, and Annex III point 4 covers worker management specifically. 2. *Our data science team built a scoring model we never sold. Who is the provider?* — **You are.** Art. 3(3) covers development for own use; you are simultaneously the deployer. 3. *Our KYC flow matches a selfie to a passport photo. Annex III point 1?* — **No.** One-to-one verification against a document is excluded from the remote biometric identification category. 4. *The vendor says Art. 6(3) applies, so the system is not high-risk.* — **Ask for the Art. 6(4) documentation and the Art. 49(2) registration.** If neither exists, the derogation has not been claimed, and if the system profiles natural persons it was never available. --- **Next:** [Module 2 — Article 26, paragraph by paragraph →](/en/academy/ai-act-deployer/module-2/) -------------------------------------------------------------------------------- ## Module 2 — Article 26, Paragraph by Paragraph URL: https://www.regulation-ai.eu/en/academy/ai-act-deployer/module-2/ Article 26 is the deployer's article. Twelve paragraphs, and almost none of them are policy statements — they are things you do, on a schedule, that leave a trace. This module walks them in order and names the artefact each one produces, because an obligation that produces no artefact cannot be demonstrated. A note on timing before we start. These obligations attach to high-risk systems, and the Chapter III regime for standalone Annex III systems applies from **2 December 2027** following the Digital Omnibus, and from **2 August 2028** for AI embedded in Annex I regulated products. That is not a reason to wait: the artefacts below take longer to build than the time remaining, and the Art. 4 literacy duty and the Art. 50 transparency duties already apply. ## 26(1) — Use it as the instructions say *Deployers shall take appropriate technical and organisational measures to ensure they use high-risk AI systems in accordance with the instructions for use.* This is the hinge of the whole article. Everything downstream assumes it. Two consequences. First, you need the instructions — Art. 13 obliges the provider to supply them, and a vendor who will not is selling you something you cannot lawfully deploy. Second, departing from the declared intended purpose is one of the three Art. 25 triggers that make you the provider. Module 5 is about that. **Artefact:** the instructions for use, filed against the system, plus a written statement of how you are actually using it and a confirmation that the two match. ## 26(2) — Oversight by competent, trained people *Deployers shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support.* Four requirements, and organisations routinely satisfy two of them. Competence and training are usually addressed. **Authority** and **support** are usually not. Authority means the overseer can act on what they see. An overseer who reviews every automated rejection but cannot overturn one has no authority, and the paragraph is not satisfied however diligent they are. Support means time, tooling and staffing: one person nominally overseeing 4,000 decisions a day is not being supported. Note also that this paragraph is where Art. 4 AI literacy meets an enforceable duty. Art. 4 itself carries no fine band under Art. 99 — it appears in none of its paragraphs. Art. 26(2) does, through Art. 99(4). **Artefact:** named individuals per system, their training record, a written delegation of authority stating what they may do, and evidence of the resourcing. ## 26(3) — Input data under your control *Where the deployer exercises control over input data, it shall ensure that data is relevant and sufficiently representative in view of the intended purpose.* The qualifier does real work. You owe this only for input data you control. A vendor's training data is not yours; the customer records you feed the system are. **Artefact:** a description of the input feed, its provenance, and a periodic check that it still matches the population the system was built for. This is also where model drift becomes visible. ## 26(4) — Monitor operation *Deployers shall monitor the operation of the high-risk AI system on the basis of the instructions for use.* Monitoring against the instructions, not against your own assumptions. If the instructions state accuracy metrics and operating conditions, those are what you monitor against. **Artefact:** a monitoring plan naming the indicators, the thresholds, the frequency, and who reads the output. ## 26(5) — Suspend and notify *Where the deployer has reason to consider that use in accordance with the instructions may present a risk within the meaning of Art. 79(1), it shall without undue delay inform the provider or distributor and the relevant market surveillance authority, and suspend use of the system.* The order in the text is inform-and-suspend; the order in practice is suspend first. A system you believe is presenting a risk should not keep running while you draft a notification. Note the trigger: risk arising from use **in accordance with** the instructions. If the risk arises because you were using it outside the instructions, you have an Art. 26(1) problem and probably an Art. 25 problem, not an Art. 26(5) notification. **Artefact:** a suspension procedure that a duty manager can execute at 2 a.m., with the notification templates already written. ## 26(6) — Keep the logs, at least six months *Deployers shall keep the logs automatically generated by the high-risk AI system, to the extent those logs are under their control, for a period appropriate to the intended purpose, of at least six months, unless provided otherwise in applicable Union or national law.* Three qualifiers, all load-bearing: **automatically generated** (Art. 12 logs, not your application logs), **under their control** (a fully hosted SaaS may hold them, which is a contract question), and **at least six months** (a floor that sectoral retention rules frequently exceed). **Artefact:** the retention schedule, the storage location, and the contractual clause that gets you the logs if the vendor holds them. That clause is the one to negotiate at procurement, because you will not get it afterwards. ## 26(7) — Tell the workers first *Before putting into service or using a high-risk AI system at the workplace, deployers who are employers shall inform workers' representatives and the affected workers that they will be subject to its use.* Before, not after. This sits on top of national information and consultation law, and in several Member States the national requirement is heavier. **Artefact:** the dated communication and, where representatives exist, the record of their information. ## 26(8) — Register, if you are a public body Deployers that are public authorities or Union institutions must register in the EU database under Art. 49. Private deployers generally do not register; their providers do. ## 26(9) — Use the information for the DPIA Where a data protection impact assessment is required under the GDPR, the deployer uses the information supplied under Art. 13 to fulfil it. The AI Act does not replace the DPIA, and the DPIA does not discharge the AI Act. They are two documents answering two questions, sharing one evidence base. ## 26(10) — Law enforcement authorisation A narrow paragraph on post-remote biometric identification in criminal investigations, requiring prior judicial or administrative authorisation. It concerns law enforcement deployers; commercial organisations can note its existence and move on. ## 26(11) — Tell the person *Deployers of high-risk AI systems referred to in Annex III that make decisions or assist in making decisions related to natural persons shall inform the natural persons that they are subject to the use of the high-risk AI system.* Note "or assist in making". A human-in-the-loop arrangement does not remove this duty. And note that this is distinct from the Art. 50 transparency duties, which apply regardless of tier — Module 6 separates them. **Artefact:** the notice, where it appears in the journey, and evidence it was shown. ## 26(12) — Cooperate Deployers cooperate with the competent authorities on any action concerning the system. In practice this means being able to produce everything above within a reasonable period, which is an argument for keeping it in one file rather than across four teams. ## The shape of the file Read as a set, the twelve paragraphs produce a single deployer file per system: instructions for use, the classification determination, named overseers and their authority, the input data description, the monitoring plan, the suspension procedure, the log retention arrangement, the worker communication, the affected-person notice, and the DPIA link. That file is what a supervisor asks for. Module 7 assembles it. ## Check yourself 1. *Our overseer reviews every rejection but cannot overturn one. Art. 26(2) satisfied?* — **No.** The paragraph requires authority as well as competence and training. 2. *Our SaaS vendor holds the system logs. Are we still on the hook for Art. 26(6)?* — **The duty is limited to logs under your control**, which makes access a contractual question you must settle before signing. 3. *We informed staff the week after go-live.* — **Too late.** Art. 26(7) requires information before putting the system into service. 4. *A human approves each decision, so Art. 26(11) does not apply.* — **It does.** The paragraph covers systems that make decisions *or assist in making* them. --- **Previous:** [Module 1 — Are you a deployer, and of what?](/en/academy/ai-act-deployer/module-1/) **Next:** [Module 3 — Human oversight that survives a review →](/en/academy/ai-act-deployer/module-3/) -------------------------------------------------------------------------------- ## Module 3 — Human Oversight That Survives a Review URL: https://www.regulation-ai.eu/en/academy/ai-act-deployer/module-3/ Human oversight is the obligation most often claimed and least often evidenced. Organisations write "a human reviews all decisions" into a policy and consider the matter closed. A supervisor reading that sentence will ask three questions the policy does not answer: which human, with what authority, and how would you know if they had stopped actually looking. This module is about answering those three. ## Two duties, two parties **Art. 14 binds the provider.** High-risk systems shall be designed and developed, including with appropriate human-machine interface tools, such that they can be effectively overseen by natural persons during the period in which they are in use. **Art. 26(2) binds the deployer.** It must assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support. Neither discharges the other. A perfectly designed system with an untrained, unauthorised overseer fails. A well-trained, empowered overseer using a system that exposes no controls also fails — and that failure is the provider's, which makes it a procurement question for you. ## What Art. 14 actually asks the system to permit Art. 14(4) lists what the oversight person must be enabled to do. Read it as a checklist against any system you are buying: - **Understand the capacities and limitations** of the system and monitor its operation, so that signs of anomalies, dysfunction and unexpected performance can be detected and addressed as soon as possible. - **Remain aware of automation bias** — the tendency to automatically rely on or over-rely on output, particularly for systems used to provide information or recommendations for decisions to be taken by natural persons. - **Correctly interpret the output**, taking into account the interpretation tools and methods available. - **Decide, in any particular situation, not to use the system or otherwise disregard, override or reverse the output.** - **Intervene in the operation or interrupt the system** through a stop button or a similar procedure that allows it to come to a halt in a safe state. The fourth and fifth are the ones to test in a demonstration. Ask the vendor to show you the override. If the answer is that the decision can be changed downstream in another system, the override does not exist in the sense Art. 14 means. ## Why automation bias is named in the text It is unusual for a regulation to name a cognitive failure mode. Art. 14(4)(b) does, because automation bias is the specific mechanism by which oversight becomes theatre while everyone involved believes it is functioning. The conditions that produce it are well understood and entirely ordinary: high volume, time pressure, an output presented with apparent confidence and no uncertainty, an interface where agreeing takes one click and disagreeing takes a form, and a working culture where overriding the model requires justification but following it does not. Every one of those is a design and management choice, which is why the Regulation treats awareness of the bias as an oversight requirement rather than a footnote. Practical counter-measures that also produce evidence: - Show uncertainty, not just a verdict. An overseer who can see that the model is at 51% behaves differently from one shown a bare recommendation. - Make override symmetrical. If agreeing is one click, disagreeing should be one click plus a reason — not five screens. - **Measure the override rate.** A rate that is stable and non-zero is the single best evidence that oversight is live. A rate of zero over months means either a perfect model or an inert overseer, and it is never the first. - Rotate and sample. Overseers reviewing a random sample with feedback stay calibrated; overseers reviewing everything stop reading. ## Art. 14(5) — the four-eyes rule for biometrics For the remote biometric identification systems in Annex III point 1, Art. 14(5) adds a specific requirement: no action or decision may be taken on the basis of the identification unless it has been **separately verified and confirmed by at least two natural persons** with the necessary competence, training and authority. There is a carve-out for law enforcement, migration, border control and asylum in certain circumstances, but for commercial deployments the two-person rule stands. If you are deploying remote biometric identification and one person can act on a match, you are not compliant, however good the model is. ## Turning "we have oversight" into evidence The claim is unfalsifiable; the artefacts are not. For each high-risk system, hold: | Artefact | What it answers | |---|---| | Named overseers, per system, with dates | Which human | | Written delegation of authority | What they may do without asking | | Training record tied to the system, not generic | Whether they were trained on *this* | | The provider's Art. 13 instructions on oversight measures | What the designer expected | | Override rate over time, per overseer | Whether it is live | | Sample of overridden cases with reasons | Whether the overrides are reasoned | | Resourcing evidence — headcount against volume | Whether support exists | | A stop procedure that has been tested | Whether Art. 14(4)(e) is real | The last one is worth doing literally. A stop procedure nobody has ever executed is a document, not a control. ## The relationship with Art. 4 Art. 4, as rewritten by the Digital Omnibus in July 2026, requires providers and deployers to take measures supporting the AI literacy of staff who operate AI systems on their behalf. It does not require you to guarantee a level for any individual, and it carries no fine band of its own. Art. 26(2) does carry one, through Art. 99(4). So the practical position is this: your general AI literacy programme answers Art. 4, and the specific, system-tied training of your named overseers answers Art. 26(2). The second is narrower, deeper and enforceable. Do not let the first stand in for it. ## Check yourself 1. *Our reviewer sees every case and approves nearly all of them.* — **Look at the override rate.** A rate at or near zero over a long period is evidence of automation bias, not of a good model. 2. *The vendor says the decision can be reversed later in our case management system.* — **That is not the Art. 14(4)(d) override.** The oversight person must be able to disregard or reverse the output of the system itself. 3. *We deploy face matching against a watchlist and one trained officer acts on matches.* — **Art. 14(5) requires two.** Separate verification by two competent, trained and authorised persons before any action. 4. *We run an annual AI awareness course, so Art. 26(2) is covered.* — **No.** Art. 26(2) requires competence, training, authority and support tied to the specific system; a general course answers Art. 4, which carries no fine of its own. --- **Previous:** [Module 2 — Article 26, paragraph by paragraph](/en/academy/ai-act-deployer/module-2/) **Next:** [Module 4 — Logs, monitoring, suspension, incidents →](/en/academy/ai-act-deployer/module-4/) -------------------------------------------------------------------------------- ## Module 4 — Logs, Monitoring, Suspension and Incidents URL: https://www.regulation-ai.eu/en/academy/ai-act-deployer/module-4/ This module is about the machinery that makes everything else provable: what the system records, what you watch, when you stop, and who has to be told. ## Art. 12 — what the system records, and why it is not your application log Art. 12 obliges providers to design high-risk systems so that events are **automatically recorded** over the lifetime of the system, at a level appropriate to the intended purpose. For the remote biometric identification systems in Annex III point 1, Art. 12 specifies a minimum: the period of each use, the reference database against which input data was checked, the input data for which the search led to a match, and the identification of the natural persons involved in verifying the results. Two things follow for a deployer. **These are not your application logs.** Your access logs, your API gateway logs and your audit trail are yours and may be excellent, but they are not the Art. 12 record. The Art. 12 record is generated by the system itself and describes its operation. **If the system does not generate them, that is a provider defect.** You cannot retrofit Art. 12 logging into a system that does not have it, and a vendor whose system produces nothing you can retain has sold you something you cannot deploy compliantly. Ask to see a sample log export during evaluation, not after. ## Art. 26(6) — six months is a floor *Deployers shall keep the logs automatically generated by the high-risk AI system, to the extent those logs are under their control, for a period appropriate to the intended purpose of the system, of at least six months, unless provided otherwise in applicable Union or national law.* Every clause is doing work: - **automatically generated** — the Art. 12 record, per above. - **under their control** — the contractual question. Settle it at procurement. - **appropriate to the intended purpose** — six months may be plainly inadequate for a system whose harms surface over years. The Regulation sets a minimum and expects you to think. - **at least six months** — a floor. - **unless provided otherwise** — and sectoral law very often provides otherwise, almost always upward. A financial entity does not get to keep decision records for six months because the AI Act says six months. The failure mode here is a retention policy written by whoever read the AI Act, overriding a longer sectoral requirement written by whoever read the sectoral law. Reconcile them explicitly and record the reconciliation. ## Art. 26(4) — monitoring against the instructions Monitoring is owed **on the basis of the instructions for use**. That phrase decides what you monitor. If the provider's instructions state operating conditions — an input distribution, a population, a language, a volume envelope, an accuracy figure under stated conditions — those are the reference points. Monitoring against your own comfortable internal metrics while the system runs outside its declared envelope satisfies nothing. A workable monitoring plan names, per system: the indicators, drawn from the instructions; the thresholds and who set them; the frequency; the person who reads the output; and the escalation path when a threshold is crossed. Without the last two it is a dashboard, not a control. Watch specifically for **input drift** — the population the system now sees diverging from the one it was built for. This is where Art. 26(3), on input data you control, and Art. 26(4) meet, and it is the most common way a compliant deployment becomes a non-compliant one without anybody changing anything. ## Art. 26(5) — the decision to stop *Where the deployer has reason to consider that use in accordance with the instructions may present a risk within the meaning of Art. 79(1), it shall without undue delay inform the provider or distributor and the relevant market surveillance authority, and suspend the use of the system.* Three observations. **The threshold is "reason to consider ... may present a risk".** It is not certainty, not proof, not a completed investigation. If you are waiting for confirmation before acting, you have set the bar higher than the Regulation does. **Suspension is not optional and not sequenced last.** The text lists informing and suspending together; operationally, suspend first. **The trigger is risk from use in accordance with the instructions.** If the risk arose because you were using the system outside its declared purpose, this is not the paragraph you are in — you are in Art. 26(1), and quite possibly Art. 25. The artefact is a suspension procedure a duty manager can execute without convening a committee: who can pull the switch, what happens to work in flight, what the fallback process is, and which templates are pre-written. Test it. A procedure that has never been executed is a document. ## Art. 73 — serious incidents, and how they reach you The reporting obligation in Art. 73 sits on the **provider**, which must report serious incidents to the market surveillance authority of the Member State where the incident occurred, immediately upon becoming aware and in any case **within 15 days**. Shorter deadlines apply for the gravest categories — where there is a risk to life and safety, or a widespread infringement — and the Regulation expects notification without undue delay in those cases even where the investigation is incomplete. The deployer's position is straightforward and easy to get wrong: **you are usually the only party that can see the incident, and the provider cannot report what it has not been told.** Your Art. 26(5) notification is what starts the provider's Art. 73 clock. A deployer who investigates internally for three weeks before telling the vendor has not breached Art. 73 — it does not bind them — but has made it impossible for the provider to comply, which is a contractual and a reputational problem, and evidence of a poor programme in any supervisory conversation. Build the two paths as one procedure: detect, suspend, notify the provider, notify the market surveillance authority, record. The AI Act notification also sits alongside, and does not replace, a GDPR personal data breach notification where one is triggered — different regimes, different clocks, different recipients. ## Art. 26(12) — cooperation, in practice Cooperation with competent authorities means being able to produce, within a reasonable period: the classification determination, the instructions for use, the oversight assignment, the monitoring output, the logs, and the incident record. If those live in six systems owned by four teams, cooperation is a project. If they live in one file per system, it is a morning. ## Check yourself 1. *Our SIEM captures everything the AI system does. Does that satisfy Art. 26(6)?* — **Not by itself.** The retained record must be the logs the system generates automatically under Art. 12; your own telemetry is not a substitute. 2. *Sectoral rules require seven years' retention. Can we keep six months?* — **No.** Art. 26(6) sets a floor and expressly defers to other Union or national law providing otherwise. 3. *We suspect a problem but have not confirmed it.* — **The Art. 26(5) threshold is "reason to consider ... may present a risk".** Suspend and notify; confirm afterwards. 4. *Do we report the serious incident to the authority under Art. 73?* — **The Art. 73 duty is the provider's.** Yours is to suspend and inform the provider and the market surveillance authority under Art. 26(5) — which is what makes the provider's report possible. --- **Previous:** [Module 3 — Human oversight that survives a review](/en/academy/ai-act-deployer/module-3/) **Next:** [Module 5 — The Article 25 trap →](/en/academy/ai-act-deployer/module-5/) -------------------------------------------------------------------------------- ## Module 5 — The Article 25 Trap: When a Deployer Becomes a Provider URL: https://www.regulation-ai.eu/en/academy/ai-act-deployer/module-5/ This is the module that changes procurement behaviour, because the consequence is disproportionate to the act that triggers it. Adding your logo to a screen is a marketing decision made in an afternoon. If the system behind that screen is high-risk, it can move the entire Chapter III obligation set onto your balance sheet. ## The three triggers Art. 25(1) provides that a distributor, importer, deployer or other third party **shall be considered a provider** of a high-risk AI system, and shall be subject to the provider's obligations under Art. 16, in any of these circumstances: **(a) You put your name or trademark on it.** The system has already been placed on the market or put into service, and you affix your own name or trademark to it. There is a carve-out for contractual arrangements allocating obligations otherwise, but do not build a programme on it: the allocation has to be real, agreed, and it does not bind a supervisory authority's view of who is presenting the product to the market. **(b) You make a substantial modification to it.** The system remains high-risk after the change. "Substantial modification" is defined in Art. 3 — a change not foreseen or planned in the provider's initial conformity assessment which affects compliance with the Chapter III requirements, or which results in a modification to the intended purpose. **(c) You change the intended purpose so that it becomes high-risk.** This one explicitly includes taking a general-purpose AI system that the provider did not classify as high-risk and putting it to a high-risk use. ## Why (c) is the one that catches people now Triggers (a) and (b) are legible: someone decides to rebrand, someone decides to retrain. Trigger (c) fires through ordinary product evolution, usually without a decision that anybody would have escalated. The pattern is always the same. An organisation licenses a general-purpose assistant for drafting and summarisation — plainly not high-risk. A team then points it at CV screening, or at drafting adverse decision letters for benefit claims, or at ranking employees for redundancy selection. Nobody rebranded anything and nobody retrained anything. But the intended purpose, as *you* now intend it, is an Annex III point 4 use, and under Art. 25(1)(c) you are the provider of a high-risk AI system. The vendor's terms of service almost certainly say the product is not for such uses. That protects the vendor. It does not protect you — if anything it strengthens the case that the purpose change was yours. ## What actually lands on you Becoming the provider is not an administrative reclassification. Art. 16 brings the whole of Chapter III: | Obligation | Article | |---|---| | Risk management system across the lifecycle | Art. 9 | | Data governance for training, validation and testing data | Art. 10 | | Technical documentation to Annex IV | Art. 11 | | Automatic logging by design | Art. 12 | | Instructions for use for downstream deployers | Art. 13 | | Human oversight by design | Art. 14 | | Accuracy, robustness and cybersecurity | Art. 15 | | Quality management system | Art. 17 | | Conformity assessment | Art. 43 | | EU declaration of conformity | Art. 47 | | CE marking | Art. 48 | | Registration in the EU database | Art. 49 | | Post-market monitoring | Art. 72 | | Serious incident reporting | Art. 73 | Consider what Art. 10 alone means for an organisation that did not train the model: you owe data governance for training data you have never seen and cannot obtain. That is why the cooperation duty matters. ## The cooperation duty, and how to make it usable Art. 25(2) requires the original provider, once someone else has become the provider, to **cooperate closely** and make available the information and technical access reasonably needed to fulfil the obligations — unless it has clearly specified that its system is not to be changed into a high-risk one. Two practical readings. First: that final clause is why vendor terms increasingly contain an explicit statement that the product must not be put to high-risk use. It is not boilerplate; it is the vendor discharging its cooperation duty in advance. Second: relying on a statutory cooperation duty to obtain training data documentation from a supplier who does not want to give it to you is not a plan. Put it in the contract, with a definition of the deliverables and a remedy. ## Catching it before it fires The controls are procurement controls, not compliance controls, and they cost almost nothing if they exist before the contract. **Record the declared intended purpose at onboarding**, quoted from the instructions for use, in the inventory field Module 1 asked you to create. Every later question about Art. 25(c) is answered by comparing current use against that quotation. **Gate purpose changes.** Any new use case for an existing system goes through the same classification step as a new system. This is one form and five minutes; without it, purpose creep is invisible by construction. **Gate branding.** A rule that the vendor's identity remains visible on any AI-driven output, unless legal has cleared removal, prevents trigger (a) at zero cost. **Gate modification.** Fine-tuning, retraining on your data, and changes to decision thresholds all need a check against the definition of substantial modification. Note that the general-purpose model track has its own version of this question — fine-tuning can make you a provider of a *model* under Chapter V, which is a different regime from being the provider of a *system*. **Write the cooperation clause.** Access to Annex IV documentation, training data descriptions, evaluation results, and log exports, with a service level. The moment to obtain this is before signature. ## A worked example A regional insurer licenses a document-understanding platform. Not high-risk: it reads PDFs and extracts fields. A claims team configures it to score claims for likely fraud. Fraud detection is expressly carved out of Annex III point 5(b), so this remains outside high-risk. Good. Eighteen months later, a pricing team reuses the same configured pipeline to inform risk assessment and pricing for health insurance policies. That is Annex III point 5(c). The intended purpose has changed and the system is now high-risk. Under Art. 25(1)(c) the insurer is its provider — and, being an insurer deploying a 5(c) system, is also one of the narrow set of deployers that owes a fundamental rights impact assessment under Art. 27. No one rebranded anything. No one retrained anything. Two teams reused a pipeline, which is exactly what good engineering practice encourages. ## Check yourself 1. *We put our brand on a licensed high-risk system, but our contract says the vendor stays the provider.* — **Art. 25(1)(a) has a carve-out for contractual arrangements, but treat it as fragile.** The allocation must be real, and it does not change who the market sees presenting the product. 2. *We fine-tuned a vendor's high-risk system on our own data.* — **Check the definition of substantial modification.** If the change was not foreseen in the provider's conformity assessment and affects Chapter III compliance, Art. 25(1)(b) fires. 3. *We pointed a general-purpose assistant at CV screening.* — **Art. 25(1)(c).** You have changed the intended purpose into an Annex III point 4 use; you are the provider. 4. *If Art. 25 fires, is the original provider off the hook entirely?* — **It stops being the provider of that system, but owes a cooperation duty** — unless it clearly specified the system was not to be changed into a high-risk one. --- **Previous:** [Module 4 — Logs, monitoring, suspension, incidents](/en/academy/ai-act-deployer/module-4/) **Next:** [Module 6 — Transparency you owe directly →](/en/academy/ai-act-deployer/module-6/) -------------------------------------------------------------------------------- ## Module 6 — Transparency You Owe Directly (and Owe Today) URL: https://www.regulation-ai.eu/en/academy/ai-act-deployer/module-6/ Everything in the previous modules attaches to high-risk systems and mostly bites from December 2027. This module is different: most of it is in force now, and most of it applies whatever tier your system sits in. If your organisation has an AI Act obligation today, it is probably in here. ## The four Art. 50 duties, and who owes each | Paragraph | Duty | Owed by | |---|---|---| | 50(1) | Tell people they are interacting with an AI system | **Provider** | | 50(2) | Mark synthetic output in a machine-readable format | **Provider** | | 50(3) | Inform people exposed to emotion recognition or biometric categorisation | **Deployer** | | 50(4) | Disclose deepfakes; disclose AI-generated text published on matters of public interest | **Deployer** | Art. 50 has applied since **2 August 2026**. It was not deferred by the Digital Omnibus. A transitional rule gives providers of generative systems already on the market before that date until **2 December 2026** to apply the machine-readable marking of Art. 50(2). ## 50(3) — emotion recognition and biometric categorisation Deployers of an emotion recognition system or a biometric categorisation system must **inform the natural persons exposed to it** of its operation, and process personal data in accordance with the data protection acquis. Before you plan the notice, check whether the deployment is lawful at all. **Art. 5(1)(f) prohibits AI to infer emotions of a natural person in the areas of workplace and education institutions**, save where the system is intended for medical or safety reasons. That prohibition has applied since 2 February 2025 and sits in the highest fine band — Art. 99(3), 35 million euro or 7% of worldwide turnover. So the sequence is: is this the workplace or an education institution? If yes, and the purpose is not medical or safety, it is prohibited and no notice cures it. If no — a retail analytics deployment, say — Art. 50(3) applies and you owe the information. The same order applies to biometric categorisation: Art. 5 prohibits categorisation systems that categorise natural persons on the basis of biometric data to deduce or infer race, political opinions, trade union membership, religious or philosophical beliefs, sex life or sexual orientation. Outside those categories, Art. 50(3) governs. ## 50(4) — deepfakes and public-interest text Two distinct duties in one paragraph. **Deepfakes.** Deployers of an AI system that generates or manipulates image, audio or video content constituting a deepfake must disclose that the content has been artificially generated or manipulated. There are exceptions: where use is authorised by law to detect, prevent, investigate or prosecute criminal offences, and — the one that matters commercially — where the content forms part of an **evidently artistic, creative, satirical or fictional work**, in which case the disclosure obligation is limited to disclosing the existence of such content in an appropriate manner that does not hamper the display or enjoyment of the work. **Text on matters of public interest.** Deployers of an AI system that generates or manipulates text **published with the purpose of informing the public on matters of public interest** must disclose that the text was artificially generated or manipulated. The exceptions are where the use is authorised by law, or where the AI-generated content **has undergone a process of human review or editorial control and a natural or legal person holds editorial responsibility** for the publication. That editorial-control exception is the one most organisations will rely on, and it is worth reading precisely. It is not enough that a human glanced at the output. There must be a review or editorial control process, and an identified person or entity bearing editorial responsibility for the publication. If you rely on it, document who that is. Note also the boundary of the duty: it concerns text published to inform the public on matters of public interest. Your AI-assisted product descriptions and internal reports are outside it. Your AI-assisted press releases and policy commentary are not obviously outside it. Art. 50(5) adds that the information must be provided at the latest at the time of the first interaction or exposure, clearly and distinguishably, and in a way that conforms to accessibility requirements. ## 26(11) — telling the person they are subject to the system *Deployers of high-risk AI systems referred to in Annex III that make decisions or assist in making decisions related to natural persons shall inform the natural persons that they are subject to the use of the high-risk AI system.* This is separate from Art. 50 and narrower: it attaches to Annex III high-risk deployments, and it fires whether the system decides or merely **assists** in deciding. A human-in-the-loop arrangement does not switch it off — if anything, assisting is the normal case. Where a system is used in the context of Art. 6(1) — AI as a safety component of a regulated product — the paragraph works differently, but for Annex III deployments the rule is straightforward: the person on the other side of the decision is told. ## 86 — the right to explanation Art. 86 gives any affected person subject to a decision taken by the deployer on the basis of the output of a high-risk Annex III system, where that decision produces legal effects or similarly significantly affects them in a way they consider adversely impacts their health, safety or fundamental rights, the right to obtain from the deployer **clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken**. Four points that decide how you implement it. **It is exercised, not published.** Unlike Art. 26(11), this is a right someone asserts. You need a route for the request, an owner, and a response time. **It explains the role of the system, not the model.** The obligation is to explain what part the system played in the procedure and the main elements of the decision. It is not a demand for model internals, feature weights, or the training data. **It is not an annulment right.** Art. 86 gives an explanation. Whether the decision itself can be challenged comes from elsewhere — sectoral law, contract, or Art. 22 of the GDPR where the decision was solely automated. **It interacts with the GDPR but is not the same.** Where the decision was based solely on automated processing with legal or similarly significant effects, GDPR Art. 22 applies with its own safeguards — including a right to obtain human intervention, to express a point of view and to contest the decision. Art. 86 does not replace that. Map both, once, and build one response procedure that satisfies the stricter of the two. ## What this looks like as an artefact Per system: which of the four Art. 50 duties apply and to whom; the wording of each notice and where in the journey it appears; the Art. 5 check that was done before concluding a deployment was lawful; the editorial-responsibility holder if you rely on that exception; the Art. 26(11) notice; and the Art. 86 request procedure with its owner and its clock. Because these duties are already in force, this is also the part of the file a supervisory authority can ask about today. ## Check yourself 1. *We want engagement analytics on staff video calls, with a clear notice.* — **Art. 5(1)(f) prohibits inferring emotions in the workplace.** No notice cures a prohibition. 2. *Our marketing team publishes AI-drafted commentary on regulatory developments, reviewed by our head of communications.* — **Potentially Art. 50(4) text on a matter of public interest, but the editorial-control exception may apply.** Document who holds editorial responsibility. 3. *A human makes the final call, so Art. 26(11) does not bite.* — **It does.** The paragraph covers systems that make decisions *or assist in making* them. 4. *An applicant asks why they were rejected. What does Art. 86 require?* — **A clear and meaningful explanation of the role the system played and the main elements of the decision** — not the model's internals, and not necessarily a reversal. --- **Previous:** [Module 5 — The Article 25 trap](/en/academy/ai-act-deployer/module-5/) **Next:** [Module 7 — The evidence file →](/en/academy/ai-act-deployer/module-7/) -------------------------------------------------------------------------------- ## Module 7 — The Evidence File a Supervisor Actually Asks For URL: https://www.regulation-ai.eu/en/academy/ai-act-deployer/module-7/ Six modules of obligations produce one thing: a file. This module assembles it, in the order a supervisory conversation actually goes, and ends with what to do first if you are starting from nothing. ## The order the questions come in A supervisor does not begin with your policy. They begin with a system, and they work outward. **"Which AI systems do you use?"** The inventory from Module 1. The failure here is not having one; the more common failure is having one that omits the systems adopted outside procurement, which are the ones most likely to carry obligations. **"How did you classify this one, and against what?"** The determination record: the tier, the Annex III point checked, the carve-out relied on, who decided, when, and against which version of the law. That last field is what lets a determination be reviewed rather than redone — the Digital Omnibus moved the Chapter III dates and rewrote Art. 4 in July 2026, and a record that does not name its legal baseline cannot be audited. **"Show me the instructions for use."** Art. 13 obliges the provider to give you these. Not having them is a finding against you even though the duty to supply is the vendor's, because Art. 26(1) requires you to use the system in accordance with them and you cannot do what you have not read. **"Who oversees it, and what may they do?"** Named individuals, training tied to this system, a written delegation of authority, and the override rate. Module 3. **"What do you monitor, and what happened when a threshold was crossed?"** The monitoring plan and at least one worked example. A plan with no incidents in eighteen months invites the question of whether anyone is reading it. **"Show me six months of logs."** Or longer, per Art. 26(6) and whatever sectoral law imposes. If the vendor holds them, show the contractual right and demonstrate an export. **"Who did you tell?"** Workers' representatives before go-live under Art. 26(7); affected persons under Art. 26(11); Art. 50 notices where they apply. **"What is your AI literacy programme?"** Art. 4, and the register behind it. ## The FRIA determination — including when you do not owe one Art. 27 requires a fundamental rights impact assessment from a narrow set of deployers: - bodies governed by public law; - private entities providing public services; - deployers of the systems in **Annex III point 5(b)** — creditworthiness evaluation and credit scoring of natural persons; - deployers of the systems in **Annex III point 5(c)** — risk assessment and pricing in relation to life and health insurance. Everyone else does not owe one. A private employer deploying recruitment screening under Annex III point 4 does not owe a FRIA. A retailer deploying biometric categorisation does not owe a FRIA. This is worth stating plainly because the market has broadly got it wrong, and the cost of getting it wrong in the over-inclusive direction is real: teams spend quarters producing an assessment nobody asked for while the Art. 26 artefacts that *are* owed remain unbuilt. **Write down the determination either way.** "We assessed Art. 27 and concluded it does not apply, because we are not a public body, do not provide public services, and the system is Annex III point 4 rather than 5(b) or 5(c)" is a two-line record that answers the question permanently. Where you do owe one, Art. 27 sets out its content: a description of the deployer's processes in which the system will be used, the period and frequency of intended use, the categories of natural persons likely to be affected, the specific risks of harm to those persons, the human oversight measures, and the measures to take if those risks materialise. And where a DPIA is also required, the FRIA complements it rather than duplicating it. ## The Art. 4 literacy register Art. 4 was rewritten by Regulation (EU) 2026/1744 in July 2026. Providers and deployers must now **take measures to support the development of AI literacy** among staff and others operating systems on their behalf, taking into account their technical knowledge, experience, education and training, the context of use, and the persons on whom the systems are used. The text states expressly that it does **not require guaranteeing any specific level of AI literacy of any individual**. Three consequences. **Evidence measures, not levels.** Before the amendment, a defensible position needed something approaching an assessment of attainment. Now the artefact is the measure itself: what you provided, to whom, when, and why it fit their role. **Art. 4 carries no fine band of its own.** It appears in none of the paragraphs of Art. 99. The exposure is indirect: a literacy failure feeds an Art. 26(2) finding, which does carry the Art. 99(4) band, and it colours the assessment of any other breach. **The register is the artefact.** One row per person: name, role, what they were trained on, date, duration, which systems it relates to, and the evidence — an attendance record, a completion record, or a certificate with a verifiable id. Reviewed when roles change or when a new system is deployed. That register is also the natural output of a training programme, which is why running one is cheaper than documenting one after the fact. ## Vendor due diligence, before signature Everything a deployer owes depends on information only the provider has. Ask for it while you still have commercial leverage: - the **instructions for use** (Art. 13), in full, not a datasheet; - the provider's **classification** of the system and its reasoning; - where the Art. 6(3) derogation is claimed, the **Art. 6(4) documentation** and the **Art. 49(2) registration** reference; - a **sample export of the Art. 12 logs**, so you know what you will be retaining and can confirm you can retain it; - the **declared intended purpose**, quoted, for your inventory; - the **human oversight measures** the provider considers appropriate, per Art. 14; - an **Art. 25 cooperation clause**: information and technical access if you ever become the provider, with a service level; - a **log access and export clause**, if the vendor hosts; - notification commitments, so your Art. 26(5) and their Art. 73 obligations connect. A vendor unable to supply the first three is selling a product that cannot be deployed compliantly for a high-risk purpose. That is a finding about the product, not about your paperwork. ## If you are starting from nothing In order, and none of these requires the Chapter III deadline to have arrived: 1. **Build the inventory.** You cannot do anything else first. 2. **Run the Art. 5 check across it.** Prohibitions are in force, carry the highest band, and catch ordinary deployments — emotion inference at work above all. 3. **Run the Art. 50 check.** In force since August 2026, tier-independent, and two of the four duties are yours. 4. **Classify, and write the determinations down.** 5. **Start the literacy register.** It is cheap, it is owed now, and it feeds Art. 26(2) later. 6. **Fix procurement.** Every future system arrives with its instructions, its classification and its cooperation clause, or it does not arrive. 7. **Then build the Art. 26 artefacts** for the systems that turned out to be high-risk, against the December 2027 date. Steps 1 to 3 are where the enforceable exposure is today. Steps 6 and 7 are where the work is. ## Check yourself 1. *We are a private hospital deploying an Annex III point 5 triage system. FRIA?* — **Consider Art. 27 carefully:** a private entity providing public services is in scope, and the answer turns on that characterisation rather than on the Annex III point alone. 2. *Our AI literacy programme has no exam. Is that a problem under Art. 4?* — **No.** As rewritten, Art. 4 asks for measures supporting literacy and expressly does not require guaranteeing a level for any individual. 3. *The vendor will not share the instructions for use.* — **Art. 13 obliges them to provide it.** Without it you cannot satisfy Art. 26(1); treat it as a blocker at procurement, not a compliance gap afterwards. 4. *We have no incidents recorded in eighteen months of monitoring.* — **Expect that to be probed.** Either the thresholds are set where nothing can cross them, or nobody is reading the output. --- **Previous:** [Module 6 — Transparency you owe directly](/en/academy/ai-act-deployer/module-6/) You have completed the seven modules. Together they cover the obligations that attach to the organisation using an AI system rather than the one building it — [sit the Deployer examination →](/en/academy/ai-act-deployer/exam/) -------------------------------------------------------------------------------- ## AI Act Fundamentals — Free 5-Module Course on EU AI Act Compliance URL: https://www.regulation-ai.eu/en/academy/ai-act-fundamentals/ ## Five modules from zero to compliance-ready **This is the Art. 4 AI literacy course.** Every organisation that develops or deploys AI systems in the EU must ensure relevant staff understand their AI Act obligations. The Fundamentals course is designed to satisfy this requirement and takes under 3 hours. → Already familiar with the basics? [Go to the Pro certification →](/academy/) to implement your compliance programme. The AI Act Fundamentals course covers the EU AI Act from its legal basis to practical compliance obligations. Each module builds on the previous. All content is free — no paywall, no registration. --- ### [Module 1: What is the EU AI Act? →](/academy/ai-act-fundamentals/module-1/) **Estimated time: 20 minutes** - The AI Act's legal basis (Art. 114 TFEU — internal market harmonisation) - Geographic scope: who it applies to (providers, deployers, importers, distributors — even if established outside the EU) - Definition of an "AI system" under Art. 3(1) — and what is explicitly excluded - The relationship between the AI Act and GDPR, DORA, NIS2, and sector-specific regulation - Key institutions: national competent authorities, EU AI Office, notified bodies → Background: [AI Act overview →](/ai-act/) --- ### [Module 2: Risk Classification →](/academy/ai-act-fundamentals/module-2/) **Estimated time: 25 minutes** - The four-tier risk pyramid: prohibited, high-risk, transparency, minimal - **Prohibited practices** (Art. 5): the eight banned AI uses, in effect since 2 February 2025 - **Annex I high-risk** (Art. 6(1)): AI embedded as safety components in regulated products - **Annex III high-risk** (Art. 6(2)): the 8 standalone high-risk AI domains - The Art. 6(3) exclusion mechanism: how to self-assess out of high-risk - **GPAI models** (Chapter V): definition, tiers, systemic risk threshold - **Transparency obligations** (Art. 50): chatbots, synthetic content, emotion recognition → Background: [Annex III guide →](/annex-iii/) · [Annex I guide →](/annex-i/) · [GPAI guide →](/gpai/) · [Prohibited practices →](/prohibited-practices/) --- ### [Module 3: Core Obligations for High-Risk AI →](/academy/ai-act-fundamentals/module-3/) **Estimated time: 30 minutes** - **Art. 9** — Risk management system: continuous, iterative, documented - **Art. 10** — Data governance: training, validation, and testing data quality requirements - **Art. 11 + Annex IV** — Technical documentation: what must be in the technical file - **Art. 13** — Transparency and provision of information to deployers - **Art. 14** — Human oversight: design measures, override capability - **Art. 15** — Accuracy, robustness, and cybersecurity: performance levels and residual risk - **Art. 17** — Quality management system (QMS): from design to post-market monitoring - **Art. 43** — Conformity assessment: self-assessment vs. third-party routes - **Art. 71** — EU AI database registration: what to register, when, how → Background: [Compliance Checklist →](/compliance-checklist/) --- ### [Module 4: GPAI Models — Who Is the Provider After You Fine-Tune? →](/academy/ai-act-fundamentals/module-4/) **Estimated time: 20 minutes** - What counts as a general-purpose AI model (Art. 3(63)) — and why a model is not a system - Provider obligations under Art. 53: documentation, downstream information, copyright policy, training-content summary - The systemic-risk presumption at 10^25 FLOPs and the extra Art. 55 duties - **The one-third compute rule**: fine-tuning only makes you the provider of the modified model above ~1/3 of the original's training compute - Why your enterprise LoRA is orders of magnitude below that line - Where the model regime and your system's regime meet — and where they do not → Background: [GPAI obligations →](/gpai/) --- ### [Module 5: Deadlines and Enforcement — What Is Due, and What It Costs →](/academy/ai-act-fundamentals/module-5/) **Estimated time: 20 minutes** - The full timetable after the Digital Omnibus — what moved and what did not - **Art. 50 transparency applies 2 August 2026 and was NOT deferred** — the nearest real deadline - Annex III deferred to 2 December 2027; Annex I to 2 August 2028 - Who enforces: national market surveillance authorities, and why your financial supervisor is likely to be yours - The three Art. 99 bands: €35M/7%, €15M/3%, €7.5M/1% — and the SME rule that inverts them - The order a programme should actually work in → Background: [Deadlines & Timeline →](/deadlines/) · [Digital Omnibus 2026 →](/omnibus/) · [Sanction Estimator →](/tools/sanction-estimator/) --- ## Get your AI literacy certificate After reading all 5 modules, you have covered the core EU AI Act requirements as required by Art. 4 (AI literacy obligation for providers and deployers). **The certificate is issued after a short exam** covering the five modules, and carries a unique ID that anyone can verify. It documents structured EU AI Act training you can file against your Art. 4 AI literacy measures. Fifteen questions are drawn from a bank and graded on the server — the answer key never reaches your browser. Score 70% or more and the certificate is issued immediately, with an Open Badge you can add to LinkedIn. → [Sit the exam now →](/en/academy/exam/) · [Verify a certificate →](/en/verify/) For the next level — risk assessment templates, technical documentation templates, and QMS extension guides — see [AI Risk Management Pro →](/academy/) -------------------------------------------------------------------------------- ## Module 1 — What the EU AI Act Actually Regulates (and What It Does Not) URL: https://www.regulation-ai.eu/en/academy/ai-act-fundamentals/module-1/ The AI Act is the first horizontal AI regulation anywhere. "Horizontal" is the word that matters: it does not regulate a sector, it regulates a *technology* and the *use* it is put to. That is why a bank, a hospital and a recruitment agency can all be in scope for entirely different reasons — and why a bank can be in scope as an *employer* while its trading desk stays out. This module answers three questions: what counts as an AI system, who the Act binds, and what it leaves alone. ## What counts as an AI system Art. 3(1) defines an AI system as a machine-based system that, with varying levels of autonomy and possible adaptiveness after deployment, **infers** from the input it receives how to generate outputs such as predictions, content, recommendations or decisions that can influence physical or virtual environments. The load-bearing word is **infers**. It draws the line that most scoping exercises get wrong in both directions: - A model that learned a mapping from data — a classifier, a scoring model, a language model, a recommender — infers. It is in. - A deterministic rules engine that executes conditions a human wrote — "if balance < 0 and days > 30 then flag" — does not infer. The Commission's guidelines on the definition of an AI system (February 2025) say so explicitly: simple rule-based systems fall outside. That distinction is worth money. Firms routinely declare their whole decision-engine estate as "AI" and then spend a year documenting rule sets that were never in scope. Others do the reverse and quietly exclude a scoring model because "it's just statistics" — statistical learning is squarely inside the definition. Being an AI system is only step one. It makes the Act *applicable*; it says nothing yet about how much of the Act applies. That is risk classification, and it is [Module 2](/en/academy/ai-act-fundamentals/module-2/). ## Who the Act binds The Act assigns obligations by **role**, not by industry. Four roles carry duties: | Role | Who you are | Weight of obligation | |---|---|---| | **Provider** | You develop an AI system, or have it developed, and place it on the market or put it into service **under your own name or trademark** | Heaviest — the full Art. 8–17 set for high-risk | | **Deployer** | You use an AI system under your own authority, in a professional capacity | Lighter but real — Art. 26, and Art. 27 for some public-interest bodies | | **Importer** | You are established in the EU and place on the market a system from a third-country provider | Verification duties, Art. 23 | | **Distributor** | You are in the supply chain and make a system available, without being provider or importer | Verification duties, Art. 24 | Most financial entities assume they are deployers, and most of the time they are right. But **Art. 25 turns a deployer into a provider** in three situations, and every one of them is a normal commercial decision somebody makes without calling a lawyer: 1. You put your **own name or trademark** on a high-risk system already on the market. 2. You make a **substantial modification** to a high-risk system that is already on the market. 3. You **change the intended purpose** of a system — including a non-high-risk one — such that it becomes high-risk. Buying a vendor model, white-labelling it in your app and pointing it at a use case the vendor never described is enough to make you the provider, with the full obligation set and the vendor's cooperation duty as your only lifeline (Art. 25(4)). This is the single most expensive mistake in AI Act scoping. ## Extraterritorial reach Art. 2(1) does not ask where you are established. It catches: - providers who **place on the EU market or put into service** an AI system in the EU, wherever they are established; - deployers who have their **place of establishment or are located** in the EU; - and — the one that surprises people — providers and deployers in a third country **where the output produced by the system is used in the EU**. A model trained and hosted in São Paulo, run by a Brazilian company, whose scores are used to decide on EU customers, is in scope. Geography of infrastructure is irrelevant; geography of *effect* is what counts. ## What the Act leaves alone Scope has real edges, and they are worth knowing before you inventory anything: - **Military, defence and national security** purposes are excluded entirely (Art. 2(3)). - **Scientific research and development** — systems developed and put into service for the sole purpose of scientific research (Art. 2(6)). - **Pre-market R&D activity**: research, testing and development *before* a system is placed on the market, except testing in real-world conditions (Art. 2(8)). - **Personal, non-professional use** by natural persons (Art. 2(10)). - **Free and open-source** AI systems, unless they are placed on the market as high-risk, are prohibited practices, or fall under the Art. 50 transparency rules (Art. 2(12)). ## How it interacts with what you already comply with The AI Act stacks; it does not replace. - **GDPR** governs the personal data inside the system. The AI Act governs the system. Art. 10(5) is the one place they interlock explicitly: it permits processing special-category data *strictly* for detecting and correcting bias, with safeguards. - **DORA** governs ICT risk and operational resilience for EU financial entities. Where an AI system is ICT, both apply — and their incident duties can fire together. That overlap has its own module in the Pro certification, and a [dedicated tool](/en/tools/dora-ai-overlap/). - **MiFID II Art. 17 and RTS 6** govern algorithmic trading. This matters because algorithmic trading appears **nowhere** in Annex III — a point Module 2 returns to. - **Sector law** (CRR/CRD, Solvency II, PSD2) is untouched by the AI Act and continues to apply on its own terms. ## Check yourself 1. *A vendor sells you a credit-decisioning model. You rebrand it as "YourBank Score" in your customer app. What are you?* — A **provider** under Art. 25(1)(a). Putting your own trademark on a high-risk system makes you one, with the full Art. 8–17 set. 2. *Your rules engine flags transactions over €10,000 from three named countries. Is it an AI system?* — **No.** It executes conditions a human wrote; it infers nothing. Art. 3(1) is not met. 3. *Your US-based model scores EU loan applicants. Your company has no EU entity. In scope?* — **Yes.** Art. 2(1)(c): the output is used in the EU. 4. *Does excluding open-source software from Art. 2(12) mean an open-source high-risk system is unregulated?* — **No.** The exemption falls away precisely when the system is high-risk, prohibited, or caught by Art. 50. --- **Next:** [Module 2 — Risk classification: the four tiers, and why most financial AI is not high-risk →](/en/academy/ai-act-fundamentals/module-2/) -------------------------------------------------------------------------------- ## Module 2 — Risk Classification: Why Most Financial AI Is Not High-Risk URL: https://www.regulation-ai.eu/en/academy/ai-act-fundamentals/module-2/ Everything expensive in the AI Act follows from classification. Get it right and a large AI estate can carry a modest compliance load. Get it wrong in the cautious direction and you will build a conformity assessment for a chatbot; get it wrong in the other and you will operate a high-risk system without one. There are four tiers. ## Tier 1 — Prohibited (Art. 5) Eight practices are banned outright. They have been in force since **2 February 2025**. The ones a commercial organisation could plausibly stumble into: - **Manipulative or deceptive techniques** that materially distort behaviour and cause significant harm. - **Exploiting vulnerabilities** of age, disability, or social/economic situation. - **Social scoring** — evaluating people over time from social behaviour or personal characteristics, leading to detrimental treatment in unrelated contexts or that is disproportionate. - **Emotion inference in the workplace or in education**, except for medical or safety reasons. This one catches sentiment analysis on employee communications and "engagement scoring" in interviews. - **Untargeted scraping** of facial images from the internet or CCTV to build recognition databases. The Digital Omnibus added one more: **non-consensual intimate imagery / nudification**, applying from 2 December 2026. Breaching Art. 5 carries the top penalty band: **€35 million or 7% of worldwide annual turnover**, whichever is higher. ## Tier 2 — High-risk (Art. 6, Annexes I and III) Two doors lead into high-risk, and they are not equivalent. **Annex I** — the system is a safety component of a product already covered by EU harmonisation law (machinery, medical devices, lifts, toys, and so on). This route applies from **2 August 2028**. Financial entities rarely enter here. **Annex III** — the system falls into one of eight listed use-case areas. This route applies from **2 December 2027** (deferred by the Digital Omnibus). This is the door that matters for finance, and the exclusions written into it are the whole point of this module. ### The carve-outs that decide most cases **Annex III 5(b) — creditworthiness.** In scope: evaluating the creditworthiness of *natural persons* or establishing their credit score. That covers consumer lending, BNPL, retail margin lending, and crypto lending to individuals. It **explicitly excludes AI systems used to detect financial fraud.** So transaction monitoring, AML screening and fraud models are *not* high-risk. This is the most common scoping error in the sector, and it runs in the expensive direction: firms classify their fraud stack as high-risk and take on Art. 8–15 obligations that were never owed. It also covers natural persons only. **SME and corporate credit scoring is not listed.** **Annex III point 1 — biometrics.** In scope: remote biometric identification, biometric categorisation by sensitive attributes, emotion recognition. It excludes **biometric verification whose sole purpose is confirming a person is who they claim to be**. A KYC selfie matched 1:1 against a document photo is verification, not identification. It is out. (GDPR Art. 9 still governs the biometric data itself — a different regime, still binding.) **Annex III point 4 — employment.** Recruitment, CV screening, promotion and termination decisions, task allocation, monitoring and evaluation of performance. This is the point that actually catches most financial entities — **as employers, not as banks**. A CV-screening tool in HR is high-risk in a bank exactly as it is in a bakery. **Annex III 5(c) — insurance.** Risk assessment and pricing in **life and health** insurance for natural persons. Non-life claims triage is not listed. ### What is not in Annex III at all **Algorithmic trading and robo-advice appear nowhere.** They are governed by MiFID II Art. 17 and RTS 6 (Delegated Regulation (EU) 2017/589), and by the ESMA statement of 30 May 2024 on AI in investment services. That is a real regulatory burden — it is simply not this one. ### The Art. 6(3) filter Even inside an Annex III area, a system is **not** high-risk if it does not pose a significant risk of harm — because it performs a narrow procedural task, improves the result of a previously completed human activity, detects decision patterns without replacing human assessment, or performs preparatory work. The filter has a catch: **profiling of natural persons always makes it high-risk**, no exceptions. And if you rely on the filter you must **document the assessment** before placing the system on the market and register it in the EU database. It is a genuine off-ramp, not a shrug. ## Tier 3 — Transparency (Art. 50) Applies whatever the risk tier. **In force 2 August 2026 — not deferred by the Omnibus**, which makes it the next real deadline for most organisations. - People must be told when they **interact with an AI system**, unless it is obvious. - **Synthetic content** must be marked in a machine-readable way. - **Deepfakes** must be disclosed as artificially generated. - **Emotion recognition or biometric categorisation** requires informing the exposed person. Your customer chatbot is not high-risk. It is caught by Art. 50, and the deadline is closer. ## Tier 4 — Minimal risk Everything else. No obligations under the Act — except **Art. 4 AI literacy**, which applies to providers and deployers across the board, whatever the tier. ## The honest map for a financial entity | Use case | Tier | Why | |---|---|---| | Transaction fraud detection | Minimal | Annex III 5(b) excludes fraud detection | | AML / sanctions screening | Minimal | Not an Annex III use case | | KYC 1:1 selfie match | Minimal | Point 1 excludes verification | | Consumer credit scoring | **High-risk** | Annex III 5(b) | | SME / corporate scoring | Minimal | 5(b) is natural persons only | | Algorithmic trading | Minimal (under the AI Act) | Not in Annex III; MiFID II / RTS 6 govern | | CV screening | **High-risk** | Annex III point 4 | | Employee performance monitoring | **High-risk** | Annex III point 4 | | Customer chatbot | Transparency | Art. 50(1) | | Life / health insurance pricing | **High-risk** | Annex III 5(c) | ## Check yourself 1. *Your AML model scores every transaction. Which tier?* — **Minimal.** Annex III 5(b) excludes fraud detection, and AML is not otherwise listed. Art. 4 literacy still applies. 2. *HR uses a CV-ranking tool. You are a bank. Which tier?* — **High-risk**, Annex III point 4. Your sector is irrelevant; you are acting as an employer. 3. *Your chatbot answers balance questions. When is the deadline?* — **2 August 2026**, Art. 50(1). Earlier than the high-risk regime, and not deferred. 4. *You rely on Art. 6(3) to say your Annex III system is not high-risk. What must you do?* — Document the assessment before market placement **and** register the system in the EU database. And check it does not profile natural persons, which would void the filter. --- **Previous:** [Module 1 — What the Act regulates](/en/academy/ai-act-fundamentals/module-1/) · **Next:** [Module 3 — Obligations by role →](/en/academy/ai-act-fundamentals/module-3/) -------------------------------------------------------------------------------- ## Module 3 — Obligations by Role: Provider, Deployer, and the Art. 25 Trap URL: https://www.regulation-ai.eu/en/academy/ai-act-fundamentals/module-3/ The Act does not ask what industry you are in. It asks what you *do* with a system, and it hands you an obligation set accordingly. Getting your role wrong is the most expensive error available, because the two main roles differ by roughly an order of magnitude in work. ## Provider obligations (high-risk) A provider develops a high-risk system — or has one developed — and places it on the market under its own name or trademark. Articles 8 to 17 then apply in full: | Article | Obligation | What it means in practice | |---|---|---| | **Art. 9** | Risk management system | A continuous, documented, lifecycle-long process — identify, estimate, evaluate post-market, mitigate. Not a one-off assessment. | | **Art. 10** | Data and data governance | Training, validation and test data must be relevant, sufficiently representative, and as far as possible error-free and complete. Bias must be examined and mitigated. | | **Art. 11** | Technical documentation | Drawn up **before** market placement, kept up to date, containing everything in Annex IV. | | **Art. 12** | Record-keeping | Automatic logging over the system's lifetime. | | **Art. 13** | Transparency to deployers | Instructions for use that let a deployer interpret output and comply with their own duties. | | **Art. 14** | Human oversight | Designed **into** the system so a human can understand, override and stop it. | | **Art. 15** | Accuracy, robustness, cybersecurity | Appropriate levels, declared, and resilient to error and adversarial input. | | **Art. 16** | Provider duties | The umbrella article, including a quality management system (Art. 17). | | **Art. 43** | Conformity assessment | Before market placement. Mostly internal control for Annex III; notified-body involvement for some biometric cases. | | **Art. 47–49** | Declaration, CE marking, registration | Sign the EU declaration of conformity, affix CE marking, register in the EU database. | | **Art. 72–73** | Post-market monitoring, serious incidents | A monitoring plan, and reporting of serious incidents to the authority. | That is a programme, not a checklist. It is why the provider/deployer determination is the first thing to settle and the last thing to guess at. ## Deployer obligations (high-risk) A deployer uses the system under its own authority in a professional capacity. **Art. 26** is materially lighter but not trivial: - **Use it as instructed.** Deviating from the instructions for use is where deployer liability starts — and can amount to a change of intended purpose. - **Assign human oversight** to people who are competent, adequately trained, and — the part usually missing — have the **authority** to intervene. An overseer who cannot overrule the model is decoration. - **Ensure input data is relevant and sufficiently representative** for the intended purpose, to the extent you control the input. - **Monitor operation**, and **suspend use** and inform the provider if you identify a risk. - **Keep the automatically generated logs** for at least six months. - **Inform workers' representatives** before putting a high-risk system into service in the workplace — before, not after. - **Inform affected persons** that they are subject to a high-risk system where it makes decisions about them. - **Report serious incidents** to the provider and, where applicable, the authority. Deployers that are public bodies, or private entities providing public services, additionally owe a **fundamental rights impact assessment** under Art. 27. ## The Art. 25 trap This is the article that reclassifies you without a meeting. A deployer becomes a **provider** — with the entire Art. 8–17 set — in three cases: **1. Your name on it.** You put your own name or trademark on a high-risk system already on the market. White-labelling a vendor model into your own app is enough. **2. Substantial modification.** You modify a high-risk system already on the market in a way that affects its compliance or changes its intended purpose. Retraining on your own data, changing the decision threshold in a way that alters the risk profile, or bolting on a new decision layer are all candidates. **3. Change of intended purpose.** You use a system for something the provider did not describe — including taking a non-high-risk system and pointing it at a high-risk use. Buying a general text classifier and using it to screen CVs converts *you* into the provider of a high-risk system. There is one lifeline: **Art. 25(4)** obliges the original provider to cooperate and supply the information and technical access you reasonably need. Put that in the contract *before* you need it, because a provider that has already been paid has little incentive to help you assume its obligations. ## GPAI in the chain If you build on a general-purpose AI model, the model provider carries its own Art. 53–55 duties. Those stay theirs. You do not inherit them by calling an API. You only become the provider of a *modified* model when the compute used for your modification exceeds roughly **one third** of the original's — the indicative criterion in the Commission guidelines of 18 July 2025. A bank's LoRA fine-tune is nowhere near that line. This is covered properly in [Module 4](/en/academy/ai-act-fundamentals/module-4/). ## Getting the determination on paper Whatever you conclude, write it down. Three questions, per system, dated and signed: 1. **What is the intended purpose, in the provider's words?** If you cannot quote it, you do not know whether you have changed it. 2. **Have we rebranded, modified, or repurposed it?** If yes to any, you are the provider. 3. **Who owns this system?** A named person, not a team. That record is the first thing an authority asks for, and the cheapest artefact in the entire regime to produce. ## Check yourself 1. *You deploy a vendor CV-screening tool unchanged, under the vendor's brand. Your role?* — **Deployer.** Art. 26 applies: oversight, input data, logs, worker information. The vendor remains the provider. 2. *Same tool, retrained on five years of your own hiring decisions. Your role?* — Almost certainly **provider** under Art. 25(1)(b): retraining on your own data is a substantial modification, and it changes the risk profile. 3. *Your overseer reviews every rejection but has never overturned one and cannot.* — Art. 26(2) is not met. Oversight requires competence, training **and authority to intervene**. 4. *How long must a deployer keep the logs?* — **At least six months**, unless other EU or national law says longer. --- **Previous:** [Module 2 — Risk classification](/en/academy/ai-act-fundamentals/module-2/) · **Next:** [Module 4 — GPAI models →](/en/academy/ai-act-fundamentals/module-4/) -------------------------------------------------------------------------------- ## Module 4 — GPAI Models: Who Is the Provider After You Fine-Tune? URL: https://www.regulation-ai.eu/en/academy/ai-act-fundamentals/module-4/ General-purpose AI is regulated on its own track. It is not a risk tier — a GPAI model is not "high-risk" or "minimal risk"; it carries model-level obligations that sit alongside the system-level regime you met in Modules 2 and 3. The obligations have been in force since **2 August 2025**. ## What counts as a GPAI model Art. 3(63): a model displaying significant generality, capable of competently performing a wide range of distinct tasks, and that can be integrated into a variety of downstream systems. Trained on large amounts of data, typically with self-supervision at scale. The distinction that matters downstream: a **model** is not a **system**. The model is the weights and what they can do. A system is the model plus the interface, the guardrails and the purpose. You can be the provider of a *system* built on someone else's *model* — that is the normal case, and it is exactly what happens when you build an assistant on a frontier API. ## What a GPAI provider owes (Art. 53) - **Technical documentation** of the model: training and testing process, evaluation results. - **Information to downstream providers** so they can understand capabilities and limitations and meet their own duties. - **A copyright policy**, including respecting text-and-data-mining reservations under the DSM Directive. - **A sufficiently detailed public summary of the training content**, following the AI Office template. Open-source models released under a free licence with public weights and parameters are exempt from the documentation and downstream-information duties — but **not** from the copyright policy or the training-content summary, and not at all if the model has systemic risk. ## Systemic risk (Art. 51 and 55) A model is **presumed** to carry systemic risk when the cumulative compute used for training exceeds **10²⁵ FLOPs**. The Commission can also designate a model on other criteria. Above that line, Art. 55 adds: - model evaluation, including **adversarial testing**; - assessment and mitigation of **systemic risks** at Union level; - tracking, documenting and **reporting serious incidents** to the AI Office; - **adequate cybersecurity** for the model and its physical infrastructure. For context: no enterprise fine-tune approaches 10²⁵ FLOPs. This tier is about a handful of frontier models. ## The question that actually comes up: does fine-tuning make me a provider? This is where organisations most often over-classify themselves, and the answer is usually no. The Commission guidelines of **18 July 2025** set an indicative criterion: you become the provider of the *modified model* when the compute used for the modification is **greater than about one third** of the compute used to train the original model. Where the original figure is not known, the guidelines point to one third of **10²³ FLOPs** as the reference. Put that in perspective. A LoRA adapter or an instruction fine-tune run by a bank on its own corpus is typically **several orders of magnitude** below that threshold. You are not the provider of the model. The upstream provider remains the provider, with its Art. 53 duties intact. What you *are*, in that case, is the provider of the **AI system** you built around it — and that is where your obligations live. If that system does consumer credit scoring, it is high-risk under Annex III 5(b) and everything in Module 3 applies. If it answers customer questions, it is caught by Art. 50 transparency. The model's regime and your system's regime are separate questions with separate answers. ## Where the two tracks meet | Question | Which regime answers it | |---|---| | Who documented the model's training data? | GPAI, Art. 53 — the model provider | | Is my credit-scoring system high-risk? | System regime, Annex III 5(b) | | Must my chatbot say it is a bot? | System regime, Art. 50(1) | | Who reports a serious incident from a frontier model? | GPAI, Art. 55 — the model provider, to the AI Office | | Who reports a serious incident from my system? | System regime, Art. 73 — you, to the national authority | A single deployment can touch all five rows. They do not collapse into one obligation set, and treating them as one is how programmes end up either massively over-scoped or missing the one duty that actually bit. ## Practical consequence for a deployer If you consume GPAI through an API: 1. **Get the Art. 53 information from your provider** and keep it. You will need it for your own technical documentation if your system is high-risk — Annex IV §2(d) asks about the data. 2. **Do not assume the provider's compliance is yours.** Their Art. 53 documentation covers their model, not your system. 3. **Track your fine-tuning compute** if you fine-tune at all. Not because you are likely to cross the line, but because being able to show you are three orders of magnitude below it ends the conversation in one slide. 4. **Watch for the change of purpose.** Using a general model for an Annex III use case makes you the provider of a high-risk system, however small your fine-tune was. That is Art. 25, not Art. 53 — a different trap, covered in Module 3. ## Check yourself 1. *You fine-tune an open-weights model with a LoRA on 50,000 internal documents. Are you the model provider?* — **No.** Nowhere near one third of the original training compute. You are the provider of the system you built. 2. *Your GPAI vendor says "we are AI Act compliant". Are you covered?* — **No.** Their Art. 53 duties are model-level. Your system's classification and obligations are yours. 3. *What is the systemic-risk presumption threshold?* — **10²⁵ FLOPs** cumulative training compute (Art. 51). 4. *When did GPAI obligations start applying?* — **2 December 2027.** Unlike the Annex III high-risk regime, they were not deferred. --- **Previous:** [Module 3 — Obligations by role](/en/academy/ai-act-fundamentals/module-3/) · **Next:** [Module 5 — Deadlines and enforcement →](/en/academy/ai-act-fundamentals/module-5/) -------------------------------------------------------------------------------- ## Module 5 — Deadlines and Enforcement: What Is Due, and What It Costs URL: https://www.regulation-ai.eu/en/academy/ai-act-fundamentals/module-5/ The AI Act entered into force on 1 August 2024 and applies in stages. The Digital Omnibus, agreed by the Council on 29 June 2026, moved some of those stages and left others exactly where they were. Knowing which is which is the difference between a programme that is late and one that is early. ## The timetable | Date | What applies | Status | |---|---|---| | **2 Feb 2025** | Prohibited practices (Art. 5) · AI literacy (Art. 4) | In force | | **2 Aug 2025** | GPAI model obligations (Art. 53–55) · governance · penalties | In force | | **2 Aug 2026** | **Transparency obligations (Art. 50)** | **NOT deferred** | | **2 Dec 2026** | New Art. 5 prohibition (non-consensual intimate imagery) · end of the grace period for marking generated content | Added by the Omnibus | | **2 Dec 2027** | **High-risk — Annex III** | Deferred from 2 Aug 2026 | | **2 Aug 2028** | High-risk — Annex I (products under harmonisation law) | Deferred | Two things follow from that table. **Art. 50 is the live deadline.** It was not deferred, and it applies whatever your risk tier. Any organisation running a customer-facing chatbot, a voice assistant, or a pipeline that generates content has a fixed date of 2 August 2026 — sooner than the high-risk regime that dominates most programme plans. **The deferral is not a reprieve for scoping.** Annex III obligations start in December 2027, but the work that takes longest — determining role, classifying systems, getting Annex IV information out of vendors, renegotiating contracts — has to happen well before. Firms that read the deferral as eighteen quiet months will spend the last six of them in a hurry. ## What the Omnibus actually changed It is worth being precise, because the Omnibus was widely over-reported: - **Art. 4 AI literacy was softened, not removed.** The wording moved from "shall ensure a sufficient level" to "shall take measures to support" AI literacy. It still applies to providers and deployers. - **Registration in the EU database was NOT abolished.** That proposal was dropped; registration remains. - **Marking of generated content**: the grace period was shortened from six months to three, ending 2 December 2026. - **High-risk timing** moved as shown above. ## Who enforces - **National market surveillance authorities** enforce the system-level regime in each member state. Financial entities are a special case: where the entity is already supervised under EU financial services law, the **financial supervisor** is typically designated as the market surveillance authority for its AI systems. Your existing prudential supervisor is likely to be your AI Act authority too. - **The AI Office**, within the Commission, supervises GPAI models directly. - **Notified bodies** perform third-party conformity assessment for the cases that require it. ## The penalties (Art. 99) Three bands. In each case the fine is the **higher** of the two figures: | Band | Ceiling | What triggers it | |---|---|---| | **Top** | **€35 m or 7%** of total worldwide annual turnover | Breach of the Art. 5 prohibitions | | **Middle** | **€15 m or 3%** | Most other infringements — including **all deployer obligations**, provider obligations, notified-body duties, and the Art. 50 transparency rules | | **Information** | **€7.5 m or 1%** | Supplying incorrect, incomplete or misleading information to authorities or notified bodies | **For SMEs and start-ups the rule inverts: the fine is the LOWER of the two figures.** That is a deliberate proportionality mechanism, and it is often misquoted in the other direction. Two points that get lost: 1. The 3% band is the one most organisations should plan against. It covers the deployer duties in Art. 26 — oversight, logs, informing workers — which are the obligations a normal company is most likely to miss. 2. Penalties are not the whole exposure. A market surveillance authority can require a system to be **withdrawn or recalled**. For a system embedded in a lending or hiring process, being ordered to stop using it is a bigger operational event than the fine. ## What a reasonable programme does next In the order that actually works: 1. **Inventory.** Every AI system, with its intended purpose in the provider's words. You cannot classify what you have not listed. 2. **Determine role per system.** Provider or deployer — and check Art. 25 honestly for each. 3. **Classify.** Use the Annex III carve-outs from Module 2 rather than assuming. Most systems come out lower than expected. 4. **Do Art. 50 now.** It has the nearest date and is the cheapest to fix. 5. **Do Art. 4 literacy now.** It is already in force, applies to everyone, and completing this course is evidence of it. 6. **Then build the high-risk programme** for the systems that genuinely need it — risk management (Art. 9), data governance (Art. 10), technical file (Annex IV), oversight (Art. 14). Steps 1 to 5 are mostly reading and writing. Step 6 is the programme, and it is what the [AI Risk Management Pro certification](/en/academy/) is built around. ## Check yourself 1. *Which obligation has the nearest deadline for most companies?* — **Art. 50 transparency, 2 August 2026.** Not deferred. 2. *A deployer fails to keep logs and to inform workers' representatives. Which band?* — **Middle: €15 m or 3%.** Deployer obligations sit there. 3. *You are a 20-person startup. Turnover €2 m. Fine for an Art. 5 breach?* — The **lower** of €35 m and 7% of €2 m — so up to €140,000, not €35 m. 4. *Did the Omnibus remove EU database registration?* — **No.** That proposal was dropped; registration stands. --- **Previous:** [Module 4 — GPAI models](/en/academy/ai-act-fundamentals/module-4/) You have completed the five modules. Together they cover the scope, classification, role and timing questions that Art. 4 expects staff working with AI systems to understand — [take the exam and claim your certificate →](/en/academy/exam/) -------------------------------------------------------------------------------- ## AI Act GPAI Certification Examination URL: https://www.regulation-ai.eu/en/academy/ai-act-gpai/exam/ Twenty questions on Chapter V and what builds on it. The paper is drawn from a bank of nearly ninety and stratified across all six modules, so every candidate is examined on the whole syllabus. It is graded on our server; the answer key never reaches your browser. **Twenty questions · 70% to pass · every answer returned with its reasoning and its article.** ## Before you start This examination is part of the [AI Act GPAI track](/en/academy/ai-act-gpai/). The modules are free to read; the examination and the certificate are the paid part, and the address you sit under must be the address the track was bought for. If you have not bought the track, the [free AI Act Fundamentals examination](/en/academy/exam/) uses the same engine and certificate machinery at no charge. -------------------------------------------------------------------------------- ## AI Act GPAI Certification — General-Purpose AI Models and What Builds on Them URL: https://www.regulation-ai.eu/en/academy/ai-act-gpai/ Chapter V is the newest and least settled part of the AI Act, and the one with the most confusion about who it binds. The confusion has a single root: the Regulation regulates **models** and **systems** under different chapters, on different timetables, with different enforcers — and almost every organisation working with foundation models touches both. This track separates the two, then works through each. ## The six modules **[Module 1 — Model or system? The Chapter V boundary](/en/academy/ai-act-gpai/module-1/)** Art. 3(63), what "significant generality" means, the research carve-out, and why the same organisation is usually a provider twice over. **[Module 2 — What every GPAI provider owes (Art. 53)](/en/academy/ai-act-gpai/module-2/)** Technical documentation to Annex XI, information to downstream providers to Annex XII, the copyright policy and the text-and-data-mining reservation, and the public training-content summary. **[Module 3 — Systemic risk (Art. 51, 52, 55)](/en/academy/ai-act-gpai/module-3/)** The 10^25 FLOP presumption and how to rebut it, the two-week notification, and the four additional obligations that follow. **[Module 4 — Codes of practice and the standards gap (Art. 56)](/en/academy/ai-act-gpai/module-4/)** What adherence demonstrates, what it does not, and how to work while harmonised standards do not yet exist. **[Module 5 — Becoming a model provider](/en/academy/ai-act-gpai/module-5/)** Fine-tuning, modification, the open-source relief and its limits, and the Art. 54 authorised representative for third-country providers. **[Module 6 — Building downstream](/en/academy/ai-act-gpai/module-6/)** You are the provider of the system you built: Art. 50 transparency, the Art. 25 trap, and what to demand from a model provider before you depend on them. ## What the examination asks Twenty questions drawn from a bank, stratified so every module is covered, graded on our server. The pass mark is 70%. ## Before you start This track assumes the [free Fundamentals course](/en/academy/ai-act-fundamentals/). If your organisation also builds high-risk systems on these models, the [Provider track](/en/academy/ai-act-provider/) covers the Chapter III obligations that then attach. -------------------------------------------------------------------------------- ## Module 1 — Model or System? The Chapter V Boundary URL: https://www.regulation-ai.eu/en/academy/ai-act-gpai/module-1/ The single most common Chapter V error is answering the wrong question. An organisation asks "are we caught by the GPAI rules?" when the useful question is "which of the two things we are doing is regulated where?" ## Art. 3(63), and the three tests inside it > **'general-purpose AI model'** means an AI model, including where such an AI model is trained with a large amount of data using self-supervision at scale, that displays **significant generality** and is capable of **competently performing a wide range of distinct tasks** regardless of the way the model is placed on the market and that **can be integrated into a variety of downstream systems or applications**, except AI models that are used for research, development or prototyping activities before they are placed on the market. Four things follow. **"Including where ... trained with a large amount of data using self-supervision at scale" is illustrative, not definitional.** A model need not be a transformer trained on web-scale text. The tests are generality, breadth of competent task performance, and integrability. **"Regardless of the way the model is placed on the market."** API, weights download, embedded in a product, offered free — the route does not change the classification. **"Can be integrated into a variety of downstream systems."** A model that can only serve one application is a component of that application, not a general-purpose model. **The research carve-out ends at market placement.** Models used for research, development or prototyping *before* being placed on the market are excluded. That protects experimentation; it does not protect a model you have started serving in production. ## Model versus system, stated once | | GPAI **model** | AI **system** | |---|---|---| | What it is | The trained artefact | The model plus what is built around it to serve a purpose | | Governed by | Chapter V (Art. 51-56) | Chapters II and III | | Bound party | Provider of the model | Provider of the system, plus its deployer | | Enforcer | Commission, via the AI Office | National market surveillance authorities | | Fine regime | Art. 101 — up to 3% or EUR 15 million | Art. 99 — bands by obligation | | Applied since | 2 August 2025 | Art. 5 from Feb 2025; Art. 50 from Aug 2026; high-risk from Dec 2027 / Aug 2028 | Note the enforcer row in particular. A GPAI provider deals with the Commission; a system provider deals with the Member State authority. Organisations that are both will meet both. ## Why most organisations here are providers twice over Take a company that trains a foundation model and also ships a customer-facing assistant built on it. **As a model provider**, it owes Art. 53: technical documentation to Annex XI, information for downstream providers to Annex XII, a copyright policy, and a public summary of training content. If the model crosses the systemic-risk threshold, Art. 55 adds evaluation, risk mitigation, incident reporting and model cybersecurity. **As a system provider**, it owes Art. 50(1) — telling people they are interacting with an AI system — and Art. 50(2) machine-readable marking of synthetic output. If the assistant is put to an Annex III use, the whole of Chapter III attaches on top. Neither set substitutes for the other, and they do not even share a deadline. ## The downstream case Now take the far commoner position: a company that trains nothing and builds a product on somebody else's model. It is **not** a GPAI provider. Chapter V duties for the underlying model stay with whoever provided it. What it *is* is the provider of the AI system it built, which brings Art. 50 and, depending on purpose, Chapter III. Two things can change that. **Modification.** Sufficiently substantial modification of a model can make you the provider of the modified model — Module 5 works through where the line sits. **Purpose.** Under Art. 25(1)(c), putting a general-purpose AI system that was not classified as high-risk to a high-risk use makes you the provider of a high-risk system. That is a Chapter III event, not a Chapter V one, and it is the single most common way an ordinary product team acquires the heaviest obligations in the Regulation. ## Where GPAI meets high-risk Art. 25 also anticipates the case where a general-purpose AI system is used directly as a high-risk system, or integrated into one. Where that happens, the provider of the GPAI system that is being integrated has cooperation duties toward the downstream provider — the same logic that runs through Art. 25(2): the party holding the information must make it available to the party carrying the obligation. In practice this is a contract question long before it is a litigation question, which Module 6 returns to. ## What to settle first Three determinations, written down: 1. **Do we place a model on the market, or put one into service?** If yes, Chapter V applies to us for that model. 2. **Do we place a system on the market, or put one into service?** If yes, Chapters II and III apply to us for that system, separately. 3. **If we build on a third-party model, what have we done to it?** Fine-tuning, distillation, merging, continued pre-training — record what and how much, because that record is what answers the provider-status question later. The third is the one that decays. Record it at the time. ## Check yourself 1. *We use a third-party model through an API. Are we a GPAI provider?* — **No.** You are the provider of the system you built on it; Chapter V duties stay with the model provider. 2. *Our model is used only internally for research.* — **The carve-out covers research, development and prototyping before market placement.** Production use is not research. 3. *We train a model and ship an assistant on it.* — **You are a provider twice**, under Chapter V for the model and under Chapter II/III for the system, with different deadlines and different enforcers. 4. *Who fines a GPAI provider, and under which article?* — **The Commission, through the AI Office, under Art. 101** — up to 3% of worldwide annual turnover or EUR 15 million, whichever is higher. --- **Next:** [Module 2 — What every GPAI provider owes (Art. 53) →](/en/academy/ai-act-gpai/module-2/) -------------------------------------------------------------------------------- ## Module 2 — What Every GPAI Provider Owes (Art. 53) URL: https://www.regulation-ai.eu/en/academy/ai-act-gpai/module-2/ Article 53 is short, and every one of its four obligations produces an artefact somebody outside your organisation will read. ## 53(1)(a) — technical documentation, to Annex XI Providers of general-purpose AI models shall **draw up and keep up to date the technical documentation of the model**, including its training and testing process and the results of its evaluation, containing at minimum the information set out in **Annex XI**, for the purpose of providing it, on request, to the **AI Office and the national competent authorities**. Annex XI covers, broadly: a general description of the model including tasks it is intended to perform and the type and nature of AI systems into which it can be integrated; acceptable use policies; date of release and methods of distribution; architecture and number of parameters; modality and format of inputs and outputs; the licence. Then, on the training process: the technical means required for integration; design specifications and training methodology including key design choices and rationale; information on the data used for training, testing and validation where applicable, including type and provenance and curation methodologies; computational resources used and training time; and known or estimated energy consumption. Two observations. **It is held, not published.** Unlike the training-content summary, Annex XI documentation is produced on request to the AI Office and national authorities. It is a file you must have, not a disclosure. **Energy consumption is in it.** Known or estimated energy consumption of the model is an Annex XI element, which surprises teams reading the article for the first time. ## 53(1)(b) — information to downstream providers, to Annex XII Providers shall **draw up, keep up to date and make available information and documentation to providers of AI systems who intend to integrate the model** into their AI systems. The information must, without prejudice to the need to observe and protect intellectual property rights and confidential business information including trade secrets: - **enable providers of AI systems to have a good understanding of the capabilities and limitations** of the model; and - **comply with their own obligations** under the Regulation. The minimum content is in **Annex XII**: a general description of the model, its intended tasks, the type and nature of systems it can be integrated into, acceptable use policies, release date and distribution methods, how it interacts with hardware and software external to the model, relevant software versions, architecture and parameter count, modality and format of inputs and outputs, and the licence — plus the technical means required for integration, and the model's design specifications and training process at the level needed for a downstream provider to do its job. This is the article a downstream builder should quote when a model vendor declines to explain what the model can and cannot do. The confidentiality carve-out is real, but it qualifies *how much* detail is owed, not *whether* the obligation exists. ## 53(1)(c) — the copyright policy Providers shall **put in place a policy to comply with Union law on copyright and related rights**, and in particular to identify and comply with, including through **state-of-the-art technologies**, a reservation of rights expressed pursuant to **Art. 4(3) of Directive (EU) 2019/790**. Article 4 of the DSM Directive permits text and data mining for any purpose, **unless** the rightsholder has expressly reserved the use in an appropriate manner — for content made publicly available online, in machine-readable form. So the obligation has two halves, and the second is the operational one: you must be able to **identify** reservations, and to **comply** with them. "Identify ... including through state-of-the-art technologies" is a moving standard: robots.txt-style signals, emerging machine-readable reservation formats, and whatever the state of the art becomes. What a defensible position looks like: a written policy; a description of the crawling and acquisition pipeline and where reservation checks sit in it; the signals honoured and the version of the standard; a record of what was excluded and when; and a review cadence tied to the state of the art moving. Note also that this obligation applies **regardless of where the training took place**. A model trained outside the Union and placed on the Union market carries it. ## 53(1)(d) — the public training-content summary Providers shall **draw up and make publicly available a sufficiently detailed summary about the content used for training** the model, according to a **template provided by the AI Office**. Three points that decide implementation. **Public.** This is the only Art. 53 output that must be published. It is read by rightsholders, journalists, competitors and downstream buyers. **Sufficiently detailed.** The tension in the article is deliberate: detailed enough to be meaningful to rightsholders assessing whether their content was used, without requiring disclosure of the dataset itself. The AI Office template is what resolves the tension in practice, and using it is the safe course. **Not a substitute for the copyright policy.** The summary describes what you trained on; the policy describes how you respected reservations. A provider that publishes a good summary and cannot describe its reservation handling has satisfied (d) and not (c). ## The open-source relief, and its limits Art. 53(2) provides that the obligations in **(a) and (b)** — Annex XI documentation and Annex XII downstream information — do **not** apply to providers of models released under a **free and open-source licence** that allows access, usage, modification and distribution of the model, and whose **parameters, including the weights, the information on the model architecture, and the information on model usage, are made publicly available**. Three limits. **It is conditional on genuine openness.** Weights, architecture and usage information public, and a licence permitting access, use, modification and distribution. A weights-available licence with field-of-use restrictions is unlikely to qualify. **(c) and (d) survive.** The copyright policy and the public training-content summary apply to open-source models too. This is the most frequently missed point in the whole article. **It does not apply to models with systemic risk.** The relief falls away entirely once Art. 51 bites — Module 3. ## Art. 54 — third-country providers Providers of GPAI models **established in third countries** shall, prior to placing a model on the Union market, **appoint by written mandate an authorised representative established in the Union**. The representative performs the tasks specified in the mandate, keeps a copy of the technical documentation at the disposal of the AI Office and national competent authorities, and cooperates with them. There is a corresponding relief for open-source models that do not present systemic risk. ## Check yourself 1. *We release our model under an open licence, so Art. 53 does not apply.* — **The relief covers (a) and (b) only.** The copyright policy and the public training-content summary still apply, and the relief disappears for systemic-risk models. 2. *Our model vendor says the architecture is a trade secret and will tell us nothing.* — **Art. 53(1)(b) and Annex XII require information enabling downstream providers to understand capabilities and limitations and to meet their own obligations**, with confidentiality qualifying the detail rather than the duty. 3. *We trained outside the EU, so the TDM reservation rules do not reach us.* — **Art. 53(1)(c) attaches to placing the model on the Union market**, not to where training happened. 4. *We published a training-data summary; are we done on copyright?* — **No.** (d) describes what you trained on; (c) requires a policy showing how reservations were identified and complied with. --- **Previous:** [Module 1 — Model or system? The Chapter V boundary](/en/academy/ai-act-gpai/module-1/) **Next:** [Module 3 — Systemic risk (Art. 51, 52, 55) →](/en/academy/ai-act-gpai/module-3/) -------------------------------------------------------------------------------- ## Module 3 — Systemic Risk (Art. 51, 52 and 55) URL: https://www.regulation-ai.eu/en/academy/ai-act-gpai/module-3/ Systemic risk is the AI Act's frontier-model regime. It affects a small number of providers directly and a large number indirectly, because every downstream builder inherits the consequences of whether the model they depend on is inside it. ## Art. 51 — two routes in A general-purpose AI model is classified as having systemic risk where either: **(a) it has high impact capabilities** evaluated on the basis of appropriate technical tools and methodologies, including indicators and benchmarks; or **(b) the Commission decides**, on its own initiative or following a qualified alert from the scientific panel, that it has capabilities or an impact equivalent to those under (a), having regard to the criteria in Annex XIII. Art. 51(2) then sets the quantitative presumption: a model **shall be presumed to have high impact capabilities** where the cumulative amount of computation used for its training measured in **floating point operations is greater than 10^25**. Three things about that number. **It is a presumption, and it is rebuttable.** Meeting it does not conclusively classify the model. A provider may present arguments that, despite meeting the criterion, the model does not present systemic risk on account of its specific characteristics. **It moves.** The Commission may adopt delegated acts to amend the threshold and to supplement benchmarks and indicators in light of evolving technology — algorithmic improvements and hardware efficiency both push it. **It is cumulative training compute**, not inference compute and not the compute of a single run. Annex XIII lists the criteria the Commission considers for designation: the number of parameters; the quality or size of the dataset; the amount of computation; input and output modalities; benchmarks and evaluations of capabilities including the number of tasks without additional training, adaptability, autonomy and scalability, and the tools it has access to; whether it has a high impact on the internal market due to its reach, presumed where it has been made available to at least 10,000 registered business users in the Union; and the number of registered end-users. ## Art. 52 — notification Where a model meets the Art. 51(1)(a) condition, the provider shall **notify the Commission without delay and in any event within two weeks** after that requirement is met or it becomes known that it will be met. Read the second limb: the clock can start **before** the threshold is crossed, at the point it becomes known that it will be. A provider planning a training run that will exceed the threshold knows in advance. The notification shall include the information necessary to demonstrate that the requirement has been met. Where the provider considers that the model does not present systemic risk despite meeting the criterion, it may present **sufficiently substantiated arguments** with the notification. If the Commission is not persuaded, the model is classified as having systemic risk. A provider may also request reassessment later, on the basis that the model no longer presents systemic risk — the classification is not permanently one-way. The Commission publishes and keeps updated a **list of models with systemic risk**, without prejudice to intellectual property and confidential business information. ## Art. 55 — the four additional obligations Providers of GPAI models with systemic risk shall: **(a) Perform model evaluation** in accordance with standardised protocols and tools reflecting the state of the art, **including conducting and documenting adversarial testing** of the model with a view to identifying and mitigating systemic risks. **(b) Assess and mitigate possible systemic risks at Union level**, including their sources, that may stem from the development, placing on the market or use of the model. **(c) Keep track of, document and report** without undue delay to the AI Office and, as appropriate, to national competent authorities, **relevant information about serious incidents** and possible corrective measures to address them. **(d) Ensure an adequate level of cybersecurity protection** for the model **and the physical infrastructure** of the model. Two things to notice. **(a) requires documentation, not just testing.** Adversarial testing that is performed and not written up does not satisfy an obligation whose text says "conducting and documenting". **(d) reaches physical infrastructure.** This is not a software security obligation. Weights are an asset whose theft is a systemic-risk event, and the article says so by extending to the infrastructure the model runs on. Art. 55 obligations sit **on top of** Art. 53, not instead of it — and the open-source relief in Art. 53(2) does not apply to systemic-risk models, so the Annex XI documentation and Annex XII downstream information are owed even for an openly released frontier model. ## Enforcement and fines Chapter V is enforced **centrally by the Commission through the AI Office**, with those powers applying from 2 August 2026. National market surveillance authorities enforce against systems; they do not enforce against models. Fines for GPAI providers sit in **Art. 101**, at up to **3% of worldwide annual turnover or EUR 15 million**, whichever is higher — a separate regime from the Art. 99 bands that apply to other operators. The Commission may impose them for, among other things, infringing the Chapter V obligations, failing to comply with a request for documents or information, failing to comply with a measure requested, or failing to give the Commission access to the model to conduct an evaluation. ## What a downstream builder should take from this module You are unlikely to be a systemic-risk provider. You are very likely to depend on one. The practical questions to put to a model vendor: - Is the model on the Commission's published systemic-risk list, and if not, does the provider expect it to be? - Can we see the Annex XII information — and is it the real document rather than a marketing page? - What is the incident notification path from you to us, given your Art. 55(c) duty and our Art. 26(5) duty if we deploy a high-risk system on your model? - What happens to us if the model is withdrawn or materially changed following a Commission measure? The last one is a business continuity question that most contracts do not answer. ## Check yourself 1. *We exceeded 10^25 FLOPs, so our model is definitively a systemic-risk model.* — **It is a rebuttable presumption.** Art. 52 lets you present substantiated arguments that the model does not present systemic risk despite meeting the criterion. 2. *We will notify once the training run completes.* — **The two-week clock runs from when the requirement is met OR it becomes known that it will be met**, which can be before the run finishes. 3. *Our systemic-risk model is open-source, so Art. 53(a) and (b) do not apply.* — **The open-source relief does not apply to models with systemic risk.** 4. *We ran red-team exercises but did not write them up.* — **Art. 55(1)(a) requires conducting AND documenting adversarial testing.** --- **Previous:** [Module 2 — What every GPAI provider owes (Art. 53)](/en/academy/ai-act-gpai/module-2/) **Next:** [Module 4 — Codes of practice and the standards gap →](/en/academy/ai-act-gpai/module-4/) -------------------------------------------------------------------------------- ## Module 4 — Codes of Practice and the Standards Gap (Art. 56) URL: https://www.regulation-ai.eu/en/academy/ai-act-gpai/module-4/ Chapter V arrived before the technical instruments that would make it operational. Art. 56 is the bridge, and understanding exactly what it does — and does not — do is worth more than knowing its text. ## The problem Art. 56 solves Most of the AI Act's requirements are outcome-stated: adequate cybersecurity, sufficiently detailed summary, state-of-the-art technologies, appropriate level. In the ordinary EU product-safety architecture, harmonised standards convert outcome statements into testable specifications, and compliance with a published standard buys a presumption of conformity. For general-purpose AI models, those standards did not exist when the obligations applied on 2 August 2025, and the standardisation work is still running. The absence of harmonised standards was also among the reasons cited for the Digital Omnibus deferring the high-risk system dates in July 2026 — the same gap, in a different chapter. A code of practice fills the interval. ## What Art. 56 provides The **AI Office shall encourage and facilitate the drawing up of codes of practice at Union level** to contribute to the proper application of the Regulation, taking into account international approaches. The AI Office and the Board shall aim to ensure that codes of practice cover at least the obligations provided for in **Art. 53 and Art. 55**, including: - the means to ensure that the information referred to in Art. 53(1)(a) and (b) is **kept up to date** in light of market and technological developments; - the adequate level of detail for the **summary about the content used for training**; - the identification of the **type and nature of the systemic risks** at Union level, including their sources where appropriate; - the measures, procedures and modalities for the **assessment and management of systemic risks** at Union level, including their documentation, proportionate to the risks, considering their severity and probability and taking into account the specific challenges of tackling those risks in light of the possible ways in which they may emerge and materialise along the AI value chain. The AI Office may invite **all providers of general-purpose AI models**, as well as relevant national competent authorities, to participate in drawing them up. Civil society organisations, industry, academia and other stakeholders such as downstream providers and independent experts may support the process. **The Commission may, by implementing act, approve a code of practice and give it general validity within the Union.** Where a code cannot be finalised, or the AI Office deems it not adequate, the Commission may provide common rules for the implementation of the Chapter V obligations by implementing act. ## What adherence buys, and what it does not **It buys a demonstrated route.** Providers may rely on a code of practice to demonstrate compliance with the Art. 53 and Art. 55 obligations until a harmonised standard is published. Compliance with a European harmonised standard, once published, gives the presumption of conformity to the extent the standard covers the obligations. **It does not convert the code into the obligation.** The obligations are in Art. 53 and Art. 55. A code describes a way of meeting them that the AI Office has facilitated and the Commission may have approved. Following it well is strong evidence; following it does not substitute for the article if the article demands something the code does not address. **It is not the only route.** Providers of general-purpose AI models who do not adhere to an approved code of practice, or do not comply with a European harmonised standard, shall **demonstrate alternative adequate means of compliance for assessment by the Commission**. That is a real alternative, and it is more expensive — you carry both the substance and the burden of showing your route is adequate. ## Working in the gap For a provider in this period, three practical positions. **Adhere, and say so.** If a code covering your obligations exists and has been approved, adherence is the cheapest demonstrable route and the one the Commission is best equipped to assess. **Map anyway.** Whether you adhere or not, produce an internal mapping from each Art. 53 and Art. 55 obligation to the specific artefact, process or control that satisfies it. If a code is approved later, that mapping becomes a gap analysis in an afternoon. Without it you start from the article. **Watch the standards.** When a harmonised standard's references are published in the Official Journal, the presumption of conformity becomes available, and the calculus changes. The transition from code to standard is the moment to re-examine positions built on the code. ## The same mechanism in Chapter III For completeness, because organisations frequently do both: Art. 40 provides the equivalent presumption for high-risk systems. Where a provider applies a harmonised standard whose references are published in the Official Journal, it is presumed to conform with the Chapter III Section 2 requirements the standard covers. Where standards do not exist or are insufficient, the Commission may adopt **common specifications** by implementing act, and providers who do not apply them must adopt technical solutions meeting the requirements at least equivalently. The pattern is identical in both chapters: an outcome-stated obligation, a voluntary instrument that demonstrates compliance, and a burden that shifts to the provider who takes another route. ## Check yourself 1. *We adhere to the code of practice, so we are compliant.* — **Adherence is a means of demonstrating compliance with Art. 53 and Art. 55**, not a substitute for them. 2. *We prefer not to adhere.* — **Then you must demonstrate alternative adequate means of compliance for assessment by the Commission** — a real route, with the burden on you. 3. *Do notified bodies certify GPAI models?* — **No.** There is no notified body role for models; enforcement is centralised at the Commission through the AI Office. 4. *A harmonised standard has just been published covering part of Art. 53.* — **Compliance with it gives a presumption of conformity for what it covers**, and it is time to re-examine positions built on the code. --- **Previous:** [Module 3 — Systemic risk (Art. 51, 52 and 55)](/en/academy/ai-act-gpai/module-3/) **Next:** [Module 5 — Becoming a model provider →](/en/academy/ai-act-gpai/module-5/) -------------------------------------------------------------------------------- ## Module 5 — Becoming a Model Provider: Fine-Tuning, Modification and Open Source URL: https://www.regulation-ai.eu/en/academy/ai-act-gpai/module-5/ This module answers the question every engineering team eventually asks: we took someone else's model and changed it — what are we now? ## Two separate questions, always The confusion in this area comes from collapsing two questions into one. Keep them apart: **Question 1 — Are we the provider of a MODEL?** This is a Chapter V question about what you did to the model artefact. **Question 2 — Are we the provider of a SYSTEM?** This is a Chapter II/III question, and if you built a product on the model and put it into service under your own name, the answer is yes regardless of what you did to the model. An organisation that fine-tunes an open model and ships an assistant is certainly the provider of the system. Whether it is also the provider of a model is the harder question. ## Where the line sits The Regulation does not give a bright-line test for when modification makes you the provider of a modified model, and no honest treatment pretends otherwise. What it gives is a direction of travel, and the direction is about **substance**. Factors that push toward provider status: - The modification **materially changes the model's capabilities** — what tasks it can competently perform, not just how well it performs one. - The modification involves **substantial additional training compute** relative to the original. - The result is **placed on the market or put into service** as a model in its own right, rather than embedded in your system. - You present it **under your own name** as a model. - The modification changes the **risk profile** in a way the original provider did not contemplate. Factors that push away: - Light adaptation for a narrow downstream task. - Adaptation that does not extend generality — the model is not now competently performing a wider range of distinct tasks. - The adapted artefact never leaves your system. There is a useful parallel with Art. 25 on the system side: the test there is whether the change was foreseen in the original assessment and whether it affects compliance or alters intended purpose. The instinct is the same — has the thing become, in substance, a different thing. **The practical control is documentation.** Record, at the time: the base model and version; what you did — fine-tune, LoRA, continued pre-training, distillation, merge; how much compute; what changed in evaluated capability; and what you concluded about provider status and why. That record is worth more than any general rule, because the question will be asked years later by someone who was not there. ## If you are the provider of a modified model Chapter V attaches to your version: - **Art. 53(1)(a)** — Annex XI technical documentation for your model. - **Art. 53(1)(b)** — Annex XII information to anyone integrating it. - **Art. 53(1)(c)** — a copyright policy. Note this covers **your** additional training data; you inherit no shelter from the base model provider's policy. - **Art. 53(1)(d)** — a public summary of the content used for training. In practice this describes your additional data and identifies the base model. And if the cumulative compute — including what the base model consumed — crosses the Art. 51 threshold, the systemic-risk regime is in play and the Art. 53(2) open-source relief is unavailable. ## The open-source relief, precisely Art. 53(2) relieves providers of models released under a **free and open-source licence that allows access, usage, modification and distribution of the model**, and whose **parameters, including the weights, the information on the model architecture, and the information on model usage, are made publicly available**, from the obligations in Art. 53(1)(a) and (b). Read as three cumulative conditions: 1. **The licence permits** access, use, modification and distribution. 2. **The weights are public** — not gated behind an application, not restricted to approved uses. 3. **Architecture and usage information are public.** A "weights-available" release under a licence restricting fields of use is unlikely to qualify. Neither is an open licence over weights nobody can obtain. And the two limits again, because they are where organisations get caught: **(c) and (d) survive the relief.** Copyright policy and public training-content summary apply to open-source models. **The relief does not apply to systemic-risk models at all.** An openly released frontier model owes the full Art. 53 set plus Art. 55. ## Art. 54 — authorised representatives Providers of general-purpose AI models **established in third countries** shall, prior to placing a model on the Union market, appoint **by written mandate** an authorised representative established in the Union. The representative: - **verifies** that the technical documentation specified in Annex XI has been drawn up and that all obligations under Art. 53 and, where applicable, Art. 55 have been fulfilled by the provider; - **keeps a copy of the Annex XI technical documentation** at the disposal of the AI Office and national competent authorities for ten years after the model has been placed on the market, and the contact details of the provider that appointed it; - **provides the AI Office**, upon a reasoned request, with all the information and documentation necessary to demonstrate compliance; - **cooperates** with the AI Office and competent authorities on any action they take in relation to the model. The mandate shall empower the representative to be addressed, in addition to or instead of the provider, by the AI Office or the competent authorities on all issues related to ensuring compliance. The representative shall **terminate the mandate** if it considers or has reason to consider that the provider acts contrary to its obligations, and shall immediately inform the AI Office, giving reasons. That is a meaningful safeguard: the representative is not a mailbox. Art. 54 does not apply to providers of models released under a free and open-source licence meeting the conditions above **that do not present systemic risks**. ## Check yourself 1. *We applied a small LoRA to an open model for our support product.* — **Almost certainly not a model provider**, but certainly the provider of the system you built. Record what you did and why you concluded that. 2. *We continued pre-training an open model on a large corpus and released the weights.* — **Likely the provider of that model**, with the full Art. 53 set attaching to your version, including a copyright policy covering your data. 3. *Our open model is behind an application form.* — **The relief requires the parameters to be publicly available.** Gated weights are unlikely to qualify. 4. *We are a US company serving a model to EU customers via API.* — **Art. 54 requires an authorised representative established in the Union appointed by written mandate**, unless the open-source, non-systemic-risk relief applies. --- **Previous:** [Module 4 — Codes of practice and the standards gap](/en/academy/ai-act-gpai/module-4/) **Next:** [Module 6 — Building downstream →](/en/academy/ai-act-gpai/module-6/) -------------------------------------------------------------------------------- ## Module 6 — Building Downstream: You Are the Provider of the System URL: https://www.regulation-ai.eu/en/academy/ai-act-gpai/module-6/ Most organisations reading this track will never train a model. They build on one, and their obligations come from three places: Art. 50 because their system is generative, Art. 25 because purpose can change under them, and their contract because everything they owe depends on information the model provider holds. ## You are the provider of the system Building a product on a third-party model and putting it into service under your own name makes you the provider of an AI system under Art. 3(3). Chapter V duties for the underlying model stay with whoever provided it. Nothing about using someone else's model shelters your system. That is the whole of it, and it is worth stating plainly because the instinct — *we didn't build the AI, they did* — is both natural and wrong. ## Art. 50, in force now Two of the four Art. 50 duties will apply to a typical generative product, and they applied from **2 August 2026**. **Art. 50(1) — interaction disclosure.** Providers shall ensure that AI systems intended to interact directly with natural persons are designed and developed so that the natural persons concerned are informed that they are interacting with an AI system, **unless this is obvious from the point of view of a reasonably well-informed, observant and circumspect natural person**, taking into account the circumstances and the context of use. There is a carve-out for systems authorised by law to detect, prevent, investigate or prosecute criminal offences, subject to safeguards. The "obvious" exception is narrower than product teams hope. A chat interface labelled with a product name is not self-evidently an AI system to a member of the public. **Art. 50(2) — machine-readable marking.** Providers of AI systems, including general-purpose AI systems, **generating synthetic audio, image, video or text content**, shall ensure that the outputs are **marked in a machine-readable format and detectable as artificially generated or manipulated**. Providers shall ensure their technical solutions are **effective, interoperable, robust and reliable as far as this is technically feasible**, taking into account the specificities and limitations of various types of content, the costs of implementation and the generally acknowledged state of the art. This obligation is tier-independent — it does not matter whether your system is high-risk — and it is a **provider** duty, so it is yours, not your model vendor's, for the system you ship. A transitional rule gave providers of generative systems already on the market before 2 August 2026 until **2 December 2026** to comply. The Art. 50(3) and 50(4) duties — emotion recognition and biometric categorisation notices, deepfake and public-interest text disclosure — sit on **deployers**, which means your customers. Your Art. 13-equivalent job is to make it possible for them to comply. ## The Art. 25 trap, from the downstream seat Art. 25(1)(c) makes you the provider of a **high-risk** AI system where you modify the intended purpose of a system — **including a general-purpose AI system that has not been classified as high-risk** — such that it becomes high-risk. The pattern is always the same and never looks like a decision: - A general assistant licensed for drafting, pointed at CV screening. Annex III point 4. - A summarisation product, used to draft adverse benefit decisions. Annex III point 5. - A classification pipeline built for content moderation, reused for creditworthiness. Annex III point 5(b) — and note that had it been reused for **fraud detection** it would have been carved out. When it fires, Art. 16 and the whole of Chapter III attach: risk management, data governance for training data you have never seen, Annex IV documentation, conformity assessment, CE marking, registration, post-market monitoring. **The control is procedural and cheap.** Every new use case for an existing system goes through the same classification step as a new system. One form, five minutes, at the moment of reuse. Without it, purpose creep is invisible by construction, because reusing a working pipeline is what good engineering practice tells a team to do. ## What to demand from a model provider Everything you owe depends on information they hold. Ask before you depend on them, while you still have commercial leverage. **The Annex XII information, as a document.** Art. 53(1)(b) obliges them to provide information enabling downstream providers to understand capabilities and limitations and to comply with their own obligations. A marketing page is not that document. Confidentiality qualifies the level of detail, not the existence of the duty. **Systemic-risk status.** Is the model on the Commission's published list; if not, do they expect it to be. It changes their obligations and, through them, your exposure. **The acceptable use policy**, and specifically what it says about high-risk uses. If it prohibits them, you know that a high-risk deployment puts you outside your licence as well as into Art. 25. **The incident path.** Their Art. 55(c) duty runs to the AI Office. Your Art. 26(5) duty, if you deploy high-risk, runs to your market surveillance authority. If you are in the middle, you need a channel in both directions with a stated timeframe. **Change and deprecation policy.** Model versions are withdrawn and behaviour shifts. If your Annex IV documentation describes performance you can no longer reproduce because the underlying model changed, you have a conformity problem caused by someone else's release schedule. **Cooperation commitments.** If Art. 25 ever makes you the provider of a high-risk system built on their model, Art. 25(2) gives you a statutory cooperation claim — unless they clearly specified the model was not to be used that way, which they very likely did. Contract for it instead. ## A short checklist for a downstream build 1. Are we generating synthetic content? Then **Art. 50(2) marking** is ours, now. 2. Does the system interact directly with people? Then **Art. 50(1) disclosure** is ours, now. 3. What is the declared intended purpose of our system, in writing? 4. Is there a **gate on new use cases** that would catch an Annex III purpose change? 5. Do we hold the **Annex XII information**, the acceptable use policy and a change policy from the model provider? 6. If we deploy for customers, have we written **instructions for use** that let them meet Art. 26? The last is the one that separates a product from a liability. Everything your customers owe under Art. 26 depends on what you tell them, and Art. 13 makes inadequate instructions a defect in your product rather than a gap in theirs. ## Check yourself 1. *Our model vendor marks its outputs, so Art. 50(2) is covered.* — **Art. 50(2) binds the provider of the system generating the content.** You ship the system; the duty is yours. 2. *We only expose a chat box; surely it is obvious it is AI.* — **The exception is judged from the point of view of a reasonably well-informed, observant and circumspect person** in context. A product-branded chat interface is rarely self-evident. 3. *A team started using our summariser to draft benefit decisions.* — **Art. 25(1)(c).** The intended purpose has changed into an Annex III use and you are now the provider of a high-risk system. 4. *The model vendor says everything is a trade secret.* — **Art. 53(1)(b) and Annex XII require information enabling downstream compliance.** Ask for it in writing, and contract for it before you depend on them. --- **Previous:** [Module 5 — Becoming a model provider](/en/academy/ai-act-gpai/module-5/) You have completed the six modules. Together they cover Chapter V and the obligations that reach a downstream builder — [sit the GPAI examination →](/en/academy/ai-act-gpai/exam/) -------------------------------------------------------------------------------- ## AI Act Provider Certification Examination URL: https://www.regulation-ai.eu/en/academy/ai-act-provider/exam/ Twenty-five questions on Chapter III from the provider's seat: the four determinations that precede development, the Art. 9 loop, data governance, the Annex IV file, oversight by design, accuracy and the AI-specific attack surface, the conformity route, and what happens after the market. The paper is drawn from a bank of over a hundred and stratified across all eight modules. It is graded on our server; the answer key never reaches your browser. **Twenty-five questions · 70% to pass · every answer returned with its reasoning and its article.** ## Before you start This examination is part of the [AI Act Provider track](/en/academy/ai-act-provider/). The modules are free to read; the examination and the certificate are the paid part, and the address you sit under must be the address the track was bought for. If you have not bought the track, the [free AI Act Fundamentals examination](/en/academy/exam/) uses the same engine and the same certificate machinery at no charge. -------------------------------------------------------------------------------- ## AI Act Provider Certification — Building and Placing High-Risk AI on the EU Market URL: https://www.regulation-ai.eu/en/academy/ai-act-provider/ The provider obligations are the heaviest part of the Regulation, and the part most organisations assume does not apply to them. It frequently does. Art. 3(3) makes you the provider if you develop a system and put it into service under your own name — **whether or not you sell it, and whether or not you wrote the code**. An internal model built by your own team has a provider, and it is you. This track works through Chapter III in the order you actually build it: what you must establish before development, what you must produce during it, what you must sign before placing the system on the market, and what you must keep doing afterwards. ## The eight modules **[Module 1 — Are you a provider, and by which route?](/en/academy/ai-act-provider/module-1/)** Art. 3(3), placing on the market versus putting into service, the Art. 25 inheritance, and the fork between the Annex I and Annex III regimes. **[Module 2 — The risk management system (Art. 9)](/en/academy/ai-act-provider/module-2/)** A continuous iterative process across the lifecycle, not a document produced once. Identification, estimation, evaluation, mitigation, and the residual risk you must be able to defend. **[Module 3 — Data and data governance (Art. 10)](/en/academy/ai-act-provider/module-3/)** Training, validation and testing data: relevance, representativeness, error, completeness, bias examination — and the narrow permission in Art. 10(5) to process special-category data to detect bias. **[Module 4 — Technical documentation (Art. 11 + Annex IV)](/en/academy/ai-act-provider/module-4/)** The file, element by element, drawn up before the system is placed on the market and kept current. **[Module 5 — Logging, instructions, oversight by design (Art. 12-14)](/en/academy/ai-act-provider/module-5/)** What the system must record, what the deployer must be told, and what the interface must let a human do. **[Module 6 — Accuracy, robustness, cybersecurity, and the QMS (Art. 15, Art. 17)](/en/academy/ai-act-provider/module-6/)** Declared performance under stated conditions, resilience, adversarial threats specific to AI, and the management system that holds it together. **[Module 7 — Conformity, declaration, marking, registration (Art. 43, 47-49)](/en/academy/ai-act-provider/module-7/)** Annex VI or Annex VII, what the declaration asserts, where the CE marking goes, and what the EU database entry contains. **[Module 8 — After the market: monitoring and incidents (Art. 72-73)](/en/academy/ai-act-provider/module-8/)** The post-market monitoring plan, serious incident reporting and its deadlines, and what a substantial modification does to everything above. ## What the examination asks Twenty-five questions drawn from a bank, stratified so every module is covered, graded on our server. The pass mark is 70%. ## Before you start This track assumes the [free Fundamentals course](/en/academy/ai-act-fundamentals/), and reads better after the [Deployer track](/en/academy/ai-act-deployer/) — because a provider that does not understand what its deployers owe will not write usable instructions for use, and Art. 13 makes that a defect in the product. -------------------------------------------------------------------------------- ## Module 1 — Are You a Provider, and by Which Route? URL: https://www.regulation-ai.eu/en/academy/ai-act-provider/module-1/ Before any of Chapter III matters, two questions have to be settled: are you a provider at all, and if so, which of the two high-risk regimes governs the system. Getting the second wrong sends a team down a conformity assessment route that does not apply to them, which is expensive in a way that only becomes visible late. ## Art. 3(3), read carefully > **'provider'** means a natural or legal person, public authority, agency or other body that **develops an AI system or a general-purpose AI model or that has an AI system or a general-purpose AI model 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. Four things are absent from that definition, and each absence catches someone. **Nothing about writing the code.** "Or that has an AI system developed" covers commissioning. If you contracted a consultancy to build a system and you put it into service under your name, you are the provider and they are not. **Nothing about selling.** "Whether for payment or free of charge" removes any commercial threshold. **Nothing about the market.** *Putting into service* is defined as supplying for first use directly to the deployer **or for own use**. An internal model deployed to your own staff has been put into service. You are its provider. **Nothing about size.** There is no SME exemption from provider status. There are proportionality allowances inside some obligations, and simplified documentation arrangements for smaller providers, but the status itself does not scale. ## Placing on the market versus putting into service The two concepts do different work. **Placing on the market** — the first making available of an AI system on the Union market. This is the trigger most obligations are written against: the technical documentation must be drawn up *before* it, the declaration of conformity signed before it, the CE marking affixed before it. **Putting into service** — supply for first use directly to the deployer or for own use, for the intended purpose. This is the route by which an organisation that never sells anything becomes a provider. Both matter for a second reason: they fix the moment at which the system's compliance is assessed. A system placed on the market compliant does not become non-compliant because the law later changed — but a **substantial modification** re-opens the question, which Module 8 returns to. ## Inheriting provider status through Art. 25 You can become the provider of a system somebody else built. Art. 25 makes a distributor, importer, deployer or other third party the provider of a high-risk system where it: - puts its own name or trademark on a system already placed on the market; - makes a substantial modification to a high-risk system that remains high-risk; - modifies the intended purpose of a system — including a general-purpose AI system not classified as high-risk — so that it becomes high-risk. The consequence is the whole of Art. 16, which is the whole of this track. Organisations meet this most often through the third trigger and through ordinary product evolution rather than through a decision. Where Art. 25 fires, the original provider must cooperate closely and make available the information and technical access reasonably needed — **unless it clearly specified that its system is not to be changed into a high-risk one**. That final clause is why supplier terms increasingly say exactly that, and why the cooperation you need belongs in the contract rather than in a statutory duty you would have to argue for. ## The fork: Annex I or Annex III Art. 6 creates two routes into high-risk, and they behave differently. **Art. 6(1) — the Annex I route.** An AI system is high-risk where it is intended to be used as a **safety component** of a product, or is itself a product, covered by the Union harmonisation legislation listed in Annex I — machinery, toys, lifts, radio equipment, medical devices, in-vitro diagnostics, civil aviation, motor vehicles, marine equipment and others — **and** that product is required to undergo a third-party conformity assessment under that legislation. Consequences: the AI Act requirements are integrated into the existing sectoral conformity assessment rather than run alongside it, and the obligations apply from **2 August 2028**. **Art. 6(2) — the Annex III route.** A system is high-risk if it falls in one of the eight Annex III areas: biometrics; critical infrastructure; education and vocational training; employment and worker management; access to essential private and public services; law enforcement; migration, asylum and border control; administration of justice and democratic processes. Consequences: conformity assessment normally by internal control under Annex VI, and obligations from **2 December 2027**. The practical test is whether the AI is functioning inside a product that already has its own CE regime. A diagnostic algorithm inside a medical device is Annex I. A CV screening tool sold as software is Annex III. A model that does both — say, a device-embedded algorithm also sold as a standalone service — is two products and needs two answers. ## The Art. 6(3) filter, from the provider's side Art. 6(3) allows a system in Annex III to be treated as not high-risk where it does not pose a significant risk of harm to health, safety or fundamental rights, including by not materially influencing the outcome of decision making, and where one of four conditions is met: narrow procedural task; improvement of the result of a previously completed human activity; detection of decision-making patterns or deviations without replacing or influencing previously completed human assessment; or a preparatory task to an assessment. Two provider-side facts. **Profiling voids it.** A system that performs profiling of natural persons is always high-risk. No condition survives. **Invoking it is not free.** Art. 6(4) requires the provider to **document the assessment before placing the system on the market** and to **register the system under Art. 49(2)**. You appear in the EU database either way. The derogation reduces the obligation set; it does not make you invisible, and a deployer doing proper diligence will ask you for both artefacts. ## What to settle before development starts Four determinations, written down, dated, and named against the version of the law they were made under: 1. **Are we the provider?** Under which limb — development, commissioning, or Art. 25 inheritance. 2. **Which route?** Annex I or Annex III, and if Annex I, which listed legislation. 3. **Which Annex III point, and does a carve-out apply?** The fraud-detection carve-out in 5(b) and the 1:1 verification carve-out in point 1 decide a great many real cases. 4. **Are we relying on Art. 6(3)?** If so, who is producing the Art. 6(4) documentation and when. Deciding these after the model is built means retrofitting Art. 10 data governance onto a dataset assembled without it, which is the single most expensive rework in this field. ## Check yourself 1. *A consultancy built our system; we deployed it under our brand. Who is the provider?* — **You are.** Art. 3(3) covers having a system developed and putting it into service under your own name. 2. *We never sell the system, we only use it internally.* — **Putting into service includes own use.** You are the provider. 3. *Our algorithm is embedded in a Class IIa medical device.* — **Annex I route**, integrated with the medical devices conformity assessment, obligations from 2 August 2028. 4. *We are relying on Art. 6(3), so we have nothing to file.* — **Art. 6(4) requires documented assessment before market placement and registration under Art. 49(2).** --- **Next:** [Module 2 — The risk management system (Art. 9) →](/en/academy/ai-act-provider/module-2/) -------------------------------------------------------------------------------- ## Module 2 — The Risk Management System (Art. 9) URL: https://www.regulation-ai.eu/en/academy/ai-act-provider/module-2/ Article 9 is the spine of Chapter III. Every other requirement either feeds it or is justified by it: data governance addresses risks you identified, the technical documentation records them, human oversight mitigates them, and post-market monitoring watches for the ones you missed. It is also the requirement most often satisfied on paper and not in fact, because the artefact — a risk assessment — looks the same whether or not a process produced it. ## What Art. 9 actually establishes Art. 9(1) requires a risk management system to be **established, implemented, documented and maintained** in relation to high-risk AI systems. Art. 9(2) defines it as a **continuous iterative process planned and run throughout the entire lifecycle**, requiring regular systematic review and updating, and comprising four steps: 1. **Identification and analysis** of the known and the reasonably foreseeable risks the system can pose to health, safety or fundamental rights when used in accordance with its intended purpose. 2. **Estimation and evaluation** of the risks that may emerge when the system is used in accordance with its intended purpose, and under conditions of **reasonably foreseeable misuse**. 3. **Evaluation of other risks** possibly arising, based on the analysis of data gathered from the post-market monitoring system. 4. **Adoption of appropriate and targeted risk management measures** designed to address the risks identified. Read step 3 again. The risk management system takes an input from post-market monitoring, which does not exist until the system is on the market. That is what makes Art. 9 unclosable: it is a loop, and Art. 72 is the return path. ## Reasonably foreseeable misuse Art. 3 defines misuse as use of an AI system in a way that is not in accordance with its intended purpose, but which **may result from reasonably foreseeable human behaviour or interaction with other systems**. This is where most risk assessments are thin. The intended-purpose analysis is usually competent because it mirrors the product specification. The misuse analysis requires imagining users behaving as users do: - A screening tool built to rank candidates, used to reject them automatically because the volume made review impractical. - A summarisation system built for internal briefings, used to generate customer-facing text. - A triage model built as decision support, used as a decision because the humans learned to trust it. - A system evaluated on one population, deployed on another because a new market opened. Note that most of these are also the deployer's Art. 26(1) failure. That does not discharge you: reasonably foreseeable misuse is a provider obligation precisely because the provider is better placed to anticipate it and to design against it. ## Measures, in the order the Regulation puts them Art. 9(5) sets an order, and it is not a menu: 1. **Eliminate or reduce risks as far as technically feasible** through adequate design and development of the system. 2. Where appropriate, implement **adequate mitigation and control measures** for risks that cannot be eliminated. 3. Provide **information required under Art. 13** and, where appropriate, **training to deployers**. Design first. A risk that could have been engineered out but was instead pushed into the instructions for use has not been managed in the way Art. 9 contemplates. This is the provision behind a common review finding: a control that exists only as a warning in the documentation. The third step is also the bridge to the deployer track. Your Art. 13 instructions are a **risk control**, not marketing collateral. When a deployer's oversight fails because your instructions did not explain what the system cannot do, that is an Art. 9 and Art. 13 defect in your product. ## Residual risk, and judging it Art. 9(5) requires that residual risks — those remaining after measures — be **judged acceptable**. The Regulation does not tell you what acceptable means, which is deliberate and unhelpful in equal measure. What survives review is a residual risk statement that: names the risk, states what was done, states what remains, states who judged it acceptable and on what basis, and states the conditions under which that judgement would change. The last element is what connects it to post-market monitoring: if you cannot say what would make you revisit the judgement, you have not made one. ## Testing (Art. 9(6)-(8)) High-risk systems must be **tested** to identify the most appropriate risk management measures, ensuring they perform consistently for their intended purpose and comply with the Chapter III requirements. Testing is against **prior defined metrics and probabilistic thresholds appropriate to the intended purpose** — so you must define the metric and the threshold before the test, not after seeing the results. Testing may be carried out at any point during development and in any event before placing on the market or putting into service. Real-world testing outside a sandbox is governed separately by Art. 60 and its own conditions. ## Vulnerable groups (Art. 9(9)) The risk management system must give consideration to whether the high-risk system is **likely to have an adverse impact on persons under the age of 18 and, as appropriate, other vulnerable groups**. This is a specific, checkable requirement and it is frequently absent from otherwise competent assessments. If minors can be affected by your system — education, employment of young people, essential services, content systems — the assessment must say so and address it. ## Interaction with existing risk management Art. 9(10) recognises that providers already subject to internal risk management under other Union law may integrate these requirements into, or combine them with, those existing procedures. That is permission to extend a working system, not to point at one. A financial entity's operational risk framework can host the AI Act risk management system, provided the four steps, the misuse analysis, the testing regime and the vulnerable-groups consideration are genuinely present and traceable within it. ## What the file looks like Per system: the risk register with intended-purpose and misuse branches; the measures against each risk, marked design / mitigation / information; the test plan with metrics and thresholds defined in advance, and the results; the residual risk statement with its named owner and revisit conditions; the vulnerable-groups consideration; and a review log with dates showing the loop turning. That review log is the artefact that distinguishes a process from a document. Without dated iterations, Art. 9(2) is unevidenced regardless of how good the assessment is. ## Check yourself 1. *Our risk assessment is thorough and was signed off before launch.* — **Art. 9(2) requires a continuous iterative process with regular systematic review.** One assessment, however good, is not a risk management system. 2. *Users are misusing the system contrary to our documentation.* — **Reasonably foreseeable misuse is squarely within Art. 9(2)(b)**, and the deployer's breach does not discharge your obligation to have anticipated it. 3. *We addressed the risk with a warning in the instructions for use.* — **Art. 9(5) puts design first.** Information to deployers is the third step, not the first. 4. *Where does post-market data enter the risk management system?* — **At step three of Art. 9(2)**, which is why the process cannot be closed out at launch. --- **Previous:** [Module 1 — Are you a provider, and by which route?](/en/academy/ai-act-provider/module-1/) **Next:** [Module 3 — Data and data governance (Art. 10) →](/en/academy/ai-act-provider/module-3/) -------------------------------------------------------------------------------- ## Module 3 — Data and Data Governance (Art. 10) URL: https://www.regulation-ai.eu/en/academy/ai-act-provider/module-3/ Art. 10 is where the Regulation reaches furthest into how systems are actually built, and where retrofitting is most painful. Data governance decisions are made at the start of a project by people who are not thinking about conformity assessment, and they are close to irreversible by the time anyone does. ## Scope: which data, and which systems Art. 10 applies to high-risk systems **which make use of techniques involving the training of AI models with data**. For those systems it governs the **training, validation and testing datasets**. For high-risk systems **not** developed by training models with data — knowledge-based systems, rules engines that nonetheless sit in Annex III — Art. 10 applies **to the testing datasets only**. That narrower duty is real and often overlooked, because teams read "data governance" as "training data governance" and conclude it does not apply to them. ## The governance practices Art. 10(2) requires Training, validation and testing datasets must be subject to data governance and management practices appropriate to the intended purpose, concerning in particular: - the relevant **design choices**; - **data collection processes** and the origin of the data, and in the case of personal data, the original purpose of collection; - relevant data **preparation** operations, such as annotation, labelling, cleaning, updating, enrichment and aggregation; - the formulation of **assumptions**, notably with respect to the information the data are supposed to measure and represent; - an assessment of the **availability, quantity and suitability** of the datasets needed; - **examination in view of possible biases** likely to affect health and safety of persons, have a negative impact on fundamental rights, or lead to discrimination prohibited under Union law, especially where data outputs influence inputs for future operations; - **appropriate measures to detect, prevent and mitigate** those possible biases; - identification of relevant **data gaps or shortcomings** that prevent compliance, and how they can be addressed. Two of these deserve separate attention. **"The formulation of assumptions, notably with respect to the information the data are supposed to measure and represent."** This is asking you to write down your construct validity argument: you are using this feature as a proxy for that quality, and here is why that holds. It is the single most useful item on the list and the least often produced, because it is usually an implicit belief rather than a recorded decision. **"Especially where data outputs influence inputs for future operations."** This names feedback loops. A hiring model trained on past hiring decisions, retrained on the decisions it influenced, is the archetype. If your system's outputs re-enter its training data, Art. 10 requires you to have examined what that does. ## Quality: relevant, representative, error-free, complete Art. 10(3): datasets shall be **relevant, sufficiently representative, and to the best extent possible free of errors and complete in view of the intended purpose**. They shall have the appropriate statistical properties, including, where applicable, as regards the persons or groups on which the system is intended to be used. The qualifiers are doing real work and are frequently misquoted. It is not "error-free" — it is "to the best extent possible free of errors". It is not "complete" — it is "complete in view of the intended purpose". The Regulation is asking for a defensible, documented judgement, not perfection. Art. 10(4) adds that datasets shall take into account, to the extent required by the intended purpose, the **characteristics or elements particular to the specific geographical, contextual, behavioural or functional setting** within which the system is intended to be used. That is the provision that catches a model validated on one national population and shipped into another. If your intended purpose covers the Union, your representativeness argument has to cover the Union. ## Art. 10(5) — the special-category permission This is the most misunderstood paragraph in the article, in both directions: some teams believe they may never touch special-category data, others treat the paragraph as a general licence. To the extent **strictly necessary for the purpose of ensuring bias detection and correction** in relation to high-risk systems, providers may **exceptionally** process special categories of personal data, subject to appropriate safeguards including: - bias detection and correction **cannot be effectively fulfilled** by processing other data, including synthetic or anonymised data; - the special-category data are subject to **technical limitations on re-use** and state-of-the-art security and privacy-preserving measures, **including pseudonymisation**; - measures to ensure the data are **secured, protected, subject to suitable safeguards, including strict controls and documentation of the access**, avoiding misuse and ensuring only authorised persons have access with appropriate confidentiality obligations; - the data are **not transmitted, transferred or otherwise accessed by other parties**; - the data are **deleted once the bias has been corrected or the personal data has reached the end of its retention period**, whichever comes first; - records of processing activities include the reasons why processing was strictly necessary and why other data could not be used. Read as a whole, this permits a controlled bias-testing programme with a documented necessity argument and a deletion trigger. It does not permit retaining a demographic-labelled dataset indefinitely because it might be useful for fairness work later. The Digital Omnibus adjusted the framing of this permission in July 2026; if your compliance position was written before then, re-read the current text before relying on it. ## Bias examination is not one number The Regulation asks for examination of possible biases and appropriate measures to detect, prevent and mitigate them. It does not prescribe a metric, and there is no single metric that could serve — the common fairness criteria are mathematically incompatible with each other except in degenerate cases. What survives review is: a statement of which groups you examined and why those; which measures of disparity you used and why; what you found; what you did; and what residual disparity remains and why it is judged acceptable. That last clause connects back to Art. 9 residual risk, and it is the honest position — a claim of no bias is neither achievable nor credible. ## Where the file gets thin In review, the recurring gaps are consistent: - **Provenance** for data acquired years ago, before anyone anticipated needing it. This is unrecoverable, which is why acquiring data without recording provenance is now a compliance decision rather than an operational shortcut. - **The assumptions statement**, because it was never explicit. - **The bias examination for the deployment population** rather than the training population. - **Third-party datasets** whose licence permits use but whose composition the provider cannot describe. - **Feedback loops**, unexamined. Each of these is cheap at the start of a project and close to impossible at the end. That is the practical argument for settling Module 1's four determinations before development begins. ## Check yourself 1. *Our system is rules-based, not trained. Does Art. 10 apply?* — **Partly.** For systems not developed by training models with data, the requirements apply to the testing datasets. 2. *We cannot check for ethnic bias because we do not hold ethnicity data.* — **Art. 10(5) permits processing special-category data exceptionally and strictly for bias detection and correction**, subject to a heavy set of conditions including a necessity argument and deletion. 3. *Our dataset is large, so it is representative.* — **Representativeness is judged against the population the system is intended to be used on**, and against the geographical, contextual, behavioural and functional setting. Size is not the test. 4. *Our model is retrained on the decisions it influenced.* — **Art. 10(2) singles this out**: bias examination matters especially where data outputs influence inputs for future operations. --- **Previous:** [Module 2 — The risk management system (Art. 9)](/en/academy/ai-act-provider/module-2/) **Next:** [Module 4 — Technical documentation (Art. 11 + Annex IV) →](/en/academy/ai-act-provider/module-4/) -------------------------------------------------------------------------------- ## Module 4 — Technical Documentation (Art. 11 and Annex IV) URL: https://www.regulation-ai.eu/en/academy/ai-act-provider/module-4/ The Annex IV file is the evidence base for everything else. The conformity assessment is carried out against it, the declaration of conformity asserts what it demonstrates, and a market surveillance authority reads it before it reads anything you wrote about yourself. It is also the artefact that reveals whether the rest of Chapter III was done. A risk management system that exists produces a section here; one that does not, cannot. ## What Art. 11 requires Technical documentation shall be **drawn up before the system is placed on the market or put into service** and **kept up to date**. It shall be drawn up in such a way as to demonstrate that the high-risk system complies with the Chapter III Section 2 requirements, and to provide national competent authorities and notified bodies with the **information necessary in a clear and comprehensive form** to assess compliance. Two consequences. **"Before" is a hard gate.** You cannot place a system on the market and document it afterwards. The obligation is dated to market placement, and so is the declaration that depends on it. **"Clear and comprehensive" is a quality standard, not a volume standard.** A file that is technically complete but unreadable does not provide the information necessary in a clear form. Reviewers are not obliged to reconstruct your argument from artefacts. Where the system is related to a product covered by the Annex I legislation, Art. 11(2) requires a **single set of technical documentation** containing all the information required under both regimes. Two parallel files is a finding, not a strategy. ## The Annex IV elements **1. A general description of the AI system**, including its intended purpose, the name of the provider, the version, how it interacts with hardware or software that is not part of the system itself, the versions of relevant software or firmware, the forms in which it is placed on the market, the description of hardware on which it is intended to run, photographs or illustrations of external features where relevant, and the basic description of the user interface provided to the deployer. **2. A detailed description of the elements of the system and of the process for its development**, including the methods and steps performed, any pre-trained systems or tools provided by third parties and how they were used, integrated or modified; the design specifications, the general logic, the key design choices including rationale and assumptions; the classification choices; what the system is designed to optimise for and the relevance of the different parameters; the description of the expected output; the risk management decisions; the validation and testing procedures and the test logs; and the cybersecurity measures. **3. Detailed information about the monitoring, functioning and control of the system**, in particular its capabilities and limitations in performance, including the degrees of accuracy for specific persons or groups on which it is intended to be used and the overall expected level of accuracy in relation to its intended purpose; the foreseeable unintended outcomes and sources of risk to health and safety, fundamental rights and discrimination; the human oversight measures needed under Art. 14, including the technical measures put in place to facilitate the interpretation of outputs by deployers; and specifications on input data as appropriate. **4. A description of the appropriateness of the performance metrics** for the specific system. **5. A detailed description of the risk management system** in accordance with Art. 9. **6. A description of relevant changes** made by the provider to the system through its lifecycle. **7. A list of the harmonised standards applied** in full or in part, and where none were applied, a description of the solutions adopted to meet the Chapter III Section 2 requirements, including a list of other relevant standards and technical specifications applied. **8. A copy of the EU declaration of conformity.** **9. A detailed description of the system in place to evaluate the performance of the system in the post-market phase** in accordance with Art. 72, including the post-market monitoring plan. ## The elements that are hardest to produce late Three of the nine cannot realistically be reconstructed after the fact. **Element 2's "key design choices including rationale and assumptions".** Rationale is a contemporaneous artefact. Six months later a team can state what it did but only reconstruct why, and a reconstructed rationale reads as one. **Element 3's "degrees of accuracy for specific persons or groups on which the system is intended to be used".** Note the phrasing: not overall accuracy, but accuracy for the groups the system will be used on. That is a disaggregated evaluation, and it requires having held out data that supports the disaggregation. If you did not plan for it, you cannot compute it afterwards. **Element 6's "relevant changes made through its lifecycle".** A change log is either kept or it is not. The rest can be written up. These three have to be produced as you go, which is the practical argument for treating Annex IV as a living file that development contributes to rather than a document that compliance writes at the end. ## Standards, and what "none applied" means Element 7 asks which harmonised standards you applied. Where a harmonised standard exists and is applied, Art. 40 gives a presumption of conformity with the requirements it covers — which is the cheapest compliance route available. Where none were applied — which, for much of the AI Act's requirement set, remains the position while standardisation work continues — you must describe **the solutions adopted** to meet the requirements. The unavailability of standards was one of the reasons the Digital Omnibus deferred the Chapter III dates; it is not a reason for the file to be silent. A description of your own solution, mapped requirement by requirement, is what the element asks for. ## Keeping it, and keeping it current Art. 18 requires the provider to keep at the disposal of national competent authorities, for **ten years** after the system is placed on the market or put into service: - the technical documentation; - the documentation of the quality management system; - documentation concerning changes approved by notified bodies, where applicable; - decisions and other documents issued by notified bodies, where applicable; - the EU declaration of conformity. Ten years is longer than most product lifecycles and considerably longer than most document retention defaults. It is also longer than many vendor relationships, which is a reason to hold the file yourself rather than rely on a supplier's systems. "Kept up to date" in Art. 11 does real work alongside element 6: a file describing version 1.0 of a system that is now on version 4.2 does not demonstrate that the system on the market complies. ## Check yourself 1. *We will assemble the Annex IV file for the audit.* — **Art. 11 requires it drawn up before the system is placed on the market**, and the Art. 43 conformity assessment is carried out against it. 2. *Element 3 asks for accuracy — we report a single overall figure.* — **It asks for the degrees of accuracy for specific persons or groups on which the system is intended to be used**, which requires disaggregated evaluation planned in advance. 3. *No harmonised standards exist for our requirement.* — **Then element 7 requires a description of the solutions you adopted**, mapped to the requirements. 4. *How long do we keep it?* — **Ten years after market placement or putting into service**, under Art. 18, alongside the QMS documentation and the declaration of conformity. --- **Previous:** [Module 3 — Data and data governance (Art. 10)](/en/academy/ai-act-provider/module-3/) **Next:** [Module 5 — Logging, instructions, oversight by design →](/en/academy/ai-act-provider/module-5/) -------------------------------------------------------------------------------- ## Module 5 — Logging, Instructions and Oversight by Design (Art. 12-14) URL: https://www.regulation-ai.eu/en/academy/ai-act-provider/module-5/ These three articles are where the provider's obligations meet the deployer's. Everything a deployer owes under Art. 26 depends on what you built and what you told them. A deployer who cannot keep logs because the system does not produce them, or cannot oversee because the interface exposes nothing, has a problem that originates in your product. ## Art. 12 — automatic record-keeping High-risk systems shall **technically allow for the automatic recording of events (logs) over the lifetime of the system**. The logging capability must provide for the recording of events relevant for: - identifying situations that may result in the system **presenting a risk** within the meaning of Art. 79(1), or in a **substantial modification**; - facilitating the **post-market monitoring** referred to in Art. 72; - monitoring the operation of high-risk systems by deployers as referred to in **Art. 26(5)**. Three design consequences. **Logging is a product requirement, not an operations concern.** It is in Chapter III Section 2 alongside accuracy and cybersecurity. A system that cannot produce these records is non-conforming, and the defect is not curable by the deployer's infrastructure. **"Over the lifetime of the system"** means the capability persists, not that you retain forever. Retention is the deployer's Art. 26(6) duty — at least six months, to the extent the logs are under their control. If you host, control is yours in fact, which makes an export capability a contractual and practical necessity. **Substantial modification is a logged event class.** Design the records so that a change affecting Chapter III compliance is visible in them, because that is what Art. 12 asks the logs to help identify. For **Annex III point 1** systems, Art. 12(3) sets a minimum: the period of each use (start and end date and time); the reference database against which input data has been checked; the input data for which the search led to a match; and the identification of the natural persons involved in the verification of the results under Art. 14(5). ## Art. 13 — transparency to deployers, and the instructions for use High-risk systems shall be designed and developed so their operation is **sufficiently transparent to enable deployers to interpret the output and use it appropriately**, and shall be accompanied by **instructions for use**. The instructions must contain, among other things: - the **identity and contact details** of the provider and its authorised representative; - the **characteristics, capabilities and limitations of performance**, including its intended purpose; the level of accuracy, including its metrics, robustness and cybersecurity against which it has been tested and validated; any known or foreseeable circumstance which may impact those; where appropriate, its performance regarding specific persons or groups on which it is intended to be used; and, where appropriate, specifications for the input data or other relevant information in terms of the training, validation and testing datasets used; - when appropriate, information to enable deployers to **interpret the output** and use it appropriately; - any **changes** to the system and its performance predetermined by the provider at the moment of the initial conformity assessment; - the **human oversight measures** referred to in Art. 14, including the technical measures put in place to facilitate the interpretation of outputs by deployers; - the **computational and hardware resources** needed, expected lifetime and necessary maintenance and care measures, including their frequency; - where relevant, a description of the mechanisms allowing deployers to properly **collect, store and interpret the logs**. That last bullet is the one that determines whether your customers can meet Art. 26(6). Three practical points. **Write it as a control.** Art. 9(5) makes information to deployers the third tier of risk management. Every residual risk you decided to manage by telling the deployer should be traceable to a passage here. **Declared performance is a commitment.** Whatever accuracy figure appears in the instructions is the figure your deployers will monitor against under Art. 26(4), and the figure a market surveillance authority will test against. State the conditions. **Predetermined changes must be declared up front.** A system designed to continue learning after deployment must have that behaviour and its bounds described at the initial conformity assessment — otherwise a later change looks like an undeclared substantial modification. ## Art. 14 — oversight has to be designed in High-risk systems shall be designed and developed, **including with appropriate human-machine interface tools**, such that they can be **effectively overseen** by natural persons during the period in which they are in use. The measures shall be **commensurate with the risks, level of autonomy and context of use**, and are ensured through either or both of: measures **identified and built into the system by the provider** before it is placed on the market; and measures **identified by the provider** before placing on the market and which are **appropriate to be implemented by the deployer**. Art. 14(4) then sets what oversight persons must be enabled to do — the checklist Module 3 of the Deployer track examines from the other side: - **understand the relevant capacities and limitations** of the system and duly monitor its operation, including to detect and address anomalies, dysfunctions and unexpected performance; - **remain aware of automation bias**, in particular for systems providing information or recommendations for decisions to be taken by natural persons; - **correctly interpret the output**, taking into account the interpretation tools and methods available; - **decide not to use the system, or otherwise disregard, override or reverse the output**; - **intervene in the operation or interrupt the system** through a stop button or similar procedure allowing it to halt in a safe state. For **Annex III point 1** systems, Art. 14(5) adds that no action or decision may be taken on the basis of the identification unless **separately verified and confirmed by at least two natural persons** with the necessary competence, training and authority — with narrow carve-outs for certain law enforcement, migration, border control and asylum contexts. ## Designing against automation bias The Regulation names automation bias as something oversight persons must remain aware of. As a provider you are the party who can design for or against it, and the design choices are not subtle: - **Surface uncertainty.** A bare verdict invites deference; a calibrated confidence changes behaviour. - **Make dissent cheap.** If accepting is one click and overriding is a form, your override rate goes to zero and your deployer fails Art. 26(2) using your product as intended. - **Expose the basis.** Element 3 of Annex IV and Art. 13 both ask about interpretation tools; they are the same capability seen from two articles. - **Instrument the override.** A system that reports its own override rate hands the deployer the single best evidence that oversight is live. It costs little and it differentiates the product. ## Check yourself 1. *Our customer's SIEM captures everything; do we need Art. 12 logging?* — **Yes.** Art. 12 is a product requirement in Chapter III Section 2; the deployer's telemetry is not a substitute and cannot make a non-conforming system conform. 2. *Our instructions are a sales datasheet plus an API reference.* — **Art. 13 requires the accuracy metrics, limitations, oversight measures and log-handling mechanisms.** Without them your deployers cannot satisfy Art. 26. 3. *Our system continuously learns after deployment.* — **Declare that behaviour and its bounds at the initial conformity assessment**, per Art. 13, or later change will read as an undeclared substantial modification. 4. *Oversight is the deployer's problem.* — **Art. 14 is a design duty on the provider.** If the interface exposes no override and no stop, the defect is yours. --- **Previous:** [Module 4 — Technical documentation (Art. 11 and Annex IV)](/en/academy/ai-act-provider/module-4/) **Next:** [Module 6 — Accuracy, robustness, cybersecurity, and the QMS →](/en/academy/ai-act-provider/module-6/) -------------------------------------------------------------------------------- ## Module 6 — Accuracy, Robustness, Cybersecurity and the Quality Management System URL: https://www.regulation-ai.eu/en/academy/ai-act-provider/module-6/ Article 15 is short and consequential: it is where a provider states what its system can do, and commits to it. Article 17 is what makes the rest repeatable rather than heroic. ## Art. 15 — the three properties High-risk systems shall be designed and developed so as to achieve an **appropriate level of accuracy, robustness and cybersecurity**, and to perform **consistently in those respects throughout their lifecycle**. **Appropriate** is relative to the intended purpose. The Regulation sets no numeric floor, which is the only workable choice across the range of Annex III. What it does instead is force declaration: the **levels of accuracy and the relevant accuracy metrics** shall be declared in the accompanying instructions for use. That declaration is load-bearing in three directions at once. It is what your deployers monitor against under Art. 26(4). It is what a market surveillance authority tests against. And it is what makes an unstated performance regression a compliance event rather than a product issue. State the conditions with the number. An accuracy figure without the population, the input distribution and the operating envelope it was measured on is not a declaration; it is a marketing claim that will be tested under conditions you did not intend. ## Robustness Systems shall be **as resilient as possible regarding errors, faults or inconsistencies** that may occur within the system or the environment in which it operates, in particular due to interaction with natural persons or other systems. Technical and organisational measures may include **backup or fail-safe plans**. Two things worth noting. "Interaction with natural persons" means the messy inputs real users produce, not the clean inputs your test harness produces. And **fail-safe** is named: a system that degrades into confident nonsense under out-of-distribution input is not robust in the sense the article means, however good its headline accuracy. Art. 15(4) also addresses systems that **continue to learn after being placed on the market or put into service**: they shall be developed to eliminate or reduce as far as possible the risk of **possibly biased outputs influencing input for future operations (feedback loops)**, and to ensure such loops are duly addressed with appropriate mitigation measures. This is the same concern Art. 10(2) raises for training data, seen at runtime. ## Cybersecurity, and why generic controls are not enough Systems shall be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting vulnerabilities. Art. 15(5) then names the AI-specific attack surface, and this is the paragraph that separates an AI Act security position from an ordinary one. The technical solutions shall be **appropriate to the relevant circumstances and the risks**, and shall include, as appropriate, measures to prevent, detect, respond to, resolve and control for: - **data poisoning** — manipulating the training dataset; - **model poisoning** — manipulating pre-trained components used in training; - **model evasion** — inputs designed to cause the model to make a mistake; - **confidentiality attacks** — extracting information about the model or its training data; - **model flaws** — defects in the model itself. A hardened CI/CD pipeline, SSO and network segmentation address none of these. They are necessary and they are not sufficient, and the file needs to show that the AI-specific surface was assessed separately. Practically: provenance and integrity controls on training data; verification of third-party pre-trained components and their supply chain; adversarial testing as part of the Art. 9 test plan; rate limiting and query monitoring against extraction; and monitoring for distribution shift that can indicate an attack rather than drift. ## Art. 17 — the quality management system Providers of high-risk systems shall put in place a quality management system ensuring compliance with the Regulation, **documented in a systematic and orderly manner in the form of written policies, procedures and instructions**. It shall include at least: - a **strategy for regulatory compliance**, including compliance with conformity assessment procedures and procedures for the management of modifications; - techniques, procedures and systematic actions for the **design, design control and design verification**; - techniques, procedures and systematic actions for **development, quality control and quality assurance**; - **examination, test and validation procedures** to be carried out before, during and after development, and their frequency; - **technical specifications, including standards**, to be applied and, where relevant harmonised standards are not applied in full, the means to ensure compliance; - systems and procedures for **data management**, including acquisition, collection, analysis, labelling, storage, filtration, mining, aggregation, retention and any other operation regarding data performed before and for the purpose of placing systems on the market; - the **risk management system** of Art. 9; - the setting-up, implementation and maintenance of a **post-market monitoring system** per Art. 72; - procedures related to the **reporting of serious incidents** per Art. 73; - the handling of **communication with competent authorities**, notified bodies, other operators, customers or other interested parties; - systems and procedures for **record keeping** of all relevant documentation and information; - **resource management**, including security-of-supply related measures; - an **accountability framework** setting out the responsibilities of management and other staff. The list reads as a table of contents for everything in this track, which is the point: Art. 17 is the container that keeps Art. 9 to Art. 15 running when the people who built the system move on. Art. 17(2) allows implementation proportionate to the size of the provider's organisation, while preserving the degree of rigour and level of protection required. And providers already subject to quality management obligations under sectoral Union law may integrate these elements into those existing systems — the same permission Art. 9(10) gives for risk management. ## What a reviewer looks for first In practice, three checks separate a real QMS from a documented one: **The modification procedure.** Art. 17's first element names the management of modifications. Show a change that went through it, and what the assessment concluded about substantial modification. **The test procedures and their frequency.** A stated cadence, and evidence it was followed. **The accountability framework.** Named roles, with authority, not a RACI diagram nobody uses. ## Check yourself 1. *We report 94% accuracy.* — **Under what conditions, on which population, against which metric?** Art. 15(3) requires the levels and the metrics declared in the instructions, and the declaration is what you are held to. 2. *Our security programme is ISO 27001 certified, so Art. 15(5) is covered.* — **It is not.** Data poisoning, model poisoning, model evasion and confidentiality attacks are AI-specific and need to be assessed and addressed as such. 3. *Our model retrains continuously on production data.* — **Art. 15(4) requires the feedback-loop risk to be eliminated or reduced as far as possible and duly addressed**, and Art. 13 requires predetermined changes to be declared at the initial conformity assessment. 4. *Do we need a new management system for Art. 17?* — **No, if an existing one genuinely hosts the listed elements.** What is assessed is the presence and documentation of the elements, not the certificate. --- **Previous:** [Module 5 — Logging, instructions and oversight by design](/en/academy/ai-act-provider/module-5/) **Next:** [Module 7 — Conformity, declaration, marking, registration →](/en/academy/ai-act-provider/module-7/) -------------------------------------------------------------------------------- ## Module 7 — Conformity Assessment, Declaration, CE Marking, Registration URL: https://www.regulation-ai.eu/en/academy/ai-act-provider/module-7/ This module covers the sequence that turns a compliant system into a lawfully marketable one, and the order matters: assessment, then declaration, then marking, then registration, then market. ## Art. 43 — which route The choice is set by the annex the system falls under and, within Annex III, by which point. **Annex III, points 2 to 8.** Conformity assessment based on **internal control (Annex VI)**. The provider verifies that its quality management system complies with Art. 17, examines the technical documentation, and verifies consistency between the design and development process and the system as built. No notified body. **Annex III, point 1 — biometrics.** Where the provider has applied harmonised standards or, where applicable, common specifications, it may use Annex VI. Where it has **not** applied them, or where they do not exist, the route is **Annex VII — assessment of the quality management system and of the technical documentation by a notified body**. **Annex I products.** The AI Act conformity assessment is carried out **as part of the conformity assessment procedure required under the relevant sectoral legislation**. If that legislation requires third-party assessment, the notified body designated under it also assesses the AI Act requirements. There is no separate parallel AI Act procedure. The single most common planning error here is budgeting for a notified body on an Annex III point 4 employment system. It does not need one. ## Reassessment A high-risk system that has undergone a conformity assessment shall undergo a **new** conformity assessment **whenever it is substantially modified**, regardless of whether the modified system is intended to be further distributed or continues to be used by the current deployer. For systems that **continue to learn after being placed on the market**, changes to the system and its performance that have been **pre-determined by the provider at the moment of the initial conformity assessment** and are part of the information in the technical documentation are **not** a substantial modification. This is why Module 5 insisted that continuous-learning behaviour and its bounds be declared up front: declaring them is what keeps ordinary model updates out of the reassessment cycle. ## Art. 47 — the EU declaration of conformity The provider shall draw up a **written machine-readable, physical or electronically signed** EU declaration of conformity for each high-risk system, and keep it at the disposal of national competent authorities for **ten years** after the system has been placed on the market or put into service. It shall identify the system for which it has been drawn up. The declaration shall state that the high-risk system **meets the requirements set out in Chapter III Section 2**, contain the information set out in Annex V, and be translated into a language that can be easily understood by the national competent authorities of the Member States in which the system is placed on the market or made available. Where a system is subject to **other Union harmonisation legislation** also requiring a declaration of conformity, a **single** declaration shall be drawn up in respect of all applicable acts — one document, all regimes. And the sentence that matters most: **by drawing up the declaration, the provider assumes responsibility for compliance**. It is a signature, not a formality, and the natural person who signs should understand what the technical documentation does and does not demonstrate. ## Art. 48 — CE marking The CE marking is subject to the general principles of Regulation (EU) 765/2008. It shall be affixed **visibly, legibly and indelibly** for high-risk AI systems; where that is not possible or warranted given the nature of the system, it shall be affixed to the **packaging or the accompanying documentation**. For **digital** high-risk systems, a digital CE marking shall be used only if it can be **easily accessed via the interface** from which the system is accessed, or via an easily accessible machine-readable code or other electronic means. Where applicable, the CE marking shall be followed by the **identification number of the notified body** responsible for the conformity assessment procedures — and that number shall also be indicated in any promotional material stating that the system fulfils the CE marking requirements. Two points that cause trouble. A **software** high-risk system still bears a CE marking; there is no exemption for the absence of a physical object. And the marking must not be affixed before the assessment and the declaration are complete, which is why the sequence in this module runs the way it does. ## Art. 49 — registration in the EU database Before placing on the market or putting into service an Annex III high-risk system, the **provider** or, where applicable, the authorised representative shall **register themselves and their system** in the EU database referred to in Art. 71. Providers that have concluded, under **Art. 6(3)**, that their Annex III system is **not** high-risk shall register themselves and that system under **Art. 49(2)**. The derogation removes obligations; it does not remove you from the database. Before putting into service or using a high-risk system listed in Annex III, deployers that are **public authorities, Union institutions, bodies, offices or agencies**, or persons acting on their behalf, shall register themselves, select the system and register its use. The database is **publicly accessible**, with the exception of systems in the law enforcement, migration, asylum and border control areas, whose registration sits in a secure non-public section accessible to the Commission and to national authorities. The public nature of the database is a strategic fact, not a filing detail: your registration is visible to your customers, your competitors and to anyone doing vendor due diligence — including deployers who have been taught to ask for your Art. 49 reference. ## The order, and the dates 1. Complete the technical documentation (Art. 11) — before market placement. 2. Run the conformity assessment (Art. 43) against it. 3. Draw up and sign the EU declaration of conformity (Art. 47). 4. Affix the CE marking (Art. 48). 5. Register in the EU database (Art. 49). 6. Place on the market or put into service. 7. Keep everything for ten years (Art. 18), and monitor (Art. 72). Those obligations apply to standalone Annex III systems from **2 December 2027**, and to AI embedded in Annex I regulated products from **2 August 2028**, following the Digital Omnibus deferrals. ## Check yourself 1. *We need a notified body for our recruitment screening system.* — **Almost certainly not.** Annex III point 4 uses Annex VI internal control; the notified body route applies to point 1 biometrics in defined circumstances and to Annex I products via sectoral law. 2. *Our system is software only, so CE marking does not apply.* — **It does.** Where physical affixing is not possible, the marking goes on packaging or accompanying documentation, and a digital marking must be easily accessible from the interface. 3. *We rely on Art. 6(3), so we are not in the database.* — **Art. 49(2) requires registration precisely in that case.** 4. *Our model updates weekly. Does each update need a new conformity assessment?* — **Not if the changes were pre-determined at the initial assessment and are described in the technical documentation.** Otherwise a substantial modification triggers reassessment. --- **Previous:** [Module 6 — Accuracy, robustness, cybersecurity, and the QMS](/en/academy/ai-act-provider/module-6/) **Next:** [Module 8 — After the market: monitoring and incidents →](/en/academy/ai-act-provider/module-8/) -------------------------------------------------------------------------------- ## Module 8 — After the Market: Post-Market Monitoring and Serious Incidents URL: https://www.regulation-ai.eu/en/academy/ai-act-provider/module-8/ The obligations do not end at market placement; in an important sense they begin there. Art. 9 requires the risk management system to take an input from post-market data, which means the loop only closes when the system is retired. ## Art. 72 — the post-market monitoring system Providers shall establish and document a post-market monitoring system **proportionate to the nature of the AI technologies and the risks** of the high-risk system. The system shall **actively and systematically collect, document and analyse relevant data**, which may be provided by deployers or collected through other sources, on the **performance of high-risk AI systems throughout their lifetime**, and shall allow the provider to **evaluate the continuous compliance** of systems with the Chapter III Section 2 requirements. Where relevant, post-market monitoring shall include an analysis of the **interaction with other AI systems**. The system shall be based on a **post-market monitoring plan**, which forms **part of the technical documentation referred to in Annex IV** — element 9. It is therefore not an operational document produced later; it is written before the system goes to market and assessed with the rest of the file. Three design questions decide whether the plan is real: **Where does the data come from?** Deployers hold the operational signal. Getting it requires a contractual route and a practical channel, and neither appears by itself. This is the mirror image of the deployer's Art. 26(5) duty to inform you. **What is compared against what?** The plan should name the declared performance from the Art. 13 instructions as the baseline, and describe what deviation looks like. Monitoring without a stated baseline generates data and no conclusions. **What triggers what?** Deviation thresholds should map to actions: investigate, notify, correct under Art. 20, or reassess conformity. A plan with no trigger table is a promise to look. ## Art. 73 — serious incident reporting Providers of high-risk systems placed on the Union market shall report any **serious incident** to the market surveillance authorities of the Member States where that incident occurred. **What is a serious incident.** Defined by consequence: an incident or malfunctioning of an AI system that directly or indirectly leads to the death of a person or serious harm to a person's health; a serious and irreversible disruption of the management or operation of critical infrastructure; the infringement of obligations under Union law intended to protect fundamental rights; or serious harm to property or the environment. Note the third limb. An incident need involve no physical harm at all — a systematic infringement of a fundamental-rights protection is a serious incident, which puts discriminatory output squarely inside the reporting regime. **Deadlines.** The report shall be made **immediately after the provider has established a causal link between the AI system and the serious incident, or the reasonable likelihood of such a link**, and in any event **not later than 15 days** after the provider — or, where applicable, the deployer — becomes aware of the serious incident. Shorter periods apply to the gravest categories: in the event of a **widespread infringement or a serious and irreversible disruption of critical infrastructure**, and in the event of the **death of a person**, the report is required considerably sooner. Where the causal link has not yet been established, the provider still reports within the applicable deadline — an initial report is not deferred pending investigation. **After reporting.** Following the report of a serious incident, the provider shall **without delay perform the necessary investigations**, including a risk assessment of the incident and corrective action. It shall cooperate with the competent authorities and, where relevant, with the notified body, and shall not perform any investigation which involves altering the system in a way which may affect any subsequent evaluation of the causes before informing the authorities. That last constraint catches engineering teams by reflex: the instinct on discovering a defect is to fix it immediately, and here fixing it first can destroy the evidence the authority needs. **Where the deployer sees it first.** The deployer's Art. 26(5) duty — suspend, inform the provider or distributor and the market surveillance authority — is in practice what starts your clock. A provider with no channel for that information will miss deadlines it never knew were running. ## Art. 20 — corrective action Providers who consider or have reason to consider that a high-risk system they have placed on the market or put into service is **not in conformity** shall immediately take the necessary corrective actions to **bring it into conformity, withdraw it, disable it or recall it**, as appropriate, and shall inform the **distributors** of the system concerned and, where applicable, the **deployers, the authorised representative and importers** accordingly. Where the system presents a risk within the meaning of Art. 79(1) and the provider becomes aware of it, it shall **immediately investigate the causes**, in collaboration with the reporting deployer where applicable, and **inform the market surveillance authorities** and, where applicable, the notified body, of the nature of the non-compliance and of any relevant corrective action taken. The threshold is "considers or has reason to consider", the same low bar the deployer works to under Art. 26(5). Waiting for certainty is not the standard. ## Substantial modification reopens the file When post-market monitoring produces a change, ask immediately whether the change is a **substantial modification**: a change not foreseen or planned in the initial conformity assessment which affects compliance with the Chapter III Section 2 requirements, or which results in a modification to the intended purpose. If it is, Art. 43 requires a **new conformity assessment**, and the consequences cascade: an updated Annex IV file, a new declaration of conformity, a database update, and — if the system's classification itself changed — potentially a different assessment route. If the change was **pre-determined at the initial conformity assessment and documented in the technical documentation**, it is not a substantial modification. That is the entire commercial argument for declaring your update and continuous-learning behaviour up front, and it is worth engineering effort to keep as much routine change as possible inside the declared envelope. ## The loop, stated once Art. 9 identifies risks and requires review over the lifecycle. Art. 72 collects the field data that Art. 9(2)(c) feeds on. Art. 73 escalates the worst of it to authorities. Art. 20 acts on non-conformity. Art. 43 reassesses when the response amounts to a substantial modification. Art. 11 keeps the file current throughout, and Art. 18 holds it for ten years. A provider organisation that treats those as six separate obligations owned by six teams will discover the gaps between them at the worst moment. A provider that treats them as one loop with named owners at each handover will not. ## Check yourself 1. *We will build the post-market monitoring plan after launch.* — **It is element 9 of Annex IV** and is assessed with the technical documentation, so it exists before market placement. 2. *No one was physically harmed, so it is not a serious incident.* — **The definition includes infringement of Union law obligations intended to protect fundamental rights.** Discriminatory output can qualify. 3. *We found the defect and patched it, then reported.* — **Art. 73 prohibits investigation that alters the system in a way that may affect subsequent evaluation of the causes before informing the authorities.** 4. *Our weekly model refresh triggers reassessment every week.* — **Not if the change was pre-determined at the initial conformity assessment and documented in the technical documentation.** --- **Previous:** [Module 7 — Conformity, declaration, marking, registration](/en/academy/ai-act-provider/module-7/) You have completed the eight modules. Together they cover Chapter III from the seat of the organisation that builds and places the system — [sit the Provider examination →](/en/academy/ai-act-provider/exam/) -------------------------------------------------------------------------------- ## EU AI Act Certification — How to Get Certified in AI Compliance URL: https://www.regulation-ai.eu/en/academy/certification/ ## EU AI Act certification: what the regulation actually requires The EU AI Act does not create a single mandatory certification exam. What it does create is a legal obligation for **AI literacy** — and that obligation has teeth. **Art. 4 — AI literacy (applies now, rewritten July 2026):** > *"Providers and deployers of AI systems shall take measures to support the development of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf, taking into account their technical knowledge, experience, education and training and the context the AI systems are to be used in, and considering the persons or groups of persons on whom the AI systems are to be used. This obligation does not require providers or deployers to guarantee any specific level of AI literacy of any individual."* > > — Article 4(1), as replaced by Regulation (EU) 2026/1744 (Digital Omnibus on AI), in force since 27 July 2026 Before the Omnibus, Article 4 asked organisations to *ensure, to their best extent, a sufficient level* of AI literacy. That was a duty of result. What replaced it is a duty of means, and the closing sentence says so explicitly. Two consequences, and both matter when you are shopping for a certification: 1. The obligation binds the **organisation**, not the individual. No course, ours included, discharges it for you. 2. What you owe is **measures**, and what an authority can ask to see is the record of them. Training is a measure. A dated, nominative certificate is the record of one. So a certificate of completion is not compliance in itself. It is one AI literacy measure you can put in the file, alongside your AI inventory, your usage rules and your role-to-competence mapping. ## What makes a good EU AI Act certification? Not all courses are equal. The ones worth recording as an Art. 4 measure — the ones that still look serious when a regulator reads the file — should: - Map directly to EU AI Act articles (not generic "AI ethics" content) - Cover the specific obligations for your role (provider vs. deployer) - Issue per-module certificates that document specific competencies - Be produced by a specialist in the EU AI Act regulatory text The regulation-ai.eu Pro certification is built to meet these criteria. Every module maps to specific articles. Templates are pre-annotated with article references. ## The Pro certification programme **Module 6 — Risk assessment in practice (Art. 9)** How to build and maintain a risk management system: identifying foreseeable misuse scenarios, evaluating severity and probability, documenting mitigation measures, and maintaining the system iteratively throughout the AI lifecycle. **Module 7 — Technical documentation (Art. 11 + Annex IV)** What goes in the technical file: system description, design specifications, training methodology, performance metrics, risk management documentation, and the human oversight section. How to structure it for a notified body or market surveillance authority. **Module 8 — Human oversight design (Art. 14)** How to design and implement human oversight that satisfies Art. 14: identifying appropriate oversight persons, documenting oversight capacity, building in intervention mechanisms, and avoiding automation bias in high-stakes AI decisions. **Module 9 — Conformity assessment (Art. 43)** Self-assessment (Annex VI) vs. notified body assessment (Annex VII): when each applies, how to prepare for third-party review, what the EU Declaration of Conformity (Art. 47) must contain, and how to affix CE marking correctly. **Module 10 — Post-market monitoring (Art. 72)** Building a post-market monitoring system: what data to collect, how often to review, when to report to market surveillance authorities, and how to handle post-deployment risks and serious incidents (Art. 73). **Included templates:** - **Risk Register (XLSX)** — 50+ pre-mapped AI risk scenarios, 5×5 risk matrix, mitigation tracking, review schedule aligned to Art. 9(4) - **Technical Documentation Template (XLSX)** — Annex IV section by section, pre-annotated with article references - **Data Governance Checklist (XLSX)** — Art. 10 obligations for training, validation, and testing data ## EU AI Act certification for financial entities If your organisation is subject to both DORA and the AI Act, the [DORA + AI Act Bundle →](/academy/) extends the Pro certification with two additional modules on DORA ICT risk management and third-party AI vendor oversight. It includes a dual-regulation gap analysis template and an AI vendor contract checklist — the two documents most frequently requested by auditors and regulators in the financial sector. ## How certification intersects with conformity assessment Certification is about people. Conformity assessment (Art. 43) is about systems. Your staff may be fully certified — but your AI system still requires its own conformity assessment before it can be placed on the EU market. The two are complementary: - Staff certification → documents AI literacy obligations (Art. 4) and builds the competency to run the compliance programme - System conformity assessment → validates that the AI system meets Chapter III technical requirements and enables CE marking Use the [Conformity Assessment Selector →](/tools/conformity-selector/) to determine whether your high-risk AI system requires self-assessment or a notified body. → [Start the free Fundamentals course →](/academy/ai-act-fundamentals/) · [Get Pro certified →](/academy/) · [Corporate training →](/academy/corporate-training/) -------------------------------------------------------------------------------- ## EU AI Act Corporate Training — Executive, In-House & Team Programmes URL: https://www.regulation-ai.eu/en/academy/corporate-training/ ## Why your team needs structured EU AI Act training **The AI Act is already in force.** Prohibited practices have been banned since 2 February 2025. GPAI obligations apply since 2 August 2025. High-risk AI system obligations arrive 2 December 2027 — but a realistic compliance programme takes 12–24 months to implement. The organisations that start structured training in 2026 will be audit-ready in 2027. Those that start in late 2027 will not. **Art. 4 is not a formality.** The obligation binds the organisation and asks it to take measures supporting AI literacy — the Digital Omnibus softened the wording in July 2026, it did not remove the duty. In a regulatory inquiry or civil claim, what you are asked for is the record of what you actually did, and "we sent the team a link to the regulation" is thin. A structured, role-appropriate programme with a certificate per participant is one measure you can put in the file, dated and attributable. ## Three formats — from executive to practitioner ### Executive briefing (2 hours) For board members, C-suite, general counsel, and senior management who need to make strategic decisions without becoming technical experts. **What it covers:** - The AI Act in 20 minutes: scope, risk tiers, key deadlines, who is liable - Your AI inventory risk exposure: which systems trigger Annex III? What is your fine exposure? - The compliance decisions that need executive sign-off: QMS investment, notified body selection, budget allocation - DORA and NIS2 interactions for regulated entities - Q&A on your specific AI systems and strategic questions **Format:** On-site or virtual · 2 hours · slides + written briefing pack --- ### Practitioner workshop (full day — 8 hours) For compliance officers, DPOs, legal counsel, risk managers, and product team leads implementing the compliance programme. **What it covers:** **Morning: Understanding the obligations** - Risk classification in depth: Annex I, Annex III, Art. 6(3) exclusion, GPAI tier - Your AI inventory mapped to Annex III categories - Role separation: who is the provider, who is the deployer, what obligations apply to each - Prohibited practices: are any current systems already non-compliant? **Afternoon: Implementing the compliance programme** - Building the risk management system (Art. 9): live walkthrough of the Risk Register template - Technical documentation (Art. 11 + Annex IV): structure, content, what notified bodies check - Human oversight design (Art. 14): who is the responsible person, what oversight mechanisms are required - Conformity assessment: self-assessment vs. notified body, timeline, EU database registration - Post-market monitoring: what to track, incident reporting thresholds, serious incident procedure **Included:** Risk Register template, Technical Documentation template, Data Governance checklist (all XLSX, pre-mapped to Annex III). Certificate of completion per participant. **Format:** On-site or virtual · Full day · Workshop format with your AI systems as the case study --- ### Custom e-learning module (asynchronous) For organisations that need structured training available to all staff on demand, at scale. **What it covers:** A custom module mapped to your internal AI governance policy, your specific AI inventory, and your role taxonomy. Staff complete the module independently; results and certificates are tracked centrally. **Ideal for:** Large organisations (100+ staff), organisations with multiple locations, compliance programmes requiring documented completion rates. **Format:** Asynchronous · Custom content · Central tracking · Certificate per completion --- ## Who attends | Team | Recommended format | Core modules | |---|---|---| | Board / C-suite | Executive briefing | Strategic overview, liability, deadlines | | General counsel / Legal | Practitioner workshop | Obligations, prohibited practices, conformity | | Compliance / DPO | Practitioner workshop | Full programme | | Risk management | Practitioner workshop | Art. 9, Art. 14, post-market monitoring | | Product / engineering leads | Practitioner workshop | Technical requirements, documentation | | HR / Procurement | Executive briefing + targeted session | Deployer obligations, FRIA, contract requirements | | All staff using AI | Custom e-learning | Art. 4 AI literacy baseline | --- ## Sector-specific customisation EU AI Act obligations are not sector-neutral. We customise all programmes to your industry: **Financial services** — DORA overlap, credit scoring AI (Annex III — essential services), fraud detection, algorithmic trading, customer-facing AI obligations. Includes dual-regulation gap analysis for DORA + AI Act. **Healthcare and medical devices** — MDR/IVDR integration for Annex I high-risk AI, clinical AI risk assessment, data governance for health data, notified body coordination. **HR and recruitment** — Employment AI (Annex III, Art. 6(2)(d)), bias testing requirements, FRIA (Art. 27), candidate transparency obligations, right to explanation. **Critical infrastructure** — Annex III category mapping, national competent authority requirements, incident reporting, resilience testing. --- ## Start with the online courses Before booking a corporate programme, your team can begin with the free Fundamentals course to build a common knowledge baseline: - **[AI Act Fundamentals (free) →](/academy/ai-act-fundamentals/)** — 5 modules, 3 hours, Art. 4 certificate - **[Pro Certification (€299) →](/academy/)** — 8 modules, practitioner templates, monthly Q&A - **[DORA + AI Act Bundle (€499) →](/academy/)** — for financial entities subject to both regulations --- ## Request a corporate training programme For custom programmes, team licensing, or to discuss your specific AI inventory and compliance requirements, use the contact form below. We respond within 48 hours. Request corporate training Tell us your sector, team size, and AI systems — we'll propose the right programme format. Request information → We respond within 48 hours. No spam. -------------------------------------------------------------------------------- ## EU AI Act: Complete Compliance Guide (2025–2028) URL: https://www.regulation-ai.eu/en/ai-act/ ## What is the EU AI Act? The EU AI Act (Regulation (EU) 2024/1689) is the world's first comprehensive horizontal legal framework for artificial intelligence. It entered into force on 1 August 2024 and applies progressively across four risk tiers. The Act uses a risk-based approach: the higher the potential harm, the stricter the obligations. It does not govern all software — only systems that qualify as AI under the definition in Art. 3(1) and Annex I, which covers machine learning, logic- and knowledge-based approaches, and statistical models. The text in force today is Regulation (EU) 2024/1689 **as amended by Regulation (EU) 2026/1744**, the Digital Omnibus on AI. That amendment moved four application dates and changed nothing else — the [record of every change](/en/changes/) sets out which, and what each article now stands at. ## Who must comply? The AI Act applies to four categories of actors: - **Providers** — organisations that develop AI systems or general-purpose AI models and place them on the EU market or put them into service in the EU - **Deployers** — organisations or individuals that use AI systems under their own authority in a professional context - **Importers** — entities established in the EU that import AI systems from third countries - **Distributors** — entities in the supply chain other than providers and importers **Geographic reach:** the Act applies whenever the AI system's output is used in the EU, regardless of the provider's location. A US-based provider whose AI is used by European companies is in scope. ## The four risk tiers | Risk tier | Scope | Key rule | |---|---|---| | **Unacceptable risk** | Manipulative AI, social scoring, real-time biometric ID, emotion recognition at work | **Prohibited** — Art. 5 | | **High risk** | Annex III (standalone) and Annex I (embedded in regulated products) | Conformity assessment, QMS, CE marking, registration | | **Limited risk** | Chatbots, deepfakes, AI-generated content | Transparency obligations — users must know | | **Minimal risk** | Spam filters, AI in video games, recommendation systems | No mandatory obligations | ## Application timeline | Obligation | Applies from | |---|---| | Prohibited practices (Art. 5) | **2 February 2025** | | GPAI rules — Chapter 5 | **2 August 2025** | | Codes of practice for GPAI | **2 August 2025** | | High-risk AI — Annex III standalone | **2 December 2027** (extended by 2026 omnibus) | | High-risk AI — Annex I embedded | **2 August 2028** (extended by 2026 omnibus) | The 2026 Digital Omnibus on AI extended the two high-risk AI deadlines by 16 and 24 months respectively, without changing the obligations themselves. ## High-risk AI systems: what triggers full obligations? An AI system is high-risk under Annex III if it falls into one of these eight areas: 1. Biometric identification and categorisation 2. Critical infrastructure management (energy, water, transport) 3. Education and vocational training (access decisions, grading) 4. Employment — recruitment, performance assessment, promotion decisions 5. Essential private and public services (credit scoring, insurance, emergency services) 6. Law enforcement (risk assessment, evidence evaluation) 7. Migration, asylum, border control 8. Administration of justice and democratic processes An additional filter applies (Art. 6(3)): Annex III systems must pose a significant risk of harm to health, safety, or fundamental rights. Low-risk AI tools in these sectors may be exempt. ## Key compliance obligations for high-risk AI providers 1. **Risk management system** (Art. 9) — continuous process throughout the lifecycle 2. **Data governance** (Art. 10) — training, validation, and testing datasets must be appropriate 3. **Technical documentation** (Art. 11 + Annex IV) — before placing on market 4. **Transparency and logging** (Art. 12–13) — automatic logging, user instructions 5. **Human oversight** (Art. 14) — measures enabling humans to monitor and intervene 6. **Accuracy, robustness, cybersecurity** (Art. 15) 7. **Quality management system** (Art. 17) 8. **Conformity assessment** (Art. 43) — third-party for some categories 9. **EU database registration** (Art. 71) 10. **CE marking** (Art. 48) before placing on market ## Convergence with DORA and NIS2 Financial institutions face overlapping obligations across AI Act, DORA, and NIS2. The AI Act's risk management system (Art. 9) maps closely to DORA's ICT risk management framework (Art. 5–16). Dual-mapping documentation reduces compliance burden. See our [convergence analysis →](/ai-act-vs-dora-vs-nis2/). -------------------------------------------------------------------------------- ## AI Act vs DORA vs NIS2: Compliance Convergence for Financial Organisations URL: https://www.regulation-ai.eu/en/ai-act-vs-dora-vs-nis2/ ## Three regulations, one compliance programme Financial organisations in the EU face AI Act, DORA, and NIS2 — three regulations that were designed independently but overlap substantially in the context of AI systems used in financial services. Managing them separately creates duplicative documentation, inconsistent governance, and unnecessary cost. This guide maps the overlaps and shows where a single compliance effort can satisfy multiple regulations simultaneously. ## Timeline comparison | Regulation | Key deadline | Status | |---|---|---| | NIS2 | October 2024 | **In force** | | DORA | 17 January 2025 | **In force** | | AI Act — Prohibited practices | 2 February 2025 | **In force** | | AI Act — GPAI rules | 2 August 2025 | **In force** | | AI Act — Annex III standalone | 2 December 2027 | Upcoming | | AI Act — Annex I embedded | 2 August 2028 | Upcoming | ## Where AI Act and DORA overlap ### Risk management **AI Act Art. 9** requires a risk management system for high-risk AI covering identification, estimation, evaluation, and mitigation of risks throughout the lifecycle. **DORA Art. 5–16** requires an ICT risk management framework covering identification, protection, detection, response, and recovery from ICT risks. **Overlap:** Both apply to AI systems used in financial services. A single risk register and governance process can satisfy both, provided it covers the AI-specific risks required by Art. 9 (accuracy, robustness, bias, fundamental rights) in addition to DORA's ICT risk categories (availability, confidentiality, integrity, authentication). **Dual-mapping approach:** Extend your DORA ICT risk register to include AI-specific risk dimensions. Document the combined assessment as meeting both Art. 9 and DORA Art. 5–16 requirements. ### Incident reporting **AI Act Art. 73** requires providers of high-risk AI to report serious incidents to market surveillance authorities without undue delay. **DORA Art. 19–23** requires financial entities to report major ICT-related incidents to competent authorities within strict timelines (initial: 4 hours; intermediate: 72 hours; final: 1 month). **Overlap:** An ICT incident caused by or involving a high-risk AI system may trigger both reporting obligations simultaneously. Build a single incident response procedure that assesses both thresholds and routes to both regulators where required. ### Third-party and supply chain **AI Act** imposes obligations on providers who develop AI. Deployers who procure high-risk AI systems from providers must verify provider compliance. **DORA Art. 28–44** requires financial entities to manage ICT third-party risk, including for AI providers and cloud services running AI systems. **Overlap:** Procurement due diligence for AI systems used by financial entities must satisfy both: DORA's ICT third-party risk assessment and contractual requirements, AND verification of AI Act conformity assessment and CE marking. **Practical tip:** Add AI Act compliance verification to your DORA ICT third-party due diligence checklist. Require AI providers to supply their conformity assessment documentation and EU database registration number. ## Where AI Act and NIS2 overlap NIS2 applies broadly to essential and important entities including financial institutions, energy providers, health organisations, and digital infrastructure operators. **NIS2 Art. 21** security measures apply to all ICT — including AI systems. Risk-based security measures, supply chain security, and business continuity planning all apply to AI as ICT components. **NIS2 Art. 23** incident reporting (24-hour early warning, 72-hour notification, 1-month final report) applies to significant incidents, including those involving AI systems. **Integration opportunity:** NIS2 security measures and AI Act Art. 15 (accuracy, robustness, cybersecurity) for high-risk AI can be addressed through the same information security management system (ISMS) and cybersecurity programme. ## Recommended dual-mapping framework 1. **Single AI inventory** — catalogue all AI systems, mapping each to AI Act risk tier AND DORA/NIS2 applicability 2. **Combined risk register** — extend ICT risk register to include AI-specific dimensions (bias, opacity, fundamental rights impact) 3. **Unified incident response** — single procedure with dual-threshold assessment for AI Act + DORA/NIS2 reporting 4. **Shared third-party template** — DORA ICT due diligence + AI Act conformity verification in one supplier questionnaire 5. **Joint QMS** — design the AI Act quality management system (Art. 17) as an extension of the DORA governance framework, not a separate silo For DORA-specific guidance, see our sister site [regulation-dora.eu](https://www.regulation-dora.eu) — covering DORA's full ICT risk management, incident reporting, and third-party frameworks in depth. -------------------------------------------------------------------------------- ## EU AI Act vs GDPR: How the Two Regulations Interact URL: https://www.regulation-ai.eu/en/ai-act-vs-gdpr/ ## Different objects, overlapping scope The clearest way to hold the two apart is to remember what each one regulates. - The **GDPR** regulates the **processing of personal data**. Its trigger is personal data, whatever technology touches it. - The **AI Act** regulates **AI systems placed on the EU market or put into service**. Its trigger is the system and its intended purpose, whether or not personal data is involved. An AI system that forecasts machine failure from sensor readings is in scope of the AI Act and outside the GDPR. A spreadsheet of customer records is in scope of the GDPR and outside the AI Act. A CV-screening tool is squarely in both. The AI Act does not carve anything out of the GDPR. Where both apply, they apply cumulatively. ## Side by side | | **GDPR** | **EU AI Act** | |---|---|---| | Legal nature | Fundamental-rights instrument | Product-safety instrument | | Trigger | Processing of personal data | Placing on the market / putting into service an AI system | | Central roles | Controller, processor | Provider, deployer, importer, distributor | | Risk logic | Risk to data subjects, assessed case by case | Fixed categories: prohibited, high-risk, transparency, minimal | | Key assessment | DPIA (Art. 35) | Conformity assessment; FRIA (Art. 27) for certain deployers | | Documentation | Records of processing (Art. 30) | Technical documentation (Annex IV), logs (Art. 12) | | Transparency | Information duties (Art. 13–14) | Disclosure duties (Art. 50); instructions for use (Art. 13) | | Human element | Right not to be subject to solely automated decisions (Art. 22) | Human oversight designed into the system (Art. 14) | | Maximum fine | €20M or 4% of worldwide turnover | €35M or 7% ([penalties](../penalties/)) | | Enforcer | Data protection authorities | Market surveillance authorities; AI Office for GPAI | ## Where the roles do not line up Controller/processor and provider/deployer are **not** parallel concepts, and mapping one onto the other is a frequent source of error. A vendor that builds and sells a recruitment-screening tool is the **provider** under the AI Act. If the tool runs on the customer's data under the customer's instructions, that same vendor is likely a **processor** under the GDPR. The customer is the **deployer** under the AI Act and the **controller** under the GDPR. The two axes move independently. Under [Article 25](../articles/article-25/), a deployer that substantially modifies a system or puts it on the market under its own name becomes a **provider** — with no change whatsoever to its GDPR role. See [providers vs deployers](../providers-vs-deployers/). ## Automated decisions: Article 22 GDPR and Article 14 AI Act These are often treated as the same requirement. They are not. **GDPR Article 22** gives the data subject a right not to be subject to a decision based solely on automated processing which produces legal or similarly significant effects, subject to exceptions, with safeguards including the right to obtain human intervention. It is a right held by an individual, exercised after the fact. **AI Act Article 14** requires that high-risk systems be **designed and developed** so that human oversight is effective while in use. It is a design and operating obligation on the provider and deployer, owed before anything goes wrong. You can satisfy Article 22 with a review process bolted on afterwards. You cannot satisfy Article 14 that way — the oversight capability has to be built into the system and staffed by someone competent to exercise it, which is where [AI literacy](../ai-literacy/) becomes load-bearing. ## DPIA and FRIA Article 27 requires certain deployers of Annex III high-risk systems — bodies governed by public law, private entities providing public services, and deployers of creditworthiness and life/health insurance pricing systems — to carry out a **fundamental rights impact assessment** before first use. The scopes differ: - A **DPIA** examines risks to the rights and freedoms of natural persons arising from **data processing**. - A **FRIA** examines the deployment context: the categories of people affected, the specific risks of harm to them, human oversight measures, and the governance arrangements if risks materialise. Article 27 explicitly says the FRIA complements the DPIA and that the assessment may build on it where one has already been carried out. In practice the efficient path is a single combined exercise with two clearly labelled outputs — not a DPIA relabelled. ## Data governance pulls in both directions Article 10 requires training, validation and testing data for high-risk systems to be relevant, sufficiently representative and, as far as possible, free of errors. Achieving representativeness can require processing more data, and sometimes special-category data, to detect and correct bias. The Regulation anticipates the tension: Article 10(5) permits processing of special categories of personal data **strictly for the purpose of bias detection and correction** in high-risk systems, subject to safeguards including technical limits on re-use, pseudonymisation where possible, and deletion once the bias has been corrected. This is a narrow, purpose-bound gateway — not a general licence. ## Practical sequencing 1. **Inventory once, classify twice.** One register of systems, assessed against the GDPR (is personal data processed?) and against [Article 6](../high-risk/) (is it high-risk?). 2. **Map both role pairs per system.** Controller/processor *and* provider/deployer. Record them separately. 3. **Combine the assessments, keep the outputs distinct.** One workshop, one evidence pack, two documented conclusions. 4. **Reuse the GDPR machinery you already have.** Records of processing, retention schedules, vendor due diligence and incident response all extend to AI Act duties with modest adaptation. 5. **Do not assume GDPR maturity equals AI Act readiness.** Technical documentation under Annex IV, logging under Article 12, accuracy and robustness under Article 15 and conformity assessment have no GDPR equivalent at all. For the convergence picture across the wider EU regulatory stack, see [AI Act vs DORA vs NIS2](../ai-act-vs-dora-vs-nis2/). -------------------------------------------------------------------------------- ## AI Governance: Framework, Policy and Certification Under the EU AI Act URL: https://www.regulation-ai.eu/en/ai-governance/ ## What AI Governance Means in Practice AI governance is the layer between a regulation and the people who have to comply with it. The EU AI Act never uses the phrase as a defined term, yet almost everything it requires assumes one exists: a risk management system that runs across the lifecycle (Article 9), a quality management system for providers of high-risk systems (Article 17), competent human oversight assigned by name (Article 26), logs kept and retrievable (Article 12), post-market monitoring that feeds back into the design (Article 72), and staff who understand what they are operating (Article 4). None of that is a document. All of it is a routine somebody owns. The practical test is simple. If a supervisory authority asked today which AI systems your organisation uses, which risk tier each falls into, who approved them and on what evidence — could you answer in a week? Organisations that can have AI governance. Organisations that cannot have an AI policy. ## The Nine Components, and the Articles That Require Them | # | Component | What it produces | AI Act basis | |---|---|---|---| | 1 | **Inventory** | A list of every AI system in use or development, with owner and vendor | Precondition for Art. 6 classification | | 2 | **Role determination** | Provider / deployer / importer / distributor, per system | Art. 3, Art. 25 | | 3 | **Risk classification** | Prohibited, Annex I, Annex III, GPAI, transparency-only, minimal | Art. 5, Art. 6, Annex I, Annex III | | 4 | **Risk management system** | Identified risks, mitigations, residual risk accepted by a named person | Art. 9 | | 5 | **Data governance** | Provenance, representativeness, bias examination for training data | Art. 10 | | 6 | **Technical documentation** | The Annex IV file, kept current for ten years after placing on the market | Art. 11, Annex IV | | 7 | **Human oversight design** | Who can intervene, how, and with what authority to stop the system | Art. 14, Art. 26 | | 8 | **Transparency and disclosure** | Where users are told they are dealing with AI or synthetic content | Art. 50 | | 9 | **Monitoring and incident reporting** | Post-market plan, logs, serious-incident route to the authority | Art. 72, Art. 73 | Read in order, those nine are a build sequence rather than a checklist. Each one depends on the one above it: you cannot design oversight for a system you have not classified, and you cannot classify a system that is not on a list. Our [AI risk classifier](/tools/ai-risk-classifier/) does step 3 in three or four questions, and the [compliance checklist](/compliance-checklist/) walks the rest. ## What an AI Policy Has to Say A policy is component zero: the written statement that the other nine exist and who owns them. The ones that survive contact with a regulator share a shape. **Scope.** Which entities, which systems, which geographies. State explicitly whether tools bought as part of a SaaS product count — they do, and omitting them is how shadow AI gets written out of the inventory. **Roles.** Name the accountable executive. Name the approver for new systems. Name who may declare a system out of scope, and require them to record why. **Prohibited uses.** Not a general exhortation but the eight practices of [Article 5](/articles/article-5/), written as rules your staff can apply: no emotion inference in the workplace, no social scoring of customers, no scraping faces to build a recognition database. **Disclosure.** Where [Article 50](/transparency-obligations/) bites — chatbots, synthetic media, deepfakes, emotion recognition — and who writes the wording. **Procurement.** What a vendor must hand over before a system is approved: intended purpose, instructions for use, accuracy metrics, the logging interface, and the contractual commitment to support your Article 26 duties. **Training.** Which measure you rely on for [Article 4](/articles/article-4/), and how you record who completed it. Since the Digital Omnibus rewrote Article 4 in July 2026 this is an obligation of means — take measures — rather than a guarantee that every person reached a level. Measures still have to be evidenced. **Incidents.** Who decides that something is a serious incident under [Article 73](/articles/article-73/), and the clock that starts when they do. ## AI Governance Certification: What Actually Exists This is where the market is noisiest, so it is worth being precise. Three different things are sold under the word certification, and they certify three different objects. **A system can be certified.** High-risk AI systems go through conformity assessment under [Article 43](/conformity-assessment/), which for most Annex III systems is an internal control procedure and for some is third-party assessment by a notified body. The output is a CE marking and an EU declaration of conformity. This certifies a product, not a person and not a company. **An organisation can be certified.** ISO/IEC 42001 is the AI management system standard, and accredited certification bodies audit against it. It is voluntary, it is genuinely useful as the scaffold for the nine components above, and it is evidence of diligence. It is not a presumption of conformity with the AI Act: only harmonised standards published in the Official Journal under Article 40 carry that effect, and the first of those appeared in October 2026. **A person can hold a training certificate.** No EU body certifies individuals for the AI Act, and none has been designated to. What a training certificate can honestly evidence is that a named person completed structured training and passed an assessment on it — which is exactly the kind of record Article 4 expects you to keep. That last one is what we issue. The [AI Act Fundamentals course](/academy/ai-act-fundamentals/) is free, the [exam](/academy/exam/) is graded on our server rather than in your browser, and the certificate carries a public id anyone can check. It is evidence for your governance file, not a licence from an authority — and we say so on the certificate itself. ## Where Governance Meets the Other Regimes Most organisations building AI governance in 2026 already run a GDPR programme, and financial institutions also run DORA and often NIS2. The controls overlap more than the regulations do. A data protection impact assessment under GDPR Article 35 and a fundamental rights impact assessment under AI Act Article 27 ask overlapping questions about the same system, and the AI Act explicitly allows the FRIA to build on an existing DPIA rather than duplicate it. Incident reporting under DORA and serious-incident reporting under AI Act Article 73 run on different clocks to different authorities but start from the same detection. Third-party risk management under DORA covers the vendor whose model you deploy. The practical move is to write each control once and file it against every regime it satisfies. [AI Act vs DORA vs NIS2](/ai-act-vs-dora-vs-nis2/) maps the overlaps for financial institutions; [AI Act vs GDPR](/ai-act-vs-gdpr/) does the same for data protection. ## A Realistic First Ninety Days **Weeks 1–3 — Inventory.** Ask every function what they use, then check the expense ledger and the SSO logs against the answer. The gap between the two is the real scope. **Weeks 4–6 — Classify.** Run each system through Articles 5 and 6. Most will come out minimal-risk; the point of the exercise is the handful that do not, and the written record showing you checked. **Weeks 7–9 — Close the Article 50 gaps.** Disclosure is already in force and is the cheapest obligation to meet. Chatbots say they are AI, synthetic media is marked. **Weeks 10–12 — Design oversight and write the policy.** For each high-risk or near-high-risk system, name who can stop it and give them the authority to. Then write the policy that records all of the above, and set the review date. Annex III obligations bite on 2 December 2027. A first pass at this takes a quarter; doing it twice because the first inventory was wrong takes two. -------------------------------------------------------------------------------- ## AI Literacy under Article 4 of the EU AI Act: What Is Actually Required URL: https://www.regulation-ai.eu/en/ai-literacy/ ## An obligation that is already in force, and that almost everyone is in scope of Article 4 is short, and that brevity is why it is routinely overlooked. As rewritten by Regulation (EU) 2026/1744, it requires providers and deployers of AI systems to **take measures to support the development of AI literacy** among their staff and other people dealing with the operation and use of AI systems on their behalf — and it then says, in terms, that the obligation "does not require providers or deployers to guarantee any specific level of AI literacy of any individual". That second sentence is the point of the rewrite. Article 4 used to read as a duty of result: ensure, to your best extent, a *sufficient level*. It now reads as a duty of means. What you owe is the measures, and the measures are what a supervisory authority can ask you to produce. Four features make it unusual: - **It applies to all AI, not just high-risk.** Almost every other substantive duty in the Regulation is gated on risk classification. This one is not. - **It has applied since 2 February 2025.** While the high-risk obligations were deferred to 2027 and 2028 by the [Digital Omnibus](../omnibus/), Article 4 was not. It was rewritten in place, not postponed. - **It is a duty of means, not of result.** You are asked to act, not to certify a state of mind. The measures are the object of the obligation. - **It reaches beyond employees.** "Persons dealing with the operation and use of AI systems on your behalf" pulls in contractors, agency staff and outsourced operators. If your organisation uses a commercial AI assistant, a CV-screening tool or an AI feature embedded in existing software, you are a deployer and Article 4 binds you today. ## What the measures have to take into account The Regulation does not define a syllabus, and since the rewrite it no longer defines a level either. What it does define — and this part survived the Omnibus unchanged — are the factors your measures have to be calibrated against: - the **technical knowledge, experience, education and training** of the people concerned - the **context** in which the systems will be used - the **persons or groups of persons** on whom the systems will be used That last factor is the one most often missed. The measures are calibrated partly by who is affected, not only by who operates. A tool that screens job applicants demands a higher standard than one that drafts internal meeting notes, even if the operator is the same person. The recital gloss is that AI literacy should equip people to make **informed deployment decisions** and to understand the opportunities, risks and possible harms of AI — including how to interpret output, and when not to rely on it. ## A workable interpretation Because Article 4 names factors rather than a curriculum, the defensible approach is role-based rather than universal. | Group | What they need to be able to do | |---|---| | **All staff** | Recognise when they are interacting with an AI system, understand that output can be wrong or biased, know the internal rules on what may be entered into which tool | | **Operators / business users** | Interpret output correctly, understand the system's limitations and intended purpose, know the escalation path when something looks wrong | | **Human oversight roles (Art. 14)** | Understand the system's capacity and limits well enough to monitor it, detect anomalies and automation bias, and override or stop it | | **Procurement and legal** | Distinguish provider from deployer duties, identify Annex III use cases, know what documentation to demand from vendors | | **Developers / data teams** | Data governance duties, documentation requirements, logging, accuracy and robustness expectations | | **Executives** | Accountability structure, risk appetite, penalty exposure, the classification of the organisation's own portfolio | ## The link to human oversight Article 4 is not a standalone compliance chore. It is the precondition for Article 14. Human oversight for high-risk systems must be **effective**: the designated person has to be able to understand the system's capacities and limitations, remain aware of automation bias, correctly interpret output, and decide not to use the system or to override it. None of that is achievable by someone who has not been trained. In practice, a weak Article 4 programme converts directly into an Article 14 failure at the point where it matters most — and Article 14 *does* sit in the €15 million / 3% penalty tier. ## Evidencing it There is no certificate to obtain, so the evidence is your own record — and now that the obligation is one of means, that record *is* the compliance artefact. A defensible file usually contains: 1. **An AI inventory** — which systems are in use, by whom, in what role. This doubles as the starting point for [high-risk classification](../high-risk/). 2. **A role-to-competence mapping** — the table above, adapted to your organisation. 3. **Delivered training records** — dates, audiences, content, attendance. 4. **Internal usage rules** — an acceptable-use policy covering what may be entered into which system, and what output may be relied on without review. 5. **A refresh cadence** — the obligation is continuous, and the systems change. 6. **Contractor coverage** — evidence that people acting on your behalf are included. ## Common misreadings **"The Digital Omnibus dropped it."** It did not. Regulation (EU) 2026/1744 replaced the text of Article 4, softening a duty of result into a duty of means and adding an express statement that no specific level need be guaranteed for any individual. The obligation to take measures, and to be able to show them, is still there. **"It only applies to high-risk systems."** It does not. Article 4 sits in Chapter I, General Provisions, and is unqualified by risk category. **"We bought a tool, so it is the vendor's problem."** The vendor is the provider and has its own Article 4 duty. Yours as deployer is separate and non-transferable. **"We will handle it with the 2027 high-risk work."** The obligation has been enforceable since February 2025. Deferring it to the [high-risk deadline](../deadlines/) leaves a gap of nearly three years on an obligation that is already live. **"One e-learning module for everyone is enough."** Possibly, for a small organisation with a narrow AI footprint. But the statutory factors are role-, context- and impact-sensitive, so a single generic module is hard to defend where the footprint is broad. Start from [Article 4](../articles/article-4/) itself, then work the [compliance checklist](../compliance-checklist/) to see how literacy connects to the rest of the obligation set. -------------------------------------------------------------------------------- ## Annex I High-risk AI: Safety Components in Regulated Products (Deadline: 2 August 2028) URL: https://www.regulation-ai.eu/en/annex-i/ ## What Annex I covers — AI embedded in regulated products Annex I of the EU AI Act lists EU legislation governing product safety. When an AI system constitutes a **safety component** of a product covered by these laws, that AI system is classified as high-risk under Art. 6(1). The deadline is **2 August 2028**, extended by 24 months by the 2026 Digital Omnibus. The defining characteristic: the AI is embedded within a regulated product and performs a safety-critical function. The AI is not placed on the market independently — it ships as part of the product. ## Which product legislation triggers Annex I? | EU legislation | AI examples | |---|---| | Machinery Regulation (2023/1230) | AI-based collision avoidance, robotic control systems, predictive maintenance for safety functions | | Medical Devices Regulation (MDR 2017/745) | AI diagnostic tools in imaging, AI-assisted surgical robots, clinical decision support systems | | In Vitro Diagnostic Regulation (IVDR 2017/746) | AI for pathology analysis, AI-assisted lab diagnostics | | Motor Vehicles type-approval (2018/858 + related) | AI for autonomous driving functions, ADAS safety systems | | Agricultural vehicles (167/2013) | AI safety systems in tractors and agricultural machinery | | Marine Equipment Directive (2014/90) | AI navigation and safety systems on vessels | | Civil aviation (EASA framework) | AI in flight control, navigation, and safety monitoring | | Railways (2016/797) | AI in train control, signalling, and collision prevention | | Lifts (2014/33) | AI safety monitoring in lifts and escalators | | Personal protective equipment (2016/425) | AI-integrated PPE with safety functions | | Pressure equipment (2014/68) | AI safety monitoring in pressure vessels | | Toys (2009/48) | AI systems in toys with safety-relevant functions | | Recreational craft (2013/53) | AI navigation systems in boats | | Radio equipment (2014/53) | AI in radio equipment with safety functions | ## How Annex I conformity assessment works Unlike Annex III (which has its own standalone conformity procedure), Annex I compliance is integrated into the **existing conformity assessment** for the relevant sector legislation. **For medical devices (MDR/IVDR):** The MDR/IVDR conformity assessment (Annex IX Technical Documentation review, or Annex X Type Examination) is extended to cover AI Act requirements. Technical documentation must additionally include: - AI-specific risk management (Art. 9) - Training and validation data description (Art. 10) - Accuracy, robustness, and cybersecurity measures (Art. 15) - Human oversight design (Art. 14) The MDR/IVDR notified body handles the combined assessment where qualified. Where an AI Act notified body is required separately, coordination between the two is needed. **For machinery and vehicles:** Similar integration applies. The type-approval or conformity assessment procedure for the product is extended to include AI Act requirements. The technical file is a combined document. ## Obligations for providers of Annex I AI (by 2 August 2028) | Obligation | Article | How it integrates | |---|---|---| | Risk management | Art. 9 | Added to existing product risk assessment | | Data governance | Art. 10 | Training/validation data documented in technical file | | Technical documentation | Art. 11 | Combined with sector-specific technical file | | Transparency | Art. 13 | Instructions for professional users/deployers | | Human oversight | Art. 14 | Designed into product safety architecture | | Accuracy and robustness | Art. 15 | Tested as part of product performance validation | | QMS | Art. 17 | Extended to cover AI lifecycle | | Conformity assessment | Art. 43 + Annex VII | Via existing sector legislation procedure | | Registration | Art. 71 | EU AI database registration | | CE marking | Art. 48 | Existing CE marking on product covers AI component | ## Why 2028 — and what to do now The 24-month extension acknowledges real-world complexity: coordinating AI Act compliance across two overlapping regulatory regimes (sector law + AI Act) while harmonised standards are still being developed takes longer than standalone systems. But the extension is not a reason to wait. **Start now** on: 1. **AI inventory** — identify which products contain AI safety components 2. **Classification** — confirm which qualify as Annex I high-risk (safety component test) 3. **Gap assessment** — map current technical documentation against Art. 11/Annex IV requirements 4. **Notified body engagement** — determine whether your current MDR/IVDR/Machinery notified body is also designated for AI Act assessment, or whether coordination with a separate AI notified body is needed 5. **QMS extension** — begin extending your ISO 13485 (medical) or ISO 9001 (machinery) QMS to cover AI lifecycle requirements Notified body capacity for AI Act assessments will be constrained as 2028 approaches. Early engagement is a competitive advantage. ## Intersection with DORA and NIS2 Medical device manufacturers and industrial equipment providers in critical sectors also face NIS2 obligations. AI systems embedded in networked medical devices or critical infrastructure equipment may simultaneously be Annex I high-risk AI (AI Act), subject to NIS2 security measures, and — if used in financial contexts — DORA ICT requirements. See our [convergence analysis →](/ai-act-vs-dora-vs-nis2/). -------------------------------------------------------------------------------- ## Annex III High-risk AI: Obligations, Scope and Deadline (2 December 2027) URL: https://www.regulation-ai.eu/en/annex-iii/ ## What Annex III covers — 8 categories of high-risk AI Annex III of the EU AI Act defines standalone high-risk AI systems across 8 areas. The deadline for compliance is **2 December 2027** (extended by the 2026 Digital Omnibus from the original 2 August 2026). "Standalone" means the AI system is not a safety component of an Annex I regulated product — it is itself placed on the market or put into service as the primary product or service. ### The 8 Annex III categories **1. Biometric identification and categorisation** Real-time and post-hoc remote biometric identification systems, AI-based systems for categorising individuals by biometric data into groups based on sensitive characteristics (ethnicity, political views, religion, etc.). Note: Real-time biometric identification of natural persons in publicly accessible spaces by law enforcement is *prohibited* under Art. 5, not just high-risk. **2. Critical infrastructure** AI systems used as safety components in the management and operation of critical infrastructure — road traffic, water supply, gas, heating, electricity grid. **3. Education and vocational training** AI that determines access to educational establishments, allocates students, assesses examination performance, monitors students during exams, or evaluates learning achievement that affects opportunities. **4. Employment, workers management, self-employment** AI used for recruitment and selection (CV screening, personality tests, job application filtering), decisions on promotion, termination, performance evaluation, task allocation in gig work, and monitoring employee behaviour. **5. Essential private and public services** AI used for creditworthiness assessment, credit scoring, insurance risk assessment and pricing, health risk scoring for insurance, evaluation of eligibility for public benefits and services, emergency dispatch decisions. **6. Law enforcement** AI for risk assessment of individuals (recidivism risk, crime likelihood), lie detection, evidence reliability evaluation, profiling in criminal investigations, crime prediction for geographic areas. **7. Migration, asylum, border control** AI for risk assessment of asylum seekers, verification of travel documents, examination of applications for asylum, visa, or residence permits, detecting irregular migration patterns. **8. Administration of justice and democratic processes** AI for researching and interpreting facts and law in judicial proceedings, AI influencing elections, AI used in voting systems. ## Provider obligations by 2 December 2027 | Obligation | Article | Description | |---|---|---| | Risk management | Art. 9 | Continuous process across the AI lifecycle | | Data governance | Art. 10 | Training/validation/test data quality requirements | | Technical documentation | Art. 11 | Comprehensive documentation before market placement | | Transparency | Art. 13 | Instructions for deployers; automatic logging capability | | Human oversight | Art. 14 | Design measures enabling human monitoring and intervention | | Accuracy & robustness | Art. 15 | Appropriate performance levels; resilience to errors | | Quality management | Art. 17 | QMS covering design through post-market monitoring | | Conformity assessment | Art. 43 | Self-assessment (most systems) or third-party (biometrics, critical infrastructure) | | Registration | Art. 71 | EU AI database registration before market placement | | CE marking | Art. 48 | Required before placing on the EU market | ## Deployer obligations by 2 December 2027 Organisations that use (deploy) Annex III AI systems — even if they did not build them — must: - Use the system in accordance with the provider's instructions - Implement human oversight measures - Monitor system performance and report serious incidents - For public bodies: complete a Fundamental Rights Impact Assessment (FRIA) - Inform workers or their representatives when AI affects employment decisions - Not use the system for purposes other than those assessed as high-risk ## Train your team on Annex III obligations Under Art. 4, all staff working with Annex III AI systems — whether as provider or deployer — must have documented AI literacy. The [AI Act Fundamentals course (free) →](/academy/ai-act-fundamentals/) covers risk classification and role obligations. For a full compliance programme: risk management, technical documentation, human oversight, and conformity assessment, see the [Pro certification →](/academy/) and the [interactive compliance checklist →](/tools/compliance-checklist/). -------------------------------------------------------------------------------- ## Article 1 — Subject matter (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-1/ ## Official Text Summary Article 1 of Regulation (EU) 2024/1689 of the European Parliament and of the Council — commonly known as the EU AI Act — establishes the subject matter of the regulation. It declares that the regulation lays down harmonised rules concerning the placing on the market, the putting into service, and the use of artificial intelligence systems in the Union. The article identifies five principal regulatory objectives that the regulation pursues: 1. Rules on prohibited AI practices that pose unacceptable risks to fundamental rights, safety, and Union values. 2. Specific requirements and obligations for high-risk AI systems and the operators involved in their lifecycle. 3. Transparency obligations for certain AI systems interacting with natural persons or generating synthetic content. 4. Rules applicable to general-purpose AI (GPAI) models, including those with systemic risk. 5. Rules on market monitoring, market surveillance, governance at both Member State and Union level, and enforcement mechanisms. Article 1 also declares that the regulation aims to improve the functioning of the internal market and to promote the uptake of human-centric and trustworthy artificial intelligence, while ensuring a high level of protection of health, safety, and fundamental rights as enshrined in the Charter of Fundamental Rights of the European Union. It thereby anchors the regulation simultaneously in internal market law (Article 114 TFEU) and fundamental rights protection. ## What This Means in Practice Article 1 is a framing provision. It does not generate direct compliance tasks in isolation, but it defines the regulatory logic that determines which obligations apply to any given actor or system. **For providers** — companies or individuals that develop AI systems or general-purpose AI models and place them on the EU market or put them into service — Article 1 signals that a comprehensive, risk-tiered compliance framework governs their activities. A provider of a high-risk AI system used in credit scoring, recruitment, or critical infrastructure must understand from the outset that the regulation pursues both market harmonisation and fundamental rights protection simultaneously. These twin objectives shape how obligations in later articles are interpreted. **For deployers** — entities that use AI systems in a professional context — Article 1 confirms that use within the Union is sufficient to trigger the regulation, even if the provider is based outside the EU. **For legal and compliance teams**, Article 1 establishes that the EU AI Act is not a sector-specific rule but a horizontal regulation covering AI across all domains, with the exception of systems used exclusively for military, national security, or research and development purposes prior to market placement, as further specified in Article 2. **Practical example:** A US-based company deploying a CV-screening AI tool for recruitment of EU-based employees falls within the regulatory perimeter Article 1 describes. The compliance journey begins with understanding Article 1's scope statement, then moves to Article 6 and Annex III to assess whether the system is high-risk. ## Key Obligations - **Understand the regulatory perimeter.** Article 1 defines what the EU AI Act governs. Every compliance programme must begin with a clear reading of its five stated objectives to correctly map which subsequent provisions apply. - **Recognise the dual legal basis.** The regulation pursues internal market harmonisation and fundamental rights protection simultaneously. Compliance assessments must address both dimensions, not just technical conformity. - **Account for all five regulatory pillars.** Prohibited practices, high-risk system requirements, transparency obligations, GPAI model rules, and governance structures each represent a distinct compliance track stemming from Article 1's subject matter declaration. - **Apply the regulation regardless of establishment location.** Article 1 makes clear that systems placed on the EU market or whose output is used in the EU are within scope, establishing an extraterritorial reach confirmed in Article 2. - **Anchor internal AI governance in Article 1's purpose.** Internal policies, risk assessments, and conformity documentation should explicitly reference the regulation's stated aim of human-centric, trustworthy AI as a guiding interpretive principle. ## Relationship to Other Articles Article 1 must be read as the gateway to the entire regulation. It connects directly to **Article 2** (scope and exclusions), which specifies precisely which actors and systems are covered or exempt, including carve-outs for military use, personal non-professional use, and limited open-source provisions. The five objectives Article 1 enumerates map directly onto the regulation's structural chapters: **Article 5** (prohibited practices), **Articles 6–51** (high-risk AI systems), **Articles 50** (transparency obligations), **Articles 51–56** (GPAI models), and **Articles 57–101** (governance and enforcement). Article 1 also reinforces the interpretive role of the **recitals**, particularly Recitals 1–10, which contextualise the regulation's purpose within the EU's digital strategy and Charter of Fundamental Rights. When ambiguity arises in applying later articles, compliance teams should return to Article 1's stated objectives as the primary interpretive anchor under standard EU statutory interpretation principles. ## Compliance Timeline Article 1 entered into force on **1 August 2024**, twenty days after the regulation's publication in the Official Journal of the European Union (OJ L 2024/1689, 12 July 2024). As a subject-matter provision, it is applicable from that date and has no deferred application period. However, the operational provisions Article 1 describes follow a phased application schedule: - **2 February 2025** — Provisions on prohibited AI practices (Chapter II, Article 5) became applicable. - **2 August 2025** — Rules on general-purpose AI models (Chapter V, Articles 51–56), governance provisions, and confidentiality/penalty articles became applicable. - **2 August 2028** — Rules for high-risk AI systems listed in Annex I (safety-component systems regulated by sectoral Union law) become applicable. - **2 December 2027** — Rules for high-risk AI systems listed in Annex III (including biometric identification, critical infrastructure, employment, essential services, law enforcement, migration, and justice) become fully applicable, with the exception of certain public-sector deployers. Understanding Article 1's framing is therefore an immediate obligation — it informs how organisations should have begun their AI inventory and risk classification exercises as of August 2024. -------------------------------------------------------------------------------- ## Article 10 — Data and data governance (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-10/ ## Official Text Summary Article 10 of Regulation (EU) 2024/1689 (the EU AI Act), located in Title III, Chapter 2, establishes mandatory data governance requirements for providers of high-risk AI systems. The article applies to training, validation, and testing datasets used in the development of such systems. Under Article 10(2), data governance practices must address: the design choices behind data collection; data preparation operations including annotation, labelling, cleaning, enrichment, and aggregation; the formulation of relevant assumptions regarding intended use; and an examination of possible biases likely to affect health, safety, or fundamental rights. Article 10(3) requires that training, validation, and testing datasets be subject to appropriate data management practices and be relevant, representative, free of errors, and complete in light of the intended purpose. Where complete freedom from errors is not achievable, providers must document residual errors and their potential impact. Article 10(4) addresses the processing of special categories of personal data — as defined in Article 9 of Regulation (EU) 2016/679 (GDPR) and Article 10 of Regulation (EU) 2018/1725 — strictly limiting such processing to bias monitoring and correction, subject to appropriate safeguards. Article 10(5) provides that Member States may establish specific conditions for processing sensitive personal data in the public interest for AI development purposes, subject to strict conditions. Article 10(6) clarifies that dataset requirements apply proportionally to providers who use pre-existing datasets they did not originally collect, to the extent that such examination is technically feasible. ## What This Means in Practice Article 10 places concrete obligations on any organisation developing or deploying a high-risk AI system in the EU. In practice, compliance requires establishing and maintaining a structured data governance programme that spans the full development lifecycle. For a provider developing an AI-assisted recruitment screening tool (an Annex III, point 4 system), Article 10 demands documenting why specific datasets were chosen, what preprocessing steps were applied, and how the datasets cover the demographic diversity of the intended applicant pool. If the training data underrepresents applicants from certain regional or ethnic backgrounds, the provider must identify this gap, assess the bias risk to equal treatment, and either correct the dataset or implement technical mitigations — all traceable in the technical documentation required by Article 11. For a provider integrating a third-party AI model or dataset, Article 10(6) still requires a best-effort examination of the pre-built data's properties relative to the intended use case. Relying on an upstream vendor's data sheet is not sufficient in isolation; downstream providers must validate that the data properties align with their specific deployment context. Practically, compliance teams should: maintain a data management plan per system; institute data lineage records; run documented bias and representativeness assessments at training, validation, and testing stages; and ensure any use of sensitive personal data for bias correction is covered by a lawful basis and appropriate access controls. These records form part of the technical documentation that must be available to national competent authorities on request. ## Key Obligations - **Data governance framework**: Establish documented data governance and management practices covering all stages — training, validation, and testing — before placing a high-risk AI system on the market. - **Dataset quality criteria**: Ensure datasets meet four cumulative quality criteria: relevance to the intended purpose, representativeness of the deployment context, freedom from errors (or documented residual error rates), and completeness. - **Bias examination**: Conduct and document an examination of datasets for biases that could lead to discrimination or risks to health, safety, or fundamental rights, applying corrective measures where biases are identified. - **Data preparation documentation**: Record all data preparation operations — annotation, labelling, cleaning, enrichment, and aggregation — along with the assumptions and design choices that shaped them. - **Restricted use of sensitive data**: Process special categories of personal data for bias detection and correction only, subject to GDPR-equivalent safeguards, and only where strictly necessary and proportionate. - **Third-party and pre-existing datasets**: Conduct a proportionate, technically feasible examination of any pre-existing or third-party datasets to verify they meet the requirements relevant to the provider's specific use case. ## Relationship to Other Articles Article 10 sits at the centre of the high-risk AI requirements framework and connects directly to several other provisions. Article 9 (risk management system) feeds into Article 10: risks identified through data governance — such as dataset bias — must be managed through the iterative risk management process. Article 11 (technical documentation) and Annex IV require providers to record data governance choices and dataset characteristics as part of the conformity documentation reviewed by notified bodies or self-assessed. Article 13 (transparency and provision of information) relies on data documentation to enable meaningful instructions of use, particularly regarding known limitations arising from data quality gaps. Article 17 (quality management system) requires data governance to be institutionalised within the provider's broader quality processes. For systems processing personal data, Article 10 intersects with GDPR obligations — Article 5 (data quality principles) and Article 25 (data protection by design) are complementary requirements that providers must satisfy in parallel. Article 10(4) explicitly cross-references Regulation (EU) 2016/679 and Regulation (EU) 2018/1725 to delimit permissible processing of sensitive data. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024**, twenty days after publication in the Official Journal of the EU (OJ L 2024/1689, 12 July 2024). Article 10 follows the phased application schedule applicable to high-risk AI systems: - **2 February 2025**: Prohibitions on unacceptable-risk AI practices (Article 5) became enforceable; no direct obligation under Article 10 at this stage. - **2 August 2025**: GPAI model requirements (Title VIII) became applicable; national market surveillance authorities assumed operational responsibility for high-risk system oversight. - **2 December 2027**: Article 10 becomes fully enforceable for high-risk AI systems listed in **Annex III** (general-purpose high-risk applications, including biometric identification, critical infrastructure, education, employment, essential services, law enforcement, migration, and justice). Providers must have compliant data governance documented and in place by this date. - **2 August 2028**: Article 10 becomes enforceable for high-risk AI systems regulated under **Annex I** (product-safety legislation, including machinery, medical devices, vehicles, and aviation). These systems must meet all data governance requirements within their product conformity assessments by this extended deadline. Providers are strongly advised to begin data governance gap assessments well in advance of the applicable deadline, as remediation of training datasets and procurement of compliant third-party data can require significant lead time. -------------------------------------------------------------------------------- ## Article 100 — Administrative fines on Union institutions and bodies (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-100/ Article 100 answers a question most compliance programmes never ask: who fines the EU itself? When Union institutions, bodies, offices or agencies breach the AI Act, the European Data Protection Supervisor holds the fining pen — on a deliberately smaller scale. ## Official Text Summary The European Data Protection Supervisor may impose administrative fines on Union institutions, bodies, offices and agencies falling within the scope of the Regulation, taking into account the nature, gravity and duration of the infringement, the number of persons affected, the degree of cooperation, any prior similar findings and the manner in which the infringement became known. The ceilings are deliberately lower than for private operators: up to EUR 1 500 000 for non-compliance with the Article 5 prohibitions, and up to EUR 750 000 for other obligations. The institution concerned has the right to be heard before any decision, proceedings respect confidentiality, the Court of Justice has unlimited jurisdiction to review, and the funds collected accrue to the general budget of the Union. ## Key Obligations - The EDPS may impose administrative fines on Union institutions, bodies, offices and agencies within the Act's scope - Ceilings: up to €1 500 000 for breaches of the Article 5 prohibitions; up to €750 000 for non-compliance with other obligations - Fines follow the classic criteria — nature, gravity, duration, cooperation, prior findings — with a right to be heard, Court of Justice jurisdiction, and proceeds flowing to the Union budget ## Compliance Timeline Applicable since 2 August 2025, together with the rest of the general-purpose AI framework; the 2026 Digital Omnibus did not alter this date. -------------------------------------------------------------------------------- ## Article 101 — Penalties applicable to providers of general-purpose AI models (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-101/ ## Official Text Summary Article 101 of Regulation (EU) 2024/1689 establishes the penalty regime specifically applicable to providers of general-purpose AI (GPAI) models, complementing the broader penalty framework of Article 99. It sets two principal financial thresholds. First, providers of general-purpose AI models who infringe the obligations contained in Chapter V of the Regulation — covering transparency obligations, technical documentation, copyright compliance, and the additional requirements for models presenting systemic risk — are subject to administrative fines of up to 15 million EUR, or, where the offender is an undertaking, up to 3% of total worldwide annual turnover for the preceding financial year, whichever is the higher amount. Second, providers who supply incorrect, incomplete, or misleading information to the AI Office or national competent authorities in response to a request made under Articles 91 or 87, or who fail to remedy an infringement within the timeframe set by a corrective measure, are subject to fines up to 15 million EUR or up to 3% of worldwide annual turnover. Article 101 also confirms that the European AI Office acts as the lead enforcement body for GPAI model providers, with the power to initiate proceedings, conduct evaluations, and impose fines in accordance with the procedural safeguards established in Articles 90 through 99. Fines imposed on Union institutions and bodies follow distinct rules. The article reinforces that all penalties must be effective, proportionate, and dissuasive, and that individual circumstances — including cooperation and remediation — are considered when determining the final amount. ## What This Means in Practice Article 101 directly affects any legal entity, including non-EU entities placing GPAI models on the Union market, that develops or releases a general-purpose AI model as defined in Article 3(63) of the Regulation. This includes providers of foundation models, large language models, multimodal models, and other models trained on broad data at scale that can serve a wide range of downstream tasks. In practical terms, a provider must first determine whether its model meets the GPAI definition and, if so, fulfil the Chapter V obligations: maintaining technical documentation, publishing a summary of training data in accordance with copyright law, implementing a policy to comply with Union copyright rules, and registering the model in the relevant EU database. Providers of models deemed to present systemic risk — currently defined by reference to a training compute threshold of 10^25 FLOPs, or by AI Office designation — face additional obligations including adversarial testing, incident reporting, and cybersecurity measures. Failure to fulfil any of these obligations exposes a provider to fines under Article 101. For large technology companies whose annual global turnover runs into tens of billions of euros, a 3% turnover-based fine substantially exceeds the 15 million EUR absolute cap, making the turnover multiplier the operative ceiling in practice. A provider headquartered outside the EU must designate an authorised representative in the Union under Article 54, and that representative's presence does not shield the provider from direct liability. Providers should treat Article 101 as a strong financial incentive to complete GPAI compliance before the August 2025 application date. Documented compliance programmes, audit trails, and proactive engagement with the AI Office during any investigation are the most effective mitigating factors. ## Key Obligations - **Chapter V compliance as the trigger condition:** The penalty power under Article 101 is activated by infringement of any obligation in Chapter V (Articles 55 to 56), meaning GPAI providers must map every applicable obligation to an internal control before the August 2025 application date. - **Accurate and complete information to the AI Office:** Providers must respond truthfully and fully to any information request issued by the AI Office under Articles 91 and 87; supplying incorrect, incomplete, or misleading responses is itself a distinct infringement subject to the same penalty ceiling. - **Systemic risk obligations for high-impact models:** Providers of GPAI models with systemic risk must additionally comply with Articles 55 and 56 — adversarial testing, incident notification, and cybersecurity safeguards — and are subject to Article 101 penalties for failure to do so. - **Designation of an authorised representative:** Non-EU providers must appoint an authorised representative in the Union, and failure to do so is an infringement of Chapter V triggering Article 101 exposure. - **Timely remediation of corrective measures:** Where the AI Office issues a corrective measure requiring a provider to remedy an infringement within a specified period, failure to comply within that deadline constitutes a separate infringement subject to additional fines. - **Proportionality and cooperation as mitigating factors:** While not a formal obligation, the Regulation requires authorities to consider the degree of cooperation and voluntary remediation when calculating fines, giving providers a strong compliance incentive to engage proactively with the AI Office. ## Relationship to Other Articles Article 101 cannot be read in isolation. It draws its substantive scope from Chapter V (Articles 55 to 56), which defines the obligations whose breach triggers the penalty. It operates alongside Article 99, which establishes the general penalty regime for all other infringements of the Regulation, and should be read as lex specialis with respect to GPAI model providers. The procedural framework within which Article 101 fines are imposed is set out in Articles 90 to 99, including the AI Office's power to initiate proceedings (Article 90), request information (Articles 91 and 87), conduct on-site inspections, and impose interim measures. Article 85 governs fines imposed on Union institutions, bodies, and agencies and is explicitly distinguished from Article 101. Article 101 also connects to Article 54 (authorised representatives for non-EU providers), Article 72 (the EU database for GPAI models), and Recitals 153 to 157, which explain the legislative intent behind graduated penalties and the primacy of the AI Office in GPAI enforcement. For systemic risk models, Articles 55 and 56 define the additional obligations whose breach is penalised under Article 101. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024. However, Chapter V obligations applicable to GPAI model providers — and therefore the Article 101 penalty regime covering those obligations — became applicable on **2 August 2025**, twelve months after entry into force, in accordance with Article 113(3). Providers should note the following phased timeline: - **1 August 2024** — Regulation entered into force; no obligations yet applicable. - **2 February 2025** — Prohibited AI practices (Article 5) became applicable. - **2 August 2025** — Chapter V GPAI obligations became applicable. Article 101 penalties are enforceable from this date for infringements of those obligations. - **2 August 2025** — AI Office governance rules and general provisions applicable. - **2 August 2028** — High-risk AI system obligations under Annex I (product safety legislation) become applicable. - **2 December 2027** — High-risk AI system obligations for systems listed in Annex III become fully applicable. Providers of general-purpose AI models who had not completed their Chapter V compliance programme by 2 August 2025 are already exposed to Article 101 enforcement action. The AI Office has indicated it will prioritise providers of models presenting systemic risk in its initial supervisory activities, but all GPAI model providers within scope remain subject to the penalty regime from that date. -------------------------------------------------------------------------------- ## Article 102 — Amendments to Regulation (EU) No 300/2008 (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-102/ ## Official Text Summary Article 102 of Regulation (EU) 2024/1689 (the EU AI Act) falls under Title XIII — Final Provisions and addresses amendments to Regulation (EU) No 300/2008 of the European Parliament and of the Council, which establishes common rules in the field of civil aviation security and repealing Regulation (EC) No 2320/2002. The amendment introduces a cross-reference mechanism within Regulation (EU) No 300/2008 to acknowledge and accommodate the application of the EU AI Act to AI systems used in the civil aviation security domain. Specifically, Article 102 ensures that where AI systems are deployed as part of civil aviation security measures — including automated screening, threat detection, and identity verification technologies — these systems remain subject to the applicable provisions of Regulation (EU) 2024/1689 in addition to the existing civil aviation security framework. The amendment is a legislative coordination measure. It does not repeal or substantively alter the core obligations under Regulation (EU) No 300/2008 but instead ensures regulatory coherence between the two instruments, preventing a gap or conflict in the applicable legal framework when AI-enabled technologies are introduced into civil aviation security operations. This reflects the EU legislator's broader approach across Title XIII of the AI Act, which systematically updates pre-existing sector-specific regulations to integrate the new horizontal AI governance layer introduced by Regulation (EU) 2024/1689. ## What This Means in Practice For organisations operating in the civil aviation security sector, Article 102 signals that AI systems deployed in security screening contexts cannot be governed solely by Regulation (EU) No 300/2008 and its implementing acts. They must simultaneously satisfy the requirements of the EU AI Act, particularly where those systems qualify as high-risk AI systems under Annex III of Regulation (EU) 2024/1689. AI-enabled technologies commonly used in civil aviation security — such as automated explosive detection systems, biometric passenger verification tools, behavioural analysis software, or AI-driven threat assessment platforms at checkpoints — are likely to fall within the high-risk category given their safety-critical function and the potential impact on fundamental rights. Operators and manufacturers of such systems must therefore comply with the full high-risk AI system obligations under Title III of the EU AI Act, including conformity assessment procedures, registration in the EU database, technical documentation, human oversight mechanisms, and transparency obligations. For competent authorities responsible for civil aviation security standards — typically national aviation authorities and bodies designated under Regulation (EU) No 300/2008 — Article 102 means that their oversight frameworks must now account for AI Act compliance as an additional layer of verification when certifying or approving security technologies. Procurement authorities and airport operators should update their vendor due diligence processes to require evidence of EU AI Act conformity alongside existing civil aviation security certifications. Concretely, an airport operator deploying an AI-powered automated baggage screening system must ensure the supplier has conducted an appropriate conformity assessment, maintains a technical file, and has registered the system in the EU AI Act database — on top of any ECAC or national approval requirements. ## Key Obligations - **Dual-framework compliance:** AI systems used in civil aviation security must comply with both Regulation (EU) No 300/2008 and the applicable provisions of the EU AI Act simultaneously — neither instrument alone is sufficient. - **High-risk classification review:** Organisations must assess whether their civil aviation security AI systems meet the high-risk criteria under Annex III of the EU AI Act, given the safety-critical and rights-impacting nature of aviation security operations. - **Conformity assessment:** Manufacturers of AI systems within scope must complete the required conformity assessment procedures under Article 43 of the EU AI Act before placing systems on the market or putting them into service in civil aviation security contexts. - **Technical documentation and registration:** Providers must maintain up-to-date technical documentation (Article 11) and register high-risk AI systems in the EU database established under Article 71 of the EU AI Act. - **Human oversight integration:** Deployers must implement appropriate human oversight measures as required by Article 14 of the EU AI Act, integrated into civil aviation security operational procedures governed by Regulation (EU) No 300/2008. - **Competent authority coordination:** National authorities responsible for civil aviation security should establish coordination mechanisms between AI Act market surveillance authorities and existing aviation security oversight bodies to ensure coherent enforcement. ## Relationship to Other Articles Article 102 is part of a cluster of final-provision amendment articles in Title XIII (Articles 97–109) that systematically update existing EU sector regulations to integrate the AI Act's horizontal framework. It should be read alongside Article 6 and Annex III (high-risk AI system classification), Article 43 (conformity assessment procedures), and Article 71 (EU database for high-risk AI systems), which define the substantive obligations triggered for systems falling within its scope. Article 102 also connects to Article 26 (obligations of deployers of high-risk AI systems) and Article 14 (human oversight), which will govern the operational use of AI systems in aviation security screening environments. The recitals of Regulation (EU) 2024/1689 — particularly those addressing safety-critical sectors and fundamental rights safeguards — provide interpretive context for understanding why civil aviation security AI is treated with heightened regulatory attention. For cross-border aviation operations, Article 102 must be read in conjunction with the market surveillance and enforcement coordination provisions under Articles 74–77 of the EU AI Act. ## Compliance Timeline Article 102 entered into force on **1 August 2024**, twenty days after the publication of Regulation (EU) 2024/1689 in the Official Journal of the European Union on 12 July 2024. The phased application schedule of the EU AI Act determines when the substantive obligations triggered by Article 102 become enforceable in practice: - **2 February 2025** — Prohibited AI practices (Article 5) became applicable. Civil aviation security systems must not employ AI approaches prohibited under this provision. - **2 August 2025** — GPAI model obligations and governance provisions became applicable. General-purpose AI components integrated into civil aviation security systems fall under the GPAI framework from this date. - **2 December 2027** — High-risk AI system obligations under Title III become fully applicable for stand-alone Annex III systems, including those used in civil aviation security screening. This is the primary compliance deadline for manufacturers and deployers of AI-enabled detection and screening technologies. - **31 December 2030** — Extended deadline for high-risk AI systems that are components of large-scale EU IT systems listed in Annex X (Article 111(1)). Operators should verify whether any of their civil aviation security AI systems fall within this extended timeline. Organisations should treat 2 December 2027 as their primary target date for achieving full EU AI Act compliance for civil aviation security AI systems, and should begin conformity assessment processes and technical documentation preparation well in advance. -------------------------------------------------------------------------------- ## Article 103 — Amendments to Regulation (EU) No 167/2013 (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-103/ ## Official Text Summary Article 103 of Regulation (EU) 2024/1689, the EU Artificial Intelligence Act, amends Regulation (EU) No 167/2013 of the European Parliament and of the Council on the approval and market surveillance of agricultural and forestry vehicles. The amendment is a sectoral alignment measure: it modifies the existing type-approval regulation governing tractors, trailers, and interchangeable towed machinery to ensure coherence with the AI Act's horizontal framework wherever AI systems are integrated into or deployed in connection with such vehicles. The specific amendment inserts a reference to the EU AI Act within Regulation (EU) No 167/2013 so that AI systems embedded in agricultural and forestry vehicles that qualify as high-risk under the EU AI Act — by virtue of being safety components or otherwise meeting the criteria in Annex I and Annex III — are subject to coordinated conformity assessment and market surveillance requirements. This prevents regulatory gaps arising from the coexistence of sector-specific vehicle legislation and the horizontal AI Act. The amendment ensures that market surveillance authorities responsible for agricultural and forestry vehicles have clear legal authority to apply AI Act oversight tools, including documentary access, testing powers, and corrective or restrictive measures, without ambiguity as to which regulatory instrument takes precedence or how the two interact in practice. ## What This Means in Practice Article 103 is primarily relevant to manufacturers, importers, and distributors of agricultural and forestry vehicles — including tractors, self-propelled machinery, trailers, and interchangeable towed equipment — who integrate AI systems into those products. It is also relevant to the type-approval bodies and national market surveillance authorities operating under Regulation (EU) No 167/2013. In practical terms, a manufacturer producing a tractor fitted with an AI-based autonomous steering or obstacle-detection system must consider whether that AI system qualifies as high-risk under the EU AI Act — most likely under Annex I, which covers AI systems that are themselves safety components of products subject to EU harmonisation legislation listed in Annex I, Section A of the AI Act. Where the AI system is high-risk, the manufacturer cannot treat type-approval under Regulation (EU) No 167/2013 as a substitute for AI Act compliance. Instead, both regimes apply in a coordinated manner: conformity assessment under the AI Act must be completed and reflected in the relevant technical documentation, and the CE marking process must account for both instruments. For market surveillance authorities, Article 103 clarifies their competence to investigate and take action regarding AI systems in agricultural and forestry vehicles. A national authority detecting a potentially non-compliant AI system in a tractor can invoke both the sectoral vehicle regulation and the AI Act framework, avoiding jurisdictional uncertainty. Manufacturers should ensure that their technical files, instructions for use, and post-market monitoring systems address AI Act requirements alongside existing type-approval documentation. ## Key Obligations - **Coordinated compliance documentation**: Manufacturers of agricultural and forestry vehicles incorporating AI systems must maintain technical documentation that satisfies both Regulation (EU) No 167/2013 and the EU AI Act, including AI-specific requirements such as risk management records, data governance documentation, and transparency information. - **High-risk AI system identification**: Economic operators must assess whether AI systems integrated into agricultural and forestry vehicles qualify as high-risk under Annex I and Annex III of the EU AI Act, particularly where the AI system functions as a safety component within the meaning of the applicable harmonisation legislation. - **Conformity assessment alignment**: Where an AI system is classified as high-risk, manufacturers must complete conformity assessment under the AI Act (Article 43) in addition to, and in coordination with, type-approval procedures under Regulation (EU) No 167/2013. - **Market surveillance cooperation**: National authorities supervising agricultural and forestry vehicles must coordinate with AI Act market surveillance authorities (designated under Article 70 of the EU AI Act) to avoid duplicative or conflicting enforcement actions regarding AI systems in these vehicles. - **Post-market monitoring**: Manufacturers must ensure post-market monitoring obligations under the EU AI Act (Article 72) are integrated into their existing post-approval monitoring obligations under Regulation (EU) No 167/2013, covering AI system performance in real-world agricultural and forestry operating conditions. - **Instructions and transparency**: User-facing documentation for agricultural and forestry vehicles equipped with high-risk AI systems must meet the transparency and information requirements of Article 13 of the EU AI Act, in addition to existing obligations under the vehicle regulation. ## Relationship to Other Articles Article 103 belongs to Title XIII (Final Provisions) alongside Articles 101 through 113, which collectively amend existing EU sector-specific legislation to ensure coherence with the AI Act's horizontal framework. It should be read alongside Article 101 (amendments to Regulation (EU) No 1828/2006 on structural funds), Article 102 (amendments to Regulation (EU) No 168/2013 on two- and three-wheel vehicles), and Article 104 (amendments to Regulation (EU) No 2018/858 on motor vehicles), all of which follow the same legislative technique of inserting AI Act alignment provisions into pre-existing product safety regulations. Within the substantive AI Act framework, Article 103 connects directly to Annex I (harmonisation legislation whose products may incorporate high-risk AI systems), Article 43 (conformity assessment procedures for high-risk AI systems), Article 70 (market surveillance authorities and their powers), Article 72 (post-market monitoring obligations), and Article 13 (transparency requirements for high-risk AI systems). Recital 97 of the EU AI Act provides relevant explanatory context on the relationship between the AI Act and sector-specific Union harmonisation legislation. ## Compliance Timeline Article 103 entered into force on **1 August 2024**, twenty days after publication of Regulation (EU) 2024/1689 in the Official Journal of the European Union on 12 July 2024. The amendment to Regulation (EU) No 167/2013 takes immediate legal effect from that date. However, the practical compliance obligations it triggers — particularly those relating to high-risk AI systems — follow the EU AI Act's phased application schedule: - **February 2025**: Prohibitions on unacceptable-risk AI practices (Article 5) became applicable. Not directly relevant to agricultural vehicle AI systems in most cases, but operators should verify no integrated AI functionality falls within prohibited categories. - **August 2025**: GPAI model obligations and governance provisions became applicable. Relevant if AI systems in vehicles rely on or incorporate general-purpose AI model components. - **August 2028**: High-risk AI system obligations under Annex I — which encompasses AI systems that are safety components of products subject to EU harmonisation legislation including agricultural vehicle regulations — become fully applicable. This is the primary compliance deadline for manufacturers and economic operators affected by Article 103. - **December 2027**: Obligations apply to high-risk AI systems under Annex III categories that were already placed on the market before August 2025 and have not undergone significant changes. Manufacturers of agricultural and forestry vehicles incorporating AI systems should treat **2 August 2028** as their principal target date for full compliance with the coordinated requirements arising from Article 103. -------------------------------------------------------------------------------- ## Article 104 — Amendments to Regulation (EU) No 168/2013 (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-104/ ## Official Text Summary Article 104 of Regulation (EU) 2024/1689 (the EU AI Act) forms part of Title XIII, which contains the final provisions governing the Act's integration with the broader EU regulatory landscape. Specifically, Article 104 introduces targeted amendments to Regulation (EU) No 168/2013 of the European Parliament and of the Council on the approval and market surveillance of two- or three-wheel vehicles and quadricycles — collectively known as L-category vehicles. The amendment mechanism reflects the EU legislature's standard approach when enacting horizontal legislation: existing sectoral regulations must be updated to remain coherent with new cross-cutting rules. Regulation (EU) No 168/2013 established a comprehensive type-approval framework covering safety and environmental requirements for L-category vehicles. Where such vehicles incorporate AI systems — for example, advanced rider-assistance systems, automated braking, or adaptive cruise control functions — those AI components may fall within the scope of the EU AI Act and could qualify as high-risk AI systems under Annex I, Section 2 (AI systems used as safety components in products covered by Union harmonisation legislation). Article 104 ensures that references, definitions, and procedures within Regulation (EU) No 168/2013 are aligned with the terminology and requirements introduced by the EU AI Act, preventing regulatory gaps or conflicts between the two instruments and preserving legal certainty for manufacturers and market surveillance authorities operating in the L-category vehicle sector. ## What This Means in Practice For manufacturers, importers, distributors, and authorised representatives of L-category vehicles, Article 104 has practical consequences wherever AI systems are integrated into those vehicles. The most immediate effect is that any AI system functioning as a safety component in a moped, motorcycle, motor tricycle, or light quadricycle must be evaluated against the EU AI Act's high-risk classification criteria. If classified as high-risk, the AI system must comply with Chapter III requirements — including conformity assessment, technical documentation, post-market monitoring, transparency obligations, and registration in the EU database — in addition to the existing obligations under Regulation (EU) No 168/2013. For type-approval purposes, national type-approval authorities and technical services involved in assessing L-category vehicles will need to verify AI Act compliance as part of their broader review. This may require updated assessment protocols and additional competences among designated technical services. Practically, a manufacturer developing an AI-driven traction control or collision avoidance system for a motorcycle should: - Determine whether the AI system qualifies as a safety component under Annex I of the EU AI Act. - If high-risk, prepare a conformity assessment dossier meeting EU AI Act requirements before placing the vehicle on the market. - Ensure that the technical documentation required by Regulation (EU) No 168/2013 is consistent with and references the AI Act documentation where applicable. - Implement quality management systems covering the AI lifecycle, including post-market monitoring and incident reporting. Market surveillance authorities responsible for L-category vehicles will likewise need to coordinate with authorities designated under the EU AI Act to avoid duplicative or conflicting oversight actions. ## Key Obligations - **Regulatory alignment:** Legal and compliance teams must ensure that all internal procedures for L-category vehicle development reflect the amendments introduced by Article 104, keeping type-approval documentation consistent with EU AI Act requirements where AI systems are present. - **High-risk classification review:** Manufacturers must assess whether AI systems integrated into L-category vehicles qualify as high-risk AI systems under Annex I of the EU AI Act, triggering the full conformity assessment obligations of Chapter III. - **Updated technical documentation:** Where AI systems are involved, technical documentation submitted for type-approval under Regulation (EU) No 168/2013 must be coherent with the technical documentation requirements set out in Article 11 and Annex IV of the EU AI Act. - **Conformity assessment procedures:** High-risk AI systems in L-category vehicles must undergo conformity assessment as required by Article 43 of the EU AI Act prior to market placement, alongside the existing type-approval procedure. - **Market surveillance coordination:** Authorities with competence under Regulation (EU) No 168/2013 and those designated under the EU AI Act must coordinate their market surveillance activities to ensure effective and non-duplicative oversight. - **Post-market monitoring:** Manufacturers of L-category vehicles incorporating high-risk AI systems must establish post-market monitoring plans and report serious incidents in accordance with Articles 72 and 73 of the EU AI Act. ## Relationship to Other Articles Article 104 does not operate in isolation. It must be read alongside the definitional provisions of Article 3, which defines key concepts including AI system, safety component, and high-risk AI system. The high-risk classification criteria in Article 6 and Annex I are directly relevant: Section 2 of Annex I lists AI systems used as safety components in products covered by Union harmonisation legislation, which explicitly encompasses vehicle regulations. The obligations triggered by a high-risk classification — technical documentation (Article 11 and Annex IV), conformity assessment (Article 43), quality management systems (Article 17), post-market monitoring (Article 72), and incident reporting (Article 73) — all apply to AI systems in L-category vehicles once the classification threshold is met. Article 104 should also be read alongside the other amendment articles in Title XIII — including Articles 103, 105, and 106 — which collectively update several sectoral Union harmonisation regulations to ensure horizontal coherence with the EU AI Act. ## Compliance Timeline Article 104 entered into force on **1 August 2024**, twenty days after the publication of Regulation (EU) 2024/1689 in the Official Journal of the European Union on 12 July 2024. The phased application schedule of the EU AI Act determines when the substantive obligations relevant to Article 104 become enforceable: - **1 August 2024** — Entry into force; the amendments to Regulation (EU) No 168/2013 take legal effect. - **2 February 2025** — Provisions on prohibited AI practices (Article 5) become applicable; not directly relevant to Article 104 but marks the beginning of substantive enforcement. - **2 August 2025** — GPAI model obligations and governance provisions apply; manufacturers should have reviewed their AI system classifications by this date. - **2 August 2028** — High-risk AI systems listed in Annex I (which includes safety components in vehicles) must fully comply with all EU AI Act obligations. This is the critical compliance deadline for AI systems in L-category vehicles subject to Regulation (EU) No 168/2013. - **2 August 2030** — Extended deadline for certain high-risk AI systems already placed on the market before August 2024, subject to conditions in Article 111. Manufacturers of L-category vehicles incorporating AI systems should use the period up to December 2026 to complete classification assessments, conformity procedures, and documentation alignment across both regulatory frameworks. -------------------------------------------------------------------------------- ## Article 105 — Amendments to Directive 2014/90/EU (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-105/ ## Official Text Summary Article 105 of Regulation (EU) 2024/1689 (the EU AI Act) amends Directive 2014/90/EU of the European Parliament and of the Council of 23 July 2014 on marine equipment. Specifically, it inserts a new paragraph 5 into Article 8 of that Directive. Article 8 of Directive 2014/90/EU governs the Commission's mandate to pursue the development of international standards for marine equipment through the International Maritime Organization (IMO) and standardisation bodies, and empowers the Commission to adopt harmonised technical specifications and testing standards by delegated act where no adequate international standard exists (paragraph 2) or where a serious weakness in an existing standard must be remedied (paragraph 3). The newly inserted paragraph 5 reads, in substance: for AI systems which are safety components within the meaning of Regulation (EU) 2024/1689, when carrying out its activities pursuant to Article 8(1) and when adopting technical specifications and testing standards in accordance with paragraphs 2 and 3, the Commission shall take into account the requirements set out in Chapter III, Section 2, of the AI Act. Chapter III, Section 2 of the AI Act sets out the full body of obligations applicable to high-risk AI systems, including: risk management systems, data governance, technical documentation, record-keeping, transparency toward deployers, human oversight measures, accuracy, robustness, and cybersecurity. By requiring the Commission to take these requirements into account when drafting marine equipment standards, Article 105 creates a mandatory integration point between maritime safety regulation and EU AI governance. ## What This Means in Practice Article 105 operates at the level of regulatory standard-setting rather than directly imposing new duties on private operators. Its practical effect unfolds in two stages. **For the European Commission:** Whenever the Commission prepares a delegated act under Article 8 of Directive 2014/90/EU — whether to fill a gap in IMO standards or to remedy a known weakness — it must now audit the draft specifications against Chapter III, Section 2 of the AI Act if the equipment in scope includes, or may include, an AI system functioning as a safety component. This obligation applies from the date the AI Act entered into force. **For manufacturers of AI-enabled marine equipment:** The wheel mark certification pathway will progressively reflect AI Act requirements. Navigation aids, electronic chart display systems (ECDIS) with AI-driven route optimisation, autonomous collision avoidance tools, automated stability monitoring, and AI-powered distress signal detection systems are all plausible candidates. Manufacturers should expect future implementing measures to require: a documented risk management system covering the AI component's lifecycle, technical documentation demonstrating conformity with Chapter III, Section 2, logs enabling post-incident traceability, and design features ensuring human override capability. **For notified bodies and classification societies** (DNV, Bureau Veritas, Lloyd's Register, and others that assess marine equipment): their audit protocols for wheel mark certification will need to incorporate AI Act criteria as the Commission updates the relevant technical specifications. Early engagement with these bodies to understand evolving conformity assessment expectations is advisable for manufacturers currently developing AI-based marine safety components. ## Key Obligations - The European Commission must consider Chapter III, Section 2 AI Act requirements when conducting standard-monitoring activities under Article 8(1) of Directive 2014/90/EU for AI-based safety components. - When adopting harmonised technical specifications for marine equipment under Article 8(2) (gap-filling in the absence of international standards), the Commission must integrate AI high-risk system obligations where the equipment incorporates AI safety components. - When adopting corrective harmonised standards under Article 8(3) (remedying weaknesses in existing standards), the Commission must likewise apply Chapter III, Section 2 criteria to any AI component dimension of the specification. - Manufacturers of AI systems functioning as safety components within the marine equipment sector must anticipate that applicable technical specifications will embed AI Act high-risk obligations covering risk management, data governance, technical documentation, transparency, human oversight, accuracy, robustness, and cybersecurity. - Notified bodies and classification societies involved in conformity assessment under Directive 2014/90/EU must update audit frameworks as Commission delegated acts begin reflecting Chapter III, Section 2 requirements. - Economic operators (manufacturers, importers, distributors) placing wheel-mark products on the market must monitor Commission delegated acts adopted under Article 8 of Directive 2014/90/EU for updated AI-related specifications as they enter into force. ## Relationship to Other Articles Article 105 belongs to Title XIII (Final Provisions) alongside Articles 101 to 113, which collectively align pre-existing EU sectoral legislation with the AI Act's framework. It should be read in conjunction with **Article 6** and **Annex I** of the AI Act, which establish the classification of AI systems as high-risk when they serve as safety components of products governed by Union harmonisation legislation — a category that expressly includes Directive 2014/90/EU. **Chapter III, Section 2** (Articles 9 to 25) contains the substantive high-risk obligations that Article 105 incorporates by reference into marine equipment standard-setting. **Article 111** governs the AI Act's transitional arrangements for products already subject to other harmonisation legislation. Comparable sectoral amendment articles include **Article 103** (amending Directive (EU) 2016/797 on rail interoperability) and **Article 104** (amending Regulation (EU) 2018/1139 on aviation safety), making Articles 103–106 a coherent cluster addressing AI in safety-critical transport and infrastructure sectors. ## Compliance Timeline **2 August 2024 — Entry into force.** Regulation (EU) 2024/1689 was published in the Official Journal on 12 July 2024 and entered into force twenty days later. Article 105 took legal effect on this date, meaning the Commission's obligation to consider Chapter III, Section 2 requirements in its marine equipment standard-setting activities was immediately operative. **February 2025.** Provisions on prohibited AI practices (Title II) became applicable. Not directly relevant to Article 105, but relevant for any maritime operator using AI systems that could fall under prohibited categories. **August 2025.** GPAI model obligations (Title VIII) became applicable. Relevant for manufacturers integrating large foundation models into marine equipment components. **2 August 2026 — General application.** The full AI Act applies, including all Chapter III, Section 2 high-risk obligations. By this date, the Commission should be routinely applying these requirements in any new delegated acts under Directive 2014/90/EU, and manufacturers should have compliance programmes covering AI-enabled marine equipment. **2 December 2027 / 2 August 2028.** Phased deadlines for high-risk AI systems listed in Annex III (stand-alone) and Annex I (Union harmonisation legislation products) respectively. Marine equipment manufacturers relying on the Annex I pathway should use the August 2028 horizon as their target for full documentation and conformity assessment readiness. -------------------------------------------------------------------------------- ## Article 106 — Amendments to Directive (EU) 2016/797 (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-106/ ## Official Text Summary Article 106 of Regulation (EU) 2024/1689 (the EU AI Act) amends Directive (EU) 2016/797 of the European Parliament and of the Council of 11 May 2016 on the interoperability of the rail system within the European Union. The amendment inserts AI Act-aligned references and provisions into the railway interoperability framework, ensuring that the two legal instruments operate coherently where AI systems are deployed in the railway sector. The core purpose of Article 106 is legislative alignment: Directive 2016/797 governs the conditions under which rail subsystems and interoperability constituents may be placed in service across the EU, including safety assessments and the role of notified bodies. Where AI systems form part of such rail subsystems or interoperability constituents — particularly in safety-critical functions such as train control, signalling, or automated driving — the amendment ensures that the conformity assessment and supervisory obligations introduced by the AI Act are integrated into the existing railway regulatory structure rather than operating in parallel without coordination. Article 106 belongs to Title XIII (Final Provisions), which contains a series of consequential amendments to sectoral EU legislation that must be updated to reflect the AI Act's new obligations. It does not stand alone as a substantive compliance chapter but rather ensures that the railway sector's pre-existing legal framework is brought into coherent alignment with the horizontal AI regulatory architecture established by Regulation (EU) 2024/1689. ## What This Means in Practice For organisations operating in the railway sector, Article 106 has two practical consequences that compliance teams must account for simultaneously. First, any AI system integrated into a railway subsystem or interoperability constituent already subject to Directive 2016/797 must be assessed against both the railway interoperability requirements and, where applicable, the EU AI Act's high-risk AI system requirements. AI systems involved in train control, automatic train operation, infrastructure monitoring, or safety-critical maintenance functions are strong candidates for classification as high-risk AI systems under Annex I, Section 3 of the AI Act (AI in transport). This means conformity assessment procedures under both regimes apply, and compliance teams must map how the two assessments interact, which notified body or conformity assessment body is competent, and how technical documentation requirements can be harmonised. Second, national safety authorities responsible for supervising compliance with Directive 2016/797 must coordinate with the national competent authorities designated under Article 70 of the EU AI Act. Article 106 creates the legal basis for this coordination by embedding AI Act references into the railway directive, but organisations should not wait for national authorities to establish coordination protocols before acting. Proactive engagement with both the railway safety authority and the AI market surveillance authority is advisable. Practically, railway undertakings and infrastructure managers should audit their AI deployments, identify which systems fall within the scope of both Directive 2016/797 and the EU AI Act, and initiate dual-compliance documentation processes as early as possible. ## Key Obligations - **Dual-regime conformity assessment**: AI systems forming part of railway subsystems or interoperability constituents must satisfy both the conformity assessment procedures under Directive 2016/797 and, where classified as high-risk, the requirements of Chapter III of the EU AI Act. - **Coordinated supervisory engagement**: Operators must engage with both national railway safety authorities and AI Act market surveillance authorities where AI systems are deployed in safety-critical rail functions. - **Technical documentation alignment**: Providers and deployers must ensure that technical documentation prepared under Article 11 of the EU AI Act and the technical files required under Directive 2016/797 are mutually consistent and cross-referencing. - **Notified body competence verification**: Organisations must verify that conformity assessment bodies authorised under Directive 2016/797 have the competence and designation to assess AI-related components, or identify whether separate AI Act notified bodies must be involved. - **Continuous monitoring obligations**: High-risk AI systems deployed in railway operations are subject to the post-market monitoring and incident reporting obligations of the EU AI Act (Articles 72–73), which must be integrated into existing railway safety management systems. - **Legislative watch**: Because Article 106 amends Directive 2016/797 rather than creating standalone obligations, organisations must track implementing measures and guidance issued under that directive as it evolves post-amendment. ## Relationship to Other Articles Article 106 must be read alongside the substantive high-risk AI system provisions of the EU AI Act, particularly Articles 9 through 17 (risk management, data governance, technical documentation, transparency, human oversight, accuracy and robustness), and Article 43 (conformity assessment procedures for high-risk systems). Annex I, Section 3 of the AI Act, which lists AI systems in transport as a high-risk category, is the primary classification gateway for railway AI deployments affected by Article 106. Within Title XIII, Article 106 sits alongside Articles 102 through 113, which collectively amend a range of sectoral EU directives and regulations to ensure coherence with the AI Act's horizontal framework. Article 97 (review and amendments to Annexes) and Article 98 (exercise of delegation) are relevant for understanding how the Annex I classification lists — and therefore the scope of Article 106's practical impact — may evolve over time. Article 70 (designation of national competent authorities) defines the supervisory architecture that Article 106 implicitly relies upon for enforcement coordination with railway safety bodies. ## Compliance Timeline Article 106 entered into force on **1 August 2024**, the date Regulation (EU) 2024/1689 took effect, as published in the Official Journal of the European Union on 12 July 2024. However, its practical impact follows the phased application schedule of the broader EU AI Act: - **2 February 2025** — Prohibited AI practices (Article 5) became applicable. Railway operators should have assessed by this date whether any AI deployment in the rail sector met a prohibition threshold. - **2 August 2025** — GPAI model obligations and governance provisions became applicable. Railway AI systems using general-purpose AI models as components must comply from this date. - **2 August 2028** — High-risk AI systems listed in Annex I (including safety components covered by existing Union harmonisation legislation such as Directive 2016/797) must comply with Chapter III obligations, with the exception of certain systems covered by the extended transition. - **2 August 2028** — Final deadline for high-risk AI systems already placed on the market before 2 August 2026 to be brought into compliance where they have undergone significant modifications, and the latest deadline for most remaining high-risk transitional provisions. Railway sector organisations should treat 2 August 2028 as their primary hard compliance deadline for AI systems affected by Article 106's amendments, and should have conformity assessment processes well underway by the end of 2025. -------------------------------------------------------------------------------- ## Article 107 — Amendments to Regulation (EU) 2018/858 (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-107/ ## Official Text Summary Article 107 of Regulation (EU) 2024/1689 (the EU AI Act) amends Regulation (EU) 2018/858 of the European Parliament and of the Council on the approval and market surveillance of motor vehicles and their trailers, and of systems, components and separate technical units intended for such vehicles (commonly referred to as the Vehicle Type Approval Regulation). The amendment inserts a reference to the EU AI Act within the sectoral framework, ensuring that AI systems deployed in vehicles and vehicle components are subject to the horizontal obligations established by Regulation 2024/1689 alongside existing automotive safety requirements. The core effect of Article 107 is to create a legal bridge between the sector-specific type-approval regime and the cross-sectoral AI regulatory framework. Where an AI system embedded in a vehicle or vehicle component qualifies as a high-risk AI system under Annex I or Annex III of the EU AI Act, the conformity assessment procedures, technical documentation obligations, post-market monitoring requirements, and transparency obligations of the EU AI Act apply in addition to — and in coordination with — the requirements of Regulation 2018/858. Article 107 thus prevents regulatory gaps that might arise from the autonomous operation of the two regimes and establishes a coherent governance architecture for AI in the automotive sector, a domain that includes increasingly safety-critical AI applications such as advanced driver-assistance systems (ADAS) and automated driving functions. ## What This Means in Practice For vehicle manufacturers, system suppliers, and type-approval authorities, Article 107 means that the introduction of AI systems into vehicles is no longer governed solely by sector-specific type-approval procedures. Any AI component that meets the criteria for classification as a high-risk AI system — particularly those covered under Annex III of the EU AI Act relating to safety components of products regulated by Union harmonisation legislation — must simultaneously satisfy the conformity requirements of both Regulation 2018/858 and the EU AI Act. In concrete terms, an automotive OEM integrating an AI-based lane-keeping assist system or an automated emergency braking system must ensure that the AI component is accompanied by the technical documentation required under Article 11 of the EU AI Act, has undergone a conformity assessment under Article 43, carries a CE marking, and is registered in the EU database established under Article 71, in addition to meeting the technical requirements and obtaining type-approval under Regulation 2018/858. Type-approval authorities and technical services responsible for vehicle certification must therefore develop competency in evaluating AI systems against EU AI Act criteria, not only automotive safety standards. Market surveillance authorities designated under Regulation 2018/858 must coordinate with the national competent authorities designated under the EU AI Act to avoid duplicative or conflicting enforcement actions. Manufacturers should review their conformity assessment strategies, notified body relationships, and post-market monitoring systems to ensure integrated compliance across both frameworks. Suppliers of AI components entering the automotive supply chain as providers of high-risk AI systems bear independent obligations under the EU AI Act regardless of their position in the automotive supply chain hierarchy. ## Key Obligations - **Dual-framework conformity**: Manufacturers and providers of AI systems in vehicles subject to Regulation 2018/858 must comply with both the type-approval requirements of that regulation and the conformity assessment obligations of the EU AI Act where the AI system qualifies as high-risk. - **Technical documentation alignment**: Technical documentation packages prepared for type-approval must be supplemented with the AI-specific documentation required under Article 11 and Annex IV of the EU AI Act, including descriptions of training data, algorithmic logic, and risk management measures. - **Post-market monitoring integration**: Post-market monitoring systems required under Article 72 of the EU AI Act must be integrated with the conformity monitoring and field compliance obligations that apply under Regulation 2018/858, ensuring that AI performance data gathered in the field is processed and reported under both regimes. - **Serious incident reporting coordination**: Providers of high-risk AI systems in vehicles must coordinate serious incident reporting obligations under Article 73 of the EU AI Act with the vehicle safety defect reporting and recall mechanisms established under Regulation 2018/858. - **Market surveillance coordination**: National market surveillance authorities responsible for enforcement under each regulation must coordinate their activities to ensure coherent oversight of AI-enabled vehicles without duplicative or conflicting requirements imposed on economic operators. - **CE marking and registration**: AI systems meeting the high-risk threshold must carry the CE marking and be registered in the EU database for high-risk AI systems (Article 71), in addition to bearing the type-approval marking required under Regulation 2018/858. ## Relationship to Other Articles Article 107 must be read alongside the broader set of final provisions in Title XIII that amend existing Union law to integrate the EU AI Act framework. It is closely related to Article 6 and Annex I of the EU AI Act, which classify AI systems that are safety components of products covered by Union harmonisation legislation — including Regulation 2018/858 — as high-risk AI systems. The classification under Article 6(1) is the trigger that activates the dual-framework obligations which Article 107 formalises. Article 107 also connects directly to Articles 11, 43, 71, 72, and 73, which establish respectively the technical documentation, conformity assessment, database registration, post-market monitoring, and incident reporting obligations applicable to high-risk AI systems. Recital 97 of the EU AI Act provides further interpretive context on the relationship between the AI Act and sector-specific Union harmonisation legislation. The amendment introduced by Article 107 should also be read alongside Article 2(7), which addresses the interaction between the EU AI Act and existing Union law in safety-regulated sectors. ## Compliance Timeline Article 107, as part of Regulation (EU) 2024/1689, entered into force on **1 August 2024**, twenty days after publication of the regulation in the Official Journal of the European Union on 12 July 2024. The phased application schedule of the EU AI Act determines when the obligations activated by Article 107's amendment become fully enforceable in practice: - **2 February 2025**: Prohibitions on unacceptable-risk AI practices (Article 5) became applicable. These do not directly concern most automotive AI systems but establish the outer limits of permissible AI use. - **2 August 2025**: Rules on general-purpose AI models (Title III, Chapter 3) and governance provisions became applicable. Automotive AI systems built on GPAI models must satisfy the applicable GPAI obligations from this date. - **2 December 2027**: Provisions on high-risk AI systems listed in Annex III, including those related to safety components in vehicles, become fully applicable. Manufacturers and providers must have completed conformity assessments, established post-market monitoring, and ensured registration by this date. - **2 August 2028**: High-risk AI systems covered under Annex I (Union harmonisation legislation product safety frameworks, including Regulation 2018/858) must comply with all applicable EU AI Act requirements by this date. This deadline is particularly relevant for AI systems integrated into vehicles subject to type-approval. Automotive manufacturers and AI system providers are advised to begin compliance gap assessments and dual-framework conformity planning well in advance of the August 2026 and August 2027 deadlines. -------------------------------------------------------------------------------- ## Article 108 — Amendments to Regulation (EU) 2018/1139 (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-108/ ## Official Text Summary Article 108 of Regulation (EU) 2024/1689 (the EU AI Act) introduces targeted amendments to Regulation (EU) 2018/1139, which establishes the common rules for civil aviation safety and creates the European Union Aviation Safety Agency (EASA). The purpose of these amendments is to ensure regulatory coherence between the horizontal AI Act framework and the pre-existing sector-specific aviation safety regime. The article modifies Regulation (EU) 2018/1139 to reflect the definitions, risk classifications, and conformity assessment procedures introduced by the AI Act, thereby preventing conflicts or gaps between the two regulatory instruments. In particular, it clarifies that EASA acts as a competent authority and, where applicable, as a notified body for the purposes of AI Act conformity assessments relating to AI systems deployed in civil aviation. The amendments also ensure that the essential requirements and certification procedures established under aviation law are read consistently with the obligations imposed on high-risk AI systems under the AI Act. By amending the aviation safety regulation rather than carving aviation out of the AI Act entirely, Article 108 reflects the EU legislature's approach of maintaining a unified AI governance layer while allowing sector-specific bodies to carry out oversight functions with domain expertise. This preserves EASA's technical authority while bringing civil aviation AI within the scope of the AI Act's accountability, transparency, and human oversight requirements. ## What This Means in Practice For organisations operating at the intersection of artificial intelligence and civil aviation, Article 108 has concrete operational implications. **Providers and deployers of AI systems in aviation** — including systems used in flight management, autonomous aircraft operations, predictive maintenance, air traffic control assistance, or aerodrome safety — must treat these systems as high-risk AI under the EU AI Act. This triggers the full suite of obligations under Chapter III, Section 2: risk management systems, data governance requirements, technical documentation, logging capabilities, human oversight mechanisms, accuracy and robustness standards, and EU conformity assessments before market placement. **EASA as dual-authority.** Following the Article 108 amendments, EASA functions not only as the aviation safety regulator but also as the competent market surveillance authority and potential notified body for AI Act purposes in the aviation domain. Providers seeking certification for AI-enabled avionics or operational AI tools should engage EASA early, as their processes now integrate both aviation airworthiness criteria and AI Act conformity requirements. **Integrated certification pathways.** Organisations that already hold EASA type certificates or operational approvals will need to review whether those processes satisfy the AI Act's conformity assessment requirements, or whether supplementary documentation and assessments are needed. Where EASA procedures are deemed equivalent, the AI Act allows for reliance on those existing frameworks, reducing duplication. **Documentation and traceability** must be maintained to satisfy both the aviation safety dossier requirements and the technical documentation obligations under Article 11 of the AI Act. ## Key Obligations - **Align existing EASA certification processes** with the definitions and conformity assessment procedures introduced by the EU AI Act, ensuring that AI systems in civil aviation are assessed consistently under both frameworks. - **Treat AI systems in safety-critical aviation functions as high-risk**, requiring providers to implement risk management, data governance, human oversight, and transparency measures before deployment. - **Engage EASA as the competent authority** for market surveillance and, where designated, as notified body for conformity assessments of aviation AI systems, replacing or supplementing generic national authorities. - **Maintain dual-compliant technical documentation** that satisfies both the AI Act's Article 11 requirements and EASA's existing airworthiness documentation standards. - **Establish logging and record-keeping systems** that meet the traceability obligations of the AI Act while remaining compatible with aviation safety reporting and incident investigation frameworks. - **Review and update existing type certificates and operational approvals** to assess whether amendments are required to reflect AI Act obligations, particularly for AI-enabled systems introduced or substantially modified after the AI Act's entry into force. ## Relationship to Other Articles Article 108 must be read alongside the broader framework established by the EU AI Act and the sector-specific provisions it interacts with. **Annex I** of the AI Act designates civil aviation AI systems as high-risk, making Chapter III, Section 2 obligations directly applicable. **Article 6** governs the classification of high-risk AI systems and determines when sector-specific rules apply. **Article 9** (risk management), **Article 11** (technical documentation), **Article 14** (human oversight), and **Article 17** (quality management systems) set out the substantive requirements that aviation AI providers must meet. **Article 103** and the other amendment articles in Title XIII (Articles 104–112) follow the same legislative technique, amending pre-existing EU sector regulations — such as those covering machinery, medical devices, and transport — to harmonise them with the AI Act. Reading Article 108 alongside these parallel provisions helps clarify the legislature's consistent approach to cross-sectoral AI governance. Finally, **Article 9 of Regulation (EU) 2018/1139** (essential requirements for aviation safety) remains the foundational standard against which aviation AI must be assessed, now read in light of the AI Act's risk-based requirements. ## Compliance Timeline The compliance obligations arising from Article 108 are governed by the EU AI Act's phased application schedule, as supplemented by the aviation sector's own certification cycles. **August 1, 2024** — The EU AI Act entered into force. Article 108 amendments to Regulation (EU) 2018/1139 took effect as part of the overall legislative instrument, though most substantive obligations were not yet applicable. **February 2, 2025** — Prohibitions on unacceptable-risk AI practices became applicable. Aviation AI systems assessed as presenting unacceptable risks would have been prohibited from this date, though no civil aviation AI is expected to fall into this category under normal operations. **August 2, 2025** — GPAI (General-Purpose AI Model) obligations and governance framework provisions became applicable. Aviation organisations using or integrating GPAI models into operational systems needed to assess their obligations under this chapter from this date. **2 August 2028** — High-risk AI systems listed in Annex I (which includes civil aviation AI) become fully subject to all Chapter III, Section 2 obligations for new systems placed on the market. Providers should have conformity assessments, technical documentation, and registration in the EU database completed before this date for newly deployed systems. **2 August 2030** — Extended deadline for high-risk AI systems that are components of larger safety systems already subject to third-party conformity assessment under existing EU law. Some EASA-certified aviation systems may qualify for this later deadline if they meet the criteria set out in Article 111(3) of the AI Act. Organisations should engage with EASA's evolving guidance on AI Act integration — including any EASA opinions, certification memoranda, or acceptable means of compliance documents issued in 2025–2026 — to confirm which pathway applies to their specific systems and certification status. -------------------------------------------------------------------------------- ## Article 109 — Amendments to Regulation (EU) 2019/2144 (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-109/ ## Official Text Summary Article 109 of Regulation (EU) 2024/1689 (the EU AI Act) amends Regulation (EU) 2019/2144 of the European Parliament and of the Council on type-approval requirements for motor vehicles and their trailers and systems, components and separate technical units intended for such vehicles. The amendment inserts specific references and requirements to align the pre-existing vehicle type-approval framework with the horizontal obligations introduced by the AI Act. Concretely, Article 109 adds provisions ensuring that AI systems embedded in vehicles — particularly those driving automated or semi-automated functions such as advanced driver-assistance systems (ADAS), automated emergency braking, lane departure warning and driver monitoring — are subject to requirements consistent with the AI Act's risk-based approach. Where such systems meet the definition of high-risk AI systems under Annex III of Regulation 2024/1689, their deployment in vehicles must satisfy not only the technical performance criteria of Regulation 2019/2144 but also the conformity, transparency, logging and human oversight obligations of the AI Act. The article reflects the EU legislature's intent to avoid regulatory fragmentation: rather than creating a parallel track, it harmonises existing sectoral legislation with the new horizontal AI framework, making vehicle type-approval authorities and manufacturers jointly responsible for ensuring AI-specific compliance is embedded into the familiar type-approval procedure. --- ## What This Means in Practice For vehicle manufacturers, system suppliers and type-approval authorities, Article 109 has several concrete implications. **Manufacturers** developing or integrating AI-driven components — such as adaptive cruise control, automated parking systems, driver drowsiness detection or emergency steering — must assess whether those systems qualify as high-risk AI systems under the AI Act. If they do, technical documentation requirements (Article 11), automatic logging of system events (Article 12), human oversight measures (Article 14) and accuracy and robustness standards (Article 15) apply in addition to the performance benchmarks already required under Regulation 2019/2144. **Tier-1 suppliers** providing AI-enabled components to OEMs are equally in scope. They must furnish the documentation and evidence that OEMs need to complete the integrated type-approval and AI Act conformity process, and must update this information whenever a substantial modification to the AI system occurs. **National type-approval authorities** must be equipped to evaluate AI-specific evidence within the type-approval process. This may require upskilling of technical services and updating evaluation protocols to incorporate AI Act conformity checks. **Importers and distributors** placing AI-equipped vehicles on the EU market must verify that the type-approval covers the AI Act dimensions and must not make modifications that would invalidate that compliance. A practical example: a manufacturer seeking type-approval for a new passenger car with an AI-powered automatic emergency braking system must include in its type-approval application both the performance test data required by Regulation 2019/2144 and the technical documentation, risk management records and conformity assessment evidence required under the AI Act for a high-risk system. --- ## Key Obligations - **Integrated conformity assessment**: AI systems embedded in vehicles subject to Regulation 2019/2144 type-approval must satisfy the applicable AI Act conformity assessment procedures (Chapter V, Articles 43–51) before a type-approval certificate is granted or renewed. - **Technical documentation**: Manufacturers must maintain AI-specific technical documentation as required by Article 11 and Annex IV of the AI Act, covering system design, training data governance, validation processes and known limitations, alongside existing type-approval technical files. - **Automatic logging**: AI systems performing automated or semi-automated driving functions must incorporate logging capabilities as specified in Article 12, enabling reconstruction of system behaviour during incidents for investigation by authorities. - **Human oversight by design**: Vehicles incorporating high-risk AI functions must implement human oversight measures under Article 14, ensuring drivers can monitor, interrupt or override AI-driven actions under reasonably foreseeable conditions. - **Substantial modification review**: Any substantial modification to an AI system already covered by a type-approval triggers a re-assessment obligation, requiring updated documentation and potentially a new or amended type-approval under the combined frameworks. - **Market surveillance coordination**: National type-approval authorities and AI Act market surveillance authorities must coordinate to avoid duplicative or conflicting oversight actions, sharing relevant findings about AI system performance in the field. --- ## Relationship to Other Articles Article 109 sits within Title XIII (Final Provisions) and is one of several amendment articles that stitch the AI Act into pre-existing sectoral legislation. It should be read alongside **Article 2** (scope) to understand when the AI Act's rules apply to vehicle-embedded systems, and **Annex III** (list of high-risk AI systems) where point 4 covers AI systems used in the management and operation of road transport infrastructure and safety-critical vehicle functions. **Articles 11–15** (high-risk AI system obligations on technical documentation, record-keeping, transparency, human oversight, and accuracy) set the substantive standards that Article 109 causes to flow into the type-approval process. **Articles 43–51** (conformity assessment procedures) define the procedural route manufacturers must follow. **Article 112**, which amends Directive 2006/42/EC on machinery, pursues a parallel logic in the industrial machinery sector and provides useful interpretive context for how the EU legislature approaches embedding AI Act obligations into sectoral approval regimes. --- ## Compliance Timeline The EU AI Act was published in the Official Journal on 12 July 2024 and entered into force on **1 August 2024**. Its application is phased: - **2 February 2025** — Prohibited AI practices (Title II, Article 5) became applicable. - **2 August 2025** — Rules on general-purpose AI models (Title VIII, Articles 51–56) and governance provisions became applicable. - **2 August 2026** — The main body of the AI Act, including the amendment articles in Title XIII and **Article 109**, becomes fully applicable; the substantive high-risk obligations of Chapter III follow on 2 December 2027 for Annex III systems and 2 August 2028 for Annex I products. From this date, type-approvals involving AI systems must reflect the amended Regulation 2019/2144 requirements. - **2 August 2028** — High-risk AI systems covered by Annex I (existing Union harmonisation legislation) benefit from an extended transition; vehicle systems that fall exclusively under that annex may continue under prior rules until this date. Manufacturers and suppliers are advised to begin conformity gap analyses and integrate AI Act documentation requirements into their type-approval preparation processes well before August 2026 to avoid delays in product launches. -------------------------------------------------------------------------------- ## Article 11 — Technical documentation (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-11/ ## Official Text Summary Article 11 of Regulation (EU) 2024/1689 (the EU AI Act) establishes the obligation for providers of high-risk AI systems to draw up technical documentation before placing such a system on the market or putting it into service, and to keep that documentation up to date throughout the system's lifecycle. The article directs that technical documentation must be compiled in a manner that demonstrates the system's compliance with the requirements laid down in Title III, Chapter 2 of the Regulation — the full set of requirements applicable to high-risk AI systems. The documentation must contain, at minimum, all the information specified in Annex IV of the Regulation. Annex IV enumerates eight categories of required information: (1) a general description of the system and its intended purpose; (2) a detailed description of the system's elements and the development process; (3) information on the monitoring, functioning, and control of the system; (4) a description of the risk management process followed pursuant to Article 9; (5) a description of changes made to the system over its lifecycle; (6) a list of harmonised standards applied and other technical standards relied upon; (7) a copy of the EU declaration of conformity required under Article 47; and (8) post-market monitoring plans as required by Article 72. The article also provides that the Commission may adopt delegated acts to amend Annex IV where technological developments make it necessary, ensuring that documentation requirements remain current and relevant as the technology evolves. ## What This Means in Practice Article 11 requires providers — not deployers, not distributors — to produce and maintain a structured technical file for every high-risk AI system they bring to market or put into service within the EU. This is a pre-market obligation: the documentation must exist before the system is released, not assembled after the fact. For an AI provider building, for example, a credit-scoring tool used by a bank (an Annex III, point 5(b) system), this means producing a living document that captures not only what the model does and how it was trained, but also how risks were identified and mitigated (Article 9), how the system was tested and validated (Article 9(8)), what data governance measures apply (Article 10), and how the system can be monitored and audited post-deployment (Article 72). The "up to date" requirement is operationally significant. Any material change to the system — a model retrain, a significant update to training data, a change in intended purpose, or an expansion to a new deployment context — must be reflected in revised documentation. Providers should therefore treat technical documentation not as a one-time compliance artefact but as a version-controlled record that tracks the system's development history. For providers established outside the EU, the authorised representative designated under Article 22 must hold the documentation and be able to present it to national market surveillance authorities or notified bodies on request. National authorities may demand access to technical documentation during conformity assessments and post-market surveillance activities, including in the context of serious incident investigations under Article 73. Notified bodies involved in third-party conformity assessment (required for certain high-risk categories, as set out in Article 43) will scrutinise technical documentation as the primary evidentiary basis for issuing an EU technical documentation assessment certificate. ## Key Obligations - Draw up complete technical documentation in accordance with Annex IV before the high-risk AI system is placed on the market or put into service. - Keep documentation up to date throughout the system's operational lifecycle, reflecting any significant changes to the system, its training data, or its deployment context. - Ensure documentation is sufficiently detailed to allow national competent authorities and notified bodies to assess conformity with all Title III, Chapter 2 requirements. - Include a description of the risk management process (Article 9), data governance measures (Article 10), and post-market monitoring plans (Article 72) as integral components of the documentation. - Make documentation available to market surveillance authorities, notified bodies, and other designated national authorities upon request, within the timeframes those bodies specify. - Retain technical documentation for ten years after the system is placed on the market or put into service, in accordance with Article 18. ## Relationship to Other Articles Article 11 sits at the centre of the conformity infrastructure for high-risk AI systems and cannot be read in isolation. It draws directly on Article 9 (risk management system), as the risk management process and its outcomes must be documented in the technical file. Article 10 (data and data governance) contributes the data-related elements required under Annex IV. Article 12 (record-keeping) complements Article 11 by requiring automatic logging of events throughout the system's operation, logs that themselves form part of the broader documentation landscape. Article 43 (conformity assessment) is the primary downstream consumer of Article 11: notified bodies conducting third-party assessments rely on technical documentation as their core evidentiary input. Article 47 (EU declaration of conformity) requires a copy of that declaration to be incorporated into the technical file itself. Article 18 sets the ten-year retention period for technical documentation. Article 72 (post-market monitoring) and Article 73 (serious incident reporting) generate information that must flow back into updated documentation over the system's life. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024 (twenty days after publication in the Official Journal on 12 July 2024). Application of the Act is phased: - **February 2, 2025** — Prohibitions on unacceptable-risk AI practices (Article 5) became applicable. Article 11 does not apply at this stage. - **August 2, 2025** — Obligations relating to general-purpose AI models (Title VIII) became applicable. Article 11 obligations do not yet apply to providers of high-risk AI systems at this date. - **2 December 2027** — High-risk AI systems listed in Annex III (points 1 to 7, excluding point 5(b)) become subject to the full Title III requirements, including Article 11. Providers must have complete technical documentation in place by this date. - **2 August 2028** — High-risk AI systems listed in Annex I (safety components of products already subject to Union harmonisation legislation) become subject to Article 11, with some additional time allowed for systems already on the market before August 2, 2026. Providers who have not yet initiated their technical documentation processes should treat August 2026 as a hard deadline and build documentation drafting into their development workflows immediately. The complexity of Annex IV and the iterative nature of AI development mean that documentation assembled retrospectively rarely meets the standard authorities will apply. -------------------------------------------------------------------------------- ## Article 110 — Amendment to the Representative Actions Directive (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-110/ Article 110 is one sentence with long reach: it adds the AI Act to Annex I of Directive (EU) 2020/1828 — the list of laws whose breach can be pursued through consumer representative actions. AI compliance failures become collectively litigable. ## Official Text Summary Article 110 amends Directive (EU) 2020/1828 on representative actions for the protection of the collective interests of consumers by adding the AI Act to its Annex I — the catalogue of Union law provisions whose infringement can be pursued through representative actions. Qualified entities designated by the Member States, typically consumer organisations, may bring actions for injunctive measures and for redress on behalf of consumers harmed by infringements of the Regulation. For providers and deployers of consumer-facing AI, this quietly changes the risk calculus: regulatory fines are no longer the only downside scenario, because the same infringement can also fuel coordinated private litigation. ## Key Obligations - The AI Act joins Annex I of Directive (EU) 2020/1828 on representative actions for the protection of consumers' collective interests - Qualified entities — consumer organisations designated by Member States — may seek injunctions and redress on behalf of groups of consumers harmed by infringements of the Act - Practical effect: an AI Act breach that harms consumers at scale can produce one coordinated action rather than thousands of individual claims ## Compliance Timeline Applies from 2 August 2026; the 2026 Digital Omnibus deferred the substantive high-risk obligations (Annex III to 2 December 2027, Annex I to 2 August 2028) but did not move this provision. -------------------------------------------------------------------------------- ## Article 111 — Transitional provisions (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-111/ ## Official Text Summary Article 111 of Regulation (EU) 2024/1689 establishes transitional provisions designed to ease the shift from the pre-Regulation legal landscape to the new EU AI Act framework. The article applies primarily to high-risk AI systems — those listed in Annex I (AI systems regulated by Union harmonisation legislation) and Annex III (standalone high-risk AI systems) — that were already placed on the market or put into service before the dates on which the relevant obligations become fully applicable. Under Article 111, such systems are not immediately required to achieve full compliance provided they are not subject to a substantial modification as defined in Article 3(23) of the Regulation. Where no substantial modification occurs, providers and deployers may continue operating these systems under a grace period that runs until 2 August 2028 for most high-risk categories, and until 2 August 2030 for certain AI systems regulated under Annex I that are also subject to existing Union harmonisation legislation. For AI systems that are components of larger infrastructure — particularly in regulated sectors such as medical devices, machinery, or civil aviation — Article 111 coordinates with existing product safety regimes, allowing continued reliance on prior conformity assessments where they remain valid. The transitional provisions do not apply to AI systems prohibited under Article 5, which became enforceable in February 2025 and admit no delay. Providers wishing to invoke transitional provisions bear the burden of demonstrating that their system has not been substantially modified and was legitimately on the market prior to the relevant threshold date. ## What This Means in Practice For businesses that deployed AI systems before the EU AI Act's phased obligations took effect, Article 111 provides a structured compliance runway rather than an immediate retrofit requirement. In practice, this means that a company running a high-risk AI-based recruitment screening tool deployed in 2023 does not need to achieve full Regulation compliance — including conformity assessments, technical documentation, and registration in the EU database — until 2 August 2027, as long as the tool has not been substantially modified. The concept of "substantial modification" is therefore pivotal. If a provider updates the underlying model, changes the purpose of the system, or alters its outputs in a way that affects safety or fundamental rights, that update likely triggers immediate compliance obligations rather than the transitional grace period. Providers should document all updates and changes to existing AI systems carefully, ideally with a change-log and an internal legal assessment of whether each update constitutes a substantial modification. Deployers using third-party AI tools also need to be alert: if their provider issues a major product update, the deployer must reassess whether the transitional protection still applies. Organisations should not assume that legacy deployment status is indefinitely preserved. Practically, the transitional period should be used proactively. Rather than waiting until 2027, compliance teams should treat this window as a runway to build conformity assessment processes, appoint a responsible person for AI governance where required, map high-risk systems against Annex III categories, and begin technical documentation. Early movers will be better positioned for the 2027 deadline and less exposed to regulatory scrutiny if an incident occurs during the transitional period. ## Key Obligations - **Identify legacy systems:** Providers must determine which AI systems were placed on the market or put into service before the relevant application date and therefore qualify for transitional treatment under Article 111. - **Monitor for substantial modifications:** Any update, upgrade, or repurposing of a transitional AI system must be assessed against the definition in Article 3(23); a substantial modification ends the transitional period immediately for that system. - **Maintain documentation of prior market placement:** To invoke transitional provisions, providers should retain evidence — such as purchase records, deployment contracts, or version histories — demonstrating that the system was on the market before the relevant threshold date. - **Prepare for full compliance by 2 December 2027:** For most high-risk AI systems under Annex III, the transitional period expires on this date; full conformity with Title III (high-risk AI obligations) is required from that point. - **Respect the 2028 deadline for Annex I regulated products:** AI systems embedded in products governed by existing Union harmonisation legislation listed in Annex I benefit from an extended transitional period until 2 August 2028, provided no substantial modification occurs and existing conformity assessments remain valid. - **No transitional relief for prohibited AI practices:** Article 5 prohibited practices — including certain biometric categorisation systems and real-time remote biometric identification — applied from 2 February 2025 and are not covered by Article 111 transitional arrangements under any circumstances. ## Relationship to Other Articles Article 111 functions as the operational counterpart to Article 113 (Entry into force and application), which sets the master phased timeline for the entire Regulation. Together, these two final provisions form the temporal architecture of the EU AI Act. Article 111 must also be read alongside Article 3(23), which defines "substantial modification" — the concept that determines whether a legacy system loses its transitional status. The article connects directly to the obligations in Title III, Chapter 2 (Articles 8–15), which establish the full suite of requirements for high-risk AI systems, including risk management, data governance, technical documentation, transparency, human oversight, accuracy, and robustness. Providers using Article 111 relief are effectively deferring these obligations, not eliminating them. Article 111 also interacts with Article 47 (EU declaration of conformity) and Article 49 (CE marking), since transitional systems may retain prior conformity marks during the grace period. For systems in regulated sectors, it must be read alongside the relevant Union harmonisation legislation listed in Annex I, including the Medical Devices Regulation and the Machinery Regulation. ## Compliance Timeline **2 August 2024** — Regulation (EU) 2024/1689 entered into force. From this date, the transitional provisions of Article 111 became legally operative, establishing which systems qualify as pre-existing. **2 February 2025** — Prohibited AI practices under Article 5 became enforceable. Article 111 provides no relief for systems falling into these categories. **2 August 2025** — GPAI model obligations (Title VII) became applicable. Transitional provisions under Article 111 do not extend to GPAI-specific requirements. **2 August 2026** — The general application date for most of the Regulation, including high-risk AI obligations under Title III. Systems already on the market before this date may invoke Article 111 transitional status. **2 December 2027** — Transitional period expires for the majority of high-risk AI systems listed in Annex III. Full compliance with all applicable Title III requirements is mandatory from this date. **2 August 2028** — Extended transitional deadline for AI systems that are safety components of, or themselves constitute, products governed by Annex I Union harmonisation legislation (e.g., medical devices, machinery), provided no substantial modification has occurred and existing conformity assessments remain valid. -------------------------------------------------------------------------------- ## Article 112 — Evaluation (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-112/ ## Official Text Summary Article 112, situated within Title XIII (Final Provisions) of Regulation (EU) 2024/1689, establishes a mandatory evaluation mechanism through which the European Commission must periodically assess the operation and impact of the EU AI Act. The Commission is required to submit evaluation reports to the European Parliament and to the Council of the European Union at defined intervals, with the first report due no later than three years after the date of application of the regulation. The scope of these evaluations is comprehensive. The Commission must assess whether the regulation's objectives are being met effectively, whether any amendments are necessary to adapt to technological change or market developments, and whether the rules on prohibited AI practices and high-risk AI systems remain proportionate and fit for purpose. The evaluation must also examine the impact of the regulation on fundamental rights, the internal market, and innovation, as well as the adequacy of the governance and enforcement architecture, including the functioning of national competent authorities and the European AI Office. Where evaluation findings indicate that the regulation no longer adequately addresses emerging risks, the Commission may accompany the report with a legislative proposal to amend the regulation. Member States are expected to provide the Commission with the data and information necessary to carry out these assessments, ensuring that evaluations are grounded in empirical evidence drawn from real-world application across the Union. ## What This Means in Practice Article 112 does not impose direct compliance obligations on AI developers, providers, or deployers. Its obligations fall on the European Commission as an institutional actor. Nevertheless, the evaluation mechanism has significant indirect implications for all stakeholders operating under the EU AI Act. For AI providers and deployers, the evaluation cycle signals that the regulatory environment is deliberately designed to evolve. Obligations that apply today — including conformity assessments, transparency requirements, and registration duties — may be extended, amended, or refined in response to Commission findings. Organisations building long-term compliance programmes should treat Article 112 as a reminder that the EU AI Act is a living instrument, not a static rulebook. For Member States and national supervisory authorities, Article 112 implies a duty to collect and transmit enforcement data, incident records, and market surveillance statistics that feed into the Commission's evidence base. Authorities that fail to build adequate data collection infrastructure risk hampering the quality of the evaluation and, indirectly, the accuracy of any subsequent legislative revision. For industry associations and civil society, the evaluation process creates a formal channel for influencing future regulatory development. The Commission is expected to consult stakeholders when preparing evaluation reports, meaning that documented evidence of compliance burdens, enforcement gaps, or unintended consequences can directly shape the next iteration of the rules. In practical terms, large AI providers should anticipate periodic information requests from national authorities or the Commission itself as part of the evaluation data-gathering process, and should maintain accessible records of conformity activities accordingly. ## Key Obligations - The European Commission must conduct periodic evaluations of the EU AI Act and submit reports to the European Parliament and the Council at regular intervals, with the first report due no later than three years after the date of application. - Each evaluation must assess the effectiveness of the regulation in achieving its stated objectives, including the protection of fundamental rights, safety, and the proper functioning of the internal market. - The evaluation must examine whether the list of prohibited AI practices in Annex I and the classification of high-risk AI systems in Annexes II and III remain appropriate and proportionate in light of technological and market developments. - The evaluation must consider the performance of the governance architecture, including the European AI Office, the AI Board, and national competent authorities, as well as the adequacy of market surveillance mechanisms. - Where warranted by evaluation findings, the Commission may submit a legislative proposal to amend the regulation alongside the evaluation report. - Member States must provide the Commission with data and information necessary to carry out the evaluations, supporting an evidence-based review process. ## Relationship to Other Articles Article 112 connects directly to the governance framework established in Title VI and Title VII of the regulation. The institutions whose effectiveness is evaluated — the European AI Office (Article 64), the AI Board (Article 65), and the Advisory Forum (Article 66) — are the operational actors whose performance the Commission must assess. The evaluation also intersects with Article 111, which addresses reporting and review of the regulation's financial and enforcement architecture. Article 112 should be read alongside Articles 113 and 114, which govern the formal amendment and entry into force procedures, since evaluation findings may trigger the legislative processes those articles describe. The article also connects to Articles 85 and 93, which establish Member State obligations to monitor and report on the regulation's application — data that directly feeds into the Commission's evaluation evidence base. Recital 168 provides additional interpretive context on the rationale for periodic review in a rapidly evolving technological domain. ## Compliance Timeline Article 112 is governed by the EU AI Act's phased application schedule, which began with the regulation's entry into force on 1 August 2024. - **1 August 2024** — Regulation entered into force; the evaluation clock begins. - **2 February 2025** — Prohibitions on unacceptable-risk AI practices became applicable (Article 5); these classifications are subject to review under Article 112 evaluations. - **2 August 2025** — GPAI model obligations (Title VIII) became applicable; their adequacy falls within the evaluation scope. - **2 August 2026** — Governance and enforcement provisions fully applicable; national authority performance becomes formally assessable. - **2 December 2027 / 2 August 2028** — High-risk AI system obligations under Annex III and Annex I respectively become fully applicable; the conformity assessment architecture becomes a primary evaluation subject. - **By approximately August 2029** — The Commission must submit its first evaluation report to the European Parliament and the Council, covering the regulation's operation since application began. Organisations should expect that the Commission will begin informal data-gathering activities well before the formal report deadline, and should be prepared to engage with national supervisory authorities providing evidence to the evaluation process from 2027 onward. -------------------------------------------------------------------------------- ## Article 113 — Entry into force and application (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-113/ ## Official Text Summary Article 113 of Regulation (EU) 2024/1689 — the EU AI Act — establishes the date on which the Regulation entered into force and the phased schedule by which its individual provisions become applicable. The Regulation entered into force on the twentieth day following its publication in the Official Journal of the European Union, which occurred on 12 July 2024, placing the entry-into-force date at 1 August 2024. The article then lays out a differentiated application timetable. The Regulation applies in full from 2 August 2026, which is two years after the entry-into-force date. However, several clusters of provisions apply earlier. Chapter I (general provisions) and Chapter II (prohibited AI practices) became applicable six months after entry into force, on 2 February 2025. Chapter V (general-purpose AI models), Chapter VII (governance), Chapter XII (penalties), and certain other provisions apply twelve months after entry into force, from 2 August 2025. Provisions relating to high-risk AI systems listed in Annex I — those embedded in products already subject to Union harmonisation legislation — apply from 2 August 2028, giving that sector a three-year adaptation window from the entry-into-force date. This staggered structure reflects the legislature's intent to prioritise the elimination of the most serious risks first, while granting industry and national authorities adequate time to build compliance infrastructure for the more technically complex obligations. ## What This Means in Practice For organisations developing, deploying, or using AI systems within the scope of Regulation 2024/1689, Article 113 defines the operative compliance calendar against which all internal readiness programmes must be benchmarked. Providers and deployers of prohibited AI systems — such as social scoring systems or real-time remote biometric identification in public spaces — had no grace period beyond 2 February 2025. Any system in one of the prohibited categories that remained in use after that date exposed the operator to enforcement action under the Regulation's penalties framework. Providers of general-purpose AI models, including frontier models with systemic risk, faced the next hard deadline: 2 August 2025. From that date, GPAI model providers must maintain technical documentation, comply with copyright transparency requirements, and — where systemic risk is identified — conduct adversarial testing and incident reporting obligations. For providers of high-risk AI systems falling under Annex III categories (employment, education, essential services, law enforcement, migration, and administration of justice), the full conformity assessment, technical documentation, and post-market monitoring obligations apply from 2 December 2027. Organisations should have completed gap analyses, appointed EU-authorised representatives where required, and registered systems in the EU database well before that date. Manufacturers placing high-risk AI as a safety component into products regulated by Annex I legislation (machinery, medical devices, civil aviation equipment) have until 2 August 2028, but should not treat this extended window as an invitation to delay, given the lead time required for notified-body conformity assessments. ## Key Obligations - **Immediate effect from 1 August 2024:** The Regulation is legally binding across all EU Member States from the entry-into-force date; no national transposition is required. - **Prohibited practices ban from 2 February 2025:** Chapter II prohibitions are directly enforceable; organisations must have removed or ceased operating any prohibited AI system by this date. - **GPAI compliance from 2 August 2025:** Providers of general-purpose AI models must meet transparency, documentation, and systemic-risk obligations under Chapter V from this date. - **Full Regulation application from 2 December 2027:** All remaining obligations — including high-risk system requirements under Annex III — become enforceable; this is the primary compliance deadline for most market actors. - **Annex I high-risk systems deadline of 2 August 2028:** Providers of AI safety components embedded in products governed by existing Union harmonisation legislation have an additional year to achieve compliance. - **Governance and AI Office provisions from August 2024/2025:** National competent authorities and the AI Office at EU level are operational and exercising supervisory functions throughout the phased application period. ## Relationship to Other Articles Article 113 must be read alongside Article 111 (transitional provisions), which governs the treatment of AI systems already on the market before 2 August 2026, and Article 112 (delegated acts), which grants the Commission authority to update certain Annexes during the application period. The phased timetable in Article 113 directly activates the substantive obligations set out in Chapter II (prohibited practices, Article 5), Chapter V (general-purpose AI models, Articles 51–56), Chapter VI (measures supporting innovation, Articles 57–63), and Chapter VII (governance, Articles 64–70). Penalties under Article 99 and Article 101 only become enforceable as each cluster of provisions reaches its application date, meaning Article 113 effectively regulates the chronological scope of the enforcement powers conferred throughout the Regulation. National market surveillance authorities deriving their mandate from Article 74 began exercising jurisdiction progressively in line with the same schedule. ## Compliance Timeline | Date | Event | |---|---| | 12 July 2024 | Regulation (EU) 2024/1689 published in the Official Journal of the EU | | 1 August 2024 | Entry into force (Article 113, paragraph 1) | | 2 February 2025 | Chapter I and Chapter II (prohibited AI practices) applicable — six-month mark | | 2 August 2025 | Chapter V (GPAI models), Chapter VII (governance), Chapter XII (penalties), and related provisions applicable — twelve-month mark | | 2 August 2026 | Regulation fully applicable to all in-scope AI systems — general application date | | 2 August 2028 | Application extended to high-risk AI systems embedded in Annex I product categories | Organisations should treat 2 December 2027 as the primary compliance deadline driving internal project plans, with the February 2025, August 2025 and 2 August 2026 milestones already passed. The window for completing conformity assessments, technical documentation and EU database registration for Annex III high-risk systems closes on that date. For Annex I embedded systems the deadline is 2 August 2028, but notified-body capacity constraints make early engagement essential. -------------------------------------------------------------------------------- ## Article 12 — Record-keeping (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-12/ ## Official Text Summary Article 12 of Regulation (EU) 2024/1689 establishes mandatory record-keeping requirements for high-risk AI systems. The article sits within Title III, Chapter 2, which sets out the technical and governance requirements that high-risk AI systems must satisfy before being placed on the EU market or put into service. The core obligation is that high-risk AI systems must be designed and developed with logging capabilities that enable the automatic recording of events — commonly referred to as logs — over the system's operational lifetime. These logs serve a dual purpose: supporting post-market monitoring by the provider under Article 72, and enabling national competent authorities to exercise their supervisory and investigative functions. Article 12(2) specifies that logging capabilities must, at minimum, record the period of each use of the system (start and end date and time), the reference database against which input data has been checked where applicable, input data that led to a given output or result, and — where biometric identification systems are concerned — the identity of natural persons involved in the verification of the results. The article places the design obligation squarely on providers. Logging must be built into the system by construction, not added retrospectively. This reflects the Regulation's broader by-design philosophy. Operators who deploy these systems bear complementary obligations under Article 26 to preserve logs generated during their use of the system, to the extent such logs are under their control. ## What This Means in Practice For providers developing or placing high-risk AI systems on the EU market, Article 12 requires engineering-level decisions to be made during the design phase, not after deployment. Logging must be an architectural feature of the product. **Affected parties.** Any organisation that develops, places on the market, or puts into service a high-risk AI system as defined under Article 6 and Annex III is subject to Article 12. This includes systems used in employment screening, credit scoring, biometric identification, critical infrastructure management, educational assessment, law enforcement, border control, and administration of justice, among others. Operators — organisations that deploy a provider's high-risk AI system in their own context — have secondary obligations to maintain logs they control. **Concrete actions required.** A provider must implement automated logging that captures the required data points without manual intervention. For example, a provider of an AI-assisted CV-screening tool must ensure the system logs each recruitment session, the dataset version used to train or calibrate the model, and the inputs (applicant profiles) that generated each output (ranking or recommendation). An operator deploying that tool must retain those logs and make them available to authorities on request. **Investigative utility.** Logs exist primarily to enable retrospective analysis. If a system produces a discriminatory outcome or causes harm, regulators must be able to reconstruct what happened. Logs that are incomplete, overwritten, or inaccessible defeat this purpose and expose both provider and operator to enforcement risk. **Proportionality.** The specific scope of what must be logged is calibrated to the type of system. Biometric systems face the most granular requirements. Providers should document their logging design decisions in technical documentation as required by Article 11. ## Key Obligations - **Logging by design.** High-risk AI systems must be designed and developed with automatic event-logging capabilities built into the system architecture before market placement or deployment. - **Minimum log content.** Logs must capture, at minimum: the operational period of each use session, the reference database used for input verification where applicable, the input data that produced each output or decision, and — for biometric identification systems — the identities of natural persons who verified results. - **Operator log retention.** Operators must retain logs generated during their use of a high-risk AI system for the period required by applicable law and, at minimum, for the duration necessary to support post-market monitoring and regulatory investigations. - **Accessibility to authorities.** Logs must be available to national competent authorities upon request to facilitate supervisory oversight, incident investigation, and market surveillance activities. - **Traceability of outputs.** The logging system must enable the reconstruction of a causal chain from a specific input to a specific output, supporting accountability and the right to explanation where it applies. - **Alignment with technical documentation.** The logging architecture and its scope must be described in the technical documentation maintained under Article 11, ensuring consistency between the system as designed and the system as monitored. ## Relationship to Other Articles Article 12 cannot be read in isolation. It operates as part of a network of interconnected requirements in Title III, Chapter 2. **Article 9 (Risk management system)** establishes the overarching framework within which logging feeds — logs generate the operational data needed to identify and assess risks in real-world deployment. **Article 11 (Technical documentation)** requires providers to document the logging architecture and capabilities as part of the broader technical file submitted to notified bodies or retained for regulatory inspection. **Article 17 (Quality management system)** requires providers to maintain a quality management system that integrates logging into broader operational controls and corrective action procedures. **Article 26 (Obligations of deployers)** assigns to operators the obligation to retain logs under their control and to cooperate with providers and authorities, making Article 12 a shared responsibility across the supply chain. **Article 72 (Post-market monitoring)** is the downstream consumer of Article 12 logs — the monitoring system relies on operational logs to detect performance degradation, unexpected outputs, and emerging risks after deployment. **Article 73 (Reporting of serious incidents)** uses log data as primary evidence when providers are required to report serious malfunctions or incidents to market surveillance authorities. ## Compliance Timeline The EU AI Act (Regulation 2024/1689) entered into force on **1 August 2024**, twenty days after publication in the Official Journal of the European Union. Application of the Regulation is phased: - **2 February 2025** — Prohibitions on unacceptable-risk AI practices (Title II, Article 5) became applicable. - **2 August 2025** — Rules on general-purpose AI models (Title VIII) and governance obligations (Title III, Chapter 4 on notified bodies; Title VI on governance) became applicable. - **2 December 2027** — Obligations for high-risk AI systems listed in Annex III begin to apply for most categories. **Article 12 falls within this phase.** Providers and operators of high-risk AI systems must have compliant logging capabilities in place by this date. - **2 August 2028** — Extended deadline for high-risk AI systems covered by existing sectoral Union harmonisation legislation listed in Annex I (e.g. machinery, medical devices), giving those sectors additional time to adapt existing conformity assessment frameworks. Organisations developing high-risk AI systems should treat **2 December 2027** as the hard compliance deadline for Article 12 logging requirements, with design and testing of logging infrastructure completed well in advance to allow for conformity assessment procedures under Article 43. -------------------------------------------------------------------------------- ## Article 13 — Transparency and provision of information to deployers (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-13/ ## Official Text Summary Article 13 of Regulation (EU) 2024/1689 (the EU AI Act) establishes transparency obligations applicable to high-risk AI systems as defined in Title III. It requires providers to design and develop high-risk AI systems in a way that allows deployers to understand and correctly interpret the outputs of such systems and to use them appropriately. The article's central mechanism is the mandatory provision of instructions for use — a structured document that must accompany every high-risk AI system placed on the market or put into service. Article 13(3) sets out the minimum content of this document in detail. It must include: the identity and contact details of the provider; the characteristics, capabilities, and limitations of the system, including its intended purpose and the specific contexts for which it has been validated; the level of accuracy, robustness, and cybersecurity against which the system has been tested, together with any known and foreseeable circumstances that may affect that performance; where relevant, technical capabilities concerning human oversight, including measures to facilitate interpretation of outputs; and guidance on the input data and the hardware and software environment in which the system is intended to operate. The transparency required by Article 13 is not merely informational: it is a prerequisite for the meaningful human oversight mandated by Article 14. Providers cannot satisfy Article 14 obligations if deployers lack the understanding that Article 13 is designed to convey. ## What This Means in Practice For organisations developing or marketing high-risk AI systems, Article 13 translates into a concrete documentation obligation that must be embedded in the product development lifecycle rather than treated as an afterthought. **For providers**, this means producing instructions for use that go well beyond a standard technical manual. The document must be calibrated to a deployer audience — typically an organisation procuring the AI system for a specific operational context, not necessarily an AI engineer. Concrete examples of what must be covered include: the accuracy rates achieved during validation broken down by relevant population subgroups where applicable (important for systems used in recruitment or creditworthiness assessments); the types of input data the system has been trained on and what deviations from that distribution might cause degraded performance; and specific guidance on how a human reviewer should interpret a confidence score or risk flag produced by the system. **For deployers**, Article 13 is the foundation of the due diligence process before deployment. A deployer procuring a high-risk AI system should verify that the instructions for use are present and substantive. Absence of adequate instructions is itself a compliance signal about the provider. Deployers in regulated sectors — credit institutions, healthcare providers, public authorities — should incorporate review of Article 13 documentation into their vendor assessment and procurement procedures. **Practical examples**: A provider of an AI-based CV-screening tool (high-risk under Annex III, point 4) must document its accuracy across demographic groups and the conditions under which the system's outputs should not be relied upon without human review. A provider of an AI system used for credit scoring must specify the data inputs it requires and the statistical confidence of its risk classifications. ## Key Obligations - **Design for interpretability**: High-risk AI systems must be designed and developed so that their operation is sufficiently transparent for deployers to interpret outputs and use the system appropriately (Article 13(1)). - **Supply instructions for use**: Providers must supply instructions for use in digital or physical form with every high-risk AI system placed on the market or put into service (Article 13(2)). - **Disclose identity and contact information**: Instructions must identify the provider and provide contact details enabling the deployer to communicate compliance-related queries (Article 13(3)(a)). - **Document capabilities and limitations**: The instructions must describe the system's intended purpose, its performance levels as validated, known or foreseeable circumstances in which performance may fall below documented levels, and any known biases (Article 13(3)(b)). - **Specify input data requirements**: Where relevant to performance, instructions must describe the nature, format, and provenance of data the system requires as input (Article 13(3)(c)). - **Enable human oversight**: Instructions must include information on the measures incorporated into the system to support the human oversight obligations of Article 14, including guidance on how to interpret and act on the system's outputs (Article 13(3)(d) and (e)). ## Relationship to Other Articles Article 13 sits at the intersection of several interlocking obligations in Title III, Chapter 2. It is operationally inseparable from **Article 14 (Human oversight)**: the measures enabling human oversight described in Article 13(3)(d) are the direct informational precondition for deployers being able to exercise the oversight duties Article 14 imposes on them. Without adequate Article 13 instructions, Article 14 compliance is structurally impossible. Article 13 draws on the technical documentation produced under **Article 11**, which requires providers to maintain comprehensive documentation of their high-risk AI systems. The instructions for use are a deployer-facing extract of that broader body of documentation. The obligations interact with **Article 16** (obligations of providers) and **Article 26** (obligations of deployers), which frame how each party must fulfil its respective role once the system is on the market. For systems undergoing conformity assessment under **Article 43**, the instructions for use constitute a required element of the conformity assessment file examined by notified bodies. Finally, Article 13 connects to **Article 50** (transparency obligations for certain AI systems) in that both address transparency, but Article 50 targets a different context — AI systems interacting with natural persons rather than professional deployers. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024, twenty days after its publication in the Official Journal of the European Union. Application is phased: - **2 February 2025**: Prohibitions on unacceptable-risk AI practices (Article 5) became applicable. - **2 August 2025**: Rules governing general-purpose AI models (Title VIII, Articles 51–56) and governance obligations became applicable. - **2 December 2027**: Article 13 becomes applicable to high-risk AI systems listed in **Annex III** (standalone high-risk systems, including those used in biometric identification, critical infrastructure, education, employment, essential services, law enforcement, migration, and administration of justice). - **2 August 2028**: Article 13 becomes applicable to high-risk AI systems covered by **Annex I** (AI systems that are safety components of products subject to existing EU product-safety legislation, such as machinery, medical devices, and civil aviation equipment). Providers targeting the August 2026 deadline should treat the current period as active preparation time. Instructions for use must be finalised and validated against Article 13(3) requirements before the system is placed on the market, not after. Organisations procuring high-risk AI systems should begin incorporating Article 13 verification into vendor due diligence processes now, ahead of the applicable dates. -------------------------------------------------------------------------------- ## Article 14 — Human oversight (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-14/ ## Official Text Summary Article 14 of Regulation (EU) 2024/1689 establishes mandatory human oversight requirements for high-risk AI systems, forming a core pillar of the regulatory framework under Title III, Chapter 2. The article requires that high-risk AI systems be designed and developed in such a way that they can be effectively overseen by natural persons during the period of use. Specifically, Article 14(1) mandates that providers ensure, where technically feasible, that human oversight measures are built into the system prior to placement on the market or putting into service. These measures must enable the persons assigned to oversight to understand the system's capabilities and limitations (Article 14(4)(a)), monitor operation for signs of anomaly, dysfunction, or unexpected performance (Article 14(4)(b)), remain aware of the risk of automation bias (Article 14(4)(c)), correctly interpret outputs (Article 14(4)(d)), and decide not to use the system or to override, disregard, or stop it in any situation (Article 14(4)(e)). Article 14(3) requires that the natural persons assigned to oversight have the necessary competence, authority, and resources to carry out their role. Where a system is intended to be used by natural persons, the oversight measures must, to the extent technically feasible, be built directly into the system interface. Article 14(5) addresses systems with a safety component function, imposing heightened expectations where AI output feeds into safety-critical decisions. ## What This Means in Practice Article 14 creates obligations for both providers and deployers, though the nature of those obligations differs at each stage of the AI system lifecycle. For **providers**, the obligation is primarily one of design: human oversight must not be an afterthought bolted on after development, but a feature engineered into the system from the outset. This means building interfaces that display meaningful confidence indicators, flagging low-certainty outputs, enabling interruption or override without technical friction, and providing documentation that allows deployers to understand what oversight is realistically achievable. For **deployers**, the obligation is operational: they must assign qualified individuals to monitor the system, ensure those individuals are trained and informed about the system's limitations, establish procedures for escalation and intervention, and maintain records of oversight activity. A deployer using an AI-powered recruitment screening tool, for example, must ensure that human recruiters review flagged candidates, understand the criteria the model applies, and retain authority to override rankings without penalty or procedural obstruction. A critical practical concern is **automation bias** — the documented tendency for human overseers to defer uncritically to AI outputs. Article 14(4)(c) explicitly requires that oversight persons be aware of this risk. In practice, this means training programmes must address cognitive bias, and workflows should be structured to require genuine deliberation rather than rubber-stamping. Structured [EU AI Act training for compliance teams](/academy/) — with a module dedicated to human oversight design under Article 14 — is the most direct way to document that oversight staff meet this competence requirement. Deployers in regulated sectors such as healthcare, law enforcement, and credit assessment face heightened expectations, given the severity of harm that can result from unchecked AI recommendations in those contexts. ## Key Obligations - **Design-stage integration**: Providers must embed human oversight capabilities into high-risk AI systems before market placement, ensuring they are technically realisable and not merely nominal. - **Comprehensibility**: Oversight measures must enable assigned persons to understand the system's capabilities, intended purpose, and limitations, including the conditions under which performance may degrade. - **Anomaly monitoring**: Assigned persons must be able to detect malfunctions, unexpected outputs, and deviations from expected system behaviour during operation. - **Bias awareness**: Persons responsible for oversight must be made aware of the risk of automation bias and the tendency to over-rely on AI-generated outputs without independent verification. - **Override authority**: Overseers must have the genuine, unobstructed ability to disregard, override, or halt the AI system at any point during use, without technical or organisational barriers preventing intervention. - **Competence and resource requirements**: Deployers must ensure that persons assigned to oversight have sufficient competence, training, authority, and time to carry out meaningful supervision — oversight cannot be delegated to persons lacking the necessary qualifications or capacity. ## Relationship to Other Articles Article 14 does not operate in isolation. It presupposes compliance with **Article 9** (risk management system), since effective oversight depends on having identified the risks the system poses and the conditions under which oversight becomes critical. It connects closely with **Article 13** (transparency and provision of information to deployers), which requires providers to supply the information necessary for deployers to understand and oversee the system — without that information, oversight as envisaged by Article 14 cannot function. **Article 16** and **Article 26** set out the general obligations of providers and deployers respectively, within which Article 14 obligations are nested. **Article 17** (quality management system) requires that human oversight procedures be documented as part of the provider's quality framework. For systems with a safety component, **Article 14(5)** intersects with product safety legislation referenced in **Annex I**, and with sector-specific requirements that may impose additional or more prescriptive oversight obligations. Finally, **Article 72** (post-market monitoring) extends the logic of oversight beyond deployment into the ongoing operational lifecycle of the system. ## Compliance Timeline Regulation (EU) 2024/1689 entered into force on **1 August 2024**, twenty days after publication in the Official Journal. Its provisions apply on a phased schedule: - **2 February 2025**: Prohibitions on unacceptable-risk AI practices (Article 5) became applicable. - **2 August 2025**: Rules on general-purpose AI models (Title VIII) and governance obligations (Title III, Chapter 4) became applicable. - **2 December 2027**: Obligations for high-risk AI systems listed in **Annex III** — including Article 14 — become fully applicable for most categories. This is the primary compliance deadline for providers and deployers of high-risk AI systems subject to human oversight requirements. - **2 August 2028**: Extended deadline for certain high-risk AI systems already subject to sector-specific Union harmonisation legislation (Annex I systems), giving those supply chains additional time to adapt conformity assessment procedures. Providers and deployers of high-risk AI systems should treat **2 December 2027** as the operative deadline for Article 14 compliance, with preparatory design and governance work requiring commencement well in advance of that date to allow for conformity assessment and documentation. -------------------------------------------------------------------------------- ## Article 15 — Accuracy, robustness and cybersecurity (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-15/ ## Official Text Summary Article 15 of Regulation (EU) 2024/1689 establishes technical requirements for accuracy, robustness, and cybersecurity that must be met by high-risk AI systems throughout their entire lifecycle. The article is structured around three interlocking obligations. First, high-risk AI systems must be designed and developed to achieve an appropriate level of **accuracy** for their intended purpose. Providers are required to declare the relevant accuracy metrics in the accompanying technical documentation, enabling downstream verification and regulatory scrutiny. Second, systems must demonstrate **robustness** — the capacity to handle errors, faults, and inconsistencies arising from within the system itself, from its operating environment, or from deliberate adversarial manipulation. The Regulation expressly mentions the need to address the risk of unintended feedback loops, particularly where a high-risk AI system influences its own training data or outputs. Third, systems must incorporate **cybersecurity** measures proportionate to the risks they pose. These measures must protect against attempts by third parties to exploit system vulnerabilities that could cause the system to behave in harmful, biased, or otherwise non-compliant ways. The Regulation recognises that cybersecurity resilience is not a static condition but must be maintained as the threat landscape evolves. Taken together, Article 15 operationalises the broader principle — articulated in Recitals 51 and 52 — that technical trustworthiness is a prerequisite for the deployment of AI in consequential domains. ## What This Means in Practice Article 15 creates concrete engineering and governance obligations for any organisation that places a high-risk AI system on the EU market or puts one into service. **For providers**, the immediate implication is that accuracy is not merely a commercial claim but a regulatory commitment that must be documented, measured, and maintained. A medical device manufacturer integrating an AI diagnostic tool must specify whether accuracy is measured as sensitivity, specificity, AUC, or another metric — and that choice must align with the system's intended purpose and risk profile. Vague or aspirational accuracy statements will not satisfy the requirement. Robustness testing must go beyond standard quality assurance. Providers should conduct stress-testing, out-of-distribution testing, and — where the system is exposed to user-controlled inputs — adversarial red-teaming. Where a system incorporates feedback loops (for example, a hiring algorithm that learns from recruiter decisions), providers must map and mitigate the risk that biased outputs corrupt future training cycles. Cybersecurity obligations under Article 15 should be read in conjunction with the provider's broader information security posture. High-risk AI systems that process personal data or connect to critical infrastructure face compounded obligations under both this Regulation and the NIS 2 Directive. Practical steps include model access controls, input sanitisation, anomaly detection on inference requests, and vulnerability disclosure procedures. **For deployers**, Article 15 compliance depends substantially on preserving the validated operating conditions described by the provider. Deploying a system on data distributions materially different from those used in validation — for instance, applying a credit-scoring model trained on one national market to a different jurisdiction — may undermine the accuracy and robustness properties on which the CE marking was granted. ## Key Obligations - **Declare accuracy metrics**: Providers must specify the relevant accuracy metrics for the high-risk AI system and include them in the technical documentation required under Article 11 and Annex IV. Metrics must be appropriate to the system's intended purpose. - **Achieve and maintain appropriate accuracy**: The system must be designed and developed to achieve the declared accuracy level; accuracy must not be treated as a one-time validation result but must be monitored post-deployment through the post-market monitoring system required under Article 72. - **Ensure robustness against errors and inconsistencies**: Technical and organisational measures must be in place so the system can handle errors, faults, and inconsistencies — whether arising from internal failures, environmental variability, or deliberate adversarial inputs — without causing unsafe or non-compliant outputs. - **Guard against adversarial attacks**: Where the system is exposed to third-party inputs, providers must implement measures to detect and resist adversarial manipulation, including prompt injection, model inversion, or data poisoning attacks where applicable. - **Address feedback loop risks**: Where a system's outputs could influence future training data or model behaviour, providers must identify this risk in the technical documentation and implement safeguards to prevent performance degradation or bias amplification over time. - **Implement proportionate cybersecurity measures**: Technical solutions — including access controls, monitoring, and incident response procedures — must be proportionate to the cybersecurity risks posed by the system, taking into account its intended purpose, deployment context, and exposure to external networks or user-controlled inputs. ## Relationship to Other Articles Article 15 cannot be read in isolation. It sits at the heart of the technical requirements for high-risk AI systems and intersects with several other provisions of the Regulation. **Article 9** (risk management system) provides the overarching framework within which accuracy, robustness, and cybersecurity risks must be identified, assessed, and mitigated. The risk management system is the procedural vehicle for meeting many of the substantive requirements Article 15 imposes. **Article 10** (data and data governance) is foundational to accuracy: a system trained on low-quality, unrepresentative, or biased data cannot achieve meaningful accuracy guarantees. Data quality obligations directly enable Article 15 compliance. **Article 11 and Annex IV** specify what must appear in technical documentation, including the accuracy metrics required by Article 15(1). **Article 17** (quality management system) requires providers to embed Article 15 compliance into their organisational processes, including design controls, testing protocols, and change management procedures. **Article 72** (post-market monitoring) creates the ongoing obligation to verify that accuracy and robustness levels are maintained after deployment, closing the lifecycle loop that Article 15 opens at the design stage. For systems that are also medical devices or safety components, Article 15 must be read alongside the applicable Union harmonisation legislation listed in Annex I. ## Compliance Timeline Article 15 follows the phased application schedule established by Article 113 of Regulation (EU) 2024/1689, which entered into force on **1 August 2024**. | Date | Milestone | |---|---| | 1 August 2024 | Regulation enters into force. Article 15 is legally enacted but not yet applicable. | | 2 February 2025 | Prohibited AI practices (Title II, Article 5) become applicable. Article 15 does not yet apply. | | 2 August 2025 | GPAI model obligations (Title VIII) become applicable. Article 15 remains inapplicable. | | 2 December 2027 | **Article 15 becomes applicable** to high-risk AI systems listed in Annex III (e.g. biometric identification, critical infrastructure management, employment tools, education systems, law enforcement applications). | | 2 August 2028 | Article 15 becomes applicable to high-risk AI systems governed by Union harmonisation legislation in Annex I (e.g. medical devices, machinery, civil aviation components). | Providers developing or placing high-risk AI systems on the market before the applicable date must nonetheless prepare documentation, testing protocols, and cybersecurity architectures in advance — regulatory readiness assessments and conformity assessments under Articles 43–47 require substantial lead time. Notified body backlogs and the complexity of adversarial testing mean that organisations targeting a 2026 launch should begin Article 15 gap assessments no later than mid-2025. -------------------------------------------------------------------------------- ## Article 16 — Obligations of providers of high-risk AI systems (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-16/ ## Official Text Summary Article 16 of Regulation (EU) 2024/1689 (the EU AI Act) establishes the comprehensive set of obligations that providers of high-risk AI systems must fulfil before placing their systems on the market or putting them into service. The article functions as the central anchor for provider responsibilities within Title III, Chapter 3. Under Article 16, providers must ensure that their high-risk AI systems comply with all requirements laid down in Chapter 2 of Title III, covering risk management (Article 9), data and data governance (Article 10), technical documentation (Article 11), record-keeping (Article 12), transparency and information provision (Article 13), human oversight (Article 14), and accuracy, robustness and cybersecurity (Article 15). Beyond compliance with Chapter 2, Article 16 imposes specific administrative and procedural obligations. Providers must establish a quality management system in accordance with Article 17, draw up technical documentation as specified in Annex IV, and where applicable undergo a conformity assessment procedure before affixing the CE marking. They must register their systems in the EU database established under Article 71 where required, cooperate with national competent authorities upon request, and retain all relevant documentation for a period of ten years following the system's placement on the market or entry into service. Providers established outside the EU must appoint an authorised representative within the Union pursuant to Article 22. ## What This Means in Practice For organisations developing or commissioning high-risk AI systems, Article 16 translates into a structured pre-market compliance programme that must be completed before any deployment or commercial release. **Developers and vendors** building AI systems that fall within the high-risk categories defined in Annex III — covering areas such as biometric identification, critical infrastructure, education, employment, essential services, law enforcement, migration, and administration of justice — must treat Article 16 as their primary compliance checklist. Before launch, they must have a documented quality management system in place, completed a conformity assessment (self-assessed or third-party, depending on the category), affixed the CE marking, and registered the product in the EU AI Act database. **A concrete example:** a software company offering an AI-powered CV screening tool to HR departments falls under Annex III, point 4 (employment and workers management). Before placing this tool on the market, the company must document its risk management process, demonstrate the quality of its training data, provide technical documentation enabling regulators to assess compliance, implement human oversight mechanisms, and register the system. If the company is based outside the EU, it must designate an EU-based authorised representative. **Ongoing obligations** persist after deployment. Providers must maintain records, monitor post-market performance under Article 72, report serious incidents under Article 73, and update technical documentation when the system undergoes substantial modifications. Compliance is not a one-time event but a continuous operational responsibility. Providers working within regulated product sectors — such as medical devices or machinery — must additionally satisfy the sector-specific conformity requirements that interact with the AI Act under Annex I. ## Key Obligations - **Ensure Chapter 2 compliance:** Verify that the high-risk AI system meets all technical and governance requirements (Articles 8–15) prior to market placement, including risk management, data governance, transparency, human oversight, and robustness. - **Establish a quality management system:** Implement a documented QMS in accordance with Article 17, covering policies, procedures, conformity assessment, post-market monitoring, and incident reporting workflows. - **Draw up and maintain technical documentation:** Prepare and keep up to date the technical documentation specified in Annex IV, demonstrating compliance to national competent authorities and notified bodies upon request. - **Undergo conformity assessment and affix CE marking:** Complete the applicable conformity assessment procedure (self-assessment or third-party) and affix the CE marking before placing the system on the market or putting it into service in the EU. - **Register in the EU database:** Enter the system in the EU-wide database for high-risk AI systems established under Article 71, where registration is mandatory for the relevant category. - **Retain records for ten years and cooperate with authorities:** Keep all technical documentation, conformity declarations, and applicable logs for at least ten years; respond to information requests from national supervisory and market surveillance authorities; appoint an EU authorised representative if the provider is not established in the Union. ## Relationship to Other Articles Article 16 cannot be read in isolation. It is the gateway obligation that activates and references virtually all other provider-facing requirements in Title III. The substantive technical requirements that Article 16 requires providers to satisfy are found in **Articles 8 through 15** (Chapter 2). The quality management system it mandates is elaborated in **Article 17**. Technical documentation specifications appear in **Annex IV**, referenced by **Article 11**. The conformity assessment procedures triggered by Article 16 are detailed in **Article 43**, with conformity declaration rules in **Article 47** and CE marking rules in **Article 48**. Post-market surveillance obligations that extend Article 16's reach beyond initial placement are set out in **Article 72**, with serious incident reporting in **Article 73**. Authorised representatives — required for non-EU providers under Article 16 — are governed by **Article 22**. Circumstances in which importers and distributors assume provider obligations are specified in **Article 24**. Finally, the EU database registration requirement connects to **Article 71**. National competent authorities enforcing Article 16 obligations operate under the framework established in **Articles 70 and 74**. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024**, twenty days after publication in the Official Journal. However, its provisions apply in a phased manner: - **2 February 2025:** Prohibitions on unacceptable-risk AI practices (Article 5) became enforceable. - **2 August 2025:** Obligations relating to general-purpose AI models (Title VIII, Articles 51–56) became applicable. - **2 December 2027:** Article 16 obligations become enforceable for **high-risk AI systems listed in Annex III** (standalone AI systems in areas such as employment, education, essential services, biometrics, and law enforcement). - **2 August 2028:** Article 16 obligations become enforceable for **high-risk AI systems covered by Annex I** (safety components of products already regulated by existing EU sectoral legislation, such as medical devices, machinery, and civil aviation). Providers should not wait until these enforcement dates to begin preparation. Building a quality management system, compiling technical documentation, and completing conformity assessments are resource-intensive processes. Organisations placing Annex III systems on the market are advised to be operationally compliant by mid-2026 at the latest, with gap analyses and remediation programmes initiated no later than early 2025. -------------------------------------------------------------------------------- ## Article 17 — Quality management system (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-17/ ## Official Text Summary Article 17 of Regulation (EU) 2024/1689 requires providers of high-risk AI systems to put in place a quality management system (QMS) before placing such systems on the market or putting them into service. The QMS must be documented in a systematic, orderly manner and must cover all stages of the AI system lifecycle. The regulation specifies that the QMS must address, at a minimum: the provider's strategy for regulatory compliance, including conformity assessment procedures; the techniques, procedures, and systematic actions used for design, design control, and verification of the AI system; the data management procedures covering data acquisition, collection, analysis, labelling, storage, filtration, mining, aggregation, and retention; the risk management system as provided for in Article 9; the establishment and implementation of the post-market monitoring system in accordance with Article 72; procedures for incident reporting in line with Article 73; the handling of communication with competent authorities, notified bodies, and other relevant operators; systems and procedures for record-keeping; resource management including supply-chain related measures; and an accountability framework documenting responsibilities throughout the organisation. Where providers are natural persons or micro-enterprises as defined in Commission Recommendation 2003/361/EC, the Commission is empowered to adopt implementing acts permitting simplified QMS arrangements, recognising the proportionality principle that runs through the regulation. ## What This Means in Practice For any organisation that develops or places a high-risk AI system on the EU market, Article 17 means that compliance cannot be a one-off exercise conducted at the point of release. It must be embedded in a living organisational system that governs the entire product lifecycle — from initial design decisions through deployment, monitoring, and eventual decommissioning. In concrete terms, a provider must be able to demonstrate that documented procedures exist and are followed at each stage. A healthcare AI provider, for example, cannot simply train a model and submit it for conformity assessment. The organisation must show that data sourcing followed documented governance rules, that design choices were reviewed against risk criteria, that responsibilities for oversight are assigned and recorded, and that a mechanism exists to detect and report post-deployment incidents. The QMS requirement means that compliance is as much an organisational and procedural challenge as a technical one. Companies that already operate under ISO 9001 or sector-specific management frameworks — such as ISO 13485 in medical devices — will find significant overlap, but will still need to map their existing systems explicitly against the AI Act's requirements rather than assume equivalence. Smaller providers benefit from the proportionality provision: micro-enterprises may qualify for simplified arrangements under implementing acts issued by the Commission. However, this does not exempt them from the underlying substantive obligations; it may only affect the form in which those obligations are documented and managed. Practically, providers should treat the QMS as the central spine from which all other compliance artefacts — technical documentation, risk registers, post-market monitoring plans, incident logs — are generated and governed. ## Key Obligations - Establish a documented quality management system prior to placing a high-risk AI system on the market or putting it into service, covering all lifecycle phases. - Integrate the risk management procedures required by Article 9 into the QMS, ensuring that risk identification, evaluation, and mitigation are systematic and traceable. - Document data management practices covering acquisition, labelling, processing, storage, and retention, consistent with the data governance requirements of Article 10. - Maintain the technical documentation specified in Article 11 and Annex IV as a QMS output, keeping it current and accessible for conformity assessment and market surveillance purposes. - Implement post-market monitoring and incident reporting procedures within the QMS framework, aligned with Articles 72 and 73 respectively. - Define and document accountability structures, roles, and responsibilities across the organisation, including supply-chain oversight where third-party components contribute to the AI system. ## Relationship to Other Articles Article 17 functions as the organisational backbone of the high-risk AI system compliance regime established in Title III, Chapter 3. It draws its substantive content from multiple interlocking obligations: the risk management system of Article 9, the data and data governance requirements of Article 10, and the technical documentation regime of Article 11 all feed directly into what the QMS must cover and produce. The QMS must also support the conformity assessment procedures in Articles 43 and 44, since the documentation it generates constitutes the primary evidence reviewed by notified bodies or self-assessment processes. Post-deployment obligations under Article 72 (post-market monitoring) and Article 73 (reporting of serious incidents) must be embedded within QMS procedures rather than managed as separate ad hoc activities. Article 26 imposes duties on deployers that are distinct from but complementary to the QMS obligations on providers. Where providers and deployers overlap — for instance, where an organisation both develops and deploys a high-risk AI system internally — Article 17's QMS must be read alongside Article 26's deployer obligations to ensure full coverage. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024, following publication in the Official Journal of the European Union. Application of its provisions is phased: - **February 2025** — Prohibitions on unacceptable-risk AI practices (Article 5) became applicable. - **August 2025** — Obligations relating to general-purpose AI models (Title VIII) became applicable. - **2 December 2027** — Article 17 becomes applicable to providers of high-risk AI systems listed in Annex III (systems in areas such as biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, and administration of justice). - **2 August 2028** — Article 17 becomes applicable to providers of high-risk AI systems governed by Annex I (AI components in products already subject to Union harmonisation legislation such as medical devices, machinery, and aviation equipment). Providers whose systems are already on the market before these dates benefit from transitional arrangements under Article 111, which may defer full QMS compliance obligations subject to conditions relating to significant modifications and ongoing conformity assessment cycles. Organisations should begin QMS design and gap assessments well in advance of the applicable deadline to allow for internal validation, notified body engagement where required, and iterative refinement before the obligation applies. -------------------------------------------------------------------------------- ## Article 18 — Documentation keeping (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-18/ ## Official Text Summary Article 18 of Regulation (EU) 2024/1689 establishes mandatory documentation retention obligations for providers of high-risk AI systems classified under Annex III or developed under the provisions of Title III, Chapter 2. The article requires providers to keep, for a period of ten years following the date on which the high-risk AI system is placed on the market or put into service, a specific set of documents and records that substantiate compliance with the Regulation. The documentation that must be retained includes: the technical documentation prepared pursuant to Article 11 and Annex IV; the quality management system documentation required by Article 17; the EU declaration of conformity issued under Article 47; where applicable, the documentation and certificates issued by notified bodies following conformity assessments under Article 43; and post-market monitoring plans and resulting data collected under Article 72. Where a provider is established outside the European Union, the obligation to maintain accessible documentation falls jointly on the provider and on the EU-based authorised representative designated under Article 22. The article further clarifies that where sector-specific Union law — such as the Medical Device Regulation (EU) 2017/745 or the Machinery Regulation (EU) 2023/1230 — prescribes a longer retention period for equivalent technical records, the more stringent sectoral requirement applies, ensuring coherence across regulatory frameworks. ## What This Means in Practice For compliance teams and product owners, Article 18 translates into a concrete records management programme that must be designed before a high-risk AI system reaches the market, not retrofitted afterwards. **Who is affected.** Any legal entity that qualifies as a "provider" under Article 3(3) — typically the organisation that develops or has a high-risk AI system developed and places it on the market under its own name or trademark — carries the primary obligation. Third-party distributors and importers are not directly subject to Article 18 but may trigger equivalent obligations if they substantially modify a system under Article 25. **What to retain.** The obligation covers the full documentary lifecycle: design-phase technical documentation (architecture, training datasets, risk assessment), the quality management system records including internal audit trails, the signed declaration of conformity, any notified body certificates, and the evolving post-market monitoring record. Version control is implicitly required because updates that constitute a substantial modification reset conformity obligations and therefore the documentation cycle. **Practical examples.** A fintech company deploying a credit-scoring model classified as high-risk must archive the model card, bias testing reports, conformity declaration, and all post-deployment incident logs for ten years. A medical device manufacturer integrating an AI-powered diagnostic tool that already falls under MDR must check whether MDR's 15-year retention rule applies, in which case that longer period governs. **Operational recommendation.** Providers should implement a document management system (DMS) with role-based access, automated retention schedules tied to market-placement dates, and an audit trail of who accessed or modified records — all of which also support readiness for market surveillance inspections under Article 74. ## Key Obligations - Retain the technical documentation compiled under Article 11 and Annex IV for a minimum of 10 years from the date of market placement or entry into service of the high-risk AI system. - Keep the quality management system documentation required by Article 17, including records of internal controls, testing outcomes, and corrective actions, for the same 10-year period. - Preserve the EU declaration of conformity issued under Article 47 and, where a conformity assessment was conducted by a notified body under Article 43, all certificates and related correspondence issued by that body. - Maintain post-market monitoring records collected pursuant to the plan required by Article 72, including incident reports and any serious incident notifications submitted under Article 73. - Ensure documentation is stored in a manner that allows prompt production to national market surveillance authorities upon request throughout the entire retention period. - Where an authorised representative is designated under Article 22, that representative must hold a copy of the documentation and be empowered to provide it to competent authorities on the provider's behalf. ## Relationship to Other Articles Article 18 functions as the archival backbone of the high-risk AI compliance framework and cannot be understood in isolation. It is downstream of **Article 11** (technical documentation) and **Annex IV**, which define what must be created; Article 18 then governs how long it must be kept. It depends on **Article 17** (quality management system) because the QMS records it mandates must be preserved. It references **Article 47** (EU declaration of conformity) and **Article 43** (conformity assessment), whose outputs form part of the retained file. Post-market obligations under **Article 72** (post-market monitoring plan) and **Article 73** (serious incident reporting) feed continuously into the document archive throughout the system's operational life. **Article 74** (market surveillance) and **Article 75** (access to data and documentation) are the enforcement counterparts: inspectors exercising powers under those articles will require access to precisely the records that Article 18 mandates be kept. For providers outside the EU, **Article 22** on authorised representatives must be read alongside Article 18 to determine which entity holds the physical or electronic records within the Union. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024**, beginning the phased application schedule. Article 18 falls within Title III, Chapter 3, which governs obligations for providers and deployers of high-risk AI systems listed in **Annex III**. These provisions apply from **2 December 2027** — the date the omnibus set for stand-alone Annex III systems. For high-risk AI systems covered by the sectoral legislation listed in **Annex I** (e.g., machinery, medical devices, civil aviation), the deadline is extended to **2 August 2028**, 48 months after entry into force, in recognition of the need to align with existing sectoral conformity frameworks. Providers should note that the 10-year retention clock starts running from the moment a system is placed on the market or put into service — which may occur on or shortly after the applicable application date. Documentation obligations therefore effectively begin on the same date that the high-risk obligations as a whole become enforceable. Organisations that anticipate placing systems on the market at or near the August 2026 date should have their records management infrastructure operational well in advance, as technical documentation under Article 11 must exist before the conformity assessment is completed. -------------------------------------------------------------------------------- ## Article 19 — Automatically generated logs (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-19/ ## Official Text Summary Article 19 of Regulation (EU) 2024/1689 establishes a logging obligation that operates across two layers: a design-time obligation on providers and an operational obligation on deployers. On the provider side, Article 19(1) requires that high-risk AI systems be technically capable of automatically generating logs of their operation throughout their lifetime. Providers must build this capability into the system to the extent technically feasible, ensuring that events can be recorded without manual intervention. This connects directly to the broader transparency and traceability framework of Title III. On the deployer side, Article 19(2) requires that deployers retain the logs automatically generated by high-risk AI systems they operate. The minimum retention period is six months, unless Union law or applicable Member State law prescribes a longer period. Sector-specific regulation — for example in finance, healthcare, or critical infrastructure — will frequently supersede this default minimum. The logs contemplated by Article 19 serve multiple compliance purposes: they support post-market monitoring under Article 72, facilitate incident reporting under Article 73, and provide the evidentiary basis needed by national competent authorities when conducting market surveillance under Chapter VI. The article does not itself prescribe the precise technical format or granularity of logs, leaving those details to be addressed through harmonised standards and the technical documentation requirements of Article 11 and Annex IV. ## What This Means in Practice For organisations deploying high-risk AI systems, Article 19 introduces a concrete data-retention obligation that must be built into operational processes from day one of deployment. Deployers must first verify that the AI system they are using is technically capable of generating logs automatically. If a provider delivers a system that lacks this capability where it is technically feasible, the provider is in breach of their own obligations — but the deployer still bears responsibility for conducting adequate due diligence before deployment, as required by Article 26. In practice, this means deployers should request from providers clear documentation confirming that logging functionality is present, describing what events are logged, and specifying the log format. This documentation should form part of the contractual arrangements between provider and deployer. Once in operation, deployers must implement a log retention policy covering at least six months. For organisations operating in regulated sectors, this baseline is almost always extended: a hospital deploying an AI-assisted diagnostic tool will need to align log retention with medical records legislation; a bank deploying an AI credit-scoring system must account for financial services record-keeping rules, which often require several years of retention. Concrete operational steps include: designating responsibility for log storage and access controls, ensuring logs are tamper-evident and securely stored, establishing processes for retrieving logs promptly in response to a regulatory request or incident investigation, and documenting the retention policy within the organisation's broader AI governance framework. Logs should capture sufficient information to reconstruct the inputs provided to the system, the outputs generated, the version of the model in use, and the timing of operations — enabling meaningful post-hoc review. ## Key Obligations - **Providers** must design and build high-risk AI systems so that they are technically capable of automatically generating logs of their operation, to the extent technically feasible, for the duration of the system's operational lifetime. - **Deployers** must retain the automatically generated logs produced by high-risk AI systems they operate for a minimum of six months from the date of generation, or longer if required by applicable Union or Member State law. - Deployers must ensure that retained logs are accessible, secure, and capable of being provided to national competent authorities on request during market surveillance or incident investigations. - Providers must document the logging capability of their system — including what is logged, the log format, and any known technical limitations — as part of the technical documentation required under Article 11 and Annex IV. - Where sector-specific regulation imposes stricter or longer retention requirements, deployers must apply those requirements in addition to, and in place of, the six-month baseline. - Deployers must ensure that logging infrastructure is maintained throughout the period of use of the high-risk AI system, and that log integrity is protected against tampering or inadvertent deletion. ## Relationship to Other Articles Article 19 sits within Chapter 3 of Title III and must be read as part of an integrated traceability framework rather than an isolated obligation. It connects directly to **Article 12 (Record-keeping)**, which requires that high-risk AI systems be designed to enable record-keeping of their operation, and to **Article 11 and Annex IV**, which specify what technical documentation providers must maintain, including descriptions of the logging capability. Article 19 feeds into **Article 72 (Post-market monitoring)**, which requires providers to actively monitor system performance in the field — logs are the primary data source for this monitoring. It also underpins **Article 73 (Reporting of serious incidents)**, where logs provide the evidentiary basis for understanding what occurred during an incident. The logs retained under Article 19 are among the records that national competent authorities may request when exercising their market surveillance powers under **Articles 74 and 75**. Finally, the allocation of responsibilities between providers and deployers articulated in Article 19 reflects the broader framework established by **Article 25 (Responsibilities along the value chain)** and **Article 26 (Obligations of deployers)**. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024**, initiating a phased application schedule. Article 19 falls within Title III, Chapter 3, which governs obligations for providers and deployers of high-risk AI systems. The general application date for high-risk AI system obligations — including Article 19 — is **2 December 2027** for systems listed in Annex III (high-risk applications in areas such as education, employment, essential services, and law enforcement). For high-risk AI systems covered by Annex I (safety components of products regulated by existing Union harmonisation legislation), the obligations apply from **2 August 2028**, aligned with the renewal or first issuance of relevant product conformity assessments. Earlier application milestones include the prohibition of unacceptable-risk AI practices (Article 5), which applied from **2 February 2025**, and obligations relating to general-purpose AI models (Title VII), which applied from **2 August 2025**. Organisations deploying high-risk AI systems should treat the **2 December 2027** date as the hard compliance deadline for Article 19 obligations, but should begin designing log retention policies, reviewing provider contracts, and aligning with sector-specific retention laws well in advance — the complexity of enterprise data governance makes last-minute compliance structurally difficult. -------------------------------------------------------------------------------- ## Article 2 — Scope (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-2/ ## Official Text Summary Article 2 of Regulation (EU) 2024/1689 defines the material and territorial scope of the EU AI Act. It establishes which actors, systems, and circumstances fall within the regulation's remit. Ratione personae, the Act applies to: (1) providers placing AI systems on the Union market or putting them into service in the EU, irrespective of their place of establishment; (2) deployers of AI systems who are established or located in the EU; (3) providers and deployers established in third countries where the output produced by the AI system is used in the Union; (4) importers and distributors of AI systems; and (5) product manufacturers who place AI systems as safety components of regulated products on the Union market. Article 2 further clarifies that the Act does not apply to AI systems developed or used exclusively for military, national security, or defence purposes, nor to AI systems used by public authorities of third countries or international organisations in the context of international agreements on law enforcement and judicial cooperation. AI systems that are not yet placed on the market and are still in the research and development phase, prior to being made available to users, also fall outside scope. Where a deployer or provider is established outside the EU but the AI system's output is used within the EU, the Act still applies, establishing a strong extraterritorial reach comparable to the GDPR model. ## What This Means in Practice Article 2 determines whether your organisation must comply with the EU AI Act at all — it is the threshold question every legal and compliance team must answer before any obligations can be assessed. For EU-based companies, the analysis is straightforward: if you develop, deploy, import, distribute, or integrate AI systems into products or services available in the EU, you are in scope. This includes SaaS providers offering AI-powered features, enterprises deploying AI tools in HR, lending, or healthcare, and manufacturers embedding AI into physical products subject to existing EU product safety legislation. For non-EU companies, the critical test is whether the AI system's output reaches or affects individuals or entities in the EU. A US-based company providing an AI recruitment screening tool used by European subsidiaries of multinationals, for example, is in scope even if the company itself has no EU presence. Such providers must designate an authorised representative in the Union. Practically, compliance teams should first map every AI system in use or development, then apply the Article 2 criteria to each. Systems exclusively used for internal R&D — not deployed to end users — can be documented as out of scope, but this status must be actively maintained and revisited at deployment. Military and national security carve-outs are narrow and should not be assumed to apply to dual-use systems or law enforcement tools without careful legal review. Open-source model providers benefit from some relaxed obligations but remain in scope for prohibited practices and high-risk classifications. ## Key Obligations - **Scope determination:** Organisations must affirmatively determine whether they fall within one of the defined actor categories (provider, deployer, importer, distributor, or product manufacturer) before assessing which tier of obligations applies to them. - **Extraterritorial compliance:** Non-EU providers whose AI system outputs are used in the Union must comply with the Act and designate an authorised representative established in the EU. - **Role clarity:** Where the same organisation acts simultaneously as provider and deployer, both sets of obligations apply cumulatively; organisations must document and manage each role separately. - **R&D boundary documentation:** Organisations relying on the research and development exemption must maintain clear records demonstrating that the system has not been placed on the market or put into service, and must reassess scope at each stage of development. - **Narrow reading of exclusions:** Military, national security, and defence exclusions must be applied strictly; dual-use AI systems or those used in general law enforcement contexts do not automatically qualify for exclusion. - **Authorised representative designation:** Third-country providers in scope must formally designate and document an authorised representative in the EU as part of their compliance infrastructure. ## Relationship to Other Articles Article 2 is the entry point to the entire regulatory framework and must be read alongside several foundational provisions. Article 3 (Definitions) is essential for interpreting the key terms used in Article 2, particularly the definitions of "AI system," "provider," and "deployer," which determine scope. Article 5 (Prohibited AI Practices) applies to all actors within scope regardless of risk tier, making correct scope determination under Article 2 a prerequisite for assessing the most serious obligations. Article 6 (Classification of High-Risk AI Systems) and Article 51 (Classification of GPAI Models) only become relevant once Article 2 scope is confirmed. For organisations relying on the third-country provider pathway, Article 2 connects directly to Article 25 (Obligations of Importers) and Article 26 (Obligations of Distributors). The extraterritorial reach established in Article 2 mirrors the logic of Article 3 of the GDPR, and regulatory authorities have confirmed these provisions should be read consistently. ## Compliance Timeline Article 2 entered into force on 1 August 2024, twenty days after publication of the Regulation in the Official Journal of the EU. However, its practical obligations activate according to the Act's phased application schedule: - **2 February 2025:** Article 2 scope applies fully with respect to the prohibited AI practices under Article 5 — organisations must have completed their scope determination by this date to assess whether any of their systems fall into prohibited categories. - **2 August 2025:** Scope applies to General-Purpose AI (GPAI) model providers under Title VIII (Articles 51–56), including systemic risk assessments and transparency obligations. - **2 August 2026:** Obligations for EU institutions and bodies using AI systems under Article 2(1)(h) become applicable. - **2 August 2028:** Article 2 scope applies to high-risk AI systems listed in Annex I (safety components of regulated products). - **2 December 2027:** Full application to high-risk AI systems listed in Annex III (standalone high-risk applications in areas such as employment, education, critical infrastructure, and law enforcement). Organisations should treat August 2024 as the date from which scope mapping exercises should have commenced, with each subsequent deadline triggering a corresponding compliance workstream. -------------------------------------------------------------------------------- ## Article 20 — Corrective actions and duty of information (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-20/ ## Official Text Summary Article 20 of Regulation (EU) 2024/1689 establishes a mandatory corrective action and information duty for providers of high-risk AI systems. Where a provider has reason to believe that a high-risk AI system it has placed on the market or put into service is no longer in conformity with the requirements set out in Chapter 2 of Title III, that provider must immediately take the necessary corrective actions to bring the system back into conformity, to withdraw it, or to recall it, as appropriate. The provider is simultaneously obliged to inform the distributors of the system and, where applicable, the authorised representative, deployers, and any other relevant third parties of the non-conformity and the corrective measures taken. Where the AI system presents a risk within the meaning of Article 79(1), the provider must also immediately notify the competent national authorities of the Member States in which it made the system available and, where applicable, the notified body that issued a certificate for the system, providing details of the non-conformity and the corrective actions undertaken. The article therefore combines two distinct but linked obligations: an operational obligation to act and restore conformity, and an informational obligation to ensure that all actors in the supply and deployment chain — including market surveillance authorities — are made aware of the situation and the steps being taken to address it. This dual structure ensures that risks do not remain siloed within the provider's organisation but are surfaced promptly across the regulatory and commercial ecosystem. ## What This Means in Practice For organisations that develop or place high-risk AI systems on the EU market, Article 20 creates a standing obligation that is permanently active throughout the system's lifecycle. Compliance cannot be treated as a point-in-time exercise limited to the initial conformity assessment. **Who is affected:** Any provider of a high-risk AI system within the scope of Annex III, or systems subject to the high-risk classification rules of Article 6. This includes manufacturers, importers placing a third-party system on the EU market under their own name, and legal entities in third countries whose systems are used in the EU via an authorised representative. **What triggers action:** The threshold is "reason to believe" — a deliberately low evidentiary bar. A provider does not need certainty of non-conformity; a credible basis for concern, whether arising from internal post-market monitoring data, a deployer's report, a user complaint, or a regulator's inquiry, is sufficient to activate the obligation. **Concrete example:** A provider of a high-risk AI system used in credit scoring detects through its post-market monitoring process (required under Article 72) that the system's accuracy has degraded significantly for a protected demographic group, raising a potential violation of the bias and robustness requirements under Articles 9 and 15. Under Article 20, the provider must promptly assess corrective options (retraining, parameter adjustment, temporary suspension), implement the chosen action, notify all deployers currently using the system, and inform the relevant national market surveillance authority if the degradation constitutes a risk under Article 79(1). **Documentation:** All corrective actions and notifications should be recorded in the technical documentation maintained under Article 18 and the logs retained under Article 19, as these will be the primary evidence reviewed by authorities. ## Key Obligations - **Immediate corrective action:** Take all necessary measures to restore conformity, withdraw the system from the market, or recall it from deployers and users, proportionate to the nature and severity of the non-conformity identified. - **Supply chain notification:** Inform distributors, authorised representatives, and deployers of the non-conformity and the corrective actions taken, without undue delay. - **Authority notification:** Where the non-conformity presents a risk within the meaning of Article 79(1), notify the competent market surveillance authorities of all affected Member States and any notified body that issued a certificate for the system. - **Provision of information:** Supply national authorities and notified bodies with full details of the non-conformity, its potential consequences, and the corrective measures implemented or planned. - **Ongoing vigilance:** Maintain the post-market monitoring systems required under Article 72 to ensure that circumstances giving rise to non-conformity are detected promptly and do not persist unaddressed. - **Documentation of actions:** Record all corrective decisions, notifications issued, and authority communications as part of the ongoing technical and quality management obligations under Articles 17, 18, and 19. ## Relationship to Other Articles Article 20 sits at the operational heart of the provider's lifecycle obligations and connects to several other provisions. It is upstream of **Article 73** (serious incident reporting), which applies specifically when a high-risk AI system causes or contributes to a serious incident; the two regimes may be triggered simultaneously and must be managed in parallel. It is downstream of **Article 72** (post-market monitoring), which is the primary mechanism through which providers will detect the non-conformities that activate Article 20. The corrective action obligation is also closely linked to **Article 9** (risk management system) and **Articles 15 and 17** (accuracy, robustness, and quality management), since the adequacy of those systems will determine whether non-conformity is detected and remedied in a timely manner. **Article 26** creates a complementary duty on deployers to report suspected non-conformities back to providers, making deployers an important upstream source of information feeding into the Article 20 trigger. Finally, **Article 21** addresses the cooperation obligations of providers once authorities have formally intervened, and should be read as the regulatory enforcement counterpart to the voluntary corrective action duty under Article 20. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024** (twenty days after publication in the Official Journal on 12 July 2024). Article 20 falls within Title III, Chapter 3 and applies to high-risk AI systems. The phased application schedule is as follows: - **February 2025:** Provisions on prohibited AI practices (Title II) became applicable. - **August 2025:** Rules on general-purpose AI models (Title VIII, Chapter 2) became applicable. - **December 2027:** Obligations for high-risk AI systems listed in Annex III used by public authorities became applicable. - **2 December 2027 (primary high-risk deadline):** The full suite of Title III obligations — including Article 20 — became applicable to providers of high-risk AI systems covered by Annex III. Providers whose systems were already on the market prior to this date benefited from a transitional period but must now comply fully. - **31 December 2030:** Extended deadline for certain high-risk AI systems that are components of large-scale EU IT systems or are subject to harmonised standards not yet published at the time of entry into force. For most providers of Annex III high-risk AI systems, **Article 20 is fully applicable from 2 December 2027**, and corrective action and information processes should already be operational. -------------------------------------------------------------------------------- ## Article 21 — Cooperation with competent authorities (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-21/ ## Official Text Summary Article 21 of Regulation (EU) 2024/1689 (the EU AI Act) establishes a general obligation for providers of high-risk AI systems to cooperate with competent national authorities upon request. Under this provision, providers — and, where applicable, their authorised representatives — must supply competent authorities with all information and documentation necessary to demonstrate that the high-risk AI system in question complies with the requirements set out in Chapter 2 of Title III. This cooperation obligation extends to granting access to the AI system itself where the competent authority considers such access necessary to fulfil its supervisory or market surveillance duties. The article operates within the broader market surveillance framework of the Regulation and must be read in conjunction with the enforcement powers conferred on national authorities under Title X. It does not create a proactive disclosure obligation in the ordinary course of business; rather, it activates upon a formal or informal request from a supervisory body. The obligation is unconditional in scope: providers cannot refuse cooperation on grounds of commercial confidentiality, trade secrecy, or proprietary concern, though the Regulation provides separate safeguards for the handling of confidential information by authorities. Article 21 effectively functions as the bridge between the conformity obligations imposed on providers and the enforcement capacity of the regulatory infrastructure established by the Member States and the European AI Office. ## What This Means in Practice For providers of high-risk AI systems, Article 21 demands that a structured, audit-ready compliance posture be maintained at all times — not merely at the point of conformity assessment. When a national market surveillance authority, a notified body acting under delegation, or the European AI Office initiates an inquiry, the provider must be in a position to respond promptly with comprehensive technical documentation, conformity assessment results, risk management records, and post-market monitoring data. **Who is affected.** Providers placing high-risk AI systems (listed in Annex III or covered by Annex I sector legislation) on the EU market are the primary duty-bearers. Authorised representatives acting on behalf of third-country providers carry the same obligation within their mandate. Deployers are not the primary addressees of Article 21, but may be drawn into cooperation procedures where their operational data or access to the deployed system is required by an authority. **Concrete examples.** A medical device manufacturer integrating an AI-driven diagnostic tool must, upon request, hand over the full technical file including training data descriptions, validation protocols, and post-deployment monitoring logs. A recruiter deploying an AI-assisted CV-screening tool categorised as high-risk under Annex III must facilitate authority access to the system's decision logic and configuration parameters if an investigation is opened. **Operational preparation.** Organisations should designate a regulatory liaison function, maintain version-controlled technical documentation, and establish an internal protocol for authority requests, including legal review timelines that do not impede timely cooperation. ## Key Obligations - **Supply documentation on request.** Providers must furnish competent authorities with all information and technical documentation necessary to assess compliance with Chapter 2 of Title III, including the technical file required under Article 11 and logs maintained under Article 12. - **Grant access to the AI system.** Where a competent authority determines that inspection of or interaction with the AI system is necessary, providers must facilitate such access without undue delay or obstruction. - **Cooperate through authorised representatives.** Third-country providers must ensure their EU-established authorised representative is empowered to fulfil cooperation obligations fully on their behalf, as required under Article 22. - **Maintain information in retrievable form.** The practical utility of Article 21 depends on documentation being current, accurate, and retrievable. Providers must not allow technical records to become outdated or inaccessible at the point a request is received. - **Refrain from obstruction.** Any act or omission that impedes, delays, or frustrates a supervisory inquiry — including selective disclosure, destruction of records, or withholding access credentials — constitutes a breach of Article 21 and may trigger penalties under Article 99. - **Extend cooperation to post-market surveillance activities.** Article 21 cooperation is not limited to pre-placement conformity checks; it encompasses ongoing supervisory oversight throughout the lifecycle of the high-risk AI system. ## Relationship to Other Articles Article 21 sits at the intersection of provider obligations and regulatory enforcement and cannot be read in isolation. It depends directly on Article 11 (technical documentation) and Article 12 (record-keeping and logging), since those provisions define the corpus of information a provider must be able to supply. It connects to Article 17 (quality management system), which governs the organisational processes underpinning documentary readiness. Article 22 (authorised representatives) operationalises Article 21 for third-country providers by designating who bears cooperation duties in the EU. On the enforcement side, Article 21 feeds into the market surveillance regime of Title X (Articles 74–76), the powers of the European AI Office under Title VIII, and the penalty framework of Article 99, which attaches sanctions to non-cooperation. Article 9 (risk management) is also relevant, as authorities may probe whether risk identification and mitigation records are adequate. Reading Article 21 alongside Articles 13 (transparency) and 14 (human oversight) gives a complete picture of the information environment providers must maintain. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024**, twenty days after publication in the Official Journal. Its provisions apply on a phased schedule: - **2 February 2025** — Prohibitions on unacceptable-risk AI practices (Title II) became applicable. Article 21 itself was not yet in force for high-risk systems. - **2 August 2025** — Provisions on general-purpose AI models (Title VIII) and obligations of the European AI Office became applicable. - **2 December 2027** — Article 21, together with the full suite of Title III obligations for high-risk AI systems listed in Annex III (other than those covered by earlier sectoral law), becomes applicable. Providers whose systems fall under this category must be fully cooperation-ready by this date. - **2 August 2028** — High-risk AI systems governed by the Union harmonisation legislation listed in Annex I (e.g., medical devices, machinery, aviation) that are already subject to conformity assessment procedures have until this date before the full AI Act high-risk obligations, including Article 21, apply to legacy products. Providers should treat the period leading up to their applicable date not as a grace period but as implementation time: technical documentation, logging infrastructure, and internal cooperation protocols should be operational well in advance of the deadline. -------------------------------------------------------------------------------- ## Article 22 — Authorised representatives of providers established outside the Union (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-22/ ## Official Text Summary Article 22 of Regulation (EU) 2024/1689 establishes a mandatory gateway mechanism for providers of high-risk AI systems and general-purpose AI models who are established in third countries but who place those systems or models on the Union market or put them into service within the Union. Such providers must, prior to making their AI system or GPAI model available in the EU, designate — by written mandate — an authorised representative established in the Union. The mandate must empower that representative to carry out a defined set of tasks in the provider's name: verifying that the EU declaration of conformity and the required technical documentation have been properly drawn up; ensuring registration in the EU database referred to in Article 71; and acting as the single identifiable point of contact for the AI Office and for national competent authorities in all matters pertaining to compliance with the Regulation. The authorised representative must be included in the mandatory registration information and must have access to sufficient documentation to allow it to fulfil its obligations. The representative operates under a continuing duty to cooperate with competent authorities and to alert the provider immediately of any risk or non-compliance identified. Importantly, the appointment of an authorised representative does not relieve the third-country provider of its own obligations under the Regulation; both parties bear distinct responsibilities, with liability for the representative arising specifically from the tasks attributed in the mandate. ## What This Means in Practice Article 22 functions as the EU AI Act's equivalent of the "responsible person" or "authorised representative" concepts already familiar from product-safety legislation such as the Medical Device Regulation and the General Product Safety Regulation. Its practical effect is to ensure that a legally identifiable entity with a physical presence inside the EU is always reachable by regulators, regardless of where the AI system's developer is headquartered. **Who is affected.** Any non-EU company — whether a US-based foundation model developer, a Singapore-based robotics software firm, or a UK-based HR-tech vendor — that offers a high-risk AI system or a GPAI model to EU customers, deployers, or users must put this structure in place. This includes companies that distribute through EU resellers or cloud marketplaces: the obligation attaches to the provider, not to the distribution channel. **What must be done.** The provider must identify a natural or legal person based in an EU Member State, conclude a written mandate specifying the representative's authorised tasks, ensure the representative holds copies of (or secure access to) the relevant technical documentation and declarations of conformity, and register the representative's details in the EU database under Article 71. **Concrete example.** A Canadian company developing an AI-based credit-scoring tool classified as high-risk under Annex III must contract an EU-established law firm, compliance consultancy, or a dedicated legal-entity subsidiary as its authorised representative before onboarding any EU bank as a customer. That representative's name, address, and contact details appear in the EU database and on product documentation, giving French or German market surveillance authorities an immediate domestic point of contact. **Ongoing obligation.** The mandate is not a one-time filing. The representative must remain reachable, keep documentation current, and escalate any identified non-conformity to the provider promptly. ## Key Obligations - **Mandatory written mandate.** The provider must grant the authorised representative a formal, written mandate before placing the high-risk AI system or GPAI model on the EU market, explicitly setting out which tasks the representative is empowered to carry out on the provider's behalf. - **EU establishment requirement.** The authorised representative must be a natural or legal person established inside the European Union; a representative based in a third country — including EEA EFTA states not covered by an equivalence arrangement — does not satisfy this requirement. - **Documentation access and verification.** The representative must verify that the EU declaration of conformity and the technical documentation required under Articles 11 and 18 have been properly drawn up, and must retain access to those documents for the duration of the mandate. - **Registration in the EU database.** The representative is responsible for ensuring that the provider's information — including the representative's own contact details — is registered in the EU database referred to in Article 71, and that registration is kept up to date. - **Point of contact for authorities.** The authorised representative serves as the primary contact point for the AI Office and national competent authorities for all compliance, market surveillance, and enforcement inquiries relating to the AI system or GPAI model in scope. - **Duty to alert and cooperate.** The representative must promptly inform the provider of any risk to health, safety, or fundamental rights or any suspicion of non-conformity that comes to its attention, and must cooperate fully with competent authorities upon request, including providing them with documentation and access to records. ## Relationship to Other Articles Article 22 operates within the broader Chapter 3 framework governing obligations of providers and deployers and must be read alongside several other provisions. **Article 16** sets out the full list of obligations applying to providers of high-risk AI systems; Article 22 effectively delegates the domestic execution of those obligations to the authorised representative where the provider is established outside the EU. **Articles 11 and 18** define the technical documentation and record-keeping obligations that the representative must verify have been fulfilled before the system is placed on the market. **Article 71** establishes the EU database in which the representative's details must be registered, making Article 22 a prerequisite for lawful registration by third-country providers. **Article 53** governs obligations specific to providers of general-purpose AI models; Article 22 extends the authorised representative requirement to this category, reinforcing that GPAI providers outside the EU face equivalent gatekeeping obligations. **Articles 74 and 75** on market surveillance are directly served by Article 22: competent authorities exercise their supervisory powers toward the authorised representative as a domestic enforcement anchor when the actual provider is unreachable. ## Compliance Timeline The EU AI Act (Regulation 2024/1689) entered into force on **1 August 2024**, twenty days after publication in the Official Journal. Application is phased: - **2 February 2025** — Provisions on prohibited AI practices (Article 5) became applicable. Article 22 does not yet apply in isolation at this stage, but providers should already be assessing whether their systems fall within high-risk or GPAI scope. - **2 August 2025** — Obligations applying to general-purpose AI models (Title V, including Article 53) become applicable. Because Article 22 explicitly covers GPAI model providers, **third-country GPAI providers must have their authorised representative in place by this date**. - **2 December 2027** — High-risk AI systems listed in Annex III that are already subject to existing EU product-safety legislation must comply with the full provider obligation chain, including Article 22 authorised representative requirements. - **2 December 2027** — All remaining high-risk AI systems listed in Annex III become subject to the full set of obligations. Third-country providers of those systems who have not yet designated an authorised representative will be in breach as of this date. Providers placing high-risk systems on the EU market for the first time after 2 August 2024 should treat the authorised representative requirement as a market-access prerequisite from the outset, rather than waiting for the relevant application date for their system category. -------------------------------------------------------------------------------- ## Article 23 — Obligations of importers (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-23/ ## Official Text Summary Article 23 of Regulation (EU) 2024/1689 (the EU AI Act) establishes the compliance obligations incumbent upon importers of high-risk AI systems. The article sits within Title III, Chapter 3, which governs the obligations of providers, deployers, importers, and distributors. Under Article 23, before placing a high-risk AI system on the market, an importer must verify that: 1. the relevant conformity assessment procedure has been carried out by the provider; 2. the provider has drawn up the technical documentation required by Annex IV; 3. the system bears the required CE marking and is accompanied by the EU Declaration of Conformity and instructions for use; 4. the provider has appointed an authorised representative in the Union pursuant to Article 22. Where an importer has reason to believe that a system is not in conformity with the Regulation, they are prohibited from placing it on the market until conformity is established. If the system presents an unacceptable risk as referred to in Article 6, the importer must inform the provider, the authorised representative, and the relevant market surveillance authorities. Importers must also ensure that, while a high-risk AI system is under their responsibility, storage and transport conditions do not jeopardise its conformity. They must indicate their name, registered trade name or mark, and postal address on the system or its packaging. Finally, importers must keep a copy of the EU Declaration of Conformity and technical documentation for ten years and cooperate fully with competent authorities. ## What This Means in Practice Article 23 has direct, concrete implications for any EU-established entity that sources and places on the EU market a high-risk AI system developed by a provider based outside the Union. **Who is affected.** A European distributor that imports a high-risk AI hiring tool developed by a US software company is an importer under this article. Similarly, an EU subsidiary that places the parent company's (third-country) high-risk AI medical diagnostic system on the European market will be treated as an importer and bear the obligations described below. By contrast, if the non-EU provider appoints an authorised representative who acts on their behalf, the importer role and the associated obligations remain distinct from that representative's role. **What actions are required before placing the system on the market.** Importers must conduct a due-diligence review of the provider's compliance package: they need to confirm the conformity assessment is complete, review the Declaration of Conformity, verify the CE marking, and check that the technical documentation (Annex IV) exists and is accessible. This is not a superficial tick-box exercise — if the documentation is missing or there are credible grounds for doubt about conformity, the importer must halt the process. **Ongoing obligations.** Once the system is on the market, importers must maintain their own copy of the declaration and documentation for a decade, affix their contact details to the system or packaging, and report serious incidents or non-conformities to market surveillance authorities. They must also cooperate with any post-market surveillance or investigation requested by national authorities, and ensure that any storage or logistical handling does not degrade the system's conformity properties. A practical example: an EU-based healthcare technology importer bringing in a third-country AI-powered triage system listed under Annex III must complete the full documentation review, confirm CE marking, label the product with their EU address, and retain records for ten years — before a single hospital is approached as a customer. ## Key Obligations - **Pre-market conformity verification.** Confirm that the provider has completed the applicable conformity assessment procedure under Article 43 and that all required documentation — technical file (Annex IV) and EU Declaration of Conformity — is available and up to date. - **CE marking and labelling check.** Verify that the high-risk AI system bears a valid CE marking and that the importer's own name, trademark or mark, and postal address appear on the system or its packaging or accompanying documentation. - **Prohibition on placing non-conforming systems on the market.** Refrain from placing any high-risk AI system on the market if there are reasonable grounds to believe it does not conform to the Regulation or poses an unacceptable risk; notify the provider, authorised representative, and relevant market surveillance authorities accordingly. - **Retention of documentation.** Keep copies of the EU Declaration of Conformity and technical documentation for ten years from the date of placement on the market or entry into service, and make them available to competent authorities upon request. - **Incident and non-conformity reporting.** Immediately inform the relevant national market surveillance authorities and the provider if a system already placed on the market is found to be non-conforming or presents a risk, and cooperate with any corrective or investigative action required. - **Preservation of conformity conditions.** Ensure that storage, handling, and transport arrangements under the importer's responsibility do not jeopardise the conformity of the high-risk AI system with the requirements set out in Chapter 2 of Title III. ## Relationship to Other Articles Article 23 cannot be read in isolation. It is closely linked to **Article 16** (Obligations of providers), which sets out the foundational compliance duties that the importer is verifying compliance with before market placement. **Article 22** (Authorised representatives) is directly referenced: the importer must confirm that such a representative has been appointed, distinguishing the importer's role from that of the representative. **Article 43** (Conformity assessment) defines the procedures whose completion the importer must verify. On the documentation side, **Annex IV** specifies the technical documentation the importer must check exists, and **Article 47** governs the EU Declaration of Conformity that must accompany the system. For post-market obligations, **Article 72** (Post-market monitoring) and **Article 73** (Reporting of serious incidents) provide the framework within which importer reporting duties operate. **Article 25** (Obligations of distributors) is the natural companion provision, clarifying how obligations differ once the system moves further down the supply chain beyond the importer. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024**, twenty days after publication in the Official Journal. However, its provisions apply in phases: - **February 2, 2025** — Prohibitions on unacceptable-risk AI practices (Title II, Article 5) became applicable. Importers are not directly implicated by these prohibitions but must be aware that systems they import cannot fall within these categories. - **August 2, 2025** — Provisions on general-purpose AI models (Title VIII) and governance structures became applicable. Article 23 does not govern GPAI models directly. - **2 December 2027** — The high-risk AI system obligations under Title III, **including Article 23**, become fully applicable for systems covered by Annex III (the main category of high-risk AI systems). Importers of these systems must be fully compliant from this date. - **2 August 2028** — Extended deadline for high-risk AI systems covered by Annex I (safety components under existing Union harmonisation legislation) that were already placed on the market before August 2, 2026. Importers should treat **2 December 2027** as the hard deadline for establishing their due-diligence and documentation processes for all Annex III high-risk AI systems currently in their supply chain. -------------------------------------------------------------------------------- ## Article 24 — Obligations of distributors (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-24/ ## Official Text Summary Article 24 of Regulation (EU) 2024/1689 establishes the obligations incumbent upon distributors of high-risk AI systems within the meaning of Article 3(7). Before making a high-risk AI system available on the market, distributors must verify that it carries the required CE conformity marking, that it is accompanied by a copy of the EU declaration of conformity issued by the provider, and that the necessary instructions for use are provided in a language that can be readily understood by users in the Member State where the system is being made available. Distributors are required to verify that the provider and, where applicable, the importer have complied with their respective obligations under Articles 16 and 23. Where a distributor has reason to believe that a high-risk AI system is not in conformity with the requirements of the Regulation, it must refrain from making the system available until conformity has been restored. If the system presents a risk, the distributor must inform the provider or importer and the competent market surveillance authorities accordingly. Distributors must also cooperate with providers, importers, and competent authorities upon request, and must provide all information and documentation in their possession that is necessary to demonstrate the conformity of a high-risk AI system. Retention obligations for relevant documentation apply for a period of ten years after the system has been made available. Crucially, the article establishes the conditions under which a distributor assumes the full obligations of a provider: when it places a system on the market under its own name, modifies the system substantially, or changes its intended purpose in a way that meets the high-risk classification threshold. ## What This Means in Practice Article 24 directly affects any business that distributes high-risk AI systems without developing them — retailers of AI-powered medical devices, resellers of AI-based biometric systems, or platform operators supplying third-party AI tools to enterprise customers. The article imposes a due-diligence checkpoint before any distribution act. Concretely, a distributor must carry out a compliance check before each placement: confirm the CE marking is present and valid, obtain and retain a copy of the EU declaration of conformity, and ensure product documentation and instructions for use are translated or otherwise accessible in the relevant Member State language. These are not one-time tasks — they apply each time the system is made available. If an audit, customer complaint, or internal review surfaces a conformity concern, the distributor may not continue distribution and must escalate immediately to the provider or importer and, if a risk to health, safety, or fundamental rights is present, to market surveillance authorities such as national AI authorities designated under Article 70. The role-escalation provision is particularly consequential. A distributor that rebrands a high-risk AI system, makes functional modifications that alter performance or intended purpose, or changes the deployment context in a material way will be reclassified as a provider. At that point, it inherits the full obligation set under Article 16, including conformity assessment, registration in the EU database, post-market monitoring, and technical documentation. Businesses should conduct a legal mapping exercise before modifying any acquired AI system to determine whether the modification threshold is crossed. ## Key Obligations - **Pre-distribution conformity verification:** Before making a high-risk AI system available, confirm the CE marking, the EU declaration of conformity, and accessible instructions for use are all present and complete. - **Suspending non-compliant systems:** If there is reason to believe a system does not conform with Regulation (EU) 2024/1689, halt distribution immediately and notify the provider, importer, and, where a risk exists, the competent market surveillance authority. - **Cooperation with authorities:** Upon request, provide all information and documentation held by the distributor to demonstrate conformity, and cooperate with investigations conducted by competent authorities. - **Ten-year documentation retention:** Maintain all relevant compliance documentation for ten years from the date the high-risk AI system was made available on the market. - **Provider obligation assumption:** Where a distributor places a system on the market under its own name or trademark, substantially modifies it, or changes its intended purpose to a high-risk use case, it must assume all provider obligations under Article 16. - **Risk reporting:** If a distributed system poses a risk to health, safety, or fundamental rights, the distributor must immediately inform the provider or importer and the relevant market surveillance authorities, providing details of the non-conformity and any corrective action taken. ## Relationship to Other Articles Article 24 sits within Title III, Chapter 3, which governs the full chain of responsibility for high-risk AI systems. It is closely linked to Article 16 (obligations of providers), as Article 24 repeatedly uses provider obligations as the compliance baseline that distributors must verify and, in certain circumstances, assume directly. Article 23 (obligations of importers) is a direct counterpart: distributors must verify that importers have fulfilled their own pre-distribution checks. Article 3 provides the definitions of distributor, provider, importer, and substantial modification that determine which obligations apply. Article 47 (EU declaration of conformity) and Article 48 (CE marking) define the documentation and marking that distributors are required to check. Articles 72 to 74 on post-market monitoring and serious incident reporting intersect with distributor obligations when a risk materialises after distribution. Market surveillance and enforcement obligations under Articles 74 to 83 govern how competent authorities interact with distributors when investigating non-compliance. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024** (20 days after publication in the Official Journal on 12 July 2024). The phased application schedule is as follows: - **2 February 2025** — Prohibitions on unacceptable-risk AI practices (Title II, Article 5) became applicable. - **2 August 2025** — General-purpose AI model obligations (Title VIII) and governance provisions became applicable. - **2 December 2027** — Article 24 obligations apply in full to distributors of high-risk AI systems listed in **Annex III** (standalone high-risk AI systems across sectors such as education, employment, law enforcement, and access to essential services). - **2 August 2028** — Article 24 obligations apply to distributors of high-risk AI systems embedded in products governed by the Union harmonisation legislation listed in **Annex I** (e.g. machinery, medical devices, civil aviation equipment). Distributors placing Annex III systems on the market should already be engaged in compliance preparation, given the 2 December 2027 deadline. Those dealing exclusively with Annex I product-embedded systems have additional time but should begin supply-chain due diligence and documentation processes without delay. -------------------------------------------------------------------------------- ## Article 25 — Responsibilities along the AI value chain (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-25/ ## Official Text Summary Article 25 of Regulation (EU) 2024/1689 (the EU AI Act) establishes the conditions under which parties other than the original provider assume provider-level responsibilities for a high-risk AI system. The article sits within Title III, Chapter 3, which governs obligations of providers and deployers throughout the lifecycle of high-risk AI systems. The article specifies three triggering scenarios. First, a distributor, importer, deployer, or other third party becomes a provider — with all associated obligations under Chapter 2 of Title III — when they place a high-risk AI system on the market or put it into service under their own name or trademark. Second, provider status is assumed when a third party makes a substantial modification to a high-risk AI system. Third, a change to the intended purpose of a high-risk AI system — even without physical alteration — can trigger re-classification and re-assessment requirements. When such a transition of responsibility occurs, the original provider is not automatically freed from liability. The Regulation requires that contractual arrangements among supply chain parties clearly delineate who holds which obligations at each stage. This ensures regulatory accountability follows the entity that exercises effective control over the system's deployment or modification. The article reinforces the broader principle that the EU AI Act assigns obligations based on the actual role and influence of each actor in the value chain, not merely on formal contractual labels. ## What This Means in Practice Article 25 has direct compliance implications for any organisation that integrates, rebrands, substantially modifies, or redeploys a third-party high-risk AI system. It prevents the common commercial practice of assuming that compliance responsibility rests exclusively with the upstream vendor. **System integrators and resellers** who place a high-risk AI system on the EU market under their own brand — for example, a software company embedding a third-party AI-based credit scoring engine into its own product and marketing it under its own name — become providers under the Act. They must fulfil all obligations set out in Article 16, including conformity assessments, technical documentation, registration in the EU database, and affixing CE marking. **Companies that modify AI systems** must assess whether their changes constitute a substantial modification. Retraining a model on a new dataset, altering decision thresholds in a way that changes risk profiles, or extending the system's functionality into a new domain are examples likely to trigger re-assessment. Even a purely software-level change that affects outputs in a regulated context can qualify. **Deployers who repurpose systems** beyond the original intended use — for instance, using a general workplace analytics tool to make employment decisions — must evaluate whether the new use case falls under a high-risk category and, if so, whether they have effectively become the system's provider. Practically, organisations should audit all AI systems in their stack, map the original provider's documented intended purpose, and establish internal governance processes to flag when proposed changes or new use cases approach Article 25 thresholds. ## Key Obligations - **Assume provider obligations when rebranding**: Any distributor, importer, or third party that markets or deploys a high-risk AI system under its own name or trademark must fulfil all provider obligations under Article 16, including technical documentation, conformity assessment, and EU database registration. - **Re-assess after substantial modification**: Any party that makes a substantial modification to a high-risk AI system must treat the modified system as a new high-risk AI system, repeat the relevant conformity assessment procedure, and update all documentation accordingly. - **Re-register the system**: Where provider status is assumed or a substantial modification is made, the new provider must register the system (or its modified version) in the EU database for high-risk AI systems established under Article 71. - **Review intended purpose before deployment**: Deployers must verify that their use of a high-risk AI system remains within the intended purpose documented by the original provider; any material deviation must be assessed for compliance implications under Article 25. - **Maintain clear contractual allocation of responsibilities**: All parties in the AI value chain — original providers, importers, distributors, and deployers — must ensure their agreements clearly allocate compliance responsibilities, especially where modifications or rebranding are anticipated. - **Retain the original provider's information**: Where a third party assumes provider status, they must have access to — and maintain — all technical documentation and conformity information originally produced by the upstream provider, as this underpins their own compliance obligations. ## Relationship to Other Articles Article 25 functions as a bridge between the provider obligations defined in **Article 16** (obligations of providers of high-risk AI systems) and the deployer obligations in **Article 26**. It ensures that the responsibilities catalogued in Article 16 — technical documentation, conformity assessment, quality management, post-market monitoring — cannot be circumvented by contractual arrangement or corporate structuring. It must be read alongside **Article 6** (classification rules for high-risk AI systems) and **Annex III**, which define when a system is high-risk and therefore subject to the full provider obligation regime. **Article 47** (EU declaration of conformity) and **Article 48** (CE marking) are directly implicated when a new provider must re-certify a modified system. **Article 71** (EU database of high-risk AI systems) is relevant because re-registration is required when provider status changes. **Recital 79** provides interpretive guidance on what constitutes a substantial modification. For supply chains involving GPAI models, **Articles 51–56** govern the upstream model provider's obligations, but Article 25 determines when a system integrator building on that model becomes a high-risk AI system provider in their own right. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024** (twenty days after publication in the Official Journal of the EU on 12 July 2024). Application is phased: - **2 February 2025** — Prohibitions on unacceptable-risk AI practices (Title II) began applying. Article 25 did not yet apply. - **2 August 2025** — Obligations for general-purpose AI models (Title VIII, Articles 51–56) and governance provisions (Title III, Chapter 4; Title V) began applying. Article 25 did not yet apply to high-risk AI systems listed in Annex III. - **2 December 2027** — Article 25 and the full Chapter 3 provider and deployer obligation regime apply to high-risk AI systems listed in **Annex III** (including biometric systems, critical infrastructure, employment, education, access to essential services, and law enforcement use cases). Organisations operating in these sectors must have governance processes, contractual frameworks, and modification-assessment procedures in place by this date. - **2 August 2028** — Article 25 obligations extend to high-risk AI systems covered by **Annex I** (product safety legislation, such as medical devices and machinery), where those systems were already on the market before August 2026 and are subject to a transitional period. Organisations should begin Article 25 compliance mapping — particularly supply chain audits and modification governance protocols — well in advance of the August 2026 deadline. -------------------------------------------------------------------------------- ## Article 26 — Obligations of deployers of high-risk AI systems (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-26/ ## Official Text Summary Article 26 of Regulation (EU) 2024/1689 sets out the obligations that fall upon deployers — those who put high-risk AI systems into use — and sits within Title III, Chapter 3 of the Act. The article establishes that deployers must take appropriate technical and organisational measures to ensure they use such systems in accordance with the instructions for use supplied by the provider (Article 26(1)). Deployers are required to assign the task of human oversight to persons who possess the necessary competence, training, and authority to carry it out effectively (Article 26(2)). Where deployers determine the purpose of use or exercise significant influence over the AI system's operation, they bear enhanced responsibilities commensurate with a provider's role. Deployers must monitor the operation of the high-risk AI system on the basis of the instructions of use and, where relevant, inform the provider of any risks identified (Article 26(5)). They must not use the system in ways that contradict those instructions or place staff under pressure likely to compromise proper oversight. Article 26(7) requires deployers to keep logs automatically generated by the high-risk AI system to the extent such logs are under their control, retaining them for a period appropriate to the intended purpose and applicable sectoral rules, and no less than six months. Article 26(9) imposes an obligation on public-body deployers and certain private operators to conduct and document a fundamental rights impact assessment prior to deployment, and to register it in the EU database established under Article 71. ## What This Means in Practice Article 26 directly affects any organisation that integrates a high-risk AI system into its operations without being that system's developer or original provider. Typical deployers include hospitals using AI-assisted diagnostic tools, employers using AI for recruitment screening, banks using AI credit-scoring engines, and public authorities using AI for benefit eligibility decisions. In concrete terms, a deployer must begin by thoroughly reading and implementing the provider's instructions for use — these become a compliance baseline. Before going live, the deployer must identify which staff member or team holds oversight responsibility and ensure they have the training and authority to intervene, pause, or override the system's outputs. A free [EU AI Act training course with an AI literacy certificate](/academy/ai-act-fundamentals/) is an audit-ready way to document that this staff training took place. Pressure to ignore or work around oversight mechanisms is explicitly prohibited. During operation, the deployer must retain system-generated logs. For a bank deploying a third-party credit-risk model, this means preserving automated decision logs for at least six months and ensuring they are accessible for audit or regulatory inspection. If the system begins producing unexpected outputs or is involved in an incident causing or potentially causing harm, the deployer must escalate immediately to the provider and, if necessary, to the national supervisory authority. Public-sector deployers and private companies providing public-facing services face an additional step: a formal fundamental rights impact assessment must be completed and registered in the EU database before the system is activated. This assessment must identify foreseeable impacts on rights such as non-discrimination, privacy, and due process, and document mitigating measures. Deployers that go beyond their instructions — by repurposing a system for a different use case or materially modifying its configuration — risk being reclassified as providers under Article 25, attracting the full weight of provider obligations including conformity assessment. ## Key Obligations - **Follow the instructions for use**: Deploy and operate the high-risk AI system strictly in accordance with the provider's instructions; any use outside the intended purpose triggers potential reclassification as a provider. - **Ensure competent human oversight**: Designate individuals with the necessary competence, training, and authority to perform effective human oversight; do not instruct or incentivise staff to bypass oversight functions. - **Monitor and report risks and incidents**: Continuously monitor the system's performance; promptly notify the provider and, where applicable, the relevant market surveillance authority of any serious risk or incident identified during use. - **Retain automatically generated logs**: Preserve logs produced by the AI system for a minimum of six months or longer where required by applicable law or sectoral rules, to the extent those logs are under the deployer's control. - **Conduct and register a fundamental rights impact assessment**: Public-body deployers and private operators providing public services must complete a documented fundamental rights impact assessment and register it in the EU database before deployment. - **Inform and protect affected workers**: Where the system is used in employment contexts, deployers must inform workers' representatives and the affected individuals in accordance with applicable Union and national law before deployment. ## Relationship to Other Articles Article 26 must be read alongside several interconnected provisions. Article 25 defines when a deployer is reclassified as a provider — a threshold deployers must actively monitor whenever they modify or repurpose a system. Article 13 (Transparency and provision of information to deployers) governs what the provider must communicate via instructions for use, directly shaping what Article 26(1) compliance looks like. Article 14 (Human oversight) elaborates the technical requirements that providers must build into systems to enable deployers to fulfil their oversight duties under Article 26(2). Article 71 (EU database) underpins the registration requirement imposed on public deployers by Article 26(9). Article 73 (Reporting of serious incidents) complements Article 26(5) by detailing the procedural framework for incident notifications. In employment contexts, Article 26(6) intersects with Directive 2002/14/EC on information and consultation of workers. For deployers in regulated sectors — finance, health, transport — sector-specific Union law may impose additional or overlapping obligations that interact with the Article 26 baseline. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024, with obligations applying on a phased schedule. Provisions on prohibited AI practices became applicable on 2 February 2025. Obligations relating to general-purpose AI models became applicable on 2 August 2025. Article 26, as an obligation applicable to high-risk AI systems listed in Annex III, becomes applicable on **2 December 2027** for most high-risk systems, with an extended deadline of **2 August 2028** for high-risk systems in the areas of employment, education, and access to essential services where existing Union harmonisation legislation applies (those systems listed in Annex I). Deployers should therefore treat 2 December 2027 as the primary compliance deadline for operational readiness, human oversight designation, log retention infrastructure, and fundamental rights impact assessment procedures, while beginning preparatory work immediately to allow sufficient lead time for governance, procurement review, and staff training. -------------------------------------------------------------------------------- ## Article 27 — Fundamental rights impact assessment for high-risk AI systems (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-27/ ## Official Text Summary Article 27 of Regulation (EU) 2024/1689 establishes an obligation for certain deployers of high-risk AI systems to conduct a fundamental rights impact assessment (FRIA) before putting such systems into service. The obligation applies to deployers that are bodies governed by public law as defined in Directive 2014/24/EU, and to deployers that are private entities providing services of a public nature — specifically in the areas of banking, insurance, healthcare, education and vocational training, employment and workers management, and administration of critical infrastructure. The assessment must be conducted prior to deployment and must cover the following elements: a description of the deployer's processes in which the high-risk AI system will be used and their purpose; the categories of natural persons and groups likely to be affected; the specific fundamental rights risks that may result from the use; the concrete measures the deployer intends to implement to mitigate those risks; an indication of whether grievance or redress mechanisms exist; and, where applicable, a description of the impact on children. Deployers covered by the obligation must also notify the relevant market surveillance authority before deploying certain categories of high-risk AI systems enumerated in Annex III. The assessment must draw on information provided by the provider pursuant to Article 13 and must be documented and kept available for competent authorities. ## What This Means in Practice For organisations within scope, Article 27 requires a structured, documented process before any high-risk AI system goes live. This is not a one-time checkbox exercise — the FRIA must reflect the actual deployment context and be revisited when that context changes materially. A public hospital deploying an AI-assisted diagnostic or triage system must assess which patient groups could be disproportionately affected, what rights are at stake (dignity, non-discrimination, access to healthcare), and what safeguards exist if the system produces incorrect recommendations. A local authority using an AI system for benefits eligibility screening must identify risks to the right to social protection and due process, and document how human oversight will function in practice. Private entities providing public-facing financial services — such as credit-scoring or insurance underwriting platforms — fall within scope if they qualify as deployers of Annex III high-risk systems. A fintech company using an AI model to assess loan applications must map the demographic groups exposed to algorithmic decisions, evaluate the risk of discriminatory outcomes, and establish a documented redress pathway. Practically, deployers should build the FRIA into their existing data protection impact assessment (DPIA) workflows under GDPR where relevant, since Article 27(4) explicitly allows the two assessments to be conducted jointly. Organisations should designate a responsible owner for the assessment, use the provider's technical documentation and instructions for use as inputs, and create a versioned record that can be produced for supervisory authorities on demand. ## Key Obligations - Conduct a fundamental rights impact assessment before deploying any high-risk AI system within the deployer's scope, covering the intended use, affected persons, identified risks, and planned mitigations. - Document the assessment in writing and retain it for inspection by competent authorities and market surveillance authorities upon request. - Notify the relevant market surveillance authority prior to deployment where required by the specific category of high-risk AI system listed in Annex III. - Use the information and instructions for use provided by the AI system's provider under Article 13 as a mandatory input to the assessment. - Update the assessment when the deployment context changes significantly, including changes in the categories of persons affected, the purpose of use, or the risk profile of the system. - Where a data protection impact assessment under Article 35 GDPR is also required, the two assessments may be conducted jointly to reduce administrative burden, provided all elements of both are covered. ## Relationship to Other Articles Article 27 sits within Chapter 3 of Title III, which distributes obligations between providers and deployers. It should be read alongside Article 26 (obligations of deployers generally), which establishes the broader duty of deployers to use high-risk systems in accordance with the provider's instructions and to implement human oversight. The FRIA draws directly on the information the provider is required to supply under Article 13 (transparency and provision of information to deployers) and Article 16(d) (provider obligation to draw up technical documentation). Article 27(4) creates a direct procedural link to the GDPR: where a DPIA under Article 35 of Regulation (EU) 2016/679 is also required, the two assessments may be merged. This connection is particularly relevant for deployers processing personal data, which will be the case in most regulated contexts covered by Annex III. Article 27 also connects to Article 72 (market surveillance) and Article 74 (access to data), as the completed assessment must be available to competent authorities exercising supervisory functions. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024 (twenty days after publication in the Official Journal on 12 July 2024). Its provisions apply in phases: - **February 2, 2025** — Prohibitions on unacceptable-risk AI practices (Article 5) became applicable. - **August 2, 2025** — Obligations relating to general-purpose AI models (Title VIII, Chapter 2) and governance provisions became applicable. - **2 August 2028** — Obligations for high-risk AI systems listed in Annex I (product safety legislation) become applicable. - **2 December 2027** — Obligations for high-risk AI systems listed in Annex III (standalone high-risk systems, including those most likely to trigger Article 27 FRIAs in areas such as employment, education, biometric identification, and access to public services) become applicable. Article 27 falls within the high-risk deployer obligations framework and therefore becomes enforceable on **2 December 2027** for Annex III systems, and **2 August 2028** for Annex I systems. Deployers should not wait until these deadlines: building FRIA processes now allows organisations to identify and remediate fundamental rights risks before enforcement begins and to align assessments with ongoing GDPR DPIA programmes. -------------------------------------------------------------------------------- ## Article 28 — Notifying authorities (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-28/ ## Official Text Summary Article 28 of Regulation (EU) 2024/1689 (the EU AI Act) establishes the framework for **notifying authorities** — the national bodies responsible for designating, monitoring, and overseeing conformity assessment bodies (notified bodies) that evaluate high-risk AI systems. Under Article 28, each Member State must designate at least one notifying authority responsible for: establishing and carrying out the procedures required for the assessment and designation of conformity assessment bodies; notifying those bodies to the European Commission and to other Member States; and providing ongoing monitoring of notified bodies to ensure continued compliance with the requirements set out in Article 31. The notifying authority must be structured so as to avoid conflicts of interest with the conformity assessment bodies it oversees. It must be operationally independent from those bodies and must have sufficient technical competence and resources to perform its functions effectively. Member States may assign the notifying authority role to an existing national body — including a market surveillance authority — provided the necessary independence criteria are met. Article 28 further requires notifying authorities to make information about their assessment and notification procedures publicly available, and to cooperate with the Commission and notifying authorities of other Member States, including through the Commission's electronic notification tool linked to the NANDO database. Any changes to a notification — including suspension, restriction, or withdrawal — must be communicated promptly through that system. ## What This Means in Practice Article 28 operates primarily at the **Member State institutional level**, but its practical implications ripple across providers of high-risk AI systems that require third-party conformity assessment before being placed on the EU market. **For Member State governments**, the immediate obligation is administrative: each must formally designate or establish a notifying authority and communicate that designation to the Commission. Member States that have existing notified body infrastructure under sectoral harmonisation legislation (such as for medical devices under Regulation (EU) 2017/745, or machinery under Directive 2006/42/EC) will typically extend or adapt those structures to cover AI-specific requirements. **For providers of high-risk AI systems**, the notifying authority is the gatekeeper for accessing accredited conformity assessment bodies. If a provider's system falls within Annex I categories requiring mandatory third-party conformity assessment, the provider must work with a notified body that has been formally designated by a national notifying authority and listed in the NANDO database. Providers should verify that any conformity assessment body they engage has current, valid notification covering the relevant AI system category. **In practice**, a provider placing, for example, a biometric categorisation system or an AI-based safety component in industrial machinery on the EU market must: 1. Identify whether their system triggers mandatory third-party conformity assessment. 2. Select a notified body listed in NANDO under the relevant scope. 3. Submit to the conformity assessment procedure overseen by that body. 4. Ensure the notified body remains validly designated throughout the product lifecycle. The notifying authority's monitoring function means that if a notified body loses its designation — due to non-compliance findings — any certificates it has issued may be affected, creating downstream compliance risk for providers holding those certificates. ## Key Obligations - **Member States must designate a notifying authority**: Each Member State is obligated to formally designate at least one national body as the notifying authority for AI conformity assessment bodies, and to communicate that designation to the European Commission. - **Independence requirement**: The notifying authority must be organised so as to be operationally independent from the conformity assessment bodies it designates and monitors, avoiding any conflicts of interest. - **Competence and resources**: Notifying authorities must possess sufficient technical expertise, staffing, and resources to carry out assessment, designation, and ongoing monitoring of notified bodies against the criteria in Article 31. - **Transparent procedures**: Notifying authorities must make their assessment and notification procedures publicly available and must use the Commission's electronic notification tool (linked to the NANDO database) for all notifications, updates, suspensions, and withdrawals. - **Ongoing monitoring**: Notifying authorities are responsible for continuous oversight of notified bodies to ensure they maintain the required competence and compliance; they must investigate complaints and take corrective action where deficiencies are found. - **Cross-border cooperation**: Notifying authorities must cooperate with each other and with the Commission, sharing information relevant to the competence and conduct of notified bodies to maintain consistent standards across the single market. ## Relationship to Other Articles Article 28 is the structural foundation of Chapter 4 (Title III) and must be read together with the articles that immediately follow it. **Article 29** specifies the detailed requirements that notifying authorities themselves must meet — including independence, impartiality, and absence of conflicts of interest. **Article 30** governs the application process by which conformity assessment bodies seek notification, establishing what information must be submitted to and assessed by the notifying authority. **Article 31** sets out the substantive requirements that notified bodies must satisfy for designation to be granted or maintained. More broadly, Article 28 connects to **Article 43**, which specifies which high-risk AI systems in Annex I are subject to mandatory third-party conformity assessment — making notified bodies, and therefore notifying authorities, operationally relevant. The article also links to **Article 74** and the broader market surveillance framework: notifying authorities and market surveillance authorities may be the same body, and their cooperation is essential for effective enforcement. The **NANDO database** infrastructure referenced in Article 28 underpins the transparency obligations that run throughout the conformity assessment chapters. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024**, triggering a phased application schedule with different deadlines across different obligations. Article 28, as part of the institutional and governance framework for notified bodies, falls within the provisions applicable to **high-risk AI systems under Annex I** (systems covered by Union harmonisation legislation). The conformity assessment infrastructure — including the formal designation of notifying authorities — must be operational in time to support the application of high-risk obligations. Key reference dates: - **1 August 2024** — Regulation enters into force; Member States begin preparatory work on authority designation. - **2 February 2025** — Prohibited AI practices under Article 5 become applicable; no direct impact on Article 28, but marks the beginning of phased enforcement. - **2 August 2025** — GPAI model obligations (Title VIII) and governance provisions become applicable; Commission guidance on notified body procedures expected. - **2 December 2027** — High-risk AI systems under Annex III (standalone high-risk systems, e.g. in employment, education, law enforcement) become subject to full obligations; notifying authorities must be fully operational by this date at the latest. - **2 August 2028** — High-risk AI systems that are safety components of products already covered by Union harmonisation legislation (Annex I systems) become fully subject to the AI Act's conformity assessment requirements; this is the date by which the notifying authority and notified body infrastructure under Article 28 must be fully functional for legacy product categories. Providers and national authorities should use the 2024–2026 window to identify the competent notifying authority in the relevant Member State and confirm that appropriately scoped notified bodies are available for their product category. -------------------------------------------------------------------------------- ## Article 29 — Application of a conformity assessment body for notification (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-29/ ## Official Text Summary Article 29 of Regulation (EU) 2024/1689 (the EU AI Act) governs the process by which conformity assessment bodies apply to their national notifying authority to be formally notified — that is, officially designated to carry out third-party conformity assessment tasks for high-risk AI systems under Title III of the Regulation. Under Article 29, a conformity assessment body wishing to be notified must submit an application to the notifying authority of the Member State in which it is established. The application must cover the conformity assessment activities the body seeks to perform, specifying the AI system categories and the conformity assessment procedures it intends to apply. The preferred evidential route is the submission of an accreditation certificate issued by the national accreditation body designated pursuant to Regulation (EC) No 765/2008. That certificate must attest that the applicant satisfies the requirements established under Article 31 of the EU AI Act. Where a conformity assessment body has not pursued accreditation, it must provide the notifying authority with documentary evidence of an equivalent level of compliance, supported by appropriate verification mechanisms. The notifying authority is responsible for evaluating the application, verifying the evidence submitted, and deciding whether to grant notification. Once granted, notification is communicated to the European Commission and the other Member States through the dedicated IT tool maintained by the Commission, ensuring cross-border transparency of notified body status across the single market. ## What This Means in Practice Article 29 is the procedural gateway for any third-party body that wants to conduct official conformity assessments of high-risk AI systems in the EU. Without completing this notification process successfully, a body cannot legally issue the certificates and opinions that certain high-risk AI system providers need to affix the CE marking and place their products on the EU market. **For conformity assessment bodies**, the practical priority is to begin building competence and seeking accreditation well in advance of the dates from which high-risk AI system providers will require third-party assessments. National accreditation bodies assess whether a conformity assessment body meets Article 31 requirements — covering areas such as independence, technical competence, staff qualifications, impartiality, liability coverage, and confidentiality obligations. Securing accreditation first, then submitting the notification application, is the most straightforward path. **For AI system providers**, understanding which bodies are notified — and for which categories of high-risk AI systems — is essential when planning conformity assessment. A provider of a high-risk AI system listed in Annex III that requires third-party conformity assessment must engage only a duly notified body. Choosing an accredited but not yet notified body would not satisfy the legal requirement. **For Member States**, Article 29 places an obligation on notifying authorities to establish clear, transparent, and timely application procedures. Delays in processing notifications could create market access bottlenecks, particularly in the period leading up to December 2027 when the Annex III high-risk obligations become enforceable. Practically, bodies seeking notification should treat the process as a multi-month undertaking: internal gap analysis against Article 31 requirements, accreditation assessment, application drafting, authority review, and IT system registration all take considerable time. ## Key Obligations - **Conformity assessment bodies** must submit a formal written application to the notifying authority of their Member State of establishment before they may perform any notified body activities under the EU AI Act. - **Applications must specify** the exact conformity assessment activities, the categories of high-risk AI systems covered, and the conformity assessment procedures or modules the body proposes to apply. - **Accreditation is the preferred evidential route**: applicants should obtain an accreditation certificate from their national accreditation body under Regulation (EC) No 765/2008 demonstrating conformity with Article 31 requirements; where accreditation is not pursued, equivalent documentary evidence must be provided. - **Notifying authorities** must evaluate all applications, verify the evidence submitted, and take a reasoned decision on whether to grant notification, communicating the outcome to the applicant. - **Granted notifications must be registered** in the Commission's IT notification tool and made accessible to the public, so that providers across the EU can identify competent notified bodies. - **Bodies that do not obtain accreditation** bear a higher evidentiary burden and must ensure the notifying authority has sufficient independent verification of their compliance with Article 31. ## Relationship to Other Articles Article 29 sits at the heart of Chapter 4 (Notifying Authorities and Notified Bodies) of Title III and must be read in close conjunction with several other provisions. **Article 28** establishes the framework and powers of notifying authorities — the national bodies responsible for receiving and processing applications under Article 29. **Article 30** sets out the detailed notification procedure that notifying authorities must follow once an application is submitted. **Article 31** defines the substantive requirements that a conformity assessment body must meet to be eligible for notification, and it is against those requirements that Article 29 applications are ultimately assessed. **Article 32** addresses notification to the Commission and Member States, which is the downstream consequence of a successful Article 29 application. More broadly, Article 29 is the operational link between the general conformity assessment obligations for providers of high-risk AI systems under **Article 43** and the existence of a functioning market of qualified, independent bodies capable of discharging those assessments. It also relates to **Article 35** (operational obligations of notified bodies once notified) and **Article 36** (changes to notifications). ## Compliance Timeline The EU AI Act entered into force on 1 August 2024, beginning the phased application of its provisions. - **1 August 2024** — Regulation enters into force; the 24-month transitional clock starts for most high-risk obligations. - **2 February 2025** — Provisions on prohibited AI practices (Article 5) became applicable. - **2 August 2025** — Obligations relating to general-purpose AI models (Title VIII) and governance structures became applicable; this is also the point from which the notification framework infrastructure, including Article 29 application procedures, was expected to be operational in Member States. - **2 December 2027** — High-risk AI systems listed in Annex III (excluding those already covered by existing Union harmonisation legislation) must comply with all Title III obligations, including provider requirements for conformity assessment. Notified bodies must therefore be in place before this date to service providers who require third-party assessment. - **2 August 2028** — The final phase-in for certain high-risk AI systems already regulated under existing product safety legislation (Annex I systems) that are placed on the market or put into service under those existing frameworks. Conformity assessment bodies and their national notifying authorities should treat the period from now through late 2026 as the critical window for completing Article 29 notification processes in order to avoid supply-side bottlenecks in the conformity assessment market. -------------------------------------------------------------------------------- ## Article 3 — Definitions (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-3/ ## Official Text Summary Article 3 of Regulation (EU) 2024/1689 (the EU AI Act) establishes the definitional framework that governs the entire Regulation. It contains 65 numbered definitions that give precise legal meaning to the core terminology used throughout the Act. The most foundational definition is that of **'AI system'** (Article 3(1)): a machine-based system designed to operate with varying levels of autonomy that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers from the input it receives how to generate outputs — such as predictions, content, recommendations, or decisions — capable of influencing physical or virtual environments. This definition deliberately aligns with the OECD Recommendation on AI and is technology-neutral. Article 3 also defines the principal market actors: **providers** (Article 3(3)), who develop and place AI systems on the market; **deployers** (Article 3(4)), who use AI systems in a professional context; **importers** (Article 3(6)); **distributors** (Article 3(7)); and **operators**, a collective term covering providers and deployers. Additional definitions cover **general-purpose AI models** (Article 3(63)), **general-purpose AI systems** (Article 3(66)), **high-risk AI systems**, **intended purpose**, **reasonably foreseeable misuse**, **substantial modification**, **placing on the market**, **putting into service**, **safety component**, **biometric data**, and many others that are essential for determining scope, obligations, and applicable risk categories under the Act. ## What This Means in Practice Article 3 is the gateway to the EU AI Act. Before any organisation can determine whether it is regulated, how heavily, and in what role, it must work through the definitions in Article 3 systematically. **Step 1 — Does your product qualify as an AI system?** Apply the Article 3(1) test: Does the system operate with some autonomy? Does it infer from inputs to generate outputs? A machine-learning model used for credit scoring qualifies. A hard-coded eligibility calculator with fixed rules does not. **Step 2 — What is your role?** A company that trains and commercialises a fraud-detection model is a **provider**. A bank that licenses that same model and integrates it into its loan approval workflow is a **deployer**. A US-headquartered company that sells the model into the EU market is an **importer**. The same legal entity can simultaneously hold multiple roles for different AI products or within the same value chain. **Step 3 — Does the GPAI definition apply?** If your organisation develops a large foundation model (such as a large language model) trained on broad data and capable of multiple tasks, Article 3(63) likely applies, triggering the Title VIII obligations for GPAI models regardless of whether the model is itself deployed as a standalone AI system. **Concrete example:** A SaaS company in Berlin that fine-tunes an open-source LLM and sells it as a customer-service chatbot to retailers is a provider of both a GPAI model (if it releases the underlying model) and an AI system. A retailer using the chatbot for customer interactions is a deployer. Both face distinct compliance obligations under the Act, all of which depend on correctly identifying roles via Article 3. ## Key Obligations - **Correctly identify the applicable legal role** — every organisation must determine whether it acts as a provider, deployer, importer, distributor, or a combination thereof, as each role carries a distinct and non-transferable set of obligations under Titles III through VIII. - **Apply the Article 3(1) AI system test** before assuming the Regulation applies — confirm the presence of machine-based inference from inputs to generate outputs before engaging the full compliance framework. - **Distinguish AI systems from GPAI models** — Article 3(63) and 3(66) create a separate regulatory track for general-purpose AI models; organisations developing foundation or base models must evaluate applicability of Title VIII obligations independently of AI system classifications. - **Assess whether a 'substantial modification' has occurred** — Article 3(23) defines substantial modification as a change to an AI system after placing on the market that affects the system's compliance with the Regulation or alters its intended purpose; such modifications reset provider obligations and may trigger re-certification. - **Establish the 'intended purpose'** — Article 3(12) defines intended purpose as the use for which an AI system is specifically designed and documented by the provider; risk classification and applicable requirements are anchored to this definition, making accurate documentation of intended purpose a critical compliance control. - **Account for 'reasonably foreseeable misuse'** — Article 3(13) requires that providers consider uses of their system that are not intended but which may arise from reasonably foreseeable human behaviour, expanding the effective scope of risk assessment beyond declared use cases. ## Relationship to Other Articles Article 3 underpins every subsequent provision of the Regulation. It connects directly to **Article 2** (scope of application), which uses the definitions of 'provider', 'deployer', 'importer', and 'distributor' to determine who is subject to the Act and under what territorial conditions. The **Article 3(1)** definition of AI system delimits the boundary between the Act and non-AI software regulation, feeding directly into the prohibited practices listed in **Article 5** and the high-risk classification criteria in **Article 6** and **Annex III**. The definition of **intended purpose** links to the conformity assessment procedures in **Articles 43–48** and to the technical documentation requirements in **Article 11** and **Annex IV**. The GPAI model definitions in **Article 3(63–66)** are foundational to the entire **Title VIII** framework (Articles 51–56). The concept of **substantial modification** (Article 3(23)) triggers re-entry into provider obligations and connects to post-market monitoring under **Article 72**. ## Compliance Timeline Article 3, as part of Title I (General Provisions), entered into application on **2 August 2026** — 24 months after the Regulation entered into force on 1 August 2024. All definitions in Article 3 therefore have full legal effect as of that date. Organisations should note, however, that accurate identification of roles and system classifications under Article 3 is a prerequisite for compliance with earlier phases of the Act's rollout. The prohibited practices in **Article 5** applied from **2 February 2025** (6 months after entry into force), meaning organisations needed to apply Article 3 definitions to assess exposure to those prohibitions from that date. The **GPAI model obligations** under Title VIII applied from **2 August 2025** (12 months after entry into force). High-risk AI system requirements under **Annex I** apply from **2 August 2028** (36 months); those under Annex III apply from **2 December 2027**, with a derogation to **2 August 2028** for certain systems already in service. Organisations that have not already completed their Article 3 role and system classification exercise are in breach of the foundational compliance prerequisite across multiple application phases. -------------------------------------------------------------------------------- ## Article 30 — Notification procedure (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-30/ ## Official Text Summary Article 30 of Regulation (EU) 2024/1689 (the EU AI Act) establishes the formal procedure by which Member States notify the European Commission and each other of conformity assessment bodies they have designated as notified bodies authorised to carry out third-party conformity assessments of high-risk AI systems. The notifying authority of each Member State submits the notification electronically through the Commission's NANDO (New Approach Notified and Designated Organisations) information system. The notification must include the conformity assessment body's identifying information, its designated scope of activities (specifying the AI system categories and tasks covered), and evidence that the body satisfies all requirements laid down in Article 31. A two-week waiting period follows notification submission. During this period, either the Commission or another Member State may raise objections. If no objection is raised, the notified body may commence its conformity assessment activities. Where an objection is raised, the Commission consults the relevant parties and determines whether the notification is justified, instructing the notifying Member State accordingly. Where a notifying authority determines that a notified body has ceased to meet the requirements or is failing its obligations, it must restrict, suspend, or withdraw the designation and promptly inform the Commission and other Member States. The Commission ensures the NANDO system remains publicly accessible and kept up to date, providing transparency over the full landscape of authorised notified bodies operating across the EU's single market. ## What This Means in Practice Article 30 has direct relevance for two groups of actors: **conformity assessment bodies** seeking to act as notified bodies, and **providers of high-risk AI systems** who must identify and engage an appropriately notified body for mandatory third-party conformity assessment. For conformity assessment bodies, the notification procedure is the gateway to operating as a notified body under the EU AI Act. Once a national notifying authority has assessed and approved a body under the criteria of Article 31 — covering independence, technical competence, impartiality, and liability coverage — it lodges the formal notification via NANDO. The body must not begin issuing conformity certificates under the AI Act until the two-week objection window has closed without challenge, or until any raised objections have been resolved in its favour. For AI system providers subject to mandatory third-party conformity assessment (primarily those placing high-risk AI systems listed in Annex III onto the EU market where a notified body is required, or those under Annex I product safety legislation), Article 30 provides the mechanism for verifying which bodies are legitimately authorised. Providers must select only properly notified bodies — identifiable through NANDO — for their conformity assessments. Engaging a body before its notification is effective, or one whose notification has been suspended, would invalidate the resulting certificate and render the system non-compliant. Where a notified body's designation is restricted or withdrawn, providers holding certificates issued by that body must take remedial steps, which may include re-engaging an alternative notified body to revalidate conformity before continuing to place the system on the market. ## Key Obligations - **Notifying authorities** must submit notifications of designated conformity assessment bodies to the Commission via the NANDO electronic notification system, including full identifying details, scope of designation, and supporting accreditation evidence. - **Notified bodies** must not commence conformity assessment activities under the EU AI Act until the two-week waiting period following formal notification has elapsed without objection, or until any objection has been resolved in their favour by the Commission. - **Notifying authorities** must continuously monitor notified bodies under their jurisdiction and immediately restrict, suspend, or withdraw the notification if the body ceases to meet Article 31 requirements or fails to fulfil its obligations, notifying the Commission and other Member States without delay. - **The Commission** must maintain and keep publicly accessible the NANDO system as the authoritative register of all notified bodies operating under the EU AI Act, ensuring transparency across Member States. - **Providers of high-risk AI systems** must verify that any conformity assessment body they engage is validly notified via NANDO and that the body's notification covers the specific AI system category and tasks required. - **Member States and the Commission** may raise objections within the two-week window following a notification submission, triggering a mandatory consultation process before the notification can take legal effect. ## Relationship to Other Articles Article 30 operates at the centre of a cluster of provisions governing the notified body framework in Title III, Chapter 4. It presupposes Article 28, which establishes and defines the role of **notifying authorities** at Member State level, and Article 29, which sets out the general requirements those authorities must themselves satisfy (independence, competence, absence of conflicts of interest) before they can legitimately notify bodies. The substance of what a body must demonstrate to receive and retain notification is governed by Article 31 (requirements for notified bodies) and Article 33 (notified body subsidiaries and subcontracting). The operational conduct of notified bodies once authorised is addressed in Articles 33 through 39. Article 30 also connects to Article 43 (conformity assessment procedures), since the legal validity of any conformity assessment certificate depends on the issuing body holding a current, effective notification under Article 30. Finally, it links to Article 74 (market surveillance) insofar as competent authorities must verify that certificates underpinning CE marking were issued by properly notified bodies. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024**, twenty days after publication in the Official Journal of the EU. Article 30 falls within the provisions that apply to **high-risk AI systems**, which follow the Act's phased application schedule: - **1 August 2024** — Entry into force. Member States begin preparatory work on establishing or designating notifying authorities. - **2 August 2025** — General obligations, including most governance and notified body framework provisions, began to apply. Member States were required to have notifying authorities operational, and conformity assessment bodies could begin the designation and notification process. - **2 December 2027** — High-risk AI systems covered by Annex III (standalone high-risk applications) must fully comply, meaning providers requiring third-party conformity assessment must have engaged a validly notified body. - **2 August 2028** — High-risk AI systems embedded in products regulated under Annex I safety legislation (e.g., machinery, medical devices, toys) must comply, aligning AI Act requirements with existing product safety conformity assessment timelines. Providers planning to place high-risk AI systems on the EU market should verify the notification status of their chosen conformity assessment body via NANDO well in advance of these deadlines, since the notification process itself involves assessment by the national authority, a two-week objection window, and potential Commission review — a process that may take several months in total. -------------------------------------------------------------------------------- ## Article 31 — Requirements relating to notified bodies (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-31/ ## Official Text Summary Article 31 of Regulation (EU) 2024/1689 establishes the conditions that a conformity assessment body must satisfy before a Member State may notify it to the European Commission as a body competent to carry out third-party conformity assessments of high-risk AI systems. The article imposes requirements across several dimensions. First, the body must be established under national law and have legal personality. Second, it must be independent of the AI systems it assesses, of their providers, and of any commercial, financial, or other pressure that could compromise its judgement; neither the body nor its staff may be the designer, developer, manufacturer, supplier, installer, purchaser, owner, user, or maintainer of the AI systems they assess. Third, the body and its staff must possess the necessary technical competence — including relevant experience with AI technologies and data practices — and must maintain that competence through continuous training. Fourth, the body must be financially sound and carry adequate liability insurance. Fifth, the body must have documented processes for handling conflicts of interest, for confidentiality of information obtained during assessment, and for protecting the interests of providers and third parties. Finally, the body must participate in coordination activities at Union level and cooperate with market surveillance authorities and notifying authorities. Where a notified body subcontracts tasks or uses a subsidiary, it must ensure those entities meet the same requirements and retains full liability for their work. ## What This Means in Practice Article 31 is primarily directed at conformity assessment bodies seeking notified-body status, and at the national notifying authorities responsible for evaluating and designating them. It does not impose direct obligations on AI providers, but its requirements shape the ecosystem in which providers must operate. For conformity assessment bodies, compliance with Article 31 means undertaking a comprehensive internal readiness exercise before applying for notification. This includes conducting a structural review to verify independence from providers and supply chains, recruiting or retraining staff with hands-on expertise in machine learning, data governance, and the specific application domain of the AI systems to be assessed (for example, medical devices, biometric systems, or critical infrastructure). Bodies must put in place documented management systems covering confidentiality, conflict of interest, and quality assurance, and must secure appropriate professional liability insurance. For AI providers of high-risk systems that require a third-party conformity assessment under Article 43 — for instance, systems listed in Annex III for which no harmonised standard covers the full requirements — choosing a notified body means verifying that the body is duly listed in the NANDO database and that its scope of notification covers the relevant AI application sector. Providers should also verify the body's sub-contracting arrangements and confirm that subsidiary assessors are themselves compliant. National notifying authorities must build evaluation frameworks that test applicants rigorously against each Article 31 criterion and must put in place monitoring procedures to verify ongoing compliance after notification, since continued satisfaction of these requirements is a condition of maintaining notified status. ## Key Obligations - **Independence and impartiality**: The notified body, its senior management, and the staff responsible for carrying out conformity assessment tasks must not be the designer, developer, manufacturer, supplier, or user of the AI systems they assess, and must be free from any influence — commercial, financial, or otherwise — that could affect their objectivity. - **Technical competence**: The body must demonstrate sufficient knowledge and experience in AI technologies, data and data governance, cybersecurity, and the specific application domain of the systems it is notified to assess, and must ensure staff undergo ongoing training to keep pace with technological developments. - **Legal personality and financial stability**: The body must be a legally constituted entity under national law and must be able to demonstrate financial health and hold adequate liability insurance to cover its assessment activities. - **Documented management systems**: The body must operate documented procedures for handling conflicts of interest, protecting the confidentiality of commercially sensitive information, and managing complaints and appeals from providers. - **Subcontracting and subsidiary rules**: Where tasks are subcontracted or delegated to a subsidiary, the notified body must verify that the subcontractor or subsidiary satisfies all Article 31 requirements, must inform the provider before subcontracting, and retains full legal responsibility for the outputs. - **Cooperation and participation**: The notified body must cooperate with national market surveillance authorities and notifying authorities, and must participate in Union-level coordination groups established for notified bodies under the AI Act framework. ## Relationship to Other Articles Article 31 sits within Title III, Chapter 4, which governs the entire notifying authority and notified body framework. It must be read together with Article 28, which defines the obligations of notifying authorities, Article 29, which sets the requirements for notification applications and the Commission notification procedure, and Article 30, which addresses the establishment and tasks of notifying authorities at national level. Downstream, Article 31 connects directly to Article 33, which specifies the operational obligations of notified bodies once designated — including their duty to carry out assessments in accordance with Articles 43 and 44 — and to Article 44, which governs the certificates issued by notified bodies and the conditions for their suspension or withdrawal. Article 43 determines precisely when third-party conformity assessment by a notified body is mandatory versus when a provider may rely on internal control. Article 49 on the EU declaration of conformity and Article 50 on CE marking are the downstream outputs that depend on a valid notified-body certificate where one is required. ## Compliance Timeline Regulation (EU) 2024/1689 entered into force on 1 August 2024. The EU AI Act applies in phased stages: - **2 February 2025**: Prohibitions on unacceptable-risk AI practices (Title II) began to apply. - **2 August 2025**: Rules on general-purpose AI models (Title VIII) and governance obligations for Member States became applicable. - **2 December 2027**: The main obligations for high-risk AI systems listed in Annex III — including conformity assessment requirements under Article 43, and therefore the operational requirements for notified bodies under Article 31 — become fully applicable. - **2 August 2028**: Extended deadline for certain high-risk AI systems that are also safety components of products already subject to Union harmonisation legislation listed in Annex I (such as medical devices and machinery). In practical terms, conformity assessment bodies wishing to be operational on 2 August 2026 must have begun their application process well before that date, given the time required for national evaluation and formal notification to the Commission. Member States were therefore expected to have their notifying authority frameworks and evaluation procedures in place by mid-2025 at the latest. -------------------------------------------------------------------------------- ## Article 32 — Presumption of conformity of notified bodies (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-32/ ## Official Text Summary Article 32 of Regulation (EU) 2024/1689 establishes a presumption of conformity for notified bodies that apply harmonised standards adopted under European Union law. Specifically, where a conformity assessment body demonstrates conformity with the criteria laid down in the harmonised standards — or with relevant parts of those standards — whose references have been published in the Official Journal of the European Union, that body is presumed to satisfy the requirements set out in Article 31 to the extent that the applicable harmonised standards cover those requirements. Article 31 establishes the substantive criteria that a conformity assessment body must meet before a Member State's notifying authority can notify it to the European Commission: independence, technical competence, impartiality, financial soundness, liability coverage, confidentiality obligations, and appropriate internal governance structures. Article 32 creates a streamlined evidentiary path by which a body can demonstrate compliance with those criteria through reference to published harmonised standards, rather than requiring case-by-case assessment of each criterion from first principles. The presumption is rebuttable and conditional: it applies only to the extent that the harmonised standards in question actually cover the relevant Article 31 requirements. Where gaps exist — either because no standard has been published or because a standard does not address a particular requirement — conformity must be demonstrated through other evidence. The article thus functions as a conformity shortcut within a broader framework of substantive accountability, maintaining the integrity of the notified body system while reducing administrative friction for well-governed assessment bodies. ## What This Means in Practice Article 32 is primarily relevant to conformity assessment bodies seeking notification status under the EU AI Act and to the national notifying authorities that evaluate their applications. For a conformity assessment body wishing to act as a notified body for high-risk AI systems, the practical path under Article 32 is straightforward in principle: identify the harmonised standards whose references the Commission has published in the Official Journal, demonstrate conformity with those standards — typically through accreditation by a national accreditation body operating under Regulation (EC) No 765/2008 — and benefit from the presumption when the notifying authority reviews the application under Article 28 and following. In practice, the most relevant harmonised standard for conformity assessment bodies operating in the AI space is likely to be ISO/IEC 17065 (for product certification bodies) or ISO/IEC 17020 (for inspection bodies), alongside any AI-specific harmonised standards that the Commission develops and references under Article 40. Until AI-specific harmonised standards are published, bodies must rely on existing standards and demonstrate how they map to Article 31 criteria. For notifying authorities — the national bodies designated under Article 28 — Article 32 simplifies the evaluation workload. Where a conformity assessment body presents valid accreditation certificates against published harmonised standards, the authority may treat the covered requirements as satisfied without conducting independent verification of each criterion. This does not eliminate oversight obligations: notifying authorities retain monitoring duties under Article 33 and must act if a notified body subsequently fails to maintain compliance. For providers of high-risk AI systems, Article 32 matters indirectly: it underpins confidence that the notified bodies assessing their systems have been verified against rigorous, publicly known standards. ## Key Obligations - A conformity assessment body seeking to benefit from the Article 32 presumption must demonstrate actual conformity with the published harmonised standards, not merely claim it — accreditation by a national accreditation body is the standard route for substantiating this. - The presumption applies only to the extent that harmonised standards cover the specific Article 31 requirements in question; bodies must separately evidence compliance with any requirements not addressed by available standards. - Notifying authorities must recognise the presumption when evaluating notification applications, but retain the right and duty to rebut it if evidence indicates non-compliance with underlying Article 31 requirements. - Notified bodies must maintain continuous conformity with the applicable harmonised standards throughout the period of notification, not only at the point of initial assessment. - Where the Commission has not yet published references to relevant harmonised standards in the Official Journal, conformity assessment bodies must demonstrate compliance with Article 31 requirements through alternative, verifiable evidence. - The Commission must publish references to relevant harmonised standards in the Official Journal of the European Union for the Article 32 presumption mechanism to be operationally available. ## Relationship to Other Articles Article 32 cannot be read in isolation from the surrounding Chapter 4 framework. Its direct referent is Article 31, which enumerates the substantive requirements for notified bodies; Article 32 solely addresses the evidentiary mechanism for satisfying those requirements and has no independent substantive content. Article 28 establishes the notifying authorities responsible for assessing and notifying conformity assessment bodies, and those authorities are the primary actors who apply or decline to apply the Article 32 presumption during notification procedures governed by Articles 29 and 30. Article 33 governs the operational obligations of notified bodies once designated, including cooperation duties with notifying authorities that are relevant when the presumption must be maintained over time. Article 40 — which establishes the harmonised standards regime for the AI Act more broadly — is the mechanism by which the Commission develops and references the standards that Article 32 relies upon. Beyond Chapter 4, Article 43 is relevant because it specifies the conformity assessment procedures that notified bodies must conduct for high-risk AI systems; the competence and governance of those bodies, validated through Articles 31 and 32, directly determines the credibility of those assessments. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024, twenty days after its publication in the Official Journal of the European Union on 12 July 2024. Article 32, situated in Title III Chapter 4, belongs to the provisions governing the infrastructure for high-risk AI system oversight and does not fall within the early application tranches. The prohibited AI practices under Article 5 became applicable on 2 February 2025. General-purpose AI model obligations under Title VIII became applicable on 2 August 2025. The obligations most directly connected to Article 32 — the full high-risk AI system conformity assessment regime including the notified body framework — become applicable progressively from 2 December 2027 for high-risk systems listed in Annex III, with a further extension to 2 August 2028 for certain high-risk AI systems already subject to existing Union harmonisation legislation listed in Annex I. Conformity assessment bodies that intend to act as notified bodies under the AI Act should therefore have initiated their accreditation and notification processes well before August 2026, as the notification procedure under Articles 28 through 30 involves national authority assessment, Commission notification, and a waiting period before a body may lawfully perform conformity assessments. National notifying authorities should ensure that their evaluation frameworks reflect published harmonised standards as they become available, so that the Article 32 presumption mechanism is operationally functional by the time the high-risk regime applies in full. -------------------------------------------------------------------------------- ## Article 33 — Subsidiaries of notified bodies and subcontracting (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-33/ ## Official Text Summary Article 33 of Regulation (EU) 2024/1689 governs the conditions under which notified bodies may delegate conformity assessment activities to subsidiaries or external subcontractors. The article establishes that a notified body wishing to subcontract specific conformity assessment tasks or use a subsidiary to carry out such tasks must first obtain the client's consent to that arrangement. Where subcontracting or subsidiary arrangements are used, the notified body is required to ensure that the subcontractor or subsidiary meets the same requirements established for notified bodies in respect of the specific tasks being delegated. This obligation mirrors the qualification, impartiality, and operational requirements set out elsewhere in Chapter 4 of Title III. Crucially, Article 33 places unambiguous responsibility on the notified body: it must take full responsibility for the work carried out by subcontractors and subsidiaries, regardless of where those entities are established — whether within the EU or in a third country. The notified body is also required to keep at the disposal of its notifying authority all relevant documentation concerning the assessment of the subcontractor's or subsidiary's qualifications and the work performed by those entities under the delegation. This article ensures that the delegation of conformity assessment tasks cannot be used to circumvent the stringent requirements that notified bodies themselves must satisfy, and that accountability remains concentrated at the level of the body formally designated by the notifying authority. ## What This Means in Practice Article 33 directly affects notified bodies operating under the EU AI Act, their corporate parents, subsidiaries, and any third-party service providers they engage to perform portions of conformity assessment work for high-risk AI systems. For a notified body seeking to scale its operations or leverage specialist expertise, subcontracting and the use of subsidiaries offers operational flexibility — but that flexibility comes with strict accountability requirements. Before engaging a subcontractor, the notified body must verify that the subcontractor satisfies the relevant qualification requirements applicable to notified bodies for those specific tasks. A general vendor contract is insufficient; a substantive compliance assessment of the subcontractor's competence and independence must be conducted and documented. The client of the conformity assessment — typically the provider of the high-risk AI system — must explicitly consent to any subcontracting arrangement. In practice, this means that contractual agreements for conformity assessment services should address subcontracting upfront, specifying whether consent is granted in general or must be sought case by case. For AI system providers undergoing third-party conformity assessment, Article 33 provides a right of transparency: they must know who is performing the assessment and have the opportunity to object. Providers should include subcontracting disclosure clauses in their agreements with notified bodies and verify that any subcontractors engaged are suitably qualified. For notified bodies with international group structures, Article 33 is particularly relevant: work performed by a non-EU subsidiary on behalf of the notified body falls within scope, and the EU-based notified body remains accountable for the quality and compliance of that work. ## Key Obligations - **Prior client consent**: The notified body must obtain the conformity assessment client's explicit consent before subcontracting any task or using a subsidiary to perform conformity assessment activities. - **Equivalence of requirements**: Subcontractors and subsidiaries must meet the same requirements that apply to the notified body itself for the specific conformity assessment tasks being delegated, including competence, impartiality, and operational standards. - **Full retained responsibility**: The notified body retains complete legal and regulatory responsibility for all work performed by subcontractors and subsidiaries; this accountability cannot be transferred, delegated, or contractually disclaimed. - **Notification to notifying authority**: The notified body must inform its notifying authority of subcontracting arrangements and subsidiary activities, and must make available all relevant documentation regarding the qualifications of subcontractors and the work they have performed. - **Documentation and record-keeping**: The notified body must maintain comprehensive records of subcontractor qualification assessments and the outputs of delegated conformity assessment tasks, available to the notifying authority on request. - **Geographic scope**: Obligations apply regardless of whether the subcontractor or subsidiary is established within the European Union or in a third country. ## Relationship to Other Articles Article 33 must be read in close conjunction with the broader framework for notified bodies established in Chapter 4 of Title III. Article 28 (Notified bodies) sets out the substantive requirements — including competence, independence, and impartiality — that subcontractors and subsidiaries must satisfy under Article 33. Article 29 (Independence of notified bodies) is equally relevant, since subcontracting arrangements must not compromise the impartiality of the conformity assessment process. Articles 30 and 31 govern the notification and designation process for notified bodies and inform what standards a body must meet to be eligible to perform conformity assessment tasks. Article 43 (Conformity assessment procedures for high-risk AI systems) defines the scope of conformity assessment activities that notified bodies are called upon to perform, and therefore the activities to which Article 33 subcontracting rules apply. Article 74 (Market surveillance) is also relevant, as market surveillance authorities may scrutinise whether notified bodies and their subcontractors have respected Article 33 obligations when investigating compliance failures. ## Compliance Timeline The EU AI Act (Regulation 2024/1689) entered into force on 1 August 2024. Article 33, as part of the framework governing notified bodies and their operational requirements, is subject to the general phased application schedule: - **1 August 2024**: Entry into force. The Regulation becomes binding EU law. - **2 February 2025**: Prohibitions on unacceptable-risk AI practices apply (Title II). - **2 August 2025**: Rules on general-purpose AI models (Title VIII) and governance provisions begin to apply. - **2 August 2028**: The conformity assessment framework — including the rules on notified bodies under Title III, Chapter 4, and therefore Article 33 — applies to high-risk AI systems listed in Annex I (safety-component systems regulated by Union harmonisation legislation). - **2 December 2027**: Full application of conformity assessment obligations for high-risk AI systems listed in Annex III, including the operational requirements under Article 33 for subcontracting and use of subsidiaries. Notified bodies seeking designation under the EU AI Act should treat Article 33 compliance as part of their initial designation readiness, ensuring that subcontracting policies, subsidiary governance frameworks, and client contract templates reflect the article's requirements well before the relevant application dates. -------------------------------------------------------------------------------- ## Article 34 — Operational obligations of notified bodies (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-34/ ## Official Text Summary Article 34 of Regulation (EU) 2024/1689 sets out the operational obligations that notified bodies must comply with on a continuing basis once designated. The article requires notified bodies to perform conformity assessments in line with the procedures specified in Annex VII of the Regulation, ensuring consistency, impartiality, and technical rigour throughout the process. Notified bodies are required to maintain, and make available upon request to the notifying authority, documented procedures covering all conformity assessment activities they carry out. They must employ sufficient numbers of personnel with the necessary competence, qualifications, and experience relevant to the specific types of AI systems and risk domains for which they are designated. The article imposes a strict obligation of confidentiality: notified bodies and their staff must treat all information obtained in the course of their assessment activities as confidential, subject to obligations owed to the relevant national authority. Conflicts of interest must be systematically identified, documented, and avoided. Notified bodies are required to take out and maintain appropriate professional liability insurance commensurate with their activities. Where a notified body subcontracts specific assessment tasks or relies on a subsidiary, it remains fully accountable for the quality and outcome of the work. Subcontractors must meet the same requirements as the notified body, and the provider subject to assessment must be informed of any subcontracting arrangement before it takes place. Finally, notified bodies must participate in relevant coordination activities and cooperate with competent authorities, market surveillance authorities, and other notified bodies to ensure coherent application of the conformity assessment procedures across the Union. ## What This Means in Practice For organisations operating as or seeking to become notified bodies, Article 34 translates into a demanding and continuous compliance burden rather than a one-time designation exercise. **For notified bodies**, the article means establishing and maintaining robust internal management systems that document every step of each conformity assessment. Staffing decisions must be driven by demonstrated technical competence specific to the AI domains covered — a notified body designated for medical AI systems, for instance, must be able to demonstrate that its assessors understand both AI methodology and the relevant medical device regulatory context. Personnel rosters, training records, and competence matrices will all be subject to scrutiny by the notifying authority. Conflict-of-interest policies must go beyond paper commitments. Notified bodies must actively screen for relationships between their staff and the providers submitting for assessment, and must document the outcome of each screening. Where a conflict is identified, the affected personnel must be excluded from the relevant assessment. On subcontracting, practical due diligence is required before any work is delegated: written agreements, competence verification, and advance notification to the AI system provider. The notified body cannot disclaim responsibility for subcontracted work if the assessment is later found to be deficient. **For providers of high-risk AI systems**, Article 34 is largely procedural background — but it matters for selecting a notified body. Providers should verify that a candidate notified body holds a current designation scope covering their product category, carries adequate insurance, and has published transparent procedures. Providers also retain the right to be informed of subcontracting arrangements and may factor this into their assessment planning. Notified bodies must also feed into the broader EU oversight architecture, sharing information with the European Artificial Intelligence Office and contributing to harmonised assessment standards as they develop. ## Key Obligations - **Conformity assessment procedures**: Notified bodies must conduct all assessments in accordance with the procedures laid down in Annex VII to the Regulation, maintaining documented processes for each assessment activity. - **Competence and staffing**: Sufficient qualified personnel must be available at all times, with expertise matched to the specific type and risk domain of the AI systems for which the body is designated. - **Confidentiality**: All information acquired in the course of conformity assessment activities must be kept confidential, except where disclosure is required by the relevant national authority or by Union law. - **Conflict-of-interest management**: Notified bodies must systematically identify and exclude conflicts of interest, documenting the screening process for each assessment and ensuring impartiality at every stage. - **Professional liability insurance**: Appropriate insurance must be maintained on an ongoing basis to cover the notified body's conformity assessment activities, providing recourse in the event of an erroneous or deficient assessment. - **Subcontracting and subsidiary use**: Where tasks are subcontracted or delegated to a subsidiary, the notified body remains fully responsible, must verify subcontractor competence against the same standards, and must inform the provider before subcontracting takes place. ## Relationship to Other Articles Article 34 sits within Title III, Chapter 4 (Articles 28–39), which governs the full lifecycle of notified bodies — from designation through to monitoring and withdrawal. It builds directly on Article 33, which sets out the substantive requirements a body must meet to qualify for designation, and should be read alongside Article 35, which governs the conformity assessment process for high-risk AI systems in the product safety-regulated sectors listed in Annex II. Article 43 (Conformity assessment) specifies when third-party notified body involvement is mandatory versus when a provider may self-assess, making it essential context for understanding the scope of Article 34 obligations. Article 44 addresses the certificates issued following assessment, while Article 45 governs the obligations of notified bodies in respect of those certificates once issued, including suspension and withdrawal. Broader oversight accountability connects Article 34 to Article 70 (Confidentiality) and Articles 74–77 governing market surveillance authorities, since notified bodies must cooperate with surveillance activities and supply information to competent authorities on request. ## Compliance Timeline Regulation (EU) 2024/1689 entered into force on **1 August 2024**, with application phased across several dates. Article 34 falls within the framework governing high-risk AI systems subject to third-party conformity assessment. The relevant phased application dates are: - **1 August 2024** — Entry into force. The Regulation became binding Union law; Member States began preparatory work on notifying authority structures. - **February 2025** — Prohibited AI practices (Article 5) became applicable. Notified body obligations were not yet active for most high-risk categories. - **August 2025** — GPAI model obligations became applicable. Notified body provisions remained in preparatory phase for high-risk systems. - **2 December 2027** — Full application of Title III provisions, including Article 34, for high-risk AI systems listed in Annex III. Notified bodies must be operationally compliant and designated national notifying authorities must be fully functional by this date. - **2 August 2028** — Extended deadline for high-risk AI systems covered by existing Union harmonisation legislation listed in Annex I, where those systems are placed on the market or put into service before August 2026. Organisations seeking designation as notified bodies should have initiated the application process well in advance of August 2026, given that designation procedures require assessment by the national notifying authority and, where applicable, peer review involving the European Commission and other Member States. -------------------------------------------------------------------------------- ## Article 35 — Identification numbers and lists of notified bodies (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-35/ ## Official Text Summary Article 35 of Regulation (EU) 2024/1689 (the EU AI Act) establishes the administrative and transparency framework governing the identification and public listing of notified bodies operating under the regulation. The article places obligations principally on the European Commission and on Member States' notifying authorities. Under Article 35, the Commission is required to assign an identification number to each notified body. Crucially, where a body is notified under more than one Union act, it receives a single identification number, ensuring consistency across legislative instruments. The Commission is further required to make publicly available a list of all notified bodies, including their identification numbers and the activities for which they have been notified. This list must be kept up to date. Member States bear a complementary obligation: they must inform the Commission of any changes to a notified body's status — including the granting of new notifications, and any restrictions, suspensions, or withdrawals of existing notifications. The Commission is then responsible for reflecting those changes in the public list without undue delay. The article operates within Chapter 4 of Title III, which governs the overall architecture of notification: who may assess conformity of high-risk AI systems, under what conditions, and with what oversight. Article 35 specifically addresses the identification and visibility layer of that architecture, ensuring that the market — including providers seeking assessment, downstream deployers, and national authorities — can reliably identify which bodies are authorised, for what scope, and whether that authorisation remains current. ## What This Means in Practice Article 35 has direct operational implications for three categories of actors: providers of high-risk AI systems, notified bodies themselves, and national notifying authorities. For **providers** seeking third-party conformity assessment under Annex VI or the full quality management system route, Article 35 provides the primary verification mechanism. Before engaging a notified body, a provider should consult the Commission's NANDO database to confirm that the body holds a valid notification under the EU AI Act, covering the specific product category or AI system type in question. Relying on a body whose notification has lapsed, been suspended, or never formally extended to AI Act scope creates a compliance gap that could invalidate a conformity assessment certificate. For **notified bodies**, Article 35 creates an indirect obligation to cooperate with their national notifying authority to ensure that any change in their operational scope or authorisation status is promptly communicated upward. A body expanding its assessment scope — for example, adding a new high-risk category such as biometric categorisation systems — cannot legitimately act under that expanded scope until the notification has been updated and reflected on the Commission list. For **national notifying authorities**, the obligation is procedural but consequential: changes in a body's status must be communicated to the Commission promptly. Delays create a window during which the public list is inaccurate, potentially misleading providers or undermining market surveillance actions taken by authorities in other Member States. In concrete terms, a legal or compliance team preparing for a conformity assessment should build a checklist step that cross-references the selected notified body's identification number on NANDO, verifies the scope of notification matches the system's risk classification, and checks that no restrictions or suspensions appear against that record. ## Key Obligations - The European Commission must assign a single identification number to each notified body, consistent across all Union acts under which that body operates. - The Commission must publish and maintain a publicly accessible, up-to-date list of all notified bodies, including their identification numbers and notified scope. - Member States and their notifying authorities must inform the Commission without undue delay of any grants, restrictions, suspensions, or withdrawals of notification. - The Commission must update the public list to reflect changes in notified body status without undue delay following Member State notification. - Notified bodies may not act beyond their notified scope; any expansion of scope requires a formal update to the notification before the body may conduct assessments under that extended scope. - Providers must verify, prior to engaging a notified body, that the body's current listing on the Commission database covers the relevant activity and remains in good standing. ## Relationship to Other Articles Article 35 cannot be read in isolation; it forms part of a coherent framework within Chapter 4 of Title III. Article 28 defines the requirements that notifying authorities — the national bodies responsible for establishing and carrying out notification procedures — must themselves satisfy, providing the institutional foundation on which Article 35's notification flows depend. Article 29 sets out the detailed application requirements a conformity assessment body must meet before it can be notified, while Article 30 governs the notification procedure itself, including the formal communication to the Commission that triggers an Article 35 listing. Article 31 addresses the presumption of conformity for notified bodies certified under relevant harmonised standards. Operationally, Article 35 connects to Articles 43 and 44, which govern the conformity assessment procedures for high-risk AI systems and the resulting certificates — documents whose validity is inseparable from the standing of the issuing body as properly listed under Article 35. Article 74 (market surveillance) also relies on accurate Article 35 listings, since authorities coordinating cross-border oversight need to identify which body issued a given certificate and whether that body remains authorised. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024, twenty days after publication in the Official Journal. Application is phased: - **February 2, 2025** — Prohibitions on unacceptable-risk AI practices (Title II) became applicable. - **August 2, 2025** — Provisions on general-purpose AI models (Title VIII) and governance obligations became applicable. - **2 December 2027** — The bulk of Title III, including the notified body framework under Chapter 4, becomes fully applicable for high-risk AI systems listed in Annex III, except those covered by the extended deadline below. - **2 August 2028** — Extended deadline for high-risk AI systems covered by existing Union harmonisation legislation listed in Annex I (e.g., machinery, medical devices), giving those sectors additional time to integrate AI Act conformity assessment requirements into existing certification workflows. Article 35 itself, as part of the notified body infrastructure, becomes operationally relevant in parallel with the application of Chapter 4 conformity assessment requirements. Member States and the Commission should ensure that notification procedures, identification number assignment, and the public database are fully operational ahead of the December 2027 date so that providers of high-risk AI systems can engage compliant notified bodies from the moment mandatory conformity assessment obligations apply. -------------------------------------------------------------------------------- ## Article 36 — Changes to notifications (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-36/ ## Official Text Summary Article 36 of Regulation (EU) 2024/1689 (the EU AI Act) establishes the obligations that apply when a notified body's situation changes after the initial notification has been granted. It sits within Title III, Chapter 4, which governs the framework for notifying authorities and notified bodies involved in the conformity assessment of high-risk AI systems. The article requires notified bodies to promptly inform their respective notifying authority of any change that is relevant to their notified status. Such changes include alterations to legal form or ownership, modifications to the organisational structure or key personnel responsible for conformity assessment activities, changes in the technical scope for which the body was notified, and any circumstance that might affect the body's continued ability to fulfil the requirements set out in Article 33. Upon receiving notification of such changes, the notifying authority must assess whether the notified body continues to meet the applicable requirements. Where the assessment reveals non-compliance, the notifying authority is empowered to restrict, suspend, or withdraw the notification, proportionate to the severity of the deficiency identified. The notifying authority must also keep the Commission and other Member States informed through the established notification channels, ensuring that up-to-date information is accessible Union-wide. This continuous oversight mechanism is designed to guarantee that only capable and compliant bodies exercise conformity assessment responsibilities throughout their period of designation. ## What This Means in Practice Article 36 creates a live, ongoing compliance obligation for notified bodies — the duty to notify does not end at the moment a body receives its designation. Any organisation holding notified body status under the EU AI Act must maintain internal processes capable of detecting and escalating material changes in its circumstances, and must act on those processes without delay. In practical terms, a notified body should establish internal triggers that automatically flag reportable changes: for example, a merger or acquisition affecting ownership, the departure of a lead assessor holding key technical qualifications, the addition or removal of AI system categories from the body's operational scope, or the emergence of a conflict of interest with a conformity assessment client. Compliance teams at notified bodies should map these trigger events and assign clear internal responsibility for reporting to the notifying authority. The reporting should be timely — not retrospective — meaning that bodies cannot wait until an annual review cycle to disclose a change that occurred months earlier. For notifying authorities — typically national market surveillance or accreditation bodies — Article 36 demands that they have a structured intake process for change notifications and a documented assessment procedure to evaluate continued compliance. Where a notified body fails to self-report a material change, the notifying authority retains the right to investigate and act upon information received from other sources, including the Commission or peer Member States. Providers of high-risk AI systems who rely on a given notified body for their conformity assessment should monitor the NANDO database for any restriction or suspension affecting their chosen body, as such changes could interrupt or invalidate their certification pathway. ## Key Obligations - **Notified bodies** must immediately inform their notifying authority of any change in circumstances that could affect their compliance with the requirements of Article 33, including changes to legal status, ownership, organisational structure, technical scope, or key personnel. - **Notifying authorities** must reassess the notified body upon receiving a change notification and determine whether the body continues to satisfy all applicable requirements. - **Notifying authorities** must restrict, suspend, or withdraw the notification where reassessment reveals that the body no longer meets the conditions under which it was designated, applying measures proportionate to the gravity of the non-compliance. - **Notifying authorities** must communicate any changes to a body's notification — including restrictions, suspensions, and withdrawals — to the European Commission and to the other Member States without undue delay. - **The Commission's notification database** (NANDO) must be kept current to reflect the actual and valid scope of each notified body's designation, ensuring transparency and legal certainty across the Single Market. - **Notified bodies** must maintain internal governance arrangements sufficient to identify and escalate reportable changes on a continuous basis, rather than treating notification as a one-time event. ## Relationship to Other Articles Article 36 cannot be read in isolation; it forms part of a coherent framework established across Chapter 4 of Title III. The foundational requirements that a notified body must continue to satisfy are set out in **Article 33** (Requirements relating to notified bodies), which defines the baseline against which any change is assessed. The initial notification procedure — against which Article 36 represents the change-management counterpart — is established by **Article 34** (Notification procedure) and **Article 35** (Identification numbers and lists of notified bodies). Article 36 also connects to **Article 37** (Challenge to the competence of notified bodies), which provides the mechanism by which the Commission or Member States may raise concerns about a body's competence or compliance — a process that may be triggered precisely when a change disclosed under Article 36 raises doubts. More broadly, it supports the market surveillance and enforcement architecture of **Articles 74 to 83**, since a notified body operating outside its valid notification scope could undermine the integrity of the conformity assessments it has issued. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024**, twenty days after publication in the Official Journal of the European Union. Article 36, as part of the institutional and governance framework for conformity assessment, falls within the provisions that apply from **2 December 2027** — the general date of application for the majority of the Regulation's obligations, including those governing high-risk AI systems in Annex III. The obligations on notified bodies and notifying authorities under Chapter 4 are therefore active from that date, meaning that any body designated as a notified body under the EU AI Act from August 2026 onwards is immediately subject to the change-notification requirements of Article 36. Bodies notified under earlier sector-specific legislation that are transitioning to EU AI Act designation should integrate Article 36 compliance into their transition planning well in advance of the August 2026 deadline. For high-risk AI systems covered by Annex I (product safety legislation), the relevant conformity assessment infrastructure — including Article 36 obligations — aligns with the **August 2028** phased application date applicable to those product categories. Providers relying on notified bodies for Annex I system certification should verify the continued validity of their notified body's designation as that deadline approaches. -------------------------------------------------------------------------------- ## Article 37 — Challenge to the competence of notified bodies (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-37/ ## Official Text Summary Article 37 of Regulation (EU) 2024/1689 (the EU AI Act) establishes a supervisory mechanism through which the competence and continued compliance of notified bodies may be formally challenged. Where the Commission or a Member State has concerns that a notified body does not meet, or no longer meets, the requirements for notification set out in Article 31 — or is failing to fulfil its obligations — it may bring the matter to the attention of the notifying authority responsible for that body. Upon receiving such a challenge, the notifying authority is required to investigate the matter without undue delay. It must examine the evidence presented and, where the investigation reveals deficiencies, take proportionate corrective measures, which may include imposing conditions, restricting the scope of the notification, suspending the notification, or withdrawing it entirely, depending on the gravity of the non-compliance. The notifying authority must inform the Commission and all other Member States of any restrictive measures taken and of their outcome. This information-sharing obligation ensures transparency and prevents divergent treatment across the single market. The notified body concerned retains the right to submit observations before measures are imposed, safeguarding procedural fairness. Certificates already issued by a body whose notification has been suspended or withdrawn remain subject to separate provisions governing their continued validity or revocation. ## What This Means in Practice Article 37 is the enforcement backbone of the notified body framework established under Title III, Chapter 4. It creates a live accountability channel that operates throughout the lifecycle of a notified body — not just at the point of initial designation. **For providers of high-risk AI systems**, the article has direct practical consequences. Conformity assessments carried out by notified bodies are a prerequisite for placing many high-risk AI systems on the EU market (see Annex III and Article 43). If the body that performed your conformity assessment has its notification suspended or withdrawn following an Article 37 challenge, you must assess whether previously issued certificates remain valid and whether re-assessment by a compliant body is required before continued market access. **For notified bodies themselves**, Article 37 means that designation is not a permanent status. Any Member State or the Commission can trigger a formal review at any time based on evidence of non-compliance. Bodies should therefore maintain continuous compliance with the requirements of Articles 31 to 36 — not only when seeking initial designation. Robust quality management systems, transparent documentation practices, and proactive communication with the notifying authority are the primary safeguards against a successful challenge. **For notifying authorities**, the article creates a mandatory investigative duty. Receipt of a credible challenge is not discretionary; the authority must act, document its findings, apply proportionate measures, and report to the Commission and peers. This places a premium on having clear internal procedures for handling inter-Member State notifications and Commission referrals. A practical example: if a German notified body is found to have certified a high-risk AI recruitment tool without conducting the required technical file review, France or the Commission could raise the matter under Article 37, prompting the relevant German notifying authority to investigate and potentially suspend the body's right to issue further certificates in that product category. ## Key Obligations - **Any Member State or the Commission may challenge** the competence of a notified body at any time by bringing substantiated concerns to the notifying authority, triggering a mandatory investigation. - **The notifying authority must investigate without undue delay**, examine evidence of non-compliance with Articles 31 to 36, and reach a reasoned conclusion. - **Proportionate corrective measures must be applied** where deficiencies are confirmed, ranging from imposition of conditions and scope restrictions to full suspension or withdrawal of notification. - **Procedural fairness must be observed** — the notified body must be given a meaningful opportunity to submit observations before any restrictive measure is finalised. - **All restrictive measures and outcomes must be communicated** to the Commission and all other Member States to ensure transparency and consistent market oversight across the EU. - **Notified bodies whose notifications are suspended or withdrawn must cease** the relevant conformity assessment activities immediately, and the status of certificates issued during the affected period must be addressed in accordance with applicable provisions. ## Relationship to Other Articles Article 37 cannot be read in isolation and is tightly coupled with several other provisions of the Regulation. The substantive requirements whose non-fulfilment triggers a challenge under Article 37 are laid down in **Article 31** (requirements for notified bodies) and **Articles 32 to 36** (the notification procedure, NANDO information systems, changes to notifications, and subsidiary obligations of notified bodies). The conformity assessment procedures that notified bodies must correctly perform are specified in **Article 43** and the relevant sections of **Annex VII**. Where a challenge leads to withdrawal of a notification, the consequences for certificates already issued connect to **Article 44** (certificates issued by notified bodies) and **Article 46** (obligations of notified bodies regarding information). **Article 38** complements Article 37 by addressing the coordination and advisory role of the AI Board in ensuring consistent supervisory practice across notifying authorities. Market surveillance provisions under **Articles 74 to 76** provide parallel enforcement tools at the product level, while Article 37 focuses on the institutional level — the body itself rather than any individual AI system. ## Compliance Timeline Article 37 falls within the provisions governing notified bodies and the high-risk AI system conformity assessment framework. The EU AI Act entered into force on **1 August 2024**, twenty days after publication in the Official Journal. The provisions of Title III, Chapter 4 — including Article 37 — become **fully applicable on 2 December 2027**, the general application date for obligations relating to high-risk AI systems listed in Annex III (with the exception of systems covered by Annex I, certain of which apply from **2 August 2028**). Notifying authorities and prospective notified bodies should have been operationally ready from mid-2025 onwards, given that the designation and notification process under Articles 31 to 36 must be completed before bodies can legally perform conformity assessments for products reaching the market on the 2026 application date. The challenge mechanism under Article 37 is operative from the moment notified bodies are formally designated and begin issuing certificates. Providers relying on third-party conformity assessments should monitor the status of their notified body via the NANDO database throughout the product lifecycle, as a challenge lodged after market placement can have retrospective consequences for certificate validity. -------------------------------------------------------------------------------- ## Article 38 — Coordination of notified bodies (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-38/ ## Official Text Summary Article 38 of Regulation (EU) 2024/1689 establishes a mandatory coordination framework for notified bodies carrying out conformity assessments of high-risk AI systems under Title III, Chapter 5 of the Act. The article requires notified bodies to participate in, and actively contribute to, a coordination group operating under the oversight and facilitation of the European Commission. The coordination mechanism serves a dual function. First, it ensures procedural consistency: notified bodies must align their assessment methodologies, interpretive approaches, and procedural standards so that equivalent high-risk AI systems receive equivalent scrutiny regardless of the Member State in which the assessment takes place. Second, it enables substantive learning: bodies must share relevant experience, emerging findings, and best practices arising from actual conformity assessments. The Commission is tasked with facilitating the coordination group and may link it to existing sectoral coordination structures established under relevant Union harmonisation legislation — such as those operating in the medical devices, machinery, or civil aviation sectors — where AI systems are subject to sector-specific assessment requirements. Where European standardisation bodies such as CEN-CENELEC have developed harmonised standards relevant to AI, coordination under Article 38 must take those standards into account. The article further provides that the Commission may adopt implementing acts to establish operational arrangements for the coordination group, including rules on information sharing, the frequency of coordination activities, and mechanisms for resolving divergences between bodies. ## What This Means in Practice For organisations developing or deploying high-risk AI systems, Article 38 has significant indirect compliance implications even though its direct obligations fall on notified bodies rather than on providers or deployers. The most immediate practical effect is consistency of conformity assessment outcomes. Before the EU AI Act, divergent interpretations of technical requirements across Member State conformity assessment bodies were a recognised problem in the CE marking ecosystem. Article 38 is designed to prevent this from recurring for AI. Providers choosing a notified body for a conformity assessment can expect that the substantive standards applied will be comparable regardless of whether they engage an Austrian, Dutch, or German body. For providers, this means documentation and technical files prepared for conformity assessment should be designed to meet a harmonised baseline rather than tailored to the idiosyncrasies of a particular body. It also means that information shared by a notified body within the coordination group — such as patterns of non-conformity or recurrent documentation gaps — may indirectly shape the scrutiny applied to future assessments across the whole ecosystem. Deployers of high-risk AI systems in regulated sectors should note that sectoral coordination linkages under Article 38 mean that bodies assessing AI components embedded within medical devices, industrial machinery, or transport systems may be applying coordination outputs from both the AI Act group and the relevant sectoral group simultaneously. Compliance teams should monitor guidance and technical notes published by the Commission or the AI Office arising from coordination group activities. Notified bodies themselves must budget for active participation in coordination, including staff time for meetings, working groups, and information-sharing obligations. Bodies that fail to engage meaningfully with coordination mechanisms risk adverse findings during the monitoring and peer review processes established elsewhere in Chapter 4. ## Key Obligations - Notified bodies must participate in the coordination group established or facilitated by the European Commission and contribute actively to its work. - Bodies must share relevant experience, assessment findings, and methodological approaches with other participating notified bodies through the coordination structure. - Bodies must align their conformity assessment practices with common approaches and interpretations developed through coordination, preventing divergent outcomes for comparable AI systems. - The Commission must facilitate the coordination group and may link it to existing sectoral coordination bodies operating under other Union harmonisation legislation where AI systems fall within the scope of both regimes. - The Commission may adopt implementing acts specifying organisational arrangements for the coordination group, including information-sharing protocols and procedures for resolving interpretive divergences between bodies. - Notified bodies must take into account harmonised standards and relevant outputs from European standardisation activities when conducting coordinated assessments. ## Relationship to Other Articles Article 38 sits within Title III, Chapter 4, which collectively governs the designation, monitoring, and operation of notifying authorities and notified bodies. It must be read alongside Article 33, which establishes the substantive requirements a body must meet to be designated as a notified body, and Article 34, which covers the notification procedure itself. Article 35 addresses the operational obligations of notified bodies during assessments, while Article 36 covers subsidiaries and subcontracting. Article 37 establishes the monitoring and review of notified bodies by notifying authorities. Beyond Chapter 4, Article 38 connects directly to the conformity assessment procedures in Chapter 5, particularly Articles 43 and 44, which specify when third-party notified body involvement is mandatory. The coordination work under Article 38 also intersects with the role of the AI Office established under Article 64 and the European Artificial Intelligence Board under Article 65, both of which have responsibilities for ensuring consistent application of the Regulation across Member States. Standardisation mandates issued under Article 40 are a primary input into the coordination group's technical work. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024, following publication in the Official Journal of the European Union. Application of the Regulation is phased: - **February 2025** — Prohibitions on unacceptable-risk AI practices (Article 5) began applying. - **August 2025** — Obligations for general-purpose AI models (Title VIII) became applicable. Notified bodies may begin applying for designation from this date, triggering the initial activation of coordination obligations under Article 38. - **August 2028** — Conformity assessment obligations for high-risk AI systems listed in Annex I (products governed by existing Union harmonisation legislation) begin applying. - **December 2027** — Full application of high-risk AI system obligations under Annex III, making the notified body coordination framework under Article 38 fully operational across all covered use cases. Organisations subject to third-party conformity assessments should engage with notified bodies well before the December 2026 and August 2027 deadlines, as coordination group outputs and harmonised assessment protocols are expected to solidify during 2025 and 2026. Monitoring Commission implementing acts relating to Article 38 coordination arrangements is recommended from mid-2025 onwards. -------------------------------------------------------------------------------- ## Article 39 — Conformity assessment bodies of third countries (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-39/ ## Official Text Summary Article 39 of Regulation (EU) 2024/1689 (the EU AI Act) addresses the conditions under which conformity assessment bodies established in third countries — that is, countries outside the European Union — may be recognised and notified for the purposes of carrying out conformity assessments of high-risk AI systems under the Regulation. The article establishes a narrow but important gateway: third-country conformity assessment bodies may be notified only where a bilateral or multilateral international agreement between the Union and the third country in question expressly provides for such recognition. In the absence of a qualifying international agreement, no third-country body may act as a notified body under the EU AI Act. Where a valid international agreement exists, third-country bodies wishing to be notified must satisfy the same requirements imposed on EU-established conformity assessment bodies under Chapter 4 of Title III. This means they must demonstrate technical competence, organisational impartiality, and operational independence equivalent to that required of European notified bodies. Notification is processed through the competent notifying authority of a Member State in accordance with the standard notification procedure set out in the preceding articles of Chapter 4. The article thus ensures that any extension of the conformity assessment framework beyond EU borders preserves the integrity, equivalence, and enforceability of the system established by the Regulation. ## What This Means in Practice Article 39 is primarily relevant to providers of high-risk AI systems who operate across jurisdictions covered by EU trade or mutual recognition agreements, and to conformity assessment bodies established in third countries that seek to offer EU AI Act certification services. In practical terms, the article means that a testing laboratory or certification body based in, for example, the United Kingdom, Japan, or another country with which the EU has concluded a relevant international agreement could, in principle, be designated as a notified body for EU AI Act purposes — provided the agreement expressly covers AI Act conformity assessments and the body meets all applicable requirements. At the time of the Regulation's entry into force, no such AI-Act-specific mutual recognition agreements were yet in place, meaning the provision operates prospectively: it creates the legal basis for future recognition without itself activating any specific third-country body. For providers of high-risk AI systems, this has a concrete implication: until qualifying international agreements are concluded and bodies are formally notified, they cannot rely on assessments conducted by a third-country body to satisfy their conformity assessment obligations under Articles 43 and 44. Any certificate or audit report issued by a body that has not been validly notified under the Article 39 pathway will not satisfy EU AI Act requirements, regardless of the technical quality of the assessment. Compliance teams should therefore monitor EU trade agreement developments and the NANDO (New Approach Notified and Designated Organisations) database for any future notifications of third-country bodies under this provision. ## Key Obligations - Third-country conformity assessment bodies may only be notified where an international agreement between the European Union and the relevant third country expressly provides for such notification — no agreement, no recognition. - Bodies seeking notification under Article 39 must meet the full set of requirements applicable to EU-established conformity assessment bodies under Chapter 4 of Title III, including technical competence, impartiality, and independence criteria. - Notification of third-country bodies must follow the standard notification procedure applicable under the Regulation, routed through a Member State notifying authority. - Providers of high-risk AI systems must verify that any conformity assessment body they engage is validly notified — whether EU-based or third-country — before relying on that body's assessment to demonstrate compliance. - Member States and the Commission must ensure that any international agreement underpinning third-country body notification maintains the equivalence and enforceability of the EU AI Act conformity assessment framework. ## Relationship to Other Articles Article 39 sits within Title III, Chapter 4 (Notifying Authorities and Notified Bodies) and must be read in conjunction with the surrounding articles of that chapter. Articles 33 and 34 establish the general requirements and obligations applicable to notified bodies; Article 35 governs the notification procedure itself; and Articles 36 and 37 address changes to notifications and challenges to notified body competence. Because Article 39 applies those same requirements wholesale to third-country bodies, it cannot be interpreted in isolation from them. Beyond Chapter 4, Article 39 connects to Article 43, which specifies the conformity assessment procedures applicable to high-risk AI systems, and Article 44, which governs the certificates issued by notified bodies. Any third-country body notified under Article 39 must issue certificates that satisfy Article 44 in full. The article also intersects with the broader framework of EU international trade law and the Union's bilateral and multilateral agreement-making competences under the Treaty on the Functioning of the European Union. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024, twenty days after publication in the Official Journal. The Regulation applies in phased stages: - **February 2, 2025** — Prohibitions on unacceptable-risk AI practices (Title II) became applicable. - **August 2, 2025** — Provisions on general-purpose AI models (Title VIII) and governance structures became applicable. - **2 December 2027** — The majority of obligations for high-risk AI systems listed in Annex III, including conformity assessment requirements under Title III, become applicable. This is the primary applicability date for Article 39 in practice, as it governs the notified body framework that underpins those assessments. - **2 August 2028** — Extended deadline for high-risk AI systems covered by Annex I (safety-component systems regulated under existing Union harmonisation legislation) to comply. Article 39 itself has been legally in force since August 2024, but its operational relevance crystallises from December 2027 onwards, when providers of high-risk AI systems must have completed conformity assessments through validly notified bodies. Organisations should begin identifying suitable notified bodies — and monitoring any qualifying international agreements that may activate third-country bodies under Article 39 — well in advance of that date. -------------------------------------------------------------------------------- ## Article 4 — AI literacy (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-4/ ## Official Text Summary Article 4 of Regulation (EU) 2024/1689 establishes a general AI literacy obligation for providers and deployers of AI systems operating within the scope of the Regulation. The article requires that providers and deployers take measures to ensure, to their best extent, that their staff and any other persons acting on their behalf who are involved in the operation and use of AI systems possess a sufficient degree of AI literacy. The article defines AI literacy as the skills, knowledge, and understanding that allow persons to make informed decisions about AI systems, to deploy and use them properly, and to be aware of the impact those systems may have. Crucially, the obligation is calibrated: the required level of literacy must be proportionate to the technical knowledge, experience, education, training, and context of the individuals concerned, as well as to the AI systems they handle. Article 4 therefore does not impose a uniform standard. Instead, it creates a due-diligence framework under which organisations must assess the competency needs of relevant staff relative to the AI systems in question and take appropriate corrective or developmental action where gaps exist. The provision reflects the legislature's intent — articulated in Recital 20 — that human oversight of AI systems is only meaningful where the humans exercising that oversight possess the foundational understanding needed to do so effectively. The obligation is horizontal in scope: it applies regardless of the risk category of the AI system concerned, making it one of the few provisions in Title I that generates direct, actionable obligations for all actors within the Regulation's reach. ## What This Means in Practice Article 4 creates an ongoing internal governance obligation. Any organisation that qualifies as a provider (placing an AI system on the EU market or putting it into service) or a deployer (using an AI system under its authority in a professional context) must actively assess and address the AI literacy of relevant personnel. In practice, this means organisations should begin by mapping which roles interact with AI systems — whether building, integrating, operating, supervising, or reviewing AI outputs. A legal team using a contract-analysis tool, a HR department deploying a CV-screening system, or an engineering team maintaining a predictive-maintenance model all fall within scope. Each role-holder must have a level of AI literacy appropriate to their responsibilities. Concretely, compliance actions may include: - Conducting a skills-gap assessment across AI-adjacent roles - Designing or sourcing role-specific training (technical staff require deeper knowledge of model behaviour, bias, and uncertainty; business users require awareness of limitations and escalation pathways) - Documenting literacy measures taken as part of broader AI governance records - Reviewing and refreshing literacy programmes as AI systems evolve or new systems are introduced For organisations that prefer a structured route, the free [EU AI Act Fundamentals training course](/academy/ai-act-fundamentals/) covers scope, risk classification, and obligations in five modules and issues an AI literacy certificate that documents the Article 4 baseline; the [EU AI Act certification guide](/academy/certification/) explains what certifications exist and how staff can get certified. A logistics company deploying a route-optimisation model, for example, should ensure that operators who act on the model's recommendations understand the system's confidence ranges, known failure modes, and when to override. Similarly, a healthcare provider deploying a diagnostic-support tool must ensure clinicians understand what the tool does and does not do before relying on its outputs. The proportionality principle means a solo-practitioner deploying a simple AI tool will face lighter obligations than a multinational deploying high-risk systems at scale. ## Key Obligations - **Assess AI literacy needs:** Providers and deployers must identify which staff and appointed persons interact with AI systems and evaluate their existing level of AI literacy against the demands of those roles. - **Take appropriate literacy measures:** Organisations must actively implement measures — training, documentation, guidance, or structured upskilling — proportionate to each person's role, existing competence, and the systems involved. - **Apply proportionality:** The level of AI literacy required is not uniform; it must reflect the technical complexity of the AI system, the degree of autonomy it exercises, and the potential impact of the role-holder's decisions. - **Maintain ongoing coverage:** The obligation is continuous. As AI systems change, as new systems are deployed, or as staff rotate into AI-adjacent roles, literacy measures must be reviewed and updated accordingly. - **Extend obligation to third parties acting on the organisation's behalf:** The article explicitly covers persons acting on behalf of providers or deployers, meaning contracted staff, service providers, and agents involved in AI system operation are within scope. - **Document efforts:** While Article 4 does not specify a documentation requirement, alignment with the Regulation's broader governance expectations (particularly for high-risk systems) means that records of literacy assessments and training activities constitute best practice and support demonstrable compliance. ## Relationship to Other Articles Article 4 sits within Title I (General Provisions) and functions as a horizontal enabler for the Regulation's more specific obligations. It is directly linked to Article 9 (risk management system for high-risk AI), which requires that persons responsible for AI risk management possess the necessary competence — a standard that presupposes baseline AI literacy. It reinforces Article 14 (human oversight), where meaningful oversight by natural persons depends on those persons understanding AI system outputs, limitations, and failure modes. Article 4 also connects to Article 16(g), which requires providers of high-risk AI systems to take steps to ensure deployers can interpret and use the system appropriately, and to Article 26(2), which obliges deployers to assign human oversight to persons with the necessary competence. In the context of general-purpose AI models (Title VIII), Article 4 underpins the expectation that deployers building on GPAI model outputs understand the nature and limitations of those models. Reading Article 4 alongside Recital 20 clarifies the legislature's intent that AI literacy is a precondition for the effective exercise of all other obligations under the Regulation. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024**, twenty days after publication in the Official Journal. The Regulation applies in phases: - **2 February 2025** — Prohibitions on unacceptable-risk AI practices (Article 5) became applicable. - **2 August 2025** — Article 4 became applicable, along with provisions on general-purpose AI models (Title VIII) and the obligations governing notified bodies and market surveillance authorities. Organisations should have had AI literacy measures in place by this date. - **2 August 2028** — Obligations for high-risk AI systems listed in Annex I (safety-component systems in regulated products) apply. - **2 December 2027** — Obligations for high-risk AI systems listed in Annex III (standalone high-risk systems) apply in full, including Articles 9–14 and 26, for which Article 4 literacy is a prerequisite. Organisations that have not yet conducted a literacy gap assessment or implemented any training measures are already non-compliant with Article 4 as of August 2025 and should treat remediation as an immediate priority. -------------------------------------------------------------------------------- ## Article 40 — Harmonised standards and standardisation deliverables (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-40/ ## Official Text Summary Article 40 of Regulation (EU) 2024/1689 establishes the role of harmonised standards in demonstrating conformity with the requirements applicable to high-risk AI systems under the EU AI Act. Where providers of high-risk AI systems apply harmonised standards — or relevant parts thereof — whose references have been published in the Official Journal of the European Union, those systems are presumed to conform with the requirements of Title III, Chapter 3, insofar as those requirements are covered by the applicable harmonised standards. The article empowers the European Commission to issue standardisation requests to the European standardisation organisations (CEN, CENELEC, and ETSI) in accordance with Regulation (EU) No 1025/2012 on European standardisation. These requests direct the ESOs to develop harmonised standards that operationalise the substantive requirements of the Act. Article 40 also addresses situations where harmonised standards do not yet exist or their references have not been published. In such cases, the Commission may adopt common specifications pursuant to Article 41, ensuring that providers have a defined technical pathway to demonstrate conformity even in the absence of formal harmonised standards. The provision draws a clear distinction between voluntary application of standards and mandatory compliance with the underlying legal requirements. Applying a harmonised standard is not obligatory, but it provides a rebuttable presumption of conformity, reducing the evidentiary burden on providers during conformity assessment procedures conducted under Articles 43 and 44. ## What This Means in Practice For providers of high-risk AI systems, Article 40 is a central compliance tool. Rather than constructing an entirely bespoke technical argument for how each legal requirement is satisfied, providers can align their systems with published harmonised standards and benefit from the presumption of conformity. This significantly simplifies the conformity assessment process, particularly for systems subject to third-party assessment by notified bodies. In practice, a provider developing an AI-based medical device falling under Annex I of the Act would consult the Official Journal to identify which harmonised standards have been published for the relevant requirements — for example, standards addressing risk management, data quality, or cybersecurity. Implementing those standards as part of the system's design and quality management process allows the provider to assert conformity with the corresponding articles of the Act without requiring the notified body to independently verify compliance from first principles. For providers who choose not to apply harmonised standards — or where no applicable standard yet exists — the burden falls on them to document, through technical files and conformity assessment evidence, how the equivalent level of protection is achieved. This is a viable but more demanding path, requiring close engagement with the notified body and potentially more extensive testing and documentation. Importers and deployers should verify that the providers whose systems they place on the market or put into service have correctly identified and applied the relevant standards, as this affects the validity of the EU declaration of conformity and the CE marking. The practical impact of Article 40 will grow progressively as the standardisation pipeline matures. Early in the Act's application, limited harmonised standards will be available, placing greater reliance on common specifications and bespoke technical assessments. ## Key Obligations - **Identify applicable harmonised standards:** Providers of high-risk AI systems must monitor the Official Journal of the European Union for published references to harmonised standards relevant to their system and the requirements under Title III, Chapter 3. - **Apply standards to trigger the presumption of conformity:** Where a provider chooses to rely on the presumption of conformity, the harmonised standard must be applied in full for the requirements it covers; partial application does not extend the presumption to uncovered elements. - **Document application of standards in technical documentation:** The technical documentation required under Article 11 and Annex IV must clearly identify which harmonised standards have been applied and how they map to the corresponding legal requirements. - **Address gaps where standards do not exist:** Where no harmonised standard covers a specific requirement, providers must demonstrate conformity through alternative means, including common specifications adopted under Article 41 or independent technical evidence, and must document this approach in their conformity assessment file. - **Maintain awareness of updated or withdrawn standards:** When a harmonised standard is revised or its reference is withdrawn from the Official Journal, providers must assess whether their existing compliance documentation remains valid and update their systems and technical files accordingly. - **Engage with standardisation processes:** Providers, particularly those in sectors with rapidly evolving AI applications, should engage with relevant standardisation bodies and industry working groups to ensure that emerging standards reflect real-world technical practice and support meaningful compliance pathways. ## Relationship to Other Articles Article 40 operates as the procedural bridge between the substantive requirements of Title III, Chapter 3 (Articles 9–15 and 17) and the conformity assessment procedures in Chapter 5. It should be read alongside Article 41, which provides for Commission-adopted common specifications as an alternative when harmonised standards are absent or insufficient. Article 43 governs the conformity assessment procedures in which the presumption created by Article 40 is relied upon, and Article 44 covers the role of notified bodies in third-party assessments. The article also connects to Article 11 and Annex IV on technical documentation, since evidence of standard application must appear in the technical file, and to Article 17 on quality management systems, which must incorporate processes for identifying and applying relevant standards. Article 48, covering the EU declaration of conformity, is the downstream instrument through which the provider formally asserts the presumption of conformity established under Article 40. For GPAI model providers, standardisation is addressed separately under Title VIII; Article 40 applies specifically to high-risk AI systems under Title III. ## Compliance Timeline Article 40 entered into force on 1 August 2024, the date the EU AI Act was published in the Official Journal of the European Union and became binding law. However, its practical application is tied to the phased rollout of obligations: - **August 2024:** Act enters into force; standardisation mandates to CEN, CENELEC, and ETSI begin or accelerate. - **February 2025:** Prohibited AI practices under Article 5 become applicable; Article 40 is not directly implicated at this stage. - **August 2025:** GPAI model obligations under Title VIII become applicable; Article 40 remains specific to high-risk AI systems and does not govern GPAI standards. - **2 December 2027:** High-risk AI systems listed in Annex III (other than those covered by Annex I product legislation) must comply with Title III requirements. Providers should have identified and applied relevant harmonised standards by this date; where published standards are available, conformity assessments relying on them must be completed. - **August 2028:** High-risk AI systems embedded in products governed by Annex I sectoral legislation (medical devices, machinery, aviation, etc.) must comply. Full harmonised standard coverage is expected to be more developed by this date, though providers should not assume complete coverage and must plan for gaps. Providers are strongly advised to monitor the Commission's standardisation requests and the work programmes of CEN-CENELEC JTC 21 (the joint technical committee for AI standardisation) to anticipate which standards will be available and when, allowing compliance timelines to be planned accordingly. -------------------------------------------------------------------------------- ## Article 41 — Common specifications (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-41/ ## Official Text Summary Article 41 of Regulation (EU) 2024/1689 establishes a mechanism by which the European Commission may adopt implementing acts laying down common specifications for high-risk AI systems listed in Annex III, and for AI systems covered by the legislation referenced in Annex I. This mechanism is activated under specific conditions: where harmonised standards do not yet exist, where existing harmonised standards are considered insufficient to cover the requirements of Chapter 2 of Title III, or where the Commission determines that published harmonised standards fail to fulfil the obligations of the Regulation. Common specifications adopted under Article 41 carry the same legal weight as harmonised standards for the purpose of demonstrating conformity. High-risk AI systems that comply with applicable common specifications benefit from a presumption of conformity with the requirements addressed by those specifications. The Commission must consult relevant stakeholders — including national competent authorities, notified bodies, and standardisation bodies — before adopting common specifications, ensuring that the technical content reflects practical implementation realities. Providers retain the right to deviate from common specifications, provided they document in their technical documentation that the alternative technical solutions adopted meet at least an equivalent level of protection. This ensures that common specifications function as a safe harbour rather than a rigid ceiling, preserving technical innovation within a compliant framework. Article 41 is an enabling provision that addresses the practical reality that standardisation processes may lag behind the pace of regulatory application. ## What This Means in Practice Article 41 is primarily relevant to providers and developers of high-risk AI systems operating in areas where the European standardisation bodies — CEN, CENELEC, and ETSI — have not yet published harmonised standards, or where published standards are incomplete or contested by the Commission. In practical terms, this means that during the critical early phase of the EU AI Act's application to high-risk systems, common specifications may function as the primary technical reference for conformity. For providers of high-risk AI systems in sectors such as employment, education, critical infrastructure, or law enforcement, Article 41 means they should monitor the Official Journal of the EU for Commission implementing acts establishing common specifications in their domain. When such acts are published, providers must review whether their existing technical documentation, risk management systems, data governance practices, and accuracy benchmarks satisfy the specified requirements. For example, a provider of an AI-assisted recruitment tool covered by Annex III, point 4, would need to check whether the common specifications address bias testing, transparency obligations, and human oversight mechanisms. If the provider's existing solution meets those requirements through a different technical approach, they must document the equivalence explicitly. Importers and authorised representatives must verify that systems they place on the EU market reference applicable common specifications in their conformity documentation. Notified bodies conducting third-party conformity assessments must use applicable common specifications as the technical baseline where harmonised standards are absent. ## Key Obligations - **Monitor and apply implementing acts:** Providers of high-risk AI systems must identify and apply any Commission implementing acts establishing common specifications relevant to their system category, as published in the Official Journal of the EU. - **Update technical documentation:** Where common specifications exist, providers must reflect conformity with those specifications in their technical documentation as required under Article 11 and Annex IV. - **Presumption of conformity:** Providers who comply with applicable common specifications may rely on the presumption of conformity with the requirements of Chapter 2 of Title III covered by those specifications, simplifying the conformity assessment process. - **Document deviations with equivalent justification:** Providers who choose technical solutions that differ from common specifications must demonstrate and document, within their technical file, that their approach achieves at least an equivalent level of protection of the applicable requirements. - **Stakeholder participation:** Standardisation bodies, notified bodies, and national competent authorities must be consulted by the Commission before common specifications are adopted, creating obligations for those entities to engage constructively in the drafting process. - **Respect for procedural hierarchy:** Common specifications function subordinate to harmonised standards; providers must first assess whether applicable harmonised standards exist before falling back to common specifications as the conformity reference. ## Relationship to Other Articles Article 41 sits within Chapter 5 of Title III alongside Articles 40 (harmonised standards), 42 (presumption of conformity), 43 (conformity assessment procedures), 44 (certificates of conformity), and 47 (EU declaration of conformity). It must be read in close conjunction with Article 40, which governs the primary route to conformity via harmonised standards — Article 41 is expressly subsidiary to that route. The presumption of conformity created by compliance with common specifications feeds directly into Article 42, which specifies the conditions under which presumption arises. Article 43 determines which conformity assessment procedure applies, and common specifications will influence whether self-assessment or third-party assessment by a notified body is required. The technical documentation requirements of Article 11 and Annex IV govern how conformity with common specifications must be recorded. Article 9 (risk management system) and Article 17 (quality management system) must also be read alongside Article 41, as common specifications may set concrete parameters for how those systems are implemented for particular AI system categories. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024. Its application is phased: - **2 February 2025** — Prohibitions on unacceptable-risk AI practices (Article 5) became applicable. - **2 August 2025** — Provisions on general-purpose AI models (Title VIII) and governance obligations became applicable. The Commission's standardisation request to CEN-CENELEC was issued in 2023, but harmonised standards relevant to high-risk systems are not expected to be fully published before mid-to-late 2026. - **2 December 2027** — High-risk AI systems covered by Annex III (standalone) become subject to full conformity obligations under Chapter 2, including the requirement to comply with applicable harmonised standards or common specifications. - **2 August 2028** — High-risk AI systems embedded in products covered by Annex I (e.g., machinery, medical devices) become subject to full obligations. Article 41 is therefore of immediate practical relevance from mid-2025 onwards as providers prepare technical documentation for the 2026 deadline. Given that harmonised standards may not be available or complete in time, the Commission may adopt common specifications to fill the gap, making it essential for providers to track implementing acts actively during 2025 and 2026. -------------------------------------------------------------------------------- ## Article 42 — Presumption of conformity with certain requirements (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-42/ ## Official Text Summary Article 42 of Regulation (EU) 2024/1689 (the EU AI Act) establishes a mechanism known as the presumption of conformity. Under this mechanism, a high-risk AI system that has been developed and tested in accordance with harmonised standards — or parts thereof — whose references have been published in the Official Journal of the European Union is presumed to comply with the requirements set out in Chapter 2 of Title III of the Regulation, to the extent that those harmonised standards cover those requirements. The same presumption applies where a provider demonstrates conformity with common specifications adopted by the European Commission pursuant to Article 41 of the Regulation, again to the extent that those common specifications address the applicable requirements. The presumption is conditional and proportionate: it operates only with respect to the requirements that the harmonised standard or common specification actually covers. Where a standard or specification addresses only part of a requirement, the presumption of conformity applies solely to that part. Providers remain responsible for demonstrating conformity with any requirements not addressed by the standard or specification through other appropriate means. This article reflects the broader European approach to product regulation, mirroring similar presumption mechanisms found in existing Union harmonisation legislation (for example, the Machinery Directive and the Radio Equipment Directive), and integrates the AI Act into the established New Legislative Framework. ## What This Means in Practice For providers of high-risk AI systems, Article 42 creates a practical compliance pathway that reduces both the cost and the complexity of demonstrating conformity. Rather than constructing bespoke technical arguments for each applicable requirement from scratch, a provider can align its development and testing processes with published harmonised standards and rely on the resulting presumption to satisfy market surveillance authorities and notified bodies. In concrete terms, a company developing an AI-powered medical device classified as high-risk under Annex III would review the harmonised standards published by the European Commission following standardisation mandates issued to bodies such as CEN-CENELEC. Where those standards have been published in the Official Journal, the company documents its conformity with them — for example, covering data governance, transparency, or robustness requirements — and records this in its technical documentation as required by Article 11 and Annex IV. Where harmonised standards are not yet available — which remains a real-world constraint given the Act's novelty — providers may instead use the common specifications adopted by the Commission under Article 41 as an equivalent route to the presumption. Importantly, the presumption does not remove the obligation to conduct a conformity assessment under Article 43. It simplifies the evidentiary basis for that assessment. Internal compliance teams, legal counsel, and notified bodies should treat Article 42 as a structured shortcut within the broader conformity assessment architecture, not as an exemption from it. Providers should maintain up-to-date monitoring of newly published harmonised standards, as conformity pathways will evolve significantly during the phased rollout period. ## Key Obligations - **Monitor published harmonised standards:** Providers must actively track the Official Journal of the European Union for references to harmonised standards covering the requirements of Chapter 2, Title III, and update their technical documentation accordingly when new or revised standards are published. - **Align development and testing with applicable standards:** To invoke the presumption, the AI system must have been developed and tested in conformity with the relevant harmonised standard or common specification. Partial alignment triggers only a partial presumption. - **Document conformity with standards in technical documentation:** Evidence of conformity with the harmonised standard or common specification must be recorded in the technical documentation required under Article 11 and Annex IV, with sufficient detail to allow reconstruction and verification. - **Identify and address gaps not covered by standards:** Where a harmonised standard or common specification does not cover a requirement of Chapter 2 in full, providers must demonstrate conformity with the uncovered portion through alternative technical or procedural means, documented and defensible to market surveillance authorities. - **Remain prepared for rebuttal:** The presumption is not absolute. Providers must retain sufficient underlying evidence — test results, data governance records, human oversight logs — to substantiate conformity if the presumption is challenged by a notified body or national authority. - **Consider Article 41 common specifications as a fallback:** Where no harmonised standard has been published or mandated, providers should assess whether common specifications issued by the European Commission under Article 41 are available and apply them to secure equivalent legal standing under Article 42. ## Relationship to Other Articles Article 42 sits at the intersection of the Act's standardisation and conformity assessment architecture and cannot be read in isolation. It depends directly on **Article 41** (common specifications), which provides the fallback route to the presumption where harmonised standards are absent or incomplete. The presumption activated by Article 42 feeds directly into **Article 43** (conformity assessment procedures), which determines the procedural route — internal control or third-party involvement — that a provider must follow. The requirements against which conformity is presumed are set out in **Articles 9 through 15** (Chapter 2, Title III), covering risk management, data governance, technical documentation, transparency, human oversight, accuracy, robustness, and cybersecurity. **Article 11** and **Annex IV** govern the technical documentation in which standard conformity must be recorded. **Article 40** (harmonised standards) is the upstream counterpart: it describes how standardisation mandates are issued and how harmonised standards acquire their status under the Regulation. Article 42 is therefore the downstream legal effect of Article 40. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024 (twenty days after publication in the Official Journal on 12 July 2024). Application of its provisions is phased: - **2 February 2025** — Prohibitions on unacceptable-risk AI practices (Article 5) became applicable. - **2 August 2025** — Rules on general-purpose AI models (Title VIII) and governance obligations became applicable. - **2 December 2027** — Obligations for high-risk AI systems listed in **Annex III** that are not safety components of products already covered by Union harmonisation legislation become applicable. Article 42 is directly relevant from this date for the majority of high-risk system providers. - **2 August 2028** — High-risk AI systems that are safety components of products covered by existing Union harmonisation legislation (the "sectoral" category under Annex I) must comply. For Article 42 specifically, the practical timeline is also driven by the European Commission's standardisation mandates to CEN-CENELEC and ETSI. Harmonised standards under the AI Act are not yet fully published as of mid-2026; providers should follow the Official Journal and the Commission's standardisation work programme closely. Until harmonised standards are available for a given requirement, reliance on common specifications under Article 41 is the primary alternative route. -------------------------------------------------------------------------------- ## Article 43 — Conformity assessment (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-43/ ## Official Text Summary Article 43 of Regulation (EU) 2024/1689 establishes the conformity assessment procedures that providers of high-risk AI systems must follow before placing a system on the market or putting it into service in the European Union. For high-risk AI systems covered by the Union harmonisation legislation listed in Annex I — such as products subject to the Machinery Directive, the Medical Devices Regulation, or civil aviation safety rules — the conformity assessment procedure applicable under that sectoral legislation applies, supplemented by the requirements of Chapter 2 of Title III of the AI Act. Where the sectoral legislation does not require third-party involvement, the provider must follow the internal control procedure set out in Annex VI of the AI Act. For high-risk AI systems listed in Annex III, Article 43 provides two routes. By default, providers follow the internal control procedure of Annex VI. However, where the system involves real-time or post-remote biometric identification of natural persons (other than those excluded by Article 6(3)), or where no harmonised standard covering all relevant requirements exists and no common specification has been adopted, the assessment must be conducted by a notified body in accordance with Annex VII. Any high-risk AI system that undergoes a substantial modification after receiving an EU declaration of conformity or a certificate must be subject to a new conformity assessment. The article also confirms that notified bodies must be notified to the Commission and Member State authorities prior to conducting assessments, and that certificates issued remain valid unless withdrawn. ## What This Means in Practice For most providers of high-risk AI systems listed in Annex III — covering areas such as employment screening, education, credit scoring, critical infrastructure management, and administration of justice — Article 43 means that internal self-assessment is the default conformity route. The provider's quality management system, technical documentation, and conformity records must be in order before the declaration of conformity is signed and the CE marking is affixed. No external auditor is required unless the system falls within one of the categories that mandate notified body involvement. For providers whose systems fall under Annex I sectoral legislation — for example, an AI system embedded in a class IIb medical device, or in safety-critical aviation equipment — the AI Act conformity assessment is layered on top of whatever sectoral procedure already applies. Practically, this means engaging the notified body already designated under the Medical Devices Regulation or the relevant aviation authority, ensuring that body is also competent to assess AI-specific requirements. The most operationally significant trigger in Article 43 is the requirement to repeat conformity assessment after a substantial modification. Development teams and product managers must therefore embed a formal change-management gate into their AI development lifecycle: any update that alters the intended purpose, performance characteristics, or risk profile of the system must be evaluated against the definition of substantial modification before deployment. Importers and distributors are not themselves responsible for conducting the conformity assessment, but they must verify that the provider has completed the procedure and that documentation is available. Deployers operating in regulated sectors should request confirmation of the applicable assessment route as part of vendor due diligence. ## Key Obligations - **Select the correct assessment route:** Providers must determine whether their high-risk AI system falls under Annex I sectoral legislation or Annex III, and apply the corresponding procedure (internal control under Annex VI, or notified body assessment under Annex VII where mandated). - **Conduct assessment before market placement:** The conformity assessment must be completed, and the EU declaration of conformity signed, before the system is placed on the Union market or put into service — not retrospectively. - **Engage a notified body where required:** Systems involving real-time remote biometric identification for law enforcement, or where no applicable harmonised standard exists and no common specification covers all requirements, require third-party assessment by an accredited notified body. - **Integrate AI assessment with sectoral procedures:** For Annex I products, the AI-specific conformity assessment must be aligned with — and where possible integrated into — the existing sectoral conformity assessment, using the same notified body where competent. - **Reassess after substantial modification:** Any substantial modification to a high-risk AI system that has already passed conformity assessment triggers a mandatory new assessment before the modified system can be deployed or marketed. - **Maintain documentation for post-market review:** Providers must retain the technical documentation, quality management records, and declaration of conformity for ten years after the system is placed on the market, and make them available to national competent authorities on request. ## Relationship to Other Articles Article 43 cannot be read in isolation. It is the procedural expression of the substantive requirements set out in Articles 8 through 15 (Chapter 2 of Title III), which define the technical and governance standards that high-risk AI systems must satisfy — including risk management, data governance, transparency, human oversight, accuracy, and cybersecurity robustness. The definition of what constitutes a high-risk AI system — and therefore triggers Article 43 — is established by Article 6 read together with Annexes I and III. The internal control procedure referenced in Article 43 is detailed in Annex VI, while the notified body procedure is set out in Annex VII. Article 44 governs the certificates issued by notified bodies following an Annex VII assessment, including conditions for suspension and withdrawal. Article 45 addresses notified body obligations during assessment. Article 47 covers the EU declaration of conformity that providers must draw up upon completing the procedure. Article 48 links conformity assessment completion to the right to affix the CE marking under Article 49. For providers whose systems also qualify as general-purpose AI models with systemic risk, the interaction with Title VIII obligations must be considered alongside Article 43. ## Compliance Timeline Regulation (EU) 2024/1689 entered into force on 1 August 2024, twenty days after its publication in the Official Journal of the European Union on 12 July 2024. Article 43 does not apply immediately across all high-risk AI systems. The phased application schedule established by Article 113 means that: - **2 February 2025** — Prohibitions on unacceptable-risk AI practices (Title II) became applicable. Article 43 was not yet in effect. - **2 August 2025** — General-purpose AI model obligations (Title VIII) became applicable. Conformity assessment obligations under Article 43 were still not yet in force for most high-risk systems. - **2 December 2027** — Article 43 becomes fully applicable to providers of high-risk AI systems listed in **Annex III** (standalone high-risk AI systems in areas such as biometrics, employment, education, and critical infrastructure). - **2 August 2028** — The deadline by which obligations, including conformity assessment, apply to high-risk AI systems embedded in **Annex I** products that are already governed by Union harmonisation legislation and were placed on the market before August 2026. Providers should treat the August 2026 deadline as the operative compliance date for internal planning purposes, ensuring that quality management systems, technical documentation, and assessment procedures are operational well in advance. -------------------------------------------------------------------------------- ## Article 44 — Certificates (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-44/ ## Official Text Summary Article 44 of Regulation (EU) 2024/1689 establishes the rules governing certificates issued by notified bodies in connection with the conformity assessment of high-risk AI systems. Under this article, certificates issued by notified bodies must be drafted in one of the official languages of the EU Member State in which the notified body is established, or in a language acceptable to that body. The article sets a maximum validity period of four years for any certificate issued, with the possibility of renewal following a new conformity assessment. Notified bodies are required to keep registers of all certificates they issue, including those that have been refused, suspended, or withdrawn. These registers must be made available to national competent authorities upon request. Article 44 further mandates that when a notified body suspends, restricts, or withdraws a certificate, it must notify the relevant market surveillance authority of the Member State in which the provider is established, as well as the other notified bodies operating under the same conformity assessment procedures. The European Commission must also be informed where certificates concern systems with cross-border implications. Importantly, the article establishes a principle of mutual recognition: certificates issued by notified bodies in one Member State are valid throughout the European Union without requiring re-certification, underpinning the functioning of the EU single market for high-risk AI systems. ## What This Means in Practice Article 44 is central to the practical administration of third-party conformity assessment for high-risk AI systems covered under Annex III of the EU AI Act. It directly affects providers of high-risk AI systems who are required to undergo conformity assessment by a notified body rather than self-assessment. **For providers**, the four-year validity ceiling means that ongoing market access depends on periodic re-certification. Providers must track certificate expiry dates and initiate renewal procedures in advance to avoid gaps in conformity status that would prevent lawful market placement. A suspended or withdrawn certificate requires immediate action: the system cannot be placed on the market or put into service until the situation is resolved. **For notified bodies**, the article imposes strict record-keeping and notification obligations. Any adverse decision — refusal, restriction, suspension, or withdrawal — must be communicated systematically to national authorities and peer notified bodies, ensuring coordinated enforcement across the EU. **Concrete example**: A provider of a biometric identification AI system certified in Germany by a German notified body can lawfully market that system in France, Spain, and all other EU Member States without obtaining separate national certificates. However, if the notified body finds during surveillance that the system no longer meets the requirements of Articles 9–15 and suspends the certificate, the provider must immediately halt distribution across the entire EU and notify downstream deployers. The mutual recognition principle is a practical trade facilitation measure, but it places significant commercial stakes on maintaining a single certificate in good standing. ## Key Obligations - **Certificates must have a defined validity period** not exceeding four years; renewal requires a fresh conformity assessment demonstrating continued compliance with the applicable requirements. - **Notified bodies must maintain complete registers** of all certificates issued, refused, suspended, restricted, or withdrawn, and make those registers accessible to national competent authorities on request. - **Adverse certificate decisions must be notified** immediately to the relevant national market surveillance authority, other notified bodies operating under the same procedures, and, where applicable, the European Commission. - **Providers must cease market activities** if a certificate is suspended or withdrawn, until conformity is re-established and a valid certificate is obtained. - **Mutual recognition applies across the EU**: a certificate issued by any properly designated notified body in one Member State is valid in all Member States, without re-certification requirements. - **Certificates must be drawn up** in a language of the issuing notified body's Member State or another mutually agreed official EU language, ensuring accessibility to national authorities. ## Relationship to Other Articles Article 44 sits within Title III, Chapter 5 (Standards, Conformity Assessment, Certificates, and Registration) and must be read in close conjunction with the surrounding provisions. **Article 43** defines the applicable conformity assessment procedures — including the conditions under which third-party notified body involvement is mandatory versus optional — establishing the upstream process that Article 44 governs in terms of certificate management. **Articles 31–39** define the requirements that notified bodies themselves must satisfy to be designated, and the obligations they carry as accredited conformity assessment bodies. The integrity of the Article 44 certificate regime depends entirely on the competence of those bodies. **Articles 9–15** set out the substantive requirements for high-risk AI systems — risk management, data governance, transparency, human oversight, accuracy, and robustness — against which certificates are assessed. A certificate under Article 44 is essentially a notified body's attestation that these provisions are met. **Article 45** addresses appeal procedures available to providers where a notified body refuses, suspends, or withdraws a certificate, providing the procedural complement to Article 44's substantive rules. **Article 51** governs the registration obligations that follow certification, linking certificates to the EU database of high-risk AI systems. ## Compliance Timeline Article 44 became part of EU law upon the entry into force of Regulation (EU) 2024/1689 on **2 August 2024**. However, its practical application is governed by the phased implementation schedule: - **2 February 2025** — Provisions on prohibited AI practices (Title II) began to apply. Article 44 was not yet operative. - **2 August 2025** — Rules on general-purpose AI models (Title VIII) and governance obligations began to apply. - **2 December 2027** — Article 44 becomes fully operative for the majority of high-risk AI systems listed in Annex III, including those in areas such as education, employment, essential services, law enforcement, and border management. Providers placing such systems on the market or into service must hold a valid certificate where third-party conformity assessment is required. - **2 August 2028** — Extended deadline for high-risk AI systems covered by existing EU product safety legislation (Annex I systems), giving those sectors additional time to align existing notified body relationships and conformity frameworks with the new AI Act certificate regime. Providers who anticipate requiring a certificate under Article 44 should engage with notified bodies well before the December 2026 deadline, given the expected demand on assessment capacity and the time required to conduct a thorough conformity assessment under Articles 9–15. -------------------------------------------------------------------------------- ## Article 45 — Information obligations on notified bodies (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-45/ ## Official Text Summary Article 45 of Regulation (EU) 2024/1689 establishes specific information obligations incumbent upon notified bodies throughout the lifecycle of their conformity assessment activities concerning high-risk AI systems listed in Annex III and, where applicable, Annex II. Under Article 45, notified bodies are required to inform the notifying authority — the national body responsible for designating and overseeing them — of all conformity assessments carried out, including those refused or withdrawn before completion. This transparency obligation extends to circumstances that may affect the scope, conditions, or ongoing validity of the notification, such as changes in the body's structure, ownership, competence, or resources. Notified bodies must additionally communicate to their notifying authority any requests for information received from market surveillance authorities, enabling coordinated oversight across national boundaries. They are also required to report complaints, appeals, and other relevant information concerning high-risk AI systems they have assessed, upon request or on their own initiative where the matter is of significance for regulatory action. Article 45 further provides that notified bodies shall exchange information with one another and with the Commission on matters related to negative results of conformity assessments, thereby establishing a collective knowledge-sharing mechanism. This prevents providers from shopping for more lenient assessors after receiving a refused assessment from one notified body — a practice sometimes referred to as certificate shopping. The article forms a cornerstone of the accountability infrastructure for the notified body system, ensuring that national authorities and the Commission maintain genuine oversight over how conformity assessments are being conducted across the Union. ## What This Means in Practice For notified bodies, Article 45 introduces a continuous, proactive disclosure culture that goes well beyond simply issuing or refusing certificates. In operational terms, a notified body must establish internal procedures to log and report all significant events to its national notifying authority, even when those events do not result in a formal certificate. Consider a scenario where a provider of a high-risk AI system used in employment screening submits documentation for a conformity assessment, but the notified body identifies critical gaps in the technical documentation and risk management system. Even if the provider withdraws the application before a formal refusal is issued, Article 45 requires the notified body to report this withdrawal. The notifying authority and, through information exchange mechanisms, other notified bodies are thereby alerted that a non-conforming system may be re-presented elsewhere for assessment. Similarly, if a market surveillance authority — such as a national consumer protection regulator — contacts a notified body seeking information about a previously assessed system that has caused harm, the notified body must inform its notifying authority of that request. This creates a paper trail that enables coordinated regulatory response. Notified bodies must also review their internal resource and competence arrangements continuously. Should they determine that their staffing or technical capacity no longer covers certain categories of AI systems, they must notify this change promptly so that the scope of their designation can be adjusted — protecting market integrity by preventing assessments in areas where the body lacks genuine expertise. For providers, this framework means that a refused or withdrawn assessment is not a confidential event. Due diligence before engaging a notified body is therefore advisable. ## Key Obligations - **Report refused and withdrawn assessments:** Notified bodies must inform the notifying authority of any conformity assessment that was refused or withdrawn by the provider before completion, including the reasons where ascertainable. - **Disclose scope-affecting circumstances:** Any change in the body's legal status, ownership, senior personnel, organisational structure, or technical competence that could affect its notification must be communicated to the notifying authority without undue delay. - **Share information with other notified bodies:** Notified bodies are required to exchange information on negative assessment outcomes and related matters with peer notified bodies and with the Commission, preventing certificate shopping across the Union. - **Report regulatory contacts:** Receipt of requests for information from market surveillance authorities, national competent authorities, or other regulatory bodies must be disclosed to the notifying authority, enabling coordinated oversight. - **Communicate complaints and appeals:** Significant complaints, appeals against assessment decisions, and post-market intelligence regarding assessed AI systems must be reported on request or proactively where warranted. - **Maintain readiness for audits:** Notified bodies must make available to the notifying authority all relevant documentation, records, and evidence of their assessment activities to support ongoing monitoring of their designation. ## Relationship to Other Articles Article 45 operates within a dense network of provisions governing the notified body framework under Title III, Chapter 5. It is inseparable from **Article 33**, which establishes the general obligations and requirements that notified bodies must satisfy to obtain and maintain their designation, and from **Article 34**, which sets out the subsidiaries and subcontracting rules that affect organisational transparency. The notification and designation process governed by **Articles 35 and 36** provides the institutional context for Article 45: the notifying authority that receives information under Article 45 is the same body that may suspend or withdraw a notification under Article 35 if the disclosed information reveals non-compliance. **Article 44** (certificates of conformity) and **Article 46** (derogation from conformity assessment procedures) should be read alongside Article 45, as they establish the outputs of the conformity assessment process whose integrity Article 45's information obligations are designed to protect. At the market surveillance level, **Articles 74 to 76** rely implicitly on the information flows created by Article 45 to function effectively, as do the coordination mechanisms involving the **European Artificial Intelligence Board (EAIB)** established under Article 65. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024**, twenty days after its publication in the Official Journal of the European Union (OJ L 2024/1689, 12 July 2024). Article 45 falls within the provisions applicable to high-risk AI systems under Title III. The phased application schedule is as follows: - **1 August 2024** — Entry into force; preparatory obligations begin for Member States and Commission. - **2 February 2025** — Prohibited AI practices (Title II, Article 5) became applicable. - **2 August 2025** — GPAI model obligations (Title VIII) and governance provisions became applicable; notified body designation processes were expected to be operationally advanced by this date. - **2 December 2027** — Article 45, along with the full set of Title III Chapter 5 obligations relating to notified bodies and conformity assessments for high-risk AI systems listed in Annex III, becomes fully applicable. Notified bodies must be fully compliant with their information obligations from this date. - **2 August 2028** — Extended deadline for certain high-risk AI systems covered by existing Union harmonisation legislation listed in Annex I, Section A, giving manufacturers in those regulated sectors additional time to adapt conformity assessment processes. Organisations seeking designation as notified bodies should have their information management and disclosure procedures in place well in advance of the August 2026 deadline to ensure they can demonstrate compliance from day one of full application. -------------------------------------------------------------------------------- ## Article 46 — Derogation from conformity assessment procedure (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-46/ ## Official Text Summary Article 46 of Regulation (EU) 2024/1689 establishes a limited derogation mechanism allowing national competent authorities to authorise the placing on the market or putting into service of high-risk AI systems that have not undergone the standard conformity assessment procedure prescribed by Article 43. This derogation may be invoked when exceptional circumstances exist and where it is in the interest of public security, the protection of life and health of persons, the protection of industrial and commercial property, or other overriding reasons of public interest. When a Member State grants such an authorisation, it must notify the Commission and the other Member States without delay. The authorisation specifies the AI system concerned, the purpose and duration of the authorisation, and the conditions attached to it. The Commission may, where justified, take measures to ensure that the authorisation does not adversely affect the functioning of the internal market or the level of protection required by this Regulation. The article draws a clear distinction between the temporary and circumstance-bound nature of the derogation and the permanent compliance obligations that apply under standard conditions. Providers benefiting from a derogation are still expected to work toward full conformity and must not treat the authorisation as a permanent exemption. The mechanism mirrors analogous provisions found in EU product safety and medical device legislation, ensuring coherence with the broader EU regulatory architecture for conformity assessment. ## What This Means in Practice In practical terms, Article 46 is an emergency valve rather than a routine compliance pathway. The vast majority of providers of high-risk AI systems will never interact with this provision directly. It is relevant primarily in two scenarios: first, where a government authority or a provider working under a government mandate needs to deploy a high-risk AI system rapidly to address an urgent public safety or national security situation; second, where a Member State wishes to facilitate market access for a system of strategic importance while a full conformity assessment is pending. Concretely, a national authority might invoke Article 46 to authorise the emergency deployment of an AI-assisted triage system during a public health crisis, or an AI tool used by law enforcement in response to an acute threat, where waiting for the full Article 43 conformity assessment procedure would create unacceptable delays. For providers, the practical implication is that even under a derogation, obligations do not disappear — they are deferred. Providers must maintain documentation, continue developing technical files, and prepare to submit to full conformity assessment once the derogation period expires. They should treat the period under derogation as a transitional phase, not a compliance-free zone. Member State authorities must ensure that any authorisation is narrowly scoped, time-limited, and communicated to the Commission. Legal teams advising clients in defence, security, or critical infrastructure sectors should be aware of this mechanism as a contingency option, while making clear that reliance on it carries procedural and reputational risks. ## Key Obligations - **Member State notification**: Any national authority granting a derogation must immediately notify the European Commission and all other Member States, providing full details of the authorisation including scope, duration, and conditions. - **Justification requirement**: The authorising authority must demonstrate that exceptional circumstances exist and that the derogation is proportionate to the objective pursued; vague or generic justifications are insufficient. - **Time limitation**: Derogations must be strictly time-limited; the authorisation must specify an end date or a defined trigger condition after which full conformity assessment obligations resume. - **Conditions attachment**: The authorisation must set out specific conditions the provider must comply with during the derogation period, which may include enhanced monitoring, incident reporting, or use restrictions. - **Commission oversight**: The Commission retains the power to assess whether a granted derogation is compatible with the integrity of the internal market and may require the Member State to withdraw or amend the authorisation. - **Continued provider obligations**: Providers operating under a derogation remain responsible for maintaining technical documentation and must complete the standard conformity assessment procedure before the derogation expires. ## Relationship to Other Articles Article 46 must be read in close conjunction with Article 43 (Conformity Assessment), which establishes the standard procedure from which the derogation departs. It also connects to Article 44 (Certificates of Conformity) and Article 45 (Information Obligations of Notified Bodies), since a derogation suspends rather than replaces these mechanisms. Article 46 is further linked to Article 74 and Article 75 on market surveillance and control of AI systems entering the Union market, as authorities granting derogations must operate within the broader oversight framework. The notification obligations under Article 46 feed into the EU database established under Article 71, ensuring that derogated systems are traceable at EU level. Providers should also cross-reference Article 9 (Risk Management System) and Article 17 (Quality Management System), since the expectations embedded in those provisions continue to apply even during a derogation period, informing what "conditions" a national authority should impose. ## Compliance Timeline Article 46 became part of EU law upon the entry into force of Regulation (EU) 2024/1689 on 1 August 2024. However, its practical activation is tied to the phased application of obligations for high-risk AI systems. The conformity assessment obligations under Article 43, from which Article 46 provides a derogation, apply to high-risk AI systems listed in Annex III from 2 December 2027, and to certain high-risk systems in Annex I sectors from 2 August 2028. This means Article 46 becomes operationally relevant as a derogation mechanism from those dates onward, since prior to that, the conformity assessment obligations it derogate from are not yet mandatory. Organisations in sectors likely to face emergency deployment scenarios — critical infrastructure, law enforcement, border management, health — should include Article 46 in their regulatory preparedness planning ahead of the August 2026 application date, ensuring they understand both how to request a derogation and what obligations persist during any authorised derogation period. -------------------------------------------------------------------------------- ## Article 47 — EU declaration of conformity (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-47/ ## Official Text Summary Article 47 of Regulation (EU) 2024/1689 establishes the obligation for providers of high-risk AI systems to draw up an EU declaration of conformity before placing their system on the market or putting it into service. The declaration must attest, on the exclusive responsibility of the provider, that the high-risk AI system in question complies with all requirements set out in Chapter 2 of Title III of the Regulation. The Article specifies the minimum content of the declaration: the identity and contact details of the provider; a description of the AI system including its name, version, and intended purpose; a statement of conformity with the applicable requirements; references to any relevant harmonised standards applied or common specifications used; where applicable, the identification of the notified body that carried out the conformity assessment, along with the number and date of the EU type-examination certificate or any other relevant certificate issued; the place and date of issue; and the signature and name of the responsible person authorised to bind the provider. Providers are required to keep the declaration up to date, ensuring it reflects any modifications made to the system that could affect conformity. The declaration must be made available to national competent authorities upon request, and providers must retain it for ten years following market placement or entry into service. Where a high-risk AI system is also subject to other Union harmonisation legislation requiring a declaration of conformity, a single EU declaration of conformity may cover all applicable Union acts, provided all required information is included. ## What This Means in Practice Article 47 places a concrete documentation obligation on every provider bringing a high-risk AI system to the EU market. In practical terms, this means that before a product can lawfully be placed on the market or put into service — and before the CE marking required by Article 48 can be affixed — the provider must have a signed, complete, and accurate EU declaration of conformity on file. For providers of AI systems that are safety components of regulated products (such as medical devices, machinery, or vehicles under Annex I legislation), Article 47 integrates with existing product compliance workflows. A single consolidated declaration can be used to cover the AI Act and the sectoral legislation simultaneously, reducing administrative duplication — but only if all required information for each applicable act is present in that single document. For providers of standalone high-risk AI systems listed in Annex III — such as AI used in recruitment, credit scoring, education, or biometric categorisation — the declaration is a standalone document drawn up internally by the provider after completing the appropriate conformity assessment procedure under Article 43. Concretely, a provider building an AI-assisted CV screening tool classified as high-risk under Annex III, Point 2, must: complete the conformity assessment, compile the technical documentation required by Article 11 and Annex IV, and then draw up and sign the EU declaration of conformity before commercial deployment. Any subsequent update to the model that meaningfully affects its intended purpose or performance must trigger a review and update of the declaration. The declaration is the provider's legally binding attestation and forms part of the audit trail inspected by market surveillance authorities. ## Key Obligations - **Draw up the declaration before market placement:** Providers must prepare the EU declaration of conformity as a prerequisite to placing the high-risk AI system on the market or putting it into service — it cannot be completed retroactively. - **Include all mandatory content elements:** The declaration must contain the provider's identity, a full description of the system, a statement of conformity, references to applied harmonised standards or common specifications, and notified body details where third-party assessment was conducted. - **Sign by an authorised representative:** The declaration must be signed by a named individual with authority to legally bind the provider, establishing clear personal and organisational accountability. - **Keep the declaration updated:** If a high-risk AI system is modified in ways that affect its conformity with the applicable requirements, the provider must update the declaration accordingly before the modified system is deployed or made available. - **Retain for ten years:** The declaration must be preserved and made available to national competent authorities on request for ten years from the date the system was placed on the market or put into service. - **Consolidation with other Union acts:** Where multiple Union harmonisation acts apply to the same product, a single combined declaration of conformity is permitted, provided all legally required information for each applicable act is comprehensively included. ## Relationship to Other Articles Article 47 sits at the centre of the conformity infrastructure established by Chapter 5 of Title III. It is directly preceded by Article 43, which defines the conformity assessment procedures that must be completed before the declaration can be validly drawn up. The content of the technical documentation that underpins the declaration is governed by Article 11 and detailed in Annex IV. Article 48 is immediately dependent on Article 47: providers may only affix the CE marking once the EU declaration of conformity has been drawn up. Article 16 lists the declaration as one of the core obligations of providers of high-risk AI systems, anchoring it within the general obligations framework. The declaration should also be read alongside Article 46, which governs the conformity assessment bodies (notified bodies) whose assessments may be referenced within the declaration, and Article 72, which establishes market surveillance authority powers to request and verify the declaration. For AI systems embedded in regulated products, the relevant sectoral Union harmonisation legislation cross-referenced in Annex I must be consulted to determine whether a consolidated declaration is appropriate. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024 (twenty days after publication in the Official Journal on 12 July 2024). The Regulation applies in a phased manner: - **February 2, 2025:** Prohibitions on unacceptable-risk AI practices (Title II, Article 5) became applicable. - **August 2, 2025:** Rules applying to general-purpose AI models (Title VIII) became applicable; governance provisions and obligations for notified bodies and market surveillance authorities also apply from this date. - **2 December 2027:** Obligations for high-risk AI systems listed in Annex III (excluding those already covered by Union harmonisation legislation) become fully applicable. Article 47 obligations — including the requirement to draw up and maintain the EU declaration of conformity — apply in full from this date for those systems. - **2 August 2028:** Obligations for high-risk AI systems that are safety components of products regulated under the sectoral Union harmonisation legislation listed in Annex I become applicable. Providers of such embedded AI systems must have their EU declaration of conformity in place by this date. Providers subject to the December 2026 or August 2027 deadlines should begin conformity assessment procedures well in advance — typically 12 to 18 months before the applicable deadline — to ensure technical documentation, conformity assessments, and the EU declaration of conformity are complete and accurate at the moment of market placement. -------------------------------------------------------------------------------- ## Article 48 — CE marking (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-48/ ## Official Text Summary Article 48 of Regulation (EU) 2024/1689 (EU AI Act) establishes the rules governing CE marking for high-risk AI systems. The CE marking constitutes the visible declaration by the provider that a high-risk AI system conforms to the requirements of the Regulation and, where applicable, to other Union harmonisation legislation that also requires CE marking. Paragraph 1 provides that the CE marking must be affixed visibly, legibly, and indelibly to the high-risk AI system — or, where that is not possible due to the nature of the system, to its packaging or to the accompanying documentation — before the system is placed on the market or put into service. Paragraph 2 prohibits affixing any marking, sign, or inscription that is likely to mislead third parties regarding the meaning or form of the CE marking. Any other markings may be affixed only if they do not impair the visibility, legibility, or meaning of the CE mark. Paragraph 3 specifies that where a high-risk AI system is also subject to other Union legislation requiring CE marking, the single CE mark signals compliance with all applicable requirements, provided all conditions of each relevant act are met. Paragraph 4 requires that, where a notified body has participated in the conformity assessment procedure, the notified body's identification number must be displayed alongside the CE marking. The identification number must be affixed by the notified body itself or, under its instruction, by the provider. The format and general rules for the CE mark are governed by Annex V of the Regulation, read in conjunction with Regulation (EC) No 765/2008. ## What This Means in Practice For providers of high-risk AI systems, CE marking is the final, outward-facing step in the conformity journey — but it is a legally significant one, not a formality. **Providers** must ensure that CE marking is affixed only after the applicable conformity assessment procedure (under Articles 43 and 44) has been completed, the EU declaration of conformity (Article 47) has been drawn up, and all relevant technical documentation (Article 11) is in order. Affixing the mark prematurely exposes the provider to enforcement action and potential withdrawal from the market. **Where to affix the mark** requires careful judgment. For embedded or software-only AI systems that have no physical housing, the mark must appear on packaging or accompanying documentation. Providers should document the rationale for placement decisions. **Notified body involvement** adds a layer of procedural obligation: if a notified body was engaged (as required for certain high-risk categories under Article 43), the notified body's four-digit identification number must appear next to the CE mark. Coordinating this with the notified body early — rather than at the point of market launch — avoids delays. **Importers and distributors** must verify that CE marking has been correctly affixed and that the accompanying EU declaration of conformity is available before making the system available on the market (see Articles 23 and 24). They should not place a system on the market if CE marking is missing or appears irregular. **Practical example:** A provider of an AI-based medical diagnostic tool subject to both the EU AI Act and Regulation (EU) 2017/745 (MDR) must satisfy conformity requirements under both instruments before affixing a single CE mark. Failure to meet either set of requirements invalidates the mark. ## Key Obligations - **Affix CE marking before market placement:** Providers must apply the CE mark to the high-risk AI system, its packaging, or accompanying documentation before placing it on the market or putting it into service in the EU. - **Complete conformity assessment first:** CE marking may only be affixed after the applicable conformity assessment procedure under Article 43 has been successfully completed; affixing it beforehand is prohibited. - **Include notified body identification number:** Where a notified body was involved in the conformity assessment, the provider must display that body's identification number alongside the CE mark. - **Avoid misleading markings:** No marking, sign, or inscription that could mislead third parties about the meaning or form of the CE mark may be affixed to the system or its documentation. - **Satisfy all applicable Union legislation:** Where other Union harmonisation legislation also requires CE marking, the provider must comply with all applicable acts before relying on a single CE mark as evidence of conformity. - **Ensure visibility and legibility:** The CE mark must be affixed in a visible, legible, and indelible manner in accordance with the format rules in Annex V of the Regulation. ## Relationship to Other Articles Article 48 sits at the culmination of the Chapter 5 conformity chain and cannot be read in isolation. It is directly dependent on **Article 43** (conformity assessment procedures), which specifies the process a provider must complete before CE marking becomes lawful, and on **Article 47** (EU declaration of conformity), the formal document that underpins the mark. **Article 11** (technical documentation) and **Article 17** (quality management system) establish the substantive conditions that must be satisfied before the declaration — and therefore the mark — can be legitimately issued. **Articles 23 and 24** extend the obligations downstream: importers and distributors must verify CE marking before making a system available, creating a chain of accountability across the supply chain. **Article 49** (registration) operates in parallel: providers of certain high-risk systems must register in the EU database before or alongside market placement, meaning CE marking alone is insufficient for full compliance. Finally, **Annex V** of the Regulation and **Regulation (EC) No 765/2008** govern the graphical and procedural rules for the CE mark itself. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024** (twenty days after publication in the Official Journal on 12 July 2024). Application of the Regulation is phased: - **2 February 2025** — Prohibitions on unacceptable-risk AI practices (Article 5) became applicable. - **2 August 2025** — Rules on general-purpose AI models (Title VIII) and governance provisions became applicable. - **2 December 2027** — High-risk AI systems covered by Annex III become fully subject to all obligations, including conformity assessment and CE marking requirements under Article 48, for newly placed systems. - **2 August 2028** — Extended deadline for high-risk AI systems governed by existing product safety legislation listed in Annex I (e.g., machinery, medical devices, toys) where those systems were already placed on the market before August 2026 under the earlier sectoral legislation. Providers of high-risk AI systems should treat the period leading up to **December 2027** as active preparation time: completing conformity assessments, engaging notified bodies where required, finalising technical documentation, and establishing internal processes for correct CE mark application — so that no system is placed on the EU market without a lawfully affixed CE mark from the applicable date. -------------------------------------------------------------------------------- ## Article 49 — Registration (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-49/ ## Official Text Summary Article 49 of Regulation (EU) 2024/1689 establishes a mandatory registration regime for high-risk AI systems before they may be placed on the Union market or put into service. The article imposes a primary obligation on **providers**: prior to market placement, they must register themselves and their high-risk AI systems in the EU database established under Article 71. Providers that are established outside the Union must ensure that their authorised representative completes this registration on their behalf. For the specific category of high-risk AI systems covered by Annex III, point 8 — systems used for biometric categorisation and emotion recognition deployed by law enforcement, border management, immigration, and asylum authorities — the obligation extends to **deployers** as well. These deployers must register their use of such systems before deployment. The information to be submitted during registration is defined in Annex VIII, Parts I and II, and must be kept accurate and up to date. Where updates occur — for instance, following a substantial modification — the registered entry must be revised accordingly. Systems used exclusively by Union institutions, bodies, offices, or agencies are registered in a dedicated, restricted section of the database, ensuring that sensitive operational information is appropriately protected while maintaining accountability. The article thereby creates a structured, lifecycle-aware transparency mechanism that enables market surveillance authorities and the public to identify and monitor high-risk AI deployments across the Single Market. ## What This Means in Practice Article 49 requires any business that develops or brings to market a high-risk AI system within the scope of Annex III to complete a registration step that is functionally comparable to a product filing with a regulator. In practice, this means that **before launch**, a provider's legal or compliance team must: 1. Create or update an account on the EU AI Act database portal (operated by the European Commission under Article 71). 2. Submit structured information per Annex VIII — covering company identity, system description, intended purpose, risk management summary, conformity declaration reference, and any notified body certificate number. 3. Obtain a registration number that must subsequently appear in the EU declaration of conformity and accompany the system's documentation. **For non-EU providers**, the authorised representative established in the Union is the point of contact responsible for submitting the registration. This mirrors the model used in other EU product-safety frameworks. **For deployers** operating high-risk biometric or emotion-recognition systems in law enforcement or border management contexts (Annex III, point 8), a separate deployer-side registration is mandatory before the system is activated in an operational environment. A practical example: a company providing an AI-powered creditworthiness scoring tool (Annex III, point 5b) must register the system in the EU database, obtain its registration number, include that number in the declaration of conformity, and update the entry if the model undergoes a substantial modification — such as a significant change to training data or output logic — that is validated through the conformity assessment process. Registration is not a one-off administrative step; it is a living record that tracks the system through its commercial life. ## Key Obligations - **Pre-market registration**: Providers must register themselves and their high-risk AI systems in the EU database under Article 71 before the system is placed on the market or put into service in the Union. - **Authorised representative as registrant**: Where the provider is established outside the EU, the authorised representative established in a Member State must complete and submit the registration. - **Deployer registration for point 8 systems**: Deployers of Annex III, point 8 high-risk AI systems (biometric categorisation, emotion recognition) in law enforcement and border contexts must register their intended use before deployment. - **Annex VIII information requirements**: Registrations must contain all information specified in Annex VIII, Parts I and II, including system identity, capabilities, limitations, conformity documentation, and certificate references. - **Ongoing accuracy obligation**: Registered information must be kept current; any substantial modification that triggers a new conformity assessment requires a corresponding update to the registration entry. - **Restricted entries for sensitive public-authority use**: Systems used exclusively by law enforcement, border management, immigration, and asylum authorities under Annex III points 1–7 are registered in a non-public section of the database, balancing transparency with operational security. ## Relationship to Other Articles Article 49 sits at the intersection of several core obligations and cannot be read in isolation. **Article 71** establishes and governs the EU database in which registrations are recorded; it defines the Commission's responsibilities as administrator and the public accessibility rules that Article 49 cross-references. **Annex VIII** specifies the exact information fields that must be submitted, making it operationally inseparable from the registration process. **Article 47** (EU declaration of conformity) and **Article 48** (CE marking) precede registration logically: the declaration of conformity reference number must be available at the time of registration, and the registration number feeds back into the declaration. Together, Articles 47, 48, and 49 form the final compliance gate before market access. **Article 43** (conformity assessment) feeds into registration because the notified body certificate obtained there is a mandatory data field in Annex VIII where third-party assessment is required. **Article 111** (transitional provisions) governs how registration timelines interact with systems already on the market before the obligations come into force, and should be consulted alongside Article 49 for any legacy system analysis. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024**, twenty days after publication in the Official Journal. However, Article 49 registration obligations do not apply immediately upon entry into force; they follow the Act's phased application schedule: - **2 February 2025** — Prohibited AI practices (Article 5) became enforceable. No direct impact on Article 49, but relevant for scoping exercises. - **2 August 2025** — GPAI model obligations (Title VIII) and governance framework became applicable. Registration under Article 49 is not triggered at this stage for GPAI models that are not separately classified as high-risk. - **2 December 2027** — Registration obligations under Article 49 apply to high-risk AI systems covered by **Annex III, points 1 to 7**. This is the primary compliance deadline for most enterprise AI providers. - **2 August 2028** — Registration obligations extend to high-risk AI systems governed by **Annex I** (harmonised product-safety legislation), such as medical devices and machinery. Providers and deployers should plan registration workflows — including Annex VIII data collection, EU database portal access, and authorised representative arrangements — well ahead of the August 2026 deadline to avoid last-minute bottlenecks. Systems placed on the market before these dates under prior frameworks benefit from transitional arrangements under Article 111, but providers are strongly advised to assess whether those arrangements apply to their specific product category. -------------------------------------------------------------------------------- ## Article 5 — Prohibited AI practices (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-5/ ## Official Text Summary Article 5 of Regulation (EU) 2024/1689 (the EU AI Act) constitutes the entirety of Title II and establishes an absolute list of AI practices that are prohibited across the European Union. The prohibitions target AI systems whose potential for harm is deemed so severe that no risk-management measure or conformity assessment can render them acceptable. The article bans: (1) AI systems that deploy subliminal techniques beyond a person's consciousness or deliberately exploit psychological weaknesses or vulnerabilities to materially distort behaviour in a way that causes or is likely to cause significant harm; (2) AI systems that exploit age, disability, or socioeconomic circumstances to distort behaviour harmfully; (3) AI systems used by public authorities or on their behalf for social scoring — evaluating or classifying natural persons based on social behaviour or inferred personal characteristics — when this leads to detrimental or unfavourable treatment; (4) AI systems assessing the risk of an individual committing a criminal offence solely on the basis of profiling or personality traits; (5) real-time remote biometric identification of natural persons in publicly accessible spaces for law enforcement purposes, subject to limited and strictly controlled exceptions; (6) real-time or post remote biometric systems used to infer sensitive attributes such as race, political opinion, trade-union membership, religious beliefs, or sexual orientation; (7) AI systems that create or expand facial recognition databases through untargeted scraping of the internet or CCTV footage; and (8) AI systems that infer emotions of natural persons in workplace and educational settings, except for safety reasons. ## What This Means in Practice Article 5 draws a hard compliance line that affects every organisation developing, deploying, or importing AI systems into the EU market, regardless of size or sector. For technology providers and AI developers, the prohibitions mean that certain product categories simply cannot be lawfully placed on the EU market. A vendor marketing a workforce productivity tool that includes emotion recognition to monitor employee engagement — flagging stressed or disengaged workers to managers — must remove or redesign that feature before 2 February 2025. Similarly, a retail analytics startup whose system infers customer mood from facial expressions in-store falls within the prohibition on emotion inference in non-safety contexts. For organisations using third-party AI tools, due diligence is equally mandatory. A human-resources department that deploys a recruitment platform performing covert psychographic profiling to screen candidates risks joint liability as a deployer. For public authorities, the social-scoring prohibition is particularly significant. Any AI system that aggregates behavioural data — payment history, mobility patterns, online activity — to produce a citizen score that then restricts access to public services or benefits is unlawful, regardless of whether the system is technically sophisticated. For law enforcement bodies, the narrow exception to the real-time biometric identification ban demands robust prior-authorisation procedures, geographic and temporal limits, mandatory logging, and post-hoc reporting to national supervisory authorities. Ad hoc or continuous deployment without prior judicial or administrative sign-off is unlawful even within the exception's scope. Organisations should conduct an inventory of all AI systems in use or under development, map each against the Article 5 criteria, and cease prohibited operations without delay. ## Key Obligations - **Cease or never deploy** any AI system that uses subliminal, manipulative, or vulnerability-exploiting techniques to distort human behaviour in ways likely to cause significant harm, with no exception or proportionality balancing available. - **Prohibit social scoring** by public authorities or entities acting on their behalf: do not use AI to evaluate or classify natural persons for social behaviour or inferred personality traits when the outcome leads to detrimental or discriminatory treatment. - **Decommission predictive policing tools** that assess individual criminal risk based solely on profiling, personality traits, or past association without concrete behavioural evidence. - **Refrain from scraping** biometric data from the internet, CCTV, or other sources to create or expand facial recognition databases; existing databases built through such means must not be used. - **Do not deploy** AI systems that infer sensitive personal attributes — racial or ethnic origin, political opinions, trade-union membership, religious or philosophical beliefs, sexual orientation — from biometric or behavioural data. - **Apply strict prior-authorisation and logging controls** if operating as law enforcement and relying on the narrow Article 5(2)–(5) exception for real-time remote biometric identification; each deployment must be time-limited, geographically scoped, and subject to ex-post reporting. ## Relationship to Other Articles Article 5 must be read as the apex of the EU AI Act's risk-based hierarchy. It operates in conjunction with the definitions in **Article 3**, which establishes what constitutes an "AI system", a "provider", and a "deployer" — the actors subject to the prohibitions. The distinction between prohibited practices under Article 5 and high-risk AI systems under **Article 6** and **Annex III** is fundamental: prohibited systems cannot be lawfully used at all, whereas high-risk systems may be deployed subject to conformity assessments, registration, and ongoing monitoring obligations. **Article 9** (risk-management systems) and **Articles 10–15** (data governance, transparency, human oversight) apply downstream to permitted high-risk systems but have no remedial role for Article 5 prohibitions. **Article 99** establishes the penalty structure, including the top-tier fine applicable to Article 5 breaches. **Article 85** and the provisions on market surveillance (**Articles 74–78**) govern enforcement. National competent authorities designated under **Article 70** are responsible for monitoring compliance with the prohibitions at Member State level. ## Compliance Timeline - **1 August 2024** — Regulation (EU) 2024/1689 entered into force, twenty days after publication in the Official Journal of the European Union. - **2 February 2025** — Article 5 prohibitions became **directly applicable** across all EU Member States. This was the first substantive application date under the phased schedule set out in Article 113. From this date, any deployment, placing on the market, or putting into service of a prohibited AI system constitutes a regulatory violation subject to penalties under Article 99. - **2 August 2025** — Rules on general-purpose AI models (Title VIII, Articles 51–56) became applicable. - **2 December 2027** — Obligations for most high-risk AI systems listed in Annex III apply, along with governance and market-surveillance provisions. - **2 August 2028** — Extended deadline for high-risk AI systems already on the market before August 2024 that fall under Annex I (safety component in regulated products). For Article 5 specifically, there is no grace period or transitional arrangement: the deadline was 2 February 2025, and compliance is now overdue for any organisation that has not yet acted. -------------------------------------------------------------------------------- ## Article 50 — Transparency obligations for providers and deployers of certain AI systems (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-50/ ## Official Text Summary Article 50 of Regulation (EU) 2024/1689 (the EU AI Act) establishes transparency obligations for providers and deployers of specific categories of AI system. It is the cornerstone provision of Title IV and addresses the risk that individuals may be deceived about whether they are interacting with a human or an AI system, or whether content they consume has been artificially generated. Under Article 50(1), providers of AI systems designed to interact directly with natural persons must ensure those systems are designed in a way that allows users to be informed, clearly and without ambiguity, that they are interacting with an AI system. This obligation rests on the provider at design stage. Article 50(2) places a marking duty on providers of AI systems — including general-purpose AI systems — that generate synthetic audio, image, video or text content: the outputs must be marked in a machine-readable format and detectable as artificially generated or manipulated. The technical solution must be effective, reliable, robust and interoperable as far as this is technically feasible. Article 50(3) extends obligations to deployers: any deployer using an emotion recognition system or a biometric categorisation system must inform the natural persons exposed to it of its operation. Article 50(4) requires deployers using AI systems to generate or manipulate image, audio, or video content that constitutes a deepfake to disclose that the content has been artificially generated or manipulated. A narrow exemption applies where such use is evidently legitimate or creatively necessary. Article 50(4) addresses AI-generated text published for purposes of informing the public on matters of public interest — deployers must disclose that text has been produced by an AI system, unless editorial human review has taken place and the output has been substantially modified. ## What This Means in Practice Article 50 directly affects any organisation that builds or deploys AI systems that interact with people or generate content presented to people. **For technology providers**, the key obligation arises at the design and development stage. A company building a customer-service chatbot must engineer a disclosure mechanism — a clear, upfront notification informing the user they are interacting with an AI system — before the product is placed on the market or put into service. This cannot be an afterthought or a footnote in terms of service. **For deployers** — companies integrating third-party AI tools into their operations — the obligation is operational. A bank deploying an AI-driven virtual assistant must ensure that customers are told they are speaking to an AI at the outset of each interaction. A media organisation using AI to draft articles must label that content as AI-generated unless a qualified human editor has materially reviewed and reworked it. **For synthetic content and deepfakes**, the obligation is particularly stringent. Marketing teams using AI-generated images of people, or media producers creating AI-voiced audio, must attach a disclosure — ideally machine-readable — to that content. Platforms distributing such content are encouraged, and in some interpretations obliged, to surface these labels to end users. **Practically**, organisations should conduct an inventory of their AI systems to identify which fall within Article 50's scope, define a disclosure template aligned with the Article's requirements, and implement technical controls — watermarking, metadata embedding, or UI-level banners — to ensure compliance is systematic rather than manual. Internal training for teams deploying AI tools is advisable so that disclosure obligations are treated as a workflow requirement rather than a legal abstraction. ## Key Obligations - **Provider design obligation**: Providers must engineer AI systems intended to interact with natural persons so that those systems can disclose their AI nature clearly and without ambiguity before or at the start of interaction. - **Deployer disclosure — conversational AI**: Deployers using AI systems to interact directly with end users must inform those users in a timely, comprehensible manner that they are interacting with an AI system, unless this is evident from context. - **Deployer disclosure — emotion recognition and biometric categorisation**: Deployers operating emotion recognition or biometric categorisation systems must notify the individuals subject to those systems of their use and operation. - **Deepfake labelling**: Deployers using AI to generate or manipulate deepfake content (image, audio, video resembling real persons, places, or events) must clearly disclose the synthetic or manipulated nature of that content. - **AI-generated text for public information**: Deployers publishing AI-generated text aimed at informing the public on matters of public interest must label it as AI-generated, except where human editorial review has led to substantial modification. - **Machine-readable watermarking for GPAI**: Providers of general-purpose AI models generating synthetic content must implement technical solutions — such as watermarking or metadata tagging — to ensure outputs are identifiable as AI-generated and machine-detectable by downstream systems. ## Relationship to Other Articles Article 50 operates within the broader transparency architecture of the EU AI Act and must be read alongside several other provisions. **Article 13** (Transparency and provision of information for high-risk AI systems) establishes parallel transparency requirements for high-risk systems, focusing on documentation and explainability directed at deployers rather than end users. Where a high-risk system also interacts with natural persons, both Articles 13 and 50 apply concurrently. **Article 26** (Obligations of deployers of high-risk AI systems) complements Article 50 by setting out the broader operational responsibilities of deployers, including monitoring and human oversight, within which the Article 50 disclosure obligation sits. **Articles 53 and 54** (Obligations for providers of GPAI models) are directly linked to Article 50(2), which places watermarking and machine-readability requirements on GPAI providers — requirements that must be reflected in the technical documentation and model compliance measures under Articles 53–54. **Recitals 132–134** provide interpretive guidance on the intent behind Title IV, clarifying the scope of the deepfake and emotion recognition provisions and the meaning of "obvious from context" in the exemption provisions. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024** (20 days after publication in the Official Journal on 12 July 2024). The Regulation applies in a phased manner: - **2 February 2025** — Prohibited AI practices under Article 5 became applicable. - **2 August 2025** — Obligations relating to general-purpose AI models (Title VIII, Articles 51–56) and governance structures became applicable. - **2 August 2026** — **Title IV, including Article 50, became fully applicable.** Providers and deployers of conversational AI, synthetic content systems, emotion recognition systems, and biometric categorisation systems were required to have compliant disclosure mechanisms in place by this date. - **2 August 2028** — High-risk AI systems listed in Annex I (product safety legislation) must comply with the full high-risk obligations. - **2 December 2027** — High-risk AI systems listed in Annex III that are already in service (existing systems placed on the market before August 2024) must comply. Organisations that had not yet implemented Article 50-compliant disclosure mechanisms by **2 August 2026** are already in breach of the Regulation and should treat remediation as an immediate priority. -------------------------------------------------------------------------------- ## Article 51 — Classification of general-purpose AI models as models with systemic risk (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-51/ ## Official Text Summary Article 51 of Regulation (EU) 2024/1689 (the EU AI Act) establishes the classification mechanism for general-purpose AI (GPAI) models as models with systemic risk. It sits within Title V, which creates a dedicated regulatory layer for GPAI models that is distinct from the high-risk AI system framework of Title III. Under Article 51(1), a GPAI model is classified as posing systemic risk where it meets either of two conditions. First, it has high-impact capabilities evaluated on the basis of appropriate technical tools and methodologies, including indicators and benchmarks — with a rebuttable presumption that any model trained using a cumulative compute of more than 10^25 FLOPs falls into this category. Second, it is designated by the Commission pursuant to Article 51(2) on the basis of other criteria, irrespective of whether the compute threshold is met. Article 51(2) grants the Commission the power to update the compute threshold by means of delegated acts as technological development evolves, ensuring the framework remains calibrated to market reality. Providers who consider that, despite meeting the threshold, their model does not pose systemic risk may notify the Commission and provide substantiating evidence. The Commission then makes a final determination. The classification under Article 51 triggers the additional set of obligations contained in Article 55, which represents the most demanding tier of obligations in the GPAI framework. ## What This Means in Practice Article 51 directly affects providers of frontier GPAI models — most immediately, large AI laboratories and technology companies that develop and release foundation models or large language models trained at scale. Any provider whose model reaches or exceeds the 10^25 FLOPs training-compute threshold must treat that model as presumptively carrying systemic risk and begin preparing for compliance with the Article 55 obligation regime, unless it successfully rebuts the presumption with the Commission. In concrete terms, a provider should audit its training infrastructure and documentation to determine whether the compute threshold has been crossed. This requires maintaining accurate records of training runs, including cumulative FLOPs. Where a new model is in development and expected to approach the threshold, providers should begin compliance planning before release rather than after, since the obligations attach at the point of placing the model on the market or putting it into service. For providers whose models are designated by the Commission on qualitative grounds — for example, due to very wide deployment across the EU market, autonomous decision-making capabilities, or multimodal reach — the trigger is not self-executing in the same way, but the designation produces identical legal consequences. Providers should therefore monitor the AI Office's public register of systemic-risk models and guidance from the Commission on the criteria it applies under Article 51(2). Downstream deployers and businesses relying on GPAI models via API access should also be aware: if the underlying model they use is classified under Article 51, they may face additional contractual disclosure requirements from the provider and should factor systemic-risk status into their own due diligence processes. ## Key Obligations - **Compute threshold monitoring**: Providers must track and document the cumulative training compute of their GPAI models to determine whether the 10^25 FLOPs threshold is reached, which triggers the rebuttable presumption of systemic risk under Article 51(1)(a). - **Proactive notification**: Providers who believe their model does not pose systemic risk despite meeting the threshold must proactively notify the Commission with substantiating evidence rather than waiting for enforcement action. - **Commission designation compliance**: Where the Commission designates a model as posing systemic risk under Article 51(2) — whether on compute grounds or other criteria — the provider must comply with that designation and the obligations it triggers. - **Threshold update monitoring**: Providers must track changes to the compute threshold made by the Commission through delegated acts under Article 51(2), since models not currently captured may fall within scope as the threshold is adjusted. - **Record-keeping readiness**: Providers must maintain technical documentation sufficient to demonstrate whether the classification thresholds are or are not met, supporting both self-assessment and any Commission review. - **Downstream communication**: Providers of classified systemic-risk GPAI models must ensure that downstream providers and deployers accessing the model through APIs or other interfaces are informed of the model's classification status, as required by the transparency obligations under Article 53. ## Relationship to Other Articles Article 51 functions as the gateway provision for the most demanding tier of the GPAI framework. It must be read together with Article 52, which sets out the procedure for classification and the Commission's designation powers in more detail, and Article 55, which lists the substantive obligations — adversarial testing, incident reporting to the AI Office, cybersecurity measures, and energy efficiency reporting — that apply once classification occurs. Article 53 establishes the baseline obligations applicable to all GPAI model providers regardless of systemic-risk classification, including technical documentation, compliance with copyright law, and publication of summaries of training data. Article 51 builds on this floor by identifying which providers face the elevated Article 55 regime. Article 4 grants the Commission power to issue delegated acts to adjust technical details, including the compute threshold in Article 51. Recitals 110 to 114 of the Regulation provide interpretive guidance on why the systemic-risk classification is warranted for high-compute models and how the Commission intends to apply the qualitative designation criteria. The AI Office established under Article 64 plays a central role in monitoring compliance with the Article 51 classification framework. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024, twenty days after its publication in the Official Journal of the European Union. The Act applies in phases: - **February 2025**: Prohibitions on unacceptable-risk AI practices (Article 5) became applicable. - **August 2025**: The GPAI framework under Title V, including Article 51, became applicable. Providers of systemic-risk GPAI models were required to be compliant with the classification procedures and the Article 55 obligations from this date. This is the most directly relevant deadline for Article 51. - **August 2028**: Obligations for high-risk AI systems listed in Annex I (safety-component systems regulated under existing Union law) apply. - **December 2027**: Full application of obligations for high-risk AI systems listed in Annex III. For Article 51 specifically, providers of large-scale GPAI models needed to assess their training compute and determine whether the systemic-risk threshold was met from August 2025 onward. The AI Office began issuing guidance and codes of practice in the lead-up to this date to support providers in making that determination. -------------------------------------------------------------------------------- ## Article 52 — Systemic-risk classification procedure (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-52/ Article 52 — officially titled simply “Procedure” — governs how a general-purpose AI model formally becomes, or contests becoming, a model with systemic risk. It is the administrative hinge between the Article 51 classification criteria and the heavy obligations of Article 55. ## Official Text Summary Where a general-purpose AI model meets the condition of Article 51 — notably the presumption triggered when cumulative training compute exceeds 10²⁵ FLOPs — the provider must notify the Commission without delay and in any event within two weeks. The notification may include arguments that, despite meeting the threshold, the model does not present systemic risks; the Commission may reject those arguments and designate the model anyway, and may equally designate a model on its own initiative where the Article 51 criteria are met. Designated models are published on a Commission-maintained list, and a provider may request reassessment on the basis of a reasoned request showing the risks have materially changed. ## Key Obligations - Notify the Commission without delay, and at the latest within two weeks, once the Article 51 condition is met — including the 10²⁵ FLOPs training-compute presumption - The notification may include arguments that the model, despite meeting the threshold, does not present systemic risk; the Commission may reject them and designate the model, or designate ex officio - The Commission publishes and maintains the list of designated models with systemic risk - On reasoned request of the provider, the Commission may reassess a designation ## Compliance Timeline Applicable since 2 August 2025, together with the rest of the general-purpose AI framework; the 2026 Digital Omnibus did not alter this date. -------------------------------------------------------------------------------- ## Article 53 — Obligations for all providers of general-purpose AI models (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-53/ ## Official Text Summary Article 53 of Regulation (EU) 2024/1689 establishes baseline obligations applicable to **all providers of general-purpose AI models** (GPAI models), irrespective of whether those models are classified as posing systemic risk. The article operates as the foundational compliance layer for the entire GPAI regulatory framework set out in Title V of the Regulation. Under Article 53, every GPAI model provider must: draw up and maintain adequate technical documentation before placing the model on the market or putting it into service; make available to downstream providers integrating the model into their own AI systems sufficient information and documentation to enable those providers to understand the capabilities and limitations of the model and to fulfil their own obligations under the Regulation; register the model in the EU database referred to in Article 71; and put in place a policy to comply with Union law on copyright and related rights, in particular to identify and comply with rights reservations expressed by rightsholders pursuant to Article 4(3) of Directive (EU) 2019/790. The technical documentation required by Article 53 must meet the minimum content requirements specified in Annex XI and must be kept up to date throughout the lifecycle of the model. Providers must also make publicly available a sufficiently detailed summary of the content used for training the GPAI model, in accordance with a template provided by the AI Office. ## What This Means in Practice Article 53 creates an unavoidable baseline compliance floor for any organisation that develops and commercialises or releases a general-purpose AI model in the EU. The obligations apply from the moment the model is placed on the market or put into service — there is no grace period once the GPAI application date of August 2025 has passed. **For developers of proprietary GPAI models** — whether large commercial frontier labs or enterprise AI teams building in-house foundation models — the primary workload lies in constructing and maintaining Annex XI-compliant technical documentation. This documentation must cover model architecture, training data sources and volumes, training methodologies and compute used, evaluation procedures, performance benchmarks, known limitations, and foreseeable misuse risks. The documentation is not a one-time deliverable; it must be updated whenever the model is materially modified. **For providers distributing models via API or licensing to downstream integrators**, Article 53 requires proactively furnishing those downstream parties with sufficient technical information. In practice, this means structured model cards, capability disclosures, and usage guidelines that allow downstream AI system providers to perform their own conformity assessments and risk classifications. **On copyright compliance**, providers must implement and document a concrete policy identifying how they detect and honour rightsholders' machine-readable reservations (Article 4(3) of the DSM Directive). This is not a best-efforts commitment — it requires a verifiable process. Training data provenance records and opt-out signal processing workflows must be in place before training commences or before placing an already-trained model on the EU market. **The public training data summary** must be published in a standardised format aligned with the AI Office template. It does not need to disclose confidential commercial details but must be sufficiently granular for public scrutiny of training data sources and categories. ## Key Obligations - **Technical documentation (Annex XI):** Draw up, maintain, and keep current technical documentation covering model architecture, training data, training methodology, compute and energy consumption, capabilities, limitations, evaluation results, and known risks, prior to market placement. - **Information provision to downstream providers:** Proactively supply integrating providers with all information necessary for them to understand the model's capabilities and limitations and to fulfil their own obligations under the Regulation, including conformity assessment requirements. - **EU database registration:** Register the GPAI model in the EU database established under Article 71 before placing it on the market, providing the information specified in Annex XII. - **Copyright compliance policy:** Establish, document, and implement a policy ensuring compliance with Union copyright law, specifically including identification of and compliance with opt-out reservations under Article 4(3) of Directive (EU) 2019/790 (the DSM Directive). - **Public training data summary:** Publish a sufficiently detailed summary of training content, in a format consistent with the template issued by the AI Office, to enable public oversight of data sourcing practices. - **Ongoing update obligation:** Keep technical documentation and downstream disclosures up to date to reflect any material modifications to the model throughout its active lifecycle. ## Relationship to Other Articles Article 53 is the baseline tier of a two-tier framework for GPAI models. It must be read alongside **Article 55**, which imposes additional, more stringent obligations specifically on providers of GPAI models with systemic risk (defined by a training compute threshold, currently 10²⁵ FLOPs, or by AI Office designation). Providers should determine whether Article 55 applies to them before concluding that Article 53 obligations alone are sufficient. **Article 51** establishes the classification criteria and notification procedure for systemic-risk models, forming the gateway to Article 55 and providing context for Article 53's scope. **Article 55** sets out the obligations of GPAI model providers that are also deployers of their own models in integrated AI systems, creating potential overlap with high-risk AI system requirements under Title III. **Annex XI** (technical documentation content) and **Annex XII** (EU database information) are directly operative annexes for Article 53 compliance. **Article 71** governs the EU database itself. **Article 4(3) of Directive (EU) 2019/790** (the DSM Directive) is the external legal reference for the copyright opt-out obligation. Codes of practice developed under **Article 56** will provide operational guidance on how to satisfy Article 53 obligations in practice. ## Compliance Timeline The EU AI Act (Regulation (EU) 2024/1689) entered into force on **1 August 2024**, twenty days after publication in the Official Journal. Application of the Regulation is phased: - **2 February 2025** — Prohibitions on unacceptable-risk AI practices (Article 5) became applicable. - **2 August 2025** — Title V (GPAI models, Articles 51–56), including Article 53, became **fully applicable**. All GPAI model providers placing models on the EU market from this date must comply with Article 53 in full. Providers whose models were already on the market before this date had until 2 August 2025 to achieve compliance. - **2 August 2026** — Codes of practice under Article 56 are expected to be finalised, providing authoritative guidance on how to demonstrate compliance with Article 53 obligations in practice. - **2 December 2027 / 2 August 2028** — High-risk AI system obligations under Title III become fully applicable (depending on Annex I vs. Annex III classification), relevant for GPAI providers that also deploy integrated high-risk AI systems. Providers should treat **2 August 2025** as the hard compliance deadline for Article 53. The AI Office's codes of practice and any delegated acts specifying Annex XI content requirements should be monitored continuously as they refine the precise documentation standards expected. -------------------------------------------------------------------------------- ## Article 54 — Authorised representatives of providers of general-purpose AI models established outside the Union (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-54/ ## Official Text Summary Article 54 of Regulation (EU) 2024/1689 (the EU AI Act) establishes the obligation for providers of general-purpose AI (GPAI) models that are established in third countries — that is, outside the European Union — to designate an authorised representative before making their models available in the Union. The article requires that such providers appoint, by written mandate, a natural or legal person established or with a registered office in the Union to act as their authorised representative. The mandate must empower the representative to perform specified tasks on the provider's behalf, including: verifying that the provider has fulfilled obligations relating to technical documentation under Article 53; cooperating with and making available to the AI Office and competent national authorities all information and documentation necessary to demonstrate compliance; and receiving communications and enforcement notices issued by Union supervisory bodies. The authorised representative must be capable of performing the tasks defined in the mandate and must be provided with all necessary means by the provider to fulfil those tasks effectively. The provider must inform the AI Office of the name, address, electronic mail address, and telephone number of its authorised representative. The representative's details must also be included in the technical documentation required under Article 53 and Annex XII. Article 54 draws a clear boundary: the designation of an authorised representative does not relieve the provider established outside the Union of its own legal responsibilities under the Regulation. ## What This Means in Practice Article 54 is the mechanism through which the EU AI Act extends its reach beyond Union borders to capture non-EU providers of general-purpose AI models. Any organisation headquartered outside the EU — including those based in the United States, United Kingdom, China, Canada, or any other third country — that makes a GPAI model available within the EU (whether through an API, a product, a platform, or any other distribution channel, and regardless of whether access is paid or free) must establish a formal legal presence through an authorised representative. In practice, this means non-EU GPAI providers must take the following steps before placing their model on the Union market or, at the latest, by the date on which GPAI obligations become applicable. They must identify a suitable natural person or legal entity — such as a law firm, a compliance consultancy, or a dedicated subsidiary — established within the EU and willing to accept the mandate. The mandate must be formalised in writing, specifying the scope of the representative's authority and the obligations they undertake. The authorised representative is not merely a postal address. They must actively liaise with the AI Office and national competent authorities, facilitate document requests, and respond to compliance enquiries. Providers must equip their representative with up-to-date technical documentation and prompt access to all compliance materials. For example, a US-based foundation model provider offering API access to EU businesses would need to appoint an EU-based entity — whether a local subsidiary, a third-party representative service, or a law firm — and register that representative with the AI Office before the GPAI provisions apply. ## Key Obligations - **Mandatory appointment**: Providers of GPAI models established outside the EU must designate an authorised representative by written mandate before making their model available in the Union market. - **EU establishment requirement**: The authorised representative must be a natural or legal person established in the EU or with a registered office within the Union. - **Scope of mandate**: The written mandate must empower the representative to carry out specified compliance tasks, including verifying technical documentation, cooperating with the AI Office, and receiving official communications. - **Notification to the AI Office**: The provider must notify the AI Office of the authorised representative's contact details (name, address, email, telephone number), and those details must be included in the technical documentation under Article 53 and Annex XII. - **Adequate resourcing**: The provider must supply the authorised representative with all means necessary — including access to documentation, records, and personnel — to fulfil their responsibilities effectively. - **Provider liability is not transferred**: Appointing an authorised representative does not discharge the non-EU provider from its own direct obligations under the EU AI Act; both parties may face enforcement measures. ## Relationship to Other Articles Article 54 must be read as part of the broader framework governing general-purpose AI models set out in Title V (Articles 51 to 56). It operates in close conjunction with Article 53, which establishes the core obligations of GPAI model providers — including drawing up technical documentation, providing information to downstream providers, and maintaining a copyright policy — since the authorised representative's core function is to verify and facilitate compliance with those obligations. It also connects to Article 51 and Article 55, which identify GPAI models with systemic risk and impose additional requirements on their providers; the authorised representative must be equipped to support compliance with those enhanced obligations as well. Article 56 governs the AI Office's supervisory powers over GPAI models, making Article 54 foundational to the Office's enforcement capacity vis-à-vis non-EU providers. More broadly, Article 54 mirrors the approach taken in Article 22 for high-risk AI system providers, ensuring consistency across the Regulation's extraterritorial reach. Recital 109 of the Regulation provides interpretive context for the rationale behind this requirement. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024, twenty days after publication in the Official Journal of the European Union. The Regulation applies in phases: - **February 2025**: Prohibitions on unacceptable-risk AI practices (Article 5) became applicable. - **August 2025**: Obligations for general-purpose AI models under Title V — including Articles 51 to 56 and therefore Article 54 — became applicable. Non-EU providers of GPAI models that were already making their models available in the Union were required to have designated and registered their authorised representative by this date. - **August 2026**: Governance and general obligations for certain AI systems (Title III, Chapter 1) become applicable. - **December 2027 / August 2028**: Full application of high-risk AI system obligations under Annex III and Annex I respectively. For non-EU GPAI providers, Article 54 is therefore already operative as of August 2025. Providers that have not yet appointed an authorised representative are in breach of the Regulation and exposed to enforcement action by the AI Office and national competent authorities, including the significant administrative fines provided for under Article 101. -------------------------------------------------------------------------------- ## Article 55 — Obligations for providers of general-purpose AI models with systemic risk (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-55/ ## Official Text Summary Article 55 of Regulation (EU) 2024/1689 establishes obligations that apply exclusively to providers of general-purpose AI (GPAI) models classified as presenting systemic risk pursuant to Article 51. These are models trained with compute exceeding 10^25 floating-point operations (FLOPs), or models designated by the AI Office on the basis of a capability or impact assessment. In addition to the baseline obligations applicable to all GPAI model providers under Article 53, providers covered by Article 55 must: perform model evaluations, including adversarial testing conducted in accordance with standardised protocols or approved methodologies; assess and mitigate systemic risks at Union level; report serious incidents and malfunctions to the AI Office without undue delay; ensure an adequate level of cybersecurity protection for the model, its infrastructure, and physical environment; and document the results of model evaluations and make those results available to the AI Office upon request. Article 55(2) provides that providers may rely on codes of practice adopted under Article 56 to demonstrate compliance. The European Commission is empowered to issue delegated acts specifying the content and procedures for evaluations, and to adapt thresholds as scientific understanding evolves. The AI Office monitors compliance and may require further information or corrective action. ## What This Means in Practice Article 55 creates a distinct compliance tier for the most capable and potentially impactful GPAI models on the EU market. Any organisation — regardless of where it is established — that provides such a model to deployers or end users in the EU must assess whether it crosses the systemic-risk threshold. **For providers above the 10^25 FLOP compute threshold**, the obligations are automatic. For providers below that threshold, the AI Office can still trigger Article 55 obligations following a case-by-case evaluation based on indicators such as the number of users, the breadth of capabilities, or integration into critical sectors. In practice, compliance requires standing up robust internal processes: a model evaluation programme capable of conducting red-teaming and adversarial probing before and after deployment; a systemic risk register and associated mitigation plan; a cybersecurity framework covering the model weights, APIs, and training infrastructure; and an incident response procedure linked to the reporting obligation toward the AI Office. Concretely, a provider of a frontier large language model made available via API to EU-based deployers must carry out adversarial testing — such as jailbreak attempts and capability elicitation for dangerous content — document results, retain them, and be able to share them with the AI Office. If the model produces output that causes or nearly causes serious harm to a person or critical infrastructure, that incident must be reported promptly. Participation in an AI Office-approved code of practice under Article 56 provides a structured pathway to demonstrate compliance without waiting for harmonised standards. ## Key Obligations - **Model evaluations and adversarial testing**: Conduct thorough evaluations, including red-teaming and adversarial testing, using standardised protocols or those approved by the AI Office, before and following significant model updates. - **Systemic risk assessment and mitigation**: Identify, analyse, and mitigate potential systemic risks at Union level that may arise from the development, placing on the market, or use of the model. - **Serious incident reporting**: Report to the AI Office without undue delay any serious incident or malfunctioning linked to the GPAI model with systemic risk, including information on the incident and corrective measures taken. - **Cybersecurity protection**: Implement and maintain appropriate cybersecurity measures protecting the model, its physical infrastructure, and supply chain — including model weights, APIs, and training pipelines — commensurate with identified risks. - **Documentation and transparency to the AI Office**: Keep records of evaluation results, testing methodologies, and risk mitigation measures; make these available to the AI Office upon request. - **Codes of practice compliance pathway**: Demonstrate conformity with Article 55 obligations by adhering to codes of practice developed under Article 56, pending the availability of harmonised standards. ## Relationship to Other Articles Article 55 cannot be read in isolation. It builds directly on **Article 51**, which defines the criteria and procedures for classifying a GPAI model as presenting systemic risk — including the 10^25 FLOP compute threshold and the AI Office's discretionary designation power. The baseline obligations of **Article 53** remain fully applicable alongside Article 55; the latter adds a further layer rather than replacing the former. **Article 55** governs qualified presumptions of conformity, while **Article 56** establishes the codes of practice mechanism that Article 55(2) explicitly references as a compliance pathway. The AI Office's supervisory role over Article 55 obligations is grounded in **Articles 101 to 90**, which set out enforcement powers and procedures. For providers who are also deployers of high-risk AI systems, the requirements of **Chapter III** (Articles 9–16) on risk management and technical documentation may overlap with systemic risk mitigation work required by Article 55, and coordination between compliance teams is advisable to avoid duplication. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024** (twenty days after publication in the Official Journal on 12 July 2024). Article 55, as part of Title V governing general-purpose AI models, became applicable on **2 August 2025** — twelve months after entry into force, in accordance with Article 113(3). This means providers of GPAI models with systemic risk were required to have their evaluation programmes, incident reporting procedures, and cybersecurity frameworks operational by that date. The phased application schedule for reference: prohibited AI practices under Article 5 applied from **2 February 2025** (six months); GPAI model obligations including Article 55 from **2 August 2025** (twelve months); obligations for stand-alone high-risk AI systems under Annex III from **2 December 2027**; and obligations for high-risk AI systems embedded in Annex I products from **2 August 2028**. Providers should also monitor delegated acts from the European Commission that may refine Article 55 evaluation requirements or adjust the compute threshold as scientific understanding of frontier model capabilities evolves. -------------------------------------------------------------------------------- ## Article 56 — Codes of practice (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-56/ Article 56 tasks the AI Office with facilitating codes of practice — the instrument that turns the general-purpose AI obligations of Articles 53 and 55 into concrete engineering and governance practice. Until harmonised standards exist, adherence to a code is the practical way to demonstrate compliance. ## Official Text Summary The AI Office encourages and facilitates the drawing-up of codes of practice at Union level, with providers, national competent authorities, civil society, industry and academia taking part. Codes must cover at least the obligations of Articles 53 and 55 — technical documentation, information to downstream providers, copyright policy, and the assessment and mitigation of systemic risks — with clear objectives, commitments and key performance indicators. They were to be ready at the latest by 2 May 2025. The Commission may, by implementing act, approve a code and give it general validity within the Union; where a code cannot be finalised in time or is deemed inadequate, the Commission may provide common rules for implementing the relevant obligations. ## Key Obligations - The AI Office encourages and facilitates codes covering at least the Article 53 and 55 duties: documentation, downstream information, copyright policy, and systemic-risk assessment and mitigation - Codes were to be ready at the latest by 2 May 2025; providers, national authorities and stakeholders participate in drawing them up - The Commission may approve a code and give it general validity across the Union by implementing act - If a code cannot be finalised or is deemed inadequate, the Commission may lay down common rules by implementing act ## Compliance Timeline Applicable since 2 August 2025, together with the rest of the general-purpose AI framework; the 2026 Digital Omnibus did not alter this date. -------------------------------------------------------------------------------- ## Article 57 — AI regulatory sandboxes (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-57/ ## Official Text Summary Article 57 of Regulation (EU) 2024/1689 requires Member States to establish at least one AI regulatory sandbox at national level, operational no later than 2 August 2026. These sandboxes must be established by the relevant national competent authority or, where appropriate, jointly with the competent authorities of other Member States, under the coordination of the European AI Office. The sandbox framework allows providers and prospective providers of AI systems to develop, train, validate, and test innovative AI systems in a real-world or simulated environment under the direct supervision of competent authorities, before placing those systems on the market or putting them into service. Participation does not constitute an exemption from the obligations set out in the Regulation or from applicable Union or Member State law. Competent authorities may, however, apply existing legal requirements in a flexible or adapted manner within the sandbox where doing so does not undermine the objectives of those provisions or risk harm to health, safety, or fundamental rights. Participating organisations must submit a sandbox plan and operate pursuant to specific terms and conditions set by the authority. The sandbox runs for an initial twelve-month period, extendable by a further twelve months. Member States must report annually to the Commission on the results of their sandboxes. The Commission, in cooperation with the AI Office and Member States, shall issue guidance on the practical implementation of this Article, including selection criteria and detailed procedures for participation. ## What This Means in Practice Article 57 creates a formal, supervised pathway for organisations to innovate responsibly without waiting for the full compliance apparatus to be established. In practice, the sandbox is most relevant for startups and SMEs that are developing AI systems that may fall under high-risk classifications or that operate in legally uncertain territory, such as systems touching health, education, employment, critical infrastructure, or law enforcement. For a company seeking to use a sandbox, the process involves identifying the competent authority in its Member State, submitting an application with a sandbox plan describing the AI system, the innovation objectives, the proposed testing methodology, and the safeguards in place. If accepted, the authority assigns a dedicated point of contact and may allow the organisation to test the system with real data or in real-world conditions that would otherwise trigger stricter pre-market obligations. A concrete example: a startup developing an AI-based medical triage tool that would normally qualify as a high-risk AI system under Annex III could enter a sandbox to run clinically supervised pilots. During the sandbox, the authority may allow a phased application of conformity assessment requirements while monitoring the system's behaviour and the startup's compliance maturity. At the end of the sandbox period, the startup must either complete full conformity assessment and register the system in the EU database, or withdraw it. Importantly, sandbox participation does not create regulatory immunity. Any harm caused to individuals during testing remains the provider's liability, and fundamental rights protections apply throughout. The sandbox is a testing and learning environment, not a waiver of obligations. ## Key Obligations - **Establishment deadline:** Each Member State must have at least one functional AI regulatory sandbox operational by 2 August 2026, under the oversight of its national competent authority or via a joint cross-border sandbox arrangement. - **Sandbox plan requirement:** Participants must submit and operate under an approved sandbox plan that defines the AI system under development, the testing scope, safeguards, and intended market application. - **Continued legal liability:** Participating organisations remain fully liable for any damage, harm, or rights violation caused during sandbox activities; participation confers no immunity under civil, criminal, or data protection law. - **Duration limits:** Sandboxes are capped at twelve months, extendable once for a further twelve months, after which the system must achieve full compliance or be withdrawn. - **Priority access for SMEs and startups:** Competent authorities must ensure that SMEs and startups have prioritised or facilitated access to sandbox programmes, including through simplified application procedures and dedicated support. - **Reporting and transparency:** Competent authorities must produce reports at the conclusion of each sandbox cycle summarising activities, outcomes, and lessons learned; Member States must report annually to the Commission on the overall functioning of their sandbox programmes. ## Relationship to Other Articles Article 57 sits within Title VI (Measures in Support of Innovation) alongside Articles 58 through 63, which address sandbox-specific data processing rules, real-world testing outside sandboxes, and measures for SMEs. It is closely connected to Article 58, which establishes the data protection conditions under which personal data may be processed within a sandbox for the purpose of developing AI in the public interest. The article also connects directly to the high-risk AI system obligations in Title III (Articles 8 to 51), since sandboxes are primarily intended to assist providers in meeting those requirements before market placement. Article 74 on market surveillance is relevant because the competent authority overseeing a sandbox may be the same body responsible for post-market supervision. Article 57 should further be read alongside Article 3 (definitions, in particular the definitions of "provider", "prospective provider", and "AI system") and Article 96, which governs the role of the AI Office in coordinating cross-border sandbox activities and issuing implementation guidance. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024, with obligations phased in over a multi-year period. Article 57 falls under the general application date of 2 August 2026, meaning Member States are required to have their AI regulatory sandboxes operational by that date. The broader compliance calendar provides context for sandbox relevance: prohibitions on unacceptable-risk AI practices became enforceable from 2 February 2025; obligations relating to general-purpose AI models (Title VIII) applied from 2 August 2025; and obligations for high-risk AI systems listed in Annex III apply from 2 December 2027, with a further extension to 2 August 2028 for high-risk systems covered by existing Union harmonisation legislation. This phasing means that the sandbox mechanism under Article 57 becomes available precisely as high-risk AI obligations become enforceable, giving innovative providers a structured pathway to test and refine their systems under supervision before facing the full weight of conformity assessment, registration in the EU database under Article 71, and ongoing post-market monitoring obligations under Article 72. -------------------------------------------------------------------------------- ## Article 58 — Conditions for the establishment and operation of AI regulatory sandboxes (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-58/ ## Official Text Summary Article 58 of Regulation (EU) 2024/1689 establishes the conditions under which AI regulatory sandboxes must be created and operated. It places a direct obligation on Member States to ensure that at least one sandbox is established at national level no later than 2 August 2026. The European Data Protection Supervisor must establish a sandbox for Union institutions, bodies, offices, and agencies falling within the scope of the Regulation. The article sets out that sandboxes must operate on the basis of a specific plan agreed between the participant and the competent authority. Participation is time-limited, as a general rule to twelve months, extendable by a further twelve months. Selection of participants must follow transparent and fair criteria; SMEs and startups are to be given priority where they meet the eligibility conditions. Competent authorities must provide guidance, supervision, and appropriate support to participants throughout the sandbox period. Participants remain subject to all applicable Union and national law during sandbox activities, including obligations regarding safety, fundamental rights, and data protection. Personal data processed during sandbox activities must be handled in accordance with Regulation (EU) 2016/679 (GDPR), Regulation (EU) 2018/1725, and Directive (EU) 2016/680, and must not be used for any purpose other than those set out in the sandbox plan without explicit authorisation. At the conclusion of the sandbox, participants must submit a final report. Competent authorities may publish a summary of results, contributing to the broader evidence base for AI regulation across the Union. ## What This Means in Practice Article 58 has practical consequences for a wide range of stakeholders — national regulators, innovators, and legal teams alike. **For national competent authorities**, the article creates a binding obligation: at least one functional sandbox must exist in each Member State by 2 August 2026. Regulators that have not yet launched sandbox programmes must accelerate governance design, resource allocation, and inter-agency coordination (particularly with data protection authorities). Cross-border sandboxes, which Article 58 explicitly permits, require bilateral or multilateral coordination protocols between national authorities. **For providers and prospective providers**, the sandbox offers a structured path to test high-risk or novel AI systems under regulatory supervision before full market deployment. Concretely, a startup developing a predictive risk-scoring system for credit decisions — a likely high-risk system under Annex III — could apply to participate in a national sandbox to assess conformity and refine technical documentation before the high-risk rules become fully applicable. **For legal and compliance teams**, Article 58 does not create a compliance holiday. All substantive obligations under other applicable law remain in force during sandbox participation. Data protection impact assessments are still required where relevant; fundamental rights safeguards cannot be waived. What the sandbox provides is structured regulatory dialogue, early supervisory feedback, and a degree of procedural flexibility — not a derogation from substantive rules. Organisations considering sandbox participation should engage early with their national competent authority, prepare a detailed sandbox plan covering objectives, methodology, data governance, and exit criteria, and document all decisions and outcomes thoroughly in anticipation of the final report obligation. ## Key Obligations - **Member States must establish at least one AI regulatory sandbox** at national level no later than 2 August 2026; the European Data Protection Supervisor must establish a sandbox for Union institutions, bodies, offices, and agencies. - **Sandbox participation must be governed by a written plan** agreed between the participant and the competent authority, specifying the AI system to be developed or tested, the activities to be carried out, the objectives, the duration, and the supervisory arrangements. - **Duration is capped at twelve months, extendable once by a further twelve months**, for a maximum total of twenty-four months; extensions must be justified and approved by the competent authority. - **Selection criteria must be transparent and non-discriminatory**; SMEs and startups meeting eligibility conditions must be prioritised, reflecting the pro-innovation policy intent of Title VI. - **All applicable Union and national law continues to apply** throughout the sandbox period, including GDPR, sector-specific legislation, and safety requirements; personal data may only be processed for the purposes set out in the sandbox plan. - **A final report must be submitted** at the end of the sandbox period, documenting activities, results, lessons learned, and measures taken or planned to ensure compliance prior to market placement or service deployment. ## Relationship to Other Articles Article 58 sits within Title VI (Measures in Support of Innovation) and must be read alongside the surrounding provisions of that title. Article 57 defines what an AI regulatory sandbox is and establishes the general framework obligation, forming the foundation on which Article 58 builds its operational conditions. Article 59 addresses the specific regime applicable to processing of personal data within sandboxes, providing the data protection interface that Article 58 requires but does not itself detail. Article 60 extends analogous testing provisions to real-world conditions outside sandboxes for certain high-risk AI systems. Beyond Title VI, Article 58 connects to the obligations of high-risk AI system providers under Title III, since sandbox participation is most relevant precisely for systems that may fall under Annex III classifications. It also interacts with Article 74 (market surveillance) and Article 70 (confidentiality), as competent authorities exercise supervisory powers within the sandbox and handle commercially sensitive information shared by participants. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024, triggering a phased application schedule. The key dates relevant to Article 58 are: - **1 August 2024** — Regulation enters into force; all provisions begin their countdown to application. - **2 February 2025** — Prohibitions on unacceptable-risk AI practices (Article 5) become applicable. - **2 August 2025** — GPAI model obligations (Title VIII) and governance provisions become applicable. - **2 August 2026** — **Article 58 becomes fully applicable**: Member States must have established at least one operational national AI regulatory sandbox by this date. The European Data Protection Supervisor's sandbox for Union institutions must also be operational. - **2 December 2027 / 2 August 2028** — High-risk AI system obligations under Annex III (and Annex I for embedded systems) become fully applicable — the period for which sandbox participation is most strategically relevant for providers developing high-risk systems. Organisations and national authorities should treat 2 August 2026 as a hard deadline for sandbox readiness, not a target to plan toward at the last moment. -------------------------------------------------------------------------------- ## Article 59 — Processing of personal data in regulatory sandboxes (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-59/ ## Official Text Summary Article 59 of Regulation (EU) 2024/1689 establishes the conditions under which personal data lawfully collected for other purposes may be processed within AI regulatory sandboxes. It addresses a fundamental tension inherent in innovation environments: real-world AI development frequently requires access to representative personal data, yet general data protection law restricts re-use of data beyond the original collection purpose. To resolve this, Article 59 introduces a targeted derogation from the purpose limitation principle in Article 5(1)(b) GDPR, applicable exclusively within the controlled environment of a regulatory sandbox established under Article 57 of the Regulation. The derogation is conditional: processing must be strictly necessary for the development, training, and testing of the AI system in question; the personal data must have been lawfully collected in the first instance; access must be restricted to authorised sandbox participants and competent authority staff; and appropriate technical and organisational safeguards must be in place throughout. The article further requires that personal data processed under this derogation be deleted or anonymised at the conclusion of the sandbox activity. It imposes a duty of close coordination between the AI Act competent authority and the relevant national data protection supervisory authority, ensuring that neither framework is applied in isolation. Member States are permitted to provide for additional safeguards. Recital 90 of the Regulation contextualises this provision as a proportionate measure to enable trustworthy AI development without creating a general exemption from data protection law. ## What This Means in Practice Article 59 matters most to organisations building or testing AI systems that require datasets containing personal data — for example, healthcare AI trained on patient records, fraud detection models drawing on financial transaction histories, or public safety systems using historical incident data. Without Article 59, repurposing such data for AI development would require identifying a fresh legal basis or obtaining new consent, often impractical at scale. The sandbox derogation allows a provider accepted into a national AI sandbox to use existing personal data collections under defined conditions, without needing to re-establish a legal basis under Article 6 GDPR for the new processing purpose. In practice, this means sandbox applicants must address data use explicitly in their sandbox plan submitted to the competent authority. The plan should identify the datasets, the categories of personal data involved, the necessity of using real personal data rather than synthetic alternatives, and the safeguards — including pseudonymisation, access controls, audit logging, and data retention schedules — that will be applied. Organisations should also expect their national data protection authority to be engaged early. Because Article 59 mandates inter-authority coordination, DPAs may issue guidance, conduct reviews, or request information about sandbox processing. Treating data protection as an afterthought is a compliance risk: sandbox approval does not immunise participants from GDPR enforcement. Finally, sandbox participants must build deletion or anonymisation workflows before the programme ends. Controllers who retain personal data beyond the sandbox period without an independent legal basis will be in breach of both Article 59 and GDPR Article 5(1)(e). ## Key Obligations - **Lawfulness of original collection**: Personal data processed in the sandbox must have been collected lawfully under GDPR in the first instance. Article 59 does not legitimise the processing of unlawfully obtained data. - **Necessity assessment**: Participants must demonstrate that processing personal data is strictly necessary for the AI development or testing activity; the use of synthetic, anonymised, or aggregated data must be considered and ruled out where practicable. - **Restricted access**: Access to personal data within the sandbox must be limited to authorised personnel of the participating organisation and, where applicable, staff of the competent authority conducting oversight. General organisational access is not permitted. - **Technical and organisational safeguards**: Appropriate measures — including pseudonymisation, encryption, access controls, and audit trails — must be implemented and documented throughout the duration of sandbox processing. - **Inter-authority cooperation**: The AI Act competent authority and the national data protection supervisory authority must coordinate their oversight of sandbox activities. Participants should be prepared to engage with both bodies. - **Data deletion or anonymisation on exit**: Upon conclusion of sandbox activities, personal data processed under the Article 59 derogation must be deleted or irreversibly anonymised, unless Union or Member State law requires or permits further retention. ## Relationship to Other Articles Article 59 cannot be read in isolation. It is directly dependent on **Article 57**, which establishes the obligation for Member States to set up at least one AI regulatory sandbox at national level, and **Article 58**, which governs the general operation of those sandboxes, including participant selection, duration, and supervisory arrangements. The personal data derogation in Article 59 interacts with the GDPR framework as a lex specialis provision: it modifies purpose limitation under **GDPR Article 5(1)(b)** but leaves all other obligations intact, including the legal basis requirements of **GDPR Article 6**, data subject rights under **GDPR Chapter III**, and accountability obligations under **GDPR Article 5(2)**. Organisations should also consult **Article 10** of the EU AI Act, which imposes specific requirements on data governance and training datasets for high-risk AI systems — many of the data quality principles articulated there inform what constitutes adequate safeguards in the sandbox context. **Recital 90** provides important interpretive context on the legislative intent behind the derogation. ## Compliance Timeline Article 59 became part of Union law when the EU AI Act entered into force on **1 August 2024**, twenty days after publication in the Official Journal. However, the provisions of Title VI — including Article 59 — apply from **2 August 2025**, the date by which Member States were required to have designated their competent authorities and by which the general governance framework, including sandbox obligations, became operational. This means national regulatory sandboxes should have been established and accepting participants from August 2025 onward. Organisations wishing to invoke the Article 59 derogation must first gain admission to a recognised sandbox under Article 57; there is no standalone right to claim the personal data processing derogation outside that framework. For reference, the broader AI Act phasing is as follows: prohibitions on unacceptable-risk AI applied from **2 February 2025**; GPAI model obligations from **2 August 2025**; obligations for high-risk AI systems listed in Annex III apply from **2 December 2027** (with a transitional period to **2 August 2028** for certain systems already on the market). Article 59 is therefore already in force and directly relevant to any organisation currently engaged in, or planning to enter, a national AI regulatory sandbox. -------------------------------------------------------------------------------- ## Article 6 — Classification rules for high-risk AI systems (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-6/ ## Official Text Summary Article 6 of Regulation (EU) 2024/1689 establishes the two-track classification mechanism that determines when an AI system is subject to the stringent obligations applicable to high-risk systems under Title III, Chapter 2. The first track, set out in Article 6(1), captures AI systems that are safety components of products already regulated by the Union harmonisation legislation enumerated in Annex I — including the Machinery Regulation, the Medical Devices Regulation, the In Vitro Diagnostic Medical Devices Regulation, the Radio Equipment Directive, and several others. Where such a product is itself required to undergo third-party conformity assessment under the applicable sectoral legislation, the AI system functioning as its safety component is automatically classified as high-risk. The second track, set out in Article 6(2), captures standalone AI systems that are listed in Annex III. That annex enumerates eight areas — biometric identification and categorisation; critical infrastructure management; education and vocational training; employment and worker management; access to essential private and public services; law enforcement; migration, asylum, and border control; and administration of justice and democratic processes. Article 6(3) introduces a self-assessment exception: a provider may determine that an Annex III system does not pose a significant risk if it does not profile natural persons and satisfies specific conditions, with the determination documented and communicated to national authorities. The Commission retains delegated power to amend Annex III and to publish guidelines clarifying the application of the self-assessment criteria. ## What This Means in Practice Article 6 is the compliance gateway for the entire high-risk regime. Before any conformity assessment, CE marking, or registration obligation arises, a provider must first determine whether their system crosses the Article 6 threshold. **For developers and providers of embedded AI:** If your AI system controls, monitors, or assists a safety function within a product that carries a CE mark under Annex I legislation — a surgical robot, an autonomous vehicle, an industrial press — you must treat it as high-risk from the moment of design. This applies regardless of whether your organisation is the manufacturer of the end product or a sub-component supplier; the obligation follows the safety function, not the corporate structure. **For providers of standalone AI applications:** You must map your intended use against each category in Annex III. A credit-scoring model used by a bank to decide access to essential financial services falls under point 5(b) of Annex III. An AI tool used by an employer to screen CVs falls under point 4. The key word throughout Annex III is "intended purpose": classification follows what you have designed and documented the system to do, not how a deployer chooses to use it post-deployment. **Self-assessment under Article 6(3):** If you believe your Annex III system qualifies for the exception — for example, a narrowly scoped AI tool that assists humans without any profiling function — you must produce a written assessment, retain it, and notify the relevant market surveillance authority. This is not a blanket opt-out; regulators may challenge the determination. **Practical first step:** Conduct a classification audit mapping every AI system in your portfolio against both Annex I product categories and all eight Annex III areas well before the first of the two deadlines that follow from it — 2 December 2027 for stand-alone Annex III systems, 2 August 2028 for Annex I products. ## Key Obligations - **Determine classification before market placement:** Providers must assess whether each AI system meets the Article 6(1) safety-component criterion or falls within any Annex III category prior to placing the system on the market or putting it into service. - **Apply the full high-risk compliance framework if classified:** A positive classification under Article 6(1) or 6(2) triggers all obligations under Title III, Chapter 2 — including risk management (Article 9), data governance (Article 10), technical documentation (Article 11), logging (Article 12), transparency (Article 13), human oversight (Article 14), and accuracy and robustness requirements (Article 15). - **Document and notify self-assessment exceptions:** Where a provider invokes the Article 6(3) exception to avoid high-risk classification for an Annex III system, the determination must be documented in writing, included in technical documentation, and communicated to the competent national authority before market placement. - **Monitor Annex III for Commission updates:** The Commission may amend Annex III via delegated acts under Article 97. Providers must track such amendments and re-classify existing systems where necessary, even after initial market placement. - **Respect sectoral law interaction for Annex I products:** For systems falling under Article 6(1), conformity assessment procedures and timelines are governed by the applicable sectoral legislation listed in Annex I, and compliance with that legislation is a precondition of AI Act compliance — the two regimes are cumulative, not alternative. - **Apply transitional provisions correctly:** Providers must identify whether any of their high-risk systems benefit from the transitional regime and record the basis for that determination, since a "significant change" to the system will end the transition and trigger immediate full compliance. ## Relationship to Other Articles Article 6 is the entry point to the high-risk regime and must be read as the precondition for the entire Chapter 2 of Title III. A positive classification under Article 6 immediately engages Article 9 (risk management system), Article 10 (training data governance), Article 11 (technical documentation per Annex IV), Article 12 (automatic logging), Article 13 (transparency and instructions for use), Article 14 (human oversight measures), and Article 15 (accuracy, robustness, and cybersecurity). Article 43 governs which conformity assessment procedure applies once a system is classified as high-risk: Article 6(1) systems generally follow the sectoral procedure, while Article 6(2) systems may use the internal control procedure of Annex VI unless a specific Annex III category requires third-party involvement. Article 47 requires providers to draw up an EU declaration of conformity, and Article 49 requires CE marking — both contingent on classification under Article 6. Article 5 (prohibited practices) applies independently and upstream of Article 6: a system may simultaneously be prohibited and high-risk, in which case Article 5 prevails absolutely. ## Compliance Timeline **2 August 2024** — Regulation (EU) 2024/1689 entered into force (20 days after publication in the Official Journal on 12 July 2024). **2 February 2025** — Prohibited AI practices under Article 5 became enforceable. Article 6 classifications do not yet apply, but providers are advised to begin portfolio mapping at this stage. **2 August 2025** — Rules on general-purpose AI models (Title VIII) and governance obligations became applicable. Article 6 still not yet in force, but the Commission is expected to publish guidelines on the Article 6(3) self-assessment criteria around this period. **2 December 2027** — Article 6 and the full high-risk obligations under Title III, Chapter 2 become enforceable for AI systems listed in Annex III. This is the primary compliance deadline for most high-risk standalone AI systems. **2 August 2028** — Extended transitional deadline for AI systems that are safety components of Annex I products and were already placed on the market or put into service before 2 August 2026 under existing sectoral law, provided no significant change has occurred. Providers should plan backwards from 2 August 2026, allowing 12–18 months for conformity assessment, technical documentation, and registration in the EU database under Article 71. -------------------------------------------------------------------------------- ## Article 60 — Testing of high-risk AI systems in real-world conditions outside AI regulatory sandboxes (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-60/ ## Official Text Summary Article 60 of Regulation (EU) 2024/1689 establishes the conditions under which providers and prospective providers of high-risk AI systems may conduct testing in real-world conditions outside the structured framework of AI regulatory sandboxes established under Articles 57 to 59. This provision recognises that meaningful evaluation of high-risk AI systems often requires exposure to genuine operational environments, while maintaining safeguards commensurate with the risks involved. The article requires that testing outside sandboxes be carried out only where a set of cumulative conditions are met. The provider or prospective provider must submit a notification to the competent national authority at least 30 days prior to commencing testing. The notification must include a test plan describing the scope, duration, geographical area, categories of persons involved, and the risk mitigation measures in place. Informed consent of subjects is a central requirement. Where the AI system interacts with or makes decisions affecting identifiable natural persons, those persons must be informed of their participation and must consent explicitly, unless applicable sectoral law provides otherwise. Testing must not exceed what is strictly necessary to achieve the stated objectives, and must not expose subjects to unacceptable risk or harm. The article further requires that the testing be conducted under the supervision of the provider, that results be recorded, and that serious incidents encountered during testing be reported to the competent authority. Member States retain the ability to authorise or refuse testing activities in their territory and may impose additional conditions. ## What This Means in Practice Article 60 is primarily relevant to organisations developing or deploying high-risk AI systems — as defined under Article 6 and Annex III of the Regulation — who need to validate system performance or safety properties in genuine operational settings before or alongside formal conformity assessment. This includes, for example, a hospital piloting an AI-assisted diagnostic tool in a live clinical environment, or a financial institution testing a creditworthiness model with real applicants outside a controlled sandbox. In practice, compliance means establishing an internal process for managing real-world tests that mirrors the obligations of the article. Before any test begins, the organisation must prepare a structured test plan, verify that all consent mechanisms are in place, and lodge the required notification with the competent authority at least 30 days in advance — leaving adequate time for the authority to raise objections or impose conditions. During the test, the organisation must maintain active human oversight, document all material incidents, and be prepared to suspend testing immediately if risks exceed anticipated levels. Data collected during testing remains subject to applicable GDPR obligations, and the processing of special categories of data requires a specific legal basis. Organisations should also ensure their contracts with deployers or third-party test operators clearly allocate responsibility for compliance with Article 60 conditions, since the obligation sits primarily with the provider or prospective provider regardless of who physically conducts the test. Internal governance frameworks — including a designated responsible person and a documented risk register for the test — are strongly advisable. ## Key Obligations - **Advance notification**: Submit a test plan to the relevant national competent authority at least 30 days before real-world testing commences, covering scope, duration, location, subject categories, and risk mitigation measures. - **Informed consent**: Obtain explicit informed consent from all natural persons involved in or affected by the testing, and inform them of their unconditional right to withdraw at any time without detriment. - **Risk proportionality**: Ensure that testing activities do not exceed what is strictly necessary for the stated objective and do not expose subjects or third parties to risks that outweigh the expected benefits. - **Supervision and documentation**: Maintain active oversight of the test, keep records of the test plan, results, and any deviations or incidents encountered throughout the testing period. - **Incident reporting**: Report without undue delay any serious incident that occurs during real-world testing to the competent authority, and take immediate corrective action to mitigate harm. - **EU database registration**: Register the real-world testing activity in the EU database for high-risk AI systems established under Article 71, prior to commencing testing. ## Relationship to Other Articles Article 60 is part of Title VI (Measures in Support of Innovation) and should be read alongside Articles 57 to 59, which establish the primary framework for AI regulatory sandboxes. Article 60 functions as a complementary pathway for testing that does not take place within a formal sandbox, but it does not replace or lower the substantive safety and transparency obligations that apply to high-risk AI systems under Title III (particularly Articles 8 to 15 on provider obligations, risk management, and technical documentation). The consent and data protection requirements of Article 60 intersect directly with Regulation (EU) 2016/679 (GDPR), particularly Articles 6, 9, and 22 on lawful processing and automated decision-making. Article 60 also connects to Article 71 on the EU database, which governs registration obligations, and to Article 73 on market surveillance, since competent authorities may inspect real-world tests. Providers should additionally consider Article 26 on obligations of deployers, as real-world testing frequently involves deployer-side infrastructure and data. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024, twenty days after its publication in the Official Journal of the European Union. Its provisions apply in phases: - **2 February 2025** — Prohibitions on unacceptable-risk AI practices (Article 5) became applicable. - **2 August 2025** — Provisions on general-purpose AI models (Title III, Chapter 3, Articles 51 to 56) and governance obligations (Title VI and VIII in part) became applicable. The regulatory sandbox framework under Articles 57 to 59 also became applicable from this date. - **2 August 2026** — The general application date for most remaining provisions, including Article 60. From this date, providers and prospective providers of high-risk AI systems wishing to conduct real-world testing outside sandboxes must comply fully with the notification, consent, documentation, and incident reporting obligations established by this article. - **2 August 2028** — Extended deadline for high-risk AI systems falling under Annex III, point 2 (AI systems in existing products already subject to Union harmonisation legislation listed in Annex I), giving affected sectors additional time to align with conformity assessment and operational requirements. Organisations planning real-world testing programmes should begin designing compliant test governance frameworks and notification procedures well in advance of the 2 August 2026 date to avoid delays when the obligation becomes enforceable. -------------------------------------------------------------------------------- ## Article 61 — Informed consent in real-world testing (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-61/ Article 61 sets the consent floor for testing high-risk AI systems in real-world conditions under Article 60: no subject participates without freely given, informed consent. It transposes a clinical-trials instinct into AI testing. ## Official Text Summary Before taking part in real-world testing under Article 60, subjects must give freely given informed consent, obtained after they receive concise, clear, relevant and understandable information about the nature and objectives of the testing, the conditions of participation and its expected duration, their rights and the guarantees attached — notably the right to refuse to participate and the right to withdraw at any time without giving reasons and without suffering any detriment — and the arrangements for requesting reversal or disregard of the system's outputs. Consent must be dated and documented, and a copy given to the subject or their legal representative. ## Key Obligations - Consent must be obtained before any participation, after concise, clear, relevant and understandable information on the testing's nature, objectives, conditions, expected duration and the subject's rights - Subjects may refuse or withdraw at any time without justification and without any detriment; withdrawal only stops future participation - Consent must be dated and documented, and a copy given to the subject or their legal representative ## Compliance Timeline Applies from 2 August 2026; the 2026 Digital Omnibus deferred the substantive high-risk obligations (Annex III to 2 December 2027, Annex I to 2 August 2028) but did not move this provision. -------------------------------------------------------------------------------- ## Article 62 — Measures for providers and deployers that are SMEs, including start-ups (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-62/ ## Official Text Summary Article 62 of Regulation (EU) 2024/1689 (the EU AI Act) falls under Title VI — Measures in Support of Innovation — and establishes a framework of targeted support measures for providers and deployers of AI systems that qualify as small and medium-sized enterprises (SMEs), including start-ups. The article imposes obligations primarily on Member States and the Commission, rather than on SMEs themselves. Under Article 62(1), Member States are required to take specific actions to support SMEs and start-ups, including ensuring their priority access to AI regulatory sandboxes established pursuant to Article 57. Where sandbox capacity is limited, competent authorities must give preferential treatment to SME and start-up applicants. Article 62(2) requires Member States to organise specific awareness-raising activities about the AI Act targeted at SMEs and start-ups. Article 62(3) directs Member States, in coordination with the Commission, to facilitate the participation of SMEs in standardisation activities relevant to AI. Article 62(4) provides that where competent authorities charge fees for conformity assessment activities, reduced rates must be applied for SMEs. Finally, the Commission is required under Article 62(5) to develop dedicated guidance documents, compliance tools, and templates tailored to the needs and capacities of SMEs, taking into account resource limitations and the absence of in-house legal and technical expertise that is typical of larger enterprises. ## What This Means in Practice Article 62 operates as a horizontal support mechanism layered over the substantive compliance obligations of the EU AI Act. It does not reduce or waive those obligations for SMEs, but it creates a set of enforceable duties on public authorities to make compliance practically achievable for smaller actors. For an SME or start-up developing or deploying a high-risk AI system — for example, an AI-assisted recruitment tool covered by Annex III — Article 62 means that when applying to participate in a national AI regulatory sandbox, the application should receive priority treatment over applications from large enterprises. This matters because sandbox capacity is finite and demand is expected to exceed available places in early implementation years. For conformity assessment costs, SMEs should verify with their national competent authority or notified body whether reduced fees apply to their specific procedure. The fee reduction obligation is binding on Member States, though the exact scale of reduction is left to national implementation. From a day-to-day compliance standpoint, the most practically relevant output of Article 62 is the Commission guidance and templates it mandates. SMEs without dedicated compliance or legal teams will be able to use standardised documentation templates — for technical documentation, risk management records, and conformity declarations — developed specifically for their context, reducing the cost and complexity of demonstrating compliance. Start-ups in the pre-market phase should also consider engaging with standardisation bodies (CEN/CENELEC, ISO/IEC) at the national level, where Article 62(3) support channels may provide subsidised or facilitated access to working groups developing harmonised standards relevant to AI. ## Key Obligations - Member States must give SMEs and start-ups priority access to AI regulatory sandboxes established under Article 57 when allocating limited sandbox capacity. - Member States must organise dedicated awareness-raising activities about the EU AI Act targeted specifically at SMEs and start-ups, addressing their particular challenges and resource constraints. - Member States, in coordination with the Commission, must facilitate SME and start-up participation in standardisation activities related to AI systems. - Where conformity assessment fees are charged by competent authorities or notified bodies, Member States must ensure that reduced rates are applied for SMEs. - The Commission must develop and make available dedicated guidance, simplified compliance documentation templates, and practical tools designed for use by SMEs and start-ups without specialist legal or technical in-house capacity. - Member States must establish at least one single information point or equivalent mechanism providing SMEs and start-ups with easily accessible information on compliance with the EU AI Act. ## Relationship to Other Articles Article 62 is operationally linked to Article 57 (AI regulatory sandboxes), which establishes the legal basis for national sandboxes and the framework within which Article 62's priority access obligation applies. It should be read alongside Article 58 (detailed provisions on sandbox arrangements) and Article 60 (testing of high-risk AI systems in real-world conditions), as SMEs are likely to be the primary beneficiaries of these innovation-support mechanisms. Article 62 also connects structurally to the conformity assessment obligations in Articles 43 and 44 — the fee reductions it mandates become relevant when SMEs must engage a notified body under those articles. More broadly, it complements Article 55 (general innovation support measures) and Article 61 (obligations on Member States to support innovation). The support infrastructure created under Article 62 is overseen at Union level by the AI Office and the European Artificial Intelligence Board established under Articles 64 and 65 respectively. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024, with application phased across several dates. Article 62 falls under Title VI, which has a general application date of 2 August 2025 — meaning that Member State obligations to set up SME support measures, priority sandbox access, and reduced fee structures were required to be operational by that date. The practical significance of Article 62 intensifies as later phases come into force. High-risk AI systems listed in Annex III become fully subject to conformity assessment requirements from 2 December 2027, with certain high-risk systems in Annex I sectors applying from 2 August 2028. These are the moments when SMEs will most acutely need the sandbox access, guidance tools, and reduced-fee pathways that Article 62 mandates. SMEs should not wait until those deadlines to engage with national competent authorities: sandbox applications, standardisation participation, and familiarity with Commission templates should be pursued from mid-2025 onward to allow adequate preparation time. -------------------------------------------------------------------------------- ## Article 63 — Derogations from certain requirements applicable to high-risk AI systems for certain operators (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-63/ ## Official Text Summary Article 63 of Regulation (EU) 2024/1689 (the EU AI Act), situated within Title VI — Measures in Support of Innovation, establishes targeted derogations from certain requirements of Chapter III, Section 2 that would otherwise apply in full to providers and other operators of high-risk AI systems. The principal beneficiaries are microenterprises within the meaning of Commission Recommendation 2003/361/EC (enterprises with fewer than 10 employees and annual turnover or balance sheet total not exceeding EUR 2 million). For such providers, Article 63 permits a simplified approach to the quality management system obligations laid down in Article 17, allowing procedures and policies to be implemented in a manner proportionate to the operator's size and operational capacity, rather than through the comprehensive documented system that larger providers must establish. Article 63 further addresses public-body operators that deploy high-risk AI systems, recognising that their procurement and governance structures may differ materially from commercial operators. Certain documentation and conformity obligations may be adapted where a public body acts exclusively as deployer and the system is procured from an external provider who retains primary provider obligations. Critically, the article preserves the substantive safety floor: derogations concern procedural form and scale, not the underlying requirements of accuracy, robustness, cybersecurity, data governance, transparency, and human oversight. All operators, regardless of size, must still ensure that high-risk AI systems meet the technical requirements of Articles 9 through 15 and remain subject to market surveillance obligations. ## What This Means in Practice Article 63 is a proportionality instrument. Its practical effect is to reduce administrative burden on the smallest market participants and on certain public-sector deployers without compromising the safety objectives of the Regulation. **For microenterprise providers**, the most significant relief relates to Article 17 quality management systems. Rather than maintaining a fully documented QMS with designated roles, change-management procedures, post-market monitoring plans, and systematic version control, a microenterprise may implement equivalent governance through simpler internal procedures — for example, a concise policy document, a designated responsible person, and a basic incident log — provided these measures adequately address risk. The technical documentation obligations of Article 11 and the conformity assessment procedures of Articles 43–44 continue to apply in full, as do registration obligations in the EU database under Article 71. **For public-body deployers**, Article 63 recognises that where a contracting authority procures a high-risk AI system, primary conformity obligations rest with the provider. The deployer's obligations under Article 26 — including fundamental rights impact assessments, human oversight designation, and logging — remain intact, but Article 63 provides contextual clarity that such bodies are not expected to replicate provider-side technical documentation they do not possess. **Practical example**: A two-person legal-tech startup placing a contract-review AI system on the market (Annex III, point 5(a) — access to legal aid) must conduct a conformity assessment and register the system, but may document its risk-management process through a streamlined internal procedure rather than a formal ISO-aligned QMS. A large municipality deploying the same system from a third-party provider remains subject to deployer obligations but is not expected to produce the provider's technical file. Operators should document their eligibility for derogations — specifically their classification as a microenterprise — as part of their compliance records, since market surveillance authorities may request evidence. ## Key Obligations - **Establish proportionate quality management procedures**: Microenterprise providers must implement internal procedures covering the substance of Article 17 obligations — risk management, data governance, documentation, post-market monitoring — scaled appropriately to their size and the risk profile of the AI system, even if not through a formal documented QMS. - **Maintain full technical documentation**: Article 63 derogations do not reduce technical documentation requirements under Article 11 and Annex IV. Providers must still produce, maintain, and make available documentation demonstrating conformity. - **Complete applicable conformity assessment**: All high-risk AI system providers, including microenterprises, must complete the conformity assessment procedure under Article 43 before placing a system on the market or putting it into service. - **Register in the EU AI Act database**: Registration obligations under Article 71 apply regardless of operator size; microenterprises must register high-risk AI systems in the public EU database maintained by the Commission. - **Preserve human oversight and safety requirements**: Technical requirements under Articles 9–15 (risk management, data governance, transparency, accuracy, robustness, cybersecurity, and human oversight) are not derogated and must be met in full by all providers irrespective of size. - **Document derogation eligibility**: Operators relying on Article 63 derogations should maintain records demonstrating their qualifying status (e.g., microenterprise classification, or public-body deployer status) to substantiate their compliance approach to national market surveillance authorities. ## Relationship to Other Articles Article 63 operates as a proportionality modifier within the broader high-risk AI system compliance framework and must be read in conjunction with several other provisions. **Article 17** (Quality management systems) is the primary article from which microenterprise derogations are drawn; Article 63 conditions and limits those derogations. **Articles 9–15** set the non-derogable technical floor that Article 63 explicitly preserves. **Article 26** governs deployer obligations and is relevant to the public-body derogation provisions. **Article 11 and Annex IV** define technical documentation requirements that remain fully applicable. Within Title VI, Article 63 sits alongside Articles 57–62 (AI regulatory sandboxes) and Articles 64–68 (support measures for SMEs and testing), forming a coherent SME-support framework. **Article 9 of Title I** (the general proportionality obligation applicable to all providers) provides the regulatory rationale underlying Article 63's specific relief measures. **Article 71** (EU database) and **Article 43** (conformity assessment) establish obligations that Article 63 does not modify. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024**, twenty days after publication in the Official Journal. The phased application schedule relevant to Article 63 is as follows: - **2 February 2025** — Prohibitions on unacceptable-risk AI practices (Article 5) became applicable. Article 63 is not relevant at this stage. - **2 August 2025** — General-purpose AI model obligations (Title III, Chapter V) and governance provisions became applicable. Article 63 derogations do not apply to GPAI providers. - **2 December 2027** — The full high-risk AI system framework under Title III, Chapter III, Section 2 — including the requirements from which Article 63 provides derogations — becomes applicable to systems listed in **Annex III** (stand-alone high-risk AI systems, including biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, and administration of justice use cases). Article 63 derogations become operative from this date for qualifying operators. - **2 August 2028** — High-risk AI systems embedded in products covered by **Annex I** harmonised legislation (machinery, medical devices, civil aviation, motor vehicles, etc.) become subject to the full framework. Article 63 derogations extend to qualifying operators in those product sectors from this date. Operators seeking to rely on Article 63 derogations should begin internal eligibility assessments and proportionate compliance planning well in advance of the applicable date for their system category. -------------------------------------------------------------------------------- ## Article 64 — AI Office (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-64/ ## Official Text Summary Article 64 of Regulation (EU) 2024/1689 establishes the AI Office as a body within the European Commission, charged with contributing to the implementation, monitoring, and supervision of the EU AI Act at Union level. The AI Office is vested with a broad institutional mandate covering several core functions: developing and maintaining Union-level expertise on artificial intelligence technologies and markets; overseeing compliance by providers of general-purpose AI models, including models presenting systemic risk; supporting the European Artificial Intelligence Board and the Commission in their respective tasks; and coordinating with national competent authorities to ensure coherent enforcement across the single market. The Article grants the AI Office investigative and enforcement powers with respect to general-purpose AI (GPAI) models. These include the authority to request information and documentation from providers, conduct evaluations of GPAI models, and refer matters for further action. The Office also manages the development of codes of practice intended to facilitate compliance with obligations applicable to GPAI model providers under Chapter V of the Regulation. Article 64 further assigns the AI Office responsibility for monitoring market developments, emerging AI capabilities, and systemic risks associated with frontier models. It may issue guidance, recommendations, and opinions to stakeholders and national authorities. The AI Office acts as the single point of contact for matters involving GPAI models and ensures that enforcement actions at Union level are proportionate, technically informed, and procedurally sound under the framework established by the Regulation. ## What This Means in Practice For providers of general-purpose AI models — including large language models and multimodal foundation models — the AI Office is the primary regulatory interlocutor at European level. Any provider whose model is made available in the EU, regardless of where the provider is established, falls within scope of the AI Office's oversight mandate once the GPAI provisions apply. In practical terms, providers should expect the AI Office to issue requests for technical documentation, model evaluations, and information about training data, compute thresholds, and downstream use cases. Providers of models classified as presenting systemic risk — those trained with more than 10^25 FLOPs or otherwise identified by the Commission — face heightened scrutiny, including adversarial testing requirements and incident reporting obligations monitored by the AI Office. The AI Office also leads the development and oversight of codes of practice for GPAI compliance. Participation in these codes is voluntary but carries significant compliance weight: providers that adhere to an approved code of practice benefit from a presumption of conformity with the corresponding obligations. Providers that choose not to participate must demonstrate alternative compliance by other means, which the AI Office evaluates. For deployers and downstream operators, the AI Office is less directly relevant but its guidance documents, published evaluations, and enforcement decisions establish the interpretive baseline that national market surveillance authorities follow. Businesses integrating GPAI models into high-risk AI systems should monitor AI Office publications closely, as its technical findings shape how obligations cascade from GPAI providers to deployers. National competent authorities handling high-risk AI systems coordinate with the AI Office through the European Artificial Intelligence Board, ensuring that enforcement across Member States remains consistent and technically informed. ## Key Obligations - **Providers of GPAI models** must cooperate fully with AI Office information requests, including providing access to technical documentation, model weights (under appropriate confidentiality protections), training data summaries, and evaluation results within the timeframes set by the Office. - **Providers of GPAI models with systemic risk** must engage with the AI Office's enhanced oversight regime, including adversarial capability evaluations, incident notification, and cybersecurity measure reporting. - **All GPAI providers** should monitor and participate in AI Office-led code of practice processes, or maintain documented alternative compliance evidence sufficient to satisfy the Office's equivalence assessment. - **The AI Office** itself is obligated to exercise its powers in accordance with due process, proportionality, and the procedural guarantees set out in Chapter VII of the Regulation, including rights of defence for entities under investigation. - **National competent authorities** must cooperate with and support the AI Office's cross-border investigations and share relevant market surveillance findings through the established coordination mechanisms. - **The European Commission** must ensure the AI Office is appropriately resourced with technical expertise, staffing, and independence of operation to carry out its mandate effectively under the Regulation. ## Relationship to Other Articles Article 64 is the institutional foundation for the Union-level governance architecture and must be read in conjunction with the surrounding provisions of Title VII. Article 65 establishes the European Artificial Intelligence Board, which works alongside the AI Office as the principal advisory body. Articles 66 and 67 create the Advisory Forum and Scientific Panel on General-Purpose AI respectively — both feeding technical expertise into the AI Office's operations. For GPAI-specific oversight, Article 64 connects directly to Chapter V (Articles 51–56), which sets out the obligations that the AI Office enforces. Articles 88 to 94 govern the AI Office's investigative and enforcement powers in detail, including access to models, corrective measures, and penalties. Article 74 on market surveillance and Article 85 on confidentiality of information are also operationally relevant to how the AI Office conducts its activities. Article 5 (prohibited practices) and Articles 6–51 (high-risk systems) inform the AI Office's market monitoring responsibilities, even where primary enforcement rests with national authorities. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024**, establishing the legal basis for the AI Office immediately. The Office began constituting its structure and expertise during the initial transitional period. **February 2025**: Provisions on prohibited AI practices (Article 5) became applicable; the AI Office's monitoring role in relation to systemic risks and market developments was activated. **August 2025**: GPAI model obligations under Chapter V became fully applicable. From this date, the AI Office's enforcement authority over general-purpose AI model providers — including systemic risk assessments, code of practice oversight, and information requests — became fully operational. **August 2028**: High-risk AI system requirements under Annex I (product safety legislation) apply; national market surveillance authorities activate under AI Office coordination. **December 2027**: Remaining high-risk AI system obligations under Annex III apply. Full cross-level governance — combining AI Office GPAI oversight with national authority enforcement of high-risk systems — is operational across the EU single market. Providers of GPAI models that were already available before August 2025 had limited transitional accommodation but should by now be fully compliant with all Chapter V obligations and actively engaged with AI Office oversight processes. -------------------------------------------------------------------------------- ## Article 65 — European Artificial Intelligence Board (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-65/ ## Official Text Summary Article 65 of Regulation (EU) 2024/1689, situated within Title VII (Governance), establishes the European Artificial Intelligence Board (EAIB) as an independent advisory and coordination body at Union level. The Article provides that the Board shall be composed of one representative from the national competent authority of each Member State, with each representative having one vote. The European Data Protection Supervisor participates as a non-voting member, ensuring coherence with the Union's data protection framework. The Commission acts as the chair of the Board without voting rights, facilitating its work and providing secretariat support. The Board operates independently in the performance of its tasks, and its members are bound by obligations of professional secrecy. Article 65 makes clear that the Board does not replace or supersede national competent authorities; it operates as a layer of Union-level coordination above national supervisors. Member States retain primary enforcement jurisdiction, but the Board ensures that divergent national interpretations do not fragment the single market's approach to AI governance. The Article further specifies that the Board may establish sub-groups or expert panels to address specific technical or sectoral questions, and that it shall cooperate with other relevant Union bodies and agencies — including the European Union Agency for Cybersecurity (ENISA), the European Medicines Agency (EMA), and sectoral regulators — where the AI Act intersects with domain-specific legislation. The Board shall adopt its own rules of procedure and may invite external experts and observers to participate in its work on a case-by-case basis. ## What This Means in Practice For organisations developing, deploying, or distributing AI systems in the EU, the Board created by Article 65 represents the primary source of authoritative, cross-border interpretive guidance on the AI Act. While the Board cannot fine or sanction individual companies directly, its opinions and recommendations carry substantial practical weight: national competent authorities are expected to take them into account when applying the Regulation, and the Commission may draw on Board guidance when proposing delegated acts or technical standards. In practice, this means that when the Board issues an opinion on what constitutes a "high-risk" use case, on the sufficiency of a technical documentation standard, or on how the conformity assessment process should be interpreted in a particular sector, compliance teams should treat that opinion as near-authoritative guidance and update internal policies accordingly. Providers of general-purpose AI models should be particularly attentive to the Board's work, as Article 65 gives it a specific coordination role in matters touching on GPAI model governance, including interaction with the AI Office established under Article 64. Deployers in regulated sectors — healthcare, education, critical infrastructure — should monitor Board sub-group outputs, since sectoral expert panels convened under Article 65 are likely to produce the most operationally relevant guidance for their industries. The Board also serves as the forum through which national authorities escalate cross-border enforcement questions. If a provider's AI system is marketed across multiple Member States and different national authorities reach conflicting preliminary findings, the Board becomes the mechanism for achieving a harmonised position. Compliance teams operating at scale across the EU should therefore track Board meeting agendas, published opinions, and annual reports as primary regulatory intelligence inputs. ## Key Obligations - **Member States** must designate a national competent authority to sit on the Board and must ensure that representative has the technical and regulatory expertise required to engage substantively in Board deliberations. - **The European Commission** is required to chair the Board, provide its secretariat, and facilitate its functioning, including administrative and analytical support necessary for the Board to discharge its advisory mandate. - **Board members** are bound by obligations of professional secrecy with respect to confidential information obtained in the course of their duties, protecting commercially sensitive information shared during cross-border coordination. - **The Board** must adopt and publish its own rules of procedure, ensuring transparency in how decisions, opinions, and recommendations are reached and disseminated. - **The Board** is required to cooperate with other relevant Union institutions, agencies, and bodies where the AI Act overlaps with other regulatory frameworks, avoiding contradictory supervisory positions across legal instruments. - **AI providers and deployers** bear no direct obligations under Article 65 itself, but must engage constructively with national competent authorities who implement Board guidance, and should maintain awareness of Board opinions that may reinterpret or clarify compliance standards applicable to their systems. ## Relationship to Other Articles Article 65 sits at the centre of the AI Act's governance architecture in Title VII and must be read alongside several closely related provisions. Article 64 establishes the AI Office within the Commission, which handles supervision of general-purpose AI models and works in close coordination with the Board; understanding the division of labour between the AI Office and the Board is essential for GPAI model providers. Article 66 sets out the Board's detailed tasks, specifying the full scope of its advisory, coordinating, and information-sharing functions. Article 67 addresses the Advisory Forum, which provides civil society and industry input to complement the Board's governmental composition. For enforcement questions, Article 65 connects directly to Articles 70 through 74, which govern market surveillance, national enforcement powers, and the mutual assistance obligations that the Board coordinates. Articles 75 and 77, covering cross-border cases and the Union safeguard procedure, are the downstream mechanisms through which Board coordination translates into binding enforcement outcomes. Providers subject to conformity assessment obligations under Articles 43 and 44 should also note that the Board may issue opinions on harmonised standards and common specifications relevant to those assessments. ## Compliance Timeline The AI Act entered into force on **1 August 2024**, and the Title VII governance provisions — including Article 65 — applied from that date, providing the immediate legal foundation for constituting the European Artificial Intelligence Board. The Board's practical importance intensified as the Act's phased application schedule took effect. Prohibitions on unacceptable-risk AI practices applied from **2 February 2025**, at which point the Board became the coordinating body for consistent enforcement of those prohibitions across Member States. Obligations relating to general-purpose AI models applied from **2 August 2025**, triggering the Board's coordination role with the AI Office on GPAI supervision. The largest tranche of high-risk AI system obligations — covering systems listed in Annex III — applies from **2 December 2027**, with a further tranche for certain regulated-product AI systems applying from **2 August 2028**. The Board's guidance output in 2025 and 2026 is therefore critical: opinions and recommendations issued in this window will shape how national authorities approach market surveillance and conformity assessment when enforcement of high-risk provisions reaches full intensity. Compliance teams should treat Board publications during this period as mandatory reading alongside Commission delegated acts and harmonised standards from CEN/CENELEC. -------------------------------------------------------------------------------- ## Article 66 — Tasks of the Board (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-66/ ## Official Text Summary Article 66 of Regulation (EU) 2024/1689 defines the tasks of the European Artificial Intelligence Board (the Board), established under Article 65. The Board is tasked with a broad range of advisory, coordination, and facilitation functions designed to ensure coherent implementation of the AI Act across all Member States. Under Article 66, the Board shall: collect and share expertise and best practices among national competent authorities; assist Member States and the Commission in ensuring consistent and effective application of the Regulation; advise and assist the Commission on matters related to AI, including requests for standard-setting, the preparation of delegated and implementing acts, and updates to the classification of high-risk AI systems; issue opinions, recommendations, and written contributions on questions raised by Member States or the Commission; contribute to the harmonisation of administrative practices; and promote cooperation with third countries and international organisations on AI governance. The Board may also establish sub-groups to examine specific issues and draw on the expertise of the EU AI Office, scientific bodies, and civil society stakeholders. It operates under the governance rules set out in Article 65 (composition and organisation) and its work feeds directly into the Commission's regulatory and enforcement activities. The Board does not itself issue binding enforcement decisions but its outputs carry significant interpretive weight and directly inform the practical application of all other provisions of the Regulation. ## What This Means in Practice For most AI providers, deployers, and importers, Article 66 operates in the background — it does not impose direct obligations on private entities. However, the practical compliance implications are substantial and should not be overlooked. First, the Board is the primary mechanism through which the Commission develops interpretive guidance, common methodologies, and clarifications on contested questions — for example, what constitutes a "substantial modification" to a high-risk AI system, or how the risk classification criteria in Annex III should be applied to emerging AI use cases. Compliance teams should monitor Board opinions and recommendations closely, as these function as the authoritative interpretation of ambiguous provisions. Second, the Board's role in facilitating joint investigations and coordinating national market surveillance authorities means that multi-jurisdictional AI deployments — products sold in multiple EU Member States — will face increasingly consistent regulatory scrutiny. Relying on regulatory arbitrage between Member States will become progressively less viable as Board coordination matures. Third, providers of general-purpose AI models should be aware that the Board advises the Commission specifically on GPAI oversight, making Board guidance documents particularly consequential for that category. Practically, compliance officers should treat Board publications — available via the EU AI Office — as primary reference documents alongside the Regulation itself, and factor expected Board guidance into their compliance roadmaps for high-risk systems entering the market through 2026 and 2027. ## Key Obligations - The Board must collect and share technical expertise and best practices among national competent authorities to promote uniform enforcement. - The Board must advise and assist the Commission on the preparation of delegated acts, implementing acts, and guidelines under the AI Act, including on the list of high-risk AI systems. - The Board must issue opinions, recommendations, and written contributions in response to requests from the Commission or Member States on questions falling within the scope of the Regulation. - The Board must promote cooperation and information exchange among competent authorities to facilitate consistent application and prevent divergent national interpretations. - The Board must contribute to the development of common methodologies and tools for AI risk assessment, including guidance relevant to conformity assessment bodies (notified bodies). - The Board may establish sub-groups and draw on external scientific and technical expertise to support its advisory and coordination functions. ## Relationship to Other Articles Article 66 cannot be read in isolation — it is embedded in a dense governance architecture. It depends directly on Article 65 (which establishes the Board) and Article 65 (which governs its composition and operating rules). The Board's advisory function on high-risk classification connects it to Article 7 (amendments to Annex III) and Annex III itself. Its role in advising on GPAI matters links it to Title IV (Articles 51–56) and to Article 90, which governs the EU AI Office's oversight role for general-purpose AI models. The Board's guidance on conformity assessment practices is relevant to Articles 43 and 44 (conformity assessment procedures and notified bodies). Its coordination function with national authorities connects it to Title VIII on market surveillance (Articles 74–78). Stakeholders dealing with prohibited AI practices should also note the Board's advisory role in relation to Title II (Article 5). ## Compliance Timeline Article 66 became operative as part of the broader governance framework of the AI Act, which entered into force on **1 August 2024**. The Board's institutional existence and initial tasks were activated from that date, with the expectation that it would be operational in time to support the phased application of the Regulation's substantive requirements. Key milestones relevant to Board activity include: - **February 2025** — Prohibition of unacceptable-risk AI practices (Article 5) became applicable; the Board's role in clarifying scope was immediately relevant. - **August 2025** — GPAI model obligations (Title IV) became applicable; the Board has an explicit advisory role in this area. - **August 2028** — High-risk AI systems listed in Annex I become subject to full obligations; Board guidance on conformity assessment and classification is expected to be substantially developed by this date. - **December 2027** — High-risk AI systems listed in Annex III (existing systems placed on the market before August 2024) must comply; Board coordination will be central to harmonised enforcement across Member States by this stage. Organisations should treat the Board's work programme as an ongoing compliance signal and revisit their risk assessments whenever the Board issues new opinions or the Commission acts on Board recommendations. -------------------------------------------------------------------------------- ## Article 67 — Advisory forum (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-67/ ## Official Text Summary Article 67 of Regulation (EU) 2024/1689 establishes an Advisory forum tasked with providing technical expertise and stakeholder representation to the European AI Board and the AI Office. The forum is composed of a broad range of representatives, including industry actors, small and medium-sized enterprises, start-ups, civil society organisations, academic and research institutions, and standardisation bodies. The European Commission is responsible for establishing the forum and defining its composition rules, ensuring balanced representation across sectors, company sizes, and EU Member States. The Advisory forum may be consulted by the Board and the AI Office on matters requiring stakeholder input, and may issue opinions, technical recommendations, and written contributions on its own initiative or upon request. It may also establish sub-groups to address specific technical or sectoral questions. The forum meets at regular intervals and its rules of procedure are published to ensure transparency. Members of the Advisory forum are expected to act independently and in the public interest, disclosing any conflicts of interest that may arise. The article reinforces the EU AI Act's broader commitment to inclusive governance by ensuring that those most affected by AI regulation — developers, deployers, civil society, and academia — have a structured channel through which to contribute to regulatory thinking and technical guidance. ## What This Means in Practice Article 67 does not impose direct compliance obligations on AI providers or deployers. However, it has significant practical implications for how the regulatory framework evolves over time. For **industry actors and trade associations**, the Advisory forum is the primary formal channel through which private sector perspectives feed into the governance of the AI Act. Companies — particularly those developing or deploying high-risk AI systems — have a strong incentive to engage with forum proceedings, monitor published opinions, and respond to consultations. Forum outputs may inform guidance documents, implementing acts, and delegated regulations that directly affect compliance obligations. For **civil society and academic institutions**, the forum provides a seat at the table in shaping how the AI Office and the Board interpret and enforce the Regulation. Organisations that submit evidence-based contributions can influence technical standards, conformity assessment guidance, and the identification of systemic risks. For **legal and compliance teams**, tracking Advisory forum opinions is an emerging best practice. Although not legally binding, these opinions signal the direction of regulatory interpretation and may be cited by national authorities during audits or enforcement actions. They also provide early visibility into areas where the Commission may propose legislative clarification. Practically, participation requires monitoring the AI Office's website and the European Commission's stakeholder consultation portals. Companies with significant exposure to the AI Act should consider nominating representatives or engaging through sectoral trade bodies that participate in the forum. ## Key Obligations - The European Commission must establish the Advisory forum and set rules governing its composition, ensuring balanced representation of industry, SMEs, civil society, academia, and standardisation bodies. - The Advisory forum must adopt and publish its rules of procedure, ensuring transparency and predictability in its operations. - Members of the Advisory forum must disclose any conflicts of interest and act in the public interest and independently of any particular commercial or institutional agenda. - The Advisory forum may issue opinions and technical recommendations either on its own initiative or in response to requests from the AI Office or the European AI Board. - The Advisory forum may constitute sub-groups to address specific technical, sectoral, or cross-cutting questions arising under the Regulation. - The AI Office and the Board must consider Advisory forum input as part of their governance and technical deliberation processes, though they are not bound by its recommendations. ## Relationship to Other Articles Article 67 is embedded within Title VII (Governance) and must be read in close conjunction with adjacent governance provisions. It operates as a complement to **Article 65**, which establishes the European AI Board composed of Member State representatives, and **Article 65**, which defines the Board's tasks and working methods. Where the Board ensures coordination between national competent authorities, the Advisory forum ensures that external expertise and civil society perspectives inform that coordination. The forum also connects to **Article 66**, which establishes the scientific panel of independent experts supporting the AI Office, particularly regarding general-purpose AI models. The Advisory forum and the scientific panel serve distinct but complementary roles: the panel provides independent scientific assessment, while the forum provides broader stakeholder representation. Article 67 further relates to **Article 70** (AI Office) and the wider enforcement architecture, since forum opinions may feed into the technical guidance and codes of practice developed under **Articles 56 and 95**. ## Compliance Timeline Article 67 falls within the governance chapter of the EU AI Act, which entered into force on **2 August 2024**. The governance provisions, including the establishment of the Advisory forum, became applicable on **2 August 2025** — twelve months after entry into force — in line with the phased application schedule set out in Article 113. This timeline means that the Advisory forum was expected to be constituted and operational by August 2025, enabling it to contribute to the governance work that underpins the high-risk AI system obligations applicable from **2 December 2027** (for high-risk systems under Annex III) and **2 August 2028** (for high-risk systems under Annex I). Organisations preparing for those later deadlines should monitor Advisory forum outputs from 2025 onward, as opinions and technical recommendations issued during that period are likely to shape how the Commission and national authorities interpret key compliance requirements. -------------------------------------------------------------------------------- ## Article 68 — Scientific panel of independent experts (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-68/ ## Official Text Summary Article 68 of Regulation (EU) 2024/1689 establishes a scientific panel of independent experts to support the enforcement and governance of the EU AI Act, particularly with respect to general-purpose AI (GPAI) models. The Commission is tasked with establishing the panel by means of an implementing act, determining its composition, rules of operation, and the procedure for selecting members. Panel members are appointed on the basis of their current, high-level scientific or technical expertise in artificial intelligence, and serve in a personal and independent capacity. They are prohibited from acting on behalf of any Member State, EU institution, or private interest, and must declare any potential conflicts of interest before participating in relevant deliberations. The panel's core mandate includes: providing independent scientific opinions, analyses, and technical advice to the AI Office and, where relevant, to national competent authorities; contributing to the assessment of GPAI models that may present systemic risks; alerting the AI Office to specific concerns; and supporting consistent application of the Regulation across the Union. The panel may also request access to information and documentation from GPAI model providers, subject to confidentiality obligations. Its work complements the institutional structure of the European AI Board and the AI Office, providing an independent scientific layer within the overall governance architecture established by Title VII. ## What This Means in Practice For most organisations deploying or developing AI systems, Article 68 operates in the background: the scientific panel is an institutional body, not a direct compliance obligation for private actors. However, its practical implications are significant, particularly for providers of general-purpose AI models with a wide reach or systemic risk potential. **For GPAI model providers:** The panel has the authority to request technical documentation, model evaluations, and test results. Providers of models classified as presenting systemic risk — or under investigation for that classification — should anticipate requests for information from the panel and be prepared to respond within the timeframes specified by the AI Office. Maintaining structured, auditable technical documentation is therefore advisable as a proactive compliance measure. **For national competent authorities and notified bodies:** The panel serves as a central scientific reference. Its opinions on risk thresholds, testing methodologies, and model capabilities are intended to support harmonised enforcement across Member States, reducing the risk of divergent national interpretations. **For compliance teams and legal counsel:** Understanding the panel's operational procedures — including how it issues alerts and recommendations — is important for anticipating the regulatory trajectory of GPAI governance. Panel outputs may influence subsequent delegated acts or guidance documents issued by the Commission, shaping compliance expectations beyond what is currently codified. The panel does not issue binding decisions, but its assessments carry authoritative weight within the enforcement chain. ## Key Obligations - **Commission obligation:** The European Commission must establish the scientific panel through an implementing act, defining composition, membership criteria, operational rules, and conflict-of-interest procedures. - **Expert independence:** Panel members must act exclusively in the public interest and in a personal capacity, disclosing any conflicts of interest that could affect the impartiality of their work. - **Technical support to the AI Office:** The panel is required to provide scientific opinions, alerts, and recommendations on GPAI models, systemic risk assessments, and technical matters referred to it by the AI Office or national authorities. - **Information access:** The panel may request relevant technical information and documentation from GPAI model providers, who are obliged to cooperate subject to applicable confidentiality protections. - **Alerting mechanism:** The panel has an explicit function to alert the AI Office to emerging risks, safety concerns, or non-compliance patterns identified in the course of its scientific activities. - **Harmonisation support:** The panel contributes to consistent and uniform application of the Regulation across the EU, in particular by providing reference scientific assessments that national competent authorities can rely upon. ## Relationship to Other Articles Article 68 sits within Title VII (Governance) and is closely interconnected with the broader governance architecture of the EU AI Act. It must be read alongside **Article 64** (power of the Commission to access information and conduct investigations into GPAI models) and **Article 65** (enforcement and investigative powers at Union level), since the panel's technical findings feed directly into those processes. The panel's work on systemic risk is directly linked to **Article 51** (classification of GPAI models with systemic risk) and **Articles 55–55** (obligations applicable to GPAI model providers, including documentation, evaluation, and incident reporting). The criteria the panel uses to assess systemic risk connect to the thresholds and indicators defined in **Annex XIII**. At the institutional level, Article 68 complements **Article 65** (AI Office) and **Article 66** (European Artificial Intelligence Board), forming a tripartite governance structure in which the panel provides independent scientific expertise, the AI Office exercises enforcement authority, and the Board coordinates national positions. **Article 70** (national competent authority powers) should also be read alongside Article 68 when considering how panel recommendations translate into Member State-level action. ## Compliance Timeline The EU AI Act entered into force on **2 August 2024**, twenty days after publication in the Official Journal. Its provisions apply in a phased manner: - **February 2025:** Prohibitions on unacceptable-risk AI practices (Title II) became applicable. - **August 2025:** Title VII governance provisions, including Article 68, became applicable. This is the date from which the scientific panel framework — covering GPAI oversight, panel establishment, and systemic risk assessment procedures — became operational. The AI Office was required to constitute the panel and its supporting infrastructure within this window. - **August 2028:** High-risk AI system requirements under Annex I (product safety legislation) apply. - **December 2027:** High-risk AI system requirements under Annex III (standalone high-risk systems) apply in full. For GPAI model providers, August 2025 is the critical compliance anchor date: from that point, the panel is empowered to request documentation and issue alerts, making technical readiness and documentation completeness an active compliance requirement rather than a future obligation. -------------------------------------------------------------------------------- ## Article 69 — Access to the pool of experts by the Member States (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-69/ Article 69 lets national authorities borrow the Union's scientific firepower: Member States may call upon the experts of the scientific panel to support their enforcement of the AI Act. It keeps deep technical capability from being a privilege of the largest administrations. ## Official Text Summary Member States may call upon the experts of the scientific panel established under Article 68 to support the activities of their market surveillance authorities under the AI Act. Access may be subject to fees payable by the Member State concerned; the Commission sets the structure and level of those fees by implementing act, taking into account the objective of adequate cost recovery. The Commission facilitates timely access to the experts as needed, and the experts must perform their tasks with impartiality and objectivity and respect the confidentiality of information obtained. ## Key Obligations - Member States may call upon scientific-panel experts to support the activities of their market surveillance authorities - Access may be subject to fees payable by the Member State, on a scale set by the Commission with cost recovery in mind - The Commission facilitates timely access, and experts act with impartiality, objectivity and confidentiality ## Compliance Timeline Applicable since 2 August 2025, together with the rest of the general-purpose AI framework; the 2026 Digital Omnibus did not alter this date. -------------------------------------------------------------------------------- ## Article 7 — Amendments to Annex III (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-7/ ## Official Text Summary Article 7 of Regulation (EU) 2024/1689 confers on the European Commission the power to amend Annex III — the list of high-risk AI system categories — by means of delegated acts adopted pursuant to Article 97. This mechanism allows the regulatory perimeter of Title III to expand or contract in response to empirical evidence, without the need for a full co-legislative procedure. When assessing whether to add a new category of AI system to Annex III, the Commission is required to apply a structured set of criteria. These include: the severity and irreversibility of the harm the system may cause to health, safety, or fundamental rights; the number of persons potentially affected and their degree of vulnerability; the extent to which the system has already been deployed and the real-world harms observed; the degree of human oversight retained over automated outputs; and whether applicable Union or Member State law already provides an adequate level of protection against the identified risks. Conversely, the Commission may remove a category from Annex III where the evidence base demonstrates that the residual risk no longer meets the threshold warranting classification as high-risk, or where equivalent safeguards have been established through other binding Union instruments. Any delegated act adopted under Article 7 is subject to the parliamentary scrutiny procedure set out in Article 97, giving the European Parliament and the Council the right to object before the act takes effect. This ensures democratic oversight of regulatory evolution while preserving the agility the Commission needs to keep pace with rapidly developing AI capabilities. ## What This Means in Practice Article 7 functions as the EU AI Act's adaptive mechanism for high-risk classification. In practice, it means that the boundary between AI systems subject to the full high-risk compliance regime and those that are not is not permanently fixed at the date of entry into force. Providers and deployers must therefore monitor Commission delegated acts continuously, not merely at the point of initial product development. For organisations building or deploying AI systems in sectors adjacent to Annex III — for example, AI tools used in workforce management, credit scoring, or public-service delivery — Article 7 creates a compliance horizon risk: a system that is out of scope today could fall within scope following a Commission amendment. Prudent organisations should conduct a preliminary high-risk assessment even for borderline systems and design their governance architecture to be upgradeable. For organisations already operating within Annex III categories, Article 7 reinforces the need for ongoing conformity monitoring. An amendment that narrows the definition of a listed category could relieve certain obligations, but organisations should not assume relief without formal legal analysis of the delegated act's scope. Concretely, a provider of an AI-assisted tool that ranks job applicants in a public-sector recruitment context is currently within Annex III point 4. If the Commission, drawing on post-market surveillance data collected under Article 72, determines that AI systems used in private-sector recruitment at small enterprises pose equivalent risks, it could extend that point via Article 7. That provider's supply chain, technical documentation requirements, and conformity assessment obligations would then apply to a wider set of customers. ## Key Obligations - **Monitor Commission delegated acts**: Providers and deployers must track any delegated acts adopted under Article 7 that amend Annex III, as amendments can alter their compliance status without transitional grace periods beyond those specified in the act itself. - **Maintain adaptable risk documentation**: Technical documentation and conformity assessment records should be structured so they can be updated to reflect any reclassification of an AI system from non-high-risk to high-risk, or vice versa. - **Conduct horizon assessments for borderline systems**: Organisations operating AI systems in sectors adjacent to Annex III should periodically assess whether evolving Commission guidance or market surveillance findings indicate a forthcoming amendment that could affect their products. - **Engage in public consultation processes**: The delegated act procedure includes consultations with relevant stakeholders; providers and industry associations should participate to ensure sector-specific evidence is considered before the Commission finalises amendments. - **Review customer and supply-chain obligations on amendment**: Where an amendment expands Annex III, providers must cascade updated contractual and technical obligations to deployers and notified bodies without undue delay. - **Track removal of categories**: Where the Commission removes a category, organisations should assess whether they can reduce compliance overhead, but must retain records demonstrating past compliance for the periods during which high-risk status applied. ## Relationship to Other Articles Article 7 cannot be read in isolation from several other provisions. It is directly subordinate to **Article 97**, which governs the exercise of the delegated power, including the duration of the delegation, the conditions for revocation, and the parliamentary objection procedure. The criteria Article 7 prescribes for adding categories to Annex III directly mirror the risk-assessment framework underlying **Article 9** (risk management system), meaning that the same factual questions that inform a Commission amendment also inform a provider's internal risk management obligations. **Article 6** defines the primary rule for high-risk classification, and Article 7 operates as its dynamic complement: together they determine which AI systems fall under the Title III obligations set out in **Articles 8 through 49**. Post-market surveillance data collected under **Article 72** and serious incident reports under **Article 73** feed directly into the evidence base the Commission uses when considering Article 7 amendments, creating a feedback loop between market oversight and regulatory classification. Finally, **Annex III** itself is the operative text that Article 7 modifies; any compliance analysis must be conducted against the version of Annex III current at the time of the relevant activity, not the version in force at any prior date. ## Compliance Timeline **2 August 2024** — Regulation (EU) 2024/1689 entered into force. Article 7, including the Commission's delegated power to amend Annex III, became operative from this date. The delegation period runs for five years from entry into force, renewable by tacit extension under Article 97. **2 February 2025** — Prohibited AI practices under Article 5 became applicable. Article 7 amendments cannot override prohibitions; any system falling under Article 5 cannot be rehabilitated by reclassification. **2 August 2025** — Rules on general-purpose AI models (Title VIII) became applicable. The Commission's post-market surveillance infrastructure began producing data that may inform future Article 7 amendments. **2 August 2028** — High-risk AI systems covered by harmonised Union legislation listed in Annex I, Section A became subject to the full Title III regime. Article 7 amendments affecting these sectors interact with existing product safety legislation. **2 December 2027** — High-risk AI systems listed in Annex III (other than those already subject to earlier dates) become fully subject to Title III obligations. This is the primary compliance deadline for most organisations affected by Annex III classifications, including any future amendments made under Article 7 prior to this date. Amendments adopted after 2 December 2027 will specify their own application dates in accordance with the delegated act procedure. -------------------------------------------------------------------------------- ## Article 70 — National competent authority (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-70/ ## Official Text Summary Article 70 of Regulation (EU) 2024/1689 requires each EU Member State to designate one or more national competent authorities for the purpose of supervising the application and enforcement of the AI Act. Each designated authority must be notified to the European Commission, which then makes this information publicly available. The article distinguishes between two functional roles that may be fulfilled by the same or different national bodies: the market surveillance authority, responsible for overseeing AI systems placed on the market or put into service, and the notifying authority, responsible for establishing and carrying out the conformity assessment body designation process. Member States must ensure that their designated authority or authorities are granted sufficient powers, resources, technical staff, and financial means to carry out their tasks effectively. Where a Member State designates more than one competent authority, it must clearly delineate their respective responsibilities and establish appropriate coordination mechanisms. Article 70 also requires Member States to designate a competent authority responsible for supervising AI systems deployed by public bodies and institutions. This acknowledges the particular sensitivity of AI use in governmental contexts and the need for dedicated oversight that is independent from commercial market surveillance. Member States must communicate their designations, and any subsequent changes, to the Commission without undue delay. ## What This Means in Practice For national governments, Article 70 is an organisational and institutional obligation: each Member State must make a concrete governmental decision about which existing regulatory body — or newly created institution — will hold supervisory powers under the AI Act. In practice, many Member States are either expanding the mandate of existing data protection authorities or digital regulators, or creating new dedicated AI oversight bodies. Countries such as France (with the CNIL and Arcom playing roles), Germany (with the Bundesnetzagentur), and Spain (with the AESIA) have moved to identify or create competent authorities ahead of the applicable deadlines. For operators — providers, deployers, importers, and distributors of high-risk AI systems — the designation of the national competent authority determines which body will conduct audits, investigations, and enforcement actions against them. This makes it essential to identify the relevant authority in each Member State where an AI system is placed on the market or put into service. For deployers of AI systems within public administrations, the designated supervisory authority for public bodies may be separate from the general market surveillance authority. This means public-sector organisations must identify which body oversees their specific context. Concrete example: a company providing a biometric identification system to a national border control agency must engage with two potentially distinct national competent authorities — the market surveillance authority (overseeing the product as a high-risk system) and the authority designated for public body deployments (overseeing the end use). Operators should monitor the European AI Office's public register of national competent authority designations and establish direct points of contact with the relevant national body. ## Key Obligations - **Member State designation**: Each EU Member State must designate at least one national competent authority responsible for supervising the application of the EU AI Act and notify the European Commission of its designation. - **Dual-function coverage**: Member States must ensure coverage of both the market surveillance function (for commercially placed AI systems) and the notifying authority function (for conformity assessment body accreditation), whether through one body or multiple coordinated bodies. - **Public-sector supervision**: A competent authority must be specifically designated to oversee AI systems used by public authorities and bodies, acknowledging the particular accountability requirements in governmental AI deployment. - **Adequate resourcing**: Designated authorities must be provided with sufficient technical expertise, human resources, and financial means to perform their supervisory and enforcement functions effectively. - **Coordination where multiple authorities**: Where more than one national authority is designated, Member States must clearly delimit responsibilities and establish formal coordination mechanisms to avoid gaps or conflicts in oversight. - **Notification and transparency**: Member States must communicate their designations to the Commission without undue delay, and the Commission must make this information publicly accessible. ## Relationship to Other Articles Article 70 is the institutional foundation for the entire Title IX enforcement and market surveillance architecture. It must be read alongside Article 74 (market surveillance and control of AI systems in the Union market), which sets out the substantive powers and procedures that national competent authorities exercise. Articles 75 and 76 address cross-border cooperation and information sharing between national authorities, which depends directly on the designations made under Article 70. Article 77 governs the powers of authorities to access data and documentation from operators, powers which flow to the authority designated under Article 70. Article 80 provides for the single point of contact that national competent authorities must establish for cross-border coordination with the European AI Office established under Article 64. At the Union level, the European AI Board (Article 65) and the European AI Office operate alongside national competent authorities, making Article 70 a critical node in the multi-level governance structure of the Regulation. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024, following publication in the Official Journal. Its obligations apply on a phased basis: - **February 2025**: Prohibitions on unacceptable-risk AI practices (Title II) became applicable. - **August 2025**: Obligations relating to GPAI models (Title VIII), governance structures including the European AI Office, and — critically for Article 70 — national competent authority designation obligations became applicable. Member States should have communicated their designations to the Commission by this date. - **August 2028**: High-risk AI system obligations under Annex I (product safety legislation) apply. - **December 2027**: Full application of obligations for high-risk AI systems listed in Annex III, completing the phased rollout. For operators, the practical significance of Article 70 becomes acute from August 2025 onward, as designated national competent authorities gain active supervisory and enforcement powers. Mapping which national authority oversees your AI systems in each relevant Member State should be treated as a compliance action completed by Q3 2025. -------------------------------------------------------------------------------- ## Article 71 — EU database for high-risk AI systems (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-71/ ## Official Text Summary Article 71 of Regulation (EU) 2024/1689 establishes the EU database for high-risk AI systems, placing the responsibility for its set-up and maintenance on the European Commission. The database is designed to serve as a centralised, publicly accessible repository that increases transparency regarding high-risk AI systems before they are placed on the EU market or put into service. Under Article 71, providers of high-risk AI systems falling within the scope of Annex III are required to register their systems in the database prior to market placement or putting into service. In specific cases, deployers of Annex III systems are also subject to registration requirements. The information to be submitted is defined in Annex VIII and covers essential identification and technical details of the system, its intended purpose, the conformity assessment approach taken, and references to the EU declaration of conformity. The article establishes two distinct sections within the database: a publicly accessible section for the majority of high-risk AI systems, and a restricted section accessible only to relevant market surveillance authorities, the Commission, and the AI Office, covering systems deployed by public authorities in sensitive domains such as law enforcement, border management, immigration, and asylum. This dual-track structure balances the public interest in transparency against legitimate confidentiality concerns in sensitive public-sector operations. The Commission is tasked with ensuring the database is functional, user-friendly, and interoperable with other relevant national and EU-level registries. ## What This Means in Practice For providers of high-risk AI systems covered by Annex III, the most immediate practical consequence of Article 71 is the mandatory registration step that must be completed before any commercial or operational deployment. Registration is not an afterthought — it is a gating obligation that must be satisfied upstream of market entry, meaning compliance processes must be structured to complete registration as part of the pre-launch checklist. Providers must create an account on the EU database platform managed by the Commission and submit the prescribed information in Annex VIII. This includes a structured description of the AI system, its intended purpose, the conformity assessment procedure that was followed, a reference to the EU declaration of conformity and, where applicable, the EU type-examination certificate issued by a notified body. Post-market monitoring plan references are also required. For example, a provider developing an AI-powered CV-screening tool used in recruitment (an Annex III, Title IV category) must register the system in the public section of the database before making it available to HR departments across EU member states. Conversely, a national police force deploying an AI system for real-time facial recognition in public spaces would register in the restricted section, with access limited to supervisory authorities. Deployers of certain Annex III high-risk AI systems — particularly those operating in the public sector or deploying systems with significant societal impact — must also verify that the systems they put into service are appropriately registered and may themselves have supplementary registration duties depending on the system category. Organisations should map their AI portfolios against Annex III categories and build registration workflows into their broader AI governance procedures. ## Key Obligations - **Provider registration before market placement**: Providers of Annex III high-risk AI systems must register the system in the EU database before placing it on the market or putting it into service within the EU. - **Submission of Annex VIII information**: Registration requires complete and accurate submission of all information fields prescribed in Annex VIII, including system description, intended purpose, conformity assessment details, and declaration of conformity references. - **Deployer registration in specified cases**: Deployers of certain Annex III high-risk AI systems (particularly public-sector deployers) bear their own registration obligations and must enter the relevant information prior to putting the system into service. - **Restricted-section registration for sensitive domains**: AI systems used by public authorities in law enforcement, border control, immigration, and asylum must be registered in the non-public, restricted section of the database rather than the general public section, with access controlled accordingly. - **Keeping registration information up to date**: Providers and deployers must ensure that registered information remains accurate and current throughout the system's lifecycle, updating entries when relevant changes occur (e.g., substantial modifications triggering a new conformity assessment). - **Commission maintenance and interoperability**: The European Commission is obliged to establish, maintain, and keep the database operational, user-friendly, and interoperable with other relevant registries, ensuring its long-term accessibility to the public and competent authorities. ## Relationship to Other Articles Article 71 operates as the practical instrument through which the documentation and transparency obligations established elsewhere in the Regulation are made publicly visible. It connects closely to Article 48 (EU declaration of conformity) and Article 47 (authorised representatives), since the declaration of conformity reference is a mandatory database field. The conformity assessment procedures set out in Articles 43 and 44 feed directly into what providers must disclose at registration. Article 71 also works in tandem with Article 49 (registration obligations as a standalone article in Title VI), which cross-references the database as the mechanism for fulfilling those duties. The Annex VIII information requirements are inseparable from the technical documentation obligations in Annex IV (Articles 11 and 12). For post-market oversight, Article 71 supports the market surveillance framework in Articles 74 and 75, as national authorities and the AI Office can use database entries as a starting point for monitoring and enforcement activities. Finally, Article 78 (confidentiality) governs how sensitive information submitted to the database, particularly in the restricted section, must be handled by competent authorities. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024, triggering the phased application schedule set out in Article 113. - **1 August 2024** — Regulation enters into force; the Commission begins preparatory work to establish the EU database infrastructure. - **2 February 2025** — Prohibited AI practices (Article 5) become applicable; no Article 71 registration obligations yet active. - **2 August 2025** — GPAI model obligations and governance provisions (Title III, Chapter III and Title V) become applicable; Article 71 database not yet operative for these categories. - **2 December 2027** — Article 71 registration obligations become applicable for providers and deployers of Annex III high-risk AI systems (excluding those already covered by Union harmonisation legislation listed in Annex I). This is the primary activation date for the EU database for the majority of in-scope systems. - **2 August 2028** — High-risk AI systems covered by Annex I product safety legislation (e.g., medical devices, machinery) that were already on the market before 2 August 2024 must comply with all applicable obligations including registration, provided they have undergone a substantial modification. Organisations developing or deploying Annex III AI systems should treat the December 2027 deadline as the firm operational target for database registration readiness, building registration workflows into their compliance programmes well in advance. -------------------------------------------------------------------------------- ## Article 72 — Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-72/ ## Official Text Summary Article 72 of Regulation (EU) 2024/1689 establishes a mandatory post-market monitoring obligation for providers of high-risk AI systems. Providers are required to proactively collect, document, and analyse relevant data about the performance of their high-risk AI systems throughout the entire operational lifetime of those systems after they have been placed on the market or put into service. The article mandates that providers draw up and implement a post-market monitoring plan, which must be proportionate to the nature of the high-risk AI technology and its associated risks. This plan must be part of the technical documentation established under Article 11 and set out in accordance with Annex IV. It must define the methods and procedures for systematically gathering performance data, including data sourced from deployers where relevant. Where the monitoring reveals that a high-risk AI system no longer complies with the requirements set out in Chapter III, Section 2, the provider must take appropriate corrective measures without delay. This includes updating the system, withdrawing it from the market, or recalling it where necessary. Article 72 also acknowledges the role of deployers: providers must instruct deployers to supply relevant operational data that cannot be collected directly. The monitoring obligation is continuous rather than point-in-time, reflecting the dynamic nature of AI system performance and the evolving contexts in which these systems are deployed. ## What This Means in Practice For organisations that develop or supply high-risk AI systems, Article 72 introduces a structured, ongoing compliance obligation that extends well beyond the moment of market placement. Providers cannot treat conformity assessment as a one-time exercise. Instead, they must design and operationalise a monitoring infrastructure before their system goes live. In practical terms, this means defining in advance what data will be collected from deployed instances of the system, how that data will be analysed, and what performance thresholds will trigger a review or corrective action. For example, a provider of an AI-assisted medical device diagnostic tool must specify which indicators — such as false-negative rates, demographic performance disparities, or model drift metrics — will be tracked, at what frequency, and by whom. Providers of AI systems embedded in third-party products face an additional challenge: they depend on deployers to relay operational data that the provider cannot access directly. This requires contractual arrangements with deployers that clearly define data-sharing obligations, as envisaged by the combined reading of Article 72 and Article 25. Organisations with existing quality management systems (QMS) — such as those already compliant with ISO 13485 in medical devices or ISO 9001 more broadly — will find natural alignment with Article 72's requirements. The post-market monitoring plan should be integrated into the broader QMS documented under Article 17, rather than treated as a standalone document. Smaller providers and startups will need to resource this function appropriately: Article 72 does not provide a de minimis exemption based on company size, though proportionality of the plan to the risk level of the system is explicitly acknowledged. ## Key Obligations - **Establish a post-market monitoring plan** that is proportionate to the risk level and nature of the high-risk AI system, documented as part of the technical documentation under Article 11 and Annex IV. - **Actively collect and analyse post-market data** on system performance throughout the operational lifecycle, including data from deployers where direct collection is not possible. - **Define performance indicators and corrective action thresholds** in advance, specifying what level of degradation or non-conformity triggers a formal review or remedial response. - **Take corrective action without delay** when monitoring reveals that the system no longer satisfies the high-risk requirements of Chapter III, Section 2, which may include updating, recalling, or withdrawing the system. - **Integrate monitoring outcomes into the quality management system** established under Article 17, ensuring findings loop back into product improvement, documentation updates, and re-assessment processes. - **Instruct deployers** to provide operationally relevant data and cooperate with the post-market monitoring process, supported by appropriate contractual or technical arrangements. ## Relationship to Other Articles Article 72 sits at the centre of a cluster of interrelated obligations. It directly feeds into Article 73, which governs the reporting of serious incidents and malfunctions to national competent authorities: the monitoring system established under Article 72 is the detection mechanism for the events that Article 73 requires to be reported. Article 17 (quality management systems) provides the organisational framework within which the post-market monitoring plan must be embedded. Article 11 and Annex IV define the technical documentation requirements that the monitoring plan must form part of. Article 25 allocates responsibilities between providers and deployers, and is essential for understanding how providers can obtain operational data from downstream users. Article 26 complements this by detailing deployer obligations, including the duty to monitor system use and report anomalies back to the provider. For high-risk AI systems that are safety components in products covered by Union harmonisation legislation listed in Annex I, Article 72 must be read alongside the post-market surveillance obligations in the applicable sectoral regulation, such as the Medical Devices Regulation (EU) 2017/745 or the Machinery Regulation (EU) 2023/1230, ensuring coherent and non-duplicative compliance. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024, following its publication in the Official Journal of the European Union. The Regulation applies in a phased manner across different categories of obligation. Article 72, as part of Title IX governing post-market monitoring and market surveillance, applies to providers of high-risk AI systems listed in Annex III (general-purpose high-risk categories such as biometrics, employment, education, and access to essential services) from **2 December 2027**. High-risk AI systems covered by Annex I — those that are safety components of products already regulated under existing Union harmonisation legislation — are also subject to the full obligations, including Article 72, from **2 August 2028** in most cases. Providers should note that the earlier deadlines — February 2025 for prohibited AI practices and August 2025 for general-purpose AI model obligations — do not directly govern Article 72, but the groundwork for monitoring infrastructure should be laid well in advance of the 2027 deadline. Organisations that develop high-risk AI systems today are advised to begin designing their post-market monitoring plans as part of the conformity preparation process, rather than retrofitting them at the point of application. -------------------------------------------------------------------------------- ## Article 73 — Reporting of serious incidents (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-73/ ## Official Text Summary Article 73 of Regulation (EU) 2024/1689 (the EU AI Act) establishes a mandatory serious incident reporting obligation for providers of high-risk AI systems made available on the Union market. Under this provision, providers must report any serious incident to the market surveillance authority of the Member State in which the incident occurred, without undue delay and within the timeframes specified by the article. The article defines the information that must be included in a report: a description of the incident, the high-risk AI system involved, the nature of the harm caused or risked, the corrective measures taken or planned, and any relevant technical documentation. Where a provider is not established in the Union, the authorised representative assumes the reporting duty. Article 73 further provides that, where a serious incident simultaneously falls within the scope of other Union legislative instruments — such as Regulation (EU) 2017/745 on medical devices or Directive 2016/680 on law enforcement data processing — the provider may submit a single notification through the most appropriate reporting channel, provided that all information requirements under each applicable instrument are fulfilled. Market surveillance authorities must share incident data with the European AI Office and with authorities in other Member States where the same system is deployed, ensuring Union-wide situational awareness. ## What This Means in Practice For any organisation that places a high-risk AI system on the EU market — whether as original developer, importer, or authorised representative — Article 73 creates a live operational obligation that activates the moment a serious incident is detected. In practical terms, compliance requires three parallel workstreams. First, internal detection: organisations must have monitoring systems, logging infrastructure, and incident triage processes capable of identifying events that meet the serious-incident threshold defined in Article 3(49). An anomaly in a credit-scoring AI that causes a discriminatory lending decision at scale, or a malfunction in an AI-based medical diagnostic tool that contributes to a misdiagnosis, would both likely qualify. Second, notification: once an incident is identified, the clock starts. A 72-hour window applies where life or safety is at immediate risk; a 15-day window applies in other cases. Organisations need pre-drafted notification templates, designated reporting contacts within their quality management systems (QMS), and clarity on which national market surveillance authority has jurisdiction — typically determined by where the affected deployer or user is located. Third, follow-up: the initial notification is rarely the end. Authorities will request supplementary information, technical logs, and root-cause analysis. Providers should maintain an incident register and document all corrective actions taken. A medical imaging company deploying an AI diagnostic tool in Germany and France must be prepared to notify the Bundesnetzagentur (or the designated competent authority in Germany) and the corresponding French authority simultaneously if incidents occur in both jurisdictions. The European AI Office receives consolidated data to track cross-border patterns. ## Key Obligations - **Immediate notification:** Report serious incidents to the competent market surveillance authority of the affected Member State without undue delay — within 72 hours where life or safety is at risk, and no later than 15 days in other cases. - **Substantive content of the report:** Include a description of the incident, identification of the AI system, nature and extent of harm, corrective measures taken or planned, and references to relevant technical documentation maintained under Article 11. - **Authorised representative duty:** Where the provider is established outside the EU, the authorised representative designated under Article 22 is responsible for submitting the incident report on the provider's behalf. - **Cross-instrument coordination:** Where an incident also triggers reporting obligations under other Union law (e.g., MDR, NIS2, DORA), the provider may consolidate notifications, provided all regulatory information requirements are met in full. - **Information sharing by authorities:** Market surveillance authorities that receive a report must share it with the European AI Office and notify authorities in other Member States where the same system is in use, enabling coordinated Union-level response. - **Incident register maintenance:** Providers must maintain records of all serious incidents and near-misses as part of their post-market monitoring obligations under Article 72, ensuring traceability and audit readiness. ## Relationship to Other Articles Article 73 cannot be read in isolation. It is the notification mechanism that operationalises the broader post-market monitoring framework established in **Article 72**, which requires providers to maintain continuous monitoring systems and incident logging as part of their quality management system. The QMS itself is governed by **Article 17**, which sets out documentation and process requirements that underpin any credible incident report. The definition of "serious incident" in **Article 3(49)** is the threshold trigger for Article 73 obligations, and the scope of "high-risk AI system" in **Article 6** and **Annex III** determines which systems fall within the article's reach. **Article 22** governs authorised representatives and is directly cross-referenced for non-EU providers. At the market surveillance level, Article 73 feeds into the broader supervisory architecture of **Articles 74–77** (market surveillance powers, access to information, and corrective measures). **Article 78** governs confidentiality of information shared between authorities. For general-purpose AI models with systemic risk, **Article 55** imposes parallel incident-reporting obligations that interact with Article 73 when such models are integrated into high-risk applications. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024**, twenty days after publication in the Official Journal of the European Union. However, its provisions apply on a phased schedule: - **2 February 2025:** Prohibitions on unacceptable-risk AI practices (Title II) became applicable. - **2 August 2025:** Obligations for general-purpose AI models (Title VIII, including Article 55 systemic-risk reporting) became applicable. The European AI Office and governance structures became operational. - **2 December 2027:** Rules applicable to high-risk AI systems listed in Annex III that are not safety components of products regulated by existing Union harmonisation legislation become applicable — **Article 73 incident reporting enters full force for these systems on this date.** - **2 August 2028:** Rules for high-risk AI systems that are safety components of products already covered by Union harmonisation legislation (e.g., medical devices, machinery) become applicable, completing the phased rollout. Organisations deploying high-risk AI systems in scope of the December 2027 / August 2028 dates should treat 2025–2026 as the compliance build period: implementing post-market monitoring infrastructure, drafting incident response procedures, and stress-testing notification workflows well before the Article 73 obligations activate. -------------------------------------------------------------------------------- ## Article 74 — Market surveillance and control of AI systems in Union territory (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-74/ ## Official Text Summary Article 74 of Regulation (EU) 2024/1689 establishes the framework for market surveillance and control of AI systems within EU territory, forming the enforcement backbone of Title IX. It requires Member States to designate market surveillance authorities in accordance with Regulation (EU) 2019/1020 on market surveillance and compliance of products, which applies mutatis mutandis to AI systems covered by the EU AI Act except where the AI Act provides specific derogations. The article confers on designated national authorities the power to investigate AI systems already placed on the market or put into service, whether supplied commercially or otherwise. Authorities are entitled to access technical documentation, training datasets, source code where necessary and proportionate, and any other information required to assess conformity. They may order operators — providers, deployers, importers, and distributors — to take corrective action, including restricting or prohibiting use, withdrawing a system from the market, or organising a recall. Where an AI system presents a serious risk, national authorities must notify the Commission and all other Member States through established rapid alert mechanisms. Article 74 also addresses the situation where AI systems are embedded in products regulated by other Union harmonisation legislation, clarifying that the relevant sectoral market surveillance authority retains competence while applying the AI Act's requirements in coordination with the general surveillance framework. For general-purpose AI models, the European AI Office exercises equivalent supervisory functions at the Union level, ensuring coherent oversight for AI components that operate across national boundaries and product categories. ## What This Means in Practice For organisations that develop, import, distribute, or deploy AI systems within the EU, Article 74 transforms the conformity assessment process from a one-time gate into an ongoing compliance obligation. Achieving CE marking or completing an internal conformity assessment does not immunise a system from post-market scrutiny. Authorities can initiate investigations at any point during the system's operational life, triggered by complaints, incidents reported through the serious incident notification mechanism under Article 73, or proactive surveillance campaigns. **Providers** must ensure that technical documentation remains current, accessible, and sufficiently detailed to support an authority's audit. If a system is updated — through model retraining, fine-tuning, or significant changes to intended purpose — the documentation must reflect those changes and, where required, a new conformity assessment may be needed. **Deployers** of high-risk AI systems should expect that authorities may contact them directly to understand how a system is being used in practice, particularly where the deployed context differs from the provider's originally envisaged use case. Deployers must cooperate fully and should maintain operational logs and human oversight records as evidence of compliant use. **Importers and distributors** bear responsibility for verifying that the products they handle carry valid documentation and markings before placing them on the EU market, since Article 74 can result in corrective orders directed at any actor in the supply chain. Practically, organisations should establish internal procedures for responding to market surveillance inquiries, appoint a designated compliance contact, and conduct periodic internal reviews to ensure the system's real-world performance continues to match its conformity assessment baseline. ## Key Obligations - **Designate cooperation points**: Providers, deployers, importers, and distributors must identify internal contacts capable of engaging promptly with national market surveillance authorities and providing access to required documentation. - **Maintain accessible technical documentation**: All documentation required under Article 11 and Annex IV must remain up to date and be made available to market surveillance authorities upon request, including for systems already in deployment. - **Cooperate with investigations**: Operators must respond to official enquiries, grant access to premises and systems where requested, and not obstruct or delay surveillance activities — non-cooperation may itself constitute a breach subject to penalties under Article 99. - **Report serious incidents**: Where providers or deployers become aware of a serious incident as defined under Article 3, they must notify the relevant market surveillance authority in accordance with Article 73, which in turn triggers coordinated action under the Article 74 framework. - **Implement corrective measures when ordered**: Upon receiving an order from a market surveillance authority — whether to modify, restrict, withdraw, or recall an AI system — operators must act within the timeframe specified and inform the authority of the steps taken. - **Cross-border notification compliance**: Where a system is found to present a serious risk and is the subject of a national enforcement measure, the authority notifies the Commission and other Member States; affected operators may be required to extend corrective measures simultaneously across multiple jurisdictions. ## Relationship to Other Articles Article 74 functions as the enforcement layer that gives practical effect to substantive requirements defined elsewhere in the regulation. It draws directly on Article 73 (post-market monitoring and serious incident reporting), which generates the data and notifications that trigger many surveillance investigations. It is inextricably linked to Articles 11 and 12 (technical documentation and record-keeping) and Articles 16 and 26 (obligations of providers and deployers), since these define what authorities are entitled to examine. The article interfaces with Article 9 (risk management systems) and Article 72 (post-market monitoring plans) as the real-world performance data collected under those provisions becomes evidence in any surveillance review. For serious risk scenarios, Articles 79 through 83 govern the specific corrective and protective measures that market surveillance authorities may apply following an investigation initiated under Article 74. The article also integrates horizontally with Regulation (EU) 2019/1020, the general EU market surveillance framework, whose procedures and notification mechanisms it adopts by reference. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024**, following publication in the Official Journal. Application of the regulation is phased: - **2 February 2025**: Prohibitions on unacceptable-risk AI practices (Article 5) became applicable. Market surveillance authorities received competence to investigate and enforce against prohibited systems from this date. - **2 August 2025**: Provisions on general-purpose AI models (Title III, Chapter V) and the associated governance framework, including the European AI Office's supervisory role, became applicable. Market surveillance of GPAI models and systemic-risk systems falls within this regime. - **2 December 2027**: Rules applying to high-risk AI systems listed in Annex III (used by public bodies) and the associated post-market monitoring and surveillance obligations under Title IX, including the full Article 74 framework for those systems, become applicable. - **2 December 2027 / 2 August 2028**: The remaining high-risk AI systems in Annex III, then AI systems regulated under the Union harmonisation legislation listed in Annex I, become subject to the complete conformity and surveillance regime. Organisations should treat the phased dates as activation points — surveillance infrastructure (documentation, incident reporting, cooperation procedures) should be in place before the relevant date, not after the first inquiry arrives. -------------------------------------------------------------------------------- ## Article 75 — Mutual assistance, market surveillance, and control of general-purpose AI models (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-75/ ## Official Text Summary Article 75 of Regulation (EU) 2024/1689 establishes the market surveillance and cross-border mutual assistance framework applicable to AI systems generally, and introduces specific oversight mechanisms for general-purpose AI (GPAI) models. The article is situated within Title IX, which governs post-market monitoring and market surveillance across the AI value chain. For AI systems other than GPAI models, Article 75 requires Member States to designate market surveillance authorities competent to verify compliance with the Regulation and to coordinate with one another and with the Commission. These authorities are vested with the investigatory and enforcement powers provided under Regulation (EU) 2019/1020 (the Market Surveillance Regulation), adapted to the specificities of AI. For general-purpose AI models — including those classified as presenting systemic risk under Article 51 — the article assigns primary supervisory competence to the European AI Office, operating under the authority of the Commission. The AI Office is empowered to request documentation and technical information from GPAI model providers, conduct evaluations, assess compliance with the obligations set out in Articles 53 and 55, and take or recommend corrective measures. Where a GPAI model with systemic risk is found to be non-compliant, the AI Office may require the provider to take remedial action, restrict access to the model, or initiate withdrawal procedures. National authorities retain the ability to act in relation to specific downstream AI systems deployed in their territory, even where the underlying GPAI model is supervised at Union level. ## What This Means in Practice Article 75 creates a two-tier enforcement architecture that practitioners and compliance teams must understand clearly. For providers and deployers of AI systems that are not GPAI models — particularly high-risk systems listed in Annexes I and III — market surveillance is conducted by national authorities designated under Article 70. Those authorities have powers to inspect, audit, and order corrective action. If a non-compliant AI system is identified in one Member State, Article 75 requires that authority to notify other Member States and the Commission through the RAPEX/Safety Gate mechanism, triggering a coordinated response. Companies operating across multiple EU jurisdictions must therefore be prepared to engage with more than one national authority and must maintain documentation that can be produced promptly upon request anywhere in the Union. For GPAI model providers — including foundation model developers who make models available via APIs, open weights, or integrated products — the practical implications are more significant. The European AI Office acts as the primary interlocutor. Providers should expect the AI Office to request access to technical documentation, training data summaries, evaluation methodologies, red-teaming results, and incident reports. Where systemic risk is determined under Article 51 (currently triggered at or above the 10^25 FLOP training threshold, or by Commission designation), Article 75 empowers the AI Office to conduct its own adversarial testing or commission third-party evaluations. Downstream deployers integrating GPAI models into high-risk applications must be aware that a finding against the upstream provider under Article 75 may affect the compliance status of their own product. Contracts with GPAI model providers should include provisions addressing notification obligations, cooperation duties, and remediation timelines in the event of an AI Office investigation. ## Key Obligations - **Member States** must designate or establish one or more national market surveillance authorities competent for AI systems, and notify the Commission of those designations, ensuring those authorities have adequate powers, resources, and independence. - **National market surveillance authorities** must cooperate with each other and with the European AI Office, share information about non-compliant AI systems through Union information-sharing mechanisms, and take coordinated action when a risk is identified in more than one Member State. - **GPAI model providers** must cooperate with the European AI Office upon request, provide access to technical documentation, model evaluations, and safety-relevant information, and implement corrective measures as directed by the AI Office within prescribed timeframes. - **Providers of GPAI models with systemic risk** are subject to enhanced supervision by the AI Office, including the possibility of direct evaluation, independent audits, and binding measures up to and including market withdrawal. - **Downstream providers and deployers** must, upon request by competent national authorities, provide all information necessary to assess the compliance of an AI system, including information about the GPAI model or components supplied by third parties. - **The European AI Office** must maintain coordination with national market surveillance authorities when exercising its supervisory powers over GPAI models, to avoid conflicting decisions and ensure consistent application of the Regulation across the Single Market. ## Relationship to Other Articles Article 75 cannot be read in isolation. It operationalises the obligations laid down in Articles 53 and 55 for GPAI model providers, and the high-risk system obligations in Articles 9 through 17, by establishing who enforces them and how. Article 70 governs the designation and organisation of national market surveillance authorities and should be read as the foundational provision to which Article 75 adds cross-border and GPAI-specific dimensions. Article 71 addresses market surveillance activities more broadly, while Article 72 covers the EU database for high-risk AI systems that supports surveillance efforts. Article 51 is directly relevant because it defines the systemic risk threshold that triggers the enhanced AI Office oversight under Article 75. Article 94 grants the Commission implementing powers to adopt procedural rules for AI Office investigations. Article 80 governs Union protective measures where a Member State takes action against a non-compliant system, which interacts with Article 75 mutual assistance obligations. Practitioners should also consult Regulation (EU) 2019/1020, which provides the baseline market surveillance procedural framework that Article 75 incorporates and adapts for AI. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024**, twenty days after publication in the Official Journal. The Regulation then applies in phases: - **2 February 2025** — Provisions on prohibited AI practices (Title II, Article 5) became applicable. - **2 August 2025** — Provisions on general-purpose AI models (Chapter V, Articles 51–56) and the market surveillance framework including **Article 75** became applicable. Member States were required by this date to have designated their national market surveillance authorities and notified the Commission. - **2 August 2028** — High-risk AI systems covered by Annex I (product safety legislation) must comply fully with the Regulation. - **2 December 2027** — All remaining high-risk AI systems listed in Annex III must comply, completing the full phased application of the Regulation. For GPAI model providers, Article 75 is therefore already in force. The European AI Office has been operational since its establishment within the Commission structure, and providers should treat its investigatory powers as immediately exercisable. National market surveillance authorities are equally active for non-GPAI AI systems already on the market. -------------------------------------------------------------------------------- ## Article 76 — Supervision of testing in real-world conditions by market surveillance authorities (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-76/ ## Official Text Summary Article 76 of Regulation (EU) 2024/1689 confers specific supervisory powers on market surveillance authorities over the testing of high-risk AI systems in real-world conditions as provided for under Article 60. The article establishes that where such testing takes place on the territory of a Member State, the competent market surveillance authority for that territory holds jurisdiction to oversee the conduct of the test and to verify that all conditions prescribed by Article 60 are being met throughout the testing period. Authorities are empowered to request access to all documentation underpinning the real-world test, including the testing plan, the informed consent procedures applied to participants, and any records generated by the AI system during operation. Where the authority identifies circumstances suggesting that the testing gives rise to a risk — particularly to the health, safety, or fundamental rights of natural persons — it may order the suspension or definitive termination of the testing activity. Such decisions must be communicated promptly to the European Commission and to the market surveillance authorities of other Member States through the Union's existing product safety information and communication infrastructure. The article also addresses coordination between authorities when testing spans multiple Member States, designating the authority of the Member State where the provider is established as lead supervisor, while preserving the right of each concerned authority to take protective measures on its own territory. This mirrors the coordinated enforcement model applied under other Union harmonisation legislation and ensures that cross-border real-world tests do not fall into a supervisory vacuum. ## What This Means in Practice For providers and deployers conducting real-world condition testing of high-risk AI systems, Article 76 means that testing is not a self-regulated activity: a designated market surveillance authority retains continuous oversight authority from the moment testing begins until it concludes. In practical terms, an AI provider running a pilot of, for example, a medical-diagnosis support system on patients in two Member States must identify the lead supervisory authority — typically the authority in the Member State where the provider is established — and must ensure that all test documentation required under Article 60 is available for inspection on short notice. If the authority requests access to system logs, the informed consent register, or the incident management records, these must be produced within the timeframe specified by the authority, which may be as short as a few days in urgent situations. Deployers (hospitals, recruitment agencies, credit institutions, or other organisations that integrate a provider's system) share the compliance burden. They must cooperate with supervisory inspections and must not obstruct authority access to test sites or system interfaces. Where testing generates a serious incident — a harm, near-miss, or unexpected adverse outcome involving a participant — the notification obligations of Article 73 are triggered in parallel, and the market surveillance authority supervising under Article 76 becomes an immediate recipient of that notification. Organisations should therefore integrate their incident response procedures with their testing governance frameworks before testing begins, not after an incident occurs. Multinational testing programmes should appoint a single internal compliance owner responsible for coordinating across Member State authorities, and should map in advance which authority holds lead jurisdiction and which hold concurrent territorial powers. ## Key Obligations - Providers and deployers must maintain all real-world testing documentation — including the testing plan, participant consent records, risk management records, and system operation logs — in a form that is immediately accessible to the competent market surveillance authority for the duration of the test. - Upon request by the market surveillance authority, providers and deployers must supply any information, data, or access necessary for the authority to assess compliance with the conditions set out in Article 60, within the timeframe specified by the authority. - Where testing spans multiple Member States, the provider must engage the lead supervisory authority (the authority of the Member State of establishment) and ensure that all concerned territorial authorities are informed and can exercise protective measures within their jurisdiction. - Where a market surveillance authority orders the suspension or termination of real-world testing, the provider and deployer must comply immediately and must cease all testing activities on Union territory until the authority lifts the measure or the matter is resolved through the applicable review procedure. - Any serious incident occurring during real-world condition testing must be notified to the supervising market surveillance authority in accordance with the timelines and procedures established under Article 73, without waiting for the conclusion of an internal investigation. - Providers and deployers must cooperate in good faith with market surveillance inspections, including providing on-site access to facilities, personnel, and AI system interfaces when requested. ## Relationship to Other Articles Article 76 sits at the intersection of several interlocking provisions of Regulation (EU) 2024/1689. Its primary connection is with **Article 60**, which defines the substantive conditions under which real-world condition testing of high-risk AI systems is authorised; Article 76 is the enforcement counterpart that gives those conditions binding force through supervisory oversight. It draws on the general market surveillance framework established by **Articles 74 and 75**, which define the powers and procedures available to market surveillance authorities across all categories of AI system, and should be read alongside those articles to understand the full scope of investigatory and corrective powers available. The article connects to **Article 73** on serious incident reporting, since incidents arising during supervised testing immediately activate that article's notification chain. **Article 57** on AI regulatory sandboxes is a related but distinct provision: sandboxes operate under national competent authority supervision with special derogations, whereas Article 76 governs testing in real-world conditions under the standard market surveillance regime. **Articles 85 and 86** on penalties and access to justice are relevant downstream: a failure to cooperate with Article 76 supervision can constitute a compliance breach attracting administrative fines under the Act's penalty framework. ## Compliance Timeline Regulation (EU) 2024/1689 entered into force on **1 August 2024**, marking the start of the phased application schedule. Article 76, as part of Title IX on post-market monitoring and market surveillance, falls within the provisions that become fully applicable to high-risk AI systems in the **second and third application phases**. For high-risk AI systems listed in Annex III (standalone high-risk applications), full market surveillance obligations — including Article 76 supervision of real-world testing — apply from **2 December 2027**. For high-risk AI systems that are safety components of products regulated by existing Union harmonisation legislation listed in Annex I (such as medical devices and machinery), the applicable date is **2 August 2028**. Providers planning real-world condition testing of high-risk systems should treat 2 December 2027 as the hard deadline for having compliant testing governance frameworks in place, including documented procedures for authority access, incident escalation, and cross-border coordination. Given that testing programmes often run for six to twelve months before a system reaches deployment, governance frameworks should realistically be designed and tested no later than **early 2026** to avoid delays to market entry. -------------------------------------------------------------------------------- ## Article 77 — Powers of authorities protecting fundamental rights (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-77/ ## Official Text Summary Article 77 of Regulation (EU) 2024/1689 establishes specific powers for national public authorities whose mandate encompasses the protection of fundamental rights, enabling them to act as an additional layer of oversight over high-risk AI systems deployed within their jurisdiction. Under Article 77(1), any national public authority or body competent for supervising or enforcing obligations relating to fundamental rights — including data protection authorities under Regulation (EU) 2016/679, equality bodies, consumer protection authorities, and similar agencies — is granted the power to request from deployers of high-risk AI systems access to the documentation generated and maintained in accordance with the Regulation. In particular, these authorities may request the fundamental rights impact assessment required from certain deployers under Article 27, the logs automatically generated by the AI system kept pursuant to Article 26(6), and any other relevant documentation demonstrating compliance. Under Article 77(2), where such an authority has reasonable grounds to believe that a high-risk AI system presents a risk to fundamental rights or to the health and safety of persons, it shall inform the relevant market surveillance authority designated under Article 70 and may provide it with all relevant information at its disposal. The market surveillance authority is then responsible for taking appropriate investigative and corrective action in accordance with its competences under Chapter VII. Article 77 thus creates a structured cooperation mechanism between sector-specific fundamental rights bodies and the primary market surveillance infrastructure, without conferring direct enforcement powers over AI system compliance on these authorities independently of the established market surveillance framework. ## What This Means in Practice Article 77 has direct operational consequences for deployers of high-risk AI systems — particularly those operating in sensitive domains such as employment, education, access to essential services, law enforcement, migration, and the administration of justice, where fundamental rights exposure is most acute. Deployers must be prepared to respond to documentation requests from a broader range of public authorities than the primary market surveillance authority alone. A data protection authority conducting an inquiry into an AI-assisted recruitment tool, an equality body investigating an automated benefits-eligibility system, or a consumer protection agency scrutinising an AI-powered credit-scoring platform may all invoke Article 77 to obtain the deployer's fundamental rights impact assessment and system logs. Practically, this means deployers should ensure their Article 27 fundamental rights impact assessment is completed, up to date, and readily accessible before deployment — not treated as a post-hoc exercise. Similarly, the logging obligations under Article 26 must be operationally active so that records can be produced on request without delay. For providers, Article 77 underscores the importance of producing and maintaining comprehensive technical documentation under Article 11 and instructions for use under Article 13 that are sufficiently detailed to support deployer compliance. If a fundamental rights authority raises concerns and notifies the market surveillance authority, the provider's documentation will be central to any subsequent investigation. Organisations deploying high-risk AI systems should map which fundamental rights authorities hold jurisdiction over their activities and proactively assess how those authorities are likely to interpret their mandate in relation to AI oversight. ## Key Obligations - **Deployers must produce documentation on request**: Upon a request from a competent fundamental rights authority, deployers of high-risk AI systems must provide access to the fundamental rights impact assessment (Article 27), automatically generated logs (Article 26(6)), and any other documentation relevant to the authority's assessment. - **Fundamental rights authorities must notify market surveillance authorities**: Where a fundamental rights authority has reasonable grounds to believe a high-risk AI system poses risks to fundamental rights or to health and safety, it is obliged to inform the relevant market surveillance authority designated under Article 70 and share all relevant information. - **Fundamental rights impact assessments must be current and accessible**: Because Article 77 creates a live documentation request right, deployers subject to Article 27 cannot defer or neglect the impact assessment — it must exist and be retrievable when an authority exercises its powers. - **Log retention must be operational before deployment**: Deployers must ensure the logging mechanisms required under Article 26(6) are active and records are preserved in a manner that allows timely production to authorities invoking Article 77. - **Cooperation across authority boundaries is required**: Deployers and providers must be prepared to engage simultaneously with multiple competent bodies — the fundamental rights authority initiating the inquiry and the market surveillance authority to which it reports — without creating contradictions in the information provided to each. ## Relationship to Other Articles Article 77 sits at the intersection of the post-market monitoring framework (Chapter IX) and the broader market surveillance architecture (Chapter VII), and must be read in conjunction with several other provisions. Article 26 (Obligations of deployers) establishes the core monitoring and logging duties that produce the documentation Article 77 authorities are empowered to access. Article 27 (Fundamental rights impact assessment for high-risk AI systems) creates the primary document that fundamental rights authorities will seek; the two articles are operationally coupled. Article 70 (Designation of national competent authorities and single points of contact) identifies the market surveillance authorities to which fundamental rights bodies must report under Article 77(2). Articles 74 and 75 define the investigative and corrective powers those market surveillance authorities may then exercise following notification. Article 13 (Transparency and provision of information to deployers) and Article 11 (Technical documentation) are relevant because the adequacy of provider-supplied documentation directly conditions a deployer's ability to respond to Article 77 requests. Article 9 (Risk management system) provides the upstream analytical framework that should inform the fundamental rights impact assessment referenced in Article 77. For organisations subject to the GDPR, Article 77 should also be read alongside Articles 35 and 51–59 of Regulation (EU) 2016/679, which govern data protection impact assessments and the powers of supervisory authorities — competences that overlap substantially with the Article 77 framework in AI deployments involving personal data processing. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024**, twenty days after publication in the Official Journal of the European Union. The phased application schedule is as follows: - **2 February 2025**: Prohibition on unacceptable-risk AI practices (Article 5) became applicable. - **2 August 2025**: Rules on general-purpose AI models (Title VIII, Articles 51–56) and governance obligations (Title VII) became applicable. - **2 December 2027**: Article 77, along with the full framework for high-risk AI systems listed in **Annex III** (including employment, education, essential services, law enforcement, migration, and justice applications), becomes applicable. This is the primary compliance deadline for most deployers likely to face Article 77 requests from fundamental rights authorities. - **2 August 2028**: The Article 77 framework — and the broader high-risk AI system obligations — becomes applicable to AI systems governed by Union harmonisation legislation listed in **Annex I** (including medical devices, machinery, civil aviation, and motor vehicle components). Deployers operating high-risk AI systems in fundamental-rights-sensitive domains should complete their Article 27 fundamental rights impact assessments and verify their Article 26 logging infrastructure is operational well in advance of the **2 December 2027** deadline. -------------------------------------------------------------------------------- ## Article 78 — Confidentiality (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-78/ ## Official Text Summary Article 78 of Regulation (EU) 2024/1689 establishes a binding confidentiality framework governing the handling of information obtained by competent authorities — including national market surveillance authorities, notifying authorities, notified bodies, and the Commission — in the course of their duties under the EU AI Act. The article requires all parties exercising functions under the Regulation to protect information that is subject to professional secrecy obligations. This encompasses business secrets, commercially sensitive data, intellectual property, and personal data encountered during audits, investigations, conformity assessments, corrective action procedures, or any other supervisory activity. The obligation applies both to the authorities themselves and to their staff, including external experts assisting in enforcement tasks. Article 78 nonetheless permits the exchange of information between competent authorities within a Member State, across Member States, and with the Commission where such exchange is necessary for the performance of tasks under the Regulation. Any information so shared retains its confidential character and the receiving body assumes the same protection obligations. The article does not prevent authorities from publishing aggregate, anonymised, or non-sensitive findings, nor does it override mandatory disclosure requirements arising from judicial proceedings. It operates in conjunction with Regulation (EU) 2016/679 (GDPR) and sector-specific confidentiality regimes where applicable, without displacing them. ## What This Means in Practice For AI providers and deployers, Article 78 provides a meaningful procedural protection. When a national market surveillance authority opens an investigation — for example, because a high-risk AI system has been flagged for non-compliance with the conformity assessment requirements of Article 43, or because a serious incident has been reported under Article 73 — the provider must cooperate and supply technical documentation, algorithmic details, and test results. Article 78 ensures that this commercially sensitive information does not leave the regulatory sphere without legal justification. **Who is affected.** The direct obligations fall on competent authorities and their personnel. Providers and deployers are the indirect beneficiaries, gaining assurance that trade secrets disclosed during enforcement are protected. Notified bodies, which assess conformity of high-risk AI systems and therefore receive detailed technical submissions, are equally bound. **Concrete scenarios.** A provider of a high-risk AI system used in credit scoring submits its technical documentation to the national market surveillance authority following a complaint. Under Article 78, the authority cannot share that documentation with a competitor or publish it in a way that reveals proprietary model architecture. Similarly, an employee of a notified body who reviews training data composition during a conformity assessment is bound by professional secrecy with respect to that data. **Practical steps for providers.** Organisations should label commercially sensitive documents submitted to authorities and maintain a log of what was disclosed, to whom, and under which regulatory obligation. Where a disclosure request seems to exceed the authority's powers, providers retain the right to object before competent courts. ## Key Obligations - Competent authorities, notifying authorities, notified bodies, the Commission, and their personnel must treat as confidential all information obtained in the exercise of their duties that qualifies as a business secret, commercially sensitive data, or personal data. - Confidentiality obligations extend to external experts and any other persons participating in regulatory tasks under the AI Act, such as technical assessors or scientific advisors. - Information exchange between authorities — within a Member State, across Member States, and with the Commission — is permitted where necessary for enforcement, but shared information retains its confidential status and the receiving body assumes equivalent protection duties. - Authorities may not disclose to third parties, including the public, any information that could harm the commercial interests of providers or deployers unless a specific legal basis, such as a court order or an overriding public interest, justifies disclosure. - Confidentiality obligations must be reconciled with, but do not displace, applicable data protection rules under GDPR; personal data contained in supervisory files must be handled in compliance with both frameworks simultaneously. - Authorities retain the ability to publish non-sensitive, anonymised, or aggregated findings — such as sectoral trend reports or market surveillance statistics — provided that no individual provider's confidential information can be derived from the published content. ## Relationship to Other Articles Article 78 is structurally connected to the broader market surveillance and enforcement architecture of the EU AI Act. It supports Article 74 (market surveillance at national level), Article 75 (Union-level market surveillance and coordination), and Article 76 (oversight of general-purpose AI models), all of which require authorities to collect and process sensitive operational and technical information. The confidentiality regime it establishes is a precondition for effective cooperation under Article 101 (AI Office cooperation with Member States). It also intersects directly with Article 73 (serious incident reporting) and Article 72 (post-market monitoring), since both mechanisms generate disclosures of potentially sensitive technical and commercial data to supervisory bodies. Within the conformity assessment chain, Article 78 reinforces the obligations of notified bodies designated under Articles 33–39, who regularly receive detailed technical documentation. Finally, it must be read alongside Article 70 (confidentiality obligations on operators more broadly) and Recital 145, which clarifies that the Regulation's transparency objectives cannot be used to justify disclosure of genuinely confidential commercial information. ## Compliance Timeline Article 78 entered into force on 1 August 2024, twenty days after publication of Regulation (EU) 2024/1689 in the Official Journal of the European Union. However, its practical relevance is tied to the phased application schedule of the broader Regulation. The first binding obligations under the AI Act — the prohibitions on unacceptable-risk AI practices under Article 5 — became applicable on 2 February 2025. From that date, market surveillance authorities began exercising active enforcement powers, making Article 78's confidentiality protections immediately operational for any investigations initiated. The framework for general-purpose AI models (Title IV) applied from 2 August 2025, extending Article 78 protections to information gathered in the oversight of GPAI providers and the AI Office's supervisory activities. The most substantial wave of obligations — covering high-risk AI systems listed in Annex III — applies from 2 December 2027, with certain systems in Annex I sectors subject to a further transition until 2 August 2028. As conformity assessment activity and post-market monitoring under Articles 72–73 intensify through 2026–2027, Article 78 will become a frequently invoked provision in the day-to-day relationship between regulators and the AI industry. -------------------------------------------------------------------------------- ## Article 79 — National procedure for AI systems presenting a risk (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-79/ Article 79 is the emergency lane of national market surveillance: what happens when an AI system on the market presents a risk to health, safety or fundamental rights. It choreographs evaluation, corrective action and, if needed, national measures — with Union-wide notification built in. ## Official Text Summary Where a market surveillance authority has sufficient reason to consider that an AI system presents a risk to the health or safety or to the fundamental rights of persons, it carries out an evaluation of the system's compliance with the Regulation — with particular attention where the risk concerns fundamental rights, in cooperation with the authorities referred to in Article 77. Where non-compliance is found, the authority requires the relevant operator to take all appropriate corrective action — bringing the system into compliance, withdrawing it or recalling it — within a period it prescribes. Where the operator fails to act, or the non-compliance is not confined to the national territory, the authority takes appropriate provisional measures to prohibit or restrict the system's availability, and informs the Commission and the other Member States without delay; the Article 81 Union safeguard procedure can follow. ## Key Obligations - The market surveillance authority evaluates the AI system where it has sufficient reason to consider it presents such a risk, including fundamental-rights risks flagged by the Article 77 authorities - The relevant operator must take all appropriate corrective actions — bring into compliance, withdraw or recall — within a period the authority prescribes - Where non-compliance is not national only, or the operator fails to act, the authority takes provisional measures and informs the Commission and the other Member States without delay ## Compliance Timeline Applies from 2 August 2026; the 2026 Digital Omnibus deferred the substantive high-risk obligations (Annex III to 2 December 2027, Annex I to 2 August 2028) but did not move this provision. -------------------------------------------------------------------------------- ## Article 8 — Compliance with the requirements (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-8/ ## Official Text Summary Article 8 of Regulation (EU) 2024/1689, situated in Title III (High-Risk AI Systems), Chapter 2 (Requirements for High-Risk AI Systems), establishes the foundational compliance obligation for providers of high-risk AI systems. Under Article 8(1), such systems shall comply with all requirements set out in Articles 9 through 15 of the same Chapter, which cover risk management systems, data and data governance, technical documentation, record-keeping, transparency and provision of information to deployers, human oversight measures, and accuracy, robustness and cybersecurity standards. Article 8(2) addresses the intersection of AI regulation with existing product safety legislation. Where a high-risk AI system is itself a safety component of a product, or constitutes the product itself, and that product falls within the scope of Union harmonisation legislation enumerated in Annex I to the Regulation, the AI system must comply with both the Chapter 2 requirements and the applicable Annex I legislation. In such cases, a single conformity assessment procedure may apply where Union harmonisation legislation so permits, ensuring that overlapping regulatory frameworks do not impose duplicative procedural burdens on providers. The article thus performs two functions: it activates the full suite of technical and governance requirements for high-risk AI, and it establishes the coordination rule between the AI Act and pre-existing sectoral product legislation, preserving coherence across the Union's regulatory landscape for safety-critical technologies. ## What This Means in Practice Article 8 is the gateway provision of Chapter 2. It does not itself specify the content of individual requirements — those are detailed in Articles 9 through 15 — but it makes compliance with all of them a binding legal obligation for providers of high-risk AI systems before any such system can be placed on the market, put into service, or made available. **For AI-only product providers:** If you develop and market a standalone high-risk AI system — for example, a recruitment screening tool falling under Annex III, Point 4, or a credit scoring system under Point 5 — you must satisfy the full Chapter 2 requirement set. This means establishing and maintaining a risk management system (Article 9), implementing appropriate data governance practices (Article 10), producing and maintaining technical documentation (Article 11), enabling automatic logging (Article 12), providing deployers with adequate instructions for use (Article 13), designing for meaningful human oversight (Article 14), and achieving validated levels of accuracy, robustness, and cybersecurity (Article 15). **For manufacturers embedding AI in regulated products:** If your high-risk AI system is a component of a product already subject to machinery regulation, medical device legislation, or other Annex I frameworks, Article 8(2) requires dual compliance. In practice, this means working with notified bodies familiar with both regimes, and where harmonised standards covering AI requirements exist, leveraging them to establish a presumption of conformity and streamline assessment procedures. **For importers and distributors:** While Article 8 places primary obligations on providers, importers and distributors must verify that providers have met these obligations before making systems available, as downstream liability exposure is linked to provider compliance status. ## Key Obligations - **Full Chapter 2 compliance required:** Providers must satisfy every requirement in Articles 9–15 — risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy, robustness, and cybersecurity — as a cumulative and non-negotiable obligation before market placement. - **Pre-market compliance verification:** Compliance must be established and demonstrable prior to placing the high-risk AI system on the market or putting it into service, not retrospectively. - **Dual compliance for Annex I products:** Where a high-risk AI system is a safety component of or constitutes a product subject to Union harmonisation legislation listed in Annex I, the provider must comply with both the Chapter 2 requirements and the applicable sectoral legislation simultaneously. - **Integrated conformity assessment where available:** Providers of Annex I products may use a single conformity assessment procedure where the applicable Union harmonisation legislation permits such integration, reducing procedural duplication. - **Ongoing compliance, not one-time certification:** The requirements of Chapter 2 impose continuous obligations — risk management systems must be updated, logs must be maintained, and technical documentation must remain current throughout the system's lifecycle. - **Provider accountability even through third-party components:** Where a high-risk AI system is built upon third-party models or infrastructure, the provider retains responsibility for ensuring the complete system satisfies all applicable Chapter 2 requirements. ## Relationship to Other Articles Article 8 is inseparable from Articles 9 through 15, which it activates and to which it expressly refers. It should also be read in conjunction with Article 6 and Annex III, which define which AI systems are classified as high-risk and therefore subject to the Chapter 2 regime that Article 8 mandates. Article 16 (obligations of providers) operationalises Article 8 by specifying the procedural and administrative steps providers must take to demonstrate compliance, including drawing up technical documentation, undergoing conformity assessment, affixing the CE marking, and registering the system. Article 43 governs the conformity assessment procedures whose outcomes are required for compliance with Article 8. For systems falling under Annex I product legislation, Article 8(2) must be read alongside the applicable sectoral acts — such as Regulation (EU) 2017/745 on medical devices or Directive 2006/42/EC on machinery — to determine how requirements interact and which conformity assessment route is available. Article 9 of the EU AI Act is the most immediate downstream article, establishing the risk management system that forms the operational backbone of Chapter 2 compliance. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024, twenty days after its publication in the Official Journal of the European Union. However, Article 8 and the broader Chapter 2 requirements do not apply immediately to all high-risk AI systems. The Regulation applies in phases: - **2 February 2025:** Prohibitions on unacceptable-risk AI practices (Article 5) became applicable. Article 8 is not yet in effect at this date. - **2 August 2025:** Rules on general-purpose AI models (Title VIII) and governance provisions became applicable. Article 8 remains inapplicable. - **2 December 2027:** Article 8 and all Chapter 2 requirements become applicable to high-risk AI systems listed in **Annex III** (e.g., biometric identification, critical infrastructure, employment, education, access to services, law enforcement, migration, administration of justice). - **2 August 2028:** Article 8 and Chapter 2 requirements become applicable to high-risk AI systems that are safety components of products subject to the **Annex I** Union harmonisation legislation (e.g., medical devices, machinery, toys, civil aviation equipment), given those sectors' longer conformity assessment cycles. Providers placing Annex III high-risk systems on the market after 2 December 2027 must be fully compliant with Articles 8–15 from that date. Providers of Annex I-embedded systems have until 2 August 2028, but should begin compliance work well in advance given the complexity of dual-regime assessment. -------------------------------------------------------------------------------- ## Article 80 — Procedure for systems misclassified as non-high-risk (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-80/ Article 80 polices the Act's biggest self-assessment: a provider's claim under Article 6(3) that its Annex III system is not high-risk. Market surveillance authorities can audit that claim — and reclassify the system with full consequences. ## Official Text Summary Market surveillance authorities may evaluate any AI system that its provider has classified as non-high-risk in application of Article 6(3), including following a reasoned request from another authority. Where the evaluation finds the system is in fact high-risk, the authority requires the provider to bring it into compliance with the full Chapter III regime within a period it may prescribe — requirements, conformity assessment, CE marking and registration included — and to take corrective action towards systems already on the market. Where the misclassification was carried out to circumvent the application of the rules, the provider is exposed to fines under Article 99, and the authority informs the Commission and the other Member States of the outcome. ## Key Obligations - The authority may evaluate any system classified by its provider as non-high-risk under Article 6(3), including on a reasoned request from another authority - If the system is in fact high-risk, the provider must bring it into full Chapter III compliance within a set period, including conformity assessment and registration - Misclassification aimed at circumventing the rules exposes the provider to fines under Article 99, and the authority informs the Commission and the other Member States ## Compliance Timeline Applies from 2 August 2026; the 2026 Digital Omnibus deferred the substantive high-risk obligations (Annex III to 2 December 2027, Annex I to 2 August 2028) but did not move this provision. -------------------------------------------------------------------------------- ## Article 81 — Union safeguard procedure (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-81/ Article 81 is the tie-breaker of AI market surveillance: when one Member State restricts an AI system and another objects, the Commission decides whether the national measure is justified. It keeps twenty-seven national procedures from producing twenty-seven different markets. ## Official Text Summary Where, within the period laid down in Article 79, objections are raised by a Member State against a measure taken by another Member State, or where the Commission considers a national measure to be contrary to Union law, the Commission enters into consultation without delay with the Member State concerned and the operator, and evaluates the national measure. It then decides whether the measure is justified and notifies its decision to the Member State concerned and the operator. If the measure is found justified, all Member States must ensure the non-compliant AI system is withdrawn from their market; if unjustified, the Member State concerned must withdraw the measure. The mechanism mirrors classic New Legislative Framework safeguard clauses, adapted to AI. ## Key Obligations - Triggered when objections are raised against a national measure taken under Article 79, or when the Commission considers such a measure contrary to Union law - The Commission consults the Member State concerned and the operator, evaluates the measure, and decides whether it is justified - A justified measure must be followed by all Member States; an unjustified one must be withdrawn by the State that took it ## Compliance Timeline Applies from 2 August 2026; the 2026 Digital Omnibus deferred the substantive high-risk obligations (Annex III to 2 December 2027, Annex I to 2 August 2028) but did not move this provision. -------------------------------------------------------------------------------- ## Article 82 — Compliant AI systems which present a risk (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-82/ Article 82 covers the uncomfortable case the conformity machinery cannot solve: an AI system that complies with the Act and still presents a risk to health, safety or fundamental rights. Compliance is not a liability shield when real-world danger appears. ## Official Text Summary Where, having performed an evaluation under Article 79, a market surveillance authority finds that a high-risk AI system complies with the Regulation and nonetheless presents a risk to the health or safety of persons, to fundamental rights, or to other aspects of public-interest protection, it requires the relevant operator to take all appropriate measures — without undue delay and within a period it may prescribe — to ensure the system no longer presents that risk when placed on the market or put into service. The Member State immediately informs the Commission and the other Member States, with details of the risk, the system's identification and the measures taken. The Commission consults the parties and can steer a Union-level response. ## Key Obligations - Where a compliant high-risk system nonetheless presents a risk, the market surveillance authority requires the operator to take all appropriate measures — the system must no longer present that risk when placed on the market or put into service - The operator ensures corrective action along the whole supply chain, within a period the authority prescribes - The Member State immediately informs the Commission and the other Member States, detailing the risk and the measures taken; the Commission consults and may propose Union-level follow-up ## Compliance Timeline Applies from 2 August 2026; the 2026 Digital Omnibus deferred the substantive high-risk obligations (Annex III to 2 December 2027, Annex I to 2 August 2028) but did not move this provision. -------------------------------------------------------------------------------- ## Article 83 — Formal non-compliance (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-83/ Article 83 is the paperwork enforcement clause: even when nothing dangerous is proven, missing CE marking, absent registration or an unavailable technical file must be corrected — and persistence turns it into a market restriction case. ## Official Text Summary Without prejudice to Article 79, a market surveillance authority requires the relevant provider to end, within a period it may prescribe, any of the following formal non-compliances: the CE marking has been affixed in violation of Article 48 or has not been affixed; the EU declaration of conformity has not been drawn up or has been drawn up incorrectly; the registration in the EU database has not been carried out; an authorised representative has not been appointed where required; or the technical documentation is not available. Where the non-compliance persists, the Member State concerned takes appropriate and proportionate measures to restrict or prohibit the high-risk AI system from being made available on the market, or to ensure that it is recalled or withdrawn without delay. ## Key Obligations - Covers defects such as CE marking affixed in violation of Article 48 or not affixed, missing EU declaration of conformity, missing registration in the EU database, no authorised representative, or technical documentation unavailable - The market surveillance authority requires the provider to end the non-compliance within a period it prescribes - If the non-compliance persists, the Member State takes appropriate and proportionate measures to restrict or prohibit the system, or ensure its recall or withdrawal ## Compliance Timeline Applies from 2 August 2026; the 2026 Digital Omnibus deferred the substantive high-risk obligations (Annex III to 2 December 2027, Annex I to 2 August 2028) but did not move this provision. -------------------------------------------------------------------------------- ## Article 84 — Union testing facilities (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-84/ ## Official Text Summary Article 84 of Regulation (EU) 2024/1689 establishes the framework for the creation and designation of **Union testing facilities** — specialised bodies tasked with providing independent, high-quality technical testing, inspection, and examination services in support of the EU AI Act's enforcement architecture. Under Article 84, the European Commission is empowered to designate existing testing facilities as Union testing facilities where a specific testing need has been identified at Union level, particularly where national infrastructure is insufficient or unevenly distributed across Member States. These facilities are intended to complement the existing conformity assessment ecosystem by making advanced technical capability available across the single market. The article provides that Union testing facilities shall operate in a manner that ensures impartiality, technical competence, and independence from commercial interests. Designated facilities must meet specific technical and organisational requirements laid down by the Commission, including requirements concerning confidentiality, liability, and access conditions. Article 84 also addresses access by small and medium-sized enterprises (SMEs) and start-ups, reflecting the legislator's intent to lower barriers to compliant market entry. The Commission retains oversight of the network of Union testing facilities and may coordinate their activities to ensure coherent and consistent testing standards across Member States, avoiding duplication and fostering trust in the results produced. --- ## What This Means in Practice For most AI system providers, Article 84 operates in the background of the compliance process — but it carries direct practical significance for specific actors and scenarios. **Market surveillance authorities** benefit most immediately. Where a national authority lacks the technical infrastructure to test a sophisticated AI system — for example, a high-risk AI system used in biometric identification or critical infrastructure management — they can refer the system to a Union testing facility for independent technical analysis. This is particularly relevant for cross-border enforcement scenarios involving AI systems deployed in multiple Member States. **Notified bodies** may also draw on Union testing facilities for complex or novel technical questions that fall outside their in-house expertise, supporting more robust conformity assessments for high-risk AI systems under Annex III. **Providers of high-risk AI systems**, especially SMEs and start-ups, gain a practical avenue to access state-of-the-art testing environments that would otherwise be financially or logistically inaccessible. This can be particularly valuable during pre-market validation, supporting voluntary pre-certification testing before a formal conformity assessment is initiated. **Concrete example:** A mid-sized company developing an AI-based medical diagnostic tool may lack the resources to commission full-scale adversarial robustness testing. Under Article 84, it could request access to a Commission-designated Union testing facility equipped with the relevant datasets and computational resources, obtaining a credible technical report that strengthens its technical documentation under Article 11 and supports its conformity assessment under Article 43. The practical utility of Union testing facilities will grow over time as the Commission progressively designates facilities and as market surveillance activity intensifies post-2026. --- ## Key Obligations - **Commission designation power:** The European Commission is responsible for identifying testing needs at Union level and formally designating facilities as Union testing facilities, establishing the criteria, procedures, and conditions that govern their operation. - **Technical and organisational requirements:** Designated Union testing facilities must satisfy specific requirements for impartiality, independence, technical competence, confidentiality, and governance, ensuring the reliability and credibility of their outputs. - **Support to market surveillance authorities:** Union testing facilities are mandated to make their services available to national market surveillance authorities carrying out enforcement activities under Chapter VII of the Regulation, including product testing and post-market investigations. - **Access for SMEs and start-ups:** The framework explicitly preserves access for smaller operators, recognising that equitable access to high-quality testing infrastructure is a precondition for fair competition and broad compliance across the single market. - **Coordination across Member States:** The Commission may coordinate the network of Union testing facilities to prevent duplication, ensure consistent methodologies, and maintain uniform technical standards across national jurisdictions. - **Operational independence:** Union testing facilities must operate free from undue influence by any party whose AI systems they test, maintaining structural and financial independence in line with the requirements applicable to notified bodies and accredited laboratories. --- ## Relationship to Other Articles Article 84 is embedded within the post-market monitoring and market surveillance framework of Title IX and must be read alongside several interconnected provisions. It directly supports **Article 74** (market surveillance and control of AI systems in the Union market) by providing the technical infrastructure that surveillance authorities need to discharge their investigative obligations effectively. It also complements **Article 43** (conformity assessment) and **Article 44** (certificates of conformity), as Union testing facilities may contribute technical input that informs conformity assessment decisions by notified bodies designated under **Article 41**. The technical documentation requirements of **Article 11** and the quality management obligations of **Article 17** are relevant because testing facility outputs may be incorporated into a provider's technical file. **Article 33** (high-risk AI systems: conformity assessment procedures) and **Annex III** (list of high-risk AI systems) define the scope of systems most likely to be referred to Union testing facilities. For SME-related provisions, Article 84 aligns with **Article 62** (support measures for operators that are SMEs, including start-ups), reinforcing the Regulation's broader objective of ensuring that the compliance burden does not structurally disadvantage smaller market participants. --- ## Compliance Timeline Article 84 falls within the general provisions of the EU AI Act that became applicable **24 months after entry into force** — that is, from **2 August 2026**. The main obligations for high-risk AI systems no longer share that date: the 2026 Digital Omnibus moved stand-alone Annex III systems to 2 December 2027 and Annex I product systems to 2 August 2028. Key reference dates for the broader compliance context: - **1 August 2024** — Regulation (EU) 2024/1689 entered into force. - **2 February 2025** — Prohibitions on unacceptable-risk AI practices (Title II) became applicable. - **2 August 2025** — GPAI model obligations (Title VIII) and governance provisions (Title VII, including the AI Office) became applicable. - **2 August 2026** — Article 84 and the full market surveillance framework became applicable; Union testing facility designations expected to begin. - **2 August 2028** — High-risk AI systems under Annex I (safety-component products) subject to full obligations. - **2 December 2027** — High-risk AI systems listed in Annex III that are also covered by existing Union harmonisation legislation fully subject to all obligations. Organisations operating in sectors where Union testing facilities are expected to be active — medical devices, biometrics, critical infrastructure, employment, education — should monitor Commission implementing acts and designations as they emerge throughout 2026 and 2027. -------------------------------------------------------------------------------- ## Article 85 — Right to lodge a complaint with a market surveillance authority (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-85/ ## Official Text Summary Article 85 of Regulation (EU) 2024/1689 (the EU AI Act) establishes the right of any natural or legal person to lodge a complaint with a competent market surveillance authority where that person considers that a provider, deployer, importer, distributor, or other relevant operator has infringed the provisions of this Regulation. The article places an obligation on the receiving market surveillance authority to handle the complaint with appropriate diligence and to keep the complainant informed of the status of the investigation and of the outcome of proceedings, to the extent such communication does not jeopardise the investigation itself. Member States retain responsibility for ensuring that their designated authorities are adequately equipped to receive and process such complaints effectively. The provision is deliberately broad in its personal scope: the right is not restricted to individuals who are directly affected or harmed by the AI system in question. Any person — natural or legal — who has reason to believe an infringement has occurred is entitled to invoke this mechanism. This inclusive standing reflects the legislator's intent to promote broad civil enforcement and public accountability for AI systems circulating in the EU market, complementing the official supervisory powers of national authorities and the European AI Office. ## What This Means in Practice For individuals and civil society, Article 85 creates an accessible enforcement channel that does not require initiating costly litigation. A consumer who believes an AI-powered decision-making tool has been deployed without required transparency disclosures, or a researcher who identifies what appears to be a prohibited practice under Article 5, can formally alert the relevant market surveillance authority and expect the matter to be investigated. For businesses operating as providers, deployers, importers, or distributors of AI systems, Article 85 introduces a realistic risk of complaint-driven investigations triggered not only by direct competitors or regulators but by any third party — including journalists, advocacy groups, or affected communities. This widens the de facto enforcement surface considerably beyond the scope of routine supervisory inspections. Practically, companies should ensure that their AI systems comply with all applicable obligations before market deployment, because a single well-documented complaint can initiate a formal investigation leading to corrective measures, withdrawal orders, or financial penalties. Compliance programmes should include mechanisms for monitoring potential public concerns and channels for proactively engaging with market surveillance authorities if a potential non-compliance is self-identified. Member States must designate accessible points of contact and clear complaint submission procedures. Organisations deploying AI systems across multiple Member States should map the relevant market surveillance authorities in each jurisdiction and understand their procedural requirements. ## Key Obligations - **Right of access for all persons:** Any natural or legal person — not only those directly harmed — holds the right to submit a complaint, ensuring broad standing for civil enforcement. - **Authority diligence:** The market surveillance authority that receives a complaint must handle it with appropriate diligence, including conducting any investigation warranted by the facts alleged. - **Complainant information:** The authority must keep the complainant informed of the progress and outcome of the complaint, subject to limits imposed by the protection of the ongoing investigation. - **Operator accountability:** Providers, deployers, importers, distributors, and other relevant operators are subject to complaint-driven scrutiny and must be prepared to cooperate with investigations arising from complaints. - **Member State facilitation:** Member States must ensure that their designated market surveillance authorities have the procedural frameworks and resources necessary to receive and act on complaints effectively. ## Relationship to Other Articles Article 85 operates as part of the broader enforcement architecture of the EU AI Act and should be read alongside several related provisions. **Article 70** establishes the market surveillance authorities themselves and defines their powers. **Articles 74 to 84** detail the supervisory and corrective measures those authorities may apply following an investigation — including orders to withdraw or recall AI systems from the market — which are the ultimate outputs of a successful complaint procedure. **Article 99** sets out the penalties that authorities may impose on operators found to have infringed the Regulation, giving material force to complaints. **Article 85** concerns the right of affected persons to receive explanations for decisions taken by certain high-risk AI systems, a provision that may frequently underpin complaints submitted under Article 85. The complaint mechanism also complements **Article 93**, which grants persons subject to high-risk AI systems the right to lodge a complaint with the relevant deployer, creating a two-tier structure: internal recourse followed, where necessary, by escalation to the public authority under Article 85. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024**, following its publication in the Official Journal of the European Union. Application of the Regulation is phased: - **2 February 2025** — Prohibitions on unacceptable-risk AI practices (Article 5) became applicable. Complaints relating to potential breaches of these prohibitions could in principle be submitted from this date. - **2 August 2025** — Provisions on general-purpose AI models (Title VIII) and the governance framework, including the establishment of market surveillance authorities, became fully applicable. From this point, complaint mechanisms are fully operational for GPAI-related concerns. - **2 August 2028** — Most high-risk AI system obligations under Annex I become applicable. - **2 August 2028** — High-risk AI system obligations for systems covered by Annex I, point 1 (certain existing Union harmonisation legislation) become applicable. Article 85 itself, situated in **Title XII (Final Provisions)**, became applicable from **2 August 2026** alongside the main body of the Regulation. Organisations should already have internal processes in place to handle potential complaints and to cooperate with market surveillance investigations as these deadlines arrive. -------------------------------------------------------------------------------- ## Article 86 — Right to explanation of individual decision-making (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-86/ ## Official Text Summary Article 86 of Regulation (EU) 2024/1689 — the EU AI Act — establishes a right to explanation for natural persons who are subject to decisions made with the involvement of high-risk AI systems listed in Annex III. Where such a decision produces legal effects on a person, or similarly significantly affects them, that person has the right to obtain from the deployer a meaningful explanation of the role the AI system played in the decision-making procedure. The explanation must encompass, at minimum, the main parameters taken into account by the system and the weight those parameters carried in reaching the specific outcome affecting the individual. This obligation is placed on the deployer — the entity putting the high-risk AI system into use — rather than the provider who developed and placed the system on the market. The right is not absolute. Article 86 carves out situations in which the decision is necessary for entering into or performing a contract, is required or authorised under Union or Member State law, or rests on the explicit prior consent of the data subject. Even in these exempt situations, deployers are generally required to implement suitable safeguards, including making human review available and informing individuals of their ability to request such review. The article thus operates as a complementary instrument to the individual rights framework established under the GDPR, particularly Articles 13–15 and 22 of Regulation (EU) 2016/679, while being tailored to the specific context of AI-assisted decision-making. ## What This Means in Practice Article 86 has direct operational implications for any organisation deploying a high-risk AI system in a context where individual outcomes are at stake. Typical scenarios include AI-assisted credit scoring by financial institutions, AI-supported recruitment or candidate screening tools, AI systems used in benefits entitlement determinations by public authorities, and AI-driven risk classification in insurance underwriting. In each of these cases, the deployer must be capable of generating — on request — a sufficiently granular account of why a particular decision came out the way it did for a specific individual. A generic description of how the model works as a class is insufficient. The explanation must be individualised: it must reflect the actual parameters evaluated for that person and how each parameter contributed to the outcome. Practically, this requires deployers to maintain logging and audit trail capabilities at the individual inference level, not merely at the model level. Where the AI system is procured from a third-party provider, the deployer must ensure that the contractual and technical arrangements in place allow them to obtain and communicate the required information. Providers are correspondingly obligated under Article 13 (transparency) and Article 16 (obligations of providers) to supply deployers with the documentation necessary to meet this duty. Organisations should also review how Article 86 intersects with their existing GDPR Article 22 processes. Where automated decision-making triggers Article 22 GDPR rights, the EU AI Act explanation right may apply concurrently, and a consolidated response mechanism covering both frameworks will reduce compliance burden and improve the experience of affected individuals. ## Key Obligations - **Deployers** of high-risk AI systems listed in Annex III must provide, upon request, an individualised explanation of the main parameters of a decision produced with AI involvement and the relative weight of those parameters in the specific outcome. - Explanations must be **specific to the individual** concerned, not a generic description of the system's overall logic or training methodology. - Deployers must maintain **technical and documentary infrastructure** — including inference-level logs — sufficient to reconstruct and communicate the relevant decision parameters after the fact. - Deployers must inform affected persons of their **right to request explanation** and, where applicable, their right to request human review of a decision, in a clear and accessible manner. - Where exemptions apply (contractual necessity, legal obligation, explicit consent), deployers must still ensure **adequate safeguards** are in place, including a genuine human review mechanism. - Providers supplying high-risk AI systems to deployers must furnish sufficient **technical documentation and instructions** under Articles 13 and 16 to enable deployers to meet their Article 86 obligations downstream. ## Relationship to Other Articles Article 86 does not operate in isolation and must be read alongside several interconnected provisions of the EU AI Act and external instruments. Within the Regulation, Article 86 depends directly on the Annex III classification of high-risk AI systems; the right is triggered only where a system falls within that scope. It is closely linked to Article 13 (transparency and provision of information to deployers), Article 14 (human oversight requirements), Article 26 (obligations of deployers), and Article 72 (fundamental rights impact assessment obligations for certain public deployers). Externally, Article 86 is explicitly designed to complement GDPR Article 22, which restricts solely automated decisions producing significant effects on individuals, and GDPR Articles 13–15, which govern information rights. Where both instruments apply, the AI Act explanation right adds an AI-specific layer of granularity to the GDPR's existing transparency framework. Practitioners should also consider the interaction with the proposed AI Liability Directive, where explanation records may become material in establishing causation in damages claims arising from AI-assisted decisions. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024, twenty days after publication in the Official Journal of the European Union. Application is phased: - **February 2025**: Provisions on prohibited AI practices (Article 5) became applicable. - **August 2025**: Rules governing general-purpose AI models (Title VIII, Articles 51–56) and governance structures became applicable. - **August 2028**: Rules applicable to high-risk AI systems covered by existing Union harmonisation legislation (Annex I) began applying. - **December 2027 / August 2028**: The full high-risk AI system obligations under Title III — including deployer obligations under Article 26 and the Article 86 right to explanation — apply from **2 December 2027** for systems listed in Annex III, with a transitional period for certain high-risk systems already in service that extends to **2 August 2028**. Organisations deploying Annex III high-risk AI systems that are not yet compliant with Article 86 should treat December 2027 as a firm deadline and prioritise building explanation infrastructure and individual rights request workflows well in advance of that date. -------------------------------------------------------------------------------- ## Article 87 — Whistleblowing (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-87/ ## Official Text Summary Article 87 of Regulation (EU) 2024/1689 (the EU AI Act) establishes a whistleblower protection framework applicable to persons who report violations of the Regulation to competent national authorities or to relevant Union institutions, bodies, offices, or agencies. The article operates by reference to Directive (EU) 2019/1937 on the protection of persons who report breaches of Union law, extending that directive's safeguards expressly to the AI Act domain. Under Article 87, Member States must ensure that reporting persons — defined broadly to include employees, contractors, trainees, volunteers, and former workers who acquired relevant information in a work-related context — are protected from retaliation, discrimination, and adverse treatment as a consequence of having made a report in good faith. Providers, deployers, and other operators subject to the AI Act are therefore prohibited from taking retaliatory action against individuals who raise concerns about potential non-compliance. The article further requires that competent authorities receiving reports treat them in accordance with the procedural guarantees established under Directive 2019/1937, including obligations around confidentiality of the reporter's identity, acknowledgment of receipt, and timely follow-up. Where Union-level institutions receive reports, analogous protections under Union staff regulations and applicable Union law apply. Article 87 thereby integrates AI Act enforcement into the broader architecture of Union whistleblowing law rather than creating a parallel, sector-specific regime. ## What This Means in Practice Article 87 has direct operational implications for any organisation within scope of the EU AI Act — primarily providers placing AI systems on the Union market, deployers using high-risk AI systems, and operators of general-purpose AI models. **For organisations**, the practical obligation is to ensure that internal policies, employment contracts, codes of conduct, and supplier agreements do not contain clauses that could deter, penalise, or contractually prevent individuals from reporting AI Act violations to external authorities. Non-disclosure agreements and confidentiality clauses must be reviewed to confirm they do not purport to restrict lawful whistleblowing activity. Where an organisation already has an internal reporting channel mandated under Directive 2019/1937, that channel should be confirmed as covering AI Act-related concerns, and designated compliance owners should be trained to handle such reports. **For HR and legal teams**, this means updating grievance, disciplinary, and termination procedures to document that any adverse action taken against an employee who has made an AI-related report is entirely unrelated to that report — and to be able to demonstrate this in any subsequent regulatory or judicial review. **For competent national authorities**, Article 87 imposes a procedural duty to handle AI-related reports with the same confidentiality safeguards and acknowledgment timelines as other whistleblowing reports received under national transposition of Directive 2019/1937. **A concrete example**: an employee at a company deploying a high-risk AI system in recruitment notices that the system's outputs appear to discriminate on the basis of gender in violation of the Act's requirements. That employee reports the issue to the national market surveillance authority. Article 87 ensures they cannot lawfully be dismissed, demoted, or subjected to a hostile work environment as a result of that report. ## Key Obligations - **Member States must extend whistleblower protections** under Directive (EU) 2019/1937 to persons reporting violations of the EU AI Act, ensuring no gap exists between general whistleblowing law and AI-specific enforcement. - **Organisations subject to the AI Act must not retaliate** against employees, contractors, or other work-related persons who report, in good faith, suspected violations to competent authorities or Union bodies. - **Internal reporting channels** required under Directive 2019/1937 (applicable to organisations with 50 or more workers) must be understood to cover AI Act violations, and nominated responsible persons must be equipped to assess such reports. - **Competent authorities receiving reports** are required to maintain confidentiality of the reporting person's identity throughout the investigative process, disclosing it only where legally required and with prior notice to the reporter where possible. - **Contractual clauses** — including non-disclosure agreements, settlement agreements, and employment contracts — that purport to restrict or penalise external reporting of AI Act violations are unenforceable to the extent they conflict with Article 87 protections. - **Reporting persons acting in good faith** retain full protection even if the reported violation is ultimately not confirmed, provided the report was not made with knowledge of its falsity. ## Relationship to Other Articles Article 87 sits within Title IX (Post-Market Monitoring, Information Sharing, and Market Surveillance) and operates as a procedural enabler for the enforcement mechanisms established throughout that title and elsewhere in the Regulation. It connects directly to **Article 74** (market surveillance and control), **Article 75** (conformity of AI systems), and **Articles 78–84** (obligations of notified bodies and national competent authorities), since whistleblower reports may trigger or supplement the investigations those provisions authorise. It also supports **Article 87** (reporting of serious incidents), creating a complementary channel through which workers who observe incidents or near-misses can escalate concerns without fear of reprisal. More broadly, Article 87 should be read alongside **Article 4** (AI literacy) and **Article 9** (risk management systems for high-risk AI), because an organisation that fosters genuine internal transparency and AI competence is better placed both to detect reportable issues and to demonstrate that any adverse HR decision is wholly independent of a protected disclosure. It also interacts with **Recital 179** of the Regulation, which affirms the Union's commitment to ensuring that the Act's enforcement is not undermined by a chilling effect on legitimate reporting. ## Compliance Timeline The EU AI Act entered into force on **1 August 2024**, twenty days after publication in the Official Journal. Article 87, as part of the main body of the Regulation, becomes fully applicable on **2 December 2027** — the general application date for the majority of provisions, including those governing high-risk AI systems under Annex III (Article 113(2)). Unlike the prohibitions on unacceptable-risk AI practices, which became applicable on **2 February 2025**, or the obligations specific to general-purpose AI models, which applied from **2 August 2025**, Article 87 is not in an accelerated-application category. Its application aligns with the general two-year implementation period. However, organisations that are already subject to Directive (EU) 2019/1937 — which Member States were required to transpose by **17 December 2021** — should already have compliant reporting channels in place. The practical compliance task before August 2026 is therefore to **audit and extend existing channels** to confirm they explicitly cover AI Act violations, retrain responsible persons, and review contractual documentation accordingly. Organisations deploying high-risk AI systems covered by the August 2028 transitional provisions for certain Annex I systems should align their whistleblowing readiness with the applicable date for their specific system category. -------------------------------------------------------------------------------- ## Article 88 — Enforcement of the obligations of GPAI providers (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-88/ Article 88 settles who polices general-purpose AI models: the Commission, exclusively, acting through the AI Office. National authorities supervise AI systems; for the models underneath them, enforcement is centralised in Brussels. ## Official Text Summary The Commission has exclusive powers to supervise and enforce Chapter V of the Regulation — the obligations of providers of general-purpose AI models — and entrusts the implementation of those tasks to the AI Office, without prejudice to the Commission's organisational powers and the Member States' competences. National market surveillance authorities keep their full mandate over AI *systems*, including systems built on GPAI models; where they need action at model level for the performance of their own tasks, they may request the Commission to exercise its powers. The split is deliberate: systems are supervised where they are deployed, models are supervised once for the whole Union. ## Key Obligations - The Commission has exclusive powers to supervise and enforce Chapter V — the GPAI obligations — and entrusts their implementation to the AI Office - National market surveillance authorities may ask the Commission to exercise these powers where needed for their own tasks - Centralisation prevents 27 divergent readings of the same frontier model's obligations ## Compliance Timeline Applies from 2 August 2026; the 2026 Digital Omnibus deferred the substantive high-risk obligations (Annex III to 2 December 2027, Annex I to 2 August 2028) but did not move this provision. -------------------------------------------------------------------------------- ## Article 89 — Monitoring actions of the AI Office (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-89/ Article 89 gives the AI Office its watchtower: continuous monitoring of whether GPAI providers actually do what Chapter V requires — including whether they live by the codes of practice they signed. It also opens the door for downstream providers to complain upward. ## Official Text Summary The AI Office may take the actions necessary to monitor the effective implementation of and compliance with Chapter V by providers of general-purpose AI models, including their adherence to approved codes of practice. Downstream providers — companies building AI systems on top of a GPAI model — may lodge a complaint alleging an infringement of the Regulation by the upstream provider; a duly reasoned complaint gives the AI Office concrete, market-sourced signals to act on. What monitoring surfaces feeds the Section 5 escalation ladder: a request for documentation and information under Article 91, an evaluation under Article 92, and ultimately a request for measures under Article 93. ## Key Obligations - The AI Office may take the necessary actions to monitor effective implementation and compliance with Chapter V by GPAI providers, including their adherence to approved codes of practice - Downstream providers may lodge a complaint alleging an infringement by an upstream GPAI provider — the supply chain becomes an enforcement sensor - Monitoring findings feed the escalation ladder: documentation requests (Art. 91), evaluations (Art. 92), measures (Art. 93) ## Compliance Timeline Applies from 2 August 2026; the 2026 Digital Omnibus deferred the substantive high-risk obligations (Annex III to 2 December 2027, Annex I to 2 August 2028) but did not move this provision. -------------------------------------------------------------------------------- ## Article 9 — Risk management system (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-9/ ## Official Text Summary Article 9 of Regulation (EU) 2024/1689 imposes a mandatory, continuous risk management system on providers of high-risk AI systems throughout the entire system lifecycle. The provision requires that the risk management system consist of an iterative process integrated into the development and operation of the high-risk AI system, updated regularly in the light of new information gathered during post-market monitoring. Concretely, Article 9 requires providers to: (a) identify and analyse all known and reasonably foreseeable risks associated with the high-risk AI system; (b) estimate and evaluate risks that may materialise when the system is used in accordance with its intended purpose and under conditions of reasonably foreseeable misuse; (c) evaluate risks arising from available data and the behaviour of persons who interact with the system; and (d) adopt suitable risk management measures based on this analysis. Risk management measures must be such that any residual risk associated with each hazard, as well as the overall residual risk of the high-risk AI system, is judged to be acceptable. Article 9 also specifies that testing must be carried out to identify appropriate measures, and that such testing must be conducted against defined metrics and probabilistic thresholds. Special attention is required where the system is likely to interact with children or other vulnerable groups. Information arising from the experience of deployers is to be fed back into the system provider's risk management process. ## What This Means in Practice Article 9 is one of the most operationally demanding requirements in Title III of the EU AI Act. It applies to any legal entity that qualifies as a provider of a high-risk AI system — meaning the entity that develops the system or has it developed and places it on the market or puts it into service under its own name or trademark. In practical terms, compliance requires establishing a documented risk management framework before the system is placed on the market. This is not a checkbox exercise: the regulation requires an iterative process that persists for the life of the product, meaning risk management documentation must evolve as the system is updated, retrained, or deployed in new contexts. A compliant risk management system will typically include: a structured risk identification procedure covering both intended use and plausible misuse scenarios; a risk estimation matrix that evaluates probability and severity of harm; a catalogue of mitigation measures with documented rationale for their selection; formal pre-market testing against defined metrics; and a mechanism to absorb post-market feedback — including incident data provided by deployers — back into ongoing risk analysis. For example, a provider of an AI-based credit-scoring tool classified as high-risk under Annex III must document how the model could produce discriminatory outcomes, what technical and organisational measures reduce that risk, and how real-world performance data will trigger re-evaluation. An AI system used in a medical context must additionally address the heightened duty of care where vulnerable users are involved. Risk management outputs feed directly into the technical documentation required by Article 11 and the conformity assessment under Articles 43-44. ## Key Obligations - **Establish and maintain a continuous risk management system** that covers the entire lifecycle of the high-risk AI system, from design through decommissioning, updated in light of post-market monitoring data. - **Identify all known and reasonably foreseeable risks**, including risks arising from reasonably foreseeable misuse, from interaction with other systems, and from the sociotechnical context of deployment. - **Estimate and evaluate risks** with respect to their probability of occurrence and severity of potential harm, taking into account the intended purpose and the categories of persons likely to be affected, including vulnerable groups and children. - **Adopt risk management measures** that reduce identified risks to an acceptable residual level; where technical measures are insufficient, organisational or informational measures must supplement them. - **Conduct pre-market testing** using defined metrics and probabilistic thresholds appropriate to the intended purpose, to validate that selected measures are effective and that residual risk is acceptable. - **Integrate post-market monitoring feedback** from deployers and end-users into the ongoing risk management process, ensuring the system remains responsive to real-world evidence of harm or near-miss events. ## Relationship to Other Articles Article 9 sits at the centre of the Chapter 2 requirements framework and is structurally linked to several other provisions. It depends on Article 6 and Annex III for its scope: only systems qualifying as high-risk are subject to its obligations. The outputs of the Article 9 process directly feed Article 11 (technical documentation), which requires providers to demonstrate that a compliant risk management system exists and has been applied. Article 9 also connects tightly to Article 10 (data and data governance), since the quality of training, validation, and test data materially affects the risk profile that must be managed. Article 13 (transparency and provision of information) requires that certain risk-related information be communicated to deployers, and Article 14 (human oversight) specifies measures that frequently serve as first-line risk mitigation tools under Article 9. Article 26 places downstream obligations on deployers to monitor real-world use and report relevant information back to providers, closing the feedback loop that Article 9 requires. Finally, Article 72 (post-market monitoring) formalises the data-collection mechanisms that sustain the iterative risk management process over time. ## Compliance Timeline The EU AI Act entered into force on 1 August 2024. Article 9, as a core Chapter 2 requirement applicable to high-risk AI systems, follows the general compliance timeline for Title III obligations: - **1 August 2024** — Regulation enters into force; the 24-month transitional clock begins for most high-risk obligations. - **2 February 2025** — Prohibitions on unacceptable-risk AI practices (Article 5) become applicable. Article 9 does not yet apply. - **2 August 2025** — Rules on General-Purpose AI models (Title VIII) become applicable. Article 9 still not yet mandatory for most high-risk systems. - **2 December 2027** — Article 9 becomes fully applicable to high-risk AI systems listed in Annex III (AI systems in areas such as education, employment, essential services, law enforcement, migration, and administration of justice). Providers must have a compliant risk management system in place by this date. - **2 August 2028** — Extended deadline for high-risk AI systems that are safety components of products already covered by existing Union harmonisation legislation listed in Annex I (e.g. machinery, medical devices, civil aviation). Providers who are developing or procuring high-risk AI systems should treat 2 December 2027 as their hard deadline for Article 9 compliance readiness, building risk management frameworks into their development processes well in advance to allow time for testing, documentation, and conformity assessment. -------------------------------------------------------------------------------- ## Article 90 — Alerts of systemic risks by the scientific panel (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-90/ Article 90 wires an alarm bell straight from science to enforcement: the scientific panel of independent experts can formally alert the AI Office when it suspects a systemic risk — or a model that should have been designated and was not. ## Official Text Summary The scientific panel of independent experts established under Article 68 may provide a qualified alert to the AI Office where it has reason to suspect that a general-purpose AI model poses a concrete identifiable risk at Union level, or that a model meets the conditions for classification as a model with systemic risk under Article 51 without having been so classified. Upon such a qualified alert, the Commission, through the AI Office and after informing the Board, may exercise the powers of Section 5 — requesting documentation and information under Article 91, conducting evaluations under Article 92 and requesting measures under Article 93. The provider concerned is kept informed. The mechanism turns independent scientific expertise into a formal enforcement trigger rather than background advice. ## Key Obligations - The scientific panel may issue a qualified alert where it has reason to suspect a concrete identifiable risk at Union level from a GPAI model, or that a model meets the Article 51 systemic-risk conditions without having been classified - Upon a qualified alert, the Commission, through the AI Office, may exercise the Section 5 powers — documentation requests, evaluations, measures - The provider concerned is informed; the alert mechanism makes independent science a formal enforcement trigger, not just advice ## Compliance Timeline Applies from 2 August 2026; the 2026 Digital Omnibus deferred the substantive high-risk obligations (Annex III to 2 December 2027, Annex I to 2 August 2028) but did not move this provision. -------------------------------------------------------------------------------- ## Article 91 — Power to request documentation and information (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-91/ Article 91 is the first rung of the Commission's GPAI enforcement ladder: the power to demand the paperwork. The technical documentation of Articles 53 and 55 exists to be producible — this is the provision that calls the bluff. ## Official Text Summary The Commission may request a provider of a general-purpose AI model to supply the documentation drawn up in accordance with Articles 53 and 55, or any additional information necessary to assess the provider's compliance with the Regulation. The Board may also submit a reasoned request asking the Commission to trigger such a request where that is necessary for its tasks. Requests state the legal basis and purpose, specify what information is required and set a time limit; the provider, or its authorised representative, supplies the information. Supplying incorrect, incomplete or misleading information — or none — is independently finable under Article 101, separate from any underlying breach. ## Key Obligations - The Commission may request a GPAI provider to supply the documentation drawn up under Articles 53 and 55, or any additional information needed to assess compliance with the Regulation - The Board may also, upon reasoned request, ask the Commission to trigger such a request - Requests state a time limit; the provider — or its authorised representative — must supply the information, and inaccurate or incomplete answers are independently finable ## Compliance Timeline Applies from 2 August 2026; the 2026 Digital Omnibus deferred the substantive high-risk obligations (Annex III to 2 December 2027, Annex I to 2 August 2028) but did not move this provision. -------------------------------------------------------------------------------- ## Article 92 — Power to conduct evaluations (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-92/ Article 92 lets the Commission stop reading and start testing: where paperwork is not enough, the AI Office can evaluate a general-purpose AI model directly — including with model access and independent experts. ## Official Text Summary The Commission may conduct evaluations of a general-purpose AI model to assess the provider's compliance where the information gathered under Article 91 is insufficient, or to investigate systemic risks at Union level — in particular following a qualified alert from the scientific panel under Article 90. The Commission may appoint independent experts, including from the scientific panel, to carry out evaluations on its behalf, and may request access to the model through APIs or other appropriate technical means and tools, including source code. Access requests respect protective conditions for trade secrets; and it is the finding of a serious and substantiated concern here that unlocks the Article 93 power to request measures. ## Key Obligations - The Commission may evaluate a GPAI model where the Article 91 information is insufficient, or following a qualified alert from the scientific panel under Article 90 - Evaluations may involve independent experts, including from the scientific panel - The Commission may request access to the model through APIs or other appropriate technical means, including source code; a serious and substantiated concern found here is the express precondition for measures under Article 93 ## Compliance Timeline Applies from 2 August 2026; the 2026 Digital Omnibus deferred the substantive high-risk obligations (Annex III to 2 December 2027, Annex I to 2 August 2028) but did not move this provision. -------------------------------------------------------------------------------- ## Article 93 — Power to request measures (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-93/ ## Official Text Summary Article 93 of Regulation (EU) 2024/1689 (the EU AI Act) sits in Chapter IX, Section 5 — the section that gives the Commission, acting through the AI Office, exclusive supervisory powers over providers of general-purpose AI (GPAI) models. Within that section it is the third and most consequential rung of an escalating enforcement ladder: Article 91 lets the Commission request documentation and information, Article 92 lets it conduct evaluations of a model, and Article 93 lets it demand that the provider actually *do something* about what those steps reveal. Unlike the market-surveillance powers elsewhere in Chapter IX, these powers are not exercised by national authorities: for GPAI models, the Commission is the single enforcer across the Union. Article 93(1) authorises the Commission, where necessary and appropriate, to request a provider to do one of three things: **(a)** take appropriate measures to comply with the provider obligations set out in Articles 53 and 54; **(b)** implement mitigation measures, where an evaluation carried out under Article 92 has given rise to serious and substantiated concern of a systemic risk at Union level; or **(c)** restrict the making available on the market of the model, or withdraw or recall it. The three limbs form their own internal escalation, from ordinary compliance through targeted mitigation to removal of the model from the Union market. The two remaining paragraphs build in de-escalation. Under Article 93(2), before any measure is requested, the AI Office may open a structured dialogue with the provider. Under Article 93(3), if a provider of a GPAI model with systemic risk offers commitments to implement mitigation measures, the Commission may by decision make those commitments binding on the provider and declare that there are no further grounds for action — closing the procedure without a formal measure ever being imposed. ## What This Means in Practice Formally, limb (a) reaches any GPAI model provider that falls short of its Article 53 obligations (technical documentation, information to downstream providers, copyright policy, training-content summary) or Article 54 (authorised representative for non-EU providers). In practice, the centre of gravity is the small group of providers whose models are classified as carrying **systemic risk** under Articles 51 and 52 — the presumption threshold being training compute above 10²⁵ FLOPs — because the mitigation and recall limbs are tied to systemic-risk findings from Article 92 evaluations. For those providers, Article 93 is where supervision acquires teeth. A documentation request is an administrative burden; an evaluation is scrutiny; a request for measures is an order with a fining mechanism behind it. Refusal exposes the provider to fines under Article 101 of up to **3% of worldwide annual turnover or €15 million**, whichever is higher — and non-compliance with the request is a fining ground of its own, independent of the underlying breach. The limb with the widest blast radius is **(c)**. A restriction, withdrawal or recall of a frontier model is existential for its provider, but it does not stop there: every downstream AI system built on that model inherits the disruption. An organisation that has integrated a systemic-risk model into its products has, in effect, a regulatory dependency it does not control. Prudent downstream providers and deployers therefore track the regulatory standing of their upstream model and address the recall scenario contractually — continuity commitments, migration assistance, notification duties. The commitments mechanism in Article 93(3) will do much of the real work. It mirrors the commitments decisions of EU competition law: the provider offers a package of mitigations, the Commission makes it binding, and both sides avoid a contested measure. A worked example: an Article 92 evaluation of a frontier model raises serious and substantiated concern that its capabilities could meaningfully assist the creation of biological threats. The AI Office opens a structured dialogue; the provider offers staged access controls, enhanced refusal training and third-party red-teaming on a defined timetable; the Commission makes those commitments binding and closes the file. No recall, but an enforceable safety upgrade. ## Key Obligations - **Respond to a request for measures within its terms.** An Article 93(1) request is not advisory; ignoring it is independently finable under Article 101. - **Keep the underlying Article 53 and 54 obligations demonstrably met** — technical documentation, downstream information, copyright policy, training-content summary, and an authorised representative where required — since limb (a) converts any persistent gap into an enforceable order. - **For systemic-risk providers, maintain the Article 55 apparatus** (model evaluations, adversarial testing, incident reporting, cybersecurity): these are the measures a mitigation request will in practice demand more of. - **Engage with the structured dialogue.** Article 93(2) exists to resolve concerns before formal measures; treating it as adversarial discovery wastes the cheapest exit. - **Consider commitments early.** A well-designed Article 93(3) commitments package closes the procedure with a declaration that no further grounds for action exist. - **Downstream operators:** no direct Article 93 duty, but real exposure to limb (c) — monitor the upstream model's standing and provide for restriction, withdrawal or recall in contracts. ## Relationship to Other Articles Article 93 completes the enforcement chain of Chapter IX, Section 5. **Article 88** establishes the Commission's exclusive enforcement competence for GPAI providers; **Article 89** provides monitoring; **Article 90** channels alerts of systemic risk from the scientific panel — often the trigger for everything that follows. **Article 91** (documentation and information) and **Article 92** (evaluations) are the investigative rungs immediately below Article 93, and an Article 92 finding of serious and substantiated concern is the express precondition for a mitigation request under 93(1)(b). **Article 94** guarantees the procedural rights of the economic operators concerned. The substantive obligations that a request enforces live in **Articles 53 and 54** (all GPAI providers) and **Article 55** (providers of models with systemic risk), with classification and designation governed by **Articles 51 and 52**. Adherence to a code of practice under **Article 56** is the practical way a provider demonstrates compliance — and therefore the cheapest insurance against ever receiving a request. The fining backstop is **Article 101**. For the wider context of GPAI regulation, see the [GPAI hub](/gpai/); for penalty exposure across the Act, see [Article 99](/articles/article-99/). ## Compliance Timeline The Regulation entered into force on **1 August 2024**. The substantive GPAI obligations that Article 93 enforces — Articles 53 to 55 — have applied since **2 August 2025**. The Commission's enforcement powers under Chapter IX, Section 5, including the power to request measures, apply from **2 August 2026**, together with the Article 101 fining power over GPAI providers. The 2026 Digital Omnibus did not touch this track: it deferred the high-risk obligations of Annex III and Annex I to 2 December 2027 and 2 August 2028 respectively, but left the GPAI framework and its enforcement dates intact. For providers of systemic-risk models, the practical preparation is straightforward to state and demanding to do: keep Articles 53–55 evidence current, adhere to a code of practice, rehearse the structured-dialogue scenario, and have a commitments strategy ready before the AI Office ever calls. -------------------------------------------------------------------------------- ## Article 94 — Procedural rights of GPAI economic operators (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-94/ Article 94 is the shortest article in the enforcement section and carries the rule of law into it: GPAI providers subject to the Commission's Section 5 powers keep the procedural rights of Regulation (EU) 2019/1020 — applied mutatis mutandis. ## Official Text Summary Article 18 of Regulation (EU) 2019/1020 — the horizontal Market Surveillance Regulation — applies mutatis mutandis to providers of general-purpose AI models, without prejudice to the more specific procedural rights provided in the AI Act itself. In substance that means the enforcement powers of Section 5 operate inside classic administrative-law guarantees: measures must state the exact grounds on which they are based, the provider must be given the opportunity to be heard within a reasonable period before adverse measures are adopted, and the remedies available under national and Union law must be communicated. Urgency can compress the hearing — it cannot abolish it: the operator must then be heard as soon as possible afterwards. ## Key Obligations - Article 18 of Regulation (EU) 2019/1020 — the Market Surveillance Regulation — applies mutatis mutandis to providers of general-purpose AI models - In substance: the right to be heard before adverse measures, reasoned decisions, and available remedies - These guarantees operate without prejudice to the more specific procedural rights in the AI Act itself, such as those built into Articles 92 and 93 ## Compliance Timeline Applies from 2 August 2026; the 2026 Digital Omnibus deferred the substantive high-risk obligations (Annex III to 2 December 2027, Annex I to 2 August 2028) but did not move this provision. -------------------------------------------------------------------------------- ## Article 95 — Codes of conduct for voluntary application of specific requirements (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-95/ ## Official Text Summary Article 95 of Regulation (EU) 2024/1689 (the EU AI Act), situated within Title X (Codes of Conduct and Guidelines), establishes a voluntary framework through which providers of AI systems that are not classified as high-risk may choose to commit to requirements that go beyond their legal baseline. Specifically, Article 95 invites providers of non-high-risk AI systems to draw up codes of conduct intended to extend, on a voluntary basis, the application of requirements set out in Title III, Chapter 2 — the mandatory obligations that apply to high-risk AI systems. These requirements include risk management systems, data governance and management practices, technical documentation, record-keeping, transparency and provision of information to deployers, human oversight measures, accuracy, robustness, and cybersecurity. Article 95 also expressly encourages codes of conduct to address the environmental sustainability of AI systems. The elaboration of such codes of conduct may involve providers, deployers, representative organisations, and other relevant stakeholders including civil society and academia. The AI Office and national competent authorities are tasked with facilitating this process. The Commission is empowered to issue guidelines on the form, content, and processes associated with codes of conduct under this article. Existing voluntary commitments and industry self-regulatory frameworks may be taken into account when drawing up codes of conduct under Article 95, avoiding unnecessary duplication of effort. ## What This Means in Practice Article 95 creates a space for responsible AI actors to signal trustworthiness by voluntarily aligning with the higher standards applicable to high-risk AI — even when they are not legally required to do so. For providers of limited-risk or minimal-risk AI systems, this means that rather than simply meeting the lighter-touch obligations that apply to their products (for example, transparency notices for chatbots under Article 50), they can elect to implement a full risk management system, conduct data governance audits, maintain technical documentation, and build in human oversight mechanisms — and formalise that commitment through a publicly stated code of conduct. In practice, participation in a code of conduct under Article 95 may serve multiple strategic functions. It can differentiate a product in a competitive market where enterprise customers or public-sector procurement teams demand demonstrable trustworthiness. It can build the internal processes and documentation habits that ease future compliance if a product is later reclassified as high-risk. It can also strengthen the organisation's position in dialogues with regulators and in the context of incident investigations. A practical example: a provider of an AI-powered recruitment screening tool that falls just below the high-risk threshold in Annex III may nonetheless adopt a code of conduct committing to bias testing, transparent model documentation, and periodic human review of algorithmic decisions — measures that build user trust and anticipate regulatory evolution. Codes of conduct are expected to be specific, measurable, and publicly accessible. Organisations should treat them not as marketing instruments but as operational commitments subject to genuine internal governance. ## Key Obligations - **Voluntary adoption**: Providers of non-high-risk AI systems are invited but not required to draw up and apply codes of conduct that extend Title III Chapter 2 requirements to their systems. - **Scope of voluntary requirements**: Codes of conduct may cover risk management, data governance, technical documentation, transparency, human oversight, accuracy, robustness, cybersecurity, and environmental sustainability of AI systems. - **Inclusive drafting process**: Codes of conduct should be elaborated with input from providers, deployers, representative organisations, and relevant stakeholders including civil society and academia, with facilitation by the AI Office and national competent authorities. - **Compatibility with existing frameworks**: Codes may build upon existing voluntary commitments or self-regulatory industry initiatives to avoid duplication, provided those frameworks are compatible with the objectives of the Regulation. - **Commission guidelines**: The European Commission may issue guidelines specifying the expected form, content, and processes for codes of conduct under this article, providing a reference framework for interested parties. - **Environmental sustainability**: Codes of conduct are expressly encouraged to include provisions promoting the environmental sustainability of AI systems throughout their lifecycle, reflecting the broader policy objectives of the Regulation. ## Relationship to Other Articles Article 95 should be read alongside the mandatory transparency obligations of **Article 50**, which represent the actual legal floor for many non-high-risk AI systems. It draws its substantive content by reference from **Title III, Chapter 2 (Articles 9–15)**, which sets out the requirements — risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy, robustness, and cybersecurity — that high-risk AI system providers must meet and that non-high-risk providers may voluntarily adopt. Article 95 is complemented by **Article 96**, which empowers the Commission to issue guidelines on the practical implementation of this article. It also connects to **Article 56**, which establishes the AI Office as a facilitating body, and to the broader scheme of **Article 55** concerning general-purpose AI model codes of practice, which operates as a parallel but distinct voluntary framework for a different category of actors. Together, these provisions reflect the Regulation's layered approach: mandatory floors, voluntary ceilings, and institutional facilitation. ## Compliance Timeline Article 95 entered into application as part of the general application date of the EU AI Act. The Regulation entered into force on 1 August 2024, twenty days after its publication in the Official Journal. Application of the Regulation's provisions is phased: - **1 February 2025**: Prohibitions on unacceptable-risk AI practices (Title II) became applicable. - **2 August 2025**: Provisions relating to general-purpose AI models (Title VIII) and governance structures (Title III of the governance chapter) became applicable. - **2 August 2028**: The majority of the Regulation's provisions, including obligations for high-risk AI systems under Annex I (product safety legislation), became applicable. - **2 December 2027**: Obligations for high-risk AI systems listed in Annex III became fully applicable. Article 95, falling under Title X, became applicable on **2 August 2026** as part of the general application of the Regulation. However, given its voluntary nature, providers wishing to use codes of conduct as a compliance and trust-building tool are encouraged to engage with the process as early as possible — particularly since the AI Office may begin facilitating code elaboration well ahead of formal deadlines, and early movers benefit from shaping the content of those codes. -------------------------------------------------------------------------------- ## Article 96 — Guidelines from the Commission on the implementation of this Regulation (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-96/ ## Official Text Summary Article 96 of Regulation (EU) 2024/1689 (the EU AI Act) mandates the European Commission to issue guidelines on the practical implementation of the Regulation. These guidelines must be published no later than 2 August 2026, two years after the Regulation's entry into force. The article specifies a non-exhaustive list of subject matters the guidelines shall address. These include: the practical application of the requirements imposed on high-risk AI systems listed in Annex III; the correct application of the definition of an AI system under Article 3(1) and its boundaries relative to conventional software; the interaction and articulation between the EU AI Act and other applicable Union law, notably sectoral legislation in areas such as financial services, healthcare, and employment; and the scope and application of the prohibited AI practices enumerated in Article 5. Article 96 further directs the Commission to pay particular attention to the needs of small and medium-sized enterprises, including start-ups, when drafting these guidelines. This reflects the Regulation's broader objective, expressed in Recital 9 and Article 62, of reducing disproportionate compliance burdens on smaller operators. The Commission may update the guidelines over time to reflect evolving technology, market practice, and enforcement experience, ensuring that the interpretive framework remains aligned with the Regulation's objectives throughout its phased implementation. ## What This Means in Practice For providers and deployers of AI systems operating in the EU, Article 96 creates an important practical resource: official interpretive guidance from the institution responsible for proposing and overseeing the Regulation. While the guidelines are not legally binding, they represent the Commission's authoritative view on how the Regulation should be read and applied, and national competent authorities are likely to refer to them when conducting market surveillance and enforcement. **For AI system providers**, the guidelines will clarify the boundary between high-risk and non-high-risk classification under Annex III — one of the most contested interpretive questions in the Regulation. They will also provide practical examples of what constitutes a prohibited practice under Article 5, reducing legal uncertainty around edge cases such as subliminal manipulation or real-time biometric categorisation. **For deployers** operating in regulated sectors such as banking, insurance, or healthcare, the guidelines will map the relationship between the AI Act's requirements and existing sectoral obligations, helping compliance teams avoid duplication and identify where the AI Act imposes obligations beyond what sector-specific law already requires. **For SMEs and start-ups**, the guidelines are particularly valuable. Article 96 requires the Commission to specifically consider their needs, which in practice should mean simplified explanations, worked examples, and tools (such as checklists or decision trees) that reduce the cost of legal interpretation. Compliance teams should monitor the Commission's AI Office and Official Journal for the publication of guidelines and treat them as primary reference documents when building or reviewing their AI governance frameworks. ## Key Obligations - The European Commission must issue guidelines on the practical implementation of the EU AI Act no later than 2 August 2026. - The guidelines must specifically address the practical application of requirements for high-risk AI systems falling under Annex III. - The guidelines must clarify the definition and scope of "AI system" under Article 3(1), including how it distinguishes AI systems from conventional software. - The guidelines must address the interaction between the EU AI Act and other applicable Union legal frameworks, including sectoral legislation. - The guidelines must address the application of the prohibited AI practices set out in Article 5. - When drafting the guidelines, the Commission must give particular consideration to the needs of small and medium-sized enterprises and start-ups to facilitate their compliance. ## Relationship to Other Articles Article 96 functions as an implementation support mechanism across the entire Regulation and therefore has connections to a wide range of provisions. Its most direct links are to Article 3(1) (definition of AI system), Article 5 (prohibited practices), Annex III (high-risk AI system classifications), and Articles 8–15 (requirements for high-risk AI systems) — these being the substantive areas the guidelines must cover as a minimum. Article 96 also connects to Article 62, which addresses measures in favour of SMEs and start-ups, and to Article 95, which governs voluntary codes of conduct — both being part of the broader framework of non-binding compliance support tools. More broadly, Article 96 should be read alongside the governance architecture established under Title VII and Title VIII, particularly the role of the European AI Office (Article 64) and the AI Board (Article 65), since these bodies contribute to ensuring consistent interpretation and implementation across Member States. The guidelines issued under Article 96 complement, but do not replace, the technical standards and harmonised standards referenced in Article 40. ## Compliance Timeline Article 96 sits within the broader phased application schedule of Regulation (EU) 2024/1689: - **1 August 2024** — The Regulation entered into force, triggering the start of all internal preparation obligations. - **2 February 2025** — Prohibited AI practices under Article 5 became applicable. The Article 96 guidelines, when published, will retrospectively clarify the scope of these prohibitions, but operators must already be compliant. - **2 August 2025** — Rules on general-purpose AI (GPAI) models under Title III, Chapter 5 became applicable, including transparency and systemic risk obligations. - **2 August 2026** — Deadline by which the Commission must publish the Article 96 guidelines. This date also marks the application of Articles on notified bodies and national competent authorities. Compliance teams should incorporate the guidelines into their governance frameworks as soon as they are published. - **2 December 2027** — High-risk AI systems listed in Annex III (excluding those covered by existing Union harmonisation legislation) become subject to the full requirements of Title III, Chapter 2. - **2 August 2028** — High-risk AI systems covered by Union harmonisation legislation listed in Annex I become fully subject to the Regulation. Operators should not wait for the Article 96 guidelines before beginning compliance work, as most substantive obligations apply on earlier dates. The guidelines will serve as a tool to refine and validate existing compliance programmes rather than as a starting point. -------------------------------------------------------------------------------- ## Article 97 — Exercise of the delegation (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-97/ ## Official Text Summary Article 97 of Regulation (EU) 2024/1689 (the EU AI Act) falls within Title XI, which governs delegation of legislative power and committee procedures. It establishes the conditions governing the exercise of delegated powers conferred on the European Commission throughout the Regulation. The article specifies that the Commission's power to adopt delegated acts is granted for a five-year period from 1 August 2024 and is automatically renewable for identical periods unless either the European Parliament or the Council objects no later than three months before the end of each period. Either the European Parliament or the Council may revoke the delegation at any time. A revocation decision terminates the delegation identified therein and takes effect the day following its publication in the Official Journal of the European Union, or on a later date specified in the decision. It does not affect the validity of any delegated acts already in force. Before adopting any delegated act, the Commission is required to consult experts designated by each Member State, consistent with the principles of the Interinstitutional Agreement of 13 April 2016 on Better Law-Making. The delegated act is notified simultaneously to the European Parliament and the Council, and enters into force only if neither institution raises an objection within three months of notification — a period that may be extended by three months at either institution's initiative. If both institutions inform the Commission they will not object, the act may enter into force earlier. ## What This Means in Practice Article 97 is primarily an institutional and procedural provision rather than one that creates direct compliance obligations for AI system providers, deployers, or operators. However, it is essential for practitioners and legal teams to understand because it determines the mechanism by which the Commission may update, supplement, or refine key aspects of the EU AI Act through delegated legislation — without requiring the full legislative process. In concrete terms, this means that certain technical or detailed provisions of the Regulation — such as updates to Annexes defining high-risk AI system categories, or changes to the conformity assessment procedures — may be modified by the Commission through delegated acts. These acts are legally binding and directly applicable across all EU Member States once they enter into force. For compliance teams, the practical implication is that the regulatory landscape under the EU AI Act is not static. Organisations that have mapped their AI systems against current Annex definitions or conformity requirements must maintain ongoing monitoring processes to detect when delegated acts are adopted that alter those requirements. Legal and compliance officers should subscribe to the Official Journal of the European Union and track European Parliament and Council scrutiny periods. The three-month objection window — potentially extended to six months — defines the earliest possible date on which new obligations derived from delegated acts could take effect. Building this lead time into internal compliance calendars is good practice. For Member State-designated experts participating in Commission consultations, Article 97 formally anchors their role in the pre-adoption phase of delegated acts. ## Key Obligations - **Five-year renewable delegation:** The Commission holds delegated powers from 1 August 2024 for five years, renewable automatically unless opposed by the European Parliament or Council within three months of period end. - **Revocation at any time:** The European Parliament or the Council may revoke the delegation of power at any point; revocation takes effect the day after publication in the Official Journal or on a specified later date. - **Member State expert consultation:** Prior to adopting any delegated act, the Commission must consult Member State-designated experts in accordance with the 2016 Interinstitutional Agreement on Better Law-Making. - **Simultaneous notification:** Each delegated act must be notified simultaneously to the European Parliament and the Council as soon as it is adopted. - **Three-month scrutiny and objection period:** A delegated act enters into force only after a three-month period (extendable by a further three months) during which neither institution raises an objection — or earlier if both institutions confirm they will not object. - **Preservation of existing delegated acts:** A decision to revoke the delegation does not affect the validity of delegated acts that have already entered into force under the Regulation. ## Relationship to Other Articles Article 97 must be read in conjunction with all provisions of the EU AI Act that expressly confer delegated power on the Commission. These include, in particular, Article 6 (classification rules for high-risk AI systems and amendments to Annexes I and III), Article 96 (guidelines on the application of the Regulation), and Article 98 (committee procedure for implementing acts). Together, Articles 97 and 98 form the procedural backbone of Title XI, delineating the boundary between delegated acts — which allow the Commission to supplement or amend non-essential elements of the Regulation — and implementing acts, which govern execution of specific uniform conditions. Article 97 also interacts with the transparency and governance framework established in Title IX (Articles 64–70) insofar as the composition and functioning of the AI Office and European Artificial Intelligence Board may inform the expert consultations required before delegated acts are adopted. Practitioners should read Article 97 alongside the specific substantive articles that trigger delegated act procedures to understand the full scope of potential regulatory change. ## Compliance Timeline Article 97 entered into force on 1 August 2024, the date of the EU AI Act's entry into force, and the five-year delegation period runs from that date. The broader EU AI Act applies in phases: - **2 February 2025** — Prohibitions on unacceptable-risk AI practices (Title II) became applicable. - **2 August 2025** — Rules on general-purpose AI (GPAI) models (Title III, Chapter V) and governance provisions became applicable. - **2 August 2026** — Most remaining provisions of the Regulation become applicable, including the Article 50 transparency obligations. - **2 December 2027** — Obligations for stand-alone high-risk AI systems listed in Annex III (excluding those in Annex I) become applicable. - **2 August 2028** — High-risk AI systems governed by existing sectoral Union harmonisation legislation (Annex I) must comply. Because Article 97 enables the Commission to amend Annexes and other non-essential elements via delegated acts, any delegated act adopted and entering into force before these milestones could alter the scope of obligations that apply at each phase. Compliance teams should treat the delegated act scrutiny calendar as a live variable within their phased compliance programmes, particularly with respect to Annex I and Annex III classifications. -------------------------------------------------------------------------------- ## Article 98 — Committee procedure (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-98/ ## Official Text Summary Article 98 of Regulation (EU) 2024/1689 (the EU AI Act) is a procedural provision located in Title XI, which governs delegation of power and committee procedure. It establishes that the European Commission shall be assisted by a committee within the meaning of Regulation (EU) No 182/2011 of the European Parliament and of the Council of 16 February 2011 laying down the rules and general principles concerning mechanisms for control by Member States of the Commission's exercise of implementing powers (the Comitology Regulation). Where reference is made to this paragraph, Article 5 of Regulation (EU) No 182/2011 applies — meaning the examination procedure governs the adoption of relevant implementing acts. Under the examination procedure, the committee must deliver an opinion by qualified majority. Where the committee delivers a positive opinion, the Commission may adopt the implementing act. Where the committee delivers a negative opinion, the Commission may not adopt the act, although it may submit a revised proposal to the committee or refer the matter to the appeal committee. Where no opinion is delivered, the Commission may adopt the implementing act unless a simple majority of committee members opposes it. This provision reflects standard EU institutional practice for delegating technical implementing power to the Commission while maintaining structured Member State oversight. It ensures that technically complex or politically significant implementing measures taken under the EU AI Act — such as those relating to classification of high-risk systems, common specifications, or harmonised standards — are subject to democratic scrutiny before becoming binding. ## What This Means in Practice Article 98 operates primarily at the institutional level and does not directly impose obligations on AI developers, providers, deployers, or national competent authorities in their day-to-day compliance work. However, it has significant indirect effects on how the regulatory framework evolves and becomes binding in practice. When the Commission needs to adopt implementing acts under the EU AI Act — for example, to establish or update the list of high-risk AI systems in Annex III, to adopt common specifications for high-risk AI systems where harmonised standards are absent or insufficient, or to specify formats for EU declarations of conformity — it must follow the committee procedure established in Article 98. This means proposals are reviewed by a standing committee of Member State representatives before adoption, introducing a layer of collective oversight. For compliance professionals and legal teams, this matters because it determines how quickly and under what conditions binding technical requirements can be updated or clarified. If the Commission wishes to add a new category of high-risk AI system or refine technical requirements via implementing act, the committee procedure governs the timeline and political feasibility of that change. For policy stakeholders and industry associations, the committee procedure is a key lever for influencing secondary legislation under the AI Act. Member State representatives on the committee can block or modify implementing acts that are disproportionate or technically unsound, providing a safeguard against overly prescriptive or poorly calibrated technical rules. Practically, operators should monitor Commission implementing acts adopted under the AI Act and track whether they passed through the committee procedure smoothly or faced opposition, as this signals the political durability of the resulting rules. ## Key Obligations - The European Commission must submit draft implementing acts to the committee before adoption, ensuring Member State review and input at the technical and political level. - The committee operates under the examination procedure (Article 5 of Regulation (EU) No 182/2011), requiring a qualified majority opinion from Member State representatives for the Commission to proceed with adoption. - Where the committee issues a negative opinion, the Commission is generally prevented from adopting the implementing act in its submitted form and must revise or escalate the proposal. - Where no opinion is delivered and a simple majority of committee members opposes the act, the Commission must refrain from adopting it. - The Commission must act in accordance with the procedural rules of Regulation (EU) No 182/2011 in all exercises of implementing powers where Article 98 is invoked, maintaining institutional accountability and transparency. - Member States retain collective oversight over the technical and administrative shape of the EU AI Act's implementing framework through their participation in the committee. ## Relationship to Other Articles Article 98 sits within Title XI alongside Article 97, which governs the exercise of the delegation of power (the delegated acts procedure), and must be read in conjunction with the specific substantive provisions of the AI Act that expressly grant the Commission implementing powers. Key articles that trigger the committee procedure include Article 7 (updating the list of high-risk AI systems in Annex III), Article 14 and Article 15 (implementing acts on human oversight and accuracy requirements), Article 41 (common specifications for high-risk AI systems), and Article 51 (registration obligations). Each of these provisions, where they empower the Commission to act via implementing act rather than delegated act, routes through the Article 98 procedure. Article 98 should also be read alongside Recitals explaining the institutional design choices of the AI Act, and in the broader context of Regulation (EU) No 182/2011, which remains the governing framework for how the committee operates, votes, and resolves disagreements. The distinction between delegated acts (Article 97) and implementing acts (Article 98) is constitutionally significant under EU law and determines the scope of Member State and Parliamentary oversight. ## Compliance Timeline Article 98 entered into force on 1 August 2024, the twentieth day after publication of Regulation (EU) 2024/1689 in the Official Journal of the European Union. As an institutional procedural provision, it applies immediately and continuously from that date, since the Commission's need to adopt implementing acts arose from the moment the Regulation entered force. The relevance of Article 98 intensifies as the AI Act's phased application schedule triggers substantive obligations: prohibited AI practices became applicable from 2 February 2025; GPAI model obligations apply from 2 August 2025; obligations for high-risk AI systems under Annex III apply from 2 December 2027 (with a further extension to 2 August 2028 for certain systems already subject to conformity assessment under other Union law). Each of these application milestones is accompanied by implementing acts that the Commission must adopt in advance — all routed through the Article 98 committee procedure. Compliance teams should track the Commission's work programme for AI Act implementing acts to anticipate how Article 98 will shape the timing and content of binding technical requirements across the phased rollout. -------------------------------------------------------------------------------- ## Article 99 — Penalties (EU AI Act) URL: https://www.regulation-ai.eu/en/articles/article-99/ ## Official Text Summary Article 99 of Regulation (EU) 2024/1689 establishes the administrative penalty framework for infringements of the EU AI Act. It sets out a three-tier structure of fines calibrated to the severity of the breach. The most serious infringements — violations of the prohibited AI practices listed in Article 5 — attract fines of up to **€35 million or 7% of total worldwide annual turnover**, whichever is higher. Violations of other obligations imposed on providers, deployers, importers, and distributors — including those relating to high-risk AI systems, transparency obligations, and GPAI models — are subject to fines of up to **€15 million or 3% of worldwide annual turnover**. Supplying incorrect, incomplete, or misleading information to notified bodies or national competent authorities is penalised at up to **€7.5 million or 1% of worldwide annual turnover**. For GPAI model providers, Article 99(3) cross-references the fine thresholds that apply to obligations under Chapter V (Articles 53–56), including systemic-risk obligations for providers of GPAI models with systemic risk. When the offending party is an SME or startup, the percentage-of-turnover ceiling applies where it produces a lower absolute figure than the fixed amount ceiling. National competent authorities are responsible for imposing and enforcing fines within their jurisdiction, while the AI Office holds enforcement competence over GPAI model providers at Union level. --- ## What This Means in Practice Article 99 is the enforcement backbone of the EU AI Act. Its tiered structure directly shapes how organisations should prioritise their compliance programmes. **For providers of high-risk AI systems**, the 3%/€15 million tier applies to failures such as inadequate conformity assessments, missing technical documentation, non-compliant quality management systems, or failure to register systems in the EU database under Article 71. A medical device manufacturer deploying an AI-assisted diagnostic tool without completing the required conformity assessment under Annex VI, for example, faces exposure in this tier. **For any operator deploying prohibited AI applications** — such as real-time biometric identification in public spaces outside the narrow exceptions, social scoring by public authorities, or subliminal manipulation techniques — the 7%/€35 million tier applies. These are the Act's hard prohibitions, and the penalty level signals that no business justification can offset a violation. **For GPAI model developers and deployers**, fines under the 3% tier attach to failures around technical documentation, copyright transparency, and — for systemic-risk models — incident reporting and adversarial testing obligations. **For all operators**, misinforming regulators during market surveillance investigations triggers the 1% tier. This is operationally significant: it means internal document management, audit trails, and cooperation protocols with authorities must be robust before regulators come knocking. Proportionality factors — including the duration of infringement, degree of cooperation, and prior violations — guide authorities in setting the actual fine within the applicable ceiling. --- ## Key Obligations - **Avoid prohibited practices (Article 5)**: Any deployment or placing on the market of AI systems that engage in practices listed in Article 5 — including real-time remote biometric identification in publicly accessible spaces (outside listed exceptions), social scoring, subliminal manipulation, and exploitation of vulnerabilities — exposes the operator to the highest penalty tier. - **Fulfil provider obligations for high-risk AI systems**: Providers must maintain conformity assessments, technical documentation, quality management systems, and post-market monitoring. Failures in any of these areas are subject to the mid-tier fine. - **Comply with GPAI model obligations (Chapter V)**: Providers of general-purpose AI models must meet transparency, documentation, and copyright policy obligations; providers of GPAI models with systemic risk face additional requirements around incident reporting, model evaluations, and cybersecurity measures. - **Provide accurate information to authorities**: All operators must cooperate with national market surveillance authorities and the AI Office, and must not supply incorrect or misleading information during investigations or conformity procedures. - **Ensure SME-proportionate compliance**: While SMEs benefit from proportionality consideration in fine-setting, they are not exempt from substantive obligations — they must still comply with applicable requirements and are subject to enforcement. - **Maintain internal audit trails**: Given that fines can be modulated by degree of cooperation and corrective actions taken, organisations should maintain evidence of compliance steps, incident response procedures, and good-faith engagement with regulators. --- ## Relationship to Other Articles Article 99 cannot be read in isolation — it is the enforcement expression of obligations defined throughout the Regulation. The most direct links are to **Article 5** (prohibited practices, triggering the top penalty tier) and **Articles 8–15** (high-risk AI system requirements, the primary source of mid-tier violations). **Article 53–56** (GPAI obligations) feed into the penalty structure for foundation model providers. **Article 71** (EU database for high-risk AI systems) is a registration obligation whose breach is caught by the mid-tier. **Article 100** is the sibling provision for Union institutions and bodies, applying a parallel penalty regime administered by the European Data Protection Supervisor rather than national authorities. **Article 98** (penalties for non-compliance by notified bodies) and **Article 101** (delegation of power concerning fines for GPAI providers) sit immediately adjacent in the penalty chapter and should be read together with Article 99 for a complete picture of the Act's enforcement architecture. **Articles 74–79** (market surveillance and enforcement) define the procedural framework within which Article 99 fines are imposed. --- ## Compliance Timeline The EU AI Act entered into force on **2 August 2024** (twenty days after publication in the Official Journal). Article 99 itself became applicable on **2 August 2025**, following the twelve-month transitional period under Article 113(2). The phased application schedule is critical context for understanding when penalty exposure attaches to different obligations: - **2 February 2025** — Prohibition provisions (Article 5) became applicable, meaning violations of prohibited AI practices have been subject to the 7%/€35 million fine tier since this date. - **2 August 2025** — General applicability date for most of the Act, including Article 99 itself, GPAI model obligations (Chapter V), and the governance framework. The 3%/€15 million and 1%/€7.5 million fine tiers became operational from this date. - **2 August 2028** — High-risk AI systems covered by Annex I (existing Union harmonisation legislation) must comply with the full high-risk requirements, making provider obligations under Articles 8–15 enforceable with fine exposure. - **2 December 2027** — High-risk AI systems listed in Annex III that were already on the market before 2 August 2024 must comply, completing the phase-in for legacy high-risk deployments. Organisations should map their AI portfolio against these dates to determine current and forward-looking penalty exposure under Article 99. -------------------------------------------------------------------------------- ## CSRD and AI Act: What Your SME Needs to Know in 2025 URL: https://www.regulation-ai.eu/en/articles/csrd-ai-act-sme-2025/ European SMEs are navigating an unprecedented regulatory environment: two landmark pieces of legislation — the **CSRD** (Corporate Sustainability Reporting Directive) and the **AI Act** — are converging to fundamentally transform business obligations. Understanding how they interact is now a strategic priority, not just a legal one. ## Why This Dual Regulation Concerns Your SME Many SME leaders mistakenly believe these regulations only apply to large corporations. This is a costly misconception. If your company is a supplier or subcontractor to a large company subject to CSRD, you will be indirectly affected by its reporting obligations. And if you use or deploy AI systems — even HR tools or customer scoring software — the AI Act applies to you right now. ## CSRD: Timeline and Thresholds for SMEs The CSRD introduced mandatory sustainability reporting in three waves: - **2025**: Large companies (>500 employees) already subject to NFRD - **2026**: Large companies (>250 employees OR >€40M turnover OR >€20M balance sheet) - **2027**: SMEs listed on regulated markets (with opt-out clause until 2028) Unlisted SMEs are not directly subject to CSRD. But beware: **large client or partner companies** will ask you for ESG data to complete their own reporting. Value chain pressure is real. ### The VSME Voluntary Standard EFRAG developed a simplified standard for unlisted SMEs: the **VSME** (Voluntary SME Standard). It allows you to respond to partner requests without bearing the full ESRS requirements. Adopting the VSME now gives you a competitive commercial advantage. ## The AI Act: What Applies to SMEs from 2025 The AI Act entered into force on 1 August 2024. Its rollout is phased: - **February 2025**: Prohibition of unacceptable AI practices - **August 2025**: Obligations for general-purpose AI (GPAI) models - **December 2027**: Full obligations for stand-alone high-risk AI systems (Annex III) ### Are You Affected by High-Risk Systems? Annex III of the AI Act lists high-risk domains. Your SME may be concerned if it uses or develops AI systems for: - **Recruitment and HR management** (CV scoring, performance evaluation) - **Access to credit** (creditworthiness scoring) - **Education and vocational training** - **Essential services** (water, gas, electricity) - **Product safety** in regulated sectors If you fall into these categories, compliance obligations apply: risk management, technical documentation, event logs, human oversight. ### SME-Specific Alleviations The EU legislator included specific measures to reduce the burden on SMEs: 1. **Regulatory sandbox**: Priority access to test your AI systems in a secure environment before commercialisation 2. **Reduced fees** at notified bodies for SMEs and micro-enterprises 3. **Simplified documentation** for certain categories 4. **Additional timelines** for providers of high-risk systems already on the market ## Convergence Points: CSRD / AI Act These two texts reinforce each other on several critical points: ### 1. Data Governance CSRD requires precise reporting on your environmental and social impacts — which implies rigorous data collection. The AI Act mandates documentation of training data for high-risk systems. A solid data architecture serves both obligations. ### 2. Transparency and Auditability Both texts require that your processes be traceable and verifiable by third parties. For CSRD, that's the financial auditor. For the AI Act, it's the market surveillance authorities. Building auditable processes is a shared investment. ### 3. Human Oversight The AI Act imposes effective human oversight on high-risk systems. This requirement aligns with the spirit of CSRD, which values responsible governance. Documenting your human control processes over AI decisions addresses both frameworks. ### 4. Value Chain Due Diligence CSRD (via CSDDD) imposes due diligence on your impacts throughout the value chain. The AI Act creates similar obligations for deployers using AI systems developed by third parties. Both texts make you responsible for what you buy and use. ## A Concrete Action Plan for Your SME Here is a pragmatic roadmap across three horizons: ### Short Term (Now — Q3 2025) - [ ] **Map your AI systems**: Identify all tools using AI (including third-party SaaS) and their risk classification - [ ] **Assess your indirect CSRD exposure**: Analyse your contracts with large companies to anticipate their ESG requests - [ ] **Designate a regulatory lead**: Even part-time, someone must steer these topics - [ ] **Inventory your data**: What is the quality, traceability, and governance of your ESG and AI data? ### Medium Term (Q4 2025 — Q2 2026) - [ ] **Adopt the VSME standard** if solicited by CSRD partners - [ ] **Bring your high-risk AI systems into compliance**: technical documentation, risk management, human oversight - [ ] **Train your teams** on AI Act basics (including the AI literacy obligation for all staff using AI systems) - [ ] **Review your AI supplier contracts**: Your SaaS providers must supply you with the documentation needed for your compliance ### Long Term (Q3 2026 and beyond) - [ ] **Integrate ESG and AI governance into your strategy**: These topics are no longer peripheral - [ ] **Leverage your compliance** with clients and investors - [ ] **Participate in regulatory sandboxes** to test innovation in a secure framework ## The AI Literacy Obligation: Often Overlooked, Yet Immediate Article 4 of the AI Act imposes a frequently neglected obligation: **ensuring a sufficient level of AI literacy** for all staff who use or supervise AI systems. This obligation applies **right now**, without any transition period. In practice, this means that if your employees use tools like ChatGPT, AI-based recruitment software, or demand prediction systems, you must be able to demonstrate that they understand the capabilities and limitations of those tools. ## Our Recommendations Do not treat CSRD and the AI Act as two separate projects. The synergies are real, and pooling them significantly reduces your compliance costs. Start with a **rapid diagnostic** of your exposure to both texts — this is the foundation of any realistic action plan. If you have questions about your specific situation, our sector analyses and diagnostic tools are available on this platform. --- *This article is provided for informational purposes and does not constitute legal advice. For your specific situation, please consult a qualified adviser.* -------------------------------------------------------------------------------- ## EU AI Act — All 113 Articles (Regulation 2024/1689) URL: https://www.regulation-ai.eu/en/articles/ This page is the complete table of contents for the EU AI Act (Regulation (EU) 2024/1689). All 113 articles are listed under their official Title and Chapter headings, with a brief description of each article's subject matter. Use this index to navigate the full legislative structure or to locate a specific provision. Each article page states at the top whether Regulation (EU) 2026/1744 moved it, and from what date it applies. Thirty-seven of the 113 were affected; the [amendment record](/en/changes/) lists them, and [`/api/changes.json`](/api/changes.json) publishes the same answer for every article. ## Title I — General Provisions - [Art. 1 — Subject matter](article-1/) — Establishes the purpose of the Regulation, which lays down harmonised rules for the placing on the market, putting into service, and use of AI systems in the Union. - [Art. 2 — Scope](article-2/) — Defines which providers, deployers, importers, distributors, and product manufacturers are subject to the Regulation, and lists the exclusions. - [Art. 3 — Definitions](article-3/) — Provides the official definitions of 68 key terms used throughout the Regulation, including "AI system", "provider", "deployer", "high-risk AI system", and "general-purpose AI model". - [Art. 4 — AI literacy](article-4/) — Requires providers and deployers to take measures supporting the development of AI literacy in their staff and persons dealing with AI systems on their behalf. Rewritten by Regulation (EU) 2026/1744: it no longer requires a specific level to be guaranteed for any individual. ## Title II — Prohibited AI Practices - [Art. 5 — Prohibited AI practices](article-5/) — Lists AI practices that are prohibited outright in the Union as being contrary to Union values, including subliminal manipulation, social scoring, and most uses of real-time remote biometric identification in public spaces. ## Title III — High-Risk AI Systems ### Chapter 1 — Classification of High-Risk AI Systems - [Art. 6 — Classification rules for high-risk AI systems](article-6/) — Sets out the two-tier classification framework: Annex I product-safety AI and Annex III stand-alone high-risk AI systems, plus the self-assessment exception procedure. - [Art. 7 — Amendments to Annex III](article-7/) — Empowers the Commission to amend Annex III via delegated acts to add or remove high-risk use-case categories based on defined criteria. ### Chapter 2 — Requirements for High-Risk AI Systems - [Art. 8 — Compliance with the requirements](article-8/) — Establishes that high-risk AI systems must comply with the requirements in this Chapter throughout their entire lifecycle. - [Art. 9 — Risk management system](article-9/) — Requires providers to establish, implement, document, and maintain a continuous risk management system for high-risk AI systems. - [Art. 10 — Data and data governance](article-10/) — Sets requirements for training, validation, and testing datasets, including relevance, representativeness, and freedom from errors and biases. - [Art. 11 — Technical documentation](article-11/) — Requires providers to draw up technical documentation before placing a high-risk AI system on the market, in accordance with Annex IV. - [Art. 12 — Record-keeping](article-12/) — Obliges providers to ensure high-risk AI systems are capable of automatically recording events (logs) throughout their lifetime. - [Art. 13 — Transparency and provision of information to deployers](article-13/) — Requires that high-risk AI systems are sufficiently transparent for deployers to interpret outputs and use the system appropriately, including via an instructions-for-use document. - [Art. 14 — Human oversight](article-14/) — Requires high-risk AI systems to be designed to allow effective human oversight and intervention during the period of use. - [Art. 15 — Accuracy, robustness, and cybersecurity](article-15/) — Specifies that high-risk AI systems must achieve appropriate levels of accuracy, be resilient to errors and faults, and be protected against cybersecurity threats. ### Chapter 3 — Obligations of Providers and Deployers of High-Risk AI Systems and Other Parties - [Art. 16 — Obligations of providers of high-risk AI systems](article-16/) — Lists the core obligations of providers, including quality management, conformity assessment, registration, and corrective action. - [Art. 17 — Quality management system](article-17/) — Requires providers to put in place a quality management system covering strategies, design controls, testing, post-market monitoring, and documentation. - [Art. 18 — Documentation keeping](article-18/) — Specifies the types of documentation providers must keep and make available to national authorities for ten years after placing a system on the market. - [Art. 19 — Automatically generated logs](article-19/) — Obliges providers to keep the logs automatically generated by their high-risk AI systems to the extent they are under their control. - [Art. 20 — Corrective actions and duty of information](article-20/) — Requires providers to take immediate corrective actions when a high-risk AI system does not conform and to inform authorities and deployers accordingly. - [Art. 21 — Cooperation with competent authorities](article-21/) — Obliges providers to cooperate with national competent authorities and supply all requested information and documentation. - [Art. 22 — Authorised representatives of providers established outside the Union](article-22/) — Requires providers established outside the EU to designate an authorised representative in the Union before placing systems on the market. - [Art. 23 — Obligations of importers](article-23/) — Sets obligations for importers to verify conformity assessment, CE marking, and provider documentation before placing high-risk AI systems on the market. - [Art. 24 — Obligations of distributors](article-24/) — Requires distributors to verify CE marking and accompanying documentation before making a high-risk AI system available on the market. - [Art. 25 — Responsibilities along the AI value chain](article-25/) — Clarifies when importers, distributors, or other parties take on the full obligations of a provider, particularly when they modify or place systems under their own name. - [Art. 26 — Obligations of deployers of high-risk AI systems](article-26/) — Sets out deployer obligations including following instructions for use, ensuring human oversight, monitoring operation, and informing providers and authorities of risks. - [Art. 27 — Fundamental rights impact assessment for high-risk AI systems](article-27/) — Requires certain public bodies and private entities performing regulated tasks to conduct a fundamental rights impact assessment before deploying a high-risk AI system. ### Chapter 4 — Notifying Authorities and Notified Bodies - [Art. 28 — Notifying authorities](article-28/) — Requires each Member State to designate a national notifying authority responsible for establishing and carrying out the procedures for assessment and notification of conformity assessment bodies. - [Art. 29 — Application of a conformity assessment body for notification](article-29/) — Sets out the procedure and information requirements for conformity assessment bodies applying to be notified. - [Art. 30 — Notification procedure](article-30/) — Describes the process through which Member States notify the Commission and other Member States of authorised conformity assessment bodies. - [Art. 31 — Requirements for notified bodies](article-31/) — Lists the organisational, independence, impartiality, and competence requirements a conformity assessment body must meet to be notified. - [Art. 32 — Presumption of conformity of notified bodies](article-32/) — Establishes that bodies accredited by a national accreditation authority in accordance with EU accreditation Regulation 765/2008 are presumed to meet the requirements for notified bodies. - [Art. 33 — Subsidiaries of and subcontracting by notified bodies](article-33/) — Permits notified bodies to subcontract or use subsidiaries provided that the client is informed and the notified body remains fully responsible. - [Art. 34 — Operational obligations of notified bodies](article-34/) — Requires notified bodies to carry out conformity assessments in a proportionate manner, document their procedures, and report to notifying authorities. - [Art. 35 — Identification numbers and lists of notified bodies](article-35/) — Provides for the Commission to assign identification numbers to notified bodies and publish an up-to-date list of all notified bodies. - [Art. 36 — Changes to notifications](article-36/) — Sets out the procedure for amending, suspending, or withdrawing a notification when a notified body no longer meets the requirements. - [Art. 37 — Challenge of the competence of notified bodies](article-37/) — Establishes the procedure by which the Commission may investigate whether a notified body continues to meet the requirements and require corrective action. - [Art. 38 — Coordination of notified bodies](article-38/) — Requires the Commission to ensure appropriate coordination and cooperation among notified bodies through a sectoral group of notified bodies. - [Art. 39 — Conformity assessment bodies of third countries](article-39/) — Permits conformity assessment bodies established in third countries to be notified under the Regulation only where a bilateral agreement between the Union and the third country so provides. ### Chapter 5 — Standards, Conformity Assessment, Certificates, and Registration - [Art. 40 — Harmonised standards and common specifications](article-40/) — Provides that high-risk AI systems conforming to harmonised standards or common specifications shall be presumed to comply with the requirements of Chapter 2. - [Art. 41 — Common specifications](article-41/) — Empowers the Commission to adopt implementing acts establishing common specifications where harmonised standards do not exist or are insufficient. - [Art. 42 — Presumption of conformity with certain requirements](article-42/) — Creates a rebuttable presumption of conformity for high-risk AI systems trained and tested on data reflecting the specific geographic, contextual, and behavioural settings of intended use. - [Art. 43 — Conformity assessment](article-43/) — Specifies the conformity assessment procedures applicable to each category of high-risk AI system, including internal control and third-party assessment routes. - [Art. 44 — Certificates](article-44/) — Governs the EU technical documentation assessment certificates and quality management system certificates issued by notified bodies, including their validity and renewal. - [Art. 45 — Information obligations of notified bodies](article-45/) — Requires notified bodies to notify the notifying authority of certificates issued, modified, supplemented, suspended, withdrawn, or refused, and to maintain a register of certificates. - [Art. 46 — Derogation from conformity assessment procedure](article-46/) — Allows Member State authorities to authorise specific high-risk AI systems to be placed on the market without completing the standard conformity assessment procedure, in the interest of public security or safety. - [Art. 47 — EU declaration of conformity](article-47/) — Requires providers to draw up a written EU declaration of conformity for each high-risk AI system and keep it updated throughout the system's lifecycle. - [Art. 48 — CE marking](article-48/) — Provides that high-risk AI systems must bear the CE conformity marking before being placed on the market or put into service, in accordance with the rules in Annex V. - [Art. 49 — Registration](article-49/) — Requires providers of high-risk AI systems listed in Annex III (and certain GPAI model providers) to register in the EU database before placing those systems on the market. ## Title IV — Transparency Obligations for Certain AI Systems - [Art. 50 — Transparency obligations for providers and deployers of certain AI systems](article-50/) — Requires providers to design certain AI systems (chatbots, deepfakes, emotion recognition, biometric categorisation) so that users are informed they are interacting with AI or that content is AI-generated. ## Title V — General-Purpose AI Models ### Chapter 1 — Classification of General-Purpose AI Models - [Art. 51 — Classification of general-purpose AI models as general-purpose AI models with systemic risk](article-51/) — Sets out the criteria and thresholds — notably training compute above 10^25 FLOPs — for classifying a GPAI model as posing systemic risk. ### Chapter 2 — Obligations for Providers of General-Purpose AI Models - [Article 52 — Systemic-risk classification procedure](article-52/) — Systemic-risk classification procedure. - [Article 53 — Obligations for all providers of general-purpose AI models](article-53/) — Obligations for all providers of general-purpose AI models. - [Art. 54 — Authorised representative of providers of general-purpose AI models established outside the Union](article-54/) — Requires providers of GPAI models established outside the EU to designate an authorised representative in the Union. - [Article 55 — Obligations for providers of general-purpose AI models with systemic risk](article-55/) — Obligations for providers of general-purpose AI models with systemic risk. ### Chapter 3 — Codes of Practice - [Article 56 — Codes of practice](article-56/) — Codes of practice. ## Title VI — Measures in Support of Innovation ### Chapter 1 — AI Regulatory Sandboxes - [Art. 57 — AI regulatory sandboxes](article-57/) — Requires Member States to establish AI regulatory sandboxes providing controlled environments for developing, testing, and validating innovative AI systems before market placement. - [Art. 58 — Detailed arrangements for AI regulatory sandboxes and their functioning](article-58/) — Empowers the Commission to adopt implementing acts specifying uniform conditions for establishing and operating AI regulatory sandboxes. - [Art. 59 — Further processing of personal data for developing certain AI systems in the public interest in the AI regulatory sandbox](article-59/) — Sets out the limited conditions under which personal data lawfully collected for other purposes may be further processed in an AI regulatory sandbox. ### Chapter 2 — Measures for Providers and Deployers, in Particular SMEs, Including Start-Ups - [Art. 60 — Testing of high-risk AI systems in real world conditions outside AI regulatory sandboxes](article-60/) — Allows testing of high-risk AI systems in real-world conditions outside a regulatory sandbox, subject to a specific plan and safeguards including informed consent. - [Article 61 — Informed consent in real-world testing](article-61/) — Informed consent in real-world testing. - [Art. 62 — Measures for providers and deployers, in particular SMEs, including start-ups](article-62/) — Requires national competent authorities and the AI Office to take specific measures to reduce the regulatory burden on SMEs and start-ups, including priority access to sandboxes and reduced fees. - [Art. 63 — Derogations from certain requirements applicable to high-risk AI systems for certain operators](article-63/) — Lets microenterprises and small providers of high-risk AI meet parts of the Chapter III, Section 2 quality-management requirements in a simplified form, without reducing the substance of the obligations. ## Title VII — Governance ### Chapter 1 — EU-Level Governance - [Art. 64 — Tasks of the AI Office](article-64/) — Lists the tasks of the AI Office including monitoring GPAI model obligations, supporting the AI Board, conducting investigations, and fostering Union-wide AI governance coherence. - [Art. 65 — AI Board](article-65/) — Establishes the European Artificial Intelligence Board composed of one representative from each Member State and the European Data Protection Supervisor, with the AI Office providing its secretariat. - [Article 66 — Tasks of the Board](article-66/) — Tasks of the Board. - [Article 67 — Advisory forum](article-67/) — Advisory forum. - [Article 68 — Scientific panel of independent experts](article-68/) — Scientific panel of independent experts. ### Chapter 2 — National Competent Authorities - [Article 69 — Access to the pool of experts by the Member States](article-69/) — Access to the pool of experts by the Member States. - [Article 70 — National competent authority](article-70/) — National competent authority. ## Title VIII — EU Database for High-Risk AI Systems - [Art. 71 — EU database for high-risk AI systems](article-71/) — Requires the Commission to establish and maintain a publicly accessible EU database containing registration information for high-risk AI systems listed under Annex III. ## Title IX — Post-Market Monitoring, Information Sharing, and Market Surveillance ### Chapter 1 — Post-Market Monitoring - [Art. 72 — Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems](article-72/) — Requires providers to establish and document a post-market monitoring system to proactively collect and analyse data on high-risk AI system performance throughout their lifetime. ### Chapter 2 — Sharing of Information on Serious Incidents - [Art. 73 — Reporting of serious incidents](article-73/) — Requires providers of high-risk AI systems placed on the Union market to report serious incidents to the market surveillance authorities of the Member States in which the incident occurred. ### Chapter 3 — Market Surveillance and Control of AI Systems in the Union Market - [Art. 74 — Market surveillance and control of AI systems in the Union market](article-74/) — Designates national market surveillance authorities, specifies their powers and responsibilities, and establishes the framework for coordinated market surveillance of AI systems. - [Art. 75 — Mutual assistance, market surveillance and control of general-purpose AI models](article-75/) — Provides for mutual assistance between national market surveillance authorities and the AI Office for the market surveillance and control of GPAI models. - [Art. 76 — Supervision of testing in real world conditions by market surveillance authorities](article-76/) — Grants market surveillance authorities the power to supervise and inspect real-world testing of high-risk AI systems and to require modifications or suspension of testing. - [Art. 77 — Powers of authorities protecting fundamental rights](article-77/) — Requires market surveillance authorities to cooperate with national authorities responsible for fundamental rights protection when assessing high-risk AI systems affecting individuals' rights. - [Art. 78 — Confidentiality](article-78/) — Obliges national competent authorities and the Commission to maintain the confidentiality of information and data obtained in carrying out their tasks, in line with applicable Union and national law. - [Article 79 — National procedure for AI systems presenting a risk](article-79/) — National procedure for AI systems presenting a risk. - [Article 80 — Procedure for systems misclassified as non-high-risk](article-80/) — Procedure for systems misclassified as non-high-risk. - [Article 81 — Union safeguard procedure](article-81/) — Union safeguard procedure. - [Article 82 — Compliant AI systems which present a risk](article-82/) — Compliant AI systems which present a risk. - [Article 83 — Formal non-compliance](article-83/) — Formal non-compliance. - [Article 84 — Union testing facilities](article-84/) — Union testing facilities. ### Chapter 4 — Remedies - [Article 85 — Right to lodge a complaint with a market surveillance authority](article-85/) — Right to lodge a complaint with a market surveillance authority. - [Article 86 — Right to explanation of individual decision-making](article-86/) — Right to explanation of individual decision-making. - [Article 87 — Whistleblowing](article-87/) — Whistleblowing. ### Chapter 5 — Supervision, Investigation, Enforcement and Monitoring for Providers of General-Purpose AI Models - [Article 88 — Enforcement of the obligations of GPAI providers](article-88/) — Enforcement of the obligations of GPAI providers. - [Article 89 — Monitoring actions of the AI Office](article-89/) — Monitoring actions of the AI Office. - [Article 90 — Alerts of systemic risks by the scientific panel](article-90/) — Alerts of systemic risks by the scientific panel. - [Article 91 — Power to request documentation and information](article-91/) — Power to request documentation and information. - [Article 92 — Power to conduct evaluations](article-92/) — Power to conduct evaluations. - [Art. 93 — Power to request measures](article-93/) — Empowers the Commission to require GPAI providers to restore compliance, implement mitigation measures after an Article 92 evaluation, or restrict, withdraw or recall the model. - [Article 94 — Procedural rights of GPAI economic operators](article-94/) — Procedural rights of GPAI economic operators. ## Title X — Codes of Conduct and Guidelines - [Art. 95 — Codes of conduct for voluntary application of specific requirements](article-95/) — Opens a voluntary route for providers of AI that is not high-risk to commit to requirements drawn from the high-risk regime, and to further objectives such as accessibility and environmental sustainability. - [Art. 96 — Guidelines from the Commission on the implementation of this Regulation](article-96/) — Requires the Commission to issue guidelines on applying the Regulation, including the high-risk classification rules, prohibited practices and the relationship with Union harmonisation legislation. ## Title XI — Delegation of Power and Committee Procedure - [Art. 97 — Exercise of the delegation](article-97/) — Sets the conditions under which the Commission may adopt delegated acts: the duration of the delegation, the right of Parliament and Council to revoke it, and the objection period. - [Art. 98 — Committee procedure](article-98/) — Provides that the Commission is assisted by a committee within the meaning of Regulation (EU) No 182/2011 when it adopts implementing acts. ## Title XII — Penalties - [Art. 99 — Penalties](article-99/) — Sets the administrative fine framework for infringements: three tiers calibrated to severity, reaching €35 000 000 or 7% of total worldwide annual turnover for the prohibited practices of Article 5. - [Article 100 — Administrative fines on Union institutions and bodies](article-100/) — Administrative fines on Union institutions and bodies. - [Article 101 — Penalties applicable to providers of general-purpose AI models](article-101/) — Penalties applicable to providers of general-purpose AI models. ## Title XIII — Final Provisions - [Art. 102 — Amendments to Directive (EU) 2016/797](article-102/) — Amends the Railway Interoperability Directive to align railway safety AI requirements with the EU AI Act framework. - [Art. 103 — Amendments to Regulation (EU) 2018/858](article-103/) — Amends the Motor Vehicles Regulation to align vehicle type-approval rules for AI systems with the EU AI Act. - [Art. 104 — Amendments to Regulation (EU) 2018/1139](article-104/) — Amends the Aviation Safety Regulation to integrate EU AI Act requirements for AI systems used in civil aviation. - [Art. 105 — Amendments to Regulation (EU) 2019/2144](article-105/) — Amends the Vehicle Type-Approval Regulation for motor vehicles to incorporate the EU AI Act's safety requirements for AI systems in vehicles. - [Art. 106 — Amendments to Directive 2006/42/EC](article-106/) — Amends the Machinery Directive to align requirements for AI-enabled machinery with the EU AI Act framework. - [Art. 107 — Amendments to Directive 2009/138/EC](article-107/) — Amends the Solvency II Insurance Directive to incorporate considerations relating to AI systems used by insurance undertakings. - [Art. 108 — Amendments to Directive 2013/36/EU](article-108/) — Amends the Capital Requirements Directive to include references to AI system governance and risk management within the prudential framework for credit institutions. - [Art. 109 — Amendments to Directive (EU) 2016/97](article-109/) — Amends the Insurance Distribution Directive to reflect AI Act requirements applicable to AI tools used in insurance distribution. - [Article 110 — Amendment to the Representative Actions Directive](article-110/) — Amendment to the Representative Actions Directive. - [Article 111 — Transitional provisions](article-111/) — Transitional provisions. - [Article 112 — Evaluation](article-112/) — Evaluation. - [Art. 113 — Entry into force and application](article-113/) — States that the Regulation entered into force on 1 August 2024 and specifies the phased application dates: February 2025 for prohibited practices, August 2025 for GPAI rules, December 2027 for stand-alone Annex III high-risk obligations, and August 2028 for Annex I high-risk product AI. -------------------------------------------------------------------------------- ## AI Watermarking: What's Been Deployed, the Results So Far, and the Consequences URL: https://www.regulation-ai.eu/en/blog/ai-watermarking-deployment-results-consequences/ Since 2 August 2026, marking AI-generated content is no longer an optional best practice in the European Union — it is a legal obligation carrying fines of up to 3% of worldwide turnover. Major providers — Google, OpenAI, Adobe, Meta, Microsoft — have in fact deployed watermarking technology at scale. But independent studies published alongside that rollout converge on an uncomfortable conclusion for compliance teams: none of these technologies, on its own, holds up durably against a determined actor. This article covers what has actually been deployed, what independent testing shows about how well it works, and what that means in practice — for providers subject to the obligation, and for anyone who has to judge whether a piece of content can be trusted. For the full legal framework, see our dedicated page on [Article 50 transparency obligations](/en/transparency-obligations/) and our analysis of [what changed on 2 August 2026](/en/blog/eu-ai-act-enforcement-august-2026/). This article takes a different angle: the technology itself, its measured results, and its practical consequences. ## Three different things called "watermark" The most common confusion comes from the fact that "watermark" actually refers to three distinct mechanisms with very different properties. 1. **The visible label** — a banner, icon, or caption reading "AI-generated." Easy for a human to understand, but not machine-readable, and it disappears the moment a screenshot or crop excludes it from the frame. 2. **The invisible mark embedded in the signal** — an imperceptible pattern woven into an image's pixels, an audio file's samples, or the statistical distribution of tokens in generated text. This is SynthID's principle, developed by Google DeepMind. It survives compression and format conversion reasonably well because it is part of the content itself rather than attached data. 3. **Signed provenance metadata** — a cryptographic manifest attached to the file, documenting who created the content, with what tool, and what edits followed. This is the approach of the **C2PA (Coalition for Content Provenance and Authenticity)** standard, marketed as **Content Credentials**. Article 50(2) of the AI Act requires "machine-readable marking" without mandating any specific technology — which is why the market has converged on combining categories 2 and 3 rather than relying on either alone. ## What has actually been deployed in 2026 Deployment accelerated sharply over the past year, driven both by the EU's regulatory deadline and by competitive pressure between major providers. | Technology | Developed by | Marking type | Notable adoption | |---|---|---|---| | **SynthID** | Google DeepMind | Invisible, embedded in the signal (image, audio, video, text) | Deployed across Google's own generative outputs; SynthID-Text open-sourced for third-party integration | | **C2PA / Content Credentials** | C2PA coalition (Adobe, Google, Microsoft, Meta, OpenAI, Sony, BBC, Amazon…) | Cryptographically signed metadata | Coalition with several thousand members and affiliates; built into many cameras and editing tools by default | | **Sora 2, DALL·E 3, ChatGPT images** | OpenAI | C2PA + SynthID-style invisible watermark | OpenAI joined the C2PA steering committee on 19 May 2026 and committed to layering both on its outputs | | **Meta AI** | Meta | Visible label + proprietary detection signals and industry standards | Deployed across content generated in Meta products | | **Firefly, Copilot, TikTok** | Adobe, Microsoft, TikTok | C2PA | Emit Content Credentials on generated content | This table makes one point clear: leading providers no longer rely on a single technique. The **Code of Practice on Transparency of AI-generated Content**, which the Commission has confirmed as an adequate means of demonstrating Article 50 compliance, explicitly recommends a multi-layer approach — C2PA metadata *and* a pixel-level invisible mark able to survive compression, cropping, and format conversion. The Code itself acknowledges that **no single technique meets all four legal criteria** — effective, interoperable, robust, and reliable — at once, which is precisely why the industry has converged on layering rather than choosing one. ## What the results actually show This is where the picture gets more complicated. Several independent research efforts published through 2024 and 2025 have tested how well these mechanisms hold up against deliberate attempts to defeat them — and the results considerably qualify the vendor narrative. **C2PA metadata is structurally fragile.** It is not anchored in the visual or audio content itself: strip it, and any trace of provenance disappears. Most major social platforms strip file metadata by default on upload — for file-size and privacy reasons, not to dodge regulation. In practice, the provenance chain breaks at exactly the moment content reaches the most people: the moment it's shared. **Invisible watermarks hold up better, but not indefinitely.** SynthID's core idea — embedding the mark in the signal itself — makes it considerably more resistant to compression, format conversion, or simple cropping than a metadata file. But research teams have repeatedly shown, since 2024, that a watermark of this kind can be degraded below detection thresholds through targeted perturbations, or simply by regenerating the content through another generative model to strip the original mark. **A study from the University of Waterloo's Cybersecurity and Privacy Institute captures the scope of the problem well:** its researchers demonstrated that virtually any AI image watermark can be removed, **without the attacker needing to know the watermark's design, or even whether the image carries one at all**. The same team notes that a bad actor can evade both deepfake detection and copyright enforcement simply by passing content back through a diffusion model. **Providers themselves acknowledge this.** A Microsoft report on media integrity and authentication, published in February 2026, explicitly concedes that it is not possible to prevent every attack, nor to stop certain platforms from stripping provenance signals during file processing. **A parallel arms race has taken hold.** As major providers expanded watermark coverage through 2026, publicly available tools — open-source repositories and commercial services alike — added support for stripping exactly those marks within weeks. That extremely short gap between a watermark's rollout and the availability of a removal tool is telling: watermarking isn't a static protective mechanism, it's a moving technical contest. ## The practical consequences Three groups of actors are directly affected, and not in the same way. **For bad-faith actors, watermarking changes almost nothing.** A voluntary — or technically defeatable — mechanism doesn't stop someone determined to produce a deepfake for election disinformation, identity fraud, or impersonation. Election-integrity research has noted across several cycles that groups producing malicious deepfakes have, by definition, no reason to use a tool that marks them — and will develop or borrow the means to strip a mark if one is technically imposed on them. That is precisely the argument for a legal mandate rather than a purely voluntary best practice: it shifts legal risk onto the provider that fails to mark, even though it doesn't technically stop a downstream bad actor. **For good-faith companies, compliance becomes both costly and short of a full guarantee.** Article 50 imposes an obligation of result — marking that is "effective, reliable, robust and interoperable" — even as the Code of Practice itself acknowledges that no current technology meets all of those criteria alone. In practice, providers subject to the obligation must layer multiple technical mechanisms (C2PA plus an invisible watermark, at minimum), document their method, and still carry residual exposure if their marking is stripped at scale — a risk they don't fully control, since it also depends on how downstream distribution platforms behave. Signing the Code of Practice remains, at this stage, the most documented route to demonstrating good-faith compliance, without amounting to immunity. **For platforms, newsrooms, and fact-checkers, watermarking creates a false-security risk.** The absence of a mark doesn't prove authenticity — it may simply mean the mark was stripped during sharing, or that the content came from a non-compliant tool. Conversely, a provenance badge can be mistaken for a guarantee of reliability when the underlying mechanism remains, by design, defeatable. The real reliability lever remains human verification and contextual analysis — technical marking is a supporting signal, not proof. **Regulation itself appears to be drawing the same conclusion.** Beyond 2 December 2026 — when the transitional period for machine-readable marking of pre-existing generative systems closes — the Code of Practice envisages building interoperable detection infrastructure, so that detection tools from different vendors can recognise marks emitted by other providers. That effort, distinct from marking itself, is an implicit admission that system reliability can't rest on watermarking alone, but on a shared detection ecosystem — a considerably harder problem than the marking technique itself. ## What this means for a company subject to Article 50 - **Don't confuse a visible label with machine-readable marking.** The legal obligation targets the latter; an on-screen "AI-generated" banner alone does not satisfy it for a large-scale generative system. - **Document a layered approach**, imperfect as it is: C2PA for declarative provenance, an invisible watermark for technical resilience. This is what the Code of Practice recommends, and it's the most defensible position in front of a market surveillance authority. - **Don't present watermarking as an absolute guarantee** in public communications — doing so creates additional exposure if a bypass is later demonstrated publicly. - **Track the 2 December 2026 deadline** for systems already on the market before 2 August 2026, and check whether your system falls within the transitional period or must already mark its outputs today. - **Check your Code of Practice status** — signatory or not — and if not, document a defensible alternative method. Our [compliance checklist](/en/compliance-checklist/) covers the full obligation set, and the [AI Act deadline tracker](/en/deadlines/) lets you check the dates that apply to your situation. The full text of the obligation is at [Article 50 of the Regulation](/en/articles/article-50/), and the applicable penalties at [Article 99](/en/penalties/). ## Sources - European Commission — [Code of Practice on Transparency of AI-generated Content](https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content) - OpenAI — [Advancing content provenance for a safer, more transparent AI ecosystem](https://openai.com/index/advancing-content-provenance/) - University of Waterloo, Cybersecurity and Privacy Institute — [Watermarks offer no defense against deepfakes](https://uwaterloo.ca/news/media/watermarks-offer-no-defense-against-deepfakes) - Coalition for Content Provenance and Authenticity — [c2pa.org](https://c2pa.org/) - Google DeepMind — [SynthID](https://deepmind.google/technologies/synthid/) - Regulation (EU) 2024/1689 — [Article 50](https://artificialintelligenceact.eu/article/50/) -------------------------------------------------------------------------------- ## EU AI Act Enforcement Has Started: What Changed on 2 August 2026 URL: https://www.regulation-ai.eu/en/blog/eu-ai-act-enforcement-august-2026/ The EU AI Act crossed from drafting into enforcement on **2 August 2026**. Two distinct things happened on that date, and conflating them is the fastest way to misjudge your exposure. **The short answer:** the Article 50 transparency obligations became directly applicable to providers and deployers, and the European Commission's AI Office acquired the power to investigate and fine providers of general-purpose AI models. The heavy high-risk regime did *not* arrive — the Digital Omnibus pushed it to December 2027 and August 2028. If you have been waiting for the high-risk deadline to start work, you have already missed a live obligation that applies to you regardless of risk tier. ## What changed on 2 August 2026 | Change | Who it hits | Legal basis | Status | |---|---|---|---| | Chatbot / AI-interaction disclosure | Providers | Art. 50(1) | **Applies now** | | Machine-readable marking of synthetic content | Providers of generative AI | Art. 50(2) | **Applies now** (grace period for pre-existing systems → 2 Dec 2026) | | Emotion recognition & biometric categorisation notice | Deployers | Art. 50(3) | **Applies now** | | Deepfake and public-interest text labelling | Deployers | Art. 50(4) | **Applies now** | | Commission enforcement powers over GPAI models | GPAI model providers | Art. 88–94, 101 | **Applies now** | | Prohibited practices enforcement | All | Art. 5 | **Applies now** | What did *not* change is as important: standalone Annex III high-risk obligations remain deferred to **2 December 2027**, Annex I embedded AI to **2 August 2028**, and the national regulatory sandbox obligation to **2 August 2027**. ## The enforcement shift nobody priced in The GPAI obligations in Chapter V have been legally binding since 2 August 2025. What they lacked was a regulator with teeth. Until 2 August 2026 the AI Office could ask, publish guidance, and negotiate — it could not compel. That asymmetry ended. The AI Office can now: - **request documentation and information** from GPAI model providers, - **conduct its own evaluations** of models, including independent testing, - **require corrective measures** — compliance actions, risk mitigation, market restriction, recall or withdrawal, - **impose fines** of up to **3% of global annual turnover or €15 million**, whichever is higher, under Article 101. The Commission also opened the channels through which cases will actually reach it: an **AI Act complaints tool**, an **AI Act Whistleblower Tool**, and a dedicated complaints channel for downstream providers building on general-purpose models. That last one matters more than it sounds — it lets a company integrating a foundation model report the upstream provider's non-compliance directly to Brussels. ## The four Article 50 obligations, precisely Article 50 is the broadest-reaching provision in the entire Regulation, because it is **risk-independent**. It does not ask whether your system is high-risk. It asks what your system *does*. **1. Systems that interact with people (Art. 50(1)) — provider duty.** Chatbots, voice assistants, AI agents and avatars must be designed so that a natural person is informed they are interacting with an AI system. The disclosure must be timely — before or at the start of the interaction. The only carve-out is where it is obvious to a reasonably well-informed person, plus the law-enforcement exemption. **2. Generative output marking (Art. 50(2)) — provider duty.** Providers of AI systems generating synthetic audio, image, video or text must mark outputs in a **machine-readable** format, detectable as artificially generated or manipulated. The marking must be effective, reliable, robust and interoperable. This is the obligation with the December grace period. **3. Emotion recognition and biometric categorisation (Art. 50(3)) — deployer duty.** Deployers must inform the natural persons exposed to the system, and comply with GDPR in parallel. Safety-protective uses such as drowsy-driver detection sit outside the disclosure duty. **4. Deepfakes and public-interest text (Art. 50(4)) — deployer duty.** Deployers publishing deepfakes, or AI-generated text on matters of public interest, must disclose that the content is artificially generated or manipulated. Exemptions apply where content undergoes human editorial review with editorial responsibility, and for manifestly artistic, creative, satirical or fictional work — subject to proportionate disclosure that does not spoil the work. Note the split: **obligations 1 and 2 fall on providers, 3 and 4 on deployers.** Most organisations are deployers, and most compliance programmes have been written as if the whole Article were a provider problem. See our breakdown of [providers vs. deployers](/en/providers-vs-deployers/) if you are unsure which you are. ## The 2 December 2026 trap The transitional period is the single most misread element of the August package. > The grace period until **2 December 2026** applies **only** to machine-readable marking, and **only** for generative AI systems already placed on the EU market before 2 August 2026. Three consequences follow: - A generative system **launched on or after 2 August 2026** has no grace period. It must mark from launch. - The **other three** Article 50 duties have no transitional period at all. Chatbot disclosure, emotion recognition notice and deepfake labelling were enforceable on 2 August. - 2 December 2026 is also when the **new Article 5 prohibition** — on AI systems generating child sexual abuse material or non-consensual intimate imagery — becomes enforceable. For providers this bites beyond intended use: it reaches any system where such generation is a reasonably foreseeable and reproducible outcome without significant technical modification, and where the system lacks adequate safeguards to prevent it. That is a design-and-red-teaming obligation, not a policy statement. ## What non-compliance costs | Breach | Ceiling | Enforced by | |---|---|---| | Prohibited practices (Art. 5) | €35M or **7%** of worldwide turnover | National authorities | | Article 50 transparency | €15M or **3%** of worldwide turnover | National market surveillance authorities | | GPAI model obligations (Art. 101) | €15M or **3%** of worldwide turnover | European Commission / AI Office | | Incorrect or misleading information to regulators | €7.5M or **1.5%** of worldwide turnover | National authorities / Commission | In each case the ceiling is *the higher* of the fixed sum and the percentage. For a company above roughly €500 million in turnover, the percentage is always the operative figure. Full detail on the tiering and the SME caps is on our [penalties page](/en/penalties/). ## Who your regulator actually is This is the practical question, and the answer is rarely Brussels. - **GPAI model providers** answer to the **Commission's AI Office**, exclusively. This is a deliberately centralised regime. - **Everyone else** — Article 50 duties, prohibited practices, and eventually the high-risk regime — answers to the **national market surveillance authority** of each Member State where the system is placed on the market or put into service. Designation of those national authorities has been uneven across the 27 Member States. In practice this produces a patchwork: identical conduct may draw an inspection in one Member State and nothing in another, at least in the first enforcement cycle. That asymmetry is a reason to comply to the strictest national interpretation, not the most permissive — a single well-resourced regulator can set the de facto European standard, as happened repeatedly under the GDPR. ## The Code of Practice: the closest thing to a safe harbour The Commission published the **Code of Practice on Transparency of AI-generated Content** in June 2026 and confirmed it as an adequate means of demonstrating compliance with the Article 50 marking and labelling duties. By the end of July 2026 roughly **190 organisations** had signed. The Code has two sections: - **Section 1 — providers** (provenance and marking requirements). Signatories include Aleph Alpha, Anthropic, Black Forest Labs, Cohere, Google, Meta, Microsoft, Mistral, OpenAI and Synthesia. - **Section 2 — deployers** (visible labelling of deepfakes and public-interest AI text). Signatories include Bulgari, Fastweb, Getty Images, Iberdrola, Lenovo and Lufthansa. Signing is voluntary and confers no legal immunity. But the asymmetry is real: a signatory implementing the Code has a documented, Commission-recognised compliance route. A non-signatory must construct and defend its own method in front of a market surveillance authority. Interoperable watermarking schemes such as Google's SynthID are the emerging technical baseline for Section 1. ## What to do in the next 120 days 1. **Inventory by function, not by risk tier.** List every AI system that talks to a person, generates content, or infers emotions. Risk classification is irrelevant to Article 50 scope. 2. **Split the inventory provider vs deployer.** Obligations 1–2 versus 3–4 land on different legal entities, often within the same group. 3. **Date every generative system.** On the EU market before 2 August 2026 → marking due 2 December 2026. On or after → due now. Record the evidence for the date. 4. **Ship the disclosures.** In-interface chatbot notices, content labels, emotion recognition notices. These are already overdue if missing. 5. **Decide on the Code of Practice.** Sign it, or document why your alternative method meets Article 50 to the same standard. 6. **Red-team against the new Article 5 prohibition** before 2 December 2026 if you provide a generative image, video or audio model. 7. **Identify your national market surveillance authority** in each Member State where you operate, and check whether it has published enforcement priorities. Our [compliance checklist](/en/compliance-checklist/) covers the full obligation set, and the [transparency obligations pillar](/en/transparency-obligations/) goes deeper on Article 50 scope and exemptions. ## The road after August 2026 | Date | Milestone | |---|---| | **2 December 2026** | Marking grace period closes; new Art. 5 prohibition (CSAM / NCII) enforceable | | **2 August 2027** | Member States must have a regulatory sandbox operational | | **2 December 2027** | Standalone Annex III high-risk obligations apply | | **2 August 2028** | Annex I embedded high-risk AI obligations apply | The deferrals granted by the Digital Omnibus bought time on the high-risk regime — roughly sixteen months for Annex III, and a further twelve on top of the year Article 113(c) had already given Annex I. They bought no time at all on transparency. Organisations that read the Omnibus as a general reprieve have misread it: the Regulation's broadest obligation is live, enforceable, and carries a 3% ceiling. For the full picture of what the Omnibus changed, see our [Digital Omnibus analysis](/en/omnibus/) and the [AI Act deadline tracker](/en/deadlines/). ## Official sources - European Commission — [Commission starts enforcing AI Act rules and new transparency requirements on 2 August](https://digital-strategy.ec.europa.eu/en/news/commission-starts-enforcing-ai-act-rules-and-new-transparency-requirements-2-august) - European Commission — [Guidelines on transparency obligations for providers and deployers of certain AI systems](https://digital-strategy.ec.europa.eu/en/library/guidelines-transparency-obligations-providers-and-deployers-ai-systems), 20 July 2026 - European Commission — [Code of Practice on Transparency of AI-generated Content](https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content) - European Commission — [Transparency obligations under Article 50 of the AI Act (FAQ)](https://digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act) - Regulation (EU) 2024/1689 — [Article 50](https://artificialintelligenceact.eu/article/50/), [Article 99](https://artificialintelligenceact.eu/article/99/) - Regulation (EU) 2026/1744 (Digital Omnibus on AI) — published in the Official Journal 24 July 2026, in force 27 July 2026 -------------------------------------------------------------------------------- ## European Commission Publishes Guidelines on AI Act Transparency Obligations URL: https://www.regulation-ai.eu/en/blog/european-commission-transparency-obligations-guidelines-ai-act/ ## What happened On 20 July 2026, the European Commission published **guidelines detailing the transparency obligations** set out in Article 50 of Regulation (EU) 2024/1689 (the EU AI Act). The guidelines are intended to help national competent authorities, providers, and deployers apply these obligations consistently across the Union. The timing is notable: the guidance lands less than two weeks before Article 50 itself enters into application on **2 August 2026** — a deadline that reaches far more organizations than the high-risk obligations under Title III, since it applies to any provider or deployer whose systems fall within scope, regardless of risk classification. ## Who is affected Two categories of actors are addressed: - **Providers**, who design and place on the market AI systems that pose transparency risks to the people who interact with them or are exposed to their output. - **Deployers**, who put these systems into use and, for certain categories, carry a direct disclosure obligation toward the individuals concerned. ## Recap: what Article 50 requires Article 50 sets out four distinct obligations, depending on the type of AI system: - **Conversational systems** (chatbots, voice assistants): providers must design the system so that natural persons are informed they are interacting with an AI system, unless this is obvious from the perspective of a reasonably well-informed person. - **Synthetic content** (AI-generated or manipulated text, image, audio, video): providers must ensure outputs are marked in a machine-readable format and detectable as artificially generated or manipulated. - **Emotion recognition and biometric categorisation systems**: deployers must inform the natural persons exposed to the system's operation, and comply with applicable personal data processing requirements. - **Deepfakes and AI-generated text published on matters of public interest**: deployers must disclose that the content has been artificially generated or manipulated. Exemptions exist where use is authorised by law to detect, prevent, or investigate criminal offences, where content undergoes human editorial review with editorial responsibility, or for works that are manifestly artistic, creative, satirical, or fictional — subject to appropriate disclosure safeguards. ## What this means in practice The guidelines do not change the text of Article 50 itself, but they clarify how the Commission expects national market surveillance authorities to interpret and enforce these obligations consistently. For organizations building or deploying AI systems in the EU, this means: - Checking, before 2 August 2026, whether any deployed system falls into one of the four categories above — irrespective of its risk classification under Title III. - Documenting how end users are informed (in-interface disclosures, content labelling, notices). - Aligning this compliance work with the **Code of Practice on transparency for AI-generated content**, which the Commission references as a complementary benchmark for labelling synthetic content. The compressed timeline — guidance published less than two weeks before the obligation takes effect — means compliance teams should treat this as an immediate priority alongside ongoing Annex III and GPAI workstreams. For more detail, see our dedicated pages on [transparency obligations](/en/transparency-obligations/) and [providers vs. deployers](/en/providers-vs-deployers/). ## Official source European Commission — [Guidelines on transparency obligations for providers and deployers of certain AI systems](https://digital-strategy.ec.europa.eu/en/library/guidelines-transparency-obligations-providers-and-deployers-ai-systems), published 20 July 2026. -------------------------------------------------------------------------------- ## EU AI Act Analysis — Enforcement, Deadlines and Regulatory Change URL: https://www.regulation-ai.eu/en/blog/ Dated analysis of EU AI Act developments — Commission guidance, enforcement milestones and amendments to the compliance timeline. Each entry states what changed, who it binds, and the deadline that follows from it. For the standing legal position rather than a specific development, start with the [AI Act deadline tracker](/en/deadlines/) or the [compliance checklist](/en/compliance-checklist/). ## Latest analysis ### [The Marking Reprieve Is Closing: What Providers Are Doing With Their Older Models](/en/blog/marking-older-models-december-deadline/) **8 September 2026** — Generative AI systems already in service before 2 August 2026 must mark their outputs by 2 December. Anthropic is the first provider to date its migration model by model, starting with Claude Opus 5 on 9 September. Where the other providers stand, the difference between the two codes of practice, and what a deployer should demand in writing before the deadline. ### [AI Watermarking: What's Been Deployed, the Results So Far, and the Consequences](/en/blog/ai-watermarking-deployment-results-consequences/) **22 August 2026** — SynthID, C2PA and Content Credentials are now deployed at scale by Google, OpenAI, Adobe, Meta and Microsoft. Independent research shows every current watermarking technique can be defeated by a determined actor — what that means for Article 50 compliance and for anyone judging whether content can be trusted. ### [EU AI Act Enforcement Has Started: What Changed on 2 August 2026](/en/blog/eu-ai-act-enforcement-august-2026/) **4 August 2026** — The Article 50 transparency obligations became directly applicable and the Commission's AI Office gained the power to fine general-purpose AI providers up to 3% of global turnover. The high-risk regime did not arrive. A grace period on machine-readable marking closes on 2 December 2026, and a new Article 5 prohibition becomes enforceable on the same date. ### [European Commission Publishes Guidelines on AI Act Transparency Obligations](/en/blog/european-commission-transparency-obligations-guidelines-ai-act/) **21 July 2026** — The Commission published guidelines on the Article 50 transparency obligations less than two weeks before they entered into application, clarifying how national market surveillance authorities are expected to interpret the four disclosure duties. ## Where to go next - [AI Act deadline tracker](/en/deadlines/) — every date, with original and revised deadlines side by side - [Digital Omnibus analysis](/en/omnibus/) — what Regulation (EU) 2026/1744 changed - [Transparency obligations (Art. 50)](/en/transparency-obligations/) — scope, exemptions, and who owes what - [Penalties](/en/penalties/) — the fine tiers and how they are calculated - [AI Act vs DORA vs NIS2](/en/ai-act-vs-dora-vs-nis2/) — overlapping obligations for regulated entities -------------------------------------------------------------------------------- ## The Marking Reprieve Is Closing: What Providers Are Doing With Their Older Models URL: https://www.regulation-ai.eu/en/blog/marking-older-models-december-deadline/ Since 2 August 2026, every model provider has managed to announce that its **new** models mark their outputs. That was the easy part: a model born under the rule is born marked. The question almost nobody asks concerns the models **already in service** — the ones thousands of companies wired into their products before the obligation existed, and for which the Regulation grants only a reprieve. That reprieve closes on **2 December 2026**. As this article is published, less than three months remain. And one provider has just put dates on its migration, model by model. For the full legal framework, see our page on the [Article 50 transparency obligations](/en/transparency-obligations/). For the technology of marking and its demonstrated limits, see our analysis of [watermark deployment](/en/blog/ai-watermarking-deployment-results-consequences/). This article is about something else: the existing fleet, and what a deployer should be demanding from a provider before December. ## What the reprieve covers — and what it does not Article 50(2) of Regulation (EU) 2024/1689 requires providers of generative AI systems to mark their outputs in a machine-readable format, detectable as artificially generated or manipulated. That obligation has applied since 2 August 2026. The **Digital Omnibus** — Regulation (EU) 2026/1744, in force since 27 July 2026 — carved out a narrow exception: generative AI systems **already placed on the Union market before 2 August 2026** get four additional months, until **2 December 2026**, to satisfy that single marking duty. Three points decide your actual exposure. **The reprieve covers marking only.** The other three Article 50 duties have applied since 2 August with no delay whatsoever: telling people they are interacting with a conversational system, informing people subject to emotion recognition or biometric categorisation, and labelling deepfakes and text published on matters of public interest. A company that believes it is covered until December for the whole of Article 50 is wrong about three obligations out of four. **The test is when the system was placed on the market, not when you integrated it.** A pre-August model you wire into your product today is still a pre-August model: the delay belongs to its provider, and it is the provider who must have closed it by December. **The obligation falls on the provider of the generative system**, not on you as an integrator — until the point at which you become the provider yourself, notably by putting your own mark on the system or substantially modifying it. Our guide to [third-party AI obligations](/en/third-party-ai/) covers that shift in detail. But even as a pure deployer, your product inherits a dependency: if the model you consume does not mark its outputs in December, it is your product that ships unmarked content. ## The first dated migration schedule At **Anthropic**, models launched on or after 2 August 2026 mark their outputs from the moment they enter service. The Claude Platform release notes of 1 September 2026 confirm this for Claude Fable 5.1 and Claude Mythos 5.1: text carries the house watermark, and image, video and audio files produced through the code execution tool carry C2PA Content Credentials when retrieved through the Files API. That left the older fleet. According to a **notice sent to Claude Platform customers**, seen by this publication and not publicly reported to date, Anthropic is extending its text watermark to **Claude Opus 5 outputs from 9 September 2026**. It is the first pre-application model to be caught up; the other models in service are to follow over the coming weeks, with each change announced in advance. The move is presented explicitly as getting ahead of the December deadline, so that marking is already in place for customers working through obligations of their own. Four technical properties matter to anyone integrating these models. - **The mark is applied at the model layer.** It therefore holds everywhere the model is served — Amazon Web Services, Google Cloud and Microsoft Foundry included. This is the legally significant property: the mark travels with the model, including through a cloud reseller, and does not depend on the interface you reach it through. - **The pattern is statistical**, carried in word choice. It adds no characters and no tokens, changes neither meaning nor readability, and has no effect on pricing, latency, or request and response formats. - **The mark carries no information** about the user, their organisation, or their conversations. That is the first objection compliance teams and data protection officers raise; it is answered at source. - **No action is required on the customer side.** The switch is transparent to existing integrations. That last point is worth stating for what it implies in reverse: a well-designed marking migration should not break an integration. If a provider tells you otherwise, the question to ask is which layer the mark is applied at. ## Where the other providers stand | Provider | New models | Older fleet | Text marking | |---|---|---|---| | **Google** | Marked | **Already marked** — SynthID deployed on images since 2023, extended to text and video in 2024 | Yes | | **Anthropic** | Marked since 2 August 2026 | **Dated migration** — Opus 5 on 9 September, others announced in advance | Yes | | **OpenAI** | Images and audio marked | Images marked since 2024 (C2PA), invisible watermark added in 2026; audio extended 31 July 2026 | **No** — method built, never deployed, no announced date | | **Meta** | C2PA, proprietary image and audio marking, visible label | Progressive rollout across consumer products | Not documented | | **Microsoft** | C2PA Content Credentials on Designer and Copilot | — | Not documented | | **Mistral** | Transparency code signatory | No public detail | Not documented | | **xAI** | Visible logo on images | No commitment | **No — signed neither code** | The instructive contrast is not between good and bad pupils but between two strategies. **Google** had no migration to run: it was marking its outputs three years before it had to, and its fleet was compliant before the rule existed. **Anthropic** has the most visible migration because it is the most recent — and because it is being dated publicly, model by model. **OpenAI**, by contrast, signed the code of practice that provides for text marking and still does not mark ChatGPT's text, with no schedule announced. ## Two codes of practice, two lists of signatories This is the most widespread confusion in the analysis published this summer, and it changes how each provider should be judged. The **code of practice on general-purpose AI models**, published in July 2025, covers model safety, security, transparency and copyright. Around thirty providers signed it. **Meta refused to sign**; **xAI signed only its safety and security chapter**. The **code of practice on transparency of AI-generated content** is a separate instrument, published on **10 June 2026**, which the Commission found adequate on **8 July** and the AI Board on **9 July**. The Commission's Article 50 guidelines followed on **20 July**, and the list of signatories was published on **31 July 2026**: roughly **190 organisations**, of which 82 under Section 1 — providers, subject to the marking duties — and 152 under Section 2, the deployers subject to labelling. **Meta signed this second code**, having refused the first. **xAI signed neither.** A non-signatory is not exempt from Article 50: it remains bound by the Regulation, but must build and defend a method of its own and demonstrate that it is as robust as the code — with, on the AI Office's consistent position, a heavier burden of proof and more requests for information. Section 2 signatories include companies well outside the sector: Bulgari, Getty Images, Iberdrola, Lenovo, Lufthansa. A useful reminder that labelling generated content is not an AI-lab problem. ## What a deployer should demand before December If you integrate a third-party model into a product that generates text, images, audio or video, four written requests are worth more than passive monitoring. 1. **The list of models you consume, with the marking status of each.** A provider who cannot answer model by model does not know where it stands. 2. **The dated migration schedule for models predating 2 August 2026.** Anthropic has just established that such a schedule can be communicated in advance, model by model. That is now a precedent you can cite to other providers. 3. **The layer at which marking is applied.** A model-layer mark follows you across every platform serving that model; a mark applied only to the consumer interface does not cover your API calls. 4. **How to obtain detection access.** Detection APIs are, at most providers, in restricted access — reserved for regulators, law enforcement, media, researchers, and companies under a verification obligation of their own. If you are in that last category, ask explicitly. And two checks on your own side: **your processing chain must not destroy the provenance metadata** on files you redistribute — many resizing and compression pipelines strip it by default; and **your status must be settled**, because putting your own mark on a third-party system, or substantially modifying it, makes you the provider, with the obligations that follow. ## What marking does not prove One final caution, to hold in any public communication on the subject. A detected mark means the model **processed** the content — it does not say the model wrote it unaided, or in what proportion. Absence of a mark proves nothing either: the content may come from a model outside the scheme, from a non-compliant provider, from a rewrite deep enough to fall below the detection threshold, or from a file whose metadata was stripped at publication. The independent research on marking robustness, which we set out in [a dedicated analysis](/en/blog/ai-watermarking-deployment-results-consequences/), converges on exactly this point. Marking is a compliance instrument and a provenance signal. It is neither an AI detector nor proof of authorship — and presenting it as either creates exposure of its own. Our [compliance checklist](/en/compliance-checklist/) covers the full set of obligations, and the [deadline tracker](/en/deadlines/) gives the dates that apply to your situation. The text of the obligation is at [Article 50](/en/articles/article-50/), the penalties at [Article 99](/en/articles/article-99/). ## Sources - European Commission — [Code of Practice on Transparency of AI-generated Content](https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content) - European Commission — [Strong backing for the Code of Practice on Transparency of AI-generated Content](https://digital-strategy.ec.europa.eu/en/news/strong-backing-code-practice-transparency-ai-generated-content), 31 July 2026 - Anthropic — [How Claude marks AI-generated content](https://support.claude.com/en/articles/16266773-how-claude-marks-ai-generated-content) - Anthropic — [How Claude's text watermarking works](https://www.anthropic.com/news/claude-text-watermark), 14 August 2026 - Anthropic — notice to Claude Platform customers regarding Claude Opus 5, seen by this publication - OpenAI — [Advancing content provenance for a safer, more transparent AI ecosystem](https://openai.com/index/advancing-content-provenance/) - Google DeepMind — [SynthID](https://deepmind.google/technologies/synthid/) - Regulation (EU) 2024/1689 — [Article 50](https://artificialintelligenceact.eu/article/50/) -------------------------------------------------------------------------------- ## Changes to Regulation (EU) 2024/1689 — the AI Act as it now stands URL: https://www.regulation-ai.eu/en/changes/ Regulation (EU) 2024/1689 entered into force on 1 August 2024. Since then **one act has amended it**: Regulation (EU) 2026/1744, the Digital Omnibus on AI, in force since 27 July 2026. It moved **four application dates** and did nothing else. It created no new obligation, removed none, changed the scope of neither Annex I nor Annex III, and introduced no exemption for any sector or company size. Read as a general reprieve — as it widely has been — it produces exactly the wrong compliance plan, because the Regulation's broadest obligation, the Article 50 transparency duties, kept its date and has been enforceable since 2 August 2026. This page is the complete record. Each of the 113 article pages on this site carries the same status at the top, and [`/api/changes.json`](/api/changes.json) publishes it for machines. ## How to read the dates Three separate things are commonly conflated, so they are worth separating before the tables: - **Entry into force** — when the act became law. For the AI Act, 1 August 2024. For the omnibus, 27 July 2026. - **Application** — when a set of obligations starts to bind. The AI Act applies in phases under Article 113, which is why the same regulation has dates in 2025, 2026, 2027 and 2028. - **Transitional arrangements** — a grace period for systems already on the market when an obligation starts. Only one is live: machine-readable marking, to 2 December 2026. An article is *deferred* only in respect of the systems whose date moved. Articles 8 to 15, for instance, set the requirements for high-risk systems generally: they bite for standalone Annex III systems on 2 December 2027 and for Annex I products on 2 August 2028. Neither date suspends the article for any other purpose. -------------------------------------------------------------------------------- ## EU AI Act Compliance Checklist: Step-by-Step FAQ Guide URL: https://www.regulation-ai.eu/en/compliance-checklist/ This guide answers the compliance checklist question in the order the questions actually arrive: does the Regulation reach me, what already binds me today, which of my systems are high-risk, what do I have to produce, and what does that cost me if I get it wrong. Every answer is scoped to a legal basis you can cite in an internal memo. Interactive tool: Use the AI Act Compliance Checker to get a personalised checklist and compliance score for your specific role and AI system type. ## Who has to run this checklist? **Any organisation that develops, deploys, imports or distributes an AI system used in the EU — regardless of where it is established.** Art. 2 reaches non-EU providers and deployers whenever the output produced by the system is used in the Union, which is why a US SaaS vendor with European customers is in scope on the same terms as a Frankfurt bank. Four things determine your obligation set, and you need all four before the checklist means anything: | Question | Determines | |---|---| | Did you build it, or do you use someone else's? | Provider or deployer (Art. 3, Art. 25) | | Is it an AI system, or a general-purpose AI model? | Chapter III or Chapter V | | Which Annex III or Annex I category does it fall in? | High-risk or not (Art. 6) | | Does it interact with people or generate content? | Art. 50 transparency, independent of risk tier | The last row is the one most inventories miss. Transparency duties attach to systems that are not high-risk at all — a customer-service chatbot on a marketing site carries an obligation today, and carried none of the conformity burden this checklist spends most of its time on. ## Which obligations already bind you, and which are still ahead? **Four of the nine application dates have passed; the heavy conformity work lands in December 2027.** The dates below follow the [deadline dataset](/deadlines/) this site publishes, which reflects the deferrals made by Regulation (EU) 2026/1744. | Obligation | Applies from | Status | |---|---|---| | Prohibited practices (Art. 5) | 2 February 2025 | In force | | AI literacy (Art. 4) | 2 February 2025 | In force | | GPAI model obligations (Chapter V) | 2 August 2025 | In force | | Transparency obligations (Art. 50) | 2 August 2026 | In force | | Commission enforcement over GPAI (Art. 101) | 2 August 2026 | In force | | Marking of pre-existing generative systems | 2 December 2026 | Upcoming | | Prohibition on generated CSAM / NCII | 2 December 2026 | Upcoming | | Regulatory sandboxes operational | 2 August 2027 | Upcoming | | High-risk — Annex III standalone systems | 2 December 2027 | Upcoming | | High-risk — Annex I embedded systems | 2 August 2028 | Upcoming | The [Digital Omnibus](/omnibus/) moved four of these dates and rewrote Art. 4; the full before-and-after register is published at [/changes/](/changes/). It removed no obligation and created no exemption, so a programme built on the original dates is still the right programme — it simply has more runway. ## Step 1 — Is your AI inventory complete? **Without a complete inventory, nothing downstream is defensible.** Create a register of every AI system your organisation touches: - AI systems you **develop and sell or license** (you are the provider) - AI systems you **purchase or license and use internally** (you are the deployer) - AI systems **embedded in products** you manufacture or import - AI systems accessed via **API** from third parties (cloud AI, foundation model APIs) For each: document the system name, function, data inputs and outputs, use context, decision impact, and affected population. Flag systems where you are uncertain of classification — these need legal review rather than an engineering answer. Two categories are systematically under-counted: AI features shipped inside SaaS tools the business already pays for, and models built by individual teams outside the procurement process. Ask finance for the vendor list and engineering for the model registry; the union of the two is closer to the truth than either. ## Step 2 — Is anything you run already illegal? **Check Art. 5 before any risk classification, because a prohibited system cannot be remediated into compliance.** Assess each system against the list: - Subliminal, manipulative or deceptive techniques that materially distort behaviour - Exploitation of vulnerabilities due to age, disability, or social or economic situation - Social scoring leading to detrimental treatment in unrelated contexts - Untargeted scraping of facial images to build recognition databases - Emotion inference in the workplace or in education - Biometric categorisation to infer sensitive characteristics - Real-time remote biometric identification in public spaces for law enforcement → **Decommission or fundamentally redesign.** These prohibitions have applied since 2 February 2025 and sit in the €35 million / 7% penalty tier. The [prohibited practices guide](/prohibited-practices/) covers the narrow exceptions that exist for each. From 2 December 2026 a further prohibition covers AI systems generating child sexual abuse material or non-consensual intimate imagery. ## Step 3 — Do you provide a general-purpose AI model? **If your organisation develops and releases a foundation model, Chapter V obligations have applied since 2 August 2025.** Three tests: - Is the model trained with self-supervision at significant scale? - Is it capable of competently performing a wide range of distinct tasks? - Is it made available to others, rather than used purely internally? If yes, prepare model documentation for the AI Office and for downstream providers, a copyright policy, and a sufficiently detailed public summary of training content. Above 10²⁵ FLOPs of training compute the model is presumed to carry systemic risk, adding model evaluation, adversarial testing, incident reporting and cybersecurity duties. See the [GPAI obligations guide](/gpai/) for the full split. Since 2 August 2026 the Commission — not national authorities — enforces this chapter directly, with fines up to €15 million or 3%. ## Step 4 — Which of your systems are high-risk? **Classify against Annex III and Annex I, then apply the Art. 6(3) filter and write the result down.** [Annex III](/annex-iii/) lists eight standalone categories: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services, law enforcement, migration and border control, and administration of justice. [Annex I](/annex-i/) catches AI acting as a safety component in products already regulated under EU product-safety law. The Art. 6(3) exception releases a system that falls in an Annex III category but poses no significant risk — narrow procedural tasks, improving the output of a completed human activity, detecting decision patterns without replacing the human assessment, or purely preparatory work. It never applies where the system profiles natural persons. The assessment must be documented before market placement, and the system still has to be registered. Classification decisions are the single most audited artefact in this checklist. Record the category considered, the reasoning, the evidence, the date and the person accountable. ## Step 5 — Are you the provider or the deployer of each system? **The role determines roughly 80% of the workload, and it is not fixed by procurement.** Under Art. 25 you become the provider of a high-risk system you did not build if you put your name or trademark on it, substantially modify it, or repurpose it so that it becomes high-risk. Fine-tuning a vendor model on your own data and shipping it under your own brand is the standard way an organisation acquires provider obligations it never budgeted for. | | Provider | Deployer | |---|---|---| | Risk management (Art. 9) | Required | — | | Data governance (Art. 10) | Required | Input data relevance only | | Technical documentation (Annex IV) | Required | — | | Conformity assessment + CE marking | Required | — | | EU database registration | Required | Public bodies register their use | | Human oversight | Design it (Art. 14) | Operate it (Art. 26) | | Log retention | Enable (Art. 12) | Keep ≥ 6 months (Art. 26) | | FRIA (Art. 27) | — | Public bodies, credit, insurance | | Incident reporting | Art. 73 | Notify provider + authority | The [provider vs deployer guide](/providers-vs-deployers/) works through the boundary cases, including importers and distributors, who carry verification duties rather than conformity duties. ## Steps 6 to 10 — What does the high-risk programme actually produce? **Six artefacts, in dependency order.** Each one is the input to the next, which is why a programme that starts with documentation and works backwards to governance stalls. 1. **Quality management system (Art. 17)** — policies, responsibilities, change control, data management, post-market monitoring and incident procedures. The QMS is what a market surveillance authority asks for first. 2. **Risk management records (Art. 9)** — the iterative identification, estimation and mitigation cycle, run across the lifecycle rather than signed off once. 3. **Data governance evidence (Art. 10)** — provenance, representativeness, bias examination and mitigation for training, validation and test sets. 4. **Annex IV technical file** — the document set described in the [technical documentation guide](/technical-documentation/), including testing results against the accuracy, robustness and cybersecurity requirements of Art. 15. 5. **Conformity assessment and declaration** — self-assessment under Annex VI, or a notified body where biometrics or Annex I product legislation require it. See the [conformity assessment guide](/conformity-assessment/). 6. **Registration, CE marking and post-market monitoring** — EU database entry before market placement, CE marking on the documentation, then the ongoing [post-market monitoring](/post-market-monitoring/) plan and serious-incident reporting under Art. 73. Target 2 December 2027 for standalone Annex III systems and 2 August 2028 for Annex I embedded systems. A realistic programme for a single high-risk system runs 12 to 24 months, so a start in late 2026 is inside the window with no slack — and notified-body capacity will tighten as the date approaches. ## What if you only use other people's AI? **You are a deployer, and your checklist is short but not empty.** Most organisations sit here: no models built, a dozen AI features consumed through SaaS and APIs. - **Art. 4 AI literacy** applies now, to every deployer, at every risk tier. - **Art. 50 transparency** applies now to what your users see: chatbot disclosure, deepfake labelling, marking of AI-generated text published to inform the public. - **Art. 26 deployer obligations** apply from 2 December 2027 wherever the use case sits in an Annex III category — recruitment screening, credit decisions, worker management. - **Art. 25** is the trap: the moment you rebrand or substantially modify, you inherit the provider set. The practical control is vendor due diligence: obtain the provider's declaration of conformity, instructions for use, and the information Art. 13 requires them to supply. The [third-party AI guide](/third-party-ai/) sets out what to demand contractually. ## What changes by sector? **The obligations are identical; the classification results and the overlapping regimes are not.** - **Financial services** — credit scoring and insurance pricing are Annex III, and deployers there owe a FRIA under Art. 27. DORA's ICT risk management partly satisfies the AI Act's risk management article but does not cover AI-specific data governance or human oversight. Design one incident workflow that satisfies DORA Art. 19 and AI Act Art. 73 together. See the [financial sector guide](/financial-sector/) and the [DORA / NIS2 convergence guide](/ai-act-vs-dora-vs-nis2/). - **Healthcare and medical devices** — AI as a safety component of an MDR/IVDR device is Annex I, applying from 2 August 2028. The existing technical file and ISO 13485 QMS are the foundation; they must be extended to Chapter III requirements, and your notified body needs a separate AI Act designation. - **HR and recruitment** — Annex III employment category. Bias examination under Art. 10 is the primary exposure, transparency to candidates is a deployer duty, and no final employment decision may rest on the system without a human able to override it. - **Public sector** — FRIA is mandatory, and deployers register their use of Annex III systems in the EU database. The [sector guides](/sectors/) work through nine industries in the same structure. ## What does non-compliance cost? **Three tiers, and the one that matters most for ordinary businesses is the middle one.** Art. 99 sets €35 million or 7% of worldwide turnover for the Art. 5 prohibitions, €15 million or 3% for most other obligations — including Art. 50 transparency and the whole high-risk set — and €7.5 million or 1% for misleading information supplied to authorities. SMEs are capped at whichever figure is lower. The third tier deserves attention out of proportion to its size: it punishes a bad answer to a regulator independently of any underlying breach. Documentation is what converts a defensible position into a demonstrable one. The [penalties guide](/penalties/) works through the exposure calculation. ## What to do in the next 90 days 1. Close the inventory gap — finance vendor list ∪ engineering model registry. 2. Screen everything against Art. 5. This is the only step with an in-force 7% tier attached. 3. Ship Art. 50 disclosures on anything user-facing; the obligation is live, not upcoming. 4. Evidence Art. 4 literacy: who was trained, on what, when. The [AI literacy guide](/ai-literacy/) sets out what the rewritten article now requires. 5. Classify the Annex III candidates and write down the reasoning, including the Art. 6(3) calls. 6. For each confirmed high-risk system, start the QMS. December 2027 is the constraint, and the queue at notified bodies is ahead of you, not behind. Working templates for the inventory, risk register, technical file and vendor due-diligence set are in the [compliance toolkits](/toolkits/); the [AI Act Academy](/academy/) covers the same ground as structured training with certification. -------------------------------------------------------------------------------- ## EU AI Act Conformity Assessment: Routes, Notified Bodies and CE Marking URL: https://www.regulation-ai.eu/en/conformity-assessment/ ## Conformity assessment is the gate, not the goal For a high-risk AI system, conformity assessment is the procedure that lets you place the system on the EU market lawfully. It does not create the requirements — those come from Chapter III, Section 2 — it verifies that you have met them and produces the paper trail. The sequence is always the same: 1. Meet the substantive requirements (Art. 9–15) — see [high-risk obligations](../high-risk/). 2. Run the applicable conformity assessment procedure. 3. Draw up the **EU declaration of conformity** (Art. 47). 4. Affix the **CE marking** (Art. 48). 5. **Register** in the EU database (Art. 49). 6. Keep documentation for **10 years** and run post-market monitoring. Skipping straight to step 2 is the most common failure mode. There is nothing to assess until the Article 9–15 work is done. ## Which route applies | Your system | Route | Third party involved? | |---|---|---| | Annex III, **not** biometrics | Internal control (Annex VI) | No | | Annex III **biometrics**, harmonised standards applied in full | Internal control (Annex VI) | No | | Annex III **biometrics**, standards not applied or applied partially | Quality management system + technical documentation assessment (Annex VII) | **Yes — notified body** | | Annex I embedded product | The procedure already required by the relevant product legislation | As required by that legislation | | Public authority / EU institution as provider of an Annex III system | The market surveillance authority acts in the role otherwise held by the notified body | Special arrangement | The practical consequence is that **most Annex III providers self-assess**. The notified-body route is the exception, concentrated on biometrics — and even there, applying harmonised standards in full returns you to internal control. That is a strong commercial argument for tracking the standards as they are published. ## What internal control actually requires Annex VI is short, and its brevity is misleading. The provider must verify that: - the **quality management system** conforms to Article 17 - the **technical documentation** is examined and demonstrates conformity with Article 9–15 - the **design and development process** and the **post-market monitoring** in Article 72 are consistent with that documentation No one external checks this. But the market surveillance authority can demand all of it, and supplying incorrect or incomplete information carries its own penalty tier — €7.5 million or 1% of turnover under [Article 99](../penalties/). Self-assessment lowers the process cost, not the evidentiary standard. ## The quality management system Article 17 is where many providers underestimate the workload. The QMS must be documented in written policies and procedures covering, among other things: - a regulatory compliance strategy, including for conformity assessment and change management - design, design control and design verification procedures - development, quality control and quality assurance procedures - examination, test and validation procedures, including the frequency at which they run - technical specifications and the standards applied - systems for data management across the whole data lifecycle - the risk management system of Article 9 - post-market monitoring under Article 72 - incident reporting procedures under Article 73 - communication with authorities and notified bodies - record-keeping - resource management, including security-of-supply - an accountability framework defining management and staff responsibilities Providers already operating an ISO 9001 or ISO/IEC 42001 management system can extend it rather than build in parallel — but the AI-specific elements, particularly data management and Article 9 risk management, rarely exist already. ## When you must reassess A conformity assessment is not a one-off. A **substantial modification** requires a fresh assessment. Under the AI Act a change is not substantial if it was pre-planned and documented in the original technical documentation — including for systems that continue to learn after being placed on the market, provided the change stays within the pre-determined envelope. The design implication is direct: define the intended change envelope **in the initial technical documentation**, or every model update becomes a substantial modification. Note also that a deployer can trigger the obligation. Under [Article 25](../articles/article-25/), putting your name on a system, substantially modifying it, or changing its intended purpose so it becomes high-risk makes you the provider — with the full conformity assessment duty. See [providers vs deployers](../providers-vs-deployers/). ## Declaration, marking and registration **EU declaration of conformity (Art. 47)** — drawn up by the provider, kept for 10 years, machine-readable where relevant, naming the system, the provider, the standards applied and the procedure followed. Where the system falls under several Union acts, a single declaration covers them all. **CE marking (Art. 48)** — affixed visibly, legibly and indelibly, or digitally where the system is supplied digitally, provided it is easily accessible. Where a notified body was involved, its identification number accompanies the marking. **Registration (Art. 49)** — providers register Annex III systems in the EU database before placing them on the market. Providers relying on the [Article 6(3) exception](../high-risk/) register too, which is what makes the exception auditable. Deployers that are public authorities also register their use. ## Timing Following the 2026 [Digital Omnibus](../omnibus/), the obligations apply from **2 December 2027** for Annex III stand-alone systems and **2 August 2028** for Annex I embedded systems. Those dates are the deadline for being *assessed and marked*, not for starting. A quality management system, an Annex IV documentation set and a validation programme are multi-quarter undertakings, and notified body capacity for the biometrics route is finite. Work backwards from the [full timeline](../deadlines/), and use the [conformity selector](../tools/conformity-selector/) to identify your route. -------------------------------------------------------------------------------- ## EU AI Act Compliance Deadlines — Complete Timeline 2025–2028 URL: https://www.regulation-ai.eu/en/deadlines/ > **Update — 2 August 2026.** Transparency obligations and Commission enforcement powers over GPAI models are now in force. Next deadline: **2 December 2026**. See [what changed on 2 August 2026](/en/blog/eu-ai-act-enforcement-august-2026/). ## AI Act compliance timeline: what applies when The EU AI Act entered into force on 1 August 2024. Application is phased: the prohibited practice bans came first, then GPAI rules, with high-risk AI obligations last. The 2026 Digital Omnibus extended the high-risk deadlines but left everything else unchanged. **Reading the table:** "Original date" = what was in the 2024 Act. "New date" = post-omnibus. Where they are the same, no extension was granted. What moved those dates is a single act: Regulation (EU) 2026/1744. The [full amendment record](/en/changes/) sets out each of the four changes with its legal basis, and states article by article which of the 113 were touched. ## Already in force — act now These obligations are not deferred and enforcement is live: **Prohibited practices (Art. 5) — since 2 February 2025.** Any AI system that manipulates users subliminally, exploits vulnerabilities, performs social scoring for public authorities, conducts real-time biometric identification in public spaces (with narrow law enforcement exceptions), or generates NCII/CSAM is banned. Fines: up to €35 million or 7% of global annual turnover. **GPAI model rules (Chapter 5) — since 2 August 2025.** All providers of general-purpose AI models (including open-source models above the threshold) must maintain technical documentation, provide summaries of training data, and comply with copyright law. Models with systemic risk (>10²⁵ FLOPs training compute) face additional adversarial testing and incident reporting obligations. **Transparency for AI-generated content — since 2 August 2025.** Providers of GPAI systems that generate synthetic audio, video, image, or text content must mark that content as AI-generated. This applies to chatbots (must disclose AI nature), deepfake generators, and synthetic media tools. ## Upcoming deadlines: prepare now **2 December 2027 — High-risk AI, Annex III standalone systems.** Providers must have completed conformity assessments, implemented a QMS, compiled technical documentation, registered in the EU AI database, and affixed CE marking. Deployers must have implemented human oversight and (for public bodies) completed fundamental rights impact assessments. **2 August 2028 — High-risk AI, Annex I embedded.** AI safety components embedded in products under existing EU product safety legislation (medical devices, machinery, aviation, toys) must comply via the existing conformity assessment pathway for that product. -------------------------------------------------------------------------------- ## EU AI Office: Mandate, Powers, and Role in AI Act Enforcement URL: https://www.regulation-ai.eu/en/eu-ai-office/ ## What Is the EU AI Office? The **EU AI Office** (formally: Office for Artificial Intelligence) is the EU-level body established within the European Commission to oversee the implementation and enforcement of the EU AI Act — with a specific mandate covering **general-purpose AI (GPAI) models**. Unlike traditional EU agencies (such as ENISA or EBA), the AI Office is not an independent regulatory authority. It is structured as an administrative office within the Directorate-General for Communications Networks, Content and Technology (DG CONNECT). This structure gives it direct access to Commission resources and agenda-setting, but also means its enforcement decisions are technically Commission decisions subject to EU judicial review. The AI Office was created early — established formally in **February 2024**, several months before the AI Act was published in the Official Journal (July 2024) and entered into force (August 2024). This early establishment was deliberate: GPAI regulation is time-sensitive given the pace of foundation model development, and the Commission wanted enforcement infrastructure ready before the most urgent obligations kicked in. ## Legal Basis and Mandate The EU AI Office's legal basis is **Chapter VIII of the EU AI Act (Art. 64–68)**, supplemented by the Commission Decision of 24 January 2024 that formally established it. Its core mandate covers three areas: ### 1. GPAI Model Oversight (Direct Enforcement) The AI Office has **exclusive EU-level competence** for overseeing providers of general-purpose AI models. This includes: - Monitoring compliance with Chapter V obligations (transparency, technical documentation, copyright compliance, energy efficiency reporting for systemic-risk models) - Requesting and reviewing technical documentation from GPAI providers - Conducting evaluations of GPAI models — including adversarial testing and red-team exercises — to assess capabilities and systemic risks - Issuing alerts when a GPAI model poses systemic risk - Imposing fines and corrective measures ### 2. Cross-Border Coordination (High-Risk AI Systems) For high-risk AI systems, enforcement is primarily national. But the AI Office plays a key coordination role: - Facilitating information exchange between national market surveillance authorities (MSAs) - Handling cases where a non-compliant high-risk AI system circulates across multiple member states - Providing technical expertise and guidance to national authorities - Requesting joint investigations where cross-border impact is significant ### 3. Scientific and Technical Support The AI Office operates a **Scientific Advisory Board** composed of independent AI experts (Art. 68). This board provides: - Technical assessments of GPAI model capabilities and risks - Advice on classification thresholds (e.g., the compute threshold for systemic-risk GPAI models) - Input into the development of standards, codes of conduct, and evaluation methodologies ## Investigative and Enforcement Powers The EU AI Office has significant investigative powers over GPAI model providers, including: ### Information Requests The AI Office may request any information from a GPAI provider that it deems necessary for its oversight tasks (Art. 91). Providers must respond within the timeframe set by the Office. Failure to provide information, or providing false or misleading information, is itself a sanctionable offence. ### Evaluations and Testing The AI Office can request that a GPAI provider submit its model for evaluation, including: - Capability assessments (identifying dangerous capabilities such as CBRN assistance, cyberattack facilitation, or manipulation at scale) - Safety and alignment evaluations - Adversarial testing / red-teaming The Office can conduct evaluations itself, or commission them to qualified third parties or national authorities. The AI Act requires GPAI providers with systemic-risk models to provide access to their models for evaluation purposes. ### On-Site Inspections For systemic-risk GPAI models, the AI Office may conduct on-site inspections of the provider's facilities, with the assistance of national authorities in the member state concerned. Prior notice is generally required unless the Office has specific grounds to believe that prior notice would prejudice the investigation. ### Interim Measures Where there is an urgent risk, the AI Office can impose provisional interim measures to prevent serious and irreparable harm. These measures must be proportionate and are subject to review. ### Fines Fines are structured in three tiers: | Violation | Maximum Fine | |---|---| | GPAI obligations non-compliance (Chapter V) | €15M or 3% global annual turnover | | Providing incorrect/incomplete information | €7.5M or 1.5% global annual turnover | | Systemic-risk GPAI obligations non-compliance | €30M or 6% global annual turnover | | General violations applicable to all entities | €35M or 7.5% (prohibited practices) | For SMEs and startups, the lower of the fixed amount or the turnover percentage applies. The AI Office must take into account the nature, gravity, duration, and consequences of the infringement, as well as cooperation levels shown by the provider. ## The GPAI Code of Practice A key instrument of the AI Office is the **GPAI Code of Practice** — a technical voluntary instrument developed through a multi-stakeholder process that translates the Act's Chapter V obligations into concrete implementation guidance. The Code of Practice process began in October 2024, with the AI Office convening working groups of GPAI providers, academic researchers, civil society organisations, and national authorities. It covers: - Transparency obligations for GPAI providers (training data summaries, capability documentation) - Copyright compliance procedures - Model evaluation methodologies for systemic-risk assessment - Safety and security standards for systemic-risk GPAI models Compliance with the Code of Practice creates a **presumption of conformity** with the corresponding Chapter V obligations. This is a significant benefit: providers who follow the Code can rely on it in enforcement proceedings rather than having to demonstrate compliance from scratch. ## The AI Board The **AI Board** (Art. 65) operates in parallel with the AI Office. It is composed of: - One representative per EU member state (national supervisory authorities) - A representative of the European Data Protection Supervisor (EDPS) - A Commission representative (non-voting chair) The AI Board's functions include: - Issuing opinions and recommendations to the AI Office and Commission - Coordinating national supervisory approaches - Advising on the classification of AI systems and models - Contributing to the development of standards and evaluation methodologies The Board is an advisory and coordination body — it does not have direct enforcement authority. However, its opinions carry significant weight and the AI Office is expected to take them into account. ## National Market Surveillance Authorities For high-risk AI systems (not GPAI models), **national market surveillance authorities (MSAs)** are the primary enforcement bodies. Each member state must designate at least one MSA responsible for AI Act enforcement on its territory. MSAs have authority to: - Conduct market surveillance activities - Request technical documentation and access logs from providers and deployers - Order corrective measures (withdrawal, recall, restriction of market access) - Impose fines under national implementing legislation The AI Office coordinates with MSAs through the AI Board and through bilateral cooperation, but does not command them. Member states are responsible for resourcing and empowering their MSAs. ## Practical Implications for GPAI Providers If you are developing or deploying a general-purpose AI model accessible in the EU market, the EU AI Office is your primary regulatory counterpart. Practically, this means: 1. **Register and document proactively** — the AI Office expects providers to have technical documentation ready before being asked. Scrambling to prepare documentation after an inquiry is not a strong compliance posture. 2. **Engage with the Code of Practice** — participation in the GPAI Code of Practice process, and adoption of its provisions, creates a presumption of conformity and demonstrates good faith to the AI Office. 3. **Know your systemic-risk status** — the current threshold for systemic-risk classification is training compute exceeding 10^25 FLOPs. If your model is close to or above this threshold, engage with the AI Office proactively about evaluation obligations. 4. **Prepare for evaluations** — if you develop a GPAI model with systemic risk, you must be able to provide model access for evaluation. This requires technical infrastructure for controlled API access, adversarial testing cooperation, and documentation of red-teaming results. 5. **Monitor alerts and opinions** — the AI Office publishes guidance, alerts, and opinions on its website. These are not binding regulations, but they signal enforcement priorities and interpretive positions that will shape investigations. -------------------------------------------------------------------------------- ## EU AI Act in the Financial Sector: Banks, Insurers, and Credit Institutions URL: https://www.regulation-ai.eu/en/financial-sector/ ## The AI Act Comes to Finance Financial institutions — banks, insurers, asset managers, payment providers, credit bureaux — are among the most intensive users of AI in Europe. Credit scoring, fraud detection, algorithmic trading, customer risk profiling, insurance underwriting, regulatory reporting automation, and AML/KYC screening all rely on AI systems that may be subject to the EU AI Act. For financial institutions, the EU AI Act does not arrive in isolation. It layers on top of an already dense regulatory stack: DORA (digital resilience), MiFID II (investment services), GDPR (data protection), CRR/CRD (capital requirements), Solvency II (insurance), PSD2/PSD3 (payment services), and sectoral EBA, EIOPA, and ESMA guidelines. Understanding how the AI Act integrates with — and sometimes conflicts with — existing financial regulation is essential for efficient compliance. ## Which AI Use Cases Are High-Risk in Finance? The EU AI Act's Annex III identifies use cases that are automatically high-risk. In the financial sector, the most directly relevant are: ### Category 5(b): Creditworthiness Assessment **High-risk.** AI systems used to evaluate the creditworthiness of natural persons or to classify natural persons in terms of credit risk are explicitly listed. This covers: - Automated credit scoring for consumer loans, personal overdrafts, credit cards, and mortgages - Models that assess repayment probability, default risk, or debt capacity of individual consumers - AI systems that recommend credit limits or loan amounts based on individual risk assessment **Not automatically covered:** Corporate credit models assessing legal entities rather than natural persons, though these may still trigger Art. 50 transparency obligations depending on deployment. ### Category 5(b): Insurance Premium and Coverage Decisions **High-risk if affecting natural persons significantly.** AI systems that make or strongly influence decisions about: - Insurance coverage (acceptance or rejection of applicants) - Premium levels (actuarial models that set individual premiums) - Claim assessment and settlement (automated claim handling) Motor insurance pricing models, health insurance underwriting, and property insurance models for households are directly in scope. The determining factor is whether the AI system makes or significantly influences a decision that materially affects a natural person's access to an essential private service. ### Category 1: Biometric Identification **High-risk.** AI systems used for: - Remote biometric identification of customers (KYC video verification, continuous authentication) - Biometric categorisation where it influences risk classification or service access Real-time biometric identification in publicly accessible spaces for law enforcement is prohibited under Art. 5. Commercial identity verification systems using facial recognition for KYC are subject to high-risk requirements but not prohibited. ### Category 6: AML/KYC and Law Enforcement Adjacent AI systems used by financial institutions to support AML/KYC screening, sanctions filtering, or transaction monitoring **where the outcome is reported to or used by law enforcement** may fall within Annex III category 6 (law enforcement). This includes: - AI-generated Suspicious Activity Reports (SARs) transmitted to FIUs - Automated PEP (Politically Exposed Person) screening systems Systems used purely for internal risk management without law enforcement output are less likely to be classified as high-risk under category 6, though other categories may apply. ## What High-Risk AI Obligations Mean for Financial Institutions If an AI system used by a financial institution is high-risk under Annex III, the obligations differ depending on whether the institution is a **provider** (built the system) or **deployer** (purchased or licensed it). ### If You Are the Provider (Built the System) - **Risk management system (Art. 9):** Establish and maintain a documented risk management process iterating throughout the system lifecycle - **Data governance (Art. 10):** Training, validation, and testing data must be subject to governance practices covering relevance, representativeness, and bias assessment - **Technical documentation (Annex IV):** Full technical file including system description, architecture, training approach, performance metrics, and post-market monitoring plan - **Transparency (Art. 13):** Instructions for use enabling deployers to understand capabilities, limitations, and oversight requirements - **Human oversight (Art. 14):** Design measures enabling human oversight and intervention - **Accuracy, robustness, cybersecurity (Art. 15):** Demonstrated performance levels and resilience - **Conformity assessment:** Self-assessment (Annex VI) for most Annex III systems, or notified body assessment for biometric systems - **CE marking and EU declaration of conformity** - **Registration in EU AI database** - **Post-market monitoring (Art. 72):** Active system for collecting real-world performance data and incident reporting ### If You Are the Deployer (Purchased/Licensed the System) - **Instructions compliance:** Use the system strictly in accordance with the provider's instructions - **Human oversight:** Assign qualified personnel to perform oversight with appropriate authority and resources - **Input data quality:** Ensure input data is relevant and representative for the specific deployment context - **Log retention:** Activate and retain automated logs for the required period - **Incident reporting:** Report serious incidents to the provider and, in some cases, directly to authorities - **Fundamental rights impact assessment (Art. 27):** Required for public bodies; recommended for private sector deployers in sensitive contexts ## Interaction with DORA The **Digital Operational Resilience Act (DORA)** entered into application in January 2025 and imposes comprehensive ICT risk management requirements on financial institutions — including AI systems as ICT components. Key interaction points: ### ICT Risk Management Framework DORA requires financial institutions to maintain an ICT risk management framework covering identification, protection, detection, response, and recovery. AI systems are ICT tools subject to this framework. The EU AI Act adds AI-specific requirements on top: bias testing, transparency documentation, human oversight design, and lifecycle management. **In practice:** A bank's AI credit scoring model must comply with both DORA ICT risk management (incident detection, continuity planning, change management) and EU AI Act high-risk requirements (risk management system, technical documentation, post-market monitoring). ### Third-Party Risk (ICT Third-Party Providers) DORA imposes detailed requirements for managing ICT third-party providers — including contractual requirements, audit rights, and oversight of critical providers. When a financial institution uses a third-party AI system (e.g., a vendor-supplied credit scoring model), DORA's third-party risk management requirements apply to that vendor. The EU AI Act's deployer obligations also apply — requiring the provider to supply instructions, conformity documentation, and logging capability. Financial institutions should ensure their third-party AI vendor contracts satisfy both DORA ICT provider requirements and EU AI Act deployer information rights. ### Incident Reporting DORA has its own incident reporting framework for significant ICT-related incidents, reported to sectoral supervisors (EBA, EIOPA, ESMA). The EU AI Act requires serious incidents involving high-risk AI systems to be reported to national market surveillance authorities. These are separate reporting obligations to different authorities. A serious incident involving an AI credit scoring system could trigger both a DORA incident report (to EBA/national financial supervisor) and an EU AI Act incident report (to the market surveillance authority). ## Sectoral Supervisors and AI Act Enforcement For financial institutions, the **sectoral financial supervisors** — EBA (banking), EIOPA (insurance), ESMA (securities and markets) — have a specific role in EU AI Act implementation, though they are not the primary AI Act enforcement authority. Under the AI Act, financial institutions that are providers of high-risk AI systems must register in the **EU AI database**. In the financial sector, the relevant financial supervisory authority may be designated as or collaborate with the national market surveillance authority responsible for AI Act oversight of that sector. The European Supervisory Authorities (ESAs) have been active in: - Publishing guidance on AI governance in financial services (EBA guidelines on internal governance, ML/AI in credit risk) - Contributing to EU AI Act implementation guidance for the financial sector - Coordinating with the EU AI Office on GPAI model oversight as it affects financial services ## Practical Compliance Priorities for Financial Institutions 1. **Inventory all AI systems in use** — classify each against Annex III criteria. Prioritise creditworthiness, insurance pricing, and biometric/KYC systems. 2. **Determine provider vs. deployer status** for each system — are you using vendor-supplied models or building in-house? 3. **Align AI governance with DORA ICT risk framework** — integrate AI Act obligations into the existing DORA governance structure to avoid duplicate processes. 4. **Review third-party AI vendor contracts** — ensure contracts provide: conformity documentation, instructions for use, logging access, incident notification commitments, update obligations, and audit rights. 5. **Establish human oversight mechanisms** — for high-risk AI use cases, ensure qualified staff have the authority, tools, and time to meaningfully review AI outputs before consequential decisions are made. 6. **Connect to post-market monitoring** — extend existing model risk management processes (Basel model validation, DORA change management) to cover the Art. 72 post-market monitoring requirements. 7. **Prepare for the EU AI database** — if you are a provider of high-risk AI systems, registration is mandatory. If you are a public body deployer, registration may also be required. -------------------------------------------------------------------------------- ## EU AI Act Glossary: Key Definitions and Terms Explained URL: https://www.regulation-ai.eu/en/glossary/ ## Core Definitions (Art. 3) The EU AI Act contains 65 defined terms in Art. 3. The most important for compliance purposes are summarised below. --- ### AI System (Art. 3(1)) A **machine-based system** that: - Operates with varying levels of autonomy - May exhibit adaptiveness after deployment - Infers, from inputs, how to generate outputs (predictions, content, recommendations, decisions) that can influence physical or virtual environments **Key implication:** The definition is technology-neutral. It does not require deep learning or neural networks — a rule-based system with adaptive components may qualify. Conversely, a simple if-then logic tree without learning capability likely does not qualify. --- ### Provider (Art. 3(3)) Any natural or legal person, public authority, agency, or body that **develops an AI system or has an AI system 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. **Key implication:** Development responsibility + market placement = provider status. A company that commissions a custom AI build from an external developer is the provider if the system is placed on the market under the company's brand. --- ### Deployer (Art. 3(4)) Any natural or legal person, public authority, agency, or body that **uses an AI system under its authority** for a professional purpose — except where use is in personal non-professional activity. **Key implication:** The vast majority of businesses using AI purchased from third parties are deployers. Deployer obligations are less burdensome than provider obligations but are still significant for high-risk systems. --- ### Authorised Representative (Art. 3(5)) Any natural or legal person established in the Union who has received a written mandate from a provider of an AI system established outside the Union to carry out obligations on behalf of that provider. **Key implication:** Non-EU providers of AI systems placed on the EU market must designate an EU-based authorised representative. This representative can be held legally responsible for the provider's EU AI Act obligations. --- ### Importer (Art. 3(6)) Any natural or legal person established in the Union that places on the EU market an AI system that bears the name or trademark of a natural or legal person established outside the Union. --- ### Distributor (Art. 3(7)) Any natural or legal person in the supply chain, other than the provider or importer, that makes an AI system available on the Union market without modifying it. --- ### Operator (Art. 3(8)) A collective term covering providers, authorised representatives, importers, distributors, deployers, and any other person subject to obligations under the Act. --- ### Intended Purpose (Art. 3(12)) The use for which an AI system is intended by the provider, including the specific context and conditions of use specified in the information supplied by the provider in the instructions for use, promotional or sales materials, or statements. **Key implication:** The intended purpose determines which risk category applies and which requirements must be met. A system intended for credit scoring is high-risk (Annex III); the same underlying model intended for spam filtering may not be. Providers cannot escape high-risk classification by leaving the intended purpose vague — the Act looks to all information about the system's design and marketing. --- ### Reasonably Foreseeable Misuse (Art. 3(13)) Use of an AI system in a way that is not in accordance with its intended purpose but that may result from reasonably foreseeable human behaviour or interaction with other systems. **Key implication:** Providers must assess and address foreseeable misuse in their risk management systems — not just the intended use case. A facial recognition system intended for access control must address the foreseeable risk that it could be used for real-time surveillance. --- ### Safety Component (Art. 3(14)) A component of a product or of an AI system which fulfils a safety function for that product or AI system, or the failure or malfunction of which endangers the health and safety of persons or property. **Key implication:** AI systems that are safety components of products covered by Annex I sector legislation are automatically subject to the high-risk requirements, regardless of whether the AI itself poses direct risk. --- ### Placing on the Market (Art. 3(9)) The first making available of an AI system or a general-purpose AI model on the Union market. --- ### Putting into Service (Art. 3(11)) The supply of an AI system for first use directly to the deployer or for own use on the Union market for its intended purpose. **Key implication:** Both "placing on the market" (selling to others) and "putting into service" (using yourself) trigger provider obligations. An enterprise that builds an AI system for internal use is putting it into service and is a provider subject to all obligations. --- ### High-Risk AI System Not defined in a single sentence — classified by reference to **Annex I** (safety components in regulated products) and **Annex III** (standalone high-risk use cases). The risk level depends on the intended purpose and deployment context, not the underlying technology. Annex III high-risk categories: 1. Biometric identification and categorisation 2. Management of critical infrastructure 3. Education and vocational training 4. Employment, workers management, access to self-employment 5. Access to and enjoyment of essential private services and public services and benefits 6. Law enforcement 7. Migration, asylum, border control management 8. Administration of justice and democratic processes --- ### General-Purpose AI (GPAI) Model (Art. 3(63)) An AI model, including where trained with a large amount of data using self-supervision at scale, that displays significant generality and is capable of competently performing a wide range of distinct tasks regardless of the way the model is placed on the market — which can be used in a variety of downstream applications. **Key distinction from AI system:** A GPAI model is not yet an AI system. It becomes part of an AI system when integrated into a product or application. The Act imposes obligations on GPAI model providers separately from (and in addition to) obligations on providers of AI systems built using GPAI models. --- ### GPAI Model with Systemic Risk (Art. 3(65)) A GPAI model designated as systemic-risk because it has high-impact capabilities evaluated according to appropriate technical tools and methodologies, or because of its actual or reasonably foreseeable high-impact reach. The current indicator is cumulative training compute exceeding **10^25 FLOPs**. Additional criteria may be applied by Commission delegated act. --- ### Serious Incident (Art. 3(49)) Any incident or malfunction of an AI system that directly or indirectly leads to: - Death of a person or serious damage to a person's health - A serious and irreversible disruption of the management and operation of critical infrastructure - Infringement of obligations under Union law intended to protect fundamental rights - Serious damage to property or the environment --- ### Substantial Modification (Art. 3(23)) A change to an AI system after placing on the market or putting into service which is not foreseen or planned in the initial conformity assessment and which affects the compliance of the AI system with the requirements of the Act or results in a change to the intended purpose. --- ### Conformity Assessment (Art. 3(20)) The process of verifying whether a high-risk AI system meets the requirements set out in Chapter III, Section 2 of the Act. Conformity assessments may be conducted by the provider (self-assessment) or by a notified body (third-party assessment), depending on the type of system. --- ### Notified Body (Art. 3(22)) A conformity assessment body designated by a member state to carry out third-party conformity assessment activities for high-risk AI systems. Notified bodies are the AI Act's equivalent of the CE marking bodies used in traditional product regulation. --- ### Market Surveillance Authority (Art. 3(26)) The national authority responsible for carrying out market surveillance under the AI Act. Member states must designate at least one market surveillance authority per member state. --- ### CE Marking (Art. 3(30)) The marking by which a provider indicates that a high-risk AI system is in conformity with the requirements of the AI Act and other applicable Union legislation providing for its affixing. --- ## Sector-Specific Terms ### Biometric Data (imported from GDPR) Personal data resulting from specific technical processing relating to the physical, physiological or behavioural characteristics of a natural person, which allow or confirm the unique identification of that natural person. ### Remote Biometric Identification System (Art. 3(40)) An AI system intended for the identification of natural persons at a distance through the comparison of a person's biometric data with the biometric data contained in a reference database, without prior knowledge of the user of the AI system whether the person will be present and can be identified. **Key implication:** Real-time remote biometric identification in publicly accessible spaces is prohibited for law enforcement purposes with narrow exceptions (Art. 5). ### Foundation Model Not defined in the AI Act — the Act uses "GPAI model" instead. Foundation model is a commonly used industry term for large-scale pre-trained models. For regulatory purposes, use "GPAI model." ### Fine-tuning Not defined in the Act. Adapting a GPAI model to a specific domain or task through additional training. If fine-tuning results in a substantially different model placed on the market, the fine-tuner may become a provider of that new model. --- ## Procedural Terms ### Technical Documentation (Annex IV) The structured documentation package that providers of high-risk AI systems must prepare before market placement and maintain throughout the system's lifecycle. It includes the system description, design logic, training data information, testing results, risk management documentation, and post-market monitoring plan. ### EU Declaration of Conformity (Art. 3(37)) A formal document signed by the provider stating that the high-risk AI system complies with all applicable requirements of the Act. It is the legal basis for affixing CE marking. ### Instructions for Use (Art. 3(15)) Information provided by the provider to inform the deployer of the AI system's intended purpose, performance, technical specifications, and conditions of use — including any restrictions and foreseeable risks. ### Post-Market Monitoring Plan (Art. 3(32)) The documented plan established by a provider for collecting and reviewing experience gained from operating a high-risk AI system after it has been placed on the market or put into service. ### Fundamental Rights Impact Assessment (Art. 27) An assessment that deployers in the public sector (and certain private deployers) must conduct before deploying a high-risk AI system, evaluating the impact on the fundamental rights of affected persons. -------------------------------------------------------------------------------- ## GPAI Model Rules under the EU AI Act — What Providers Must Do URL: https://www.regulation-ai.eu/en/gpai/ ## What is a GPAI model? **GPAI** stands for *general-purpose AI*. Under the EU AI Act, a GPAI model is an AI model trained on large amounts of data using self-supervision at scale, which displays significant generality and can competently perform a wide range of distinct tasks. Large language models, multimodal foundation models and large image generation models all qualify. A GPAI **model** is distinct from a GPAI **system**: the model is the trained foundation; the system is that model deployed inside an application. Obligations fall on the **model provider** — not on the downstream deployer who integrates the model into a product. ## GPAI rules apply now — since 2 August 2025 Chapter 5 of the EU AI Act (Art. 51–56) governs general-purpose AI models separately from high-risk AI systems. These rules apply from 2 August 2025 and were not extended by the 2026 omnibus. ## Who qualifies as a GPAI model provider? An organisation is a GPAI model provider if it trains a model at significant scale and makes it available to other providers or deployers. This includes: - Developers of large language models (GPT, Claude, Gemini, Mistral, Llama) - Developers of large multimodal models (vision-language, audio-language) - Developers of large image or video generation models - Developers of code generation models The Act distinguishes between providers who **release models commercially**, those who **release open-source weights**, and those who **train models for internal use only**. Internal-use models are not placed on the market and therefore outside scope. ## Standard GPAI obligations (all non-exempt models) All GPAI models except those with open-source weights must comply with: 1. **Technical documentation** (Art. 53(1)(a)) — including training methodology, evaluation results, energy consumption, and data sources 2. **Copyright compliance summary** (Art. 53(1)(c)) — a publicly available summary of content used in training, sufficient for copyright holders to exercise their rights 3. **Downstream compliance support** (Art. 53(1)(b)) — information enabling downstream providers to comply with their own AI Act obligations 4. **Cooperation with AI Office** (Art. 53(1)(d)) — providing information and documentation upon request ## Additional obligations for systemic-risk GPAI models GPAI models trained with more than **10²⁵ FLOPs** face additional obligations under Art. 55: | Obligation | Detail | |---|---| | **Model evaluation** | Standardised protocols including adversarial testing (red teaming) before and after training | | **Systemic risk assessment** | Assess and mitigate systemic risks from the model's training and foreseeable use | | **Incident reporting** | Serious incidents to the EU AI Office without undue delay | | **Cybersecurity** | Adequate cybersecurity protection for the model and its infrastructure | | **Energy reporting** | Electricity consumption reporting | ## Open-source GPAI: reduced but not zero obligations Open-source GPAI models (published weights) are exempt from the technical documentation and copyright summary requirements **unless** they have systemic risk. They still must: - Comply with copyright law (not a reduced obligation) - If systemic risk: all systemic-risk obligations still apply - Cooperate with AI Office investigations ## AI Office enforcement The European AI Office is the primary regulator for GPAI models across the EU. It operates under the Commission and is the single point of contact for GPAI providers. National competent authorities handle GPAI system obligations (downstream deployers). -------------------------------------------------------------------------------- ## High-Risk AI Systems under the EU AI Act: Classification and Obligations URL: https://www.regulation-ai.eu/en/high-risk/ ## Two routes into the high-risk category "High-risk" is not a judgement call about how powerful a system is. Article 6 defines two closed routes, and a system is high-risk if it takes either of them. **Route 1 — Annex I, embedded in a regulated product.** The AI system is a safety component of a product, or is itself a product, covered by one of the Union harmonisation acts listed in Annex I — machinery, medical devices, lifts, toys, radio equipment, civil aviation, motor vehicles and others — *and* that product must undergo third-party conformity assessment under those rules. See [Annex I](../annex-i/). **Route 2 — Annex III, stand-alone use cases.** The system falls into one of eight listed areas: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services, law enforcement, migration and border control, and administration of justice and democratic processes. See [Annex III](../annex-iii/). Both routes converge on the same requirements in Chapter III. The difference lies in the conformity assessment path and in the applicable deadline. ## The Article 6(3) exception, and its price An Annex III system is presumed high-risk, but the presumption is rebuttable. Under Article 6(3) a system is not high-risk if it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons — in particular where it: - performs a narrow procedural task - improves the result of a previously completed human activity - detects decision-making patterns or deviations from prior patterns without replacing or influencing human assessment without proper review - performs a preparatory task to an assessment relevant to the listed use cases There is a hard carve-out: a system that performs **profiling of natural persons** is always high-risk, whatever else it does. The exception is not free. A provider relying on it must **document the assessment before placing the system on the market**, and remains subject to the registration obligation in Article 49(2). Documentation must be produced on request. In practice, invoking Article 6(3) means committing to a defensible written analysis — not to silence. ## What providers must do Chapter III, Section 2 sets out the substantive requirements. They apply across the whole lifecycle, not at a point in time. | Requirement | Article | What it means in practice | |---|---|---| | Risk management system | [Art. 9](../articles/article-9/) | A continuous, documented, iterative process identifying and mitigating foreseeable risks, including reasonably foreseeable misuse | | Data governance | [Art. 10](../articles/article-10/) | Training, validation and testing sets must be relevant, sufficiently representative and, as far as possible, free of errors and complete for the intended purpose | | Technical documentation | [Art. 11](../articles/article-11/) | Drawn up **before** placing on the market, following Annex IV. See [technical documentation](../technical-documentation/) | | Record-keeping | [Art. 12](../articles/article-12/) | Automatic logging of events over the system's lifetime | | Transparency to deployers | [Art. 13](../articles/article-13/) | Instructions for use that let a deployer interpret output and use the system appropriately | | Human oversight | [Art. 14](../articles/article-14/) | Designed so that oversight is *effective* — the person must be able to understand, monitor and intervene | | Accuracy, robustness, cybersecurity | [Art. 15](../articles/article-15/) | Declared accuracy metrics, resilience to faults, protection against adversarial manipulation | On top of the requirements, providers carry the obligations in Article 16: quality management system, conformity assessment, CE marking, registration in the EU database, corrective action, and cooperation with authorities. ## What deployers must do Deployer duties under Article 26 are lighter but not trivial: - use the system in accordance with the instructions for use - assign human oversight to people with the competence, training and authority to exercise it - ensure input data is relevant and sufficiently representative for the intended purpose, to the extent the deployer controls it - monitor operation and suspend use plus inform the provider and authorities where risks arise - keep the automatically generated logs under the deployer's control - inform workers and their representatives before putting a system into service in the workplace Certain public bodies and private entities providing public services must also carry out a **fundamental rights impact assessment** under Article 27 before first use. ## When a deployer becomes a provider Article 25 is the most commonly missed provision in the whole Regulation. A deployer, distributor or importer takes on the **full provider obligations** if it: - puts its own name or trademark on a high-risk system already on the market - makes a substantial modification to a high-risk system - modifies the intended purpose of a system — including a non-high-risk system — such that it becomes high-risk Buying a general-purpose tool and repurposing it for CV screening is enough to trigger this. See [providers vs deployers](../providers-vs-deployers/) for the decision tree. ## The deadlines that actually apply The 2026 Digital Omnibus reshaped this timeline, and older guides still quote the superseded dates. | Obligation | Applies from | |---|---| | Article 5 prohibitions | 2 February 2025 (in force) | | AI literacy (Art. 4) | 2 February 2025 (in force) | | GPAI model rules | 2 August 2025 (in force) | | Penalties (Art. 99) | 2 August 2025 (in force) | | **Annex III stand-alone high-risk** | **2 December 2027** | | **Annex I embedded high-risk** | **2 August 2028** | Systems already on the market before the applicable date are covered by the transitional provisions in Article 111 — but a substantial modification after that date pulls them into scope. Check the full [deadline timeline](../deadlines/) and the [omnibus changes](../omnibus/). ## Where to start 1. Inventory every AI system in use, including embedded vendor features that were never procured as "AI". 2. Run each through the two Article 6 routes — not through intuition. 3. For Annex III hits, decide whether Article 6(3) applies and **write the assessment down**. 4. For confirmed high-risk systems, establish who is provider and who is deployer for each one. 5. Work the gap against the Chapter III requirements table above. The [AI risk classifier](../tools/ai-risk-classifier/) walks the classification logic, and the [compliance checklist](../compliance-checklist/) covers the obligation set once classification is settled. -------------------------------------------------------------------------------- ## EU AI Act Newsletter — Weekly Compliance Insights URL: https://www.regulation-ai.eu/en/newsletter/ ## Stay current on EU AI Act compliance The regulatory landscape around the EU AI Act is moving fast. The Omnibus revision, delegated acts, GPAI Code of Practice, and authority guidance are all evolving in 2026. This newsletter tracks every relevant change so your compliance team doesn't miss what matters. Each issue covers: - **Regulatory updates** — new guidance, delegated acts, and authority decisions - **Deadline alerts** — upcoming obligation dates and grace period reminders - **Implementation tips** — practical advice on risk classification, documentation, and oversight - **Case studies** — how organizations are approaching AI Act compliance in practice Subscribe — it's free One email per week. No spam. Unsubscribe any time. Subscribe free What would you like to receive? Weekly digest Deadline alerts GPAI updates Financial sector Join compliance officers, DPOs, and legal counsel already subscribed. ## What subscribers get ### Weekly regulatory digest Every Tuesday, receive a structured summary of the week's AI Act developments — authority statements, legislative updates, enforcement signals. Curated for compliance professionals, not AI enthusiasts. ### Deadline reminders The AI Act's obligation schedule is complex: different dates for providers, deployers, GPAI model developers, and notified bodies. The newsletter tracks all of them and sends targeted reminders before key dates. ### Early access to resources Newsletter subscribers receive early access to new templates, Academy course launches, and research reports — before they're announced publicly. ## Who reads this newsletter The newsletter is read by compliance officers, DPOs, legal counsel, and risk managers at organizations developing or deploying AI systems in the EU. It is also relevant for: - Product managers overseeing AI systems subject to the Act - Consultants advising clients on AI Act compliance - Legal teams at law firms covering technology regulation - Policy teams monitoring regulatory developments For deeper implementation support, see the [AI Act Academy →](/academy/) with structured training and templates. -------------------------------------------------------------------------------- ## EU AI Act Omnibus 2026: New Compliance Deadlines Explained URL: https://www.regulation-ai.eu/en/omnibus/ai-act-omnibus-deadlines/ ## What the 2026 Digital Omnibus on AI changes The Digital Omnibus on AI amended two central application dates in EU Regulation 2024/1689 (the EU AI Act): | Obligation | Original deadline | **New deadline** | Change | |---|---|---|---| | High-risk AI — Annex III (standalone systems) | 2 August 2026 | **2 December 2027** | +16 months | | High-risk AI — Annex I (embedded in regulated products) | 2 August 2026 | **2 August 2028** | +24 months | **No other major deadlines were modified.** Prohibited practices (2 February 2025), GPAI rules (2 August 2025), and transparency obligations for GPAI content marking (2 August 2025) remain in force on their original dates. ## Why the omnibus deferred high-risk AI deadlines The European Commission cited three drivers: 1. **Alignment with implementing acts** — technical standards and harmonised norms for high-risk AI assessment (CEN/CENELEC work programme) were not finalised in time for August 2026. Conformity assessments require these standards. 2. **Compliance infrastructure gap** — notified bodies, national competent authorities, and the EU AI Office needed additional setup time. Without operational enforcement infrastructure, an August 2026 deadline would have been unenforceable in practice. 3. **SME readiness** — smaller providers, particularly in medtech, HR tech, and financial services, reported insufficient time to complete QMS implementation and technical documentation alongside parallel DORA and NIS2 obligations. The extension is a grace period, not a reduction in scope. All obligations remain; only their timeline shifts. ## Annex III — standalone high-risk AI (deadline: 2 December 2027) **Annex III standalone** covers AI systems that are themselves placed on the market or put into service as high-risk systems, without being a safety component of another product. Examples: - Recruitment and HR screening AI (CV ranking, interview analysis) - Credit scoring and creditworthiness assessment AI - Biometric categorisation (not real-time identification, which is prohibited) - AI used in critical infrastructure management - AI in educational and vocational training assessment - AI used by law enforcement and migration authorities **Provider obligations by 2 December 2027:** 1. Complete a conformity assessment under Art. 43 2. Implement a quality management system (Art. 17) 3. Compile technical documentation (Art. 11 + Annex IV) 4. Register the system in the EU AI database (Art. 71) 5. Affix CE marking (Art. 48) 6. Appoint an EU representative if established outside the EU **Deployer obligations (also by 2 December 2027):** 1. Conduct a Fundamental Rights Impact Assessment (FRIA) for public body deployers 2. Implement human oversight measures (Art. 26) 3. Document inputs and outputs (Art. 26(6)) 4. Inform employees where AI-assisted decisions affect them ## Annex I — embedded high-risk AI (deadline: 2 August 2028) **Annex I embedded** covers AI that forms a safety component of a product already regulated under existing EU product safety legislation. The AI Act compliance is integrated into the existing conformity assessment procedure for that product. Examples: - AI components in medical devices (MDR/IVDR) - AI in automotive systems (type-approval frameworks) - AI in machinery (Machinery Regulation) - AI in aviation components - AI in toys and consumer products (low voltage/EMC) The two-year additional extension (vs. 16 months for Annex III) reflects the layered complexity of conformity assessment across two regulatory regimes simultaneously. ## What changed is the deadline — not the obligations A common misreading of the omnibus: the deadline extension means obligations are softened. They are not. The conformity assessment, QMS, technical documentation, CE marking, and registration requirements are identical to what was required under August 2026. The omnibus does not reduce scope, create exemptions, or add transition derogations. It moves the finish line. **Practical implication:** organisations that use the extension as an excuse to pause compliance programmes will face a harder crunch in late 2027. The more productive use of the additional time is to complete QMS implementation, stress-test technical documentation against draft harmonised standards, and engage with notified bodies early — their capacity will be constrained as the December 2027 deadline approaches. ## Prohibited practices that are already in force These prohibitions under Art. 5 applied from **2 February 2025** and were not touched by the omnibus: - **Subliminal manipulation** — AI techniques that exploit subconscious vulnerabilities to alter behaviour against users' interests - **Exploitation of vulnerabilities** — targeting children, elderly, or disadvantaged groups - **Social scoring** — AI-based general-purpose scoring of natural persons by public authorities - **Real-time remote biometric identification** in publicly accessible spaces by law enforcement (with narrow exceptions) - **Emotion recognition** in the workplace and educational institutions - **Biometric categorisation** systems that infer sensitive characteristics (race, political opinions, trade union membership, sexual orientation, religion) — unless for legitimate law enforcement purposes with judicial authorisation - **NCII/CSAM** — generation or manipulation of non-consensual intimate imagery or child sexual abuse material using AI is prohibited Non-compliance with Art. 5 prohibitions from 2 February 2025 carries fines up to **€35 million or 7% of global annual turnover**, whichever is higher. ## GPAI model rules: already applicable Chapter 5 GPAI obligations apply from **2 August 2025**: - All GPAI providers must comply with transparency obligations (Art. 53) - Providers of GPAI models with systemic risk (above 10²⁵ FLOPs training compute) face additional obligations including adversarial testing and incident reporting - AI-generated content marking (watermarking) for synthetic media applies to generative GPAI systems ## Convergence with DORA and NIS2 Organisations in financial services face the triple burden of AI Act, DORA, and NIS2 obligations with overlapping timelines. Key intersections: - **ICT risk management under DORA** (Art. 5–16) must cover AI-driven ICT systems — DORA does not exempt AI tools from its ICT risk framework - **Incident reporting** under DORA (Art. 19–23) applies to incidents caused by or involving AI systems - **NIS2 security measures** (Art. 21) include AI-related cyber risks in scope - **AI Act Art. 9 risk management** for high-risk AI overlaps significantly with DORA's ICT risk management — dual-mapping is possible and recommended to avoid duplicative documentation See our [full convergence analysis →](/ai-act-vs-dora-vs-nis2/) or our sister site [regulation-dora.eu](https://www.regulation-dora.eu) for DORA-specific coverage. -------------------------------------------------------------------------------- ## EU AI Act Digital Omnibus 2026: What It Changes URL: https://www.regulation-ai.eu/en/omnibus/ > **Update — 2 August 2026.** The Omnibus deferred the high-risk regime but not the transparency regime, which is now live and enforceable. Read [what changed on 2 August 2026](/en/blog/eu-ai-act-enforcement-august-2026/). ## What the 2026 Digital Omnibus on AI changed The Digital Omnibus on AI moved **four** application dates. Two are widely reported; the other two are the ones that catch compliance programmes out. | Provision | Before omnibus | After omnibus | Basis | |---|---|---|---| | High-risk AI — Annex III (standalone) | 2 August 2026 | **2 December 2027** | Art. 6(2), Annex III | | High-risk AI — Annex I (embedded in regulated products) | 2 August 2027 | **2 August 2028** | Art. 6(1), Annex I | | National regulatory sandboxes | 2 August 2026 | **2 August 2027** | Art. 57–63 | | Content marking — systems already on the market | 2 August 2026 | **2 December 2026** | Art. 50(2) | Everything else kept its date. The omnibus did not create new obligations, remove existing ones, or introduce derogations or exemptions. Those four rows are the complete list. For the same record article by article — including an explicit answer for the 76 articles nothing happened to — see [changes to Regulation (EU) 2024/1689](/en/changes/), published as [`/api/changes.json`](/api/changes.json) for machines. ### What kept its original date | Provision | Applies since | Status | |---|---|---| | Prohibited practices (Art. 5) | 2 February 2025 | In force | | GPAI model obligations (Chapter 5, Art. 51–56) | 2 August 2025 | In force | | Transparency duties (Art. 50) | 2 August 2026 | In force | | Commission enforcement over GPAI providers | 2 August 2026 | In force | **The sandbox deferral is the one most often got wrong.** Article 57 requires each Member State to have a national AI regulatory sandbox operational; that obligation moved to 2 August 2027. It is regularly listed among the provisions the omnibus left alone. It is not one of them — see the [national implementation tracker](/en/national-implementation/) for where each Member State currently stands. ## Why the Commission extended the deadlines Three official reasons: 1. **Standards not ready** — Harmonised technical standards needed for conformity assessments under AI Act Art. 40 were not finalised by the original August 2026 deadline. Without these standards, conformity assessments could not be completed properly. 2. **Enforcement infrastructure gap** — Notified bodies needed designation and accreditation. National competent authorities required resources and guidelines. The EU AI Office needed operational capacity. An August 2026 deadline would have been unenforceable in practice. 3. **Industry and SME readiness** — Particularly for smaller providers in medtech, HR technology, and financial services, the parallel burden of AI Act, DORA (January 2025), and NIS2 (October 2024) compliance was cited as excessive. ## What the omnibus does NOT do The omnibus extension is commonly misread as reducing the regulatory burden. It does not: - Remove any obligation - Create an exemption for any sector or company size - Reduce fines for non-compliance after the new deadlines - Change the scope of what constitutes high-risk AI under Annex III or Annex I - Affect GPAI rules, prohibited practice bans, or transparency obligations ## What this means for a compliance programme The deferral changes *when* you must be ready, not *what* ready means. Three consequences follow, and they run in opposite directions depending on which annex you fall under. **If your system is stand-alone high-risk (Annex III)** — recruitment scoring, credit assessment, biometric identification, education, essential services — you have until 2 December 2027. That sounds distant. It is roughly one conformity-assessment cycle: a notified body engagement plus the technical documentation of Annex IV typically runs 12 to 18 months, and notified bodies are still being designated. The deferral removes the crisis, not the lead time. **If your AI is a safety component of a regulated product (Annex I)** — medical devices, machinery, civil aviation, vehicles — you have until 2 August 2028, but your sectoral conformity assessment is already running on its own cycle. The practical question is whether your next MDR, Machinery or type-approval submission falls before or after that date, because aligning the two is far cheaper than doing them twice. **If you deploy a chatbot or generate synthetic content**, none of this applies to you. Article 50 has been enforceable since 2 August 2026, and the only omnibus concession was a grace period to 2 December 2026 for systems already on the market. That is the nearest real deadline for most organisations, and it is the one the deferral headlines have obscured. ## The classification question comes first Every date above depends on a determination you may not have made: whether your system is high-risk at all. Most are not. Annex III point 5(b) explicitly carves out AI used to detect financial fraud; point 1 excludes one-to-one biometric verification; algorithmic trading appears nowhere in the annex. Working through classification before buying anything is the difference between a proportionate programme and an expensive one. The [risk classifier](/en/tools/ai-risk-classifier/) walks the Annex III categories, and [providers vs deployers](/en/providers-vs-deployers/) settles which set of obligations attaches to your role. ## Detailed guide to deadline changes For the obligation-by-obligation breakdown and a compliance programme timeline, see [AI Act Omnibus 2026: New Deadlines Explained →](/omnibus/ai-act-omnibus-deadlines/). *Editorial, not legal advice.* -------------------------------------------------------------------------------- ## EU AI Act Penalties and Fines: The Three Tiers Explained URL: https://www.regulation-ai.eu/en/penalties/ ## The three penalty tiers at a glance The EU AI Act sets maximum fines in Article 99. The tier depends on which obligation was breached, not on how much harm resulted. | Tier | Maximum fine | What triggers it | |------|--------------|------------------| | **Prohibited practices** | **€35 million or 7%** of total worldwide annual turnover, whichever is higher | Breach of the Article 5 prohibitions: manipulative techniques, exploitation of vulnerabilities, social scoring, untargeted facial-image scraping, emotion inference at work or school, and most real-time remote biometric identification in public spaces | | **Most other obligations** | **€15 million or 3%** | Provider obligations (Art. 16), authorised representatives (Art. 22), importers (Art. 23), distributors (Art. 24), deployers (Art. 26), notified bodies, and the transparency duties in Art. 50 | | **Incorrect information** | **€7.5 million or 1%** | Supplying incorrect, incomplete or misleading information to notified bodies or national competent authorities in reply to a request | The percentage is calculated on the **preceding financial year's total worldwide annual turnover of the undertaking**, not on EU turnover and not on the revenue of the specific product. ## The SME rule works in reverse This is the detail most summaries get wrong. For ordinary undertakings the fine is the **higher** of the fixed amount and the percentage. For SMEs and start-ups, Article 99 applies whichever figure is **lower**. The practical effect is large: - A group with €10 billion turnover breaching Article 5 faces up to 7% — €700 million, far above the €35 million figure. - A start-up with €2 million turnover breaching the same article faces 7% of €2 million — €140,000, far below €35 million. So the headline "€35 million" number is close to meaningless for small companies, and much too low for large ones. Always compute both figures before quoting an exposure. ## Who enforces what Three separate enforcement tracks run in parallel, and they are frequently conflated. **Article 99 — national market surveillance authorities.** Each Member State designates the authorities that supervise operators on its territory and lays down the penalty regime, within the ceilings above. Member States were required to notify their rules to the Commission. Because the ceilings are maxima rather than fixed amounts, actual exposure varies by country. **Article 100 — the European Data Protection Supervisor.** EU institutions, bodies, offices and agencies are in scope of the AI Act, but not of national enforcement. The EDPS may impose administrative fines of up to **€1,500,000** for breaches of the Article 5 prohibitions and up to **€750,000** for other breaches. The scale is deliberately far lower than for private operators. **Article 101 — the Commission, via the AI Office.** Providers of general-purpose AI models answer to the Commission rather than to national authorities. The Commission may impose fines of up to €15 million or 3% of worldwide annual turnover. This power activates on **2 August 2026**. ## When penalties started applying The penalty framework did not arrive with the rest of the Regulation. It phased in: - **2 February 2025** — the Article 5 prohibitions took effect, but the penalty machinery was not yet applicable. - **2 August 2025** — Article 99 became applicable, alongside the governance architecture and the GPAI obligations. From this date national authorities could sanction breaches. - **2 August 2026** — the Commission's enforcement powers over general-purpose AI model providers under Article 101 activate. The 2026 Digital Omnibus deferred the substantive high-risk obligations to 2 December 2027 (Annex III) and 2 August 2028 (Annex I). It did not defer the prohibitions or the penalty regime — a distinction worth checking against the full [compliance timeline](../deadlines/). ## What regulators weigh before fining Article 99 requires authorities to take into account, among other factors: - the nature, gravity and duration of the infringement, and the number of people affected - whether the same operator has already been fined for the same infringement by another authority - the size, annual turnover and market share of the operator - whether the infringement was intentional or negligent - any action taken to mitigate harm - the degree of cooperation with authorities - how the authority became aware of the infringement, and in particular whether the operator notified it That last point matters operationally: self-reporting is an explicit mitigating factor. ## Reducing exposure in practice Penalty exposure is mostly a function of classification accuracy. Most organisations are not at risk of the 7% tier — the Article 5 prohibitions are narrow and largely cover practices no compliant business intends. The realistic exposure sits in the 3% tier, and it follows from three questions: 1. **Do we operate a high-risk system without knowing it?** Annex III use cases in recruitment, credit scoring, education and essential services catch many systems that were never described internally as "AI". Start from the [high-risk classification](../high-risk/) rather than from the vendor's label. 2. **Are we a provider or a deployer?** The obligation sets differ sharply, and modifying a system or putting it on the market under your own name can convert a deployer into a provider. See [providers vs deployers](../providers-vs-deployers/). 3. **Can we evidence compliance?** The €7.5 million tier punishes bad answers to regulators, independent of the underlying breach. Technical documentation, logs and a conformity trail are what turn a defensible position into a demonstrable one. Run the [compliance checklist](../compliance-checklist/) to establish where you stand, and use the [sanction estimator](../tools/sanction-estimator/) to model exposure against your own turnover. -------------------------------------------------------------------------------- ## EU AI Act Post-Market Monitoring (Art. 72): Obligations for High-Risk AI Providers URL: https://www.regulation-ai.eu/en/post-market-monitoring/ ## What Is Post-Market Monitoring? Conformity assessment and CE marking are the entry ticket to the EU market for a high-risk AI system — not the finish line. Article 72 of the EU AI Act imposes a continuing obligation: providers must establish and operate a **post-market monitoring (PMM) system** that actively collects, analyses, and acts on real-world performance data throughout the operational lifetime of the system. The rationale is straightforward. An AI system validated on a fixed dataset may drift as real-world inputs shift, as the user population changes, or as the environment in which it operates evolves. Static compliance snapshots cannot capture this. PMM is the mechanism that turns compliance into a continuous process rather than a one-time event. The PMM system must be proportionate to the nature and risks of the high-risk AI system concerned. A credit-scoring model deployed at scale across millions of consumers will require more intensive monitoring than a narrow document-classification tool used internally by a regulated firm. ## Who Must Establish a PMM System? **Mandatory for:** - Providers of **Annex III standalone high-risk AI systems** — systems listed in Annex III that are not safety components of a product (e.g., AI used in employment decisions, access to education, law enforcement, creditworthiness assessment, critical infrastructure management) - Providers of **Annex I product-embedded AI systems** — AI safety components integrated into products covered by existing EU harmonisation legislation (medical devices, machinery, vehicles) **Not required for:** - Providers of minimal-risk AI systems (no formal PMM obligation, though good practice applies) - Providers of transparency-only AI systems (Art. 50 obligations do not extend to PMM) - GPAI model providers — these are subject to a separate regime under Art. 61–62, which includes incident reporting for systemic-risk models but is structured differently from Art. 72 PMM **The deployer's role** is supporting but not optional. Deployers must operate the AI system in accordance with the provider's instructions, activate and retain the logging functionality built into the system, and — critically — report any serious incidents they become aware of to the provider without undue delay. A deployer who observes a serious incident and fails to notify the provider is not compliant. ## The Post-Market Monitoring Plan (Annex IV, Point 12) The PMM plan is a mandatory component of the technical documentation (Annex IV). It cannot be a generic document: it must be specific to the system, its deployment context, and its identified risks. At minimum, it must define: 1. **Data collection** — what performance metrics are captured (accuracy, error rates, decision outcomes), how data is collected (automated telemetry, deployer reports, user feedback), and at what frequency 2. **Feedback loops** — the mechanism by which deployers can report performance issues, anomalies, or incidents back to the provider in a structured and timely way 3. **Accuracy monitoring** — how the system's performance is tracked against the validated benchmark used during conformity assessment, including any drift-detection methodology 4. **Bias monitoring** — for systems where demographic outcomes are material (hiring, credit, law enforcement), ongoing monitoring of statistical disparities across protected groups, with defined methodology and thresholds 5. **Update triggers** — the specific quantitative or qualitative thresholds that prompt corrective action, including model retraining, parameter adjustment, or deployment suspension 6. **Review schedule** — how often the PMM plan itself is reviewed and updated, ensuring it remains fit for purpose as the deployment context evolves The PMM plan must be kept up to date. An outdated plan that no longer reflects the actual monitoring methodology does not satisfy Art. 72. ## Serious Incident Reporting (Art. 73) ### What constitutes a serious incident? Article 73 defines a serious incident as any incident or malfunction of a high-risk AI system that directly or indirectly leads to: - **Death** or **serious harm to health** (physical or psychological) - A **serious and irreversible disruption** to the management or operation of critical infrastructure - A **serious breach of fundamental rights** (privacy, non-discrimination, due process) - A situation in which a person **narrowly avoided** any of the above Importantly, the AI Act does not require that a causal link to the AI system be established before reporting. A reasonable suspicion that the AI system contributed to or failed to prevent the harm is sufficient to trigger the obligation. Providers who wait for certainty before reporting risk non-compliance. ### Reporting timelines | From | To | Deadline | |---|---|---| | Deployer | Provider | Without undue delay (upon becoming aware) | | Provider | National market surveillance authority | Within **15 calendar days** of becoming aware | | Provider (public security risk) | National market surveillance authority | Within **24 hours** of becoming aware | | Provider (newly emerged systemic risk pattern) | National market surveillance authority | Without undue delay (no specific incident required) | The 15-day clock starts when the provider becomes aware of the incident — which, in practice, means when the deployer notifies them. Providers should design their deployer notification procedures so that information reaches them quickly enough to meet the downstream reporting deadline. ### What an incident report must contain A compliant incident report to the national market surveillance authority should include: - **System identification**: name, version, EU database registration number - **Description of the incident**: what happened, what harm occurred or was narrowly avoided, date and location - **Affected persons**: number and categories of affected users or third parties (anonymised where required under GDPR) - **Preliminary causal analysis**: the provider's current understanding of how the incident arose, clearly labelled as preliminary - **Immediate corrective or safety measures taken**: any steps already taken to limit further harm or risk (e.g., suspension of affected functionality, deployer notifications) - **Contact point**: the person or team responsible for follow-up correspondence with the authority The report should be factual and proportionate. Preliminary reports may be supplemented by follow-up reports as the investigation progresses. ## Mandatory Logging (Art. 12) Article 12 requires that high-risk AI systems be designed and built with the capability to **automatically generate logs** at a level of granularity sufficient to enable: - Post-market monitoring in accordance with Art. 72 - Tracing of events leading to a serious incident - Investigation by national authorities This is a design requirement imposed on the **provider**. The provider must build the logging capability into the system before it is placed on the market. The obligation to **activate and retain** those logs falls on the **deployer**. Deployers must not disable logging functionality and must retain logs for the period specified in the provider's instructions and technical documentation. Where no specific retention period is defined, logs should be retained for a period commensurate with the operational lifecycle of the system and any applicable sector-specific requirements (e.g., financial services record-keeping rules under DORA or MiFID II). ## Substantial Modifications and Re-Assessment Not every change to a deployed AI system triggers a new conformity assessment. The Act distinguishes between minor updates and **substantial modifications**. A modification is substantial — and requires a new conformity assessment and updated technical documentation — when it: - Changes the **intended purpose** of the system (even partially) - Involves a **significant change to the architecture** or training methodology - Uses new training data that materially affects the system's performance in ways that could affect compliance-relevant behaviour - **Degrades performance** beyond thresholds defined in the risk management documentation in ways that affect safety or fundamental rights Minor updates — security patches, bug fixes that correct clearly identified defects without altering compliance-relevant behaviour, cosmetic interface changes — do not require a full re-assessment. However, they must be **documented**, and the provider must retain a written assessment confirming that the modification does not constitute a substantial modification. That record is subject to inspection by market surveillance authorities. ## Practical Implementation Checklist The following checklist reflects the minimum operational requirements under Art. 72, Art. 73, and Art. 12. It is not a substitute for legal advice but provides a starting point for gap analysis. - [ ] PMM plan documented in the technical file (Annex IV, point 12), specific to the system and its deployment context - [ ] Automated logging capability designed and built into the system prior to market placement - [ ] Deployer instructions include a clear, written incident reporting procedure with escalation contact - [ ] Incident reporting contact point established internally and notified to the relevant national market surveillance authority - [ ] Bias and accuracy monitoring processes or dashboards defined, with documented methodology and thresholds - [ ] Escalation thresholds for corrective action documented and linked to the risk management system - [ ] Substantial modification assessment procedure in place, with a decision record template for each update - [ ] Log retention policy defined, communicated to deployers, and aligned with sector-specific retention rules --- *Cross-references: [Technical Documentation](/technical-documentation/) — [Annex III High-Risk AI Systems](/annex-iii/) — [Providers vs. Deployers](/providers-vs-deployers/)* -------------------------------------------------------------------------------- ## EU AI Act Prohibited Practices (Art. 5): In Force Since February 2025 URL: https://www.regulation-ai.eu/en/prohibited-practices/ ## Prohibited practices are already law — since 2 February 2025 Article 5 of the EU AI Act prohibits eight categories of AI practices deemed to pose unacceptable risk. These prohibitions entered into force on **2 February 2025** — six months after the Act entered into force — and apply to all providers and deployers in the EU without exception. The 2026 Digital Omnibus did not change these prohibitions. Enforcement is live. National market surveillance authorities and the EU AI Office have authority to investigate, impose injunctions, and levy fines. ## The eight prohibited practices ### 1. Subliminal manipulation **AI systems that deploy techniques operating below the threshold of human consciousness** to distort behaviour in ways that cause or are likely to cause significant harm. This targets AI that exploits cognitive biases, psychological weaknesses, or subconscious triggers to steer behaviour against users' own interests. Distinguishing feature: the manipulation must be below conscious perception AND cause (or likely cause) significant harm. Persuasive but transparent AI is not prohibited. ### 2. Exploitation of vulnerabilities **AI that exploits specific vulnerabilities of particular groups** — children, elderly persons, people with disabilities, those in economic distress — to distort behaviour in a way that causes or is likely to cause significant harm. ### 3. Social scoring by public authorities **General-purpose social scoring systems operated by public authorities** that evaluate or classify natural persons based on their social behaviour or personal characteristics, where the scoring leads to detrimental treatment unrelated to the context in which the data was generated. This targets Chinese-style social credit systems. It applies only to public authorities — private sector credit scoring in specific domains (financial creditworthiness) remains permissible under Annex III. ### 4. Real-time remote biometric identification in public spaces (law enforcement) **Real-time remote biometric identification of natural persons in publicly accessible spaces for the purpose of law enforcement** is prohibited, with three narrow exceptions: - Targeted search for specific victims of crime (kidnapping, trafficking, sexual exploitation) - Prevention of specific, substantial, and imminent terrorist threat - Identification of perpetrators of listed serious criminal offences carrying custodial sentences above 3 years Exceptions require prior judicial or independent administrative authorisation, are time- and location-limited, and are notified to a national authority. ### 5. AI-based individual criminal risk prediction **AI systems that assess or predict the risk of a natural person committing a criminal offence** based solely on profiling or personality characteristics, without reference to objective, verifiable facts directly linked to criminal activity. ### 6. Emotion recognition in the workplace and educational institutions **AI systems used to infer emotions of natural persons in the workplace or educational institutions** are prohibited. Exceptions exist for medical purposes (e.g., pain assessment) and safety purposes (drowsiness detection for vehicle operators). ### 7. Biometric categorisation inferring sensitive characteristics **AI systems that categorise individuals based on biometric data to infer or deduce race, political opinions, trade union membership, religious or philosophical beliefs, sexual orientation, or health status** are prohibited. Standard facial recognition for access control (identifying who someone is) is different from categorisation (inferring what group they belong to). The latter is prohibited. ### 8. NCII and CSAM generation **AI systems that generate or manipulate image, audio, or video content constituting non-consensual intimate images (NCII) or child sexual abuse material (CSAM)** are prohibited. This was added to address the specific harm from generative AI models in these categories. ## Penalties Non-compliance with Article 5 carries the highest tier of AI Act fines: - **€35 million** or **7% of total worldwide annual turnover** for the preceding financial year, whichever is higher - For SMEs and start-ups: the lower of the two figures applies National competent authorities also have powers to require immediate withdrawal of the AI system from the market. -------------------------------------------------------------------------------- ## EU AI Act: Providers vs. Deployers — Who Is Responsible for What? URL: https://www.regulation-ai.eu/en/providers-vs-deployers/ ## The Two-Actor Architecture of the EU AI Act The EU AI Act does not create a single universal obligation for all AI stakeholders. It distinguishes systematically between two primary roles in the AI value chain: - **Providers** — entities that develop, train, or fine-tune AI systems and bring them to market - **Deployers** — entities that operate AI systems in a professional context without having built them This distinction is not semantic. It determines which obligations apply, who holds which documentation, who registers in the EU AI database, who performs conformity assessment, and who is liable when something goes wrong. Getting your role right is the first step in any EU AI Act compliance programme. A third role — **authorised representative** — applies to providers established outside the EU who must designate an EU-based representative to carry their regulatory obligations on EU territory. ## Defining the Provider (Art. 3(3)) A **provider** is any natural or legal person, public authority, agency, or other body that: 1. Develops an AI system or has an AI system developed, **and** 2. Places it on the market or puts it into service under its own name or trademark — whether for payment or free of charge The key indicators of provider status are **development responsibility** and **market placement**. An AI laboratory that builds and licenses a credit-scoring model is a provider. A consultancy that designs and builds a custom recruitment screening tool for a client, then hands it over, is also a provider (as long as it places the system on the market under its own name; if it is built under the client's brand, the client may be the provider). The definition covers: - AI startups and software vendors selling packaged AI products - Enterprises building AI systems for internal deployment - Research institutions publishing AI systems for general use - Cloud providers offering AI-as-a-service under their own brand **Providers bear the heaviest compliance burden under the Act.** For high-risk systems, this includes conducting conformity assessments, preparing technical documentation, registering in the EU AI database, affixing CE marking, and maintaining a post-market monitoring system. ## Defining the Deployer (Art. 3(4)) A **deployer** is any natural or legal person, public authority, agency, or other body that uses an AI system under its authority for a professional purpose — except where use is in personal non-professional activity. Deployers do not build AI systems. They use systems built by others — whether purchased off-the-shelf, licensed via API, or embedded in a SaaS product. The vast majority of European organisations that "use AI" are deployers: companies using ChatGPT or Claude via API, HR departments using AI-powered applicant tracking, hospitals using AI-assisted diagnostic tools, banks using vendor-supplied credit models. **Key deployer obligations (for high-risk AI systems):** - Use the system only in accordance with the instructions provided by the provider (Art. 26(1)) - Assign a human with competence, authority, and resources to perform human oversight (Art. 26(2)) - Ensure input data is relevant and representative for the intended purpose (Art. 26(5)) - Monitor system operation to detect anomalies (Art. 26(5)) - Retain logs produced by the system for the period required (Art. 26(6)) - Notify the provider and competent authority of any serious incidents (Art. 26(8)) - Conduct a Data Protection Impact Assessment where required by GDPR (Art. 26(9)) Deployers of emotion recognition and biometric categorisation systems must also comply with Art. 50 transparency obligations regardless of risk classification. ## The Provider-Deployer Boundary in Practice The boundary between provider and deployer is straightforward in theory but blurred in practice. Three scenarios illustrate the common grey areas: ### Scenario 1: Off-the-shelf SaaS with no customisation A company subscribes to a vendor's AI-powered HR screening platform with no modification. The vendor is the provider. The company is the deployer. The vendor owes the company instructions for use, conformity documentation, and logging capability. The company owes its employees transparency and human oversight. ### Scenario 2: API integration with significant prompt engineering A company integrates a GPAI model via API, adds a custom system prompt, builds a user interface, and releases the application to customers. For the underlying GPAI model, the original developer is the provider. For the application built on top, the company is the provider — it has developed an AI system and placed it on the market under its own brand. Both provider and GPAI obligations apply at different layers. ### Scenario 3: Custom internal build A bank builds its own creditworthiness assessment model, trains it on proprietary data, and deploys it internally for loan decisions. The bank is simultaneously the provider (it built and deployed the system) and the deployer (it operates the system for its own purposes). All provider obligations under the Act apply — including conformity assessment for this Annex III high-risk use case — as well as all deployer obligations. ## When Deployers Become Providers (Art. 25) Art. 25 establishes clear triggers by which a deployer assumes provider status and inherits all provider obligations: 1. **Substantial modification** — the deployer makes a substantial modification to a high-risk AI system beyond what the original provider intended 2. **Purpose change triggering high-risk classification** — the deployer uses a non-high-risk system in a way that meets the Annex III high-risk criteria 3. **Own-name placement** — the deployer places the AI system on the market or puts it into service under its own name or trademark 4. **GPAI model modification** — a deployer who makes a major change to a GPAI model in a way that alters its general-purpose use case When Art. 25 is triggered, the original provider's obligations transfer to the new provider. The original provider is relieved of obligations for the modified or repurposed system. This is an important liability allocation mechanism: organisations that merely customise a system must understand where customisation ends and substantial modification begins. ## Obligations Comparison Table | Obligation | Provider | Deployer | |---|---|---| | Conformity assessment (Annex VI/VII) | Yes | No | | Technical documentation (Annex IV) | Yes | No | | CE marking and EU Declaration of Conformity | Yes | No | | EU AI database registration | Yes (Art. 49) | Yes (public bodies, Art. 49(2)) | | Instructions for use | Must provide | Must follow | | Post-market monitoring plan | Must establish | Must support | | Serious incident reporting | To MSA (Art. 73) | To provider (Art. 26(8)) | | Human oversight measures | Must implement in design | Must implement in operation | | Logging capability | Must build in | Must activate and retain | | Fundamental rights impact assessment | No | Yes (public bodies, Art. 27) | | GDPR DPIA (where applicable) | Yes | Yes | ## How to Determine Your Role Three questions establish your role under the EU AI Act: 1. **Did you develop the AI system, or have it developed under your direction?** If yes — and you placed it on the market or into service — you are a provider. 2. **Are you using an AI system built by someone else for a professional purpose?** If yes, you are a deployer. 3. **Have you substantially modified, repurposed, or rebranded an AI system?** If yes, you may have become a provider for that modified system under Art. 25. For organisations that are both — internal build for internal use — all obligations stack. There is no reduction for integrated operations. ## Contractual Allocation of Responsibilities The Act allows providers and deployers to contractually allocate specific obligations. Art. 25(1) explicitly permits this for certain obligations. However, two limits apply: - **Regulatory liability cannot be contracted away.** If the deployer operates a high-risk system, it remains responsible for deployer obligations regardless of what the contract says. Contracts can establish internal recourse but cannot shift regulatory accountability to the other party. - **The information flow must be preserved.** Any allocation must ensure the deployer has the information necessary to fulfil its obligations — instructions for use, logging access, incident reporting channels. Contracts that cut off this information flow are problematic for compliance, not just commercially. Procurement teams should use AI vendor contracts to ensure providers supply what deployers need: instructions, conformity documentation, incident notification channels, update commitments, and data governance terms for any data shared for fine-tuning. ## Training for providers and deployers Art. 4 requires both providers and deployers to ensure relevant staff have documented AI literacy. Use the [compliance checklist tool →](/tools/compliance-checklist/) to map your specific obligations by role, and the [AI Act Fundamentals course (free) →](/academy/ai-act-fundamentals/) for team training. For teams implementing full compliance programmes: [Pro certification →](/academy/) · [Corporate training →](/academy/corporate-training/) -------------------------------------------------------------------------------- ## EU AI Act by Sector — Industry-Specific Compliance Guide URL: https://www.regulation-ai.eu/en/sectors/ ## How Sector Shapes EU AI Act Exposure The EU AI Act is horizontal legislation — it applies to AI systems placed on the market or put into service across every sector of the economy in the European Union. However, the practical compliance burden is not uniform. Sector determines which **Annex III high-risk categories** are relevant, which pre-existing regulatory frameworks create overlapping obligations, and which national or EU-level supervisory authorities will have jurisdiction over AI deployments. The Act establishes a tiered risk architecture: **prohibited practices** under **Art. 5**, **high-risk AI** under **Art. 6** and Annex III, **General Purpose AI (GPAI)** obligations under **Art. 51 to Art. 55**, and **transparency obligations** under **Art. 50**. All sectors face the prohibited practices prohibition and the Art. 50 transparency layer. The Annex III high-risk obligations fall selectively, depending on what AI the organisation deploys and for what purpose. Understanding sector exposure begins with mapping operational AI use cases against Annex III categories. Organisations must also assess whether deployed AI constitutes a GPAI model under Art. 3(63), and whether any supplier relationships create obligations as a GPAI deployer or provider. ## Understanding Annex III by Sector Annex III of the EU AI Act defines 8 categories of standalone high-risk AI. Each category maps to specific industries and AI use cases. ### Category 1 — Biometrics (Cross-Sector) **Art. 6 read with Annex III point 1** covers AI systems for biometric identification and biometric categorisation of natural persons. Real-time remote biometric identification in publicly accessible spaces by law enforcement is **prohibited** under **Art. 5(1)(h)**, not merely high-risk. Post-hoc biometric identification and biometric categorisation systems used in employment, border control, law enforcement (within permitted limits), and access control remain in the high-risk category. Any organisation deploying facial recognition, fingerprint matching, voice recognition, or similar systems for consequential decisions is within scope. ### Category 2 — Critical Infrastructure (Transport, Energy, Water) **Annex III point 2** covers AI used as safety components in the management and operation of critical digital infrastructure, road traffic, water supply, gas, heating, and electricity. Transport operators, energy grid managers, water utilities, and digital infrastructure providers must assess whether their AI systems qualify. **Annex I** of the AI Act also intersects here: AI safety components embedded within Annex I regulated products (machinery, vehicles, civil aviation equipment, rail systems) are high-risk under **Art. 6(1)**, not Annex III. ### Category 3 — Education and Vocational Training **Annex III point 3** covers AI that determines access to educational establishments, allocates students to educational pathways, assesses examination or test performance, evaluates learning achievement that substantially affects future opportunities, and monitors student behaviour during assessments. EdTech platforms, universities, vocational training providers, and examination bodies must assess their AI-driven tools against these criteria. ### Category 4 — Employment and HR **Annex III point 4** covers AI used in recruitment and selection (CV screening, candidate ranking, automated interview analysis), decisions on promotion, termination, task allocation for platform workers, monitoring of employee behaviour, and performance evaluation. This category is among the broadest in scope — virtually every organisation using AI-assisted HR processes must assess compliance. The obligation applies to AI used by employers, staffing agencies, and gig-economy platforms. ### Category 5 — Essential Private and Public Services (Finance, Insurance, Healthcare-Adjacent, Benefits) **Annex III point 5** is the broadest category, encompassing AI used in creditworthiness assessment and credit scoring for natural persons, insurance risk assessment and pricing, evaluation of eligibility for public benefits and social services, and emergency dispatch decisions. This category directly affects banks, insurers, public administrations, and social service providers. Health-related AI that scores individuals for insurance eligibility also falls here, creating overlap between financial services and healthcare obligations. ### Categories 6, 7, and 8 — Law Enforcement, Migration, Justice **Annex III points 6, 7, and 8** target public sector authorities and their technology suppliers. Law enforcement AI (risk scoring, recidivism prediction, crime prediction, evidence evaluation), migration and border control AI (asylum risk assessment, document verification, application processing), and justice and democratic process AI (judicial research tools, election-related AI) are all high-risk. These categories primarily affect police authorities, border agencies, immigration tribunals, courts, and their contracted AI providers. ## Sector Guides Each of the following dedicated guides maps the EU AI Act obligations to the specific regulatory context, typical AI use cases, and enforcement architecture of the sector. ### [Healthcare and Life Sciences](/en/sectors/healthcare/) Healthcare AI operates at the intersection of the EU AI Act and the Medical Device Regulation (MDR) and In Vitro Diagnostic Regulation (IVDR). AI systems that qualify as medical devices are regulated primarily under MDR/IVDR but remain subject to the AI Act's fundamental rights and transparency obligations. **Annex III point 5** captures AI used for health risk scoring in insurance and public benefit eligibility. Clinical decision support, diagnostic AI, patient triage tools, and drug discovery AI each carry specific obligations depending on their regulatory classification. ### [HR and Recruitment](/en/sectors/hr-recruitment/) **Annex III point 4** places virtually all AI-assisted HR processes in the high-risk category. CV screening tools, psychometric assessment platforms, automated interview video analysis, performance management systems, and workforce scheduling AI must comply with provider and deployer obligations. This guide addresses the obligations of employers as deployers under **Art. 26**, data governance requirements under **Art. 10**, and the interaction with GDPR profiling restrictions. ### [Public Sector and Justice](/en/sectors/public-sector/) Public authorities are simultaneously deployers of high-risk AI and the entities that national competent authorities will scrutinise most closely. **Annex III points 5 through 8** collectively cover a large portion of public sector AI: benefit eligibility determination, emergency services AI, law enforcement tools, border management systems, and judicial AI. This guide addresses the specific obligations of public deployers, transparency mandates for automated decisions affecting citizens, and the intersection with the GDPR and the Law Enforcement Directive. ### [Transport and Critical Infrastructure](/en/sectors/transport/) Transport operators must navigate both **Annex III point 2** (safety components in critical infrastructure) and **Annex I** product safety regulation. AI in autonomous vehicle systems, railway traffic management, air traffic management, port operations, and logistics routing may trigger high-risk classification under multiple pathways. This guide addresses the interaction with EASA regulations, the Rail Safety Directive, and the role of notified bodies in conformity assessment. ### [SMEs](/en/sectors/sme/) Small and medium-sized enterprises face the same EU AI Act obligations as large organisations when they are providers of high-risk AI or deployers using high-risk AI. However, the Act provides proportionality mechanisms. This guide explains simplified technical documentation options, access to regulatory sandboxes under **Art. 57 to Art. 63**, and how to structure a minimal but legally sufficient compliance programme. It also addresses SME exposure as deployers of third-party AI tools. ### [Insurance](/en/sectors/insurance/) Insurance AI is subject to **Annex III point 5(b)** (risk assessment and pricing for life and health insurance of natural persons) and intersects with Solvency II requirements for model governance and the use of internal models. Motor, health, property, and life insurance pricing AI, underwriting decision tools, and automated claims settlement systems all require assessment. This guide addresses the roles of EIOPA and national insurance supervisors alongside the AI Act's NCA framework. ### [Retail and Call Centres](/en/sectors/retail/) Retail and customer service operations are primarily affected by the **Art. 50 transparency obligations** — AI-generated content disclosure, chatbot identification, and deepfake labelling — and by employment-related AI under Annex III point 4. Emotion recognition systems used in customer-facing contexts are explicitly regulated. This guide addresses online retail AI, recommendation engines, automated customer service, and workforce management in contact centres. ### [Education and EdTech](/en/sectors/education/) **Annex III point 3** places educational AI in the high-risk category where it determines or substantially influences access to educational pathways or evaluates achievement. This guide addresses the obligations of EdTech providers, universities, vocational training bodies, and public examination authorities. It covers adaptive learning platforms, proctoring software, automated essay grading, and student risk prediction tools. ### [Financial Sector (Banking)](/en/financial-sector/) The banking sector guide addresses **Annex III point 5(b)** credit scoring and creditworthiness assessment, fraud detection AI, algorithmic trading systems, AML/KYC tools, and robo-advisory platforms. It examines the layering of EU AI Act obligations on top of DORA, MiFID II, CRR/CRD, and EBA guidelines. The intersection between the AI Act's model governance requirements and existing model risk management frameworks under EBA guidelines is a primary focus. ## Cross-Cutting Obligations Several EU AI Act obligations apply regardless of sector. Every organisation operating in the EU must understand these baseline requirements. ### Prohibited Practices — Art. 5 **Art. 5** establishes absolute prohibitions effective from **2 February 2025**. These apply to every sector without exception: subliminal manipulation techniques that cause harm, exploitation of vulnerabilities of natural persons, social scoring by public authorities, real-time remote biometric identification by law enforcement in public spaces (subject to narrow exceptions), emotion recognition in workplaces and educational institutions (outside specified uses), biometric categorisation using sensitive characteristics, and predictive policing based solely on profiling. No sector-specific exemption overrides these prohibitions. ### Transparency Obligations — Art. 50 **Art. 50** requires providers and deployers of AI systems that interact with natural persons to disclose the AI nature of the interaction. This applies to chatbots, virtual assistants, automated call centre systems, and any AI system designed to appear human. AI-generated content — synthetic media, deepfakes, text — must be machine-readable labelled. These obligations apply to retail, financial services, healthcare patient-facing tools, public sector citizen services, and every other sector deploying conversational or generative AI. ### GPAI Model Obligations — Art. 51 to Art. 55 Organisations that deploy GPAI models — large language models, foundation models, multimodal AI — must assess whether they are deployers of a third-party GPAI model or providers of a GPAI-integrated system. GPAI providers bear obligations under **Art. 53** (transparency to downstream providers, copyright policy, summary of training data). GPAI models with systemic risk bear additional obligations under **Art. 55**. Every sector using commercial foundation model APIs or self-hosted foundation models must assess these obligations. ## SMEs and Proportionate Obligations SMEs represent the majority of EU businesses and a growing proportion of AI system providers and deployers. The EU AI Act does not create a blanket SME exemption, but **Art. 9(5)**, **Art. 11**, and **Art. 16** require that provider obligations be proportionate to organisational size and capacity. The regulatory sandbox framework (**Art. 57 to Art. 63**) is specifically designed to provide SMEs and startups with supervised development environments, reduced regulatory uncertainty, and direct access to national competent authority guidance. Participation does not guarantee compliance clearance, but it provides a structured path to market entry for innovative AI products. For SMEs acting as deployers of high-risk AI provided by a third party, **Art. 26** obligations — use-case assessment, human oversight implementation, fundamental rights impact assessment — apply. The scale of documentation and monitoring required is proportionate, but the legal obligations are not waived. The dedicated [SME guide](/en/sectors/sme/) provides a compliance roadmap tailored to smaller organisations, covering prioritisation, minimum viable documentation, supplier due diligence, and sandbox access procedures. ## Enforcement The EU AI Act creates a layered enforcement architecture with significant sector-specific dimensions. ### National Competent Authorities Each EU Member State designates one or more national competent authorities (NCAs) under **Art. 70**. NCAs are responsible for authorising regulatory sandboxes, conducting market surveillance, receiving post-market monitoring data from providers, investigating suspected violations, and imposing administrative fines under **Art. 99 to Art. 101**. Maximum fines reach **€35 million or 7% of global annual turnover** for violations of Art. 5 prohibited practices. ### Sector Regulators as Market Surveillance Authorities **Art. 74(8) and Art. 74(9)** provide for sector regulators to act as market surveillance authorities for AI in their domains. The European Banking Authority (EBA), European Insurance and Occupational Pensions Authority (EIOPA), European Securities and Markets Authority (ESMA), European Medicines Agency (EMA), and European Union Aviation Safety Agency (EASA) each have roles in supervising AI within their regulatory perimeters. This creates dual-track enforcement exposure: a bank's credit scoring AI may be examined both by a national financial regulator applying Annex III obligations and by an NCA conducting AI Act market surveillance. ### The European AI Office The **European AI Office**, established under **Art. 64 to Art. 70**, holds direct enforcement authority over GPAI model providers. For organisations deploying GPAI models with systemic risk, the AI Office is the primary regulatory counterpart — not the national NCA. Sector regulators have no direct jurisdiction over GPAI models as such, though downstream AI systems integrating GPAI remain subject to national and sector supervision. ### Enforcement Timeline The prohibition on practices under **Art. 5** has applied since **2 February 2025**. GPAI obligations under **Art. 51 to Art. 55** became effective **2 August 2025**. Full obligations for Annex III high-risk AI systems — covering all eight categories and all provider and deployer duties — apply from **2 December 2027** (extended from the original 2 August 2026 deadline by the 2025 Digital Omnibus amendment). Organisations in all sectors should treat the period to December 2027 as an active compliance window, not a grace period. -------------------------------------------------------------------------------- ## Banking & Finance — EU AI Act Compliance Guide URL: https://www.regulation-ai.eu/en/sectors/banking/ ## Why Banking Faces Concentrated EU AI Act Exposure The banking and financial services sector sits at the intersection of the EU AI Act's strictest obligations and the most complex regulatory environment in the EU. Financial institutions are among the largest deployers of AI in Europe — in credit underwriting, fraud detection, AML/CFT screening, customer due diligence, algorithmic trading, and wealth management. The EU AI Act directly targets the most consequential of these use cases through **Annex III**, classifying several financial AI applications as **high-risk** by definition. Banking also operates under a dense pre-existing regulatory layer: **DORA**, **MiFID II**, **CRD IV/CRR**, **AML Directives**, **GDPR**, and **BCBS 239**. The EU AI Act does not replace these frameworks — it adds to them. For a credit institution, deploying an AI-based credit scoring model triggers simultaneous obligations under the AI Act (Annex III, Art. 9–16), DORA (ICT risk management), and the EBA's model risk management guidelines. ## High-Risk AI Use Cases in Banking Under Annex III **Annex III, category 5(b)** explicitly lists AI used for the evaluation of creditworthiness or credit scoring of natural persons, and AI used for assessing credit risk of legal persons where AI determines or substantially influences the outcome. This captures a broad range of financial AI deployments. **Credit scoring and underwriting models** — automated systems that determine loan eligibility, credit limits, or interest rates for retail and SME customers — are high-risk AI under Art. 6(2) read with Annex III. Banks acting as providers of these systems must complete conformity assessments, maintain technical documentation under Art. 11, implement risk management systems under Art. 9, ensure human oversight mechanisms under Art. 14, and register the system in the EU AI Act database (Art. 71) before deployment. **AML and fraud detection systems** present a more nuanced picture. Systems that apply sanctions screening, transaction monitoring, or behavioural analytics to flag suspicious activity generally affect financial institutions rather than directly determining outcomes for individuals. Where the AI output is the primary basis for adverse action against a customer (account freezing, refusal of service), high-risk classification may be triggered under Annex III cat. 5(b) or cat. 6 (law enforcement) depending on the national authority's role. Banks must conduct a careful classification analysis. **GPAI-based tools** — large language models used for customer service, document processing, or investment analysis — are subject to Art. 50 transparency requirements (disclosure that users interact with AI) and, where the model provider has systemic risk, Art. 55 obligations. ## Provider vs Deployer Obligations for Banks Banks may act as **providers** (building their own AI models), **deployers** (using third-party AI systems), or both. The distinction determines the obligation profile: | Role | Obligation source | Key requirements | |------|------------------|-----------------| | Provider | Art. 9–17 | Conformity assessment, technical documentation, QMS, registration | | Deployer | Art. 26 | Monitor system, ensure human oversight, maintain logs, inform users | | Both | Art. 9–17 + Art. 26 | Full provider obligations + deployer monitoring duties | Banks purchasing credit scoring AI from a fintech vendor act as deployers under Art. 26. They must verify the vendor has completed conformity assessment, integrate human review into adverse decision processes, maintain usage logs for 10 years (Art. 26(6)), and ensure that AI decisions are explained to affected individuals under GDPR Art. 22 and EU AI Act Art. 13. ## Sectoral Regulation Overlap: DORA, MiFID II, and Solvency II **DORA (Regulation 2022/2554)** applies to banks, investment firms, insurance companies, and ICT third-party providers. For AI specifically, DORA requires: - AI systems treated as ICT systems subject to risk management frameworks (Art. 6 DORA) - ICT-related incident classification and reporting — AI failures may constitute major ICT incidents - Resilience testing of critical ICT systems — AI models included where material to operations - Third-party risk management covering AI vendor contracts, exit strategies, and audit rights **MiFID II** (Markets in Financial Instruments Directive) applies to algorithmic trading and investment advice. AI-generated investment recommendations trigger suitability assessment requirements; algorithmic trading systems require pre-trade controls, kill switches, and regulatory notification. **EBA Guidelines on ICT and Security Risk Management** (EBA/GL/2019/04, updated 2022) mandate technology risk governance covering AI models, operational continuity requirements, and model validation independence. These align substantially with EU AI Act Art. 9 risk management requirements. ## Enforcement Authorities EU AI Act enforcement for banking AI operates through a dual-layer authority structure: **National Competent Authorities (NCAs)** designated by each Member State under Art. 70 are the primary AI Act enforcement bodies. They can conduct market surveillance, request technical documentation, and impose fines (up to €30M or 6% of global annual turnover under Art. 99). **European Banking Authority (EBA)** coordinates sector-specific AI oversight across the banking union, provides technical standards on ICT risk, and issues guidelines that shape national supervisory expectations. EBA also participates in the European AI Board established under Art. 65. **ECB and national prudential supervisors** may request AI model documentation as part of SREP (Supervisory Review and Evaluation Process) assessments under CRD IV where AI drives material credit or operational risk decisions. ## Compliance Roadmap for Banks **Immediate (now → August 2026):** Complete prohibition compliance check — review all AI systems for practices banned under Art. 5, including social scoring and real-time biometric identification in public spaces. These prohibitions apply immediately for new contracts. **Q3 2026 — High-risk classification audit:** Map all deployed and in-development AI systems against Annex III, specifically categories 5(b) and 5(c). Document classification rationale. Engage legal and compliance to assess DORA overlap. **Q4 2026 — Provider obligations for in-house AI:** For credit scoring and underwriting models built internally, initiate conformity assessment procedures, develop technical documentation per Annex IV, and implement QMS under Art. 17. **2027 — Deployer obligations for third-party AI:** Audit all AI vendor contracts for EU AI Act compliance. Require providers to furnish conformity declarations and registration numbers. Update data processing agreements to reflect Art. 26 logging obligations. **August 2027 — GPAI obligations effective:** Ensure all third-party LLMs and foundation models used in banking applications comply with Art. 51–55. Verify providers have published transparency documentation under Art. 53. **December 2027 — High-risk AI deadline:** Full compliance required for all Annex III high-risk AI systems. Ensure registration in the EU AI Act database, operational human oversight mechanisms, and post-market monitoring plans under Art. 72. -------------------------------------------------------------------------------- ## Education & EdTech — EU AI Act Compliance URL: https://www.regulation-ai.eu/en/sectors/education/ ## Education Sector and the EU AI Act — Why Student Rights Are Central The EU AI Act (Regulation (EU) 2024/1689) identifies education and vocational training as a domain of elevated risk, classifying specific AI applications within it as **high-risk** under **Annex III, category 3**. This classification reflects a foundational judgment by the European legislator: AI systems that shape access to educational opportunities or determine academic outcomes engage rights of profound individual significance — the right to education (Art. 14, EU Charter of Fundamental Rights), the right to non-discrimination (Art. 21), and, for the large proportion of students who are minors, the heightened protections of **GDPR Art. 8** and international frameworks including the **UN Convention on the Rights of the Child (UNCRC)**. The education sector presents a distinctive compliance profile. Most educational institutions — universities, schools, and vocational training bodies — occupy the role of **deployer** under the EU AI Act: they procure and operate AI systems built by EdTech vendors rather than developing AI in-house. This distinction does not reduce their obligations. Deployers of high-risk AI under **Art. 26** carry independent legal duties that cannot be discharged simply by purchasing a CE-marked product. At the same time, EdTech companies that develop and place AI systems on the EU market are **providers** subject to the full conformity assessment regime under **Chapter III, Section 2**. The sector is also characterised by a significant concentration of sensitive personal data. Student behavioral data, assessment records, engagement patterns, learning difficulties, and demographic profiles are processed at scale by adaptive learning platforms and analytics tools. This data concentration means that EU AI Act compliance in education cannot be designed in isolation from **GDPR** — the two frameworks must be addressed as an integrated compliance obligation. --- ## High-Risk AI in Education — Admissions, Grading, and Proctoring Annex III, category 3 defines two distinct categories of high-risk education AI. Understanding the scope of each category is essential for classification decisions. ### Admissions AI — Determining Access to Educational Institutions **Annex III, category 3(a)** covers AI systems intended to be used for the **determination of access or assignment to educational and vocational training institutions or programmes**. This category captures AI that scores, ranks, or filters applicants in university admissions processes, AI that assesses prior qualifications or recognition of professional credentials, and AI that determines eligibility for specific academic tracks or specialised programmes. The high-risk classification applies where the AI system's output has a **significant effect** on an applicant's access to an educational opportunity. This threshold is met by most operationally deployed admissions AI: a scoring model whose outputs are reviewed and acted upon by admissions officers without systematic re-evaluation of the underlying assessment effectively determines outcomes even if a human formally approves each decision. Providers of such systems must comply with **Arts. 9–15** (data governance, technical documentation, logging, transparency, human oversight, accuracy and robustness). Deploying institutions must verify compliance and implement **Art. 26** deployer obligations before the system is used in any admissions cycle. **Bias risk** is particularly acute in admissions AI. Systems trained on historical admission and academic success data may encode existing inequalities — gender gaps in certain disciplines, socioeconomic disparities in academic preparation, differential performance between domestic and international applicants. **Art. 10** requires training data to be subject to governance practices that address known biases, and **Art. 9** mandates risk management measures calibrated to the severity of potential harm, which in this context includes denial of educational opportunity to qualified applicants from disadvantaged groups. ### Automated Assessment AI — Grading and Academic Pathway Assignment **Annex III, category 3(b)** covers AI systems that **evaluate and assess students**, including AI-automated grading tools and systems that assign students to differentiated academic tracks, where those systems have a **significant effect on their educational pathways**. An automated essay grading tool that produces final grades determining whether a student passes or fails a course, receives a qualification, or gains progression to the next academic level is high-risk. Similarly, AI that places students into remedial, standard, or advanced tracks based on performance data has a significant effect on educational pathways and falls within this category. The boundary for formative assessment tools — tools used exclusively to provide feedback to students where a human educator retains full and effective control over all graded outcomes — is narrower. Such tools may fall outside category 3(b), but this classification must be documented and justified, and institutions must ensure that the human oversight is genuinely substantive rather than a formal rubber-stamp of AI-generated results. ### Remote Exam Proctoring AI Remote exam proctoring systems that monitor student behaviour during assessments through video analysis, eye-tracking, browser lockdown, keystroke logging, or behavioral anomaly detection represent one of the most legally complex AI applications in education. Where such systems **flag or disqualify students** based on their automated analysis — or where their outputs are used by human reviewers in ways that substantially determine outcomes — they constitute high-risk AI under **Annex III, category 3** as AI that evaluates students and has significant effects on their academic pathways. Proctoring AI also engages the **Art. 5(1)(d)** prohibition on **real-time remote biometric identification** in publicly accessible spaces. Where proctoring systems use facial recognition to continuously verify student identity during an exam in real time, this constitutes prohibited biometric identification unless a very narrow Member State legislative exception under **Art. 5(2)–(6)** applies. Institutions deploying proctoring AI must carefully distinguish between identity verification at the point of exam access (potentially lawful where compliant) and continuous real-time biometric surveillance throughout the exam session (subject to the Art. 5 prohibition). --- ## Provider vs. Deployer — EdTech Companies and Educational Institutions The EU AI Act allocates obligations asymmetrically between providers and deployers. Understanding this allocation is foundational to compliance planning for both EdTech vendors and the institutions that use their products. ### EdTech Provider Obligations EdTech companies that develop and place high-risk AI systems on the EU market are **providers** under **Art. 3(3)** and must comply with the full high-risk AI requirements in **Chapter III, Section 2**: - **Art. 9** — Establish and maintain a risk management system for the AI system's entire lifecycle - **Art. 10** — Implement data governance for training, validation, and testing datasets, addressing bias, representativeness, and statistical limitations - **Art. 11 and Annex IV** — Maintain comprehensive technical documentation demonstrating conformity - **Art. 12** — Ensure automatic logging of system operation enabling post-hoc review of AI decisions - **Art. 13** — Provide transparency information enabling deployers to understand the system's capabilities and limitations - **Art. 14** — Design the system to enable effective human oversight by deployers - **Art. 15** — Achieve appropriate accuracy, robustness, and cybersecurity for the intended educational context - **Art. 49** — Register the system in the EU AI database before or at market placement Providers must also supply deploying institutions with instructions for use that are specific enough to enable institutions to fulfil their own deployer obligations — including information on the student population subgroups for which the system has been tested, known performance limitations, bias testing results, and log management procedures. ### Institutional Deployer Obligations Universities, schools, and vocational training bodies that deploy high-risk EdTech AI under **Art. 26** must: - Verify that the AI system bears a CE mark and that an EU Declaration of Conformity is available - Implement the provider's instructions for use in full - Ensure qualified staff are assigned responsibility for human oversight, with sufficient technical competence and practical authority to intervene in AI-generated outputs - Maintain operational logs for a minimum period and make them available to national supervisory authorities upon request - Report serious incidents or malfunctions to the provider and, where relevant, to national AI supervisory authorities - Conduct or commission a **fundamental rights impact assessment (FRIA) under Art. 27** before deployment of AI assessment or admissions systems - Not modify high-risk AI systems in ways that alter their intended purpose without triggering provider re-assessment --- ## Interaction with GDPR, Children's Rights, and National Education Law ### GDPR and the Processing of Student Data Education AI operates on data that is intrinsically sensitive. Learning analytics platforms, adaptive tutoring systems, and behavioral proctoring tools process data that may include academic performance records, engagement metrics, behavioral signals, and communications — all linked to identifiable students. Where students are minors, **GDPR Art. 8** restricts the processing of personal data based on consent: Member States have set the age below which parental or guardian consent is required at between 13 and 16 years. EdTech platforms that rely on student consent as their legal basis for processing must age-gate their systems and implement mechanisms to verify and record parental consent where required. Institutions acting as **data controllers** under GDPR must ensure that their contracts with EdTech vendors include appropriate **data processing agreements under GDPR Art. 28** and that student data is not transferred outside the EEA without adequate safeguards. Processing of special categories of data — which may arise where learning difficulty assessments, mental health screening, or demographic profiling is involved — requires an explicit legal basis under **GDPR Art. 9(2)** and typically a Data Protection Impact Assessment under **Art. 35**. ### Art. 50 — Transparency for AI Tutoring Chatbots **Art. 50** of the EU AI Act imposes a specific transparency obligation on AI systems designed to interact directly with natural persons. AI-powered tutoring chatbots, virtual learning assistants, and AI-generated feedback tools deployed in educational settings must clearly disclose their AI nature to students at the outset of each interaction. Where the student audience includes minors, the disclosure must be adapted to be age-appropriate and genuinely comprehensible. Institutions deploying AI tutoring tools must verify that the vendor's implementation satisfies this obligation and must not configure the system in ways that suppress or obscure the AI disclosure. ### National Education Law National education legislation in EU Member States may impose additional obligations on AI use in academic settings — for instance, requirements relating to examination integrity, data retention for academic records, and procedural fairness in admissions appeals. Compliance programs for educational institutions must map EU AI Act and GDPR obligations against applicable national law, including sector-specific ministerial guidance issued by national education ministries. Where AI systems produce outputs that are used in formally regulated processes (state examinations, accredited qualifications), the interface between AI Act obligations and national examination law requires specific legal analysis. --- ## Enforcement — DPAs and Education Authorities Enforcement in the education sector involves a layered structure of competent authorities. **National AI supervisory authorities** (designated under Art. 70) hold primary jurisdiction over EU AI Act compliance, including conformity assessment, market surveillance, and penalties. For educational institutions, this authority may be a general AI supervisory authority or, in some Member States, a designated sectoral body. **Data Protection Authorities (DPAs)** play a major independent enforcement role. Given the volume and sensitivity of student data processed by education AI, DPAs actively supervise AI deployments in schools and universities. GDPR infringements related to education AI — unlawful processing of children's data, inadequate data processing agreements with EdTech vendors, failure to conduct required DPIAs — attract DPA fines of up to **€20 million or 4% of global annual turnover** under GDPR Art. 83. DPA enforcement actions have historically preceded formal AI Act enforcement in regulated domains, and education sector AI should be planned with DPA scrutiny as a near-term risk. **University governing bodies and national accreditation authorities** may impose institutional consequences — including reputational sanctions, suspension of automated processes, and requirements for independent audits — where AI use in admissions or assessment is found to have produced unfair or discriminatory outcomes. Institutional academic governance, including student appeals processes, must be designed to accommodate challenges to AI-influenced decisions. --- ## Compliance Roadmap for Educational Institutions and EdTech Providers ### For EdTech Providers 1. **Classify each product** against Annex III, category 3 — document the classification rationale with specific reference to the system's intended purpose and the significance of its effect on educational outcomes. 2. **Implement the full high-risk conformity assessment regime** under Arts. 9–15 for all products classified as high-risk, including bias testing across demographic subgroups representative of the EU student population. 3. **Register high-risk systems** in the EU AI database (Art. 49) before market placement. 4. **Prepare complete deployer-facing documentation**: instructions for use, conformity documentation, bias and accuracy testing results, log management guidance. 5. **Implement Art. 50 transparency** in all AI systems that interact directly with students. 6. **Review data processing agreements** to ensure GDPR Art. 28 compliance, including mechanisms for parental consent where required under Art. 8. ### For Educational Institutions 1. **Audit all AI systems in use** — admissions, grading, proctoring, analytics, tutoring — and classify against Annex III, category 3. 2. **Request and review conformity documentation** from all EdTech vendors for any system classified or potentially classifiable as high-risk. 3. **Conduct fundamental rights impact assessments** under Art. 27 before deploying or continuing to deploy AI admissions or assessment systems. 4. **Assign named oversight responsibility** for each high-risk AI system to qualified staff with genuine technical competence and institutional authority. 5. **Review admissions and assessment appeals processes** to ensure they accommodate challenges to AI-influenced decisions and provide meaningful human review. 6. **Audit GDPR compliance** for all student data processed by EdTech platforms — confirm data processing agreements, legal bases, and parental consent mechanisms are in place. 7. **Verify proctoring AI configurations** for compliance with Art. 5 prohibition on real-time biometric identification — if any configuration involves continuous facial recognition during exam sessions, obtain urgent legal advice before the next examination period. -------------------------------------------------------------------------------- ## Healthcare & Life Sciences — EU AI Act Compliance URL: https://www.regulation-ai.eu/en/sectors/healthcare/ ## Why the EU AI Act Has Particular Significance in Healthcare The EU AI Act (Regulation (EU) 2024/1689) creates its most demanding compliance obligations precisely in domains where AI errors carry life-or-death consequences. Healthcare and life sciences sit at the intersection of two such demands: the Act's structural classification of medical-device AI as high-risk under **Art. 6(1)**, and the sector's existing regulatory density under **MDR (EU) 2017/745**, **IVDR (EU) 2017/746**, **GDPR Art. 9**, and the **Clinical Trials Regulation (EU) 536/2014**. For health AI providers and deployers, this intersection is not merely additive. It creates layered obligation sets that must be designed, documented, and monitored together. An AI system embedded in a diagnostic imaging device must satisfy notified body conformity assessment under MDR and a separate conformity assessment under the EU AI Act. A hospital deploying an AI-driven triage tool becomes a **deployer** under **Art. 26** with independent obligations that cannot be discharged by relying on the vendor's CE marking alone. The stakes for non-compliance are correspondingly high. National supervisory authorities may impose fines of up to **€30 million or 6% of global annual turnover** for placing non-compliant high-risk AI on the market. Beyond financial penalties, market withdrawal orders, suspension of clinical use, and mandatory corrective actions can interrupt patient care at scale. ### The Dual Regulatory Track The defining structural feature of healthcare AI compliance is the simultaneous application of product-safety law and AI-specific law. Where an AI system constitutes a **safety component** of a medical device as defined in **Annex I of the EU AI Act** (cross-referencing the New Legislative Framework), it is automatically classified as high-risk under **Art. 6(1)** without any further assessment of probability or severity of harm. The classification is categorical. This means organisations must maintain two parallel conformity assessment tracks — one under MDR or IVDR, one under the EU AI Act — and must demonstrate compliance with both in the **EU database for high-risk AI systems (EUAI DB)** prior to market placement. --- ## High-Risk AI Use Cases — Medical Devices and Care Delivery ### Diagnostic Imaging AI AI systems deployed in radiology, pathology, and ophthalmology that analyse images to detect, classify, or characterise lesions, abnormalities, or disease states are, in virtually all clinically relevant configurations, **safety components of medical devices** under MDR Class IIa or higher. They are therefore high-risk under **Art. 6(1)** and must comply with **Chapter III Section 2** of the EU AI Act, covering data governance (**Art. 10**), technical documentation (**Art. 11, Annex IV**), automatic logging (**Art. 12**), transparency (**Art. 13**), human oversight (**Art. 14**), and accuracy, robustness, and cybersecurity (**Art. 15**). ### Clinical Decision Support Systems **Clinical decision support (CDS)** tools span a wide risk spectrum depending on their functional role. The critical regulatory distinction is whether the system **replaces** or **assists** clinical judgment: - **Autonomous or near-autonomous output**: A CDS system that generates a prescription recommendation, determines a patient's medication dosage, or classifies a patient as requiring emergency intervention without requiring clinician review before the output is acted upon is likely to be high-risk under **Annex III** and potentially constitutes a medical device under MDR. - **Filtered output for clinician review**: A CDS that presents ranked differential diagnoses or flags lab results as abnormal, where a qualified clinician reviews and approves each recommendation before it affects patient management, may not qualify as high-risk, provided it does not independently meet Annex III criteria on other grounds. This distinction must be documented in the AI system's **intended purpose** statement, which forms part of both the AI Act technical documentation and the MDR technical file. ### Patient Triage Prioritisation in Emergency Settings AI systems that prioritise the order in which emergency patients receive attention — including sepsis prediction models and ICU monitoring systems that trigger escalation protocols — operate in conditions of time pressure and clinical complexity that make **human oversight under Art. 14** particularly demanding. Deploying organisations must ensure that the oversight mechanism is genuinely effective: the clinician assigned oversight responsibility must have the technical understanding, access to the AI's reasoning, and time in the workflow to intervene before the system's output affects patient outcomes. ### Mental Health Screening AI AI tools used to screen populations or individual patients for mental health conditions — depression risk scores, suicide risk stratification, burnout screening — engage both the AI Act's high-risk provisions (where they influence access to care or resource allocation) and **GDPR Art. 9** in an especially sensitive dimension. Mental health data is health data for GDPR purposes; its processing for AI training or inference requires a lawful basis under Art. 9(2) and appropriate safeguards under Art. 22 (automated individual decision-making). ### Surgical Robotics and AI-Guided Procedures AI components integrated into surgical robotic systems that adapt procedural parameters in real time — instrument positioning, haptic feedback modulation, tissue classification — are safety components of active implantable devices or Class III medical devices under MDR. The conformity assessment burden is accordingly the highest available: **notified body assessment under MDR Annex IX or X**, combined with **EU AI Act conformity assessment** under **Art. 43**. Post-market surveillance obligations under both frameworks must be integrated into a single clinical follow-up and performance monitoring system. ### Annex III Category 5(a) — Access to Essential Healthcare Services Beyond the medical device pathway, **Annex III, point 5(a)** of the EU AI Act separately classifies as high-risk AI systems used to determine access to essential public services, including healthcare. An AI system that determines whether a patient qualifies for a reimbursed treatment, is included in a transplant waiting list, or is eligible for a clinical trial is high-risk under this provision even if it is not embedded in a medical device. --- ## Provider vs. Deployer Obligations in Healthcare ### Provider Obligations Organisations that **develop, place on the market, or put into service** a high-risk health AI system as providers under **Art. 16** must: - Establish and implement a **quality management system (QMS)** under **Art. 17**, covering design controls, risk management aligned with **ISO 14971** (harmonised for MDR), and post-market monitoring procedures. - Prepare **technical documentation** under **Annex IV**, including the intended purpose, risk management file, training data descriptions, validation and testing results, and post-market monitoring plan. - Register the system in the **EU database** prior to market placement (**Art. 49**). - Ensure the system carries a **CE marking** and provide an **EU Declaration of Conformity**. - Appoint an **EU Authorised Representative** if established outside the EU. - Maintain the technical documentation and logs for **10 years after market placement** (**Art. 18**). ### Deployer Obligations Hospitals, clinics, pharmacy networks, and other healthcare institutions acting as **deployers** of third-party high-risk AI systems bear obligations under **Art. 26** that are independent of the provider's compliance: - Implement the system within the **scope of the provider's instructions for use** — any use outside that scope potentially re-classifies the institution as a provider. - Assign **human oversight** responsibilities to staff with the competence, authority, and tools to monitor and intervene in system operation. - Maintain **operational logs** for at least six months, or longer where applicable sector legislation (MDR vigilance, hospital record-keeping laws) requires it. - Report serious incidents or malfunctions to the provider promptly, and where patient safety is implicated, to relevant health authorities under **MDR Art. 87** vigilance procedures. - Conduct **fundamental rights impact assessments (FRIAs)** under **Art. 27** where the AI system is used to make or assist decisions affecting individual patients at scale. --- ## Interaction with MDR, IVDR, and GDPR ### MDR and IVDR: The Dual Conformity Assessment Regime **Art. 6(1)** of the EU AI Act, read with **Annex I**, establishes the safety-component pathway. Where an AI system is a safety component of a product regulated under MDR or IVDR, the EU AI Act conformity assessment must be integrated into the existing MDR/IVDR procedure. **Art. 8(1)** of the EU AI Act gives precedence to MDR/IVDR sector-specific rules where they impose equivalent or stricter obligations, but does not eliminate AI Act obligations — it adjusts the procedure, not the requirement. For **Class IIb and Class III** medical devices with embedded AI, a notified body assessment under **MDR Annex IX (quality management) or Annex X (type examination)** is mandatory. The same notified body, if designated under the AI Act, may conduct the AI Act conformity assessment as part of an integrated procedure. For **Class I SaMD (software as medical device)**, manufacturers must independently assess whether the AI system qualifies as high-risk under the AI Act on grounds other than Art. 6(1). ### GDPR Art. 9 and Training Data Health data used to train, validate, or test AI models is **special category data** under **GDPR Art. 9(1)**. Processing is prohibited absent one of the derogations in Art. 9(2), most relevantly: - **Art. 9(2)(a)**: explicit consent of the data subject - **Art. 9(2)(h)**: processing necessary for medical diagnosis or provision of health care, subject to professional secrecy - **Art. 9(2)(j)**: scientific research, subject to Art. 89 safeguards The EU AI Act's **Art. 10** data governance obligations — which require documentation of the origin, collection methods, representativeness, and known limitations of datasets — must be satisfied in a manner consistent with the applicable GDPR legal basis. Retrospective use of clinical datasets without explicit consent requires a research derogation and, typically, ethics committee approval under the **Clinical Trials Regulation** or applicable national research law. ### Post-Market Surveillance Integration Both MDR (**Art. 83**, Post-Market Clinical Follow-Up) and the EU AI Act (**Art. 72**, post-market monitoring) require ongoing collection and analysis of real-world performance data. Where both apply, a single integrated post-market surveillance system can satisfy both frameworks, provided it captures the data points required by each — including MDR's clinical evidence requirements and the AI Act's requirements for automatic logging of AI system operation. --- ## Enforcement Authorities ### European Medicines Agency and National Medicines Agencies The **European Medicines Agency (EMA)** has no direct enforcement role under the EU AI Act for non-medicinal-product AI, but its guidance on AI in medicinal product development and pharmacovigilance is authoritative for life sciences companies. National medicines agencies — including **ANSM** (France), **BfArM** (Germany), and their equivalents — exercise MDR and IVDR market surveillance authority and may investigate AI systems embedded in medical devices as part of their post-market surveillance mandate. ### Notified Bodies For high-risk AI systems that are safety components of medical devices, **notified bodies** designated under MDR/IVDR and, separately or jointly, under the EU AI Act conduct conformity assessments. Their certificates are a prerequisite for CE marking. Notified bodies may suspend or withdraw certificates where post-market surveillance reveals non-conformities. ### National AI Supervisory Authorities Each EU member state has designated or is designating a **national AI supervisory authority** (competent authority under **Art. 70** of the EU AI Act). In the healthcare sector, coordination between the AI supervisory authority and the national medicines agency is required where jurisdiction overlaps. The AI supervisory authority has powers to request documentation, conduct audits, impose corrective measures, and refer cases for financial penalties. --- ## Compliance Roadmap — Priorities for Health AI ### Step 1: Classification and Scope Assessment Map all AI systems in development or deployment against **Art. 6(1)** (safety component of a medical device) and **Annex III, point 5(a)** (access to essential services). Document the intended purpose of each system with sufficient precision to support both AI Act and MDR/IVDR classification decisions. Engage regulatory counsel to assess borderline CDS tools. ### Step 2: Dual Conformity Assessment Planning For each high-risk AI system that is also a medical device, identify the applicable MDR/IVDR conformity assessment route and determine whether the designated notified body is also accredited under the EU AI Act. Plan the conformity assessment as an integrated procedure where possible to reduce duplication. ### Step 3: Data Governance and GDPR Alignment Audit training and validation datasets for health AI systems. Document legal bases under GDPR Art. 9(2) for all health data used in model development. Establish data governance procedures under **Art. 10** of the EU AI Act and ensure these are reflected in the technical documentation required by **Annex IV**. ### Step 4: Human Oversight Protocols Design and implement human oversight mechanisms under **Art. 14** for each high-risk AI deployment. Oversight must be operationally realistic: it requires trained staff, accessible intervention mechanisms, and workflow integration — not a pro forma checkbox. For emergency settings with time pressure, the oversight design requires particular care. ### Step 5: Post-Market Surveillance Integration Design a post-market surveillance system that satisfies both MDR **Annex III (PMCF)** and EU AI Act **Art. 72** requirements. Establish incident reporting procedures that align with MDR vigilance timelines (**Art. 87**: serious incidents reported within 15 days) and AI Act serious incident reporting under **Art. 73**. ### Step 6: Deployer Due Diligence Healthcare institutions procuring third-party AI diagnostic or CDS tools should require providers to produce the EU Declaration of Conformity, the instructions for use, and a summary of the technical documentation. Procurement contracts should specify log retention obligations, incident reporting responsibilities, and the boundaries of the permitted use scope to avoid inadvertent re-classification as a provider. -------------------------------------------------------------------------------- ## HR & Recruitment — EU AI Act Compliance URL: https://www.regulation-ai.eu/en/sectors/hr-recruitment/ ## Why the EU AI Act Is Central to HR Technology Artificial intelligence has become deeply embedded in employment practices across the EU — from automated resume parsing in applicant tracking systems to real-time performance dashboards and behavioural analytics in contact centres. The EU AI Act, in force since **1 August 2024** with obligations on high-risk AI systems applying from **2 August 2026**, treats employment AI as an area of fundamental rights sensitivity warranting the highest level of regulatory scrutiny. **Annex III, category 4** of the Regulation identifies AI systems used in employment, workers management, and access to self-employment as **high-risk** across three distinct sub-categories: recruitment and selection (cat 4(a)), decisions on promotion, task allocation, and monitoring of contractual obligations (cat 4(b)), and real-time monitoring of emotional or behavioural states of workers (cat 4(c)). This classification is categorical — there is no materiality threshold, no carve-out for small deployments, and no distinction based on whether the tool is proprietary or acquired from a third-party vendor. The sector sits at the intersection of three regulatory frameworks: the AI Act, **GDPR** (in particular Art. 22 on automated decision-making), and national labour law — including co-determination rights over workplace technology. Compliance requires a coordinated approach spanning legal, HR, IT, and works council engagement. --- ## High-Risk Use Cases — All Annex III Category 4 Systems ### Recruitment and Selection (Cat 4(a)) AI systems used in the recruitment lifecycle are high-risk without exception. This encompasses: - **CV and resume screening tools** integrated into ATS platforms (Workday, SAP SuccessFactors, Greenhouse, Lever, SmartRecruiters). Ranking, shortlisting, and rejection logic driven by AI falls squarely within cat 4(a). - **Video interview analysis tools** that assess facial expressions, voice tone, speech patterns, or micro-expressions to infer candidate suitability or personality traits (e.g., HireVue-type tools). These may also trigger **Art. 50(2)** transparency obligations if they incorporate emotion recognition. - **Targeted job advertising algorithms** that determine which individuals are shown job postings based on inferred characteristics — including age, gender, or geographic indicators — are explicitly enumerated in cat 4(a) and present particular risk of discriminatory targeting. ### Workforce Management and Monitoring (Cat 4(b)) AI used to manage the employment relationship after hiring is equally high-risk: - **Performance evaluation AI** that generates scores, ratings, or ranking outputs used to inform promotion, bonus, or termination decisions. - **Task allocation algorithms** in gig economy platforms (**Uber, Deliveroo, Amazon Flex**) that assign work, set pay rates, and determine deactivation. These are high-risk under cat 4(b) regardless of the employment classification of the worker. - **Productivity monitoring software** that aggregates keyboard activity, application usage, communication metadata, or location data to produce performance metrics. Where outputs feed into contractual decisions, cat 4(b) applies. ### Real-Time Emotional and Behavioural Monitoring (Cat 4(c)) **Annex III cat 4(c)** is targeted specifically at systems that monitor the emotional or behavioural state of workers in real time. Common deployments in scope: - **Call centre emotion analytics** that assess caller and agent sentiment during live calls and generate performance flags. - **Biometric wellbeing platforms** that infer stress, fatigue, or engagement levels from physiological or behavioural signals. - **Attention and engagement monitoring** during remote work using webcam-based inference. These systems additionally trigger **Art. 50(2)**: any deployer using emotion recognition on workers must notify those workers that they are subject to the system. This notification obligation applies irrespective of whether the broader high-risk compliance timeline has been met. --- ## Provider vs Deployer Obligations — The Employer's Position Under the AI Act, most employers occupy the **deployer** role — they procure high-risk AI systems from providers (software vendors) and deploy them in their HR processes. The provider/deployer distinction is legally significant because obligations differ. ### Provider Obligations (Vendor Responsibilities) Providers — HR software vendors — must, before placing high-risk systems on the EU market: - Establish and maintain a **quality management system** (**Art. 9**) covering risk management, data governance, technical documentation, and post-market monitoring. - Prepare **technical documentation** per **Annex IV** demonstrating the system's design, intended purpose, performance metrics, training data, and known limitations. - Conduct a **conformity assessment** under **Art. 43** and register the system in the EU database (**Art. 49**). - Affix the **CE marking** and issue an **EU declaration of conformity**. - Provide deployers with **instructions for use** (**Art. 13**) including information on limitations, intended user profiles, and oversight requirements. ### Deployer Obligations (Employer Responsibilities) Employers must: - **Verify provider compliance** before deploying: check for CE marking, conformity declaration, and adequate instructions for use. - **Implement in accordance with instructions**: deployers may not use the system for purposes beyond its stated intended use (**Art. 25(1)**). - **Ensure meaningful human oversight** (**Art. 25(2)**): employees designated to supervise AI outputs must have the authority, technical competence, and time necessary to understand system outputs and override them when appropriate. Nominal human review — a checkbox sign-off without genuine evaluation — does not satisfy this requirement. - **Conduct a fundamental rights impact assessment (FRIA)** (**Art. 27**): mandatory for public-sector deployers; strongly recommended for private-sector employers deploying cat 4 systems, particularly where outputs affect protected characteristics. - **Monitor for post-deployment risks**: if a deployer identifies risks that the provider did not foresee, the deployer must notify the provider and, where relevant, the market surveillance authority. - **Suspend use** if serious incidents occur or if the system is found to be non-compliant in operation. --- ## Interaction with GDPR Article 22 and Labour Law ### GDPR Article 22 — Automated Decision-Making **GDPR Art. 22** remains fully operative alongside the AI Act and applies directly to HR AI. It prohibits decisions based **solely** on automated processing where those decisions produce legal effects or similarly significant effects on the data subject. In the employment context, the following decisions are unambiguously in scope: hiring and rejection, termination, promotion and demotion, pay determination, and disciplinary action. Compliance requires: - **Meaningful human intervention** before any consequential decision — the reviewing human must have access to the underlying data and logic, not merely a summary recommendation. - **Right to obtain human review** of any automated decision upon request, with genuine reconsideration capacity. - A **legal basis** for processing under Art. 6 and, where special category data is involved (health, ethnicity, biometric data inferred from facial analysis), under **Art. 9**. The AI Act and GDPR are **complementary, not mutually exclusive**. Art. 2(7) of the AI Act confirms that it applies without prejudice to GDPR. Employers must satisfy both regimes simultaneously. ### National Labour Law — Works Councils and Co-Determination In several EU member states, national labour law confers co-determination rights over workplace technology that apply to AI systems independently of the AI Act: - **Germany — Betriebsverfassungsgesetz §87(1) no. 6**: the works council has a binding co-determination right on the introduction of technical devices designed to monitor employee behaviour or performance. Deployment of AI monitoring or evaluation tools without prior works council agreement may be challenged before the labour court (Arbeitsgericht) and enjoined. - **Netherlands — Wet op de ondernemingsraden (WOR) Art. 27**: the ondernemingsraad has consent rights over personnel systems and monitoring arrangements. - **Austria — Arbeitsverfassungsgesetz §96**: binding co-determination on monitoring measures affecting personal dignity. - **France — Code du Travail L. 2312-38**: the Comité Social et Économique must be informed and consulted before deployment of automated tools affecting working conditions. Works council rights typically require advance notice, documentation of the system's functioning, and in many cases formal agreement or a works agreement (Betriebsvereinbarung) before deployment. These obligations are triggered before the AI Act compliance timeline and cannot be deferred. **Directive 2002/14/EC** on information and consultation of employees also provides a framework for European Works Councils of multinational groups deploying AI tools across member states. --- ## Enforcement — DPAs, Equality Bodies, and Labour Inspectorates Enforcement of AI Act obligations in the HR sector will involve multiple competent authorities: - **Data Protection Authorities (DPAs)**: the primary market surveillance authority designation in many member states will sit with or alongside the DPA. DPAs have concurrent competence under GDPR Art. 22 for automated decision-making violations. The EDPB guidelines on AI and employment remain the authoritative interpretation at EU level. - **National equality bodies**: where AI systems produce discriminatory outcomes in recruitment or promotion — for example, disparate impact on women, ethnic minorities, or older workers — equality bodies (e.g., ECRI, Défenseur des droits, Equinet members) have investigative and enforcement powers under the **Equal Treatment Directives** (2000/43/EC, 2000/78/EC, 2006/54/EC). - **Labour inspectorates**: in member states with strong labour inspection regimes, inspectors may investigate AI-related breaches of working conditions, monitoring limitations, and works council rights. France (DREETS), Germany (Gewerbeaufsicht), and Spain (Inspección de Trabajo) are examples of active enforcement bodies. Penalties under the AI Act reach **€30 million or 6% of global annual turnover** for prohibited practices, and **€15 million or 3% of turnover** for other high-risk violations. GDPR fines under Art. 83 apply cumulatively. Reputational risk and employee litigation under national labour law represent additional exposure. --- ## Compliance Roadmap for HR Professionals A structured compliance programme for employers deploying AI in HR should address the following in sequence: **1. AI system inventory**: catalogue all AI tools used across the employment lifecycle — recruitment, onboarding, performance management, workforce planning, and exit. For each tool, identify the Annex III category and confirm high-risk classification. **2. Provider due diligence**: before 2 August 2026 (or at next contract renewal), demand from each vendor: CE marking, EU declaration of conformity, technical documentation summary, and instructions for use. Vendors unable to provide these should be treated as non-compliant. **3. Works council consultation**: initiate co-determination or consultation procedures under applicable national law for all AI systems not yet subject to formal agreement. Document outcomes in a works agreement or equivalent instrument. **4. GDPR Art. 22 audit**: map all HR decisions with legal or significant effects and verify that no decision rests solely on automated output. Implement human oversight protocols with documented reviewer competence and intervention records. **5. Fundamental rights impact assessment**: conduct FRIA under Art. 27 for all Annex III cat 4 deployments. For public-sector employers, this is mandatory; for private-sector employers, it is the expected standard of due diligence and a defence against enforcement action. **6. Transparency obligations**: implement Art. 50(2) employee notification for any emotion recognition system. Ensure job applicants are informed of AI-assisted screening under GDPR transparency requirements (Arts. 13–14). **7. Human oversight capacity**: verify that personnel designated to review AI outputs in HR have genuine authority to override recommendations, sufficient time to conduct meaningful review, and documented training appropriate to the complexity of the system. **8. Incident response procedures**: establish procedures for logging, investigating, and reporting serious incidents involving HR AI systems, in line with **Art. 73** provider obligations passed through to deployers via contractual arrangements. Compliance in this sector is not a one-time project. The combination of AI Act obligations, evolving DPA guidance on GDPR Art. 22, and active works council engagement requires an ongoing governance structure with dedicated ownership within HR, legal, and data protection functions. -------------------------------------------------------------------------------- ## Insurance — EU AI Act Compliance URL: https://www.regulation-ai.eu/en/sectors/insurance/ ## Insurance and the EU AI Act — the Actuarial Challenge The EU AI Act (Regulation (EU) 2024/1689) imposes its highest compliance burden on AI systems that affect the ability of natural persons to access essential services and financial products. Insurance sits at the centre of this concern. AI systems that determine whether a natural person can obtain motor, health, life, or property insurance — and at what cost — are, in many configurations, **high-risk AI systems** under **Annex III, point 5(b)** of the Act. The defining challenge for the insurance sector is actuarial. For over a century, insurance pricing has been grounded in statistical modelling of risk across population cohorts. The EU AI Act does not prohibit actuarial differentiation, but it imposes substantive obligations on the AI systems through which such differentiation is executed when those systems operate at the level of the individual natural person. The shift from traditional pooling models to **AI-driven individual risk scoring** — enabled by telematics, health data streams, and behavioural analytics — is precisely what triggers the Act's high-risk regime. Insurers operating in the EU must therefore undertake a systematic classification exercise: which of their AI systems produce individualised outputs that determine or significantly influence coverage decisions for natural persons? That classification exercise is not merely a compliance formality. Its outcome determines whether the insurer, as a **deployer** under **Art. 26** (or provider under **Art. 16**), bears obligations relating to data governance, technical documentation, human oversight, conformity assessment, and registration in the EU database for high-risk AI. The Act's application to insurance is further complicated by the sector's existing regulatory density. **Solvency II Directive (2009/138/EC)**, the **Insurance Distribution Directive (IDD) (EU) 2016/97**, **GDPR**, and **EIOPA's principles-based AI guidelines (2021)** each impose requirements on actuarial modelling, customer treatment, and data use. These frameworks overlap with — but do not substitute for — EU AI Act obligations. Compliance programmes must address all simultaneously. --- ## High-Risk AI Use Cases in Insurance ### Actuarial Pricing Models for Natural Persons **Annex III, point 5(b)** of the EU AI Act classifies as high-risk any AI system used to evaluate the creditworthiness of natural persons or to classify natural persons in terms of their risk profile for the purpose of accessing insurance services. This covers actuarial AI systems that: - Generate an **individual risk score** used to set a motor insurance premium for a named policyholder - Classify a natural person's health status or mortality risk to determine life insurance coverage eligibility or premium - Produce a property insurance pricing decision based on AI-assessed risk factors attributable to a specific natural person The critical threshold is individual natural person impact. Actuarial AI applied to **legal entities** — corporate liability, commercial cargo, industrial property — does not trigger **Annex III cat 5(b)** unless natural persons are affected in a materially equivalent way. Insurers writing both personal and commercial lines must classify each AI system by the population it acts upon. ### Motor Insurance Telematics and Pay-as-You-Drive Systems Telematics-based insurance pricing systems that collect driving behaviour data — speed, acceleration, braking patterns, time-of-day usage — and use AI models to generate an individual premium for a named natural person are the paradigmatic high-risk insurance AI use case. These systems meet all elements of **Annex III cat 5(b)**: they evaluate individual natural persons, they produce outputs that determine access to and pricing of insurance, and their AI-driven individualisation is precisely what distinguishes them from traditional actuarial pooling. Providers of telematics scoring engines — whether developed in-house or licensed from a third-party vendor — must comply with **Art. 9** (risk management), **Art. 10** (data governance for training and validation datasets), **Art. 11** read with **Annex IV** (technical documentation), **Art. 12** (logging), **Art. 13** (transparency), **Art. 14** (human oversight), and **Art. 15** (accuracy, robustness, cybersecurity). ### Life and Health Insurance Underwriting AI AI systems used in life insurance underwriting to assess longevity or mortality risk for individual applicants — determining whether coverage is offered and at what premium — are high-risk under **Annex III cat 5(b)** where they produce individualised assessments for natural persons. This includes AI systems that process health questionnaire responses, medical records (where lawfully accessed), or wearable device data streams to generate a risk score that influences underwriting decisions. Health insurance AI that segments individual applicants by health risk profile for the purpose of pricing or eligibility determination is subject to the same classification. Insurers must be attentive to the intersection of **GDPR Art. 9** (health data as special category data) and the AI Act's **Art. 10** data governance requirements: training datasets containing health data require an explicit GDPR Art. 9(2) legal basis, and this basis must be documented in the technical documentation required by **Annex IV**. ### Claims Assessment and Settlement AI The classification of claims AI depends on its functional role in the claims decision workflow. Two scenarios must be distinguished: - **AI that significantly influences a claims outcome for a natural person**: where an AI system assesses a claim and its output directly results in reduction, rejection, or conditional payment of an insurance benefit to a natural person — even if nominally reviewed by a human — the system is likely high-risk under **Annex III cat 5(b)**, because it effectively determines the natural person's access to insurance benefits. - **AI that flags claims for human investigation**: where the AI output is one input among several considered by a claims handler who makes an independent substantive decision, and the handler has the authority and information to depart from the AI's assessment, the system may not be high-risk. This distinction must be documented and operationally genuine, not nominal. ### Insurance Fraud Detection AI systems used to detect potentially fraudulent claims occupy an important borderline. Where the fraud detection AI triggers an automatic adverse action — suspension of payment, policy cancellation — affecting a natural person without substantive human review, it is likely high-risk. Where the AI only generates a fraud risk flag that is then investigated by a specialist handler who retains full decision authority, it may not be. Insurers should document the fraud AI workflow in detail and assess whether the operational human oversight is substantive or nominal. --- ## Provider vs Deployer in Insurance ### Distinguishing Roles The EU AI Act imposes different obligation sets depending on whether an organisation is a **provider** (develops and places the AI on the market) or a **deployer** (uses a third-party AI system in a professional context). For insurers, this distinction is commercially significant: - An insurer that **develops its own telematics scoring engine or actuarial pricing AI** is a **provider** under **Art. 3(3)** and bears the full provider obligations under **Art. 16**: quality management system, technical documentation, EU Declaration of Conformity, CE marking, registration in the EU database, and post-market monitoring. - An insurer that **licenses actuarial AI software from a vendor** is a **deployer** under **Art. 3(4)** and bears deployer obligations under **Art. 26**: implementation in accordance with the provider's instructions, human oversight, log maintenance, and incident reporting. - An insurer that **modifies** a licensed AI system in ways that alter its intended purpose — for example, by applying a telematics model to a policyholder population outside the validated scope — may be **re-classified as a provider** under **Art. 25(1)** with full provider obligations. ### Deployer Due Diligence for Actuarial Vendor AI Insurers deploying third-party actuarial AI systems must exercise structured due diligence before and after deployment: **Pre-deployment**: Verify that the AI system is registered in the EU database for high-risk AI under **Art. 49**, bears a CE mark, and is accompanied by an EU Declaration of Conformity. Request and review the technical documentation summary, including accuracy and bias metrics, the validated use case scope, and the intended purpose statement. **Contractual protections**: Procurement contracts with AI vendors should specify: the vendor's obligation to notify the insurer of significant updates or re-assessments; the vendor's obligation to produce updated post-market monitoring data on request; and the boundaries of the permitted deployment scope — with a clear mechanism for the insurer to request a scope extension assessment rather than proceeding unilaterally. **Ongoing monitoring**: Under **Art. 26(5)**, deployers must monitor the performance of high-risk AI systems in their operational context. For actuarial AI, this means tracking model performance against actual claims outcomes, monitoring for distributional shift between the training population and the live policyholder population, and escalating material deviations to the vendor for investigation. --- ## Interaction with Solvency II, IDD, and GDPR ### Solvency II — System of Governance and ORSA The **Solvency II Directive** Pillar II requirements establish a System of Governance over actuarial and risk management functions. The **Own Risk and Solvency Assessment (ORSA)** requires documented risk identification, stress testing, and internal model governance. These requirements overlap substantially with the EU AI Act's **Art. 9** risk management system and the model validation components of **Annex IV** technical documentation. Insurers should conduct a structured gap analysis to identify which Solvency II governance artefacts can be leveraged for AI Act compliance and which gaps remain. Key gaps typically include: AI-specific bias testing and fairness assessment (not addressed in Solvency II); **Art. 10** dataset documentation for training and validation data (which extends beyond Solvency II model validation scope); **Art. 12** automatic logging of AI system operation; and **Art. 14** human oversight mechanism design. Where an internal model approved under Solvency II incorporates AI components, the governance framework for that model must be extended to satisfy AI Act obligations before the system can be lawfully deployed under the high-risk regime. ### Insurance Distribution Directive — Fairness and Transparency The **IDD (EU) 2016/97** requires that insurance distribution is conducted in the customer's best interest, with information presented in a comprehensible manner. Where AI is used in the distribution process — for example, in a digital platform that generates personalised product recommendations or premium quotes — the IDD's fairness and disclosure obligations align with the EU AI Act's **Art. 13** transparency requirements. Insurers should integrate AI Act disclosure obligations into IDD product disclosure documents (IPIDs) and Key Information Documents, ensuring that the AI's role in the distribution or pricing decision is communicated in language accessible to the policyholder. ### GDPR — Special Category Data and Automated Decision-Making **GDPR Art. 9** classifies health data, genetic data, and data concerning a person's physical or mental health condition as special category data, processing of which is prohibited absent a specific derogation. Life and health insurers using such data in AI training or scoring must identify and document a valid Art. 9(2) legal basis — most commonly **explicit consent** under Art. 9(2)(a) or a member state law derogation under Art. 9(2)(b) — for each data category and processing purpose. **GDPR Art. 22** restricts solely automated decisions that produce legal or similarly significant effects for natural persons. An AI underwriting decision that automatically rejects a coverage application, or an AI claims decision that automatically reduces a benefit payment, without human involvement constitutes solely automated decision-making under Art. 22. The data subject is entitled to: human review of the decision; an explanation of the principal factors influencing the automated decision; and the right to contest the outcome. Insurers must build these rights into their customer-facing processes and ensure the internal review mechanisms are substantively functional. ### EIOPA AI Guidelines **EIOPA's principles-based guidelines on AI use in insurance (2021)** established sector expectations around transparency, non-discrimination, data quality, and model explainability ahead of the AI Act's entry into force. EIOPA is developing sector-specific implementation guidance for the EU AI Act, and insurers should monitor EIOPA outputs closely. National supervisors — **ACPR** (France), **BaFin** (Germany), **IVASS** (Italy), **DNB** (Netherlands) — will implement supervisory expectations in alignment with EIOPA guidance, and sector-specific Q&A publications are expected during the Act's implementation period. --- ## Enforcement — EIOPA and National Supervisors ### EIOPA's Supervisory Role **EIOPA** (European Insurance and Occupational Pensions Authority) does not have direct enforcement authority under the EU AI Act, which designates national supervisory authorities as competent authorities under **Art. 70**. However, EIOPA coordinates supervisory convergence across EU insurance regulators and issues binding and non-binding technical standards. EIOPA's AI governance expectations — expressed through guidelines, opinions, and supervisory statements — will shape how national supervisors implement AI Act requirements in the insurance context. Insurers should treat EIOPA outputs as authoritative sector guidance even where they are not legally binding. ### National Insurance Supervisors as AI Competent Authorities National insurance supervisors in major EU markets are positioned to exercise AI Act competent authority functions over insurance AI systems: - **ACPR** (Autorité de contrôle prudentiel et de résolution) in France, which has published supervisory expectations on AI in financial services - **BaFin** (Bundesanstalt für Finanzdienstleistungsaufsicht) in Germany, with an established track record in algorithmic decision-making supervision - **IVASS** (Istituto per la Vigilanza sulle Assicurazioni) in Italy - **DNB** (De Nederlandsche Bank) in the Netherlands These authorities have powers under **Art. 74** and **Art. 75** to request access to training data, technical documentation, and logs; to conduct on-site inspections; to order corrective measures; and to recommend financial penalties for non-compliance. Fines for placing non-compliant high-risk AI on the market may reach **€30 million or 6% of global annual turnover**, whichever is higher. ### Dual Supervision: AI Act and Sector Regulation Insurance supervisors conducting AI Act enforcement will do so in the context of their broader prudential and conduct mandates. An AI Act investigation into a biased actuarial pricing model may simultaneously engage Solvency II Pillar III reporting obligations, IDD conduct requirements, and GDPR enforcement by the data protection authority. Insurers should assume that supervisory interventions will be cross-functional and design their compliance programmes accordingly. --- ## Compliance Roadmap for Insurers ### Step 1: AI System Inventory and Classification Conduct a comprehensive inventory of all AI systems used in: premium pricing; underwriting acceptance or rejection; claims assessment or payment; fraud detection; customer risk scoring; and distribution or product recommendation. For each system, assess whether it produces outputs that determine or significantly influence outcomes for individual natural persons. Systems meeting this threshold require classification assessment against **Annex III cat 5(b)**. ### Step 2: Provider/Deployer Determination For each high-risk AI system, determine whether the insurer is the provider, deployer, or — critically — whether use outside the vendor's validated scope has triggered re-classification as a provider. Engage legal counsel to assess borderline configurations, particularly where in-house data or policyholder populations have been used to fine-tune or extend a licensed model. ### Step 3: Gap Analysis against AI Act Obligations Map existing Solvency II governance artefacts, ORSA documentation, and internal model validation processes against the AI Act requirements under **Art. 9** (risk management), **Art. 10** (data governance), **Art. 11** and **Annex IV** (technical documentation), **Art. 12** (logging), **Art. 13** (transparency), **Art. 14** (human oversight), and **Art. 15** (accuracy, robustness, cybersecurity). Document identified gaps and assign remediation responsibility. ### Step 4: Data Governance and GDPR Alignment For each high-risk AI system, audit training and validation datasets. Document data provenance, collection methods, representativeness across relevant policyholder demographic groups, and known limitations. Ensure GDPR legal bases are in place for all personal data and, where applicable, for special category data. Integrate **Art. 10** documentation into the **Annex IV** technical file. ### Step 5: Human Oversight Mechanism Design Design operationally realistic human oversight mechanisms for each high-risk AI deployment. For underwriting AI, this means a qualified underwriter has the information, authority, and workflow time to review and depart from the AI's recommendation before it affects the policyholder. For claims AI, it means a claims handler has substantive review authority — not a nominal sign-off function. Document the oversight design and include it in the technical documentation. ### Step 6: Vendor Due Diligence and Contract Remediation For third-party actuarial AI systems, implement the pre-deployment due diligence process described above and review existing vendor contracts. Where contracts lack provisions requiring the vendor to maintain AI Act compliance documentation, notify the insurer of significant changes, and permit audit of AI system performance, remediate through contract amendment or renegotiation. Establish internal procedures for monitoring AI system performance in the live policyholder population and reporting significant deviations to vendors and, where required, to supervisory authorities. -------------------------------------------------------------------------------- ## Public Sector & Justice — EU AI Act Compliance URL: https://www.regulation-ai.eu/en/sectors/public-sector/ ## Public Sector and the AI Act — Why Government Is the Highest-Risk Deployer The EU AI Act (Regulation (EU) 2024/1689) applies horizontally across sectors, but its most concentrated burden of mandatory obligations falls on public bodies. Government agencies, law enforcement authorities, judicial institutions, and border management bodies are both the heaviest deployers of consequential AI and the entities whose use of AI creates the greatest structural risk to fundamental rights. The Act reflects this asymmetry in two structural ways. First, four of the eight Annex III high-risk categories address public-sector AI directly — **categories 5 through 8** cover essential public services, law enforcement, migration and border control, and the administration of justice. These categories are not residual catch-alls: they enumerate specific AI applications commonly used in government operations that carry classification-level risk by definition. Second, **Art. 27** imposes a **mandatory fundamental rights impact assessment (FRIA)** on public bodies before deploying high-risk AI systems. For private-sector deployers, the FRIA is strongly recommended; for public bodies, it is a legal obligation. The assessment must examine the impact of the AI system on individuals' rights under the **EU Charter of Fundamental Rights**, including the right to dignity (**Art. 1**), protection of personal data (**Art. 8**), the right to an effective remedy (**Art. 47**), and the presumption of innocence (**Art. 48**). The compliance landscape for public bodies is further complicated by the layering of AI Act obligations on top of existing sector-specific regimes: the **Law Enforcement Directive 2016/680**, the **Schengen Information System Regulation**, the **Frontex Regulation 2019/1896**, the **General Data Protection Regulation**, and the constitutional requirements of the **European Convention on Human Rights** as interpreted by the European Court of Human Rights. Each of these frameworks creates independent obligations that must be satisfied in parallel with EU AI Act requirements. --- ## High-Risk AI Systems — Categories 5 Through 8 ### Annex III, Category 5 — Essential Public Services and Benefits Assessment **Annex III, point 5(b)** classifies as high-risk any AI system used to evaluate the eligibility of natural persons for essential public benefit services and make decisions in that context. This category encompasses the full spectrum of welfare-state AI: - **Automated unemployment benefit assessment**: AI systems that determine whether a claimant meets eligibility criteria based on employment records, job-search activity, or means assessments. - **Housing and disability allowance decisions**: Algorithmic tools that score applications for social housing priority, disability benefit entitlement, or personal independence payments. - **Social assistance fraud detection**: AI profiling systems that generate risk scores for suspected benefit fraud, potentially triggering investigations or payment suspension. Point 5(b) also covers **creditworthiness and insurance AI** in relation to natural persons, though the primary public-sector exposure is in benefit and service eligibility. In all cases, the classification attaches when the AI system has a material influence on access to a public service — whether or not the final decision is taken by a human official. ### Annex III, Category 6 — Law Enforcement Category 6 covers AI used by law enforcement authorities across three domains: **Risk assessment and profiling**: AI systems that evaluate the likelihood of an individual committing a criminal offence, reoffending, or posing a security threat — including **recidivism scoring tools** used in pre-trial detention hearings, parole decisions, and sentencing recommendations. These systems are high-risk under **Annex III, point 6(a)**. **Detection and analysis during investigations**: AI for detecting emotional states, personality traits, or deceptive behaviour from facial expressions, voice, or physiological indicators used in criminal investigations. **Art. 5(1)(f)** separately prohibits AI systems that infer emotions of individuals in law enforcement and border management contexts except for specific safety purposes, drawing a firm outer boundary around this use case. **Deep fake and document detection**: AI used to detect manipulated digital content or assess the authenticity of documents in criminal proceedings — classified as high-risk under **Annex III, point 6(c)**. ### Annex III, Category 7 — Migration, Asylum, and Border Control Category 7 applies to AI deployed in the context of migration and border management: **Risk assessment at borders**: AI systems that assess irregular migration risk or generate threat scores for individuals crossing borders — including **SIS-integrated profiling tools** and **Frontex risk analysis systems** operating under Regulation 2019/1896. **Document and identity verification**: AI systems assessing the authenticity of travel documents, visas, residence permits, or identity documents for border crossing or immigration purposes. **Asylum application processing**: AI that examines asylum applications, assesses the credibility of individual claims, or profiles applicants for expedited or accelerated procedures. All category 7 systems must be assessed for compliance not only with the AI Act but with the **Refugee Convention (1951)**, the **EU Charter Art. 18** (right to asylum), and the **non-refoulement** principle as interpreted in ECHR case law — a constitutional constraint that the FRIA under **Art. 27** must address explicitly. ### Annex III, Category 8 — Administration of Justice and Democratic Processes Category 8 addresses AI deployed within the justice system itself: **Judicial support AI**: Systems that assist in researching case law, identifying applicable legal provisions, or structuring legal reasoning for judges, prosecutors, or court administrators — high-risk under **Annex III, point 8(a)**. **Predictive justice tools**: AI systems that predict the likely outcome of litigation, sentencing ranges, or judicial decisions based on historical case data. These systems raise acute concerns under **Art. 47** of the EU Charter regarding the right to a fair trial, since their use in judicial decision-making may structurally disadvantage parties whose profiles differ from historical norms. Category 8 does not prohibit AI-assisted judicial work; it subjects it to the high-risk compliance regime and requires courts and justice ministries to ensure that AI outputs are always subject to **substantive human review** — the judge or decision-maker must be able to, and in practice must, disregard the AI's output where it is not appropriate. --- ## Mandatory Obligations for Public Body Deployers Public bodies operating as **deployers** of high-risk AI systems under the AI Act carry a defined, non-delegable set of obligations under **Art. 26** and **Art. 27**. ### Fundamental Rights Impact Assessment (Art. 27) The FRIA is the most distinctive obligation for public deployers. It must be conducted **before** deployment and must address: the specific rights-affecting purposes of the system; the categories of individuals whose rights may be affected; the foreseeable risks of harm and the probability and severity of those risks; how existing legal safeguards mitigate those risks; and the measures taken to monitor the system post-deployment. The completed FRIA must be provided to the **national AI supervisory authority** upon request and must be updated when the system is modified or deployed in a new context. ### Human Oversight and Designated Responsibility Art. 26(1) requires deployers to assign human oversight of high-risk AI systems to **natural persons with the necessary competence, authority, and resources** to intervene. In public administration, this means that each automated process affecting individuals — whether benefit eligibility, border risk scoring, or judicial support output — must have an identified official who can override the system's output and who is not structurally incentivised to defer to it. ### Transparency to Affected Individuals **Art. 13** requires deployers to ensure that individuals subject to AI-assisted decisions are **clearly informed** that an AI system is being used. In public administration, this obligation typically requires inserting AI-use disclosures into decision letters, administrative communications, and hearing procedures. **Art. 86** protects the confidentiality of data submitted to supervisory authorities in the context of compliance monitoring, providing a route for sensitive internal documentation to be disclosed without public exposure. ### Logging, Record-Keeping, and Incident Reporting Deployers must maintain **operational logs** of AI system activity for a minimum period — at least six months for most high-risk systems, with extended retention where the legal framework governing the underlying administrative process requires it. Serious incidents — incidents resulting in death, serious injury, significant property damage, or fundamental rights violations — must be reported to the competent national AI supervisory authority without undue delay. --- ## Prohibited Practices in Public Administration Certain AI practices are **absolutely prohibited** under **Art. 5** of the EU AI Act. For public authorities, three prohibitions are of direct operational relevance. **Art. 5(1)(c) — Social scoring by public authorities**: AI systems that evaluate or classify individuals based on their social behaviour or personality characteristics to generate a score used to determine access to public services, benefits, or legal treatment are prohibited. This prohibition is specifically directed at public authorities and targets so-called social credit mechanisms regardless of how they are labelled or structured. **Art. 5(1)(d) — Real-time remote biometric identification in public spaces**: The use of real-time AI-powered remote biometric identification systems (facial recognition, gait analysis, or other biometric tools) in publicly accessible spaces by law enforcement authorities is prohibited, subject to three narrow exceptions: targeted searches for missing children; prevention of specific, imminent terrorist threats; and identification of suspects in serious crimes where prior judicial or independent administrative authorisation has been obtained. These exceptions are exhaustive; no general surveillance programme qualifies. **Art. 5(1)(e) — Subliminal and manipulative techniques**: AI systems that deploy techniques operating below the threshold of conscious awareness to manipulate individual behaviour, or that exploit vulnerabilities of specific groups, are prohibited for all deployers including public authorities. --- ## Enforcement — Supervisory Authorities and Oversight Mechanisms The AI Act's enforcement architecture in the public sector involves multiple layers of competent authority. **National AI supervisory authorities** designated under **Art. 70** are the primary enforcement bodies for the Act in each member state. In most jurisdictions, these are or will be integrated with or closely aligned to existing data protection authorities. They have powers to conduct audits, request technical documentation and FRIA results, issue corrective orders, and impose administrative fines. Fines for public bodies are subject to member state discretion under **Art. 99(6)**: member states may provide that public authorities are not subject to monetary penalties, but must ensure that alternative supervisory and corrective mechanisms — including mandatory audits, publication of non-compliance findings, and suspension of AI system use — are available. This discretion does not extend to permitting non-compliance; it concerns only the financial penalty mechanism. **Data protection authorities (DPAs) and the EDPB** retain parallel competence over the personal data processing dimensions of public-sector AI under GDPR and the LED. Non-compliance with GDPR or LED obligations in the context of AI system operation is subject to DPA enforcement independently of the AI Act supervisory authority. **The European Court of Human Rights** constitutes an external constitutional constraint: decisions taken on the basis of algorithmic processes — particularly in criminal justice and immigration — must satisfy the Convention standards for **Art. 6** (fair trial) and **Art. 8** (private life) as interpreted in the ECHR's evolving case law on automated decision-making. --- ## Implementation Roadmap for Government Agencies ### Phase 1 — AI System Inventory and Classification (Months 1-3) Public bodies must first establish a **comprehensive inventory** of all AI systems currently in use or under procurement. Each system must be assessed against Annex III categories 5-8 and the prohibition provisions of **Art. 5**. Systems involving personal data processing should be assessed simultaneously against GDPR and LED requirements. The output of this phase is a classified inventory — prohibited, high-risk, limited-risk, or minimal-risk — that drives the compliance programme. ### Phase 2 — Fundamental Rights Impact Assessments (Months 3-6) For each identified high-risk system, public bodies must commission and complete a **FRIA under Art. 27**. This requires legal, technical, and policy input: legal analysis of the rights at stake; technical documentation of the system's operation, training data, and known failure modes; and a policy assessment of the mitigating measures available. FRIAs must be documented and ready for submission to supervisory authorities. ### Phase 3 — Provider Verification and Procurement Reform (Months 3-9) Public procurement processes must be updated to require AI providers to demonstrate compliance with the EU AI Act as a condition of contract award. Deployers must verify CE marking, Declaration of Conformity, technical documentation, and post-market monitoring commitments before deployment. Public bodies acting as joint operators or co-developers with technology vendors must clarify responsibility allocation for conformity assessment obligations contractually. ### Phase 4 — Operational Safeguards and Staff Training (Months 6-12) Designated human oversight officials must be identified for each high-risk AI system, trained in the system's capabilities and limitations, and equipped with override procedures. Transparency notices for affected individuals must be drafted and embedded in existing administrative procedures. Logging infrastructure must be verified or established. Incident reporting protocols must be integrated with existing administrative and data protection incident management processes. ### Phase 5 — Continuous Monitoring and Annual Review High-risk AI system compliance is not a one-time certification exercise. Post-market monitoring obligations require public bodies to actively track system performance, document any changes in accuracy, bias, or behaviour, and update FRIAs when material changes occur. Annual supervisory authority reporting, where required under national law, must be supported by the documentation generated through the monitoring programme. -------------------------------------------------------------------------------- ## Retail, E-commerce & Call Centres — EU AI Act Compliance URL: https://www.regulation-ai.eu/en/sectors/retail/ ## Retail, E-commerce, and Call Centres Under the EU AI Act The retail and e-commerce sector is a high-intensity deployer of artificial intelligence. From the moment a customer lands on a website, AI shapes which products are displayed, what price is offered, which promotions are surfaced, and how customer service queries are handled. In call centres, AI coaches agents in real time, scores conversations, and infers customer emotion from voice signals. The EU AI Act, in force since **1 August 2024** with key transparency obligations applying from **2 February 2025** and high-risk obligations from **2 August 2026**, imposes a structured compliance framework across this landscape. Crucially, the AI Act does **not** treat all retail AI as equivalent. The Regulation draws a precise distinction between systems subject only to transparency obligations — the majority of consumer-facing retail AI — and systems classified as high-risk, which carry the full obligation set: conformity assessment, technical documentation, quality management systems, and human oversight requirements. Understanding which category applies to each deployed system is the foundational compliance task for retailers and call centre operators. The sector is simultaneously governed by **GDPR**, the **Consumer Rights Directive** (2011/83/EU), the **Unfair Commercial Practices Directive** (2005/29/EC), the **P2B Regulation** (EU 2019/1150), and, for call centres, national labour law regimes on employee monitoring. The AI Act adds a layer but does not replace these existing frameworks. --- ## Art. 50 Transparency Obligations — The Primary Compliance Layer For the majority of retail and e-commerce AI deployments, **Art. 50** of the EU AI Act is the operative provision. Its obligations apply from **2 February 2025** and are not contingent on high-risk classification. Non-compliance may be sanctioned independently of the high-risk timeline. ### Chatbot and Conversational AI Disclosure — Art. 50(1) **Art. 50(1)** imposes a mandatory disclosure obligation on any deployer of a conversational AI system — a system designed to interact with humans through natural language — to inform users that they are interacting with an AI, unless this is obvious from the circumstances. In the retail context, this obligation applies to: - **Website chatbots and live chat bots** — including chat widgets powered by large language models, rule-based chatbots with AI-enhanced understanding, and hybrid systems. - **Voicebots and IVR AI** — automated telephone systems that handle inbound customer queries through voice-based AI, including AI-enhanced interactive voice response systems. - **In-app virtual assistants** — AI-powered help functions embedded within retail apps, loyalty programme apps, or banking-adjacent apps offered by retailers. - **Social media customer service bots** — AI agents responding to messages on WhatsApp, Instagram, or Messenger on behalf of a retailer. The exemption for "obvious from circumstances" is narrow. A chatbot named "Emma" or described as a "virtual assistant" does not meet the threshold. A header displaying "You are now speaking with an automated AI system — no human agent is involved" would suffice. Retailers must not rely on consumer inference — the disclosure must be explicit, given at or before first interaction, and presented in a manner comprehensible to the ordinary consumer. The obligation falls on the **deployer** — the retailer or call centre operator — not solely on the technology provider. Contractual provisions transferring disclosure responsibility to the vendor do not discharge the deployer's regulatory obligation. ### Emotion Recognition Disclosure — Art. 50(2) **Art. 50(2)** requires that any person exposed to an emotion recognition system be informed of its operation. An **emotion recognition system** is an AI system that infers emotional states from physiological or behavioural signals — facial expressions, voice tone, speech rhythm, word choice, or micro-expressions. In the retail and call centre sector, this obligation applies to: - **Customer sentiment analysis in calls** — AI that analyses the acoustic or linguistic features of a customer's voice to infer frustration, satisfaction, or emotional state during a call centre interaction. The customer must be informed that this analysis is occurring. - **In-store customer analytics** — AI-enabled camera systems that attempt to infer shopper emotion or attention from facial expressions. Where the system meets the definition of emotion recognition, in-store disclosure is required. - **Agent voice analysis** — sentiment or emotion analysis applied to the call centre agent's own voice (addressed further below in the employee monitoring section). Disclosure must be given before the emotion recognition system begins processing. For telephone channels, this typically requires an IVR announcement or verbal notification at the start of the call. Silence — including audio prompts that only reference call recording without mentioning AI emotion analysis — does not satisfy the Art. 50(2) obligation. ### AI-Generated Synthetic Media — Art. 50(4) **Art. 50(4)** requires that AI-generated or AI-manipulated media — images, video, and audio — be labelled as artificially generated or manipulated when there is a risk that users will believe it to be authentic. Retail-specific applications in scope include: - **AI-generated product imagery**: images of products, rooms, or lifestyle scenes produced by generative AI and presented as authentic photography in product listings or advertising. - **AI-generated promotional video**: brand videos, testimonial-style content, or marketing materials where the visual or audio content is substantially AI-generated. - **AI-generated or AI-cloned voice narration** used in product demos, branded content, or customer communications. - **Virtual try-on AI** that generates synthetic images of a customer wearing or using a product — where the output is presented as an accurate depiction. The labelling obligation does not require that the AI origin be concealed to trigger compliance — the standard is whether a consumer could reasonably mistake the content for authentic photography or video. Failure to label also creates exposure under the **Unfair Commercial Practices Directive (2005/29/EC)**, which prohibits the use of editorial content to promote products without clearly indicating that it is paid-for or artificially produced content. --- ## Employee Monitoring AI in Call Centres — High-Risk Classification Call centres routinely deploy AI to monitor, score, evaluate, and coach agents in real time. Where these systems cross into **Annex III, category 4** territory, full high-risk obligations apply. ### Agent Coaching and Real-Time Guidance AI **Real-time agent coaching AI** — systems that monitor live calls and provide agents with in-call guidance, scripts, compliance prompts, or emotional state feedback — sits at the intersection of cat 4(b) and cat 4(c). Where the system monitors the agent's compliance with contractual obligations (call handling standards, regulatory scripts), cat 4(b) applies. Where it infers the agent's emotional or behavioural state and generates alerts or performance flags from that inference, cat 4(c) applies. Both sub-categories trigger the full high-risk obligation set: - **Risk management system** per **Art. 9**: continuous identification, evaluation, and mitigation of risks to agents and to customers interacting with the system. - **Data governance** per **Art. 10**: training datasets must be relevant, representative, and managed to minimise discriminatory bias. - **Technical documentation** per **Art. 11 and Annex IV**: comprehensive documentation of system design, intended purpose, limitations, performance metrics, and test results. - **Transparency to deployers** per **Art. 13**: providers must supply instructions for use that include information on system limitations, operating conditions, and foreseeable risks. - **Human oversight** per **Art. 14**: deployers must designate individuals with the authority, competence, and time to intervene in or override system outputs. - **Accuracy and robustness** per **Art. 15**: systems must perform reliably within stated parameters. ### Quality Scoring and Performance Assessment AI AI systems that assign quality scores to calls, generate agent performance rankings, or produce outputs used in appraisal, bonus determination, or dismissal processes fall within **Annex III cat 4(b)** as systems used for decisions on promotion, task allocation, or monitoring of contractual obligations. High-risk obligations apply in full. Operators must additionally satisfy the **Art. 50(2)** disclosure requirement for agents subject to emotion recognition components within these systems — regardless of the high-risk compliance timeline. ### National Labour Law Obligations Employee monitoring AI in call centres triggers national co-determination and consultation rights independently of the AI Act. In Germany, **Betriebsverfassungsgesetz §87(1) no. 6** grants works councils binding co-determination rights over technical monitoring devices; AI monitoring systems require works council agreement before deployment. Equivalent rights apply in the Netherlands (**WOR Art. 27**), Austria (**ArbVG §96**), and France (**Code du Travail L. 2312-38**). These obligations cannot be deferred until the 2026 AI Act high-risk deadline. --- ## Customer-Facing AI That Is Not High-Risk A significant portion of retail AI is **not** classified as high-risk under Annex III. The following categories are explicitly not enumerated in Annex III and do not require conformity assessment under the AI Act: - **Product recommendation engines** — AI that personalises product suggestions based on browsing history, purchase patterns, or collaborative filtering. - **Dynamic pricing systems** — AI that adjusts pricing in real time based on demand, inventory, competitor pricing, or consumer segments. - **Inventory demand forecasting** — AI that predicts stock requirements at SKU or category level. - **Customer churn prediction models** — AI that scores the likelihood of customer attrition for retention campaign targeting. - **Search personalisation** — AI that re-ranks search results on retail websites based on individual or cohort signals. - **Returns fraud detection** — AI that scores return requests for potential fraud, where the output feeds into a human-reviewed decision process. These systems are nonetheless subject to **GDPR** where they involve individual customer profiling. Behavioural analytics, purchase history aggregation, and cross-site tracking require a lawful basis under **Art. 6 GDPR** — typically legitimate interest (requiring a documented balancing test) or consent. Where profiling produces decisions with significant effects on individual consumers — for example, customer account suspension based on fraud scoring — **GDPR Art. 22** may apply, requiring human review of automated decisions. The **P2B Regulation** (EU 2019/1150) imposes transparency requirements on ranking algorithms used on online marketplaces and comparison tools — operators must disclose the main parameters determining ranking and the relative importance of those parameters. AI-driven ranking is not exempt. --- ## Consumer Protection and the Unfair Commercial Practices Directive AI-driven commercial practices in retail create additional exposure under the **Unfair Commercial Practices Directive (2005/29/EC)**, particularly following the **Omnibus Directive** amendments effective in member states from 2022 onwards: - **AI-generated fake reviews**: the UCPD, as amended, explicitly prohibits the submission of fake consumer reviews and the use of review curation services that do not disclose AI involvement. AI-generated product reviews submitted as authentic consumer reviews are unlawful. - **Personalised pricing without disclosure**: where a retailer uses AI to present individually tailored prices to specific consumers based on profiling, the amended UCPD requires disclosure of the fact of personalisation where a consumer encounters a personalised price. - **Manipulative personalisation**: **Art. 5 of the EU AI Act** prohibits AI systems that use subliminal techniques or exploit vulnerabilities to distort consumer behaviour. Aggressive personalisation that targets consumers at moments of cognitive vulnerability or exploits emotional states inferred from prior interaction data may constitute a prohibited practice. - **Misleading AI-generated descriptions**: product descriptions, specifications, or comparative claims generated by AI that are inaccurate or fabricated — including hallucinated specifications in LLM-generated product content — may constitute misleading commercial practices under the UCPD. --- ## Enforcement Authorities and Penalties Enforcement of AI Act obligations in the retail sector is distributed across multiple competent authorities: - **National AI supervisory authorities**: designated under each member state's AI Act implementation legislation. These are the primary authorities for Art. 50 transparency violations and for high-risk compliance breaches. - **Consumer protection authorities**: national consumer agencies and the **BEUC** network will be particularly active in monitoring chatbot disclosure, AI-generated content labelling, and UCPD-adjacent AI practices. The Consumer Protection Cooperation (CPC) Network enables coordinated enforcement across member states. - **Data Protection Authorities**: retain concurrent enforcement jurisdiction under GDPR for customer profiling, automated decision-making, and biometric data processing incidents. - **Labour inspectorates**: in member states with strong labour inspection regimes — France (DREETS), Germany (Gewerbeaufsicht), and Spain (Inspección de Trabajo) — AI-based employee monitoring that breaches labour law or co-determination obligations is subject to investigation independent of AI Act proceedings. **Penalty exposure** under the AI Act: violations of Art. 50 transparency obligations carry fines of up to **€15 million or 3% of global annual turnover**, whichever is higher. Violations of prohibited practices (Art. 5) carry fines of up to **€35 million or 7% of global annual turnover**. GDPR fines apply cumulatively. For large e-commerce operators with global revenues, the 7% ceiling represents substantial financial exposure. --- ## Compliance Roadmap for Retailers and Call Centre Operators A structured AI Act compliance programme for the retail sector should address the following in sequence: **1. AI system inventory**: catalogue all AI tools in use across customer-facing channels (website, app, telephone, social), marketing and merchandising functions (pricing, recommendations, content generation), and call centre operations (coaching, scoring, monitoring). For each system, determine whether it is a general-purpose tool, a transparency-obligation system, or potentially high-risk. **2. Chatbot and voicebot disclosure audit**: review all conversational AI deployments for compliance with **Art. 50(1)**. Verify that disclosure is explicit, given at first interaction, and does not rely on consumer inference. Update chat interface copy, IVR scripts, and help centre language accordingly. **3. Emotion recognition mapping**: identify all systems — customer-facing and agent-facing — that infer emotional or affective states. Implement **Art. 50(2)** notifications for all in-scope systems. For agent-facing systems, assess Annex III cat 4 classification and initiate high-risk compliance planning. **4. Synthetic media audit**: audit all marketing assets, product imagery, and branded content for AI-generated components. Implement an Art. 50(4) labelling workflow — ensuring that generated or manipulated content is identified before publication. **5. Call centre AI due diligence**: for each AI vendor supplying coaching, scoring, or monitoring tools, request confirmation of Annex III classification, CE marking status (from 2 December 2027), and instructions for use. Initiate works council consultation or co-determination procedures under applicable national law. **6. GDPR profiling review**: conduct a GDPR lawful basis audit for customer profiling activities. Where legitimate interest is relied upon, document and maintain balancing test records. Update privacy notices to reflect AI-driven profiling practices. **7. UCPD compliance check**: review personalised pricing disclosure, review generation practices, and AI-generated content workflows against UCPD requirements, including Omnibus Directive amendments as enacted in relevant member states. **8. Incident response and governance**: establish AI governance ownership — typically across legal, DPO, compliance, and digital/technology functions — with documented escalation procedures for incidents involving Art. 50 breaches or employee complaints relating to monitoring AI. Retailers and call centre operators that embedded AI early in their customer and operational workflows face the broadest compliance surface. The transparency obligations of Art. 50 are already applicable; the high-risk obligations for employee monitoring AI require programme-level preparation before **2 August 2026**. -------------------------------------------------------------------------------- ## SMEs — EU AI Act Compliance Guide URL: https://www.regulation-ai.eu/en/sectors/sme/ ## EU AI Act and SMEs — The Good News The EU AI Act (Regulation (EU) 2024/1689) applies to all organisations placing or using AI systems within the EU market, regardless of size. However, the regulatory reality for most small and medium-sized enterprises is considerably less burdensome than headlines suggest, for one fundamental reason: **the vast majority of SMEs use AI rather than build it**. An SME that subscribes to an AI-enhanced CRM, deploys a chatbot from a SaaS vendor, or uses cloud-based demand forecasting software is, in EU AI Act terminology, a **deployer** — not a provider. Deployer obligations are systematically lighter than provider obligations. Providers bear the principal burden of conformity assessment, technical documentation, CE marking, and registration. Deployers have a more targeted obligation set focused on correct use, human oversight, and incident reporting. Beyond the deployer/provider distinction, the EU AI Act contains a discrete package of **SME-specific provisions** that provide structural support: priority access to regulatory sandboxes, reduced conformity assessment fees, and a dedicated single point of contact at national level. These provisions reflect the legislature's explicit intention to prevent the AI Act from becoming a disproportionate barrier to smaller market participants. This guide sets out what the EU AI Act means in practice for an SME — whether you use third-party AI tools, deploy AI in customer-facing contexts, or are yourself building and commercialising an AI product. --- ## SME-Specific Provisions in the Regulation The EU AI Act includes four provisions that apply specifically to SMEs (enterprises meeting the **Commission Recommendation 2003/361/EC** threshold: fewer than 250 employees and either annual turnover not exceeding €50 million or a balance sheet total not exceeding €43 million) and to startups. ### Art. 55 — Priority Access to Regulatory Sandboxes **Art. 55** establishes that regulatory AI sandboxes — supervised environments for developing and testing AI before market placement — shall be accessible by priority to SMEs and startups. Access is free of charge or subject to reduced fees, and participating organisations receive direct guidance from the competent authority. Sandbox access enables pre-market risk identification and regulatory dialogue in a protected setting, without the consequences of a non-compliant market placement. SMEs building AI systems should regard sandbox participation as both a compliance tool and a mechanism for engaging directly with the supervisory authority before product launch. ### Art. 96 — Reduced Fees for Conformity Assessment Where a high-risk AI system requires third-party conformity assessment by a **notified body** (applicable to systems listed in **Annex III points 1, 6, and 7**, and medical device AI under **Art. 6(1)**), **Art. 96** requires member states to establish reduced fees for small enterprises. Micro-enterprises — those with fewer than 10 employees and annual turnover or balance sheet not exceeding €2 million — are entitled to even greater reductions. The exact fee schedules are set at member state level and vary by jurisdiction; the relevant national AI authority or the Enterprise Europe Network can provide current figures. ### Art. 85 — Single Point of Contact **Art. 85** obligates national AI supervisory authorities to establish a **dedicated single point of contact for SMEs**. This means an SME seeking guidance on AI Act obligations does not need to navigate multiple regulatory departments or coordinate across fragmented authorities. The single point of contact provides information, routes queries to the appropriate function, and facilitates sandbox applications. This provision significantly reduces the administrative cost of understanding regulatory obligations. ### Art. 9(5) — Proportionate Risk Management **Art. 9(5)** provides that the risk management system required of providers of high-risk AI systems may be implemented proportionately, taking into account the organisation's size and structure. For an SME acting as provider of a high-risk system, this means that while all substantive requirements of the risk management system must be met, the documentation format, process complexity, and governance structure may be scaled to the organisation's actual capacity — provided this does not undermine the protection objectives of the framework. --- ## Are You a Provider or Deployer? — Decision Framework for SMEs The single most important preliminary determination for any SME engaging with the EU AI Act is whether it acts as a **provider** or a **deployer** with respect to each AI system it uses or offers. **Provider** (**Art. 3(3)**): An organisation that develops an AI system, or has an AI system developed, and places it on the market or puts it into service under its own name or brand — whether for payment or free of charge. This includes SMEs that: - Build a software product incorporating AI (including AI models accessed via API) and sell or licence that product to customers; - Develop an AI model or application internally and deploy it as a service to end users outside the organisation; - Substantially modify a third-party AI system in a way that changes its intended purpose. **Deployer** (**Art. 3(4)**): An organisation that uses an AI system under its own authority for a professional purpose. This covers SMEs that: - Subscribe to SaaS products with embedded AI features (AI-enhanced CRM, ERP, accounting software); - Use a third-party chatbot or conversational AI on their website; - Access cloud AI APIs (natural language processing, image classification, recommendation engines) solely to automate internal workflows or enhance their own services without offering the AI capability as a product feature to third parties; - Procure HR software, inventory forecasting, or customer analytics tools from external vendors. **The critical boundary case**: An SME that integrates an external AI API into its own customer-facing product and markets that capability as a feature of its product is a **provider** with respect to that AI functionality — not merely a deployer of the underlying API. The legal entity that defines the intended purpose, controls the user experience, and places the product on the market bears provider obligations under **Art. 16**, regardless of where the AI model originates. --- ## Key Deployer Obligations for SMEs Using Third-Party AI For the majority of SMEs — those deploying third-party AI tools rather than building their own — the following obligations apply under **Art. 26** and related provisions. ### Use AI Systems per Provider Instructions Deployers must use high-risk AI systems **only in accordance with the provider's instructions for use** as supplied under **Art. 13**. Using an AI system for purposes beyond its documented intended purpose, or in configurations the provider has not validated, transfers a portion of compliance liability to the deployer and may vitiate the system's conformity assessment. ### Designate Responsible Human Oversight Art. 26(1) requires deployers to assign responsibility for AI oversight to a qualified person within the organisation. For most SMEs, this will be a named individual (not necessarily a dedicated AI compliance officer) who understands the system's function, its known limitations, and the circumstances in which human intervention is required. This designation should be documented. ### Retain Operational Logs Where high-risk AI systems generate logs automatically (**Art. 12**), deployers must retain those logs for the legally required period — generally **six months** under the AI Act, unless sector-specific law requires a longer retention. Deployers must verify that their vendor contract grants access to logs and confirms their format and completeness. ### Report Serious Incidents to the Provider **Art. 26(5)** requires deployers to notify the **provider** of any serious incidents or malfunctions discovered during use. Where the deploying organisation is a public body, notification obligations extend to the national AI supervisory authority. For SME deployers in the private sector, the primary channel is direct notification to the provider, which then carries its own obligations to notify the authority under **Art. 73**. ### Conduct a Fundamental Rights Impact Assessment Where Applicable **Art. 27** requires public bodies deploying high-risk AI to complete a fundamental rights impact assessment before deployment. Private-sector SMEs deploying high-risk AI — particularly in HR, credit assessment, or customer-facing decision contexts — are **strongly recommended** to complete an equivalent assessment, as it demonstrates due diligence and materially reduces enforcement risk. ### Review Vendor Contracts SME deployers must ensure that their contracts with AI vendors include: conformity documentation and instructions for use; confirmation of EU database registration where required; specification of the logging capability and access rights; vendor commitment to incident notification and remediation; and information on update or modification obligations that may affect the system's conformity status. --- ## If You Are Building AI — SME Provider Obligations and Support SMEs that develop and commercialise AI systems are **providers** and bear full provider obligations under **Chapter III** for any system that is high-risk. The scope of those obligations is substantial: quality management system (**Art. 17**), technical documentation per **Annex IV**, data governance per **Art. 10**, logging per **Art. 12**, transparency requirements per **Art. 13**, human oversight design per **Art. 14**, and accuracy and robustness standards per **Art. 15**. For Annex III systems requiring notified body assessment, the conformity route follows **Art. 43**. The practical entry point for an SME provider is the **risk classification determination**: - Is the AI system covered by **Art. 5** (prohibited practices)? If so, development must cease or be fundamentally restructured before any market activity. - Does the system qualify as **high-risk** under **Art. 6(1)** (safety component of a regulated product) or **Annex III** (listed application areas including biometric identification, critical infrastructure, education, employment, essential services, law enforcement, migration, justice)? - Does the system qualify only as a **general-purpose AI model** governed by **Art. 51–56**, without high-risk classification? - Is the system subject only to the **transparency obligations** of **Art. 50** (emotion recognition, deepfake, chatbots)? For SMEs whose systems fall outside the high-risk and prohibited categories, compliance is considerably lighter: Art. 50 transparency disclosures, GDPR alignment, and sector-specific obligations under applicable national or EU law. For SMEs developing high-risk AI, the **Art. 55 regulatory sandbox** is the most important available tool. Sandbox participation enables pre-market testing under regulatory supervision, provides documented evidence of good-faith compliance effort, and can identify corrective actions before they become enforcement matters. Applications are submitted to the national single point of contact (**Art. 85**). --- ## Practical Steps for SME Compliance **Step 1 — Inventory all AI systems in use or under development.** List every AI tool, SaaS product, cloud API, and internally developed model. Note the vendor, the function, and whether the SME acts as provider or deployer for each. **Step 2 — Classify each system by risk category.** Apply the Art. 5 / Art. 6 / Annex III / Art. 50 framework to each system. Where classification is uncertain, use the Art. 85 single point of contact for guidance. **Step 3 — For deployer roles: audit vendor contracts.** Verify that each AI vendor has supplied the documentation required under Art. 13 and that the contract addresses logging, incident notification, and update obligations. Flag gaps for renegotiation. **Step 4 — For provider roles: initiate the conformity pathway.** Determine whether your high-risk AI system requires self-assessment (**Art. 43(2)**) or third-party notified body assessment (**Art. 43(1)**). Apply for sandbox access under **Art. 55** if the system is in development. Engage the notified body early to understand timeline and fee implications, noting your entitlement to SME fee reductions under **Art. 96**. **Step 5 — Implement Art. 26 deployer obligations across all high-risk systems.** Designate oversight persons, document their responsibilities, verify log retention procedures, and confirm incident notification channels. **Step 6 — Establish an AI Act review cycle.** The EU AI Act is a living framework. Designate a responsible person to monitor guidance from the EU AI Office, national authority updates, and changes to Annex III classifications. Schedule an annual internal review of the system inventory and compliance status. -------------------------------------------------------------------------------- ## Transport & Critical Infrastructure — EU AI Act Compliance URL: https://www.regulation-ai.eu/en/sectors/transport/ ## Why Transport Is an EU AI Act Priority Sector The EU AI Act (Regulation (EU) 2024/1689) assigns its most demanding obligations to domains where AI failures carry direct consequences for physical safety, critical service continuity, and public security. Transport and critical infrastructure occupy a central position in this architecture for two independent legal reasons: the pervasive deployment of AI as **safety components** in regulated transport products (triggering **Art. 6(1)** via Annex I), and the explicit listing of critical infrastructure management AI as high-risk under **Annex III, point 2**. The transport sector is also distinguished by the density and maturity of its existing regulatory frameworks. Vehicle type-approval under **General Safety Regulation (EU) 2019/2144**, aviation certification under **EASA Basic Regulation (EU) 2018/1139**, railway interoperability and safety under **ERA Regulation (EU) 2016/796** and **Safety Directive 2016/798**, and critical infrastructure cybersecurity under **NIS2 Directive (EU) 2022/2555** all create pre-existing legal obligations that stack with — and in some cases structurally interact with — the EU AI Act. For transport organisations, the practical consequence is that AI compliance cannot be managed as an isolated regulatory workstream. It must be integrated into existing type-approval, certification, safety management, and cybersecurity programmes. Failure to achieve this integration risks not only AI Act non-compliance but also non-conformity with sector regulations that have their own enforcement authorities and market-access consequences. --- ## Safety Component AI (Annex I) vs. Critical Infrastructure AI (Annex III, Point 2) The EU AI Act creates two distinct high-risk pathways relevant to transport. Understanding which pathway applies — and whether both apply simultaneously — is the first analytical step in any transport AI compliance programme. ### Annex I — Safety Components of NLF-Regulated Products **Art. 6(1)** of the EU AI Act classifies as high-risk any AI system that is a **safety component** of a product regulated under New Legislative Framework (NLF) legislation listed in **Annex I**. For transport, the key NLF instruments are: - **General Safety Regulation (EU) 2019/2144** — road vehicles (cars, trucks, motorcycles, buses) - **EASA Basic Regulation (EU) 2018/1139** — aircraft, engines, and associated equipment - **ERA Railway Legislation** — including Regulation (EU) 2016/796 (ERA Agency), Directive 2016/797 (interoperability), and Directive 2016/798 (rail safety) - **Machinery Regulation (EU) 2023/1230** — relevant for AI in automated port equipment, industrial vehicles, and construction machinery operating in transport infrastructure contexts An AI system is a safety component of a transport product if its failure or malfunction could endanger the health or safety of persons. For road vehicles, this encompasses autonomous emergency braking systems, lane-keeping AI, adaptive cruise control at SAE L2 and above, and all L3–L5 automated driving systems. For aviation, it encompasses AI in flight management systems, autopilot components, and ground-proximity warning systems. For rail, it encompasses AI in automatic train protection, AI-assisted signalling, and autonomous shunting. The classification under **Art. 6(1)** is categorical. It does not require the AI system to independently demonstrate a significant probability of harm — the safety-component designation is sufficient. This means providers of such systems must comply with **Chapter III, Section 2** requirements (Arts. 9–15) covering risk management, data governance, technical documentation, automatic logging, transparency, human oversight, and accuracy and robustness. ### Annex III, Point 2 — Critical Infrastructure Management Separately from the safety-component pathway, **Annex III, point 2** expressly lists as high-risk AI systems intended to be used as **safety components in the management and operation of critical infrastructure**, specifically: - Critical **road traffic** infrastructure - Critical **water transport** infrastructure - Critical **electricity grid** components (as critical infrastructure with transport-equivalent risk profiles) AI systems that fall into this category include: motorway traffic management platforms using AI for dynamic speed control and incident detection, AI-based smart grid stability and load balancing systems where grid failure would affect transport operations, and AI systems managing port infrastructure at the level of essential service operation. The distinction between point 2 and the Annex I pathway is that Annex III, point 2 applies to **operators** of infrastructure rather than only to product manufacturers. A public authority or private concession holder operating an AI-driven traffic management centre is subject to point 2 obligations as a deployer or, if it has developed the AI system itself, as a provider. ### Dual Classification Where an AI system is both a safety component of an NLF-regulated product and is deployed in critical infrastructure management (e.g., an AI system integrated into a smart motorway platform that also interfaces with vehicle systems), both pathways apply. The more demanding obligations govern. --- ## Provider vs. Deployer in the Transport Context — OEM vs. Operator The allocation of obligations between **providers** (Art. 16) and **deployers** (Art. 26) is particularly complex in transport, where the supply chain between AI developer, system integrator, OEM, infrastructure operator, and end-user fleet may involve multiple legal entities each bearing distinct AI Act responsibilities. ### Vehicle OEMs as Providers An OEM that integrates an AI driving system — whether developed in-house or sourced from a Tier 1 or Tier 2 supplier — and places the vehicle on the EU market under its own brand name is the **provider** of the AI system under Art. 16. This is the case even if the AI technology was originally developed by a third party, provided the OEM has not merely resold an unchanged system under the third-party's branding. Provider obligations include: - Establishing a **quality management system** under **Art. 17** - Preparing and maintaining **technical documentation** under **Art. 11 and Annex IV**, covering the AI system's intended purpose, design, training data, validation results, and post-market monitoring plan - Conducting or commissioning **conformity assessment** — which, for safety components of vehicles, must be coordinated with the type-approval procedure under GSR 2019/2144 - Registering the AI system in the **EU database for high-risk AI systems** under **Art. 49** prior to market placement - Providing **instructions for use** to downstream deployers (fleet operators, rental companies) sufficient to enable compliant deployment ### Fleet Operators and Concession Holders as Deployers A company operating a fleet of autonomous vehicles, a local authority deploying an AI traffic management system, or a rail infrastructure manager using AI-assisted maintenance tools is a **deployer** under **Art. 26**. Deployer obligations include: - Using the AI system **within the scope of the provider's instructions for use** — any operational use outside that scope may re-classify the deployer as a provider, triggering the full provider obligation set - Implementing **human oversight measures** as specified by the provider and appropriate to the operational context - Maintaining **operational logs** generated by the AI system for at least six months, or longer where applicable sector legislation (NIS2, national transport safety legislation) requires extended retention - Reporting malfunctions or serious incidents to the provider promptly, and to national competent authorities under **Art. 73** where safety or fundamental rights are implicated - Conducting **fundamental rights impact assessments (FRIAs)** under **Art. 27** where the AI system is deployed by a public authority or in contexts affecting individuals at scale --- ## Interaction with Sector Regulations — EASA, ERA, and Type-Approval ### Road Vehicles — GSR 2019/2144 and Type-Approval The **General Safety Regulation (EU) 2019/2144** mandates the inclusion of specific ADAS and autonomous driving features in new vehicle types and establishes technical requirements for their performance. Vehicle type-approval — conducted by national type-approval authorities (e.g., KBA in Germany, DREAL in France, DVSA in the UK for historical approvals) — is the primary market-access mechanism for road vehicles. The EU AI Act does not displace type-approval. **Art. 8(1)** of the AI Act specifies that where sector-specific legislation imposes requirements of equivalent or greater stringency, procedural alignment is possible, but AI Act obligations remain. In practice, the conformity assessment for an AI driving system must address both the GSR technical requirements (assessed as part of type-approval) and the AI Act requirements (technical documentation, data governance, logging, human oversight, post-market monitoring). OEMs should plan for an **integrated assessment** covering both frameworks to avoid duplicative effort and potential gaps. ### Aviation — EASA and the AI Roadmap **EASA** exercises certification authority over aircraft, engines, and parts under Regulation (EU) 2018/1139. EASA's AI roadmap (published in successive editions from 2020) addresses AI trustworthiness for airborne AI systems and is the primary certification reference for AI in flight-critical applications. The EU AI Act applies to **ground-based aviation AI** (traffic management, maintenance diagnostics, cabin management systems) that falls outside EASA's airworthiness perimeter. For airborne AI systems that are certified by EASA, **Art. 8(1)** alignment is available, but the overlap between EASA airworthiness requirements and AI Act obligations (particularly on logging and human oversight) must be analysed system by system. EASA's concept of "AI assurance level" does not map directly onto the EU AI Act's high-risk classification or conformity assessment requirements. ### Rail — ERA and Safety Management Systems **ERA** (European Union Agency for Railways) oversees railway interoperability and the common safety framework under Directives 2016/797 and 2016/798. Railway undertakings and infrastructure managers are required to maintain a **Safety Management System (SMS)** that covers risk assessment, accident investigation, and continuous improvement. The EU AI Act's risk management requirements under **Art. 9** closely parallel ERA's SMS requirements. Organisations that have a mature SMS are well-positioned to integrate AI Act risk management documentation into the existing framework. ERA and the European Commission have indicated a preference for integrated compliance approaches that avoid duplication between SMS and AI Act obligations. AI systems used in automatic train operation, ETCS (European Train Control System) AI components, or predictive maintenance that feeds into safety-critical decisions are high-risk under Annex I (safety component of rail vehicles or infrastructure). --- ## Enforcement and Certification Authorities Transport AI compliance involves multiple enforcement bodies with partially overlapping jurisdiction, depending on the AI system's function and the product it is embedded in. **EASA** is the certification authority for AI in aircraft and aeronautical products. It may conduct investigations into AI system failures that implicate airworthiness, and its decisions affect market access across the EU and bilateral partner jurisdictions. **ERA** oversees the common safety framework for railways. Railway safety certificates and authorisations to operate are contingent on SMS conformity, which increasingly intersects with AI Act compliance for AI-enabled rail systems. **National vehicle type-approval authorities** — including KBA (Germany), ANFIA-delegated bodies (Italy), and Rijksdienst voor het Wegverkeer (Netherlands) — issue and can withdraw type approvals for road vehicles. Non-conformity with AI Act requirements for AI safety components may constitute grounds for type-approval suspension or recall. **NIS2 national competent authorities** — designated by each member state, often a national cybersecurity agency such as BSI (Germany), ANSSI (France), or NCSC-NL (Netherlands) — enforce NIS2 obligations for transport operators of essential services. NIS2 enforcement can result in binding instructions, fines, and in severe cases suspension of operations. **National AI supervisory authorities** designated under **Art. 70** of the EU AI Act will have general market surveillance powers, with coordination mechanisms for sector-specific authorities to avoid jurisdictional conflicts. --- ## Compliance Priorities for Transport Operators and Providers ### Step 1: AI System Inventory and Classification Conduct a structured inventory of all AI systems in development or deployment across the transport product or operational portfolio. For each system, determine whether it is a safety component of an NLF-regulated product (**Art. 6(1)** pathway), a critical infrastructure management AI (**Annex III, point 2**), or both. Document the classification rationale in writing. Systems that cannot be definitively excluded from high-risk classification should be treated as high-risk pending definitive legal analysis. ### Step 2: Conformity Assessment Route Planning For AI systems that are safety components of vehicles, aircraft, or rail products, identify the applicable sector certification procedure and map it against the AI Act conformity assessment requirements. Determine whether a notified body is required (**Art. 43(3)**) or whether a self-assessment with third-party technical audit suffices. Coordinate the AI Act conformity assessment timeline with the type-approval or certification programme to avoid market access delays. ### Step 3: Technical Documentation and Data Governance Prepare technical documentation under **Annex IV** for each high-risk AI system. For transport AI, this must include: the intended purpose with precision sufficient to support both AI Act and sector-regulation classification; training data provenance, including any real-world driving, operational, or sensor data used; simulation environment descriptions for AI systems validated through virtual testing; and post-market monitoring plans aligned with sector-specific reporting obligations. ### Step 4: NIS2 Integration for Critical Infrastructure Operators Transport operators of essential services must integrate AI Act cybersecurity requirements under **Art. 15** with NIS2 cybersecurity risk management obligations. Establish a single security risk assessment process covering both frameworks. Ensure AI software suppliers — including AI model developers and data providers — are subject to supply chain security requirements consistent with NIS2 Art. 21(2)(d) and AI Act Art. 25 (third-party tool obligations). ### Step 5: Human Oversight in Operational Contexts Design human oversight mechanisms under **Art. 14** that are operationally viable in transport environments. For autonomous driving systems, define the conditions under which a driver must be able to take control (L3) or a remote operator must be able to intervene (L4). For air traffic management AI, specify the points in the workflow at which a controller must review and approve AI-generated instructions. For rail maintenance AI, define escalation protocols when the system flags safety-critical anomalies. Oversight mechanisms must be documented in the technical documentation and reflected in the instructions for use provided to deployers. ### Step 6: Post-Market Monitoring and Incident Reporting Establish post-market monitoring systems that satisfy both AI Act **Art. 72** requirements and sector-specific safety reporting obligations (ERA accident reporting, EASA occurrence reporting under Regulation (EU) 376/2014, NIS2 incident notification). Serious incidents involving high-risk AI systems must be reported to the national AI supervisory authority under **Art. 73** within 15 working days of becoming aware. This timeline must be reconciled with NIS2's 24-hour initial notification requirement for significant cybersecurity incidents, which may cover the same event if the AI malfunction is attributable to a cybersecurity breach. -------------------------------------------------------------------------------- ## EU AI Act Technical Documentation (Art. 11): What High-Risk AI Systems Must Prepare URL: https://www.regulation-ai.eu/en/technical-documentation/ ## What Is the Technical File? The technical documentation — commonly called the "technical file" — is the master evidence package that demonstrates a high-risk AI system meets all EU AI Act requirements. Mandated by **Art. 11** and structured by **Annex IV**, it must be drawn up *before* the system is placed on the EU market and kept up to date throughout the system's lifecycle. The technical file is **not submitted centrally**. The provider holds it and presents it on request to market surveillance authorities and notified bodies. This is a pull model: authorities come to you; you must be ready to hand over a complete, coherent package, not an improvised stack of files assembled under pressure. Art. 11 imposes three duties on providers: 1. **Draw it up** before market placement or putting into service. 2. **Keep it up to date** — any substantial change to the system requires updating the file and reassessing conformity. 3. **Make it available** to competent authorities and notified bodies on request, within a defined timeframe (typically 10 business days under national market surveillance rules). The standard for "up to date" is functional: the technical file must reflect the system as actually deployed, not the system as originally designed. If a model update changes performance characteristics, accuracy thresholds, or training data, the file must be revised accordingly. --- ## Who Needs Technical Documentation? Technical documentation under Art. 11 and Annex IV is mandatory for **providers** of: - **High-risk AI systems listed in Annex III** — standalone systems in areas such as biometric categorisation, recruitment, credit scoring, critical infrastructure management, education, law enforcement, migration and border control, and administration of justice (subject to the Art. 6(3) significant-risk filter) - **AI systems functioning as safety components in Annex I-regulated products** — AI embedded in medical devices, machinery, vehicles, aviation equipment, and similar products governed by existing EU product safety legislation Technical documentation is **not required** for: - Minimal-risk AI systems (chatbots, spam filters, recommendation engines outside high-risk categories) - AI systems subject only to transparency obligations under Art. 50 (e.g. deepfake disclosures, emotion recognition disclosures where not high-risk) - General-Purpose AI (GPAI) model providers — they have separate documentation obligations under **Art. 53**, including technical documentation for the model itself, but not the Annex IV format designed for deployed high-risk systems If you are a **deployer** (not a provider), you are not required to prepare the technical file. However, deployers must maintain logs of system use (Art. 26(5)), and providers are entitled to draw on these logs when updating technical documentation or handling incident reports. --- ## The 14 Elements of Annex IV Annex IV specifies the minimum content of the technical file. There is no rigid format — providers may organise the documentation as they see fit — but all 14 elements must be present and substantive. Tick-box entries without supporting evidence do not satisfy Annex IV. | # | Annex IV element | What it must contain | |---|---|---| | 1 | **General description** | System name, version identifier, intended purpose, intended users, geographic markets, provider name and address, any authorised representative | | 2 | **System components** | Hardware requirements, software components, third-party models or libraries used, training methodology overview, algorithmic approach (e.g. supervised learning, reinforcement learning, transformer architecture) | | 3 | **Design specifications** | System architecture, data flow diagrams, key design decisions and their rationale, trade-offs made (e.g. accuracy vs. explainability), output format and how outputs feed into downstream decisions | | 4 | **Training, validation and testing data** | Datasets used at each stage, data sources, data governance procedures, statistical properties of datasets (size, distribution, coverage), data processing and pre-processing protocols, measures taken to detect and address dataset biases | | 5 | **Risk management documentation** | The complete Art. 9 risk management system: identified risks to health, safety, and fundamental rights; risk estimation and evaluation; risk mitigation measures adopted; residual risks accepted; basis for accepting residual risks | | 6 | **Lifecycle changes** | Description of all substantial modifications made after initial deployment, their nature and scope, how conformity was reassessed after each change, version history with dates | | 7 | **Human oversight measures** | How Art. 14 requirements are implemented: override and stop mechanisms, interfaces enabling human operators to monitor outputs, training or qualification requirements for operators, documented procedures for human intervention | | 8 | **Validation and testing procedures** | Performance metrics used (accuracy, precision, recall, F1, AUC, fairness metrics), test dataset descriptions, test conditions and environment, bias testing methodology and results, robustness and stress testing, out-of-distribution performance | | 9 | **Cybersecurity measures** | Technical measures against model theft, data poisoning, adversarial attacks, prompt injection (for LLM-based systems), access controls, encryption in transit and at rest, vulnerability management procedures | | 10 | **Bias and accuracy monitoring** | Ongoing monitoring procedures post-deployment, accuracy thresholds below which the system triggers a review, performance benchmarks disaggregated by demographic groups where relevant, procedures for acting on detected drift or bias | | 11 | **Instructions for use** | The Art. 13 deployer-facing document: intended purpose and use cases, performance characteristics and limitations, known constraints, maintenance and update requirements, logging obligations for deployers, contact point for reporting incidents | | 12 | **Post-market monitoring plan** | The Art. 72 monitoring system design: data collected from deployers, frequency of monitoring cycles, thresholds triggering a review or update, serious incident reporting procedure (Art. 73), procedure for feeding monitoring data back into risk management | | 13 | **Description of interfaces** | APIs and integration points, input data formats and constraints, output formats and their semantics, integration with other systems or components, version compatibility | | 14 | **Harmonised standards and common specifications** | List of harmonised standards applied (e.g. ISO/IEC 42001:2023, EN standards under the AI Act standardisation programme), common specifications adopted under Art. 41, the extent to which each standard was applied, any deviations and their justification | **Practical note on element 4 (training data):** Annex IV does not require you to disclose the datasets publicly or to authorities by default. It requires that the documentation *exists* and can be produced. For proprietary datasets, a description of data governance procedures, statistical summaries, and bias-testing results will typically satisfy the requirement without disclosing commercially sensitive data. **Practical note on element 14 (standards):** As of mid-2026, the AI Act standardisation programme is still in progress. ISO/IEC 42001 (AI management systems) is available and widely referenced. Providers should monitor the European standardisation work under CEN/CENELEC JTC 21 and update this section as harmonised standards are published in the Official Journal. --- ## EU Declaration of Conformity (Art. 47) The EU Declaration of Conformity (EU DoC) is a **separate mandatory document** — it is not part of the technical file, but it references it. The EU DoC is the provider's formal statement that the AI system complies with all applicable EU AI Act requirements. A valid EU DoC must include: - The provider's name and address (and authorised representative if applicable) - The AI system's name, version, serial or batch number if applicable - A statement that the system complies with the EU AI Act - The conformity assessment procedure used: **Annex VI** (internal control / self-assessment) for most Annex III systems, or **Annex VII** (third-party assessment by a notified body) for biometric categorisation AI and AI used in critical infrastructure requiring third-party involvement - A list of the harmonised standards or common specifications relied on - The signature of the provider's authorised representative with date and place The EU DoC must be kept for **10 years** after market placement and produced on request. It accompanies the CE marking (see below). For AI systems embedded in Annex I products, the EU DoC may be merged with the declaration of conformity required under the relevant sector legislation, provided it contains all the elements required by both legal instruments. --- ## CE Marking (Art. 48) High-risk AI systems placed on the EU market must bear the **CE marking**, which signals conformity with the EU AI Act and any other applicable Union harmonised legislation covering the same product. **Exceptions:** AI systems in Annex III categories deployed by **public authorities for their own internal use** are exempt from CE marking requirements. They remain subject to all other obligations — technical documentation, risk management, human oversight, registration — but do not need to affix CE marking. CE marking must be affixed before the system is placed on the EU market. It must be visible, legible, and indelible. Where the physical nature of the system does not permit affixing the marking directly, it may appear on the packaging or in the instructions for use. When a high-risk AI system is a component of an Annex I product that already requires CE marking under sector-specific legislation (e.g. medical devices, machinery), the CE marking covers conformity with both the sector legislation and the AI Act. Providers should document clearly which conformity assessment procedures underpin the CE marking. --- ## Practical Checklist: Minimum Viable Technical File Before any high-risk AI system is placed on the EU market, verify these 10 items are complete and evidenced: - [ ] **System description and version control** — name, version, intended purpose documented; a change log exists - [ ] **Architecture diagram** — data flow and component diagram showing all hardware, software, and third-party elements - [ ] **Training data inventory and governance record** — datasets catalogued with source, size, splits, and data quality procedures documented - [ ] **Risk assessment (per Art. 9)** — identified risks, mitigation measures, and accepted residual risks documented and signed off - [ ] **Bias testing results** — testing methodology documented; results disaggregated by relevant demographic groups where applicable - [ ] **Accuracy metrics on a representative test set** — performance metrics documented with test conditions; thresholds defined - [ ] **Human oversight procedure document** — override mechanisms described; operator requirements (training, qualification) documented - [ ] **Cybersecurity assessment** — known attack vectors assessed; technical countermeasures documented - [ ] **Instructions for use (deployer-facing)** — Art. 13 document complete, including limitations, logging obligations, and incident reporting contact - [ ] **Post-market monitoring plan** — data collection scope, monitoring frequency, review triggers, and incident reporting procedure documented This checklist covers the minimum. A well-prepared technical file will go further — particularly on bias testing methodology, model cards for component models, and evidence of the risk management process being iterative rather than a one-time exercise. --- ## How This Links to the EU AI Act Academy The **EU AI Act Academy Pro tier** includes ready-to-use technical documentation templates covering all 14 Annex IV elements, including: - A structured XLSX workbook with one tab per Annex IV element, pre-populated with prompts and example entries - A DOCX technical file skeleton ready for editing - A risk assessment worksheet following the Art. 9 iterative process - A data governance record template covering training, validation, and test datasets - A post-market monitoring plan template aligned with Art. 72 These templates are designed to be adapted to your specific system — they are starting points with substantive content, not blank forms. **Related pages:** - [Annex III — High-risk AI categories and obligations](/annex-iii/) - [Conformity Assessment procedures (Annex VI and VII)](/conformity-assessment/) - [EU AI Act Academy — templates and training](/academy/) - [Tools — Conformity Assessment Selector](/tools/conformity-selector/) -------------------------------------------------------------------------------- ## Using Third-Party AI Systems and LLMs: Deployer Obligations Under the EU AI Act URL: https://www.regulation-ai.eu/en/third-party-ai/ ## The Reality of Third-Party AI: Most Organisations Are Deployers The majority of European organisations using AI are neither OpenAI, nor Mistral, nor a research laboratory. They integrate existing models — via an API, a SaaS platform, an Azure AI component, or a business tool plugin. Salesforce Einstein, Copilot for Microsoft 365, an HR chatbot powered by a large language model, a credit scoring solution purchased from a specialist vendor: in all these cases, you are a **deployer** of an AI system built by someone else. This position is occupied by the vast majority of organisations affected by the EU AI Act. It carries precise obligations — different from those of the provider, but non-negligible. It can also evolve: if you modify the system or resell it, your legal status changes. Understanding your position in the AI value chain is the first step in any compliance effort. --- ## Your Obligations as a Deployer Deployer obligations differ depending on the risk level of the AI system you are using. ### For High-Risk AI Systems (Annex III) If you deploy a third-party AI system that qualifies as high-risk (creditworthiness assessment, biometric identification, recruitment screening, critical infrastructure management, etc.), your obligations under Art. 26 are: **1. Follow the instructions for use** Use the system only for its intended purpose and in accordance with the instructions the provider is required to supply. Using a high-risk AI system outside its validated scope is a compliance failure even if you are only a deployer. **2. Assign human oversight** Designate a natural person with the competence, authority, and resources to perform meaningful human oversight over the AI system's outputs. This person must be able to understand what the system is doing, detect anomalies, and override or halt the system when necessary. **3. Ensure input data quality** Ensure that data you feed into the system is relevant, sufficiently representative, and appropriate for the intended purpose in your specific deployment context. A system validated on one population may perform differently on yours — that is your risk to manage. **4. Monitor operation and detect anomalies** Actively monitor the system's operation for anomalies, unexpected outputs, or performance degradation. This is not the provider's responsibility in deployment — it is yours. **5. Retain logs** Activate and retain the automated logs produced by the system for the period required by the Act (and any sectoral regulation that may apply). Do not turn off logging to save storage costs. **6. Report serious incidents** If you become aware of a serious incident or malfunction — one that caused or could cause death, serious harm, fundamental rights violations, or significant property damage — notify the provider without undue delay. In some cases (particularly where the deployment involves public-facing services or law enforcement adjacent activities), direct reporting to the national market surveillance authority may also be required. **7. Fundamental rights impact assessment (public bodies)** If you are a public body, or a private entity deploying AI systems in areas likely to affect fundamental rights (healthcare, social services, education, law enforcement), you must conduct a Fundamental Rights Impact Assessment before deployment (Art. 27). ### For Transparency-Only AI Systems (Art. 50) If you deploy a chatbot, AI-generated content system, or emotion recognition tool that is not high-risk but falls under Art. 50 transparency obligations, you must: - Inform users they are interacting with an AI system (Art. 50(1)) - Ensure AI-generated content is technically marked (Art. 50(4)) where applicable - Inform exposed persons when emotion recognition or biometric categorisation is being used (Art. 50(2)–(3)) These obligations apply even when using a third-party API or SaaS tool. The provider is responsible for building in the technical capability; you are responsible for activating it and ensuring the disclosure actually reaches users. ### For Minimal-Risk AI Systems No specific legal obligations under the AI Act. Voluntary codes of conduct apply. Good governance practice still recommends basic documentation of AI systems in use and periodic review of their performance. --- ## What to Demand from Your Third-Party AI Provider Your ability to fulfil deployer obligations depends directly on what the provider gives you. The EU AI Act requires providers of high-risk AI systems to supply specific information — and GPAI model providers have parallel documentation obligations. Use this checklist when procuring third-party AI: ### For Any AI System - **System description:** What does the system do, what inputs does it take, what outputs does it produce, and what decisions can it influence? - **Intended purpose:** Precisely for which use cases has the system been designed, validated, and approved? - **Known limitations:** Under what conditions does the system perform poorly? What populations, languages, or data types are outside its validated scope? - **Instructions for use:** The full set of instructions the provider is required to supply under Art. 13 for high-risk systems ### Specifically for High-Risk Systems - **Declaration of Conformity** or summary of conformity assessment results - **Risk management documentation** — what risks were identified and how were they mitigated? - **Bias and fairness testing results** — what protected characteristics were tested, what metrics were used, and what results were found? - **Performance metrics** — accuracy, false positive/negative rates, and disaggregated performance by relevant demographic groups - **Logging capability** — confirmation that the system generates the logs required by Art. 12, and instructions for accessing and retaining them - **Incident notification process** — who to contact, in what timeframe, and by what channel when a serious incident occurs - **Update policy** — how does the provider notify you of material updates, and what re-validation is required after updates? ### For GPAI Models (APIs and Foundation Model Access) - **Model card or technical summary** — capabilities, limitations, training data summary, evaluation results - **Copyright compliance statement** — how the provider addresses copyright law for training data and outputs - **Acceptable use policy** — what use cases are prohibited by the provider, and what happens if you breach them? - **Data processing terms** — how does the provider handle your input data? Is it used for further training? --- ## When You Become a Provider The EU AI Act's Art. 25 is crucial for third-party AI users: it defines when a deployer transitions into a provider and assumes all provider obligations. You become a provider when you: ### 1. Substantially Modify a High-Risk AI System If you take a high-risk AI system and make substantial changes that go beyond what the provider intended — changing the model, retraining on your data, altering core logic — you are now a provider of a new or substantially modified system. All provider obligations apply: conformity assessment, technical documentation, CE marking, EU database registration. **Key question:** Is your customisation "use within the intended parameters" or "development of a new capability"? Fine-tuning a model on your domain data may or may not be substantial modification depending on the degree of change and whether it affects the risk profile. ### 2. Change the Intended Purpose to High-Risk If you take a system not classified as high-risk and deploy it for a high-risk use case — using a general text classifier to make employment decisions, for example — you have changed the intended purpose in a way that triggers high-risk classification. You become the provider of a high-risk AI system and must comply with all provider obligations for that deployment. ### 3. Place the System on the Market Under Your Own Name If you purchase or license an AI system and resell it or offer it to others as your own product (white-labelling), you place it on the market under your own name and become the provider. This is common in the SaaS sector: integrating a third-party model into your own product offering makes you the provider for that product. ### 4. Make Major Changes to a GPAI Model If you take a GPAI model and make major modifications to its capabilities or use case — beyond fine-tuning within the provider's intended parameters — you may become a provider of a new GPAI model with your own Chapter V obligations. --- ## Contractual Protections for Deployers Because your compliance depends on what the provider gives you, your contracts with third-party AI vendors are a critical compliance tool. Key clauses to include: ### Information Rights - Right to receive and regularly updated version of the instructions for use - Right to access the declaration of conformity and conformity assessment summary - Right to receive bias testing results and performance metrics - Right to receive documentation of material model updates before deployment ### Incident Management - Obligation on provider to notify you of any serious incidents or vulnerabilities they become aware of, within a defined timeframe - Clear channel and process for you to report incidents to the provider - Commitment from provider to cooperate with your incident investigations and regulatory inquiries ### Audit Rights - Right to audit or to receive audit reports on the provider's compliance with AI Act obligations - Right to request updated documentation when significant changes occur ### Update Obligations - Provider must notify you before deploying material updates to the AI system - Provider must advise whether an update constitutes a substantial modification requiring re-validation - Continuity of documentation — updated technical documentation must be provided with each material update ### Liability Allocation - Clarity on which party is responsible for which obligations under Art. 25 - Indemnification for losses arising from provider non-compliance with supplier obligations - Limitation of liability provisions that do not undermine your ability to meet regulatory obligations --- ## The Vendor AI Market: What to Watch The market for AI tools and services is evolving rapidly, and the EU AI Act compliance posture of vendors varies significantly: - **Major cloud and AI providers** (Microsoft, Google, AWS, OpenAI, Anthropic) have invested heavily in AI governance and GPAI compliance documentation. Their terms of service and model cards provide more information than most other vendors. - **Specialist vertical AI vendors** (HR tech, legal tech, fintech, healthtech) are at varying stages of EU AI Act readiness. Many are SMEs that have not yet fully mapped their obligations. - **Embedded AI in SaaS tools** (AI features in CRM, ERP, productivity tools) may not be marketed as "AI products" — but if they make or influence consequential decisions about individuals, EU AI Act obligations apply. Procurement teams should add AI Act compliance screening to vendor due diligence — asking vendors to attest to their compliance status, provide conformity documentation for high-risk systems, and commit to ongoing information-sharing as the regulatory landscape develops. -------------------------------------------------------------------------------- ## EU AI Act Complete Toolkit — All Seven Working Files URL: https://www.regulation-ai.eu/en/toolkits/complete/ Seven files that cover an AI Act programme from the first inventory to the evidence a supervisor asks for. ## Why buy them together Because they reference each other. The inventory tells you which systems are high-risk; the risk register and technical file only apply to those. The vendor questionnaire asks for the Annex IV information the technical file needs. The literacy register records the training that Art. 26(2) oversight depends on. Bought one at a time, you discover those dependencies in the wrong order. ## What you get Each file is a working Excel workbook — pre-filled with content, not an empty grid. Derived values are formulas, not typed opinions, so an assessment leaves an audit trail rather than an assertion. They open identically in Excel, LibreOffice Calc and Google Sheets: no FILTER, no XLOOKUP, no array formulas. ## The honest position The whole set is built on a claim this site makes everywhere: **most of your AI is not high-risk**. Annex III 5(b) excludes financial fraud detection, point 1 excludes 1:1 biometric verification, and algorithmic trading appears nowhere in the annex at all. That is why the inventory comes first and why four of the seven files apply regardless of tier. A toolkit that assumed everything was high-risk would be easier to sell and wrong. ## What it is not It is not legal advice, and we are not a notified body or a supervisory authority. These are the documents a competent team produces; your competent authority remains the only source of a binding position. -------------------------------------------------------------------------------- ## EU AI Act Data Governance Checklist — Art. 10 Training Data Requirements URL: https://www.regulation-ai.eu/en/toolkits/data-governance/ Article 10 is the requirement that fails quietly. The model works. The documentation exists. And nobody can say where the training data came from, or whether it represents the people the system will be used on. ## What Art. 10 actually asks Eleven things, and they are more specific than most teams expect: - the **design choices** for the data, documented; - **collection processes and origin** — and for personal data, the *original* purpose of collection; - **preparation operations**: annotation, labelling, cleaning, updating, enrichment, aggregation; - the **assumptions** each data set is meant to represent; - an assessment of **availability, quantity and suitability**; - **bias examination** for biases likely to affect health, safety or fundamental rights; - **bias mitigation** measures; - **gaps and shortcomings**, identified and addressable; - training, validation and test sets that are relevant, sufficiently representative, and as far as possible error-free and complete (10(3)); - **contextual characteristics** — geographical, behavioural, functional (10(4)); - and the narrow permission in **10(5)** to process special-category data strictly for detecting and correcting bias, with safeguards. ## What is in the file An **inventory** of every training, validation and test set with its provenance and whether it holds personal data. The **eleven criteria** as a checklist with a state and an evidence pointer. A **bias examination register** — attribute examined, method, what was found, mitigation applied, residual. And a **gaps tab**, because 10(2)(h) asks you to *identify* shortcomings, not to have none. ## The line that matters most Art. 10(2)(b) asks for the origin **and**, where personal data is involved, the original purpose of collection. Repurposing customer data for model training is precisely where this file and your GDPR record have to agree — and where they most often do not. -------------------------------------------------------------------------------- ## EU AI Act Toolkits — Working Templates for Compliance Teams URL: https://www.regulation-ai.eu/en/toolkits/ Seven working files covering an EU AI Act programme from the first inventory to the evidence a supervisor asks for. They are built on a claim this site makes everywhere and that most vendors avoid: **most of your AI is not high-risk**. Annex III 5(b) expressly excludes financial fraud detection, point 1 excludes 1:1 biometric verification, and algorithmic trading appears nowhere in the annex. That is why the inventory comes first, and why four of the seven files apply whatever tier your systems land in. Start with the inventory. Then buy only what your classification actually requires. -------------------------------------------------------------------------------- ## EU AI Act Art. 4 AI Literacy Programme — Curriculum and Training Register URL: https://www.regulation-ai.eu/en/toolkits/literacy-programme/ Art. 4 is the obligation everyone already owes and almost nobody evidences. It has applied since **2 February 2025**. It binds providers *and* deployers. It does not care what tier your systems are in. And the Digital Omnibus softened its wording — from "shall ensure a sufficient level" to "shall take measures to support" — without removing it. ## What a supervisor actually asks for Not a slide deck. A record: which roles were trained, on what, and when. That is what this file is. ## Different roles need different things The reason literacy programmes stall is that they are designed as one course for everyone, which is simultaneously too much for most staff and too little for the people who need it. The curriculum here splits eight roles: - **Board and executive** — the obligation map, the penalty exposure, who owns what. Not the technical detail. - **Compliance and risk** — enough to challenge a classification and read a technical file. - **Legal and procurement** — provider vs deployer, the Art. 25 triggers, the clause set. - **Product and engineering** — oversight and logging built in rather than bolted on. - **Data science** — what Art. 10 asks of a training set. - **Operations and human overseers** — how to actually exercise the oversight assigned to them. - **Customer-facing staff** — what must be disclosed under Art. 50. - **All staff** — baseline awareness. ## The Art. 26(2) trap For high-risk deployers the bar is higher than Art. 4. The people assigned to human oversight must have competence, training **and the authority to intervene**. A trained overseer who cannot overrule the model does not satisfy Art. 26(2) — and that is the failure automation bias produces on its own, quietly, over months. ## Free training that feeds this register The [AI Act Fundamentals course](/academy/ai-act-fundamentals/) on this site is free and covers the "All staff" row and much of "Compliance and risk". Its exam issues a certificate with a public verification id you can file straight into the register. -------------------------------------------------------------------------------- ## EU AI Act Template Pack — Risk Register, Technical File and Data Governance URL: https://www.regulation-ai.eu/en/toolkits/pro-pack/ The three files a high-risk AI system needs, bought together. ## Why these three They are the three obligations that produce documents a supervisor can ask to see: - **Art. 9** — the risk management system, as a register with 18 scenarios already written. - **Art. 11 + Annex IV** — the technical documentation, as 30 discrete elements with owners and evidence pointers. - **Art. 10** — data governance, as an inventory plus the eleven criteria and a bias examination register. They also feed each other. Annex IV §2(d) asks about the data, which is what the Art. 10 file holds. Annex IV §5 asks about the risk management system, which is the register. Filling them in isolation means filling parts of each one twice. ## Before you buy this Check that you actually have a high-risk system. Annex III 5(b) excludes financial fraud detection, point 1 excludes 1:1 biometric verification, and algorithmic trading is not in the annex at all. The [inventory and classification workbook](/en/toolkits/system-inventory/) settles that question first, and it is the cheaper mistake to avoid. If your classification comes back clear of Annex III, the files you need are the [transparency pack](/en/toolkits/transparency-pack/) and the [literacy programme](/en/toolkits/literacy-programme/) — both of which apply whatever your tier. -------------------------------------------------------------------------------- ## EU AI Act Risk Register — Art. 9 Risk Management System (Annex III Mapped) URL: https://www.regulation-ai.eu/en/toolkits/risk-register/ Article 9 does not ask for a risk assessment. It asks for a **system** — continuous, documented, running across the entire lifecycle of a high-risk AI system, identifying risks, estimating them, evaluating them post-market, and adopting measures. The gap between those two things is where most programmes sit. A one-off assessment produces a document. Art. 9 wants a process that keeps producing evidence. ## What is in the file **Eighteen risk scenarios, already written.** Data unrepresentative of the deployment population, historical bias reproduced from past decisions, drift after deployment, the reviewer who rubber-stamps, the deployer who silently becomes a provider under Art. 25, the vendor who will not supply Annex IV information, the serious incident with no path to Art. 73. Each carries the article it answers to and a mitigation to start from. The first review is then a conversation about your situation rather than a blank page and a facilitator. **Scoring that means something.** Likelihood × impact, where impact means impact on **health, safety or fundamental rights** — Art. 9(2) is not asking about your P&L. Residual risk is scored after mitigation and recorded with the name of whoever accepted it, because Art. 9(2)(d) expects exactly that. **An Annex III scope tab** with the carve-outs, so the register is not filled in for a system that was never high-risk. **A dashboard** that recalculates: how many risks are high, how many are still open, and how they distribute across the eight themes. ## The honest caveat A register with no accepted residual risk has not finished its job. The file says so on the dashboard. Art. 9 anticipates that some risk remains and asks you to judge it acceptable and say so — not to reach zero. -------------------------------------------------------------------------------- ## AI System Inventory & Classification Workbook — EU AI Act URL: https://www.regulation-ai.eu/en/toolkits/system-inventory/ You cannot classify what you have not listed, and you cannot budget a programme without knowing how many systems land in each tier. This file does both, in the order that avoids the usual mistakes. ## The order matters Most classification exercises go straight to Annex III and ask "is this in the list?". That is how a fraud-detection model ends up classified as high-risk — it *looks* like credit scoring, and the carve-out that excludes it sits inside the same point. The decision path here asks the eight questions in the order that gets the answer right: 1. **Is it an AI system at all?** Art. 3(1) requires inference. A deterministic rules engine is out entirely — and counting those is budget you do not spend. 2. **Is it prohibited?** Art. 5, in force since February 2025. Stop before anything else. 3. **Does a carve-out apply?** Financial fraud detection, 1:1 biometric verification, creditworthiness of legal persons. 4. **Annex I?** Then 2 August 2028. 5. **Annex III?** Then 2 December 2027. 6. **Does the Art. 6(3) filter apply** — and is it void because the system profiles natural persons? 7. **Does Art. 50 transparency apply** regardless? 8. **Are you provider or deployer**, and does Art. 25 flip it? ## The tier is derived, not typed You answer five yes/no questions per system. The workbook computes the tier. That matters more than it sounds: a classification someone typed is an opinion, while a classification a formula derived from stated answers is an audit trail. If a supervisor disagrees, you can show which answer drove the outcome. Empty rows stay empty — they do not silently count as high-risk. The summary tab gives you the counts a budget conversation needs: systems listed, out of scope, prohibited, high-risk, not high-risk. ## What usually happens Organisations come out of this with **far fewer high-risk systems than they feared**, and one or two they had not noticed — typically in HR, because Annex III point 4 catches you as an employer whatever your sector. If every system in your inventory comes out high-risk, the classification is wrong. The file says so explicitly, and tells you which three carve-outs to re-read. -------------------------------------------------------------------------------- ## EU AI Act Technical Documentation File — Annex IV Template (Art. 11) URL: https://www.regulation-ai.eu/en/toolkits/technical-file/ Art. 11 says the technical documentation must be drawn up **before** the system is placed on the market and kept up to date. Annex IV says what has to be in it. Annex IV is nine paragraphs of dense prose. Read as prose, it produces meetings. Read as a checklist, it produces a file. ## What is in the file **Thirty discrete elements**, extracted from the nine Annex IV sections and listed individually — from "intended purpose, provider name, version" through "validation and testing procedures, metrics used, and test logs" to "the post-market monitoring plan under Art. 72". Each element carries a state (missing, drafted, reviewed, complete, not applicable), an owner, and a link to where the evidence actually lives. That last column is the one that turns a documentation exercise into an audit trail. **A completeness view** that recalculates per section, so "are we ready" has a percentage instead of an opinion — and so the section that is 0% is visible before an auditor finds it. **A change log**, because Art. 11 requires the file to be *kept* up to date and a file with no version history cannot show that it was. ## Who fills it in If you are the provider, all of it. If you are a deployer, you do not owe an Annex IV file — but you will need much of its content anyway, and getting it out of your vendor is a contractual matter best settled before signing. The [vendor due diligence pack](/en/toolkits/vendor-due-diligence/) is the questionnaire for that. ## One thing worth knowing Art. 18 requires this documentation to be kept for **ten years** after the system is placed on the market. Reaching 100% completeness is the beginning of that obligation, not the end of it. -------------------------------------------------------------------------------- ## EU AI Act Art. 50 Transparency Pack — Disclosure Templates & Register URL: https://www.regulation-ai.eu/en/toolkits/transparency-pack/ Art. 50 is the AI Act obligation most programmes discover last and owe first. It applies **whatever your risk tier**. The chatbot you correctly classified as minimal risk is still caught. So is the marketing image your team generated last week. And unlike the Annex III high-risk regime, deferred to 2 December 2027, Art. 50 was **not** moved by the Digital Omnibus. It lands on **2 August 2026**. ## Why organisations miss it Programme plans are built around the biggest number on the page, which is the high-risk regime. Art. 50 is smaller, cheaper and sooner, and it sits with teams that are not in the compliance conversation: marketing generates content, support runs the chatbot, product ships the assistant. Nobody in that chain reads Annex III, and nobody told them they owe a disclosure. ## What is in the file **The obligations** — each paragraph of Art. 50, what it actually says, the touchpoint it typically bites on, and whether the provider or the deployer owes it. Including the artistic and satirical exception in 50(4), which limits *how* you disclose rather than removing the duty. **Touchpoint register** — twelve pre-listed places an organisation touches a person with AI, from web chat to synthetic voice to AI-drafted email sent under a human name. Mark what is in use, which paragraph applies, and whether a disclosure exists. One formula tells you what is live and undisclosed, which is the number that matters. **Disclosure wording** — sentences you can adapt, for each situation, with a note on the trap in each. A visible watermark, for instance, is not machine-readable marking; 50(2) asks for the output to be detectable as artificially generated. **Marking register** — where synthetic content is produced, how it is marked, and whether that marking is machine-readable. ## Who this is for Compliance officers who need to know what is exposed before August, and the product or marketing owner who has to fix it. It assumes no legal background and produces an artefact you can hand to an auditor. -------------------------------------------------------------------------------- ## AI Vendor Due Diligence Pack — 32 Questions and Contract Clauses URL: https://www.regulation-ai.eu/en/toolkits/vendor-due-diligence/ Your obligations as a deployer depend on information you do not hold. The Annex IV documentation, the bias examination, the accuracy figures per segment, the log format — all of it sits with the provider. Ask for it after signing and you are negotiating from zero leverage. On the sister site's DORA work, contract remediation is consistently the longest workstream in a programme. The AI Act version will be no different, and it has the same fix: ask before you sign. ## The questionnaire Thirty-two questions in eight groups — identification, classification, documentation, data, performance, oversight, logging, change, incidents, cooperation and exit — written to be sent to a supplier as-is. Each has a slot for their answer and an adequacy verdict that colours itself. Some of them are uncomfortable on purpose: - *Is our data used to train or improve your models? Under what terms, and can we opt out?* - *If we fine-tune or configure the system, at what point do you consider us the provider?* - *Do you accept the Art. 25(4) cooperation duty in writing, including technical access?* ## Reading the answers Not every "No" weighs the same. The scoring tab names the five that are deal-breakers rather than negotiating points — starting with a refusal of the **Art. 25(4) cooperation duty**, which is the one to walk away over. Without it, if you ever become the provider under Art. 25, you cannot meet the obligations you have just inherited. ## The clause library Eight clauses covering cooperation, Annex IV documentation, change notification, log export and retention, serious incidents, bias and data governance, use of your data for training, and exit. Square brackets mark the numbers you set. They are drafted to be dropped into your own paper, not to replace your counsel. ## Who this is for Procurement and legal teams buying AI, and the compliance officer who will be asked to sign off on a system whose internals they have never seen. -------------------------------------------------------------------------------- ## AI Risk Classifier — Is Your AI System High-Risk Under the EU AI Act? URL: https://www.regulation-ai.eu/en/tools/ai-risk-classifier/ ## How EU AI Act risk classification works The EU AI Act uses a four-tier classification logic. Work through each question in order — the first match determines your category. ### Step 1 — Is your AI a safety component embedded in a regulated product? If your AI system is integrated into a product governed by EU product safety legislation (medical devices MDR/IVDR, machinery, motor vehicles, aviation, railways, lifts, toys, PPE), it is classified as **Annex I high-risk** under Art. 6(1). The compliance deadline is **2 August 2028**. → Yes: [Annex I obligations →](/annex-i/) ### Step 2 — Is your AI a standalone system in one of 8 high-risk sectors? If your AI operates autonomously (not embedded in a regulated product) and falls into one of these domains, it is **Annex III high-risk** under Art. 6(2): 1. Biometric identification and categorisation 2. Critical infrastructure management 3. Education and vocational training access 4. Employment, worker management, and self-employment access 5. Essential private and public services (credit scoring, insurance risk, benefits) 6. Law enforcement 7. Migration, asylum, and border control 8. Administration of justice and democratic processes The compliance deadline is **2 December 2027**. Note: Art. 6(3) allows exclusion if the system presents no significant risk of harm — this must be documented. → Yes: [Annex III obligations →](/annex-iii/) ### Step 3 — Is your system a general-purpose AI model? If your system is an AI model trained at large scale on broad data to perform a wide range of tasks (LLM, multimodal foundation model, large image-generation model), it is classified as **GPAI** under Chapter V. Obligations have applied since **2 August 2025**. → Yes: [GPAI obligations →](/gpai/) ### Step 4 — Transparency or minimal risk If none of the above apply: - **Transparency-only (Art. 50):** AI systems that interact with humans (chatbots), generate synthetic content (deepfakes), or perform emotion recognition must disclose their AI nature to users. - **Minimal risk:** All other AI systems. No mandatory obligations, but voluntary codes of conduct apply. Use the [Compliance Checklist →](/compliance-checklist/) after classification to map out your specific obligations and timelines. -------------------------------------------------------------------------------- ## EU AI Act Compliance Checker — Interactive Checklist & Score URL: https://www.regulation-ai.eu/en/tools/compliance-checklist/ ## Check your EU AI Act compliance obligations in 3 steps This tool gives compliance teams, legal counsel, and product managers a fast, personalised read on their EU AI Act obligations. Work through the wizard in under 5 minutes to get your compliance score and a prioritised list of actions. **How it works:** 1. Select your role — provider, deployer, both, or GPAI developer 2. Select your AI system's risk tier 3. Work through the relevant checklist items and see your compliance score Results are indicative guidance only and do not constitute legal advice. Complex or edge-case situations require professional legal assessment. **Checklist coverage:** - **Annex III high-risk providers** — 30+ obligations from Art. 9 (risk management) through Art. 71 (EU AI database registration) - **Annex I high-risk providers** — integration with host product regulation (MDR, Machinery, etc.) + Annex III obligations - **Annex III deployers** — oversight, FRIA, staff training, incident reporting obligations - **GPAI developers** — technical documentation, copyright, downstream support, systemic risk assessment - **Transparency-only AI** — Art. 50 disclosure obligations (chatbots, deepfakes, emotion recognition) -------------------------------------------------------------------------------- ## Conformity Assessment Selector — Which EU AI Act Procedure Applies to Your AI? URL: https://www.regulation-ai.eu/en/tools/conformity-selector/ ## Two routes to EU AI Act conformity for high-risk AI The EU AI Act provides two conformity assessment procedures for high-risk AI systems. Which one applies depends on your AI system category. ## Route A: Self-assessment (Annex VI internal control) **Applies to:** Most Annex III standalone high-risk AI systems **Who does the assessment:** The provider internally, against harmonised standards (EN ISO/IEC standards when published) or directly against the AI Act requirements (Art. 9-15, 17). **What it produces:** 1. Technical documentation (Art. 11 + Annex IV) 2. Quality Management System (Art. 17) 3. EU Declaration of Conformity (Art. 47) 4. CE marking on the system or documentation (Art. 48) 5. Registration in the EU AI database (Art. 71) **Timeline:** No external bottleneck — the provider controls the pace. Most organisations should allow 6-12 months for thorough self-assessment given the documentation depth required. ## Route B: Third-party assessment (Annex VII — notified body) **Mandatory for:** - Biometric identification and categorisation AI (Annex III point 1) - Certain critical infrastructure AI where no harmonised standard covers the relevant safety component **What the notified body does:** Reviews the technical documentation, conducts conformity assessment, issues an EU technical documentation assessment certificate (Annex VII). The provider then draws up the DoC and applies CE marking. **Timeline:** Notified body queues are already constrained (2026) and will worsen as 2027 approaches. Engage your notified body as early as possible — 12-18 months lead time is advisable. ## Route C: Integrated assessment (Annex I systems) **Applies to:** AI embedded as a safety component in regulated products (medical devices, machinery, vehicles, aviation equipment, etc.) **How it works:** AI Act conformity assessment is integrated into the existing product safety conformity assessment. No separate AI-only procedure. Your existing notified body (MDR, MDR, Machinery) handles the combined assessment if designated for AI Act conformity — otherwise coordination between two notified bodies may be required. For Annex I details: [Annex I obligations →](/annex-i/) | For Annex III details: [Annex III obligations →](/annex-iii/) -------------------------------------------------------------------------------- ## EU AI Act Deadline Calculator — When Does Your AI System Need to Comply? URL: https://www.regulation-ai.eu/en/tools/deadline-calculator/ ## EU AI Act compliance deadlines — updated for Digital Omnibus 2026 The Digital Omnibus 2026 extended two key deadlines. The table below reflects current law. | AI System Type | Deadline | Extension vs. original | |---|---|---| | **Prohibited practices** (Art. 5) | 2 February 2025 | Not extended — already in force | | **GPAI models** (Chapter V) | 2 August 2025 | Not extended — already in force | | **General provisions** (transparency, Art. 50) | 2 August 2026 | Not extended | | **Annex III standalone high-risk AI** | 2 December 2027 | +16 months (was 2 Aug 2026) | | **Annex I embedded high-risk AI** (product safety) | 2 August 2028 | +24 months (was 2 Aug 2026) | ## Finding your deadline **Prohibited practices (Art. 5):** Already in force since 2 February 2025. If you are using social scoring, real-time biometric identification in public spaces for law enforcement (without exceptions), subliminal manipulation systems, or other prohibited AI — you are already out of compliance. Stop use immediately. **GPAI providers:** Obligations under Chapter V have applied since 2 August 2025. If you provide a GPAI model and have not yet implemented technical documentation and copyright summaries, you are currently non-compliant. **Annex III systems:** You have until 2 December 2027, but notified body queues and harmonised standard availability mean that preparation should begin now. [Use the Compliance Checklist →](/compliance-checklist/) **Annex I systems:** The 2 August 2028 deadline reflects the additional complexity of coordinating AI Act conformity assessment with your existing product safety certification. Engage your notified body early — capacity is limited. For the full deadline timeline with countdowns, see [Deadlines & Key Dates →](/deadlines/) -------------------------------------------------------------------------------- ## DORA + EU AI Act Overlap Detector — Dual Compliance for Financial Entities URL: https://www.regulation-ai.eu/en/tools/dora-ai-overlap/ ## Where DORA and the EU AI Act converge for financial entities DORA (Digital Operational Resilience Act) has applied since 17 January 2025. The EU AI Act applies from various dates in 2025–2028. Banks, insurers, investment firms, payment institutions, and other financial entities must satisfy both simultaneously. The two regulations share significant conceptual ground — both target ICT risk management, third-party dependencies, and operational resilience — but with different scopes and obligations. ## Key overlap areas by AI use case | AI Use Case | DORA obligations | EU AI Act obligations | |---|---|---| | **Credit scoring / loan decisions** | ICT risk management (Art. 5-10); third-party risk if vendor-supplied | Annex III high-risk (Art. 6); full Chapter III obligations; deadline Dec 2027 | | **Fraud detection** | ICT incident classification (Art. 17-23); third-party TPSP management | Annex III high-risk (law enforcement adjacent — check scope); Art. 13 transparency to deployers | | **Algorithmic trading** | ICT change management (Art. 14-16); operational risk | Likely minimal risk or transparency-only; check if GPAI models underpin it | | **AML / transaction monitoring** | ICT resilience testing (TLPT for significant entities) | Potentially Annex III (law enforcement nexus); legal analysis required | | **Customer service chatbots** | ICT operational risk | Art. 50 transparency — must disclose AI nature to users | | **Insurance risk pricing** | ICT third-party risk for model vendors | Annex III high-risk (essential services — insurance risk assessment) | ## Where the frameworks reinforce each other **ICT third-party risk + AI Act provider obligations:** DORA Art. 28-44 requires contractual clauses with ICT service providers covering audit rights, exit strategies, and performance standards. When that ICT provider is also an AI Act provider, the AI Act requires the provider to supply technical documentation, instructions for use, and post-market monitoring support. A single well-drafted vendor contract can satisfy both. **Incident reporting:** DORA mandates major ICT-related incident reporting to supervisors. The AI Act requires reporting of serious incidents involving high-risk AI to national market surveillance authorities. For financial entities, a single AI failure (e.g., a credit-scoring model outage causing systemic risk) may trigger both reporting chains simultaneously. **Resilience testing:** DORA's Threat-Led Penetration Testing (TLPT) for significant entities overlaps with AI Act Art. 15's robustness and cybersecurity requirements. Combining both testing regimes reduces duplication. For a detailed analysis of the regulatory convergence, see [AI Act vs. DORA vs. NIS2 →](/ai-act-vs-dora-vs-nis2/) -------------------------------------------------------------------------------- ## GPAI Checker — Does Your AI Model Have EU AI Act GPAI Obligations? URL: https://www.regulation-ai.eu/en/tools/gpai-checker/ ## What qualifies as a GPAI model under the EU AI Act? A General-Purpose AI (GPAI) model under Art. 3(63) is an AI model that: - Is trained on large amounts of data using self-supervision at scale - Displays significant generality - Is capable of competently performing a wide range of distinct tasks Examples include large language models (LLMs), large multimodal models, and large code-generation models. A downstream application built on top of a GPAI model is a **GPAI system** — different obligations apply to the model provider vs. the downstream integrator. **GPAI obligations have been in effect since 2 August 2025.** ## The three GPAI obligation tiers | Tier | Trigger | Key obligations | |---|---|---| | **Reduced** | Open-source weights publicly released | Copyright compliance; cooperation with AI Office; systemic risk obligations if threshold exceeded | | **Standard** | All non-open-source GPAI providers | Technical documentation (Art. 53); copyright summary; downstream support; AI Office cooperation | | **Systemic risk** | Training compute > 10²⁵ FLOPs | All standard obligations + adversarial testing, incident reporting, cybersecurity measures, energy consumption disclosure | ## Which tier applies to you? **Question 1:** Do you publicly release model weights so anyone can run the model locally? - Yes → Reduced obligations (but read the systemic risk question below) - No → Standard obligations minimum **Question 2:** Was your model trained with more than 10²⁵ floating-point operations (FLOPs)? - Yes → Systemic risk obligations apply (in addition to reduced or standard) - No / unknown → Use conservative estimates; if uncertain at scale, consult with technical advisors For the full list of GPAI obligations and how to meet them, see the [GPAI obligations guide →](/gpai/) -------------------------------------------------------------------------------- ## Free EU AI Act Compliance Tools — Risk Classifier, GPAI Checker, Compliance Checklist URL: https://www.regulation-ai.eu/en/tools/ ## Seven free tools for EU AI Act compliance These tools give compliance teams, legal counsel, and product managers an instant, indicative read on their EU AI Act obligations. Each tool is free, browser-based, and requires no registration. Results are guidance only — they do not constitute legal advice. - **[Compliance Checklist Wizard](/tools/compliance-checklist/)** — Get a personalised compliance checklist and score based on your role (provider, deployer, GPAI developer) and AI system type. Covers 30+ obligations with gap analysis. - **[AI Risk Classifier](/tools/ai-risk-classifier/)** — Answer 3-4 questions to determine whether your AI system falls under Annex I, Annex III, GPAI, transparency obligations, or minimal risk. - **[GPAI Checker](/tools/gpai-checker/)** — Determine whether your AI model qualifies as GPAI and which obligation tier applies: standard, systemic risk (>10²⁵ FLOPs), or open-source reduced obligations. - **[Deadline Calculator](/tools/deadline-calculator/)** — Find your specific compliance deadline based on system type, including post-Omnibus 2026 extensions. - **[Sanction Estimator](/tools/sanction-estimator/)** — Calculate your maximum potential fine based on violation type and global annual turnover. - **[DORA + AI Act Overlap Detector](/tools/dora-ai-overlap/)** — For financial entities subject to both DORA and the AI Act, identify where ICT and AI obligations converge. - **[Conformity Assessment Selector](/tools/conformity-selector/)** — Determine whether your high-risk AI system requires self-assessment (Annex VI) or third-party assessment (Annex VII). All tools reflect the EU AI Act as amended by the Digital Omnibus 2026. For a complete compliance checklist covering all 12 high-risk AI obligations, see the [Compliance Checklist →](/compliance-checklist/) -------------------------------------------------------------------------------- ## EU AI Act Sanction Estimator — Calculate Your Maximum Fine URL: https://www.regulation-ai.eu/en/tools/sanction-estimator/ ## EU AI Act sanction tiers | Violation | Max fine (large org) | Max fine (SME/startup) | |---|---|---| | **Prohibited practices** (Art. 5) | €35,000,000 or **7%** of global annual turnover | Lower of the two amounts | | **High-risk AI non-compliance** (Chapters III & V) | €15,000,000 or **3%** of global annual turnover | Lower of the two amounts | | **Incorrect/misleading information** to authorities | €7,500,000 or **1%** of global annual turnover | Lower of the two amounts | ## Estimating your exposure For a large organisation with €1 billion global annual revenue: - Prohibited practice violation: up to **€70,000,000** (7% > €35M absolute cap) - High-risk AI non-compliance: up to **€30,000,000** (3% > €15M absolute cap) For a mid-market company with €50 million global annual revenue: - Prohibited practice violation: up to **€35,000,000** (cap applies — 7% = €3.5M, so cap applies; wait, for SME the LOWER applies — €3.5M) - High-risk AI non-compliance: up to **€1,500,000** (3% of €50M = €1.5M, lower than €15M cap) **Key insight for SMEs:** The "lower amount" rule significantly reduces SME exposure. A startup with €5M revenue faces a maximum of €350,000 for a prohibited practice (7% of €5M), not €35M. ## Stacking with GDPR and NIS2 AI systems often process personal data and may be deployed in critical sectors. Fines can stack: - **GDPR:** Up to €20M or 4% global annual turnover for personal data violations - **NIS2:** Member state fines, typically up to €10M or 2% of global revenue for essential entities - **AI Act:** As above A biometric identification system deployed without proper consent could simultaneously trigger all three. Total maximum exposure for a large organisation across all three: **€70M (AI Act) + €20M (GDPR) + €10M (NIS2)**. To reduce your exposure, complete the [Compliance Checklist →](/compliance-checklist/) and ensure all high-risk AI obligations are documented and implemented before your deadline. -------------------------------------------------------------------------------- ## Commission Guidelines on the AI Act Transparency Obligations (Article 50) URL: https://www.regulation-ai.eu/en/transparency-obligations/guidelines/ > **What this page is.** A reader's guide to the Commission's Article 50 guidelines — what document it is, what weight it carries, and what a compliance team should actually do with it. For the obligations themselves, see the [Article 50 transparency pillar](/en/transparency-obligations/). On **20 July 2026** the European Commission published guidelines on the transparency obligations of Article 50 of Regulation (EU) 2024/1689. The document is referenced **C(2026) 5054 final**; its annex carries the longer title *Guidelines on the implementation of the transparency obligations for certain AI systems under Article 50 of Regulation (EU) 2024/1689 (the 'AI Act')*. They landed **thirteen days** before Article 50 entered into application on 2 August 2026. ## What the guidelines are — and are not | | | |---|---| | **Instrument** | Commission guidelines — interpretive, not legislative | | **Reference** | C(2026) 5054 final, 20 July 2026 | | **Subject** | Article 50 of Regulation (EU) 2024/1689 | | **Addressed to** | National competent authorities, providers, deployers | | **Binding?** | No. Only the Court of Justice can bind on interpretation | | **Changes the text?** | No. Article 50 is unchanged | The distinction matters more here than it usually does. Article 50 is enforced by **27 national market surveillance authorities**, each applying the same sentence independently, and the Commission has no direct enforcement power over anyone but general-purpose AI model providers. Guidelines are the mechanism by which the Commission tries to keep 27 readings from diverging. Non-binding does not mean inconsequential: an authority opening an inquiry will start from them, and a company whose design departs from them will be asked why. ## Why they arrived when they did The sequence is worth stating plainly, because it explains why so many programmes were built without them: | Date | Event | |---|---| | June 2026 | Code of Practice on Transparency of AI-generated Content published | | 24 July 2026 | Regulation (EU) 2026/1744 (Digital Omnibus on AI) published in the Official Journal | | 20 July 2026 | **Guidelines on Article 50 published — C(2026) 5054 final** | | 27 July 2026 | Digital Omnibus enters into force | | **2 August 2026** | **Article 50 enters into application** | | 2 December 2026 | Machine-readable marking grace period closes for pre-existing generative systems | Anyone who scoped their Article 50 work in the first half of 2026 did so without the Commission's stated position on the exemptions. That is not a reason to redo the work; it is a reason to **re-read it against the guidelines** before an authority does. ## What the guidelines address The guidelines follow the structure of the article itself, covering each of the four substantive obligations and the conditions attaching to them: - **Art. 50(1) — systems interacting with natural persons.** The scope of the provider's design duty, and the boundaries of the "obvious to a reasonably well-informed, observant and circumspect person" exemption. - **Art. 50(2) — machine-readable marking of synthetic content.** What "effective, reliable, robust and interoperable" means in practice for providers of generative systems, including general-purpose AI systems, and where the assistive-editing exemption stops. - **Art. 50(3) — emotion recognition and biometric categorisation.** The deployer's duty to inform exposed persons, and its interaction with the GDPR, which Article 50(3) expressly incorporates. - **Art. 50(4) — deepfakes and public-interest text.** The deployer's disclosure duty, the editorial-responsibility exemption for text, and the proportionate-disclosure regime for artistic, creative, satirical and fictional works. - **Art. 50(5) — how disclosure is presented.** Clear and distinguishable, at the latest at the time of first interaction or exposure, and consistent with accessibility requirements. That last point is the one most likely to produce enforcement in the first cycle, because it is the only one that can be assessed from the outside without any access to a company's systems. A regulator can open your product and see whether the notice is there. ## What to do with them 1. **Re-read your disclosure design against Art. 50(5), first.** Presentation is externally auditable in a way that internal marking pipelines are not. A notice buried behind a menu, in a footer, or in terms of service does not meet "clear and distinguishable at the latest at the time of first interaction". 2. **Re-test your obviousness argument.** If you concluded that no disclosure was needed because the AI nature was obvious, that judgement was made before the Commission stated where the bar sits. Document the reasoning again, against the guidelines. 3. **Separate provider duties from deployer duties in writing.** Paragraphs 1–2 and 3–4 land on different legal entities, frequently inside the same group. See [providers vs deployers](/en/providers-vs-deployers/). 4. **Date every generative system against 2 August 2026.** The 2 December 2026 grace period is available only for systems already on the EU market before that date, and only for the Art. 50(2) marking duty. 5. **Decide on the Code of Practice.** Sign it, or record why your own method meets the same standard. A documented decision either way is worth more than an undocumented one. 6. **Identify your market surveillance authority** in each Member State where you operate — the [national implementation tracker](/en/national-implementation/) records the designations. ## What the guidelines do not do They do not defer anything. The Digital Omnibus deferred the **high-risk** regime — Annex III to 2 December 2027, Annex I to 2 August 2028, national sandboxes to 2 August 2027 — and left Article 50 exactly where it was. Reading the omnibus as a general reprieve is the most expensive misreading available right now, because the Regulation's broadest obligation is live, carries a **€15 million or 3%** ceiling under Article 99(4), and applies whatever risk tier your system occupies. For what the omnibus did and did not move, see the [Digital Omnibus analysis](/en/omnibus/) and the [changes to Regulation (EU) 2024/1689](/en/changes/). ## Official sources - European Commission — [Guidelines on transparency obligations for providers and deployers of certain AI systems](https://digital-strategy.ec.europa.eu/en/library/guidelines-transparency-obligations-providers-and-deployers-ai-systems), 20 July 2026 (C(2026) 5054 final) - European Commission — [Transparency obligations under Article 50 of the AI Act (FAQ)](https://digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act) - European Commission — [Code of Practice on Transparency of AI-generated Content](https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content) - European Commission — [Commission starts enforcing AI Act rules and new transparency requirements on 2 August](https://digital-strategy.ec.europa.eu/en/news/commission-starts-enforcing-ai-act-rules-and-new-transparency-requirements-2-august) - Regulation (EU) 2024/1689 — [Article 50](/en/articles/article-50/), [Article 99](/en/articles/article-99/) *Editorial, not legal advice. This page describes the status and structure of the Commission's guidelines; for their operative text, read the official document linked above.* -------------------------------------------------------------------------------- ## EU AI Act Transparency Obligations (Art. 50) — Chatbots, Deepfakes & Synthetic Content URL: https://www.regulation-ai.eu/en/transparency-obligations/ > **Applies now.** Article 50 entered into application on **2 August 2026** and is enforced by national market surveillance authorities. The Commission published its interpretive [guidelines on the Article 50 transparency obligations](/en/transparency-obligations/guidelines/) on 20 July 2026. One deadline is still ahead: machine-readable marking of pre-existing generative systems closes on **2 December 2026**. Article 50 of Regulation (EU) 2024/1689 requires providers and deployers of certain AI systems to tell people when they are dealing with AI. It is **risk-independent** — it applies whatever tier your system sits in — which makes it the broadest-reaching obligation in the Regulation. It has four substantive paragraphs: **two on providers, two on deployers**, with a ceiling of **€15 million or 3% of worldwide turnover** under Article 99(4). ## The four obligations at a glance | Paragraph | Obligation | Falls on | Status | |---|---|---|---| | **Art. 50(1)** | Systems interacting with people must disclose they are AI | Provider | Applies since 2 Aug 2026 | | **Art. 50(2)** | Synthetic audio, image, video or text marked in a machine-readable format | Provider | Applies since 2 Aug 2026 — grace period to 2 Dec 2026 for systems already on the market | | **Art. 50(3)** | People exposed to emotion recognition or biometric categorisation must be informed | Deployer | Applies since 2 Aug 2026 | | **Art. 50(4)** | Deepfakes, and AI text published to inform the public on matters of public interest, must be disclosed | Deployer | Applies since 2 Aug 2026 | Two further paragraphs govern how the duties are discharged rather than adding new ones: **Art. 50(5)** fixes the manner and timing of the information, and **Art. 50(6)** confirms that none of this displaces the high-risk requirements of Chapter III. **The provider/deployer split is where most programmes go wrong.** Paragraphs 1 and 2 are design-stage duties on whoever places the system on the market. Paragraphs 3 and 4 are use-stage duties on whoever puts it into service. A marketing agency using a third-party video tool is a deployer and owes the deepfake disclosure itself — it cannot rely on the provider having marked the output. If you are unsure which you are, [providers vs deployers](/en/providers-vs-deployers/) settles it. --- ## Who falls under Art. 50 (and not under the high-risk regime) The AI Act is tiered. Most AI systems deployed today are not high-risk under Annex III or Annex I; they land in one of two lighter categories: - **Transparency obligations only (Art. 50)** — chatbots, generative systems, deepfake tools, emotion recognition and biometric categorisation. - **Minimal risk** — spam filters, AI in games, recommendation systems: voluntary codes of conduct only. The distinction that matters is that **transparency-only systems require disclosure, not conformity assessment, technical documentation or CE marking**. The burden is far lower — but it is live today, whereas the high-risk regime is not. Working out which tier you occupy is the first step; the [AI risk classifier](/en/tools/ai-risk-classifier/) walks the Annex III categories. --- ## Art. 50(1) — Systems that interact with people **Provider duty.** Any AI system designed to interact directly with natural persons must be built so that those persons are informed they are interacting with an AI system. **Scope.** Customer service bots, virtual assistants, AI phone agents, conversational AI embedded in social media, AI-powered support chat, avatars and agentic interfaces. If a human-facing interface uses a language model to conduct dialogue, Art. 50(1) applies. **Exemption 1 — obviousness.** No disclosure is required where it is obvious to a *reasonably well-informed, observant and circumspect* person that they are interacting with an AI. That is a high bar. Implicit UI cues alone are unlikely to clear it where a user could reasonably believe they are talking to a human. **Exemption 2 — law enforcement.** Systems authorised by law to detect, prevent, investigate or prosecute criminal offences, subject to safeguards for third-party rights. --- ## Art. 50(2) — Machine-readable marking of synthetic content **Provider duty.** Providers of AI systems — including general-purpose AI systems — that generate synthetic audio, image, video or text must ensure the outputs are marked in a **machine-readable format** and detectable as artificially generated or manipulated. The technical solution must be effective, reliable, robust and interoperable as far as technically feasible. **Scope.** Text-to-image and text-to-video generators, voice cloning systems, audio synthesis, and AI writing systems producing output at scale. **This is the obligation with a grace period.** Generative systems **already placed on the EU market before 2 August 2026** have until **2 December 2026** to comply with the marking duty. A system launched on or after 2 August 2026 has no grace period and must mark from day one. Record the evidence for your placing-on-the-market date — it is the fact that decides which regime you are in. **Exemption.** Systems performing an assistive function for standard editing, or that do not substantially alter the input data provided by the deployer or its semantics. The Commission's **Code of Practice on Transparency of AI-generated Content**, published in June 2026, is recognised as an adequate means of demonstrating compliance with the marking duty. Roughly 190 organisations had signed by the end of July 2026. Signing confers no legal immunity, but a signatory implementing the Code has a documented, Commission-recognised route; a non-signatory must construct and defend its own. --- ## Art. 50(3) — Emotion recognition and biometric categorisation **Deployer duty.** Deployers of an emotion recognition system or a biometric categorisation system must inform the natural persons exposed to it of the operation of the system, and process personal data in accordance with the GDPR and related instruments. **Emotion recognition** covers systems that detect, classify or score emotional or psychological states — engagement, stress, anger, deception — from facial expression, voice, physiological signals or behaviour. Typical cases: HR interview analysis, call-centre sentiment monitoring, retail response tracking. **Biometric categorisation** covers systems inferring characteristics from biometric data. Where the inference concerns sensitive attributes — race or ethnic origin, political opinions, trade union membership, religious or philosophical beliefs, sex life or sexual orientation — the practice is **prohibited outright under Art. 5**, not merely subject to disclosure. See [prohibited practices](/en/prohibited-practices/): where a system is banned, transparency is beside the point. **Not covered.** Systems detecting physiological states purely for safety or medical purposes — drowsy-driver detection that triggers an alert without inferring or retaining emotional state. The carve-out is narrow: a system repurposed for profiling loses it. Where the system is *also* high-risk under Annex III — emotion recognition in employment or education is — the full high-risk obligations stack on top from 2 December 2027. --- ## Art. 50(4) — Deepfakes and AI-generated text on matters of public interest **Deployer duty**, in two limbs. **Deepfakes.** A deployer of an AI system that generates or manipulates image, audio or video content constituting a deep fake must disclose that the content has been artificially generated or manipulated. The disclosure is for the audience: visible for image and video, audible for audio — not metadata alone. **Public-interest text.** A deployer publishing AI-generated or AI-manipulated text *for the purpose of informing the public on matters of public interest* must disclose it. This limb is narrower than it is often read: it targets published informational text, not internal drafting or marketing copy. **Exemptions.** - **Editorial review** — the text limb does not apply where the content has undergone human review or editorial control and a natural or legal person holds editorial responsibility for the publication. - **Artistic, creative, satirical or fictional works** — the deepfake disclosure is limited to what is appropriate, presented in a way that does not hamper the display or enjoyment of the work. - **Law enforcement**, where authorised by law. Documenting intent matters for the artistic exemption: an authority will assess whether the artificial nature was genuinely apparent in context. --- ## Art. 50(5) — How the disclosure must be presented This paragraph is where enforcement will bite, because it is the one that turns a policy into an interface change. The information required by paragraphs 1 to 4 must be given to the persons concerned: - in a **clear and distinguishable** manner, - **at the latest at the time of the first interaction or exposure**, - in conformity with the applicable accessibility requirements. In practice that excludes burying the notice in terms of service, in a page footer, or behind a menu option on an online interface. For a chatbot, the disclosure belongs at the opening of the conversation. For a deepfake video, at the point of exposure — not in the description below it. --- ## Practical compliance steps by system type | System type | Obligation | Paragraph | Responsible party | |---|---|---|---| | Chatbot, virtual assistant, AI phone agent | Disclose AI interaction at start of session | 50(1) | Provider (design) | | Text-to-image / video / voice generator | Machine-readable mark on every output | 50(2) | Provider | | Large-scale AI text generation | Machine-readable mark on output | 50(2) | Provider | | Emotion recognition (HR, call centre, retail) | Inform the persons exposed | 50(3) | Deployer | | Biometric categorisation (non-prohibited) | Inform the persons exposed | 50(3) | Deployer | | Deepfake image / audio / video published | Visible or audible "AI-generated" label | 50(4) | Deployer | | AI text published to inform the public | Disclose artificial generation | 50(4) | Deployer | Deployers carry their obligations independently of whether the provider has met its own. A deployer cannot rely on the provider's marking as a substitute for its own disclosure. --- ## Relationship with the GDPR Article 50 is legally independent of GDPR Article 22 on automated individual decision-making. The same system can trigger both. A chatbot used as the first stage of a loan application must: 1. disclose it is an AI system at the start of the conversation — Art. 50(1); 2. if it makes or meaningfully contributes to a solely automated decision with legal or similarly significant effects, give the data subject the GDPR Art. 22 rights: not to be subject to the decision, to human review, and to an explanation. Art. 50(3) also expressly requires emotion recognition and biometric categorisation deployers to process personal data in accordance with the GDPR — the two instruments are stitched together at that point rather than merely running in parallel. Organisations deploying AI in financial services, insurance or HR should map both in the same review. See [AI Act vs GDPR](/en/ai-act-vs-gdpr/) for the full interaction. --- ## Fines for non-compliance Breaches of the Article 50 transparency obligations fall under **Article 99(4)**: up to **€15 million or 3% of total worldwide annual turnover** for the preceding financial year, whichever is higher. | Breach | Ceiling | Enforced by | |---|---|---| | Prohibited practices (Art. 5) | €35M or **7%** of worldwide turnover | National market surveillance authorities | | **Article 50 transparency** | **€15M or 3%** of worldwide turnover | National market surveillance authorities | | GPAI model obligations (Art. 101) | €15M or 3% of worldwide turnover | European Commission / AI Office | | Incorrect or misleading information to authorities | €7.5M or 1% of worldwide turnover | National authorities / Commission | The ceiling is *the higher* of the fixed sum and the percentage; above roughly €500 million of turnover the percentage is always the operative figure. For SMEs and start-ups Article 99(6) caps the fine at the *lower* of the two. Full tiering on the [penalties page](/en/penalties/). Enforcement rests with the **national market surveillance authorities** designated under Art. 74, not with Brussels — the Commission's exclusive competence covers GPAI model providers only. Designation has been uneven across the 27 Member States; the [national implementation tracker](/en/national-implementation/) records where each one stands. --- ## Next steps - Read the [Commission's Article 50 guidelines](/en/transparency-obligations/guidelines/) — C(2026) 5054 final, 20 July 2026 — for how authorities are expected to interpret each paragraph. - Inventory **by function, not by risk tier**: every system that talks to a person, generates content, or infers emotions. - Date every generative system against 2 August 2026 to decide whether the 2 December 2026 grace period is available to you. - Use the [AI risk classifier](/en/tools/ai-risk-classifier/) to confirm whether transparency is your only obligation or whether the high-risk regime also applies from December 2027. - Check [what changed on 2 August 2026](/en/blog/eu-ai-act-enforcement-august-2026/) for the enforcement picture, and the [Digital Omnibus analysis](/en/omnibus/) for what Regulation (EU) 2026/1744 did and did not move. *Editorial, not legal advice.* --------------------------------------------------------------------------------