Vietnam AI law sets a risk-based model for AI governance

At a glance

What this is: Vietnam’s AI Law establishes the country’s first comprehensive AI governance framework, with risk-based obligations, lifecycle accountability, and reporting requirements for serious incidents.

Why it matters: It matters because IAM, data, and AI governance teams will need to map who is responsible for AI decisions, controls, and incident response as deployments cross development, provider, deployer, and user boundaries.

👉 Read OneTrust’s analysis of the Vietnam AI Law and AI governance obligations

Context

Vietnam’s AI Law introduces a governance model that separates low-risk from high-risk AI systems and ties obligations to the potential for harm. For practitioners, the core issue is not simply whether AI is in use, but whether the system can affect individuals, public safety, or national infrastructure in ways that require stronger controls.

The law also creates a clear accountability structure across the AI lifecycle, which is highly relevant to identity and access governance. When developers, providers, deployers, and users all carry different responsibilities, organisations need traceability for system ownership, approvals, logging, and escalation paths rather than assuming governance ends at deployment.

Key questions

Q: How should organisations classify AI systems before deployment?

A: Organisations should classify AI systems by the harm they could cause, not by how advanced the model seems. Start with the decisions the system influences, the people or processes it affects, and whether human oversight can realistically catch failures before impact. High-risk systems need formal review, documented ownership, and stronger evidence of control.

Q: Why does lifecycle accountability matter in AI governance?

A: Lifecycle accountability matters because AI risk is shared across developers, providers, deployers, and users. If ownership is unclear at any handoff, no one can prove who approved the system, who maintains controls, or who responds when harm occurs. That makes traceability a governance requirement, not an administrative nice-to-have.

Q: What do security teams get wrong about AI logging?

A: Many teams log only infrastructure events and miss the AI-specific evidence needed for oversight. Useful logs must show prompts, outputs, configuration changes, and human interventions so investigators can reconstruct the system’s behaviour. Without that detail, incident response and regulatory reporting become guesswork.

Q: Who is accountable when a high-risk AI system causes harm?

A: Accountability usually follows the role that controlled the system’s deployment and use, even if the model was built elsewhere. The deployer often remains responsible for affected people, while contractual recovery may be possible against a provider or developer. Organisations therefore need clear role definitions and incident escalation paths before an issue occurs.

Technical breakdown

Risk-based AI classification and conformity assessment

The law uses a risk-based model that classifies AI systems as low, medium, or high risk. High-risk systems require conformity assessment before deployment, which is a control step that tests whether the system meets safety and compliance requirements. In practice, this moves governance upstream, so organisations must assess intended use, affected populations, and possible harm before release. The key technical point is that risk classification is not static. A model’s control obligations depend on context, data sensitivity, and the decisions it influences, not just the underlying model architecture.

Practical implication: build a pre-deployment AI risk triage process that determines when formal assessment, documentation, and human review are required.

Lifecycle accountability across developers, providers, deployers, and users

Vietnam’s framework assigns distinct responsibilities across the AI lifecycle. That matters because modern AI systems are rarely owned by a single party from training through operation. Developers may build or fine-tune the model, providers may distribute it under their brand, deployers may integrate it into business workflows, and users may rely on outputs that shape decisions. This shared chain of responsibility creates a governance problem familiar to identity teams: access, approval, and accountability must survive handoffs. Without that, organisations cannot prove who authorised the system or who owns the control failure when things go wrong.

Practical implication: maintain lifecycle ownership records that connect each AI system to a responsible party, approval history, and escalation path.

Logging, incident handling, and high-risk AI safeguards

The law requires technical documentation, logging, transparency, and ongoing compliance for high-risk systems. Logging is especially important because AI governance breaks down when organisations cannot reconstruct what the system processed, produced, or changed. The article also notes incident handling and serious-incident reporting through a national portal, which means organisations need operational detection and response, not just policy text. For identity and security practitioners, this is where AI governance meets control evidence. If a system can make recommendations, trigger decisions, or affect regulated outcomes, logs become the proof that oversight existed and was active.

Practical implication: align AI logging, incident triage, and evidence retention with existing security operations and compliance workflows.

Threat narrative

Attacker objective: The objective is to use AI systems in ways that cause harm, deceive users, or bypass accountability while avoiding effective oversight.

1. Entry occurs when an AI system is introduced into a business process without adequate classification, ownership, or pre-deployment review.
2. Escalation follows when the system is allowed to operate in a high-impact context without sufficient logging, oversight, or incident handling.
3. Impact occurs when harmful or deceptive outputs affect individuals, public order, cybersecurity, or national security and the organisation cannot prove effective control.

NHI Mgmt Group analysis

Vietnam’s AI Law turns AI governance into a control-execution problem, not a policy statement. The law’s emphasis on risk classification, conformity assessment, logging, and incident reporting means organisations must prove that governance works in practice. That is the same shift identity teams have seen in IAM and PAM programmes: accountability only matters when it is mapped to system ownership and enforceable controls. Practitioner conclusion: treat AI governance as an operating model with evidence, not a policy library.

