18. The EU AI Act in one pass

New to the field? Start with what AI governance is and which frameworks shape it.

How to read this chapter

This chapter teaches the Act; chapter 08 indexes it. Read this one for the logic of the law and chapter 08 for the full obligation rows. Every duty below names the artefact that evidences it and the stack layer that produces it.

The text is read against Regulation (EU) 2024/1689 ¹ as amended by Regulation (EU) 2026/1744, the Digital Omnibus on AI², and every date is stamped as of 2026-09-24. It is an engineer’s reading, not legal advice. The engineer builds the control and the evidence; counsel confirms that the obligation was read correctly (see regulatory translation). Mappings are illustrative, not a claim of conformity.

The stack layers named throughout are chapter 04’s five: 1 Govern-as-Code · 2 Inventory & Transparency · 3 Evals & Red Teaming as Evidence · 4 Runtime Controls & Observability · 5 Assurance & Continuous Compliance.

The Act and the Omnibus

The AI Act is a product-safety regulation with fundamental-rights goals. It is directly applicable in every Member State, it entered into force on 1 Aug 2024, and its duties switch on in stages¹². Four ideas carry the whole text:

1. A definition gate. Is the thing an AI system, a general-purpose AI (GPAI) model, or neither?
2. A risk ladder. Which rung does the system’s intended purpose put it on?
3. A set of operator roles. Which hat does your organisation wear for this system?
4. A timeline. From which date does each duty bite?

The Digital Omnibus on AI is Regulation (EU) 2026/1744 of 8 July 2026. It was published in the Official Journal on 24 July 2026 and entered into force on the third day after publication, 27 July 2026². It did not rewrite the Act. It moved the high-risk dates, added two prohibitions and made targeted changes that matter to an engineer (its GDPR counterpart is a separate proposal, covered in the GDPR side of the Digital Omnibus, chapter 19):

All of the above is in the amending text². Article numbers in the rest of the chapter are the post-Omnibus ones.

Scope and reach

Who is in scope

Article 2(1) reaches providers placing AI systems or GPAI models on the EU market, wherever they are established; deployers in the Union; providers and deployers in third countries whose system’s output is used in the Union; importers and distributors; product manufacturers placing AI with their product under their own name; authorised representatives of non-EU providers; and affected persons in the Union¹.

The reach is extraterritorial twice over: by placement and by output¹. The engineering consequence is a registry field. “Where is it hosted?” is not the scope question; “where is its output used?” is. An agent registry that records only the hosting region cannot answer it.

What counts as an AI system

Article 3(1) defines an AI system as “a machine-based system that is designed to operate with varying levels of autonomy and 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 that can influence physical or virtual environments”¹. The Commission’s guidelines read the sentence as seven elements (machine-based; autonomy; possible adaptiveness; objectives; inference; outputs; influence on environments) and note that not every element has to be present in both the building and the use phase³.

The decisive element is inference. The guidelines exclude systems based on rules defined solely by natural persons, and they name four families that compute but may still fall outside the definition: systems for improving mathematical optimisation, basic data processing, systems based on classical heuristics, and simple prediction systems³. The guidelines are not binding³.

For the engineer, scope is a recorded decision, not an assumption. Each registry entry carries ai_system: true | false and, when false, the element that fails and the reasoning. A “not an AI system” call with no reasoning attached is the first thing an authority will ask about. A GPAI model is a separate object with its own definition (Art. 3(63)), covered below; a model is not an AI system on its own and needs further components, such as a user interface, to become one (recital 97)¹. What “AI” means technically, beyond the legal test, is the subject of chapter 11.

What the Act excludes

The first six rows are in the original text¹; the Section B row is as amended². Union data protection law applies alongside the Act in every case (Art. 2(7)).

The risk ladder

The Act sorts AI systems by intended purpose onto four rungs, and puts GPAI models on a separate track. One system can sit on two rungs at once: an Annex III chatbot carries both the high-risk duties and the Art. 50 disclosure duty.

Dates are those of Art. 113 as amended¹².

Prohibited practices (Article 5)

