AI Governance in Production Under Vietnam's AI Law

Operationalizing Decree 142, Decision 33 High-Risk Classification and Circular 05 Ethics

An AI governance lead is asked a question that sounds easy: which AI systems does the company run?

The technology team has a list of models. Procurement has contracts for hosted services. Business teams use embedded AI inside larger products. A pilot is operating with real users but is still described as a test. Another system changed vendors, yet the risk assessment still names the old provider.

Then the harder questions arrive. Which systems were screened against Vietnam's official high-risk list? Which version of the list was used? What categories did the operator declare? Who approved the risk tier? Why did the reviewer disagree with the initial proposal?

Those questions expose the difference between an AI policy and an AI governance system.

Vietnam's legal and guidance layers make the operating challenge concrete. Decision 33 was promulgated, not drafted, and took effect on 15 August 2026. Its appendix contains 46 high-risk AI system categories across education, ethnic and religious affairs, health, banking, proceedings, and transport. Circular 05 is active subordinate ethics guidance under the AI Law, adding a responsible-AI layer around human oversight, transparency, complaints, testing, training, and self-assessment.

Neither instrument justifies a black-box classification product.

This is the point I want AI leaders to take seriously: a screening result is useful only if a responsible person can review it, challenge it, approve a classification, and stand behind the reason later.

The organization is not buying an oracle. It is building a decision record.

Read the AI Stack Alongside Privacy, Data and Security

ComplianceOne supports the AI Law 134/2025/QH15, Decree 142/2026, Decision 33/2026 and Circular 05/2026 as distinct legal and ethics layers. It also supports Decision 1671/QĐ-TTg, issued on 28 August 2026, as an active strategy reference. The national AI strategy provides direction to 2030 with a vision to 2045; the platform raises no obligation, risk tier, procedure, deadline, sanction or evidence duty from it. Any legal effect on a particular organization remains a matter for counsel. Strategy alignment is not classification approval or conformity evidence. Official Decision 1671 record.

AI evidence also depends on the data and deployment it describes. Personal-data processing needs separate review under PDPL 91/2025/QH15, Decree 356/2025 and relevant procedures in Decision 778/QĐ-BCA. The Data Law, Decree 165/2025 and Decision 20/2025 support a separate review of data governance and important/core-data classification. Cybersecurity Law 116/2025 and applicable implementing instruments address the system-security context. An approved AI risk tier does not establish lawful processing, an approved transfer or an approved information-system level.

Sector context remains necessary. Healthcare deployments may need Decree 102 evidence; banking deployments may need payment, supervisory-reporting or credit-information work; education deployments may need education-data records. Decision 33 classification should connect to that evidence without replacing the sector's own applicability decisions and approvals.

AI risk classification is one axis of compliance. The same deployed system can simultaneously create privacy, cybersecurity, banking, healthcare, education, consumer or other sector obligations. ComplianceOne keeps those decisions connected without flattening them into one generic “AI compliant” status.

Additional overlays depend on the deployed use. Public-facing generative or content systems may trigger online-information or false-information obligations under Decree 147/2024 and Decree 328/2026. Public-sector AI involving protected information may require controls under the State Secrets Law and Decree 63/2026. AI systems involving electronic identity or authentication may require separate review under the Identity Law and Decrees 69/2024 and 320/2026. These requirements need their own applicability assessments and supporting evidence. An approved AI risk classification does not establish compliance with them.

Data-service activities under Decree 169/2025 as amended by Decree 347/2026, and data exchanges under Decree 314/2026, require a specific role and activity match. Using training data or a hosted AI service alone does not establish those roles. Enforcement references also retain their own status: Decree 330/2026 addresses cybersecurity and personal-data penalties, while Decree 363/2026 on data-sector penalties remains upcoming until 11 November 2026. Neither should be represented as an AI risk-classification rule.

The practical model is one deployed-system identity with connected evidence, plus separate decisions for AI risk, privacy, data, security and sector scope. Supported content gives reviewers context; it does not make every framework applicable or authorize the platform to decide for them.

The Production Inventory Problem

Organizations rarely lose control of AI because nobody cares. They lose control because AI enters operations through several doors.