Lifecycle accountability is the law’s most operationally important design choice. By assigning responsibilities to developers, providers, deployers, and users, the framework acknowledges that AI risk is distributed across the supply chain. That maps closely to identity governance problems where ownership breaks at handoff points, especially when data, model access, and approval rights are separated. Practitioner conclusion: build traceability across the full AI lifecycle so responsibility does not disappear between teams.

High-risk AI oversight will increasingly resemble identity and access governance for non-human systems. Once AI systems can influence decisions, generate outputs, or trigger business actions, organisations need logging, review, escalation, and incident response that resembles control evidence in IAM and NHI programmes. The important shift is that AI systems are not just tools to deploy; they are operational actors that require managed authority. Practitioner conclusion: extend governance models so AI systems are monitored like privileged digital entities.

Prohibited manipulative uses show that governance now includes misuse prevention, not just model safety. The law explicitly targets deceptive, harmful, and exploitative AI behaviour, which means organisations must assess intended misuse as part of deployment decisions. That broadens the governance lens from technical accuracy to downstream abuse and public harm. Practitioner conclusion: evaluate both what the model can do and how it could be used against users or regulated processes.

Serious-incident reporting will push organisations toward auditable AI control evidence. Once authorities can investigate and publicise outcomes, weak logging, unclear ownership, and incomplete escalation paths become governance liabilities. For identity and security practitioners, this reinforces a familiar lesson: if controls are not measurable, they will not survive regulatory scrutiny. Practitioner conclusion: make evidence generation part of the AI control design from the start.

What this signals

AI governance will increasingly be judged by whether organisations can prove who changed what, when, and under whose authority. Vietnam’s model reinforces the broader market shift toward auditable lifecycle controls, not just policy language. For teams running AI in regulated workflows, this means identity-style traceability for models, operators, and exceptions will become a practical requirement, especially where NIST AI Risk Management Framework concepts are already in use.

Privilege discipline for AI systems is now a governance issue as much as a security issue. Our research shows 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, which is a strong signal that access scoping is drifting ahead of control maturity. The organisations that close this gap first will be the ones able to operationalise AI accountability rather than merely describe it.

For practitioners

• Classify AI systems before deployment Create a pre-release review that assigns each AI use case a risk tier based on impact, data sensitivity, and decision criticality. Require a documented owner and approval record before production use.
• Map accountability across the AI lifecycle Record which team owns development, provision, deployment, user-facing operation, and incident response for every in-scope system. Keep this mapping current when vendors, integrations, or workflows change.
• Add logging for AI decisions and outputs Capture prompts, outputs, configuration changes, and human overrides so investigations can reconstruct what happened. Retain records long enough to support incident review and regulatory reporting.
• Define serious-incident escalation paths Pre-agree who triages harmful AI events, who files regulatory notifications, and who can suspend the system when output causes or risks significant harm. Test the path with a tabletop exercise.
• Review misuse scenarios at design time Assess how the system could be used for deception, manipulation, or harmful automation before it is approved. Use those scenarios to decide whether human review, content controls, or deployment limits are needed.

Key takeaways

• Vietnam’s AI Law formalises a risk-based governance model that ties obligations to the harm an AI system could cause.
• The law’s lifecycle accountability model pushes organisations to track ownership, logging, and escalation across developers, providers, deployers, and users.
• For practitioners, the real task is to turn AI governance into auditable control evidence before high-risk systems reach production.

Key terms

• High-risk AI system: An AI system that could significantly affect individuals, safety, public order, or other critical interests. In governance terms, this classification determines whether stronger controls, assessments, documentation, and oversight are required before and during deployment.
• Conformity assessment: A formal evaluation used to verify that a system meets required safety and compliance expectations before it is deployed. For AI governance, it functions as a pre-release control that tests whether risk, oversight, and documentation requirements are satisfied.
• Lifecycle accountability: A governance model that assigns responsibility across the full AI lifecycle rather than assuming one party owns the entire system. It is especially important when developers, providers, deployers, and users all influence how an AI system behaves in production.
• Serious incident: An event linked to AI operation that causes, or could cause, significant harm to people, rights, property, cybersecurity, public order, or national security. The term matters because it triggers escalation, investigation, and potential regulatory response.

What's in the full article

OneTrust's full blog covers the operational detail this post intentionally leaves for the source:

• Detailed explanation of how Vietnam’s AI Law maps responsibilities across developers, providers, deployers, users, and affected persons.
• Practical examples of high-risk AI systems and the types of conformity or impact assessments they may require.
• A closer look at prohibited AI uses, including manipulative, deceptive, and harmful applications.
• OneTrust DataGuidance context for organisations comparing Vietnam’s rules with other regional AI governance regimes.

👉 OneTrust’s full blog covers the role definitions, high-risk safeguards, and enforcement details in more depth.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, and secrets management for practitioners building durable identity controls. It is suited to teams that need to connect identity governance to broader security and compliance programmes.