Article 5 is a list of banned uses, not a risk assessment. If a practice is on the list, no mitigation makes it lawful. The list now has ten points¹²:

The two Omnibus points carry an engineering test. Placing such a generator on the market is prohibited only where that output is its intended purpose, or where the output is “a reasonably foreseeable and reproducible outcome” and the system lacks “reasonable and adequate technical safety measures” to prevent it and correct observed misuse; use is prohibited only where the deployer uses it for that purpose². The evidence that the safeguard holds is therefore part of the legal test. The Commission’s guidelines on the original prohibitions are non-binding⁴. The scraping ban in point (e) has a data protection precedent in the Clearview AI case.

For most organisations Art. 5 is two controls: a denylist of prohibited purposes evaluated at intake (Policy Card), and for generative systems an output Runtime Guardrail tested by an Adversarial Red-Team Suite. Both leave records a regulator can read. Breaches sit in the highest fine tier (see “Penalties”).

High-risk through products (Annex I)

A system is high-risk under Art. 6(1) when both conditions hold: it is a safety component of a product, or is itself a product, covered by the Union harmonisation legislation in Annex I; and that product must undergo a third-party conformity assessment under that legislation¹. Section A of Annex I covers products such as toys, lifts, radio equipment, medical devices and in vitro diagnostics; Section B covers sectoral regimes such as civil aviation and vehicles¹.

The Omnibus narrowed the route². A safety component must now have the intended purpose of preventing or mitigating risks to health and safety, or be one whose failure endangers them (Art. 3(14)). AI used solely for user assistance, performance optimisation, efficiency, automation, convenience or quality control is not a safety component unless its failure would endanger health and safety (Art. 6(1a), 6(1b)). A third-party assessment required only for non-safety reasons, such as radio spectrum, does not count (Art. 6(1c)). Machinery moved to Section B, and delegated acts due by 2 Aug 2027 may limit duties where Section A law already gives equivalent protection (Art. 2(13)). The Annex I route applies from 2 Aug 2028².

High-risk through use (Annex III)

Under Art. 6(2), Annex III lists eight areas. A system whose intended purpose falls in one of them is high-risk unless the Art. 6(3) filter takes it out¹:

The Commission can add use cases to Annex III by delegated act (Art. 7)¹, so the intake classifier’s Annex III table is data with a version, not a hard-coded list. What point 5 guards against is visible in the Dutch childcare-benefits case.

The Annex III filter and the profiling override

Under Art. 6(3), an Annex III system is 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. The filter applies when at least one of four conditions holds¹:

1. the system performs a narrow procedural task;
2. it improves the result of a previously completed human activity;
3. it detects decision-making patterns or deviations without replacing or influencing the completed human assessment without proper human review;
4. it performs a preparatory task to an assessment relevant to an Annex III use case.

One override beats all four: an Annex III system that profiles natural persons is always high-risk¹. A provider relying on the filter must document its assessment before placing the system on the market, register it (Art. 6(4), Art. 49(2)), and hand the documentation to authorities on request¹. The Omnibus trimmed that registration record, deleting the summary of grounds and the list of Member States from Annex VIII, Section B².

The Commission’s classification guidelines, with practical examples, were due by 2 Feb 2026 under Art. 6(5). A draft was published on 19 May 2026, with a targeted consultation open until 23 July 2026; as of 2026-09-24 the Commission’s page still presents them as a draft⁵⁶. Until they are final, the engineer’s defence is a good record, not a good argument.

This record is the output of the intake and classification workflow and lives in Layer 2 (Inventory & Transparency); the rule that computes it lives in Layer 1.

Transparency cases (Article 50)

Article 50 is often called the “limited risk” rung. It applies to any AI system that fits one of its cases, whatever else the system is¹:

The information must reach people at the latest at first interaction or exposure (Art. 50(5))¹. The article has applied since 2 Aug 2026; generative systems already on the market before that date have until 2 Dec 2026 to mark outputs (Art. 111(4))². The final Code of Practice on Transparency of AI-generated Content (10 June 2026) has a provider section on marking and a deployer section on labelling, and the Commission and the AI Board confirmed it as an adequate voluntary tool; the Commission published its guidelines on the Art. 50 transparency obligations on 20 July 2026, after a draft of 8 May 2026⁹¹⁴. Law outside the Act also reaches synthetic media: see deepfakes and synthetic media in chapter 20.