A central data-science team builds a model. A department activates an AI feature in existing software. A vendor adds automated scoring. A chatbot moves from internal experimentation to customer service. A transport, education, health, or finance workflow introduces automation without using the words "AI system" in its project name.

If inventory depends on voluntary reporting at one annual review, it will lag reality.

A useful AI register therefore needs enough context to distinguish systems that happen to share a model family. It should identify the provider, deployment context, lifecycle stage, system owner, relevant data categories, and the classification inputs required for review.

The register is not merely a catalog. It is the anchor for screening, reviewer judgment, obligations, evidence, and later reassessment.

For each AI system, a governance team should be able to answer:

• What does the system do in its deployed context?
• Who provides, operates, and owns it?
• Which people, decisions, or public interests may be affected?
• What lifecycle stage is it in?
• Which data categories does it process?
• Which listed categories did the operator declare relevant?
• Who reviewed and approved the classification?
• Which evidence and obligations follow from that decision?

Without that anchor, ethics evidence becomes a folder of generic principles and high-risk screening becomes a spreadsheet detached from the system it concerns.

Why Sector Alone Cannot Classify a System

Decision 33's 46 categories are grouped across six sectors, but being used in one of those sectors does not automatically make an AI system high-risk.

High-risk status depends on matching a listed category and satisfying the applicable conditions, including significant-harm potential and the absence of an applicable exclusion under Decree 142. A system that looks superficially similar to a category is not classified by resemblance alone.

This is why keyword matching is a dangerous shortcut. Natural-language descriptions of system behavior require contextual and legal judgment. A tool that finds the word "credit" or "education" has not established what the system actually does, whether the category fits, or whether an exclusion applies.

In ComplianceOne, the operator declares the categories considered relevant. Screening records those declarations, the rationale, and the exact version of the installed list. It produces a proposal. A separately permissioned reviewer decides the tier.

A screened but unreviewed system remains unclassified. It never defaults to low risk.

That state is more honest than a reassuring green label. "Unclassified" tells leadership that work remains. "Low risk" would imply a judgment nobody made.

The Human Reviewer Is the Control

The reviewer does not exist to rubber-stamp a machine result. The reviewer is the accountable control that turns structured inputs into an organizational classification.

The record should preserve:

• The list version used in screening.
• The operator's declared categories and rationale.
• The proposed tier and the basis for the proposal.
• The reviewer who approved the classification.
• The approval time and approved tier.
• The reason for any departure from the proposal.

A reviewer disagreement is not a system failure. It is valuable governance evidence. It shows that a person examined context and exercised judgment rather than accepting an automated answer.

This also explains why screening and approval should be separately permissioned. Different permissions make role separation possible. The organization still decides how to assign them, but the workflow does not assume that running a screening confers authority to approve a legal classification.

Legal Status and Timing Must Stay Precise

Decision 33 was issued by the Prime Minister on 30 June 2026 and took effect on 15 August 2026. It is in force.

Issuance and effectiveness are separate events, and public content should not collapse them into one. A system screened against the appendix before 15 August 2026 was being measured against an instrument that had been promulgated but was not yet in force. After 15 August 2026, Decision 33 is in force. The applicable compliance timeline then depends on the system's deployment date and sector.

Records should preserve both the screening date and the applicable transition deadline so reviewers can establish which requirements applied at the time.

Decision 33 is also not a sanctions decree. It supplies the official national list of high-risk AI systems beneath the AI Law and Decree 142. Decree 142 provides implementing duties and official forms. Decision 33 provides the identification layer that informs which systems enter high-risk workflows.

The transition schedule also depends on the system and sector context. Existing systems in healthcare, education, and finance or banking that operated before 15 August 2026 have a listed transition date of 1 September 2027. Existing systems in the other listed sectors have a listed transition date of 1 March 2027. Systems put into operation within six months of 15 August 2026 also have a listed date of 1 March 2027.

Organizations should track the applicable date per system, not place every AI activity beneath one calendar reminder.

Govern Official AI Forms and Evidence

Decree 142 does not stop at abstract governance principles. Its appendices prescribe official AI forms covering areas including serious incidents, controlled testing and certain impact-assessment processes.

ComplianceOne can govern the evidence feeding those outputs: the system identity, approved classification, responsible owner, incident context, testing status, source evidence, approvals, version history and submission record.

