Microsoft Copilot — cách triển khai 2026, chi phí và phân quyền

Nhận được thông báo từ trụ sở chính tại Nhật rằng “sẽ đưa Copilot vào toàn công ty”, hoặc ngược lại muốn tự mình đề xuất lên trụ sở — thời gian gần đây chúng tôi nhận được ngày càng nhiều câu hỏi về việc triển khai Microsoft Copilot từ các doanh nghiệp sản xuất Nhật Bản tại Thái Lan. Nhưng chỗ vấp trong quá trình cân nhắc này không nằm ở chuyện mô hình thông minh đến đâu. Copilot không phá vỡ phân quyền, nhưng đổi lại, nó đưa ra ánh sáng mọi thông tin mà một người về mặt kỹ thuật có thể tiếp cận, chỉ bằng một câu hỏi bằng ngôn ngữ tự nhiên. Nói cách khác, sự lỏng lẻo của các thiết lập chia sẻ bị bỏ mặc suốt nhiều năm sẽ hiện ra ngay trong ngày đầu triển khai. Bài viết này sắp xếp lại cách nhìn về chi phí, cách rà soát phân quyền, cách phân định nghiệp vụ, và những điểm riêng của một chi nhánh ở nước ngoài.

Bài viết này bàn gì và không bàn gì

Các bài viết về triển khai AI tạo sinh thường nghiêng về một trong hai thái cực: giới thiệu tính năng theo kiểu “làm được những gì”, hoặc cảnh báo trừu tượng kiểu “sợ rò rỉ thông tin”. Nhưng thứ thực sự ngốn giờ công và chi phí trong một dự án triển khai không phải là tính năng, cũng không phải nỗi sợ, mà là phần chuẩn bị nền cần làm xong trước khi mua bản quyền. Bỏ qua phần này, doanh nghiệp có nguy cơ vừa trả tiền vừa tự mở ra một lỗ hổng trong dòng chảy thông tin nội bộ.

Phạm vi của bài viết như sau.

Nếu bạn muốn nhìn bức tranh tổng thể bao gồm cả những lựa chọn ngoài Copilot, chúng tôi đã sắp xếp các trục so sánh của những công cụ chính trong bài So sánh AI tạo sinh cho doanh nghiệp 2026. Bài viết lần này đào sâu vào một lựa chọn trong số đó: “đưa Copilot vào môi trường Microsoft 365”.

Xin lưu ý thêm, các mức giá xuất hiện trong bài được ghi rõ ràng theo hai nhóm tách biệt: giá đang niêm yết trên trang giá chính thức của Microsoft tại thời điểm viết bài, và các thông tin thứ cấp từ báo chí. Giá bản quyền là lĩnh vực thường xuyên được điều chỉnh, nên khi lập báo giá thực tế, bạn hãy luôn kiểm tra lại với thông tin chính thức mới nhất và với các đối tác của Microsoft.

Trước khi triển khai Microsoft Copilot, hãy thống nhất “Copilot là cái gì”

Không phải “một mô hình”, mà là “một cửa sổ nối vào dữ liệu của chính công ty”

Khi giải thích về Copilot trong nội bộ, có một nhận thức nên thống nhất ngay từ đầu: Copilot không phải là một chatbot trả lời dựa trên kiến thức trên Internet, mà là một cửa sổ được kết nối vào dữ liệu nằm bên trong tenant Microsoft 365 của chính công ty bạn.

Khác biệt này làm thay đổi tận gốc các điều kiện tiền đề của việc triển khai. Với một chatbot phổ thông, bạn có thể phát cho mọi người mà không cần bận tâm tới quan hệ với dữ liệu nội bộ. Nhưng Copilot tạo câu trả lời bằng cách tham chiếu tới chính tài sản thông tin của công ty: email, hội thoại trên Teams, tệp trên SharePoint, vùng cá nhân trên OneDrive, lịch làm việc. Do đó, chất lượng câu trả lời phụ thuộc rất mạnh vào chất lượng và phạm vi thông tin mà người đó được phép tiếp cận.

Điểm quan trọng ở đây là tính chất Copilot không phá vỡ phân quyền. Một tệp mà nhân viên không có quyền truy cập thì dù có hỏi Copilot cũng sẽ không hiện ra. Đặc điểm này thường được dùng để giải thích rằng “vì vậy nên nó an toàn”. Nhưng hàm ý về mặt thực tiễn lại đi theo chiều ngược lại.

Lâu nay, lý do những tệp có thiết lập chia sẻ lỏng lẻo chưa gây thiệt hại thực tế là vì không ai lần ra được chúng. Việc gõ đúng từ khóa vào ô tìm kiếm của SharePoint rồi lọc ra thứ mình cần từ hàng loạt kết quả vốn tốn không ít công sức. Còn Copilot, trước một câu hỏi bằng ngôn ngữ tự nhiên như “tổng hợp giúp tôi các tài liệu viết về việc rà soát thù lao ban lãnh đạo kỳ này”, sẽ dò xuyên suốt phạm vi mà người dùng có quyền truy cập, rồi tóm tắt và trình bày lại. Chi phí dò tìm gần như bằng không chính là thứ khiến sự lỏng lẻo của các thiết lập cũ lộ ra cùng một lúc.

Hiểu được cấu trúc này thì thứ tự ưu tiên về thời gian trong dự án triển khai sẽ thay đổi. Bạn sẽ nhận ra rằng thay vì dồn thời gian cho các buổi đào tạo về cách viết prompt, việc nắm được ai đang ở trạng thái tiếp cận được cái gì có mức độ ưu tiên cao hơn nhiều.

Tên gọi lẫn lộn khiến các cuộc họp nội bộ đi lệch hướng

Một chuyện nữa hay xảy ra ở giai đoạn đầu cân nhắc là sự lẫn lộn về tên gọi. Có nhiều sản phẩm cùng mang tên “Copilot”, và mỗi cái khác nhau cả về đối tượng, chi phí lẫn mô hình phân quyền. Không hiếm trường hợp những người ngồi trong cùng một cuộc họp đang nói về những thứ khác nhau.

Khi tờ trình nội bộ chỉ ghi vỏn vẹn “triển khai Copilot”, kế toán sẽ nghĩ tới chi phí, bộ phận IT nghĩ tới phân quyền, còn hiện trường nghĩ tới hỗ trợ công việc. Chỉ cần chốt trong một dòng ngay từ đầu rằng đối tượng là cái nào, tốc độ của toàn bộ các thảo luận sau đó sẽ khác hẳn. Trong bài viết này, khi ghi “Copilot”, về nguyên tắc chúng tôi đang nói tới Microsoft 365 Copilot.

Cái gì là mới, và cái gì không mới

Khi cần thống nhất kỳ vọng trong nội bộ về Copilot, bảng sắp xếp dưới đây sẽ hữu ích.

Xin hãy chú ý dòng cuối cùng. Copilot không thay đổi mô hình phân quyền. Nó không tạo ra quyền mới, cũng không nới lỏng quyền hiện có. Thứ thay đổi chỉ là mức độ dễ dàng để chạm tới thông tin nằm trong phạm vi quyền đã có. Nếu chia sẻ được điểm này trong nội bộ, bạn sẽ tránh được cách giải thích sai lệch kiểu “Copilot đã tự ý làm lộ thông tin”. Điều thực sự xảy ra là: thứ vốn đã nhìn thấy được, nay bị nhận ra là đang nhìn thấy được.

Chi phí và các gói giá của Microsoft 365 Copilot năm 2026

Ý nghĩa của việc đây là một add-on

Điều đầu tiên cần nắm khi ước tính chi phí là Microsoft 365 Copilot được cung cấp theo hình thức add-on. Không thể ký riêng lẻ, mà phải cộng thêm lên trên một bản quyền nền thuộc diện đủ điều kiện. Với Copilot Business dành cho doanh nghiệp vừa và nhỏ, bản quyền nền được yêu cầu là Microsoft 365 Business Standard trở lên.

Điều này có nghĩa là tùy vào cấu hình bản quyền hiện tại, ngoài chi phí add-on còn có thể phát sinh chi phí nâng cấp bản quyền nền. Ví dụ, khi muốn đưa Copilot vào một bộ phận đang dùng Business Basic, trước hết phải chuyển đổi lên Standard trở lên. Phần “nâng nền” này rất dễ bị bỏ sót nếu bạn mới chỉ nhìn vào giá add-on của Copilot.

Dưới đây là các mức giá đang được niêm yết trên trang giá chính thức của Microsoft.

Nhìn vào giá của các gói tích hợp, bạn sẽ thấy được chênh lệch so với phương án cộng dồn riêng lẻ bản quyền nền và add-on. Tổ hợp nào có lợi hơn còn tùy vào cấu hình bản quyền hiện có, thời điểm gia hạn hợp đồng và số lượng ghế. Vì phán đoán này phụ thuộc vào tình trạng hợp đồng của từng công ty, chúng tôi không thể nói một cách chung chung rằng “bên này lợi hơn”. Tuy nhiên, nếu rà soát trước cơ cấu bản quyền nền hiện tại (Basic, Standard, Premium mỗi loại bao nhiêu người), bạn sẽ có được vạch xuất phát để so sánh.

