The five hour Microsoft 365 outage and the case for sovereign AI
AI inherits the failure modes of wherever it runs, and on 23 July 2026 that meant around five hours of silence.

An AI capability hosted in someone else's cloud fails whenever that cloud fails, which is the plain lesson of 23 July 2026, when a network failure in Microsoft's West US region took Azure and Microsoft 365 services offline for around five hours. Teams, SharePoint, OneDrive and Copilot went down together. Microsoft attributed the incident to a maintenance automation bug that removed critical network routes. For most organisations it was a lost afternoon. For anyone wiring AI into critical operations, it was a preview of a far more expensive future.
We build Mickai, a Sovereign Intelligence Operating System that runs entirely on the customer's own hardware, on premise and air-gapped where the mission requires it. We are not writing about this outage to criticise Microsoft's engineering, which operates at a scale few organisations can imagine. We are writing about it because the incident proves a structural point that no amount of engineering can remove. If your AI runs in a remote region you do not control, your resilience is capped by theirs.
What happened in the Microsoft 365 outage on 23 July 2026?
A network failure in Microsoft's West US region took Azure and Microsoft 365 services offline for around five hours on 23 July 2026, disrupting Teams, SharePoint, OneDrive, Copilot and dozens of Azure services, mostly for customers whose traffic routed through that region. As reported by Bleeping Computer from Microsoft's own account of the incident, a maintenance automation bug removed critical network routes, cutting healthy services off from the customers trying to reach them. Nothing was breached and nobody was attacked. Routine automation made a mistake, and from the first failures to full recovery around five hours later, the organisations caught behind that region discovered how many of their daily services shared a single point of failure.
Why does a cloud outage matter for AI adoption?
It matters because AI is shifting from a convenience to a dependency, and a dependency inherits every failure mode of wherever it runs. When Copilot went down alongside Teams, SharePoint and OneDrive, it demonstrated that a cloud AI assistant is not a separate resilience domain. It sits in the same basket as the rest of the productivity estate, behind the same regions, the same identity services and the same network routes. An organisation that builds AI into decision making, customer operations or regulated workflows is making an implicit bet that the provider's region will be up at the moment the work matters most. On 23 July that bet lost, for around five hours, for everyone routed through that region.
What is concentration risk, and why should regulated organisations care?
Concentration risk is the exposure created when many critical services depend on a single supplier, so that one fault cascades across everything at once, and regulated organisations should care because their obligations do not pause when a vendor's region goes down. Supervisors across banking, healthcare and government have spent recent years pressing firms to map their dependencies on critical third parties for precisely this reason. An outage caused by a maintenance bug is the benign version of the problem. The same concentration that turns one bug into a global work stoppage would also turn one compromise into a systemic incident. Service credits compensate for neither.
“A service credit refunds pennies on the hour. It does not refund the hour, the missed deadline or the regulatory question that follows.”
How does a sovereign operating system change the calculation?
A sovereign operating system removes the remote dependency entirely by running the models, the data and the controls on hardware the organisation owns. Mickai is designed to operate fully offline. Our own sovereign models run inside the customer's perimeter, so the intelligence that staff rely on does not vanish because a network route disappeared on another continent. Sensitive actions are checked by a cooperative multi-model consensus substrate, in which specialist models must agree before anything sensitive runs, and gated by voice biometrics, with the whole system anchored to a hardware-held root of trust in the building.
In practical terms, this is what keeps working on an air-gapped Mickai deployment while a cloud region is down:
- The intelligence itself, because our sovereign models run on the customer's own hardware rather than in a provider's region
- The evidence, because the Open Audit Record signs every action with post-quantum cryptography, is tamper evident, and verifies offline with no external service in the loop
- The safety controls, because consensus checks between specialist models and voice-biometric gating on sensitive actions all execute inside the same enclave
- The root of trust, because it is held in hardware on site rather than in a remote identity service that can be cut off by a routing fault
Does running AI on your own hardware mean giving up capability?
No, it means choosing which capabilities you depend on and owning them outright. Mickai carries 87 studios on one operating system, covering the working surfaces an organisation actually uses, from documents and collaboration to analysis and operations. Ten of those studios are production ready, and we launch with those ten, while the remaining 77 are in development. We say that plainly because a resilience argument built on overclaims is worthless. The architecture behind the system is covered by 104 filed UK patent applications across 2,340 claims, filed rather than granted, though the design goal was never paperwork. It was an operating system that keeps working, and keeps proving what it did, when everything outside the building goes quiet.
What should organisations take from the 23 July outage?
The honest takeaway is to classify AI dependencies the way you already classify other critical services, and to decide which of them you can afford to lose for five hours. For plenty of workloads a cloud assistant is a sensible choice, and outages of this scale are rare. But for the workloads where minutes matter, where regulators expect continuity, or where the data should never leave the building in the first place, the calculation is different. Sovereignty is not nostalgia for on-premise computing. It is the recognition that availability, control and evidence belong to whoever holds the hardware. On 23 July 2026 that was, briefly and involuntarily, nobody.
Frequently asked questions
What caused the Microsoft 365 outage on 23 July 2026?
A maintenance automation bug removed critical network routes in Microsoft's West US region, according to Microsoft's account of the incident as reported by Bleeping Computer, taking Azure and Microsoft 365 services offline for around five hours.
Which services were affected by the outage?
Teams, SharePoint Online, OneDrive and Copilot were among the Microsoft 365 services disrupted on 23 July 2026, alongside numerous Azure services, which meant meetings, file access, collaboration and the embedded AI assistant were unavailable together for around five hours, mostly for customers whose traffic routed through Microsoft's West US region.
Can serious AI really run fully offline?
Yes. Mickai runs our own sovereign models on the customer's hardware, fully offline and air-gapped where required, so the operating system, its studios and its audit trail all function without any connection to a cloud provider.
How does an air-gapped system stay accountable without a cloud?
Accountability is built into the machine itself through the Open Audit Record, which cryptographically signs every action with post-quantum cryptography, is tamper evident, and can be verified offline, so oversight never depends on an external service being reachable.
What is MICKAI?
MICKAI is a Sovereign Intelligence Operating System, a SIOS, that runs on the customer's own hardware, on premise and air-gapped, with every action recorded in the cryptographically signed, post-quantum secure Open Audit Record. It carries 87 studios on one operating system, with ten production ready at launch and 77 in development, and its architecture is covered by 104 filed UK patent applications across 2,340 claims, filed rather than granted.