EU AI Act: the EU regulation for artificial intelligence.

What the EU AI Act is

The EU AI Act (Regulation (EU) 2024/1689) is the European Union's horizontal law for artificial intelligence: binding on providers and deployers, not a certifiable standard, and enforced by national authorities rather than an accredited body. It entered into force on 1 August 2024.

Rather than regulating AI as a single category, the Act sorts systems by risk. A small set of unacceptable-risk practices is banned outright (Art. 5). General-purpose AI models carry their own obligation set (Art. 51 to 55). AI systems that touch chatbots, deepfakes or synthetic content carry transparency duties (Art. 50). And AI systems classified as high-risk under Article 6 carry the Act's heaviest regime: risk management, data governance, technical documentation, logging, transparency, human oversight, conformity assessment and registration. Most of the compliance work sits in getting that classification right, and in building the evidence trail that shows how you got there.

Who the EU AI Act applies to

Article 2 reaches further than most compliance teams model, and further than the GDPR. It covers providers placing AI systems on the Union market or putting them into service in the Union, irrespective of where they are established; deployers established or located in the Union; and providers and deployers established in a third country whenever the output produced by their AI system is used in the Union.

That third limb is the one that catches US and Swiss organisations. There is no targeting requirement and no intent requirement: the Act asks a narrower factual question than the GDPR does, whether the output is used here. A score, a ranking, a recommendation or a generated document produced outside the EU and consumed by a team inside it brings the system into scope, with no EU entity, staff or infrastructure required. Switzerland's domestic approach offers no passporting or equivalence route, so a Swiss provider selling into the Union is assessed exactly as a US or Japanese one would be. Non-EU providers of high-risk systems must also appoint an authorised representative established in the Union (Art. 22).

Providers and deployers routinely hold both roles across different systems, and Article 25 can convert a deployer into a provider (see the obligations section below), so role determination has to happen per system, not once per organisation.

How an AI system becomes high-risk

An AI system is high-risk under the Act if it takes one of two routes (Art. 6). Route one: it is a safety component of, or is itself, a product covered by the Union harmonisation legislation listed in Annex I, medical devices, machinery, toys, lifts, radio equipment, civil aviation, vehicles and the rest of the CE-marking universe, and that product is required to undergo third-party conformity assessment. Route two: its intended purpose falls within one of the eight use-case areas listed in Annex III.

Intended purpose decides route two, not architecture. The same underlying model is high-risk in one deployment and out of scope in another: a general-purpose assistant summarising meeting notes is not an Annex III system; the same assistant deployed to rank job applicants is. Intended purpose is established from the provider's instructions for use, technical documentation, and promotional materials, so marketing copy that promises more than the technical file admits is read against the provider.

The Article 6(3) derogation, and where it fails

Landing in Annex III does not end the analysis. Article 6(3) provides an exit for systems that do not pose a significant risk of harm to health, safety or fundamental rights, where at least one of four conditions is met:

• ●(a) A narrow procedural task, such as transforming unstructured data into structured data or deduplicating records.
• ●(b) Improving the result of a previously completed human activity.
• ●(c) Detecting decision-making patterns or deviations from prior patterns, without replacing the previously completed human assessment.
• ●(d) Performing a preparatory task to an assessment relevant to an Annex III use case.

The four conditions are alternative, not cumulative. One is enough, but the derogation must be read narrowly, as an exception to rules protecting fundamental rights. It fails absolutely wherever the system profiles natural persons, evaluating or predicting aspects of a person's performance, economic situation, health, preferences, behaviour, location or movements, regardless of which of the four conditions might otherwise be satisfied. It is assessed at system level, not component level: where multiple AI components interact and their combined output materially influences an Annex III decision, the whole is treated as one AI system. Adding a human-involvement requirement does not fix it either; human oversight is a Chapter III obligation, not a classification lever.

Claiming the derogation is itself a compliance obligation. Article 6(4) requires the provider to document the assessment before the system is placed on the market or put into service, and to produce it to national competent authorities on request. Article 49(2) additionally requires that provider to register itself and the system in the EU database. Under Article 80, market surveillance authorities can open a procedure against systems a provider has classified as non-high-risk, taking database information into account. An undocumented derogation is not a derogation. It is an unclassified system.