Về mức giá dành cho doanh nghiệp lớn, có thông tin báo chí đưa ra con số 4.497 yên mỗi người mỗi tháng. Đây không phải giá niêm yết trên trang chính thức mà là thông tin thứ cấp từ báo chí, nên nếu đưa vào tài liệu nội bộ, bạn hãy ghi rõ tính chất của nguồn và coi đó là con số cần xác nhận lại bằng báo giá chính thức.

Những thay đổi kể từ đầu năm 2026

Bước vào năm 2026, hệ thống bản quyền của Copilot và các sản phẩm xung quanh đã có một số chuyển động. Tất cả đều ảnh hưởng tới tiền đề của kế hoạch triển khai nên rất đáng nắm. Phần dưới đây chủ yếu dựa trên thông tin thứ cấp, vì vậy điều kiện áp dụng chính xác xin hãy xác nhận với Microsoft hoặc với đối tác đang ký hợp đồng.

Thay đổi liên quan tới các tổ chức từ 2.000 ghế trở lên là điểm quan trọng, vì ở những doanh nghiệp có tenant quy mô lớn, tiền đề của cách làm “chỉ đưa Copilot vào một vài bộ phận” có thể đã khác đi. Lý do là những chức năng vốn dùng được miễn phí trong một phạm vi nhất định được cho là không còn khả dụng trên các ghế chưa được gán add-on. Với các tập đoàn lớn mà trụ sở Nhật và các chi nhánh nước ngoài như Thái Lan dùng chung một tenant, bạn nên kiểm tra xem tổng số ghế có vượt ngưỡng này hay không.

Ngoài ra, việc điều chỉnh giá bản quyền nền vào ngày 1 tháng 7 là khoản tăng chi phí phát sinh độc lập với việc cân nhắc Copilot. Khi giải thích rằng “triển khai Copilot sẽ làm chi phí tăng chừng này”, nếu trộn lẫn phần điều chỉnh giá này vào, thảo luận trong nội bộ sẽ lệch sang hướng “Copilot đắt quá”. Chúng tôi khuyến nghị tách bạch phần tăng do Copilot và phần tăng phát sinh không liên quan tới Copilot.

Hãy ước tính chi phí theo 5 lớp

Một kế hoạch ngân sách chỉ nhìn vào chi phí bản quyền rất dễ thiếu hụt ở các giai đoạn sau. Chi phí thực tế phát sinh khi triển khai Copilot chia thành 5 lớp sau.

Trong số này, lớp thứ 3 (rà soát phân quyền và chỉnh trang dữ liệu) mới chính là phần thân của dự án triển khai Copilot. Đây là luận điểm trung tâm của bài viết. Bản quyền chỉ cần đặt mua là hôm sau dùng được, nhưng rà soát phân quyền là một cuộc khảo sát thực trạng nội bộ, không phải công việc có thể khoán trọn cho bên ngoài. Và rủi ro của việc bỏ qua lớp này rồi mở rộng triển khai sẽ không hiện ra dưới dạng vấn đề chi phí, mà dưới dạng vấn đề quản lý thông tin.

Lớp thứ 5 là “vận hành” cũng hay bị bỏ sót. Bản quyền Copilot, nếu người được phát không dùng, sẽ tiếp tục chảy ra dưới dạng chi phí. Nếu ngay từ đầu bạn đưa vào thiết kế một quy trình mỗi quý xem lại tình hình sử dụng và chuyển bản quyền từ người không dùng sang người có dùng, thì lãng phí sẽ không tích tụ. Triển khai mà chưa quyết ai đảm nhiệm việc này thì một năm sau sẽ rơi vào trạng thái “không ai nhìn tới”.

Những thứ nên đo trước khi lập ngân sách

Có một số hạng mục nếu xác nhận trong nội bộ trước khi đi lấy báo giá sẽ giúp độ chính xác tăng lên. Tổng hợp thủ công cũng không sao, bạn hãy nắm trước các con số sau.

Đặc biệt dòng thứ hai và thứ ba sẽ quyết định quy mô của việc rà soát phân quyền được bàn ở chương sau. Nếu đi trao đổi với nhà cung cấp mà không có các con số này, báo giá sẽ hoặc dừng lại ở mức “phải khảo sát mới biết được”, hoặc ngược lại được đưa ra trên những tiền đề không khớp với thực tế.

Rà soát phân quyền cần làm trước khi triển khai (đối sách chia sẻ quá mức)

Chính vì không phá vỡ phân quyền nên sự lỏng lẻo hiện ra nguyên vẹn

Xin nhắc lại, chương này là hạt nhân của bài viết. Copilot không phá vỡ phân quyền. Nó không tự ý đọc ra những thông tin mà người dùng không có quyền truy cập. Vấn đề vẫn xảy ra là bởi ở nhiều tổ chức, “phạm vi tiếp cận được về mặt kỹ thuật” đang rộng hơn “phạm vi nên được tiếp cận theo nghiệp vụ”.

Trạng thái này thường được gọi là chia sẻ quá mức (oversharing). Có khảo sát cho thấy trung bình mỗi tenant doanh nghiệp tồn tại từ 150 đến 300 site SharePoint bị chia sẻ quá mức. Không thể áp thẳng con số này vào công ty bạn, nhưng nó là căn cứ để nói rằng không nên kết luận “chỗ mình ổn thôi” khi chưa có cơ sở.

Chia sẻ quá mức hình thành không phải do ác ý. Phần lớn trường hợp là sự tích tụ của những thao tác vận hành thường ngày như sau.

Dòng thứ tư, “nhãn chỉ gắn ở cấp container”, là điểm bị hiểu nhầm nhiều nhất. Nhãn bảo vệ thông tin gắn cho container (site hoặc team) không tự động được kế thừa xuống các item bên trong (từng tệp riêng lẻ). Cách hiểu “để trong site Confidential nên đã được bảo vệ” không thành lập khi cơ chế kiểm soát dựa trên nhãn. Copilot coi các item chưa gắn nhãn là đối tượng tham chiếu thông thường. Những tổ chức chỉ vận hành nhãn ở cấp site nhất định phải kiểm tra điểm này.

Hãy hình dung cụ thể điều gì sẽ xảy ra

Giải thích trừu tượng rằng “có rủi ro rò rỉ thông tin” sẽ không làm lay chuyển ý thức cảnh giác trong nội bộ. Trình bày bằng các ví dụ cụ thể như dưới đây sẽ dễ truyền đạt hơn. Tất cả đều là những điều có thể xảy ra mà không hề phá vỡ phân quyền.

Những trường hợp này không phải do Copilot phá hỏng thứ gì, mà chỉ là việc chạm tới thông tin vốn đã có quyền chạm tới nay trở nên dễ dàng hơn. Chính vì vậy, đối sách phải đi theo hướng “sửa lại thiết lập chia sẻ” chứ không phải “hạn chế Copilot”.

Trình tự đối sách: hiện hóa, chặn phơi lộ, gắn nhãn, mở rộng

Rà soát phân quyền là công việc mà khối lượng thay đổi rất lớn tùy vào việc bạn có giữ đúng trình tự hay không. Ngược lại, làm sai thứ tự thì sẽ không bao giờ xong. Dòng chảy được khuyến nghị như sau.

Xin lưu ý, trong chương này chúng tôi gọi thứ tự công việc là “công đoạn”. Nó khác về độ hạt so với “giai đoạn” được bàn trong phần lộ trình ở sau, mong bạn không nhầm lẫn hai khái niệm.

Điểm quan trọng về mặt thực tiễn ở đây là tính chất của công đoạn 2 và công đoạn 3 khác nhau. “Chặn phơi lộ” ở công đoạn 2 là biện pháp có thể thực hiện trong thời gian tương đối ngắn, bằng cách loại ra khỏi phạm vi tham chiếu của Copilot. Trong khi đó, “gắn nhãn” ở công đoạn 3 là việc chỉnh trang lâu dài bắt đầu từ xây dựng quy tắc phân loại thông tin, và là công cuộc kéo dài từ vài tháng đến hàng năm.

Lý do nhiều tổ chức thất bại là vì họ lấy việc hoàn thành công đoạn 3 làm tiền đề cho công đoạn 4. Nếu quyết rằng chưa gắn nhãn xong thì chưa mở rộng, dự án sẽ đứng lại trên thực tế. Cách thiết kế dễ triển khai hơn trong thực tế là: bắt đầu thí điểm ngay khi hoàn tất tới công đoạn 2, rồi cho công đoạn 3 và công đoạn 4 chạy song song. Tuy nhiên, điều này có tiền đề là công đoạn 2 phải được hoàn thành chắc chắn. Không được bỏ qua bước này.

Vị trí của các công cụ từ phía Microsoft

