Vietnam AI Adoption 2026 — AI Law RFP and 90-Day PoC

Vietnam AI adoption in 2026 should start with an RFP connecting use, risk, data, human control, change and evidence—not a product comparison. This guide turns current official sources into procurement controls and a proposed 90-day PoC whose gates extend beyond accuracy.

Executive answer — put eight items into one RFP before product selection

The first deliverable should not be a feature matrix. Build an “AI use-case and control register” in which every row connects these eight items:

1. Use-case inventory: whose decision or task is supported, with which input and output.
2. AI Law risk classification: whether the system is classified high, medium or low risk, why, and by whom.
3. Decision 33 applicability: who obtained legal confirmation of possible inclusion in the high-risk list.
4. Personal data and cross-border flow: how inputs, logs, evaluation data, storage, access, subprocessors and overseas transfers work.
5. Provider/deployer boundary: who owns the model, application, operation, decision and incident response.
6. Human-in-command: where a person reviews, intervenes, rejects and stops the system.
7. Reclassification after change: who reassesses a changed purpose, dataset, model, integration or user population.
8. Evidence and exit: how the parties prove versions, approvals, logs, stop, rollback, data return/deletion and migration.

These are not eight independent checklists. For one use case, classification influences human intervention; intervention determines screens, permissions and logs; the data flow determines contract clauses and PoC tests. If departments keep separate spreadsheets, the chain breaks during contracting. The RFP row should persist as the identifier for acceptance tests, operating procedures, change requests and incident records.

Translating Vietnam’s 2026 AI framework into procurement controls

Vietnam’s AI Law 134/2025/QH15 was issued on 10 December 2025 and took effect on 1 March 2026. The official government overview of implementing Decree 142/2026/NĐ-CP describes high-, medium- and low-risk classification and provider self-classification before use. Article 13 of the official Decree 142 text concerns conformity reassessment of a high-risk system after major changes such as a purpose or integration change. It should not be generalized into a statutory requirement to redo risk classification for every system; the broader classification-impact review in this article is a proposed purchaser change-control practice.

Decision 33/2026/QĐ-TTg, issued on 30 June 2026 and effective on 15 August 2026, concerns the high-risk list. This article does not enumerate listed categories because the supplied primary-source ledger does not verify the detailed list. Instead, document the candidate activity, users, decision impact, input data and use of outputs so qualified Vietnam counsel can check the current text and practice.

The Ministry of Science and Technology’s English summary of Circular 05/2026/TT-BKHCN describes an ethics framework in which human oversight and intervention should reflect system impact. The procurement question is therefore not whether a proposal says “human-in-the-loop.” It is who can see what, within what time, under which authority, and which result that person can stop.

For personal data, Decree 356/2025/NĐ-CP was issued on 31 December 2025 and took effect on 1 January 2026. Together with Personal Data Law 91/2025/QH15, it is a reason to map prompts and business inputs, conversation and action logs, evaluation data, attachments, user identifiers, foreign model APIs and remote support before signature. Specific legal duties depend on the use case, parties and data. This article is not legal advice; confirm the current texts and their application with internal legal, privacy and security teams and qualified Vietnam counsel.

The new national strategy shifts AI from experiments to organizational capability

Decision 1671/QĐ-TTg was issued on 28 August 2026 and replaces Decision 127/QĐ-TTg. The government explanation dated 4 September 2026 frames AI as a core capability spanning problem definition, design, organization and operations, supported by talent, infrastructure, data foundations, institutions and governance.

For a company, this means that distributing a chat interface is not an AI operating model. The organization must choose use cases from business problems, prepare operational data, assign accountability and stop authority, and sustain improvement after launch. On 1 September 2026, the Ministry of Science and Technology reported that Qualcomm proposed cooperation and expressed an intention to make Vietnam one of its future AI hubs. This was a proposal and stated intention—not completed investment or a government guarantee. Procurement teams should not turn policy news into an assumed demand forecast, subsidy commitment or vendor assurance.

