Procuring Clinical AI in Viet Nam: A Practical Framework for Vendor Due Diligence, Contracting and Accountability
PRACTICAL FRAMEWORKS & TOOLS
Procuring Clinical AI in Viet Nam: A Practical Framework for Vendor Due Diligence, Contracting and Accountability
GOVERNANCE & RESPONSIBLE ADOPTION
Last reviewed: 1 October 2026
Buying clinical AI is not the same as buying ordinary software.
A hospital may be shown an impressive demonstration, a strong accuracy figure, a list of international customers and a promise that the technology will save time or improve clinical decisions. All of those may be relevant. None of them, on their own, answers the question a healthcare organization ultimately has to answer: Is this particular AI system appropriate, sufficiently supported by evidence, legally and technically suitable, operationally workable and governable in our healthcare environment?
That question becomes even more important once an AI system moves beyond a demonstration or short pilot. The organization may depend on the vendor for model updates, cloud infrastructure, technical support, performance information, cybersecurity response and investigation when something goes wrong. Patient information may pass through the vendor’s systems. An algorithm may change while the commercial product retains the same name. A system that works well in one country or hospital may behave differently when introduced into another patient population, device environment or clinical workflow.
Procurement is therefore not simply the point at which a healthcare organization chooses a vendor and negotiates a price. For clinical AI, it is one of the most important governance decisions in the AI lifecycle.
Viet Nam’s regulatory environment makes this increasingly relevant. The Law on Artificial Intelligence No. 134/2025/QH15 has been effective since 1 March 2026, Decree No. 142/2026/NĐ-CP since 1 May 2026, and Decision No. 33/2026/QĐ-TTg establishing the list of high-risk AI systems since 15 August 2026. The Personal Data Protection Law, its implementing decree, the 2026 Cybersecurity Law and medical device rules may also apply depending on the system, its intended purpose, data flows and deployment architecture.
For healthcare organizations, the practical challenge is to bring these considerations together before a commercial commitment makes important choices difficult or expensive to change.
Clinical AI procurement should start with the healthcare problem, not the vendor
The first due-diligence question is not “Which AI product should we buy?” It is “What healthcare problem are we trying to solve?”
A hospital may want to reduce missed findings on imaging, improve lesion detection during endoscopy, shorten reporting time, identify deteriorating patients earlier, support clinical documentation or improve the prioritization of work. Those are different problems with different clinical consequences if the technology fails.
The proposed clinical use case should therefore be clear before products are compared. Who will use the AI? Which patients will be affected? At what point in the care pathway will it operate? Will its output be advisory, prioritizing, diagnostic, predictive or directly linked to an intervention? What happens if the system is wrong, unavailable or ignored? What outcome is the organization actually trying to improve?
This matters because vendors naturally describe what their product can do. The healthcare organization needs to decide whether that capability addresses a problem important enough to justify changing clinical practice.
International procurement guidance follows the same logic. The NHS buyer’s guide to AI in health and care is designed to help organizations determine whether an AI product is appropriate, safe, effective and suitable for their particular environment rather than evaluating products only from marketing claims.[14]
A good procurement process therefore begins with a clinical use-case statement defined by the healthcare organization and then asks whether that use case fits within the vendor’s documented intended purpose, evidence and regulatory status. The hospital should not quietly expand the intended use of a product beyond what the provider has validated or represented as appropriate.
“Procurement” does not mean the same legal process for every healthcare organization in Viet Nam
In this article, procurement refers broadly to evaluating, selecting, acquiring and contracting for an AI-enabled product or service. It should not be interpreted as meaning that every healthcare organization follows the same statutory purchasing or tendering procedure.
Where a procurement falls within the scope of Viet Nam’s Law on Bidding, including relevant procurements by public healthcare institutions, the organization must comply with the applicable procurement legislation, authority, contractor-selection method, documentation and procedural requirements. As of 1 October 2026, relevant consolidated texts include Consolidated Document No. 74/VBHN-VPQH dated 25 March 2026 on the Law on Bidding and Consolidated Document No. 36/2026/VBHN-NĐ-BTC dated 23 September 2026 on contractor selection.[11,12]
Private healthcare organizations may have greater flexibility in how they select and contract with vendors, but they remain subject to applicable AI, personal-data, cybersecurity, medical-device, commercial and other legal obligations.
The framework in this article is therefore primarily a clinical, technical, governance and contractual due-diligence framework. It does not replace the statutory procurement procedures that may apply to a particular institution, funding source or procurement package.
Before comparing vendors, determine what the product actually does
AI marketing terminology can make fundamentally different technologies appear similar.
One vendor may offer software that detects a finding and displays an alert. Another may prioritize cases in a worklist. A third may generate a diagnostic recommendation. Another system may modify device parameters or trigger an automated process. Generative AI may draft clinical documentation or patient-facing text rather than produce a numerical prediction.
The procurement team should therefore ask the vendor to describe the system operationally: What does the AI receive as input? What does it produce? Who receives the output? What action is expected from the user? How much autonomy does the system have?
The organization should also determine whether AI is embedded inside another product. A hospital may believe it is purchasing an imaging system, endoscopy platform or clinical software package when an AI function is actually one component of the broader product.
This matters for regulatory analysis. Under Viet Nam’s current medical-device framework, some software can fall within medical-device regulation depending on its intended purpose and applicable criteria.[10] The presence of AI does not by itself create a separate medical-device category. What the software is intended to do remains central.
A procurement file should therefore identify the specific AI-enabled function being evaluated, not merely the commercial name of the larger product.
Ask for the AI regulatory classification and its supporting documentation
Foreign regulatory clearance, certification or marketing authorization may provide useful information, but healthcare organizations should not assume that foreign regulatory status automatically establishes compliance in Viet Nam.
Under Viet Nam’s AI Law, the provider is responsible for classifying an AI system before it is placed into use. Systems classified as medium or high risk must have a classification dossier, and the provider must notify the Ministry of Science and Technology of the classification result through the national AI one-stop electronic portal before such a system is placed into use.[1,2]
For medium- and high-risk systems, Decree No. 142 specifies that the classification dossier includes information identifying the system and version, its intended purpose and deployment context, principal input-data types and a summary of risk-management, safety and transparency measures.[2]
A healthcare organization should therefore ask for the documented risk classification and its basis, rather than relying only on a verbal statement that the system is “low risk,” “AI compliant” or “internationally certified.”
Practical questions include: What classification has the provider assigned under Vietnamese law? What evidence supports it? Does the system appear within Decision No. 33/2026/QĐ-TTg? If it is high risk, what conformity-assessment requirements apply? Has the applicable process been completed? Is the software also subject to medical-device regulation? What approvals, registrations, declarations or other regulatory records relate to the specific version being purchased?
For systems within Decision No. 33 that were already operating before the Decision took effect on 15 August 2026, transitional provisions are important. Existing high-risk systems in healthcare, education and finance must complete the applicable AI compliance obligations before 1 September 2027 and may continue operating during the transitional period unless competent authorities require suspension or termination because of a risk of serious harm.[3]
There is also a separate transitional rule for systems within the high-risk list that are first placed into operation during the six-month period beginning on 15 August 2026: providers and deployers must complete the applicable compliance obligations before 1 March 2027.[3]
These transition periods should not be treated as exemptions from governance. A healthcare organization purchasing, renewing, deploying or expanding an affected system should understand which obligations remain outstanding, who is responsible for completing them and whether the contract provides the information and cooperation needed to do so.
Do not assume that all clinical AI is legally high-risk
As of 1 October 2026, the healthcare portion of Decision No. 33/2026/QĐ-TTg does not classify every diagnostic or clinical AI application as high risk. Its healthcare section currently identifies specified AI systems supporting surgery or robotic surgery where the stated conditions are met.[3]
A healthcare organization should therefore not label every radiology algorithm, decision-support system or generative AI application as legally “high-risk” simply because it is used in healthcare.
At the same time, absence from the statutory high-risk list does not mean that a product warrants minimal clinical scrutiny. An AI system that prioritizes emergency imaging, generates medication-related information or materially influences a diagnostic pathway may still create significant patient-safety consequences depending on how it is used.
Statutory AI risk classification and organizational clinical risk are related, but they are not interchangeable. Procurement teams need to understand both.
Vendor evidence should be evaluated against the actual intended use
A common procurement error is to ask whether the vendor “has evidence” rather than whether the evidence supports the use being proposed.
A vendor may present a high sensitivity, specificity, area under the curve or accuracy result from a retrospective dataset. That may demonstrate technical performance under particular conditions, but it does not necessarily show that the technology improves clinical practice in the buyer’s environment.
The healthcare organization should understand who was studied, where the study occurred, what equipment and data were used, what reference standard and comparator were applied, whether the evaluation was retrospective or prospective, whether external validation was performed and what outcomes were actually measured.
A strong performance metric is less informative if the validation population differs substantially from the population in which the organization intends to deploy the product. The buyer should also examine clinically important subgroups where relevant. Age, sex, disease prevalence and severity, equipment, image acquisition, care setting and other factors may influence performance depending on the system.
The key question is: Does the available evidence reasonably support this AI system, for this intended purpose, in patients and workflows sufficiently similar to ours?
Published evidence is valuable, but publication alone is not proof that a system is suitable for local use.
Ask what evidence does not yet exist
Good due diligence is not only about verifying positive findings. It is also about identifying uncertainty.
Has the system been prospectively validated? Has it been evaluated outside the development institution? Has it been tested in Asian populations or settings reasonably comparable with Viet Nam? Is there evidence from routine clinical use? Is performance known across different equipment, sites or patient subgroups?
A vendor should be able to discuss limitations without turning every answer into a sales message. “The model achieved 95% accuracy” is not enough if the vendor cannot explain the test population, denominator, confidence intervals, reference standard, prevalence or clinical consequences of error.
Marketing claims should also remain aligned with evidence. A study showing improved detection does not automatically prove reduced morbidity. Reduced reading time does not automatically demonstrate better patient outcomes. High user satisfaction does not establish clinical safety.
Healthcare organizations do not need to reject innovative technology because every uncertainty has not been eliminated. They do need to understand which uncertainties they are accepting, whether those uncertainties matter clinically, and whether controlled piloting, local validation or enhanced monitoring can address them.
Due diligence should include the vendor, not only the algorithm
A good algorithm can still come from a vendor that is poorly prepared to support healthcare deployment over time.
Clinical AI can create a relationship lasting years. The healthcare organization may depend on the provider for technical support, model maintenance, security patches, new versions, regulatory information, cloud infrastructure and incident investigation.
The buyer should therefore understand the organization behind the technology. Is there a clearly identifiable legal entity responsible for the product? Who provides support in Viet Nam? Does the company have relevant healthcare, quality, regulatory and cybersecurity capability? How mature is the product? What happens if a critical issue occurs outside normal working hours? Will the same support be available after implementation as during the sales process?
Organizational certifications can contribute to due diligence but should be interpreted correctly. TCVN ISO/IEC 42001:2025, identical to ISO/IEC 42001:2023, is an AI management-system standard. It specifies requirements and guidance for establishing, implementing, maintaining and continually improving an AI management system within an organization; it does not establish that an individual clinical product is safe, effective or suitable for a particular hospital.[13]
The question is not only “Is this a credible company?” It is also “Can this company support the clinical responsibility we are about to place on its product?”
Understand exactly where patient data goes
Data architecture should be understood before the contract is signed, not discovered during implementation.
A clinical AI system may operate entirely inside the hospital, send data to a domestic or regional cloud service, rely on infrastructure outside Viet Nam, use foreign subprocessors or transmit information back to the developer for support, monitoring or product improvement.
The buyer should know what personal data is collected, which data is actually necessary, where it is stored and processed, who can access it, how long it is retained, whether subprocessors are involved and whether the vendor uses any information for its own purposes.
Viet Nam’s Law on Personal Data Protection No. 91/2025/QH15, effective since 1 January 2026, is directly relevant. Article 26 contains specific requirements for personal data involving health information. Article 30 separately addresses personal data in AI, big data, blockchain, metaverse and cloud-computing environments, including purpose limitation, necessity and appropriate protection measures.[4]
Where the healthcare organization and vendor actually operate as personal-data controller and processor, Article 37 is also important. A processor may receive personal data only after the required processing agreement or contract is in place and must process the data in accordance with that agreement.[4]
The contractual allocation should therefore reflect the parties’ real roles. A vendor should not simply be labelled a “processor” because that wording is commercially convenient if its actual decisions about the purposes or means of processing indicate a different role.
Cross-border architecture should be identified before implementation
Cloud architecture can create cross-border personal-data issues even when the AI product is purchased from a local distributor.
Decree No. 356/2025/NĐ-CP implements the Personal Data Protection Law and specifically treats activities such as storing Vietnamese personal data on servers or foreign cloud services, transferring data to recipients outside Viet Nam, or sending data collected in Viet Nam to a foreign platform for continued processing as forms of cross-border personal-data transfer.[5] The Decree also establishes impact-assessment and documentation requirements where applicable.
The healthcare organization should therefore determine early whether the proposed architecture involves a cross-border transfer and who is responsible for preparing, filing, maintaining and updating the applicable documentation.
This should be visible during procurement because changing hosting architecture after contracting can be difficult. The practical question is not simply “Is the vendor GDPR compliant?” It is “Can this specific deployment comply with Vietnamese personal-data requirements as actually configured?”
The importance of this area is no longer theoretical. Decree No. 330/2026/NĐ-CP, effective since 19 August 2026, establishes administrative penalties for violations in cybersecurity and personal-data protection, including specific violations involving health information and healthcare applications.[9]
The contract should be explicit about secondary use of data
Healthcare organizations should not assume that data provided to operate an AI service will only be used to deliver that service.
The agreement should clearly address whether the vendor may use data for troubleshooting, performance monitoring, analytics, research, model training or retraining, benchmarking or development of future products. It should distinguish, where relevant, between patient data, derived information, logs, telemetry and other data generated through operation of the system.
This is especially important in clinical AI because real-world healthcare data can have substantial value in improving a commercial product. If secondary use is proposed, the organization should evaluate the legal basis, purpose, necessity, safeguards, patient implications and commercial consequences rather than allowing the issue to disappear into generic software terms.
A useful contracting question is: What can the vendor do with data generated or supplied through our use of the system, and what can it not do?
If the answer is difficult to determine from the agreement, the agreement is not clear enough.
Cybersecurity due diligence belongs in the procurement decision
Clinical AI can introduce new network connections, cloud dependencies, remote access, software components and interfaces. A vulnerability may therefore become more than an IT issue. It may interrupt care, expose data, alter information or affect the reliability of a clinical workflow.
Viet Nam’s Law on Cybersecurity No. 116/2025/QH15 has been effective since 1 July 2026. Its implementing framework includes Decree No. 331/2026/NĐ-CP on cybersecurity protection for information systems and Decree No. 333/2026/NĐ-CP detailing a number of provisions and implementation measures under the Cybersecurity Law.[6–8]
Vendor due diligence should therefore consider authentication, access control, encryption, vulnerability management, patching, security logging, remote access, backup and recovery, incident response and relevant third-party dependencies.
The organization should also consider clinical continuity. Does the AI stop functioning when connectivity is lost? Does a cloud outage interrupt the underlying clinical workflow? Is there a safe fallback? Can the AI component be disabled without disabling the medical system it supports?
For clinical AI, cybersecurity and continuity of care should be evaluated together.
Interoperability is a patient-safety issue, not just an IT convenience
An AI system can perform well technically and still fail in practice because it does not fit the organization’s systems and workflows.
The buyer should understand how the product will interact with the HIS, EMR, PACS, RIS, LIS, endoscopy platform, medical devices or other relevant infrastructure. What interfaces and standards are supported? Who builds and maintains the integration? Who resolves problems when another system is upgraded?
Workflow matters just as much. Where does the AI output appear? Does a clinician need to open another application? Will an alert arrive at the moment when it can affect care? Could the product create excessive alerts or additional manual reconciliation? Can clinicians see the underlying clinical information alongside the AI result?
An algorithm does not operate in isolation. The clinical system is the combination of technology, people and workflow. A procurement process that evaluates only model performance can therefore miss some of the most important reasons an AI system eventually succeeds or fails.
Human oversight should be specified before purchase
Vendors often describe their product as “decision support” or say that “the clinician remains responsible.” That statement alone does not establish meaningful oversight.
The healthcare organization should understand what users need in order to interpret the output safely. Can clinicians examine the underlying information? Can they disregard or override the AI result? Does the interface communicate relevant uncertainty and limitations? What happens when the AI and clinician disagree? Will the workflow realistically allow independent judgment, or will operational pressure gradually turn the AI output into a default decision?
Viet Nam’s AI framework emphasizes human-centered AI and human control. For high-risk systems, the AI Law and Decree No. 142 impose more specific responsibilities relating to human oversight and intervention.[1,2]
For procurement purposes, the important point is that human oversight should be reflected in product design, workflow, training and operational controls, not reduced to a contractual sentence stating that the physician remains responsible.
Ask what happens when the model changes
Traditional procurement often assumes that the product purchased today will remain substantially the same. AI makes that assumption increasingly unsafe.
A provider may update a model, change thresholds, retrain using new data, alter the user interface, change infrastructure or introduce new functionality. Even if the commercial product name remains unchanged, the system being used clinically may no longer be identical to the one originally evaluated.
This creates a central contracting question: Which changes can the vendor make without prior approval, and which changes require notification, review, testing or revalidation?
The AI Law and Decree No. 142 recognize that material changes can affect risk and may require reassessment, reclassification or renewed conformity assessment depending on the circumstances.[1,2] High-risk AI systems must undergo conformity assessment before use and when significant changes affect the basis of the earlier assessment.
Contracts should therefore address version identification, material-change notification and the healthcare organization’s right to review significant changes before they enter routine clinical use where appropriate.
The organization should also know whether it can remain temporarily on an existing version while a significant new version is evaluated. A “software update” should not automatically become an unreviewed change in clinical practice.
Monitoring responsibilities should be agreed before deployment
Procurement should establish not only whether the AI works at the beginning, but also how the organization will know whether it continues to work.
Who monitors performance? What information will the vendor provide? Can the hospital access logs or performance information needed for governance? Will the provider notify the organization if it discovers a material performance problem, safety signal or cybersecurity issue affecting the same product elsewhere? What happens if patient populations, equipment or workflows change?
The NIST AI Risk Management Framework provides useful voluntary guidance here. It specifically addresses third-party and supply-chain risks, regular monitoring of third-party AI resources, post-deployment monitoring, incident response, recovery, change management and decommissioning.[15]
As of 1 October 2026, AI RMF 1.0 remains NIST’s published framework, but NIST states that it is currently being revised. Organizations using it should therefore continue to monitor future revisions rather than treating the 2023 document as static.[15]
For AI-enabled medical devices, IMDRF’s final 2025 Good Machine Learning Practice principles similarly emphasize lifecycle thinking.[16] IMDRF is also developing a Technical Framework for Artificial Intelligence Life Cycle Management. As of 1 October 2026, N93 remains a proposed document following a public consultation that closed on 10 July 2026 rather than final IMDRF guidance.[17]
A contract that is detailed about implementation but silent about post-deployment performance and change is incomplete for clinically consequential AI.
Incident management should include the vendor
When an AI-related incident occurs, the healthcare organization may not have enough technical visibility to investigate alone. It may need model-version information, system events, logs, error records or technical analysis that only the provider can supply.
That dependency should be addressed during procurement rather than discovered during an incident. The contract or associated procedures should define how the provider is notified, expected response times according to severity, preservation of relevant records, cooperation in investigation and communication of material safety information discovered through other deployments where appropriate.
This is especially important where the healthcare organization has its own patient-safety or regulatory responsibilities and needs vendor-held information in order to meet them.
Vendor incident support should therefore not be treated as optional goodwill. For clinically consequential AI, it is part of the safety infrastructure.
Contracting should describe the product more precisely than the sales proposal
One of the main purposes of a contract is to convert commercial promises into clear responsibilities.
The contractual documentation should identify what is being supplied: the product and AI functions, agreed or permitted use, relevant version where appropriate, hosting arrangement, interfaces, implementation responsibilities, support services and ongoing service commitments.
Material commitments that influenced the procurement decision should not disappear when negotiations move from the sales presentation to standard legal terms. If the vendor promises particular availability, support response times, monitoring, training or implementation services, those commitments should be captured appropriately in the agreement, service levels or other binding documentation.
The contract should also be clear about what is not included. Does the price include integration? Updates? Training? Model monitoring? Additional sites or devices? New modules? Regulatory support? Data export at termination?
A low headline price can become expensive when essential implementation and governance functions are treated as additional services after the organization has become dependent on the product.
AI contracts need a realistic allocation of responsibility
No contract can remove legal responsibilities imposed on a healthcare organization, provider, clinician or other actor.
The purpose of contractual accountability is therefore not to transfer every AI risk to the vendor. It is to define who controls which risks, what each party is required to do and where cooperation is necessary.
The vendor may control development, model changes, security patches and some technical records. The healthcare organization controls local workflow, user authorization, implementation, staff training and important aspects of patient care. Monitoring, incident investigation and significant change review may require action by both.
Contract language should reflect that operational reality. Where appropriate and after legal review, agreements may need to address warranties and representations, regulatory compliance, data-processing responsibilities, security obligations, confidentiality, intellectual property, service levels, insurance, limitation of liability, indemnification and consequences of material breach.
There is no single clinical AI contract template that will be correct for every healthcare organization or procurement in Viet Nam.
Information and audit rights should be proportionate and usable
Healthcare organizations sometimes ask for broad audit rights that sound strong in a contract but are difficult to exercise in practice. At the other extreme, vendors may offer so little information that the healthcare organization cannot independently govern the system.
The goal should be usable and proportionate rights.
Can the organization obtain current regulatory documents, relevant validation reports, version history, material cybersecurity information, incident information, subprocessor information, agreed performance information and material-change notices? Where appropriate, can compliance with key contractual controls be verified through records, certifications, independent reports or audit?
A vendor may legitimately protect source code, detailed algorithms, model parameters, trade secrets and other proprietary information. Responsible procurement does not require maximum disclosure.
It requires sufficient information and verification rights for accountable use.
Subcontractors, cloud providers and external model providers should not remain invisible
The organization selling an AI product may not operate every component of the service.
It may rely on cloud providers, data-processing vendors, cybersecurity providers, external model providers or other subcontractors. Generative AI products may incorporate a foundation model developed and operated by another company.
Healthcare organizations should understand which third parties materially affect personal-data processing, system availability, model behavior, security and incident response. Where personal data is involved, these relationships must also be assessed under the parties’ actual roles and the requirements of the Personal Data Protection Law and Decree No. 356.[4,5]
Contracts should therefore address material subprocessors or other relevant third parties and changes to them to the extent appropriate to the deployment and legal framework.
A healthcare organization should not discover after a serious incident that its direct vendor does not control the component that failed and has no contractual mechanism to obtain the necessary information.
Avoid creating unnecessary vendor lock-in
Clinical AI can become difficult to replace once it is embedded in workflows, data flows, device integrations and staff routines. Exit should therefore be considered before entry.
Can the organization retrieve its data in a usable format? What happens to data held by the vendor after termination? How will integrations be disabled? Can clinically relevant historical information remain accessible where necessary? What happens if the vendor stops supporting the product or exits the market?
If the healthcare organization contributes local data, annotations, implementation knowledge or workflow designs, the rights and permitted uses associated with those contributions should also be understood.
A mature procurement process asks not only “How do we implement this system?” but also “How would we safely stop using it?”
Price should be evaluated as the total cost of responsible use
Clinical AI may be priced through an annual license, per-study fee, user subscription, equipment bundle, software module or cloud service. The visible price may represent only part of the actual cost.
Healthcare organizations should consider integration, validation, implementation, staff training, cybersecurity, infrastructure, storage, technical support, monitoring, upgrades and internal governance time. Expanding to additional sites, users or devices may also change the commercial model substantially.
The cost of fallback and continuity procedures should not be ignored. An AI system that produces modest productivity gains but requires extensive manual reconciliation or duplicate workflows may not deliver the expected value once the full implementation burden is included.
Economic evaluation should therefore ask whether the AI creates meaningful value after the cost of safe implementation and continued governance is considered.
A pilot should not compensate for poor due diligence
Piloting clinical AI can be extremely useful, but a pilot should not be used to postpone questions that should be understood before patients, clinicians or production data are materially exposed to the technology.
Regulatory status, intended use, vendor identity, material data flows, cybersecurity fundamentals and appropriate legal and governance controls should be understood before a clinical pilot proceeds.
The pilot then addresses different questions: Does the AI perform adequately in the local environment? Does it fit the workflow? Do clinicians use it as intended? Do unexpected safety signals appear? Can the organization monitor it effectively? Does the system generate enough clinical or operational value to justify wider deployment?
For many clinical deployments, a defensible pathway is:
Due diligence → Appropriate contractual and governance controls → Controlled pilot → Evaluation → Scale decision
This should not be treated as a rigid universal sequence. Technical evaluation or a limited proof-of-concept may occur earlier where legally permissible and appropriately controlled, particularly when no clinical decision or production personal data is involved.
The underlying principle is more important than the exact order: a pilot should reduce remaining uncertainty, not substitute for basic governance.
Public procurement should preserve clinical and technical due diligence
Organizations subject to Viet Nam’s statutory procurement framework face an additional challenge: ensuring that a legally compliant contractor-selection process also captures the characteristics that matter for responsible clinical AI.
Specifications should be objective, proportionate and consistent with the applicable procurement rules while still addressing clinically relevant evidence, regulatory status, interoperability, data protection, cybersecurity, implementation, monitoring and lifecycle support.
This is one reason multidisciplinary involvement before procurement documents are finalized is valuable. If important patient-safety or lifecycle requirements appear only after a vendor has been selected, the organization may find that they were never included in the procurement requirements, evaluation criteria, contract or price.
At the same time, technical specifications should avoid unnecessary requirements that effectively favor a particular vendor unless they are objectively justified and permitted under the applicable procurement framework.
Responsible AI procurement and fair procurement should reinforce each other. The aim is to define what the healthcare organization actually needs, not to reverse-engineer requirements around a preferred product.
A practical vendor due-diligence process can remain manageable
Healthcare organizations do not need a hundred-page questionnaire for every AI application.
The depth of due diligence should be proportionate to the potential clinical consequences, type and sensitivity of data, degree of autonomy, number of patients exposed, difficulty of detecting errors and dependency created by the technology.
For a clinically consequential system, however, the organization should normally be able to answer a connected set of questions before making a final commitment: What healthcare problem are we solving? What exactly does the AI do? What is its legal and regulatory status? What evidence supports the intended use? How relevant is that evidence to our patients and workflows? What personal data will be processed and where? How are cybersecurity and continuity managed? How will the system integrate into existing workflows? What does meaningful human oversight look like? How are model changes controlled? What will be monitored after deployment? How will incidents be investigated? What contractual rights allow us to manage those issues? How would we safely exit?
Those questions should not be answered by procurement staff alone. Clinical leadership, quality and patient safety, IT, cybersecurity, data protection, legal or compliance, procurement and frontline users may all need to contribute. The level of involvement can be scaled according to the use case.
The final output should be a documented organizational decision, not simply a folder containing vendor documents.
Some vendor responses should trigger deeper review
Not every incomplete answer means that a product should automatically be rejected. Early-stage technologies may have legitimate evidence limitations, and smaller vendors may document their systems differently from large multinational companies.
But some patterns deserve deeper scrutiny.
A vendor that cannot define the intended use clearly, cannot identify which version was validated, avoids discussing limitations, provides only internally generated performance claims, cannot describe material data flows, gives vague answers about model updates or cannot explain how incidents will be supported is asking the healthcare organization to accept risks that it cannot properly evaluate.
The same applies when clinical or regulatory questions are repeatedly answered with “the AI is only advisory” without explaining how clinicians will actually use and interact with the output.
Responsible procurement is not about finding a vendor that claims every risk has been eliminated. It is about finding a vendor that understands its risks well enough to discuss them transparently and manage them with the healthcare organization.
Procurement does not transfer responsibility for clinical use
Buying a regulated product does not mean the hospital has outsourced its governance responsibilities. A strong contract does not replace responsible local implementation. A reputable vendor does not determine whether clinicians use a system safely. Foreign regulatory clearance or international certification does not establish that a product will work appropriately in every Vietnamese healthcare environment.
The vendor and healthcare organization control different parts of the AI lifecycle. The provider may control the model, software architecture and important aspects of technical development. The healthcare organization determines how the system enters its workflow, who is authorized to use it, which patients are exposed, how human oversight functions locally and whether continued use remains acceptable in its environment.
That is why clinical AI procurement belongs inside the healthcare organization’s broader AI governance operating model. The organization is selecting more than a piece of technology. It is selecting a long-term dependency, a data relationship, a safety relationship and a governance relationship.
From buying AI to acquiring a governable clinical capability
The best clinical AI procurement decision is not necessarily the product with the highest published accuracy, the strongest brand, the lowest price or the most impressive demonstration.
It is the product and commercial relationship for which the healthcare organization can build a defensible chain from healthcare need to evidence, regulatory status, implementation, patient safety, accountability and continued monitoring.
That requires asking harder questions before commitment: What exactly are we buying? What problem does it solve? What evidence supports it? What do we still not know? Where does our data go? Who controls model changes? What information will remain available after deployment? How will an incident be investigated? What happens if a critical third-party dependency fails? Can we safely exit the relationship?
If those questions are addressed early, procurement becomes more than a commercial transaction. It becomes one of the first major control points for responsible AI implementation.
For healthcare leaders in Viet Nam, the practical question should therefore not be simply “Which AI vendor should we choose?”
It should be:
“Which vendor and contractual arrangement will allow us to use this AI safely, responsibly and accountably throughout its lifecycle?”
That is the difference between purchasing AI and procuring a clinical capability that the organization can actually govern.
Professional education notice
This article is intended for professional education and knowledge exchange. It does not constitute individualized legal, procurement, regulatory, clinical, medical device, cybersecurity, personal-data, commercial or contractual advice.
The vendor due-diligence and contracting practices discussed here are practical governance recommendations and should not automatically be interpreted as statutory requirements. Applicable obligations depend on the healthcare organization, funding source, procurement structure, AI system, risk classification, medical-device status, personal-data roles, technical architecture and intended deployment.
Public healthcare organizations and other entities or transactions falling within the scope of Viet Nam’s procurement legislation should determine and follow the specific procedures required under the Law on Bidding and applicable implementing instruments.
Foreign regulatory clearances, certifications and international standards may support due diligence but do not by themselves establish compliance with Vietnamese law. Contractual arrangements also cannot remove responsibilities that applicable law assigns to providers, deployers, healthcare organizations, healthcare professionals or other actors.
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.
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.
National Assembly of Viet Nam. Law No. 116/2025/QH15 on Cybersecurity. Adopted 10 December 2025; effective 1 July 2026.
Government of Viet Nam. Decree No. 331/2026/NĐ-CP on Cybersecurity Protection for Information Systems. 19 August 2026; effective 19 August 2026.
Government of Viet Nam. Decree No. 333/2026/NĐ-CP Detailing a Number of Articles and Measures for Implementation of the Cybersecurity Law. 19 August 2026; 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. 19 August 2026; effective 19 August 2026.
Ministry of Health of Viet Nam. Consolidated Document No. 08/VBHN-BYT on Medical Device Management. 6 March 2026.
Office of the National Assembly of Viet Nam. Consolidated Document No. 74/VBHN-VPQH — Law on Bidding. 25 March 2026.
Ministry of Finance of Viet Nam. Consolidated Document No. 36/2026/VBHN-NĐ-BTC Detailing a Number of Articles and Measures for Implementation of the Law on Bidding on Contractor Selection. 23 September 2026.
Viet Nam Standards and Quality Institute. TCVN ISO/IEC 42001:2025 — Information technology – Artificial intelligence – Management system. Identical to ISO/IEC 42001:2023.
Government Digital Service. A Buyer’s Guide to AI in Health and Care. Organisation: NHS. Published 30 January 2025.
National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1; 2023.
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.
International Medical Device Regulators Forum. N93: Technical Framework for Artificial Intelligence Life Cycle Management. Proposed document; public consultation closed 10 July 2026.