Triển khai AI agent 2026 – Khác gì với 88% dừng lại ở PoC

PoC đã chạy được, nhưng không lên nổi production. Đây là kết cục thường gặp nhất khi triển khai AI agent. Theo khảo sát của Anaconda/Forrester, 88% các PoC AI agent không đạt tới production. Nguyên nhân không nằm ở việc chọn model hay chọn công cụ, mà ở chỗ bốn điểm — quyền hạn, phạm vi dữ liệu, giám sát và quyền sở hữu — đã không được quyết định “trước khi thử”. Bài viết này lấy tiền đề là các nhà máy tại Việt Nam và các cứ điểm doanh nghiệp Nhật Bản đang hoạt động tại Việt Nam, lần lượt trình bày bốn thiết kế phải chốt trước khi triển khai, cấu trúc chi phí, và cách tiến hành trong 90 ngày.

Cấu trúc khiến việc triển khai AI agent dừng lại ở mức PoC

Trong công ty có người đã thử, chủ đề này được đưa ra họp ban lãnh đạo, đề xuất từ nhà cung cấp cũng liên tục gửi tới. Vậy mà số doanh nghiệp thực sự đi được tới vận hành production chỉ là thiểu số. Trước hết hãy nắm thực trạng của khoảng cách này bằng con số.

88% không đạt tới production

Theo khảo sát của Anaconda/Forrester, 88% các PoC AI agent không đạt tới production. Con số này được tái lập ở mức tương đương trong khảo sát của a16z cũng như panel CIO của MIT Sloan. Gartner còn khắt khe hơn, cho rằng 89% dừng lại ở mức PoC. Chủ thể khảo sát và đối tượng khảo sát đều khác nhau, nhưng tất cả đều hội tụ về cùng một kết luận: gần 90% không lên được production.

Cũng trong khảo sát đó, các yếu tố cản trở việc đạt tới production đã được xác định.

Điều đáng chú ý là hai yếu tố đứng đầu không liên quan gì tới năng lực của model. Cả việc thiếu tiêu chí đánh giá lẫn ma sát quản trị đều bắt nguồn từ “những thứ chưa được quyết định”, chứ không phải từ kỹ thuật. Ngay cả yếu tố thứ ba là độ tin cậy của model, nếu đã quyết trước “đạt mức nào thì coi là đậu” thì cũng quy về vấn đề tiêu chí đánh giá. Nói cách khác, con số 88% không phát sinh vì model còn non, mà phát sinh vì người ta đã thử mà chưa quyết định những điều đáng lẽ phải quyết trước khi thử. Đây là xương sống của bài viết này.

78% có PoC, chỉ 14% đạt tới vận hành toàn công ty

Khảo sát do Digital Applied công bố tháng 3/2026 (650 lãnh đạo công nghệ doanh nghiệp, thực hiện trong tháng 2–3) cho thấy cấu trúc này một cách cụ thể hơn nữa.

• 78% doanh nghiệp đang có ít nhất một PoC
• Nhưng chỉ 14% đạt tới vận hành production ở quy mô toàn công ty
• 64% doanh nghiệp có PoC đã thử mở rộng và bị đình trệ từ 6 tháng trở lên
• Thời gian PoC trung bình cho tới lúc đình trệ là 4,7 tháng

Chênh lệch giữa 78% và 14%, tức khoảng cách 64 điểm phần trăm, chính là “scaling gap”. Điều quan trọng là 64% đó được diễn đạt là “bị đình trệ” chứ không phải “đã thất bại”. Thứ chạy được thì đã làm ra rồi. Nhưng đúng vào khoảnh khắc muốn mở rộng, hàng loạt vấn đề chưa từng bị hỏi tới trong giai đoạn PoC đồng loạt bùng lên.

Con số trung bình 4,7 tháng cũng rất gợi mở. Mất gần nửa năm để chạy PoC, rồi bắt tay vào mở rộng, rồi lại đứng yên thêm hơn 6 tháng. Cộng lại là gần một năm trôi qua. Trong suốt quãng thời gian đó, chi phí nhân sự và chi phí license đã bỏ ra không hề được thu hồi.

Chênh lệch giữa các ngành lên tới gần ba lần

Cũng trong khảo sát này, tỷ lệ đạt tới production theo ngành rất đáng xem.

Theo trực giác, ta hay nghĩ “ngành nào bị quản lý chặt thì càng khó tiến”. Nhưng tài chính là một trong những ngành bị quản lý chặt nhất, mà tỷ lệ đạt production lại cao nhất.

Cách đọc hiện tượng đảo ngược này như sau. Các ngành bị quản lý chặt đã có sẵn thủ tục để quyết định “ai phê duyệt, ghi lại những gì, giao đến đâu cho máy” mỗi khi đưa một cơ chế mới vào. Việc đáp ứng kiểm toán, quản lý phân quyền, lưu giữ log đều đã được thiết lập thành quy trình nghiệp vụ, nên khi xuất hiện một đối tượng mới là AI agent, họ vẫn đặt được nó lên khung sẵn có. Ngược lại, ở tổ chức không có những thủ tục đó thì phải bàn từ con số không. Vì ngay cả danh sách những việc cần quyết cũng không có trong tay, cuộc thảo luận phân tán và không bao giờ được phê duyệt. Quản trị không phải là rào cản của việc triển khai, mà đúng hơn là cơ chế làm tăng tốc độ triển khai.

Chi phí chìm khi thất bại trung bình khoảng 2,1 triệu USD

Với các doanh nghiệp trong Fortune 1000, chi phí chìm trung bình của một dự án AI agent thất bại vào khoảng 2,1 triệu USD. Tất nhiên đây là con số của doanh nghiệp lớn, không thể áp thẳng cho một nhà máy tại Việt Nam. Nhưng nếu phân rã thành các thành phần thì thấy rằng dù quy mô khác nhau, các khoản mục phát sinh vẫn giống nhau.

• Phí license và phí sử dụng API (vẫn bị tính tiền trong suốt giai đoạn PoC)
• Chi phí thuê ngoài trả cho nhà cung cấp
• Chi phí nhân sự nội bộ (giờ công của các thành viên dự án)
• Phát triển tích hợp (phần code để nối với hệ thống hiện có)
• Chuẩn bị dữ liệu (sắp xếp tài liệu để cho học và tham chiếu)

Trong đó, hai khoản cuối vẫn có khả năng còn lại như tài sản ngay cả khi PoC bị dừng. Việc chuẩn hóa API của hệ thống hiện có và cấu trúc hóa tài liệu nội bộ vẫn có giá trị kể cả khi không dùng AI agent. Nói ngược lại, phần chiếm đa số trong chi phí chìm là license và nhân sự, và khoản này tăng đơn điệu theo thời gian. Cái giá của việc để tình trạng đình trệ kéo dài 6 tháng lớn hơn nhiều so với hình dung. Cách duy nhất để cắt đứt cấu trúc này là chốt tiêu chí phán đoán trước khi bắt đầu PoC.

Bắt đầu bằng “thử xem có dùng được không” thì chắc chắn sẽ tắc

Rất nhiều dự án khởi đầu bằng câu “cứ thử xem có dùng được không đã”. Nghe thì có vẻ là điểm xuất phát lành mạnh, nhưng cách vào việc này có bốn khiếm khuyết mang tính cấu trúc.

Thứ nhất, không có ngưỡng đậu. Thử mà không có định nghĩa thế nào là “dùng được” thì sẽ rơi vào một trong hai: hoặc hài lòng ngay khi bản demo chạy, hoặc mãi mãi nói “độ chính xác vẫn chưa đủ”. Trường hợp đầu sẽ vỡ trận ở production, trường hợp sau thì vĩnh viễn không lên production.

Thứ hai, câu chuyện quyền hạn bị đẩy lùi lại sau. Trong PoC, người phụ trách chạy bằng tài khoản của chính mình nên vấn đề quyền hạn không lộ ra. Chỉ khi định chuyển sang production thì câu hỏi “đọc hệ thống lõi bằng quyền của ai” mới xuất hiện, và mọi thứ dừng lại ở đó.

Thứ ba, phạm vi dữ liệu vẫn mơ hồ mà đã mở rộng. Ở production, bắt buộc phải quyết “được đọc tới thư mục nào”, “có bao gồm bản vẽ của khách hàng không”. Ranh giới này không phải chuyện kỹ thuật mà là quyết định quản trị, và việc phê duyệt tốn thời gian.

Thứ tư, chưa quyết cơ chế này là của ai. Khi đầu ra sai thì ai sửa, khi nghiệp vụ thay đổi thì ai cập nhật. Chỗ này để trống thì sự xuống cấp bắt đầu ngay từ lúc vừa vận hành.

Bốn điều này tương ứng với “quyền hạn – phạm vi dữ liệu – giám sát – quyền sở hữu” sẽ bàn ở phần sau. Nơi mà 88% bị tắc gần như đều tập trung vào bốn chỗ này.

62% đang thử nghiệm, chỉ 23% scale được – Vị trí hiện tại của Nhật Bản và khu vực

Chương trước là những nhận định chung dựa trên khảo sát. Từ đây chúng ta xác nhận bằng con số xem doanh nghiệp Nhật Bản và các cứ điểm trong khu vực thực sự đang đứng ở đâu. Hãy dùng nó như một cây thước để đo vị trí hiện tại của chính doanh nghiệp bạn.

McKinsey: 62% ở giai đoạn thử nghiệm, 23% đã scale

Trong báo cáo “The State of AI” (bản tháng 11/2025) của McKinsey, 62% tổ chức đang ở giai đoạn thử nghiệm AI agent, trong khi chỉ 23% đạt tới việc vận hành ở quy mô scale cho ít nhất một nghiệp vụ trên toàn công ty.

Tổ hợp 62% và 23% này về mặt cấu trúc giống hệt cặp 78% và 14% ở chương trước. Vì đối tượng khảo sát và định nghĩa đều khác nhau nên không thể so sánh trực tiếp, nhưng bức tranh “doanh nghiệp đang thử là đa số, doanh nghiệp đang vận hành thật là thiểu số” thì trùng khớp giữa nhiều khảo sát.

Điều cần nắm là 23% được tính theo một tiêu chí khá lỏng: “chỉ cần scale được một nghiệp vụ là đã tính”. Nghĩa là ở thời điểm 2026, chỉ cần vận hành ổn định AI agent cho một nghiệp vụ thôi là đã lọt vào nhóm 20% dẫn đầu. Nói ngược lại, không cần nhắm tới triển khai toàn công ty quy mô lớn ngay từ đầu. Việc chạy chắc chắn một nghiệp vụ đã trực tiếp tạo ra vị thế cạnh tranh.

Tỷ lệ sử dụng AI tạo sinh trong công việc tại Nhật Bản là 55,2%

Theo Sách trắng Thông tin và Truyền thông năm Reiwa 7 của Bộ Nội vụ và Truyền thông Nhật Bản, tỷ lệ sử dụng AI tạo sinh trong công việc như sau.

