A category shift is quietly being formalised in how governments treat AI. For years, official guidance on AI security dealt with it as a technology issue - protect your models, mind your data, watch for novel attacks. The newer wave of guidance is different in kind: cybersecurity agencies responsible for critical infrastructure have begun applying their existing regulatory authority to AI systems deployed inside power grids, hospitals, water treatment and similar essential services. The premise of that move deserves attention, because it is a factual claim as much as a policy one: AI has crossed from analysing critical infrastructure to participating in its operation - forecasting load, flagging anomalies, scheduling maintenance, in some cases closing control loops - and a failure or compromise there is not a software bug with a support ticket. It is a public safety event.
The security logic differs from ordinary IT in ways worth understanding even outside the utility sector. Traditional infrastructure protection is built on determinism: control systems do specific things, engineers can enumerate their states, and a deviation is detectable precisely because normal is well defined. Machine-learning systems break that assumption twice over. Their behaviour is statistical rather than enumerable, so deviation is a judgment rather than a fact. And they add attack surfaces that classical security does not cover: training data that can be poisoned upstream, models that can be manipulated through their inputs, and the drift by which a model quietly stops matching the world it was trained on - no attacker required. Standards for AI in essential services therefore reach beyond firewalls into unfamiliar territory: provenance of training data, monitoring of model behaviour against expected envelopes, and the mandated ability to fall back to non-AI operation when confidence is lost.
That last requirement - the fallback - is the one with the widest resonance. Infrastructure regulators are effectively insisting that AI in essential services be an enhancement with an exit, not a dependency without one: the grid must be operable, the water treatable, the hospital runnable if the model is switched off. This discipline exists because infrastructure engineering has a long institutional memory of automation that worked until it didn't. It contrasts sharply with how AI is being adopted in ordinary businesses, where the exit is rarely designed and often nobody can say what the manual procedure would be, because the people who ran it manually have moved on or the volume has outgrown them. The regulated sectors are being forced to answer a question every adopter should ask voluntarily: on the day this system is unavailable or untrustworthy, what happens?
For most firms, AI-in-infrastructure standards will never apply directly, and that is precisely why the development is useful - it is a preview, written by institutions that cannot afford wishful thinking, of where AI assurance is heading. The direction of travel is visible: higher-stakes deployments attract requirements for monitoring, provenance, human override and graceful degradation, and those expectations migrate outward over time through insurers, large customers and procurement checklists, the same route by which general cybersecurity practice spread over the past two decades. A business deploying AI into anything it would call essential to its own operation can borrow the discipline early and cheaply: know what the system touches, watch what it actually does, keep a working way to operate without it, and treat the answer to who notices if it goes wrong as part of the deployment, not a question for later. The utilities are being made to do it. The rest of us merely should.