Để rà soát phân quyền, bạn có thể dùng các chức năng quản trị do Microsoft cung cấp. Sắp xếp trước xem cái nào làm được gì sẽ giúp dễ phán đoán phạm vi nào nên thuê ngoài.

Vị trí của Restricted Content Discovery sẽ rõ ràng nếu hiểu đây là chức năng để “che khỏi mắt Copilot trước, rồi mới sửa dứt điểm thiết lập chia sẻ sau”. Sửa từng thiết lập chia sẻ một sẽ rất mất thời gian. Ngược lại, việc gộp các site bị nghi chia sẻ quá mức rồi loại khỏi phạm vi tham chiếu của Copilot có thể thực hiện trong thời gian tương đối ngắn. Nhờ vậy, bạn có thể tiến hành theo cách vừa đẩy công việc chỉnh trang căn bản, vừa mở rộng triển khai một cách an toàn trong thời gian đó.

Tuy nhiên, các site bị loại bằng RCD chỉ là không hiện ra với Copilot, còn người có quyền vẫn truy cập trực tiếp và xem được như trước. Cần hiểu rằng đây không phải giải pháp căn cơ mà là biện pháp để mua thêm thời gian. Nếu cứ để nguyên như vậy, sớm muộn nó sẽ dội ngược lại thành sự bất tiện trong công việc dưới dạng câu hỏi “tại sao tài liệu này không hiện ra trên Copilot”.

Ai là người làm công việc này

Trở ngại thực tế nhất trong rà soát phân quyền không phải kỹ thuật mà là người đảm nhiệm. Chỉ riêng bộ phận hệ thống thông tin thì không thể hoàn tất.

Bảng này cho thấy một cấu trúc: việc phát hiện có thể tự động hóa, nhưng việc phán đoán thì chỉ bộ phận nghiệp vụ mới làm được. Do đó, khi lập lịch cho dự án triển khai, bạn nhất định phải tính đến thời gian mà các bộ phận nghiệp vụ cần để đưa ra phán đoán. Tiến hành theo kiểu “đã giao cho bộ phận IT” thì sẽ hình thành một hàng đợi chờ phán đoán và dự án đứng lại.

Cách tiến hành thực tế là sắp xếp kết quả phát hiện theo thứ tự số lượng nhiều nhất hoặc rủi ro cao nhất, rồi lần lượt xác nhận với các bộ phận từ trên xuống. Đừng cố xử lý toàn bộ cùng một lúc; cách chia nhỏ theo hướng ưu tiên dọn xong trước phạm vi của những bộ phận dự kiến được phát Copilot cũng rất hiệu quả. Đây cũng là một trong những lý do nên bắt đầu thí điểm ở quy mô nhỏ.

Phân định nghiệp vụ nào Copilot ra kết quả và nghiệp vụ nào không

Dễ ra kết quả là những nghiệp vụ mà thông tin đã nằm sẵn trong Microsoft 365

Về nguyên tắc, thứ Copilot tham chiếu được là dữ liệu nằm bên trong tenant Microsoft 365. Chỉ từ một điểm này, những nghiệp vụ dễ ra kết quả đã tự khoanh lại.

Nhìn vào cột “điều kiện tiền đề” của bảng trên, bạn sẽ thấy một điểm chung. Chừng nào tài liệu còn nằm trong thư mục cục bộ trên máy tính cá nhân, hoặc trên máy chủ tệp bên ngoài Microsoft 365, thì chúng nằm ngoài tầm với của Copilot. Ở các nhà máy tại Thái Lan, cấu hình thường gặp là dựng máy chủ tệp Windows (NAS) rồi chia thư mục dùng chung theo từng bộ phận. Trong trường hợp này, dù có triển khai Copilot, nó cũng không chạm được tới dữ liệu được tham chiếu nhiều nhất trong công việc hằng ngày.

Vì vậy, trước khi ước tính hiệu quả triển khai, bạn cần xác nhận dữ liệu nghiệp vụ hiện đang nằm ở đâu. Nếu phát bản quyền Copilot khi chưa hoàn tất việc chuyển sang SharePoint và OneDrive, đánh giá sẽ là “không hữu ích như mong đợi”, và khoản đầu tư tiếp theo sẽ bị dừng.

Hãy nói trước về những nghiệp vụ khó ra kết quả

Để căn chỉnh kỳ vọng, việc truyền đạt trước những lĩnh vực khó có tác dụng là rất quan trọng. Nếu mập mờ ở điểm này rồi mở rộng, sự thất vọng của hiện trường sẽ biến thành lời phủ định toàn diện rằng “AI tạo sinh chẳng dùng được”.

Dòng thứ ba, “tri thức ngầm của hiện trường”, là lĩnh vực mà ngành sản xuất kỳ vọng vào Copilot nhiều nhất, đồng thời cũng dễ trượt nhất. Tiêu chí phán đoán của người thợ lâu năm ngay từ đầu đã không tồn tại dưới dạng tệp, nên dù AI có xuất sắc đến đâu cũng không tham chiếu được. Nếu muốn bước vào lĩnh vực này, như đã sắp xếp trong bài Các cách dùng AI để hỗ trợ truyền thừa kỹ năng, trước hết cần một công đoạn khai thác tri thức ra và định hình nó.

Tương tự, nếu muốn có câu trả lời dựa trên quy trình tác nghiệp, bản vẽ và hồ sơ chất lượng riêng của công ty, bạn cần một cơ chế khác với Copilot. Lựa chọn trong trường hợp này là xây dựng RAG nội bộ, và tư duy thiết kế của nó được chúng tôi tổng hợp trong bài Các điểm cần lưu ý khi triển khai RAG cho tri thức nhà máy. Sự bất mãn kiểu “đã đưa Copilot vào rồi mà chuyện của hiện trường vẫn chẳng biết gì” hoàn toàn có thể ngăn được nếu bạn giải thích ranh giới này ngay từ đầu.

Đối diện thế nào với nhận định “chỉ một trong bốn người giảm được thời gian”

Về hiệu quả triển khai công cụ AI tạo sinh, có nhận định rằng số người dùng thực sự giảm được thời gian làm việc chỉ dừng ở một trong bốn người. Con số này không dễ chịu với phía đang cân nhắc triển khai, nhưng thay vì phủ nhận, hiểu nó như một cấu trúc sẽ thực tế hơn.

Sắp xếp các nguyên nhân có thể có, ta được như sau.

Dòng cuối cùng là điểm dễ bị bỏ sót. Nếu thời gian tiết kiệm được chuyển sang các công việc khác, cảm nhận của bản thân người dùng sẽ là “vẫn bận như cũ”. Nếu không thiết kế cách đo hiệu quả trước khi triển khai, loại hiệu quả này sẽ không được ghi lại. Việc đo cái gì và đo thế nào được chúng tôi bàn riêng trong bài Khung đo lường hiệu quả triển khai AI.

Về bức tranh chung của doanh nghiệp Nhật Bản, khảo sát thực trạng AI tạo sinh mùa xuân 2026 của PwC Japan cho thấy mức độ ứng dụng và thúc đẩy đạt 87 phần trăm, còn nhóm chưa bắt tay hoặc đã bỏ cuộc là 4 phần trăm. Mặt khác, khảo sát tháng 3 năm 2026 của Teikoku Databank cho thấy tỷ lệ doanh nghiệp “đang ứng dụng” trong công việc là 34,5 phần trăm. Chênh lệch giữa hai con số này nhiều khả năng đến từ khác biệt về đối tượng khảo sát và cách đặt câu hỏi, nhưng có thể đọc ra rằng khoảng cách giữa “đang triển khai” và “đang dùng trong công việc” là rất lớn. Với người ở vị trí cân nhắc triển khai, con số thứ hai hẳn sẽ cho cảm giác gần với thực tế hơn.

Cũng trong khảo sát của Teikoku Databank, nếu xét tỷ lệ “đang ứng dụng” theo quy mô doanh nghiệp, ta có doanh nghiệp lớn 46,5 phần trăm, doanh nghiệp vừa và nhỏ 32,4 phần trăm, doanh nghiệp quy mô nhỏ 28,0 phần trăm. Mặt khác, trong số các doanh nghiệp đang ứng dụng, tỷ lệ trả lời rằng “đã có hiệu quả với công việc” là 86,7 phần trăm. Nói cách khác, cấu trúc ở đây là: ở những doanh nghiệp đã bắt đầu dùng thì tỷ lệ ra hiệu quả khá cao, nhưng khoảng cách theo quy mô lại lớn ngay ở khâu có bắt đầu hay không. Xin lưu ý rằng 46,5 phần trăm, 32,4 phần trăm và 28,0 phần trăm chỉ là tỷ lệ ứng dụng theo quy mô, chứ không phải con số chia tỷ lệ ra hiệu quả theo quy mô.

