EU AI Act

The EU AI Act is product-safety law applied to software. It does not regulate AI as a technology; it regulates placing on the market and putting into service particular AI systems for particular purposes, and it allocates duties by the role you play in that supply chain. The two questions that decide almost everything are: which tier does this system fall in, and am I the provider or the deployer of it?

Two structural points before the detail. First, the obligations attach to intended purpose, not to model architecture. The same model can be minimal-risk in one product and high-risk in another. Second, the Act applies in phases running from February 2025 to August 2030, so “does the AI Act apply to us” has no single answer without a date attached.

Verify against the current text. This page is written from the Official Journal text of Regulation (EU) 2024/1689 as published on 12 July 2024, via the article-by-article explorer maintained by the Future of Life Institute. The Commission holds delegated powers to amend several thresholds and annexes (Articles 6(6) - (7), 7, 51(3), 97), and the Act contains its own review clauses. Before making a compliance decision, check the consolidated text on EUR-Lex and any Commission guidelines issued under Article 96.

The four tiers

“Limited risk” and “minimal risk” are descriptive labels, not defined terms in the enacting text. The operative distinction is that Article 50 imposes disclosure obligations on certain categories regardless of whether they are also high-risk, and everything not caught by Article 5, Article 6 or Article 50 carries no system-specific obligation under this Regulation.

Prohibited practices (Article 5)

Article 5(1) prohibits eight categories of AI practice. Rather than reproducing the legal text here (which contains precise qualifiers that change the meaning if paraphrased), the categories are summarised below. Read the full Article 5 text before making a compliance determination.

The qualifiers carry the weight. Several prohibitions turn on “significant harm”, on “materially distorting” behaviour, or on a decision being based solely on profiling. A system that informs rather than determines, or that a human reviews on independent evidence, may fall outside the prohibition and land in the high-risk tier instead. That is a different set of duties, not an absence of duties.

High-risk (Article 6)

Two independent routes in.

Route 1 - Article 6(1), embedded safety components. An AI system is high-risk where both: 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; and that product is required to undergo third-party conformity assessment under that legislation. This is the machinery, medical devices, lifts and similar route, and it applies irrespective of whether the AI system is placed on the market independently of the product.

Route 2 - Article 6(2), Annex III use cases. AI systems in the Annex III areas are high-risk:

The Article 6(3) derogation. An Annex III system may escape the high-risk classification if it poses no significant risk of harm and meets at least one of four conditions relating to the narrowness and independence of its role. Read the full Article 6 text for the precise conditions, because paraphrasing them changes the legal effect.

Two things constrain this. Notwithstanding the derogation, an Annex III system is always high-risk where it performs profiling of natural persons. And a provider relying on the derogation must document the assessment before placing the system on the market or putting it into service, is still subject to the registration obligation in Article 49(2), and must provide the documentation to national competent authorities on request. The derogation is a documented, reviewable position, not a self-declared exit.

Article 6(5) required the Commission, after consulting the Board and no later than 2 February 2026, to issue guidelines on the practical implementation of Article 6 with a comprehensive list of practical examples of high-risk and non-high-risk use cases. Check for those guidelines before finalising a borderline classification.

Transparency obligations (Article 50)

Four duties, split between providers and deployers, applying from 2 August 2026:

Article 50(2) is the one with real engineering consequences: it is a provider obligation on general-purpose AI systems as well as narrow ones, and “machine-readable” points at watermarking and content provenance rather than a visible label. Note the technical-feasibility and state-of-the-art qualifiers (the obligation is calibrated, not absolute), and that the information under paragraphs 1 to 4 must reach the person concerned clearly and distinguishably at the latest at the time of first interaction or exposure.

Providers versus deployers

A provider develops an AI system or has it developed and places it on the market or puts it into service under its own name or trademark. A deployer uses one under its own authority. Most organisations are deployers of someone else’s high-risk system and providers of their own internal tools. Article 25 can also turn a deployer into a provider, for instance by putting your own name on a system or making a substantial modification to it.

Provider duties for high-risk systems (Chapter III Section 2 requirements, Article 16 onwards): a risk management system across the lifecycle (Article 9); data and data governance requirements (10); technical documentation (11); automatic record-keeping (12); transparency and instructions for use enabling deployer compliance (13); human oversight designed into the system (14); accuracy, robustness and cybersecurity (15); a quality management system (17); document retention (18); retention of automatically generated logs (19); corrective action and duty to inform (20); conformity assessment (43), EU declaration of conformity (47), CE marking (48) and registration (49); and post-market monitoring (72) with serious incident reporting (73).

Deployer duties for high-risk systems (Article 26) are narrower but not trivial:

• take appropriate technical and organisational measures to use the system in accordance with the instructions for use;
• assign human oversight to natural persons with the necessary competence, training, authority and support;
• where the deployer controls input data, ensure it is relevant and sufficiently representative for the intended purpose;
• monitor operation; where the deployer has reason to consider that use in accordance with the instructions may present a risk under Article 79(1), inform the provider or distributor and the market surveillance authority without undue delay and suspend use; report serious incidents first to the provider, then importer or distributor and market surveillance authorities;
• retain automatically generated logs under the deployer’s control for a period appropriate to the intended purpose and at least six months, unless other Union or national law provides otherwise;
• where the deployer is an employer, inform workers’ representatives and affected workers before putting a high-risk system into service at the workplace;
• if a public authority: comply with registration obligations under Article 49 and, on finding the system is not registered in the EU database under Article 71, not use it and inform the provider or distributor;
• use the Article 13 information to carry out a data protection impact assessment where one is required under Article 35 GDPR or Article 27 of Directive (EU) 2016/680;
• inform natural persons subject to Annex III systems that make or assist decisions about them (Article 26(11));
• cooperate with competent authorities (Article 26(12)).

