The National AI Governance Playbook · Part IV · Chapter 11

Security and critical infrastructure

AI risk in critical infrastructure sits at the junction of three existing mandates, and a junction with three owners tends to have none. This chapter separates the three exposures, assigns each as an extension of machinery that already exists, routes incidents down one path, and puts procurement to work as the quiet control.

By Myriam Ayada · MindXO · July 2026

In brief

Chapter 2 found risk to critical infrastructure to be the most frequent unassigned gap in national program portfolios, and the reason is structural: the risk sits at the junction of three existing mandates, the sector supervisors, the national cyber authority and the evaluation capability of Chapter 10, and a junction with three owners tends to have none. The chapter separates the risk into three exposures: AI operating inside critical functions, AI systems as an attack surface, and AI-enabled attacks on the infrastructure itself. Each exposure is assigned as a written extension of one existing mandate, with the other two bodies named as contributors. Incidents travel the existing reporting rails, extended with AI-specific fields; procurement applies the standards and assurance of Chapter 5 at the point of purchase; the capability of Chapter 10 serves all three mandates through one interface. One rule holds throughout: extend the machinery that exists, because a parallel AI-security regime duplicates the scarcest capabilities and orphans incidents.

The gap with three owners

Chapter 2 examined the implementation gap, and across the program portfolios it drew on, one omission recurred more often than any other: risk to critical infrastructure, present in the strategy and assigned to no mandate beneath it. The mapping exercise of Chapter 3 surfaces the same gap from the other direction, as work that three bodies could each plausibly perform and that none has been asked to perform in writing. An omission this regular is rarely an accident of drafting; it has a structure, and the structure is worth naming before any assignment is made.

The structure is a junction. AI risk in critical infrastructure sits where three existing mandates meet. The national cyber authority holds the security of essential services, and reads a deployed model as one information asset among many. The sector supervisors hold the operational risk of energy, health, finance and transport, and read the same model as one component of a regulated function. The evaluation capability of Chapter 10 holds the technical understanding of how models fail and how they are attacked, and holds no sector and no enforcement power. Each body can defensibly file the risk under one of the other two, and in most portfolios each does. A junction with three owners tends to have none.

One design principle resolves the junction, and the chapter holds it throughout. The risk is separated into three exposures; each exposure is assigned as an extension of exactly one existing mandate, recorded in writing; and the two remaining bodies are named as contributors with defined obligations to the owner. No new institution is created. The alternative reading, that a junction of this importance deserves a body of its own, is examined at the end of the chapter, because it is the most common way the assignment fails.

Three exposures

The junction resolves because the traffic through it is separable. Three exposures pass through it, with different objects, different natural owners and different extensions. The separation matters because the owner changes with the exposure; no single mandate covers all three without absorbing powers that belong elsewhere.

E1. AI inside critical functions: the model inside the function

What it is: models operating inside essential functions: energy dispatch and grid balancing, clinical triage, payment and settlement infrastructure. The exposure is operational. A model that fails, drifts or is manipulated degrades the function it serves, whatever the cause later proves to be. Natural owner: the sector supervisor, under the usage-based regime of Chapter 4. Failure of a model inside a regulated function is operational risk of that sector, and the supervisor already holds the inspection powers, the licence conditions and the outage duties that govern it. What extends: AI-specific requirements written into the sector rulebook and drawn from the shared standards through the citation of Chapter 5: an inventory of models in critical functions, evaluation before deployment, monitoring in operation, and a tested fallback for the model's withdrawal.

E2. AI systems as attack surface: the model as target

What it is: deployed models attacked as systems: adversarial inputs that steer behaviour, poisoning of training data, extraction of the model or of the data behind it. The patterns are catalogued publicly, in MITRE ATLAS and in NIST's adversarial machine learning taxonomy, in the form the security community already uses for conventional techniques. Natural owner: the national cyber authority. An attack on a deployed model is an attack on an information system, and the authority's mandate over essential services already covers it in general terms. What extends: model-specific security testing drawn from the capability of Chapter 10, and AI-specific attack patterns added to the security baseline that essential services already carry.

E3. AI-enabled attacks on infrastructure: the model as instrument

What it is: model-assisted intrusion and vulnerability discovery, and social engineering against operators at a scale manual tradecraft does not reach. This is a raised baseline threat rather than a new category of incident; the attacks arrive through channels that are already monitored. Natural owner: the existing CERT and the critical-infrastructure protection regime, which in most jurisdictions sit with or beside the cyber authority. The response runs through machinery that already exists, resourced for a higher tempo. What extends: threat assessments updated for model-assisted tradecraft, with the evaluation capability contributing an evidence-based reading of what current models can automate.

Sheet 11 of 13, three exposures, three owners, one incident path: an exposure-by-owner grid. The rows are the three exposures, AI inside critical functions, AI systems as attack surface and AI-enabled attacks on infrastructure; the columns are the sector supervisor, the cyber authority and the evaluation capability. A filled marker names each row's natural owner: the sector supervisor for AI inside critical functions, the cyber authority for the attack surface and for AI-enabled attacks. Hollow markers name the contributors, and the evaluation capability contributes on every row. On the right, a single incident path collects all three rows into one CERT report, routed once and shared.