Chỉ riêng Nhật Bản thấp hơn gần 40 điểm phần trăm. Ít nhất có thể đọc ra rằng “ở doanh nghiệp Nhật Bản, bản thân việc dùng AI tạo sinh trong công việc vẫn chưa trở thành điều hiển nhiên”.

Tiền đề này rất quan trọng, đặc biệt với các cứ điểm Nhật Bản tại Việt Nam vốn chịu ảnh hưởng của phương châm từ trụ sở chính. AI agent nằm ở lớp cao hơn của AI tạo sinh. Đưa một agent tự phán đoán và tự hành động vào một tổ chức mà ngay cả việc dùng AI tạo sinh theo chỉ thị của con người còn chưa bén rễ thì bậc thang quá cao. Thực tế hơn là trước hết làm cho việc dùng AI tạo sinh bén rễ ở một nghiệp vụ cụ thể, rồi trong chính nghiệp vụ đó mới giao cho agent “phần mà con người lần nào cũng ra cùng một phán đoán”.

Chỉ 23% doanh nghiệp Nhật Bản thấy kết quả vượt xa kỳ vọng

Trong Khảo sát thực trạng AI tạo sinh mùa xuân 2025 của PwC Japan, chỉ 23% doanh nghiệp Nhật trả lời rằng kết quả của AI tạo sinh “vượt xa kỳ vọng”.

Con số này không có nghĩa là không có kết quả. Vấn đề là 77% còn lại phân bố ở đâu, và điều đó phụ thuộc rất lớn vào mức kỳ vọng được đặt ra lúc triển khai. Nếu đặt kỳ vọng ở mức “cả nghiệp vụ sẽ được tự động hóa trọn gói” thì gần như chắc chắn sẽ hụt. Nếu đặt ở mức “thời gian cho một thao tác cụ thể giảm 30%” thì nằm trong phạm vi đạt được. Việc đặt kỳ vọng không phải chuyện tinh thần, mà chính là việc thiết kế tiêu chí đánh giá. Con số “thiếu tiêu chí đánh giá 64%” ở chương trước nối thẳng vào đây.

Tỷ lệ ban hành chính sách sử dụng AI: doanh nghiệp lớn 50%, doanh nghiệp vừa và nhỏ 30%

Tỷ lệ ban hành chính sách sử dụng AI của doanh nghiệp Nhật Bản là khoảng 50% ở doanh nghiệp lớn và khoảng 30% ở doanh nghiệp vừa và nhỏ.

Nghĩa là ngay cả ở doanh nghiệp lớn, một nửa vẫn đang dùng AI trong trạng thái không có chính sách. Tức là “được nhập những gì”, “tin đầu ra tới mức nào”, “ai chịu trách nhiệm” đều chưa được văn bản hóa. Ở giai đoạn cá nhân dùng chat thì dù vậy cũng khó dẫn tới sự cố lớn.

Nhưng AI agent thì khác. Agent thực hiện đọc và ghi lên hệ thống ở nơi không có ai đang nhìn. Đưa thứ đó lên production khi chưa có chính sách thì lúc xảy ra sự cố sẽ không truy ngược được “ai đã cho phép tới đâu”. Con số ma sát quản trị 57% chính là kết quả của sự vắng mặt này lộ ra ngay trước ngưỡng chuyển sang production.

Với các cứ điểm nước ngoài, số luận điểm còn tăng thêm. Chính sách tiếng Nhật của trụ sở chính có áp dụng cho cứ điểm tại Việt Nam không, có được cung cấp bằng ngôn ngữ mà nhân viên bản địa đọc được không, quan hệ với các quy định bảo vệ dữ liệu cá nhân tại nước sở tại được sắp xếp ra sao. Việc một cứ điểm chỉ có bản chính sách bằng tiếng Nhật không phải chuyện hiếm, nhưng như vậy thì trên thực tế nó không tồn tại đối với nhân viên bản địa.

Thị trường đạt 7,8 tỷ USD năm 2026, được nhúng vào 40% ứng dụng doanh nghiệp

Cũng cần nắm cả động thái phía cung.

• Quy mô thị trường AI agent năm 2026 là 7,8 tỷ USD (tăng 50% so với năm trước)
• Theo dự báo của Gartner, tới cuối năm 2026, 40% ứng dụng doanh nghiệp sẽ nhúng AI agent

Điểm thứ hai mới quan trọng về mặt thực tiễn. AI agent đang chuyển từ thứ mà ta chọn “có triển khai hay không” thành thứ tự động đi vào bên trong các ứng dụng nghiệp vụ mà ta đang dùng. Quản lý sản xuất, kế toán, groupware, CRM. Số tình huống mà tính năng agent được kích hoạt qua một bản cập nhật sẽ ngày càng nhiều. Nghĩa là không thể trì hoãn việc thiết kế quyền hạn và phạm vi dữ liệu được nữa. Bởi vì kể cả bạn không tự xây dựng, agent nhúng sẵn trong ứng dụng hiện có vẫn sẽ đọc dữ liệu nội bộ.

Về bản thân xu hướng công nghệ agent và độ mở rộng của khả năng ứng dụng trong ngành sản xuất, chúng tôi đã sắp xếp trong bài Xu hướng mới nhất của AI agent 2026. Bài viết này tập trung vào “khi thực sự triển khai thì phải quyết những gì”, nên sẽ không lặp lại phần giải thích xu hướng công nghệ.

Khoảng cách đặc thù của khu vực – Ví dụ Thái Lan với tổ chức 10,7% và nhân viên 72%

Từ đây là một trong những phần cốt lõi của bài viết. Đông Nam Á có một cấu trúc khác với Nhật Bản và phương Tây. Nếu bê nguyên kế hoạch triển khai của trụ sở chính vào mà không hiểu cấu trúc này, thì hoặc là không tiến được, hoặc ngược lại rơi vào trạng thái không kiểm soát nổi.

Hiện tượng đảo ngược: tổ chức 10,7%, cá nhân nhân viên 72%

Xếp các con số của khu vực cạnh nhau, một đứt gãy rõ ràng hiện ra.

Việt Nam ở mức 23%, cao hơn Thái Lan (10,7%) hơn hai lần, nhưng so với Singapore (69%) thì mới bằng khoảng một phần ba. Nói cách khác, Việt Nam đang ở vị trí giữa trong khu vực: đã vượt qua nhóm chậm nhất, nhưng còn cách rất xa nhóm dẫn đầu. Con số 23% cũng có nghĩa là hơn ba phần tư tổ chức tại Việt Nam vẫn chưa triển khai AI ở cấp tổ chức — tức là dư địa để tạo khác biệt cạnh tranh trong hai đến ba năm tới vẫn còn rất rộng.

Trong khi đó, tại Thái Lan, 72% cá nhân nhân viên đang dùng một dạng AI nào đó trong công việc. Chênh lệch giữa 10,7% và 72% có nghĩa là việc sử dụng AI không thông qua phê duyệt của tổ chức đang diễn ra trên diện rộng. Microsoft Work Trend Index 2026 cũng báo cáo cùng một bức tranh: người lao động Thái Lan đi trước khu vực về mức độ tận dụng AI, còn phía tổ chức thì tụt lại. Hiện trường chạy trước, công ty chưa theo kịp.

Đây chính là điểm mà độc giả Việt Nam nên đối chiếu. Cấu trúc “cá nhân đi trước, tổ chức đi sau” không phải hiện tượng riêng của Thái Lan mà thường xuất hiện ở các thị trường có lực lượng lao động trẻ, thích ứng nhanh với công cụ mới, nên rất đáng để kiểm tra xem nó có đang diễn ra tại nhà máy của bạn hay không. Nếu tại nhà máy của bạn, tỷ lệ triển khai ở cấp tổ chức vẫn thấp trong khi nhân viên đã dùng AI tạo sinh trên điện thoại cá nhân, thì bạn đang ở đúng cấu trúc này.

Ba rủi ro mà cấu trúc này sinh ra

Bản thân việc cá nhân đi trước không phải điều xấu. Ngược lại, thích ứng nhanh với công cụ mới là một thế mạnh. Vấn đề nằm ở việc trạng thái tổ chức không nắm được cứ kéo dài.

Thứ nhất, không nhìn thấy đường rò rỉ thông tin. Có khả năng nhân viên đang dán kích thước trên bản vẽ, mã hàng của khách, thông tin giá thành, báo cáo lỗi vào một dịch vụ AI tạo sinh bằng tài khoản cá nhân. Không phải vì ác ý, mà đơn giản vì muốn xong việc nhanh hơn. Nếu phía tổ chức không có chính sách lẫn phương án thay thế thì dòng chảy này không dừng lại.

Thứ hai, chất lượng đầu ra không được ai kiểm chứng. Chừng nào còn là cá nhân sử dụng thì người xác nhận đúng sai chỉ có chính người đó. Khảo sát tại Thái Lan cho thấy 61% doanh nghiệp xếp “năng lực diễn giải, kiểm chứng và phản biện đầu ra của AI” vào nhóm kỹ năng quan trọng trong thời gian tới. Nói ngược lại, đang tồn tại một nhận thức phổ biến rằng ở thời điểm hiện tại năng lực đó chưa đủ. Trạng thái mà đầu ra chưa được kiểm chứng lẫn vào báo cáo hoặc câu trả lời gửi khách hàng là một rủi ro chất lượng âm thầm tiến triển.

Thứ ba, nghiệp vụ bị cá nhân hóa. Nghiệp vụ mà một cá nhân đã tối ưu bằng AI thì know-how đọng lại trong tay chính người đó. Prompt lẫn các điểm cần kiểm tra đều không được chia sẻ. Ngay khi người đó chuyển bộ phận hoặc nghỉ việc, nghiệp vụ quay về tốc độ cũ, và xét về năng suất của tổ chức thì chẳng có gì được tích lũy.

Mức độ trưởng thành số của Thái Lan là 2,12/4,0

Mức độ trưởng thành số của doanh nghiệp Thái Lan trung bình là 2,12/4,0. Con số này đã tăng từ 1,56 của năm 2025, tức là hướng đi thì đang tiến lên.

Đây là mức chỉ vừa vượt qua giữa thang bốn bậc một chút. Có thể diễn giải rằng đa số tổ chức đã số hóa ở mức độ nào đó các hệ thống nghiệp vụ nền tảng, nhưng chưa đạt tới giai đoạn dữ liệu được nối ngang với nhau và được dùng cho việc ra quyết định.

Đây là một tiền đề nghiêm trọng đối với việc triển khai AI agent, và cũng là câu hỏi mà nhiều nhà máy tại Việt Nam nên tự đặt cho mình. Agent chỉ tạo ra giá trị khi tiếp cận được dữ liệu làm căn cứ phán đoán. Trong trạng thái mà tồn kho, kế hoạch sản xuất, tiến độ công đoạn còn nằm rải rác trên giấy và Excel thì không có nguyên liệu nào để đưa cho nó.

