The Cyber Security and Resilience Bill (CSRB), now HL Bill 32, has been scrutinised line by line in the House of Lords Grand Committee this month, across four sittings on 1, 3, 7 and 9 September 2026. Those sittings have produced the clearest signal yet on one of the questions in-scope organisations keep asking: does this Bill regulate artificial intelligence? The short answer from the Government is that it will not bring AI vendors into scope - and that answer has real consequences for how regulated entities need to govern their own use of AI.
This post explains what the Lords actually debated on AI, why the Government held the line, and the practical steps in-scope organisations should take now rather than waiting for a provision that is not coming.
What the Lords committee did this month
Committee Stage is the first chance for peers to examine a Bill clause by clause and to move amendments. Unlike the Commons, where the CSRB went through a Public Bill Committee, Lords Committee Stage on HL Bill 32 took place in Grand Committee across four scheduled sittings (1, 3, 7 and 9 September 2026), so a wide range of peers could table and speak to amendments before the Bill returns to the chamber for Report Stage. No Report Stage date had been announced at the time of writing.
Reporting indicates peers tabled around 65 amendments, covering AI, executive liability, incident reporting thresholds and emergency powers. The Government's own headline change is a new "vendor-related direction" power over risky technology suppliers, which we cover in detail in our analysis of the new powers to block risky suppliers. Alongside that, peers pressed the familiar themes from Second Reading: the near-total public sector exemption, the breadth of delegated powers, reform of the Computer Misuse Act 1990, and - most prominently in the press coverage - the Bill's silence on AI.
The Cyber Security and Resilience Bill and artificial intelligence
The central AI argument at committee was straightforward. A cross-party group, led by Lord Clement-Jones, argued that legislation presented as the UK's flagship cyber resilience reform should not ignore the technology now reshaping the threat landscape, and pushed for AI developers and frontier model providers to be pulled within the Bill's regulatory perimeter. Critics described an "AI-shaped hole" in the Bill.
The Government declined. Baroness Lloyd of Effra, the minister taking the Bill through the Lords, argued that regulating AI vendors and frontier model developers through this Bill would not, in practice, stop hostile actors from misusing their products, and that the Bill is not the right vehicle for AI-specific regulation. The effect, as commentators noted, is that the CSRB targets the organisations that use technology to deliver essential and digital services, not the companies that build AI models. AI risk is therefore addressed indirectly, through the security and resilience duties placed on regulated entities, rather than through any duty on AI providers themselves.
The Government also rejected a proposed AI "kill switch". An amendment from Lord Clement-Jones, co-signed by Baronesses Harding and Kidron and Lord Hunt, sought emergency powers to shut down AI systems and the data centres running them in a crisis. AI Minister Kanishka Narayan argued that existing powers already allow the Government to intervene, and a Government spokesperson said that "Britain cannot simply turn AI off".
Separately, peers probed the Government's power to direct organisations away from designated high-risk technology. That power sits in the same family as the vendor-direction provisions rather than being an AI-specific control, and its practical reach for suppliers and buyers is covered in our companion post linked above.
What this means if your organisation uses AI
The key takeaway for in-scope organisations is that the absence of AI-specific clauses is not an absence of AI-related obligations. If you are an operator of essential services, a qualifying managed service provider, a data centre operator, a large digital service provider or a designated critical supplier, the Bill's duties will attach to your systems and services regardless of whether those systems incorporate AI. Where you deploy AI - in a security operations centre, a customer-facing platform, an automated decision pipeline or a managed service you resell - the resilience of that deployment is your responsibility to assess and evidence.
There are five practical steps worth taking now:
-
Map where AI sits in your in-scope services. Treat AI components - models, inference services, third-party copilots, automated tooling - as part of the network and information systems the Bill will regulate. If a compromised or malfunctioning AI component could disrupt an essential or digital service, it belongs in your risk register.
-
Fold AI into your incident scenarios. The Bill tightens incident reporting duties. Rehearse the scenarios that AI introduces - prompt injection, model poisoning, data leakage through an AI feature, or an AI-enabled attack compressing your response window - so that your reporting triggers and timelines hold up under a real event.
-
Push resilience requirements down your supply chain. Because the Bill regulates you rather than your AI vendors, the contractual and assurance burden falls to you. Require security evidence, incident cooperation and change notification from AI suppliers, and confirm those obligations flow through managed service arrangements. Our managed service provider guidance and large SaaS provider guidance set out how the scope tests apply.
-
Align with the NCSC Cyber Assessment Framework. The most defensible way to demonstrate you are managing AI-related risk under the Bill's duties is to map it to a recognised framework. Our guide to preparing with the NCSC Cyber Assessment Framework explains how to structure that evidence.
-
Watch Report Stage, not just Committee. Committee amendments are frequently withdrawn to be pressed again later. An AI provision rejected in Grand Committee can return at Report Stage, so treat the current position as the Government's stated intent rather than the final word.
The other development worth flagging for security teams is a proposed new clause on the Computer Misuse Act 1990. Lord Clement-Jones tabled an amendment that would have placed a statutory duty on the Secretary of State to review - within 12 months of the Bill passing - whether a statutory defence under section 1 of the Computer Misuse Act is needed to protect good-faith security researchers and vulnerability testers, and to report the findings to Parliament.
Computer Weekly reports that the Government rejected the clause and it was withdrawn, with the minister saying Computer Misuse Act changes would come "as soon as parliamentary time allows". Lord Clement-Jones signalled that peers may return to it at Report Stage. For any organisation that commissions penetration testing or runs a vulnerability disclosure programme, the legal position for researchers is therefore unchanged by this Bill for now.
Where this sits in the Bill's journey
The CSRB cleared all its Commons stages and passed to the Lords, where Second Reading was completed on 14 July 2026. Lords Committee Stage sat across four sittings in September, after which the Bill moves to Report Stage and Third Reading in the Lords before returning to the Commons to consider any Lords amendments. Royal Assent is still expected in late 2026, with most substantive duties commencing later through secondary legislation - following the Government's implementation consultation - towards 2028.
For the wider set of themes driving Lords scrutiny, see our analysis of the Lords Second Reading and Committee Stage agenda. For the end-to-end picture, read what the Cyber Security and Resilience Bill is, the key changes it makes, and the text and structure of the Bill.
Position as at 14 September 2026. Committee sitting dates (1, 3, 7 and 9 September 2026) and the Bill's stage history are taken from the UK Parliament pages for HL Bill 32 (Bill 4035), the House of Lords business papers and the Hansard Society. Automated access to parliament.uk and Hansard was unavailable at the time of writing, so committee detail here is drawn from named reporting by The Register, GovInfoSecurity, MLex, Computer Weekly and PA. The AI scope and kill-switch rejections are corroborated across several outlets; the Computer Misuse Act outcome is reported by Computer Weekly. Amendment counts and wording are as reported; verify against the Bill's official amendment papers and Hansard before relying on them.