One incident path

A model that fails in a dispatch centre produces an outage, and a model that is poisoned in a triage system produces a clinical incident. Both are critical-infrastructure incidents before they are AI incidents, and the reporting rails for critical-infrastructure incidents already exist: operators of essential services carry incident duties to the CERT or the cyber authority in every jurisdiction with a protection regime. The design task is to extend the taxonomy those rails carry, with the fields later analysis needs, which system was involved, whether the behaviour drifted or was induced, what evaluation the system had passed, instead of creating a second reporting duty beside the first. One event should produce one report, routed once and shared with every body whose mandate it touches.

The European Union illustrates both layers and the seam between them. Serious incidents involving high-risk AI systems are reportable under Regulation (EU) 2024/1689, while significant incidents at essential entities are reportable under the sectoral cyber baseline of Directive (EU) 2022/2555, the NIS2 directive. One event at one operator can engage both duties. The design task, wherever both layers exist, is making the two file as one report: one form that satisfies both duties, routed once, and shared between the authorities behind them. Where the seam is left open, the operator's counsel selects the narrower duty, and the analysis that needed both reports is completed by neither authority.

Procurement as the quiet control

Critical-infrastructure operators buy most of their AI. The models inside dispatch, triage and settlement arrive as procured products and services, and the buyer's leverage over their properties is greatest at the moment of purchase, before dependence accumulates. Procurement is therefore where the apparatus of the earlier chapters can be applied without new law. The chain of Chapter 5 already runs from the rulebook to the standard to the evidence, and a tender can require its lower links as conditions of sale.

Evidence of evaluation. Systems bound for critical functions arrive with documented security and performance evaluation, from the vendor or from the capability of Chapter 10, and the documentation is a condition of award.
Assurance against the cited standards. Conformity with the standards the rulebooks already cite, demonstrated through accredited assessment of the kind Chapter 5 places at the fifth link, in place of the vendor's own attestation.
Incident-reporting clauses. A contractual duty on the vendor to report model incidents, vulnerabilities and material changes to the operator, which writes the single incident path into the supply contract and reaches vendors that no licence condition reaches.

Each gate applies an instrument that already exists, and the tender moves it to the point of purchase. The control is quiet in a precise sense: no statute is amended, no rulebook is reopened, and the obligations arrive as conditions of sale that a vendor accepts by bidding. For governments early in the sequencing of Chapter 7, procurement is often the first place the standards of the chain acquire commercial force.

What the capability contributes

The capability of Chapter 10 appears on every row of the sheet and owns none of them. Its security testing serves the three exposures in three different ways. For AI inside critical functions, it evaluates systems before deployment, and the sector rulebook can require that evaluation as a condition of operation. For the attack surface, it supplies the model-specific testing that the cyber authority folds into the security baseline. For AI-enabled attacks, it contributes threat evaluation to the CERT's assessments, an evidence-based reading of what current models can automate and at what cost. One capability, three mandates drawing on it.

The arrangement is the interface of Chapter 4 again, applied to security. The capability publishes evidence, and the bodies with legal powers act on it. Holding the testing in one institution respects the scarcity Chapter 10 established, since the security-evaluation talent a government can assemble does not divide three ways, and it preserves the independence of the evidence, established in Chapter 3, since the body that produces the analysis holds no power to enforce a consequence. What each mandate may require of the capability, and what the capability owes each in return and on what cadence, belongs in the same interface documents Chapter 4 called the load-bearing joint of the architecture.

Common failure mode. The parallel regime. A new AI-security body is created beside the CERT and the sector supervisors, with its own reporting duty and its own taxonomy. One incident becomes reportable to three places in three vocabularies, operators comply with the cheapest interpretation, and the scarce testing talent divides across parallel teams. The unassigned risk of Chapter 2 returns wearing a new logo. Extension beats duplication everywhere the existing machinery already holds powers, and a new institution is defensible only where no mandate reaches; each of the three exposures sits inside a mandate that does.

Security completes the machinery of Part IV: the capability of Chapter 10, and the mandate extensions of this chapter that put it to work on critical infrastructure. What remains is the question every minister eventually asks of the whole apparatus: whether any of it is working. Chapter 12 closes the part by building the measurement, the indicators a governance program can credibly report, and the cadence at which someone with authority reads them.

Three questions for every government

For each of the three exposures, which existing mandate owns it, and what has been added to that mandate in writing?
Where does an AI incident in critical infrastructure get reported today, and how many duties would one incident trigger?
Which procurement gates apply the standards and assurance of the chain to systems entering critical functions?

Selected public sources

Regulation (EU) 2024/1689 (AI Act), European Union, 2024
Directive (EU) 2022/2555 (NIS2), European Union, 2022
MITRE ATLAS, adversarial threat landscape for AI systems, MITRE
Adversarial Machine Learning: A Taxonomy and Terminology (NIST AI 100-2), NIST