Trong cùng khảo sát, mối lo được nêu nhiều nhất là “độ chính xác của thông tin” với 50,4 phần trăm. Ngoài ra, nhóm chưa sử dụng thành thạo được cho là tập trung nhiều nhất ở cấp trưởng phòng và tổ trưởng. Hai điểm này gợi ý trực tiếp cho việc thiết kế triển khai: với mối lo về độ chính xác, hãy đáp lại bằng quy tắc hóa cách dùng lấy việc kiểm chứng làm tiền đề; còn để thẩm thấu tới tầng quản lý trung gian, hãy chuẩn bị những ví dụ sử dụng sát với công việc hằng ngày của chính tầng này. Nếu bê nguyên một chương trình đào tạo phổ thông dành cho nhân viên trẻ, nhiều khả năng nó sẽ khó chạm tới nhóm này. Tư duy thiết kế đào tạo được chúng tôi tổng hợp trong bài Cách xây dựng chương trình đào tạo AI tạo sinh cho ngành sản xuất.

Bảng rà soát nghiệp vụ

Trước khi triển khai, nếu bộ phận đối tượng làm một bảng rà soát theo dạng dưới đây, thiết kế cho giai đoạn thí điểm sẽ trở nên cụ thể.

Nếu bạn đề nghị mỗi bộ phận nêu ra từ 3 đến 5 trường hợp theo dạng này, bạn sẽ có căn cứ để phán đoán có nên phát Copilot cho bộ phận đó hay không. Nếu cột “có hoàn tất trọn vẹn trong Microsoft 365 không” đều là “không”, thì bộ phận đó nên được hạ thứ tự ưu tiên. Quyết định không phát bản quyền cũng là một phần đường hoàng của thiết kế triển khai.

So sánh và dùng xen kẽ với ChatGPT bản doanh nghiệp (cách chọn công cụ AI tạo sinh)

Hãy suy nghĩ theo 3 nhóm

Câu hỏi “nên chọn Copilot hay ChatGPT” gần như chắc chắn sẽ xuất hiện trong nội bộ. Nhưng chính cách đặt câu hỏi này đang dần không còn khớp với thực tế. Theo khảo sát tháng 2 năm 2026 của Forrester, 34 phần trăm các trường hợp triển khai AI trong doanh nghiệp đang dùng song song nhiều nền tảng (thông tin thứ cấp). Thay vì chọn một trong hai, việc dùng xen kẽ theo mục đích đang trở thành hình thái thực tế hơn.

Về trục phân định, sắp xếp theo 3 nhóm dưới đây sẽ dễ phán đoán.

Ba nhóm này không loại trừ lẫn nhau. Trên thực tế, có những tổ hợp được áp dụng như sau: đặt nhóm 1 làm nền tảng cho toàn công ty, phát nhóm 2 giới hạn cho một số vị trí như lập kế hoạch, thu mua, đảm bảo chất lượng, và xây nhóm 3 riêng lẻ cho từng bài toán của hiện trường sản xuất. Nếu bước vào nhóm 3, trọng tâm thiết kế sẽ là cách chọn dữ liệu đối tượng và cách duy trì độ chính xác. Điểm này được bàn trong bài Xây dựng RAG cho tri thức nhà máy.

Các góc nhìn để so sánh

Đặt ba lựa chọn cạnh nhau theo những góc nhìn liên quan tới quyết định triển khai, ta có bảng sau. Về giá, xin lưu ý rằng con số của Copilot lấy từ trang giá chính thức, còn của ChatGPT Enterprise là con số từ báo chí.

Con số báo chí về số ghế tối thiểu của ChatGPT Enterprise là luận điểm có tác động khi bạn cân nhắc ký hợp đồng riêng cho một chi nhánh nước ngoài. Nếu số nhân viên của chi nhánh Thái Lan dưới 150 người, khả năng ký hợp đồng độc lập cho riêng chi nhánh có thể không thành lập. Điểm này nối thẳng sang phần bàn về chủ thể ký hợp đồng ở sau.

Những kiểu dễ chọn sai

Xin nêu ra một số kiểu lệch lạc trong phán đoán hay xảy ra tại các cuộc họp so sánh.

Đặc biệt kiểu cuối cùng rất hay xảy ra ở các chi nhánh nước ngoài. Kết quả của việc trụ sở lựa chọn dựa trên thực tế nghiệp vụ tại Nhật là phương án được triển khai mà không tính đến tình huống dữ liệu chính tại chỗ đang nằm trên máy chủ tệp. Việc từ chi nhánh truyền lên trụ sở sự thật “dữ liệu của chúng tôi nằm ở đây” từ giai đoạn sớm sẽ giúp tránh được những khoản phí bản quyền lãng phí.

Các trục so sánh chi tiết của từng lựa chọn được bàn trong bài So sánh AI tạo sinh cho doanh nghiệp 2026, nên nếu bạn đang ở giai đoạn cân nhắc rộng bao gồm cả các phương án ngoài Copilot, xin mời tham khảo thêm.

Các luận điểm khi đưa Copilot vào chi nhánh nước ngoài (nhà máy tại Thái Lan)

Đặt chủ thể ký hợp đồng ở đâu

Khi triển khai Copilot tại chi nhánh Thái Lan, thứ cần chốt trước cả kỹ thuật là chủ thể ký hợp đồng. Việc trụ sở tại Nhật ký gộp hay pháp nhân tại chỗ tự ký sẽ làm thay đổi rất lớn cách vận hành về sau.

Ở phần lớn doanh nghiệp Nhật Bản, hình thức được áp dụng là dùng chung tenant với trụ sở nhưng chuyển chi phí bản quyền sang cho chi nhánh. Trong trường hợp này, thứ cần xác nhận là đơn giá chuyển giao và cách xử lý khi không sử dụng. Bạn hẳn muốn tránh tình huống trụ sở phân bổ đồng loạt “20 suất cho chi nhánh”, chi phí được chuyển sang chi nhánh, rồi tại chỗ không ai dùng mà chi phí vẫn được ghi nhận.

Nếu bạn ở vị trí đề xuất từ chi nhánh lên trụ sở, hãy trình bày cụ thể “phát bao nhiêu suất, cho bộ phận nào, với mục đích gì”, đồng thời ghi rõ tiền đề rằng số lượng sẽ tăng giảm theo kết quả thí điểm. Như vậy câu chuyện sẽ dễ tiến triển hơn.

Ước tính thế nào về chất lượng thực dụng trong môi trường đa ngôn ngữ

Tại các nhà máy Nhật Bản ở Thái Lan, ba ngôn ngữ tiếng Nhật, tiếng Anh và tiếng Thái vận hành cùng lúc. Cấu trúc phổ biến là người Nhật biệt phái dùng tiếng Nhật, tầng quản lý dùng tiếng Anh, còn nhân viên và người vận hành tại hiện trường dùng tiếng Thái. Vấn đề nảy sinh ở đây là chất lượng thực dụng của AI tạo sinh không đồng đều giữa các ngôn ngữ.

Đây không phải khiếm khuyết của một sản phẩm cụ thể mà là điều mang tính cấu trúc, sinh ra từ chênh lệch về lượng dữ liệu huấn luyện và mức độ tích lũy tài liệu nghiệp vụ. Nếu không căn chỉnh kỳ vọng khi triển khai, cảm giác bất công kiểu “tiện cho người Nhật nhưng nhân viên người Thái không dùng được” sẽ nảy sinh.

Về thiết kế thực tế, cách nghĩ phân chia mục đích theo từng ngôn ngữ rất hữu hiệu. Chẳng hạn, tích cực dùng cho việc soạn thảo và tóm tắt tài liệu bằng tiếng Nhật và tiếng Anh, còn với tiếng Thái thì bắt đầu từ vai trò “hỗ trợ dịch và tóm tắt qua lại với tiếng Nhật hoặc tiếng Anh”. Nếu ngay lập tức kỳ vọng thay thế hoàn toàn công việc bằng tiếng Thái, đánh giá sẽ đi xuống.

Một luận điểm nữa là ngôn ngữ của các tài liệu nội bộ được tham chiếu. Copilot trả lời bằng cách tham chiếu tài liệu trong tenant. Nếu tài liệu nội bộ chủ yếu bằng tiếng Nhật thì dù hỏi bằng tiếng Thái, nguồn tham chiếu vẫn là tiếng Nhật nên câu trả lời sẽ đi qua một lớp dịch. Cấu trúc này là điều không tránh khỏi ở những chi nhánh làm việc đa ngôn ngữ. Thậm chí, với mục đích để nhân viên người Thái đọc hiểu tài liệu tiếng Nhật, cấu trúc này đôi khi lại có lợi. Nếu nghĩ tới tình cảnh trước đây các tài liệu kỹ thuật tiếng Nhật không đến được tại chỗ mà nằm ngủ yên, hoàn toàn có thể có một thiết kế tìm thấy giá trị nhất định ở hướng này.

Ổ chia sẻ tại chỗ thường được tạo theo kiểu “cứ để tất cả mọi người xem”

Đây không phải chuyện riêng của Thái Lan, nhưng ở các chi nhánh nước ngoài có một xu hướng đặc biệt rõ: thư mục dùng chung và site SharePoint thường được tạo theo kiểu “cứ để tất cả mọi người truy cập được”.