Minimal risk

Everything else is minimal risk. The Act asks nothing specific of it beyond AI literacy (Art. 4) and invites voluntary codes of conduct (Art. 95)¹. “Minimal” is a legal category, not a risk verdict: data protection, consumer, product-liability and anti-discrimination law still apply (see existing law and privacy and AI), and your own risk management may rate a minimal-risk system as high for your organisation.

General-purpose AI models

Model, system and the indicative criterion

A GPAI model is an AI model that “displays significant generality and is capable of competently performing a wide range of distinct tasks” and can be integrated into a variety of downstream systems, excluding models used for research, development or prototyping before they are placed on the market (Art. 3(63))¹. A GPAI system is an AI system based on such a model (Art. 3(66))¹. The Commission’s guidelines give an indicative criterion: training compute above 10^23 FLOP and the ability to generate language (text or audio), text-to-image or text-to-video⁷.

Duties of every GPAI provider

The duties and their details are in the Act¹; the chapter 08 rows for Art. 53 and Art. 55 carry the dates and the authority. The copyright law behind the Art. 53(1)(c) policy is in chapter 20 (copyright policy and TDM opt-outs).

Systemic risk: threshold, notification, designation

A GPAI model has systemic risk if it has high-impact capabilities, or if the Commission designates it on the Annex XIII criteria (Art. 51(1))¹. High-impact capabilities are presumed above 10^25 FLOP of cumulative training compute, a threshold the Commission can amend (Art. 51(2), 51(3))¹. The provider must notify the Commission within two weeks of meeting the threshold or knowing it will, and may argue that the model exceptionally presents no systemic risk (Art. 52)¹.

The engineering artefact is a compute ledger: cumulative training FLOP per model lineage, with the estimation method, and an alert when planned compute will cross the threshold, because the two-week clock can start before training ends.

Duties for models with systemic risk

On top of Arts. 53 and 54, the provider must evaluate the model with state-of-the-art protocols including adversarial testing; assess and mitigate systemic risks at Union level; track, document and report serious incidents to the AI Office without undue delay; and ensure adequate cybersecurity for the model and its physical infrastructure (Art. 55(1))¹. The artefacts are the eval gate and red-team suite, a systemic-risk register, the incident pipeline on the Commission’s reporting template (see chapter 08) and weight-security controls.

Open-source carve-outs and their limits

A model released under a free and open-source licence, with its weights, architecture and usage information public, is exempt from Art. 53(1)(a) and (b) and from the authorised-representative duty (Arts. 53(2), 54(6))¹. The exemption never covers a systemic-risk model, and the copyright policy and training summary still apply¹. Monetisation defeats it: the guidelines treat dual licensing, paid support without which the model cannot be used, and exclusive paid hosting as monetisation⁷. The Omnibus keeps GPAI models inside the Art. 25(4) written-agreement duty even when released openly².

When a fine-tuner becomes a GPAI provider

A modifier becomes the provider of a new GPAI model only if the change is significant for generality, capabilities or systemic risk. The guidelines’ indicative criterion is modification compute above one third of the original training compute (or, if unknown, a third of 10^25 FLOP for a systemic-risk original and of 10^23 FLOP otherwise), and the modifier’s Art. 53(1) duties are then limited to the modification and its data; Art. 54 applies, and where the original is a systemic-risk model the modified model is presumed to have systemic risk, so the modifier notifies the Commission (Art. 52) and meets the Art. 55 duties⁷. Keep this test apart from Art. 25: fine-tuning a model changes GPAI-provider status; changing a system’s intended purpose into Annex III changes high-risk provider status. Two tests, two objects, two registry fields.

The Code of Practice and enforcement

