Triển khai AI tại Việt Nam 2026｜RFP theo Luật AI và PoC 90 ngày

Triển khai AI tại Việt Nam năm 2026 nên bắt đầu bằng RFP nối use case, rủi ro, dữ liệu, quyền kiểm soát của con người, thay đổi và bằng chứng, thay vì bảng so sánh sản phẩm. Bài viết chuyển nguồn chính thức thành điều kiện mua sắm và PoC 90 ngày đề xuất với các cổng vượt ngoài độ chính xác.

Kết luận trước｜Đưa 8 nội dung vào một RFP trước khi chọn sản phẩm

Sản phẩm bàn giao đầu tiên không nên là ma trận tính năng. Hãy lập “sổ đăng ký trường hợp sử dụng và kiểm soát AI”, trong đó mỗi dòng nối 8 nội dung:

1. Danh mục trường hợp sử dụng: hỗ trợ quyết định hay công việc của ai, với input và output nào.
2. Phân loại rủi ro theo Luật AI: high, medium hay low; lý do và người quyết định.
3. Kiểm tra Decision 33: ai đã nhận xác nhận pháp lý về khả năng thuộc danh mục rủi ro cao.
4. Dữ liệu cá nhân và luồng xuyên biên giới: input, log, dữ liệu đánh giá, lưu trữ, truy cập, nhà thầu phụ và chuyển ra nước ngoài vận hành thế nào.
5. Ranh giới provider/deployer: ai chịu trách nhiệm về mô hình, ứng dụng, vận hành, quyết định và sự cố.
6. Human-in-command: con người xem xét, can thiệp, từ chối và dừng hệ thống ở đâu.
7. Phân loại lại khi thay đổi: ai đánh giá lại mục đích, dữ liệu, mô hình, tích hợp hoặc nhóm người dùng mới.
8. Bằng chứng và lối thoát: chứng minh phiên bản, phê duyệt, log, dừng, rollback, hoàn trả/xóa dữ liệu và chuyển nhà cung cấp ra sao.

Đây không phải tám checklist độc lập. Với một use case, phân loại quyết định cách con người can thiệp; cách can thiệp quyết định màn hình, quyền và log; data flow quyết định điều khoản hợp đồng và bài test PoC. Nếu các phòng ban quản lý Excel riêng, chuỗi này sẽ đứt ở giai đoạn hợp đồng. ID của một dòng RFP phải tiếp tục được dùng trong acceptance test, quy trình vận hành, change request và incident record.

Chuyển khung AI Việt Nam năm 2026 thành điều kiện mua sắm

Luật Trí tuệ nhân tạo 134/2025/QH15 được ban hành ngày 10/12/2025 và có hiệu lực ngày 01/03/2026. Bản giới thiệu chính thức về Nghị định 142/2026/NĐ-CP mô tả phân loại high, medium, low và provider tự phân loại trước khi sử dụng. Điều 13 của toàn văn Nghị định 142 đề cập việc đánh giá lại sự phù hợp của hệ thống rủi ro cao sau thay đổi lớn như thay đổi mục đích hoặc tích hợp. Không nên khái quát điều này thành nghĩa vụ pháp luật phải phân loại rủi ro lại cho mọi hệ thống; việc rà soát tác động đến classification trong bài là đề xuất change control của bên mua.

Quyết định 33/2026/QĐ-TTg, ban hành ngày 30/06/2026 và có hiệu lực ngày 15/08/2026, liên quan đến danh mục rủi ro cao. Bài viết không liệt kê các nhóm trong danh mục vì sổ nguồn được cung cấp chưa xác minh chi tiết đó. Thay vào đó, hãy ghi rõ hoạt động, người dùng, ảnh hưởng đến quyết định, dữ liệu đầu vào và cách dùng đầu ra để chuyên gia pháp lý đủ năng lực tại Việt Nam kiểm tra văn bản và thực tiễn mới nhất.