Mức trung bình 2,12 cho thấy “có một số lượng đáng kể cứ điểm cần chuẩn bị nền tảng dữ liệu trước cả khi nói tới agent”. Bỏ qua chỗ này mà lao vào xem xét agent thì sẽ đâm vào bức tường “không có dữ liệu để cho đọc” ngay từ giai đoạn PoC. Yếu tố cản trở “thiếu dữ liệu học theo lĩnh vực 41%” ở chương trước chính là trạng thái này.

Ba luận điểm riêng của cứ điểm Nhật Bản tại Việt Nam

Ngoài những điều trên, các cứ điểm Nhật Bản còn có hoàn cảnh riêng.

Luận điểm 1: Sự đứt gãy trong ra quyết định giữa trụ sở chính và cứ điểm

Phương châm liên quan tới AI thường do bộ phận IT hoặc bộ phận thúc đẩy DX của trụ sở chính xây dựng. Trong khi đó, thực trạng nghiệp vụ tại cứ điểm Việt Nam lại khó nhìn thấy từ trụ sở. Kết quả là công cụ được trụ sở phê duyệt không khớp với nghiệp vụ ở hiện trường, hiện trường dùng phương tiện khác, và chính sách trở thành hình thức.

Đối sách là phía cứ điểm cụ thể hóa trước “dùng vào nghiệp vụ nào, dùng như thế nào” rồi trình lên trụ sở. Câu “chúng tôi muốn đẩy mạnh tận dụng AI” không đủ để trụ sở ra phán đoán. Nhưng nếu hạ xuống tới mức “nghiệp vụ trả lời thời hạn giao hàng đang nhận 50 lượt hỏi mỗi ngày, mỗi lượt mất trung bình 12 phút” thì cuộc thảo luận sẽ tiến được.

Luận điểm 2: Ngôn ngữ chia thành ba lớp

Tại nhà máy Nhật Bản ở Việt Nam, cấu trúc ba lớp là phổ biến: quản lý người Nhật dùng tiếng Nhật, nhân viên bản địa dùng tiếng Việt, còn báo cáo cho khách hàng và trụ sở dùng tiếng Anh; tài liệu mà agent phải xử lý cũng lẫn lộn cả ba ngôn ngữ này.

Vấn đề nằm ở chỗ cùng một nội dung tồn tại ở ba ngôn ngữ và thời điểm cập nhật bị lệch nhau. Tiêu chuẩn thao tác bản tiếng Nhật đã được sửa đổi mà bản tiếng Việt vẫn cũ là chuyện không hiếm. Nếu không quyết định rõ ràng thứ tự ưu tiên của nguồn tham chiếu thì đầu ra sẽ không ổn định.

Luận điểm 3: Cần thiết kế trên tiền đề có biến động nhân sự

Tại hiện trường sản xuất ở Việt Nam, biến động nhân sự phát sinh ở một mức độ nhất định, đặc biệt tại các khu công nghiệp có nhiều nhà máy cạnh tranh tuyển dụng. Cần lấy tiền đề rằng người được đào tạo lúc triển khai có thể không còn ở đó sau một năm. Để dùng thành thạo agent cần có cảm nhận về “ra chỉ thị thế nào thì thu được đầu ra như ý”, nhưng nếu điều này chỉ nằm trong đầu một cá nhân thì ngay khi đổi người phụ trách, mức độ tận dụng sẽ tụt xuống. Để lại các mẫu chỉ thị dưới dạng template và viết thành quy trình bằng tiếng Việt là điều kiện để nó bén rễ.

Biến việc cá nhân đi trước thành tài sản của tổ chức

Không cần nhìn cấu trúc này một cách bi quan. Việc 72% nhân viên đã dùng AI có nghĩa là sức cản đối với việc triển khai rất nhỏ. Trong khi ở trụ sở Nhật Bản, kêu gọi “hãy thử dùng AI” mà phản ứng vẫn nguội lạnh, thì tại Thái Lan, người đã dùng lại là đa số.

Thứ cần thiết không phải là cấm đoán, mà là cung cấp nơi tiếp nhận. Cụ thể, trình tự sau đây là thực tế.

1. Nắm thực trạng: hỏi xem ai đang dùng công cụ gì cho nghiệp vụ nào, không kèm chế tài
2. Chỉ ra ranh giới thông tin được phép nhập: thay vì liệt kê điều cấm, hãy nêu ví dụ theo từng nghiệp vụ “cái này được nhập / cái này không”
3. Chuẩn bị môi trường dùng được ở cấp tổ chức: nếu công ty cung cấp môi trường xử lý được dữ liệu nghiệp vụ thì lý do để chảy sang tài khoản cá nhân sẽ biến mất
4. Nhân rộng những cách dùng hay: thu thập cách dùng do cá nhân nghĩ ra, biến thành template và chia sẻ

Bốn bước này cũng vận hành tốt với vai trò là giai đoạn tiền đề của việc triển khai agent. Bởi vì chính công việc nắm thực trạng sử dụng của cá nhân sẽ trở thành danh sách ứng viên cho câu hỏi “nên agent hóa nghiệp vụ nào”.

Ngoài ra, ở cấp chính sách công, các khung hỗ trợ trong khu vực cũng đang chuyển động. Chương trình TH-AI Passport và ưu đãi thuế cho đào tạo nhân lực của Cơ quan Xúc tiến Kinh tế Số Thái Lan (DEPA) là ví dụ; phần này sẽ được sắp xếp cùng kế hoạch ngân sách trong lộ trình 90 ngày ở phần sau.

AI agent khác ở chỗ nào – Ranh giới với AI tạo sinh, RPA và chatbot

Một trong những nguyên nhân khiến phán đoán triển khai bị sai lệch là sự lẫn lộn thuật ngữ. Cụm từ “AI agent” đang được dùng để chỉ những thứ hoàn toàn khác nhau, từ chatbot cho tới phần mở rộng của RPA. Ở đây chúng ta phân định ranh giới theo chủ thể của phán đoán.

Phân loại theo việc ai nắm quyền phán đoán

Nếu phân loại không theo cơ chế kỹ thuật mà theo “ai đang nắm quyền phán đoán trong nghiệp vụ”, khác biệt thực tiễn sẽ hiện ra rõ ràng.

Khác biệt mang tính quyết định nằm ở hàng cuối cùng: “ứng xử với tình huống ngoài dự kiến”. RPA gặp tình huống ngoài dự kiến thì dừng. Agent gặp tình huống ngoài dự kiến thì tự thử cách khác. Thứ dừng lại thì an toàn vì nó không làm gì cả. Thứ tự thử cách khác, nếu thuận lợi thì nghiệp vụ tiến lên mà không cần bàn tay con người, nhưng nếu chọn nhầm cách thì một xử lý sai sẽ được thực thi. Tính chất “hành động tự chủ” và tính chất “phán đoán sai được thực thi” là hai mặt của cùng một thứ. Chính vì vậy, phạm vi quyền hạn và thiết kế giám sát trở thành tiền đề của việc triển khai. Cuộc thảo luận vốn không cần với RPA lại trở thành bắt buộc với agent.

Xử lý tài sản RPA hiện có ra sao

Tại các nhà máy trong khu vực, không ít nơi đã triển khai RPA. Chúng tôi thường nhận được câu hỏi “nếu đưa agent vào thì có phải bỏ RPA không”, và câu trả lời là không bỏ.

Sắp xếp lại thì như sau.

Hiệu quả chi phí cao nhất là hàng thứ hai và hàng thứ tư. Phần lớn nguyên nhân khiến RPA dừng là “định dạng đầu vào khác với dự kiến”, và chèn AI tạo sinh vào chỗ này sẽ giúp nó ổn định. Bạn tận dụng nguyên vẹn tài sản RPA hiện có mà vẫn giảm được tần suất bị dừng. Hàng thứ tư cũng quan trọng. Nếu không để agent thực thi tới bước cuối mà cho nó tạo bản nháp rồi con người kiểm tra và gửi đi, bạn giảm rủi ro rất mạnh mà vẫn lấy được phần lớn hiệu quả cắt giảm giờ công.

Ngoài ra, khi đánh giá đề xuất của nhà cung cấp, hãy xác nhận ba điểm: “sản phẩm này có phải định nghĩa kịch bản trước không”, “có đi ngang qua nhiều hệ thống được không”, “khi thất bại thì chuyện gì xảy ra”. Sản phẩm phải định nghĩa kịch bản trước thực chất là công cụ workflow; nếu đặt kỳ vọng theo chuẩn agent thì sẽ không khớp.

Thêm nữa, khi cho agent tham chiếu tài liệu nội bộ và bản vẽ, bạn cần xây dựng RAG (retrieval-augmented generation) làm nền tảng cho việc đó. Việc chuẩn bị dữ liệu cho agent tham chiếu thường tốn nhiều giờ công hơn cả bản thân agent. Về cách tiến hành và chi phí của phần này, chúng tôi đã sắp xếp riêng trong bài Chi phí và cách triển khai RAG.

Bốn thiết kế phải chốt trước khi triển khai – Quyền hạn, phạm vi dữ liệu, giám sát, quyền sở hữu

Đây là phần trung tâm của bài viết. Như đã thấy ở các chương trước, nơi PoC bị tắc gần như tập trung vào bốn chỗ. Chỉ cần chốt bốn điểm này trước khi bắt đầu PoC là kết quả đã thay đổi rất lớn.

Vì sao quyết “trước” lại hiệu quả

Trong khảo sát của Digital Applied có một con số mang tính quyết định. Tổ chức đặt bộ phận chuyên trách vận hành AI vào vị trí “trước” khi mở rộng quy mô có tỷ lệ thành công cao gấp 5,7 lần so với tổ chức quyết định việc đó sau.

Cùng là lập một bộ phận như nhau, mà lập trước hay lập sau tạo ra chênh lệch 5,7 lần. Chênh lệch này không do sự tồn tại của bộ phận, mà do thứ tự. Nếu lập sau, bạn phải thiết kế bộ phận cho vừa với PoC đang chạy, và ràng buộc của PoC trở thành ràng buộc của production. Năm yếu tố cản trở việc mở rộng hàng đầu cũng có thể được đọc lại trong bối cảnh này.

Cả năm yếu tố hàng đầu đều tương ứng với một trong bốn thiết kế. Không phải vì khó về kỹ thuật mà bị tắc. Vì chưa quyết định nên bị tắc.

Dưới đây, chúng ta xem lần lượt bốn điểm.

Thiết kế 1: Quyền hạn – Agent hành động với tư cách đại diện của ai

Điều đầu tiên phải quyết là agent dùng quyền của tài khoản nào, tác động lên hệ thống nào, chỉ đọc hay ghi được.

Trong PoC, câu hỏi này không lộ ra, vì người phụ trách chạy bằng tài khoản của chính mình. Nhưng ở production, agent có thể chạy 24/24 và được gọi bởi nhiều người dùng. Nếu chưa chốt “đại diện cho ai” thì thiết kế phân quyền không thể xây dựng được.

Các hạng mục cần quyết được sắp xếp như sau.