Lý do là điều có thể hiểu được. Ở giai đoạn khởi động chi nhánh, số người ít, không có dư địa cũng chẳng cần thiết phải thiết kế phân quyền tỉ mỉ. Để mọi người đều xem được thì công việc chạy trơn hơn. Nhưng khi chi nhánh lớn lên, số người tăng, rồi việc nghỉ việc và tuyển mới lặp đi lặp lại, tiền đề ban đầu sụp đổ.

Dòng cuối cùng là lĩnh vực đặc biệt cần lưu ý ở chi nhánh Thái Lan. Nếu triển khai Copilot khi thông tin về đãi ngộ nhân viên đang nằm ở nơi có thiết lập phân quyền lỏng lẻo, có nguy cơ sinh ra trạng thái hỏi bằng ngôn ngữ tự nhiên là biết được lương của ai bao nhiêu. Đây sẽ là một vấn đề cực kỳ lớn về quản lý lao động. Trong khâu rà soát trước triển khai, xin hãy ưu tiên cao nhất việc xác nhận nơi lưu trữ và quyền truy cập đối với thông tin liên quan tới nhân sự và tiền lương.

Cái khó thực tế khi tiến hành rà soát phân quyền tại chỗ là người biết đầu đuôi câu chuyện khi đó đã không còn trong công ty. Chuyện người tạo đã nghỉ việc và không ai giải thích được vì sao quyền lại được đặt như vậy xảy ra rất bình thường. Trong trường hợp này, vì không phán đoán được “có được khôi phục về trạng thái cũ hay không” nên công việc bị đứng lại. Cách xử lý thực tế là làm lần lượt từ những thứ rủi ro cao, theo hướng cứ hạn chế lại trước, nếu công việc gặp trở ngại thì mở ra từng trường hợp. Nếu cố truy nguyên đầu đuôi của toàn bộ, sẽ không bao giờ kết thúc.

Môi trường đầu tư AI tại Thái Lan như một cơn gió thuận

Để làm ngữ cảnh cho việc thông qua ngân sách trong nội bộ, việc nắm tình hình đầu tư số và AI của Thái Lan đôi khi rất hữu ích.

Theo Thailand Digital Outlook 2026 do Bangkok Post đưa tin, độ trưởng thành số của doanh nghiệp Thái Lan đạt 2,12 trên thang điểm 4, tăng từ mức 1,56 của năm trước và lần đầu tiên bước vào mức “trung bình”. Ngoài ra, hơn 70 phần trăm doanh nghiệp vừa và nhỏ của Thái Lan được cho là đang triển khai AI, và có thông tin báo chí cho rằng trong Global AI Diffusion Report của Microsoft, Thái Lan đứng thứ 2 thế giới về tốc độ tăng trưởng ứng dụng AI, chỉ sau Hàn Quốc (thông tin thứ cấp).

Về môi trường đầu tư, hồ sơ xin đầu tư nửa đầu năm 2026 của BOI (Ủy ban Đầu tư Thái Lan) được đưa tin là đã đạt 1,47 nghìn tỷ baht (1.299 hồ sơ), tăng 37 phần trăm so với cùng kỳ năm trước. Trong đó, khung “Smart and Sustainable Industry” được cho là có 132 hồ sơ với khoảng 17,2 tỷ baht.

Những con số này có thể dùng làm căn cứ phản biện trước giả định từ phía trụ sở rằng “tại chỗ còn chậm nên chưa đến lúc”. Tuy nhiên, việc chi phí bản quyền phần mềm như Copilot có thuộc diện được hưởng ưu đãi của BOI hay không sẽ thay đổi theo các điều kiện như ngành nghề, nội dung đầu tư và phân loại hồ sơ. Không thể căn cứ vào nội dung bài viết này để kết luận rằng công ty bạn thuộc diện áp dụng. Nếu cân nhắc, xin hãy xác nhận trực tiếp với cơ quan phụ trách hoặc với BOI.

Về cách tiến hành triển khai AI nói chung tại Thái Lan, bài Cách triển khai AI thực tế tại chi nhánh Thái Lan bàn về các ràng buộc riêng của địa phương và việc xây dựng đội ngũ.

Khi trụ sở và chi nhánh không nói cùng một ngôn ngữ

Cuối cùng, xin đề cập tới điều gây khó khăn thực tế nhiều nhất trong triển khai AI ở chi nhánh nước ngoài. Đó không phải kỹ thuật cũng không phải chi phí, mà là việc các tiền đề không được chia sẻ giữa trụ sở và chi nhánh.

Điểm chung ở cột bên phải của bảng này là cách ứng xử từ chi nhánh trả lời lại bằng sự thật dưới dạng con số. Thay vì phản ứng chủ quan kiểu “chỗ chúng tôi không hợp”, nếu trình bày dưới dạng số người thuộc diện đối tượng, nơi lưu dữ liệu, tỷ lệ ngôn ngữ và giờ công cần thiết, phía trụ sở cũng dễ điều chỉnh kế hoạch hơn. Ngược lại, nếu không trả lời bằng sự thật mà để việc phát đồng loạt được quyết định, toàn bộ gánh nặng vận hành sau đó sẽ đổ lên chi nhánh.

Các bước triển khai và cách tiến hành trong nội bộ (lộ trình)

Dòng chảy tổng thể

Chúng tôi sắp xếp lại toàn bộ nội dung phía trên theo thứ tự thực thi. Thời lượng thay đổi rất lớn tùy quy mô tổ chức và mức độ chỉnh trang hiện tại, nên xin bạn xem đây là tham khảo về trình tự.

Trong 6 giai đoạn này, thất bại hay gặp nhất là bỏ qua giai đoạn 0 và giai đoạn 1 rồi bắt đầu luôn từ giai đoạn 2. Vì bản quyền hôm nay đặt mua thì mai đã dùng được nên về mặt tâm lý ai cũng muốn tiến lên trước. Nhưng một cuộc thí điểm mà mục đích chưa được diễn đạt thành lời thì không thể đánh giá, còn một đợt mở rộng khi phân quyền chưa được sắp xếp thì là ổ chứa sự cố.

Giai đoạn 0: diễn đạt mục đích thành lời

“Ứng dụng AI tạo sinh” không phải là một mục đích. Thứ cần viết ra ở giai đoạn này là một nghiệp vụ cụ thể, và thời gian hiện đang tốn cho nghiệp vụ đó. Hãy dùng bảng rà soát nghiệp vụ đã nêu ở chương trước và đề nghị mỗi bộ phận nêu ra từ 3 đến 5 trường hợp.

Điều cần lưu ý lúc này là xác nhận xem những nghiệp vụ được nêu ra có thực sự hoàn tất trọn vẹn trong Microsoft 365 hay không. Dù có nguyện vọng “muốn nâng hiệu suất phân tích lỗi”, nếu dữ liệu lỗi nằm trong hệ thống điều hành sản xuất thì Copilot không xử lý được. Sàng lọc ở giai đoạn này sẽ ngăn được sự thất vọng về sau.

Giai đoạn 1: hiện hóa phân quyền và chặn phơi lộ

Đây là nội dung đã bàn ở chương trước. Nhắc lại các điểm mấu chốt về mặt thực tiễn thì có 3 điều sau.

Thứ nhất, đừng cố sắp xếp hoàn chỉnh phân quyền toàn công ty rồi mới bắt đầu. Ưu tiên dọn xong phạm vi mà bộ phận thí điểm truy cập được sẽ giúp tiến về phía trước một cách thực tế hơn.

Thứ hai, hãy trả việc phán đoán về cho bộ phận nghiệp vụ. Dù việc phát hiện có thể tự động hóa, câu hỏi “có được dừng chia sẻ này không” chỉ người đang dùng mới phán đoán được. Xin hãy đưa thời gian chờ phán đoán vào lịch trình.

Thứ ba, hãy ưu tiên cao nhất việc xác nhận thông tin liên quan tới nhân sự, tiền lương và đãi ngộ. Riêng phần này, dù phạm vi thí điểm ở đâu thì cũng đáng để kiểm tra trước. Ngoài ra, việc gắn nhãn vốn là công cuộc chỉnh trang lâu dài nên không cần hoàn thành ở giai đoạn này. Xin hãy lập kế hoạch trên tiền đề cho nó chạy song song với thí điểm.

Giai đoạn 2: thí điểm với 20 đến 50 người

Lý do lấy khoảng 20 đến 50 người làm mốc quy mô thí điểm là vì đây là quy mô vừa lấy được lượng dữ liệu đủ để đánh giá, vừa có thể quay lui khi có sự cố. Với 5 người thì ảnh hưởng của yếu tố ngẫu nhiên quá lớn, còn với quy mô vài trăm người thì khi có chuyện sẽ không thu dọn nổi.

Cách chọn đối tượng cũng cần được thiết kế.

