Building an AI Inventory and Risk Register in Viet Nam: A Practical Framework for Healthcare Organizations
PRACTICAL FRAMEWORKS & TOOLS
Building an AI Inventory and Risk Register in Viet Nam: A Practical Framework for Healthcare Organizations
PRACTICAL FRAMEWORKS & TOOLS
Last reviewed: 2 October 2026
A healthcare organization cannot govern AI effectively if it does not know which AI systems are actually being used, where they are used, who is responsible for them and what risks they create.
That sounds straightforward, but AI rarely enters a hospital through one door. One system may be purchased as clinical decision-support software. Another may be embedded inside an imaging or endoscopy platform. A third may appear after a vendor software update. Staff may use generative AI for documentation, translation or administrative work, while a patient-facing chatbot may be operated by an external provider. Some AI-enabled functions may sit inside existing HIS, EMR, PACS, LIS or enterprise platforms and may not even be described internally as “AI.”
The result is a practical governance problem: an organization may have an AI committee, policies and approval processes but still lack a reliable picture of the AI it is actually governing. An AI inventory addresses that visibility problem by maintaining an organized record of AI systems and AI-enabled functions in use or under consideration. An AI risk register goes further by documenting the important risks associated with those systems, the controls in place, who owns the risks, what residual risk remains and what actions are still required. Together, they create a practical foundation for responsible AI governance.
This is increasingly relevant in Viet Nam. The Law on Artificial Intelligence No. 134/2025/QH15 has been effective since 1 March 2026. Providers must classify AI systems before they are put into use, while deployers must coordinate with providers to review and reclassify systems when deployment, modification, integration or changes in function create new or higher risks. Decree No. 142/2026/NĐ-CP, effective since 1 May 2026, further specifies that review and reclassification are required when deployment, modification, integration or a change in function or intended purpose creates new or higher risk.[1,2]
These rules do not, however, establish a universal hospital AI inventory template or organizational risk-register form. The framework in this article is a practical governance approach designed to help healthcare organizations know what AI they are using and manage it consistently.
An AI inventory is not the same as Viet Nam’s national AI database
Viet Nam’s AI framework establishes an AI one-stop electronic portal and a National Database on Artificial Intelligence Systems. The portal supports regulatory processes including risk-classification notifications, conformity-assessment information, classification updates and other required reporting. As a general rule, providers of medium- and high-risk AI systems must notify their classification results to the Ministry of Science and Technology through the portal before putting the system into use.[1,2]
That general rule needs to be read together with transitional provisions. Decision No. 33/2026/QĐ-TTg, effective from 15 August 2026, gives certain high-risk systems already in operation additional time to complete compliance obligations. High-risk systems in healthcare, education and finance that were already operating before the Decision took effect must complete those obligations before 1 September 2027. High-risk systems first put into operation during the six months following the Decision’s effective date must complete the applicable obligations before 1 March 2027.[3]
An internal healthcare organization inventory serves a different purpose. It should help leadership, clinical departments, quality and patient-safety teams, IT, privacy, cybersecurity, procurement and other governance functions answer questions such as: What AI are we using? Why are we using it? Who owns it? Who relies on it? What data does it process? What evidence supports it? What could go wrong? What controls are in place? Has anything changed since it was approved?
An internal inventory will typically contain substantially more organization-specific information than an external regulatory submission or public record, such as local validation findings, departmental ownership, workflow risks, training status, contract dependencies, local incidents, downtime arrangements and unresolved corrective actions. The two mechanisms should therefore not be confused.
Start with AI systems, not only algorithms or products marketed as “AI”
A useful inventory needs a clear scope. Under Decree No. 142, risk classification applies to an AI system, rather than to an AI model in isolation, except where a model is used as a component of a specific AI system.[2] That distinction is useful for healthcare governance as well. An algorithm or foundation model may be technically important, but organizational risk usually depends on the system in which it is deployed: who uses it, what data enter it, what output it produces and how that output affects decisions or care.
Healthcare organizations should therefore avoid building an inventory that includes only products explicitly marketed as “AI solutions.” Relevant systems may include AI-enabled imaging, pathology, laboratory and endoscopy functions; predictive and clinical decision-support systems; generative documentation tools; patient-facing conversational AI; triage and prioritization systems; remote-monitoring analytics; AI integrated into medical devices; operational AI; and AI functions embedded inside larger information or enterprise systems.
AI-enabled features introduced through software updates also deserve attention. A platform originally purchased as conventional software may later acquire AI functionality through a vendor release. Without a governance mechanism for identifying such changes, new AI can enter the organization without passing through the original approval process.
Approved AI is only part of the picture
A governance inventory should also help identify shadow AI. This may include staff using public generative AI tools to summarize information, translate text, draft documentation, analyze spreadsheets or produce reports without formal approval. It may also include locally created models, research tools, innovation projects and departmental pilots that have not yet reached central governance.
Not every experimental or unapproved use should become an approved organizational system. But an organization cannot manage risks it does not know exist. Discovery should therefore be capable of identifying approved AI, experimental AI and known unapproved AI use while keeping those governance states clearly separate.
The purpose is not to create staff surveillance. It is to understand where AI is entering clinical and operational work so the organization can decide what should be approved, restricted, reviewed, redesigned or stopped.
Inventory the use case, not just the vendor
A vendor name and product name are not enough to govern an AI system. The same technology can create very different risks depending on how it is used.
An AI model that flags radiographs for closer review is different from the same model being used to automatically prioritize a worklist. A generative tool used to improve grammar in internal administrative documents is different from the same tool drafting individualized patient advice. A predictive system operating silently during evaluation is different from one whose output is visible to clinicians and influences treatment.
The inventory should therefore capture the local intended use. At minimum, the organization should understand what the system does, who uses it, which patients or processes it affects, what decision or action it supports, whether its output is advisory or more automated, where it sits in the workflow and what happens after an output is produced.
This local-use description is one of the most important fields in the inventory because nearly every other governance decision depends on it.
Legal risk classification and organizational risk priority are different things
Healthcare organizations should keep two concepts clearly separate.
The first is the statutory AI risk classification under Vietnamese law. AI systems are classified as high, medium or low risk. Providers conduct the initial classification, while deployers must coordinate with providers on reclassification when local deployment, modification or integration changes the risk profile.[1,2]
The current high-risk list under Decision No. 33/2026/QĐ-TTg does not classify every clinical AI application as high-risk. In healthcare, the current list identifies specified AI systems involving surgical support and surgical robots under defined conditions of integration, intervention and automation.[3]
The second concept is the organization’s internal risk assessment. A hospital may reasonably decide that a particular AI requires intensive internal oversight because it strongly influences diagnosis, processes sensitive information or could cause serious harm if it fails, even though the system is not legally classified as high-risk under Decision No. 33.
To reduce confusion, the inventory should use visibly different fields. For example, Legal AI risk classification: High / Medium / Low / Pending clarification, while Organizational risk priority: Critical / Significant / Moderate / Routine. The organization should define the methodology behind its internal priority rating and should never present that rating as the statutory classification.
Every AI system needs clear accountability
One of the most useful questions in an AI inventory is simple: Who owns this system inside the organization?
Ownership should mean more than knowing which department pays the invoice. An accountable organizational owner should have enough authority to coordinate decisions about intended use, performance, user access, monitoring, incidents, changes and eventual retirement.
Different supporting responsibilities can sit in different places. IT may manage technical integration, the clinical department may be responsible for clinical use, quality and patient safety may oversee safety monitoring, and privacy teams may oversee data-processing risks. The inventory may also need to identify the external provider and, where relevant, the internal or external developer.
The goal is not to force every responsibility onto one individual. It is to make the accountability structure visible.
Regulatory, evidence and assurance status should be easy to find
Clinical AI can sit at the intersection of several regulatory frameworks. An AI system may also constitute or be incorporated into a medical device, process sensitive personal data, create cybersecurity obligations or be subject to other sector-specific requirements.
The inventory should therefore capture regulatory status without pretending that the inventory itself is a legal opinion. Useful fields can include the AI-law provider and deployer, current statutory risk classification, classification-notification status where applicable, current high-risk-list status, medical-device status, relevant registrations or authorizations and links to supporting documentation.
If a system is legally classified as high-risk, applicable conformity-assessment requirements must also be addressed. Article 13 of the AI Law establishes conformity assessment for high-risk systems before use and when significant changes occur. The exact assessment pathway can differ, specialized-law assessment results may be recognized within their valid scope, and transitional provisions may affect timing.[1–3]
Where the organization cannot yet determine a regulatory status, recording “under review” is better than leaving the field blank. Unresolved questions should remain visible until they are resolved.
Evidence and assurance should be equally visible. The organization should be able to determine what evidence supported adoption, whether that evidence is relevant to the local population and workflow, whether local technical or clinical evaluation was undertaken, what acceptance criteria were used and whether important limitations remain unresolved.
The inventory does not need to contain the entire evidence dossier. It should point to it. A concise record might state: evidence reviewed: yes/no; local validation: completed / conditional / not indicated under the current organizational assessment, rationale documented / pending; approved use: defined population and workflow; known limitations: link or summary; baseline performance: reference to validation record.
Version and configuration matter
AI governance becomes difficult when nobody can answer: Which version are we actually using?
An organization may approve one version and later discover that the provider has updated the model, changed a decision threshold, modified the interface, changed the underlying infrastructure or added functionality. The inventory should therefore capture the deployed software or model version where available and relevant, together with important local configuration, the most recent material change and the date of the latest governance review.
Not every routine technical change should trigger a full review. Decree No. 142 expressly provides that routine upgrades, performance optimization, ordinary technical fixes or periodic data updates that do not change the nature of the system’s risk do not require review and notification of reclassification.[2] The organization nevertheless needs enough visibility to distinguish routine maintenance from changes that may alter risk, intended use, human oversight, data processing or regulatory status.
Version and configuration information therefore belongs in governance records, not only in technical documentation.
An AI risk register should describe scenarios, not vague labels
Once the organization knows which systems it has, the next question is what could go wrong. A risk-register entry such as “AI risk - high” provides almost no useful information.
A stronger entry describes a plausible event, the conditions that could allow it to happen and its potential consequence. For example: If endoscopy AI produces frequent false-positive alerts under local image conditions, clinicians may develop alert fatigue and begin ignoring valid detections, reducing the intended patient-safety benefit. Another scenario might be: If patient information is entered into an unapproved external generative AI service, sensitive health information may be processed outside approved organizational controls. Or: If a model update materially changes performance but is deployed without local review, clinicians may continue relying on evidence that no longer describes the system currently in use.
Specific scenarios make it much easier to design meaningful controls.
Risk should be considered across the whole system
Clinical AI risk is not only model-performance risk. Organizations should consider clinical and patient-safety risk, performance and evidence risk, human-factor risk, data and privacy risk, cybersecurity risk, operational risk, regulatory and compliance risk, third-party risk, and transparency or communication risk.
Clinical risks can include missed findings, inappropriate recommendations, delayed care or harmful automation. Performance risks can include poor transportability, calibration problems, drift, subgroup differences or insufficient validation. Human-factor risks include automation bias, alert fatigue and misunderstanding of outputs. Operational risks include downtime, latency, failed integrations and inability to continue a workflow when AI becomes unavailable. Third-party risks can arise from vendor concentration, subcontractors, cloud infrastructure or inadequate change notification.
Not every system needs the same depth of assessment. The depth of the risk register should remain proportionate to potential harm, degree of automation, uncertainty and organizational dependence on the technology.
Record controls, residual risk and action
Identifying a risk is only the beginning. The register should document what reduces that risk and what remains after those controls are applied.
A false-negative risk may be mitigated through independent clinician review, local validation and post-deployment monitoring. A privacy risk may be reduced through approved processing environments, access controls and data minimization. A provider-change risk may be addressed through contractual notification requirements, version control and revalidation triggers.
The organization can then consider the residual risk that remains. A risk that appears serious in the abstract may become manageable under strong controls, while a seemingly modest risk may remain unacceptable if no effective control exists.
Each material risk should also have an accountable owner, a defined control or corrective action, a target date and a method for verifying completion. Actions might include obtaining additional evidence, restricting the approved population, improving training, changing an interface or workflow, strengthening contractual protections, performing additional validation or temporarily restricting use.
Where residual risk is formally accepted, that should be a conscious decision at the appropriate governance level and documented. Internal risk acceptance cannot waive mandatory legal, regulatory, professional or patient-safety obligations.
Discovery should be systematic
Creating an AI inventory for the first time is often harder than maintaining one. A single email asking departments “Do you use AI?” is unlikely to identify everything because users may not know whether a product contains AI or may not consider a familiar embedded feature to be an AI system.
A stronger discovery process can combine procurement and contract records, medical-equipment inventories, HIS/EMR/PACS/LIS integrations, software and cloud subscriptions, vendor questionnaires, IT application inventories, departmental interviews, research and innovation projects, patient-facing digital services, cybersecurity reviews and structured review of generative-AI use.
Vendor discussions are particularly important because AI functionality may be embedded inside a larger product. A useful question is not simply “Is this an AI product?” but “Does any function use AI or machine learning to generate predictions, recommendations, content or decisions that influence our staff, patients, workflow or operations?”
Discovery becomes more reliable when it focuses on function rather than marketing terminology.
Do not make the inventory so broad that it becomes unusable
There is also a risk in the opposite direction. If every spreadsheet formula, conventional rules engine, search function and routine automation enters the AI inventory because it appears “smart,” the register will quickly lose value.
Organizations need a documented scope. The AI Law provides a legal definition of an AI system, while an organization may deliberately use a somewhat broader discovery process to identify technologies requiring review. The final governance inventory should nevertheless distinguish AI systems and AI-enabled functions from conventional software and automation.
Where status is genuinely uncertain, a temporary category such as “AI status to be determined” is more useful than either excluding the technology prematurely or treating it as AI without analysis. The goal is reliable governance, not the largest possible inventory.
The inventory should follow the system through its lifecycle
An AI inventory should not end when a system receives approval. Its status should evolve with the technology.
A practical lifecycle might move from proposed → under review → pilot → approved for limited use → routine use → restricted → suspended → decommissioning → retired. Movement between stages should trigger the relevant governance process. A pilot entering routine care may need stronger monitoring. Expansion to another site may require review of workflow and local validation. A material update may require change assessment. A suspended system should have documented reasons and clear conditions for reinstatement.
The inventory therefore becomes a lightweight lifecycle-control mechanism as well as a source of organizational memory.
Periodic review is useful, but the calendar should not be the only trigger. The inventory and risk register should also be updated when intended use changes, deployment expands to another site or population, a model or software version changes materially, a new data source or third-party dependency is introduced, local validation produces important findings, monitoring identifies deterioration, an incident occurs, the legal classification changes, or the system is restricted or retired.
This lifecycle approach also aligns with international risk-management practice. NIST AI RMF 1.0 is voluntary, not healthcare-specific and not a Vietnamese legal requirement, but its GOVERN 1.6 explicitly calls for mechanisms to inventory AI systems and resource them according to organizational risk priorities. NIST is currently revising AI RMF 1.0.[4]
WHO/Europe’s September 2026 Knowledge Community report similarly identified governance gaps and unclear accountability among barriers raised by participants, while strong governance was identified as an important enabler of responsible AI adoption. The report reflects the views of Knowledge Community participants and is not a binding WHO regulatory standard.[5]
A practical minimum AI inventory
A healthcare organization does not need a highly complex database on day one. A useful minimum record should identify system identity (name, AI-enabled function, provider and current version); purpose and scope (local intended use, target patients or processes, setting and sites); accountability (organizational owner, clinical owner where relevant, developer and supporting governance functions); users and workflow (intended users, affected population, output, degree of automation, human oversight and downstream action); legal and regulatory status (provider/deployer roles, statutory risk classification, high-risk-list status where relevant, medical-device status and supporting documentation); data (principal data types, sensitive health information, important flows and external or cloud dependencies); evidence and assurance (evidence reviewed, local-validation status, limitations and approved conditions of use); risk and controls (material risks, controls, residual risk and open actions); monitoring (owner, indicators, latest review and incidents); and change and lifecycle (version, material changes, revalidation or reclassification status, lifecycle stage and next review).
It is better to maintain a smaller inventory that is accurate and actively used than a sophisticated register that becomes obsolete after six months.
A practical AI Inventory and Risk Register Gate
Before an AI system moves into routine organizational use, a healthcare organization can apply a simple AI Inventory and Risk Register Gate.
Visibility: Is the system formally recorded in the AI inventory, including relevant embedded AI functionality?
Purpose: Is its local intended use, patient or operational population, workflow role and degree of automation clearly defined?
Accountability: Is there an identifiable organizational owner with authority to coordinate governance?
Legal status: Are provider/deployer roles, statutory risk classification and other relevant regulatory statuses known or actively under review?
Evidence: Is the evidence and local-validation status visible, together with important limitations and the rationale for the chosen assurance approach?
Risk: Have material clinical, human-factor, data, cybersecurity, operational, regulatory, third-party and communication risks been documented?
Controls: Are principal controls, residual risks, owners and outstanding actions clear?
Lifecycle: Is the current version, deployment status, monitoring arrangement and change history known?
Review: Are there clear triggers for updating the inventory, reassessing risk, revalidating, reclassifying or escalating concerns?
This Gate is an organizational governance framework, not a statutory checklist created by Vietnamese law.
What this means for healthcare organizations in Viet Nam
Healthcare organizations do not need to wait until they have dozens of AI systems before creating an inventory. In fact, the best time to start is while the number is still manageable.
A hospital can begin with the AI already known to leadership, then expand discovery through procurement, clinical departments, IT, medical equipment, research programs and generative-AI use. Each system can be assigned a clear owner and documented local intended use, linked to its regulatory status, evidence and validation records, and connected to a small number of meaningful risk scenarios.
Over time, this becomes more than a list of technology. It becomes organizational memory. When leadership asks whether an AI system was validated, the answer is findable. When a provider announces a model update, the affected workflows can be identified. When an incident occurs, the accountable owner and existing controls are visible. When a department proposes expansion to another site, the organization can see what assumptions supported the original approval. When the technology is no longer useful, it can be retired deliberately rather than quietly remaining in the environment.
For healthcare leaders, the practical question is not simply “How many AI systems do we have?” It is “Do we know where our AI is, what it is doing, who is responsible for it, what could go wrong and whether the controls we relied on are still working?”
That is the purpose of an AI inventory and risk register. Good AI governance starts with visibility. If an organization cannot see its AI, it cannot reliably govern it.
Professional education notice
This article is intended for professional education and knowledge exchange. It does not constitute individualized legal, regulatory, clinical, medical-device, cybersecurity, personal-data or risk-management advice.
The AI Inventory, Risk Register and AI Inventory and Risk Register Gate described in this article are practical organizational governance recommendations. They are not statutory forms, registers or checklists mandated for all healthcare organizations under Vietnamese law.
The internal organizational risk priority described in this article should not be confused with the statutory high-, medium- and low-risk classification of AI systems under the Law on Artificial Intelligence and Decree No. 142/2026/NĐ-CP. Internal risk acceptance likewise does not override mandatory legal, regulatory, professional or patient-safety requirements.
Healthcare organizations should separately assess applicable obligations relating to AI risk classification and notification, high-risk AI, conformity assessment, medical devices, personal-data protection, cybersecurity, professional practice and other specialized 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. 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. 30 June 2026; effective 15 August 2026.
[4] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, January 2023. Voluntary framework; revision in progress as of 2 October 2026.
[5] World Health Organization Regional Office for Europe. Report of the Knowledge Community on Responsible Artificial Intelligence in Health. 1 September 2026. WHO/EURO:2026-13381-53155-83077.