Two sector carve-outs are worth noting: financial institutions subject to internal governance requirements under Union financial services law satisfy the monitoring obligation by complying with those rules, and maintain logs as part of documentation kept under that law. Deployers of post-remote biometric identification for law enforcement face additional constraints in Article 26(10). These include ex-ante judicial or binding administrative authorisation, or authorisation without undue delay and no later than 48 hours, and annual reporting.

Separately, Article 27 requires a fundamental rights impact assessment for certain deployers of Annex III high-risk systems. Read it directly if you are a public body or provide banking or insurance services.

General-purpose AI models

Chapter V regulates GPAI models, distinct from AI systems, and has applied since 2 August 2025.

Baseline obligations, Article 53(1). Providers of any GPAI model must meet four categories of obligation: technical documentation, downstream provider information, copyright compliance, and training data transparency. The precise requirements reference Annexes XI and XII for the minimum content of documentation. See the full Article 53 for binding wording.

Open-source carve-out, Article 53(2). The documentation duties in 53(1)(a) and (b) do not apply to models released under a free and open-source licence permitting access, use, modification and distribution, where parameters including weights, architecture information and usage information are publicly available. The copyright policy and the training-content summary still apply. The carve-out does not apply to GPAI models with systemic risk.

Systemic risk threshold, Article 51. A GPAI model is classified as having systemic risk if it has high impact capabilities evaluated on appropriate technical tools and methodologies including indicators and benchmarks, or if the Commission decides - on its own initiative or after a qualified alert from the scientific panel - that it has equivalent capabilities or impact having regard to the Annex XIII criteria. Article 51(2) sets a rebuttable presumption:

That figure is a presumption, not a definition, and Article 51(3) empowers the Commission to amend both the thresholds and the benchmarks by delegated act to track algorithmic and hardware efficiency improvements. Do not treat 10^25 FLOP as a stable line.

Additional obligations for systemic-risk models, Article 55(1). Four additional duties apply: model evaluation using standardised protocols, systemic risk assessment and mitigation at Union level, serious incident tracking and reporting, and cybersecurity protection for the model and its infrastructure. See the full Article 55 for binding wording.

Codes of practice. Under Articles 53(4) and 55(2), providers may rely on codes of practice under Article 56 to demonstrate compliance until a harmonised standard is published; compliance with European harmonised standards grants a presumption of conformity to the extent the standards cover those obligations. A provider that adheres to neither must demonstrate alternative adequate means of compliance for Commission assessment. Codes of practice were due to be ready by 2 May 2025, and from 2 August 2025 the Commission may set common rules by implementing act if a code cannot be finalised or the AI Office deems it inadequate.

Application dates

Entry into force is not application. The Act entered into force on 1 August 2024 and at that point none of its requirements applied.

Three legacy rules decide whether existing deployments are caught:

• High-risk systems already on the market before 2 August 2026 (other than Annex X large-scale IT system components) fall under the Regulation only if they are subject to significant changes in their design from that date onwards (Article 111(2)). A significant redesign pulls a legacy system into scope.
• GPAI models placed on the market before 2 August 2025 have until 2 August 2027 to comply (Article 111(3)).
• Annex X large-scale IT system components placed on the market before 2 August 2027 must be brought into compliance by 31 December 2030 (Article 111(1)).

The 2 August 2026 date is the one most organisations should plan against, because it is when Annex III high-risk duties and the Article 50 transparency duties both begin.

Penalties

Article 99 requires Member States to lay down rules on penalties that are effective, proportionate and dissuasive, taking into account the interests of SMEs including start-ups and their economic viability. Penalties may include warnings and non-monetary measures. The ceilings are set in the Regulation:

The percentage-versus-fixed-amount rule inverts for smaller companies: for SMEs including start-ups, each fine under Article 99 is capped at the percentage or the amount, whichever is lower (Article 99(6)). For larger undertakings the higher of the two applies.

Fines under Article 99 are imposed at Member State level (by national courts or other bodies depending on the legal system), and Member States decide the extent to which public authorities and bodies can be fined at all (Articles 99(8), 99(9)). GPAI fines under Article 101 are imposed by the Commission, which must communicate preliminary findings and give the provider an opportunity to be heard; the Court of Justice has unlimited jurisdiction to cancel, reduce or increase them.

Article 99(7) lists the factors that shape the actual amount: nature, gravity and duration of the infringement and its consequences including the number of affected persons; whether other authorities have already fined the same operator for the same infringement; the operator’s size, turnover and market share; financial benefit gained or loss avoided; degree of cooperation; the technical and organisational measures implemented; how the infringement came to light and whether the operator notified it; intent or negligence; and mitigation of harm to affected persons. In practice these mean documented governance is not merely evidence of compliance but a mitigating factor in its absence of perfection.

Out of scope

This page covers classification, role allocation, GPAI, timing and penalties. It does not cover the detailed content of the Chapter III Section 2 requirements, conformity assessment under Article 43 and Annexes VI and VII, registration under Articles 49 and 71, the Article 27 fundamental rights impact assessment, or the scope and extraterritoriality rules in Article 2, which decide whether the Regulation reaches you at all when you are established outside the Union. Read those directly.

The Act is also not a data protection regime. It operates alongside the GDPR and Directive (EU) 2016/680 and says so repeatedly: Article 26(9) points at DPIAs, Article 5 preserves Article 9 GDPR for biometric data. Satisfying one does not satisfy the other.

Related

• NIST AI Risk Management Framework - voluntary US framework whose map, measure and manage outputs can feed AI Act documentation
• ISO/IEC 42001 - certifiable management system; certification is not AI Act conformity
• AI governance - index