The form is therefore not the entire compliance record. The defensible evidence package also shows how the organization reached the information contained in it.

A Seven-Part Production Governance Model

Production AI governance works best when seven records remain connected: registration, screening inputs, human classification, applicable obligations, operational ethics evidence, change history, and exportable review evidence.

Each exists for a reason. Registration establishes identity. Screening structures the question. Human classification records judgment. Obligations translate the decision into owned work. Ethics evidence shows how responsible-AI principles operate. Change history preserves context. Evidence export packages approved records for review.

1. Register the Deployment, Not Just the Model

The same underlying model can support very different uses. A language model used to draft internal meeting notes does not have the same context as one used to recommend a benefit decision. A vision model in quality assurance does not share the same impact profile as one used for wide-scale biometric identification in proceedings.

Registration should therefore describe the deployed system, provider, users, purpose, lifecycle stage, and operating context. Linking it to a broader systems inventory can help, but a fresh organization should not be prevented from registering AI simply because that inventory is incomplete.

The system record becomes the stable identity to which classifications, transparency notices, oversight interventions, complaints, testing evidence, training, incidents, and reassessments attach.

2. Screen Against Versioned Regulatory Content

The Decision 33 list should be maintained as regulatory content rather than written permanently into application logic. When the official list changes, organizations need a content update and a clear record of which earlier screenings used the previous version.

Versioning answers a critical audit question: was this classification reasonable against the list available at the time?

The screening should be reproducible. Given the same declared inputs and the same list version, it should produce the same proposal. That deterministic behavior is a strength. An unpredictable model-generated classification would make later reconstruction harder.

The system still does not determine whether a category applies. The operator declares that contextual input, and the human reviewer owns the classification.

3. Preserve the Medium-Risk Boundary

Decree 142 distinguishes high-, medium- and low-risk AI systems.

High-risk systems are identified through the official high-risk list and its applicability criteria. Medium-risk classification follows the separate conditions in Article 9 of Decree 142, including whether an AI system may cause users to mistake the nature of an interaction or AI-generated content, together with the exclusions specified in the decree.

ComplianceOne should therefore not infer medium risk merely because a system failed to match Decision 33.

Screening can structure the relevant facts and flag potential conditions. The provider or responsible organization remains accountable for the resulting classification.

A system that has not completed the organization's classification process should remain visibly unclassified, rather than silently defaulting to low risk.

4. Turn Approved Classification Into Owned Work

An approved high-risk classification should activate the relevant operating work, not end the process with a label.

ComplianceOne connects an approved classification to obligations drawn across the AI Law, Decree 142, and Decision 33. This matters because duties do not all live in one instrument. Human oversight, for example, cannot be reconstructed correctly by reading only the implementing decree.

The work is organized across six independently statused areas. Nothing begins as satisfied merely because the platform created a task. Teams must provide evidence and record progress for dossier, conformity readiness, transparency and labeling, monitoring, serious-incident readiness, and other applicable work.

This prevents a subtle governance failure: treating workflow creation as compliance. A generated obligation is a responsibility to address, not proof of completion.

Controlled-testing obligations require similar care. They are instantiated only when classification is approved while the system is in controlled testing. They do not disappear automatically when the system exits that setting. The operator records why each is no longer applicable where appropriate, preserving the exit decision instead of inferring it silently.

5. Make Ethics Evidence System-Specific

Circular 05 is active subordinate guidance, effective 10 March 2026. It adds an ethics and responsible-AI layer without replacing the parent AI Law, Decree 142 procedures, or Decision 33 classification work.

ComplianceOne operationalizes Circular 05 through eight evidence areas: applicability, human oversight, transparency, complaints, responsible testing, training, self-assessment and mapping to parent AI controls.

Circular 05's scope matters. It applies directly to state management agencies and organizations or individuals developing, providing, deploying or using AI for state management or public services. Other organizations with AI activity in Vietnam are encouraged to apply it. An ordinary private deployment should not acquire a direct Circular 05 duty merely because the framework is supported. Equivalent controls may still be required independently under the AI Law, Decree 142, Decision 33 or a sector rule.

