Stress-Testing Clinical AI in Viet Nam: A Practical Framework for Red Teaming, Edge Cases and Failure-Oriented Testing Before and After Go-Live
PRACTICAL FRAMEWORKS & TOOLS
Stress-Testing Clinical AI in Viet Nam: A Practical Framework for Red Teaming, Edge Cases and Failure-Oriented Testing Before and After Go-Live
IMPLEMENTATION INSIGHT
Last reviewed: 3 October 2026
A clinical AI system can perform well during validation and still fail in exactly the situation in which its output matters most. The patient may be much younger or older than most people in the validation dataset. Two diagnoses may interact in an unusual way. A laboratory value may arrive in an unexpected unit. A critical field may be missing. An emergency may initially resemble a routine complaint. A clinician may phrase the same question in Vietnamese, English or a mixture of both. A network delay may make supposedly current data several hours old. A generative-AI assistant may receive an authoritative-looking instruction designed to override its safeguards. An AI agent may correctly complete the first four steps of a task and make a dangerous decision at the fifth.
These failures do not necessarily appear when a system is tested mainly on clean, typical cases. Clinical AI evaluation therefore needs to ask two different questions. The first is familiar: How well does the system perform under expected conditions? The second is less comfortable but equally important: How does the system fail when conditions are difficult, unusual, incomplete, misleading or deliberately adversarial?
Stress testing is about finding that second answer before go-live and continuing to challenge it after deployment.
Validation and stress testing answer different questions
Conventional validation asks whether an AI system performs adequately on a defined dataset or set of scenarios. Depending on the use case, this may involve discrimination, calibration, sensitivity, specificity, predictive values, segmentation accuracy, factual correctness, task completion or other measures. These remain essential.
Stress testing starts from a different premise. Rather than estimating typical or average performance, it deliberately looks for conditions under which the system becomes unreliable, unsafe or difficult to control. An edge case is not simply a rare case. It is a situation near or beyond the assumptions under which the system normally operates: an unusual clinical presentation, a difficult combination of variables, an uncommon population, a technical boundary condition or a workflow situation that exposes a hidden dependency. A rare event with negligible consequence may deserve little attention, while a rare event capable of delaying recognition of sepsis or producing an unsafe medication recommendation may deserve extensive testing.
Red teaming goes further by deliberately challenging the system to uncover adverse behavior, vulnerabilities or safeguards that do not hold under pressure. NIST describes AI red teaming as an adversarial form of testing intended to expose undesirable behavior and vulnerabilities and emphasizes that the value of the exercise depends substantially on the expertise and perspectives of the people conducting it [8]. NIST's September 2026 ARIA Evaluation Planning Manual similarly places red teaming alongside model testing and user testing as complementary components of holistic AI evaluation [9].
Clinical red teaming is therefore broader than cybersecurity penetration testing. It can include prompt injection and security attacks, but it should also try to uncover unsafe clinical reasoning, inappropriate certainty, harmful omissions, privacy failures, subgroup problems, failures of escalation, misleading interfaces and unsafe tool use. A system can be technically secure and still be clinically unsafe.
Recent healthcare research illustrates why these approaches matter. A 2025 npj Digital Medicine study brought together clinicians, medical and engineering students, and technical professionals to red-team language models using realistic medical scenarios. Among 1,504 responses to 376 unique prompts, reviewers classified 20.1% as inappropriate across safety, privacy, hallucination or accuracy, and bias domains. That figure is specific to the tested systems and study methodology and should not be generalized to all clinical AI, but the study shows how adversarial exploration can expose problems conventional medical benchmarks were not designed to reveal [10].
Research in 2026 has gone further. A Scientific Reports study distinguishes failures of document adherence from failures of instruction adherence and demonstrates how sustained multi-turn interactions can expose vulnerabilities missed by single-turn tests [11]. Dynamic red-teaming research in Nature Health similarly identified a substantial gap between strong static benchmark performance and reliability under adaptive adversarial testing across robustness, privacy, bias–fairness and hallucination or factual inaccuracy [12]. A structured Nature Medicine study of triage recommendations using 60 clinician-authored vignettes and 960 responses found that important failures were concentrated at clinical extremes rather than distributed evenly across cases [13]. Together, these studies reinforce a practical point: acceptable average performance does not tell an organization how the system behaves at its most consequential boundaries.
Start with possible harm, not with a collection of difficult cases
A common approach is to build an “edge-case dataset” and then see how the model performs. A stronger approach starts one step earlier: with the ways the system could plausibly harm a patient, clinician or healthcare organization.
For a deterioration-prediction model, failure might mean missing a genuinely deteriorating patient, generating excessive false alerts, processing stale information or interpreting an absent laboratory result incorrectly. For imaging AI, important conditions might include unusual anatomy, implants, image artifacts, low-quality acquisition, protocol differences or pathology poorly represented during development. For an AI documentation assistant, the relevant failure may be inventing a diagnosis, dropping an allergy, attributing a statement to the wrong patient or converting uncertainty into a definitive finding.
For generative clinical AI, the failure surface is wider. The system may provide an unsupported treatment recommendation, miss a contraindication, fabricate or misrepresent a citation, use obsolete evidence or express unjustified confidence when essential information is missing. For an agentic system, the problem can extend beyond the final answer: the AI may retrieve the wrong record, call the wrong tool, repeat an action, act outside its intended authority or propagate an early error through several later steps.
A 2026 Nature review of LLM safety and security in healthcare maps risks across design, data, model, inference and deployment environments, illustrating why evaluation needs to consider the complete system rather than the model in isolation [15]. The governance question should therefore not only be “Can we make the model wrong?” It should also be “Can a model error, data problem, interface problem or workflow condition make the surrounding clinical system unsafe?”
Edge cases should reflect clinical practice in Viet Nam
A healthcare organization in Viet Nam should not assume that an international vendor's standard test suite adequately represents its own deployment environment. The local system may encounter Vietnamese text with and without diacritics, English terminology embedded in Vietnamese documentation, locally used abbreviations, trade and generic medicine names, copied-forward information, incomplete referral records, different laboratory reference ranges and clinical concepts documented differently by different departments.
Differences between healthcare facilities also matter. The same AI product can encounter different patient mixes, documentation practices, laboratory systems, imaging protocols, formularies, staffing patterns and information-system configurations across sites. A system that performs well at one hospital cannot automatically be assumed to behave identically at another simply because the software version has not changed.
Local clinical experience is therefore one of the best sources of stress-test scenarios. Near misses, incident reports, unusual cases discussed in morbidity and mortality meetings, recurrent documentation mistakes, previous interface failures, questions clinicians repeatedly struggle with and situations in which experts disagree can all be converted into useful tests. The goal is not to recreate every rare condition in medicine. It is to identify the circumstances in which this AI, in this workflow, with these patients and these dependencies could cause meaningful harm.
Testing should also consider subgroup and access effects without assuming that every statistical difference necessarily represents clinically meaningful unfairness. Performance can reasonably be examined across age, sex, site, clinical service and other relevant groups where clinically and legally appropriate, with attention to sample size, underlying prevalence and the actual clinical consequences of error.
Data and integration failures should be introduced deliberately
Many failures that appear to be model problems actually begin upstream. Stress testing should therefore deliberately introduce missing values, duplicated records, unexpected units, invalid categories, delayed inputs, out-of-range measurements, changed coding, stale information, conflicting fields and interrupted interfaces.
If a system depends on a laboratory result, testers should ask what happens when the result does not arrive, arrives twice, arrives late, is associated with the wrong encounter or is represented using a changed unit or reference range. The system's behavior matters as much as the corrupted input. Does it continue silently? Substitute a default? Use an older value? Reduce confidence? Alert the user? Stop producing an output?
For generative systems using retrieval-augmented generation, equivalent challenges include removing an important source, inserting a superseded guideline, presenting conflicting guidance, breaking an index refresh, truncating a source document and checking whether the system still produces confident citations. Where the AI depends on multiple technical systems, testing should examine what happens when only one component fails while everything else appears normal.
This is closely related to data-quality, lineage and change-control governance. Safe operation should not depend on the unrealistic assumption that every data source and integration layer will always function perfectly.
Human factors and generative AI need to be tested as part of the system
Clinical AI does not operate independently of people. Its output changes what clinicians notice, trust, question and do next. Stress testing should therefore examine human-AI interaction, not only whether the model's answer is technically correct.
An incorrect recommendation may be especially dangerous when presented with high confidence or placed in a workflow that encourages rapid acceptance. Conversely, a correct recommendation may provide little value if clinicians cannot understand its limitations or if uncertainty is displayed so poorly that users overlook it.
Useful testing can include a plausible but incorrect recommendation, a correct recommendation with low confidence, an AI output that conflicts with a clinician's initial judgment, repetitive false alerts, inconsistent outputs generated at different times and cases in which the appropriate clinical response is to disregard or override the AI. The purpose is not to see whether clinicians can be tricked. It is to understand whether the workflow supports appropriate skepticism, escalation and recovery when the system is wrong.
Human oversight should also be tested rather than merely documented. If policy states that a clinician can override the AI, the organization should confirm that the user can actually identify the need to intervene, has the necessary information and authority, can intervene in time and is not constrained by an interface or workflow that effectively makes the AI output irreversible.
Generative AI creates additional failure surfaces because users can influence the system through natural language and because outputs are not limited to predefined categories. Testing should therefore include misleading clinical framing, contradictory instructions, attempts to obtain unsafe advice, false claims of professional authority, multi-turn escalation, ambiguous context, requests to ignore system instructions and instructions embedded inside retrieved content. Healthcare red-teaming research increasingly shows that adaptive and multi-turn testing can reveal weaknesses not visible during ordinary evaluation [10–12].
For agentic AI, evaluation should often examine the whole action trajectory, not only the final response. A final answer may look reasonable even though the system accessed the wrong record, used an inappropriate intermediate tool, exceeded its intended authority or performed an unnecessary action along the way.
In some situations, the safest behavior may be to stop. If essential information is missing, evidence conflicts, image quality is outside specification or an agent is asked to act beyond its authorized scope, appropriate behavior may include abstention, uncertainty disclosure, escalation, restricted functionality, a validated fallback workflow or temporary suspension. These behaviors should be defined and tested before go-live rather than discovered during a real incident.
Clinical red teams need clinical diversity, not just technical skill
The value of a red team depends heavily on who is trying to break the system. A cybersecurity specialist may identify prompt injection or unauthorized access. A pharmacist may notice a subtly unsafe dose. A nurse may recognize an unrealistic workflow assumption. A laboratory specialist may understand why two apparently equivalent results are not clinically interchangeable. A health-information professional may detect a patient-identity problem, while a quality and patient-safety team may recognize how a small error can propagate through an existing process.
NIST emphasizes that red-team effectiveness depends on participant expertise and perspective [8]. The medical red-teaming study published in 2025 likewise involved both clinical and technical participants [10].
For a healthcare organization, a practical team may therefore include representatives from the clinical service using the system, quality and patient safety, IT or data engineering, cybersecurity where relevant, and pharmacy, laboratory, imaging or other specialties depending on the use case. Vendor or development personnel can provide important technical knowledge, but some degree of independent challenge can be useful for higher-consequence systems because the people who built the system may naturally test assumptions they already understand.
The red team needs to understand the intended use, but it should also be able to challenge whether that intended use remains realistic in actual care.
Pre-go-live testing should become progressively more realistic
Stress testing does not need to begin with live clinical exposure. A sensible progression starts in a controlled technical environment, where model behavior and integration failures can be challenged extensively without affecting care. Testing can then incorporate realistic local data, terminology and workflow conditions, followed by integration testing with the EMR, laboratory, imaging, pharmacy or other systems on which the AI depends.
Where feasible and legally appropriate, silent or shadow-mode deployment can add another layer. The AI processes real workflow data, but its outputs do not yet drive clinical decisions. This can reveal unexpected input distributions, timing problems, integration failures and local edge cases while reducing direct clinical exposure. Shadow mode does not, however, remove applicable duties relating to personal-data processing, information security or other sector-specific requirements simply because clinicians do not see or act on the AI output.
Simulation can then examine how people respond. What happens when an alert arrives during a busy shift? Can staff recognize when an output falls outside intended use? How do teams respond when the AI and clinician disagree? Can the AI be disabled without disrupting the underlying care process?
Release criteria should be agreed before testing begins. Otherwise, an organization risks redefining “acceptable” after seeing inconvenient results. Severity, likelihood, detectability, recoverability and exposure can all inform decisions. A rare failure that is immediately obvious to a clinician may require a different response from an equally rare but highly plausible error that is unlikely to be recognized before reaching the patient.
Some failures may reasonably be release-blocking depending on intended use: an unsafe high-consequence recommendation without an appropriate warning, unauthorized disclosure of patient information, action outside an agent's permitted authority, inability to stop or override the system, or a reproducible subgroup problem with meaningful clinical consequences. There is no universal numerical threshold that determines readiness for every clinical AI system. The threshold should reflect the clinical consequence of failure, not simply whether an aggregate performance target has been achieved.
Stress testing should connect to Viet Nam's AI framework without overstating what the law requires
Viet Nam's Law on Artificial Intelligence No. 134/2025/QH15 has been effective since 1 March 2026, and Decree No. 142/2026/NĐ-CP since 1 May 2026 [1,2]. The framework is risk-based rather than imposing identical obligations on every AI system.
For high-risk AI systems, Article 15 of Decree No. 142 requires the provider to establish and maintain a risk-management system appropriate to the intended use, deployment scope and risk level. Among other elements, it addresses identification and assessment of risk; the quality, suitability and representativeness of training, testing and evaluation data; human oversight and intervention; measures to control identified risks; and review of those measures when significant changes occur [2].
Deployers have distinct operational responsibilities. These include operating the system within the provider's defined conditions and limitations, monitoring for deviations, risks or incidents, maintaining appropriate human oversight, applying measures within their control when new risks arise and coordinating with the provider where significant changes or incidents require risk controls to be reviewed [2].
Stress testing and red teaming can support these responsibilities, but Vietnamese AI legislation does not prescribe the specific failure-oriented testing framework proposed in this article as a universal statutory checklist.
The boundaries of high-risk AI also need to be understood carefully. Decision No. 33/2026/QĐ-TTg, effective from 15 August 2026, establishes the current list of high-risk AI systems [3]. As of this review, its healthcare section identifies specified AI-assisted surgical and robotic-surgery systems under defined conditions. It does not classify every predictive, imaging, documentation or generative-AI application used in healthcare as high-risk simply because it operates in a hospital.
The high-risk list and the broader regulatory framework can evolve. Healthcare organizations should therefore assess classification against the law and regulatory instruments in force at the time of deployment and reconsider that assessment when the system or its deployment context materially changes.
Significant changes are another reason stress testing should not be treated as a one-time exercise. Under Article 13 of Decree No. 142, the provider of a high-risk AI system must reassess conformity where a significant change affects the basis of the original conformity assessment. Relevant changes can include the principal function or intended use, system architecture or model, major data sources or input types, data-processing methods, or integration into another system or operating environment where the change materially affects operation or risk [2]. Routine data updates, bug fixes, performance optimization or version upgrades that do not affect compliance with the applicable requirements are treated differently.
An organization's internal safety threshold can reasonably be broader than the statutory threshold for conformity reassessment. A hospital may choose to rerun relevant stress tests after a vendor model update, a new EMR interface, a laboratory analyzer change, a revised workflow, expansion to another facility or a meaningful change in patient population even when the change does not necessarily trigger formal legal reassessment.
The practical question is: Could this change invalidate an assumption under which the AI previously appeared safe?
Viet Nam's controlled-testing mechanism is different from internal red teaming
Decree No. 142 establishes a formal controlled-testing mechanism for AI systems, but this should not be confused with every internal validation, simulation or red-team exercise performed by a healthcare organization.
Participation in the formal mechanism is voluntary. Organizations participating in controlled testing must comply with the approved scope, scale, participants, duration, conditions and risk-management requirements and remain subject to supervision by the competent authority [2].
Importantly, Article 21 states that research, development or testing of AI systems conducted in a simulated environment, closed environment or as internal testing without actual test participants and without creating impacts outside the organization is outside the scope of the controlled-testing mechanism established by the Decree [2].
This does not mean that every activity described as a “pilot,” “shadow mode” or “red team” is automatically outside the mechanism. The Article 21 exclusion depends on the actual conditions of the testing activity. Where testing involves actual participants, external effects, patient care or other regulated activities, the organization should assess the applicable AI, healthcare, personal-data, research, cybersecurity and other sector-specific requirements according to the design of the test.
Internal stress testing is therefore a useful organizational safety practice, while the statutory controlled-testing mechanism is a distinct regulatory pathway with its own conditions and oversight.
Test data, personal data and medical-device requirements still apply
Stress testing creates its own privacy risks if healthcare organizations use real patient records simply because those records are convenient. Viet Nam's Law on Personal Data Protection No. 91/2025/QH15 and Decree No. 356/2025/NĐ-CP have been effective since 1 January 2026 [4,5]. Under Decree No. 356, health status is included among sensitive personal data.
Where appropriate, synthetic, simulated or otherwise privacy-protective test data can reduce unnecessary exposure of personal information. But artificial test data should not be so clean that they remove the documentation errors, missingness, contradictions and workflow irregularities the organization is trying to uncover. When real patient information is used, processing purpose, access, retention, logging, vendor access and other applicable personal-data controls need to be addressed before testing begins. A non-production environment should not become a less-protected clinical-data environment.
Circular No. 13/2025/TT-BYT has governed electronic medical-record implementation since 21 July 2025 and remains in force, making EMR systems an increasingly important upstream dependency for many clinical AI deployments [6].
AI risk classification under the AI Law is also separate from medical-device status. Under Viet Nam's medical-device framework, software can fall within the definition of a medical device when it meets the applicable statutory criteria and has an intended medical purpose such as diagnosis, prevention, monitoring or treatment [7]. The framework has continued to evolve, including the risk-determination and management measures introduced by Circular No. 24/2026/TT-BYT, effective from 1 July 2026.
Successful internal red teaming therefore does not replace any separate medical-device classification, registration, conformity, quality-management or other regulatory requirements that may apply to a particular product. Stress testing can contribute evidence to safety governance; it is not a substitute for sector-specific compliance.
Go-live is the beginning of stress testing, not the end
Clinical environments change continuously. Patient populations, documentation practices, coding systems, laboratory processes, data interfaces, staffing patterns and user behavior can evolve even when the underlying model remains technically unchanged.
A 2026 longitudinal study of four deployed clinical AI systems found that validation-era performance did not remain a stable operational property after deployment. Calibration deterioration often appeared before substantial changes in discrimination, while operational indicators such as input missingness and data latency could provide earlier signals of emerging fragility. The study involved four systems within one healthcare organization and should not be generalized mechanically to all clinical AI, but it provides useful evidence that pre-deployment validation alone is not a durable safety guarantee [14].
Post-go-live stress testing should therefore become a living regression suite. When a failure, near miss or unusual case is discovered, the organization should consider converting it into a repeatable test. When a vendor changes the model, prompt, retrieval architecture, threshold or integration, relevant scenarios can be rerun. When another hospital or clinical service adopts the system, local failure conditions can be added.
This turns incidents into organizational learning. A problem should not simply be fixed once; the organization should ask whether it can become a test that prevents the same class of failure from quietly returning.
Monitoring and stress testing have related but different roles. Monitoring asks what the system is doing in real use. Stress testing asks what it could do under deliberately difficult conditions. Monitoring can reveal changes in calibration, missingness, latency, usage, overrides, subgroup behavior or incident frequency. Stress testing can recreate and amplify an emerging problem to understand its boundaries. Conversely, red teaming can identify a plausible failure before it occurs in production and help determine which operational signals should be monitored.
A useful lifecycle is:
stress test → identify failure mode → establish control → monitor → detect change or incident → create new stress test → reassess control
This is more useful than treating pre-launch validation and post-launch monitoring as unrelated projects.
Vendors should provide more than a validation report
A vendor's global validation and benchmark results are useful, but they cannot establish how a product will behave in every Vietnamese healthcare workflow.
Vendor due diligence should therefore examine how edge cases were selected, what known failure modes remain, what adversarial testing has been performed, whether relevant subgroup performance has been evaluated, how model and integration changes are regression-tested, what happens when critical inputs are unavailable, what conditions trigger abstention or fallback, and which post-deployment signals the vendor monitors.
For generative AI, additional questions include how jailbreaks and indirect prompt injection are tested, whether retrieved documents can alter system behavior, how hallucinations and citation fidelity are evaluated, and whether a problematic interaction can be reconstructed after an incident. For agentic systems, organizations should understand limits on tool use, access permissions, confirmation requirements, retry behavior and emergency interruption.
Healthcare organizations should also know which tests they are technically and contractually permitted to perform themselves. A clinically consequential black-box system is much harder to govern if the healthcare organization cannot meaningfully challenge its behavior in the environment where it will actually be used.
A practical Clinical AI Stress-Testing Gate
Before go-live, the organization can begin with failure definition. What harms could occur if the AI is wrong, delayed, unavailable, overconfident, manipulated or used outside its intended scope? Which failures remain serious even if they are uncommon? What assumptions about patients, data, workflow, connectivity and users must remain true for the system to operate safely?
The next layer is edge-case and dependency testing. Has the system been challenged with clinical extremes, unusual combinations of conditions, missing and conflicting information, atypical values, delayed data, interface failures, different sites, Vietnamese and mixed-language input, local terminology and situations close to the limits of intended use? When a dependency fails, does the AI continue silently, signal uncertainty, restrict its function or stop?
A third layer is adversarial, human-factors and misuse testing. Can users, retrieved content or connected systems cause the AI to operate outside its intended scope? Can a generative system be pushed toward unsafe recommendations, fabricated certainty or privacy disclosure? Can an agent take an unauthorized action or propagate an early error through several steps? Can clinicians recognize an incorrect output, override it and recover safely?
The organization then needs release and recovery controls. Which findings block go-live? Who has authority to accept residual risk? Can the system be restricted or stopped quickly? Is there a workable fallback process? Are logs sufficient for investigation? Does a clinically significant AI problem enter the patient-safety pathway rather than being treated only as an IT support issue?
Finally comes lifecycle retesting. Which changes to the model, data, interfaces, prompts, knowledge sources, thresholds, workflows, vendor configuration or deployment site trigger regression testing? How will incidents and near misses become new stress-test scenarios? Which critical tests should be repeated periodically even if no obvious incident has occurred?
The Clinical AI Stress-Testing Gate is a practical organizational framework proposed for implementation and patient-safety purposes. It is not a statutory checklist prescribed by Vietnamese law.
What this means for healthcare organizations in Viet Nam
Clinical AI governance should not be built around the assumption that a system is safe because the vendor has validated it, because an average performance metric is high or because it has operated for a period without an obvious incident. The cases that matter most are often not the cases best represented by average metrics.
Viet Nam is expanding the use of electronic medical records while implementing a new AI regulatory framework, a new personal-data protection regime and an evolving medical-device framework. At the same time, healthcare organizations are beginning to encounter more predictive AI, imaging AI, generative assistants and systems capable of retrieving information or acting across digital workflows. Those developments create opportunity, but they also make the interaction between technology, data and clinical workflow more consequential.
The realistic objective is not to prove that an AI system can never fail. No stress-test program can enumerate every future clinical situation, technical failure or adversarial strategy. A stronger objective is to understand the most important ways a system can fail, challenge those assumptions before patients encounter them, design controls around what is learned and continue testing as both the system and its environment change.
The leadership question should therefore move beyond “Has this AI been validated?” A more useful question is:
“Have we deliberately tried to make it fail in the situations that could harm our patients — and do we know what happens when it does?”
That is the difference between testing whether clinical AI works and governing whether it can fail safely.
Professional education notice
This article is intended for professional education and knowledge exchange. It does not constitute individualized legal, regulatory, clinical, cybersecurity, data-protection or medical-device advice.
The terms stress testing, clinical red teaming, edge-case testing, failure-oriented testing and the Clinical AI Stress-Testing Gate are used here as practical AI-governance and patient-safety concepts. The framework proposed in this article is not a statutory testing checklist under Vietnamese law.
Article 15 of Decree No. 142/2026/NĐ-CP establishes distinct risk-management responsibilities for providers and deployers of high-risk AI systems, while Article 13 addresses conformity reassessment following significant changes. These provisions should not be generalized into a requirement that every healthcare AI system follow the exact red-teaming process proposed here. Decision No. 33/2026/QĐ-TTg establishes the current high-risk list and, as of this review, does not classify every clinical AI application as high-risk merely because it is used in healthcare.
The controlled-testing mechanism under Vietnamese AI legislation is also distinct from ordinary internal validation, simulation, stress testing and red teaming. Research, development or testing satisfying the specific exclusion conditions in Article 21 of Decree No. 142 falls outside that controlled-testing mechanism. Testing involving actual participants, external impacts, patient care or other regulated activities should instead be assessed according to its actual design and the applicable legal framework. Separate obligations may also arise under personal-data protection, medical-device, healthcare, cybersecurity and other relevant legislation.
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] National Assembly of Viet Nam. Law No. 91/2025/QH15 on Personal Data Protection. Adopted 26 June 2025; effective 1 January 2026.
[5] 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. Issued 31 December 2025; effective 1 January 2026.
[6] Ministry of Health of Viet Nam. Circular No. 13/2025/TT-BYT Providing Guidance on Implementation of Electronic Medical Records. Issued 6 June 2025; effective 21 July 2025.
[7] Government of Viet Nam. Decree No. 98/2021/NĐ-CP on Management of Medical Devices, 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. Issued 30 June 2026; effective 1 July 2026.
[8] Autio C, Schwartz R, Dunietz J, et al. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. National Institute of Standards and Technology; 2024.
[9] Jensen T, Przybocki M, Kodwani M, Greene K, Hall P, Amironesei R, Greenberg C. ARIA Evaluation Planning Manual: Elements of ARIA-Style AI Evaluations. NIST AI 200-3. National Institute of Standards and Technology; 2026.
[10] Chang CT, Farah H, Gui H, et al. Red teaming ChatGPT in medicine to yield real-world insights on model behavior. npj Digital Medicine. 2025;8:149.
[11] Hussain SA, Jackson DI, Lewis A, et al. Toward trustworthy chatbots: a protocol for red teaming for health related conversations. Scientific Reports. 2026;16:15550.
[12] Pan J, Jian B, Hager P, et al. Addressing benchmarking gaps in large language models for health and medicine with dynamic red-teaming. Nature Health. Published 15 July 2026.
[13] Ramaswamy A, Tyagi A, Hugo H, et al. ChatGPT Health performance in a structured test of triage recommendations. Nature Medicine. 2026;32(5):1671–1675.
[14] Kopanitsa G. Validation is not enough: Longitudinal evidence of post-deployment fragility in clinical AI systems. PLOS Digital Health. 2026;5(7):e0001534.
[15] Clusmann J, Freyer O, Ostermann M, et al. Safety and security of large language models in healthcare. Nature. 2026;656:577–589.