Can Your AI Keep Working When an External Dependency Disappears?

Your AI assistant runs on local GPUs. Company documents stay inside your environment. The model answers questions without calling a public AI API.

Then an external service becomes unavailable.

Existing users can still ask questions, but a new user cannot sign in. A running model keeps responding, but a replacement container cannot start. Search works against yesterday’s documents, but new files cannot be processed because the parser uses a hosted endpoint.

The model is local. The workflow still depends on services outside your control.

These are illustrative failure scenarios, not results from a customer deployment. They expose a question every organisation adopting private or sovereign AI should ask:

Which business functions can we continue, for how long, and with which controls intact when a dependency disappears?

Why this question matters now

On 20 October 2026, Microsoft announced further sovereign cloud capabilities covering customer control, business continuity, and connected and disconnected operations. The announcement distinguishes available capabilities from previews and planned releases. It reinforces the need to assess the operating requirements of each workload. Read Microsoft’s announcement.

On 23 October, OpenAI described stronger containment for its internal frontier-model training and evaluation environments, including removing models’ live internet access. It also explained that the surrounding infrastructure retains necessary external connections. Restricting a model’s network access does not, by itself, make the entire platform air-gapped or operationally independent. These research conditions are distinct from customer use of released models. Read OpenAI’s technical account.

For enterprise teams, the practical implication is to examine the complete service: identity, data preparation, inference, tools, evidence, maintenance, and recovery.

My earlier article, Your AI Data Stays Local. Who Controls Everything Else?, explored those control boundaries. The next step is to test what happens when a dependency within that design becomes unavailable.

Start with the business function you must preserve

“The AI must keep working” is too vague to test.

A maintenance assistant might need to answer questions from an approved set of manuals during a connectivity outage. An agent that changes production records may need to stop if it cannot verify current permissions or obtain approval. A document-ingestion service might safely queue new files while an approved parser is unavailable.

Define the required behaviour before designing a fallback. An illustrative continuity requirement could be:

During an eight-hour loss of external connectivity, authorised operators must be able to retrieve approved maintenance guidance from the retained corpus. The service must preserve access controls, citations, and audit records. New document ingestion may pause. Actions requiring unavailable approval services must remain blocked.

Eight hours is a planning example, not a universal target. Set the duration, permitted degradation, and recovery objectives with the business owner.

The acceptance criteria should include both useful work and actions the system must refuse.

A running process is only the first test

A warm system can conceal dependencies. Models, container layers, credentials, signing keys, and application data may already be cached. A brief disconnection can therefore produce a reassuring result while leaving restart and recovery untested.

Assess five distinct capabilities:

Keep these results separate. Passing the first test does not establish the other four. A successful restore also needs functional and permission checks; a process reporting “healthy” is insufficient evidence that the business service has recovered.

Follow one request through the whole system

For a private document assistant, trace a user from sign-in to the final cited answer. Then trace ingestion, deployment, and restoration separately. For agents, include every tool and approval service they can invoke.

Use a dependency register that records purpose, operator, location, credentials, expiry conditions, failure behaviour, approved alternative, and accountable owner.

The following table is a starting point for a controlled exercise:

A component can introduce several dependencies. An “internal” service may still rely on an external identity provider, key service, DNS resolver, or supplier control plane.

Design the fallback without weakening the boundary

A fallback deserves the same review as the primary path.

If local inference fails, routing confidential documents to a public model API changes the processing boundary. It should only happen when the data classification, destination, and use are explicitly permitted. Otherwise, queue the request, offer an approved reduced service, or stop with an explanation.

A replacement model also needs evaluation. Different models can change answer quality, citation behaviour, tool arguments, and latency. Changing an embedding model may require rebuilding the index and reassessing retrieval.

Identity failures require particular care. Continuing indefinitely with stale permissions can preserve availability while exposing information to someone whose access was revoked. Define bounded permission freshness and an explicit response when current authority cannot be established. Emergency access must remain scoped, approved, and auditable.

For an agent, a timeout creates another problem: the external action may have completed even though its response was lost. Blind retries can duplicate changes. Use supported idempotency mechanisms, reconcile uncertain outcomes, and require human review where the result cannot be established.

A continuity test passes when the system performs permitted work and reliably refuses work whose required controls are unavailable.

Run a dependency-failure exercise

Start with one representative workflow in an isolated environment using synthetic or approved test data. Give the exercise an owner, a rollback procedure, and clear stop conditions.

1. Record a baseline. Pin the application, model, prompt, corpus, policy, and configuration versions. Capture normal quality, latency, access decisions, and audit behaviour.
2. Remove one dependency. Simulate an unavailable endpoint, denied access, or expired test credential. Confirm the intended failure was actually applied; a bypassed proxy or cached response can invalidate the exercise.
3. Exercise different lifecycle states. Test an existing session, a fresh login, a token renewal, a process restart, and a replacement instance where relevant. Use short-lived test credentials rather than changing clocks on shared infrastructure.
4. Test permitted and forbidden work. Include an authorised query, a denied-document query, an unavailable tool, a missing approval, and a request for which no approved fallback exists.
5. Restore and reconcile. Confirm queued work, retries, permissions, and audit records remain consistent. Measure recovery against the agreed objectives.
6. Retain the result. Record expected and observed behaviour, evidence references, gaps, an accountable owner, and a retest date. Mark untested cases as unverified.

After individual failures are understood, test selected combinations that reflect the business scenario. Independent component tests cannot establish what happens during a wider connectivity loss.

Publish a bounded claim that evidence can support

“Works offline” leaves too much unspecified. A more useful result names the function, duration, conditions, and limitations.

For example, a hypothetical result could read:

The maintenance assistant completed the agreed query set during an eight-hour external-connectivity outage using approved local artifacts and the retained corpus. Authorised users received cited answers, denied-document tests remained blocked, and one replacement instance started successfully. New ingestion was unavailable. Longer outages and full backup restoration were not tested.

That statement gives an operator a usable boundary. It does not claim indefinite independence, complete security, or regulatory certification.

Attach the result to the system’s evidence record, alongside the tested versions, expiry assumptions, recovery objectives, and accepted gaps. Retest after changes that affect identity, routing, models, artifacts, or deployment.

Make continuity part of the architecture decision

Some workloads can accept a managed-service outage. Others need a limited local operating mode. A smaller group needs a complete disconnected deployment, supported by retained artifacts, local operating services, and trained staff.

Choose the design around the business function and the controls it must preserve. Budget for the engineering and ongoing testing that the chosen independence requires.

SovAIHub’s Internal Artifact Supply Chain and Sovereign EvalOps resources provide starting points for artifact planning and release evidence. The AI System Passport Builder can document the system and reference its continuity evidence.

For a focused review, bring one workflow, its dependency map, and the outage scenario you need to survive to a Sovereign AI Architecture Review.

Choose one critical workflow. Remove one dependency in a controlled test. Record what continues, what stops, and whether the controls survive.

---

Sources reviewed on 25 October 2026. Vendor announcements provide context and are not evidence that a particular deployment meets its continuity requirements. The scenarios, duration, and sample result in this article are illustrative; no customer test results are claimed.