EU AI Act compliance is now a British business problem, not a Brussels one. Regulation (EU) 2024/1689 does not care where your company is registered. It follows the market you sell into and the place where your system’s output lands, which means a Manchester software house shipping a hiring tool to Dublin, a Leeds insurer scoring policies for customers in Lisbon, and a London consultancy whose model ranks loan applications in Paris are all inside its reach. Brexit removed you from the EU’s law-making table. It did not remove you from the EU’s single market rulebook.
The awkward part is that the UK has taken a different path. There is no British equivalent statute to map your controls against, so UK teams cannot simply comply at home and assume the export version follows. Instead, EU AI Act compliance has to be built as a deliberate, evidenced exercise: work out which of your systems are caught, work out what role you play for each one, classify the risk, then produce the documentation the Regulation expects a regulator to be able to read.
This guide turns the Regulation into a working EU AI Act compliance checklist. It covers the dates that already apply, the inventory that has to exist before anything else can happen, the provider and deployer split that decides most of your obligations, the risk tiers, the twelve technical duties that attach to a high-risk system, what to demand from the vendors behind your models, and the penalties waiting at the end. Where a date or a threshold matters, it is stated plainly so you can diarise it rather than re-read the law.
Table of contents
- Why EU AI Act compliance reaches UK companies at all
- The EU AI Act compliance timeline UK companies must diarise
- Step 1: Build the EU AI Act compliance inventory
- Step 2: Decide your EU AI Act compliance role for each system
- Step 3: Classify each system into the EU AI Act compliance risk tiers
- Step 4: The high-risk EU AI Act compliance checklist for providers
- Step 5: Deployer duties in the EU AI Act compliance regime
- Step 6: General-purpose AI models and the vendors you rely on
- Step 7: AI literacy, governance and the evidence pack
- EU AI Act compliance penalties, enforcement and commercial cost
- Common EU AI Act compliance mistakes UK companies make
- Frequently asked questions about EU AI Act compliance
- References
Why EU AI Act compliance reaches UK companies at all
The extraterritorial reach is written into Article 2, and it is broader than most UK boards expect. Three separate tests can pull you in, and you only need to fail one of them for EU AI Act compliance to become your responsibility.
The market-placing test
If you place an AI system on the Union market or put it into service there, you are a provider under the Regulation regardless of where you are established. Selling through a reseller, bundling the capability inside a wider product, or offering it as a hosted service to an EU customer all count. There is no de minimis carve-out for small vendors, no grace period for first-time exporters, and no exemption from EU AI Act compliance for a UK company that simply never opened an EU office.
The output test
The test that surprises people is the one covering providers and deployers located outside the Union whose system output is used inside it. A UK marketing agency running a scoring model over a Spanish client’s customer list, or a UK employer using an automated screening tool on applicants based in Ireland, is producing output used in the Union. That is enough for EU AI Act compliance duties to attach even though the software never left your London data centre.
The supply-chain pull-through
Even where the Regulation does not reach you directly, your customers’ obligations will. An EU deployer of a high-risk system must follow the provider’s instructions for use, keep logs, and assign competent human oversight. They cannot do any of that unless you supply the documentation, and they will pass the requirement down the contract. Expect EU AI Act compliance clauses in EU tenders long before any regulator writes to you.
Where the UK’s own rules sit
The UK has no single AI statute. The pro-innovation approach leaves existing regulators to apply existing law, so the ICO polices automated decision-making and data protection, the FCA covers financial services, the MHRA covers medical devices, and so on. That means UK obligations and EU AI Act compliance are separate exercises that overlap heavily in evidence, and a UK-only governance programme will not satisfy an EU market surveillance authority on its own.
| UK company profile | Typical role | In scope? | Why |
|---|---|---|---|
| SaaS vendor with EU customers | Provider | Yes | System placed on the Union market |
| UK firm with an EU subsidiary using AI | Deployer | Yes | Deployer established in the Union |
| Agency scoring an EU client’s data in the UK | Deployer or provider | Yes | Output used in the Union |
| Recruiter screening candidates in the EU | Deployer | Yes | Output used in the Union, Annex III use case |
| Reseller of an EU-built AI product | Distributor | Yes, limited | Verification and cooperation duties |
| UK-only chatbot, UK-only users | None | No | No Union market or output nexus |
| UK supplier to an EU-facing customer | Sub-supplier | Indirectly | Obligations arrive by contract |
The EU AI Act compliance timeline UK companies must diarise
The Regulation entered into force on 1 August 2024 and applies in staggered phases. Two of them have already passed, which is why treating EU AI Act compliance as a 2026 problem is a mistake for anyone touching prohibited practices or general-purpose models.
What already applies
Since 2 February 2025 the prohibitions in Article 5 have been live, alongside the Article 4 duty to ensure staff have sufficient AI literacy. Since 2 August 2025 the obligations on general-purpose AI model providers, the governance structures including the AI Office and the national authorities, and most of the penalty regime have applied. If you sell or fine-tune a general-purpose model, your EU AI Act compliance clock started over a year ago.
What lands on 2 August 2026
This is the big one, and it is the date most EU AI Act compliance programmes are built around. The general application date brings the Annex III high-risk regime and the Article 50 transparency duties into force. Chatbots must disclose that they are machines, synthetic media must be marked in a machine-readable way, deepfakes must be labelled, and every high-risk system in recruitment, credit, insurance pricing, education or critical infrastructure must carry the full documentation set before it is placed on the market.
The 2027 and 2030 tails
Systems that are safety components of products already regulated under EU product legislation, listed in Annex I, follow on 2 August 2027. General-purpose models placed on the market before 2 August 2025 must be brought into line by the same date. High-risk systems intended for use by public authorities and placed on the market before August 2026 have until 2 August 2030. These tails are generous but conditional, and they disappear the moment the system is significantly changed.
The grandfathering trap
Legacy high-risk systems already on the market before the general application date are largely spared, but only until their design changes significantly. In practice this means the version you ship in July 2026 sets your baseline and every meaningful retrain, re-scope or feature release afterwards risks pulling the product into the full regime. Build your EU AI Act compliance evidence now rather than betting on a grandfather clause you may break in the first quarter.
A word on shifting dates
Amendments have been proposed at EU level that would move parts of the high-risk timetable. Until any amendment is formally adopted and in force, the dates in the adopted Regulation stand, so plan against them and treat any delay as a windfall rather than an assumption. Confirm the current position before you commit a board-level date.
Step 1: Build the EU AI Act compliance inventory
Nothing else on this checklist can start until you know what you have. An inventory is also the artefact a regulator asks for first, because it demonstrates that the organisation knows its own footprint rather than discovering it during an investigation. Every later EU AI Act compliance decision is traceable back to a row in this register.
What counts as an AI system
The definition is deliberately wide: a machine-based system designed to operate with varying levels of autonomy, that may exhibit adaptiveness, and that infers from its input how to generate outputs such as predictions, content, recommendations or decisions. That captures far more than large language models. Scoring engines, computer vision on a production line, recommendation logic and forecasting models all qualify for EU AI Act compliance analysis, while a deterministic rules engine written entirely by hand generally does not.
The fields your register needs
A register that only lists tool names is useless for classification. For each system capture the business purpose, the deployment context, whether output touches EU users, the model or vendor behind it, the data classes involved, whether decisions affect individuals, the degree of autonomy, the named owner and the review date. Those nine fields are enough to run every later step of EU AI Act compliance without reopening the conversation.
Finding the systems nobody registered
Most organisations underestimate their footprint by a wide margin, because AI arrives embedded in tools that were bought for something else. Check your CRM, your ATS, your service desk, your marketing automation, your security stack and your finance tooling for features switched on by a vendor update. Then check expenses for individual subscriptions. Our guide to the AI system inventory sets out a discovery approach that finds the shadow estate as well as the sanctioned one.
Separate the estate by exposure
Once the register exists, split it. Systems with no EU nexus at all can be governed under your normal IT governance arrangements. Systems with any EU market or output link move into the EU AI Act compliance workstream and get classified properly. Doing this split early stops you gold-plating fifty internal tools that were never in scope, and it keeps the EU AI Act compliance effort pointed at the systems that genuinely carry duties.
Step 2: Decide your EU AI Act compliance role for each system
The Regulation assigns obligations by role, not by company. The same organisation is routinely a provider for one system and a deployer for another, so the analysis is done per system and recorded in the register.
Provider versus deployer
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. A deployer uses an AI system under its own authority in a professional capacity. Providers carry the overwhelming majority of the EU AI Act compliance burden. Deployers carry operational duties around oversight, input data, logging and informing affected people.
When a deployer quietly becomes a provider
Article 25 is the clause that catches UK firms most often. You become a provider of a high-risk system if you put your own name or trademark on one already on the market, if you make a substantial modification to it, or if you change the intended purpose of a system so that it becomes high-risk. Fine-tuning a general-purpose model and pointing it at CV screening does exactly that, and the full provider obligations follow.
Record the role decision and its reasoning in the register. A role you never consciously chose is still a role a regulator can assign you during an EU AI Act compliance investigation.
Importers, distributors and product manufacturers
Importers must verify that the provider carried out conformity assessment, that the documentation exists and that the CE marking is present. Distributors must check the marking and documentation and act if they believe a system is non-conforming. Product manufacturers who integrate a high-risk system into their own product under their own name take on provider duties for it.
The authorised representative requirement
This one has a hard edge for British businesses. A provider established outside the Union must appoint, by written mandate, an authorised representative established in the Union before making a high-risk system available on the EU market. That representative holds the documentation, cooperates with authorities and can terminate the mandate if it believes you are non-conforming. Budget for it as a standing cost of EU AI Act compliance, not a formality.
| Obligation | Provider | Deployer | Importer or distributor |
|---|---|---|---|
| Risk management system | Yes | No | No |
| Technical documentation | Yes, author it | No | Verify it exists |
| Conformity assessment and CE marking | Yes | No | Check present |
| EU database registration | Yes | Public bodies only | No |
| Human oversight in operation | Design for it | Assign and resource it | No |
| Keep automatically generated logs | Enable them | Retain at least six months | No |
| Inform affected workers | No | Yes | No |
| Serious incident reporting | Yes | Report to provider | Inform provider |
| Authorised representative in the EU | Yes if outside the Union | No | No |
Step 3: Classify each system into the EU AI Act compliance risk tiers
Classification is where most of the EU AI Act compliance value sits, because it decides whether a system needs a paragraph of documentation or a year of engineering work. Do it once, properly, and record the reasoning.
Tier one: prohibited practices
Article 5 bans a short list outright, and these bans have applied since February 2025. They cover manipulative or subliminal techniques that materially distort behaviour and cause significant harm, exploitation of vulnerabilities linked to age, disability or social and economic situation, social scoring that leads to detrimental treatment in unrelated contexts, predicting criminal offending from profiling or personality traits alone, untargeted scraping of facial images to build recognition databases, emotion inference in workplaces and schools, and biometric categorisation that deduces sensitive characteristics.
The workplace emotion ban deserves a second look
British employers testing sentiment analysis on support calls, engagement scoring from webcam feeds, or productivity tools that infer mood should treat this as a hard stop rather than a risk to be managed. The prohibition on inferring emotions in the workplace has narrow exceptions for medical and safety purposes only, and it is enforced at the highest penalty band. This is the single most likely way a well-intentioned UK HR project breaches EU AI Act compliance.
Tier two: high-risk under Annex III
Eight use-case families are high-risk: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services including creditworthiness and life and health insurance pricing, law enforcement, migration and border control, and the administration of justice. Recruitment and credit are the two that pull ordinary commercial businesses into full EU AI Act compliance hardest and most often.
Tier two continued: safety components under Annex I
The other route to high-risk is being a safety component of a product already covered by EU product legislation, or being such a product yourself, where third-party conformity assessment is required. Machinery, medical devices, lifts, radio equipment and vehicles all sit here. This route follows the later 2027 date but carries the same substantive obligations.
The Article 6(3) filter
An Annex III system escapes the high-risk label if it does not pose a significant risk of harm because it performs a narrow procedural task, improves the result of a previously completed human activity, detects decision patterns or deviations without replacing human assessment, or performs a preparatory task. The catch is absolute: any system that profiles natural persons is high-risk regardless. You must document the assessment before placing the system on the market and register it.
Tiers three and four: transparency and minimal risk
Everything else falls into limited-risk systems that carry Article 50 disclosure duties, or minimal-risk systems with no mandatory obligations. Most internal productivity tooling lands here, which is the good news buried in the Regulation: the majority of your estate needs proportionate governance, not a conformity assessment. Scoping EU AI Act compliance honestly usually shrinks the problem rather than growing it.
Step 4: The high-risk EU AI Act compliance checklist for providers
If you provide a high-risk system, twelve substantive duties attach before it can lawfully be placed on the EU market. Treat this part of EU AI Act compliance as an engineering backlog, because most items need product work rather than paperwork.
Risk management and data governance
A risk management system must run continuously across the lifecycle, identifying foreseeable risks, testing mitigations and re-evaluating after changes. Separately, training, validation and testing data must be relevant, sufficiently representative and, as far as possible, free of errors and complete, with documented examination for bias. Our AI risk assessment template gives you a scoring structure that maps cleanly onto this requirement.
Documentation, logging and instructions
Technical documentation following Annex IV must exist before market placement and be kept for ten years. The system must log events automatically throughout its lifetime, and providers must keep those logs for at least six months. Instructions for use must be complete enough that a deployer can operate the system correctly, understand its limitations and exercise oversight.
Human oversight, accuracy and cybersecurity
The system must be designed so that people can effectively oversee it, including the ability to interpret output, override it and stop the system. It must achieve an appropriate level of accuracy, robustness and cybersecurity, declared in the instructions, and be resilient to attacks specific to machine learning such as data poisoning and adversarial examples.
Quality management, conformity and registration
Providers need a documented quality management system, must run the applicable conformity assessment, draw up an EU declaration of conformity, affix CE marking and register the system in the EU database before placing it on the market. Most Annex III systems can self-assess their EU AI Act compliance, but biometric systems commonly require a notified body.
After launch: monitoring and incidents
Post-market monitoring must collect and analyse performance data across the system’s life. Serious incidents must be reported to the market surveillance authority of the member state concerned promptly, with tighter deadlines for widespread infringements and for incidents involving death. If you have no route from a support ticket to a regulatory notification in under a fortnight, that gap is your first EU AI Act compliance project.
| Duty | Evidence a regulator expects | Usual owner |
|---|---|---|
| Risk management system | Living risk register with retest records | Product and risk |
| Data governance | Dataset provenance and bias examination | Data science |
| Technical documentation | Annex IV pack, versioned | Engineering |
| Automatic logging | Retained event logs, six months minimum | Platform |
| Instructions for use | Published limits, accuracy and oversight steps | Product |
| Human oversight design | Override, stop and interpretation controls | Product and UX |
| Accuracy and robustness | Declared metrics and test results | Data science |
| Cybersecurity | Adversarial and poisoning test evidence | Security |
| Quality management system | Documented procedures and change control | Quality or compliance |
| Conformity and CE marking | Declaration of conformity on file | Compliance |
| EU database registration | Registration record before launch | Compliance |
| Post-market monitoring | Monitoring plan and incident log | Operations |
Step 5: Deployer duties in the EU AI Act compliance regime
Most UK companies will be deployers far more often than providers, and the deployer list is short enough to implement in weeks rather than quarters. This is the fastest EU AI Act compliance win available to a business that buys its AI rather than building it.
The core deployer obligations
Use the system in line with the provider’s instructions. Assign human oversight to named people with the competence, training, authority and support to actually intervene. Ensure input data is relevant and sufficiently representative for the intended purpose where you control it. Monitor operation, keep the automatically generated logs for at least six months, and tell the provider and the authorities when something goes seriously wrong.
Telling people they are subject to a decision
Where a high-risk system is used to make or assist decisions about individuals, those individuals must be informed. Affected people also have a right to a meaningful explanation of the role the system played in a decision that produces legal or similarly significant effects. Build the explanation into the process rather than treating it as a subject access exercise.
Informing workers before deployment
Before putting a high-risk system into service in the workplace, deployers must inform workers’ representatives and the affected workers. In the UK this sits alongside consultation expectations that many employers already have, so the cheapest route is to fold it into your existing change process and your AI acceptable use policy.
Fundamental rights impact assessments
Public bodies, private entities providing public services, and deployers of credit scoring or life and health insurance pricing systems must complete a fundamental rights impact assessment before first use. It documents the process, the affected people, the risks of harm, the oversight measures and the governance arrangements. It complements a data protection impact assessment rather than replacing it.
The Article 50 transparency set
From August 2026, systems interacting with people must disclose that they are AI unless it is obvious. Synthetic audio, image, video and text must be marked in a machine-readable format. Deepfakes must be disclosed. Emotion recognition and biometric categorisation must be flagged to the people exposed. Published text on matters of public interest must be labelled unless a human took editorial responsibility. These are cheap to build, embarrassing to be caught missing, and the most publicly visible part of EU AI Act compliance because customers can see them.
Step 6: General-purpose AI models and the vendors you rely on
Almost every UK AI project sits on top of somebody else’s foundation model, so a large share of your EU AI Act compliance position is really your vendor’s position, transferred by contract.
What GPAI providers must do
Providers of general-purpose models must maintain technical documentation, supply information and documentation to downstream providers who integrate the model, adopt a policy to comply with Union copyright law including text and data mining reservations, and publish a sufficiently detailed summary of the content used for training. Certain free and open-source models are exempt from the first two duties unless they present systemic risk.
Systemic-risk models
Models presumed to carry systemic risk face extra duties: model evaluation including adversarial testing, assessment and mitigation of systemic risks, tracking and reporting serious incidents to the AI Office, and adequate cybersecurity for the model and its physical infrastructure. You will not be building one of these, but you may be buying from someone who is, and their obligations become your EU AI Act compliance evidence.
What to demand in the contract
Ask for the downstream documentation package by name, the training data summary, the copyright policy, notice of model version changes, and a commitment on how long a deprecated version stays available. Our AI procurement checklist turns those into questions your legal, security and IT reviewers can each score.
The fine-tuning trap
If you fine-tune a general-purpose model and deploy it for an Annex III purpose, you are the provider of a high-risk system. That is not a technicality. It moves the entire twelve-duty engineering backlog from your vendor’s roadmap onto yours, and it is the most common way a UK company acquires provider obligations without noticing. Decide deliberately whether the accuracy gain is worth the EU AI Act compliance cost.
Step 7: AI literacy, governance and the evidence pack
The Regulation expects capable people and documented decisions, not just conformant software. This section is where UK firms can move fastest on EU AI Act compliance, because none of it requires product changes.
Article 4 AI literacy is already in force
Providers and deployers must take measures to ensure a sufficient level of AI literacy among staff and others operating systems on their behalf, taking account of their technical knowledge, experience and the context of use. Role-based training with an attendance record satisfies this. Generic awareness slides sent to everyone do not, because the duty is proportionate to what each group actually does.
Who owns it internally
Give EU AI Act compliance to whoever already owns supplier assurance or regulatory compliance, with named contributors from legal, security, data protection and engineering. Creating a standalone AI governance function tends to duplicate existing controls and slow decisions, particularly in organisations under a few thousand people. What matters is that one person can answer for the register and the evidence.
Mapping to what you already have
Very little of this is new work if you run a mature information security and privacy programme. A management system built to ISO/IEC 42001 gives you the governance scaffolding, UK GDPR documentation covers a large share of the data governance requirement, and DPIAs overlap heavily with fundamental rights assessments. Our guide to ISO 42001 implementation covers the controls that carry over directly.
The evidence pack
Assume you will one day have to hand a folder to a customer’s auditor or a market surveillance authority. It should contain the system register, the role and classification decision for each system with reasoning, the technical documentation for anything high-risk, the literacy training records, the incident procedure, the vendor assurance responses, and the review dates. If it takes more than an afternoon to assemble, it is not an evidence pack, it is a research project, and your EU AI Act compliance position is weaker than your documentation suggests.
Rehearse the incident path
Reporting deadlines measured in days do not survive a discovery process measured in weeks. Test the route from a user complaint to a regulator notification in a tabletop exercise, exactly as you would for a security breach, using your AI incident response plan as the script.
EU AI Act compliance penalties, enforcement and commercial cost
The fines are headline-grabbing, but for most UK companies the commercial consequences of weak EU AI Act compliance arrive first and hurt sooner.
The three fine bands
Breaching the Article 5 prohibitions attracts up to 35 million euro or 7 per cent of total worldwide annual turnover, whichever is higher. Most other obligations sit at up to 15 million euro or 3 per cent. Supplying incorrect, incomplete or misleading information to authorities or notified bodies attracts up to 7.5 million euro or 1 per cent. For small and medium enterprises, including start-ups, the lower of the two figures applies rather than the higher.
Who actually enforces it
Member states designate market surveillance authorities, which handle systems placed on their national markets. The European AI Office oversees general-purpose model providers directly and can impose its own fines on them. A UK provider therefore faces EU AI Act compliance enforcement in each member state where its product is sold, with the authorised representative as the first point of contact.
The commercial consequence arrives first
Long before any regulator writes to you, an EU customer’s procurement team will ask for your conformity documentation and your role determination. No answer means no shortlist. This is why EU AI Act compliance is better framed as market access than as legal risk, and why sales teams are often the internal sponsor that unlocks the budget.
| Breach | Maximum fine | Turnover cap | SME treatment |
|---|---|---|---|
| Prohibited practice under Article 5 | 35 million euro | 7 per cent worldwide | Lower of the two |
| High-risk provider or deployer duties | 15 million euro | 3 per cent worldwide | Lower of the two |
| Transparency duties under Article 50 | 15 million euro | 3 per cent worldwide | Lower of the two |
| Misleading information to authorities | 7.5 million euro | 1 per cent worldwide | Lower of the two |
| General-purpose model provider duties | 15 million euro | 3 per cent worldwide | Imposed by the AI Office |
Common EU AI Act compliance mistakes UK companies make
These are the EU AI Act compliance failure patterns that show up repeatedly, and every one of them is cheaper to avoid than to remediate.
Assuming Brexit is a shield
The most expensive assumption on this list. EU AI Act compliance follows the market and the output, not the registered office, so a UK-only legal entity with EU customers is squarely in scope and usually needs an authorised representative as well.
Classifying at tool level instead of use-case level
The same model is minimal risk when it drafts marketing copy and high-risk when it ranks job applicants. Classification attaches to the intended purpose, so a register that lists one row per vendor rather than one row per use case will systematically under-classify.
Treating the derogation as a formality
Article 6(3) is a genuine off-ramp, but it requires a documented assessment before market placement, registration, and a system that does not profile individuals. Claiming it verbally in a meeting is worse than not claiming it, because it creates a paper trail showing the question was considered and mishandled.
Leaving transparency to the last sprint
Machine-readable marking of synthetic content and AI disclosure in interfaces are small pieces of engineering with long lead times when they touch every output path. Teams that leave them until mid-2026 find them competing with the high-risk backlog.
Confusing a DPIA with the full picture
A data protection impact assessment covers personal data risk. It does not cover accuracy thresholds, robustness testing, human oversight design or conformity assessment. Reusing DPIA evidence is smart; assuming it discharges EU AI Act compliance is not.
Never reopening the classification
Systems drift. A tool bought for summarising documents grows a scoring feature, a vendor swaps the model underneath, an internal pilot quietly becomes the hiring process. Without trigger-based re-review, your classification decisions age into fiction and your EU AI Act compliance record describes a system you no longer run.
Frequently asked questions about EU AI Act compliance
Does the EU AI Act apply to a UK company with no EU entity?
Yes. EU AI Act compliance attaches if you place an AI system on the Union market or if the output of your system is used in the Union, and neither test requires an EU establishment. If you provide a high-risk system, you must also appoint an authorised representative established in the Union before making it available there.
What is the single most important date?
2 August 2026, when the Annex III high-risk regime and the Article 50 transparency duties apply. That said, the prohibitions and the AI literacy duty have applied since February 2025 and the general-purpose model rules since August 2025, so EU AI Act compliance is not a future obligation for everyone.
Is a general-purpose chatbot high-risk?
Not by itself. Risk attaches to the intended purpose, so a general assistant used for drafting is generally minimal or limited risk with a disclosure duty. Point the same assistant at CV screening, credit decisions or exam marking and it becomes high-risk under Annex III.
We only use vendor tools. What do we actually have to do?
Inventory the tools, determine your role for each, classify by use case, implement deployer duties for anything high-risk, keep logs for six months, run literacy training, and collect vendor documentation. You do not need conformity assessment unless Article 25 has quietly made you a provider, so most deployer-only EU AI Act compliance work is process rather than engineering.
How does this interact with UK GDPR?
They overlap but do not substitute. UK GDPR governs personal data, lawful basis, individual rights and automated decision-making. The Regulation governs the system: its risk management, documentation, oversight, accuracy and market conformity. Most organisations run one governance process producing both sets of evidence.
Does ISO 42001 certification make us compliant?
No, but it helps considerably. Certification demonstrates a governed management system and produces much of the documentation the Regulation expects, which shortens the work substantially. It is evidence of good process, not a conformity assessment, and it does not remove any specific EU AI Act compliance duty.
What should a small UK company do first?
Build the register, mark which systems have any EU nexus, and classify only those. That single afternoon of work usually shows that the majority of the estate is minimal risk, which turns EU AI Act compliance from an intimidating programme into a short list of genuinely high-risk systems that deserve real attention.
References
European Commission Regulatory Framework for Artificial Intelligence
EU AI Act Article 5 Prohibited AI Practices
EU AI Act Article 6 Classification Rules for High-Risk AI Systems
EU AI Act Annex III High-Risk AI Systems
EU AI Act Article 14 Human Oversight
EU AI Act Article 50 Transparency Obligations
ICO Guidance on Artificial Intelligence and Data Protection
ICO Data Protection Impact Assessments
UK Government A Pro-Innovation Approach to AI Regulation
NCSC Guidelines for Secure AI System Development
NIST AI Risk Management Framework
OWASP Top 10 for Large Language Model Applications
BSI ISO/IEC 42001 Artificial Intelligence Management Systems
More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.
