Your AI Outage Is a Business-Continuity Event. Design For It.

TL;DR: Two of the three AI outages on 3 September 2026 shared one hidden dependency, and nobody could see it while it was happening. Treat AI outages as business-continuity events. Give every AI-dependent process a named owner, a written degraded mode and a recovery time you have actually tested.

What is the short answer?

• A second AI vendor does not protect you if both vendors sit on the same infrastructure.
• Ask four questions about each AI-dependent process: what stops, who owns the fallback, what the degraded mode is, and how fast you recover.
• Write the degraded mode down with a trigger, a procedure and an endpoint.
• Rehearse the failure on purpose and time it.
• Give each critical process a named continuity owner who is not the technology lead.

What happened on 3 September 2026?

On the morning of 3 September 2026, ChatGPT, Claude and Grok all went down within the same few hours. Development platforms that depend on them stalled too.

The common reaction was to use more than one model. That helps, but it's incomplete. It's also where a lot of expensive surprises will come from over the next two years.

Were those really three separate outages?

The real problem is dependency you never mapped. Two of the three shared one. SpaceX later attributed an outage at its Memphis compute centre to Grok and to compute partners including Anthropic. OpenAI's window came from a routing error of its own, so one of the three really was a coincidence.

Nobody outside those vendors could tell which was which while it was happening. You can't build a continuity plan on a distinction you can't make in the moment. You thought you'd bought diversification. Two of your doors opened into the same room, and nothing told you.

Here's the decision I want you to leave with. Stop treating AI outages as technology incidents for an on-call engineer. Treat them as business-continuity events with named owners, defined fallback modes and tested recovery. The rest of this piece shows how.

Key Point: Two of the three outages shared a hidden dependency, and nobody could see it live. That's why AI outages belong in continuity planning.

Figure 1. Two of the three shared a dependency. One did not.

Why was availability the wrong metric?

For years, “is the service up” was a fair question. AI sat at the edge of the business. It drafted a paragraph, summarised a document, suggested a subject line. If it vanished for an hour, someone waited an hour.

Now AI sits inside customer service queues, software delivery pipelines, knowledge retrieval, analytics and automated workflows that run with nobody watching. When the model goes dark, a process stops. The queue stops clearing. The pipeline stops shipping. The report your Monday meeting runs on doesn't build.

Because the process depends on the model, the outage is an operating event. The people who feel it first sit outside the technology function. They're the ones trying to keep the work moving. An AI outage is a business-continuity event wearing a technology costume, and most continuity plans haven't caught up.

Key Point: Once a process depends on the model, an outage is an operating problem and needs an operating answer.

Does using more than one AI vendor give you resilience?

Adding a second or third provider is understandable, and it's useful. It solves a narrower problem than it seems to, and it can give you a false sense of safety. Two things go wrong.

• Correlated infrastructure. If your primary and your backup both depend on the same cloud region or orchestration service, one failure takes both. The redundancy was decorative.
• Correlated integration. The fallback was never wired into the real workflow, the prompts were tuned for one model's behaviour, and nobody has run the switch under load.

A backup you've never exercised is a hypothesis.

Resilience depends on whether a specific business process can continue when a specific dependency fails. The number of vendors you can name doesn't answer that. Only the answer to that question keeps you running at 2am.

Key Point: A second vendor only adds resilience if it doesn't share infrastructure or integration with the first.

Which four questions expose your real risk?

When I walk into an operation that has quietly wired AI into its core, I start with the work. The technology stack comes later. I ask four questions, in order.

1. If the model disappears at 2am, which business process stops?

Name the process, and make it concrete: "customer refunds stop being triaged," instead of "we lose some automation." Teams can usually answer this if you push. The pushing matters, because the vague version hides the exposure.

2. Who owns the fallback?

A person's name is a good answer. "IT," or a shrug, means you've found a hole. Ownership that lives everywhere lives nowhere. Continuity is an accountability question before it's a technical one, and an unowned fallback won't happen when the pressure is on.

3. What is the degraded mode?

When the model is gone, can the team keep going manually, slower but alive? Or does the whole thing seize? A degraded mode is a designed answer to that: reduced throughput, a manual checklist, a queue that holds work until service returns. With no degraded mode, the outage is a full stop.

4. How fast can you recover, and have you tested it?

Very few people can answer this one honestly. You can't estimate recovery time in a meeting. You measure it by running the failure. If you've never tested it, you have a guess with a confident voice.

