Clinical AI After Go-Live in Viet Nam: How Healthcare Organizations Should Monitor Performance, Safety, Drift and Change
IMPLEMENTATION INSIGHTS
Clinical AI After Go-Live in Viet Nam: How Healthcare Organizations Should Monitor Performance, Safety, Drift and Change
EVIDENCE & EVALUATION
10/1/2026 · 20 min read
Last reviewed: 1 October 2026
Getting a clinical AI system through evaluation, procurement, piloting and go-live can feel like the end of a long implementation process. In reality, go-live marks the beginning of a different kind of responsibility.
Before deployment, the central question is usually whether the system has enough evidence to justify adoption. After deployment, the question changes: Is the system still performing safely and usefully in our patients, our workflows and our clinical environment?
That distinction matters because an AI system does not operate in a laboratory after go-live. Patient populations and disease patterns can change. Imaging equipment, laboratory methods and clinical protocols may change. Software interfaces are updated, vendors release new versions, data pipelines are modified, and clinicians may gradually use the technology differently from how it was used during validation. A system that performed well before deployment can therefore behave differently in routine care.
This is particularly important in Viet Nam. The Law on Artificial Intelligence No. 134/2025/QH15, effective from 1 March 2026, identifies healthcare as an essential field in which AI requires stricter risk management. For healthcare applications, the Law specifically emphasizes patient safety, reliability under real-world conditions of use and protection of health data.[1]
The practical implication is straightforward: responsible adoption of clinical AI does not end when the system goes live. Healthcare organizations need a way to know whether it continues to deserve their trust.
Go-live changes the evidence question
Pre-deployment evaluation asks whether an AI system performs adequately before routine use. Depending on the system, this may include technical validation, clinical validation, usability testing, local piloting and assessment of how the technology fits a particular clinical pathway. Post-deployment monitoring asks a different set of questions. Does the performance observed before launch continue under real-world conditions? Are there particular patient groups, departments, devices or clinical situations in which performance differs? Are clinicians using the system as intended? Has anything changed in the data, workflow, technology or population that could alter its safety or usefulness?
International guidance increasingly approaches this as a lifecycle issue. WHO's evidence framework for AI-based medical devices connects development and validation with post-market surveillance. FDA regulatory-science work similarly notes that patient populations, data-acquisition systems and protocols can change across time and clinical sites, potentially altering the safety and effectiveness of AI-enabled medical devices. NIST's 2026 work on deployed AI reaches the same broad conclusion: pre-deployment evaluation cannot capture every dynamic that emerges in real-world use, so post-deployment monitoring is needed to determine whether systems continue to operate reliably and to identify unexpected consequences.[5–8]
Validation, in other words, is not a permanent property attached to an AI system. It is evidence generated under particular conditions at a particular point in time.
“Clinical AI” is useful language, but it is not a legal classification in Viet Nam
In this article, clinical AI refers broadly to AI systems whose outputs are used in or may influence clinical care, including screening, diagnostic support, imaging interpretation, triage, monitoring, treatment planning and other clinical decision-support functions. It is a practical description, not a separate legal category under Vietnamese law.
The AI Law classifies AI systems into three risk levels: high, medium and low. Classification depends on factors including potential impact on human rights, safety and security, the field of use, the population affected and the scale of impact. A healthcare organization should therefore not assume that every AI system used clinically is legally classified as high-risk simply because it is used in healthcare.[1,2]
That distinction is particularly important under Decision No. 33/2026/QĐ-TTg, effective from 15 August 2026. As of this review, the healthcare section of the current high-risk AI list contains two specified entries, both involving AI-assisted surgery or robotic surgical systems under defined conditions. The current list does not classify every AI system used in imaging, diagnosis, triage or clinical decision support as high-risk by default.[3]
That does not make other clinical AI systems risk-free or remove other legal obligations. The AI Law still requires healthcare applications of AI to receive particular attention to patient safety and reliability in real-world use, while medical-device, personal-data, cybersecurity, healthcare and other laws may apply depending on what the system actually does. Regulatory classification and clinical governance therefore need to be considered together rather than treated as the same question.
Monitoring should begin before the system goes live
A common implementation mistake is to decide what to monitor only after an AI system has already been deployed. By then, the organization may discover that important baseline information was never captured, required data are unavailable, the vendor does not provide the necessary logs or performance measures, or nobody has been assigned responsibility for reviewing them.
A better approach is to define the monitoring plan before go-live. The organization should know what the AI is expected to do, for whom, under what conditions and how deterioration or unexpected behavior will be recognized. That requires a clear intended purpose, defined population and clinical pathway, relevant performance measures, known limitations, acceptable operating boundaries and an appropriate baseline against which future performance can be compared.
There is no universal set of metrics that every healthcare organization should apply to every clinical AI system. For a tool supporting detection of a serious condition, missed cases may be particularly important. For another system, false positives may generate unnecessary investigations or referrals. A risk-prediction model may require attention to discrimination and calibration. An alert system may require monitoring of alert burden and clinician response. A generative AI system that summarizes clinical information may need assessment of factual errors, clinically important omissions and unsupported statements rather than conventional classification metrics.
The useful question is therefore not, “Which AI metric should every hospital monitor?” It is “What evidence would tell us that this particular system is no longer performing safely or usefully for its intended clinical purpose?”
Technical performance and clinical performance are not the same thing
An AI service can be technically available almost all the time and still perform poorly as a clinical intervention. Conversely, a model can preserve its statistical accuracy while creating new problems in workflow. Healthcare organizations therefore need to look beyond whether the server is running and whether the algorithm continues to produce an output.
Consider an AI system that identifies patients for additional clinical review. Its underlying predictive performance may remain similar, but the number of alerts could increase until clinicians begin ignoring them. A diagnostic-support system may maintain acceptable overall accuracy while performing less well in a particular group or clinical setting. An imaging system may generate technically valid results, but a workflow change could cause clinicians to see the AI output before conducting their own review, increasing the possibility of automation bias.
The real performance of clinical AI is therefore partly a property of the human–AI–workflow system, not just the algorithm. This is consistent with the IMDRF's final Good Machine Learning Practice principles, which emphasize performance of the human–AI team, clinically relevant testing, monitoring of deployed models and management of risks associated with retraining.[9]
Drift can occur even when the model itself has not changed
The word drift is increasingly used in AI governance, but several different phenomena may sit behind it. Input or data drift occurs when the data entering a system begin to differ from the data on which it was developed or previously evaluated. A hospital may introduce a new scanner, change an imaging protocol, alter a laboratory method, modify an electronic medical record field or begin serving a different mix of patients.
Performance drift refers to deterioration or meaningful change in the system's observed performance over time. Concept drift more specifically describes a change in the relationship between inputs and the outcome the model is trying to predict. Changes in disease patterns, clinical practice or treatment pathways can sometimes contribute to this.
There can also be workflow drift even when neither the algorithm nor the patient population changes. Clinicians may gradually apply the system to cases outside its intended use, skip a verification step, create workarounds or begin giving the AI output more weight than anticipated when the system was introduced.
These distinctions matter because detecting a statistical change in input data does not, by itself, prove that clinical performance has deteriorated or that patients are being harmed. The reverse is also possible: performance can deteriorate without an obvious automated data-drift signal. Monitoring should therefore connect technical indicators with clinical performance, workflow observation and patient-safety review rather than relying on a single drift score.
FDA's regulatory-science work on AI-enabled medical devices reflects this problem directly by examining methods to detect changes in AI inputs, monitor output performance and understand the causes of performance variation under real-world conditions.[7]
Local performance matters because local conditions matter
An AI system may have strong evidence from another country, another healthcare organization or a large multicenter study. That evidence is important, but it does not guarantee identical performance at every implementation site. Patient characteristics, disease prevalence, equipment, image-acquisition protocols, laboratory methods, language, clinical documentation, coding practices and workflows can all differ.
This is particularly relevant when systems developed or validated outside Viet Nam are introduced into Vietnamese healthcare. Even a well-developed system may have been trained or evaluated in populations, equipment, languages or clinical workflows that differ from those at the local implementation site.
The appropriate response is not to reject externally developed AI. It is to recognize that transportability should be demonstrated rather than assumed. WHO's framework for AI-based medical devices emphasizes evaluation across intended populations and use environments and connects evidence generation with post-market surveillance.[6] For healthcare organizations in Viet Nam, local monitoring is therefore part of evidence generation, not simply an information-technology exercise.
Overall performance can hide clinically important variation
A system can appear to perform well overall while performing differently in particular groups or circumstances. Healthcare organizations should therefore consider whether performance needs to be examined across clinically relevant patient groups, sites, equipment types or care settings rather than relying only on one organization-wide average.
Which analyses are appropriate will depend on the use case. Age, sex, clinical condition, disease severity, site, device type or other characteristics may matter for one application and be irrelevant to another. The purpose should be to identify variation that could influence safety or effectiveness, not to subdivide data indefinitely until apparent differences emerge by chance.
This should also not become an excuse to collect every possible personal characteristic. Monitoring involving personal or sensitive information must have an appropriate purpose and comply with Viet Nam's personal-data framework. Law No. 91/2025/QH15 on Personal Data Protection and Decree No. 356/2025/NĐ-CP have both been effective since 1 January 2026.[10,11]
The objective is not unlimited surveillance of patients. It is to identify clinically meaningful performance differences when doing so is necessary, proportionate and lawful.
Monitor how people use the AI, not only the AI itself
AI performance after deployment is strongly influenced by how people interact with the system. Clinicians may over-rely on an AI recommendation, a concern commonly described as automation bias. They may also distrust the system and routinely ignore recommendations that are useful. Some clinicians may stay within the intended use while others gradually apply the technology to different patient groups, clinical questions or stages of the care pathway.
Useful monitoring may therefore include how frequently the AI is used when eligible, how often clinicians disagree with or override its output, whether disagreements cluster around particular clinical circumstances, whether users recognize when the system is outside its intended use and whether the technology changes workload or decision-making in unexpected ways.
An override rate is not automatically a quality measure. A high rate could suggest poor performance, an inappropriate threshold, poor integration or appropriate clinical judgment in a complex population. A very low rate is not automatically reassuring either; it could represent genuinely good performance or excessive reliance on AI. Numbers need clinical interpretation.
That is why post-deployment monitoring should involve clinical users, quality and patient-safety teams, data or AI specialists, information technology and relevant vendors rather than being left entirely to a technical team.
Safety monitoring should extend beyond accuracy
One of the easiest mistakes in clinical AI governance is to equate safety with model accuracy. Patient harm can arise even when a model remains technically accurate.
An alert may appear too late in the workflow to influence care. A recommendation may be displayed in a way that makes uncertainty difficult to understand. Clinicians may not know that the AI service is unavailable. An integration problem may associate information with the wrong patient. A system may generate enough false alerts to contribute to alert fatigue, or staff may delay an appropriate clinical action because they are waiting for an AI output that is not actually required.
Healthcare organizations should therefore monitor patient-safety signals and unintended consequences, not just algorithmic metrics. Existing quality and safety systems can help. AI-related concerns can be incorporated into incident reporting, near-miss review, clinical audit, morbidity and mortality review where appropriate, risk registers and quality-improvement processes rather than creating an entirely separate safety system for AI.
The point is not to label every adverse event as an “AI incident.” It is to ensure that the contribution of AI, its interface and the surrounding workflow is considered when relevant to the chain of events.
Usage data can reveal problems before outcome data do
In many clinical settings, definitive outcome data are difficult to obtain quickly. Ground truth may require specialist review, pathology results, follow-up or later clinical events. Operational and usage measures can therefore provide useful early warning signals while more definitive clinical evidence accumulates.
A sudden fall in AI use may indicate that clinicians no longer trust the system. A rapid rise in alerts could reflect a change in incoming data, clinical practice or patient population. A shift in override patterns might follow a software update or workflow change. Increasing numbers of cases that the system cannot process may indicate changes in input quality or integration.
These signals should not replace clinical performance evaluation, but they can identify where closer investigation is needed. NIST's 2026 report organizes deployed-AI monitoring into six broad categories—functionality, operations, human factors, security, compliance and large-scale impacts—and identifies performance degradation and drift among the practical challenges of post-deployment monitoring.[8]
Change needs governance because apparently small changes can have clinical consequences
Clinical AI rarely remains completely static within an unchanged environment. A vendor may release a new model. A threshold may be changed. The electronic medical record may be upgraded. New data sources may be connected. The AI may be integrated into another system or introduced in a new department. A product originally used in one population may be proposed for another.
Not every change requires the same response, but healthcare organizations need a change-control process that records what changed, why it changed, what risks could be affected, what testing is required and who has authority to approve the change before it enters routine clinical use.
Vietnamese law contains two related but distinct mechanisms that should not be confused. First, AI risk classification may need to be reviewed and updated. Under Decree No. 142/2026/NĐ-CP, a deployer must cooperate with the provider in reclassification where the deployer modifies, integrates or changes system functions in a way that creates a new or higher risk than the original classification. Providers are also required to review classification when specified events affect the original risk assessment. If the resulting classification is higher, the relevant parties must notify the competent authority within 15 working days after completing the review and immediately apply risk-management measures corresponding to the new risk level. Routine upgrading, performance optimization, ordinary technical bug fixes or periodic data updates that do not alter the nature of the system's risk do not, by themselves, require reclassification review and notification.[1,2]
Second, a system already classified as high-risk is subject to conformity assessment before use and must be reassessed when a significant change affects the result of the original conformity assessment. Decree No. 142 identifies examples including changes to the main function, intended purpose or scope of use; system architecture, AI model or major technical configuration; important data sources, main input types or processing methods; integration with another system; or deployment in a new operating environment where the change affects performance, safety, controllability or risk. Periodic data updates, routine technical corrections, performance optimization or version upgrades that do not affect continued conformity are not automatically treated as significant changes for this purpose.[1,2]
These are different legal questions: Has the system's risk classification changed? and Does a high-risk system require reassessment of conformity because a significant change affects the basis of its previous assessment? A single change may sometimes be relevant to both, but the two processes should not be treated as identical.
The broader safety principle is simpler: when the system or the way it is used changes materially, previous evidence should not automatically be assumed to remain sufficient.
Viet Nam's AI framework creates responsibilities after deployment
An important feature of Viet Nam's 2026 AI framework is that it does not treat compliance as a one-time approval event. For high-risk AI, the provider must establish and maintain risk-management measures, review them when significant changes or new risks arise, manage relevant data quality, maintain technical documentation and activity logs, support human oversight and cooperate in inspection, post-deployment review and incident remediation. Deployers have their own responsibilities, including operating and monitoring the system within its intended purpose, scope and classified risk, maintaining data security and human-intervention capability, managing incidents and cooperating with providers and competent authorities.[1]
Decree No. 142 makes the operational expectation clearer. A deployer of high-risk AI must organize risk management during deployment and operation, monitor the system to detect deviations, risks or incidents, maintain mechanisms for human oversight and intervention, take measures within its control when the system operates outside its intended use or new risks emerge, and coordinate with the provider when significant changes or incidents occur.[2]
These provisions apply specifically within the legal regime for high-risk AI. Medium- and low-risk systems are governed differently under the Law. Healthcare organizations may nevertheless decide that some systems deserve stronger clinical monitoring than the statutory minimum because of the consequences of error, the dependence of clinical workflows on the technology or other patient-safety considerations.
Vietnamese law does not prescribe one universal hospital AI dashboard, one statistical drift test or one clinical performance threshold. Organizations still need to translate applicable legal requirements and the clinical risk of each system into an appropriate assurance process.
The current high-risk list should not become the hospital's entire AI governance boundary
As of 1 October 2026, Decision No. 33/2026/QĐ-TTg lists two healthcare entries under the high-risk AI regime, both relating to AI-assisted or robotic surgery under specified conditions.[3] It would be a mistake to conclude from this that other clinical AI does not require post-deployment monitoring.
Legal risk classification answers one question: which obligations apply under the statutory AI risk-management framework? Clinical governance asks another: What could happen to a patient if this system is wrong, unavailable, misused or trusted too much?
A diagnostic-support system that is not currently listed as high-risk can still influence clinical decisions. An AI endoscopy system can influence lesion detection. An imaging algorithm can affect which cases clinicians prioritize. A generative AI tool can summarize information incorrectly. A deterioration-prediction system can fail to identify a patient whose condition is worsening. The intensity of monitoring should therefore be proportionate to clinical consequence as well as formal legal classification.
Decision No. 33 also contains transitional provisions relevant to organizations using systems on the high-risk list. For listed systems in healthcare that were already operating before 15 August 2026, providers and deployers must complete the applicable AI-law compliance obligations before 1 September 2027. Those pre-existing systems are expressly permitted to continue operating during that transition period unless a competent authority determines that a system presents a risk of serious harm and orders suspension or termination.[3]
A separate rule applies to listed AI systems put into operation during the six months from the Decision's effective date: providers and deployers must complete the applicable compliance obligations before 1 March 2027.[3] Healthcare organizations should therefore determine not only whether a system appears on the current high-risk list, but also when it entered operation and which transitional provision applies.
Viet Nam's National AI Ethics Framework adds a useful governance reference
Viet Nam also issued the National Artificial Intelligence Ethics Framework under Circular No. 05/2026/TT-BKHCN, effective from 10 March 2026.[4] The Framework emphasizes safety and reliability, quality of data, models and outputs, appropriate testing, human oversight, resilience, mechanisms for receiving reports and correcting problems, cybersecurity, accountability and clear allocation of responsibility across the AI lifecycle.
Its legal scope needs to be stated carefully. The Circular applies directly to state-management agencies and to organizations or individuals acting as AI developers, providers, deployers or users where the AI system serves state management or the provision of public services. Vietnamese and foreign organizations and individuals conducting AI research, development, provision, deployment or use in Viet Nam outside that direct scope are encouraged to apply the Framework.[4]
A private healthcare organization should therefore first determine whether its particular activity falls within the Circular's direct scope rather than assuming that the Framework is either universally mandatory or merely optional. Even where it is applied on an encouraged basis, the Framework provides a useful national governance reference because its emphasis on safety, testing, human control, accountability and lifecycle monitoring aligns closely with the practical needs of clinical AI assurance.
Vendor monitoring does not replace local monitoring
Healthcare organizations can reasonably expect an AI vendor to monitor its product, investigate software problems and manage changes. A vendor may also be able to detect patterns across multiple deployments that no individual hospital could see. That is valuable, but it is not enough.
The healthcare organization sees something the vendor cannot fully see: how the AI interacts with its patients, clinicians, equipment and workflows. Local experience may reveal performance changes associated with a particular scanner, patient population, workflow or clinical protocol that are not obvious in aggregate vendor data.
Responsibilities should therefore be defined before procurement or go-live. The organization should know which monitoring data it can access, which measures the vendor reviews, how performance concerns are communicated, whether model or software changes are announced in advance, what logs are available, how incidents are investigated and what happens if the healthcare organization believes continued use has become unsafe.
A contract that simply states that the vendor will “maintain the AI system” is not a post-deployment assurance strategy.
A practical monitoring model does not have to begin with a sophisticated AI platform
Healthcare organizations do not necessarily need an elaborate machine-learning operations infrastructure before they can begin responsible monitoring. A workable approach can start with five practical questions.
First, what should remain true? Define the intended use, population, expected performance, important limitations and safety assumptions. Second, what could change? Identify important dependencies such as patient mix, disease prevalence, equipment, data sources, interfaces, clinical workflows, model versions and practice patterns. Third, what should be measured? Select a manageable set of clinically meaningful performance, safety, workflow, usage and technical indicators instead of collecting every possible metric.
Fourth, who reviews the information and how often? Some high-consequence systems may require frequent or automated monitoring, while other measures may appropriately be reviewed weekly, monthly or through periodic clinical audit. Fifth, what happens when a threshold is crossed? A monitoring system without an escalation pathway is only a dashboard.
The organization should know who can investigate a signal, contact the vendor, increase human review, restrict use, require additional validation, revert to a previous configuration or temporarily suspend the system when necessary. The intensity of these controls should be proportionate to risk and clinical consequence.
Monitoring should have predefined triggers for action
Not every fluctuation requires an AI system to be stopped. Statistical variation is expected, particularly when case numbers are small, and thresholds that are too sensitive can produce repeated false alarms until users stop paying attention. At the other extreme, waiting for obvious patient harm before investigating defeats much of the purpose of monitoring.
Organizations therefore need agreed triggers for different levels of response. Some findings may justify observation. Others may require a focused audit, additional validation, discussion with the vendor or increased human review. A credible safety signal may justify restricted use or temporary suspension while the issue is investigated.
The escalation decision should consider the potential severity of harm, strength and persistence of the signal, number of people potentially exposed, reversibility of the problem, availability of alternative clinical pathways and the degree of uncertainty. Where an event meets the statutory criteria for a serious AI incident, the AI Law and Decree No. 142 establish specific incident-management and reporting requirements. Not every performance variation, incorrect output or near miss automatically meets that legal threshold.[1,2]
That distinction is important. Internal safety monitoring should be capable of identifying concerns before they develop into serious incidents.
Monitoring data need governance too
Post-deployment monitoring can require substantial amounts of clinical and operational information, which creates governance obligations of its own. Healthcare organizations should define what information is genuinely needed, who can access it, how long it will be retained, whether identifiable data are necessary, whether information will be shared with the vendor and whether overseas processing or cloud services are involved.
Where personal data are processed, the Personal Data Protection Law and Decree No. 356/2025/NĐ-CP need to be considered alongside the AI framework.[10,11] There is an important balance here: an organization needs sufficient information to identify unsafe performance and clinically important variation, but collecting excessive patient information simply because it “may be useful for AI monitoring” is not good governance.
Monitoring should itself be purposeful, proportionate and accountable.
Post-deployment monitoring is becoming an international lifecycle expectation
The international direction is increasingly consistent. WHO approaches AI in health through lifecycle evidence and risk management and has highlighted post-market monitoring because important issues may emerge only when systems are used across broader populations and real healthcare settings.[5,6] FDA regulatory-science work includes proactive monitoring of changes in inputs, data drift and performance variation.[7] NIST's 2026 report treats deployed-AI monitoring as a distinct discipline spanning functionality, operations, human factors, security, compliance and broader impacts.[8]
The IMDRF published its final Good Machine Learning Practice for Medical Device Development: Guiding Principles in January 2025.[9] In 2026, it also released the proposed N93 Technical Framework for Artificial Intelligence Life Cycle Management for public consultation. That consultation ran from 10 April to 10 July 2026 and is now closed; as of this review, N93 remains a proposed document, not a final IMDRF technical document.[12]
FDA's August 2025 final guidance on predetermined change control plans for AI-enabled device software functions reflects a related lifecycle principle: planned modifications should be described together with how they will be developed, validated and implemented, and their effects on safety and effectiveness should be assessed.[14] In August 2026, FDA also issued a discussion paper on generative-AI-enabled medical devices that includes postmarket monitoring among the topics under consideration. FDA expressly states that this paper is for discussion and does not constitute draft or final guidance.[13]
These international materials do not replace Vietnamese law. Their value is in helping healthcare organizations translate broad responsibilities for safety, performance and change management into practical lifecycle assurance.
What good post-go-live clinical AI governance could look like in Viet Nam
A healthcare organization with mature AI governance would not consider an AI project complete when the launch meeting ends. The system would have a named clinical owner and an accountable governance structure. Intended use, limitations and important assumptions would be documented. The organization would know which version is running and when that version changes. Performance would be reviewed against a defined baseline, and patient-safety concerns and clinician feedback would have a clear reporting pathway.
Relevant patient groups, sites, equipment types or clinical contexts would be reviewed where justified. Vendor updates would enter change control rather than being installed automatically into clinical production. Material changes would trigger consideration of whether additional validation, risk reclassification, renewed conformity assessment or other action is required. Monitoring data would be reviewed by people with enough clinical and technical understanding to interpret what they mean.
AI assurance would also be connected to existing hospital systems for clinical governance, patient safety, information technology, data governance, risk management and leadership oversight rather than living only in a vendor dashboard.
Most importantly, somebody would have the authority to act when the evidence changes. That is the difference between merely operating AI and governing AI.
The main message
Clinical AI should not be treated as a product that is evaluated once, switched on and then assumed to remain safe indefinitely. After go-live, the healthcare environment continues to change even when the algorithm does not. Patient populations change. Data change. Technology changes. Workflows change. People change the way they use systems. Vendors update products, and new integrations create new dependencies.
For healthcare organizations in Viet Nam, post-deployment monitoring is therefore both a clinical-governance issue and, in relevant circumstances, a regulatory responsibility. The 2026 AI framework places particular emphasis on patient safety and reliability under real-world conditions in healthcare and establishes continuing responsibilities for risk management, monitoring, human oversight, change management and incident response, particularly for systems classified as high-risk.[1–4]
The most useful question after go-live is not simply “Is the AI still running?” It is “Do we still have evidence that this AI is performing safely, effectively and appropriately in the way we are actually using it?”
If the organization cannot answer that question, deployment has moved faster than governance.
Professional education notice
This article is intended for professional education and knowledge exchange. It does not constitute individualized legal, regulatory, clinical, medical-device, data-protection or cybersecurity advice; determine the regulatory classification of any particular AI system; establish a Vietnamese clinical guideline; or replace assessment of the specific product, intended purpose, clinical workflow, contractual arrangements and applicable laws.
The term clinical AI is used here as a practical description and is not a formal risk category under the Law on Artificial Intelligence. Whether a particular system is classified as high, medium or low risk, constitutes a medical device, requires conformity assessment or triggers other legal obligations depends on its actual functionality, intended purpose, deployment model, risk characteristics and applicable regulations.
The terms data drift, concept drift, performance drift and workflow drift are used as technical and governance concepts. They should not be interpreted as separate statutory classifications under Vietnamese law.
The National Artificial Intelligence Ethics Framework has a defined scope under Circular No. 05/2026/TT-BKHCN. Organizations and activities outside its direct scope are encouraged, rather than universally required by that Circular, to apply the Framework. International standards, guidance and proposed frameworks referenced in this article are useful benchmarks for lifecycle AI assurance but do not replace Vietnamese legal requirements.
References
National Assembly of Viet Nam. Law No. 134/2025/QH15 on Artificial Intelligence. Adopted 10 December 2025; effective 1 March 2026.
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. 30 April 2026; effective 1 May 2026.
Prime Minister of Viet Nam. Decision No. 33/2026/QĐ-TTg Promulgating the List of High-Risk Artificial Intelligence Systems. 30 June 2026; effective 15 August 2026.
Ministry of Science and Technology of Viet Nam. Circular No. 05/2026/TT-BKHCN Promulgating the National Artificial Intelligence Ethics Framework. 10 March 2026; effective 10 March 2026.
World Health Organization. Regulatory Considerations on Artificial Intelligence for Health. Geneva: World Health Organization; 2023.
World Health Organization. Generating Evidence for Artificial Intelligence-Based Medical Devices: A Framework for Training, Validation and Evaluation. Geneva: World Health Organization; 2021.
U.S. Food and Drug Administration. Methods and Tools for Effective Postmarket Monitoring of Artificial Intelligence-Enabled Medical Devices. Center for Devices and Radiological Health.
Rao A, Keller A, Kalra N, Steed R, Kwegyir-Aggrey K, Klyman K, Staheli D, Bergman A. Challenges to the Monitoring of Deployed AI Systems. NIST AI 800-4. National Institute of Standards and Technology; 2026. doi:10.6028/NIST.AI.800-4.
International Medical Device Regulators Forum. Good Machine Learning Practice for Medical Device Development: Guiding Principles. IMDRF/AIML WG/N88 FINAL:2025. Published 29 January 2025.
National Assembly of Viet Nam. Law No. 91/2025/QH15 on Personal Data Protection. Adopted 26 June 2025; effective 1 January 2026.
Government of Viet Nam. Decree No. 356/2025/NĐ-CP Detailing a Number of Articles and Measures for Implementation of the Law on Personal Data Protection. 31 December 2025; effective 1 January 2026.
International Medical Device Regulators Forum. N93 Technical Framework for Artificial Intelligence Life Cycle Management. Proposed document; public consultation 10 April–10 July 2026, now closed.
U.S. Food and Drug Administration. Considerations for the Regulation of Generative AI-Enabled Medical Devices: Discussion Paper and Request for Feedback. August 2026. Discussion paper; not draft or final guidance.
U.S. Food and Drug Administration. Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions. Final Guidance. August 2025.