What is the difference between the UK Code of Practice for AI Cyber Security and the EU AI Act?

How the UK Code of Practice and the EU AI Act differ in purpose

The simplest way to separate them is by function. The UK Code of Practice is a voluntary security baseline for organisations building or operating AI systems, so it is aimed at technical hardening, secure development, and operational discipline. The EU AI Act is a law, so it is aimed at legal classification, compliance duties, market obligations, and enforcement.

That difference matters because the Code is designed to improve security posture, while the Act is designed to regulate AI use and market access. A team may use the Code to strengthen controls even if no legal duty applies, but the Act creates formal obligations that can trigger conformity work, documentation, oversight, and penalties.

For a practical comparison, the Code asks, “What should we do to secure the system?” while the Act asks, “What category is this AI system, and what legal duties follow from that category?” Those are related questions, but they are not the same control problem.

What each one expects from practitioners

The UK Code of Practice is useful when the main concern is secure engineering and operational assurance. It pushes teams toward threat-informed design, resilience, monitoring, access control, and safer deployment practices. It is best understood as guidance that can be adopted early, including by teams that want a defensible security baseline before regulation or procurement pressure forces the issue.

The EU AI Act is structured differently. It is risk-based and compliance-driven, so practitioners have to determine whether a system is prohibited, high-risk, or otherwise subject to specific duties. That classification step changes the work: legal role allocation, technical documentation, human oversight, record keeping, transparency, and evidence of compliance become central.

The result is that one document helps you secure the system, while the other determines whether the system can be lawfully placed on the market or used under specified conditions. In practice, organisations often need both views at once, because a technically secure system can still be non-compliant, and a compliant system can still be poorly secured if teams treat legal conformity as a substitute for engineering controls.

Why the difference matters in governance and delivery

These two instruments sit at different layers of decision-making. The UK Code is usually most useful to engineers, security architects, and operators who need concrete controls and implementation guidance. The EU AI Act is most useful to product owners, compliance teams, legal teams, and governance functions that need to decide what obligations apply and what evidence must be retained.

That means the operational sequence is different. With the Code, teams usually start by improving system security and operational readiness. With the Act, teams start by determining applicability, classifying the AI use case, and mapping duties to the relevant internal owners. The first is control-led; the second is obligation-led.

For organisations that operate across the UK and EU, the two frameworks should be treated as complementary rather than interchangeable. The Code can help you implement the security side of AI governance, while the Act defines the regulatory side. If you confuse them, you risk either over-engineering a security programme into a legal compliance programme, or underestimating how much legal evidence the Act can require.

Risk and Threat Considerations

When teams treat the UK Code as if it were law, they can overestimate their compliance position and miss mandatory EU obligations. When they treat the EU AI Act as if it were only a security checklist, they can underinvest in the technical controls needed to reduce abuse, failure, and unsafe deployment.

Failure mechanism: The two regimes address different failure modes, so a programme that uses only one of them can leave either the security baseline or the legal obligation gap unaddressed. That is especially risky for cross-border deployments, where one framework may influence engineering choices while the other determines enforceable duties and penalties.

Impact: The practical impact is mis-scoped governance, incomplete evidence, and avoidable exposure to both security incidents and regulatory findings. In a mature programme, the Code informs how AI is built and operated, while the Act determines what must be documented, classified, overseen, and proven.

Practitioner Guidance

What to prioritise: Start by separating “security baseline” work from “legal applicability” work. The first is about hardening the system; the second is about determining whether the system falls into a regulated category and what evidence is needed.

What to verify: Confirm that your AI inventory distinguishes between controls you adopt voluntarily and duties you must satisfy under law. That distinction should be visible in ownership, review cadence, and audit evidence.

Decision rule: If the question is “Can we deploy this safely?”, use the Code as a security guide. If the question is “Can we deploy this lawfully in the EU?”, use the Act as the primary compliance reference, then map supporting security controls around it.

Practitioner takeaway: The right mental model is not “security versus regulation”, but “technical assurance versus legal obligation”. Strong AI governance needs both, and each answers a different question.

Related resources from NHI Mgmt Group

• Guide: Agentic AI Compliance Guide
• How should security teams structure EU AI Act compliance for AI systems?
• How should security teams build AI systems to meet EU AI Act requirements without slowing delivery too much?
• How should security teams implement pre-production testing to meet EU Cyber Resilience Act requirements in modern software delivery?
• How should security teams prepare AI governance workflows for EU AI Act audits?