The EU AI Act in Practice: Scope, Risk Tiers and What UK Organisations Must Do

A UK-headquartered lender uses a third-party model to score loan applications. A recruitment team in Manchester runs CV-ranking software over candidates in Dublin and Berlin. A software business in Leeds embeds a chatbot in a product sold to European customers. None of these organisations has an EU office. All three can fall within the EU AI Act, because its scope follows the market and the affected person rather than the place of incorporation.

That is the first uncomfortable point. The second is that most organisations cannot yet answer the question the Act starts from: which AI systems are in use, who supplied them, what decisions do they influence, and who inside the business owns each one. Until that list exists, every downstream obligation is guesswork. What follows covers what triggers scope, how classification works, what the provider and deployer roles actually demand, and what a compliance or risk lead can begin on Monday.

What actually brings a non-EU organisation into scope

The Act reaches providers who place an AI system on the EU market or put it into service in the Union, irrespective of where they are established. It also reaches providers and deployers established outside the Union where the output produced by the system is used in the Union. That second hook is the one UK teams underestimate. If a model runs on a server in London but its scores, rankings or generated content land in front of someone in the EU as part of a decision, the geography of the infrastructure is not the deciding factor.

Importers, distributors, product manufacturers and authorised representatives carry their own duties. There are carve-outs — systems used in purely personal, non-professional activity, national security and defence, and models and systems used solely for scientific research and development — but they are narrower than they first appear, and a research exemption ends when a system is put into service for real users.

Obligations phase in rather than landing at once: prohibitions and AI literacy first, duties on general-purpose AI models next, then the bulk of the high-risk regime, with AI embedded in regulated products last. The timetable has been the subject of amendment proposals, so confirm the date that applies to your specific classification rather than relying on a chart circulated last year.

The four tiers, and why classification is the whole exercise

Nothing in the Act applies uniformly. Obligations attach to a system's classification, so a wrong classification produces either wasted effort or an undefended gap.

Tier	Typical examples	Core obligation
Prohibited	Social scoring, untargeted scraping of facial images to build recognition databases, emotion inference in workplaces and education, exploitation of vulnerability, certain biometric categorisation and predictive policing	Stop. There is no compliance route
High risk	Biometrics, critical infrastructure, education and assessment, employment and worker management, access to essential services including creditworthiness and life or health insurance pricing, law enforcement, migration, justice; plus AI as a safety component of regulated products	Full lifecycle regime: risk management, data governance, technical documentation, logging, human oversight, conformity assessment, registration
Transparency risk	Chatbots and other systems people interact with, emotion recognition, biometric categorisation, synthetic or manipulated audio, image, video and text	Disclose to the person; mark synthetic content in a machine-readable form
Minimal risk	Most productivity, drafting and internal analytics tools	No specific AI Act duties; data protection, equality and sector law still apply

There is a narrow escape from the high-risk tier: a system in a listed use case may not be high risk where it performs only a narrow procedural task, improves the result of a completed human activity, detects patterns or deviations without replacing or influencing human assessment, or performs a preparatory task. Two conditions matter. A system that profiles natural persons is always high risk, and a provider relying on the exemption is expected to document that assessment and register the system. An undocumented assumption is not an exemption.

Provider or deployer: the role decides the workload

Most mid-size organisations are deployers — they buy or licence AI systems rather than build them. The deployer burden is real but bounded. The provider burden is heavy, and it can transfer without anyone deciding to accept it.

A deployer becomes a provider of a high-risk system in three situations: putting its own name or trade mark on the system, making a substantial modification to it, or changing the intended purpose so that a system not previously classified as high risk becomes so. White-labelling a vendor's tool, fine-tuning a model on internal data until its behaviour materially changes, or repurposing a screening tool into a promotion tool can each move the organisation across that line — along with conformity assessment, technical documentation and post-market monitoring.

Deployer checklist for a high-risk system

• Use the system according to the provider's instructions for use. Departing from them starts to look like a modification.
• Assign human oversight to named people who have the competence, training and — critically — the authority to override or stop the system. Oversight held by someone who cannot say no is not oversight.
• Check input data relevance and representativeness for the intended purpose where the deployer controls that data.
• Monitor operation and escalate. Inform the provider and the relevant authority where a risk emerges, suspend use where needed, and report serious incidents.
• Keep the automatically generated logs that are under your control, for at least the minimum period the Act sets and longer where other law requires it.
• Inform workers and their representatives before putting a high-risk system into service in the workplace.
• Tell affected individuals when a listed high-risk system is used to make or assist a decision about them, and be able to give a meaningful explanation of the system's role where that decision has legal or similarly significant effects.
• Complete a fundamental rights impact assessment where you are a public body, a private entity delivering public services, or deploying creditworthiness or life and health insurance risk systems.
• Confirm the data protection position separately. A data protection impact assessment is a different instrument with different triggers, and the AI Act does not discharge it.

The duties that catch supposedly harmless tools

Two obligations apply far more widely than the high-risk regime. Transparency duties require that people are told when they are interacting with an AI system unless it is obvious, that emotion recognition and biometric categorisation are disclosed to the people exposed to them, and that synthetic or manipulated content is marked in a machine-readable format and, for deep fakes, disclosed. A customer service chatbot and a marketing team's generated imagery both sit here.

Separately, providers and deployers are expected to ensure a sufficient level of AI literacy among staff dealing with the operation and use of these systems, proportionate to their role and the context. In practice most teams meet this with role-based training and a record of who completed it.

How enforcement bites

The headline maximums are up to 7% of global annual turnover for breaching the prohibitions and up to 3% for most other obligations, with lower ceilings applying to smaller organisations under the proportionality provisions. Fines are the visible end of the mechanism, not the whole of it. Market surveillance authorities can require corrective action, restrict availability, or order withdrawal from the market — which for a product business is the more disruptive outcome. UK and EU GDPR continue to run alongside, with their own maximum of 4% of global turnover, and a single deployment can engage both regimes on different grounds.

Limits of this guide

This is an orientation to the structure of the Act, not a legal opinion, and it does not attempt to cover everything. It does not address the general-purpose AI model regime in any depth, sector-specific overlays such as medical devices, machinery or financial services, the detail of conformity assessment procedures and notified bodies, or how national implementing measures and supervisory authorities are being organised across member states.

It also does not resolve the harder judgement calls. Whether a particular fine-tune amounts to a substantial modification, whether a given use falls inside a listed high-risk category, whether the narrow-task exemption is defensible on your facts, and how AI Act duties interact with automated decision-making rules under data protection law are all questions where competent professionals reach different answers. Where a system materially affects someone's employment, credit, insurance, education, liberty or access to a public service, take specialist legal advice on the classification and record the reasoning. The timetable is still moving; the evidence you would need to defend a decision is not something you can assemble retrospectively.