Bản tóm tắt tiếng Anh của Bộ Khoa học và Công nghệ về Thông tư 05/2026/TT-BKHCN mô tả khung đạo đức yêu cầu giám sát và can thiệp của con người tương ứng với tác động của hệ thống. Vì vậy, câu hỏi mua sắm không phải chỉ là hồ sơ có cụm từ human-in-the-loop hay không, mà là ai được thấy gì, trong thời gian nào, có quyền gì và có thể dừng kết quả nào.

Về dữ liệu cá nhân, Nghị định 356/2025/NĐ-CP được ban hành ngày 31/12/2025 và có hiệu lực ngày 01/01/2026. Khi xem cùng Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15, doanh nghiệp nên lập bản đồ prompt và input nghiệp vụ, log hội thoại/thao tác, dữ liệu đánh giá, tài liệu đính kèm, mã người dùng, API mô hình ở nước ngoài và hỗ trợ từ xa trước khi ký. Nghĩa vụ cụ thể phụ thuộc use case, các bên và dữ liệu. Bài viết không phải tư vấn pháp lý; cần để pháp chế, quyền riêng tư, an ninh nội bộ và chuyên gia Việt Nam kiểm tra nguyên văn và cách áp dụng.

Chiến lược quốc gia mới chuyển AI từ thử nghiệm thành năng lực tổ chức

Quyết định 1671/QĐ-TTg được ban hành ngày 28/08/2026 và thay thế Quyết định 127/QĐ-TTg. Giải thích của Chính phủ ngày 04/09/2026 đặt AI như năng lực cốt lõi từ xác định vấn đề, thiết kế, tổ chức đến vận hành, với trọng tâm vào nhân lực, hạ tầng, nền tảng dữ liệu, thể chế và governance.

Đối với doanh nghiệp, chỉ phát giao diện chat chưa phải operating model. Cần chọn use case từ vấn đề kinh doanh, chuẩn bị dữ liệu vận hành, chỉ định trách nhiệm và quyền dừng, đồng thời cải tiến sau khi triển khai. Ngày 01/09/2026, Bộ KH&CN đưa tin Qualcomm đề xuất hợp tác và bày tỏ ý định đưa Việt Nam thành một trong các AI hub tương lai. Đây là đề xuất và ý định, không phải khoản đầu tư đã hoàn tất hay bảo đảm của Chính phủ. Không nên biến tin chính sách thành cam kết nhu cầu, trợ cấp hoặc bảo chứng vendor.

Use-case inventory｜Tách “đưa AI vào” thành đơn vị quyết định

Workshop đầu tiên không nên bắt đầu bằng tên sản phẩm. Hãy kiểm kê các quyết định và công việc đang vướng ở mức sau:

“AI bảo trì” không phải một use case duy nhất. Tìm sổ tay, tìm sự cố tương tự, tóm tắt kiểm tra, đề xuất phụ tùng và hỗ trợ quyết định dừng máy có input và ảnh hưởng khác nhau. Dù không điều khiển máy trực tiếp, khuyến nghị sai vẫn có thể tác động lớn nếu kỹ thuật viên dùng để quyết định. Ngược lại, trợ lý dịch thuật tưởng như đơn giản vẫn cần phân tích data flow nếu gửi dữ liệu khách hàng hoặc nhân viên ra API ngoài.

Danh mục cũng nên giữ quyết định “chưa dùng AI”. Nếu không có đáp án tham chiếu, không có owner, không dừng được, dữ liệu đầu vào quá kém hoặc luật nghiệp vụ hiện tại đã đủ thì nên tạm hoãn trước khi đánh giá sản phẩm. Ít use case nhưng kiểm chứng được sẽ giúp so sánh vendor tốt hơn.

Không giao toàn bộ việc phân loại rủi ro cho vendor

Dù tóm tắt Nghị định 142 mô tả provider self-classification trước khi dùng, deployer không nên chỉ lưu câu trả lời của vendor. Intended use của provider có thể khác thực tế trong nhà máy. RFP cần yêu cầu tối thiểu:

