Grounding Clinical Generative AI in Viet Nam: Governing RAG, Knowledge Sources, Citation Fidelity and Evidence Freshness
IMPLEMENTATION INSIGHTS
Grounding Clinical Generative AI in Viet Nam: Governing RAG, Knowledge Sources, Citation Fidelity and Evidence Freshness
IMPLEMENTATION INSIGHT
Last reviewed: 3 October 2026
A clinical generative AI system can produce an answer that sounds precise, cites respectable-looking sources and is still unsafe. The problem may not be that the language model invented everything. It may have retrieved the wrong guideline, relied on a superseded version, missed a critical contraindication elsewhere in the document, blended recommendations from different populations, or attached a citation that is relevant to the topic but does not actually support the claim being made.
Retrieval-augmented generation, or RAG, is increasingly used to reduce some of these problems. Instead of asking a language model to rely only on knowledge encoded during training, a RAG system retrieves information from external sources and provides that information to the model as context for generating an answer. In healthcare, those sources might include clinical guidelines, regulatory documents, drug information, hospital protocols, formularies, medical literature or, in some systems, patient-specific records. Research on healthcare RAG shows why this approach is attractive: retrieving domain-relevant information can improve factual grounding, relevance and transparency. But performance still depends heavily on the corpus, retrieval strategy, source selection and overall system architecture [9].
That means “uses RAG” is not a patient-safety claim. A healthcare organization still needs to know whether the system retrieved the right evidence, whether that evidence was authoritative for the question being asked, whether the generated claims were actually supported by the cited material, and whether the evidence was sufficiently current and applicable to the patient and setting. For clinical generative AI, these questions should form part of the organization's safety assessment rather than being treated as technical details at the edge of implementation.
RAG changes where the risk sits; it does not remove it
A simplified RAG workflow looks straightforward: a user asks a question, the system searches an approved knowledge base or other sources, relevant passages are retrieved, those passages are placed into the model's context, and the model generates an answer. In practice, each step can fail differently.
The original question can be interpreted incorrectly. Retrieval can miss the most relevant document. Chunking can separate a recommendation from its exception. Semantic search can retrieve a passage that sounds similar but applies to another population. A reranker can prioritize the wrong source. An old guideline can remain indexed after a replacement has been issued. The model can combine two retrieved passages into a conclusion that neither source actually states, or it can quietly use its own parametric knowledge to fill gaps in the retrieved evidence.
RAG should therefore be governed as a system, not treated as a feature added to a language model. Healthcare RAG literature emphasizes corpus selection, retrieval design and knowledge integration as important determinants of performance, while newer multi-source approaches are exploring dynamic source selection, evidence validation and explicit attribution rather than relying on one undifferentiated knowledge store [9,11].
Changing the model is also not the only way to change system behavior. A stable model can produce materially different answers after a knowledge-base update, a change in chunking strategy, a new embedding model, a modified reranker, a change in source-precedence logic or the addition of live web search. The grounding layer therefore needs its own governance and change control.
Governing the answer begins with governing what is allowed to become evidence
Not every medically relevant document should automatically become an eligible source for clinical AI. A hospital may possess thousands of policies, educational materials, scanned documents, archived clinical pathways, vendor manuals, conference slides, locally developed forms and previous versions of guidelines. Indexing everything may increase retrieval coverage while reducing clinical reliability.
A source should enter a clinical knowledge base because there is a defensible reason for trusting it for a defined purpose. That reason will differ by question. For a question about Vietnamese legal obligations, the relevant authority may be a current law, decree, circular, decision or other document issued by the competent authority. For a medication question, approved product information, regulatory safety communications, local formulary requirements and appropriate clinical evidence may all matter. For a bedside workflow, an approved hospital protocol may be operationally decisive even when international evidence provides the broader scientific basis.
There should therefore be no simplistic hierarchy in which an “international guideline,” “peer-reviewed paper” or “government source” always wins. Authority is contextual. An international guideline does not by itself determine what is legally permitted in Viet Nam. An internal hospital protocol does not override applicable law. A recent observational study does not automatically supersede a current evidence-based guideline. A medical website does not become authoritative merely because it is newer.
Before a document becomes retrievable evidence, the organization should know what it is, who issued or approved it, its scope, intended users, relevant population, version, publication or approval date, effective date where applicable, review status and whether it has been replaced or withdrawn. Ideally, those attributes should influence retrieval itself rather than being stored only as administrative metadata. For clinically consequential systems, retrieval should consider more than semantic similarity: eligibility, authority, applicability, version status and current validity can be as important as textual relevance.
Viet Nam creates a particularly important multilingual grounding problem
Clinical generative AI in Viet Nam will often operate across at least two knowledge environments. Vietnamese laws, Ministry of Health instruments, hospital policies and many operational documents are written primarily in Vietnamese, while a large proportion of the international scientific and clinical literature is published in English. Within hospitals, clinicians also routinely use mixed Vietnamese-English terminology, specialty abbreviations, local shorthand and product names.
This creates risks that are easy to underestimate. The same clinical concept may be expressed differently in Vietnamese and English. Abbreviations may be specific to one hospital or department. Medicines may be documented by generic name, international non-proprietary name, trade name or local product name. A translated term can be understandable while still failing to match the terminology used in an authoritative Vietnamese source. Numerical thresholds, populations, exceptions and regulatory language can also change meaning subtly when summarized across languages.
For high-consequence use, translation should not erase provenance. If an English-language answer is grounded in a Vietnamese regulatory or clinical document, the organization should be able to retain or reconstruct the original source, the relevant original-language passage and, where material, the translation or terminology mapping used by the system. The generated English explanation should not silently become the new authority.
This is particularly important for dosage, contraindications, regulatory requirements, eligibility criteria and numerical treatment thresholds. A fluent translation can help a clinician understand a source; fluency alone does not establish that the translation preserves the legal or clinical meaning of the source.
A citation is not evidence that the answer is grounded
Generative AI interfaces increasingly display citations, and citations can create a strong impression of reliability. But a visible reference answers only one part of a much larger question.
A citation may point to a real document but fail to support the specific claim. It may support only one clause in a longer sentence. The source may contain the stated fact but apply to a different patient population. A general recommendation may be correctly cited while the model adds a dose, timing rule or exception that does not appear in the source. A citation can also be perfectly accurate and still refer to evidence that has been superseded.
Research on citation-enabled language models has explicitly separated answer correctness from citation quality. The ALCE benchmark, for example, evaluates whether generated statements are supported by their cited evidence rather than treating the mere presence of references as proof of verifiability [10]. NIST's Generative AI Profile similarly emphasizes the importance of provenance, source verification, data quality and evaluation of retrieval-augmented approaches as part of generative-AI risk management [14].
For clinical governance, citation fidelity should therefore mean more than “the system produced a citation.” A material claim should be supported by the cited evidence at the level of specificity at which the claim is presented. The source should be identifiable, available to an appropriately authorized reviewer, applicable to the question and represented without materially changing its meaning.
The standard may reasonably be higher for safety-critical claims. If the system gives a medication dose, states a contraindication, identifies a treatment threshold, recommends escalation, determines eligibility or describes a legal obligation, the organization may require stronger evidence binding than it would for general educational background.
One practical approach is to retain the evidence span associated with clinically important generated claims. An audit trail can then show not only which document was retrieved, but also which version and passage were supplied to the model, when they were retrieved and how they relate to the generated statement. This does not guarantee that the answer is correct, but it makes verification and incident investigation far more meaningful.
Evidence freshness is more complicated than finding the newest document
Clinical AI needs current evidence, but “freshness” should not be reduced to publication date. A guideline published three years ago may still be the current authoritative guideline. A document published yesterday may not yet be effective. A regulatory instrument may have an issue date, an effective date and later amendments. A hospital protocol may remain operational until formally replaced even if newer external evidence is available. Conversely, an urgent drug-safety communication may need to affect retrieval immediately rather than waiting for a scheduled knowledge-base refresh.
A useful grounding system therefore needs to understand document status over time. Important metadata can include the date issued or published, effective date, revision date, version, issuing organization, date ingested, date last verified, supersession status and, where appropriate, the expected next review.
There should be no universal rule that every piece of medical evidence becomes “stale” after 30, 90 or 365 days. Appropriate freshness depends on the knowledge domain, the rate at which practice changes and the clinical consequence of outdated information. A rapidly evolving therapeutic area may require much more frequent surveillance than a stable anatomical reference. Regulatory alerts and medication-safety changes may justify event-driven updating, while a hospital workflow may change whenever a newly approved protocol goes live.
A more useful operational principle is therefore not “always retrieve the newest source.” It is “know which source is currently authoritative, applicable and effective for this question.”
A grounded system must know when its sources disagree
Medical knowledge is not always internally consistent. Different professional societies can issue different recommendations. A national guideline may differ from an international one. A hospital protocol may deliberately choose one of several defensible approaches. New research may challenge an older standard before formal guidance changes. Two documents may address apparently similar questions while applying to different populations.
A RAG system that retrieves conflicting evidence can select one source according to predefined governance rules, expose the disagreement, seek additional evidence or escalate the question for human review. What it should not do silently is merge different recommendations into a single confident statement that creates a consensus that does not exist.
Source governance therefore needs rules for conflict handling. The system should be able to recognize version relationships, distinguish local operational authority from external guidance, preserve important differences in population or scope, and surface clinically meaningful disagreement when it cannot be resolved safely. Two passages can both be highly relevant to a query and still represent different standards of care. Retrieval can find them; governance has to determine what the system is permitted to do with them.
Grounding should include the ability not to answer
One of the most useful safety behaviors in clinical generative AI is also one of the least impressive in a product demonstration: abstention.
If the system cannot retrieve sufficiently reliable evidence, cannot resolve conflicting sources, cannot establish whether a source is current or cannot find adequate support for a clinically consequential statement, it should have a defined path for handling that uncertainty. Depending on the intended use, it may request additional information, provide a qualified response, direct the user to the source document or escalate the question to an appropriately authorized clinician or expert.
A RAG system that always produces a complete answer can therefore be less governable than one that sometimes says that the available evidence is insufficient. “No sufficiently reliable source found” is useful information. Replacing it with a plausible answer generated from the model's internal knowledge can conceal the exact limitation that grounding was meant to address.
Organizations should decide explicitly whether the model is permitted to use parametric knowledge when retrieval fails or is incomplete. If it is, the interface or workflow should make clear where clinically material content is not supported by the approved retrieval corpus.
Retrieval and generation need to be evaluated separately
A single overall accuracy score cannot tell an organization why a RAG system succeeds or fails. If the answer is wrong, the problem may have occurred before generation ever began. Clinical evaluation should therefore examine at least two linked layers: did the retrieval system find the evidence that a competent reviewer would reasonably need, and, given the evidence retrieved, did the language model represent it faithfully and produce an appropriate answer?
These layers have different failure modes. Retrieval testing can examine whether relevant sources are found, whether important evidence is omitted, whether a current version outranks an obsolete one, whether inappropriate documents are excluded and whether retrieval behaves consistently across Vietnamese and English queries. Generation testing can examine factual correctness, faithfulness to retrieved evidence, citation support, handling of uncertainty, disclosure of important conflicts and appropriate abstention.
Local evaluation in Viet Nam should also reflect the language clinicians actually use. A benchmark composed only of polished English medical questions may say little about a system's performance with Vietnamese abbreviations, mixed Vietnamese-English terminology, local medicine names, specialty shorthand, spelling variation or hospital-specific expressions.
The evaluation corpus should deliberately include difficult cases: superseded documents that should no longer be used, multiple versions of the same protocol, questions for which no approved evidence exists, conflicting local and international recommendations, incomplete patient context, ambiguous abbreviations and equivalent questions phrased differently in Vietnamese and English. A system that performs well only when the correct evidence is obvious has not yet demonstrated robust clinical grounding.
This direction is consistent with newer medical RAG research moving beyond simple retrieval toward multi-source selection, evidence validation, agent collaboration and explicit source attribution [9,11]. Benchmark gains are useful evidence of technical capability; they should not be treated as proof of safety in a Vietnamese clinical workflow.
When RAG retrieves patient information, grounding becomes personal-data governance
There is a fundamental difference between retrieving a public clinical guideline and retrieving information from a patient's medical record. Both may use RAG architecture, but their governance implications are very different.
Viet Nam's Law on Personal Data Protection No. 91/2025/QH15 has been effective since 1 January 2026, together with Decree No. 356/2025/NĐ-CP [4,5]. Under Decree No. 356, health status is included in the list of sensitive personal data. The Decree also contains specific provisions for personal-data protection in AI systems. Data produced through AI inference remain subject to personal-data safeguards where they can be used to identify or help identify a particular individual. Where personal data are processed automatically, personal data controllers and controller-processors also have duties that include notifying the data subject, explaining the operating principles of the algorithm and its effects on lawful rights and interests, and providing options enabling the data subject not to participate, in accordance with the applicable legal framework [5].
Decree No. 356 also requires organizations and individuals to apply safeguards to personal data used in AI systems, including cybersecurity and data-protection measures, system monitoring and accountability mechanisms, early warning of cybersecurity risks and annual assessment of compliance with personal-data protection requirements [5]. Separately, the relevant controllers, controller-processors and processors must prepare and retain personal-data processing impact-assessment dossiers from the commencement of processing and comply with the applicable submission and updating requirements [5].
For clinical RAG, the practical implication is that the knowledge architecture should distinguish public or institutional knowledge from patient-specific information. If a system retrieves diagnoses, laboratory results, medication histories, imaging reports, clinical notes or other identifiable patient information, access control, processing purpose, user authorization, logging, retention, vendor roles and data flows become part of the grounding design.
Cloud architecture deserves particular attention. Under the current personal-data framework, sending personal data collected or stored in Viet Nam to infrastructure outside Viet Nam, to a foreign recipient, or to an overseas platform for further processing may constitute a cross-border transfer of personal data. Where the statutory requirements apply and no exemption is available, the responsible party must comply with the applicable cross-border impact-assessment, documentation, filing and update requirements [5].
Healthcare organizations should therefore understand where a cloud-based generative-AI system actually sends and processes information, not merely where its user interface is accessed. Depending on the architecture, this may include model endpoints, logging environments, vector databases, backup infrastructure, subprocessors and overseas platforms used for further processing.
Converting clinical text into embeddings should also not be assumed, by itself, to make the underlying information anonymous. Whether the information remains personal data depends on the actual ability to identify or help identify a person in the relevant context, not simply on the fact that the information has been transformed into a vector representation.
Circular No. 13/2025/TT-BYT, effective since 21 July 2025 and currently in force, adds another relevant layer when clinical RAG connects to the electronic medical record. The Circular places EMR implementation within the applicable framework covering healthcare information, data, information technology, electronic transactions, information security, cybersecurity and personal-data protection [6].
RAG also creates a new security boundary
Retrieved material is not automatically trustworthy simply because it came from a knowledge store. Documents can be corrupted, misclassified, added without proper approval or deliberately manipulated. Systems that retrieve uploaded documents, websites or external content also face the possibility that apparently ordinary material contains instructions designed to influence the model.
OWASP's 2025 guidance identifies prompt injection as a major risk for LLM applications and separately identifies vector and embedding weaknesses relevant to RAG systems, including unauthorized access, manipulation and information disclosure [15]. RAG can reduce some knowledge limitations of a language model, but it does not eliminate prompt-injection or knowledge-base security risk.
For a hospital, corpus ingestion should therefore have its own trust boundary. An uploaded PDF should not become clinically authoritative simply because the system can parse and index it. Document approval and source permissions should be enforced at retrieval time, not only when content is originally stored. Retrieved content should be treated as evidence to be interpreted rather than as trusted instructions to the model, and a high-consequence action should not be authorized solely because retrieved text tells the model to perform it.
These controls become even more important as generative AI moves from answering questions toward agents that can interact with clinical systems. Research published in 2026 has demonstrated increasingly capable EHR-integrated and locally governed medical agents, including systems able to navigate simulated clinical workflows or operate within on-premise environments. These studies are important demonstrations of capability, but they also emphasize continuing needs for governance, reliability assessment and prospective real-world validation [12,13].
Viet Nam's AI framework is relevant, but RAG is not a separate legal category
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 classifies AI systems according to risk and assigns obligations accordingly. It does not establish a separate statutory category called a “RAG system.”
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 covers specified AI-assisted surgical and robotic-surgery systems under defined conditions. A clinical generative-AI knowledge assistant or RAG application is therefore not automatically on the current healthcare high-risk list simply because it is used in a hospital or provides clinical information. Its legal classification needs to be assessed according to the actual system, functions and intended use.
Being outside the current high-risk list does not, however, mean that a clinical generative-AI system falls outside Viet Nam's AI framework. Article 11 of the AI Law requires providers to ensure that AI systems interacting directly with people are designed and operated so users can recognize that they are interacting with AI, except where the law provides otherwise [1]. Decree No. 142 also provides for medium-risk classification where a system is not high-risk but can cause confusion, influence or manipulation because users do not recognize that the interacting entity is AI or that the content has been generated by AI, subject to specified exclusions [2]. A clinical assistant should therefore be assessed for its actual classification and applicable transparency duties rather than being treated as automatically high-risk or automatically low-risk.
For high-risk systems, RAG architecture can also become relevant to conformity reassessment. Article 13 of Decree No. 142 requires providers to reassess conformity when a significant change affects the original assessment, including changes to data sources, principal input data types or data-processing methods that materially affect system operation or risk. Routine data updates, ordinary bug fixes, performance optimization or version upgrades are not treated as significant changes when they do not alter compliance with the applicable requirements [2].
This distinction is useful for RAG governance. Replacing an approved guideline with its formally updated version may be an ordinary controlled content update. Adding unrestricted internet retrieval, replacing a curated corpus with mixed public sources, changing the retrieval architecture, altering source-precedence rules or introducing access to patient records could have much greater safety significance. Whether a particular change legally triggers conformity reassessment depends on the system's classification and the materiality criteria in the law; an organization's internal clinical AI review threshold can reasonably be broader.
AI risk classification 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 statutory criteria and is intended for purposes such as diagnosis, prevention, monitoring or treatment [7]. A generative-AI or RAG application should therefore not be assumed to fall outside medical-device regulation merely because it is absent from the current high-risk AI list. The assessment depends on the software's intended purpose and functionality.
The knowledge base should be managed like a clinical dependency, not a document folder
Once an AI system depends on an external corpus, that corpus becomes part of its operational behavior. Someone therefore needs to own it. Ownership should include decisions about which sources are eligible, who approves additions, how versions are maintained, how replaced documents are retired, how conflicts are handled, how urgent safety information enters the corpus and how failures in ingestion or indexing are detected. A technically successful refresh is not enough if the wrong version was indexed.
This also changes incident investigation. If the AI gives a clinically important wrong answer, the organization should ideally be able to reconstruct which model version was running, what question was asked, what retrieval query was generated, which sources and passages were retrieved, which versions they were, what context was supplied to the model, what citations were returned and whether the knowledge base or retrieval configuration had recently changed.
Without that traceability, a hospital may know that the AI produced a wrong answer without knowing whether the failure began in the model, retriever, corpus, source document, source version or integration between them.
Vendors should disclose the knowledge contract, not simply say that the system uses “trusted medical sources”
Statements such as “powered by the latest medical evidence,” “grounded in trusted sources” or “uses RAG to prevent hallucinations” are not sufficient for clinical due diligence.
Healthcare organizations need to understand what those claims mean operationally. Which sources can enter the system? Who selects and approves them? Are public websites used? Is live web search enabled? Can the customer restrict the source set? Are previous document versions preserved? How quickly are withdrawn or superseded sources removed? What happens when sources conflict? Can the model answer from internal knowledge when retrieval fails? Are citations tied directly to retrieved evidence? Can an authorized reviewer inspect the passage supporting a clinically material statement?
There is also an important difference between a vendor maintaining a general medical corpus and a healthcare organization supplying its own policies, protocols or patient information. Responsibilities for source approval, updating, security, intellectual property, personal data and incident response may be divided differently in each architecture.
For clinically important systems, it is useful to treat these expectations as a knowledge contract: a defined agreement about what external information the AI is allowed to use, how that information is governed and what the system must do when adequate evidence is unavailable.
Evidence grounding needs operational monitoring after go-live
A RAG system that performed well during validation can still deteriorate after deployment. An index can fail to refresh. A new guideline can be parsed incorrectly. A source website can change structure. Retrieval behavior can shift after a software update. A withdrawn document can remain in the vector store. An access-control change can make an important corpus unavailable. Citation generation can continue to look normal even while source support has become weaker.
Operational monitoring should therefore cover the grounding layer separately from general model performance. Depending on the use case, organizations may need to monitor source-refresh success, ingestion failures, retrieval of superseded documents, unsupported or uncited material claims, source-age exceptions, retrieval failures, fallback to model memory, changes in source distribution, unresolved source conflicts and abrupt changes in citation behavior.
Monitoring is useful only if signals lead to decisions. A delayed routine corpus refresh may justify investigation; failure to ingest an urgent medication-safety update may justify restricting a clinical use case. If the AI cannot access the approved source required for a particular task, continuing to generate confident answers may not be an acceptable degraded mode.
A practical Clinical Generative AI Grounding Gate
Before deployment, an organization can begin with purpose and source governance. What clinical task is the generated answer intended to support, and what could happen if the answer is wrong or stale? Which source categories are permitted or prohibited? Who determines that a source is authoritative for a given question? Can the organization identify the issuer, title, version, scope, approval status, applicable population and current status of each important source? Can the system distinguish Vietnamese legal and clinical requirements from international recommendations, and can Vietnamese-English terminology be mapped without losing the original source or meaning?
The next group of questions concerns retrieval and evidence fidelity. Has the system been tested to determine whether it retrieves the evidence a competent reviewer would expect? Does each clinically material claim actually follow from the evidence cited? Can a citation omit an important exception elsewhere in the same document? What happens when credible sources disagree? Does the system abstain or escalate when evidence is missing, uncertain or conflicting? If the model is allowed to use parametric knowledge when retrieval fails, is that distinction visible to the user?
A third group concerns patient data and security. Can retrieval reach identifiable clinical information, and if so, are purpose, authorization, access, logging, retention, vendor roles and personal-data obligations controlled appropriately? Does any part of the data flow cross national borders or use overseas cloud infrastructure? Can external documents, users or unauthorized content influence retrieval or model behavior? Are access permissions enforced when information is retrieved rather than only when it was originally stored?
Finally, the organization needs local validation, change control and monitoring. Has the complete system been tested with Vietnamese language, local terminology, current protocols and realistic clinical workflows? Which changes to source collections, embeddings, rerankers, prompts, retrieval methods, web access, models or integrations require review or revalidation? How will the organization detect deterioration in retrieval quality, citation fidelity or evidence freshness? If an unexpected clinical output occurs, can it be reconstructed back to the model version, retrieval event, evidence passage and source version that contributed to it?
The Clinical Generative AI Grounding 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
Generative AI creates a different clinical information problem from conventional decision-support systems. Traditional clinical decision support often exposes the rule, threshold or source content driving an alert. A general-purpose language model can produce a sophisticated answer from knowledge that is largely invisible to the healthcare organization. RAG can make part of that knowledge environment more controllable and auditable, but only if retrieval itself is governed.
International guidance points in the same general direction. WHO's guidance on large multimodal models emphasizes governance across health uses of generative AI, while NIST's Generative AI Profile highlights provenance, source verification, data quality and retrieval-augmented approaches among the issues organizations should consider when managing generative-AI risks [8,14].
For Viet Nam, the timing is particularly relevant. Healthcare organizations are expanding electronic medical records while operating under a new AI law, a new personal-data protection framework and increasingly capable generative-AI platforms. At the same time, current Vietnamese legislation does not prescribe a universal RAG architecture, a mandatory citation-fidelity metric or a single evidence-refresh interval for clinical generative AI. Those controls need to be designed according to the system, intended use, evidence environment and clinical risk.
The leadership question should therefore move beyond “Does this AI use RAG?” A more useful question is: “Can we show what evidence this AI used, why that evidence was eligible, whether it was current and applicable, and whether the answer actually says what the evidence supports?”
That is the difference between connecting a language model to documents and building a clinically governable grounding system.
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 grounding, RAG, knowledge contract, citation fidelity, evidence freshness and the Clinical Generative AI Grounding Gate are used here as practical AI-governance and patient-safety concepts. The framework proposed in this article is not a statutory checklist under Vietnamese law. Legal obligations depend on the nature of the AI system, its risk classification, intended purpose, functions, data processing, deployment architecture and other applicable legislation.
Decision No. 33/2026/QĐ-TTg establishes the current list of high-risk AI systems and should not be interpreted as classifying every healthcare generative-AI or RAG application as high-risk. Conversely, absence from the current high-risk list does not remove other potentially applicable duties under the AI Law and Decree No. 142, including risk classification and transparency requirements. Article 13 of Decree No. 142 concerning significant changes to data sources, principal input data types or processing methods applies in the context of conformity assessment for high-risk AI systems and should not be generalized into a statutory revalidation requirement for every RAG update. Healthcare organizations may nevertheless use broader, proportionate source, retrieval and change-control measures as internal patient-safety practices.
Personal-data requirements become particularly important when clinical generative AI processes identifiable patient information. A RAG system using only public guidelines raises different data-protection issues from one retrieving clinical records or sending patient data to external infrastructure. Medical-device status is also a separate legal question from AI risk classification and should be assessed according to the software's intended purpose and functionality.
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 by Decree No. 07/2023/NĐ-CP, Decree No. 96/2023/NĐ-CP and Decree No. 04/2025/NĐ-CP.
[8] World Health Organization. Ethics and Governance of Artificial Intelligence for Health: Guidance on Large Multi-Modal Models. World Health Organization; 2024.
[9] Abo El-Enen M, Saad S, Nazmy T. A survey on retrieval-augmentation generation (RAG) models for healthcare applications. Neural Computing and Applications. 2025;37:28191–28267.
[10] Gao T, Yen H, Yu J, Chen D. Enabling Large Language Models to Generate Text with Citations. Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing. 2023:6465–6488.
[11] Lu Y, Goi SY, Zhao X, et al. MultiMed-RAG: leveraging multi-source knowledge and agent collaboration for medical tasks. npj Digital Medicine. Published 17 August 2026.
[12] Ferber D, Hilgers L, Höper C, et al. Towards autonomous medical artificial intelligence agents. Nature. 2026;655:1282–1291.
[13] Zhang L, Wölflein G, Ferber D, et al. On-premise medical AI agents for reliable clinical decision-making. Nature Medicine. Published 15 September 2026.
[14] Autio C, Schwartz R, Dunietz J, Jain S, Stanley M, Tabassi E, Hall P, Roberts K. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. National Institute of Standards and Technology; 2024.
[15] OWASP GenAI Security Project. OWASP Top 10 for LLM Applications 2025. 2025.