The EU AI Act: What It Covers and Which Role You Hold

Most confusion about the EU AI Act comes from skipping straight to obligations. The obligations only make sense once two prior questions are settled.

Is the thing in question an AI system as the Act defines it? If not, the Act does not apply at all, however clever the software is.

What role does your organisation hold in relation to it? The Act is not a set of rules about AI. It is a set of rules assigned to specific roles, and the same system produces entirely different duties depending on whether you built it, bought it, imported it, or resold it.

Organisations routinely get the second question wrong in a costly direction: they assume that because they did not build the model, the heavy obligations belong to someone else. Several ordinary commercial acts move you from the light role to the heavy one without anyone intending it.

This lesson answers both questions. The next covers what the answers trigger.

The Act defines an AI system as 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 that can influence physical or virtual environments.

The definition was deliberately aligned with the OECD's, so it travels beyond Europe.

The load-bearing word is infers. A system that applies rules a human wrote is not inferring; it is executing. A payroll calculator implementing tax brackets in a spreadsheet is not an AI system. A model that learned from data which invoices are likely fraudulent is.

Autonomy is a spectrum, not a threshold, and adaptiveness after deployment is explicitly optional, signalled by may. A model frozen at training time is still in scope.

The practical consequence for most organisations is that the boundary sits inside their existing software. Lead scoring in a CRM, CV ranking in an HR platform, and suggested replies in a helpdesk are all AI systems, whether or not anyone bought them as AI.

The Act assigns duties to roles along a supply chain, and the weight is very unevenly distributed.

A provider 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. Providers carry the great majority of the obligations.

A deployer uses an AI system under its own authority, other than in a personal non-professional activity. This is where most organisations sit, and the duties are much lighter.

An importer places on the EU market a system bearing the name or trademark of a provider established outside the EU.

A distributor is anyone else in the supply chain who makes a system available on the EU market.

One organisation can hold different roles for different systems simultaneously: a deployer of a purchased assistant, and a provider of the model it built in-house. The roles attach to systems, not to companies.

This is the trap, and it is worth knowing before rather than after.

The Act provides that a deployer, distributor or importer is treated as the provider of a high-risk system, taking on the full provider obligations, in three situations.

First, if they put their own name or trademark on a high-risk system already on the market. White-labelling someone else's system as your product makes it your product for regulatory purposes.

Second, if they make a substantial modification to a high-risk system already on the market, such that it remains high-risk.

Third, if they modify the intended purpose of a system, including a general-purpose AI system, in a way that makes it high-risk when it was not before.

That third route is the one that catches ordinary businesses. Take a general-purpose assistant, build a workflow on top that screens job applications, and you have given it an intended purpose that sits in a high-risk Annex III category. The original provider did not do that. You did, and the obligations follow the decision.

When this happens, the original provider must cooperate but is relieved of the provider obligations for that system.

The Act does not stop at the EU border, and the trigger is where the output lands rather than where the company sits.

It applies to providers placing AI systems on the EU market or putting them into service in the EU, wherever the provider is established.

It applies to deployers established or located in the EU.

And it applies to providers and deployers established outside the EU where the output produced by the system is used in the EU. That third limb is the broad one: a company with no EU establishment, running a model on servers elsewhere, is in scope if the results are used within the Union.

Providers established outside the EU that place high-risk systems on the market must appoint an authorised representative in the Union.

For a Swiss or UK organisation the practical reading is straightforward: serving EU customers or making decisions that take effect in the EU brings you inside the Regulation regardless of where you are incorporated. This is the same extraterritorial logic the GDPR established, and organisations that mapped their GDPR position have done much of the analytical work already.

Several exclusions matter, and knowing them prevents work that was never required.

Systems developed and used exclusively for military, defence or national security purposes are outside the Act's scope.

Scientific research and development is excluded, as is testing and development activity prior to placing on the market, though real-world testing has its own regime.