• Kết quả phân loại, ngày quyết định, phiên bản, intended use và excluded use.
• Giả định về input, output, người dùng, tích hợp và human oversight.
• Chủ thể kiểm Decision 33 và phiên bản pháp luật sử dụng.
• Ảnh hưởng của configuration, fine-tuning, RAG, API và đổi mục đích.
• Quy trình phát hiện, thông báo và đánh giá yếu tố có thể đổi phân loại.
• Thông báo khi model provider, cloud hoặc subprocessor thay đổi.

Deployer phải đính kèm use-case card của mình. Cần thống nhất phân loại bao phủ mô hình riêng hay cả ứng dụng và tích hợp nghiệp vụ. Không suy diễn quy trình là low risk chỉ vì mô hình nền được mô tả như vậy. Chuyên gia xác nhận kết luận pháp lý; dự án triển khai chuẩn bị bằng chứng, version control và change detection.

Vẽ dữ liệu cá nhân và luồng xuyên biên giới trước hợp đồng

Với Generative AI, chỉ rà training data là chưa đủ. Phải theo input, search index, embedding, prompt, output, feedback, evaluation data, monitoring log, bản sao điều tra sự cố và backup. Lập data-flow register:

Không quyết định chỉ từ câu “server tại Việt Nam”. Model API, monitoring, support console, log analytics, backup hoặc identity platform có thể tạo thêm flow. Cũng không nên quyết định chỉ vì có cross-border flow; pháp chế và security phải đánh giá dữ liệu, mục đích, các bên, hợp đồng và biện pháp.

Dữ liệu đánh giá thường bị bỏ sót. Khi người chấm PoC gắn nhãn câu trả lời tốt/xấu, bản ghi có thể chứa câu hỏi gốc, tài liệu nguồn, tên nhân viên hoặc dữ liệu khách hàng. Hãy đưa vào cùng sổ trước khi chia sẻ với evaluation SaaS hay vendor nước ngoài.

Viết ranh giới provider/deployer bằng động từ

Bảng chỉ ghi “vendor: hệ thống; khách hàng: vận hành” sẽ thất bại khi có sự cố. Với từng động từ, phân người thực hiện, duyệt, thông báo và giữ bằng chứng.

Nếu model provider, app vendor, cloud, integrator, pháp nhân Việt Nam và trụ sở là các bên khác nhau, tách theo service layer. Kiểm tra trách nhiệm hợp đồng có khớp quyền thao tác trong ca nhà máy không. Ghi tên người phụ trách dừng không phải control nếu ca đêm không có quyền dừng.

Biến human-in-command thành màn hình, quyền và thời gian

Quy định “quyết định cuối cùng thuộc con người” chưa đủ. Nếu người duyệt chỉ bấm approve hàng loạt output khó hiểu, việc can thiệp không có ý nghĩa. Định nghĩa sáu năng lực cho từng use case:

1. Nhìn thấy: hiển thị nguồn, output, giới hạn, bằng chứng, phiên bản model/config và cảnh báo.
2. Hiểu: dùng ngôn ngữ và thuật ngữ nghiệp vụ người địa phương hiểu.
3. Từ chối: có quyền reject, sửa, hold hoặc escalate.
4. Dừng: xác định user, supervisor, IT và management dừng được phần nào.
5. Thay thế: trở lại giấy, màn hình cũ hoặc phán đoán người sau khi dừng.
6. Học: dùng lý do từ chối để cải tiến nhưng không reuse dữ liệu nhạy cảm vô hạn.

Thời gian rất quan trọng trong sản xuất. Tư vấn bất thường thiết bị và tóm tắt báo cáo tháng có deadline khác nhau. Phải chỉ rõ thời hạn review, cách xử lý timeout và safe behavior khi không phản hồi. Nếu output tiến đến tự động thực hiện, hãy test trạng thái trước/sau duyệt và điểm cuối còn đảo ngược được.

Làm RFP phát triển AI tại Việt Nam có thể chấm điểm