The General-Purpose AI Code of Practice was published on 10 July 2025. Its Transparency and Copyright chapters apply to all GPAI providers, its Safety and Security chapter only to systemic-risk models, and the Commission and the AI Board confirmed it as an adequate voluntary tool⁸. Providers may rely on it until a harmonised standard exists; non-signatories must show adequate alternative means (Arts. 53(4), 55(2))¹. GPAI obligations have applied since 2 Aug 2025, Commission fines under Art. 101 since 2 Aug 2026, and models placed on the market before 2 Aug 2025 must comply by 2 Aug 2027 (Art. 111(3))¹⁷.

High-risk requirements (Articles 8 to 15)

Article 8 requires a high-risk system to meet Section 2 of Chapter III, taking into account its intended purpose and the state of the art¹. The requirements are design duties on the provider. In one table, with the artefact that evidences each:

The requirements are in the Act¹; the SME and SMC form in Art. 11(1) is an Omnibus addition². Chapter 14 builds the technical file from pipeline records. Art. 14(5) adds two-person verification before acting on a remote biometric identification, with exceptions in law enforcement, migration, border control and asylum¹; see designing human oversight and the Human-in-the-loop Gate. A high-risk system within the Cyber Resilience Act that fulfils the conditions of its Article 12(1) is deemed to meet the Art. 15 cybersecurity requirement (Art. 42(3))², so one security evidence pack can serve both regimes.

Provider duties beyond the requirements

Article 16 and the quality management system (Article 17)

Article 16 is the umbrella for the provider’s duties: the requirements, name on the system, QMS, documentation, logs, conformity assessment, declaration, CE marking, registration, corrective action, cooperation and accessibility¹. Chapter 08 breaks it out article by article.

The QMS must be documented as written policies, procedures and instructions covering at least 13 aspects, from a compliance strategy with change management, design control, testing and data management to the Art. 9 risk system, post-market monitoring, incident reporting, record-keeping and an accountability framework (Art. 17(1))¹. It is proportionate to the provider’s size, which the Omnibus now spells out for SMEs and SMCs without lowering the required rigour, and SMEs without partner or linked enterprises may meet certain elements in a simplified way (Arts. 17(2), 63)². Read as an engineer, the QMS is the pipeline plus its records: versioned policies, change control and the gates that run on every release. The Article 17 standard is published but not cited in the Official Journal, and ISO/IEC 42001 is not the Article 17 QMS (see chapter 08, and chapter 22 on harmonised standards and the presumption of conformity). Where the Act and the voluntary instruments overlap, and where they do not, is laid out topic by topic in ISO 42001 vs EU AI Act and NIST AI RMF vs EU AI Act.

Conformity assessment, declaration, marking and registration

Annex III points 2 to 8 use internal control (Annex VI) with no notified body; biometrics (point 1) may use internal control only where harmonised standards or common specifications were applied in full, and otherwise need a notified body (Annex VII) (Art. 43(1), 43(2))¹. Annex I, Section A products follow the sectoral procedure, which now expressly includes the Section 2 requirements and a QMS assessment; their notified bodies must apply for designation under the Act by 28 Jan 2028 (Art. 43(3))². A substantial modification triggers a new assessment (Art. 43(4))¹.

The provider then draws up the EU declaration of conformity (Art. 47), affixes the CE marking (Art. 48) and registers the system in the EU database (Arts. 49, 71)¹. Documentation is kept for 10 years (Art. 18) and logs for at least six months (Art. 19)¹. Each is an output of the pipeline: the declaration is generated from the evidence that the gates passed, and the registration record is pushed from the registry.

Post-market monitoring and serious incidents (Articles 72 and 73)

The provider runs a post-market monitoring system that actively collects and analyses performance data, including from deployers, to evaluate continuous compliance (Art. 72(1), 72(2))¹. Its plan is part of the Annex IV documentation, and the Omnibus replaced the overdue implementing act with Commission guidance and a template due by 2 Sep 2027 (Art. 72(3))². Continuous Assurance Telemetry is the monitoring system; the plan is its versioned configuration.

Serious incidents are reported to the market surveillance authority immediately after a causal link, or its reasonable likelihood, is established, and in any event on the Art. 73 clocks, each counted from when the provider (or deployer) becomes aware of the incident: 15 days in general, two days for a widespread infringement or a serious and irreversible disruption of the management or operation of critical infrastructure (Art. 3(49)(b)), and 10 days after a death¹. Chapter 08 holds the reporting-clock table; chapter 17 treats incidents end to end. Providers of high-risk systems under the AI Office’s direct competence report to the AI Office instead (Art. 75(1a))².