Most teams can answer question one. Almost none can answer question four. The distance between those two answers is your actual risk.

Key Point: Question one is easy and question four is hard. Your risk sits between them.

How do you go from questions to an operating model?

The questions show the exposure. Turning it into resilience follows the same sequence I use for any high-consequence system: understand, remove, design, execute, measure.

1. Understand. Build the dependency map. For every process that touches AI, write down the provider, the underlying infrastructure where you can see it, and the business function that breaks if it fails. This is unglamorous and it's the whole game. You can't protect a dependency you haven't named.
2. Remove. Some dependencies shouldn't exist. If a process has quietly become reliant on a model for something that used to work fine without one, ask whether that reliance earns its risk. Not every automation is worth its failure mode. Removing a fragile dependency is often cheaper and more durable than defending it.
3. Design. For the dependencies that stay, design the fallback on purpose. Assign an owner by name. Define the degraded mode in writing so the team knows what "keep going" looks like without the model. Decide which failures trigger a switch and who has the authority to make the call. Design is where continuity stops being aspiration and becomes decisions someone can execute at speed.
4. Execute. Wire the fallback into the real workflow. A document doesn't count. If the plan is to switch providers, the switch has to be a path people can actually take, tested against the way work really flows. A fallback that only exists in a policy PDF will fail the first time it's needed.
5. Measure. Run the failure on purpose. Take the dependency out in a controlled window and watch what happens. Time the recovery. Find where the degraded mode breaks. Then fix it and run it again. Organisations that stay up during real outages have already survived rehearsed ones.

Key Point: Five steps, in order: understand, remove, design, execute, measure. Skipping the first one makes the rest guesswork.

What does a real degraded mode look like?

"Degraded mode" sounds operational and means nothing until someone writes it down. It's a set of decisions made in advance about how work continues at reduced capability. A usable one has three parts: a trigger, a procedure and an endpoint.

The trigger

The trigger is the condition that activates the mode. "The model is unavailable" is too vague. A usable trigger reads: "API calls to the primary endpoint return errors for more than five consecutive minutes, and the secondary endpoint also fails its health check." That's specific enough that the on-call person doesn't make a judgment call under pressure, and nobody can argue about it while the queue grows.

The procedure

The procedure is what the team actually does. Two examples:

• Customer-service routing: stop AI-assisted prioritisation, switch the queue to FIFO order, and have the team lead add a manual triage step for any ticket flagged "urgent" in the subject line.
• Software delivery pipeline: pause any stage that relies on automated code review, hold the release branch, and have engineering leads run a manual diff review against the last approved checkpoint.

The procedure doesn't need to be elegant. The person in the seat when the outage happens has to be able to run it.

The endpoint

The endpoint is the condition for returning to normal. Without one, teams stay in degraded mode long after the service recovers, because no one noticed or no one had the authority to call the all-clear. A usable endpoint: service restored and stable for 15 minutes, health check green, and a named person has signed off the return.

Written down, this feels obvious. Left to informal understanding, it produces three people doing three different things at 2am while the business waits.

Key Point: A degraded mode has a trigger, a procedure and an endpoint, and all three are written down before the outage.

Figure 2. A trigger, a procedure, an endpoint.

Why does the manual fallback fade faster than you expect?

Most degraded-mode plans assume the team fully understands the manual version of the process. That assumption erodes fast.

When AI handles routing, triage or summarisation for long enough, the manual version of that skill fades. The team knows how to review the model's output. They may no longer know how to produce the same judgment without it. That's no criticism of the team. Any tool that works reliably for a long stretch does this.

So rehearse on a schedule, and don't just document. A manual triage procedure that hasn't run in six months is a memory of a procedure, and memories under pressure are unreliable.

Quarterly fire drills can be small. Give one team two hours to run the manual version of a single process, then report where it broke. That teaches you more than any planning document. The failures that show up in a calm drill are the same ones that show up at 2am, and the calm ones can be fixed before they cost anything.

Key Point: Manual skills fade while AI works well, so the fallback only counts if the team has practised it recently.

How do you build the dependency map?

Organisations often skip the map because it feels like documentation work. It's the one thing that turns a vague sense of exposure into a list of decisions you can make.

Start with the process. A map built around tools gives you a list of vendors. A map built around processes shows which parts of the operation break, and in what order. That's the one worth having.