Use-case inventory — break “adopt AI” into decision units

Do not begin the first workshop with product names. Inventory the decisions and tasks that cause operational friction at this level:

“Maintenance AI,” for example, is not one use case. Manual search, similar-failure retrieval, inspection-summary generation, spare-parts recommendation and shutdown-decision support have different inputs and impacts. A system need not control equipment directly to have material impact if technicians rely on its recommendation. Conversely, a translation assistant may look harmless but still require data analysis if customer or employee information is sent to an external API.

The inventory should preserve the decision “do not use AI yet.” A use case can be held when it lacks reference answers, an accountable owner, a safe stop, sufficient input quality, or any advantage over existing rules. Fewer verifiable cases make vendor responses more comparable.

Do not outsource AI Law risk classification to the vendor

Even where the official Decree 142 overview describes provider self-classification before use, a deployer should not merely file the vendor’s answer. The provider’s intended use may differ from the factory’s actual use. Require at least:

• Classification, decision date, covered version, intended uses and excluded uses.
• Assumptions concerning input, output, users, integration and human oversight.
• The party that checked Decision 33 and the legal version used.
• Effects of customer configuration, fine-tuning, RAG, API integration and purpose change.
• A procedure to detect, notify and assess conditions that may change classification.
• Notice when a model provider, cloud service or subprocessor changes.

The deployer should attach its own use-case card. Align whether classification covers a model alone or the application and business integration. Do not infer that a business process is low risk merely because an underlying model is described that way. Qualified experts should confirm legal conclusions, while the project can still implement evidence preparation, version control and change detection.

Map personal data and cross-border flows before contract signature

For generative AI, reviewing training data alone is insufficient. Trace inputs, search indexes, embeddings, prompts, outputs, feedback, evaluation datasets, monitoring logs, incident copies and backups. Build a data-flow register with these columns:

Do not decide from the phrase “servers in Vietnam.” A model API, monitoring service, support console, log analytics, backup or identity platform may create additional flows. Nor should the mere existence of a cross-border flow predetermine the answer; legal and security teams assess the data, purpose, parties, contract and safeguards.

Evaluation data is often missed. When PoC reviewers label answers good or bad, the record may preserve the original question, source document, employee name or customer detail. Include it in the same register before sharing it with an evaluation SaaS or overseas vendor.

Define provider/deployer boundaries with verbs, not broad RACI labels

A responsibility chart that says “vendor: system; customer: operations” will fail during an incident. For each verb, assign execution, approval, notification and evidence retention.

Where model provider, application vendor, cloud, integrator, local subsidiary and headquarters are distinct, split responsibilities by service layer. Confirm that contractual ownership matches the authority available on the factory shift. Naming a stop owner in a document is not a control if nobody on night shift can exercise the stop.

Turn human-in-command into screens, permissions and response times

Human oversight is not complete when a procedure says “the final decision is human.” If a reviewer merely rubber-stamps a large volume of opaque output, intervention is not meaningful. Define six capabilities for each use case:

1. Visibility: show sources, output, limitations, evidence, model/configuration version and warnings.
2. Comprehension: use a language and operational vocabulary the local user understands.
3. Rejection: grant authority to reject, correct, hold or escalate.
4. Stop: decide what users, supervisors, IT and management can disable.
5. Fallback: return to paper, an existing screen or human judgment after stop.
6. Learning: use rejection reasons for improvement without unrestricted reuse of sensitive data.

Time matters in manufacturing. Equipment-anomaly advice and a monthly-report summary have different response windows. Specify review deadline, handling after timeout and safe behavior on non-response. If an output progresses toward automatic execution, test the state change before and after approval and identify the last reversible point.

Make the Vietnam AI development RFP scoreable

A strong RFP lets teams compare answers on one basis and reuse them in the PoC. The following weights are a proposed example; adapt them to company risk appetite.