Who you are in the value chain

The EU operator roles

The Act binds operators (Art. 3(8)): providers, product manufacturers, deployers, authorised representatives, importers and distributors¹. The GPAI chapter adds the GPAI provider and the downstream provider. The table puts each role in the engineer’s terms: what it produces and what it must collect from someone else.

The duties are in Arts. 16 to 27 and 53 to 55¹. The affected person is in scope (Art. 2(1)(g)) as a holder of protections, not duties¹.

Article 25: when someone else becomes the provider

A distributor, importer, deployer or other third party becomes the provider of a high-risk system, with all of the Art. 16 duties, in three cases (Art. 25(1))¹:

1. it puts its name or trademark on a high-risk system already on the market, subject to contracts allocating the obligations otherwise;
2. it makes a substantial modification to a high-risk system that stays high-risk;
3. it changes the intended purpose of a system that was not high-risk, including a general-purpose AI system, so that it becomes high-risk.

A substantial modification is an unplanned change after placing on the market that affects compliance or changes the assessed intended purpose (Art. 3(23))¹. When a trigger fires, the initial provider stops being the provider of that system but must cooperate with the new one; the Omnibus now spells out that this means documentation sufficient to assess compliance, known limitations and failure modes, and targeted technical access for testing, unless the initial provider had clearly excluded any change into a high-risk system (Art. 25(2))². High-risk providers and their suppliers of systems, models, tools and components must fix the information and access needed in a written agreement (Art. 25(4)), and breaches of both paragraphs are now fined in the middle tier (Art. 99(4)(da))².

In the pipeline the three triggers are detectable events: a white-label or brand change, a retrain that touches conformity, and a configuration change that moves intended_purpose into an Annex III value. Each should fire a role re-assessment and a Vendor / Model Due-Diligence Gate ticket (see third-party and procured AI).

Roles name tasks, not organisations

A role attaches to an activity on a specific system, not to a company. A bank is the provider of the credit model it built, the deployer of that model in its branches (“putting into service” includes own use, Art. 3(11)¹) and the deployer of a vendor’s chatbot. So the registry records roles per system, as a list: ["provider", "deployer"] for an in-house system, ["deployer"] for a procured one.

The same roles across regimes

The words differ across laws; the tasks rarely do. The mapping column is this chapter’s reading, not a legal equivalence.

Colorado’s law was signed on 14 May 2026 and its duties apply from 1 Jan 2027¹⁰. The Korean Act (version in force since 21 July 2026) reaches acts abroad that affect the Korean market or users and requires a domestic representative for foreign operators above decree thresholds (Arts. 4, 36)¹². The ISO/IEC 22989 list and its clause (5.19) are marked for verification¹³. See chapter 08 and AI laws worldwide for these regimes in context.

Deployer duties (Article 26)

Article 26 is the deployer’s list for high-risk systems. Broken into sub-duties, each has an artefact¹:

Financial institutions meet the monitoring and log duties through their financial-services governance rules¹. The deployer’s view of procured systems is developed in governing deployment.

Fundamental rights impact assessment (Article 27)

Who. Before deploying an Annex III system (except point 2, critical infrastructure), a FRIA is required from deployers that are bodies governed by public law or private entities providing public services, and from deployers of credit scoring (point 5(b)) and life and health insurance pricing (point 5(c))¹.

When. Before first use; the deployer may rely on earlier FRIAs or on the provider’s impact assessment in similar cases, and must update it when an element changes (Art. 27(2))¹.

What. The deployer’s processes that use the system; the period and frequency of use; the categories of people affected; the specific risks of harm to them, using the provider’s Art. 13 information; the human oversight measures; and the measures if risks materialise, including internal governance and complaint mechanisms (Art. 27(1)(a) to (f))¹.

