EU AI Act

Executive summary

The dominant narrative presents the EU AI Act as “the world’s first comprehensive AI law.” It is a useful commercial description, but conceptually misleading. The framing obscures what actually matters about the Regulation, which is not what it regulates but how.

The AI Act does not regulate artificial intelligence. It regulates the placing on the market and putting into service of AI systems within the Union, and it does so with the legal logic of product safety regulations. The regulated object is not the technology. It is the act of commercialisation. Researchers training a model in an academic laboratory fall outside the scope of the Regulation. The same model, integrated into a system offered on the European market, falls fully within scope.

This has three structural consequences worth fixing before reading any specific obligation.

First. The AI Act is built on the architecture of the Union’s New Legislative Framework. That logic explains why concepts such as risk management system, conformity assessment, CE marking, notified bodies, harmonised standards, post-market monitoring and serious incident reporting appear throughout the text. The AI Act is not an artificial intelligence law conceived from scratch. It is the extension of a regulatory model proven over four decades in toys, medical devices, lifts, machinery and pressure equipment, applied to algorithmic systems. Anyone reading the Regulation as if it were a digital rights statute misses the operational backbone. Anyone reading it as a product safety regulation finds it surprisingly familiar.

Second. The Regulation classifies systems, not technologies. The same neural network architecture can be of unacceptable, high, limited or minimal risk depending on the intended purpose and the context of use. Obligations are determined by use, not by technical architecture. This shifts the question from “is this model legal?” to “is this use case lawful, and under which obligations?” A diffusion model used for entertainment is minimal risk. The same model used to manipulate biometric features in an employment context can become a prohibited practice. The technology is identical. The regulatory weight is not.

Third. The AI Act introduces two parallel regulatory planes that coexist without fully overlapping: the plane of AI systems (risk by use) and the plane of general-purpose AI models, GPAI (risk by capability and by systemic impact). The first applies at the end of the chain, to the commercialised product. The second applies at the beginning, to the foundation model itself, before it has any specific purpose. Most of the operational complexity in real compliance work plays out in how these two planes articulate when a single actor occupies both roles, which is now the rule rather than the exception in the foundation model market.

The conceptual problem most organisations have not yet internalised is that the AI Act does not require them to “use AI ethically.” It requires them to build, document and maintain a body of technical and organisational evidence that demonstrates conformity ex ante and reproduces it on demand before a competent authority. The principal obligation of the Regulation is not behavioural. It is documentary and architectural.

This is not a subtle distinction. Behavioural compliance can be retrofitted with policies and training. Documentary and architectural compliance cannot. It must be designed into the development lifecycle, embedded in the data pipeline, and sustained by a quality management system that produces verifiable evidence at every step. The cost of late compliance is not the fine. It is the obligation to redo the engineering.

Who is obligated

The Regulation defines six figures with differentiated obligations: provider, deployer, importer, distributor, authorised representative and product manufacturer that incorporates an AI system. The distinction between provider and deployer concentrates around 80% of the practical complexity.

A provider is the natural or legal person that 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, whether for payment or free of charge. A deployer is the natural or legal person using an AI system under its authority, except where the use takes place in the course of a personal non-professional activity.

The distinction looks clear until the three scenarios of Article 25 appear, each of which converts a deployer into a provider with full attendant obligations:

1. Branding. The deployer puts its own name or trademark on a high-risk AI system already on the market.
2. Substantial modification. The deployer makes a substantial modification to a high-risk AI system, where “substantial modification” is defined in Article 3(23).
3. Change of intended purpose. The deployer modifies the intended purpose of an AI system, including a general-purpose AI system, in a way that turns it into a high-risk AI system within the meaning of Article 6.

A company acquiring a foundation model, fine-tuning it on proprietary data for credit scoring and deploying it as an internal product under its own brand can become the provider of the fine-tuned system, assuming all obligations under Annex I. The original foundation model provider remains responsible for the model layer; the deploying company assumes responsibility for the system layer. Both relationships must be governed by the contractual obligations of Article 25(4).