Define disqualifying conditions as well as scores. Proposed examples include an inability to disclose customer-data reuse conditions, no customer-controlled stop, an unidentified classification version, or inaccessible customer audit logs. They are purchaser controls, not universal statutory requirements.

Do not accept a yes/no response. Distinguish standard capability, configuration, custom development, third-party dependency and roadmap. Require assumptions, limits, owner, evidence and change impact. Give the vendor a demo script using representative data plus missing fields, contradictions, unauthorized access, suspected prompt injection, confidential content and out-of-scope questions.

For general selection criteria, see our Generative AI Tool Selection Guide 2026. For headquarters and subsidiary roles, see the Generative AI Roadmap for Overseas Subsidiaries. The delivery-artifact perspective in our AI Development Outsourcing Guide for Thailand can also be adapted; this article specifically adds Vietnam’s 2026 framework and acceptance evidence.

Proposed 90-day PoC — make more than accuracy an acceptance gate

The timeline below is illustrative. Adapt it to legal review, data readiness and the factory calendar. The objective is not production by day 90. It is an evidence-based choice among continue, continue with conditions, redesign and stop.

Days 0–20: fix the use, classification and data contract

Finalize the use-case card, current workflow, error effects, users and data flow. Obtain the provider’s classification record and prepare facts for qualified counsel to assess Decision 33 applicability. Legal/privacy owners confirm how Personal Data Law 91/2025/QH15 and Decree 356/2025/NĐ-CP apply, determine what data may enter the PoC, and approve masking, access, retention, cross-border flow and deletion.

An illustrative gate is: the use, version and user population are uniquely identified; no unexplained data path remains; and business, IT, legal/privacy and security decision owners are assigned. If not, reduce the scope rather than rushing to connect the model.

Days 21–45: test quality, refusal, authorization and leakage resistance

Build a fixed evaluation set containing representative cases, hard cases, missing and contradictory inputs, stale documents and out-of-scope questions. Measure not only correct answers but also whether the system refuses when it should, states when evidence is absent, avoids unauthorized documents and does not expose another user’s history.

Set thresholds by use case. Proposed absolute conditions might require zero critical confidentiality exposure or privilege crossover, mandatory approval by a named role for material decisions, and no automatic execution of an unsupported answer. A high average score cannot offset failure of an absolute gate.

Days 46–70: test intervention, stop, failure and reclassification

Ask local users to interpret evidence, warnings, versions and rejection controls in Vietnamese or the required operating language. Inject model API delay and outage, missing logs, identity failure, bad configuration and data-refresh failure, then switch to the fallback process.

Test changes one by one: add a new RAG document set; expand the purpose to another process; change the model version; connect output to an ERP/MES update candidate; or extend users to a contractor. Where classification or data flow may be affected, prove that a change request triggers reclassification review and blocks production deployment until approval.

Days 71–90: prove exit, rollback and committee acceptance

Inventory settings, prompts, evaluation datasets, logs, users, integrations and residual data. Stop the service, return to the prior procedure, reconcile open work, export required assets and exercise the contractual deletion path. Rollback means more than restoring a backup: determine how far a business process that acted on AI output can be reversed.

Use four illustrative decisions: limited production, conditional extension, redesign or stop. Business owner, local management, IT, security and legal/privacy—not the sales team—review the evidence pack and record owners and deadlines for open items.

What belongs in the acceptance evidence pack

Acceptance needs more than meeting minutes. A later reviewer must reconstruct which version, use and evidence a named approver considered.

