Clinical AI Downtime, Degraded Performance and Safe Fallback in Viet Nam: How Healthcare Organizations Should Maintain Safe Care When AI Is Unavailable or Unreliable
IMPLEMENTATION INSIGHTS
Clinical AI Downtime, Degraded Performance and Safe Fallback in Viet Nam: How Healthcare Organizations Should Maintain Safe Care When AI Is Unavailable or Unreliable
PRACTICAL FRAMEWORK & TOOL
Last reviewed: 2 October 2026
A clinical AI system does not need to fail completely to create a patient-safety problem. Sometimes the service is simply unavailable. But an AI system can also remain online while receiving incomplete data, responding too slowly, producing stale outputs, operating through a broken integration or behaving differently from what the organization expects.
The second situation can be harder to manage because the technology still appears to be working. Consider an AI system that helps prioritize radiology studies. A complete outage is usually obvious: no AI result appears. But what if the interface remains active while the data feed is incomplete? What if predictions continue to appear but arrive too late to be clinically useful? What if an integration problem sends incorrect data? Or what if the system continues to produce confident-looking outputs even though its performance or operating conditions have changed?
For healthcare organizations, the important question is therefore not simply “What do we do when the AI goes down?” It is “How do we maintain safe care whenever the AI is unavailable, impaired or no longer reliable enough for its intended use?”
As AI becomes more deeply embedded in clinical workflows, this becomes a healthcare continuity issue rather than only an IT issue. The organization needs to know what care looks like without the AI, how it recognizes when fallback is needed, who has authority to restrict or suspend use, how affected users are informed, and what evidence is needed before routine reliance resumes.
Downtime and degraded operation are different safety problems
A useful starting point is to distinguish unavailability from unreliability. An unavailable system is usually easier to recognize. A cloud service may be down, an application may fail to load, a network connection may be lost or a vendor platform may become inaccessible. Users know that the AI is unavailable and can, at least in principle, switch to another process.
Degraded operation is more subtle. The system may continue producing outputs even though an important dependency has failed or the system is no longer operating within conditions that support safe use. Examples include incomplete or corrupted inputs, delayed data feeds, broken interfaces, abnormal latency, stale predictions, material changes in patient population or workflow, configuration problems, cybersecurity containment measures or other conditions that reduce confidence in the AI output.
This distinction matters because a system that is visibly unavailable may be safer than one that is silently unreliable. For continuity planning, healthcare organizations therefore need to answer two different questions: Can we detect when the AI is unavailable? And can we detect when it is still available but should no longer be trusted for its intended clinical role?
Viet Nam’s AI framework makes reliability, monitoring and incident response directly relevant
Viet Nam’s Law on Artificial Intelligence No. 134/2025/QH15 has been effective since 1 March 2026, with Decree No. 142/2026/NĐ-CP effective since 1 May 2026. The legislation does not create a general statutory concept called a “clinical AI downtime plan,” and this article should not be read as suggesting that every healthcare AI system is legally required to use the same fallback framework.
Several provisions nevertheless make reliability, monitoring, human intervention and incident management directly relevant to healthcare AI governance. Article 6 of the AI Law requires stricter risk management for AI applications in essential fields that directly affect life and health. For healthcare, the Law specifically identifies patient safety, reliability under real-world conditions and protection of health data. For legally high-risk AI, the Law and Decree add more specific ongoing requirements concerning monitoring, risk management, human intervention and incident response.
Decree No. 142 also establishes a serious-incident reporting framework in Article 19. A serious AI incident is an event occurring during operation that causes death or serious harm to health, significant property damage or serious disruption to an organization, serious infringement of human rights or lawful interests, or serious disruption of public or essential services or effects on national security, social order or safety. Importantly, Article 19 is framed around serious incidents of AI systems; it is not limited only to systems classified as high-risk.
When such a serious incident occurs, deployers and users must promptly record it, take necessary measures to limit the consequences and notify the provider. A provider or deployer must submit a preliminary report through the AI single-window portal within 72 hours for urgent serious incidents involving death or serious harm to health, serious disruption of public or essential services or national-security/social-order effects, and uncontrollable serious infringements of rights. Other serious incidents are subject to a five-working-day preliminary-reporting period.
These periods run from the point at which the organization or individual has sufficient initial information to conclude that the incident has actually occurred and is highly likely to originate from an AI-system fault; a full technical investigation does not need to be completed first. The Decree also expressly states that submitting the preliminary report is not an admission of technical fault or legal liability. Providers and deployers must preserve relevant logs, data and information, and the official remediation report is due within 15 days after the preliminary report.
This requires an important qualification: an AI outage, delay or episode of degraded performance is not automatically a serious incident under Decree No. 142. The statutory reporting regime is triggered when the event reaches the legal serious-incident threshold. An ordinary service interruption may still require internal clinical action, incident review or vendor escalation without triggering Article 19.
Where an event is also reportable under cybersecurity, personal-data or other specialized legislation, those requirements may apply in parallel. The practical principle is therefore broader than legal reporting: healthcare organizations need to recognize when continued AI use is unsafe and intervene before a technical problem becomes patient harm.
Safe fallback is relevant beyond legally high-risk AI
Decision No. 33/2026/QĐ-TTg establishes Viet Nam’s current statutory high-risk list and has been effective since 15 August 2026. The specific legal obligations attached to high-risk AI should not be automatically imposed on every other AI system merely because a healthcare organization considers it clinically important.
Internal patient-safety governance, however, can appropriately go beyond the statutory minimum. An AI system outside the current high-risk list may still become important to diagnosis, triage, workflow prioritization, documentation or another clinical process. If staff and workflows become dependent on it, an outage or silent degradation can create significant patient-safety consequences even though its statutory classification has not changed.
Safe-fallback planning is therefore not another legal risk classification. It answers a healthcare question:
If this AI can no longer support care safely, how will the organization continue caring for patients?
Start with dependencies, then define the safe state
Clinical AI rarely operates alone. A system may depend on an electronic health record, laboratory information system, PACS, imaging device, network, identity-management service, cloud platform, API, database, vendor service, data pipeline or another application. It may also depend on correct timestamps, coding conventions, device settings or upstream workflows that users rarely see.
An AI system can therefore become unsafe even when the underlying model itself is functioning as designed. For each clinically significant use case, the organization should understand the dependency chain from source data to clinical action:
patient or device data → source system → interface or data pipeline → AI service → returned output → user interface → clinician interpretation → downstream action
A failure at any point can change the safety of the whole workflow. Dependency mapping is therefore more useful than asking only whether “the AI server is online.” The organization should understand which dependencies are essential, which have redundancy, which are under internal control and which rely on external providers. Particular attention should be paid to single points of failure. A fallback pathway that depends on the same failed network, cloud service or interface as the primary pathway is not genuinely independent.
The next question is what the system and workflow should do when confidence in safe operation is lost. This is the safe state. For some AI applications, the safe state may be to stop displaying recommendations. For others, the underlying system can remain accessible while the AI feature clearly shows that it is impaired. In another workflow, automated action may need to stop while underlying clinical information remains available for manual review.
There is no universal rule that every AI application should simply “fail closed” or “fail open.” Blocking a misleading AI output may protect patients, while completely blocking access to an underlying clinical application because an optional AI feature has failed could itself delay care.
The safe state therefore needs to be designed around the clinical consequence, not only the technical architecture. A useful question is: If we no longer trust the AI output, what should users see, what should stop automatically, and what safe pathway should become available instead?
That decision is much easier to make before an outage than during one.
A fallback process must still work, and people must still know how to use it
“Revert to the manual process” sounds simple in a policy. In practice, it may be one of the most fragile parts of a continuity plan.
Once AI becomes embedded in routine work, the previous process can gradually change or disappear. Staff may become less familiar with it. Patient volume may have increased because AI enabled greater throughput. Information that was once displayed directly may now be surfaced through an AI-enabled interface. Staffing assumptions may have changed around the new workflow.
A radiology department may technically still be able to interpret studies without AI, but its downtime workload may be substantially different if AI has been prioritizing worklists for years. A documentation assistant may appear nonessential until staff discover that workflows and staffing patterns have adapted around it. A surveillance system may have replaced a manual process that newer staff have rarely used.
Healthcare organizations should therefore ask not only whether a fallback exists on paper, but whether people can actually perform it at the necessary scale, speed and quality.
A 2026 NEJM AI article on human-factors risks in AI-enabled medical devices identifies safe fallback pathways, training to mitigate deskilling, workflow integration, real-world monitoring and communication of changes among relevant risk-management measures. The paper focuses on AI-enabled medical devices, so its recommendations should not be treated as requirements for every clinical AI application; its human-factors principles are nevertheless highly relevant to clinically consequential AI fallback design.
Human capability can itself become a hidden dependency. Repeated use of AI may reduce how often some underlying manual skills are exercised. That does not mean organizations should avoid useful AI simply to preserve every previous workflow. It does mean continuity planning should ask whether sufficient clinical and operational capability remains to maintain safe care when the technology is unavailable.
Depending on the use case, this may justify competency checks, alternative reference tools, simulation or rehearsal of non-AI workflows, or cross-training for staff involved in critical fallback functions.
A fallback process that depends on skills nobody has practiced for years is not a reliable fallback.
Degraded operation needs a trigger, and users need to know system status
Complete downtime often generates an obvious trigger: the system stops responding. Degraded operation may not.
Healthcare organizations should define signals that indicate a system needs investigation, restricted use or temporary removal from the workflow. Depending on the AI, these might include abnormal latency, missing input variables, incomplete data transfer, unusual rates of errors or overrides, unexpected changes in output distribution, evidence of drift, repeated disagreement with clinical findings, interface failures or vendor notification of a model or infrastructure problem.
There does not need to be one universal threshold for every AI system. There does need to be a pre-agreed path from “something may be wrong” to “the system is now operating under restricted conditions or fallback mode.”
This is where monitoring and continuity planning meet: monitoring detects the signal; fallback determines what happens next.
System status should also be understandable to the people relying on the AI. A clinician should not have to infer from unusual behavior that an AI feature stopped updating 40 minutes earlier. Where appropriate, users may need to know whether the service is operating normally, whether a relevant integration is impaired, when an output was generated, whether required source data are complete or whether the system has entered a restricted mode.
The purpose is not to display every technical diagnostic to clinicians. It is to prevent silent failure.
A stale recommendation that looks current may create more risk than no recommendation at all.
Continuity planning should be proportionate to clinical dependency
Not every AI application warrants the same level of continuity preparation.
If an AI tool supports an administrative task that can safely wait several hours, downtime may mainly create inconvenience or backlog. If an AI system affects time-sensitive triage, prioritization or another clinically consequential workflow, its loss may require much more robust fallback arrangements.
Organizations should therefore consider how quickly loss or degradation of the AI could affect patient care, whether the underlying task can continue without it, whether backlog itself could become a safety problem, whether an alternative system or additional staffing will be needed and which patients or services need protection first.
The answers should shape both the fallback design and the urgency of restoration.
The objective is continuity of safe clinical care, not simply rapid restoration of software.
WHO’s health-service continuity handbook was developed to help healthcare facilities minimize disruption and increase resilience by preparing service-continuity arrangements before emergencies disrupt care. Although it is not an AI-specific document, its preparedness principle is directly relevant: essential care should not depend on inventing continuity arrangements after disruption has already occurred.
Cybersecurity containment and suspension authority belong in the continuity plan
Not every outage is accidental. A healthcare organization may deliberately isolate or suspend an AI system because of suspected cybersecurity compromise. Credentials may need to be revoked, an API disconnected or a cloud service blocked while an incident is investigated.
In that situation, pressure to restore the AI quickly should not override the need to determine whether the environment is safe. Viet Nam’s Law No. 116/2025/QH15 on Cybersecurity has been effective since 1 July 2026, so cybersecurity needs to be considered alongside AI governance and clinical continuity rather than treated as an unrelated IT issue.
A WHO-convened technical consultation on future cybersecurity threats in digital health emphasized cyber resilience alongside prevention, including the need to consider continuity, restoration and recovery when disruption occurs. The resulting report reflects the collective views of participating experts and does not necessarily constitute WHO policy.
WHO/Europe’s 2025 cybersecurity and privacy maturity framework provides a complementary formal WHO reference for digital-health information systems, emphasizing structured cybersecurity and privacy risk assessment across digital health technologies, including AI and machine-learning applications.
For clinical AI, a practical implication is that the fallback pathway should remain usable even when the primary technology environment has been intentionally isolated.
Someone also needs clear authority to activate that fallback. A continuity plan can fail if everyone recognizes a problem but nobody knows who may place the AI into restricted mode, initiate fallback, suspend use or request emergency vendor action.
Decision rights may involve clinical leadership, IT, quality and patient safety, cybersecurity, an AI governance group or the system owner. The precise arrangement can vary, but the authority should be explicit and should not depend on finding one individual who happens to be unavailable.
For legally high-risk AI, Decree No. 142 imposes specific risk-management and intervention duties on deployers. For other clinical AI, comparable suspension and escalation arrangements can be adopted as internal patient-safety controls without changing the system’s legal classification.
Communication is part of the clinical fallback
During AI downtime or degradation, clinicians need more than an IT notification stating that a service is “experiencing issues.” They need to know what the problem means for patient care.
A useful operational message may need to explain which AI function is affected, when the problem began, whether previously generated outputs remain usable, whether results after a certain time should be disregarded, what fallback workflow should be followed, who should be contacted for urgent questions and when the next update will be provided.
Communication may also need to reach scheduling teams, laboratories, imaging departments, patient-support services, leadership or external partners depending on the workflow. If patient care has been affected, existing patient-safety incident and communication processes should be used as appropriate.
A technically accurate outage notice is not enough if the people receiving it do not know what they need to do differently.
Recovery is not the same as “the server is back”
Restoring technical service does not automatically mean an AI system is ready for normal clinical reliance.
Before re-entry, the organization may need to verify that relevant dependencies are functioning properly: data feeds are complete, interfaces are synchronized, the intended model and configuration are active, queued transactions have been handled appropriately, security concerns are resolved and critical monitoring is functioning.
The organization should also consider whether outputs generated immediately before or during the failure need review. If an interface silently stopped sending an important variable for several hours, fixing the interface does not answer what happened to decisions made during that period. If a cloud service returns with a changed configuration, the fact that the application loads again does not establish that its expected clinical behavior is unchanged.
The depth of recovery review should be proportionate to the clinical importance of the system and the nature of the failure. Basic functional testing may be sufficient for a low-consequence feature. A clinically consequential system following a significant technical, cybersecurity or performance problem may justify staged restoration, targeted validation or enhanced monitoring.
The relevant question is therefore “What evidence gives us reasonable confidence that this system is safe to rely on again?” rather than simply “Is it online again?”
Recovery also needs to address the backlog created during downtime. Studies may have accumulated. Alerts may not have been generated. Documentation may be incomplete. Appointments may have been handled manually. Temporary workflows may have created records that now need reconciliation.
The organization should determine whether cases handled during downtime require review, whether queued data will be processed automatically when the system restarts, whether duplicate actions could occur and whether temporary manual records need to be reconciled with the primary system.
Automatically processing a backlog can itself create risk. A large number of delayed alerts generated after the relevant clinical moment has passed may confuse rather than help users.
Recovery should therefore restore the care process, not simply the AI service.
Vendor arrangements should cover continuity, not only uptime
A service-level agreement promising “99.9% uptime” may be useful, but it does not answer many of the questions that matter clinically.
Healthcare organizations may also need to know how the vendor detects degraded operation, how quickly significant incidents are communicated, whether customers can see current system status, how queued transactions are handled, what clinical or technical support is available during disruption, how configuration integrity is confirmed after restoration, whether rollback is possible after a problematic update and what evidence is available for post-incident review.
Contracts may also need to address evidence preservation, incident cooperation and notification of changes that could affect fallback or recovery.
The important question is therefore not only “How often does this system go down?” but “When it becomes unavailable or unreliable, does our vendor relationship give us enough information and control to maintain safe care?”
Safe fallback should be tested, not assumed
A fallback process that has never been exercised may contain hidden assumptions.
A tabletop exercise can reveal that nobody knows who may suspend the AI. A simulation may show that clinicians cannot access the necessary source information without the AI interface. A downtime drill may reveal that the manual pathway cannot handle current patient volume.
Healthcare organizations can therefore test fallback proportionately through tabletop reviews, simulation or planned exercises that do not expose patients to unnecessary risk. Scenarios might include a complete service outage, loss of a critical data interface, abnormal latency, suspected degraded operation, a cybersecurity incident requiring isolation or a vendor update followed by unexpected behavior.
The purpose is not to predict every possible disruption. It is to find weaknesses before a real failure forces the organization to discover them during patient care.
A practical Clinical AI Safe Fallback & Continuity Gate
For a clinically significant AI system, a healthcare organization can ask:
Clinical dependency: What clinical or operational decisions currently depend on the AI, and how quickly could loss of the system affect patient care?
Technical dependencies: Which data sources, networks, interfaces, cloud services, devices, APIs and external vendors are necessary for safe operation?
Failure modes: What could make the system unavailable, partially available or unreliable while still appearing operational?
Detection: How will users or monitoring systems recognize outage, stale output, incomplete input, abnormal latency or degraded operation?
Safe state: What should the system and workflow do when safe operation can no longer be assured?
Fallback pathway: What non-AI process will maintain care, and can staff perform it at the required scale and speed?
Human capability: What skills, staffing, source information and alternative tools need to remain available?
Escalation authority: Who can restrict, suspend or isolate the AI, and who needs to be informed?
Communication: What do clinicians and other affected teams need to know, including whether earlier outputs remain usable?
Serious-incident assessment: Could the event meet the serious-incident criteria under Article 19 of Decree No. 142, and if so, who is responsible for the applicable reporting and record-preservation requirements?
Vendor and cybersecurity response: What support, evidence, notification, isolation and recovery capabilities are available internally and from external providers?
Recovery criteria: What technical, clinical, cybersecurity or validation checks must be satisfied before routine reliance resumes?
Backlog and reconciliation: How will cases handled or accumulated during downtime be reviewed, reconciled or safely processed?
Testing: Has the fallback pathway been exercised, and have weaknesses identified during testing been corrected?
Post-event learning: After a significant outage or degradation event, who reviews what happened and updates controls, training, contracts or monitoring?
This Clinical AI Safe Fallback & Continuity Gate is a practical organizational patient-safety framework. It is not a statutory AI risk-classification method, conformity-assessment procedure or legal requirement that applies identically to every AI system.
Connect AI fallback with existing healthcare continuity systems
Clinical AI should not create an entirely separate emergency-management structure. A more sustainable approach is to connect AI fallback planning with existing business-continuity processes, clinical downtime procedures, cybersecurity incident response, medical-device management, patient-safety escalation and emergency operations.
If a hospital already has downtime procedures for its health information system, PACS or laboratory system, AI dependencies should be incorporated into those arrangements where appropriate rather than managed in isolation. The same principle applies to drills, communication pathways, leadership escalation and post-event review.
WHO’s continuity-planning handbook encourages healthcare facilities to build service-continuity capacity proactively and to review and update existing arrangements rather than waiting for disruption to expose weaknesses.
AI-specific continuity planning should strengthen that existing resilience structure rather than compete with it.
What this means for healthcare organizations in Viet Nam
As clinical AI moves from pilots into routine workflows, healthcare organizations need to pay attention not only to whether a system works, but also to what happens when it does not.
Viet Nam’s AI Law already places particular emphasis on patient safety and real-world reliability in healthcare. For legally high-risk systems, the Law and Decree establish more specific responsibilities concerning monitoring, human intervention, risk management and incident response. Article 19 of Decree No. 142 additionally establishes concrete reporting and record-preservation obligations when an event reaches the statutory threshold of a serious incident.
But continuity planning should not be limited to AI systems carrying a high-risk legal label. An AI application outside the statutory high-risk list can still become operationally important enough that its failure, degradation or sudden withdrawal creates patient-safety risk.
The appropriate level of fallback planning should therefore be proportionate to clinical dependency, consequence of failure and difficulty of recovery.
International evidence points in the same direction. WHO’s AI regulatory considerations emphasize evaluation and monitoring across the lifecycle and real-world use, while the 2026 NEJM AI human-factors article includes safe fallback pathways among relevant measures for AI-enabled medical devices. WHO’s work on health-service continuity and digital-health cybersecurity similarly supports preparing for disruption and recovery rather than assuming digital systems will remain continuously available.
For healthcare leaders, the useful question is therefore not only “How reliable is this AI?”
It is:
“If we cannot rely on it tomorrow, can we still provide safe care?”
A mature clinical AI program should be able to answer yes, not because failure is impossible, but because failure has been anticipated.
The goal is not to build a healthcare system in which AI never goes down.
It is to build one in which AI failure does not become patient-care failure.
Professional education notice
This article is intended for professional education and knowledge exchange. It does not constitute individualized legal, regulatory, clinical, cybersecurity, medical-device, business-continuity or conformity-assessment advice.
Terms such as degraded operation, safe state, safe fallback and the Clinical AI Safe Fallback & Continuity Gate are used here as practical organizational and patient-safety concepts. They are not statutory AI risk categories or formal assessment methods established by Viet Nam’s Law on Artificial Intelligence, Decree No. 142/2026/NĐ-CP or Decision No. 33/2026/QĐ-TTg.
The AI Law and Decree impose specific risk-management, monitoring, human-intervention and incident-management requirements according to the applicable legal framework. Article 19 of Decree No. 142 establishes reporting obligations for serious incidents that meet its statutory criteria; an ordinary outage, delay or episode of degraded operation does not automatically fall within that definition.
The broader continuity and fallback measures described in this article are practical governance approaches. Their appropriate scope should depend on the particular technology, intended use, clinical consequences, organizational context and applicable legal requirements.
References to WHO and international research are provided as governance, resilience and patient-safety considerations. They should not be interpreted as Vietnamese statutory requirements unless separately made applicable through law, regulation, contract, certification commitment or another binding basis.
References
[1] National Assembly of Viet Nam. Law No. 134/2025/QH15 on Artificial Intelligence. Adopted 10 December 2025; effective 1 March 2026.
[2] Government of Viet Nam. Decree No. 142/2026/NĐ-CP Detailing a Number of Articles and Measures for Implementation of the Law on Artificial Intelligence. Issued 30 April 2026; effective 1 May 2026.
[3] Prime Minister of Viet Nam. Decision No. 33/2026/QĐ-TTg Promulgating the List of High-Risk Artificial Intelligence Systems. Issued 30 June 2026; effective 15 August 2026.
[4] World Health Organization. Regulatory Considerations on Artificial Intelligence for Health. 19 October 2023. WHO describes the publication as a general, high-level and nonexclusive overview of regulatory considerations rather than guidance, a regulatory framework or policy.
[5] Mathias R, Schmitt A, Campos M, Vasey B, Lorenz S, McCulloch P, Gilbert S. Evaluation of Human Factors–Related Risks in AI-Enabled Medical Devices — A Practical Guide. NEJM AI. 2026;3(4). Published 26 March 2026. DOI: 10.1056/AIpc2501297.
[6] World Health Organization. Addressing Future Cybersecurity Threats in Digital Health: Report of the Technical Consultation, Geneva, Switzerland, 12–14 December 2023. Published 2024. The report contains the collective views of participating experts and does not necessarily represent WHO policy.
[7] WHO Regional Office for Europe. Cybersecurity and Privacy Maturity Assessment and Strengthening for Digital Health Information Systems. 19 March 2025.
[8] World Health Organization. Health Service Continuity Planning for Public Health Emergencies: A Handbook for Health Facilities. 3 September 2021.
[9] National Assembly of Viet Nam. Law No. 116/2025/QH15 on Cybersecurity. Adopted 10 December 2025; effective 1 July 2026.