Clinical AI Governance Assurance in Viet Nam: How Healthcare Organizations Should Test Whether AI Controls Work in Practice
PRACTICAL FRAMEWORKS & TOOLS
Clinical AI Governance Assurance in Viet Nam: How Healthcare Organizations Should Test Whether AI Controls Work in Practice
PRACTICAL FRAMEWORK & TOOL
Last reviewed: 2 October 2026
A healthcare organization may have an AI policy, an approval committee, an AI inventory, a risk register, requirements for human oversight and a process for monitoring clinical AI after go-live. On paper, the governance structure may look strong. But that still does not answer the most important question: do those controls actually work when AI is used in real clinical care?
An AI inventory may exist but miss systems that staff have started using independently. A policy may require local validation, but nobody can produce the evidence supporting the deployment decision. A monitoring dashboard may collect performance data, but no one regularly reviews it. Human oversight may be required, yet clinicians may not know when to question the AI or how to escalate a suspected failure. An incident procedure may exist, but staff may not recognize AI as a contributing factor when a near miss occurs.
This is the difference between governance design and governance assurance. Governance defines what should happen. Assurance tests whether it is happening, whether there is evidence that it is happening, and whether the controls remain effective as the technology, clinical workflow and organization change.
For healthcare organizations in Viet Nam, that distinction is becoming increasingly important. The Law on Artificial Intelligence No. 134/2025/QH15 has been in force since 1 March 2026, Decree No. 142/2026/NĐ-CP since 1 May 2026, and Decision No. 33/2026/QĐ-TTg establishing the current high-risk AI list since 15 August 2026.[1–3] Viet Nam’s AI framework also places additional emphasis on risk management in healthcare, including patient safety, reliability in real-world use and protection of health data.[1]
The next governance challenge is therefore not only to create controls, but to establish reasonable confidence that those controls operate in practice.
A policy is not the same as an effective control
Healthcare quality and patient safety have long recognized that writing a procedure does not mean the procedure is reliably followed. AI governance is no different.
A hospital may require every clinical AI system to have an accountable owner. Assurance asks whether every deployed system actually has one, whether that person understands the role, and whether important governance decisions can be traced back to clear ownership. A policy may require human review of AI outputs. Assurance asks whether users genuinely review them, whether they have enough information and time to detect errors, whether they can reject the output, and whether meaningful intervention is possible in the real workflow.
The same applies to monitoring. A policy may require post-deployment surveillance, but assurance asks whether relevant performance and safety indicators are actually reviewed, whether thresholds or escalation criteria have been defined, whether clinically important subgroup or workflow problems can be detected, who acts on the results, and what happens when a signal becomes concerning.
The distinction is simple: control design asks whether an appropriate control exists; control effectiveness asks whether that control actually works. Clinical AI governance needs both.
Assurance is not the same as conformity assessment
This distinction is particularly important under Viet Nam’s current AI framework.
Article 13 of the AI Law requires high-risk AI systems to undergo conformity assessment before being put into use and again when a significant change occurs during use. The applicable route depends on the system. Where a high-risk system belongs to the subset that requires conformity certification before use, assessment must be performed by a registered or recognized conformity-assessment body. For other high-risk systems, the provider may conduct a self-assessment or engage a registered or recognized conformity-assessment body.[1] Decree No. 142 operationalizes these requirements and provides that providers and deployers must carry out conformity assessment in accordance with the Law and the Decree.[2]
That statutory process should not be confused with the organizational assurance approach described in this article.
Clinical AI governance assurance, as used here, means an internal or organization-commissioned process for checking whether governance controls are appropriately designed and operating as intended. It can support patient safety, quality management, risk management and legal compliance, but it is not itself a statutory conformity assessment, certification or substitute for one where Vietnamese law requires it.
Nor should every assurance activity automatically be called an “audit.” Formal internal audit may have a defined mandate, independence requirements, methods and reporting lines. A clinical AI assurance review may instead be performed by quality, patient safety, clinical governance, enterprise risk, IT, privacy, cybersecurity or a multidisciplinary team, depending on the organization and the degree of independence required.
Terminology matters because assurance should strengthen governance without creating a false impression that an internal review carries regulatory or certification status.
There is also a transitional issue that remains relevant as of 2 October 2026. Under Decision No. 33, systems on the high-risk list that were already operating before 15 August 2026 must complete applicable compliance obligations by 1 September 2027 for healthcare, education and finance. Systems put into operation during the six-month period following the Decision’s effective date must complete the applicable obligations before 1 March 2027.[3] These transitional arrangements affect the timing of statutory compliance; they do not remove the organizational need to understand and manage patient-safety risk while the system is in use.
Viet Nam’s AI framework already points toward operating effectiveness
The regulatory direction is not limited to having documentation.
Article 4 of the AI Law establishes principles including human control and the ability to intervene, system safety, data security, accountability and the ability to inspect and monitor the development and operation of AI systems. Article 6 goes further for essential fields that directly affect life and health and specifically addresses risk management in healthcare, including patient safety, real-world reliability and health-data protection.[1]
Article 12 places responsibilities on developers, providers, deployers and users to ensure safety, security and reliability and to detect and address incidents capable of harming people, property, data or social order. For serious incidents, deployers and users must record the incident, provide timely notification and cooperate in remediation.[1]
For high-risk AI, Article 14 is more specific. Deployers must operate and monitor systems within their classified purpose, scope and risk; protect data and maintain human intervention capability; comply with applicable AI technical standards and regulations; meet transparency and incident-management obligations; provide accountability information; and cooperate with providers and competent authorities in inspection, assessment, post-market review and remediation.[1]
Decree No. 142 adds operational detail. For high-risk systems, deployers must organize risk management during deployment and operation, operate systems within defined conditions and limitations, monitor for deviations, risks and incidents, maintain human supervision and intervention, apply measures when risks emerge, and coordinate with providers when significant changes or incidents occur.[2]
The practical implication is straightforward: for clinical AI, a policy statement alone should not be treated as evidence that risk is actually being controlled.
Assurance should test evidence, not intentions
A useful assurance review is evidence-based.
If leadership says, “All clinical AI is reviewed before deployment,” the assurance question is not whether leadership believes that statement. It is whether the reviewer can select deployed systems and trace them back to documented assessment and approval. If the organization says, “Clinical staff are trained before using AI,” assurance looks for training records, competency expectations, interviews with actual users and evidence that they understand the limitations and escalation process.
If policy states that AI incidents are monitored, assurance examines the incident-reporting system, near-miss records, vendor communications and frontline understanding to determine whether an AI-related event would actually be recognized.
Evidence may come from documents, system logs, dashboards, meeting minutes, contracts, interviews, direct observation and samples of real cases. No single source should automatically be treated as proof that a control works.
Healthcare organizations can also borrow a familiar method from quality and patient-safety practice: the tracer. Rather than reviewing governance only from the boardroom, the assurance team follows an AI system through the real care pathway, from approval and staff training to patient encounter, AI output, clinician action, monitoring, incident management and subsequent system change. A tracer often reveals gaps that a policy review will not.
Start with the AI inventory, but verify it
Assurance begins with knowing what AI the organization actually uses. The inventory should identify the system, version, provider, intended use, organizational owner, clinical department, recorded statutory AI risk classification, deployment status, data involved and relevant governance controls. For higher-impact systems, it should also link to supporting evidence such as approval, validation, monitoring, incident and change records.
But the existence of an inventory does not prove that it is complete.
A review can compare the inventory with procurement records, IT integrations, software configurations, vendor contracts, departmental interviews and staff use of public or enterprise generative-AI tools. Differences may reveal unregistered systems, systems that were supposedly retired but remain active, or approved platforms being used for purposes that were never assessed.
The more useful question is therefore not merely “Do we have an AI inventory?” but “Can we demonstrate that the inventory reflects what is actually being used?”
Test whether accountability is real
Many organizations assign an “AI owner” without defining what ownership means. Assurance should determine whether each clinically significant use case has clear responsibility for clinical use, technical operation, vendor management, data governance, monitoring and patient-safety response.
Those responsibilities do not necessarily need to sit with one person, but they should not disappear between departments.
A useful test is to select one AI system and ask relevant people independently who can approve a new use, who reviews performance, who determines whether an incident requires escalation, who can suspend the system, who communicates with the vendor and who decides whether a major update requires reassessment.
If clinical, IT, quality and procurement teams give incompatible answers, the governance structure may exist formally without functioning reliably.
Accountability becomes meaningful when decision rights remain clear when something goes wrong.
Verify approved use against real-world use
An AI system can be well governed at approval and gradually move into a different use without any technical modification.
An imaging AI approved as a second reader may become the first result clinicians consult. A generative-AI assistant approved for administrative drafting may begin summarizing patient records. A decision-support system approved for one population may spread informally to another.
Assurance should therefore compare the approved use with actual use. This can involve user interviews, workflow observation, access patterns and selected case tracing. The reviewer needs to understand who uses the system, which patients are affected, what decisions it influences and whether local adaptations have changed its role.
Where actual use is materially different from the approved use, a new clinical risk assessment, validation or governance decision may be appropriate. If deployment, modification, integration, function or intended purpose creates new or higher risks, Viet Nam’s framework also requires review of the statutory classification in coordination with the provider.[2]
Clinical drift and regulatory reclassification are not the same thing, but a mature assurance process needs to recognize when either question should be reopened.
Local validation should be traceable, not merely claimed
An assurance review should be able to show why the organization believed an AI system was suitable for local use before routine deployment.
This does not mean every AI application requires the same validation design. The level of evidence should be proportionate to clinical impact, intended use, uncertainty in the available evidence and the local setting.
Where local validation was considered necessary, however, the reasoning should be traceable. The organization should be able to identify the system and version assessed, population and setting, data used, predefined measures, results, limitations, governance decision and any conditions attached to deployment.
It should also be possible to determine whether the system operating today is materially the same system that was assessed. If the model, configuration, interface, intended clinical function or workflow has changed, earlier evidence may no longer answer the current question.
WHO’s 2023 Regulatory Considerations on Artificial Intelligence for Health discusses intended use, analytical and clinical validation, lifecycle risk management, documentation, monitoring and change management as important regulatory considerations. WHO explicitly describes the publication as a high-level, nonexclusive resource rather than guidance, a regulatory framework or policy, so these points should be used as international considerations rather than presented as legal requirements in Viet Nam.[4]
The assurance question is therefore not simply “Was this validated?” It is “Can we trace the evidence and reasoning that justified deployment, and does that reasoning still apply to the system we are using today?”
Human oversight should be tested in the workflow
Human oversight is one of the clearest examples of a control that may look stronger in a policy than in practice.
A system may technically allow a clinician to reject an AI output. That does not establish that meaningful oversight actually occurs. The assurance review should determine whether users understand the system’s intended role and limitations, can independently access relevant clinical information, have enough time to question the output, possess the authority to disagree and work in an environment where overriding AI is realistically possible.
Decree No. 142 treats human supervision and intervention as a core risk-management requirement for high-risk AI and requires deployers to maintain these mechanisms during use.[2]
One useful assurance technique is to examine situations in which users disagreed with or did not follow an AI recommendation. If no disagreement can ever be identified after extensive use, that does not necessarily prove exceptional AI performance. It may justify examining automation bias, workflow behavior or whether disagreement is captured at all.
Where human oversight is a material control, the organization should be able to show evidence that it functions in practice.
Monitoring should lead to decisions
Many AI governance programs stop at dashboards.
A dashboard may show usage, sensitivity, false-positive rates, latency, downtime, subgroup performance or other indicators. Assurance asks what happens after those data are generated.
Who reviews the information? At what frequency? Which signals trigger investigation? What thresholds or criteria require action? Can monitoring result in restricted use, enhanced manual review, vendor escalation, revalidation or temporary suspension? Are the decisions documented?
WHO’s regulatory considerations emphasize a lifecycle perspective that includes post-deployment monitoring and change management because real-world performance may evolve over time.[4]
In practice, the strongest evidence of effective monitoring is often not the dashboard itself. It is the record showing that a meaningful signal was noticed, interpreted and acted upon.
Incident processes should capture AI-related events
An AI-related patient-safety event may not initially look like an “AI incident.”
It may present as a missed diagnosis, inappropriate prioritization, inaccurate documentation, delayed treatment, repeated false alerts or a clinician acting on an incorrect recommendation. Unless staff know to ask whether AI contributed, the technology may never appear in the incident analysis.
Assurance should therefore test whether the organization’s existing incident-management process can identify AI as a contributing factor, including in near misses rather than only in events causing actual harm.
The review should examine whether frontline staff know how to raise an AI-related concern, whether incident reporting can identify the relevant AI system or version, whether quality and patient-safety teams can investigate the role of AI, whether vendors are informed when appropriate and whether learning feeds back into monitoring and governance.
This is also relevant to Viet Nam’s AI Law. Article 12 creates incident-management responsibilities for developers, providers, deployers and users, while high-risk deployers have additional obligations under Article 14.[1]
An incident process is effective only if the organization can recognize the incident when it happens.
Change control is an assurance priority
AI governance can become outdated quickly. A model may be replaced, software updated, another hospital site added, a new population included, integration changed or an AI output given greater influence within the workflow while the user interface remains almost identical.
Assurance should therefore test whether changes that warrant review are actually reaching the governance process.
One useful method is to select several changes from the previous six or twelve months and trace them backward. Was the change detected? Was its significance assessed? Was additional testing or validation required? Were users informed? Were governance documents updated? Was the statutory classification reconsidered where relevant?
For high-risk AI, the Law requires conformity assessment when a significant change occurs, and Decree No. 142 requires risk-management arrangements to be reviewed and updated when significant changes affect the system.[1,2]
Change control is therefore not mainly a document-management exercise. It prevents evidence collected for yesterday’s system from being automatically assumed to support tomorrow’s system.
Vendor governance should also be tested
Healthcare organizations often depend on information that only a vendor possesses. Contracts and governance arrangements therefore need to provide enough visibility and cooperation for the organization to manage clinical use safely.
Relevant arrangements may include notification of model or software changes, access to meaningful performance information, incident cooperation, cybersecurity responsibilities, data-processing terms, downtime support and a clear escalation route for clinically significant concerns.
The assurance question is not merely whether those clauses exist. It is whether they work when needed.
Has the vendor actually notified the organization of previous changes? Are agreed performance or security reports received? Can a clinically important failure be investigated? Is there a named escalation route? Can unsafe deployment be restricted or paused?
Vendor governance becomes effective when contractual rights translate into operational action.
AI assurance should connect with existing healthcare governance
Clinical AI should not create a completely separate quality system beside the organization’s existing governance structure.
A stronger approach is to connect AI assurance with processes that already exist in clinical governance, patient safety, quality management, medical-device management, privacy, cybersecurity, procurement, workforce competency and incident investigation.
AI-related incidents can enter the existing patient-safety system rather than an isolated technology database. AI competency requirements can be linked to established education and competency-management processes. Vendor controls can connect with procurement and contract management. Monitoring findings can feed quality or clinical governance committees.
This reduces duplication and makes governance more likely to survive after the initial implementation phase.
International standards point in a similar direction. ISO/IEC 42001:2023 specifies requirements for establishing, implementing, maintaining and continually improving an AI management system. ISO/IEC 23894:2023 provides guidance on integrating AI risk management into organizational activities, while ISO/IEC 42005:2025 provides guidance for AI system impact assessment across the lifecycle.[5–7] These standards are useful international reference points, but they are not automatically statutory requirements for healthcare organizations in Viet Nam unless they become applicable through law, regulation, contract, certification commitment or another binding basis. ISO
A practical Clinical AI Governance Assurance Review
A healthcare organization can structure an assurance review around the following domains:
AI inventory and classification: Can the organization demonstrate that deployed AI systems are identified, current and linked to their intended uses, owners and recorded statutory classifications?
Governance and accountability: Are approval authority, operational ownership, clinical accountability, escalation and suspension rights clear and functioning?
Evidence and local validation: Can the organization trace the evidence supporting deployment, limitations identified and any local validation required for the actual population, setting and workflow?
Data, privacy and cybersecurity: Are data flows understood and controlled, sensitive information appropriately protected, access governed and cybersecurity responsibilities operating as intended?
Human oversight: Do users have the information, competency, authority and practical ability to question, reject or override AI outputs where appropriate?
Workforce competency: Have relevant users been trained and assessed for the specific use case rather than receiving only general AI-awareness education?
Vendor and third-party governance: Are update notification, performance information, data responsibilities, incident cooperation and escalation arrangements working in practice?
Performance and safety monitoring: Are meaningful indicators defined, reviewed and acted upon, including clinically relevant errors, subgroup differences, drift and workflow effects where appropriate?
Incident and near-miss management: Can the organization recognize when AI may have contributed to an event, investigate it and translate lessons into corrective action?
Change control and revalidation: Are significant technical, clinical, workflow or vendor changes detected and assessed before previous approval or evidence is assumed to remain valid?
Transparency and patient communication: Where applicable, are transparency, disclosure and patient-facing safeguards actually implemented in the deployed workflow?
Documentation and management review: Can leadership see significant AI risks, findings, incidents, unresolved actions and material changes, and is there evidence that these issues are being addressed?
This Clinical AI Governance Assurance Review is a practical organizational framework. It is not a statutory conformity-assessment procedure, certification scheme or substitute for any regulatory assessment required under Vietnamese law.
Test a sample deeply rather than everything superficially
An organization does not necessarily need to review every control for every AI system at the same depth. A risk-based assurance program can prioritize systems with greater potential clinical consequences, complex data processing, broad deployment, limited evidence, recent significant change, previous incidents or heavy dependence on human oversight.
For a larger healthcare organization, one practical approach is to select representative systems and conduct end-to-end tracers. One might be a diagnostic AI system, another a prediction or workflow system, and another a generative-AI application. Each tracer follows the system from inventory and approval through actual use, monitoring, incidents and change control.
This can provide more insight than reviewing hundreds of policies and checkboxes. The objective is not to prove that governance is perfect. It is to identify where controls are weaker than the organization believes they are.
Findings should lead to corrective action, not just a report
Assurance has little value if it ends with a report that nobody acts upon. Each significant finding should have an accountable owner, corrective action, target date and method of follow-up. More serious findings may require temporary risk controls while a permanent solution is developed.
For example, discovering that a clinically significant AI system has no current monitoring process may justify enhanced manual review while monitoring is established. Finding that staff are using a system outside its approved population may require immediate use restrictions. Discovering that a vendor implemented a significant update without governance review may require reassessment or revalidation.
The assurance process should then determine whether corrective actions were not only completed but effective.
This is an important lesson from mature healthcare quality systems: closure is not the same as effectiveness. A corrective action can be marked complete while the underlying risk remains.
Independence should match the importance of the question
The people who design and operate a control are often best placed to monitor it day to day. But they should not always be the only people deciding whether it works.
For routine controls, clinical or operational owners may conduct ongoing self-checks. Quality, patient safety, enterprise risk, privacy or information-security teams can provide an additional level of challenge and assurance. Where an organization has an internal audit function, a more formal independent review may be appropriate for enterprise-level governance or particularly significant risks.
The degree of independence should be proportionate to the importance of the system and the decision being assured.
A clinical department does not need an external auditor every time it reviews an AI dashboard. But an organization should be cautious about concluding that its entire AI governance program is effective solely because the team that designed the program says that it is.
Management needs an assurance picture, not hundreds of metrics
Senior leadership does not need every AI data point. It needs to know whether the governance system is working and where it is not.
A useful management view can identify higher-impact AI systems, controls that have or have not been tested, significant unresolved findings, current safety or performance signals, recent incidents, overdue corrective actions, important vendor or model changes and decisions requiring leadership attention.
This helps governance bodies distinguish among three very different positions: we have a policy; the control has been implemented; and we have evidence that the control is operating effectively.
The third is the position that assurance is intended to support.
What this means for healthcare organizations in Viet Nam
Viet Nam’s AI regulatory framework has moved healthcare organizations into a new phase. The immediate challenge is no longer only to understand the law or create AI governance structures. Organizations increasingly need to understand whether AI remains safe, reliable and controlled once it is operating in real healthcare environments.
That is particularly relevant because the AI Law explicitly identifies healthcare as a field requiring stronger risk management and attention to real-world reliability. For systems legally classified as high-risk, the Law and Decree impose more specific ongoing requirements concerning risk management, human intervention, monitoring, incidents, accountability and cooperation with regulatory oversight.[1,2]
But the logic of assurance should not be limited to systems on the statutory high-risk list.
A clinically important AI system outside that list may still warrant strong organizational assurance because patient-safety risk depends on how the technology is actually used. Internal assurance should therefore be proportionate to clinical significance and local risk rather than treated simply as a consequence of a statutory label.
WHO/Europe’s September 2026 report reinforces this broader point. Its Knowledge Community identified fragmented and biased datasets, governance gaps, unclear accountability and AI-literacy deficits among major barriers to responsible AI deployment, while strong governance frameworks, transparency, codesign and equitable access were identified as important enablers. WHO/Europe summarized the central message as governance readiness, rather than speed of deployment, being the better measure of responsible progress.[8]
For healthcare leaders, the practical progression is therefore:
First, define the governance. Then implement the controls. Then test whether they work.
A clinical AI program becomes mature not when it has the most policies, committees or dashboards, but when the organization can link important risks to real controls, show that those controls operate, detect when they fail and demonstrate that weaknesses are corrected.
The most important assurance question is not simply “Do we have AI governance?”
It is “What evidence do we have that our AI governance is actually protecting patients in practice?”
That is the point at which responsible AI governance becomes part of healthcare quality and patient safety rather than simply a technology policy.
Professional education notice
This article is intended for professional education and knowledge exchange. It does not constitute individualized legal, regulatory, clinical, conformity-assessment, certification, internal-audit, medical-device, cybersecurity or personal-data advice.
Clinical AI governance assurance and the Clinical AI Governance Assurance Review are practical organizational concepts used in this article. They are not statutory assessment methods established by the Law on Artificial Intelligence, Decree No. 142/2026/NĐ-CP or Decision No. 33/2026/QĐ-TTg.
An internal assurance review does not replace a legally required conformity assessment, certification, inspection, medical-device requirement or other regulatory obligation. Where conformity assessment is legally required for a high-risk AI system, the applicable statutory method must be determined under Article 13 of the AI Law, Decree No. 142/2026/NĐ-CP and the relevant high-risk list.
References to ISO/IEC standards in this article are provided as international governance and risk-management references. They should not be interpreted as mandatory requirements for a Vietnamese healthcare organization unless they become applicable through law, regulation, contract, certification commitment or another binding basis.
The scope, independence and depth of organizational assurance should be proportionate to the specific AI system, its intended use, its effect on patients and workflow, and the regulatory requirements that apply.
References
[1] National Assembly of Viet Nam. Law No. 134/2025/QH15 on Artificial Intelligence. Adopted 10 December 2025; effective 1 March 2026.
[2] Government of Viet Nam. Decree No. 142/2026/NĐ-CP Detailing a Number of Articles and Measures for Implementation of the Law on Artificial Intelligence. Issued 30 April 2026; effective 1 May 2026.
[3] Prime Minister of Viet Nam. Decision No. 33/2026/QĐ-TTg Promulgating the List of High-Risk Artificial Intelligence Systems. Issued 30 June 2026; effective 15 August 2026.
[4] World Health Organization. Regulatory Considerations on Artificial Intelligence for Health. 19 October 2023.
[5] International Organization for Standardization. ISO/IEC 42001:2023 — Information Technology — Artificial Intelligence — Management System. 2023.
[6] International Organization for Standardization. ISO/IEC 23894:2023 — Information Technology — Artificial Intelligence — Guidance on Risk Management. 2023.
[7] International Organization for Standardization. ISO/IEC 42005:2025 — Information Technology — Artificial Intelligence (AI) — AI System Impact Assessment. 2025.
[8] WHO Regional Office for Europe. Report of the Knowledge Community on Responsible Artificial Intelligence in Health. 1 September 2026.