What Happens When the AI Goes Away?

Imagine a business that has delivered on its AI business case.

Routine work moves faster. Customers get answers sooner. Costs have fallen, and a smaller team handles the exceptions. The benefits report is unusually cheerful. For once, the promised transformation has made it out of the presentation and into the building.

Then, one morning, the AI becomes unavailable.

Perhaps the provider has a problem. Perhaps a connection fails. Or perhaps the servers are working perfectly, but a government decision has changed who is allowed to use them.

The customers continue arriving. Their deadlines remain impressively uninterested in the explanation.

Someone opens the continuity plan. It says the business will revert to manual processing.

Unfortunately, manual processing accepted a redundancy package last quarter.

This is a hypothetical business, but the question deserves a place in a real approval meeting: what capability will remain if we lose access to the AI we have built the business around?

In Who Owns the Future?, I explored who controls AI and who receives its gains. This follows one consequence down to the organisation making promises to customers.

I use these tools extensively. I want the useful work they make possible. I would also like the continuity plan to describe an organisation that still exists.

The people in the fallback plan

A staffing decision changes more than the salary bill. It changes who knows how the work gets done, how much spare capacity remains and who can handle the case that does not fit the procedure.

An organisation might keep enough people to supervise an automated process while losing the capacity to perform that process without automation. Those are different jobs. Checking selected outputs does not establish that the reviewer could complete the entire workload from scratch.

There can also be knowledge that never made it into the instructions: which records are unreliable, why a particular exception matters, or who needs to be called when the answer looks technically correct and practically ridiculous.

If we want that knowledge available during a disruption, somebody has to retain it and keep practising. A procedure in a folder is useful. Its ability to answer the phone is limited.

This does not mean keeping every previous role forever. AI can improve documentation, spread knowledge and help more people perform work competently. Those benefits could make an organisation more resilient. The evidence should determine how much human capacity, alternative technology or contracted support it needs.

The test belongs before the staffing reduction. Give the proposed remaining team representative work, remove access to the main AI in a controlled exercise, and measure what they can actually complete. Include difficult cases and the effort required to check them.

Then put the cost of maintaining that capability into the business case. Otherwise, some of the apparent saving may be the cost of recovery that nobody has budgeted for yet.

The system is back. The work is still waiting.

Consider an illustrative service receiving 1,000 cases each working day.

Without its AI, it can safely complete 300. Over a 10-working-day disruption, it accumulates 7,000 unfinished cases.

When access returns, suppose the service can process 1,300 cases a day. That sounds comfortably above normal demand. But after handling the 1,000 new arrivals, only 300 places remain for the backlog. Clearing it takes about 24 further working days.

If restored capacity is only 1,000, the backlog does not shrink at all.

These are invented numbers to show the mechanism, with equal-sized cases, constant demand and no additional rework. Real cases can become harder while they wait. People call again, information changes, deadlines pass and staff spend time explaining the delay instead of reducing it.

Select the graphic to open the full-size version.

The provider's incident may be closed while the business is still dealing with its consequences.

A recovery plan needs to cover that period too. Who supplies the extra capacity? Which cases come first? How do we reconcile work completed during the disruption without losing records or doing the same thing twice?

Some businesses never had the old team

There is another route to the same exposure.

New businesses are being built around AI-delivered services. Y Combinator's company directory includes businesses offering agents and automated business work.

For a business selling AI-handled customer support, document processing or software production, loss of model access could interrupt the product itself. Revenue may stop while wages, rent, refunds and customer obligations remain.

An established organisation might have dismantled its previous operating capability. A new business might never have had one.

‘Go back to how we did it before’ is an awkward instruction when before was three people, a domain name and a very encouraging demo.

I would not assume these businesses will always suffer the greatest losses. A small company with portable software and a tested alternative could adapt faster than a large organisation whose systems have spent 20 years becoming mutually indispensable. Exposure depends on what the company relies on, how readily it can substitute it and how long it can withstand interrupted income.

There is a consequence for buyers as well. The supplier you contract with may depend on an AI provider you have never assessed. Buying from several small firms may still leave your critical services relying on the same underlying platform.