Quan trọng nhất là “chủ thể thực thi”. Cấp quyền mạnh cho một tài khoản riêng thì thiết kế sẽ nhẹ đi, nhưng sẽ mở ra lỗ hổng “dữ liệu mà người dùng đó vốn không được xem lại xem được thông qua agent”. Một nhân viên kinh doanh chỉ được cấu hình xem khách hàng mình phụ trách, nếu hỏi agent thì lại lấy được thông tin của toàn bộ khách hàng. Đó là sự sụp đổ của quản lý phân quyền. Đối sách là thiết kế theo hướng kế thừa quyền của người dùng sang agent. Về kỹ thuật thì tốn công hơn, nhưng chi phí sửa lại về sau lớn hơn nhiều.

Về quyền ghi, chúng tôi khuyến nghị ban đầu cố định ở mức “chỉ tới bước tạo bản nháp”. Không cần giao ngay từ đầu cho agent các hành động thực thi như đặt hàng, ra lệnh xuất hàng, gửi thư cho khách. Chỉ cần tự động hóa tới bản nháp là đã lấy được phần lớn hiệu quả cắt giảm giờ công, mà rủi ro thực thi sai bằng không. Sau khi xác nhận được độ chính xác trong vận hành thực tế, hãy mở dần quyền thực thi theo từng bước ở phạm vi có ảnh hưởng nhỏ.

Thiết kế 2: Phạm vi dữ liệu – Cho đọc cái gì, không cho đọc cái gì

Tiếp theo là quyết định phạm vi dữ liệu mà agent tham chiếu. Chỗ này không phải chuyện kỹ thuật, mà là lĩnh vực trộn lẫn giữa quyết định quản trị và phán đoán pháp lý, nên việc phê duyệt tốn thời gian. Vì vậy cần bắt tay vào sớm.

Trước hết, hãy chia dữ liệu thành bốn nhóm.

Trong thực tế, nơi gây tranh cãi nhiều nhất là hàng thứ hai, nhóm “có điều kiện”. Việc có được cho đọc bản vẽ của khách hay không phụ thuộc cả vào điều khoản trong thỏa thuận bảo mật với khách hàng lẫn điều kiện xử lý dữ liệu của dịch vụ được sử dụng. Nếu hợp đồng yêu cầu “không được dùng để huấn luyện” thì phải kiểm tra tới cả hình thức hợp đồng của dịch vụ.

Với các cứ điểm tại Việt Nam, ở đây còn cộng thêm góc nhìn về các quy định bảo vệ dữ liệu cá nhân của nước sở tại. Nếu đưa vào phạm vi tham chiếu những tài liệu chứa thông tin cá nhân của nhân viên hoặc của người phụ trách bên đối tác, bạn cần sắp xếp căn cứ và phạm vi xử lý. Riêng phương châm của trụ sở chính Nhật Bản là không đủ. Với các cứ điểm đặt tại Thái Lan thì đây là câu chuyện của PDPA (luật bảo vệ dữ liệu cá nhân Thái Lan); nguyên tắc thì giống nhau, chỉ khác ở văn bản pháp lý áp dụng — điều phải làm là xác định luật nào chi phối cứ điểm của bạn, rồi sắp xếp phạm vi dữ liệu theo luật đó.

Và hàng thứ tư thực ra mới là bức tường lớn nhất. Thực chất của “thiếu dữ liệu học theo lĩnh vực 41%” trong phần lớn trường hợp không phải là “không có dữ liệu” mà là “chưa được văn bản hóa”. Tiêu chí mà người có kinh nghiệm phán đoán trong đầu không được viết ở đâu cả, và agent không thể tham chiếu thứ không được viết ra. Điều cần thiết ở đây là phán đoán: không phải văn bản hóa toàn bộ rồi mới bắt đầu, mà thu hẹp nghiệp vụ mục tiêu rồi chỉ văn bản hóa đúng phạm vi mà nghiệp vụ đó cần. Nếu định hoàn tất việc chuẩn bị tri thức cho toàn công ty trước, thì chỉ riêng việc đó đã ngốn mất một năm.

Trên thực tế, việc thiết kế phạm vi dữ liệu sẽ được tiến hành gắn liền với kế hoạch chuẩn bị tài liệu tham chiếu.

Thiết kế 3: Giám sát – Phát hiện suy giảm bằng cách nào

Điểm thứ ba là giám sát. Hai con số “chất lượng đầu ra suy giảm khi chạy quy mô lớn 58%” và “thiếu giám sát 54%” thực chất chỉ cùng một vấn đề. Chất lượng sẽ suy giảm. Không phát hiện được thì không ai nhận ra.

Vì sao lại suy giảm? Có ba lý do. Phân bố đầu vào thay đổi (trong PoC bạn thử với các trường hợp tiêu biểu, nhưng ở production sẽ xuất hiện những câu hỏi có định dạng không lường trước, sản phẩm mới, khách hàng mới. Độ chính xác lúc PoC chẳng qua là độ chính xác đối với phân bố đầu vào lúc PoC). Dữ liệu tham chiếu trở nên cũ (tiêu chuẩn thao tác đã sửa đổi mà tài liệu tham chiếu chưa cập nhật. Trong trạng thái này, agent tự tin trả lời theo tiêu chuẩn cũ. Điểm phiền toái của loại suy giảm này là cái sai xuất hiện dưới dạng “câu trả lời nghe rất hợp lý” chứ không phải “tôi không biết”). Cách dùng của người dùng thay đổi (khi đã quen, họ bắt đầu dùng vào những mục đích ban đầu không lường trước. Bản thân điều đó là tốt, nhưng với mục đích ngoài dự kiến thì độ chính xác không được đảm bảo).

Do đó, giám sát cần được thiết kế không phải như giám sát hệ thống (có đang chạy không) mà như giám sát nghiệp vụ (có đúng không). Tối thiểu hãy nhìn bốn thứ sau.

Đặc biệt “tỷ lệ người dùng chỉnh sửa” là chỉ số thực dụng nhất. Nếu lần nào người dùng cũng phải sửa rất nhiều thì ở nghiệp vụ đó agent chưa vận hành được. Ngược lại, nếu gần như được dùng mà không cần sửa thì có thể cân nhắc mở quyền thực thi. Chỉ số này vừa lấy được tự động, vừa gắn thẳng với giá trị nghiệp vụ.

Việc ghi lại “đầu vào ngoài dự kiến” cũng không thể thiếu. Những câu hỏi không tìm thấy trong dữ liệu tham chiếu chính là danh sách tài liệu cần chuẩn bị tiếp theo. Giám sát không chỉ để phát hiện suy giảm, mà còn là cơ chế sinh ra nguyên liệu cải tiến.

Lưu ý rằng công việc lấy mẫu hằng tuần và phán định đúng sai, tùy khối lượng nghiệp vụ, sẽ tốn từ vài giờ tới hơn chục giờ mỗi tháng. Nếu chưa quyết định giờ công này nằm trong thời gian làm việc của ai thì việc giám sát sẽ thành hình thức sau ba tháng. Điều này dẫn tới thiết kế thứ tư.

Thiết kế 4: Quyền sở hữu – Đây là cơ chế của ai

Cuối cùng là quyền sở hữu. “Thiếu quyền sở hữu ở cấp tổ chức 49%” cho thấy ở khoảng một nửa số tổ chức, “cơ chế này của ai” vẫn chưa được quyết.

Cần quyết bốn vai trò sau.

Dễ bị bỏ sót nhất là “phụ trách dữ liệu”. Việc cập nhật tài liệu tham chiếu là việc của bộ phận đang viết tiêu chuẩn thao tác, nhưng bộ phận đó thường không ý thức được sự tồn tại của agent. Nếu quy trình “khi sửa đổi tiêu chuẩn thì cập nhật cả nguồn tham chiếu” không được nhúng vào quy trình nghiệp vụ, thì độ mới chắc chắn sẽ tụt.

“Chủ sở hữu nghiệp vụ lại là bộ phận hệ thống thông tin” cũng là mẫu hình thất bại điển hình. Khi một bộ phận không có khả năng phán định đúng sai của đầu ra trở thành owner thì việc giám sát không vận hành. Owner nhất định phải đặt ở phía nghiệp vụ.

Cũng nên sắp xếp cả quan hệ với nhà cung cấp bên ngoài. Dù thuê ngoài phần xây dựng thì phần vận hành vẫn ở lại với chính bạn. Nếu thuê ngoài trọn gói cả phần vận hành thì mỗi lần thay đổi nghiệp vụ đều tốn tiền và thời gian, và việc cải tiến sẽ đứng lại. Ngược lại, nếu định tự làm toàn bộ ngay từ đầu thì khởi động rất chậm. Cấu hình thực tế là vừa phối hợp với bên ngoài để xây dựng và vận hành giai đoạn đầu, vừa chuyển dần chủ thể vận hành về nội bộ theo từng bước. Đối tượng bàn giao chủ yếu gồm ba thứ: việc thực hiện giám sát, việc cập nhật tài liệu tham chiếu, và việc xử lý câu hỏi. Về cách chuyển giao này, chúng tôi đã sắp xếp theo từng giai đoạn trong bài Hỗ trợ nội bộ hóa năng lực AI.

Gói bốn thiết kế vào một trang

Bốn thiết kế không độc lập mà phụ thuộc lẫn nhau. Quyết quyền hạn thì phạm vi dữ liệu được quyết theo, quyết phạm vi dữ liệu thì hạng mục giám sát được quyết theo, quyết hạng mục giám sát thì giờ công cần thiết và owner cũng được quyết theo. Chúng tôi khuyến nghị trước khi bắt đầu PoC, hãy làm một trang sau đây. Chỉ cần gói gọn trong một trang A4 là đủ.

• Nghiệp vụ mục tiêu: làm gì, ai làm, hiện đang làm thế nào
• Mục tiêu: cải thiện cái gì bao nhiêu phần trăm (tiêu chí đánh giá)
• Chủ thể thực thi: dùng tài khoản nào, tác động lên hệ thống nào, đọc hay ghi
• Phạm vi dữ liệu: thứ cho tham chiếu, thứ không cho, thứ có điều kiện
• Phê duyệt: thao tác nào cần con người duyệt, ngưỡng là bao nhiêu
• Giám sát: chỉ số nhìn, tần suất, người phán định
• Vai trò: họ tên của chủ sở hữu nghiệp vụ, phụ trách vận hành, phụ trách kỹ thuật, phụ trách dữ liệu
• Tiêu chí dừng: rơi vào trạng thái nào thì kết thúc PoC

Việc đưa “tiêu chí dừng” ở dòng cuối vào rất hiệu quả trong thực tế. Cấu trúc mất 4,7 tháng rồi rơi vào đình trệ sinh ra từ chỗ không thể ra quyết định dừng. Nếu đặt trước một tiêu chí kiểu “tới mốc 3 tháng mà tỷ lệ chỉnh sửa vẫn trên 70% thì tạm dừng”, bạn sẽ chặn được việc chi phí chìm phình ra.

Công việc làm một trang này, chỉ cần các bên liên quan ngồi lại là xong trong 2–3 buổi họp. Thứ tạo ra chênh lệch 5,7 lần chỉ là khối lượng công việc cỡ đó.