Provider and deployer obligations, and the Article 25 flip

Obligations split along the role held for a given system, and organisations routinely hold both roles across their AI portfolio.

Providers carry the design and evidence burden:

• ●Risk management (Article 9) and data governance (Article 10)
• ●Technical documentation (Article 11) and automatic logging (Article 12)
• ●Transparency and instructions for use (Article 13) and human-oversight design (Article 14)
• ●Accuracy, robustness and cybersecurity (Article 15)
• ●Quality management (Article 17), conformity assessment, the EU declaration of conformity, CE marking, EU database registration and post-market monitoring

Deployers carry operational duties:

• ●Using the system in accordance with the instructions for use
• ●Assigning competent human oversight with real authority to intervene
• ●Ensuring input data is relevant and sufficiently representative
• ●Retaining logs and monitoring operation
• ●Informing affected persons where required
• ●Running a fundamental rights impact assessment, for certain deployers

Article 25 collapses the distinction. A deployer who puts its own name or trademark on a high-risk system, substantially modifies it, or changes its intended purpose becomes the provider and inherits the full provider obligation set. Fine-tuning a vendor model on your own data and pointing it at an Annex III use case is the common path to this, usually taken by a product team without a compliance review.

Timeline after the Digital Omnibus, and penalties

The Act entered into force on 1 August 2024 and applies on a phased timetable that Regulation (EU) 2026/1744, the Digital Omnibus on AI, in force since 27 July 2026, revised without touching the classification rules in Article 6. The deferral is fixed-date, not conditional: the Commission's original proposal tied the delay to the availability of harmonised standards, but the final text abandoned that mechanism in favour of hard dates.

2 August 2026 was not cancelled. It remains the Act's general application date, and the Article 50 transparency duties took effect on schedule: an organisation that treated the delay as covering the whole regulation has, since that date, been out of compliance on disclosure and content-marking obligations carrying exposure of up to EUR 15 million or 3% of worldwide annual turnover.

Penalty tiers: prohibited practices under Article 5 carry fines of up to EUR 35 million or 7% of worldwide annual turnover, whichever is higher; most other breaches, including the high-risk obligations, carry up to EUR 15 million or 3%.

ISO 42001, harmonised standards, and the compliance gap

A widely repeated shorthand holds that ISO/IEC 42001 certification delivers AI Act compliance. It does not, for a structural reason. Under Article 40, presumption of conformity attaches only to harmonised standards whose references have been published in the Official Journal of the EU. As of mid-2026, no CEN-CENELEC deliverable under the AI Act standardisation request has been cited there: CEN-CENELEC JTC 21 assessed ISO/IEC 42001 against the Act's quality-management requirement, found the objectives and definitions insufficiently aligned, and drafted a bespoke European standard (prEN 18286) rather than adopting 42001 directly.

The practical consequence is an allocation of burden. A provider aligned to a harmonised standard, once cited, benefits from a rebuttable presumption: a market surveillance authority challenging conformity has to show the standard does not adequately cover the requirement. A provider relying on ISO/IEC 42001 alone keeps the full evidentiary burden and must demonstrate sufficiency clause by clause. That does not make 42001 a waste. Its risk management, data governance, transparency and human-oversight controls map closely to several of the Act's expectations, and a well-implemented AI management system builds most of the governance machinery a provider needs, in auditable form. It is the right substrate. It is not the shield. See the full ISO 42001 framework guide.

Running the EU AI Act in Acuna

Classification is not a document produced once. It is a live record that has to survive a product change, a vendor model update and, eventually, a question from a market surveillance authority, reconcilable with what your ISO 42001, ISO 27001, GDPR, NIS2 and DORA programmes already say about the same systems.

Acuna's AI Governance module holds the AI system register at article level: role, risk class, Annex III use case, and the dated reasoning behind each, alongside the Article 6(4) derogation assessments and a human-oversight register that names who can actually intervene, not just who is nominally responsible. Approval is gated on a completed impact assessment, and vendor-supplied systems link straight to the supplier's assurance evidence already held in the TPRM module, rather than opening a separate AI questionnaire cycle. See Acuna AI Governance.