That dependency belongs in the purchasing conversation, before it becomes the explanation in the incident report.

Access can change while the machinery still works

We already have a direct example involving AI access.

Anthropic says a US export-control directive on 12 June 2026 prohibited foreign-national access to Fable 5 and Mythos 5. It suspended both models for all customers because it could not immediately verify nationality. Other Anthropic models remained available. The controls were lifted on 30 June, with general Fable access restored on 1 July. Suspension statement, restoration account.

That was a restriction on particular models. It does not establish that every US provider will be blocked together. It does establish that an organisation's access can change abruptly for reasons beyond its own technology team.

October restrictions on Ukraine's Starshield service, which uses the Starlink network, affected moving terminals without disconnecting all of Ukraine. Reuters reported on 15 October that officials said the instruction came from inside the White House, but the decision-maker was unidentified and a senior US official denied a presidential request. AP reported the following day that Ukraine was seeking removal of the speed cap. Reuters report, AP report.

The operational lesson is that having equipment, a contract and an urgent need does not necessarily give the customer control over continued service.

Sometimes the connection really does disappear

Physical connectivity brings a separate set of risks, including accidental damage and deliberate disruption by a hostile actor.

We do not need to settle the attribution of every suspected sabotage incident to include deliberate damage in a continuity exercise. Nor should we turn every broken cable into proof of a foreign-government operation. NATO's Baltic Sentry activity, launched in January 2025 to help protect undersea infrastructure, shows that the threat is receiving practical attention. NATO's maritime security account.

Tasmania offers a useful local example of what communications failure can affect. On 1 March 2022, separate civil works cut two fibre connections between Tasmania and mainland Australia, at locations on land. AEMO lost remote visibility and suspended Tasmania's electricity spot market for six hours and 40 minutes. Local control continued, and no generation or load was lost because of the incident. AEMO's final report.

The retained local capability matters as much as the disruption. The electricity system continued operating while part of its wider coordination machinery was unavailable.

A cable failure does not automatically disconnect a country. Traffic may be rerouted, spare capacity may exist and some services may remain local. The practical question is which connections your service needs, what remains after a failure, and whether that remaining capacity is enough.

The data centre can be attacked too

A civilian business can lose an essential service without being the intended target. The data centre at the other end of its connection is part of that exposure.

Reporting on 11 and 12 October 2026 described Ukrainian strikes on three Yandex data centres in Russia, with disruption extending into cloud services and everyday applications. These followed Russian attacks on Ukrainian data centres and telecommunications infrastructure. Euronews, The Record.

In its 26 February statement about its Pentagon dispute, Anthropic said Claude already supported intelligence analysis and operational planning. Its stated objections concerned mass domestic surveillance and fully autonomous weapons, rather than military use generally. Anthropic's statement.

My inference is straightforward: military reliance on AI gives an adversary a reason to disrupt the infrastructure supporting it. We should include physical attacks and destructive cyber incidents in planning for a conflict involving the United States or Australia. Which services would be affected depends on where they actually run and what redundancy survives. Losing one building does not automatically disable an entire provider.

The cyber concern already appears in Australian guidance. ASD warns that state-backed actors routinely target Australian critical-infrastructure networks, potentially preparing to disrupt or damage them during a crisis or conflict. ASD's CI Fortify guidance.

For the business, the useful test is whether the same disruption could disable both its primary service and its fallback. Moving everything into one Australian building would still leave it in one building.

An Australian address does not settle control

Even when the hardware survives, access can still be withdrawn.

A US-controlled AI service might run in an Australian data centre. That could reduce exposure to some international connectivity failures. It does not, by itself, remove dependence on the provider's permission to supply the service.

If a restriction covers that provider's service to Australian customers, the equipment could be perfectly healthy and still unavailable to them.

This is why two different suppliers are not necessarily two independent alternatives. They might share a model, infrastructure, an identity service or exposure to the same government restriction.

My proposed test for a critical operation is therefore broader than ‘can we switch providers?’:

Can the service continue if the primary provider and every alternative covered by the same restriction become unavailable, even while their Australian data centres remain operational?

