The EU AI Act: What It Actually Requires, and When

Who it applies to

The Act binds providers who place an AI system on the EU market or put it into service there, regardless of where the provider is established. It also binds deployers established in the EU, and it reaches situations where the output of a system is used in the EU even if the system itself sits elsewhere. Building a model in London or San Francisco does not put you outside it.

The distinction between provider and deployer matters more than most people expect. A provider develops the system or has it developed and places it on the market under its own name. A deployer uses it under its own authority. Buy a high-risk system and deploy it, and you carry deployer obligations. Fine-tune it, rebrand it or change its intended purpose substantially, and you can become the provider of a new system, inheriting the heavier set.

The four tiers, and why most systems are not high-risk

A small set of practices is prohibited outright. These include social scoring by public authorities, exploiting vulnerabilities of specific groups, certain biometric categorisation, and untargeted scraping of facial images to build recognition databases. If your product does one of these, no amount of documentation makes it compliant.

High-risk is the tier that carries real engineering cost. It covers AI used as a safety component in regulated products, and a listed set of uses including biometrics, critical infrastructure, education, employment and worker management, access to essential services, law enforcement, migration and border control, and administration of justice. Recruitment screening and creditworthiness assessment are the two that catch ordinary businesses most often.

Limited risk brings transparency duties rather than engineering ones. Users must be told they are interacting with an AI system, synthetic content must be marked as artificially generated, and deepfakes must be disclosed. Everything else falls into minimal risk with no specific obligations, and this is where most commercial software lands.

The practical first step is therefore classification rather than remediation. Many organisations assume they are high-risk, spend accordingly, and discover afterwards that their product is a transparency obligation and little more.

What a high-risk system must actually do

The obligations read like a product safety regime because that is what they are modelled on. You need a risk management system running across the lifecycle rather than a one-off assessment. You need data governance covering training, validation and testing data, including examination for bias and gaps that could produce discriminatory outcomes.

You need technical documentation sufficient for an authority to assess conformity, automatic logging so the system keeps records of its operation, and instructions for use that let a deployer understand its capabilities and limitations. You need human oversight designed in, meaning a person can genuinely intervene rather than nominally supervise, and appropriate accuracy, robustness and cybersecurity for the intended purpose.

Around all of that sits a quality management system, a conformity assessment before placing on the market, CE marking, and registration in an EU database. The shape of this will be familiar to anyone who has certified a medical device or industrial product, and unfamiliar to most software teams.

General-purpose AI

General-purpose AI models carry their own obligations regardless of tier: technical documentation, information for downstream providers who build on the model, a policy for complying with EU copyright law, and a sufficiently detailed summary of the content used for training. That last requirement is more onerous than it first reads, because it applies whether or not the training data was public.

Models judged to present systemic risk carry additional duties, including model evaluation, adversarial testing, incident tracking and reporting, and cybersecurity protection. The threshold is set by compute used in training, with the Commission able to designate models by other criteria.

If you build on someone else's foundation model rather than training your own, most of this sits with them. What lands on you is whatever your own use makes you a provider or deployer of, which loops back to classification.

Where ISO 42001 helps, and where it does not

ISO 42001 is the management system standard for AI, and it is the natural scaffolding for AI Act work: governance, roles, risk process, lifecycle controls, supplier management and continual improvement. If you already run ISO 27001, the structure will be immediately recognisable, and much of the governance machinery is shared.

What it is not is proof of AI Act conformity. Certification against a management system standard demonstrates that you govern AI systematically. Conformity assessment under the Act demonstrates that a specific high-risk system meets specific requirements. Holding the first makes the second considerably cheaper, because the documentation, risk process and oversight design already exist. It does not replace it, and anyone selling it as though it does is overstating.

What to do now

Inventory the AI systems you provide and the ones you deploy, including the ones embedded in tools you bought rather than built. Most organisations underestimate this list, because AI has arrived inside HR platforms, support tooling and analytics products without anyone classifying it.

Classify each one against the tiers before spending anything on remediation. Then check whether you are provider or deployer for each, and whether any customisation you perform tips you from the second into the first.

For anything genuinely high-risk, the long lead item is the quality management system and conformity assessment rather than the technical controls, so start there. For everything else, transparency obligations are cheap to meet and expensive to be caught missing.