Vietnam Digital Technology Industry Law: AI Evidence Boundaries
Vietnam Law 71/2025/QH15 took effect on January 1, 2026 and introduced a national framework for digital technology, including risk-based AI provisions. This guide maps its AI governance duties to accountable owners and shows where identity-bound request evidence can support monitoring without replacing disclosure, labeling, human oversight, or product governance.

Vietnam's National Assembly enacted Law 71/2025/QH15 on June 14, 2025. The official record says the Digital Technology Industry Law took effect on January 1, 2026. Its AI provisions use a risk-based structure and assign duties around transparency and data governance, with monitoring and cybersecurity under continuing human control.
A gateway record can support part of that evidence for managed LLM traffic. It cannot become the whole compliance file. I would delete any control map that gives one proxy ownership of product classification and user notices, or labeling and human oversight alongside runtime enforcement.
TL;DR
- Vietnam Law 71/2025/QH15 has applied since January 1, 2026.
- High-risk and large-impact AI governance requires evidence owned by product and legal teams, with security and operating teams.
- Identity-bound LLM request records can support route monitoring and control, plus incident reconstruction for managed HTTP traffic.
- Disclosure and labeling, plus system classification and human authority, need evidence outside the gateway for off-route activity.
Law 71/2025/QH15 creates a national AI framework
The official Government document record identifies Law 71/2025/QH15 as the Digital Technology Industry Law. It records enactment on June 14, 2025, effect from January 1, 2026, issuance by the National Assembly, and signature by Trần Thanh Mẫn. The signed law is attached to that record.
The Government's passage announcement reports that 441 of 445 voting delegates approved the law, a 92.26% vote. It describes a human-centered approach with transparency and safety, plus nondiscrimination and continuing human control. It also describes risk groupings that include high-risk and large-impact systems, plus systems outside the high-risk class.
For an enterprise using LLMs, the first artifact should be a Vietnam applicability and system-classification record. Name the legal entity and product, market and intended use, affected people, and deployment owner with the classification rationale. Add runtime logs after those ownership facts are recorded.
Articles 41, 43, and 45 need different owners
The signed law's AI provisions cover development principles and risk management, along with responsibilities for relevant systems. A practical implementation should avoid placing every duty under the security team. Legal and product owners should interpret scope and classification. Data governance owns approved data uses and quality records. Security owns threat treatment and incident response. The operating team owns deployment configuration, monitoring, and change control.
Create one owner-to-evidence register for each AI system. Include the applicable provision and accountable owner, required artifact, and review date with the evidence location. For high-risk or large-impact use, attach the classification analysis and approval. Link the data inventory and model and provider register, validation results and human-oversight design, monitoring plan and incident route, and change history.
On a 47-row spreadsheet, the dangerous column is the one labeled "covered by platform." Replace it with the named system and control owner. A model provider's documentation can support the file, but the deploying enterprise still needs evidence for its own use and data, users and configuration, and decisions. The AI governance framework provides the wider operating structure for that register.
Transparency and labeling sit with the product experience
Article 44's disclosure and labeling duties concern what users are told and how AI-related products or outputs are presented. Those are legal and product/user-experience responsibilities. Keep the approved notice text and placement, language version and display condition, and release identifier with the accessibility review. For generated content that requires labeling, preserve the rule and the release test that proves the label appears in the relevant channel.
A model request log can identify the system and route that produced an output. It can also retain the policy decision and time. The record cannot prove that a notice appeared on a user's screen, that the label survived export, or that a downstream application displayed it. Capture those facts in application telemetry and release evidence.
The same boundary applies to human control. The gateway can require an application-supplied use-case and role before an LLM call. The application must still present the result to the right reviewer and preserve that person's actual decision.
Data governance starts before the prompt
The law's AI framework includes data-governance responsibilities. Build the evidence from the source system forward. Record each dataset or business record used by the application, pairing its owner with the lawful basis, its quality checks with the classification, its approved purpose with the retention rule, and its permitted model destinations. Then define the transformation that selects fields for the prompt.
At runtime, evaluate the prompt against that approved contract. A customer-support route may allow a ticket body after account numbers and authentication secrets are removed. A legal-review route may require a different provider and retention setting. The policy should bind the authenticated identity and role to the use case and prompt classification, plus the model destination and current approval.
Per-route AI policies can turn that design into a deterministic decision. A blocked request should carry a reason code such as unapproved destination or missing identity context, prohibited data class, or expired system approval. The data inventory and legal analysis are outside the gateway, while the event records how the approved rule handled one request.
Monitoring evidence needs independent decision records
Monitoring for a high-risk or large-impact system should join several records. Product monitoring covers output quality, performance against the intended use, and user reports. Security monitoring covers abuse and data exposure, plus unauthorized routes and policy failures. Incident management owns severity and investigation, containment and notification analysis, and corrective action. Change management tracks revisions to providers, models, prompts, data, and policy.
For managed LLM traffic, a per-decision event should include the user or workload identity supplied by the application and the role, use-case identifier and route, model destination and data classification, policy version and permit or redact or deny outcome, and timestamp with the reason. Preserve a stable correlation identifier so investigators can join the request decision to product and incident records.
This avoids the self-attestation problem described in the AI audit-log chain-of-custody guide. The application should not have sole custody of the only evidence about its own model call. Independence still has a boundary: the request record cannot observe a local model or a personal browser session. It also cannot observe a vendor capability whose model traffic never enters the managed path.
The implementation file needs explicit exclusions
Every system record should state what the control set leaves outside scope. For a stateless HTTP gateway, exclusions include model training and model-weight custody, local execution and user-interface notices, and downstream publication with final business decisions. Direct provider calls and hidden vendor integrations also need separate controls or an integration change that brings the traffic onto the managed route.
For a specific authenticated analyst who sent classified text to an approved model under policy version 23, the gateway record can establish the route and policy outcome. Application evidence must establish whether the product displayed the required Vietnamese notice before the user acted. The legal and product file controls the system's classification under Law 71/2025/QH15.
Run a route test for each approved model destination and a display test for every disclosure and label. Exercise the human-review workflow with a rejected output. Reconcile the product inventory against network and provider billing records to find routes that bypass the expected control.
DeepInspect
DeepInspect can enforce selected controls on authenticated HTTP traffic between users or agents and LLM endpoints when applications deliberately route that traffic through it. Policies can evaluate application-supplied identity and role with data classification, plus the approved use case and model destination. Each permit, redact, or deny decision creates an independent record tied to the policy version and timestamp.
Use those records for route approval, data-policy testing, monitoring, and incident reconstruction under the enterprise's Law 71/2025 control map. Keep system classification, notices, labels, human authority, training governance, and final product decisions with their accountable owners. Hidden vendor traffic requires evidence from its own control point.
Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- When did Vietnam Law 71/2025/QH15 take effect?
The official Government record lists June 14, 2025 as the enactment date and January 1, 2026 as the effective date. The National Assembly issued the law, and the attached signed text is the controlling primary record. Organizations should preserve the version and translation used for their legal analysis. They should also track implementing rules and official guidance because the law delegates detail to the Government. Counsel should confirm applicability and classification for each product rather than applying one generic conclusion to every AI capability.
- Does the law require the same controls for every AI system?
The Government passage announcement describes a risk-based framework with high-risk and large-impact systems, plus other systems. Control depth should follow the system's legal classification and intended use, plus affected people and the operating context for the data. Keep a written classification rationale and approval. Revisit it when the product purpose and model, market and autonomy, or data changes. A low-risk internal assistant and a system influencing access to a consequential service should not share an unlabeled template with identical evidence.
- Can an AI gateway satisfy Vietnam's transparency duties?
A gateway can produce evidence about authenticated HTTP model traffic deliberately routed through it. It can show the destination and data classification, active policy and outcome, and time. Transparency duties involving user notices and AI disclosure operate in the product experience. Content labeling does too. The application must present and test them. Use the gateway event as supporting provenance when appropriate, then keep screenshots and release tests, plus notice versions and display telemetry with the product owner.
- What should a high-risk AI evidence register contain?
Start with system identity and intended use, legal entity and market, and owner with the classification rationale. Add the data inventory and provider and model versions, validation and testing records with the human-oversight design, approved routes and monitoring measures, and the incident process with user disclosures, labeling rules, and change history. For managed model calls, attach or reference per-decision events through stable identifiers. Store sensitive prompt content only under an approved purpose and retention design.
- What happens when an application bypasses the managed route?
Detect bypass through network controls, provider account restrictions, cloud configuration, billing reconciliation, and application review. Treat an unapproved direct call as a control failure with an owner and remediation date. The incident record should identify affected data and provider behavior. Restoring the approved route improves future enforcement, but it does not recreate evidence for calls that already bypassed it.