For each critical process, capture five things:

1. The process name and the team accountable for it. Name the human team, and treat the system as secondary. Accountability lives with people.
2. The AI touchpoint. Where exactly does the model enter the workflow? It might generate output a human reviews, or it might make a decision the system acts on automatically. Those carry different risk. A draft a human approves fails gracefully. A model routing a transaction no human touches doesn't.
3. The upstream dependency chain. Which provider, which region, which orchestration layer sits between your system and the model? A middleware platform, an API gateway or a managed LLM service is a dependency too. September showed this: the failure sat in a compute centre upstream of two of the three providers, and the model layer itself was fine.
4. The downstream consequence. If this touchpoint fails, what breaks first, and what breaks second? Sequence matters. A customer-service queue that stops routing tickets creates a recoverable backlog. An automated risk flag that stops firing creates a silent exposure. Write down the whole chain.
5. The current fallback. Be honest here. "The team would figure it out" isn't a fallback. A fallback is a named procedure, a named owner and a tested path. If none of those exist, write "none" and leave it there. That entry becomes the work.

The finished map will be uncomfortable to look at, and that discomfort is useful. Every blank cell is a decision your organisation has been putting off until the moment of failure. The map moves that decision into a meeting room, where it belongs.

Key Point: Map by process, and every blank cell becomes a decision you can make before an outage.

Figure 3. The dependency map, built around processes rather than tools.

Who owns AI continuity, and why isn't it the technology team?

There's a reflex to file all of this under IT and move on. That reflex is why so many continuity plans are fiction. The technology function can tell you which services are running. It can't tell you which business decisions are acceptable when they aren't. Whether refunds wait, whether the pipeline holds, whether you serve customers manually or pause: those are operating calls, and they belong to the people accountable for the operation.

Leadership has to decide, on purpose and in advance, what the business does when a dependency it doesn't control disappears. That's a governance decision about how the organisation continues under pressure. You can't hand it to whoever happens to hold the credentials.

A second accountability failure sits below the leadership question. Process owners often assume resilience is someone else's job:

• Client onboarding assumes engineering handled the AI dependency.
• Engineering assumes the vendor handled availability.
• The vendor's SLA guarantees uptime, which is a different thing from business continuity.

Each team has assumed the hole belongs to someone else, and nobody has closed it.

The structure that works is simple. Each critical process that depends on AI gets a named continuity owner who is not the technology lead. That owner makes sure the fallback is defined, tested and current. They don't need to understand the infrastructure. They need to know what the process requires to keep moving, and what authority they have to activate the degraded mode. That's a business question, so it has a business owner.

Key Point: IT detects the failure. The business decides what happens next, so a named business owner has to hold the fallback.

Figure 4. Detection sits with IT. Activation and the all-clear sit with the business.

How do you rehearse an AI outage?

Testing the failure is what separates organisations with real resilience from those with well-formatted documentation. Plenty of organisations have the documentation. Few have run the test.

A rehearsal needs a controlled window, a scoped process and honest measurement. It doesn't need a full production outage. Here's a sequence that works.

1. Choose one process. Start with the highest-consequence AI dependency on your map. The easy ones teach you nothing useful. The hard ones do.
2. Define the measurement criteria before you start. Decide what you want to find out. Useful questions:Write these down before you pull the plug. Pressure during a running drill produces motivated reasoning about what counts as success.
   • How long from trigger detection to degraded mode activation?
   • How long from degraded mode to the process running stably in manual?
   • What backlog builds during the transition?
   • What errors does the manual version produce that the automated version would catch?
3. Pull the dependency in a controlled window. Disable the AI touchpoint for a scoped process during a period of low but real traffic. A Thursday afternoon works, when the team is present, the work is real and errors are recoverable. A Sunday at midnight with no one watching teaches you less. Let the team activate the degraded mode as written. Don't coach them. Watch what happens.
4. Measure the actual numbers. Track time to detection, time to degraded mode activation, and work processed per hour in manual mode versus automated mode. Also count how many times someone deviated from the written procedure, and how many times someone said "I don't know what to do here." Those last two numbers matter most.
5. Run the post-drill review the same day. Hold it while the experience is fresh. Ask what broke, what was unclear and which assumption in the plan was wrong. Update the procedure before the review ends. A procedure updated in the room is more likely to be accurate than one a project manager updates three weeks later from notes.