This re-allocation of provider status is the single most underestimated risk in current corporate AI practice. Many organisations treat fine-tuning and prompt engineering as deployment activities. In specific high-risk use cases, those activities legally promote them to provider status, with conformity assessment, technical documentation and CE marking obligations that no internal IT function is currently structured to deliver.

Extraterritorial reach

The Act applies extraterritorially. A provider established in the United States that places an AI system on the EU market is subject to the Act. A provider established outside the EU whose system’s output is used in the Union is also subject, regardless of where the model was trained or where the company is incorporated. This is the same extraterritorial logic that made GDPR a global standard, and it will produce the same effect: organisations will design for EU compliance and roll it out globally because operating two regimes is more expensive than complying with the stricter one.

What is regulated

The material scope is defined by the legal definition of “AI system” in Article 3, aligned with the OECD definition updated in 2023: 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 input how to generate outputs such as predictions, content, recommendations or decisions, that can influence physical or virtual environments.

The Regulation also covers general-purpose AI models (GPAI), defined in Article 3(63) as models trained with a large amount of data using self-supervision at scale, displaying significant generality and capable of competently performing a wide range of distinct tasks, regardless of how the model is placed on the market. Within this category, a reinforced subcategory of GPAI models with systemic risk applies under Article 51, with a default trigger of training compute exceeding 10²⁵ floating-point operations.

Out of scope:

• AI systems exclusively for military, defence and national security purposes
• AI systems used for the sole purpose of scientific research and development prior to placing on the market
• Personal non-professional use by natural persons
• Free and open-source AI systems and models, with significant exceptions: open-source GPAI models with systemic risk are within scope, and prohibited practices apply regardless of licensing

The open-source carve-out is narrower than initial readings suggested. A model published under an Apache 2.0 licence is not automatically exempt. If it crosses the systemic-risk threshold, the obligations of Title VIIIa apply in full.

Obligations

The AI Act articulates regulatory obligation across four risk levels for AI systems, plus a specific regime for GPAI models.

Tier 1 — Unacceptable risk (Title II, Article 5)

Prohibited practices. Article 5 lists eight categories of AI practices banned from placement on the market, putting into service or use within the Union:

• Subliminal, manipulative or deceptive techniques designed to materially distort behaviour and cause significant harm
• Exploitation of vulnerabilities related to age, disability or socio-economic situation
• Social scoring systems by public or private actors leading to detrimental treatment in unrelated contexts
• Predictive policing based solely on profiling or personality traits
• Untargeted scraping of facial images from the internet or CCTV to build facial recognition databases
• Emotion recognition in workplaces and educational institutions, except for medical or safety reasons
• Biometric categorisation systems inferring race, political opinions, trade union membership, religious or philosophical beliefs, sex life or sexual orientation
• Real-time remote biometric identification in publicly accessible spaces for law enforcement, except in narrowly defined cases subject to prior judicial authorisation

These prohibitions have been applicable since 2 February 2025. The compliance question is binary: no conformity assessment, no technical documentation and no risk management system make a prohibited practice lawful.

Tier 2 — High risk (Title III, Annexes I and III)

The high-risk regime is the operational core of the Act, and where most compliance work concentrates. A system is classified as high-risk via two routes:

Route 1 — Annex I. AI systems that are themselves safety components of products covered by Union harmonisation legislation (medical devices, machinery, toys, in-vitro diagnostics, lifts, vehicles, aviation, marine equipment), or that are themselves such products. The high-risk classification is automatic when the underlying product requires third-party conformity assessment.

Route 2 — Annex III. Eight areas of use where the legislator has identified a structural risk to fundamental rights:

1. Biometrics (remote biometric identification, biometric categorisation, emotion recognition outside prohibited contexts)
2. Critical infrastructure (digital infrastructure, road traffic, water, gas, heating, electricity)
3. Education and vocational training (admission, evaluation, monitoring of prohibited behaviour)
4. Employment, workers management, and access to self-employment
5. Access to and enjoyment of essential private and public services (creditworthiness, life and health insurance risk, public benefits, emergency dispatch)
6. Law enforcement (risk assessments, polygraphs, evidence reliability, profiling)
7. Migration, asylum and border control
8. Administration of justice and democratic processes

Provider obligations for high-risk systems include:

• Risk management system (Article 9) running across the full lifecycle: identification, estimation, evaluation and mitigation of foreseeable risks to health, safety and fundamental rights
• Data and data governance (Article 10) ensuring training, validation and testing datasets meet quality criteria appropriate to the intended purpose
• Technical documentation (Article 11 and Annex IV) sufficient to demonstrate conformity, prepared before placing on the market and kept up to date
• Logging and traceability (Article 12) through automated event recording relevant to risk identification and post-market monitoring
• Transparency and information to deployers (Article 13) through clear instructions for use
• Human oversight (Article 14) designed into the system to prevent or minimise risks
• Accuracy, robustness and cybersecurity (Article 15) appropriate to the intended purpose, declared in technical documentation
• Quality management system (Article 17) documenting compliance strategies, design, development, quality control and post-market surveillance
• Conformity assessment (Article 43) before placing on the market, through internal control or third-party assessment by a notified body depending on system type
• EU declaration of conformity and CE marking (Articles 47–48) affixed before market placement
• Registration (Article 49) in the EU database for high-risk AI systems
• Post-market monitoring (Article 72) plan and serious incident reporting to authorities within strict timeframes (Article 73)

Each of these is not a policy. It is an evidence requirement. The provider must be able to demonstrate, on demand, that the system was developed under these constraints, that the constraints are still in place, and that the documentation reflects the current state of the system.

Deployer obligations are lighter but non-trivial. Deployers must use the system in accordance with provider instructions, assign human oversight to qualified persons with the necessary competence and authority, monitor operation, retain logs for at least six months, conduct Fundamental Rights Impact Assessments before deploying certain Annex III systems (Article 27), and inform affected persons of high-risk AI use in decisions concerning them.

Tier 3 — Limited risk (Title IV)

Transparency obligations. Three specific scenarios:

• Conversational AI systems interacting with natural persons must inform users that they are interacting with an AI system, unless this is obvious
• Emotion recognition and biometric categorisation systems must inform users of the operation of the system
• AI-generated synthetic content (text, audio, image, video) must be marked as artificially generated or manipulated, in a machine-readable format. Deepfakes have specific labelling obligations

These obligations are light at the legal level but architecturally intrusive. Implementing machine-readable provenance for synthetic content requires watermarking infrastructure and content credentials at the model output layer.

Tier 4 — Minimal risk

No specific obligations. Voluntary codes of conduct.

Parallel regime — General-Purpose AI models (Title VIIIa)

Two regimes operate independently of high-risk classification.

All GPAI providers (Article 53):

• Maintain technical documentation, including training and testing process and evaluation results
• Make information and documentation available to downstream providers integrating the model into AI systems
• Comply with Union copyright law, including identification and respect of opt-out signals under Article 4(3) of Directive (EU) 2019/790
• Publish a sufficiently detailed summary of training data content

GPAI providers with systemic risk (Article 55) add:

• Model evaluation, including adversarial testing, before placement on the market
• Assessment and mitigation of systemic risks at Union level
• Tracking, documentation and reporting of serious incidents to the AI Office
• Adequate cybersecurity protection

The threshold for systemic risk is training compute exceeding 10²⁵ FLOPs, or designation by the AI Office based on capabilities. The AI Office published the General-Purpose AI Code of Practice in 2025, providing a presumption-of-compliance route for signatories. Adherence is not mandatory but operationally significant: non-signatories face a higher evidentiary burden in demonstrating compliance.