Về mặt thực tiễn, tổ hợp có sự cân bằng tốt nhất về lượng thông tin thu được là phát gộp cho một hoặc hai bộ phận, đồng thời bao gồm trong đó tầng quản lý và những người dùng đa ngôn ngữ. Xét việc khảo sát của Teikoku Databank cho thấy nhóm chưa dùng thành thạo tập trung nhiều nhất ở cấp trưởng phòng và tổ trưởng, việc đưa nhóm này vào thí điểm để nắm thực trạng là có ý nghĩa.

Thứ cần thu thập trong thời gian thí điểm không chỉ là nhật ký sử dụng. Nếu đề nghị mọi người ghi lại “đã hỏi câu gì”, “câu trả lời có đúng như mong đợi không”, “nếu không thì thiếu cái gì”, bạn sẽ có được tài liệu đào tạo cho lúc mở rộng.

Giai đoạn 3: thiết kế đo lường hiệu quả

Nếu bắt đầu nghĩ tới việc đo lường hiệu quả sau khi đã khởi động thí điểm thì đã muộn. Lý do là nếu không đo trạng thái trước khi triển khai, bạn sẽ không có đối tượng để so sánh. Đó chính là vì sao trong bảng rà soát nghiệp vụ ở giai đoạn 0 lại có mục “cách đo hiệu quả”.

Cách nghĩ ở dòng cuối cùng rất quan trọng khi giải thích trong nội bộ. Nếu thời gian tiết kiệm được chuyển sang các công việc khác thì chi phí nhân sự không giảm. Trong trường hợp này, cách diễn đạt chính xác hơn là chuyển sang dạng “với cùng số người thì khối lượng xử lý được đã tăng bao nhiêu”.

Giai đoạn 4: mở rộng và đào tạo

Khoản chi phí dễ bị bỏ sót ở giai đoạn mở rộng là đào tạo. Đặc biệt ở các chi nhánh nước ngoài, bạn sẽ cần tài liệu đào tạo bằng ngôn ngữ bản địa và một đầu mối có thể trả lời câu hỏi bằng ngôn ngữ bản địa. Phát tài liệu tiếng Nhật rồi coi như xong thì sẽ không hình thành được thói quen sử dụng.

Về nội dung đào tạo, các ví dụ sử dụng sát với nghiệp vụ có hiệu quả hơn là hướng dẫn thao tác. Chỉ cần có 3 ví dụ cụ thể kiểu “khi soạn biên bản cuộc họp này thì nhờ như sau” là rào cản để bắt đầu dùng đã hạ xuống. Những ghi chép thu thập được trong thời gian thí điểm chính là giáo trình.

Thêm một điểm nữa, xin hãy đưa cách dùng lấy việc kiểm chứng làm tiền đề vào chương trình đào tạo. Xét việc mối lo được nêu nhiều nhất trong khảo sát của Teikoku Databank là “độ chính xác của thông tin” (50,4 phần trăm), việc nêu rõ các quy tắc như “không dùng thẳng đầu ra”, “con số phải luôn kiểm tra lại ở tài liệu gốc” sẽ giúp duy trì được sự tin cậy.

Giai đoạn 5: đừng ngừng việc phân bổ lại

Bản quyền Copilot nếu phát ra rồi bỏ mặc thì chi phí sẽ cứ chảy đi mà không ai dùng. Xin hãy đưa vào thiết kế ngay từ khi triển khai một quy trình vận hành: mỗi quý xác nhận tình hình sử dụng và chuyển bản quyền từ người không dùng sang người có dùng.

Để quy trình này thành lập, cần các chuẩn bị sau.

Nếu thông báo trước rằng cơ chế này tồn tại, va chạm khi thu hồi sẽ giảm bớt. Khi quy tắc “không dùng thì sẽ chuyển sang người khác” được chia sẻ, bản thân điều đó cũng có tác dụng thúc đẩy việc sử dụng.

Vì sao không nên “phát đồng loạt toàn công ty”

Nếu nhận được chỉ thị từ trụ sở tại Nhật rằng “đưa vào toàn công ty”, thay vì thực thi nguyên như vậy, việc đề xuất chia thành từng giai đoạn là rất đáng làm. Có 3 lý do.

Thứ nhất, bản quyền sẽ nằm không. Phát cho nhân viên hiện trường vốn không mở Microsoft 365 hằng ngày thì chỉ phát sinh chi phí. Hãy đưa ra số lượng thực tế của đối tượng và đề xuất thu hẹp phạm vi phát.

Thứ hai, việc chỉnh trang phân quyền không theo kịp. Mở rộng đồng loạt toàn công ty đồng nghĩa với việc thiết lập chia sẻ của toàn công ty đã được sắp xếp xong. Nếu triển khai khi tiền đề này chưa được thỏa mãn, các vấn đề về quản lý thông tin sẽ phát sinh trên diện rộng cùng một lúc.

Thứ ba, khi có chuyện thì không lui lại được. Nếu chia thành từng giai đoạn, bạn có thể dừng đợt mở rộng tiếp theo ngay tại thời điểm xảy ra tình huống ngoài dự tính. Với việc phát đồng loạt, không còn dư địa cho phán đoán đó.

Khi truyền đạt những điều này lên trụ sở, cách hiệu quả là trình bày dưới dạng đề xuất về trình tự chứ không phải sự phản đối. Nếu diễn đạt theo kiểu “lấy việc mở rộng toàn công ty làm tiền đề, trước hết tiến hành thí điểm 3 tháng với 20 đến 50 người, đồng thời song song chỉnh trang phân quyền và đo lường hiệu quả”, thì ý chí của trụ sở và thực tế nghiệp vụ tại chỗ có thể cùng tồn tại.

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

Chi phí triển khai Microsoft Copilot là bao nhiêu?

Theo các mức giá niêm yết trên trang giá chính thức của Microsoft, add-on Microsoft 365 Copilot Business là 3.148 yên mỗi người dùng mỗi tháng (tương đương trả theo năm), còn nếu trả theo tháng là 3.778 yên. Từ ngày 1 tháng 7 đến ngày 30 tháng 9 năm 2026, mức giá khuyến mãi chỉ áp dụng cho năm đầu là 2.698 yên (tương đương trả theo năm). Với các gói tích hợp, Microsoft 365 Business Standard cộng Copilot Business là 3.523 yên, còn Business Premium cộng Copilot Business là 4.797 yên (đều là tương đương trả theo năm, tính trên mỗi người dùng mỗi tháng). Về gói dành cho doanh nghiệp lớn, có thông tin đưa ra con số 4.497 yên mỗi người mỗi tháng, nhưng đây là thông tin thứ cấp nên xin hãy xác nhận bằng báo giá chính thức.

Tuy nhiên, đó mới chỉ là chi phí của bản quyền add-on. Tổng chi phí thực tế cần được ước tính theo 5 lớp: một là bản quyền add-on, hai là nâng cấp bản quyền nền (vì cần Business Standard trở lên nên người đang dùng Basic phải chuyển đổi), ba là rà soát phân quyền và chỉnh trang dữ liệu, bốn là triển khai và đào tạo, năm là vận hành (theo dõi tình hình sử dụng và phân bổ lại). Trong đó, lớp thứ ba tốn nhiều giờ công nhất và cũng là phần không thể khoán trọn ra ngoài. Lập ngân sách chỉ với chi phí bản quyền sẽ rất dễ thiếu hụt ở các giai đoạn sau.

Đưa Copilot vào có làm rò rỉ thông tin không?

Copilot không phá vỡ phân quyền. Nó không tự ý đọc ra những thông tin mà người dùng không có quyền truy cập. Do đó, nếu thiết lập phân quyền vẫn đang được giữ đúng như chủ đích thì Copilot không được thiết kế để tạo ra một đường đi mới cho thông tin. Điểm xuất phát của cách hiểu là: các đường đi sẵn có trở nên nhìn thấy được, chứ bản thân số lượng đường đi không tăng lên.

Vấn đề nằm ở chỗ tại nhiều tổ chức, “phạm vi tiếp cận được về mặt kỹ thuật” đang rộng hơn “phạm vi nên được tiếp cận theo nghiệp vụ”. Trước đây điều đó chưa thành thiệt hại thực tế là vì không ai lần ra được. Copilot chỉ với một câu hỏi bằng ngôn ngữ tự nhiên sẽ dò xuyên suốt phạm vi quyền rồi tóm tắt lại. Khi chi phí dò tìm gần như bằng không, sự lỏng lẻo của các thiết lập chia sẻ hiện có sẽ lộ ra nguyên vẹn.

Cụ thể, các trường hợp điển hình là thư mục bị đứt kế thừa quyền, liên kết được chia sẻ ở mức “toàn tổ chức”, site chia sẻ do người đã nghỉ việc tạo và nay không ai quản lý. Ngoài ra, nếu nhãn bảo vệ thông tin chỉ được gắn cho site (container), nhãn đó không được kế thừa xuống các item bên trong, nên từng tệp riêng lẻ vẫn là đối tượng tham chiếu ở trạng thái chưa gắn nhãn. Trước khi triển khai, xin hãy rà soát theo trình tự: hiện hóa, chặn phơi lộ, gắn nhãn, rồi mới mở rộng. Về mặt thực tiễn, quy trình khả thi là dùng báo cáo phân quyền của SharePoint Advanced Management để phát hiện hiện trạng, rồi dùng Restricted Content Discovery để loại các site chia sẻ quá mức khỏi phạm vi tham chiếu của Copilot.