These records should attach to the AI system they concern. A generic ethics policy can state principles, but it cannot show what happened when a person intervened in a particular system, which notice users received, how a complaint was remediated, or whether a testing safeguard was reviewed.

Circular 05 includes an authority-issued self-assessment guidance template in Appendix II, covering assessment criteria, supporting evidence, remediation actions, responsible owners and deadlines.

ComplianceOne can support this official structure alongside additional platform-prepared working records and evidence structures. These additional aids are not prescribed government forms.

Circular 05 is not a sanctions instrument, and using either the official template or platform-prepared aids does not guarantee compliance or authority acceptance.

6. Reassess When Context Changes

AI classification is not a permanent property of a model name. A change in purpose, deployment context, affected population, data, provider, lifecycle stage, or regulatory list can alter the inputs a reviewer needs to consider.

The register should make earlier decisions readable rather than overwrite them. Teams need to know what the operator declared, which list version applied, and why the reviewer approved the tier at that time.

Change triggers can include:

• A new or materially expanded use.
• Movement from testing into production.
• A change in sector or affected decision.
• New data categories or populations.
• A provider or material technical change.
• An amendment to the Decision 33 list.
• A serious incident, complaint pattern, or oversight finding.

Not every change requires a different tier. Every material change deserves a deliberate decision about whether reassessment is needed.

7. Export Decisions, Not Proposals

Evidence-pack export should require an approved classification. An unreviewed proposal should not be packaged in a way that reads like the organization's formal decision.

This boundary also supports permission discipline. Reading the register does not automatically grant authority to produce a formal evidence artifact. The organization can decide who may view systems, who may screen, who may approve, and who may assemble an export.

The resulting package should allow a reviewer to follow the classification inputs, list version, rationale, approval, obligations, and supporting evidence without mistaking platform logic for legal judgment.

An Automated Credit Decision in Production

Consider a bank using AI in an automated credit-granting workflow, one of the areas represented in Decision 33's banking categories.

The governance lead registers the deployed system, not merely its model. The record identifies its provider, purpose, lifecycle stage, affected decision, and relevant data context. The operator declares which Decision 33 category may apply and documents the rationale and applicability conditions.

Screening records the installed list version and produces a proposed tier. A named reviewer examines the real workflow, the potential for significant harm, relevant conditions, and any exclusion question. The reviewer then approves the classification and records a reason if the decision differs from the proposal.

If high risk is approved, the relevant operating work begins with a not-started state. Owners assemble dossier evidence, readiness material, transparency records, monitoring, oversight, and incident preparation. Circular 05 evidence can link the system's notices, human interventions, complaint handling, training, and self-assessment to those parent controls.

The result is not a platform declaring the credit system high risk. It is a bank recording how an accountable person reached and approved that conclusion against a particular version of the official list.

A Learning System That Remains Unclassified

Now consider an education provider that registers a system and completes screening, but the designated reviewer has not yet examined the result.

The temptation is to display the proposal as provisional classification or to treat a non-match as low risk. Both would turn incomplete governance into a substantive conclusion.

The honest state is unclassified.

That state can drive escalation and ownership without prejudging the answer. Leadership can see that a production system lacks approved classification. The governance lead can locate the pending review. An auditor can distinguish an operator proposal from an organizational decision.

Once the reviewer acts, the decision record captures the approved tier, time, identity, and rationale. Until then, no formal evidence pack should imply otherwise.

A System Leaving Controlled Testing

A third system was classified while operating in controlled testing. Its related obligations were created for that context. Later, the organization exits the testing program.

Automatically closing the obligations would erase the accountable transition. Instead, the operator reviews each item and records why it is no longer applicable or what follow-up remains necessary.

This may feel slower than a lifecycle toggle. It is better evidence. A later reviewer can see that someone considered the exit and documented its effect rather than relying on a background rule to rewrite the record.

What Leadership Should Demand From an AI Register

An executive dashboard should not reduce AI governance to counts of high, medium, and low systems. Those figures matter only if the decision process behind them is credible.

Leadership should ask:

1. Which production AI systems remain unclassified?
2. Which screenings used an older version of the high-risk list?
3. Where did reviewers depart from proposals, and are the reasons clear?
4. Which approved high-risk systems still have unstarted or unsupported obligations?
5. Which systems have current oversight, transparency, complaint, training, and self-assessment evidence?
6. Which material changes have triggered reassessment?
7. Can a formal evidence package be traced to an approved human decision?

