When Clinical AI Goes Wrong in Viet Nam: How Healthcare Organizations Should Detect, Report, Investigate and Learn from AI-Related Incidents
IMPLEMENTATION INSIGHTS
When Clinical AI Goes Wrong in Viet Nam: How Healthcare Organizations Should Detect, Report, Investigate and Learn from AI-Related Incidents
IMPLEMENTATION & CAPABILITY BUILDING
10/1/2026 · 22 min read
Last reviewed: 1 October 2026
When clinical AI works as intended, its contribution may be almost invisible. An algorithm prioritizes an examination appropriately. A possible lesion is highlighted. A deterioration alert reaches the clinical team at the right time. A generated summary saves a clinician several minutes without changing the meaning of the medical record.
When something goes wrong, however, the problem may be much harder to recognize. An AI system may miss an abnormality or repeatedly generate false alerts. A generative system may omit an allergy or introduce information that was never present in the record. A software update may change performance. An interface may associate the correct AI output with the wrong patient. Clinicians may begin relying too heavily on a recommendation intended only as decision support. A cybersecurity incident may make the system unavailable, or an upstream data change may quietly alter how the model behaves.
Not all of these events will harm a patient. Not all will be legally reportable, and some may not originate from the AI model itself. But all can matter. For healthcare organizations, the central question is therefore not simply “Did the AI make an error?” It is “Did something involving the AI create, contribute to or reveal a risk to safe care, and what should we do about it?”
Viet Nam's Law on Artificial Intelligence No. 134/2025/QH15, effective from 1 March 2026, makes incident management part of the AI lifecycle. Developers, providers, deployers and users have responsibilities relating to safety, security and reliability and must promptly detect and remedy incidents capable of causing harm. When a serious incident occurs, additional responsibilities arise around remediation, recording, notification and cooperation with competent authorities.[1]
For healthcare organizations, however, regulatory reporting should be only one part of the response. The broader objective is to protect patients, preserve evidence, understand what happened, correct the immediate problem and prevent recurrence.
“AI-related incident” is broader than the legal term “serious incident”
In this article, AI-related incident is used as a practical patient-safety and governance term. It refers broadly to an event, error, near miss, unexpected behavior, failure or unsafe condition in which an AI system, its data, integration, surrounding workflow or the way people interact with it may have contributed to risk. This is intentionally broader than the statutory concept of a serious incident.
The AI Law describes a serious incident as an event occurring during operation of an AI system that causes or creates a risk of serious harm to life, health, human rights, property, cybersecurity, public order or the environment, or disrupts the operation of an important information system related to national security.[1] Decree No. 142/2026/NĐ-CP further operationalizes the reporting framework by identifying serious incidents involving death or serious harm to health; significant property damage or serious disruption to an organization's operations; serious infringement of human rights or lawful rights and interests; or serious disruption of public or essential services or impacts on national security, public order or safety.[2]
The distinction matters. A false-positive alert, one incorrect generated sentence, a temporary performance anomaly or an AI-related near miss does not automatically constitute a legally reportable serious incident. Yet a useful internal safety system should still be capable of capturing those weaker signals before they develop into serious harm.
AI can contribute to an incident without being its sole cause
Clinical incidents rarely have one simple cause, and AI does not change that. Suppose an imaging AI misses an abnormality. The model may have performed poorly, but other factors may also matter: image quality may have changed, the software version may have been updated, the clinician may have relied too heavily on the absence of an alert, or the interface may have made that absence appear more reassuring than intended.
A generative AI system may produce an inaccurate discharge summary because the source information was incomplete, because the model generated unsupported content, because an integration retrieved an outdated medication list, because the clinician did not notice the error or because the workflow did not make meaningful verification realistic. An AI alert may even be technically correct but still contribute to harm if it reaches the clinical team too late to influence care.
The investigation should therefore avoid beginning with “Who made the mistake?” or even “Was the AI wrong?” A more useful patient-safety question is: What happened across the patient, data, AI, interface, workflow and human decision-making process?
Detection should not depend on obvious patient harm
Some AI problems will be immediately visible. Others may remain hidden for weeks or months. A clinician may notice an unusual recommendation. Quality teams may see repeated overrides. Monitoring may reveal an unexpected change in sensitivity. Several patients may receive similarly incorrect summaries. A provider may disclose a software defect. An imaging device may begin producing slightly different data after an upgrade, or a clinical workflow may gradually push an AI system outside its intended use.
Healthcare organizations therefore need multiple routes for detecting AI-related problems. These may include clinician and staff reporting, patient complaints, near-miss reporting, post-deployment performance monitoring, override and disagreement patterns, changes in usage, clinical audit, technical and application logs, cybersecurity monitoring, provider safety notifications and routine quality review.
This matters because real-world AI performance can change after deployment when patient populations, data-acquisition systems, equipment or clinical practices change. FDA's regulatory-science work on AI-enabled medical devices specifically examines methods for detecting changes in AI inputs and monitoring real-world performance variation.[9]
Detection therefore begins long before somebody formally labels an event an “AI incident.”
Staff need a simple way to raise concerns
If clinicians must first determine whether the model technically failed, whether an event meets a regulatory threshold and which technical team owns the problem before they can report it, many safety signals will never enter the system.
Frontline reporting should be simpler. A clinician should be able to report observations such as: “The AI recommendation did not match the clinical findings,” “the output appeared under the wrong patient,” “the system failed to identify something important,” “the AI-generated note contained information I could not verify,” or “the system is behaving differently from before.” Classification can happen afterward.
This approach fits established patient-safety practice. WHO describes incident reporting and learning systems as mechanisms for capturing safety events and converting them into structured learning to reduce future harm.[7] A clinical AI reporting process should therefore be easy enough for frontline staff to use without requiring them to become AI specialists.
The first response should protect patients, not protect the project
When a credible AI-related safety concern emerges, the first priority is not determining whether the provider, clinician or hospital is responsible. It is reducing continuing patient risk.
Depending on the circumstances, immediate actions might include increasing human review, narrowing the permitted use case, reverting temporarily to a manual workflow, reviewing recent affected cases, disabling an integration, containing a cybersecurity problem or temporarily suspending the AI system while the concern is assessed.
The response should be proportionate. A single questionable output does not automatically justify shutting down an entire AI platform. Conversely, repeated evidence of a potentially dangerous failure should not remain in routine use simply because confirmed serious harm has not yet occurred.
The key questions are practical: Is the risk still active? Could another patient be exposed? Can the problem be contained? Is there a safe alternative workflow? If continued use cannot be justified confidently, patient safety should take priority over maintaining the appearance of a successful implementation.
Containment and investigation should happen in parallel
Clinical AI incidents should not always be handled as a simple sequence in which the organization completes an investigation first and only then decides what action to take. Immediate patient protection may be necessary while the technical cause remains uncertain.
At the same time, evidence needs to be preserved. Changing model settings, overwriting logs or immediately replacing the affected software version may solve an operational problem while making it much harder to understand what actually happened.
A mature response therefore combines containment, clinical review, evidence preservation, regulatory assessment and technical investigation from the beginning. Clinical leaders may be assessing patient consequences while technical teams examine logs, quality teams determine whether similar events occurred previously, legal or compliance personnel assess regulatory obligations and the provider investigates system behavior.
No single department has enough information to manage a significant clinical AI incident alone.
Preserve evidence before it disappears
AI investigations can become extremely difficult if the organization cannot reconstruct what the system actually received and produced at the time of the event.
Where lawful and technically available, relevant evidence may include the AI system and model version, configuration and thresholds, input data, output, confidence information where applicable, timestamps, logs, software and integration versions, recent updates, user actions, overrides, downstream clinical decisions and relevant communications with the provider.
The organization may also need to know whether processing the same patient information later would reproduce the same output. That is particularly important for systems that change over time or rely on external services. A cloud-hosted model may have been updated by the provider, a generative model may not reproduce identical text and an integration may overwrite intermediate information.
Decree No. 142 specifically requires providers and deployers to maintain and preserve system logs, data and information relating to a serious incident for verification, assessment and remediation.[2] Evidence preservation should therefore be planned before an incident occurs, including through procurement requirements, technical architecture and contracts.
Serious incidents trigger specific duties under Viet Nam's AI framework
Article 12 of the AI Law applies incident-management responsibilities to developers, providers, deployers and users of AI systems. It is not limited to systems currently included on the high-risk AI list. These parties must support safety, security and reliability and promptly detect and remedy incidents capable of causing harm.[1]
When a serious incident occurs, developers and providers must urgently apply technical measures to remedy the problem, including suspension or recall of the system where appropriate, and notify the competent authority. Deployers and users must record and promptly notify the incident and cooperate in remediation.[1]
Decree No. 142 makes these responsibilities more operational. Deployers and users must promptly record the incident, take necessary measures to limit its consequences and notify the provider. The provider must take the technical measures needed to prevent, limit and remedy the consequences, while providers and deployers must cooperate in supplying information and carrying out necessary actions.[2]
For healthcare organizations, the important point is that incident management cannot simply be delegated to the technology provider. A hospital or clinic acting as the deployer has responsibilities of its own.
Viet Nam has specific reporting periods for serious AI incidents
Article 19 of Decree No. 142 establishes two preliminary-reporting periods. A preliminary report must be submitted within 72 hours from confirmation of the incident for serious incidents that cause death or serious harm to health; serious disruption of public or essential services or impacts on national security, public order or safety; and serious infringements of rights under point (c) of Article 19(1) where the incident cannot be controlled. Other serious incidents are subject to a preliminary-reporting period of five working days from confirmation.[2]
“Confirmation” does not mean completion of a full root-cause investigation. Under the Decree, the clock begins when the organization or individual has sufficient initial information to establish that the incident actually occurred and that there is a high probability that it originated from an AI-system fault. The organization should not wait until the technical investigation is complete. The Decree also expressly states that submitting the preliminary report is not treated as an admission of technical fault or legal liability.[2]
The preliminary report is submitted by the provider or deployer through the national one-stop AI portal. If the deployer cannot contact the provider, the deployer must perform the reporting obligation. Providers and deployers must also submit an official report on the outcome of remediation within 15 days from the date the preliminary report was submitted.[2]
Healthcare organizations should establish these responsibilities before a serious event occurs. A 72-hour reporting period leaves little time to decide for the first time who owns the process.
The national one-stop AI portal is already operating
The AI Law and Decree No. 142 provide for serious-incident reporting through Viet Nam's one-stop electronic portal for artificial intelligence. This is no longer merely a future administrative mechanism.
On 28 August 2026, the Ministry of Science and Technology officially launched the national one-stop AI portal as a unified online point for AI-related procedures, declarations, information and regulatory interaction.[3]
Healthcare organizations deploying AI should therefore assign responsibility in advance: who has access to the portal, who can authorize a filing, who prepares clinical information, who prepares technical information and who communicates with the provider and regulator.
A regulatory deadline is much harder to meet when nobody knows who owns the process.
One incident may trigger several reporting regimes
A clinical AI incident may fall under more than one legal framework. Decree No. 142 expressly recognizes this: where a serious AI incident is also subject to reporting under cybersecurity law, personal-data-protection law or another specialized legal regime, reporting must also be carried out under those applicable rules.[2]
An AI serious-incident report should therefore not automatically be assumed to satisfy every other notification requirement. For example, an AI system may produce unsafe clinical recommendations because patient records were maliciously altered. The same event could potentially raise AI-incident, cybersecurity and personal-data questions.
The relevant legal assessments need to occur in parallel.
Personal-data violations may have a separate 72-hour clock
The Law on Personal Data Protection No. 91/2025/QH15 has been effective since 1 January 2026. Article 23 requires a personal-data controller, controller-processor or third party that detects a violation capable of causing specified forms of harm—including harm to life, health, honor, dignity or property—to notify the specialized personal-data-protection authority no later than 72 hours after detecting the violation. A processor that discovers the violation must promptly notify the relevant controller or controller-processor.[4]
This is not the same 72-hour clock as the AI incident rule. Under Decree No. 142, the reporting period runs from confirmation of a qualifying serious AI incident. Under the Personal Data Protection Law, it runs from detection of the qualifying personal-data violation.
Healthcare organizations should therefore avoid writing a single generic “72-hour reporting rule” into policy. The trigger, responsible party and starting point depend on which legal framework applies.
Cybersecurity incidents may create another set of deadlines
If an AI-related event is also a cybersecurity incident affecting an information system, Decree No. 331/2026/NĐ-CP may impose additional reporting responsibilities on the system owner.
The Decree requires a report on the cause, scope of impact and remediation measures within 72 hours from detection of the cybersecurity incident. A serious cybersecurity incident requires an initial notification within 24 hours, while an incident showing signs of affecting national security, public order or safety, or causing serious disruption to the information system, must be reported immediately upon detection.[5]
These requirements should not be applied mechanically to every clinical AI error. They become relevant only when the facts fall within the cybersecurity framework. The practical lesson is that a significant clinical AI event may require clinical, AI-regulatory, privacy and cybersecurity assessment at the same time.
AI regulated as a medical device may bring another regulatory layer
Some clinical AI systems may also fall within Viet Nam's medical-device regulatory framework. Software can fall within the legal definition of a medical device when the applicable criteria are met, so an AI system or AI function may potentially be regulated through both the AI framework and medical-device rules depending on its intended purpose and characteristics.[6]
Where that framework applies, the registration-number holder has defined responsibilities for incidents that seriously affect users. Depending on the circumstances, these can include notifying the Ministry of Health and relevant healthcare facilities, investigating the cause, suspending circulation of an affected lot, implementing corrective measures or recall and reporting investigation and remediation results.[6]
The exact pathway depends on the product and event. A healthcare organization should therefore not assume that complying with the AI incident process replaces medical-device incident and corrective-action obligations where both regimes apply.
This is another reason regulatory classification should be understood before deployment rather than discovered during an incident.
Internal incident management should be broader than statutory reporting
A well-designed healthcare safety system should not ask only whether an event has crossed a statutory reporting threshold. It should be able to distinguish an unusual output or technical signal that merits review, a near miss in which harm was prevented, an event involving patient harm and the smaller subset of events meeting the statutory definition and reporting criteria for a serious AI incident.
These are practical internal patient-safety categories, not new risk categories under Viet Nam's AI Law.
Consider a diagnostic AI tool that fails to flag an important abnormality, but the clinician identifies it independently. The patient is not harmed. From a narrow outcome perspective, little happened; from a safety perspective, the organization has received valuable information at relatively low cost.
Was the miss consistent with known limitations? Was it associated with a particular patient group, image type or device? Have similar misses occurred? Did the clinician detect it because the workflow supports independent review, or was the outcome simply fortunate?
WHO emphasizes that patient-safety incident reporting and learning systems should capture safety events and turn them into structured learning that reduces future risk.[7]
An organization that celebrates “no AI incidents” while discouraging near-miss reporting may simply be measuring silence.
Investigation should examine the whole human–AI system
Once immediate risk is controlled, investigation should move beyond asking whether the model output was technically correct. A useful review should consider at least the AI model, data, integration, workflow, human interaction and governance environment.
The model review may ask whether the output was consistent with expected performance, whether the AI was being used within its intended purpose and whether a recent update changed behavior. Data review may consider input quality, missing information, changes in patient mix or changes to imaging, laboratory or documentation processes. Integration review may examine patient mapping, timing, interface problems and failures in data exchange.
Workflow review should examine how the result was presented and what happened next. Did the clinician have enough information and enough time? Could the recommendation be challenged or overridden? Did staff understand important limitations? Did the AI change attention or confidence in a way that had not been anticipated?
Governance review should look further upstream. Did the organization select an appropriate use case? Was the technology adequately evaluated before implementation? Was its performance monitored after go-live? Were software and model changes controlled? Had previous warning signals already appeared?
A technically accurate algorithm can still sit inside an unsafe system.
Do not assume the last person who clicked the button caused the incident
Healthcare investigations can become distorted when the most visible final action was performed by a clinician. If a clinician accepted an incorrect AI recommendation, that decision should be examined, but the investigation should also ask why acceptance was likely.
Was the AI correct almost all the time? Did the interface visually emphasize its recommendation? Was disagreement cumbersome? Was workload excessive? Did training address the relevant limitation? Had similar outputs been reported before? Was the AI being used outside the population or context in which it had been evaluated?
Human performance should be investigated, but it should be investigated in context. This is not the same as avoiding accountability. Deliberate misuse, reckless behavior or serious professional failure may require appropriate action. But defaulting immediately to individual blame can suppress future reporting while leaving an unsafe system unchanged.
A learning-oriented investigation seeks to understand the system while still preserving accountability where accountability is genuinely warranted.
Provider investigation should complement, not replace, the healthcare organization's investigation
Clinical AI incidents frequently cross organizational boundaries. The provider may be best placed to examine model behavior, software defects and patterns across multiple customers. The healthcare organization may be the only party able to understand the local clinical workflow, patient consequences and how clinicians actually interacted with the system.
Both perspectives are needed.
Contracts should therefore define incident responsibilities before deployment. They should address response times, access to relevant logs and technical information, disclosure of model or software changes, escalation of safety concerns, cooperation with regulatory reporting and verification of corrective action.
A provider's statement that “we could not reproduce the error” should not automatically close a clinical investigation where the healthcare organization still has credible evidence of a safety problem. Conversely, the healthcare organization should not conclude that “the AI failed” without considering whether the product was used within its intended scope and whether local data or integration contributed.
Corrective action should address the mechanism, not just the event
An investigation has limited value if its only output is a report. The purpose is to change something in the system of care.
Corrective action might include repairing an interface, restricting AI use to the intended population, changing an alert threshold, improving data quality, adding a verification step, strengthening human oversight, retraining staff, modifying provider requirements or temporarily removing the AI from a workflow.
The learning may also extend beyond the immediate event. If the hospital discovers that it cannot reliably identify which AI version is operating, it may need a stronger AI inventory and change-control system across the organization. If clinicians did not know how to report concerns, the corrective action may need to include organization-wide reporting education rather than training one department.
Every meaningful action should have an owner, a timeframe and a way to determine whether it worked.
“Staff reminded to be careful” is rarely an adequate corrective action for a complex system failure.
Restarting AI after an incident requires evidence
The end of technical remediation does not automatically mean that an AI system is ready to return to routine clinical use. Before unrestricted restart, the organization should know what changed, whether the suspected failure mechanism has been addressed and what evidence supports safe reintroduction.
That evidence will depend on the event. It may involve reproducing the original failure, testing affected patient groups or data types, validating an integration repair, confirming software versions, running simulated workflows, temporarily increasing human review or intensifying monitoring after restart.
If remediation results in a significant change to the AI system or its use, the organization should also consider whether risk reclassification, renewed conformity assessment or another regulatory action is required under Viet Nam's AI framework.
The restart decision should have a named authority and a documented rationale, particularly where the initial event involved significant patient-safety risk.
A provider telling the organization that a patch has been installed is important information. It is not automatically evidence that the entire clinical system is safe again.
Patients and affected people may also need communication
Reporting an incident to a government authority and communicating with patients are different issues.
An AI-related incident may lead to retrospective review of medical records, additional testing or changes in treatment. It may involve inaccurate documentation or exposure of personal information. Depending on the facts, healthcare, personal-data, civil or other legal requirements and organizational policies may create obligations to communicate with affected patients or other individuals.
There is no single AI-specific rule requiring identical patient notification for every AI-related error. Healthcare organizations should therefore determine communication requirements from the actual circumstances rather than assuming either that every AI error requires the same disclosure or that filing a regulatory report completes all communication responsibilities.
Where patient communication is required, it should focus on what is known, what remains uncertain, what has been done to protect the patient and what follow-up is necessary, rather than overwhelming the patient with technical terminology or prematurely assigning blame.
Leadership should know when an AI incident becomes an organizational risk
Not every AI concern needs to reach the hospital director, chief executive or board. Many events can be managed through ordinary departmental quality and safety processes. Serious or recurrent problems, however, should have defined escalation criteria.
Senior leadership may need to become involved when patient harm is significant, multiple patients may be affected, continued operation is uncertain, statutory reporting may be required, a disagreement with the provider remains unresolved, public trust may be affected or the event exposes a wider weakness in AI governance.
Leaders do not need to personally determine whether model drift occurred. They do need to understand whether patients remain exposed, whether a safe fallback exists, whether regulatory obligations are being met and whether corrective action is progressing.
Clinical AI incident management therefore belongs within the organization's wider clinical governance, patient safety and enterprise risk structure, not only within IT or vendor management.
Incident response should be rehearsed before a real event
A healthcare organization should not wait for its first serious AI incident to discover that nobody knows who should contact the provider, retrieve the logs, review affected patients or submit a regulatory report.
A tabletop exercise can reveal these weaknesses before patients are at risk. A scenario might begin with clinicians reporting several unusual outputs from a diagnostic-support AI system. The team then discovers that a recent software update occurred. One patient may have experienced delayed treatment, but it remains unclear whether the AI output, integration or human review contributed.
The exercise can test whether staff can identify the system owner, restrict use, preserve evidence, review potentially affected cases, involve the provider, determine whether statutory reporting thresholds have been met, assess privacy and cybersecurity implications and decide who has authority to restart the technology.
The goal is not to predict every possible failure. It is to make sure the organization can act coherently while the cause is still uncertain.
Learning should travel beyond the department where the incident occurred
An incident involving one AI product may reveal a weakness relevant to every AI system in the organization.
A missing record of the model version may expose a broader AI inventory problem. Inability to obtain logs may reveal a procurement weakness. Automation bias in one department may show that AI training focuses too much on software operation and too little on limitations. Failure to recognize an upstream data change may expose weak post-deployment monitoring.
Organizations should therefore ask after each meaningful incident:
What does this event teach us about this AI system, and what does it teach us about how we govern AI generally?
The second question may ultimately be more important than the first.
The NIST AI Risk Management Framework follows a similar lifecycle approach. Its MANAGE function incorporates monitoring, user feedback, incident response, recovery, communication and continual improvement rather than treating incidents as isolated events.[8]
What a practical clinical AI incident process could look like
Most healthcare organizations do not need to begin by creating a sophisticated AI safety center. They do need clear ownership and reliable escalation.
A practical process can begin when a clinician, patient, monitoring system, provider or technical team raises a concern. The organization records the event, assesses immediate patient risk and decides whether AI use should continue, be restricted or be suspended. Potentially affected patients or cases are identified where appropriate, while relevant logs and other evidence are preserved.
A multidisciplinary review then considers clinical impact, AI behavior, data, integration, workflow, human factors and recent changes. At the same time, legal and regulatory personnel assess whether the event meets the serious-AI-incident threshold or triggers personal-data, cybersecurity, medical-device or other reporting obligations.
Corrective actions are assigned, their effectiveness is evaluated and criteria for safe restart are documented. Finally, the organization determines whether the event exposes a wider governance weakness that needs to be corrected elsewhere.
The process therefore connects detection → containment → reporting → investigation → corrective action → verification → learning.
That is more useful than treating incident management as the completion of a form.
The main message
Clinical AI will not always behave perfectly, and neither will the people, workflows, data systems and organizations around it. Responsible AI governance therefore cannot be built on the assumption that good procurement and validation will prevent every incident. The real test is what happens when something goes wrong.
Viet Nam's 2026 AI framework now establishes concrete responsibilities for serious-AI-incident management and reporting. Decree No. 142 requires preliminary reporting within 72 hours for specified serious incidents and five working days for the remaining serious incidents, preservation of relevant evidence and an official report on remediation within 15 days of the preliminary report. It also recognizes that cybersecurity, personal-data and sector-specific reporting obligations may operate in parallel.[1,2]
But legal compliance is only the minimum objective. A safe healthcare organization should detect weak signals before they become serious incidents, make it easy for clinicians to raise concerns, protect patients before blame is assigned, investigate the entire human–AI system, verify that corrective action works and share learning beyond the department where the incident occurred.
The most useful question after an AI-related incident is therefore not simply “Who was responsible?” It is “What allowed this to happen, what could happen next, and what will we change so that the system of care is safer?”
That is the point at which incident reporting becomes organizational learning.
Professional education notice
This article is intended for professional education and knowledge exchange. It does not constitute individualized legal, regulatory, clinical, medical-device, cybersecurity or data-protection advice; determine whether a specific event is legally reportable; determine responsibility or liability in a particular case; or replace assessment of the actual AI system, event, patient consequences, contractual arrangements and applicable law.
The term AI-related incident is used here as a practical governance and patient-safety concept and is intentionally broader than the statutory term serious incident under Viet Nam's Law on Artificial Intelligence. An AI error, near miss, unexpected output, performance signal or patient-safety event does not automatically meet the statutory threshold for serious-incident reporting.
The reporting timelines discussed in this article arise under different legal frameworks and should not be treated as interchangeable. AI serious-incident reporting under Decree No. 142/2026/NĐ-CP, personal-data notification under Law No. 91/2025/QH15 and cybersecurity incident reporting under Decree No. 331/2026/NĐ-CP have different triggers, responsible parties and starting points.
Where an AI system is also regulated as a medical device or is subject to another specialized regulatory regime, additional incident, notification, investigation, corrective-action or recall requirements may apply.
International frameworks and guidance referenced in this article provide useful approaches to patient-safety learning and lifecycle AI risk management but do not replace Vietnamese legal requirements.
References
National Assembly of Viet Nam. Law No. 134/2025/QH15 on Artificial Intelligence. Adopted 10 December 2025; effective 1 March 2026.
Government of Viet Nam. Decree No. 142/2026/NĐ-CP Detailing a Number of Articles and Measures for Implementation of the Law on Artificial Intelligence. 30 April 2026; effective 1 May 2026.
Ministry of Science and Technology of Viet Nam. One-Stop Electronic Portal for Artificial Intelligence. Officially launched 28 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. 331/2026/NĐ-CP on Cybersecurity Protection for Information Systems. 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.
World Health Organization. Patient Safety Incident Reporting and Learning Systems: Technical Report and Guidance. Geneva: WHO; 2020.
National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1; 2023.
U.S. Food and Drug Administration. Methods and Tools for Effective Postmarket Monitoring of Artificial Intelligence-Enabled Medical Devices. Center for Devices and Radiological Health.