Compliance Guide

    EU AI Act vs UK AI Regulation: One Control Set for Firms Operating in Both Markets

    Largely yes, with limits. The EU AI Act is a statutory, risk-tiered regime and the more prescriptive reference point. The UK approach has been principles-based, non-statutory and cross-sector, applied through existing regulators. Firms can define one baseline of controls for risk management, human oversight, documentation and record-keeping against the EU standard, then add jurisdiction-specific configuration and sector-regulator expectations. A single control set does not remove the need for jurisdiction-specific handling, pre-deployment testing or organisational governance.

    Talk to an Expert See How Evidence Is Produced

    Defining the common baseline

    1. Define Art. 9, Art. 14 and record-keeping controls once, against the EU reference point
    2. Hold retention, residency and oversight triggers as per-jurisdiction configuration
    3. Add UK sector-regulator expectations as a layer on the same controls
    4. Keep an inventory with risk tier, provider or deployer role and EU output use
    5. Maintain a change log for EU amendments, delegated acts and UK regulator publications
    1. Re-baseline plans to the amended EU high-risk dates, and confirm which obligations already apply
    2. Classify each AI use case by EU risk tier and by provider or deployer role
    3. Map existing controls to Art. 9, Art. 14 and record-keeping, and list the gaps
    4. Identify which UK sector regulators apply and what current guidance they have issued
    5. Set retention, residency and human oversight triggers per jurisdiction
    6. Assign owners for runtime enforcement, pre-deployment testing, lineage and governance

    Two regimes, two designs

    The EU AI Act (Regulation (EU) 2024/1689) sets risk-based rules intended to encourage safe and trustworthy AI in the single market while protecting health, safety and fundamental rights. It sorts AI systems into risk categories with different requirements, and its most detailed obligations fall on high-risk systems. It applies across sectors and is without prejudice to existing Union law on data protection, consumer protection, fundamental rights, employment and product safety. It also reaches providers and deployers established in a third country where the output of their AI systems is intended to be used in the Union. A UK firm can therefore be in scope without an EU establishment.

    The UK has taken a different route. Its approach follows the 2023 white paper, AI Regulation: A Pro-Innovation Approach. It has been described as principles-based, non-statutory and cross-sector, applying the existing technology-neutral regulatory framework to AI rather than creating a general AI statute. Accountability sits with the regulators that already supervise a firm's sector. Because the UK position can change, compliance teams should confirm it against current regulator publications as of November 2026.

    The practical consequence is an asymmetry. The EU gives a firm a defined set of legal obligations to map controls against. The UK gives outcome-oriented expectations that vary by regulator. That is why the EU Act is the sensible reference point for a shared baseline.

    Where the regimes overlap and where they diverge

    The two approaches share concerns about safe, accountable AI use, but they differ in legal force and specificity. The comparison below is an editorial mapping for control design, not a statement of equivalence.

    • Legal basis: EU: a statutory regulation with direct obligations. UK: principles-based and non-statutory, applied through existing regulators.
    • Structure: EU: risk categories with different requirements. UK: existing technology-neutral frameworks applied to AI across sectors.
    • Risk management: EU: a risk management system established, implemented, documented and maintained for high-risk systems (Art. 9). UK: expressed through each sector regulator's expectations, which the firm maps individually.
    • Human oversight: EU: high-risk systems designed so people can effectively oversee them in use, including through human-machine interface tools (Art. 14). UK: oversight expected as an outcome, with specifics set per regulator.
    • Documentation and records: EU: transparency, technical documentation and record-keeping are named requirements. UK: evidence expectations depend on the regulator and the use case.
    • Territorial reach: EU: can apply to third-country providers and deployers where output is used in the Union. UK: determined by the remit of each existing regulator.

    EU application dates as of November 2026

    The EU timetable has changed, so project plans built on the original dates need re-baselining. The Commission says the Digital Omnibus entered into force on 27 July 2026 and extended the high-risk deadlines, citing the delayed availability of standards. The amending Regulation (EU) 2026/1744 also added prohibited practices, revised the AI literacy obligation and strengthened AI Office supervisory and enforcement powers. The earlier 2 August 2026 date for high-risk requirements is superseded. Obligations already in application still apply.

    • 2 February 2025: Prohibitions and general provisions began to apply.
    • 2 August 2025: Governance structure, penalties and obligations for general-purpose AI model providers began to apply.
    • 2 August 2026: The original general application date for the regulation.
    • 2 December 2027: Revised deadline for stand-alone high-risk AI systems.
    • 2 August 2028: Revised deadline for high-risk AI embedded in products.

    What runtime enforcement and evidence contribute, and what they do not

    Runtime policy enforcement applies the baseline at the point where an AI system acts. Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Each interaction or tool call can be allowed, redacted, blocked, rate limited or escalated for human approval. This is enforced at runtime, not reviewed after the fact, and it gives a concrete mechanism for human oversight triggers and for constraining what a system can do. Enforcement also generates continuous audit-ready evidence, mapped to the EU AI Act among other frameworks, which supports the record-keeping and documentation side of the baseline. Trussed can be self-managed in the customer cloud, with configurable retention and data residency, which fits the per-jurisdiction configuration described above.

    The boundaries matter. Runtime enforcement operates on individual interactions and tool calls. It does not replace pre-deployment testing, and it does not provide model lineage or dataset provenance. It does not establish organisational governance, such as accountability, risk acceptance and oversight roles, which remains a separate workstream. It does not classify use cases by risk tier, and it does not make a firm compliant with either regime. Evidence from enforcement shows what an AI system was permitted to do and what it did. Whether that evidence satisfies a given UK regulator's expectations must be confirmed with that regulator's current guidance.

    One baseline, two jurisdictional layers

    Common baseline

    Risk management, human oversight, documentation and record-keeping, defined once against the EU reference point.

    EU layer

    Risk tier, provider or deployer role, and the amended application dates.

    UK layer

    Expectations from each sector regulator relevant to the firm, mapped to the same controls.

    Evidence

    Records showing what each AI system was allowed to do and what it did.

    Map one control set across both markets

    Talk through how policy enforced in the execution path and audit-ready evidence fit your EU and UK baseline, and which obligations sit elsewhere.

    Talk to an Expert