Then. The deployer notifies the market surveillance authority of the results on the AI Office template (Art. 27(3))¹. After the Omnibus, it may cross-reference or include the relevant DPIA sections, and the template must allow for that (Art. 27(4), 27(5))². The duty applies from 2 Dec 2027 with the Annex III regime². Build it as FRIA-as-Code: a versioned record generated from the registry, the instructions for use and the DPIA, so an update is a diff, not a rewrite.

Explanation and notice to affected people

The right to explanation (Art. 86). A person subject to a deployer’s decision based on the output of an Annex III high-risk system (except point 2), which produces legal effects or similarly significant effects that the person considers adverse to their health, safety or fundamental rights, may obtain “clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken”¹. The right yields to exceptions in Union or national law and applies only where Union law does not already provide it¹, which is why it has to be read with GDPR rights on automated decisions (see privacy and AI).

The artefact is an explanation record per decision: system and model version, the inputs or reason codes behind the output, whether the output was determinative or advisory, and the human who decided; methods are in fairness and explainability, with what the right to explanation (Art. 86) asks of the content. On timing, Art. 86 sits in Chapter IX, which applies from 2 Aug 2026, but it has work to do only once Annex III systems are regulated from 2 Dec 2027. That is this chapter’s reading; confirm it with counsel (verify).

The other notices. Workers before workplace use (Art. 26(7)); people subject to Annex III decisions (Art. 26(11)); people exposed to emotion recognition or biometric categorisation (Art. 50(3)); and anyone facing a deep fake (Art. 50(4))¹. Any person may complain to a market surveillance authority (Art. 85), and whistleblowers reporting breaches of the Act are protected under Directive (EU) 2019/1937 (Art. 87)¹.

AI literacy and bias-detection data

AI literacy (Art. 4). Since 27 July 2026, providers and deployers must “take measures to support the development of AI literacy” of their staff and others operating or using AI systems on their behalf, considering their knowledge, the context of use and the people affected, without having to guarantee any specific level². It binds every provider and deployer on every rung. The artefact is a role-based literacy programme whose completion records are keyed to registry roles, so no one is rostered as an Art. 26(2) overseer without a current record.

Bias-detection data (Art. 4a). Providers of high-risk systems may exceptionally process special categories of personal data where strictly necessary for bias detection and correction, if other data (including synthetic or anonymised data) would not work, the data are pseudonymised, secured, access-controlled and never passed on, they are deleted once the bias is corrected, and the records of processing say why². Art. 4a(2) extends the basis to other AI systems and models and to deployers of high-risk systems, without creating a duty². The artefact is a controlled enclave with access logs and automatic deletion (see data governance across the stack).

Sandboxes and real-world testing

Sandboxes (Arts. 57 to 59). Each Member State must have at least one national AI regulatory sandbox operational by 2 Aug 2027, a date the Omnibus moved from 2 Aug 2026¹². The AI Office may run a Union-level sandbox for the systems under its direct competence, with priority for SMEs and SMCs, and a sandbox plan may include real-world testing². Art. 59 sets the conditions for further processing of personal data in a sandbox for public-interest systems¹.

Real-world testing (Arts. 60, 60a, 61). Providers may test Annex III systems, and after the Omnibus Annex I, Section A systems, in real-world conditions outside a sandbox². The conditions include a plan approved by the market surveillance authority, registration with a Union-wide identification number, a maximum of six months extendable by six, informed consent that is dated and documented, effective oversight, outputs that can be reversed, and Art. 73 reporting of serious incidents¹. Member States may allow testing of Annex I, Section B products under national frameworks (Art. 60a)². A real-world test is a production system with extra evidence: a plan as code, consent records, a reversal path and incident hooks.

Governance and enforcement

Who supervises what

Market surveillance follows the sector¹: product authorities for Annex I, Section A systems (Art. 74(3)), financial supervisors for regulated financial institutions (Art. 74(6)), and data protection or other designated authorities for biometrics in law enforcement, border management and justice and for Annex III points 6 to 8 (Art. 74(8)). The Annex XIV codes and the Art. 77 rules are Omnibus text².

The AI Office’s direct powers (Articles 75 and 75a to 75d)