Nên chọn ChatGPT hay Microsoft Copilot?

Chúng tôi khuyến nghị xem lại chính cách đặt câu hỏi theo kiểu chọn một trong hai. Như đã đề cập trong bài, có khảo sát cho thấy tỷ lệ doanh nghiệp dùng song song nhiều nền tảng đã chiếm một phần đáng kể, nên tiền đề suy nghĩ theo kiểu loại trừ đang dần không khớp với thực tế.

Về trục phán đoán, chia thành 3 nhóm dựa trên việc thông tin bạn muốn xử lý nằm ở đâu sẽ dễ sắp xếp hơn. Nếu là nghiệp vụ hoàn tất trọn vẹn trong Microsoft 365 như dò tìm và tóm tắt cuộc họp, email, tài liệu nội bộ thì chọn Copilot; nếu là dữ liệu ngoài Microsoft hoặc các việc nghiên cứu, lập kế hoạch cần độ tự do cao thì chọn ChatGPT Enterprise và tương đương; còn nếu muốn có câu trả lời dựa trên quy trình tác nghiệp, bản vẽ, hồ sơ chất lượng riêng của công ty thì xây RAG nội bộ.

Xin lưu ý thêm, với ChatGPT Enterprise có con số từ báo chí là 45 đến 75 USD mỗi người dùng mỗi tháng, hợp đồng theo năm và tối thiểu 150 ghế. Số ghế tối thiểu này có thể trở thành ràng buộc khi bạn cân nhắc ký hợp đồng riêng cho một chi nhánh nước ngoài. Với những chi nhánh ít nhân sự, khả năng ký hợp đồng độc lập có thể không thành lập, nên xin hãy xác nhận cùng với việc thiết kế chủ thể ký hợp đồng.

Dùng bằng tiếng Thái hay tiếng Anh có được chất lượng như tiếng Nhật không?

An toàn hơn là không lấy mức ngang nhau làm tiền đề. Chất lượng thực dụng của AI tạo sinh có chênh lệch theo ngôn ngữ, và đây không phải khiếm khuyết của một sản phẩm cụ thể mà là điều mang tính cấu trúc, sinh ra từ chênh lệch về dữ liệu huấn luyện và mức độ tích lũy tài liệu nghiệp vụ.

Về cách xử lý, như đã nêu trong bài, chúng tôi khuyến nghị thiết kế phân chia mục đích theo từng ngôn ngữ. Với tiếng Thái, thay vì giao ngay một vai trò thay thế nghiệp vụ độc lập, việc bắt đầu từ vai trò giới hạn là hỗ trợ dịch và sắp xếp ý chính sẽ dẫn tới cách dùng thực tế hơn. Nếu phát ra khi kỳ vọng vẫn đang đặt quá cao, đánh giá của nhân viên tại chỗ sẽ đi xuống và việc mở rộng sau đó sẽ khó khăn.

Một điểm nữa là ngôn ngữ của các tài liệu nội bộ được tham chiếu cũng có tác động. Ở những chi nhánh mà phần lớn tài liệu nội bộ được viết bằng tiếng Nhật, dù hỏi bằng tiếng Thái thì nguyên liệu vẫn là tiếng Nhật nên câu trả lời sẽ đi qua một lớp dịch. Tuy nhiên, điều này đôi khi lại có lợi ở chỗ nhân viên người Thái nay có thể tự đọc hiểu những tài liệu kỹ thuật tiếng Nhật vốn trước đây không đến được tại chỗ. Nếu không chỉ hạ kỳ vọng mà còn đưa hướng sử dụng này vào thiết kế, bạn sẽ tạo được giá trị riêng có của môi trường đa ngôn ngữ.

Bắt đầu từ bao nhiêu người là thực tế?

Chúng tôi khuyến nghị lấy khoảng 20 đến 50 người làm mốc. Với quy mô này, bạn vừa thu được lượng dữ liệu đủ để đánh giá, vừa có thể quay lui khi có sự cố. Với khoảng 5 người thì ảnh hưởng của khác biệt cá nhân quá lớn nên không thành đánh giá; còn bắt đầu ở quy mô vài trăm người thì khi xảy ra tình huống ngoài dự tính sẽ không thu dọn nổi.

Đừng chọn người nhận một cách ngẫu nhiên: hãy giữ trọn một bộ phận rồi chủ đích trộn thêm tầng quản lý và những người làm việc bằng ngôn ngữ khác tiếng Nhật. Việc khảo sát tháng 3 năm 2026 của Teikoku Databank cho thấy nhóm chưa dùng thành thạo tập trung nhiều nhất ở cấp trưởng phòng và tổ trưởng là một gợi ý thực tiễn khi quyết định đối tượng.

Về những thứ cần thu thập, như đã nêu trong bài, bản ghi các cuộc trao đổi thực tế có giá trị hơn nhật ký sử dụng. Cách nhanh nhất để làm giáo trình cho giai đoạn mở rộng là làm từ chính những bản ghi này.

Copilot có tác dụng với nghiệp vụ ở hiện trường (dây chuyền sản xuất) không?

Đây là lĩnh vực nên tiết chế kỳ vọng. Dữ liệu kết quả trong hệ thống quản lý sản xuất, dữ liệu vận hành thiết bị, biểu mẫu viết tay, các trao đổi bằng lời tại hiện trường — tất cả đều hoặc nằm ngoài tenant Microsoft 365, hoặc ngay từ đầu đã không được ghi lại. Không có nguyên liệu để tham chiếu thì không thể tạo ra câu trả lời.

Ngoài ra, tri thức ngầm như tiêu chí phán đoán của người thợ lâu năm vốn không tồn tại dưới dạng văn bản, nên dù AI xuất sắc đến đâu cũng không tham chiếu được. Nếu muốn bước vào lĩnh vực này, trước hết cần một công đoạn khai thác tri thức ra và định hình nó.

Lựa chọn thực tế khi muốn có tác dụng tại hiện trường không phải Copilot, mà là xây dựng RAG trên dữ liệu riêng của công ty, hoặc các cơ chế phía hệ thống điều hành sản xuất và IoT. Nói ngược lại, thứ Copilot phù hợp là các nghiệp vụ giấy tờ của khối hành chính, kỹ thuật và quản lý. Việc bạn có truyền đạt trước phạm vi hoạt động này trong buổi giới thiệu triển khai hay không sẽ làm thay đổi rất lớn cách hiện trường đón nhận.

Ở các tổ chức từ 2.000 ghế trở lên thì có gì thay đổi?

Từ ngày 15 tháng 4 năm 2026, ở các tổ chức có từ 2.000 ghế bản quyền Microsoft 365 trở lên, các ghế không được gán add-on Copilot được cho là không còn dùng được chức năng Copilot trong Word, Excel, PowerPoint và OneNote. Nội dung này dựa trên thông tin thứ cấp, nên điều kiện áp dụng cho công ty bạn nhất định phải được xác nhận bằng thông tin gốc.

Về hàm ý thực tiễn, có trường hợp bạn sẽ phải rà soát lại kế hoạch vốn lấy việc triển khai từng phần làm tiền đề. Với doanh nghiệp Nhật Bản, trụ sở và các chi nhánh nước ngoài thường dùng chung tenant, nên dù riêng chi nhánh có quy mô nhỏ thì tổng của cả tập đoàn vẫn có thể vượt ngưỡng. Việc công ty bạn có rơi vào phân loại này hay không, xin hãy xác nhận sớm với bộ phận đang là đầu mối hợp đồng.

Có nên hoàn tất rà soát phân quyền cho toàn công ty rồi mới mở rộng không?

Nếu lấy việc sắp xếp hoàn chỉnh toàn công ty làm tiền đề cho việc mở rộng, dự án sẽ đứng lại trên thực tế. Cách thiết kế dễ triển khai hơn trong thực tế là bắt đầu thí điểm ngay khi hoàn tất phần hiện hóa và chặn phơi lộ (loại các site chia sẻ quá mức khỏi phạm vi tham chiếu của Copilot), còn những việc chỉnh trang lâu dài như gắn nhãn thì cho chạy song song.

Tuy nhiên, không được bỏ qua bước chặn phơi lộ. Đây là biện pháp có thể thực hiện trong thời gian ngắn, đồng thời là đối sách có hiệu quả lớn nhất. Ngoài ra, về nơi lưu trữ và quyền truy cập đối với thông tin liên quan tới nhân sự, tiền lương và đãi ngộ, dù phạm vi thí điểm ở đâu thì cũng đáng để kiểm tra trước. Ở các chi nhánh nước ngoài, việc những thông tin này nằm trong vùng dùng chung không phải chuyện hiếm.