Chi phí triển khai AI agent và cấu trúc chi phí (năm 2026)

Bây giờ đến chuyện tiền. Điều cần lưu ý ở đây là chi phí AI agent thường bị nói tới như thể chỉ là “phí license”. Trên thực tế, phần chi phí nhìn thấy được chỉ là một phần của tổng thể.

Ba khung giá

Hình thức triển khai chia thành ba nhóm lớn. Dưới đây là mức tham khảo theo mặt bằng thị trường Thái Lan, và sẽ dao động rất mạnh tùy theo nghiệp vụ mục tiêu, số lượng hệ thống cần tích hợp, và tình trạng chuẩn bị của dữ liệu hiện có. Đây không phải con số có thể khẳng định là báo giá cho doanh nghiệp bạn, hãy xem nó như điểm xuất phát để cân nhắc.

Nếu quy đổi tham khảo sang yên Nhật theo tỷ giá 1 baht ≈ 4,5 yên, chi phí ban đầu của khung A vào khoảng 450.000 – 2.250.000 yên, khung B khoảng 3,6 – 13,5 triệu yên, và khung C khoảng 13,5 – 67,5 triệu yên. Vì tỷ giá biến động, hãy chỉ dùng nó để nắm quy mô con số; khi quy sang đồng Việt Nam, cần tính theo tỷ giá tại thời điểm lập ngân sách.

Không cần nhắm tới khung C ngay từ đầu. Như đã nói, ở thời điểm 2026 chỉ cần scale được một nghiệp vụ là đã thuộc nhóm 20% dẫn đầu. Chạy chắc chắn một nghiệp vụ ở khung B rồi mở rộng dựa trên hiểu biết thu được, rốt cuộc lại nhanh hơn và rẻ hơn.

Ba loại chi phí vận hành khó nhìn thấy

Chi phí ban đầu thì có trên báo giá. Vấn đề nằm ở chi phí vận hành. Nếu chỗ này bị ước tính thấp ngay từ giai đoạn báo giá thì sau khi vận hành sẽ thành “đắt hơn tưởng tượng”, và quyết định duy trì sẽ lung lay.

Loại 1: Chi phí token và API

Agent gọi model nhiều lần trong một lượt xử lý. Nó phân rã mục tiêu, đi tìm thông tin cần thiết, đánh giá kết quả, và nếu cần thì thử cách khác. Với một yêu cầu, việc tiêu thụ gấp vài lần tới hơn chục lần lượng token của AI tạo sinh kiểu đối thoại là chuyện bình thường.

Khi lập báo giá, hãy ước tính theo công thức sau.

Chi phí token hằng tháng = Lượng token dự kiến cho mỗi lượt × Số lượt mỗi tháng × Đơn giá

Điều quan trọng là đặt lượng token của mỗi lượt bằng giá trị đo thực tế trong PoC. Nếu lấy theo giá trị catalogue hoặc theo trường hợp của công ty khác thì quy mô con số sẽ khác hẳn. Ngoài ra, tài liệu tham chiếu càng nhiều thì token cho mỗi lượt càng tăng. Cần đưa vào kế hoạch ngân sách mối quan hệ sau: càng đẩy mạnh chuẩn bị dữ liệu thì chi phí vận hành càng tăng.

Loại 2: Chi phí nhân sự cho giám sát

Như đã nói ở chương trước, giám sát là công việc của con người. Hằng tuần lấy mẫu, phán định đúng sai, ghi lại xu hướng. Giờ công này, tùy quy mô nghiệp vụ mục tiêu, nên dự trù từ vài giờ tới hơn chục giờ mỗi tháng.

Nó không xuất hiện trên báo giá, nhưng chắc chắn phát sinh. Ở tổ chức không dành sẵn giờ công này trong thời gian làm việc, việc giám sát sẽ dừng sau ba tháng. Một hệ thống giám sát đã dừng sẽ tạo ra trạng thái không ai nhận ra dù suy giảm vẫn đang tiến triển.

Loại 3: Huấn luyện lại và cập nhật dữ liệu tham chiếu

Tiêu chuẩn thao tác thay đổi. Sản phẩm thay đổi. Yêu cầu của khách hàng thay đổi. Mỗi lần như vậy phải cập nhật tài liệu tham chiếu, và nếu cần thì điều chỉnh cả khuôn dạng đầu ra. Công việc này không tốn nhiều giờ công như lúc xây dựng ban đầu, nhưng phát sinh liên tục. Cách nghĩ phổ biến là dự trù khoảng 10–20% chi phí xây dựng ban đầu mỗi năm cho ngân sách bảo trì và cải tiến. Không dự trù chỗ này thì sau một năm sẽ rơi vào trạng thái “đã triển khai nhưng nó trả lời thông tin cũ nên chẳng ai dùng”.

Cộng cả ba loại lại, chi phí vận hành chiếm một tỷ lệ không thể bỏ qua trên chi phí ban đầu khi tính theo năm. Không so sánh theo tổng chi phí sở hữu trong ba năm thì sẽ phán đoán sai giữa khung A và khung B.

Đưa cả chi phí khi thất bại vào ước tính

Con số chi phí chìm trung bình 2,1 triệu USD nhắc ở chương trước là của doanh nghiệp lớn, nhưng cách tư duy thì dùng được ở mọi quy mô. Hãy sắp xếp trước nếu PoC bị dừng thì mất bao nhiêu và còn lại bao nhiêu.

Kết luận rất rõ ràng. Thứ nên làm trước là khoản đầu tư ở phía “còn lại”. Công việc làm cho dữ liệu lấy ra được từ hệ thống hiện có, và công việc sắp xếp tài liệu nghiệp vụ, đều không lãng phí ngay cả khi agent không dùng được. Ngược lại, nếu vào việc từ khâu chọn công cụ thì các khoản chi ở phía “mất” sẽ chất lên trước. Chỉ cần đổi thứ tự là thiệt hại khi thất bại đã khác.

Ba điểm cần xác nhận khi đánh giá báo giá

Khi đã lấy được báo giá từ nhà cung cấp, hãy xác nhận ba điểm sau. Có khoản mục chuẩn bị dữ liệu không (nếu chỉ có một dòng “vui lòng chuẩn bị phía quý khách” thì giờ công đó ở lại với bạn. Hãy tự ước tính lại xem mất bao nhiêu ngày công). Có ghi tiền đề của chi phí vận hành không (một con số hằng tháng mà không nêu tiền đề về số lượt mỗi tháng và lượng token mỗi lượt là con số không có căn cứ). Có ghi điều kiện bàn giao vận hành không (nếu mập mờ về việc bạn sẽ nhận lại công việc nào thì mỗi thay đổi nhỏ đều phát sinh báo giá bổ sung).

Những lĩnh vực ứng dụng hiệu quả tại hiện trường sản xuất

Rời khỏi những lập luận trừu tượng, chúng ta sắp xếp các lĩnh vực dễ tạo ra hiệu quả tại nhà máy. Điều kiện chung là những nghiệp vụ mà “con người mỗi ngày đều lặp lại những phán đoán tương tự” và “nguyên liệu cho phán đoán nằm trong hệ thống”.

Lĩnh vực 1: Quản lý sản xuất và trả lời thời hạn giao hàng

Nghiệp vụ trả lời các câu hỏi về thời hạn giao hàng từ khách hàng là ứng viên số một cho việc agent hóa. Có ba lý do. Số lượt nhiều (không hiếm cứ điểm nhận vài chục lượt hỏi mỗi ngày), nguyên liệu cho phán đoán nằm trong hệ thống (tồn kho, kế hoạch sản xuất, tiến độ công đoạn, lead time mua hàng), trình tự mang tính định hình (dòng chảy xem nhiều hệ thống, tổng hợp lại rồi soạn câu trả lời lần nào cũng như nhau).

Thứ giao cho agent là tới bước tra cứu xuyên qua tồn kho và kế hoạch rồi tạo bản nháp câu trả lời. Việc gửi đi do con người kiểm tra và thực hiện. Với cấu hình này, rủi ro báo sai thời hạn cho khách hàng vẫn bằng không, mà thời gian tra cứu được rút ngắn đáng kể.

Điểm cần lưu ý là chênh lệch độ mới của dữ liệu giữa các hệ thống. Trong trạng thái tồn kho là thời gian thực, kết quả sản xuất là batch hằng ngày, mua hàng lại cập nhật hằng tuần, thì độ tin cậy của câu trả lời tổng hợp sẽ giảm. Việc triển khai agent cũng đồng thời là công việc làm lộ ra sự không nhất quán về độ mới của dữ liệu.

Lĩnh vực 2: Phân tích chất lượng và hàng lỗi

Việc điều tra ban đầu khi phát sinh hàng lỗi cũng hợp với agent. Tìm các lỗi tương tự trong quá khứ, trích xuất điều kiện sản xuất của lô tương ứng, xác nhận lịch sử các hành động khắc phục liên quan. Con người làm thủ công thì mất vài giờ, nhưng nguyên liệu đều nằm trong hồ sơ. Thứ giao cho agent là phần điều tra kiểu “với hạng mục lỗi này, hãy đưa ra các hồ sơ tương tự trong một năm qua và biện pháp lúc đó”, còn việc khẳng định nguyên nhân và quyết định biện pháp thì do con người.

Điều kiện tiên quyết là hồ sơ phải ở trạng thái nối được với nhau. Hồ sơ kiểm tra không có mã thiết bị, thời gian lệch nhau giữa các hệ thống, định nghĩa lô khác nhau giữa các công đoạn. Ở những trạng thái như vậy thì không tạo được tập dữ liệu để đưa cho agent. Đây chính là lĩnh vực mà “thiếu dữ liệu học theo lĩnh vực 41%” biểu hiện cụ thể nhất tại hiện trường sản xuất.

Lĩnh vực 3: Bảo trì thiết bị

Đây là ứng dụng mà khi thiết bị có bất thường, agent tổng hợp và trình bày cùng lúc lịch sử xử lý các sự cố cùng loại trong quá khứ, đoạn tương ứng trong tài liệu hướng dẫn của thiết bị đó, và tình trạng tồn kho phụ tùng. Nghiệp vụ bảo trì rất dễ bị cá nhân hóa tri thức. Người có kinh nghiệm chỉ nghe triệu chứng là đoán được nguyên nhân, nhưng căn cứ phán đoán đó không được văn bản hóa. Giá trị của việc đưa agent vào nằm ở chỗ làm dịu sự cá nhân hóa này.

Tuy nhiên trên thực tế, rất nhiều trường hợp hồ sơ sự cố trong quá khứ chỉ ghi mỗi chữ “đã xử lý”. Nếu triệu chứng, nguyên nhân, biện pháp, kết quả không được lưu lại một cách có cấu trúc thì agent chẳng có gì để tham chiếu. Lĩnh vực này thường phải bắt đầu từ việc cải thiện biểu mẫu ghi chép.

Lĩnh vực 4: Mua hàng và thu mua

