Brexit removed the UK from the EU's regulatory jurisdiction in most respects. It did not remove UK businesses from the reach of EU regulation when those businesses operate in, sell to, or process data belonging to people in EU member states. The EU AI Act — the world's first comprehensive AI regulatory framework — follows the same territorial logic as GDPR. If your AI system touches EU users, EU operations, or EU markets, the Act applies to you regardless of where your company is incorporated.
Most UK businesses have not yet taken this seriously. Awareness of the Act is patchy, compliance planning is rarer still, and the AI consultancies implementing AI systems inside UK businesses are not, in the main, building regulatory classification into their delivery process. That is a problem that will become acute as enforcement mechanisms mature. This article sets out what you need to understand, what compliance practically requires, and what to expect from any AI consultancy you work with.
What the EU AI Act is
The EU AI Act entered into force in August 2024. Its requirements are being phased in across a three-year window running through 2025 to 2027, with the most serious prohibitions already applying and high-risk system requirements coming into full effect progressively. It is a risk-based framework: the obligations imposed on any given AI system depend on what that system does and the harm it could cause, not on the technology itself.
The framework has four tiers. At the top, a set of practices are prohibited outright — banned because the risk is considered unacceptable by design. Below that, high-risk AI systems face substantial compliance obligations before they can be deployed. A limited-risk tier imposes transparency requirements — disclosure that a system is AI, labelling of AI-generated content. At the bottom, minimal-risk systems face no specific obligations under the Act.
Enforcement sits with national AI Authorities in EU member states — the Act does not create a single pan-EU regulator. But enforcement actions against non-EU businesses will follow the same principle as GDPR enforcement: where you have EU-facing operations, EU regulators have jurisdiction. Penalties for violations involving prohibited practices reach up to €35 million or 7% of global annual turnover, whichever is higher. For high-risk system violations, the ceiling is €15 million or 3% of global turnover.
Which UK businesses are caught
The territorial scope of the EU AI Act extends to any provider placing an AI system on the EU market, any deployer using an AI system within the EU, and any business whose AI system outputs are used in the EU. That language catches a broader range of UK businesses than most realise.
UK businesses with EU offices, subsidiaries, or employees using AI tools are clearly in scope. So are UK SaaS businesses with EU customers where the SaaS product includes AI that makes or influences decisions. UK businesses deploying AI systems that affect EU citizens — even when operated from UK infrastructure — are covered. UK businesses that process EU personal data through AI systems are subject to both the AI Act and EU GDPR simultaneously.
The practical test to apply internally: does any part of your AI system touch EU data, EU users, or EU operations? If the answer is yes, operate on the assumption that you are in scope until specific legal advice tells you otherwise. The Act's drafters were deliberate about closing the extraterritorial gaps. Post-Brexit incorporation in the UK is not a safe harbour.
The risk classification framework
Understanding which tier your AI systems fall into is the single most important practical step. The compliance burden varies enormously between tiers, so misclassification in either direction creates real problems — either significant under-compliance with high-risk requirements, or unnecessary cost and process around systems that require only light-touch obligations.
Prohibited practices include social scoring systems operated by public authorities, real-time biometric identification in publicly accessible spaces (with narrow law enforcement exceptions), AI that exploits the vulnerabilities of specific groups — psychological, physical, or circumstantial — and subliminal manipulation techniques. These are banned outright. No compliance pathway exists; the practice must not occur.
High-risk systems are where most of the compliance burden sits. The Act identifies specific categories: AI used in critical infrastructure, AI in education affecting admissions or assessment, AI in employment and workforce management, AI in essential services including credit scoring and insurance underwriting, AI in law enforcement, AI in migration and border control, and AI in the administration of justice. This is not an exhaustive list — it is a defined set of domains where the consequences of AI failure are considered severe enough to warrant structured oversight.
The employment category deserves particular attention for UK businesses. AI systems used for CV screening, candidate ranking, performance monitoring, and promotion decisions are explicitly classified as high-risk. Any organisation considering AI recruitment tools — or already using them — should treat this classification as a material compliance consideration, not a footnote.
Limited-risk systems face transparency obligations. Chatbots must disclose that they are AI. Deepfakes must be labelled as AI-generated. AI-generated content must be identifiable as such. The practical lift here is modest, but the obligation is real and enforceable.
Minimal-risk systems face no specific obligations under the Act. Most business AI — workflow automation, document processing, internal productivity tools, recommendation engines operating in low-stakes contexts — will fall here. The absence of mandatory requirements does not mean compliance considerations are irrelevant; it means the Act does not impose them directly.
What high-risk compliance actually requires
If your AI system falls into a high-risk category, the Act imposes a structured set of requirements that must be met before deployment and maintained throughout operation. These are not aspirational guidelines — they are conditions of lawful use.
A fundamental rights impact assessment is required, evaluating the potential for the system to adversely affect individuals or groups protected under EU law. Data governance requirements mandate documentation of training data, evidence of bias testing, and ongoing monitoring of system performance against fairness criteria. Technical documentation must be maintained and made available to regulators on request — this is not post-hoc paperwork, it must be built into the development and deployment process.
Human oversight is a structural requirement, not a preference. High-risk AI systems cannot be designed to make final decisions autonomously in regulated domains. There must be a genuine, functional human review layer — not a perfunctory sign-off process that rubber-stamps AI outputs, but meaningful human agency over consequential decisions. Accuracy, robustness, and cybersecurity requirements apply throughout the system lifecycle. And for certain categories of high-risk system, registration in the EU AI Act database is mandatory.
The burden here is substantial. For organisations that have already deployed AI systems in high-risk categories without these structures in place, retrofitting compliance is considerably harder than building it in from the outset. This is why classification at the design stage matters.
The GDPR layer that already applies
UK businesses subject to the EU AI Act are not encountering AI regulation for the first time. UK GDPR — the retained EU law version of the original regulation — already imposes obligations on automated decision-making that affects individuals. Article 22 gives individuals rights regarding decisions made solely by automated means, including the right to human review and the right to an explanation of the decision logic.
The EU AI Act does not replace GDPR. It adds a compliance layer on top. For high-risk AI systems, the two frameworks overlap substantially — human oversight requirements under the Act align with Article 22 rights under GDPR, and data governance requirements under the Act reinforce data minimisation and accuracy obligations under GDPR. But they are not identical, and satisfying one does not guarantee satisfying the other.
UK businesses with EU operations also face the full EU GDPR alongside the AI Act — not just the UK version. Where AI systems process personal data of EU citizens, EU GDPR applies, with its own enforcement infrastructure via EU data protection authorities. The ICO is your regulator for UK data; EU DPAs are your regulators for EU data. The compliance map has multiple authorities and multiple frameworks, and they need to be managed simultaneously.
For businesses in financial services, the FCA's Consumer Duty adds a further layer — requiring that AI systems used in customer-facing contexts demonstrably deliver good outcomes for retail customers. We have covered that intersection in more detail in our article on AI consultancy for UK financial services. Legal firms face analogous considerations under SRA guidance, examined in our piece on AI for UK law firms.
What your AI consultancy should be doing about this
Regulatory classification should happen at the start of every AI implementation project, not at the end. The decision about how to build a system — its architecture, its human oversight structure, its logging and documentation — is shaped by which regulatory tier it occupies. A system discovered to be high-risk after it has been built and deployed requires expensive restructuring. A system classified correctly at the design stage can have compliance requirements built into its architecture from the outset.
Documentation is not an administrative overhead to be produced once a system is live — it is a core artefact of compliant development. Model cards, data provenance records, bias testing logs, and system change logs are the materials that support a compliance audit. Any AI consultancy that is not producing and maintaining this documentation as a matter of course is not building systems that are defensible in a regulated environment.
Human-in-the-loop architecture is not simply a preference for high-risk categories — it is a structural requirement. That means designing systems where human review is genuinely meaningful: where the reviewer has access to the information needed to evaluate the AI's output, where the review step cannot be bypassed under operational pressure, and where the final decision authority rests with a human. This has architectural implications that need to be resolved at the design stage.
Data processing agreements need to cover sub-processors, including the AI model providers whose infrastructure underlies any implementation. If you are using a third-party large language model or machine learning platform as part of your AI system, that provider is a sub-processor under GDPR. Your DPA structure needs to reflect that, and your AI consultancy should be identifying and documenting this chain, not leaving it to your legal team to discover later.
Ask any AI consultancy: "How do you classify our use case under the EU AI Act, and what does that mean for how you build?" If they cannot answer that question directly and specifically, they are not thinking about production. A system that works in a demo environment but cannot be defended in a compliance audit is not a finished system.
What UK businesses should do now
The phased application timeline means there is still time to act — but not to defer indefinitely. High-risk system requirements are coming into force progressively, and businesses that have deployed AI systems in regulated categories without the required structures in place will face increasing pressure as enforcement infrastructure matures.
The immediate priorities are mapping and classification. Produce an inventory of every AI system your business uses or deploys, including AI components within third-party software. Classify each system against the EU AI Act's risk tiers. This does not require legal expertise at every step — the classification framework is published and relatively clear — but it does require honest assessment of what each system does and who it affects.
For systems that fall into high-risk categories, build a structured compliance programme: fundamental rights impact assessment, data governance documentation, human oversight architecture, and audit trail logging. This work is considerably easier to do properly when the system is being designed than when it is already in production. If you have high-risk systems already deployed without these structures, the remediation work should start now.
Get legal advice specific to your business. The EU AI Act's territorial scope in relation to your particular EU exposure — the nature of your EU operations, your customer base, your data flows — requires analysis by lawyers who understand both the Act and your business. This article is not legal advice, and the specific question of whether and how the Act applies to your organisation is one that requires professional legal input.
You can read more about what production-ready AI implementation actually requires — including the compliance and documentation structures that support regulatory defensibility — in our article on what production-ready AI means. Our AI consultancy UK guide covers the broader landscape of working with AI advisory firms in the current environment.
How Mason Bedford approaches this
We build regulatory awareness into implementations from the start of every engagement. That means classifying use cases under the EU AI Act as part of the design process, structuring human-in-the-loop architecture where high-risk categories apply, and producing documentation — model cards, data provenance records, testing logs — that supports compliance audits rather than needing to be created after the fact.
We are not your lawyers, and we will tell you when you need specific legal advice on regulatory applicability. What we can do is build systems that are structurally defensible: systems where the oversight mechanisms are genuine, the documentation is current, and the architecture reflects the regulatory environment in which they operate.
If you are planning an AI implementation and want to understand how regulatory classification should shape the design, or if you have existing AI systems that need a compliance review, our services page sets out how we work. You can also get in touch directly — we are straightforward about scope and straightforward about what we can and cannot do.