Nếu trụ sở đã quyết “phát đồng loạt toàn công ty” thì nên ứng xử thế nào?

Chúng tôi khuyến nghị trả lời dưới dạng đề xuất về trình tự chứ không phải sự phản đối. Nếu bạn chấp nhận bản thân việc mở rộng toàn công ty như một tiền đề, rồi đặt trước nó một đợt thí điểm quy mô nhỏ và phần chỉnh trang phân quyền, bạn sẽ bảo vệ được thực tế nghiệp vụ tại chỗ mà không phủ định ý chí của trụ sở.

Thứ cần kèm theo khi đó là sự thật chứ không phải cảm tính. Số người thực tế mở Microsoft 365 hằng ngày, nơi lưu dữ liệu nghiệp vụ chính (trên SharePoint hay trên máy chủ tệp), tỷ lệ các ngôn ngữ đang được dùng trong công việc, số giờ công cần cho việc rà soát phân quyền — nếu trình bày những thứ này bằng con số, phía trụ sở cũng dễ điều chỉnh kế hoạch hơn. Chỉ với phản ứng “chỗ chúng tôi không hợp” thì kế hoạch sẽ không thay đổi, và toàn bộ gánh nặng vận hành sau đó sẽ đổ lên chi nhánh.

Sau khi triển khai, làm sao để phán đoán là đã có hiệu quả?

Nếu không đo trạng thái trước khi triển khai thì không thể phán đoán. Ở giai đoạn diễn đạt mục đích thành lời, xin hãy nêu ra từ 3 đến 5 nghiệp vụ đối tượng, và với mỗi nghiệp vụ hãy chốt thời gian đang cần hiện nay cùng “cách đo hiệu quả”.

Các đối tượng đo có thể kể tới thời gian cần cho một nghiệp vụ nhất định, tần suất sử dụng, cảm nhận của người dùng, tỷ lệ phải làm lại đầu ra (dùng được luôn hay phải sửa), và số vụ việc xử lý được với cùng số người. Một lưu ý là nếu thời gian tiết kiệm được chuyển sang các công việc khác thì chi phí nhân sự trên dòng tiền không nhúc nhích. Nếu giải thích theo hướng cắt giảm nhân sự, tiền đề sẽ bị chất vấn và lập luận sụp đổ; trình bày dưới dạng thay đổi về khối lượng xử lý được sẽ chịu được các thảo luận trong nội bộ hơn.

Xin nói thêm, có nhận định rằng số người dùng thực sự giảm được thời gian làm việc chỉ dừng ở một trong bốn người (thông tin thứ cấp). Thay vì tiếp nhận con số này một cách bi quan, việc phân rã nó thành các yếu tố như không khớp với nghiệp vụ, nơi lưu dữ liệu, không biết dùng thế nào, không có tình huống để dùng, rồi xác nhận xem công ty mình rơi vào yếu tố nào, sẽ thực tế hơn.

Kết luận

Chỗ vấp khi cân nhắc triển khai Microsoft Copilot không nằm ở năng lực của mô hình. Copilot một mặt không phá vỡ phân quyền, nhưng mặt khác đưa chi phí để chạm tới thông tin mà một người có thể tiếp cận về mặt kỹ thuật xuống gần bằng không. Lâu nay sự lỏng lẻo của các thiết lập chia sẻ chưa gây thiệt hại thực tế là vì không ai lần ra được, và việc tiền đề đó thay đổi chính là bản chất của hiện tượng xảy ra khi triển khai.

Do đó, phần thân của dự án triển khai không phải là “mua bản quyền” mà là “rà soát phân quyền”. Thư mục bị đứt kế thừa quyền, liên kết “toàn tổ chức”, site chia sẻ do người đã nghỉ việc tạo, nhãn chỉ gắn ở cấp container — xin hãy giữ đúng trình tự hiện hóa những thứ này, chặn phơi lộ, rồi mới mở rộng. Bỏ qua trình tự này để triển khai toàn công ty đồng nghĩa với việc vừa trả tiền vừa tạo ra trạng thái thông tin bị nhìn thấy trên diện rộng.

Về chi phí, xin hãy ước tính theo 5 lớp: một là bản quyền add-on, hai là nâng cấp bản quyền nền, ba là rà soát phân quyền và chỉnh trang dữ liệu, bốn là triển khai và đào tạo, năm là vận hành (theo dõi tình hình sử dụng và phân bổ lại). Giá add-on trên trang giá chính thức là 3.148 yên mỗi người dùng mỗi tháng (tương đương trả theo năm), nhưng đó mới chỉ là lớp thứ nhất. Lớp thứ ba tốn nhiều giờ công nhất và cũng là phần không thể khoán trọn ra ngoài.

Việc phân định nghiệp vụ cũng cần làm xong trước. Copilot có tác dụng với những nghiệp vụ mà thông tin nằm sẵn trong Microsoft 365 như tóm tắt cuộc họp, đọc hiểu văn bản dài, dò tìm tài liệu cũ, trích đầu việc từ biên bản họp. Ngược lại, nó không chạm tới dữ liệu trong hệ thống lõi, các phán đoán dựa trên bản vẽ và hồ sơ chất lượng, hay tri thức ngầm của hiện trường. Nếu muốn xử lý nhóm sau, bạn cần một cơ chế khác như RAG tự xây.

Quan hệ với ChatGPT và các công cụ tương tự nên được thiết kế theo hướng dùng xen kẽ theo mục đích chứ không phải chọn một trong hai. Ba nhóm sẽ là trục phán đoán: nghiệp vụ khép kín trong Microsoft 365 thì dùng Copilot, tài sản xuyên suốt và ngoài Microsoft thì dùng ChatGPT Enterprise và tương đương, tài sản riêng của công ty thì dùng RAG tự xây. Việc dùng song song nhiều nền tảng nay đã không còn hiếm.

Ở các chi nhánh nước ngoài như Thái Lan, có 3 luận điểm riêng: chủ thể ký hợp đồng (trụ sở ký gộp hay pháp nhân tại chỗ) cùng việc chuyển giao chi phí, chênh lệch chất lượng thực dụng giữa các ngôn ngữ cùng cách căn chỉnh kỳ vọng, và thực tế những ổ chia sẻ được tạo theo kiểu “cứ để tất cả mọi người truy cập được”. Đặc biệt, nơi lưu trữ thông tin liên quan tới nhân sự và tiền lương xin hãy kiểm tra với mức ưu tiên cao nhất. Việc từ chi nhánh trả lời lại trụ sở bằng sự thật dưới dạng con số như số người thuộc diện đối tượng, nơi lưu dữ liệu, tỷ lệ ngôn ngữ và giờ công cần thiết sẽ giúp ngăn được chi phí lãng phí cùng gánh nặng vận hành về sau.

Về cách tiến hành, chúng tôi khuyến nghị trình tự: diễn đạt mục đích thành lời, hiện hóa phân quyền, thí điểm với 20 đến 50 người, thiết kế đo lường hiệu quả, mở rộng, rồi phân bổ lại. Lý do nên tránh phát đồng loạt toàn công ty có 3 điều: bản quyền sẽ nằm không, việc chỉnh trang phân quyền không theo kịp, và khi có chuyện thì không lui lại được.

Dù bạn đang ở giai đoạn vừa nhận thông báo từ trụ sở rằng “sẽ đưa Copilot vào toàn công ty”, hay đang muốn tự đề xuất từ chi nhánh lên trụ sở, hay vẫn ở cửa vào của việc cân nhắc mà chưa có gì được quyết, tất cả đều không sao. Bạn chỉ cần kể lại tình hình dưới dạng “thư mục dùng chung để chế độ ai cũng truy cập được suốt 10 năm nay”, “dữ liệu chính nằm trên máy chủ tệp và chưa chuyển được sang SharePoint”, “giả định của trụ sở và thực tế tại chỗ không khớp nhau” — chúng tôi có thể cùng bạn sắp xếp từ việc ước lượng phạm vi rà soát phân quyền cho tới thiết kế đợt thí điểm. Trao đổi khi chưa quyết triển khai cũng hoàn toàn ổn, xin cứ thoải mái liên hệ với chúng tôi qua biểu mẫu liên hệ.

Nguồn tham khảo

• Microsoft “Bảng giá Microsoft 365 Copilot”
• Microsoft Tech Community “Mitigate oversharing to govern Microsoft 365 Copilot and agents”
• Microsoft Learn “Get ready for Copilot with SharePoint Advanced Management”
• Microsoft “Microsoft 365 Copilot vs ChatGPT Enterprise”
• PwC Japan Group “Khảo sát thực trạng về AI tạo sinh, mùa xuân 2026”
• Teikoku Databank “Khảo sát doanh nghiệp về tình hình ứng dụng AI tạo sinh (khảo sát tháng 3 năm 2026)”
• Bangkok Post “AI adoption helps Thai firms become digitally mature”
• The Nation Thailand (hồ sơ xin đầu tư BOI nửa đầu năm 2026)