Purely personal, non-professional use by a natural person is outside the deployer definition entirely.

Free and open-source AI systems are outside several obligations, though this exemption does not extend to systems that are high-risk, prohibited, or subject to the Article 50 transparency duties. It is narrower than it is usually reported to be.

The 2026 Digital Omnibus added a carve-out for products covered by the Machinery Regulation, removing an overlap that had required manufacturers to satisfy two regimes for the same safety component, and it narrowed the definition of a safety component.

One exclusion people expect and do not get: there is no small-business exemption. Size affects how proportionately you must comply, not whether the Act applies.

Alongside the rules for AI systems, the Act has a distinct regime for general-purpose AI models, the large models that can be adapted to many downstream tasks.

The obligations here fall on the model provider, not on you as a downstream user. They include maintaining technical documentation, providing information to downstream providers who build on the model, a policy to comply with EU copyright law, and a sufficiently detailed public summary of the training content.

A further tier applies to models presenting systemic risk, which brings model evaluation, adversarial testing, serious-incident reporting and cybersecurity obligations.

These rules have applied since 2 August 2025. Models already on the market at that date have until 2 August 2027 to come into full compliance.

Why this matters to a non-provider: it is the reason you can reasonably ask a model vendor for documentation. Their obligation to give downstream providers the information needed to understand capabilities and limitations is what makes your own diligence possible. The 2026 Omnibus also gave the AI Office exclusive competence over AI systems built on a general-purpose model where the model and the system come from the same provider, which centralises supervision of the largest players.

A short procedure that resolves most cases, applied per system rather than per organisation.

List the systems. Include AI features inside software you did not buy as AI, since that is where most of them hide.

For each, ask whether it infers outputs from input rather than executing rules a human wrote. If it executes, stop.

Ask who placed it on the market under their name. If that is a vendor, you are a deployer. If it is you, you are a provider.

Then check the three provider-by-conduct routes: have you branded it, substantially modified it, or given it a new intended purpose? Any of those and you may be a provider for that system.

Record the answer and the reasoning, because a role assessment nobody wrote down is one you will redo.

The realistic outcome for most organisations: deployer for nearly everything, provider for one or two internal builds, and one uncomfortable case where somebody wrapped a general-purpose assistant in a workflow that decides something about a person. That last case is where the effort belongs.

Since most readers are deployers, it is worth stating the shape of that role now, before the next lesson adds the risk tiers.

For any AI system, regardless of tier, a deployer supports the development of AI literacy among staff and others operating systems on its behalf, following the 2026 amendment to Article 4.

Where Article 50 transparency duties apply, a deployer must inform people they are interacting with an AI system, disclose emotion recognition or biometric categorisation where used, and label deepfake content. These duties apply from 2 August 2026.

Where a system is high-risk, the deployer set expands considerably: use it in accordance with the instructions for use, assign human oversight to people with the necessary competence, training and authority, ensure input data is relevant and sufficiently representative where the deployer controls it, monitor operation and report serious incidents, keep logs, and inform workers before putting a high-risk system into use in the workplace.

That is the whole deployer picture. It is a real set of duties, and it is far short of what providers carry.

Five beliefs that cause the most wasted or misdirected effort.

The Act only applies to AI companies. It applies to any organisation using AI systems professionally, in any sector, at any size.

We use a vendor's tool, so it is their problem. Deployer duties are real, and branding or repurposing the tool can make you the provider.

Everything AI is high-risk. Most systems are not. The high-risk tier is a defined list of use cases, covered next.

We are not in the EU, so we are outside it. Output used in the EU is enough.

The fines are 35 million euros for any breach. That top tier belongs to the prohibited practices in Article 5. Most other obligations sit in a lower tier of up to 15 million euros or 3 percent of worldwide annual turnover, and some provisions carry no dedicated fine at all.

The correction to all five is the same. Work system by system, establish the role, then read only the obligations that role and tier actually trigger.