Đây là các nghiệp vụ như so sánh báo giá, hỗ trợ chọn nhà cung cấp, phát hiện dấu hiệu chậm giao hàng. Việc so sánh báo giá của nhiều nhà cung cấp theo từng khoản mục rồi sắp xếp phần chênh lệch tốn rất nhiều công sức, chính vì định dạng không thống nhất. Đây là lĩnh vực sở trường của AI tạo sinh.

Không giao việc thực thi đặt hàng cho agent. Các thao tác làm dịch chuyển tiền bạc phải dừng ở mức bản nháp, đúng theo nguyên tắc thiết kế quyền hạn. Chỉ cần tự động hóa tới bước lập bảng so sánh là giờ công của bộ phận mua hàng đã giảm thấy rõ.

Lĩnh vực 5: Tài liệu đa ngôn ngữ

Đây là lĩnh vực dễ thấy hiệu quả triển khai nhất tại các cứ điểm Nhật Bản ở Việt Nam. Triển khai tiêu chuẩn thao tác tiếng Nhật sang tiếng Việt, tóm tắt báo cáo hằng ngày tiếng Việt sang tiếng Nhật, sắp xếp quy cách yêu cầu của khách hàng bằng tiếng Anh sang cả tiếng Nhật lẫn tiếng Việt. Giá trị của agent nằm ở chỗ nó dịch theo hệ thuật ngữ nội bộ, chứ không đơn thuần là dịch máy. Nếu tên hạng mục lỗi, tên công đoạn, tên thiết bị được dịch thống nhất theo hệ mã nội bộ thì chất lượng bản dịch sẽ ổn định. Điều này rất khó đạt được bằng công cụ dịch phổ thông.

Điểm mấu chốt trong vận hành là quyết định ngôn ngữ nào là bản gốc. Nếu coi cả hai đều là bản gốc thì mỗi lần cập nhật sẽ sinh ra mâu thuẫn. Luận điểm “ngôn ngữ chia thành ba lớp” ở chương trước đến đây trở thành một hạng mục thiết kế cụ thể.

Trục phán đoán để chọn điểm bắt đầu

Đã liệt kê năm lĩnh vực, nhưng không nên bắt đầu tất cả cùng lúc. Trục phán đoán khi lựa chọn gồm bốn điểm sau.

Nghiệp vụ đầu tiên nên chọn là nghiệp vụ có số lượt nhiều, nguyên liệu nằm trong hệ thống, ảnh hưởng của sai sót nhỏ, và bộ phận thì hợp tác. Ở phần lớn cứ điểm, việc trả lời thời hạn giao hàng hoặc tài liệu đa ngôn ngữ rơi vào nhóm này. Điều quan trọng là không chọn ngay nghiệp vụ đang khó khăn nhất. Mục đích ban đầu là kiểm chứng cơ chế và bộ máy vận hành, chứ không phải tối đa hóa kết quả. Nếu chọn nghiệp vụ khó, các luận điểm cần kiểm chứng sẽ trộn lẫn với cái khó riêng của nghiệp vụ đó, và bạn không phân biệt được nguyên nhân khiến mọi thứ bị tắc.

Lộ trình 90 ngày cho nhà máy tại Việt Nam

Đến đây, chúng ta hạ toàn bộ nội dung trên xuống thành trình tự để thực sự vận hành. Tiền đề là “cứ điểm mà việc dùng AI tạo sinh ở cấp cá nhân đã bắt đầu, nhưng chưa triển khai ở cấp tổ chức”. Xét theo cấu trúc của khu vực, đây là mẫu hình phổ biến nhất.

Day 0-30: Quyết định mà không đụng tới công cụ

Phần lớn việc phải làm trong 30 ngày này là công việc không đụng tới công cụ.

• Hỏi thực trạng sử dụng ở cấp cá nhân: nắm xem ai đang dùng gì cho nghiệp vụ nào, không kèm chế tài. Đây sẽ thành danh sách ứng viên nghiệp vụ mục tiêu
• Thu hẹp nghiệp vụ mục tiêu xuống còn một: chọn theo bốn trục phán đoán ở chương trước. Không bắt đầu từ hai nghiệp vụ trở lên cùng lúc
• Đo thực tế giờ công hiện tại: đo số lượt và thời gian cho mỗi lượt bằng đồng hồ bấm giờ. Đây sẽ là chuẩn cho việc tính ROI sau này
• Gói bốn thiết kế vào một trang: quyền hạn, phạm vi dữ liệu, giám sát, quyền sở hữu
• Quyết tiêu chí đánh giá và tiêu chí dừng: cải thiện cái gì bao nhiêu phần trăm thì đậu, rơi vào trạng thái nào thì dừng
• Kiểm kê dữ liệu tham chiếu: các tài liệu mà nghiệp vụ mục tiêu cần đang nằm ở đâu, bằng ngôn ngữ nào, cập nhật lần cuối khi nào

Sản phẩm đầu ra là văn bản, không phải một hệ thống chạy được. Vì ở giai đoạn này bạn đã có đủ tài liệu để đưa cho nhà cung cấp, độ chính xác của báo giá cũng tăng lên.

Chỗ dễ vấp là không thu hẹp được nghiệp vụ mục tiêu. Khi tập hợp các bộ phận liên quan, mỗi bên mang vấn đề của bộ phận mình vào và phạm vi phình ra. Hãy hội tụ lại bằng cách nói rõ “lần này một nghiệp vụ. Nghiệp vụ tiếp theo ở chu kỳ sau”. Lưu ý rằng 30 ngày này có thể tiến hành chỉ bằng giờ công nội bộ. Trình tự hoàn tất những phán đoán quan trọng nhất khi chưa phát sinh khoản chi lớn chính là biện pháp mạnh nhất để kìm chi phí chìm.

Day 31-60: Chạy nhỏ và thực sự làm việc giám sát

Thu hẹp vào nghiệp vụ mục tiêu để xây dựng PoC và dùng thật trong công việc. Mục đích ở đây không phải xác nhận “nó chạy được”, mà là lấy số đo thực tế.

• Vận hành với nhóm người dùng giới hạn: để vài người phụ trách dùng trong công việc thật. Không triển khai cho toàn bộ
• Thực sự thực hiện giám sát: hằng tuần lấy mẫu, phán định đúng sai. Đo cả giờ công của chính công việc này
• Ghi lại tỷ lệ chỉnh sửa: tỷ lệ dùng được nguyên trạng và tỷ lệ phải sửa
• Đo thực tế lượng tiêu thụ token: lấy giá trị thực tế cho mỗi lượt. Đây là căn cứ để ước tính chi phí vận hành
• Ghi lại phần dữ liệu tham chiếu còn thiếu: các câu hỏi không trả lời được sẽ thành danh sách cần chuẩn bị
• Quyết cách vận hành xử lý ngoại lệ: khi agent không phán đoán được thì chuyển cho ai và chuyển thế nào

Chỗ dễ vấp là giám sát. Nếu “tuần này bận nên bỏ qua” xảy ra hai lần liên tiếp thì từ đó về sau sẽ không làm nữa. Cần bố trí sẵn người phụ trách giám sát và khung thời gian như một phần công việc ngay từ giai đoạn Day 0-30. Một cái bẫy khác là mở rộng người dùng quá nhanh. Càng nhiều người dùng được thì các yêu cầu bổ sung tính năng càng chất lên, và đối tượng cần đánh giá bị nhòe. Day 31-60 nên cố định tính năng và tập trung vào việc đo thực tế mới là đúng.

Day 61-90: Phán đoán và chốt bộ máy

Khi đã có đủ số đo thực tế, hãy ra phán đoán về việc chuyển sang production. Có bốn căn cứ phán đoán.

1. Có đạt tiêu chí đánh giá không: so với tiêu chí đã quyết ở Day 0-30, số đo thực tế ra sao
2. Tỷ lệ chỉnh sửa có nằm trong mức chấp nhận được không: nếu người dùng lần nào cũng phải sửa nhiều thì chuyển production là quá sớm
3. Chi phí vận hành đo thực tế là bao nhiêu: tính chi phí năm từ token đo thực tế và so với hiệu quả cắt giảm
4. Có bộ máy duy trì được việc giám sát không: có bố trí được người và giờ công không

Nếu chỉ cần một trong bốn điều này không đạt, hãy đưa cả phương án tạm dừng chứ không gia hạn vào danh sách lựa chọn. Ý nghĩa của việc chốt tiêu chí dừng từ trước nằm ở đây.

Nếu đạt, hãy chốt bộ máy.

• Quyết chủ sở hữu nghiệp vụ (business owner), phụ trách vận hành, phụ trách kỹ thuật, phụ trách dữ liệu bằng họ tên cụ thể
• Nhúng quy trình cập nhật tài liệu tham chiếu vào quy trình quản lý tài liệu hiện có
• Soạn tài liệu hướng dẫn thao tác bằng tiếng Việt
• Quyết biểu mẫu ghi chép giám sát và nơi lưu trữ
• Chọn một ứng viên cho nghiệp vụ mục tiêu tiếp theo

Thứ thu được ở cuối 90 ngày không phải một hệ thống đã hoàn thiện, mà là căn cứ phán đoán và bộ máy. Giữ đúng trình tự này rốt cuộc lại nhanh hơn so với việc nhắm triển khai toàn công ty ngay từ đầu. Chênh lệch 5,7 lần nằm ở cách dùng 90 ngày này.

Đưa các chính sách hỗ trợ vào kế hoạch ngân sách – ví dụ DEPA và BOI của Thái Lan

Một điểm bổ sung mang tính khu vực: hãy đưa việc kiểm tra các chính sách hỗ trợ công vào kế hoạch.

Trường hợp Thái Lan là ví dụ dễ hình dung. DEPA (Cơ quan Xúc tiến Kinh tế Số) đang triển khai TH-AI Passport (quy mô 1,6 tỷ baht, mở đăng ký ngày 5/6/2026), đồng thời khởi động Coding Thailand 2026 vào ngày 16/3/2026 tại Siam Square SiamScape. Về mặt nhân lực, có ưu đãi thuế lên tới 250% đối với chi phí đào tạo doanh nghiệp liên quan tới phát triển nhân lực. Trong việc triển khai agent, nút thắt thường là phát triển nhân lực chứ không phải chi phí công cụ, nên rất đáng để kiểm tra cách xử lý chi phí đào tạo dưới góc độ thuế khi chốt bộ máy vận hành ở Day 61-90.

Với các cứ điểm đang hưởng ưu đãi của BOI (Ủy ban Đầu tư Thái Lan), cũng nên xác nhận cách xử lý các khoản đầu tư liên quan tới chuyển đổi số. Điều kiện áp dụng, phạm vi đối tượng và thủ tục đăng ký của mỗi chính sách đều theo thông tin mới nhất của cơ quan chủ quản, nên ở đây chúng tôi chỉ nêu như một hạng mục cần kiểm tra ở giai đoạn lập ngân sách.