After the first rehearsal, schedule the next one. The interval depends on how fast your processes and team composition change. Quarterly is a sensible default for high-consequence processes. Semi-annually is acceptable for lower-stakes ones. Never is unacceptable for any process you've decided is critical.

Key Point: One scoped drill with real measurements teaches you more than a stack of plans, and the numbers about hesitation tell you the most.

Figure 5. The rehearsal scorecard.

What does this look like in regulated financial services?

The principles apply across industries, and the consequences are sharpest in regulated environments. In financial services, an AI outage can be a regulatory event as well as an operational disruption.

Take a fund operations team that has embedded a model into its daily NAV reconciliation. The model flags discrepancies above a set threshold for human review. On a normal day it processes 400 line items and surfaces 12 for manual attention. When the model goes dark, those 400 items either wait or proceed without the flag layer.

• Waiting creates a settlement delay.
• Proceeding without the flag layer creates a silent control failure.

Neither outcome is acceptable under CPS 234 or equivalent operational resilience frameworks. A designed degraded mode avoids both: a rule-based threshold checker running on the existing data warehouse, no model required, covering the highest-risk line items during an outage. Coverage is lower than the model's, and it's enough to keep the control in place without the settlement delay.

A technology team working from a requirements document can't design that fallback. It takes the fund operations lead, the risk function and the technology team in the same conversation, deciding in advance what "sufficient" looks like under constraint.

That conversation is the governance work. The technical build is the easier part. Many organisations have it backwards: they invested in the tooling and skipped the governance. Tooling fails silently. Missing governance fails loudly, in front of a regulator.

Key Point: In regulated firms, a silent control failure is the real danger, and a designed degraded mode is how you prevent it.

Figure 6. Not every AI dependency carries equal weight.

What should you do this week?

You don't need a transformation programme to start. You need to name your exposure before the next outage does it for you.

1. Pick your three most important processes that touch AI.
2. Answer the four questions for each one: what stops, who owns the fallback, what the degraded mode is, and how fast you can recover.
3. Treat every question you can't answer as a task. Those answers are your task list.
4. Run it as a dependency mapping session with the process owners in the room, and avoid handing it to an IT architect to do alone.

If you're in a regulated environment, start with your Tier 1 processes, the ones where an untested fallback ends in a silent control failure. They tolerate vague answers least, and they cost the most when a vague answer meets a real outage.

The investment is smaller than the risk it offsets: one structured mapping session, one designed degraded mode, one rehearsal. That's the minimum version of treating AI resilience as a business-continuity function.

The next simultaneous outage will come. What's still open is whether you decide in advance what happens, or find out live at 2am with everyone watching. Right now it's a design choice.

Key Point: Three processes, four questions, one mapping session. You can start this week.

FAQs

Is using more than one AI model enough to survive an outage?

No. If your primary and backup providers share the same cloud region or orchestration service, one failure takes both. The backup also needs to be wired into the real workflow and tested under load.

What is a degraded mode?

It's a set of decisions made in advance about how work continues at reduced capability. It has a trigger, a procedure and an endpoint.

Who should own AI continuity?

A named continuity owner for each critical process, and that person is not the technology lead. The technology team detects the failure. The business decides what happens next.

How often should you rehearse an AI outage?

Quarterly for high-consequence processes, and semi-annually for lower-stakes ones. For any process you've called critical, never is too rare.

What is an AI dependency map?

It's a process-by-process record of the accountable team, the AI touchpoint, the upstream dependency chain, the downstream consequence and the current fallback. Build it around processes, and leave the tool list for later.

Why isn't vendor uptime the right measure?

Uptime tells you whether a service is running. It says nothing about whether your business process can keep moving when it isn't. An SLA guarantees uptime, and business continuity is a separate matter.

Where should a regulated firm start?

With its Tier 1 processes, the ones where an untested fallback could end in a silent control failure. Fund operations reconciliation is one example.

Key Takeaways

• Two of the three outages on 3 September 2026 shared a hidden dependency, and nobody could tell in the moment.
• More vendors don't equal more resilience when infrastructure and integration are correlated.
• Ask four questions per process: what stops, who owns the fallback, what the degraded mode is, and how fast you recover.
• A usable degraded mode has a trigger, a procedure and an endpoint, all written down.
• Manual skills fade, so rehearse the failure on a schedule and measure it.
• Each critical process needs a named business owner for continuity, outside the technology team.