1. Traceability between use-case ID, requirement ID, test ID, risk and data fields.
2. Provider classification, deployer use-case card, Decision 33 fact submission and expert response.
3. Versions of model, application, prompt, RAG, filters, permissions and integrations.
4. Evaluation-set provenance, sensitivity, expected and actual results, evaluator and variance reason.
5. Normal, refusal, hold, unauthorized, leakage-prevention and human-intervention records.
6. Change request, reclassification review, approval, deployment, retest and rollback history.
7. Detection, stop, communication, fallback, restoration, reconciliation and restart approval.
8. Evidence for storage, access, cross-border flow, evaluation use, return and deletion of sensitive data.
9. Contract versions and notices for vendor, cloud, model provider and subprocessors.
10. Open risks, interim measures, due dates, owners and residual-risk acceptance.

Timestamp and version each artifact. Screenshots may not show the full setting or alteration history, so combine configuration exports, audit logs, test results and approval workflow. Because logs can themselves contain personal or confidential data, preserve evidence under controlled access.

Make reclassification a production change gate

AI does not remain as deployed. Models, prompts, RAG documents, APIs, users, languages, purposes, downstream systems and provider subprocessors change. A normal IT change process may overlook the effect on classification and data flows.

Require each change request to answer:

• Does intended use, user population, affected person or use of output change?
• Is new personal data, confidential data, image, audio, log or evaluation data involved?
• Does storage, cross-border transfer, subcontracting or model reuse change?
• Does human review, stop authority, fallback or response time change?
• Could an existing classification assumption or Decision 33 review be affected?
• Which evaluation set and absolute acceptance conditions must be rerun?
• Which version is the rollback target, and how will open work be reconciled?

UI edits and changes of purpose need not follow identical approval routes. Predetermine triggers that automatically involve legal, privacy and security teams. Do not say that an automatic model update is “not a change.” Contract for advance notice, visible versions, regression testing and a stop window.

Common failures in an AI adoption approach

Leaving legal review until just before signature

After product selection, changing data routes and responsibility is expensive. Prepare the use-case card and flow diagram before the RFP so experts can assess concrete facts.

Reusing the vendor’s classification for the whole process

A model-level assumption may not match the integrated factory use. Manage classification subject, version, purpose, users and integration together.

Passing the PoC on average accuracy

An average can hide confidentiality exposure, privilege crossover, unsafe confidence and an inability to stop. Make refusal, authorization, leakage, intervention, reclassification and exit independent gates.

Reducing human-in-the-loop to an approval button

Approval becomes ceremonial if the user lacks evidence, time or authority. Test visibility, comprehension, rejection, stop, fallback and escalation during local shifts.

Using only clean PoC data

Production contains stale documents, contradictions, mixed Vietnamese and English, permission differences and variable image quality. Use protected production-representative data and hard cases.

Waiting until renewal to define exit

Test whether data, prompts, evaluation sets, embeddings, logs and settings can be exported; how deletion is evidenced; and whether operations can return to a fallback.

Expanding the controls to AI use across Southeast Asia

When extending the system from Vietnam to Thailand, Singapore or Indonesia, do not copy only the interface and language. Reassess use, classification, personal data, cross-border flow, labor context, contract and local support for each country, entity and process. What can be standardized is the structure of use-case IDs, evaluation-set governance, change triggers, evidence packs and stop exercises.

Headquarters should own comparable minimum controls rather than centralizing every approval. The local entity owns actual use, users, language, operational impact and fallback; headquarters supports common vendor contracts, security, audit and cross-country learning. A global checklist cannot replace provider classification and qualified local legal assessment.

Execution checklist

Before issuing the RFP

• [ ] Break use cases into decision units and name business, data, system and risk owners.
• [ ] Prepare facts needed to review the AI Law, Decree 142 and Decision 33.
• [ ] Map input, logs, evaluation, support, backup, cross-border flow and exit.
• [ ] Divide provider, deployer, cloud, integrator, headquarters and local duties by verb.
• [ ] Define what people see, reject, stop, fall back to and escalate.
• [ ] Define reclassification triggers and an owner for expert confirmation.

Before starting the PoC

