The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The UK does not have one universal AI-security law that applies identically to every organisation. As of 13 October 2026, the central AI-specific instrument is the government’s AI Cyber Security Code of Practice, published on 31 January 2025. It is voluntary, but it sets a detailed baseline for organisations that develop, deploy, operate or use AI. Separate data-protection, sectoral, contractual and other legal duties can still be binding. A related ETSI technical specification is now published, but its existence does not turn the UK code into law.
What the UK AI security rules are today
The UK framework is best understood as a combination of a voluntary AI-security code, implementation guidance, National Cyber Security Centre (NCSC) technical guidance, board-level governance guidance and existing laws that may apply to the organisation’s data, sector or services.
The government’s Code of Practice for the Cyber Security of AI describes baseline requirements across the AI lifecycle. It covers systems using deep neural networks, generative AI and other machine-learning approaches intended for deployment. It is not aimed at academic systems created and tested only for research when there is no plan to deploy them.
The code uses mandatory-sounding wording such as “shall” inside its provisions. That wording describes the code’s recommended baseline; it does not create a generally applicable statutory duty because the document expressly identifies itself as voluntary. An organisation may nevertheless have binding obligations under another regime, such as data-protection law, financial regulation, health and safety rules, procurement terms or a customer contract.
#1 Best Overall
Legal force and scope at a glance
| Instrument | Current status | What it does | Who should use it |
|---|---|---|---|
| UK AI Cyber Security Code of Practice | Voluntary government code, published 31 January 2025 | Baseline expectations for secure design, development, deployment, maintenance and end of life | AI developers, operators, data custodians and organisations using AI |
| Code implementation guide | Government implementation support | Translates the code’s principles into practical activities and role-specific detail | Security, engineering, risk, procurement and governance teams |
| NCSC Guidelines for Secure AI System Development | Version 1.0, published and reviewed 27 November 2023 | Technical guidance on secure design, development, deployment, operation and maintenance | Providers, developers, managers, decision-makers and risk owners, especially where hosted models or external APIs are used |
| Cyber Governance Code of Practice | Board and director guidance within the government’s modular cyber-code approach | Ownership, risk appetite, strategy, culture, assurance and training | Public- and private-sector boards, particularly medium and large organisations |
| ETSI TS 104 223 | Technical specification version 1.1.1, dated April 2025 | Baseline cybersecurity requirements for AI models and systems | Teams seeking a technical baseline or standards alignment; legal applicability must be assessed separately |
The Department for Science, Innovation and Technology’s AI cybersecurity collection was last updated on 7 September 2026 and continues to list the code, implementation guide and standards-related material. The ETSI work-programme entry records publication of the related EN transposition on 12 December 2025. Neither event establishes a universal statutory requirement for every UK organisation.
Which role does your organisation perform?
Responsibility follows what an organisation actually does, not whether it bought an AI product from a supplier. The code identifies four roles, and one organisation can occupy several of them at once.
Developers
Developers create or adapt an AI model or system. A business that fine-tunes a model, adds retrieval or tools, or builds a model into its own application may be a developer even when the underlying model came from elsewhere.
Recommended Free Tools
System operators
System operators embed or deploy models in infrastructure and keep the service running. A provider embedding an AI capability for business customers can be an operator. A company deploying an external model inside its own cloud environment may also be an operator.
Data custodians
Data custodians control permissions and integrity for data used by the system. This includes organisations that set data-use rules, retention requirements and data-management policies. More than one custodian may be involved in a single system.
Rank #2
End users
End users include employees and UK consumers who interact with an AI system. The code places expectations on upstream stakeholders to inform users, provide safeguards and make it possible to report suspected security problems.
Buying an external model does not transfer every responsibility to the supplier. Map each component, supplier and data flow, record which roles your organisation performs, and assign an accountable owner for each control.
What the code expects across the AI lifecycle
1. Secure design
Before creating or deploying an AI system, developers and operators should document the business need, likely security risks and proposed mitigations. Design decisions should account for adversarial inputs, model or data failure, confidentiality, integrity and availability.
Where the system can call other software, data stores or business processes, assess the permissions required for each connection. Grant only the access needed for the stated functionality. A conversational assistant that can read a database should not automatically be able to alter records, send messages or approve transactions.
2. Secure development
Developers should threat-model AI-specific attacks as well as conventional application threats. Examples named in the code include data poisoning, model inversion and membership inference. Revisit the model when a new dataset, prompt, plug-in, API, deployment configuration or feature changes the attack surface.
Rank #3
Maintain an audit trail for the operation and lifecycle management of models, datasets and prompts. The trail should let investigators establish what version was used, which data and instructions were supplied, who changed a setting and what the system produced.
3. Secure deployment
Deployment controls should protect infrastructure, interfaces, credentials and connected systems. Test behaviour with unexpected inputs and failure conditions, not only with normal user journeys. External software, models and APIs require security-risk assessment and supplier due diligence within the organisation’s existing software and procurement processes.
When an external provider is involved, assess its security practices, incident-notification arrangements, update process, subcontractors, data handling and ability to support an investigation. The code says developers and operators should conduct due diligence and should seek provider adherence to the code.
4. Secure maintenance and operation
Security continues after launch. Monitor model behaviour, access, logs, data flows and system health. Define how vulnerabilities, unsafe outputs, compromised credentials and suspicious prompts are escalated. Updates should be tested, approved and traceable; an update that changes model behaviour or permissions can create a new security risk.
NCSC guidance specifically highlights supply-chain security, deployment infrastructure, incident management, logging, monitoring and update management. Its central message is that “Security must be a core requirement, not just in the development phase, but throughout the life cycle of the system.”
Free tools Windows power users keep installed
One-click scans. No signup required.
5. Secure end of life
Plan how to retire a model, dataset, prompt library, API key and supporting infrastructure. Revoke access, remove obsolete integrations, preserve records needed for legal or security investigations, and dispose of or return data according to the applicable retention rules. Tell users and suppliers when a service is being withdrawn and what replacement, if any, is authorised.
AI-specific threats the organisation should model
- Data poisoning: malicious or corrupted training, fine-tuning or retrieval data alters system behaviour.
- Model inversion: an attacker infers sensitive characteristics or training information from model outputs.
- Membership inference: an attacker tests whether a particular record was included in training data.
- Prompt injection: untrusted instructions manipulate a model into ignoring controls, disclosing information or taking an unauthorised action.
- Unexpected output: inaccurate or misleading generation causes a downstream user or automated process to make a harmful decision.
- System failure: an unavailable model or broken dependency interrupts a critical service or leaves a fail-open control.
Threat modelling should connect each threat to a concrete control, an owner, a detection method and a response decision. Reassess after material changes rather than treating the original assessment as permanent.
How NCSC guidance fits with the government code
NCSC’s Guidelines for Secure AI System Development are aimed primarily at providers building AI systems with hosted models or external APIs, while encouraging developers, managers, decision-makers and risk owners to use them. The guidance is organised around secure design, secure development, secure deployment, and secure operation and maintenance.
The NCSC leadership guidance treats security as a leadership, culture, process and communication issue as well as a technical one. Senior leaders should understand consequences for confidentiality, integrity and availability, approve an incident response plan and know who can stop or restrict an AI system when risk becomes unacceptable.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsTwo practical questions from the NCSC material belong in management reviews: “Do you understand where accountability and responsibility for AI/ML security sit in your organisation?” and “How would you respond to a serious security incident involving an ML tool?” If nobody can answer quickly, the organisation has a governance gap even if its technical controls are strong.
Data protection and governance are related, not interchangeable
The AI code notes that personal data, including pseudonymised data, may trigger data-protection obligations and directs organisations to Information Commissioner’s Office guidance. The voluntary AI code does not replace those duties. Teams must establish a lawful and controlled basis for collecting, using, retaining and sharing personal data, and should involve the appropriate privacy specialists before deployment.
The Cyber Governance Code of Practice gives boards a broader framework covering risk management, risk appetite, supplier assurance, strategy, culture and training. It is described as foundational within the Department for Science, Innovation and Technology’s modular cyber-code approach. Organisations implementing the AI code are encouraged to follow the governance code and any organisation-specific codes as well.
General cyber-risk figures illustrate why board oversight matters, but they are not AI statistics. The Cyber Governance Code, citing the 2024 Cyber Security Breaches Survey, reports that 50% of businesses, 66% of high-income charities, 70% of medium businesses and 74% of large businesses reported some form of cyber breach or attack in the preceding 12 months. These figures should not be presented as evidence of AI incidents or AI-security adoption.
What the ETSI standard changes—and what it does not
ETSI TS 104 223 is titled Securing Artificial Intelligence (SAI); Baseline Cyber Security Requirements for AI Models and Systems. Version 1.1.1 is dated April 2025, and the related EN transposition was recorded as published on 12 December 2025.
The specification can provide a useful technical baseline for control design, procurement questionnaires and assurance mapping. It does not, on the evidence available here, impose a blanket legal duty on every UK organisation. A regulated organisation should check whether its regulator, contract, procurement framework or customer requirement incorporates the standard before treating compliance as mandatory.
A practical implementation plan
- Inventory AI use. List models, assistants, analytical tools, training pipelines, APIs, plug-ins and experiments that may reach production. Mark systems that process sensitive or personal data.
- Assign roles and accountability. For every system, name the developer, operator, data custodian and business owner. Record where one organisation performs multiple roles and where a supplier is involved.
- Document the pre-deployment assessment. State the business purpose, security threats, data sensitivity, mitigations, residual risk, approval authority and conditions for refusing deployment.
- Map connections and permissions. Draw the model’s links to identity systems, files, databases, tools and external services. Remove permissions that are not required for the advertised function.
- Threat-model AI attacks. Include poisoning, inversion, membership inference, prompt injection, information disclosure, unsafe output and failure of dependencies. Re-run the model after significant changes.
- Build traceability. Version models, datasets, prompts, configurations and infrastructure. Keep logs that support incident investigation while applying appropriate retention and access controls.
- Assess suppliers. Review provider security, sub-processors, update practices, vulnerability handling, incident notification, data location and exit arrangements. Put critical commitments in the contract.
- Prepare operations and response. Define monitoring, alert thresholds, human escalation, service shutdown, credential revocation, evidence preservation and communications for an AI-related incident.
- Train and involve users. Explain approved use, prohibited data, reporting routes, verification of generated output and how to recognise prompt-injection or data-leakage attempts.
- Retire safely. Revoke keys, remove integrations, handle retained records, notify affected users and document the final disposition of models and data.
Common mistakes and how to correct them
- Calling the code “UK AI law”. Describe it as a voluntary government code and separately identify binding requirements that apply to the organisation.
- Assuming the supplier owns all risk. Buying an API does not remove the operator’s duties for configuration, permissions, data and user protection.
- Stopping security at launch. Monitoring, updates, incident response and retirement are part of the lifecycle, not optional post-launch tasks.
- Logging too little. Without model, dataset, prompt and configuration history, investigators may be unable to reproduce or contain an incident.
- Granting broad tool access. Limit each integration to the minimum data and actions needed, and test whether a manipulated prompt can cross that boundary.
- Treating pseudonymisation as an automatic exemption. Pseudonymised information can still be personal data and may remain subject to data-protection obligations.
- Confusing ETSI alignment with legal compliance. Use the specification as a technical reference unless a regulator, contract or other rule makes it applicable.
Questions boards and executives should ask
- Which AI systems are deployed, and which are being developed for deployment?
- Do we understand where accountability and responsibility for AI/ML security sit?
- What personal, confidential or regulated data enters each system?
- Which supplier, model, API or plug-in could change the risk without our direct control?
- What is the most serious plausible loss of confidentiality, integrity or availability?
- How would we respond to a serious security incident involving an ML tool?
- Can we identify the exact model, dataset, prompt and configuration involved in an incident?
- What evidence would show that access, updates and supplier controls are working?
- When would we pause, restrict or retire the system?
Bottom line for UK organisations
Follow the AI Cyber Security Code of Practice as a practical baseline, use NCSC guidance for engineering and operational detail, and use the Cyber Governance Code to give boards clear ownership and assurance. Treat ETSI TS 104 223 as a published technical standard rather than automatic UK law. Then assess data-protection, sector-specific, contractual and procurement duties that apply to the particular system. The strongest programme is role-based, documented, continuously monitored and designed for the full lifecycle—from the first business case to secure retirement.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
