How Should Healthcare Organizations Pilot Clinical AI in Viet Nam? A Practical Framework from Use-Case Selection to Safe Go-Live
PRACTICAL FRAMEWORKS & TOOLS
How Should Healthcare Organizations Pilot Clinical AI in Viet Nam? A Practical Framework from Use-Case Selection to Safe Go-Live
Last reviewed: 23 September 2026
Clinical artificial intelligence is moving beyond demonstrations and vendor presentations into selected real healthcare workflows. In Viet Nam, hospitals and clinics are increasingly encountering AI embedded in imaging systems, endoscopy platforms, clinical software, monitoring technologies and decision-support tools. For healthcare leaders, the practical question is no longer simply whether AI has potential. It is how to evaluate and introduce a specific system while managing risks to patients, clinicians and the organization.
A clinical AI pilot should therefore be more than installing a product in one department for a few weeks and asking staff whether they liked it. A useful pilot is a controlled implementation designed to answer predefined questions about evidence, safety, workflow, human oversight, technical performance and organizational readiness before wider deployment.
This is particularly important in Viet Nam in 2026. The Law on Artificial Intelligence No. 134/2025/QH15 has been in effect since 1 March 2026, followed by Decree 142/2026/NĐ-CP on 1 May 2026. Viet Nam also now has substantially developed frameworks for personal data protection, health-data management, cybersecurity and medical-device regulation.[1–9,12–15]
The practical consequence is an important change in mindset: a pilot is not a regulatory shortcut. Calling an implementation a “pilot,” “proof of concept” or “trial” does not by itself remove obligations that would otherwise apply to the technology, the healthcare activity or the data being processed.
First, be clear about what “pilot” means
Healthcare organizations should distinguish an internal implementation pilot from the formal controlled-testing mechanism for AI systems established under Viet Nam’s AI framework. Decree 142/2026/NĐ-CP makes participation in this mechanism voluntary and expressly excludes research, development or testing conducted in a simulated, closed or internal environment where there are no real participants and no effects outside the organization.[2]
For organizations that formally enter the controlled-testing mechanism, Decree 142 establishes three testing levels. At Level 1, the testing location and period are defined and participants are identified according to specified criteria, but the AI output is not used in actual operations, integrated into service or work processes, provided to users or used as a reference for decision-making. At Level 2, real users or directly affected individuals participate and AI output may be used in actual operations or as a reference in decision-making, provided it does not directly create, change or terminate the rights or obligations of an organization or individual. Level 3 applies to specified circumstances, including certain processing of sensitive personal data, core or important data or children’s personal data where a personal-data processing impact assessment is required, systems processing state-secret information, and systems deployed in or directly connected to information systems classified as important to national security.[2]
This does not mean every hospital AI pilot needs to enter the formal mechanism. It does mean that hospitals should not use the words “pilot” and “sandbox” interchangeably. Within a formally approved testing scope, Decree 142 allows competent authorities to recognize specified support mechanisms, including certain adjustments to compliance obligations. Those mechanisms apply only within the approved scope and conditions, and completion of controlled testing does not replace licenses, certificates, approvals or other legal requirements that may apply.[2]
An ordinary hospital implementation pilot therefore remains subject to whatever healthcare, AI, medical-device, personal-data, cybersecurity, research and other requirements apply to the actual project.
Stage 1: Start with a healthcare problem, not an AI product
The strongest pilot usually begins before a vendor is selected. The organization should first define the problem it is trying to solve. Is the objective to improve lesion detection during endoscopy? Reduce reporting delays? Identify deteriorating patients earlier? Improve diagnostic consistency? Reduce unnecessary testing? Support follow-up after discharge?
The intended use should then be written in operational terms. Who will use the system? Which patients will it apply to? At what point in the care pathway will it operate? What information will it receive? What output will it generate? What will the clinician be expected to do with that output? What is explicitly outside the intended use?
Defining these points early helps prevent a common implementation problem: acquiring an impressive AI system and only afterwards deciding where it might be useful. WHO’s regulatory considerations for AI in health similarly emphasize intended use, documentation and transparency, data quality, external validation, human intervention, cybersecurity and lifecycle considerations as important elements of responsible health-AI regulation and deployment.[11]
For a first clinical AI project, a narrowly defined use case is usually easier to evaluate than a system expected to perform many functions across several departments. The pilot should address a meaningful healthcare problem, have measurable baseline performance, include enough cases to generate useful learning and allow clinicians to retain appropriate control while the organization is still learning how the technology behaves.
Stage 2: Establish ownership before implementation begins
A clinical AI system should have a named clinical owner or clinical lead, not simply an information-technology owner or vendor contact. Someone within the relevant clinical service needs to be responsible for defining how the technology fits into care, reviewing unexpected behavior and helping determine whether it remains appropriate for the intended clinical use.
Governance should also involve the functions that actually carry the relevant risks. Depending on the project, this may include clinical leadership, quality and patient safety, information technology, data governance, cybersecurity, legal or regulatory expertise, biomedical engineering, research governance, procurement and the vendor. This does not mean creating a large committee for every low-consequence technology. It means making roles, authority and escalation pathways explicit before the pilot begins.
For high-risk AI systems, Decree 142 sets out specific risk-management responsibilities for deployers, including operating within the intended purpose and conditions of use, monitoring for deviations, risks and incidents, maintaining human supervision and intervention, applying risk controls and coordinating with the provider when material changes or incidents occur. The Decree also requires reassessment when deployment, modification, integration or a change in function or intended purpose creates new or higher risks.[2]
Even when a clinical AI system does not fall within the current formal high-risk list, these principles provide a useful governance model because clinically important harm can occur outside a statutory high-risk classification.
Stage 3: Determine the regulatory pathway before the clinical pilot
Before patient-facing testing begins, the organization should be able to answer a basic question: what exactly is this product, and what rules apply to this use?
Under Decree 142, the provider is responsible for classifying the AI system before it is put into use. The deployer must cooperate with the provider in reassessing the classification where deployment, modification, integration or a change in function or purpose creates new or higher risks.[2] The current high-risk list under Decision 33/2026/QĐ-TTg is relatively narrow in healthcare and presently contains two specified categories involving AI-assisted surgery and surgical robotic systems.[3]
That formal classification should not be confused with clinical risk. An AI system assisting endoscopy, imaging interpretation or deterioration prediction may not appear on the current high-risk list and may still have significant consequences for patients. Legal AI classification and clinical risk assessment therefore need to be considered together, but they answer different questions.
The organization should also determine whether the software falls within medical-device regulation. Decree 98/2021/NĐ-CP includes software within the medical-device framework where it satisfies the relevant definition and is intended for specified medical purposes. Circular 24/2026/TT-BYT, effective from 1 July 2026, further regulates risk determination and management measures for products and goods that are medical devices.[8,9]
Outside a formally approved controlled-testing arrangement or another applicable legal pathway, an implementation pilot should not be used to bypass an unresolved material regulatory requirement. If medical-device status, registration or another significant regulatory question remains unclear, that issue should be addressed before clinicians are asked to rely on the output in patient care.
The same care is needed when a project may constitute biomedical research. A service-improvement pilot and a biomedical research study are not automatically the same thing. Where an activity constitutes biomedical research or otherwise falls within applicable ethics-review requirements, the organization should determine and complete the appropriate research-governance and ethics process before the relevant activities begin. Circular 43/2024/TT-BYT, effective since 1 February 2025, is the current Ministry of Health framework governing the establishment, organization and operation of ethics committees in biomedical research.[10]
Stage 4: Require an evidence and vendor dossier before touching the workflow
A vendor demonstration should not substitute for an evidence review. Before a clinical pilot begins, the healthcare organization should understand exactly what evidence supports the system’s claimed use. This includes how the model was developed, the characteristics of the training and validation datasets, whether independent or external validation exists, how performance varies across relevant patient groups, what comparator or reference standard was used and whether the evaluation environment resembles the proposed Vietnamese setting.
For diagnostic or predictive AI, headline accuracy is rarely enough. Depending on the application, sensitivity, specificity, positive and negative predictive values, calibration, clinically important false-negative patterns and subgroup performance may be more informative. The organization should also understand known failure modes, contraindications or limitations, minimum data-quality requirements and circumstances in which the system should not be used.
WHO’s regulatory guidance similarly identifies documentation and transparency, intended use, external validation, data quality, human intervention, cybersecurity and performance monitoring among important considerations for health AI.[11]
The technical dossier should also identify the exact software or model version being evaluated. If the vendor changes an algorithm during the pilot without documenting the change, interpretation of the results becomes difficult. Version control, notification of updates and the circumstances under which re-evaluation is required should therefore be agreed before implementation.
Stage 5: Resolve data governance and cybersecurity before patient data flow
Clinical AI often relies on some of the most sensitive information held by a healthcare organization, so a data-flow assessment should occur before integration. The organization should know which data leave the clinical system, where they are processed and stored, who can access them, which subcontractors or cloud providers are involved, how long information is retained and whether data cross national borders. It should also be clear whether the vendor intends to reuse patient data, images, prompts or outputs for model training, product development or another secondary purpose.
Viet Nam’s Law on Personal Data Protection No. 91/2025/QH15 and Decree 356/2025/NĐ-CP have been in effect since 1 January 2026. The Law contains specific provisions relating to personal health data, while Decree 356 provides detailed implementation requirements, including provisions relevant to personal-data protection impact assessments and cross-border data transfers.[4,5] The Data Law and Decree 102/2025/NĐ-CP also form part of the framework governing digital health data.[6,7]
Cybersecurity needs to be considered at the same stage. The Cybersecurity Law No. 116/2025/QH15 took effect on 1 July 2026, followed in August by additional implementing regulations including Decree 331/2026/NĐ-CP on cybersecurity protection for information systems and Decree 333/2026/NĐ-CP detailing provisions and measures for implementation of the Cybersecurity Law. Decree 330/2026/NĐ-CP, also effective from 19 August 2026, establishes administrative penalties in the fields of cybersecurity and personal data protection.[12–15]
Even a “silent” pilot can therefore create privacy and cybersecurity exposure if real patient information is transmitted to an AI system. The fact that clinicians cannot see or use the AI output does not remove the need to govern the underlying data.
Stage 6: Validate locally before asking clinicians to rely on the AI
A sensible progression is to begin with the least consequential form of evaluation that can answer the next important question. Technical integration should first be tested without allowing AI output to influence patient care. The organization needs to confirm that the correct patient data reach the correct system, units and fields are interpreted appropriately, images retain adequate quality, identifiers are matched correctly, output returns to the correct patient and latency is acceptable.
Where appropriate, the next step may involve retrospective local validation or a prospective silent or shadow evaluation, in which the AI processes real-world cases but its output is not used to guide clinical decisions. This can help reveal differences between the vendor’s validation environment and the hospital’s own patients, equipment, data quality and workflow.
A silent evaluation is not risk-free and it is not automatically equivalent to Level 1 of Viet Nam’s formal controlled-testing mechanism. Level 1 is a specific legal classification within that mechanism and depends on the conditions set out in Decree 142. Operational terms such as “silent,” “shadow” or “offline” should therefore not be treated as regulatory classifications.
Likewise, if retrospective validation or silent/shadow evaluation is conducted as research or otherwise falls within applicable ethics-review requirements, the relevant research-governance, ethics and data-protection obligations still need to be assessed. Only when technical behavior, local performance, data governance and applicable oversight requirements are sufficiently understood should the organization consider exposing AI output to clinicians in live care.
Stage 7: Design the live pilot as a clinical evaluation, not a demonstration
The live phase should answer questions that retrospective or silent testing cannot: how clinicians interact with the system, whether AI changes decisions, whether users over-trust or ignore its recommendations, whether workflow becomes faster or slower and whether previously unseen safety problems emerge.
These issues are also central to DECIDE-AI, an international reporting guideline developed for early-stage, small-scale live clinical evaluation of AI-based decision-support systems before larger comparative studies. DECIDE-AI emphasizes clinical performance, safety, human factors and the interaction between the AI system, its users and the clinical environment. Importantly, it is a reporting guideline rather than a substitute for study-design methodology or regulatory requirements.[16]
The pilot protocol should define the target population, inclusion and exclusion criteria, clinical users, duration, expected case volume, how AI output will be displayed, what clinicians are permitted or expected to do with it, circumstances in which the AI must not be used and who has authority to pause or stop the pilot. It should also define how patients will be informed and whether consent or other patient-facing processes are required under the applicable clinical, research, data-protection or institutional framework.
Clinicians need training not only in operating the software but also in understanding its limitations. They should know what evidence supports the system, its known failure modes, what to do when AI conflicts with clinical judgment and how to report unexpected behavior. For higher-consequence AI, explicit override mechanisms and fallback pathways are particularly important. If the system becomes unavailable, the organization should already know how care will continue safely.
Stage 8: Measure more than accuracy
A pilot that ends with “the AI achieved 94% accuracy and doctors liked it” has answered relatively little about implementation. Evaluation should instead consider several dimensions at the same time.
Technical performance examines whether the system performs as expected with local data. Clinical performance asks whether it improves the relevant clinical task or outcome. Safety considers missed cases, false positives, inappropriate recommendations, incidents and near misses. Human factors include usability, automation bias, alert fatigue and the frequency and reasons for clinician overrides. Workflow considers time, workload and changes in care processes. Equity examines whether performance differs meaningfully across relevant patient groups. Organizational value may include utilization, cost, avoided downstream activity or other outcomes relevant to the problem the technology was intended to solve.
Baseline measures should be established before the pilot whenever possible. Without a meaningful comparator, an organization may know how the AI performed but still not know whether it improved anything.
Small pilots are not always designed or statistically powered to demonstrate definitive clinical benefit, and they should not pretend to be. Their purpose may instead be to determine whether local performance, safety, feasibility, human factors and workflow integration are sufficiently promising to justify a larger evaluation or controlled scale-up.
Stage 9: Define stop rules before the first patient
One of the clearest signs of a well-governed pilot is that the organization knows in advance what would cause it to pause or stop. Potential triggers may include an unexpected patient-safety event, materially worse performance than expected, systematic false negatives, a cybersecurity or personal-data incident, significant workflow disruption, unacceptable downtime or latency, concerning subgroup performance, a material software or model update during the evaluation, or evidence that clinicians are using the system outside its intended purpose.
The thresholds will not be identical for every AI system. They should reflect the consequences of failure and the nature of the intended use. The important point is that the response should not need to be invented after an incident has already occurred.
Where an organization participates in the formal controlled-testing mechanism under Decree 142, the approved testing arrangement includes requirements around risk management, human supervision, emergency stopping, system logs, monitoring and reporting, together with conditions under which testing may be suspended or terminated.[2]
Stage 10: Use a real go-live gate
Finishing the pilot should not automatically mean purchasing, deploying or scaling the technology. Pilot completion and go-live approval are separate decisions.
A go-live decision should generally require satisfactory evidence across eight areas: regulatory status; evidence for the intended use; local technical and clinical performance; data protection and cybersecurity; clinical workflow; user training and meaningful human oversight; downtime, incident, escalation and rollback readiness; and post-deployment monitoring of performance and outcomes.
If one of these areas remains materially uncertain, the appropriate decision may be to extend the evaluation, modify the implementation, narrow the intended use or stop the project. A pilot can still be valuable when its conclusion is “not ready to scale.”
Go-live should be staged, not treated as the end of governance
Clinical AI does not become a conventional static technology simply because a pilot has finished. Software can be updated, patient populations and data distributions can change, equipment may be replaced, staff behavior can evolve and vendors may modify models or underlying systems.
Post-deployment governance should therefore include version control, monitoring of safety and relevant performance measures, review of overrides and incidents, periodic assessment of workflow impact and a process for deciding when changes require additional validation or reassessment.
This lifecycle approach is reflected in Viet Nam’s AI framework. Decree 142 requires risk controls for high-risk AI to be reviewed and updated when there are significant changes in models, data, operating methods or intended use, and requires deployers to monitor systems for deviations, emerging risks and incidents while maintaining human supervision and intervention.[2]
The same lifecycle principle is useful for clinical AI even when the system is not formally classified as high risk.
A practical sequence for Vietnamese healthcare organizations
For many organizations, a practical pathway is:
Healthcare need → Intended use → Governance owner → Regulatory pathway → Evidence review → Data and cybersecurity review → Local technical validation → Silent/shadow evaluation where appropriate → Controlled live pilot → Go-live decision → Monitored scale-up
The sequence matters because when organizations begin with technical integration and only later ask about evidence, regulation, data governance or workflow, difficult issues often emerge after substantial time and resources have already been committed.
What should be different in Viet Nam?
The aim should not be to copy an AI governance structure developed in the United States, Europe or another health system line by line. The underlying principles are transferable, but implementation needs to fit Vietnamese law, healthcare workflows and organizational maturity.
Healthcare organizations in Viet Nam vary in digital infrastructure, data standardization, interoperability, staffing and governance capability. AI may also be acquired as a component of imaging, endoscopy or other medical technology rather than as a standalone AI product. In some organizations, a clinical department may encounter the technology before quality, patient safety, information technology, data-governance or regulatory teams become involved.
The practical answer is not to surround every low-consequence technology with an unnecessarily complex governance structure. Governance should instead be proportionate to the consequences of failure. An AI tool supporting a low-consequence administrative or information-retrieval task should not necessarily go through the same process as AI influencing cancer detection, triage or treatment. Once an AI output can materially influence patient care, however, expectations for evidence, accountability, human oversight and monitoring should become correspondingly stronger.
WHO’s ethics and governance guidance similarly emphasizes human autonomy, safety and public interest, transparency, accountability, responsibility, inclusiveness and sustainability in health AI.[17]
The purpose of a pilot is to reduce uncertainty
The most useful way to think about a clinical AI pilot is not simply as a small deployment, but as a structured process for reducing uncertainty. Before the pilot begins, the organization should know what it does not yet know. It may be uncertain whether the model performs adequately in its own patient population, whether local data and equipment are compatible, whether clinicians interpret the output appropriately, whether the technology creates new workflow risks or whether it actually produces the expected operational or clinical benefit.
The pilot should be designed to answer those uncertainties. If it does, the organization reaches the go-live decision with more than a successful demonstration. It has a defined intended use, relevant evidence, local experience, trained users, clear accountability, safety controls and a plan for ongoing monitoring.
That is the difference between trying clinical AI and implementing clinical AI responsibly.
References and further reading
National Assembly of Viet Nam. Law on Artificial Intelligence No. 134/2025/QH15. Effective 1 March 2026.
Government of Viet Nam. Decree No. 142/2026/NĐ-CP detailing provisions and measures for implementation of the Law on Artificial Intelligence. Effective 1 May 2026.
Prime Minister of Viet Nam. Decision No. 33/2026/QĐ-TTg promulgating the List of High-Risk Artificial Intelligence Systems. Effective 15 August 2026.
National Assembly of Viet Nam. Law on Personal Data Protection No. 91/2025/QH15. Effective 1 January 2026.
Government of Viet Nam. Decree No. 356/2025/NĐ-CP detailing provisions and measures for implementation of the Law on Personal Data Protection. Effective 1 January 2026.
National Assembly of Viet Nam. Law on Data No. 60/2024/QH15. Effective 1 July 2025.
Government of Viet Nam. Decree No. 102/2025/NĐ-CP on management of health data. Effective 1 July 2025.
Government of Viet Nam. Decree No. 98/2021/NĐ-CP on medical-device management, as amended.
Ministry of Health of Viet Nam. Circular No. 24/2026/TT-BYT on risk determination and management measures for products and goods that are medical devices and amendments to Circular No. 05/2022/TT-BYT. Effective 1 July 2026.
Ministry of Health of Viet Nam. Circular No. 43/2024/TT-BYT on the establishment, organization and operation of ethics committees in biomedical research. Effective 1 February 2025.
World Health Organization. Regulatory considerations on artificial intelligence for health. World Health Organization; 2023.
National Assembly of Viet Nam. Law on Cybersecurity No. 116/2025/QH15. Effective 1 July 2026.
Government of Viet Nam. Decree No. 331/2026/NĐ-CP on cybersecurity protection for information systems. Effective 19 August 2026.
Government of Viet Nam. Decree No. 333/2026/NĐ-CP detailing provisions and measures for implementation of the Law on Cybersecurity. Effective 19 August 2026.
Government of Viet Nam. Decree No. 330/2026/NĐ-CP on administrative penalties in the fields of cybersecurity and personal data protection. Effective 19 August 2026.
Vasey B, Nagendran M, Campbell B, et al. Reporting guideline for the early-stage clinical evaluation of decision support systems driven by artificial intelligence: DECIDE-AI. Nature Medicine. 2022;28:924–933. doi:10.1038/s41591-022-01772-9.
World Health Organization. Ethics and governance of artificial intelligence for health. World Health Organization; 2021.
Regulatory and implementation note
This article provides a practical framework for healthcare organizations considering clinical AI pilots in Viet Nam as of 23 September 2026. “Clinical AI” is used here as a practical healthcare term and should not be interpreted as a standalone legal category under Vietnamese law.
The applicable requirements for a specific project depend on factors including its intended use, AI risk classification, medical-device status, data processing, organization type, whether the activity constitutes or forms part of biomedical research, whether the formal controlled-testing mechanism is used and other features of the implementation.
A hospital implementation pilot, a biomedical research study and participation in the formal controlled-testing mechanism under the AI Law are therefore not interchangeable concepts. The applicable regulatory, ethics, data-protection and governance requirements should be determined from the actual design and intended use of each project.
This article is educational and does not constitute legal, regulatory or clinical advice.