Third-Party Dependencies and AI Supply-Chain Risk in Healthcare in Viet Nam: Governing Foundation Models, APIs, Cloud Services and Subprocessors
IMPLEMENTATION INSIGHTS
Third-Party Dependencies and AI Supply-Chain Risk in Healthcare in Viet Nam: Governing Foundation Models, APIs, Cloud Services and Subprocessors
IMPLEMENTATION INSIGHT
Last reviewed: 4 October 2026
A healthcare organization may believe it has purchased one clinical AI product. In reality, that product may depend on a commercial foundation model, cloud infrastructure, APIs, an embedding service, a vector database, OCR, speech recognition, external medical knowledge sources, monitoring tools and several other technology providers. Some may process patient information. Some may operate outside Viet Nam. Some may change their models, APIs, security controls or commercial terms without the hospital signing a new contract with them.
The healthcare organization may know the name of the vendor whose logo appears on the screen while knowing much less about the infrastructure actually producing the clinical output. That is the problem of AI supply-chain risk.
In this article, AI supply-chain risk refers to the operational, clinical, cybersecurity, privacy and governance risks that arise when an AI system depends on external models, software, data sources, APIs, cloud services or other organizations. It is not about the pharmaceutical or physical medical-device supply chain, and “AI supply chain” is not itself a statutory risk category under Vietnamese law.
The practical governance question is straightforward: If an external dependency changes, fails or becomes unsafe, can the healthcare organization still understand, control and safely operate the AI system it approved?
One AI product can contain an entire dependency ecosystem
Modern AI products are rarely self-contained. Consider a hypothetical clinical assistant used by a hospital. A local vendor develops the application and user interface. The application sends requests to a foundation-model API. Patient documents are converted using OCR. Clinical policies are indexed in a vector database. Speech is processed by another provider. The application runs in a public cloud. Logs go to an observability platform, while authentication depends on a separate identity service.
To the clinician, this is one product. Operationally, the chain may look more like:
hospital → clinical-AI vendor → foundation-model provider → cloud provider → API → OCR or speech service → vector database → external knowledge source → monitoring platform
Not every AI product will contain all of these layers, but the principle matters. A healthcare organization can become dependent on an organization it has never directly assessed and may not even know exists.
Traditional vendor due diligence often concentrates on the company signing the contract. AI governance needs to understand the material dependencies behind that company as well.
OWASP's 2025 guidance identifies supply-chain vulnerabilities as a distinct risk for LLM applications and extends the concept beyond conventional software dependencies to third-party pretrained models, datasets and deployment platforms. The risks include compromised components, weak model provenance, outdated models, vulnerable adapters, licensing concerns and unclear or changing privacy and contractual arrangements [9].
Healthcare makes these dependencies more consequential because an upstream failure can affect clinical information, patient privacy, service availability or the reliability of a clinical workflow.
Using someone else's model does not necessarily remove provider responsibility
Viet Nam's Law on Artificial Intelligence No. 134/2025/QH15 has been effective since 1 March 2026 [1]. Its definition of provider is particularly relevant to AI supply chains.
Under the Law, a provider is an organization or individual that places an AI system on the market or puts it into use under its own name, brand or trademark, regardless of whether that system was developed by the organization itself or by a third party. A deployer is an organization or individual using an AI system under its control in professional, commercial or service-provision activities [1].
This means a technology company cannot automatically treat an upstream foundation-model company as the only relevant provider simply because it did not build the underlying model. Depending on the actual arrangement, the company placing the branded clinical AI product on the market may itself fall within the provider role. Likewise, a healthcare organization using the system under its control in healthcare delivery may fall within the deployer role.
The broader governance principle is important: technical outsourcing does not make responsibility disappear.
At the same time, Vietnamese law recognizes that downstream providers may not have unlimited visibility into upstream technology. Article 12 of Decree No. 142/2026/NĐ-CP provides that, for the risk-classification dossier applicable to high- and medium-risk AI systems, where a provider develops the system using a third-party platform, model or AI service, it is required to provide technical and data information only within the scope of its lawful rights of access and control [2].
This is an important practical boundary. A healthcare organization should distinguish between information its direct vendor controls, information the vendor can contractually obtain from an upstream provider, and information that legitimately remains outside the vendor's direct visibility.
Limited visibility, however, should not become an excuse for unmanaged dependency. Decree No. 142 also provides that where an AI system integrates AI models supplied by other organizations or individuals, the provider must reach arrangements with those model providers to support cooperation and provision of technical information necessary for legally required transparency and explanation [2].
The objective is therefore not perfect visibility into every proprietary component. It is sufficient visibility to govern the clinically material dependencies of the system.
Foundation models and APIs can change while the hospital-facing product appears unchanged
Foundation models create an unusual type of software dependency. In conventional software, a hospital may validate a particular product version and reasonably expect that version to remain substantially stable until an update is installed. AI delivered through an external model API may behave differently.
An upstream provider can release a new model, change a model alias, modify safety policies, alter structured-output behavior, change context limits, deprecate a model or modify infrastructure in ways that force the downstream vendor to alter its application. The clinical-AI product may still display the same name and interface. From the hospital's perspective, nothing obvious has changed; from the system's perspective, one of its most important components may have changed substantially.
Healthcare organizations should therefore distinguish between the product version they see and the dependency versions that materially influence system behavior.
For clinically consequential AI, the organization should be able to establish, directly or through the primary vendor, which foundation model or model family materially supports the system, whether the system is pinned to a model version or may change dynamically, who can authorize a model switch, and what testing occurs before such a change reaches the clinical workflow. A statement such as “we use a leading foundation model” is not sufficient system documentation.
APIs create a similar problem. They connect AI applications to models, EHRs, laboratory systems, imaging services, cloud platforms and external knowledge sources. Technically, an API is an interface. Once clinical workflow depends on it, it can also become a patient-safety dependency.
An API may begin returning a different schema, truncate information, change authentication behavior, become slower, modify version support or return different error responses. Some failures are obvious because the application stops working. Others are more difficult to detect because the application continues operating with incomplete or altered inputs.
NIST's current Guidelines for API Protection for Cloud-Native Systems, updated in March 2026, addresses API risks and controls across development and runtime stages [8]. It is neither Vietnamese law nor healthcare-specific, but it provides a useful technical reference for AI architectures increasingly dependent on APIs.
Clinical-AI API governance should therefore extend beyond cybersecurity to include schema stability, data integrity, latency, versioning, error behavior, deprecation and fallback. If an upstream API becomes unavailable or behaves unexpectedly, the organization should know whether the AI stops safely, continues with cached information, loses part of its context, produces a degraded output or alerts the user that its information environment has changed.
Cloud, downstream providers and patient-data flows need to be mapped together
Cloud services make sophisticated AI accessible without requiring hospitals or vendors to own the entire computing infrastructure. They also introduce external dependencies. A cloud outage can make an AI system unavailable, a regional failure can interrupt inference, a networking problem can increase latency, and a platform provider can retire or alter services on which a downstream product depends.
For a low-consequence administrative AI tool, temporary unavailability may be inconvenient. For a system embedded in triage, imaging prioritization or clinical decision support, the same event can alter care delivery.
Cloud availability should therefore be considered part of the system's operating environment. Healthcare organizations need to know whether the product can operate in degraded mode, how long the clinical workflow can safely tolerate interruption and what non-AI fallback remains available.
Cloud architecture is also a personal-data issue. Decree No. 356/2025/NĐ-CP contains specific requirements for personal-data protection in cloud computing [5]. Organizations entering contracts involving personal-data processing with cloud-service providers have responsibilities that include addressing compliance with Vietnamese personal-data law in the contract, identifying personal-data processing flows and party roles, defining security and organizational measures, immediately notifying relevant parties of changes that may affect personal data, complying with retention and deletion requirements, protecting data-subject rights and implementing appropriate access controls [5].
The Decree also places obligations on cloud-service providers themselves, including requiring subcontractors to comply with applicable personal-data protection requirements and carrying out periodic compliance assessment [5].
This makes cloud architecture more than an infrastructure decision. It becomes part of privacy governance and, where the AI affects care, potentially part of patient-safety governance as well.
The term subprocessor is commonly used in international technology contracts to describe an organization engaged downstream to perform part of the processing. It is useful operational language, but it is not one of the core personal-data roles defined by Viet Nam's Personal Data Protection Law. The Law uses roles including personal data controller, personal data processor, personal data controller-and-processor and third party [4]. The relevant legal role depends on what an organization actually does with the data rather than the commercial label applied to it.
Healthcare organizations should therefore not be satisfied merely because a vendor says that it uses “subprocessors.” They need to understand what material downstream organizations actually do. A foundation-model provider may receive clinical prompts. A speech service may process recordings. An observability platform may receive prompts or outputs. A vector database may store clinical text. A cloud service may host or actively process information.
Those functions reveal the real data-processing architecture.
A local vendor can still sit on top of an international data flow
A product can appear local while its processing architecture is international. A hospital may contract with a Vietnamese company whose application is hosted on a foreign cloud platform, whose model endpoint operates abroad, and whose speech-recognition, analytics or support providers are located in additional jurisdictions.
Under Decree No. 356/2025/NĐ-CP, cross-border transfer of personal data includes specified circumstances such as transferring personal data collected or stored in Viet Nam to servers outside Viet Nam or foreign cloud services, transferring personal data to recipients abroad, or sending personal data collected in Viet Nam to an overseas platform for continued processing [5].
Where the relevant statutory conditions apply, responsible parties need to address the applicable cross-border impact-assessment, documentation, filing and updating requirements. The required cross-border impact-assessment dossier also includes documentation demonstrating binding responsibilities between transferring and receiving parties [5].
Separate personal-data processing impact-assessment requirements may also apply to relevant controllers, controller-processors and processors from the commencement of personal-data processing [5].
The practical lesson is simple: the healthcare organization needs to understand the actual path of patient data, not merely the address of the company from which it bought the software. A Vietnamese contract does not make an overseas model endpoint local.
Supply-chain governance also requires technical provenance
Healthcare organizations need to understand not only who processes information, but also which technical components materially influence the AI product.
AI systems can incorporate pretrained models, fine-tuning adapters, open-source libraries, datasets, embedding models, model weights, container images and other components obtained from third parties. OWASP identifies weak model provenance, compromised pretrained models, vulnerable adapters, outdated models and tampered components among LLM supply-chain risks [9].
NIST's 2026 Cybersecurity Supply Chain Risk Management: Due Diligence Assessment Quick-Start Guide similarly identifies provenance, resilience, foundational cybersecurity practices and supply-chain tiers, alongside foreign ownership, control or influence, as relevant dimensions of ICT supplier due diligence [7]. Neither framework is Vietnamese law or a clinical-AI standard, but their principles are useful when healthcare organizations decide how deeply to evaluate material AI dependencies.
Relevant questions include whether a critical model came from an authoritative source, whether its deployed version is identifiable, which external datasets or knowledge sources materially influence the product, which open-source or third-party components are critical, and whether the vendor can reproduce the deployed configuration after an incident.
A hospital does not need to inspect every software package in every product. The depth of review should be proportionate to consequence. What matters is understanding the components whose failure, compromise or alteration can materially change clinical behavior, privacy, security or availability.
Third-party changes should not become invisible AI updates
One of the hardest supply-chain problems is deciding when an upstream change should be treated as a change to the clinical AI system itself.
The hospital may install no new software while an upstream model provider changes a model. A speech service modifies transcription behavior. A cloud provider retires a service. The primary vendor replaces an embedding model. An external knowledge source changes its API. Any of these events can alter downstream AI behavior without appearing in ordinary hospital change management.
For high-risk AI systems, this can have direct regulatory relevance. Article 13 of Decree No. 142 requires the provider to reassess conformity when a significant change affects the basis of the original conformity assessment. Relevant examples include changes to system architecture or AI models, data sources or principal input types, data-processing methods and integration into new operating environments where those changes materially affect operation or risk [2].
This does not mean every upstream patch, model release or API revision automatically triggers conformity reassessment. The legal test depends on whether the change meets the significant-change criteria.
Healthcare organizations can nevertheless operate a broader internal clinical-AI change-control threshold. A foundation-model switch, major API change, replacement of a clinical knowledge provider, new cloud environment, material downstream-provider change or modification of data-retention behavior may justify governance review even if formal conformity reassessment is not legally required.
The key question is: Could this third-party change alter the evidence on which we previously concluded that the AI was safe and appropriate for this workflow?
Availability, resilience and concentration risk can become patient-safety issues
The more useful an AI system becomes, the easier it is for the organization to become dependent on it. Clinicians adjust workflows. Manual steps disappear. Queues are redesigned around AI prioritization. Staffing assumptions change. Knowledge and operational capability gradually move into automated processes.
An upstream service can then fail. A foundation-model API may become unavailable. Cloud access may be disrupted. Authentication may fail. A vendor may discontinue a service. An upstream company may be acquired, become insolvent or retire a product on which the hospital depends.
NIST SP 1326 treats resilience as a core dimension of supplier due diligence [7]. In healthcare AI, resilience should be assessed clinically as well as technically.
The organization needs to know what function disappears when the dependency disappears. If an AI-generated discharge summary is unavailable, staff may return to manual documentation. If an AI system used to prioritize urgent imaging disappears, radiology workload may require immediate redistribution. If a clinical knowledge assistant becomes unavailable, established reference resources may provide a workable fallback. If a semi-autonomous workflow has displaced the manual process entirely, recovery may be much harder.
Responsible implementation therefore needs degraded-mode, fallback, recovery and maximum tolerable interruption arrangements before the service becomes operationally indispensable.
Organizations also need to consider concentration risk. A hospital may believe that three products from three AI vendors provide diversification while all three ultimately depend on the same foundation-model provider, cloud region, speech-recognition service or identity platform. A single upstream outage, cybersecurity event or policy change can then affect several apparently independent clinical systems at once.
Dependency governance should therefore operate at the organizational level, not only at the individual-product level. Several high-consequence AI applications relying on one upstream service make that service important because of its aggregate organizational impact, even if each individual contract appears relatively small.
Contracts need to govern technical change as well as commercial change
A healthcare organization does not need a direct contract with every upstream provider. Its primary contract should, however, provide enough visibility and control to govern the dependencies that materially affect the service.
For clinically consequential AI, relevant contractual topics can include material service providers; permitted uses of patient information; processing and hosting locations; retention and deletion; whether patient data may be used to train or improve third-party models; cybersecurity controls; incident notification; changes to architecture; foundation-model replacement; API deprecation; downstream providers; service availability; business continuity; data portability; and exit support.
Some of these provisions are legally required in particular circumstances. Others are prudent risk-management controls rather than universal statutory requirements. That distinction should remain clear.
Cloud contracts involving personal-data processing have a particularly strong legal anchor in Decree No. 356. The Decree imposes specific responsibilities relating to data-processing flows, party roles, technical and organizational safeguards, changes affecting personal data, retention and deletion, data-subject rights and access controls [5].
Healthcare organizations can go beyond those data-protection requirements by requiring appropriate notice where a technical change could materially affect clinical performance or patient safety.
Commercial terms also matter. A foundation-model provider may alter retention rules. An API service may change whether customer content can be used for service improvement. A new downstream provider may be introduced. Regional availability can change. Pricing may force the primary vendor to replace one model or service with another.
OWASP recognizes unclear or changing privacy and contractual terms as part of the LLM supply-chain problem [9].
A system initially approved because patient prompts were not retained should not automatically remain approved if an upstream change alters that assumption. Material technical, contractual and privacy changes belong in the same governance conversation.
Cybersecurity compromise can become a clinical event
A compromised dependency can create more than a confidentiality problem. A tampered model could alter outputs. A compromised API could return manipulated responses. A poisoned knowledge source could influence recommendations. An attacker controlling an orchestration layer might redirect prompts, tools or actions.
Viet Nam's Law on Cybersecurity No. 116/2025/QH15 has been effective since 1 July 2026 [6], alongside other applicable cybersecurity and information-security requirements.
This article does not attempt to restate those obligations. The important implementation point is that AI supply-chain cybersecurity and clinical safety can intersect directly.
If a cyberattack changes a recommendation presented to a clinician, the security incident has become a patient-safety issue. Healthcare organizations should therefore move beyond treating “Is the vendor secure?” and “Is the AI clinically safe?” as completely separate questions, and also ask:
“Could compromise of any material dependency change the clinical behavior of this AI, and would we know?”
Supplier due diligence should follow dependency criticality
Not every third-party dependency deserves the same depth of review. A low-level software utility does not create the same risk as the foundation model generating a clinical recommendation. An analytics service that never receives patient information creates a different privacy risk from a speech service that processes entire clinical consultations.
Useful indicators of dependency criticality include whether the dependency can materially influence clinical output; receives identifiable or sensitive patient data; can execute actions; creates a single point of failure; can change without the healthcare organization's approval; operates outside Viet Nam; is difficult to replace; or supports several clinical AI systems simultaneously.
NIST SP 1326 provides a useful general model for supplier due diligence through factors such as provenance, resilience, foundational cybersecurity practices and supply-chain tiers [7]. In healthcare, these technical factors should be combined with clinical consequence.
A dependency deserves deeper scrutiny when its failure or compromise can materially alter patient care.
A Clinical AI Dependency Register can make hidden dependencies governable
Healthcare organizations commonly maintain vendor lists, technology inventories and data-processing records. Clinical AI creates a case for another view: a Clinical AI Dependency Register.
For each clinically consequential AI system, such a register can identify the primary vendor; relevant provider and deployer roles; foundation model or model family where known and material; hosting environment; critical APIs; external clinical-data or knowledge sources; OCR, speech or imaging services; vector databases; material processors, subcontractors or downstream service providers; relevant processing locations; categories of personal data involved; dependencies capable of changing system behavior; fallback arrangements; and the internal owner responsible for monitoring the system.
The purpose is not to document every software library used by every vendor. It is to identify the dependencies that can materially affect clinical function, data protection, cybersecurity, availability or accountability.
A useful dependency register should help answer: If this component changes or disappears tomorrow, what breaks? Who will know? Who decides whether the AI can continue operating?
Visibility alone is not governance. Once material dependencies have been identified, the organization should define which events require technical review, cybersecurity assessment, privacy review, clinical-safety review, contractual action or system suspension.
A minor patch to an internal monitoring component may require no clinical review. A foundation-model change supporting clinical recommendations may require regression testing. A new foreign processor may require personal-data assessment. An API-schema change may require integration validation. An upstream outage may activate downtime procedures.
Not every change requires a committee meeting, but important changes should not disappear into ordinary vendor release notes.
Post-go-live monitoring should include the upstream ecosystem
Traditional clinical-AI monitoring focuses on the output of the system: performance, drift, incidents, calibration and user behavior. Supply-chain monitoring asks whether the system behind that output has changed.
Depending on the product, an organization may need to know whether a foundation-model version has changed, an API has been deprecated, a cloud region or hosting arrangement has changed, a new processor or downstream provider has been introduced, a critical component has reached end of support, data-retention terms have changed or an upstream outage is affecting availability or latency.
At the organizational level, monitoring should also identify whether a single upstream service is becoming a critical shared dependency for an increasing number of AI applications.
NIST SP 1326 recommends considering continuous monitoring so supplier due-diligence information can be updated as supplier circumstances evolve [7]. The principle is particularly relevant to AI because dependencies can change faster than traditional procurement cycles. An annual vendor review may be inadequate for an AI product whose material upstream components change several times within a year.
AI supply-chain risk is not a separate legal risk class in Viet Nam
Viet Nam's AI Law and Decree No. 142 apply a risk-based regulatory framework to AI systems. They do not create a statutory category called AI supply-chain risk [1,2].
Decision No. 33/2026/QĐ-TTg, effective from 15 August 2026, establishes the current list of high-risk AI systems [3]. As of this review, its healthcare section identifies specified AI-assisted surgical and robotic-surgery systems under defined conditions. A healthcare AI application does not therefore become legally high-risk merely because it relies on multiple third-party services.
Being outside the current high-risk list does not place an AI system outside the AI Law. Medium- and low-risk systems remain subject to applicable requirements under the framework depending on the actual system, its use and its classification [1].
For high-risk AI systems, the supply chain can become particularly important because Article 15 of Decree No. 142 requires providers to maintain risk-management systems and provide deployers with information necessary for safe operation. Article 13 requires reassessment of conformity where specified significant changes affect the basis of the original assessment [2].
The Decree also expressly recognizes that providers may build AI systems using third-party platforms, models or AI services and calibrates risk-classification information requirements to the provider's lawful rights of access and control [2]. That provision should not be interpreted as removing responsibility for material dependencies; rather, it reflects the practical reality that responsibility, technical visibility and contractual access do not always sit with the same organization.
These provisions do not impose the specific Dependency Register or Supply-Chain Gate proposed in this article. They nevertheless reinforce the need to understand which material components and organizations can affect the operation of regulated AI systems.
A practical Clinical AI Dependency and Supply-Chain Gate
Before approving a clinically consequential AI system, the healthcare organization can begin with dependency mapping. What external models, APIs, cloud services, data sources and processing services are necessary for the product to work? Which are controlled by the primary vendor and which are provided by other organizations? Can the vendor identify the model families, service versions or other components that materially influence clinical behavior?
The next layer is criticality and resilience. Which dependencies can change clinical output? Which create single points of failure? What happens if the foundation model, API, cloud platform or knowledge source becomes unavailable? Is there a safe degraded mode? Can the clinical workflow continue without the AI? How long can a dependency be unavailable before care is materially affected?
A third layer is personal-data governance. Which organizations receive patient information? What legal role does each actually perform under Vietnamese personal-data law? Where is information processed and stored? Does any data flow meet the legal definition of a cross-border transfer? Are required processing agreements, impact assessments, cloud-contract provisions, retention rules and deletion arrangements in place where applicable?
The organization should then examine change control and provenance. Can the vendor replace a foundation model, API, data source or downstream provider without notification? Are clinically material models and configurations traceable? How are upstream changes regression-tested? Which changes require local review or revalidation? If an unexpected clinical output occurs, can the organization reconstruct the material dependency configuration that was active at that time?
The next layer is cybersecurity and integrity. How does the vendor evaluate third-party models and other critical dependencies? How are API credentials, interfaces and access controls protected? Are critical components monitored for vulnerabilities, compromise and deprecation? Could a compromised model, knowledge source or software component silently alter clinical behavior?
Finally comes contracting and lifecycle oversight. Do agreements provide appropriate notice of material technical, privacy and supplier changes? Are service levels and incident communications adequate for the clinical use? Is exit support defined? Can the organization retrieve its data and relevant configuration history? Is there an internal owner for material AI dependencies, and are those dependencies monitored after go-live?
The Clinical AI Dependency and Supply-Chain Gate is a practical organizational framework proposed for healthcare implementation, patient safety and digital governance. It is not a statutory checklist prescribed by Vietnamese law.
What this means for healthcare organizations in Viet Nam
As healthcare AI becomes more sophisticated, healthcare organizations are increasingly buying systems assembled from other systems.
The vendor visible to the hospital may not own the foundation model. The model provider may not operate the cloud. The cloud provider may not operate the speech service. The AI may rely on medical knowledge or data services that none of those organizations controls.
That architecture is not inherently unsafe. Modern digital healthcare already depends extensively on third-party technology. The governance problem begins when clinically important dependencies become invisible.
A healthcare organization cannot meaningfully govern the safety of clinical AI if it does not know which external components can materially change behavior, where patient information travels, what happens when an upstream service fails and who is expected to respond when something goes wrong.
This is especially relevant in Viet Nam as healthcare organizations adopt cloud services, generative AI and international technology platforms while operating under new AI, personal-data protection and cybersecurity frameworks.
The objective is not to eliminate third-party dependencies. It is to make critical dependencies visible, proportionate and governable.
The leadership question should therefore move beyond “Which AI vendor are we buying from?”
A more useful question is:
“What does this AI actually depend on, who can change those dependencies, where does our patient data go, and can we continue providing safe care if one of those dependencies changes or fails?”
That is where vendor management becomes clinical AI supply-chain governance.
Professional education notice
This article is intended for professional education and knowledge exchange. It does not constitute individualized legal, regulatory, clinical, cybersecurity, procurement, data-protection or medical-device advice.
The terms AI supply chain, dependency, foundation-model dependency, subprocessor, concentration risk, dependency register and the Clinical AI Dependency and Supply-Chain Gate are used here as practical technology-governance and patient-safety concepts. “AI supply chain” is not a separate statutory risk category under Vietnamese AI legislation. “Subprocessor” is used as a common operational and contractual term rather than as a substitute for the personal-data roles defined under Vietnamese law.
The applicable legal obligations depend on the actual architecture, AI risk classification, contractual relationships, personal-data roles, data flows and cybersecurity context. For high-risk AI systems, material changes to architecture, AI models, data sources, principal input types, processing methods or operating environments may become relevant to conformity reassessment under Decree No. 142/2026/NĐ-CP where the statutory criteria are met.
Decree No. 142 also recognizes limits on a downstream provider's access to technical information when systems are built on third-party platforms, models or AI services. Those limits should be understood as part of the actual allocation of visibility and control, not as a general exemption from governance or risk-management responsibility.
The NIST and OWASP materials cited in this article are international implementation and cybersecurity references. They are not Vietnamese legal requirements and should be adapted to the healthcare organization's actual clinical context and applicable Vietnamese law.
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] National Assembly of Viet Nam. Law No. 116/2025/QH15 on Cybersecurity. Adopted 10 December 2025; effective 1 July 2026.
[7] Boyens J, McWhite R, Calloway L. NIST Cybersecurity Supply Chain Risk Management: Due Diligence Assessment Quick-Start Guide. NIST SP 1326. National Institute of Standards and Technology; 2026.
[8] Chandramouli R, Butcher Z. Guidelines for API Protection for Cloud-Native Systems — March 2026 Update. NIST SP 800-228-upd1. National Institute of Standards and Technology; 2026.
[9] OWASP GenAI Security Project. OWASP Top 10 for LLM Applications 2025: LLM03 — Supply Chain. 2025.