A clinical AI service should make a material loss of capability visible and limit its behaviour accordingly. Continuing to produce fluent text is not necessarily a safe fallback. If retrieval, patient context or an action-confirmation service is unavailable, users need to know which promises the system can no longer support before they rely on its output.
An outage does not have to look like a blank screen
A complete loss of service is obvious. Partial failure can be harder to interpret. An assistant might still generate an answer after losing its evidence-retrieval component, or continue drafting after the connection needed to submit an action has failed.
The user may experience a normal-looking response while the evidential or operational basis has changed. That is the specific concern behind a silent downgrade: not simply slower software, but a different service presented as if it were unchanged.
A proposed resilience assessment should therefore examine the dependencies behind each capability. The question is not only whether the application loads. It is whether the information, checks and external confirmations required for the task are available.
Define modes around capability, not colour alone
A coloured status indicator can help, but it needs a meaning the user can act on. The following is a proposed mode specification rather than a description of any existing product:
| Mode | What remains available | What should change for the user |
|---|---|---|
| Fully supported | Required sources, context and checks are functioning | Use within the approved scope |
| Reference-limited | A required evidence source cannot be retrieved | Do not present an unsupported answer as source-verified |
| Draft-only | Content can be prepared but the action connection is unavailable | Keep the task visibly uncommitted |
| Suspended | A necessary safeguard or reliable context is unavailable | Use the approved alternative pathway |
The labels are less important than the boundaries. A system should not offer a reassuring badge while hiding the practical consequence in a technical log.
A fictional reference failure
Imagine a fictional medicines-information assistant that usually retrieves current source material. Its retrieval service fails, but the underlying language model remains available. The assistant can still write a plausible explanation.
Whether any answer is appropriate now depends on the intended service and controls. If the product's claim is that the answer is grounded in retrieved material, it should not quietly imply that the same verification occurred. It may be appropriate to provide a clear limitation, direct the clinician to the original source or decline the unsupported task.
This example does not allege that a named service behaves this way. It illustrates why a fallback must be assessed against the promise made to the user, not merely against the ability to generate output.
Substituting a model changes the question
Switching to another model can restore availability, but it does not automatically preserve behaviour. The replacement may handle uncertainty, source use or structured actions differently. A substitution should therefore be evaluated as part of the designed fallback, not improvised invisibly during an incident.
The NCSC's secure-operation and maintenance guidance, published in November 2023, recognises that changes to models, data and prompts can alter system behaviour. That supports testing degraded modes and substitutions, rather than assuming they are equivalent because the interface remains familiar.
Where a fallback has narrower evidence or capability, describe that narrower scope. Do not borrow the primary system's evaluation results without establishing that they apply.
The safest answer may be that the task is unfinished
For connected workflows, the crucial distinction is often between preparing, submitting, accepting and completing an action. A network interruption can leave the application uncertain about which stage was reached.
In a fictional appointment workflow, the assistant might have sent a request but not received a confirmation. Retrying blindly could duplicate it; declaring success could leave the patient without an appointment. A safer design preserves the uncertain state and provides a reconciliation route.
The local team should agree who owns that unresolved work and where it remains visible. A patient-facing message should accurately describe the status rather than transform a technical attempt into a promise that care has been arranged.
Build the alternative around continuing care
The US SAFER Guides, checked on 10 October 2026, include contingency planning for electronic health record unavailability. They are a useful reference for resilience thinking, not a substitute for UK organisational requirements or an AI-specific approval process.
For a local AI service, the proposed fallback should identify the tasks that can continue through existing clinical systems, the tasks requiring manual coordination and the work that must be deferred. It should also state how staff obtain the information needed to continue without copying confidential material into unapproved alternatives.
A technically available consumer chatbot is not automatically an acceptable substitute for an approved clinical workflow. Availability answers whether something can be used, not whether it should process the information or perform the task.
Test restoration, not only failure
Recovery can introduce its own errors. Drafts prepared during an outage may no longer reflect the current plan. Queued actions may be duplicated by manual work undertaken in the meantime. A restored connection may trigger activity that staff assumed had been cancelled.
A proposed recovery exercise should therefore reconcile pending tasks before unrestricted processing resumes. Identify what was completed manually, what remains necessary and what requires fresh clinical review. Record the decision about restarting automated actions rather than treating reconnection as sufficient authorisation.
Staff should also know whether they need to revisit answers produced during a degraded period. The appropriate scope depends on the affected component and the consequences of its failure, not simply the length of the outage.
Make limitations usable during a busy session
An effective message states the unavailable capability, the affected task and the appropriate next step. "Something went wrong" leaves too much interpretation to the clinician. "The referral has not been confirmed; it remains in the unresolved queue" is more operationally meaningful, provided the system can substantiate that status.
For reference tools, including iatroX, users should distinguish an accessible explanation from a verified source-based answer. iatroX's published methodology, checked on 10 October 2026, describes intended safeguards; it is not a published test of every possible outage behaviour.
A useful team-learning exercise is to identify which missing component would make a fictional output unsuitable for its intended purpose. The goal is informed fallback, not a requirement that clinicians become experts in cloud architecture.
Frequently asked questions
Is an AI service safe to use if it still produces answers during an outage?
Not necessarily. The organisation needs to know whether the sources, context and checks required for that task are still functioning.
Can a different model be used as an automatic fallback?
It may be possible within a properly assessed design, but the substitution should not silently inherit evidence or capability claims that have not been established for it.
What should happen to actions whose completion is uncertain?
They should remain visibly unresolved with named ownership and a reconciliation process. Neither repeated submission nor a conversational claim of success is an adequate substitute for confirmation.
Explore clinical questions with visible supporting sources →