That is a planning scenario, not a prediction of a blanket US cutoff. Testing it reveals dependencies that a routine outage exercise may miss. The same reasoning applies to relevant restrictions from other jurisdictions.

Where something runs, who controls it and whether we can keep using it are separate questions. A postcode cannot answer all of them.

What open weights change

With a closed model delivered as a hosted service, we buy access to a capability the provider operates. We generally do not receive a copy we can run ourselves.

Open-weight models give us another option. Their trained parameters, the numerical values learned during training, are made available under specified terms so others can run the model.

That can let an organisation prepare a usable copy on infrastructure it controls. It no longer needs the original developer's hosted service to authorise every request.

The licence still matters. Downloadable weights do not automatically mean unrestricted use or fully open-source AI. The Open Source Initiative's definition requires more, including relevant code and information about the training data. OSI definition.

It also matters how we use the model:

The model's label does not determine who controls the service. An open-weight model hosted by a supplier covered by the same restriction may become unavailable too.

A local model is helpful only if it can reach the records, applications and permissions needed to do the job. If those still depend on unavailable external services, the local machine may be ready to answer questions about a business it can no longer see.

Select the graphic to open the full-size version.

Dedicated hardware also needs power, maintenance, security and people who can operate it. One server can become a new point of failure. Australian cyber guidance covers these operating responsibilities, including checking model supply chains and maintaining controls after deployment. Secure AI deployment guidance.

And holding weights is not immunity from applicable law. The alternative must remain lawful to use. Independence from a hosted service and permission to operate the model are both part of the assessment.

Does every critical system need to start with an open model?

I would set a service requirement first: critical operations must have a funded, tested way to continue at defined safe service levels when their primary AI and similarly exposed alternatives are unavailable.

An independently operated open-weight model is a strong candidate for meeting that requirement. It could be the primary system where sustained independence matters and its performance is sufficient. Or it could preserve essential work while a more capable hosted model handles normal operations.

A proven human process or conventional software might meet the requirement too. The right arrangement depends on the work and the consequences of interruption.

For example, a document service might preserve intake, reliable field extraction and routing to qualified staff while pausing complex analysis. The fallback offers fewer functions, but the essential ones still meet their required standard.

That distinction needs care. Lower throughput or fewer features may be acceptable. Quietly lowering a required safety or accuracy threshold is a different decision, with different consequences.

If only one remote model can perform an essential function to the necessary standard, installing a smaller model does not make the dependency disappear. We need to redesign the workflow, retain another qualified delivery method or limit what we commit to until a credible alternative exists.

Open weights can give us more control. They do not award us competence on installation.

Migration starts before the incident

There are two plans to consider. One explains how to change suppliers over time. The other explains what happens while today's service is unavailable. A well-managed six-month migration can be a perfectly good exit strategy and a remarkably unhelpful response to tomorrow's deadline.

I would build the immediate alternative around five pieces of work.

Define the service we are preserving. Name the outputs people need, the maximum interruption, the acceptable backlog and the quality standard. Decide which activities can pause. ‘Keep the business running’ leaves a large amount of interpretation to people who will already be having a difficult day.

Keep our business context usable elsewhere. Negotiate export and exit rights when buying the service, then verify the exports are usable. Retain authorised copies of the records, workflow state, instructions, permissions and audit history that make the service work. Plan for components that may need rebuilding. A search index or model-specific customisation cannot simply be assumed to transfer. Model access without the surrounding business knowledge is an incomplete replacement.

Test the alternative on the whole task. Use ordinary work, exceptions and realistic volumes. Check what it retrieves, what it produces and what it is allowed to do. If an agent can take actions, verify those actions and the controls around them. Two models accepting the same request format does not establish that they behave the same way.

Prepare enough capacity to activate in time. For local operation, that means having the approved model and supporting software available beforehand, with suitable hardware and trained operators. Check for external licence checks, identity services and downloads the system quietly expects. For a hosted alternative, secure credible capacity arrangements. If a disruption affects many customers together, everybody may be trying to move into the same spare room.

