_Post 18 of the AI in cyber series._
The Cyber Security and Resilience Bill is now through its committee stage and the commencement work has begun. The substance has stabilised enough to write usefully about what the AI-in-cyber implications actually are. I wrote the board read of the Bill in February 2024 from the general regulatory angle. This post takes the AI-specific angle, the way the secondary legislation is treating it, and what vendors and customers should be doing this quarter.
What the Bill itself says about AI
A specific observation that is sometimes missed in the public discussion. The Bill's primary legislation says relatively little about AI directly. The substance is in the secondary legislation that the Bill's framework authorises, and which is being drafted in parallel with the primary text. The pattern is primary legislation widens the perimeter, sharpens the clock, strengthens supply-chain diligence; secondary legislation specifies what those obligations mean in concrete contexts including AI.
This is, I think, the right approach. AI is moving fast enough that primary-legislative provisions would age in two-year cycles. Secondary legislation is updatable on a shorter cadence. The cost is that the substance of the AI-specific obligations is, at the time of writing, partly available in draft and partly still being worked out.
What the secondary legislation drafting suggests
To the extent that the drafting is publicly visible — and a lot of it has been in committee work that produces footprints in the published amendment text — four substantive provisions are taking shape.
Inventory obligation. Regulated entities will be required to maintain an inventory of material AI components in their security operations. The definition of material will turn on impact rather than capability — an AI system whose failure or compromise would affect the entity's ability to deliver an important business service is in scope. The inventory will need to specify the provider, the use case, the data flows, and the contractual basis.
Audit-trail obligation for consequential AI decisions. Where an AI system is involved in a decision that contributes to the firm's response to an incident — flagging, classification, containment recommendation — the firm must be able to demonstrate which model version produced which output on which input. This is the determinism property and audit-trail property from earlier posts in this series, made into a regulatory obligation.
Supply-chain diligence for AI providers. The Bill's supply-chain provisions apply to AI providers in the same way as to other critical suppliers. Regulated entities will be required to demonstrate that they have evaluated AI providers' security posture, data-handling arrangements, and continuity arrangements. Cyber Essentials certification of the AI provider is one piece of evidence; it is not the only piece.
Reporting obligation for AI-driven incidents. The 24-hour preliminary notification clock and the 72-hour full report obligation apply to incidents where AI was material. The full report must include what the AI did, when, and on what basis. This is the obligation that is hardest to deliver from most current LLM-based products and that the constrained-agency shape makes most achievable.
What this means for AI vendors
Four practical implications for any AI security vendor selling into UK regulated entities through 2026.
The customer's audit obligation becomes a vendor disclosure obligation. If your customer has to be able to demonstrate which model version produced which output on which input, your product has to expose that information. The audit-log format your product produces, today, has to satisfy the regulator's question through the customer.
Your provider-side resilience becomes your customer's regulatory risk. A model regression, a hosted-LLM outage, a vendor-side incident affecting your product — the customer carries the regulatory consequence. Your incident-disclosure and remediation arrangements are now part of the customer's compliance posture, not just a service-level question.
Your continuity arrangements become a procurement criterion. What the customer's fallback is if you have a serious outage is now something they have to be able to answer to the regulator. Vendors who can demonstrate, with evidence, that the customer can maintain operations during the vendor's outage will win deals against vendors who cannot.
Your cross-tenant intelligence model becomes auditable by the regulator. If your product aggregates data across customers — for shared threat intelligence, for model improvement, for any other purpose — the customer's regulator can ask the customer to demonstrate that this has been done under appropriate consent and anonymisation. Your customer cannot answer this from your marketing material; they need audit-grade evidence from your product. The seven principles from post 12 are the shape of what good looks like here.
What this means for customers
Three practical pieces of work for any regulated firm using AI in its security operations.
The inventory. This is the most concrete piece of work and the most overdue in most firms. A named list of every AI component in security operations: the product, the provider, the use case, the data flows, the contract. Six pages, signed off by the general counsel. The firm that has this is in a good place. The firm that does not has the work to do this quarter.
The audit chain for AI-driven decisions. Pick five AI-driven verdicts from the past month. Can the firm, today, demonstrate the model version, the input, the output, and the audit chain for each? The exercise reveals where the documentation is good and where it is not. The remediation work follows naturally.
The continuity plan. For each material AI provider, what happens if the provider has a 72-hour outage. The exercise from the BoE/FCA/HMT autumn cycle post is the same exercise. The Cyber Security and Resilience Bill makes it not optional.
How EmilyAI's posture reads against the drafting
For completeness, since the series's comparative frame requires it.
The inventory obligation: EmilyAI is one named, identifiable, contractually-clear component. The customer's inventory line for us is straightforward — UK Cyber Defence EmilyAI platform, version X.Y, deployed on dedicated R760 hardware in the UK, contractual data-handling terms in Schedule Z.
The audit-trail obligation: the determinism and model-registry properties have been in place since 2018. Which model version, what input, what output is answerable for any verdict the platform has ever produced.
The supply-chain diligence: the cross-tenant intelligence governance and the single-tin deployment posture give the customer audit-grade evidence on both data-handling and continuity.
The reporting obligation: the platform's audit chain produces the structured detail the 72-hour report requires. The customer has the data; they do not have to ask us for it under incident-response pressure.
The architectural decisions from 2018 turn out to be the right shape for the regulatory environment of 2026. This was not luck. The properties that turn into regulatory obligations now were good engineering then.
What this quarter looks like
For the regulated firm, three pieces of work that the Bill will, by spring 2026, expect to be in train.
The named AI inventory. The audit-chain demonstration for five recent AI-driven decisions. The continuity exercise for the most material AI provider.
If those three are in motion by the end of Q1, the firm is broadly in the position the Bill's commencement order will expect. If they are not, the work for Q2 is large and accelerated.
What is next
In six weeks: the open-frontier-model question. DeepSeek, the open-weight reasoning models that have changed the supply chain of intelligence, and what the provenance and licensing regime around the models that customers run actually mean for cyber security AI.