Vietnam AI adoption now runs in a different order from every other ASEAN country, because the Law on Artificial Intelligence took effect on 1 March 2026. Vietnam is the only country in the region where a comprehensive AI law arrived before the market matured. If you run your Vietnam site the way you would run Thailand or the rest of ASEAN — pilot first, scale what works, add governance afterwards — you will stall at the scaling phase. This article sets out the three gates that manufacturers with Vietnamese operations always hit, and puts a concrete number on the workload difference between handling them in parallel and handling them late.
Vietnam AI adoption follows a different sequence from its neighbours
Vietnamese companies are among the most active adopters of AI in Southeast Asia. A Deloitte survey found that 93% of Vietnamese companies say they have adopted or are considering AI. That figure gets quoted widely in regional media, but reading it as “93% have deployed AI” is wrong. In the same survey, only 13.8% have reached deployment at scale. The 93% is a wide-scope number that includes companies still at the evaluation stage; the 13.8% is a narrow-scope number limited to companies that have moved past limited operation into full-scale rollout. So many organisations are moving, yet fewer than one in seven has reached scale. That gap is an accurate description of what is happening in Vietnam right now.
The supporting figures point the same way. Only 36.5% of companies have a documented AI strategy. 55% name talent shortage as their single biggest constraint. In manufacturing, 21% of companies are actively looking for AI solutions. In other words there is plenty of appetite and plenty of individual experimentation, but strategy documents and skilled people have not kept pace, so most organisations are stuck at pilot or limited-operation stage.
| Indicator | Figure | Scope |
|---|---|---|
| Adopted or considering AI | 93% | Includes the evaluation stage. Widest scope |
| Reached deployment at scale | 13.8% | Companies past limited operation and into full rollout |
| Has a documented AI strategy | 36.5% | Presence of a strategy document |
| Named talent shortage as a constraint | 55% | The most frequently cited constraint |
| Manufacturers seeking AI solutions | 21% | Manufacturing only |
Japanese-owned operations in the country are just as motivated. Around 2,400 Japanese companies operate in Vietnam, and roughly 26% of them are manufacturers. 56.1% of Japanese-affiliated companies in Vietnam say they will expand their business over the next one to two years, the highest rate anywhere in ASEAN. At the same time, 62.0% cite rising labour costs as a risk in the investment environment. A decree promulgated in November 2025 raised regional minimum wages by an average of roughly 7% from 1 January 2026. In the north, large investments by Chinese, Korean and Taiwanese companies have intensified competition for skilled staff. When you want to expand but cannot add headcount, turning to AI to reduce headcount requirements is the natural move.
On top of that plateau, the legal framework landed in 2026. On 10 December 2025 the National Assembly passed the Law on Artificial Intelligence (Law No. 134/2025/QH15, Luật Trí tuệ nhân tạo), and it took effect on 1 March 2026. The Vietnam AI law is the first standalone AI statute in ASEAN, and for now it is the only piece of comprehensive ASEAN AI regulation actually in force. The structure is compact — 8 chapters and 35 articles — with much of the detail delegated to government decrees. A draft decree was published in February 2026.
What matters here is less the content of the law than the sequence. Rather than finalising every detail before commencement, Vietnam stood the law up first and is filling in the decrees and registers afterwards. Manufacturing sites in Vietnam therefore find themselves being asked to classify and notify their AI systems under a law already in force, while they are still stacking up pilots. A law arriving ahead of the market, at a point where 93% are moving but only 13.8% have scaled — that is the situation unique to Vietnam.
Why running the PoC first is harder to sustain in Vietnam than anywhere else
The AI law includes transitional provisions for AI systems that were already operating before commencement. Healthcare, education and finance get 18 months; every other sector gets 12 months. With a commencement date of 1 March 2026, the deadlines work out as follows.
| Sector | Transitional period | Compliance deadline |
|---|---|---|
| Healthcare, education, finance | 18 months | 1 September 2027 |
| All other sectors, including manufacturing | 12 months | 1 March 2027 |
A manufacturing plant falls, as a rule, into the “all other sectors” row. That means your deadline is 1 March 2027. Counting back from the day you are reading this, that is not a generous runway. And a transitional period does not mean “you may do nothing until it expires” — it means “bring yourself into compliance within it.” Start at the last minute and you will be modifying systems that are already live.
The rework that late starters incur falls into three groups.
First, vendor enquiries drag contract renegotiation in with them. If you are using SaaS or external APIs with AI functionality, you need to know whether that vendor has completed its own notification as a provider in Vietnam, and if not, what obligation lands on you instead. Before deployment, this is simply one more selection criterion you ask about. After go-live, an unsatisfactory answer forces you into contract revision or a switching evaluation.
Second, reflecting transparency requirements in the user interface pulls regression testing along with it. The AI law requires that users be notified they are interacting with AI, and that AI-generated content — audio, images, video — be disclosed. These requirements are calibrated to risk and context, but where they apply you will be changing screen displays and output markings. Built in at design time this is a few hours of work; retrofitted onto a production system it means impact analysis and a full test cycle.
Third, the decision on whether to suspend a running system becomes a management matter. If classification puts a system in the medium-risk band and you discover the pre-deployment notification was never filed, someone has to decide whether to shut it down until the notification is submitted or keep it running while you file. That call cannot be made on the shop floor; it needs a decision-making body. Committee time is the hardest thing to see on a workload sheet, and in practice it consumes the most elapsed time.
None of these three would have happened if classification had been completed at the pilot stage. That is exactly why Vietnam AI compliance work — inventory, risk classification and pre-deployment notification — has to run in parallel with your pilots rather than behind them. Changing nothing but the order changes the workload — that is the argument of this article, and the model calculation later on puts a number on it.
Gate 1 — Your role changes project by project
The first gate is determining which role you occupy. The AI law splits the parties involved with an AI system into developer, provider and deployer roles, and assigns obligations accordingly. The structure puts the classification duty on the party that provides the system, before use begins.
Where most Japanese-owned sites trip up is deciding this at company level — “we only use vendor tools, so we are a deployer.” Your role is not fixed at company level. It is determined project by project. Within the same plant, it is entirely normal to be a plain deployer on one project and a provider on the next.
The moment that needs the most care is when you build a RAG system or a chatbot in house. Even if all you are doing is calling a commercial LLM API, once you feed it your own documents, build your own interface, and put it in front of your own employees or business partners, you are the one providing that combination. The foundation model vendor is providing an API, nothing more; you are the party deciding who uses that AI system and how. Get this line wrong and you will run a system in production without realising the notification duty sits with you.
The Vietnamese AI law also has extraterritorial reach. It covers “Vietnamese and foreign organisations and individuals involved in AI-related activities within Vietnam.” A system developed by your Japanese head office and rolled out to the Vietnam plant is in scope. So is a cloud service running in a Singapore region, if the activity touches Vietnam. Treating this as “a local-entity matter only” is a dangerous simplification.
Determining your role across six typical plant scenarios
Here are six patterns that come up constantly in practice, with the likely role and the point that decides it.
| Scenario | Likely role | What decides it |
|---|---|---|
| Buying and using a commercial visual-inspection AI unit | Deployer | The equipment maker is the provider. Confirm its notification status in the contract |
| Employees using a commercial generative AI service for work | Deployer | The service provider notifies. Control the use cases through your usage policy |
| Building an in-house RAG chatbot over internal documents | Provider | You are providing it to users. Classification and notification are yours |
| Head office develops an AI tool and distributes it to the Vietnam plant | Provider at group level | Extraterritorial scope applies. Decide whether HQ or the local entity notifies |
| Commissioning a Vietnamese software house to build AI for you | The commissioning party is usually the provider | The contractor is the developer. Whose name it is provided under decides it |
| Letting business partners use AI you developed yourself | Provider and developer | External provision widens the transparency requirements that apply |
This determination is not a one-off exercise. More use cases means more projects, and every project needs its own assessment. That is precisely why building the assessment template while you still have few projects is the cheaper path. For structuring how employees are allowed to use generative AI, see our guide on building a generative AI usage policy. Adding a single column to that policy for “who is the provider for this use case” makes the later inventory dramatically easier.
Gate 2 — Risk classification follows the use case, not the product
The second gate is risk classification. The Vietnamese AI law uses three tiers — high, medium and low. The classification criterion is “potential impact on human life, health and legitimate rights and interests, on the public interest, and on social order,” with the detail set out in government decrees.