RFP tốt giúp so sánh câu trả lời trên một cơ sở và tái dùng trong PoC. Trọng số dưới đây là đề xuất minh họa, cần chỉnh theo risk appetite.

Đặt cả điều kiện loại. Ví dụ đề xuất gồm: không thể nói rõ điều kiện reuse dữ liệu khách hàng; khách hàng không có quyền stop; không xác định được phiên bản đã phân loại; hoặc khách hàng không lấy được audit log. Đây là control mua sắm minh họa, không phải nghĩa vụ pháp luật áp dụng chung.

Không chấp nhận câu yes/no. Tách standard, configuration, custom development, third party và roadmap; yêu cầu giả định, giới hạn, owner, bằng chứng, ảnh hưởng khi đổi. Demo phải dùng dữ liệu đại diện cùng trường thiếu, mâu thuẫn, truy cập trái quyền, nghi ngờ prompt injection, dữ liệu mật và câu hỏi ngoài phạm vi.

Để xây tiêu chí so sánh sản phẩm, xem Hướng dẫn lựa chọn công cụ Generative AI 2026. Vai trò trụ sở và công ty con được trình bày trong Lộ trình áp dụng Generative AI tại chi nhánh nước ngoài. Góc nhìn về sản phẩm bàn giao khi thuê ngoài có thể tham khảo Hướng dẫn thuê phát triển AI tại Thái Lan; bài này bổ sung riêng khung Việt Nam 2026 và bằng chứng nghiệm thu.

PoC 90 ngày đề xuất｜Đặt cổng nghiệm thu ngoài độ chính xác

Tiến độ sau là ví dụ. Hãy chỉnh theo legal review, data readiness và lịch nhà máy. Mục tiêu không phải production đúng ngày 90, mà là quyết định bằng chứng: tiếp tục, tiếp tục có điều kiện, thiết kế lại hoặc dừng.

Ngày 0–20: cố định use, classification và data contract

Chốt use-case card, current flow, hậu quả lỗi, người dùng và data flow. Nhận classification record từ provider và chuẩn bị dữ kiện để chuyên gia kiểm Decision 33. Chủ pháp chế/quyền riêng tư xác nhận cách áp dụng Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15 và Nghị định 356/2025/NĐ-CP, quyết định dữ liệu vào PoC và duyệt masking, access, retention, cross-border, deletion.

Gate minh họa: use, version và user population được xác định duy nhất; không còn data path chưa giải thích; có người quyết định về business, IT, legal/privacy, security. Nếu chưa đạt, thu hẹp phạm vi thay vì vội kết nối model.

Ngày 21–45: test chất lượng, từ chối, phân quyền và chống rò rỉ

Tạo fixed evaluation set gồm trường hợp đại diện, trường hợp khó, input thiếu/mâu thuẫn, tài liệu cũ và câu hỏi ngoài phạm vi. Đo không chỉ câu đúng mà cả khả năng từ chối đúng lúc, nói rõ khi thiếu căn cứ, không tìm tài liệu vượt quyền và không lộ lịch sử người dùng khác.

Đặt ngưỡng theo use case. Absolute condition minh họa có thể yêu cầu critical confidentiality exposure và privilege crossover bằng 0; quyết định quan trọng luôn qua role chỉ định; câu trả lời thiếu căn cứ không chuyển sang tự động. Điểm trung bình cao không bù được việc hỏng absolute gate.

Ngày 46–70: test can thiệp, dừng, sự cố và phân loại lại

Để người dùng địa phương xác nhận bằng chứng, cảnh báo, phiên bản và nút reject dễ hiểu bằng tiếng Việt hoặc ngôn ngữ vận hành. Tiêm model API trễ/mất, log thiếu, lỗi identity, cấu hình sai và data refresh hỏng, rồi chuyển sang fallback.

Test từng thay đổi: thêm bộ tài liệu RAG; mở rộng mục đích sang công đoạn khác; đổi model version; kết nối output với ứng viên cập nhật ERP/MES; mở người dùng cho nhà thầu. Nếu có thể ảnh hưởng classification hoặc data flow, chứng minh change request kích hoạt reclassification review và chặn production trước khi được duyệt.