Hàm ý cho độc giả tại Việt Nam rất rõ: điểm đáng học không phải là bản thân chương trình của Thái Lan, mà là thói quen kiểm tra các ưu đãi thuế và chương trình hỗ trợ chuyển đổi số, phát triển nhân lực đang áp dụng tại địa bàn của mình trước khi chốt ngân sách, đặc biệt với các doanh nghiệp đang hưởng ưu đãi đầu tư tại khu công nghiệp hoặc khu chế xuất. Trình tự thực tế là không lập kế hoạch dựa trên chính sách, mà kiểm tra xem có chính sách nào dùng được cho kế hoạch đã chốt.

Đo lường hiệu quả và cách tính ROI

Chúng ta sắp xếp phương pháp tính toán phục vụ quyết định đầu tư. Vì thiếu tiêu chí đánh giá là yếu tố cản trở lớn nhất với 64%, việc chốt trước công thức tính chính là đối sách trực tiếp.

Cách tư duy cơ bản: nhìn theo bốn hạng mục

Không cần làm phức tạp. Hãy ước tính lợi ích năm theo bốn hạng mục sau rồi so với chi phí.

Trục chính của quyết định đầu tư đặt ở ①. Các mục ②–④ có giá trị lớn nhưng cần quá nhiều giả định để định lượng, và làm giảm sức thuyết phục của bản tính toán. Cách lành mạnh là bắt đầu từ phạm vi mà chỉ riêng ① đã cho thấy triển vọng hoàn vốn, còn ②–④ thì kèm theo với vị trí “ngoài ra còn kỳ vọng thêm những hiệu quả này”.

Ví dụ tính toán cụ thể: nghiệp vụ trả lời thời hạn giao hàng

Lấy lĩnh vực 1 ở chương trước làm ví dụ để tính thử. Dưới đây là ví dụ tính toán nhằm minh họa phương pháp, không phải là con số kết quả thực tế của một dự án cụ thể; các khoản tiền vẫn được đặt theo mặt bằng thị trường Thái Lan giống bảng chi phí ở chương trước. Hãy thay bằng số đo thực tế của doanh nghiệp bạn khi sử dụng.

Tiền đề

• Nghiệp vụ mục tiêu: trả lời câu hỏi về thời hạn giao hàng từ khách hàng
• Số lượt: 50 lượt/ngày × 240 ngày làm việc trong năm = 12.000 lượt/năm
• Thời gian hiện tại: trung bình 12 phút cho mỗi lượt (tra cứu nhiều hệ thống + soạn câu trả lời)
• Thời gian sau triển khai: trung bình 4 phút cho mỗi lượt (agent tạo bản nháp, con người kiểm tra rồi gửi)
• Đơn giá nhân công: 400 THB/giờ (theo tổng chi phí nhân sự của nhân viên khối quản lý)

Tính lợi ích

• Giờ công hiện tại trong năm: 12 phút × 12.000 lượt ÷ 60 = 2.400 giờ
• Giờ công sau triển khai trong năm: 4 phút × 12.000 lượt ÷ 60 = 800 giờ
• Giờ công cắt giảm: 1.600 giờ/năm
• Quy ra tiền: 1.600 giờ × 400 THB = 640.000 THB/năm

Tính chi phí

• Chi phí ban đầu: 900.000 THB (gần cận dưới của khung B, bao gồm kết nối với hệ thống hiện có)
• Chi phí vận hành năm: 258.400 THB

– Phí token và API: khoảng 140.000 THB

– Chi phí nhân sự cho giám sát: 8 giờ/tháng × 12 tháng × 400 THB = 38.400 THB

– Bảo trì và cập nhật dữ liệu tham chiếu: khoảng 80.000 THB

Tính hoàn vốn

• Lợi ích ròng năm: 640.000 − 258.400 = 381.600 THB/năm
• Số năm hoàn vốn đơn giản: 900.000 ÷ 381.600 = khoảng 2,4 năm

Với các hệ thống hiện trường trong ngành sản xuất, cảm nhận chung là hoàn vốn được trong 2–4 năm thì quyết định đầu tư dễ được thông qua. Bản tính toán này nằm trong phạm vi đó.

Ba điểm dễ tính sai

Phép tính trên rất đơn giản, nhưng trong thực tế dễ sai ở ba điểm sau.

Sai lầm 1: Không đưa chi phí vận hành vào phần chi phí

Nếu chỉ lấy chi phí ban đầu để tính số năm hoàn vốn thì được 900.000 ÷ 640.000 = khoảng 1,4 năm, lệch rất xa so với con số thực tế 2,4 năm. Đặc biệt chi phí token và chi phí nhân sự cho giám sát không xuất hiện trên báo giá nên phải chủ động cộng vào.

Sai lầm 2: Đặt thời gian sau triển khai quá lạc quan

Ta hay muốn đặt tiền đề kiểu “12 phút mỗi lượt xuống còn 1 phút”, nhưng thời gian con người kiểm tra chắc chắn vẫn còn lại. Nếu đặt trên bàn giấy mà không dùng số đo thực tế của Day 31-60 thì phần này sẽ bị ước tính thấp.

Sai lầm 3: Chưa quyết dùng thời gian đã tiết kiệm vào việc gì

Dù cắt giảm được 1.600 giờ, nếu không làm gì với số giờ đó thì hiệu quả trên sổ sách tài chính vẫn không xuất hiện. Bạn sẽ đáp ứng việc tăng sản lượng mà không tăng người, hay chuyển sang các nghiệp vụ có giá trị gia tăng cao hơn? Chỗ này mà mập mờ thì sau khi vận hành sẽ nhận được đánh giá “nhẹ đi thì có nhẹ, nhưng con số thì không đổi”.

Văn bản hóa tiêu chí đánh giá trước khi triển khai

Quan trọng hơn cả bản thân công thức tính là văn bản hóa phép tính này ngay từ giai đoạn Day 0-30.

Nếu định đo hiệu quả sau khi đã triển khai, bạn sẽ không có số đo thực tế trước triển khai để làm mốc so sánh. Chỉ có thể đánh giá kiểu “hình như có nhanh hơn”, và cả quyết định đầu tư lẫn quyết định duy trì đều không có căn cứ. Việc đo số lượt và thời gian hiện tại chỉ làm được trước khi triển khai.

Trong văn bản tiêu chí đánh giá, tối thiểu hãy viết bốn thứ sau. Chỉ số đo (thời gian, số lượt, tỷ lệ chỉnh sửa), cách đo (ai đo, đo khi nào, đo thế nào), ngưỡng đậu (đạt mức nào thì chuyển production), ngưỡng dừng (ở mức nào thì dừng).

Đối sách cho yếu tố cản trở lớn nhất là “thiếu tiêu chí đánh giá 64%” chính là viết ra bốn dòng này. Không phải vấn đề kỹ thuật, cũng không phải vấn đề ngân sách, mà là vấn đề văn bản hóa.

Câu hỏi thường gặp (FAQ)

Triển khai AI agent tốn khoảng bao nhiêu tiền?

Khác nhau rất lớn tùy hình thức triển khai. Theo mặt bằng tham khảo của thị trường Thái Lan, chi phí ban đầu vào khoảng 100.000 – 500.000 THB với việc cấu hình dùng dịch vụ có sẵn, khoảng 800.000 – 3.000.000 THB với việc xây dựng agent chuyên biệt thu hẹp vào 1–2 nghiệp vụ, và khoảng 3.000.000 – 15.000.000 THB với việc triển khai nhiều nghiệp vụ kèm tích hợp hệ thống lõi. Tuy nhiên con số này dao động mạnh theo nghiệp vụ mục tiêu, số hệ thống cần tích hợp và tình trạng chuẩn bị của dữ liệu hiện có.

Khi đánh giá báo giá, việc xác nhận chi phí vận hành quan trọng hơn chi phí ban đầu. Ba khoản — phí token và API, chi phí nhân sự cho giám sát, chi phí cập nhật dữ liệu tham chiếu — vừa khó xuất hiện trên báo giá, vừa phát sinh liên tục. Không so sánh theo tổng ba năm thì sẽ phán đoán sai. Nếu muốn kìm chi phí, hãy bắt đầu bằng cách thu hẹp vào một nghiệp vụ đúng như lộ trình 90 ngày. Lấy báo giá sau khi đã chốt thiết kế thì phạm vi rõ ràng, nhờ đó độ dao động của số tiền cũng nhỏ hơn.

AI agent khác RPA ở chỗ nào?

Khác ở việc ai nắm quyền phán đoán. RPA thì con người viết toàn bộ trình tự và nó thực hiện đúng như vậy. Gặp đầu vào ngoài dự kiến thì dừng. AI agent được giao mục tiêu và tự quyết trình tự. Trong tình huống ngoài dự kiến thì tự thử cách khác.

Khác biệt này vừa là giá trị vừa là rủi ro. Thứ dừng lại thì an toàn vì nó không làm gì, nhưng nghiệp vụ không tiến cho tới khi có người xử lý. Thứ tự phán đoán thì đẩy được nghiệp vụ đi, nhưng cũng có thể thực thi một phán đoán sai. Vì vậy phạm vi quyền hạn và thiết kế giám sát trở thành bắt buộc.

Về mặt thực tiễn, không cần bỏ RPA để thay bằng agent. Với nghiệp vụ có trình tự cố định hoàn toàn thì RPA rẻ hơn và chắc chắn hơn. Vì phần lớn nguyên nhân khiến RPA dừng là sự dao động của định dạng đầu vào, nên cấu hình chèn AI tạo sinh vào đó để chỉnh lại định dạng cũng là phương án có hiệu quả chi phí cao nhất trong nhiều tình huống.

Thời gian triển khai mất bao lâu?

Nếu thu hẹp vào một nghiệp vụ thì 90 ngày là mức tham chiếu để có đủ căn cứ phán đoán. Phân bổ gồm 30 ngày nắm thực trạng và thiết kế, 30 ngày PoC trong phạm vi giới hạn cùng giám sát, và 30 ngày phán đoán chuyển production và chốt bộ máy.

Điều cần lưu ý là theo khảo sát, thời gian PoC trung bình là 4,7 tháng, và sau đó 64% bị đình trệ từ 6 tháng trở lên. Nguyên nhân chính khiến thời gian kéo dài không phải kỹ thuật, mà là việc lặp đi lặp lại câu “theo dõi thêm một chút nữa” khi không có tiêu chí phán đoán. Chốt tiêu chí dừng ngay tại thời điểm bắt đầu sẽ ngăn được sự đình trệ này. Ngoài ra, nếu tài liệu cần cho agent tham chiếu chưa được chuẩn bị thì cần thêm thời gian riêng cho việc đó. Vì thu hẹp nghiệp vụ mục tiêu cũng thu hẹp luôn phạm vi cần chuẩn bị, nguyên tắc “bắt đầu từ một nghiệp vụ” phát huy tác dụng cả ở đây.

Cứ điểm quy mô nhỏ có triển khai được không?