The most commonly misunderstood thing about these three tiers is the unit of classification. Classification attaches to the use case, not the product. The same LLM used to summarise internal meeting minutes and used to power an external multilingual chatbot lands in different tiers. Organise your records at product level — “we use vendor A’s LLM, therefore low risk” — and your justification documents collapse the moment a new use case appears. In an audit or a regulator enquiry, the painful failure is not getting the classification wrong; it is being unable to explain how you arrived at it.
Obligations become substantially heavier in the high-risk tier. Lifecycle risk management and safety assurance, human oversight, retention of technical documentation and records, conformity with applicable standards, and a conformity assessment under the competent authority’s rules are all added. Once conformity assessment is in play, the response no longer fits inside internal paperwork; you need a plan that assumes external involvement.
For the medium tier, the draft decree published in February 2026 gives example triggers: failing to make AI interaction explicit, deepfakes and synthetic media, and generating content that manipulates trust. For the high tier, the construct is that a system qualifies if it appears on the high-risk AI register maintained by the Prime Minister. Because it is a register, its contents will be updated over time. Design the format of your justification documents on the assumption that classification is not settled once and for all.
Classifying ten typical plant use cases
Below are the manufacturing AI use cases in Vietnam that come up most often on plant floors, with a first-pass classification based on information available today. Final classification has to follow the decrees and the register, but this gives you the axes to think along.
| Use case | Likely classification | The deciding axis |
|---|---|---|
| Image judgement for visual inspection, internal process only | Low | Impact stays inside your own process. Little direct effect on people |
| Equipment anomaly detection and predictive maintenance | Low | Operation assumes a human confirms the judgement |
| Summarising and translating internal documents | Low | Output users are limited to internal staff |
| Production planning support | Low | A human makes the final decision |
| External-facing multilingual chatbot | Medium | Interacts with external users. Disclosure is required |
| AI-generated promotional images and video | Medium | Can fall under AI-generated content disclosure |
| Facial recognition for site access control | Medium to high | Biometric data and impact on rights and interests. Overlaps the PDPL |
| Safety cameras detecting hazardous behaviour | Medium to high | May constitute worker monitoring. Operational design changes the answer |
| Screening support in recruitment | Tends to be high | Direct impact on individual rights and interests |
| Mechanical feed into attendance and performance evaluation | Tends to be high | Can translate directly into employment disadvantage |
Read the table and a pattern emerges: inspection, maintenance and planning — the core of plant operations — cluster in the low tier, while classification rises the closer a use case gets to people. The practical conclusion is simple. Start your pilots with low-risk use cases, and settle classification and governance before you touch the people-facing ones. That ordering alone caps the number of medium-and-above projects you must clear before the transitional deadline.
Which services you choose also changes whether the provider-side notification burden lands on you. For the underlying platform decision, our comparison of enterprise generative AI services sets out the selection criteria. For a Vietnam site, add one more criterion to the usual list — how much of the provider role in Vietnam the vendor is willing to carry.
Gate 3 — Notification is not approval, but the justification stays with you
The third gate is pre-deployment notification. Medium-risk and high-risk AI systems must be notified to the competent authority before they go live, through the national AI information system, the AI one-stop electronic portal.

