Clinical AI Suspension, Withdrawal and Decommissioning in Viet Nam: When Healthcare Organizations Should Pause, Withdraw or Retire an AI System
PRACTICAL FRAMEWORKS & TOOLS
Clinical AI Suspension, Withdrawal and Decommissioning in Viet Nam: When Healthcare Organizations Should Pause, Withdraw or Retire an AI System
PRACTICAL FRAMEWORK & TOOL
Last reviewed: 3 October 2026
Healthcare organizations spend considerable time deciding whether an AI system is ready to go live. Much less attention is usually given to the opposite decision: when should it stop?
A clinical AI system may need to be paused because monitoring identifies an unexpected safety signal. A vendor may report a defect. Performance may deteriorate after changes in patient population, workflow or data. A cybersecurity incident may affect confidence in the integrity of the system. A contract may end, technical support may disappear, or the organization may decide that the clinical benefit no longer justifies the operational burden. In other situations, a provider may withdraw a system or a competent authority may require its suspension, recall or reassessment.
These situations are not the same. A temporary pause while a problem is investigated is different from withdrawing a system from routine clinical use, and both are different from permanently retiring a system at the end of its operational life. Yet they share the same patient-safety question: how can a healthcare organization stop relying on AI without creating a new risk in the process?
Responsible AI governance therefore should not end with procurement, validation, go-live and monitoring. It also needs a safe exit pathway.
Pausing, withdrawing and decommissioning are different decisions
For practical healthcare governance, it is useful to distinguish three situations. A pause or suspension is a temporary restriction on use. The system may remain installed and technically available, but its clinical use is stopped or limited while the organization investigates a safety signal, performance problem, cybersecurity event, regulatory concern or other uncertainty. Use may resume if defined conditions are subsequently met.
Withdrawal from clinical use goes further. The organization removes the AI system, or a particular function or version of it, from the approved clinical workflow. Withdrawal may follow a safety concern, vendor notice, regulatory action, loss of acceptable performance or an organizational decision that continued use is no longer appropriate. A return to use could later be considered after formal review, but unlike a short pause, re-entry should not be assumed.
Retirement or decommissioning is the deliberate end of the system's operational life within the organization. This may happen because the technology has become obsolete, a contract ends, the vendor discontinues support, another system replaces it, the use case no longer delivers sufficient value or the organization changes direction. Decommissioning involves more than switching software off: dependencies, data flows, users, interfaces, records, access, evidence and replacement workflows all need to be addressed.
These are practical governance terms used in this article. They should not be treated as one-to-one equivalents of statutory terminology under Vietnamese law. Viet Nam's AI legislation uses legal concepts including temporary suspension, recall, reassessment and termination of operation in specified circumstances.
Viet Nam's AI framework already recognizes that an AI system may need to stop
Viet Nam's Law on Artificial Intelligence No. 134/2025/QH15 was adopted on 10 December 2025 and has been effective since 1 March 2026. Article 12 requires developers, providers, deployers and users to help ensure safety, security and reliability and to promptly detect and address AI incidents capable of harming people, property, data or social order.
When a serious incident occurs, the Law assigns different responsibilities to different actors. Developers and providers must urgently apply technical measures to remedy the problem, suspend or recall the system as appropriate, and notify the competent authority. Deployers and users must record and promptly report the incident and cooperate in remediation. The competent state authority may also require suspension, recall or reassessment of the AI system where necessary.
Decree No. 142/2026/NĐ-CP, issued on 30 April 2026 and effective from 1 May 2026, provides the more detailed serious-incident framework. It establishes categories of serious incidents that include events causing death or serious health harm and other serious consequences involving property, rights, essential services, public order or security.
For preliminary reporting, a provider or deployer, as applicable, must report specified urgent serious incidents within 72 hours and other serious incidents within five working days. Those periods run from the time the incident is confirmed, the point at which sufficient initial information exists to determine that the event actually occurred and is highly likely to have originated from an AI-system fault. Organizations do not wait for a complete technical investigation before the reporting period begins, and submission of the preliminary report is not itself treated as an admission of technical fault or legal liability.
Providers and deployers must also preserve relevant system logs, data and information for verification, assessment and remediation and submit an official report on remediation results within 15 days of the preliminary report. Where the same event is reportable under cybersecurity, personal-data-protection or another specialized legal framework, those reporting requirements continue to apply.
A transitional provision is particularly relevant in 2026. Under Article 35 of the AI Law, providers and deployers of systems already operating before 1 March 2026 have 18 months to meet the Law's compliance obligations for AI systems in healthcare, education and finance, compared with 12 months for other pre-existing systems. During that period, a system may continue operating unless the AI state-management authority determines that it presents a risk of serious harm and requires suspension or termination.
These legal provisions are important, but they should not be interpreted to mean that a healthcare organization only needs to stop an AI system after a statutory serious incident or government order. Legal incident thresholds and internal clinical-safety thresholds serve different purposes.
Stop rules and stop authority should exist before the organization needs them
A statutory serious incident is a legal threshold. An organizational stop rule should be capable of intervening earlier when continued use could expose patients to unacceptable or insufficiently understood risk.
Consider an AI system whose sensitivity has fallen materially below its locally validated range even though no serious injury is yet known to have occurred. An AI documentation tool begins intermittently omitting medication changes. A vendor warns that a model version can produce unreliable outputs under a particular condition. Clinicians increasingly override recommendations because local practice has changed, or the patient population has shifted away from the population on which the system was evaluated. None of these situations should require an organization to wait for death, serious injury or another statutory serious incident before considering a pause.
Before routine deployment, healthcare organizations should therefore define conditions that trigger review, restriction or temporary suspension. Potential triggers may include performance moving outside agreed limits; clinically important drift; repeated unexpected or unsafe outputs; serious incidents or meaningful near misses; vendor safety notices; cybersecurity compromise affecting data or model integrity; an unapproved material change; inability to provide effective human oversight; loss of required regulatory status; persistent workflow failure; or evidence that risk now exceeds the organization's agreed tolerance. Commercial and operational events can justify review for different reasons, including contract expiry, loss of vendor support, inability to obtain necessary technical information, loss of integration compatibility, strategic replacement or failure to demonstrate continuing clinical value.
NIST AI RMF 1.0 takes the same lifecycle view. GOVERN 1.7 states that processes and procedures should be in place to decommission and phase out AI systems safely without increasing risk or decreasing organizational trustworthiness. The associated Playbook recommends deliberate decommissioning policies that consider business continuity, upstream and downstream dependencies, regulatory retention requirements, migration to replacement systems and potential future legal, regulatory, security or forensic investigations.
The organization also needs to know who can actually stop the system. Clinical AI often sits across multiple functions: it may be purchased by management, integrated by IT, clinically owned by one service, monitored by quality and patient-safety teams, supplied by an external vendor and used daily by clinicians. For clinically consequential AI, stop authority should therefore be assigned before deployment.
A practical structure may allow designated clinical or patient-safety leaders to implement an urgent temporary stop where there is a credible immediate concern, followed by timely multidisciplinary review involving relevant clinical, quality, IT, cybersecurity, personal-data-protection, biomedical or medical-device and AI-governance functions. The subsequent decision may be to resume, resume with restrictions, remediate, revalidate, withdraw or permanently retire the system. This is an organizational governance approach, not a decision structure prescribed by Vietnamese AI legislation; what matters is that authority is clear before a safety signal appears.
Suspension is not the same as downtime
During downtime, the healthcare organization intends to use the AI system but cannot reliably do so because it is unavailable, disconnected or technically degraded. The objective is usually to maintain safe care until service is restored. During suspension, the system may be fully available from a technical perspective, but the organization has decided that it should not currently be relied upon.
The fallback workflow may look similar in both situations because clinicians may temporarily return to a non-AI process. The governance pathway is different. After downtime, restoration may follow when technical service is recovered and required checks are completed. After a safety suspension, technical availability alone is not enough: the reason for suspension must be understood and defined criteria for safe re-entry must be satisfied.
A system that turns back on is not necessarily a system that is ready to return to clinical care.
Stopping AI can create new patient-safety risks
Clinical teams adapt around technologies that become part of everyday work. AI may change prioritization, work allocation, staffing, escalation routes, reporting patterns and expectations. Manual processes may gradually become less familiar, or may even be redesigned because staff expect AI support to remain available. Removing an embedded system can therefore redistribute risk rather than simply eliminate it.
A 2026 study in the Journal of the American College of Radiology examined staff experience after withdrawal of a chest-radiograph AI triage tool at a multisite NHS trust. Forty of 187 invited staff completed the post-decommissioning survey. The study found both perceived loss of clinical or pathway value and operational relief across different staff roles and proposed a three-stage AI Off-Boarding Protocol: prewithdrawal assessment, graduated transition and postwithdrawal support.
The tool in that study was decommissioned after pilot funding ended rather than because of a safety failure, so the findings should not be generalized directly to Vietnamese healthcare or to safety-driven withdrawal. The broader lesson is nevertheless useful: removing embedded AI is a clinical and organizational change event, not merely an IT action.
Before withdrawal, an organization should therefore understand what has become dependent on the AI. What process will replace it? Are staff still competent and adequately resourced to perform that process? Will turnaround times change? Will another team absorb additional workload? Could withdrawal create delays, missed prioritization or communication gaps? A safe exit plan addresses these effects before the system disappears.
Retrospective patient review and evidence preservation may need to happen together
Some AI problems are identified only after a system has been operating for a period of time. If an organization discovers a model defect, incorrect configuration, significant drift or unreliable model version, preventing future use may not be sufficient. It may also need to determine whether earlier patients, outputs, reports or decisions were affected.
The scope of retrospective review should depend on the evidence and potential harm. Relevant questions include when the problem began, which system and version were involved, which patients or workflows were exposed, whether human reviewers corrected erroneous outputs and whether any patient now requires further clinical assessment or follow-up. This is where AI inventory, provenance and traceability become operational patient-safety capabilities. If the organization cannot determine which version was used, where it was used and which patients or workflows were exposed, retrospective assessment may become extremely difficult.
Stopping future use should therefore be accompanied, where appropriate, by preserving the evidence needed to understand past use. NIST specifically cautions that irregular or indiscriminate termination or deletion of AI systems can increase organizational risk because decommissioned systems or artifacts may later be required for legal, regulatory, security or forensic investigation. Its decommissioning guidance also highlights retention periods, system dependencies, regulatory requirements and migration to replacement systems.
For clinical AI, potentially relevant material may include the system identity, deployed model or configuration version, validation evidence, monitoring results, change history, incident records, necessary system logs, links between affected outputs and patients where justified, relevant vendor communications and the organizational decision explaining why use was suspended or ended. This does not mean that every dataset, prompt or technical artifact should be retained indefinitely. Medical-record, personal-data-protection, cybersecurity, contractual and other retention requirements still apply, and unnecessary retention can itself create privacy and security risk.
The narrower principle is that decommissioning should not destroy information the organization may reasonably need to understand what the system did while it was in clinical use.
Vendor withdrawal remains a healthcare organization's patient-safety problem
A healthcare organization may have little control over why an external vendor withdraws a model, stops supporting a product or ends a service. It still needs to manage the effect on its own clinical operations.
Contracts and procurement arrangements should therefore anticipate the end of the relationship, not only its beginning. Depending on the technology and service, relevant provisions may address advance notice of discontinuation or material support changes, safety notifications, access to necessary historical logs and version information, data export, transition support, handling of residual data, removal of integrations and credentials, retention or deletion requirements and migration assistance.
Where AI is embedded inside a larger platform, the organization should understand whether the AI function can be disabled independently. If it cannot, withdrawing the AI may require broader software, workflow or contractual changes. The organization should also consider what happens when a vendor stops supporting a model that remains technically functional. Technical availability does not necessarily mean that continued use remains safe, maintainable or appropriate.
A system can become a governance risk before it becomes a technical failure.
Where clinical AI is also a medical device, another regulatory layer may apply
Not every AI system used clinically is legally a medical device. Where a product does fall within Viet Nam's medical-device regulatory framework, however, AI-governance decisions need to be considered alongside the applicable medical-device requirements.
The current consolidated decree-level medical-device framework is Consolidated Document No. 08/VBHN-BYT dated 6 March 2026, which consolidates the rules on medical-device management. This replaces the older consolidated version cited in the earlier draft of this article.
The framework contains specific post-market obligations. Where a medical-device incident seriously threatens public health or causes death, the registration-number holder must notify relevant purchasers/users and the Ministry of Health, temporarily suspend circulation of the affected device lot, investigate the incident and report the results. Where device fault is established, further remediation or recall requirements can apply.
The implementing regulatory layer has also continued to evolve. Circular No. 24/2026/TT-BYT, issued on 30 June 2026 and effective from 1 July 2026, sets rules for determining product-risk levels and management measures for medical-device products and amends parts of Circular No. 05/2022/TT-BYT.
These rules should not be applied automatically to every AI tool used in a hospital. The first question is whether the particular product and its intended use fall within the medical-device regulatory framework. Where they do, AI-law obligations, medical-device requirements, clinical governance, cybersecurity and personal-data-protection responsibilities may operate in parallel.
Returning a suspended AI system to use requires more than fixing the fault
A temporary pause should have defined re-entry criteria. Before resuming use, the organization needs to understand why the system was suspended and what has changed since that decision.
The evidence required will depend on the problem. A configuration error may require correction and verification. A model defect may require a new version and targeted revalidation. Performance drift may require investigation of the patient population, workflow or data pipeline. A cybersecurity event may require assurance that integrity, access controls and relevant data flows have been restored.
For clinically consequential AI, re-entry should usually answer several practical questions: Has the cause been sufficiently understood? Has corrective action been implemented? Has the affected function been retested? Does performance remain acceptable in the local environment? Have users been informed of relevant changes or limitations? Is enhanced monitoring required after restart?
A vendor statement that an issue has been “resolved” may be important evidence, but it should not automatically replace the healthcare organization's own assessment of whether the system is ready to return to its local clinical workflow. Where remediation involves a material system change, established change-control and revalidation processes should be followed rather than treating restart as an ordinary technical restoration.
Permanent decommissioning needs a defined end state
A system is not fully decommissioned simply because clinicians have stopped using it. Interfaces may still send data, API credentials may remain active, scheduled processes may continue, user accounts may persist and historical outputs may remain visible in clinical systems. Staff may still expect an alert or score to appear, while a replacement system may inadvertently run in parallel with the retired one.
Decommissioning therefore needs a defined end state. The AI inventory should record the system as suspended, withdrawn or retired rather than simply deleting its history. Relevant workflows and procedures should be updated, unnecessary integrations and permissions removed, data-retention or deletion decisions documented, required evidence preserved and affected users informed that the system is no longer part of the approved workflow.
If another AI system replaces it, the replacement should undergo its own evaluation and validation. A new product is not automatically safe simply because it serves the same nominal purpose. Organizations should also check whether the replacement changes outputs, thresholds, terminology or workflow in ways that require staff retraining.
A clean technical shutdown matters, but a safe clinical transition matters more.
A practical Clinical AI Exit Gate
When continued use of a clinical AI system is questioned, healthcare organizations can work through the following governance questions:
Trigger: What prompted review: a safety signal, performance deterioration, incident, cybersecurity event, vendor notice, regulatory change, loss of support, contract issue or planned retirement?
Immediate risk: Can the system continue operating safely while review occurs, or should use be restricted immediately?
Authority: Who can pause, restrict, resume, withdraw or permanently retire the system?
Scope: Does the action apply to the whole system, one function, one site, one patient group, one model version or one workflow?
Patient impact: Could previous outputs have affected care, and is retrospective clinical review needed?
Continuity: What replaces the AI, and can staff deliver safe care through that alternative?
Dependencies: Which interfaces, downstream systems, teams, staffing arrangements or clinical processes depend on the AI?
Regulatory status: Does the event trigger obligations under AI legislation, medical-device rules, cybersecurity, personal-data protection or another applicable framework?
Vendor action: What information, remediation, technical support, data export or transition assistance is required from the provider?
Evidence preservation: Which versions, logs, validation records, monitoring results, outputs, incident information and other artifacts need to remain accessible?
Communication: Who needs to know: clinicians, relevant patients, operational teams, leadership, regulators or external partners?
Re-entry criteria: If the restriction is temporary, what evidence must exist before clinical use resumes?
Replacement: If another system will take over, has it been independently evaluated and locally validated where appropriate?
Closure: What demonstrates that interfaces, access, data flows, procedures and operational dependencies have been safely closed?
Learning: What should change in procurement, contracting, monitoring or governance because of this experience?
The Clinical AI Exit Gate is a practical organizational framework proposed for healthcare governance. It is not a statutory checklist or regulatory procedure established by Vietnamese law.
What this means for healthcare organizations in Viet Nam
This issue is becoming more important as Viet Nam simultaneously develops a more explicit AI regulatory framework and promotes broader AI adoption. The country now has a dedicated AI Law, Decree No. 142/2026/NĐ-CP on implementation and serious-incident management, and Decision No. 33/2026/QĐ-TTg establishing the current statutory high-risk AI list. The AI Law took effect on 1 March 2026, Decree No. 142 on 1 May 2026, and Decision No. 33 on 15 August 2026.
At the same time, Decision No. 1671/QĐ-TTg of 28 August 2026 approved the National Artificial Intelligence Strategy to 2030, with a vision to 2045, providing the policy framework for broader AI development and deployment, including in healthcare.
The more AI becomes embedded in healthcare, the more important exit governance becomes. Not every system will be withdrawn because it failed. Some will reach a planned end of life, some will be replaced by better tools, some will lose funding or vendor support, and others may be temporarily suspended and later return safely to use. The governance challenge is to manage each transition without losing patient safety, continuity, traceability or accountability.
The most useful leadership question is therefore not simply, “Can we switch this AI system off?” It is, “Can we stop relying on it safely, understand who and what will be affected, preserve what we may need later, and know what must happen before it is either restored or finally retired?”
That is what responsible AI lifecycle governance looks like when use comes to an end.
Professional education notice
This article is intended for professional education and knowledge exchange. It does not constitute individualized legal, regulatory, clinical, cybersecurity, personal-data-protection, procurement or medical-device advice.
The terms pause, suspension, withdrawal, retirement, decommissioning and the Clinical AI Exit Gate are used in this article as practical organizational governance concepts. They should not be assumed to correspond one-to-one with statutory terms such as suspension, recall, reassessment or termination under Viet Nam's AI legislation.
Not every performance concern or organizational decision constitutes a “serious incident” under Article 19 of Decree No. 142/2026/NĐ-CP. Healthcare organizations may nevertheless establish internal suspension thresholds below that statutory threshold where proportionate to patient safety and organizational risk.
Where an AI system is also regulated as a medical device, separate medical-device requirements may apply in parallel. Healthcare organizations should determine the regulatory status of the particular technology and intended use rather than assume that all clinical AI is, or is not, a medical device.
NIST AI RMF materials and the international healthcare research discussed in this article are included as governance and implementation references. They do not create legal obligations in Viet Nam unless separately made applicable through Vietnamese law, regulation, contract, certification requirement 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] Ministry of Health of Viet Nam. Consolidated Document No. 08/VBHN-BYT on Medical Device Management. Consolidated 6 March 2026.
[5] Ministry of Health of Viet Nam. Circular No. 24/2026/TT-BYT on determining risk levels and management measures for medical-device products and amending certain provisions of Circular No. 05/2022/TT-BYT. Issued 30 June 2026; effective 1 July 2026.
[6] Prime Minister of Viet Nam. Decision No. 1671/QĐ-TTg Approving the National Artificial Intelligence Strategy to 2030, Vision to 2045. Issued 28 August 2026.
[7] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework 1.0 — GOVERN 1.7 and AI RMF Playbook. Voluntary guidance on safe decommissioning and phasing out of AI systems.
[8] Shelmerdine SC, et al. Responsible Artificial Intelligence Off-Boarding in Radiology: Staff Perspectives on Decommissioning and a Proposed Withdrawal Framework. Journal of the American College of Radiology. Available online 6 June 2026.