Ngày 71–90: chứng minh exit, rollback và nghiệm thu hội đồng

Kiểm kê setting, prompt, evaluation set, log, user, integration và dữ liệu còn lại. Dừng service, trở về quy trình cũ, reconcile việc dở, export tài sản cần thiết và diễn tập xóa theo hợp đồng. Rollback không chỉ là restore backup; phải biết quy trình nghiệp vụ đã hành động theo AI output có thể lùi đến đâu.

Sử dụng bốn quyết định minh họa: limited production, conditional extension, redesign hoặc stop. Chủ nghiệp vụ, quản lý địa phương, IT, an ninh và pháp chế/quyền riêng tư—chứ không phải đội bán hàng—đọc evidence pack và ghi owner/deadline cho điểm mở.

Những gì phải có trong acceptance evidence pack

Nghiệm thu cần nhiều hơn biên bản họp. Người kiểm tra sau này phải dựng lại được ai đã duyệt use/version nào dựa trên bằng chứng gì.

1. Traceability giữa use-case ID, requirement ID, test ID, risk và data field.
2. Provider classification, deployer use-case card, bộ dữ kiện kiểm Decision 33 và trả lời chuyên gia.
3. Version của model, app, prompt, RAG, filter, permission và integration.
4. Nguồn gốc, độ nhạy, kỳ vọng/thực tế, evaluator và lý do chênh của evaluation set.
5. Bằng chứng normal, refusal, hold, unauthorized, leakage prevention và human intervention.
6. Lịch sử change request, reclassification review, approval, deploy, retest, rollback.
7. Detection, stop, communication, fallback, restore, reconciliation, restart approval.
8. Bằng chứng lưu, truy cập, cross-border, dùng đánh giá, hoàn trả và xóa dữ liệu nhạy cảm.
9. Version hợp đồng và notice của vendor, cloud, model provider, subprocessor.
10. Open risk, biện pháp tạm, deadline, owner và người chấp nhận residual risk.

Mỗi artifact cần timestamp và version. Screenshot có thể không cho thấy toàn bộ setting hay lịch sử sửa, nên kết hợp configuration export, audit log, test result và approval workflow. Log cũng có thể chứa dữ liệu cá nhân hoặc bí mật, vì vậy phải bảo toàn bằng chứng với quyền truy cập phù hợp.

Biến reclassification thành cổng của production change

AI không đứng yên sau triển khai. Model, prompt, tài liệu RAG, API, người dùng, ngôn ngữ, mục đích, downstream system và subprocessor thay đổi. IT change thông thường có thể bỏ sót ảnh hưởng đến classification và data flow.

Mỗi change request phải trả lời:

• Intended use, user population, người bị ảnh hưởng hoặc cách dùng output có đổi không?
• Có dữ liệu cá nhân, bí mật, ảnh, audio, log hoặc evaluation data mới không?
• Storage, cross-border, subcontracting hoặc model reuse có đổi không?
• Human review, stop authority, fallback hoặc response time có đổi không?
• Giả định classification hoặc kết quả kiểm Decision 33 có thể bị ảnh hưởng không?
• Phải chạy lại evaluation set và absolute gate nào?
• Rollback về version nào và reconcile việc đang mở ra sao?

UI edit và purpose change không cần cùng lộ trình duyệt. Định trước trigger tự động chuyển legal, privacy và security. Không coi automatic model update là “không phải change”; hợp đồng phải có notice, version visibility, regression test và stop window.

Sai lầm thường gặp trong cách triển khai AI

Để kiểm tra pháp lý sát lúc ký

Sau chọn sản phẩm, thay đổi data route và trách nhiệm rất tốn kém. Chuẩn bị use-case card và flow diagram trước RFP để chuyên gia kiểm sự kiện cụ thể.

Dùng classification của vendor cho cả quy trình

