Part of the AI, Future and War series. Analysis and hypothetical examples are identified in the text.
Essential services need a usable fallback
AI may help infrastructure operators interpret maintenance data or prioritise service incidents. The harder question is what happens when the model, its data connection or a supporting cloud service becomes unavailable. During conflict, a digital dependency can fail at the same time as staffing, communications and electricity are under pressure.
Joint guidance published by the Australian Signals Directorate and international partners addresses secure deployment of externally developed AI systems, particularly on premises and in private cloud settings. It is a useful security reference for those deployments; it should not be presented as a complete operational-resilience standard for every AI service. ASD and international partners: Deploying AI systems securely
Map the whole service chain
A risk review should begin with the service people need, such as a functioning hospital appointment system or a water utility's maintenance process. Then identify the software, data suppliers, identity systems and human skills supporting it. Listing the main model vendor alone will miss common dependencies that can interrupt several services together.
This article proposes distinguishing loss of functionality from loss of trust. A system may remain online while its inputs become unreliable. Continuing to use confident but stale recommendations can be more damaging than an obvious outage because staff may not recognise the need to switch procedures.
Design degraded operation deliberately
A fallback is only credible if someone has rehearsed it. A procedure that requires unavailable specialists, an expired software licence or an inaccessible data export will not provide continuity. Teams should determine the minimum acceptable service, the information needed to deliver it and the time for which that arrangement can be sustained.
Consider a hypothetical utility using AI to prioritise routine maintenance. If its external analytics service fails, trained staff could temporarily return to a documented inspection schedule. The exercise should test workload and safety constraints rather than assume that manual operation can absorb unlimited demand. This is an illustrative planning example, not engineering advice for a particular facility.
Restrict authority before disruption occurs
An advisory tool and a system authorised to change operations have different risk profiles. Organisations should document which actions require human approval and which permissions can be withdrawn quickly. Access should be limited to the task, and consequential changes should leave records that reviewers can understand.
Incident plans should identify who can suspend the AI component without stopping every supporting service. They should also set out how to notify affected users and how to decide whether restored data are trustworthy. Recovery is incomplete if the system resumes operation with an unresolved integrity problem.
Prove recovery, not only availability
An availability percentage describes ordinary operation poorly when the main concern is a rare, compound disruption. A more informative exercise tests restoration from a clean baseline, retrieval of essential records and the time needed to resume a minimum service. Record unsuccessful steps and revise the plan.
The strategic benefit of AI should be measured alongside the dependence it creates. Resilient adoption means retaining enough knowledge, authority and tested alternatives to serve the public when the preferred digital workflow is unavailable. It also means accepting that, in some applications, a simpler tool may be easier to sustain under stress.