The notification covers provider information, system identification, your self-classification, and risk mitigation measures. The point to hold on to is that this is not an approval procedure. You are not waiting for a licence before you can operate; you are being entered into a database by filing. That distinction matters enormously in practice, and it means you do not need to worry about deployments stalling in a review queue.
But “not approval” does not mean “less burden.” Under an approval regime, the authority passes judgement on whether your classification is sound. Under a notification regime, responsibility for the classification stays with you from beginning to end. What you filed — above all the self-classification and its reasoning — is retained as your own documentation and can be questioned later. Which is why building the justification after the fact is the worst value for money in this whole exercise. A few lines written the moment you decide on the use case will take a fraction of the time it costs to reconstruct the reasoning from memory a year later.
Notification is not a one-time event either. Any change that shifts the risk level triggers reclassification. Swapping out the training data, opening an internal-only use case to external users, feeding results through without human confirmation — each of these is a reclassification trigger. Adding one line to your change management procedure asking “does this change move the risk level” is enough to stop reclassifications being missed.
Post-deployment, incident reporting applies. High-risk systems must be reported within 48 hours of confirmation, medium-risk within 72 hours. That clock evaporates once a reporting line through Japanese head office is involved. If local fact-finding and internal escalation consume a full day of the 48, you have one day left. Decide who drafts the report and who approves it before an incident happens, not after.
Setting the medium and high obligations side by side gives the following picture. The high-risk column reflects what the AI law states explicitly as additional obligations; the medium-risk column reflects what the law leaves to the decrees.
| Item | Medium risk | High risk |
|---|---|---|
| Pre-deployment notification | Required | Required |
| Nature of the notification | Registration, not approval | Registration, not approval |
| Conformity assessment | Not specified in the law, left to decrees | Required under the competent authority’s rules |
| Human oversight | Not specified in the law, left to decrees | Explicitly required |
| Technical documentation and records | Not specified in the law, left to decrees | Retained across the full lifecycle |
| Incident reporting deadline | Within 72 hours of confirmation | Within 48 hours of confirmation |
Reading “not specified” in the medium column as “nothing to do” is premature. Since the notification itself requires you to state a self-classification and your risk mitigation measures, you will need the underlying records regardless. Even if the formality demanded is lighter than at high risk, keeping the classification rationale is the practical minimum at medium risk too.
As for penalties, the AI law itself does not specify them; they are left to subsequent regulations. Reading an undetermined amount as “we can wait and see” is a risky call. Locking in your design before the penalty levels are set is far more reliable than reacting once you see them.
Double exposure with the PDPL — the other foundation that changed on 1 January 2026
Two months before the AI law, Vietnam also replaced the foundation for personal data protection. The Personal Data Protection Law (PDPL) 91/2025/QH15, passed on 26 June 2025, and its implementing decree 356/2025/ND-CP of 31 December 2025 both took effect on 1 January 2026, and the previous decree 13/2023/ND-CP ceased to have effect. Alignment was also made with the Data Law 60/2024/QH15, which had already been in force since 1 July 2025. On top of that, the amended Law on Intellectual Property 131/2025/QH15 took effect on 1 April 2026, adding questions about AI training, IP asset formation and platform liability.