Giả định cấp model có thể khác use đã tích hợp. Quản lý subject, version, purpose, user và integration thành một bộ.

Cho PoC qua bằng accuracy trung bình

Trung bình có thể che confidentiality exposure, privilege crossover, tự tin nguy hiểm và không dừng được. Tách refusal, authorization, leakage, intervention, reclassification và exit thành gate.

Thu nhỏ human-in-the-loop thành nút approve

Phê duyệt chỉ mang tính hình thức nếu thiếu bằng chứng, thời gian và quyền. Test visibility, comprehension, rejection, stop, fallback và escalation trong ca địa phương.

Chỉ dùng dữ liệu PoC sạch

Thực tế có tài liệu cũ, mâu thuẫn, tiếng Việt/Anh lẫn nhau, chênh quyền và chất lượng ảnh khác nhau. Dùng dữ liệu đại diện đã bảo vệ và hard case.

Đợi gia hạn hợp đồng mới định nghĩa exit

Ngay trong PoC, test export data, prompt, evaluation set, embedding, log, setting; cách chứng minh deletion; và khả năng trở về fallback.

Mở rộng sang ứng dụng AI tại Đông Nam Á

Khi mở rộng từ Việt Nam sang Thái Lan, Singapore hoặc Indonesia, không chỉ sao chép UI và ngôn ngữ. Phải đánh giá lại use, classification, personal data, cross-border, bối cảnh lao động, hợp đồng và hỗ trợ địa phương theo từng nước, pháp nhân và quy trình. Có thể chuẩn hóa cấu trúc use-case ID, evaluation governance, change trigger, evidence pack và stop exercise.

Trụ sở nên sở hữu minimum control có thể so sánh, không phải gom mọi phê duyệt. Pháp nhân địa phương sở hữu actual use, user, language, operational impact và fallback; trụ sở hỗ trợ hợp đồng chung, security, audit và học tập liên quốc gia. Global checklist không thay được provider classification và local legal assessment.

Checklist thực hiện

Trước khi phát hành RFP

• [ ] Tách use case thành đơn vị quyết định và đặt business/data/system/risk owner.
• [ ] Chuẩn bị dữ kiện kiểm AI Law, Decree 142 và Decision 33.
• [ ] Vẽ input, log, evaluation, support, backup, cross-border và exit.
• [ ] Chia provider, deployer, cloud, integrator, HQ và local bằng động từ.
• [ ] Định nghĩa thứ con người thấy, từ chối, dừng, thay thế và escalate.
• [ ] Định nghĩa reclassification trigger và owner xác nhận chuyên gia.

Trước khi bắt đầu PoC

• [ ] Cố định product, model, app và configuration version đã phân loại.
• [ ] Duyệt nguồn, expected result, sensitivity và access của evaluation set.
• [ ] Thêm refusal, authorization, leakage, intervention, failure, exit ngoài accuracy.
• [ ] Có màn hình, cảnh báo, đào tạo và liên hệ bằng ngôn ngữ địa phương.
• [ ] Có thể dừng PoC và thu hồi data/account khi hỏng.

Trước khi duyệt production

• [ ] Truy được requirement, version, test và approval trong evidence pack.
• [ ] Open item có severity, interim action, owner, deadline, residual-risk acceptance.
• [ ] Change request nối reclassification, data, security và regression.
• [ ] Chứng minh stop, fallback, rollback khi provider outage, hết hợp đồng, model đổi.
• [ ] Chuyên gia Việt Nam kiểm văn bản hiện hành và use case cụ thể.

Kết luận｜Triển khai AI tại Việt Nam được quyết định bằng bằng chứng thiết kế trước khi mua

Khi triển khai AI tại Việt Nam, không để pháp luật thành checklist sau dự án. Hãy nối use case, classification, Decision 33 review, personal/cross-border data, responsibility, human intervention, reclassification, evidence và exit trong một RFP. PoC 90 ngày chỉ là ví dụ, nhưng nguyên tắc bền vững là dùng refusal, authorization, leakage, human intervention, reclassification trigger, stop và rollback làm gate cùng accuracy. Chuyên gia Việt Nam xác nhận kết luận pháp lý; doanh nghiệp duy trì sự kiện và bằng chứng vận hành liên tục.

