What Happens When AI Becomes Critical Infrastructure?

The moment an AI system sits in a decision path people depend on, it stops being an efficiency project and becomes infrastructure, and infrastructure carries a different body of expectations. Availability targets, defined failure modes, dependency mapping, tested degradation and a duty to keep the service running arrive whether the organisation asked for them or not, and most AI deployments were architected under none of them.

The threshold gets crossed one workflow at a time, which is why it gets crossed unnoticed. A triage assistant becomes the triage process. A scoring model becomes the reason a benefit was refused. The dependency hardens while the governance stays where the pilot left it.

What actually changes when AI moves from productivity tool to decision path?

The change is in the failure question: not "how much slower are we today?" but "what happens to the people downstream, and who is accountable for it?". Electricity and telecoms teach the shape of the answer, and neither promises perfection. Both promise a stated availability target, published failure modes, a mapped dependency chain, a tested fallback and a duty to report when things break. The discipline is knowing how you fail, proving the fallback before you need it, and reconstructing events for someone who was not in the room. An AI decision path that cannot produce those five things is not being run as infrastructure.

Why is an AI outage a different class of event to a software outage?

Because AI can fail without announcing it. A payments gateway that goes down produces errors, alarms and a queue, and loud failures get fixed. An AI system in a decision path can stay available, stay responsive and start being subtly wrong: degraded retrieval, a stale index, a silently swapped model version, a drifted input distribution. The service is up, the decisions are worse, the dashboard is green, and the fault propagates because nothing is trying to stop it. The propagation is decisions: hundreds of them, acted on before anyone complains.

Which is why observability built for uptime is insufficient. It answers "is it responding", not "is it responding correctly, under what version of what model, with what inputs, under whose authority, and can that be proved later".

What does a dependency map for AI actually look like?

It looks uncomfortable, which is why it is rarely drawn. Resilience engineering traces the chain until every single point of failure is named, along with the jurisdiction it sits in. On an AI decision path that chain runs through a model provider, an inference region, a vector store, an embedding model that must match its index, an orchestration layer, and a contract that can be repriced or deprecated on notice. Several of those links sit outside the organisation's control, several outside its jurisdiction, and at least one will be changed by its owner without asking.

A model deprecation notice is a dependency failure with a calendar date on it: a migration ticket under a productivity framing, and under an infrastructure framing a forced re-certification of every decision path that touched the retired model.

The honest counter-argument, stated plainly: the hyperscalers run availability engineering at a standard almost no enterprise can match internally, and their record on core services is genuinely strong. For most workloads that is the right answer. The argument here is narrower, and it is not about uptime. Availability is one property of critical infrastructure; the others are control of change, continuity of the dependency, jurisdictional certainty and provability to an authority that trusts neither party. Those are properties of ownership, not service levels.

Which duties attach once the AI is load-bearing?

In the regulated classes the duties are already written down, and none of them were written for AI. Operators of essential services in the EU carry incident reporting and supply-chain security duties under NIS2. Financial entities carry operational resilience, third-party risk and testing duties under DORA. Where automated processing produces a decision with legal or similarly significant effect on a person, GDPR Article 22 attaches rights to explanation and to contest. The EU AI Act layers obligations for high-risk uses. None of these regimes ask whether the AI was a pilot.

The pattern across them is one demand, expressed four ways:

• Know your dependencies, including the ones you do not own, and what happens when they change or stop.
• State what you promise, in availability and in behaviour, and test the fallback before the incident.
• Treat degraded correctness as an incident class of its own, not a quality issue.
• Reconstruct any consequential decision afterwards, for someone hostile, from evidence they can check without trusting you.

The last one is where AI governance quietly collapses. Application logs are written by the party under scrutiny and mutable by that party, so infrastructure evidence has to survive the assumption that the operator is not trusted.

What should a board do about this in the next quarter?

Find where the threshold has already been crossed. Which AI-assisted workflows would materially harm someone outside the organisation if they stopped for a working day? For each, what is the availability target, who owns it, and does the manual fallback exist as trained people with authority to act, or only as a paragraph written before the headcount changed? Dependency creates duty, and it arrives on the schedule of the dependency, not the governance programme.

Frequently asked questions

Is AI already classed as critical infrastructure in law?

Not as a category of its own in most jurisdictions, and that is the trap. Duties attach to the essential service, the financial entity or the significant decision, not to the technology, so an AI system inherits the obligations of whatever it was embedded into. Nobody inside NIS2 or DORA gets a lighter regime because the component is a model.

What availability target should an AI decision path have?

Whatever the process it sits inside already promises. If that service carries a resilience commitment, the AI in its decision path cannot be less available without silently weakening it. The number matters less than the fact that someone owns it and the fallback beneath it has been exercised rather than documented.

Does running AI on owned hardware actually improve resilience?

It changes which risks you hold rather than removing risk. You take on hardware, capacity and operations, which is real work. In exchange you remove the links you cannot control: deprecation on someone else's calendar, silent version changes, jurisdictional exposure and repricing. For the regulated class of workload that trade is often correct. For most others it is not.

Why are application logs not sufficient evidence for an AI incident?

Because the party being investigated wrote them and can change them. Infrastructure-grade evidence must be created before the action, bound to the model version, inputs, authority and clearance in force at that moment, and verifiable by someone who does not trust the operator. Anything less is an assertion from the operator, which is the weakest evidence in the room.

Mickai is a British Sovereign Intelligence Operating System, built and live today, for the class of work where AI has already become infrastructure. It runs offline on hardware the organisation owns, in its own jurisdiction, with 50 brains and departmental studios rather than a dependency chain running through someone else's calendar. Its Open Audit Record seals every consequential action before it executes, signs it with post-quantum FIPS 204 ML-DSA-65 and hash-chains it, so a regulator or a court can verify what happened offline, without trusting us. The architecture is covered by 104 filed UK patent applications carrying 2,340 claims, held by Mickai LTD. Read the case at /sovereign-ai and the evidence model at /oar, or map your own decision paths at /ai-readiness.