The Omnibus made the AI Office exclusively competent for two groups of AI systems²: systems built on a GPAI model by the same provider or undertaking (except Annex I products, Annex III point 2, justice systems under point 8, and law-enforcement, border and financial systems under Art. 74(6)), and systems that are or sit inside designated very large online platforms or search engines. The competence covers providers, and deployers only within the same undertaking².

Articles 75a to 75d give the AI Office investigations, information requests, inspections, orders to give access and explanations and to retain data (Art. 75a); binding commitments (Art. 75b); non-compliance decisions with Art. 99 fines and periodic penalty payments of up to 5% of average daily income or worldwide annual turnover per day (Art. 75c); and rights of defence and publication of decisions (Art. 75d)². They sit in Chapter IX, which applies from 2 Aug 2026¹². If you build systems on your own GPAI model, your evidence store must answer Brussels as fast as a national authority.

Penalties

The tiers are in Arts. 99 and 101¹, with the Omnibus additions in Arts. 75c, 99(4)(da) and 99(6a)². Member States decide whether and how public bodies are fined (Art. 99(8))¹. Two of the factors authorities weigh are the degree of responsibility “taking into account the technical and organisational measures implemented” and whether the operator notified the infringement itself (Art. 99(7)(g), (h))¹. Your evidence is also your mitigation argument.

The post-Omnibus timeline

Other high-risk systems already on the market before the Chapter III date fall under the Act only if their design changes significantly after that date (Art. 111(2) as amended)². “Significant change in design” is therefore an event the pipeline should log, with the reasoning, every time a legacy system is modified.

What you can do this week

1. Add three fields to every registry entry: eu_roles (a list, per system), risk_rung with the article that put it there, and output_used_in_eu. Run Shadow-AI Discovery to find the systems that have no entry.
2. Write the classification decision record for every Annex III candidate, with the Art. 6(3) condition relied on and the profiling flag stated explicitly, and store it next to the system. The AI Act triage drafts one against the schema.
3. Gate the 2 Dec 2026 prohibitions. Put Art. 5(1)(ba) and (bb) in the intake denylist and add an adversarial suite for any image, video or voice generator to the eval gate before that date.
4. Read your vendor terms for Art. 25. Find the clause that excludes high-risk use and the written agreement under Art. 25(4); open a due-diligence ticket wherever a high-risk component has neither.
5. Test the Art. 50 surfaces that are already live. Check that every chat interface discloses AI use and every generator marks its output, and file the passing check as evidence.

Maps to: EU AI Act Arts. 2, 3, 4, 4a, 5, 6, 8 to 27, 43 to 50, 51 to 57, 60 to 61, 72 to 75d, 86, 99, 101, 111, 113 (as amended by Regulation (EU) 2026/1744) · GPAI Code of Practice · Code of Practice on Transparency of AI-generated Content · Colorado SB 26-189 · Texas HB 149 · Korea AI Basic Act · ISO/IEC 22989 · all five stack layers. Mappings are illustrative, not a claim of conformity.

Sources