These questions recognize that disagreement and incomplete work are not embarrassing data. They are governance states that need ownership.

I would be more concerned by a register in which every proposal was accepted instantly than by one that records reasoned overrides. Perfect agreement can signal that human review is ceremonial.

The Shift From AI Classification to Accountable Classification

Many AI governance programs focus on finding the right label. High risk, medium risk, or another category becomes the endpoint.

Production governance requires a different mindset. The label matters because it activates work, but the durable asset is the accountable decision around it: system context, declared categories, list version, proposal, reviewer, rationale, obligations, evidence, and change history.

Circular 05 adds depth by connecting ethics to operations. Human oversight becomes recorded interventions. Transparency becomes system-specific notices. Complaint handling becomes attributable remediation. Training and self-assessment become periodic evidence rather than statements of intent.

Decision 33 adds a national identification layer, but it does not remove judgment. The platform can structure the screening. It cannot accept responsibility for the classification.

That boundary is not a product limitation. It is what makes the evidence credible.

AI governance in production should make uncertainty visible, judgment attributable, and obligations operational. Register systems as they are deployed, screen against versioned regulatory content, preserve human review, and connect ethics evidence to the system it concerns.

To see how an AI System Register can support accountable classification and evidence without autonomous legal decision-making, explore AesirX ComplianceOne.

Ronni K. Gothard Christiansen
Technical Privacy Engineer and CEO, AesirX.io

AI Governance in Practice

See how ComplianceOne connects AI system registers, risk screening, human-approved classification, ethics, obligations and reassessment with accountable owners and supporting evidence.

Laws and instruments referenced

Law 134/2025/QH15 on Artificial Intelligence – Vietnam’s primary AI law and the parent framework for AI governance, risk classification and related obligations.

Decree 142/2026/NĐ-CP – Implements the AI Law, including risk-related requirements, procedures, official forms and conditions relevant to high-risk classification.

Decision 33/2026/QĐ-TTg – Establishes Vietnam’s official list of high-risk AI systems, covering 46 categories across six sectors; effective 15 August 2026.

Circular 05/2026/TT-BKHCN – AI ethics guidance covering human oversight, transparency, complaints, responsible testing, training and self-assessment; effective 10 March 2026.

Decision 1671/QĐ-TTg – Sets Vietnam’s national AI strategy to 2030, with a vision to 2045; included as strategy context rather than a classification or compliance obligation.

Law 91/2025/QH15 on Personal Data Protection and Decree 356/2025/NĐ-CP – Provide the personal-data protection framework relevant where AI systems process personal data.

Decision 778/QĐ-BCA – Supports procedures for personal-data protection compliance.

Data Law 60/2024/QH15 and Decree 165/2025/NĐ-CP – Provide the broader data-governance framework relevant to data used or processed in connection with AI systems.

Decision 20/2025/QĐ-TTg – Establishes the list used for important and core data classification.

Decree 169/2025/NĐ-CP, as amended by Decree 347/2026/NĐ-CP – Governs relevant data-product and data-service activities where the organization’s role and activities fall within scope.

Decree 314/2026/NĐ-CP – Provides the regulatory framework for data platforms and exchanges where applicable.

Cybersecurity Law 116/2025/QH15 and applicable implementing instruments – Provide the cybersecurity framework relevant to AI systems and their deployment environment.

Decree 330/2026/NĐ-CP – Provides cybersecurity and personal-data protection penalty provisions; it is not an AI risk-classification instrument.

Decree 102/2025/NĐ-CP – Provides healthcare-sector requirements relevant to AI deployments involving healthcare data or systems.

Decree 363/2026/NĐ-CP – Provides the data-sector enforcement framework; effective 11 November 2026.

Disclaimer

This article provides general operational and compliance information from a platform vendor and does not constitute legal, regulatory or other professional advice. Applicability depends on the organization, AI system, provider and operator roles, deployment context, affected individuals, data processing, risk classification, sector and jurisdiction. Organizations should confirm applicable requirements with qualified Vietnamese legal and compliance professionals.

Frequently Asked Questions About AI Governance in Production