Được. Thậm chí cứ điểm nhỏ còn có mặt lợi thế. Vì ít bên liên quan nên việc đạt đồng thuận về quyền hạn và phạm vi dữ liệu nhanh hơn. Quyền sở hữu cũng dễ quyết hơn. Các nguyên nhân hàng đầu khiến 88% dừng ở mức PoC là ma sát quản trị và thiếu quyền sở hữu ở cấp tổ chức, và những thứ này càng nghiêm trọng khi tổ chức càng lớn.

Bất lợi về mặt quy mô nằm ở số lượt. Vì ROI được quyết bởi “thời gian cắt giảm mỗi lượt × số lượt”, nghiệp vụ có số lượt ít sẽ khó ra hiệu quả. Cách đúng là phán đoán theo số lượt của nghiệp vụ mục tiêu, chứ không theo số nhân viên. Với nghiệp vụ chỉ vài lượt mỗi ngày thì đơn giản hóa trình tự còn hiệu quả hơn agent hóa. Ở cứ điểm nhỏ, trình tự thực tế là bắt đầu từ việc cấu hình dùng dịch vụ có sẵn (khung A), xác nhận hiệu quả rồi mới xem xét xây dựng loại chuyên biệt.

Cứ điểm tại Việt Nam có trao đổi bằng tiếng Nhật được không?

Được. TOMAS TECH đặt cứ điểm tại Bangkok và làm việc bằng tiếng Nhật, tiếng Thái và tiếng Anh; với các cứ điểm ngoài Thái Lan, việc trao đổi được thực hiện bằng tiếng Nhật hoặc tiếng Anh. Tại các nhà máy Nhật Bản trong khu vực, mô hình phân công phổ biến là quản lý người Nhật thảo luận bằng tiếng Nhật còn nhân viên bản địa vận hành bằng tiếng bản địa, và việc thiết kế cần lấy cấu trúc này làm tiền đề.

Điều quan trọng trên thực tế là không để mọi thứ khép kín trong tiếng Nhật. Nếu chính sách, tài liệu hướng dẫn thao tác và tài liệu tham chiếu đều chỉ có bản tiếng Nhật thì trên thực tế chúng không tồn tại đối với nhân viên bản địa. Xét việc 72% nhân viên tại Thái Lan đã dùng AI trong công việc, và khả năng một cấu trúc tương tự cũng đang hình thành tại Việt Nam, thì việc chuẩn bị bằng ngôn ngữ mà nhân viên bản địa đọc được là điều kiện tiên quyết để nó bén rễ.

Điều tương tự cũng đúng trong quan hệ với trụ sở chính Nhật Bản. Phía cứ điểm cụ thể hóa “dùng vào nghiệp vụ nào, dùng thế nào” rồi trình lên trụ sở sẽ giúp cuộc thảo luận tiến xa hơn so với một phương châm trừu tượng do trụ sở chủ đạo.

Có phải thay hệ thống lõi hiện có mới triển khai được không?

Không cần thay. Tuy nhiên, công việc làm cho dữ liệu lấy ra được từ hệ thống hiện có là cần thiết. Từ chỗ yếu tố cản trở việc mở rộng đứng đầu là “độ phức tạp khi tích hợp hệ thống legacy 63%”, có thể thấy đây là luận điểm kỹ thuật lớn nhất.

Cách tiến hành thực tế là không đụng vào hệ thống hiện có mà tạo một kênh truy cập chỉ đọc. Hãy xác nhận quyền đọc cơ sở dữ liệu, việc trích xuất dữ liệu định kỳ, và sự tồn tại của API, rồi dựng cấu hình chỉ cần đọc là đủ. Việc tích hợp có kèm ghi dữ liệu có phạm vi ảnh hưởng lớn nên hãy để lại giai đoạn sau. Ngoài ra, công việc này vẫn còn lại như tài sản kể cả khi agent không dùng được. Thứ nên làm trước chính là khoản đầu tư ở phía còn lại này.

Quản lý rủi ro rò rỉ thông tin thế nào?

Có hai đối tượng cần quản lý. Rò rỉ từ chính agent do tổ chức triển khai và rò rỉ từ việc sử dụng cá nhân mà tổ chức không nắm được.

Cái thứ nhất quản lý được bằng thiết kế. Phân định tường minh phạm vi dữ liệu cho tham chiếu, loại trừ nhân sự, lương, thông tin sức khỏe, và thực sự kiểm chứng rằng đã loại trừ được. Nếu thiết kế theo hướng kế thừa quyền của người dùng sang agent thì cũng bịt được lỗ hổng nhìn thấy dữ liệu vốn không được phép nhìn. Lưu log thực thi thì việc truy vết sau sự cố cũng khả thi.

Cái nghiêm trọng hơn trên thực tế là vế thứ hai. Tại Thái Lan, 72% cá nhân nhân viên dùng AI trong công việc trong khi tỷ lệ triển khai của tổ chức chỉ 10,7%; tại Việt Nam, tỷ lệ tổ chức là 23% — cao hơn nhưng vẫn có nghĩa là hơn ba phần tư tổ chức chưa có phương án chính thức. Cấm đoán thì thiếu tính thực thi. Việc cung cấp một môi trường dùng được ở cấp tổ chức mới là biện pháp chống rò rỉ thực tế nhất. Đồng thời, hãy ban hành chính sách, cung cấp bằng ngôn ngữ mà nhân viên bản địa đọc được, và sắp xếp quan hệ với quy định bảo vệ dữ liệu cá nhân tại nước sở tại. Ba điểm này đáng để bắt tay vào bất kể có triển khai agent hay không.

Kết luận

Thứ quyết định thành bại của việc triển khai AI agent không phải là chọn model hay chọn công cụ. Đó là việc bạn đã chốt hay chưa chốt bốn điểm “quyền hạn – phạm vi dữ liệu – giám sát – quyền sở hữu” trước khi bước vào PoC. 88% dừng lại ở mức PoC là vì bốn điểm này bị đẩy lùi lại sau, và người ta vào việc bằng câu “thử xem có dùng được không”.

Xin tóm tắt các ý chính của bài viết.

• 88% không đạt tới production. Các yếu tố cản trở hàng đầu là thiếu tiêu chí đánh giá 64%, ma sát quản trị 57%, độ tin cậy của model 51%. Hai yếu tố đầu không liên quan tới năng lực của model mà bắt nguồn từ những thứ chưa được quyết định
• 78% có PoC, chỉ 14% đạt tới vận hành toàn công ty. 64% bị đình trệ từ 6 tháng trở lên, thời gian PoC trung bình cho tới lúc đình trệ là 4,7 tháng. Chi phí chìm trung bình của dự án thất bại khoảng 2,1 triệu USD
• Nhật Bản có tỷ lệ dùng AI tạo sinh trong công việc 55,2%, thua Trung Quốc 95,8%, Mỹ 90,6% và Đức 90,3%. Theo McKinsey, 62% ở giai đoạn thử nghiệm và 23% đã scale. Chỉ cần vận hành ổn định một nghiệp vụ là đã thuộc nhóm 20% dẫn đầu
• Thái Lan có cấu trúc đảo ngược: tổ chức 10,7% nhưng cá nhân nhân viên 72%. Việt Nam ở mức 23%, cao hơn Thái Lan nhưng còn cách xa Singapore 69% — nghĩa là dư địa tạo khác biệt vẫn rộng, và sức cản nhỏ ở hiện trường cũng là một thế mạnh. Mức trưởng thành số 2,12/4,0 của Thái Lan cho thấy nhiều cứ điểm cần chuẩn bị nền tảng dữ liệu trước cả khi nói tới agent
• Bốn thiết kế mới là phần lõi. Quyền hạn là “hành động với tư cách đại diện của ai”, phạm vi dữ liệu là “cho đọc cái gì và không cho đọc cái gì”, giám sát là “phát hiện suy giảm bằng cách nào”, quyền sở hữu là “đây là cơ chế của ai”. Tổ chức đặt bộ phận chuyên trách trước khi mở rộng có tỷ lệ thành công cao gấp 5,7 lần
• Hãy phán đoán chi phí theo phần vận hành. Phí token và API, chi phí nhân sự cho giám sát, chi phí cập nhật dữ liệu tham chiếu đều khó xuất hiện trên báo giá. Thứ nên làm trước là khoản đầu tư ở phía còn lại kể cả khi thất bại (lấy được dữ liệu ra khỏi hệ thống hiện có và chuẩn bị tài liệu nghiệp vụ)
• Tạo ra căn cứ phán đoán trong 90 ngày. 30 ngày đầu không đụng tới công cụ mà viết thiết kế và tiêu chí thành văn bản, 30 ngày tiếp theo đo thực tế PoC phạm vi giới hạn cùng việc giám sát, 30 ngày cuối phán đoán chuyển production và chốt bộ máy
• ROI đặt trục chính ở việc cắt giảm giờ công. Trừ đi chi phí vận hành, giữ lại thời gian con người kiểm tra, và quyết dùng thời gian tiết kiệm được vào việc gì. Tiêu chí đánh giá chỉ tạo ra được trước khi triển khai

Về môi trường bên ngoài, có dự báo của Gartner rằng tới cuối năm 2026, 40% ứng dụng doanh nghiệp sẽ nhúng AI agent, và quy mô thị trường cũng được dự kiến mở rộng lên 7,8 tỷ USD trong năm 2026 (tăng 50% so với năm trước). Kể cả bạn không tự xây dựng, agent vẫn sẽ đi vào bên trong các ứng dụng hiện có. Khoảng thời gian còn có thể trì hoãn việc thiết kế quyền hạn và phạm vi dữ liệu không còn dài.

Cuối cùng, xin nhắc lại một lần nữa. Hãy quyết bốn điểm trước khi thử. Đó là toàn bộ nội dung của bài viết này.

Công việc chốt bốn thiết kế có thể bắt đầu từ chỗ đặt cạnh nhau hiện trạng của nghiệp vụ mục tiêu và những dữ liệu có thể tham chiếu, trước cả khi ký hợp đồng công cụ. TOMAS TECH tại Thái Lan, thông qua việc xây dựng các hệ thống hiện trường bao gồm PEGASUS – hệ thống quản lý sản xuất và năng lượng, đã xử lý phần việc lấy dữ liệu nhà máy ra từ đâu và nối nó vào các phán đoán nghiệp vụ như thế nào, và cũng đồng hành cùng các doanh nghiệp sản xuất Nhật Bản đang hoạt động trong khu vực ASEAN, bao gồm Việt Nam. Chỉ riêng những điểm ở giai đoạn thiết kế như “nên bắt đầu từ nghiệp vụ nào thì hợp với doanh nghiệp mình”, “có thể lấy dữ liệu ra khỏi hệ thống lõi hiện có tới đâu” cũng có thể trao đổi được, và nếu bạn mới chỉ đang ở giai đoạn bắt đầu cân nhắc trong nội bộ thì cũng hoàn toàn không sao. Sau khi lắng nghe tình hình cứ điểm của bạn, chúng tôi sẽ sắp xếp và trình bày các phương án tiến hành. Mọi trao đổi xin gửi qua biểu mẫu liên hệ.