Nếu quý doanh nghiệp đang định hình use case, RFP hoặc cổng nghiệm thu AI cho nhà máy/pháp nhân tại Việt Nam, hãy liên hệ TOMAS TECH. Có thể bắt đầu từ ranh giới nghiệp vụ, dữ liệu và kiểm soát khi chưa chọn sản phẩm.

FAQ｜Nên bắt đầu phát triển AI tại Việt Nam từ đâu?

Hãy bắt đầu bằng use-case inventory, không phải sản phẩm. Ghi user, input, output, decision impact, error impact, data flow và stop route để tạo dữ kiện cho provider classification, legal review và câu trả lời vendor có thể so sánh.

FAQ｜Trụ sở và pháp nhân địa phương phân công triển khai Generative AI ở nước ngoài thế nào?

Trụ sở cung cấp khung security, contract, evaluation và evidence chung. Pháp nhân địa phương sở hữu actual use, user, language, operational impact và fallback. Không dùng global standard thay cho đánh giá riêng tại Việt Nam.

FAQ｜Có thể dùng cùng control cho ứng dụng AI tại Đông Nam Á không?

Có thể chuẩn hóa use-case ID, evaluation governance, change trigger và evidence pack. Classification, personal data, cross-border, contract, labor context và local operation phải đánh giá lại theo từng nước, pháp nhân và use case.

FAQ｜PoC 90 ngày có bắt buộc trong cách triển khai AI không?

Không. Kế hoạch 90 ngày là đề xuất minh họa. Quan trọng là đặt trước gate cho accuracy, refusal, authorization, leakage, intervention, reclassification, failure và exit. Use case đơn giản low-risk có thể ngắn hơn; dữ liệu và tích hợp phức tạp có thể dài hơn.

Lưu ý quan trọng

Bài viết hệ thống hóa nguồn chính thức được kiểm tra đến ngày 07/09/2026 cho quản lý mua sắm và triển khai AI, không phải tư vấn pháp lý. Hãy để chuyên gia pháp lý đủ năng lực tại Việt Nam và đội pháp chế, quyền riêng tư, an ninh nội bộ xác nhận nguyên văn, phạm vi, yêu cầu, chuyển tiếp và thực tiễn mới nhất. Trọng số RFP, điều kiện loại, lịch 90 ngày và giá trị nghiệm thu đều là đề xuất/ví dụ.

Tài liệu tham khảo

• Chính phủ Việt Nam, Luật 134/2025/QH15, ban hành 10/12/2025, hiệu lực 01/03/2026.
• Truyền thông Chính phủ, giới thiệu chính thức Nghị định 142/2026/NĐ-CP (ba mức rủi ro và provider phân loại trước khi sử dụng).
• Chính phủ Việt Nam, toàn văn Nghị định 142/2026/NĐ-CP, Điều 13 (đánh giá lại sự phù hợp của hệ thống rủi ro cao sau thay đổi lớn về mục đích hoặc tích hợp).
• Công báo, Quyết định 33/2026/QĐ-TTg, ban hành 30/06/2026, hiệu lực 15/08/2026.
• Bộ Khoa học và Công nghệ, Ethical framework for artificial intelligence established, tóm tắt Thông tư 05/2026/TT-BKHCN.
• Công báo, trang Nghị định 356/2025/NĐ-CP, ban hành 31/12/2025, hiệu lực 01/01/2026.
• Chính phủ Việt Nam, Quyết định 1671/QĐ-TTg, ban hành 28/08/2026.
• Báo Chính phủ, giải thích chiến lược AI quốc gia mới, 04/09/2026.
• Bộ Khoa học và Công nghệ, Qualcomm proposes AI and semiconductor partnership with Viet Nam, 01/09/2026.