The new framework puts concrete shape on the composition and submission of impact assessment dossiers, cross-border transfer procedures, and how to structure your data protection function. Translated into plant reality, it means every point at which AI touches personal data needs an impact assessment. And those points overlap almost exactly with the use cases that push you up the AI law’s risk tiers.
| Typical plant use case | Personal data touched | Position under the AI law |
|---|---|---|
| Facial recognition for site access control | Biometric data | Medium to high. State the classification rationale explicitly |
| Safety cameras detecting hazardous behaviour | Employees captured on video | Medium to high. Limit the purpose and scope of monitoring |
| Screening support in recruitment | Applicant history and attributes | Tends to be high. Human oversight required |
| Anomaly detection over attendance data | Working hours and location | Depends on use. Feeding into evaluation raises the tier |
| Conversation logs from an external chatbot | Customer enquiry content | Medium. Check the cross-border transfer treatment too |
There is a way to make all of this lighter. AI law classification and PDPL impact assessment can start from the same use-case inventory. Build one list of “which business process, which data, which AI, and for whom” and you can derive both your AI law classification rationale and your PDPL impact assessments from it. Run them separately — AI law compliance in one department, PDPL compliance in another, on different templates — and you will conduct the same interviews twice. Where the Vietnam site has IT and administration as separate functions, deciding on this integration up front is worth a great deal.
Cross-border transfer ties directly into AI use as well. Sending personal data collected in Vietnam to a head-office system in Japan or to an AI service in an overseas region is a cross-border transfer. With generative AI services, it is common for organisations not to know which region actually processes their data. Include fields for processing location and data flow in the use-case inventory from the start.
Model calculation — At a 400-person site, running late costs about 1.8 times the effort
Now translate all of the above into hours. What follows is not a real engagement but a model calculation built on conditions typical of a Japanese-owned plant in Vietnam. The assumptions are stated so you can substitute your own.
The assumptions are these. Site headcount is 400. There are 12 use cases either in use or under consideration. The breakdown is 10 low risk, 2 medium risk (an external multilingual chatbot and AI-generated promotional imagery), and 0 high risk. One person-day is counted as 8 hours.
The standard work per use case breaks into five tasks. (1) Inventory and description of the use case. (2) Risk classification and drafting the justification. (3) Enquiring with the vendor about notification status. (4) Medium risk only, filing the notification through the portal. (5) Medium risk only, reflecting AI interaction disclosure and content disclosure in the UI. Tasks 1 to 3 apply to all 12 use cases; tasks 4 and 5 apply only to the 2 medium-risk cases.
First, Scenario B — working in parallel, preparing everything before go-live.
| Task | Cases | Per case | Subtotal |
|---|---|---|---|
| (1) Inventory and description | 12 | 2 hours | 24 hours |
| (2) Risk classification and justification | 12 | 4 hours | 48 hours |
| (3) Vendor notification-status enquiry | 12 | 3 hours | 36 hours |
| (4) Filing notification through the portal | 2 | 6 hours | 12 hours |
| (5) Interaction and content disclosure in the UI | 2 | 8 hours | 16 hours |
That is 12 cases x (2 + 4 + 3) = 108 hours, plus 2 medium-risk cases x (6 + 8) = 28 hours, for a total of 136 hours = 17 person-days. Because the work runs in parallel with the pilots, task 2 is written immediately after the use case is decided and task 5 is folded into the first screen design. That is why the per-case hours stay small.
Next, Scenario A — running late, starting just before the transitional deadline. Three things change. Task 3 goes from 3 hours to 8 because contract renegotiation gets pulled in. Task 5 goes from 8 hours to 20 because it becomes a retrofit onto a live production UI and needs regression testing. And 20 hours is added for the decision-making body that has to rule on whether to suspend the 2 running medium-risk systems.
| Task | Cases | Per case | Subtotal |
|---|---|---|---|
| (1) Inventory and description | 12 | 2 hours | 24 hours |
| (2) Risk classification and justification | 12 | 4 hours | 48 hours |
| (3) Vendor enquiry including contract renegotiation | 12 | 8 hours | 96 hours |
| (4) Filing notification through the portal | 2 | 6 hours | 12 hours |
| (5) Retrofit onto live UI plus regression testing | 2 | 20 hours | 40 hours |
| Decision body ruling on suspension | One-off | 20 hours | 20 hours |
That is 12 cases x (2 + 4 + 8) = 168 hours, plus 2 medium-risk cases x (6 + 20) = 52 hours, plus 20 hours of committee time, for a total of 240 hours = 30 person-days.
The difference is 104 hours = 13 person-days, a ratio of roughly 1.8 times. Clearing the same 12 use cases to the same standard costs 13 extra person-days purely because of when you started. At a site with only a handful of IT staff, 13 person-days is heavy enough to stop another project outright. And with 56.1% of Japanese-affiliated companies in Vietnam planning to expand over the next one to two years while 62.0% flag rising labour costs as a risk, hiring your way through those 13 person-days is not a realistic option.
Two cautions on how to read this calculation. First, a single high-risk use case adds conformity assessment and pushes you outside the model entirely. If your site has people-facing use cases, treat these numbers as a floor. Second, we have not converted this into money. Hourly rates at a Vietnam site vary enormously with grade and with how much Japanese expatriate time is involved, so no defensible rate can be set. Argue in hours and apply your own actual rates.
Knowing the sensitivity to the assumptions makes this easier to explain internally. If medium-risk cases rise from 2 to 4, Scenario B goes from 28 hours to 56 and Scenario A from 52 hours to 104. In other words, the more medium-risk use cases you have, the bigger the payoff from working in parallel. Conversely, at a site where everything stays low risk, the difference shrinks to task 3 alone and the ratio narrows. Estimating how many medium-risk use cases you are likely to end up with is the decisive variable.
Can you carry the same design from your Thailand site into Vietnam?
This is the most common question from companies with sites in both countries. The short answer is that you cannot simply hand the same policy to both, because the two regimes are at different stages of maturity.
The Thailand AI Act is still a draft and is not yet in force. On 2 July 2026 the ETDA published a revised draft and opened a public consultation of around 30 days. The draft uses three categories — prohibited, high risk, and general use. Thailand does have sector-specific rules touching AI, but no comprehensive AI law has been enacted. Vietnam’s law, by contrast, is already in force, with pre-deployment notification biting in practice. Our article on AI implementation in Thailand covers the Thai situation and how to approach AI there.
The classification frameworks do not line up either. Vietnam runs high, medium and low; the Thai draft runs prohibited, high risk and general use. Same number of tiers, different content, so you cannot mechanically map results from one to the other. Working out where a Vietnamese medium-risk classification lands under the Thai draft is a mapping exercise to do once the draft is finalised.
The layers you can standardise and the layers you must split by site
That said, you do not have to build everything twice. Split the design into layers and a good deal can be shared.
| Layer | Treatment | Reason |
|---|---|---|
| Use-case inventory template | Standardise | The questions are the same regardless of country. Consolidation gets easier too |
| Information handling classes, confidentiality | Standardise | An internal standard, independent of jurisdiction |
| Prohibited use list | Standardise | Aligning to the strictest country keeps it backward compatible |
| Risk classification definitions and thresholds | Split by site | Vietnam has three tiers, the Thai draft has a different three |
| Notification and filing procedures | Split by site | Vietnam uses portal notification, Thailand is undecided |
| Incident reporting deadlines and recipients | Split by site | Vietnam is fixed at 48 hours and 72 hours |
| Personal data handling and cross-border transfer | Split by site | Vietnam is specified under the PDPL. Thailand is a separate jurisdiction to check on its own |
This split has a secondary benefit. Lock the shared layer down first and, when the Thailand AI Act is enacted, the only additions are the classification definitions and the procedures. Build a policy from scratch per country and every legislative change means rewriting the whole document. For the general approach to deploying the same mechanism across multiple sites — the wider context around any overseas plant generative AI rollout — see our guide to rolling out systems to overseas plants, which helps if you want the AI work to move in step with your other rollout projects.
A 90-day sequence for AI implementation in Vietnam
Finally, here is the order of work if you are starting now, laid out over 90 days. Even counting back from the 1 March 2027 deadline, building the foundation in 90 days and spending the remainder on implementation is the realistic shape.
The first 30 days are for inventory, and nothing else. Interview the shop floor and list every AI use case, in production and under consideration. Two things get missed most often here: AI features bundled inside SaaS that individual departments contracted for themselves, and generative AI that employees use on personal accounts. You can find the first through accounts payable records and the second through network access logs. At the same time, make a provisional determination of who the provider is for each use case, and flag whether it touches personal data. This one list becomes the shared entry point for both AI law and PDPL compliance.
Days 31 to 60 are classification and decisions. Assign high, medium or low to each use case on the list and write a few lines of rationale for each. For anything at medium or above, decide whether to proceed as is, narrow the use case to bring it down to low risk, or stop it for now. That middle option — narrowing the use case to lower the classification — is routinely overlooked, and there are real cases where restricting an external-facing tool to internal use alone transforms the burden. In parallel, start the vendor enquiries. Responses take time, so the earlier you begin, the better.
Days 61 to 90 are notification and implementation. Prepare portal notifications for everything at medium risk or above and file them before go-live. Build the transparency requirements into the design of screen displays and output markings. Document the incident reporting flow — who confirms, who drafts, who approves, and how it goes out within 48 or 72 hours. Finally, leave behind a checklist so the same sequence can be run whenever a new use case appears.
| Period | Main work | Definition of done |
|---|---|---|
| Days 1 to 30 | Use-case inventory, provisional provider determination, personal data flags | Every use case fits on a single sheet |
| Days 31 to 60 | Risk classification and rationale, proceed / narrow / stop decisions, vendor enquiries | The count of medium-and-above cases is fixed |
| Days 61 to 90 | Portal notification, transparency implementation, incident flow documentation | No live medium-risk system is un-notified |
The thing to keep in mind across these 90 days is not to halt AI implementation itself. Low-risk use cases can proceed without waiting out the first 30 days. The only things that need to stop are use cases likely to be medium risk or above where notification has not been filed. The faster you make that separation, the less shop-floor activity you have to freeze.
Frequently asked questions
Where should we start with AI implementation in Vietnam?
With the use-case inventory. Before selecting tools or building an organisation, list what you are already using AI for. Without that list, classification and notification cannot start and you cannot produce PDPL impact assessments either. With it, classification takes a few hours per use case to get a first read. The inventory cannot be completed by the IT function alone, so book time with manufacturing, quality, HR and sales from the outset.
Does the Vietnamese AI law only apply to the local entity?
No. The extraterritorial scope of the AI law covers “Vietnamese and foreign organisations and individuals involved in AI-related activities within Vietnam.” A system developed by Japanese head office and distributed to the Vietnam plant is in scope, as is a cloud service running in an overseas region but used from Vietnam. You need to decide, project by project, which group entity files the notification.
If we outsource AI development to a Vietnamese company, who carries the notification duty?
As a rule, the party providing the AI system carries the classification and notification duty. Even where the contractor is the developer, if the finished system is put in front of your employees or customers under your name, you are the provider. Adding a clause requiring the contractor to supply the technical information needed to build the classification rationale will save you work later. Do not assume that outsourcing development transfers the obligation.
Is there a cost benchmark for AI implementation in Vietnam?
This article does not give a monetary benchmark. Hourly rates at a Vietnam site vary too much by grade and by the degree of Japanese expatriate involvement for a single defensible rate to be set. We give hours instead. In a model calculation with stated assumptions, handling 12 use cases in parallel takes 136 hours = 17 person-days, handling them late takes 240 hours = 30 person-days, a difference of 104 hours = 13 person-days. Apply your own actual rates to those hours. A high-risk use case adds conformity assessment and pushes you beyond this range.
Can we reuse our Thailand generative AI usage policy as is?
Not as is. Thailand’s AI law is not yet in force. The ETDA published a revised draft on 2 July 2026 and opened a public consultation of around 30 days. The classification frameworks differ too: Vietnam uses three tiers of high, medium and low, while the Thai draft uses prohibited, high risk and general use, and the content does not match. You can standardise the use-case inventory template, the information handling classes and the prohibited use list. Split the classification definitions, the notification procedures and the incident reporting deadlines by site.
Summary
Vietnam AI adoption changed sequence relative to the rest of ASEAN the moment AI Law 134/2025/QH15 took effect on 1 March 2026. What makes Vietnam distinctive is that the law arrived at a stage where 93% of companies had adopted or were considering AI while only 13.8% had reached deployment at scale. For manufacturing, the transitional deadline is 1 March 2027. Run inventory, risk classification and pre-deployment notification in parallel with your pilots and a model calculation puts the work at 17 person-days; leave it late and the same work becomes 30 person-days, roughly 1.8 times. There are three gates — your role changes project by project, classification follows the use case rather than the product, and because notification is not approval the responsibility for the justification stays with you. The PDPL under 91/2025/QH15 and 356/2025/ND-CP layers on top of all of it, but the entry point, the use-case inventory, can be shared between them.
We are happy to talk at the stage where the discussion is still internal, whether that is AI implementation at your Vietnam site or how to separate policy between Vietnam and Thailand. Show us your use-case inventory once and we can give you a read on which items are likely to fall into medium risk and what sequence keeps the workload down. It is perfectly fine if you have not yet decided whether to proceed at all. Get in touch through our contact page.
References
- Vietnam enacts its first Law on Artificial Intelligence (VILAF)
- Responding to Vietnam’s AI Law (TMI Global Consulting)
- Law No. 134/2025/QH15 on Artificial Intelligence (LuatVietnam)
- Commentary on Vietnam’s AI Law (One Asia Lawyers)
- Vietnam’s personal data protection framework (EY Japan)
- Thailand’s draft AI law (Norton Rose Fulbright)
- Vietnam AI market update (B-Company)
- Trends among Japanese companies in Vietnam (Career Link Asia)