• [ ] Fix the classified product, model, application and configuration version.
• [ ] Approve evaluation provenance, expected outputs, sensitivity and access.
• [ ] Add refusal, authorization, leakage, intervention, failure and exit gates to accuracy.
• [ ] Provide local-language screens, warnings, training and contact paths.
• [ ] Be able to stop the PoC and recover data and accounts after failure.

Before production approval

• [ ] Trace requirement, version, test and approval through the evidence pack.
• [ ] Record severity, interim action, owner, due date and residual-risk acceptance for open items.
• [ ] Connect change requests to reclassification, data, security and regression testing.
• [ ] Prove stop, fallback and rollback for provider outage, contract exit and model change.
• [ ] Obtain qualified Vietnam review of current texts and the concrete use case.

Conclusion — Vietnam AI adoption is decided by evidence designed before purchase

For AI adoption in Vietnam, do not leave current regulation as an after-the-fact checklist. Connect the use case, classification, Decision 33 review, personal and cross-border data, responsibility boundary, human intervention, reclassification after change, evidence and exit in one RFP. A 90-day PoC is only an illustrative format, but the principle endures: gate production on refusal, authorization, leakage, human intervention, reclassification triggers, stop and rollback as well as accuracy. Qualified Vietnam counsel should confirm legal conclusions; the company should continuously maintain the facts and operating evidence behind those conclusions.

If you are still shaping use cases, an AI RFP or acceptance gates for a Vietnam factory or subsidiary, contact TOMAS TECH. We can begin by mapping the business, data and control boundaries before a product is selected.

FAQ — Where should Vietnam AI development start?

Start with the use-case inventory, not product selection. Record users, inputs, outputs, decision impact, error impact, data flow and stop route. That creates the facts needed for provider classification, qualified legal review and comparable vendor responses.

FAQ — How should headquarters and a local entity divide overseas generative AI adoption?

Headquarters can provide common security, contracting, evaluation and evidence structures. The local entity should own actual use, users, language, operational impact and fallback. Do not replace Vietnam-specific legal assessment with a global standard.

FAQ — Can the same controls support AI use across Southeast Asia?

Use-case IDs, evaluation governance, change triggers and evidence packs can be standardized. Classification, personal data, cross-border flow, contracts, labor context and local operations must be reassessed by country, entity and use case.

FAQ — Is a 90-day PoC mandatory in an AI adoption approach?

No. The 90-day plan in this article is a proposed example. What matters is predefining gates for accuracy, refusal, authorization, leakage, intervention, reclassification, failure and exit. A simple low-risk case may be shorter; complex data and integrations may require longer.

Important notice

This article organizes primary sources checked as of 7 September 2026 for AI procurement and implementation management. It is not legal advice. Ask qualified Vietnam counsel and internal legal, privacy and security specialists to confirm original texts, scope, requirements, transitional treatment and current regulatory practice. RFP weights, disqualifying conditions, the 90-day sequence and acceptance values are all proposed examples.

References

• Government of Vietnam, Law 134/2025/QH15, issued 10 December 2025, effective 1 March 2026.
• Government Media, official overview of Decree 142/2026/NĐ-CP (three levels and provider classification before use).
• Government of Vietnam, official text of Decree 142/2026/NĐ-CP, Article 13 (high-risk system conformity reassessment after a major purpose or integration change).
• Official Gazette, Decision 33/2026/QĐ-TTg, issued 30 June 2026, effective 15 August 2026.
• Ministry of Science and Technology, Ethical framework for artificial intelligence established, summary of Circular 05/2026/TT-BKHCN.
• Official Gazette, Decree 356/2025/NĐ-CP page, issued 31 December 2025, effective 1 January 2026.
• Government of Vietnam, Decision 1671/QĐ-TTg, issued 28 August 2026.
• Government News, explanation of the new national AI strategy, 4 September 2026.
• Ministry of Science and Technology, Qualcomm proposes AI and semiconductor partnership with Viet Nam, 1 September 2026.