I tell internal product teams this early: the UK did not adopt a single, EU-style AI statute. To be fair, that’s deliberate — the UK chose a regulator‑led, pro‑innovation approach instead of a single binding law. Granted, “lighter” does not mean “you’re exempt forever”. In practice this means you are on a different rulebook and you must manage UK expectations separately from the EU AI Act and MDR/IVDR obligations.
I work on CE/UKCA dossiers for Class IIa/IIb devices. Over the past two years I’ve seen the consequences of this bifurcation in three practical ways: regulator communications that read like bespoke requirements, guidance that changes faster than templates, and audit questions that assume you’ve implemented EU AI Act-style controls even when you only sell in the UK.
What the UK approach actually is
The UK’s approach is sectoral and regulator‑led:
- Rather than a single omnibus AI statute, the government set out a “pro‑innovation” direction (white paper / policy statements) and asked existing regulators — ICO, MHRA, Ofcom, FCA and the Office for AI among them — to produce targeted guidance and codes of practice.
- Regulators publish guidance, expectations and sometimes codes of practice; these are often outcome‑focused rather than prescriptive.
- Regulators can still take enforcement action under existing laws (data protection, safety and product rules). So you’re not operating in a vacuum — you’re operating under a distributed regulatory model.
Why medtech manufacturers should care
If you’re a small medtech manufacturer preparing a software validation or a PMCF for an AI component, the practical consequences are:
- Dual compliance risk: if you sell into both the EU and UK, you must adhere to the EU AI Act’s eventual obligations (and EU notified‑body expectations) and also to the UK’s sectoral expectations — they’re similar in spirit but different in detail.
- Audit variability: UK conformity assessments or MHRA queries will focus on existing regulatory levers (safety case, clinical evidence, data protection) and will expect evidence of governance, explainability and monitoring — but they may not accept an EU‑centric conformity assessment without adaptation.
- Guidance churn: regulator guidance can change quickly. That’s not the same as new law, but it is something auditors and enforcement teams will reference.
Practical checklist — what I actually do differently for the UK
When I prepare a Technical File or a UKCA artefact for software/AI components, these are the concrete steps I insist on:
- Map where you sell, not where you plan to sell.
- Separate the EU AI Act route from the UK route in your regulatory plan.
- Use regulator‑specific evidence packages.
- Create a UK‑facing evidence bundle that references MHRA guidance on software/AI (safety and clinical aspects), ICO guidance on data protection and DPIAs for automated decision‑making, and any Office for AI outputs relevant to transparency and governance.
- Treat data protection as a live product requirement.
- DPIA, data minimisation, lawful basis and records of processing are non‑negotiable under ICO expectations.
- Make post‑market monitoring explicit for algorithms.
- Define model performance thresholds, logging and retraining governance in PMS/PSUR and your change control. In practice this means linking software versions, datasets and CAPA history in your eQMS.
- Keep an audit trail for human oversight.
- Document how clinicians interact with outputs, what mitigation exists for false positives/negatives and how that is reflected in IFU and training materials.
- Use the EU AI Act as a helpful template where useful.
- If you’re resource constrained, voluntarily adopting many EU AI Act processes (risk classification, conformity assessment‑like evidence) can reduce friction later; but don’t assume this substitutes for UK‑specific evidence requests.
What I ask my QMS/eQMS to do
In a practical team meeting I’ll say: give me traceability and connected workflow. Specifically:
- Traceability between software versions, risk assessments and changes (Annex II style traceability for me).
- Change Impact Mapping that shows which Technical File sections a model update affects.
- Automated CAPA generation when monitoring thresholds are breached — AI‑assisted CAPA assistance is helpful so engineers have a draft root cause and corrective action to review.
- A reviewable, auditable log of model performance and data provenance.
These are not marketing checkboxes; they are the features that stop auditors from asking follow‑up questions. In my experience, an eQMS that supports connected workflows between change control, risk, and PMS saves weeks in audit prep.
Common misinterpretations I correct
- “The UK hasn’t legislated, so we can wait.” No. Existing laws and regulator expectations apply now.
- “If we meet the EU AI Act, we’re fine in the UK.” Not necessarily. The EU Act is a good baseline, but MHRA/ICO emphasise different evidence and wording — transparency statements, DPIAs and device safety narratives must be UK‑centred.
- “Guidance = optional.” Guidance is not law, but auditors and enforcement teams will use it as the bar for “reasonable practice”. Treat it as required evidence for conformity.
Final thought
If your device team is juggling EU and UK submissions, the simplest, pragmatic approach I’ve found is to maintain two living evidence bundles: an EU‑centric Technical File and a UK‑centric evidence pack that reuses artefacts where possible but explicitly references ICO/MHRA expectations. That keeps you audit‑ready on both sides without duplicating work.
How are you organising your evidence for UK vs EU AI expectations — one file that tries to do both, or two separate packs?
Top comments (0)