1. [1] Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act), of 13 June 2024; OJ L, 2024/1689, 12.7.2024 (original text: Arts. 2, 3, 5 to 27, 43, 49 to 61, 64 to 75, 85 to 87, 99, 101, 111, 113; Annexes I, III, VIII). Publications Office of the EU (EUR-Lex). 2024-07-12. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng (verified: primary)
2. [2] Regulation (EU) 2026/1744 (Digital Omnibus on AI), of 8 July 2026, amending Regulations (EU) 2024/1689, 2018/1139 and 2023/1230; OJ L, 2026/1744, 24.7.2026; in force on the third day after publication (amended Arts. 2, 3(14), 4, 4a, 5, 6, 10, 11, 17, 25, 27, 42, 43, 50, 56, 57, 60, 60a, 63, 72, 75, 75a to 75d, 77, 99, 111, 113; Annexes I, VIII, XIV). Publications Office of the EU (EUR-Lex). 2026-07-24. https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng (verified: primary)
3. [3] Commission Guidelines on the definition of an artificial intelligence system established by Regulation (EU) 2024/1689 (seven elements; four out-of-scope families; non-binding; formal text C(2025) 5053 final). European Commission. 2025-02-06. https://digital-strategy.ec.europa.eu/en/library/commission-publishes-guidelines-ai-system-definition-facilitate-first-ai-acts-rules-application (verified: primary)
4. [4] Commission Guidelines on prohibited artificial intelligence practices, as defined by the AI Act (non-binding; authoritative interpretation reserved to the CJEU). European Commission. 2025-02-04. https://digital-strategy.ec.europa.eu/en/library/commission-publishes-guidelines-prohibited-artificial-intelligence-ai-practices-defined-ai-act (verified: primary)
5. [5] Draft Commission guidelines on the classification of high-risk AI systems (Art. 6; Annex I and Annex III sections; practical examples; draft for targeted consultation). European Commission. 2026-05-19. https://digital-strategy.ec.europa.eu/en/library/draft-commission-guidelines-classification-high-risk-ai-systems (verified: primary)
6. [6] Guidelines for providers and deployers of AI high-risk systems (policy page: classification guidelines still in draft, consultation open until 23 July 2026; application dates 2 Dec 2027 and 2 Aug 2028). European Commission. 2026. https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-high-risk-systems (verified: primary)
7. [7] Commission Guidelines on the scope of the obligations for providers of general-purpose AI models established by Regulation (EU) 2024/1689 (content approved 18 July 2025 by C(2025) 5045 final; formal text C(2025) 7719 final of 19 Nov 2025; paras. 65 to 68 on modifiers; 10^23 FLOP indicative criterion; one-third modification criterion; monetisation; notification within two weeks; fines from 2 Aug 2026). European Commission. 2025-11-19. https://digital-strategy.ec.europa.eu/en/library/guidelines-scope-obligations-providers-general-purpose-ai-models-under-ai-act (verified: primary)
8. [8] The General-Purpose AI Code of Practice (published 10 July 2025; Transparency, Copyright, and Safety and Security chapters; confirmed as an adequate voluntary tool). European Commission. 2025-07-10. https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai (verified: primary)
9. [9] Code of Practice on Transparency of AI-generated Content (final version 10 June 2026; provider marking and detection, deployer labelling; confirmed as an adequate voluntary tool; Art. 50 guidelines: draft 8 May 2026, final 20 July 2026). European Commission. 2026-06-10. https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content (verified: primary)
10. [10] SB26-189 Automated Decision-Making Technology (signed 14 May 2026; developer and deployer duties; covered technology from 1 Jan 2027; deployer records kept at least three years). Colorado General Assembly. 2026-05-14. https://leg.colorado.gov/bills/sb26-189 (verified: primary)
11. [11] Texas Responsible Artificial Intelligence Governance Act (HB 149), enrolled text (Sec. 552.001 definitions of developer and deployer). Texas Legislature (89R). 2025. https://capitol.texas.gov/tlodocs/89R/billtext/pdf/HB00149F.pdf (verified: primary)
12. [12] Framework Act on the Development of Artificial Intelligence and the Establishment of a Foundation for Trust (인공지능 발전과 신뢰 기반 조성 등에 관한 기본법), Act No. 21311 as amended 20 Jan 2026, version in force 21 Jul 2026 (Art. 2(7) to (9) roles; Art. 4 reach; Arts. 31 to 36 duties and domestic representative). Korea Ministry of Government Legislation (law.go.kr). 2026-07-21. https://www.law.go.kr/LSW/lsInfoP.do?lsiSeq=282791 (verified: primary)
13. [13] ISO/IEC 22989:2022, Artificial intelligence concepts and terminology (edition 1; AI stakeholder roles). ISO/IEC JTC 1/SC 42. 2022-07. https://www.iso.org/standard/74296.html (verified: primary)
14. [14] Guidelines on transparency obligations for providers and deployers of AI systems (Art. 50; final text after the draft of 8 May 2026; obligations apply from 2 Aug 2026). European Commission. 2026-07-20. https://digital-strategy.ec.europa.eu/en/library/guidelines-transparency-obligations-providers-and-deployers-ai-systems (verified: primary)