Exercise the loss and the return. Test lost external connectivity and, separately, withdrawn provider access while the network remains healthy. Include loss of a hosting site and a cyber incident that makes shared administration or backups untrustworthy. Use a controlled environment and the staffing level the business actually plans to retain. Then test reconciliation, duplicate handling and backlog clearance. Repeat after material changes to the model, workflow or staffing.

The business service owner should own this outcome, with technology, workforce and procurement teams responsible for their parts. Someone needs to be able to say what will continue, who will deliver it and what evidence supports that claim.

‘We have another subscription’ is an input to that conversation. It is a fairly short conversation if nobody has tested it.

What governments should require and fund

Governments have a particular reason to care when interrupted services affect health, payments, transport or people's access to support. Criticality should follow the consequences of failure, including when a small supplier performs an essential part of the service.

My recommendation is to make demonstrated continuity a condition of approving and reviewing critical AI-dependent services, before removing the existing delivery capability. Require an accountable owner, a defined minimum service, a usable alternative and evidence that it can start and operate within the required time. If a material gap remains, retain the existing capability or limit the rollout while the gap is addressed. A migration plan with an unfunded line marked ‘future state’ should not pass this test.

There is already Australian policy and guidance to build on.

NSW's AI Operational Policy, section 5.4.2(j), addresses continuity and sovereign capability. It requires the ability to operate or transition government services if an AI solution, model or service becomes unavailable or materially changes. It does not prescribe another frontier LLM as the fallback. NSW policy, printed page 11.

The federal government's architecture checklist covers AI dependencies, portability and exit testing. The checklist itself is labelled non-mandatory. Australian Government checklist. For APRA-regulated financial institutions, CPS 230 already requires continuity within defined tolerances and testing against severe but plausible disruptions. APRA CPS 230.

ASD's CI Fortify addresses operational technology, the systems that control physical processes. It recommends testing whether vital operational technology and its supporting systems can remain isolated for three months while critical services continue. It also calls for the ability to rebuild them. This is guidance for critical-infrastructure operators, not a universal three-month requirement for every AI application. CI Fortify.

These have different scopes. Together, they provide a basis for a more useful question than whether somebody has written a policy: what capability has been funded, exercised and demonstrated?

The policy text cannot tell us whether each agency has a working alternative. That requires evidence from implementation and exercises. I would want that evidence to include a restriction affecting relevant US-controlled services together, as well as infrastructure failure. An exercise that changes the supplier but preserves the same exposure has not answered that question.

There is an investment case alongside the requirement. Shared testing facilities, independent domestic operating capacity, trained specialists and reusable deployment arrangements could make resilience affordable across agencies and smaller essential-service suppliers. Funding processors alone leaves quite a few people and procedures missing from the photograph.

The federal government could coordinate common tests, procurement expectations and investment across sectors. States and territories could apply them to their services, fund the delivery arrangements and exercise them with suppliers. Existing regulators and assurance bodies should be involved so the result fits the service's actual obligations.

Shared provision also needs diversity. One national platform could become another common point of failure. And support for essential capability should be justified by public benefit, rather than becoming a promise to underwrite every business that puts AI in its pitch deck.

Before we sign off the saving

There is a fair objection to all this: businesses already depend on electricity, networks and other people's software. Maintaining alternatives costs money, and complete self-sufficiency is unrealistic.

I agree. The aim is proportionate resilience for the services people depend on. AI may help us achieve it. Portable models, better documentation and more capable staff could make recovery easier than it was before.

What concerns me is counting the benefit of dependence while leaving its consequences untested, particularly when we remove the people or alternatives that could absorb a failure.

At the next approval meeting, I would put one critical service on the table. Specify the proposed staffing level, which dependency has disappeared and how long it will be unavailable. Ask the team to demonstrate what customers will still receive, at what standard, and how the organisation will recover afterwards.

Then the business case can contain both the productivity gain and the cost of keeping its promises.

If your AI access disappeared tomorrow, which promises to your customers could you still keep?

Sources checked on 17 and 18 October 2026. The opening business and backlog calculation are illustrative. The service-continuity recommendations are my judgement, not a claim that every organisation faces the same risk.