Xây dựng MCP server cho nhà máy: kết nối MES, ERP với AI agent an toàn

“Chúng tôi muốn cho AI agent xem dữ liệu quản lý sản xuất và chất lượng. Nghe nói nhiều về MCP, nhưng cần xây đến đâu, và phải ghi gì vào yêu cầu đặt hàng?” Đây là câu hỏi đầu tiên mà những người phụ trách hệ thống thông tin và chuyển đổi số tại các nhà máy vốn Nhật Bản ở Thái Lan đang gặp phải. Xin nói kết luận trước. Xây dựng MCP server không phải là mở một “cửa sổ cơ sở dữ liệu”, mà là mở một “cửa sổ nghiệp vụ”. Điều quyết định thành công không phải là độ thông minh của mô hình hay tốc độ kết nối, mà là thiết kế 3 lớp: (1) mức độ chi tiết (granularity) của công cụ, (2) phân quyền (giới hạn trên của quyền hạn), và (3) dấu vết kiểm toán (audit trail).

Mọi số tiền, thời gian và tỷ lệ cắt giảm xuất hiện trong bài viết này đều là giá trị ước tính và giả định do chính bài viết đưa ra, dựa trên nhà máy mẫu được mô tả ở phần sau. Đây không phải mức trung bình của ngành, cũng không phải số liệu khảo sát. Hãy đọc chúng như một “khuôn mẫu tính toán” để thay các tiền đề bằng số liệu đo thực tế của doanh nghiệp mình.

MCP là gì và năm 2026 đã thay đổi những gì

MCP (Model Context Protocol) là một quy ước chung để AI agent gọi dữ liệu và chức năng của các hệ thống bên ngoài. Giữa phía agent (client) và phía cung cấp dữ liệu, chức năng (server), MCP thống nhất các điều như “có những công cụ nào”, “gọi công cụ như thế nào” và “trả kết quả ra sao”. Chức năng mà server cung cấp chủ yếu gồm 3 loại: công cụ (Tools), tài nguyên (Resources) và prompt (Prompts). Trong bối cảnh nhà máy, có thể hình dung đơn giản rằng đây là việc dựng một “quầy tiếp nhận dành cho agent” phía trước MES, ERP, hệ thống quản lý chất lượng (QMS) và hệ thống quản lý tài liệu.

Khác biệt so với API

Hẳn nhiều nhà máy sẽ nói rằng ERP và MES của họ đã có API. API là cổng để lập trình viên gọi từ chương trình, và việc gọi cái gì theo thứ tự nào là do người viết chương trình quyết định. Còn với công cụ MCP, agent (mô hình ngôn ngữ) đọc “phần mô tả công cụ” rồi tự phán đoán để chọn và gọi. Nói cách khác, khác biệt bản chất so với API là: trong MCP server, chính phần mô tả công cụ trở thành tài liệu đặc tả đối với mô hình, và phạm vi những gì có thể gọi chính là giới hạn trên của sự cố. Chỉ phủ một lớp MCP server mỏng lên trên API là chưa đủ. Cần thiết kế lại một lần nữa câu hỏi “cho phép mô hình làm gì”.

Đặc tả phiên bản 2026-07-28 đã thay đổi những gì

Tính đến tháng 10/2026, phiên bản mới nhất của đặc tả MCP là bản “2026-07-28”. Các thay đổi chính so với bản trước (bản 2025-11-25) như sau.

• Loại bỏ phiên (session) ở cấp giao thức và header ID phiên trong Streamable HTTP
• Bãi bỏ bước bắt tay initialize khi bắt đầu kết nối, chuyển sang không trạng thái (stateless), mỗi request mang theo phiên bản giao thức và thông tin năng lực của client
• Bổ sung cơ chế truy vấn chức năng của server (server/discover)
• Chuyển Tasks từ chức năng lõi mang tính thử nghiệm sang dạng phần mở rộng chính thức
• Đưa Roots, Sampling, Logging vào trạng thái không khuyến nghị (Deprecated)
• Không khuyến nghị transport HTTP+SSE kiểu cũ, chuyển sang Streamable HTTP
• Không khuyến nghị đăng ký client động của OAuth, khuyến nghị dùng Client ID Metadata Documents
• Áp dụng chính sách vòng đời: khi bãi bỏ một chức năng phải có thời gian không khuyến nghị tối thiểu 12 tháng

Theo blog chính thức, nhờ chuyển sang không trạng thái, server có thể được đặt trên bất kỳ instance nào phía sau một bộ cân bằng tải kiểu round-robin thông thường. Với bộ phận hệ thống thông tin của nhà máy, đây là thay đổi giúp việc dự phòng (redundancy) và bố trí theo từng cơ sở trở nên dễ dàng hơn. Mặt khác, cần lưu ý rằng một số MCP server được xây dựng trong năm 2025 dùng những phương thức vừa bị đưa vào diện không khuyến nghị lần này.

Mức độ phổ biến và tính trung lập

Quy mô phổ biến cũng đã khác hẳn so với năm 2025. Cũng trong blog chính thức nói trên, tổng số lượt tải các SDK chính (Tier 1) được cho là đang tiến gần mức khoảng 500 triệu lượt mỗi tháng. Các SDK Tier 1 cho TypeScript, Python, Go và C# đã hỗ trợ phiên bản mới ngay từ ngày đặc tả được công bố.

Về mặt quản trị, ngày 9/12/2025, Linux Foundation công bố thành lập Agentic AI Foundation (AAIF), và MCP của Anthropic trở thành một trong các dự án sáng lập. AWS, Google, Microsoft, OpenAI cùng nhiều công ty khác có tên trong danh sách thành viên Platinum. Có thể nói MCP đã bước sang giai đoạn được coi là nền tảng chung của ngành, chứ không còn là tiêu chuẩn riêng của một nhà cung cấp cụ thể.

Tuy nhiên, việc MCP phổ biến và việc dùng nó an toàn trong nhà máy của chính mình là hai chuyện khác nhau. Theo dự báo của Gartner vào tháng 6/2025, hơn 40% dự án AI dạng agent dự kiến sẽ bị hủy bỏ trước cuối năm 2027, với các lý do được nêu là chi phí tăng vọt, giá trị kinh doanh không rõ ràng và quản lý rủi ro chưa đầy đủ. Xây dựng MCP server là công đoạn liên quan trực tiếp đến cả 3 lý do này.

“Cửa sổ cơ sở dữ liệu” và “cửa sổ nghiệp vụ”: 3 vấn đề khi nối thẳng connector đa dụng

Cách nhanh nhất để có một MCP server chạy được là nối thẳng các connector đa dụng cho cơ sở dữ liệu hoặc ERP. Chỉ cần trao cho agent một công cụ chạy được SQL, một công cụ đọc được bất kỳ bảng nào, agent sẽ tra cứu được mọi thứ. Ở giai đoạn làm thử, nó chạy tốt đến bất ngờ.

Thế nhưng, cấu hình kiểu “cửa sổ cơ sở dữ liệu” này khi dùng trong nhà máy thực tế sẽ cùng lúc mang 3 vấn đề sau.

Vấn đề thứ ba, không thể nghiệm thu, thường bị bỏ sót. Điều mà bên đặt hàng có thể xác nhận trong kiểm thử nghiệm thu là các chức năng đã định nghĩa có chạy đúng như định nghĩa hay không, và có điều gì ngoài định nghĩa xảy ra hay không. Một công cụ chạy được SQL bất kỳ thì “làm được mọi thứ”, nên không thể chứng minh qua kiểm thử rằng “những điều không được phép làm sẽ không xảy ra”.

Ngược lại, kiểu “cửa sổ nghiệp vụ” tách công cụ theo đơn vị nghiệp vụ, chẳng hạn “truy xuất lịch sử lô”, “tra cứu tình trạng trả lời ngày giao hàng của đơn đặt hàng”, “soạn bản nháp báo cáo sự không phù hợp”. Số lượng công cụ tăng lên, nhưng vì có thể quyết định từng công cụ trả về gì và cho phép ai dùng, nên cả 3 yếu tố quyền hạn, dấu vết và nghiệm thu đều trở nên có thể thiết kế được.

Dưới đây, chúng ta sẽ lần lượt xem xét 3 lớp nâng đỡ “cửa sổ nghiệp vụ” này: lớp 1 là thiết kế công cụ, lớp 2 là phân quyền và lớp 3 là dấu vết kiểm toán. 3 lớp này không độc lập với nhau mà xếp chồng lên nhau: vì công cụ được tách theo đơn vị nghiệp vụ nên mới quyết định được phạm vi phân quyền, và vì phân quyền đã được xác định nên mới quyết định được các mục cần ghi vào dấu vết.

Lớp 1, thiết kế công cụ: tách việc kết nối MES, ERP theo đơn vị nghiệp vụ

Quyết định thiết kế đầu tiên khi xây dựng MCP server là “tách công cụ theo đơn vị nào”. Nguyên tắc ở đây là không tách theo câu SQL hay theo bảng, mà theo đơn vị công việc mà nhân viên phụ trách thực hiện hằng ngày.

Ví dụ về công cụ theo đơn vị nghiệp vụ

Nếu thay các thao tác tra cứu mà nhân viên quản lý sản xuất, đảm bảo chất lượng và mua hàng của nhà máy làm hằng ngày bằng công cụ, ta có bảng sau.

Điều quan trọng ở đây là giới hạn nội dung công cụ trả về ở “chỉ những mục cần cho nghiệp vụ đó”. Công cụ truy xuất lịch sử lô không cần trả về tên cá nhân hay bậc lương của công nhân. Thu hẹp giá trị trả về có tác dụng cho cả việc phân quyền được trình bày ở phần sau lẫn việc tuân thủ Luật Bảo vệ dữ liệu cá nhân của Thái Lan (PDPA).

Tách công cụ tham chiếu và công cụ ghi

Nguyên tắc thứ hai là tách công cụ tham chiếu và công cụ ghi sang các server khác nhau, hoặc ít nhất là sang các phạm vi quyền (scope) khác nhau. Nếu tham chiếu và ghi cùng nằm trên một server, người dùng mà ta chỉ muốn cho phép tham chiếu cũng nhìn thấy công cụ ghi, khiến việc thiết kế quyền trở nên phức tạp. Nếu tách server từ đầu, có thể triển khai theo từng bước một cách tự nhiên: “ban đầu chỉ công khai server tham chiếu, sau đó mới bổ sung server ghi”.

Với công cụ ghi, nguyên tắc là “agent chỉ làm đến bước bản nháp và lập phiếu, việc xác nhận do con người làm”. Agent được giao soạn nháp báo cáo sự không phù hợp hay lập phiếu đề nghị thay đổi đơn mua hàng, còn các nút phê duyệt, xác nhận và gửi do người phụ trách bấm. Nếu thiết kế để mọi nội dung đều qua mắt con người trước khi xác nhận, thì dù agent có ghi sai, thiệt hại cũng chỉ dừng ở “công sức làm lại”.

Phần mô tả công cụ là “tài liệu đặc tả mà mô hình đọc”

Nguyên tắc thứ ba là viết cẩn thận phần mô tả công cụ (description). Như đã nói ở trên, agent đọc phần mô tả để quyết định gọi công cụ nào. Nếu mô tả mơ hồ, mô hình sẽ nhầm lẫn giữa các công cụ có tên gần giống nhau, hoặc tự đoán để điền các tham số cần thiết.

Phần mô tả tối thiểu cần ghi các nội dung sau.

• Công cụ này trả về gì (ghi cả những gì nó không trả về)
• Ý nghĩa và định dạng của tham số (số chữ số của mã lô, định dạng ngày tháng, v.v.)
• Nên dùng cho câu hỏi nào, thuộc nghiệp vụ nào
• Những trường hợp không được dùng (ví dụ: không dùng để phán định cuối cùng việc có được xuất hàng hay không)

Cần lưu ý rằng thuật ngữ nghiệp vụ trong nhà máy thường có nhiều cách gọi cho cùng một thứ. Nếu “lô”, “số lệnh sản xuất” và “mẻ” đang được dùng lẫn lộn tùy cơ sở hoặc bộ phận, hãy thống nhất thuật ngữ trong phần mô tả và trong giá trị trả về bằng một bộ từ điển. Cách xử lý ngôn ngữ khi vận hành nhiều cơ sở sẽ được bàn lại ở phần các vấn đề đặc thù của Thái Lan.

Bao nhiêu công cụ là phù hợp

Không cần biến toàn bộ nghiệp vụ thành công cụ ngay từ đầu. Ngược lại, chúng tôi khuyên ban đầu chỉ nên giới hạn ở 2 đến 3 công cụ tham chiếu. Quá nhiều công cụ sẽ làm tăng xác suất mô hình chọn nhầm, và số hạng mục kiểm thử nghiệm thu cũng phình ra. Trong kế hoạch 90 ngày ở phần sau, 30 ngày đầu tiên được dùng để đo thực tế công việc tra cứu, rồi rà soát các ứng viên công cụ theo thứ tự từ những nghiệp vụ tốn nhiều thời gian nhất.

Lớp 2, phân quyền: “giới hạn trên của quyền hạn” là điều cần quyết định đầu tiên trong bảo mật MCP

Sau khi đã tách công cụ theo đơn vị nghiệp vụ, bước tiếp theo là quyết định “ai được gọi công cụ nào, trên phạm vi dữ liệu nào”. Điều cần quyết định đầu tiên trong bảo mật MCP, trước cả phương thức kỹ thuật, là nguyên tắc: quyền hạn của agent không vượt quá quyền hạn của người yêu cầu.

Agent hoạt động với tư cách “người đại diện của người yêu cầu”

Khi nhân viên đảm bảo chất lượng yêu cầu “cho tôi xem lịch sử của lô này”, phạm vi agent được phép xem chỉ đến mức mà chính nhân viên đó có thể xem khi tự đăng nhập vào MES. Nếu trao cho agent một tài khoản dịch vụ tương đương quản trị viên để nó “xem được mọi thứ”, thì thông qua agent, người yêu cầu sẽ thấy được cả những dữ liệu mà lẽ ra họ không được xem. Đó chính là leo thang đặc quyền.

Trong danh sách rủi ro dành cho MCP do OWASP công bố (OWASP MCP Top 10, tính đến tháng 10/2026 vẫn ở giai đoạn beta), leo thang đặc quyền do phạm vi quyền phình to (MCP02) và xác thực, phân quyền không đầy đủ (MCP07) cũng được nêu thành các hạng mục.

Cách xử lý token theo yêu cầu của đặc tả

Đặc tả phân quyền của MCP bản 2026-07-28 lấy OAuth 2.1 làm nền tảng khi dùng với các transport dạng HTTP. Từ phía bên đặt hàng, có 3 điểm chính cần nắm.

1. Kiểm tra đích đến của token: MCP server bắt buộc (MUST) phải kiểm tra xem access token nhận được có đúng là được cấp cho chính nó hay không.
2. Cấm chuyển tiếp token: Đặc tả cấm chấp nhận token khác, cũng như chuyển nguyên token xuống hệ thống phía dưới. Tài liệu thực hành tốt về bảo mật chính thức gọi việc này là Token Passthrough và cấm rõ ràng. Cách làm chuyển nguyên token nhận từ agent sang API của ERP là không được phép.
3. Không đưa token vào URL: Việc đưa access token vào chuỗi truy vấn (query string) của URL cũng bị cấm.

Lưu ý thêm, MCP server dạng STDIO chạy cục bộ không theo đặc tả phân quyền này mà lấy thông tin xác thực từ môi trường. Với server dùng chung cho nhiều người dùng trong nhà máy, nguyên tắc cơ bản là xây dựng trên transport dạng HTTP và tuân theo đặc tả phân quyền.

Phạm vi quyền bao trùm là sai lầm điển hình

Tài liệu thực hành tốt về bảo mật chính thức khuyến nghị bắt đầu phạm vi quyền (scope) ở mức tối thiểu rồi nâng dần khi cần, và nêu việc cấp scope bao trùm kiểu full-access là một sai lầm điển hình.

Với nhà máy, cách thiết kế scope thực tế như sau.

Bảng đối chiếu giữa danh sách scope và danh sách công cụ có thể dùng nguyên làm tài liệu đính kèm RFP, đồng thời trở thành các hạng mục kiểm thử nghiệm thu.

Server của nhà cung cấp cũng theo cùng cách nghĩ

Cách nghĩ “quyền hạn của agent chỉ trong phạm vi vai trò được gán” cũng đã được đưa vào sản phẩm của các nhà cung cấp ERP lớn. Dynamics 365 ERP MCP server của Microsoft được thiết kế để chỉ trả về menu, thực thể (entity) và API trong phạm vi vai trò bảo mật (security role) được gán cho agent, và từ chối các lệnh gọi ngoài quyền. Các client được phép kết nối cũng có thể được quản lý theo cơ chế cấp phép.

Tách dữ liệu theo từng cơ sở

Khi nhiều cơ sở như Thái Lan, Việt Nam và trụ sở chính tại Nhật Bản dùng chung một MCP server, tách dữ liệu theo từng cơ sở (hoặc từng pháp nhân) cũng là một yêu cầu thiết kế của phân quyền. Như trường hợp Asana được trình bày ở phần sau cho thấy, khả năng nhìn thấy dữ liệu giữa các tổ chức có thể bị phá vỡ chỉ vì lỗi phần mềm, ngay cả khi không có tấn công. Hãy ghi rõ trong cả tài liệu thiết kế lẫn kiểm thử rằng “token của người dùng nhà máy Thái Lan sẽ không trả về lô của nhà máy Việt Nam”.

Lớp 3, dấu vết kiểm toán: ghi lại mọi lệnh gọi công cụ

Lớp thứ ba là dấu vết kiểm toán. Nếu không thể truy lại sau đó xem agent đã trả lời dựa trên căn cứ nào và đã ghi gì, thì khi xảy ra vấn đề chất lượng hay khi bị kiểm toán, doanh nghiệp sẽ không thể giải trình. Trong OWASP MCP Top 10, việc thiếu kiểm toán và telemetry cũng là một hạng mục độc lập, mang mã MCP08.

Các mục cần ghi lại

Tối thiểu, với mọi lệnh gọi công cụ, cần ghi lại các mục sau.

Có lưu toàn văn giá trị trả về hay không sẽ được quyết định dựa trên cân nhắc giữa dung lượng dữ liệu và cách xử lý dữ liệu cá nhân. Ít nhất, nếu giữ lại được “đã trả về bao nhiêu bản ghi” và “đã chạm vào đối tượng nào”, thì nhật ký sẽ đủ dùng cho việc điều tra sau sự việc.

Quyết định thời gian lưu trữ và người xem

Chỉ lưu nhật ký thôi thì không có ý nghĩa. Cần quyết định ai xem và xem với tần suất nào. Ví dụ, bộ phận hệ thống thông tin kiểm tra hằng tuần các bản ghi về lệnh gọi ngoài quyền đã bị từ chối, còn tỷ lệ bị từ chối của công cụ ghi được rà soát hằng tháng cùng bộ phận nghiệp vụ. Thời gian lưu trữ được quyết định theo quy định lưu hồ sơ chất lượng của doanh nghiệp và yêu cầu kiểm toán.

Việc xử lý nhật ký gắn liền với thiết kế giám sát cho toàn bộ hoạt động vận hành agent. Về giám sát lưu lượng sử dụng API và tỷ lệ lỗi của agent, xem bài “Vận hành API cho AI agent“. Về cách quản lý bằng sổ đăng ký xem agent nào đang kết nối với server nào, xem bài “Sổ đăng ký và kiểm soát AI agent“.

Bài học bảo mật MCP từ các sự cố và lỗ hổng thực tế

Thiết kế 3 lớp không phải là chuyện lý thuyết trên giấy, điều này thấy rõ khi nhìn vào các sự cố đã thực sự xảy ra và các lỗ hổng đã được công bố trong năm 2025. Ở đây chỉ giới thiệu những trường hợp có bài học gắn trực tiếp với việc xây dựng MCP server cho nhà máy.

Asana: không có tấn công, nhưng lỗi phần mềm vẫn có thể làm lộ dữ liệu của tổ chức khác

Dịch vụ quản lý dự án Asana công bố MCP server vào ngày 1/5/2025. Ngày 4/6, công ty phát hiện một lỗi logic và dừng server, đến ngày 17/6 thì khôi phục. Do lỗi này, thông tin như nhiệm vụ và dự án đã ở trạng thái có thể bị người dùng MCP của tổ chức khác nhìn thấy. Theo báo chí, bộ phận truyền thông của Asana cho biết số khách hàng bị ảnh hưởng vào khoảng 1.000. Các bài báo không đề cập đến dấu hiệu bị khai thác, và đây là sự việc do lỗi phần mềm chứ không phải do tấn công.

Bài học: Việc tách dữ liệu giữa các tổ chức hoặc các cơ sở cần được đưa vào yêu cầu thiết kế, không chỉ để phòng tấn công mà còn để phòng lỗi phần mềm. Nếu nhiều cơ sở dùng chung một MCP server, hãy xác nhận “không trả về dữ liệu của cơ sở khác” trong kiểm thử nghiệm thu, và tiếp tục xác nhận bằng kiểm thử hồi quy sau mỗi lần sửa đổi.

“Toxic Agent Flow” của GitHub MCP: tài liệu từ bên ngoài trở thành lối vào

Tháng 5/2025, công ty bảo mật Invariant Labs công bố một phương thức tấn công nhắm vào agent sử dụng MCP server của GitHub. Nếu cài sẵn chỉ thị độc hại vào một Issue trong kho mã công khai, agent đọc Issue đó sẽ làm theo chỉ thị, đọc thông tin từ kho mã riêng tư và làm rò rỉ thông qua một pull request được tạo tự động. Đây chính là kiểu tấn công prompt injection gián tiếp. Tác giả cho rằng đây không phải là khiếm khuyết trong mã nguồn của chính GitHub MCP server, mà là vấn đề mang tính cấu trúc của hệ thống agent, và cần có biện pháp đối phó ở phía agent.

Bài học: Áp vào nhà máy, đây là những tình huống cho agent đọc các tài liệu đến từ bên ngoài như email của đối tác, bản đặc tả của khách hàng, phiếu kết quả kiểm tra của nhà cung cấp. Nếu agent đọc tài liệu bên ngoài lại được cấp cả công cụ ghi, sẽ hình thành con đường để các chỉ thị cài trong tài liệu gây ra việc lập phiếu hay gửi đi không cần thiết. Ở đây, nguyên tắc “thao tác ghi chỉ đến bản nháp, việc xác nhận do con người làm” và việc tách tham chiếu khỏi ghi một lần nữa phát huy tác dụng.

Ngay cả công cụ chính thức và phổ biến cũng có lỗ hổng

Trong năm 2025, hàng loạt lỗ hổng có mức độ nghiêm trọng cao đã được công bố đối với các công cụ xoay quanh MCP.

mcp-server-git là server được công bố làm bản tham chiếu chính thức của MCP. Với tiền đề rằng ngay cả thứ chính thức, thứ được dùng rộng rãi cũng có lỗ hổng, khi đặt hàng cần thỏa thuận trước “danh sách phiên bản các gói liên quan đến MCP sẽ sử dụng” và “khi có lỗ hổng được công bố thì cập nhật trong vòng bao nhiêu ngày”.

postmark-mcp: tấn công chuỗi cung ứng bằng server không rõ nguồn gốc

Tháng 9/2025, có thông tin rằng công ty bảo mật Koi Security đã phát hiện một MCP server độc hại tên “postmark-mcp” được phân phối trên npm. Gói này giả mạo thư viện chính thống của Postmark Labs, và ở bản v1.0.16 công bố ngày 17/9/2025, một dòng mã đã được thêm vào để gửi BCC toàn bộ email gửi đi tới một địa chỉ bên ngoài. Tổng số lượt tải là 1.643.

Bài học: Nếu nhân viên tại hiện trường tự ý cài các MCP server có vẻ tiện lợi theo phán đoán cá nhân, những gói độc hại như thế này sẽ lọt vào công ty. OWASP MCP Top 10 nêu MCP server nằm ngoài sự quản lý là MCP09 (Shadow MCP Servers), và việc gói phụ thuộc bị can thiệp là MCP04. Biện pháp cơ bản là lập danh sách cho phép (allowlist) các MCP server và gói phụ thuộc được phép dùng, và cấu hình sao cho không thể kết nối với bất kỳ thứ gì ngoài danh sách.

Hành động ban đầu khi xảy ra sự cố, tức là quyết định dừng server, xác định phạm vi ảnh hưởng và quy trình liên lạc với người dùng, được trình bày chi tiết trong bài “Ứng phó sự cố AI agent“. Trước khi đưa MCP server vào vận hành thực tế, ít nhất hãy quyết định “ai có quyền ra quyết định dừng server”.

Ranh giới với OT: không đưa thao tác ghi vào PLC và hệ thống điều khiển vào phạm vi MCP

Khi nói về MCP trong nhà máy, chắc chắn sẽ có câu hỏi “có kết nối cả thiết bị và PLC với AI không”. Khuyến nghị của bài viết này rất rõ ràng: không đưa thao tác ghi vào PLC và hệ thống điều khiển vào phạm vi của MCP.

Lý do đơn giản. Thao tác ghi vào MES hay ERP, nếu sai thì con người có thể chặn lại ở giai đoạn bản nháp, và ngay cả sau khi xác nhận vẫn có thể khôi phục bằng cách sửa chứng từ. Ngược lại, thao tác ghi vào hệ thống điều khiển ảnh hưởng trực tiếp đến hoạt động của thiết bị, đến sản phẩm và trong một số trường hợp đến an toàn của con người, và không thể “sửa sau”. Như đã thấy ở phần trước, khi hành vi của agent có thể bị thay đổi bởi chỉ thị cài trong tài liệu bên ngoài, thì việc trao cho agent quyền vận hành thiết bị, ở thời điểm hiện tại, là một rủi ro không đáng đánh đổi.

OPC UA MCP server đang ở giai đoạn preview

OPC Foundation, tổ chức xây dựng chuẩn truyền thông công nghiệp OPC UA, đã công bố dưới dạng gói NuGet một server cho phép công khai các lệnh gọi dịch vụ OPC UA dưới dạng công cụ MCP. Phiên bản mới nhất là 2.0.0-preview.6 công bố ngày 30/9/2026, được xếp vào diện bản phát hành trước (prerelease). Gói này cũng có cơ chế profile để chuyển đổi phạm vi công cụ theo mục đích sử dụng.

Việc chính tổ chức tiêu chuẩn tham gia vào MCP là điều đáng chú ý, nhưng ở thời điểm hiện tại nó vẫn đang ở giai đoạn preview. Hợp lý nhất là không dùng cho mục đích điều khiển trong vận hành thực tế, mà chỉ dừng ở việc tham chiếu dữ liệu thiết bị trong môi trường kiểm chứng. Ngay cả khi muốn cho agent xem dữ liệu vận hành của thiết bị, cách an toàn là bắt đầu từ cấu hình cho agent đọc các giá trị đã được tích lũy trong MES hoặc nền tảng thu thập dữ liệu thiết bị, thông qua công cụ chỉ tham chiếu.

Về việc tách mạng phía OT và thiết kế ranh giới khi đưa AI agent vào mạng nhà máy, xem chi tiết trong bài “Bảo mật AI agent trong công nghiệp“.

MCP server có sẵn hay tự xây dựng: chọn hướng nào để kết nối ERP

Khi tính đến việc xây dựng MCP server, một ngã rẽ lớn là dùng MCP server có sẵn do nhà cung cấp ERP hoặc nhà cung cấp đám mây cung cấp, hay tự xây dựng từ đầu (do doanh nghiệp tự làm hoặc thuê nhà thầu). Trong năm 2026, các server có sẵn cho những ERP chính cũng đã xuất hiện.

Ví dụ về server có sẵn

Dynamics 365 ERP MCP server (Microsoft): Cung cấp các chức năng ERP của Dynamics 365 dưới dạng công cụ thuộc 3 nhóm: thao tác dữ liệu (Data), thao tác màn hình (Form) và gọi hành động (Action). Như đã nói ở trên, server chỉ trả về các chức năng trong phạm vi vai trò bảo mật được gán cho agent, và các client được phép kết nối cũng được quản lý theo cơ chế cấp phép. Các form như thiết lập bảo mật hay quản lý người dùng không thể truy cập từ MCP. Khi dùng từ các client khác ngoài Copilot Studio, mỗi lệnh gọi công cụ sẽ tiêu tốn 0,1 Copilot Credit. Ngôn ngữ được hỗ trợ chỉ có tiếng Anh (Mỹ), và server phiên bản “static” trước đây đã bị ngừng vào ngày 1/10/2026.

AWS for SAP MCP Server (Amazon Bedrock AgentCore): Bắt đầu cung cấp chính thức (general availability) từ tháng 5/2026. Server kết nối với S/4HANA và SAP ECC, cung cấp cho agent các thao tác tạo, tham chiếu, cập nhật và xóa đối với các đối tượng nghiệp vụ SAP như đơn đặt hàng bán, đơn mua hàng, mã vật tư và chứng từ kế toán. Server có tách phiên (session isolation), kết nối riêng (private connectivity), xác thực hai lớp bằng AgentCore Identity và telemetry thông qua CloudWatch.

So sánh để lựa chọn

Điểm mấu chốt là ngay cả khi chọn server có sẵn, việc thiết kế quyền hạn và thiết kế dấu vết vẫn là việc của bên đặt hàng. Dynamics 365 ERP MCP hoạt động trong phạm vi vai trò bảo mật, nhưng việc gán vai trò nào cho agent là do doanh nghiệp sử dụng quyết định. Gán vai trò rộng thì agent cũng hoạt động rộng. Ngoài ra, server có sẵn chỉ nhìn thấy bên trong ERP, nên các công cụ theo đơn vị nghiệp vụ xuyên suốt MES, QMS và ERP như “lịch sử lô” thường sẽ cần được xây dựng riêng.

Trên thực tế, ở nhiều nhà máy, điểm cân bằng sẽ là kết hợp: dùng server có sẵn cho các thao tác tra cứu và lập phiếu khép kín trong ERP, và tự xây dựng server theo đơn vị nghiệp vụ cho các nghiệp vụ xuyên suốt MES, QMS và quản lý tài liệu. Cách chọn nhà thầu và những điểm cần lưu ý trong hợp đồng phát triển AI được tổng hợp trong bài “Cách chọn công ty phát triển AI“.

Chi phí và ROI khi xây dựng MCP server: ước tính tại nhà máy mẫu

Từ đây, chúng ta sẽ ước tính chi phí và hiệu quả của việc xây dựng MCP server bằng một nhà máy mẫu. Xin nhắc lại, mọi con số dưới đây đều là giá trị ước tính và giả định do chính bài viết đưa ra, không phải mức trung bình của ngành, cũng không phải số liệu khảo sát. Nếu dùng cho tờ trình phê duyệt, hãy thay các tiền đề bằng số liệu của doanh nghiệp mình và tính lại.

Tiền đề chung (nhà máy mẫu P)

• Nhà máy linh kiện điện tử vốn Nhật Bản tại tỉnh Ayutthaya, Thái Lan, 850 nhân viên
• 40 nhân viên phụ trách quản lý sản xuất, đảm bảo chất lượng và mua hàng dành trung bình 45 phút mỗi người mỗi ngày cho “công việc tra cứu”, tức là tìm kiếm và thu thập thông tin từ MES, ERP, QMS và quản lý tài liệu (giá trị giả định)
• Số ngày làm việc là 250 ngày/năm
• Đơn giá giờ công là 250 THB (giá trị tạm đặt của bài viết, gồm lương khối văn phòng, kỹ thuật cộng bảo hiểm xã hội và các khoản tương tự)

Tổng thời gian tra cứu mỗi năm là 40 người × 0,75 giờ × 250 ngày = 7.500 giờ/năm. Nhân với đơn giá giờ công, chi phí nhân công cho công việc tra cứu mỗi năm là 7.500 × 250 = 1.875.000 THB/năm.

Cấu hình 1 “chỉ tham chiếu, công cụ theo đơn vị nghiệp vụ”

Cấu hình chỉ xây dựng công cụ tham chiếu theo đơn vị nghiệp vụ, kèm nền tảng phân quyền và nhật ký kiểm toán.

Về hiệu quả, giả định cắt giảm được 45% thời gian tra cứu (giá trị giả định). 7.500 giờ × 45% = 3.375 giờ, nhân với đơn giá giờ công 250 THB được 843.750 THB/năm.

Lợi ích ròng hằng năm là 843.750 − 380.000 = 463.750 THB/năm, thời gian hoàn vốn giản đơn là 1.400.000 ÷ 463.750 = khoảng 3,0 năm.

Cấu hình 2 “tham chiếu + ghi (lập phiếu, bản nháp, con người phê duyệt xác nhận)”

Cấu hình bổ sung vào cấu hình 1 các công cụ ghi để soạn nháp, lập phiếu như báo cáo sự không phù hợp hay đề nghị thay đổi đơn mua hàng, cùng với luồng phê duyệt.

Hiệu quả được tính bằng phần cắt giảm tra cứu 843.750 THB của cấu hình 1 cộng thêm phần cắt giảm công việc lập phiếu. Giả định mỗi năm có 6.000 phiếu, mỗi phiếu giảm được 15 phút, ta có 6.000 phiếu × 0,25 giờ = 1.500 giờ, và 1.500 × 250 = 375.000 THB. Tổng hiệu quả là 843.750 + 375.000 = 1.218.750 THB/năm.

Điều cần lưu ý ở đây là không tính phần cắt giảm tra cứu hai lần. Hiệu quả của cấu hình 2 là “phần cắt giảm tra cứu của cấu hình 1” cộng với “phần cắt giảm lập phiếu”, chứ bản thân phần cắt giảm tra cứu không tăng lên. Có thể ta muốn cộng thêm vào tỷ lệ cắt giảm tra cứu với lý do “có công cụ ghi thì tra cứu cũng nhẹ hơn”, nhưng đó là tính trùng không có căn cứ.

Lợi ích ròng hằng năm là 1.218.750 − 580.000 = 638.750 THB/năm, thời gian hoàn vốn giản đơn là 2.300.000 ÷ 638.750 = khoảng 3,6 năm.

Phí sử dụng 120.000 THB là giá trị giả định. Trên thực tế, phí sử dụng có thể biến động theo số lần gọi. Ví dụ, Dynamics 365 ERP MCP nói ở trên có cơ chế tiêu tốn 0,1 Copilot Credit cho mỗi lệnh gọi từ client khác ngoài Copilot Studio. Cách chắc chắn nhất để ước tính tần suất gọi công cụ là dựa vào nhật ký của giai đoạn chạy thử.

Điểm mấu chốt 1: cộng dồn 5 năm, thêm công cụ ghi gần như không tạo khác biệt

Nếu chỉ nhìn lợi ích ròng của một năm, cấu hình 2 (638.750 THB/năm) nhiều hơn cấu hình 1 (463.750 THB/năm) 175.000 THB mỗi năm, nên có vẻ thêm công cụ ghi sẽ có lợi hơn. Nhưng khi so sánh lợi ích ròng cộng dồn 5 năm sau khi trừ đầu tư ban đầu, bức tranh thay đổi.

Cấu hình 2 có đầu tư ban đầu nhiều hơn 900.000 THB, và với phần lợi ích ròng tăng thêm 175.000 THB mỗi năm thì trong 5 năm chỉ thu hồi được 875.000 THB. Kết quả là, cộng dồn 5 năm, cấu hình 1 chỉ nhiều hơn 25.000 THB.

Kết quả này cho thấy công cụ ghi không phải là thứ “thêm vào vì có lãi”. Giá trị của công cụ ghi nằm ở chỗ “người phụ trách có thể dành thời gian lập phiếu cho công việc khác” và “giảm sót, lọt khi lập phiếu” hơn là ở số tiền, và để được như vậy thì tiền đề là việc vận hành quyền hạn và dấu vết phải đã chạy trơn tru ở giai đoạn công cụ tham chiếu. 90 ngày đầu tiên bắt đầu chỉ với tham chiếu, sau khi xác nhận vận hành ổn định mới thêm thao tác ghi. Căn cứ cho quyết định này chính là phép so sánh cộng dồn 5 năm.

Điểm mấu chốt 2: một biến số quyết định việc hoàn vốn

Còn một điều quan trọng nữa rút ra từ phép ước tính. Thời gian hoàn vốn của khoản đầu tư này gần như được quyết định bởi một biến số duy nhất: “tỷ lệ cắt giảm thời gian tra cứu”.

Hãy tính trường hợp cấu hình 1 có tỷ lệ cắt giảm thời gian tra cứu là 25% thay vì 45%.

• Hiệu quả: 7.500 giờ × 25% × 250 THB = 468.750 THB/năm
• Lợi ích ròng: 468.750 − 380.000 = 88.750 THB/năm
• Hoàn vốn giản đơn: 1.400.000 ÷ 88.750 = khoảng 15,8 năm

Chỉ cần tỷ lệ cắt giảm hạ từ 45% xuống 25%, thời gian hoàn vốn kéo dài từ khoảng 3,0 năm lên khoảng 15,8 năm. Lý do là chi phí vận hành hằng năm 380.000 THB phát sinh bất kể tỷ lệ cắt giảm, nên chỉ cần hiệu quả giảm một chút là lợi ích ròng bị bào mòn rất nhiều.

Nói cách khác, nếu đặt hàng mà chưa đo thực tế hiện nay đang tốn bao nhiêu thời gian cho công việc tra cứu, thì bản thân quyết định đầu tư cũng không thể đưa ra được. Nếu tiền đề 45 phút mỗi người mỗi ngày thực ra chỉ là 20 phút, thì dù tỷ lệ cắt giảm như nhau, hiệu quả cũng giảm xuống dưới một nửa. Đây là lý do trong kế hoạch 90 ngày ở phần sau, 30 ngày đầu tiên được dành cho “đo thực tế công việc tra cứu”.

12 hạng mục cần ghi trong RFP MCP

Khi chuyển thiết kế 3 lớp và các bài học từ sự cố ở trên thành yêu cầu đặt hàng (RFP), ta có 12 hạng mục sau. Dù dùng server có sẵn hay thuê nhà thầu xây dựng, việc yêu cầu trả lời cho 12 hạng mục này sẽ giúp so sánh các đề xuất dễ dàng hơn.

Đặc biệt, hạng mục thứ 12 là hạng mục dễ bị bỏ sót khi so sánh báo giá. Như việc bản 2026-07-28 đã đưa vào những thay đổi lớn như bãi bỏ phiên và không khuyến nghị HTTP+SSE, đặc tả MCP vẫn là một tiêu chuẩn đang thay đổi. Vì đã có chính sách đặt thời gian không khuyến nghị tối thiểu 12 tháng trước khi bãi bỏ một chức năng, cần quyết định ngay tại thời điểm đặt hàng xem việc “sửa đổi trong vòng 12 tháng kể từ khi có thông báo không khuyến nghị” được tính vào hợp đồng bảo trì hay báo giá riêng. Nếu điểm này mơ hồ, từ năm thứ hai trở đi sẽ phát sinh chi phí sửa đổi ngoài dự kiến.

Về các vấn đề hợp đồng như phạm vi bảo trì hay trách nhiệm đối với khiếm khuyết, hãy tham khảo thêm bài “Những điểm chính trong hợp đồng phát triển hệ thống“.

Những gì cần xác nhận trong FAT/SAT: kiểm thử nghiệm thu MCP server

12 hạng mục ghi trong RFP chỉ có ý nghĩa khi được xác nhận trong kiểm thử nghiệm thu tại xưởng (FAT) và kiểm thử nghiệm thu tại hiện trường (SAT). Các hạng mục kiểm thử đặc thù của MCP server như sau.

Kiểm thử injection không phải đạt một lần là xong. Kết quả có thể thay đổi mỗi khi mô hình được cập nhật hoặc có công cụ mới được thêm vào, nên hãy lưu giữ bộ tài liệu kiểm thử như một tài sản và chạy lại như kiểm thử hồi quy sau mỗi lần sửa đổi. Cách xây dựng kiểm thử nghiệm thu cho AI agent nói chung được giải thích chi tiết trong bài “Kiểm thử nghiệm thu AI agent“.

Các vấn đề đặc thù của Thái Lan: PDPA, dự thảo luật AI, vận hành nhiều cơ sở

Khi xây dựng MCP server tại nhà máy ở Thái Lan, ngoài kỹ thuật còn có 4 vấn đề cần nắm. Lưu ý rằng các quy định được nêu trong phần này (PDPA, dự thảo luật AI, hướng dẫn của ETDA) đều là quy định của Thái Lan. Với những phần liên quan đến pháp luật, nội dung bài viết chỉ dừng ở mức tổng hợp chung, vì vậy các phán đoán cụ thể xin hãy xác nhận riêng với bộ phận pháp chế, chuyên gia hoặc cơ quan có thẩm quyền.

1. Chuyển dữ liệu ra nước ngoài theo PDPA

Nếu mô hình ngôn ngữ mà agent dùng đang chạy trên đám mây ở nước ngoài, giá trị trả về của công cụ sẽ được gửi nguyên sang API của LLM ở nước ngoài. Nếu giá trị trả về chứa dữ liệu cá nhân như họ tên công nhân, mã nhân viên, tên người phụ trách phía đối tác, thì các quy định về chuyển dữ liệu ra nước ngoài của Luật Bảo vệ dữ liệu cá nhân Thái Lan (PDPA) sẽ có liên quan.

Tại Thái Lan, Ủy ban Bảo vệ dữ liệu cá nhân (PDPC) đã ban hành 2 thông báo về chuyển dữ liệu ra nước ngoài vào ngày 25/12/2023, có hiệu lực từ ngày 24/3/2024. Điều 28 là khung dựa trên tiền đề quốc gia, vùng lãnh thổ tiếp nhận có mức độ bảo vệ đầy đủ, còn Điều 29 là khung dựa trên các biện pháp bảo vệ thích hợp như quy tắc doanh nghiệp ràng buộc (BCR) trong tập đoàn hay điều khoản hợp đồng mẫu. Việc sử dụng LLM của doanh nghiệp có thể được xếp vào khung nào cần được xác nhận riêng với bộ phận pháp chế hoặc chuyên gia.

Biện pháp có thể làm từ phía thiết kế là loại bỏ dữ liệu cá nhân khỏi giá trị trả về của công cụ. Nếu thiết kế sao cho công cụ truy xuất lịch sử lô chỉ trả về kết quả công đoạn và kiểm tra, chứ không trả về tên cá nhân của công nhân, thì có thể thu nhỏ chính vấn đề chuyển dữ liệu ra nước ngoài. Việc ở lớp 1 chúng tôi viết “giới hạn giá trị trả về ở những mục cần cho nghiệp vụ” cũng mang ý nghĩa này.

2. Dự thảo luật AI của Thái Lan

Tại Thái Lan, Cơ quan Phát triển Giao dịch Điện tử (ETDA) đã công bố dự thảo luật AI mới vào tháng 7/2026 và tiến hành lấy ý kiến. Dự thảo là một khung tiếp cận dựa trên rủi ro, tham khảo quy định về AI của EU, phân loại AI theo mức độ rủi ro và dự kiến mức phạt hành chính từ 1 triệu đến 5 triệu baht (1.000.000 đến 5.000.000 baht) đối với vi phạm. Tuy nhiên, tính đến tháng 10/2026, đây vẫn ở giai đoạn dự thảo, chưa được thông qua. Nội dung và thời điểm có thể thay đổi, nên về cách xử lý khi dùng agent trong nghiệp vụ nhà máy, hãy xác nhận tình hình mới nhất với chuyên gia hoặc cơ quan có thẩm quyền.

3. Hướng dẫn quản trị AI của ETDA

ETDA đã công bố hướng dẫn quản trị AI dành cho cấp lãnh đạo vào năm 2023, và ngày 30/10/2024, Bộ Kinh tế và Xã hội số (Bộ DE) cùng ETDA đã công bố hướng dẫn quản trị AI tạo sinh dành cho tổ chức. Cả hai đều là hướng dẫn không có tính ràng buộc pháp lý. Tuy không phải nghĩa vụ pháp lý, chúng có thể được dùng làm tài liệu tham chiếu khi xây dựng quy chế nội bộ hoặc yêu cầu đối với nhà thầu.

4. Vận hành nhiều cơ sở, nhiều ngôn ngữ

Cấu hình dùng chung một MCP server cho Thái Lan, Việt Nam và trụ sở chính tại Nhật Bản là hình thức thường gặp ở các doanh nghiệp sản xuất Nhật Bản. Ở đây có 2 vấn đề thực tiễn.

Thứ nhất là tách dữ liệu theo từng cơ sở như đã nói ở trên. Như trường hợp Asana cho thấy, khả năng nhìn thấy dữ liệu giữa các tổ chức có thể bị phá vỡ chỉ vì lỗi phần mềm. Số cơ sở càng nhiều, kiểm thử việc tách dữ liệu càng quan trọng.

Thứ hai là ngôn ngữ của phần mô tả công cụ. Vì phần mô tả công cụ là tài liệu đặc tả mà mô hình đọc, nên viết bằng một ngôn ngữ thống nhất sẽ giúp hành vi của mô hình ít bị dao động giữa các cơ sở hơn là làm riêng bản tiếng Thái, bản tiếng Việt, bản tiếng Nhật cho từng cơ sở. Dù người dùng đặt câu hỏi bằng ngôn ngữ của cơ sở mình, phần mô hình đọc mô tả để chọn công cụ vẫn là chung. Đồng thời, nếu thống nhất các thuật ngữ nghiệp vụ xuất hiện trong giá trị trả về (mã hàng, tên công đoạn, phân loại lỗi, v.v.) bằng một bộ từ điển, thì cùng một câu hỏi sẽ nhận được cùng một câu trả lời giữa các cơ sở. Ngoài ra, có những server có sẵn chỉ hỗ trợ tiếng Anh (Mỹ), như Dynamics 365 ERP MCP, nên hãy đưa cả cách xử lý ngôn ngữ vào danh sách hạng mục cần xác nhận khi chọn sản phẩm.

Kế hoạch 90 ngày triển khai MCP: bắt đầu từ đo thực tế

Các nội dung trên được tổng hợp thành kế hoạch cho 90 ngày đầu tiên. Điểm mấu chốt là không bắt tay xây dựng ngay, mà dành 30 ngày đầu tiên để đo thực tế công việc tra cứu. Như đã thấy ở phần chi phí, thời gian hoàn vốn gần như được quyết định bởi một biến số là tỷ lệ cắt giảm thời gian tra cứu, và nếu không biết điểm xuất phát “hiện nay đang tốn bao nhiêu thời gian” thì không thể đưa ra quyết định đầu tư.

Ngày 0 đến 30: đo thực tế công việc tra cứu và rà soát ứng viên công cụ

• Đề nghị nhân viên quản lý sản xuất, đảm bảo chất lượng và mua hàng ghi lại thời gian và nội dung công việc tra cứu trong 1 đến 2 tuần (đã tìm gì, trên hệ thống nào, mất bao nhiêu phút)
• Từ các bản ghi, lọc ra những thao tác tra cứu tốn nhiều thời gian nhất để làm ứng viên công cụ theo đơn vị nghiệp vụ
• Với từng ứng viên công cụ, sắp xếp hệ thống tham chiếu, các mục cần trả về, các mục không được trả về (như dữ liệu cá nhân) và các bộ phận được phép sử dụng
• Phân định phần có thể đáp ứng bằng MCP server có sẵn và phần cần tự xây dựng

Sản phẩm của giai đoạn này là số liệu đo thực tế công việc tra cứu và danh sách ứng viên công cụ (kèm phân loại tham chiếu/ghi). Đây sẽ trở thành giá trị tiền đề cho phép ước tính, đồng thời là bản nháp cho danh sách công cụ trong RFP.

Ngày 31 đến 60: chạy thử 2 đến 3 công cụ chỉ tham chiếu

• Trong các thao tác tra cứu xếp hạng cao khi đo thực tế, chọn 2 đến 3 thao tác để làm thử dưới dạng công cụ chỉ tham chiếu
• Đưa cơ chế phân quyền (không vượt quá quyền của người yêu cầu) và nhật ký kiểm toán vào ngay từ giai đoạn chạy thử, theo cùng cách nghĩ như khi vận hành thực tế
• Chạy thử với một nhóm người dùng giới hạn, và đo thời gian tra cứu đã giảm bao nhiêu bằng đúng phương pháp đã dùng khi đo thực tế trong 30 ngày đầu
• Từ nhật ký, tìm ra các trường hợp chọn nhầm công cụ, phần mô tả còn thiếu, giá trị trả về thừa hoặc thiếu, rồi cải thiện

Tỷ lệ cắt giảm đo được trong giai đoạn chạy thử sẽ là căn cứ cho quyết định đầu tư triển khai chính thức. Giả sử tỷ lệ cắt giảm chỉ dừng ở mức khoảng 25%, thì như đã thấy ở điểm mấu chốt 2, thời gian hoàn vốn sẽ kéo dài rất nhiều, và đó là căn cứ để xem lại cách chọn công cụ hoặc nghiệp vụ đối tượng.

Ngày 61 đến 90: FAT/SAT và quyết định có cần thao tác ghi hay không

• Thực hiện FAT/SAT với các hạng mục kiểm thử ở phần trước, xác nhận việc từ chối ngoài quyền, tách dữ liệu theo cơ sở và tính đầy đủ của nhật ký
• Xây dựng bộ tài liệu kiểm thử injection và lưu giữ làm tài sản cho kiểm thử hồi quy
• Thử vận hành thực tế việc ai xem nhật ký kiểm toán và xem với tần suất nào
• Sau khi xác nhận việc vận hành tham chiếu đã ổn định, quyết định có bổ sung công cụ ghi (bản nháp, lập phiếu) hay không

Như đã thấy ở điểm mấu chốt 1, việc có thêm công cụ ghi hay không được quyết định không phải bởi câu hỏi “có lãi không”, mà bởi câu hỏi “việc vận hành quyền hạn và dấu vết ở giai đoạn tham chiếu đã chạy ổn định chưa”. Nếu chưa, câu trả lời đúng là hoãn thao tác ghi và tiếp tục cải thiện công cụ tham chiếu.

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

MCP server là gì? Khác gì so với API?

MCP server là quầy tiếp nhận được xây dựng theo tiêu chuẩn chung (MCP) để AI agent gọi dữ liệu và chức năng của các hệ thống bên ngoài. API được thiết kế với tiền đề lập trình viên gọi từ chương trình, nên thứ tự và phạm vi gọi do chương trình quyết định. Còn công cụ MCP được agent đọc phần mô tả rồi tự phán đoán để chọn và gọi, vì vậy phần mô tả công cụ trở thành tài liệu đặc tả đối với mô hình, và phạm vi có thể gọi chính là giới hạn trên của sự cố. Điều quan trọng là không bọc nguyên API hiện có, mà thiết kế lại công cụ theo đơn vị nghiệp vụ.

Chi phí xây dựng MCP server là bao nhiêu?

Chi phí thay đổi rất nhiều tùy vào số nghiệp vụ đối tượng, chỉ tham chiếu hay có cả thao tác ghi, và có dùng được server có sẵn hay không. Trong phép ước tính tại nhà máy mẫu của bài viết này (công việc tra cứu 7.500 giờ/năm), cấu hình chỉ tham chiếu được đặt ở mức đầu tư ban đầu 1.400.000 THB và vận hành hằng năm 380.000 THB, còn cấu hình có thêm thao tác ghi là đầu tư ban đầu 2.300.000 THB và vận hành hằng năm 580.000 THB. Đây là các giá trị ước tính do chính bài viết đưa ra, không phải mức giá thị trường. Thời gian hoàn vốn biến động mạnh theo tỷ lệ cắt giảm thời gian tra cứu, vì vậy chúng tôi khuyên trước hết hãy đo thực tế công việc tra cứu.

Nên chọn MCP server có sẵn (do nhà cung cấp ERP cung cấp) hay xây dựng từ đầu?

Với các thao tác tra cứu và lập phiếu khép kín trong ERP, các server có sẵn như Dynamics 365 ERP MCP hay AWS for SAP MCP Server sẽ khởi động nhanh. Mặt khác, các công cụ theo đơn vị nghiệp vụ xuyên suốt MES, QMS và ERP như “lịch sử lô” thường sẽ cần tự xây dựng (hoặc thuê nhà thầu). Dù chọn hướng nào, việc gán quyền nào cho agent, lưu dấu vết ra sao và ai xem vẫn là việc bên đặt hàng phải quyết định.

Điều cần quyết định đầu tiên trong bảo mật MCP là gì?

Đó là nguyên tắc “quyền hạn của agent không vượt quá quyền hạn của người yêu cầu”. Trên cơ sở đó, cần quyết định: định nghĩa scope theo đơn vị nghiệp vụ và không đặt scope bao trùm; server kiểm tra đích đến của token và không chuyển tiếp token; ghi mọi lệnh gọi công cụ vào nhật ký kiểm toán; lập danh sách cho phép các MCP server và gói phụ thuộc được dùng. Nếu có khả năng gửi dữ liệu cá nhân tới LLM ở nước ngoài, hãy xác nhận riêng với bộ phận pháp chế hoặc chuyên gia về quy định chuyển dữ liệu ra nước ngoài theo PDPA (luật của Thái Lan).

Có nên kết nối PLC hay thiết bị với AI qua MCP không?

Bài viết này khuyến nghị không đưa thao tác ghi vào PLC và hệ thống điều khiển vào phạm vi của MCP. Lý do là thao tác ghi vào hệ thống điều khiển khi sai thì không thể khôi phục sau đó, và ảnh hưởng trực tiếp đến thiết bị cũng như an toàn của con người. OPC UA MCP server của OPC Foundation, ngay cả ở phiên bản mới nhất 2.0.0-preview.6 công bố ngày 30/9/2026, vẫn đang ở giai đoạn preview, nên hợp lý nhất là không dùng cho mục đích điều khiển trong vận hành thực tế mà chỉ dừng ở mục đích tham chiếu trong môi trường kiểm chứng.

Mất bao lâu để triển khai?

Bài viết này đề xuất tổ chức 90 ngày đầu tiên thành 3 giai đoạn: ngày 0 đến 30 đo thực tế công việc tra cứu và rà soát ứng viên công cụ, ngày 31 đến 60 chạy thử 2 đến 3 công cụ chỉ tham chiếu, ngày 61 đến 90 thực hiện FAT/SAT và quyết định có cần thao tác ghi hay không. Thời gian đến khi triển khai toàn diện trong vận hành thực tế sẽ thay đổi tùy theo số nghiệp vụ đối tượng, số cơ sở và việc có dùng server có sẵn hay không. Ngoài ra, dự thảo luật AI của Thái Lan tính đến tháng 10/2026 vẫn ở giai đoạn dự thảo, chưa được thông qua, nên về mặt quy định, hãy xác nhận riêng với chuyên gia hoặc cơ quan có thẩm quyền.

Tổng kết: xây dựng MCP server là mở “cửa sổ nghiệp vụ”

• Xây dựng MCP server như một “cửa sổ nghiệp vụ” chứ không phải “cửa sổ cơ sở dữ liệu”. Nối nguyên cơ sở dữ liệu hay ERP bằng connector đa dụng sẽ cùng lúc mang 3 vấn đề: quyền hạn quá rộng, không có dấu vết và không thể nghiệm thu
• Thành bại được quyết định bởi 3 lớp: (1) thiết kế công cụ theo đơn vị nghiệp vụ, (2) phân quyền không vượt quá quyền của người yêu cầu, (3) dấu vết của mọi lệnh gọi
• Tách tham chiếu và ghi, với thao tác ghi thì “chỉ đến bản nháp và lập phiếu, việc xác nhận do con người làm”. Không đưa thao tác ghi vào PLC và hệ thống điều khiển vào phạm vi MCP
• Việc lộ dữ liệu giữa các tổ chức của Asana, Toxic Agent Flow, lỗ hổng trong công cụ chính thức và postmark-mcp lần lượt cho thấy tách dữ liệu theo cơ sở, cách xử lý tài liệu bên ngoài, quản lý phiên bản và danh sách cho phép đều là yêu cầu thiết kế
• Trong phép ước tính tại nhà máy mẫu, cấu hình 1 chỉ tham chiếu có lợi ích ròng 463.750 THB/năm, hoàn vốn khoảng 3,0 năm; cấu hình 2 có thêm thao tác ghi có lợi ích ròng 638.750 THB/năm, hoàn vốn khoảng 3,6 năm. Cộng dồn 5 năm, cấu hình 1 đạt 918.750 THB, cấu hình 2 đạt 893.750 THB, chênh lệch chỉ 25.000 THB
• Nếu tỷ lệ cắt giảm hạ từ 45% xuống 25%, thời gian hoàn vốn của cấu hình 1 kéo dài lên khoảng 15,8 năm. Không thể ra quyết định đầu tư nếu chưa đo thực tế công việc tra cứu
• Trong RFP, ghi 12 hạng mục, bao gồm phiên bản đặc tả, phương thức phân quyền, danh sách scope và công cụ, nhật ký kiểm toán, tách dữ liệu theo cơ sở, xử lý lỗ hổng và việc theo kịp sửa đổi đặc tả

MCP đã thay đổi diện mạo đáng kể với bản 2026-07-28 và vẫn là một tiêu chuẩn đang thay đổi. Chính vì vậy, thay vì các chi tiết của đặc tả, việc chốt trước những phần không đổi dù đặc tả thay đổi, tức là biến nghiệp vụ nào thành công cụ, cho phép ai làm gì và ghi lại những gì, mới là sự chuẩn bị chắc chắn nhất đối với bên đặt hàng.

Chúng tôi có thể hỗ trợ ngay từ giai đoạn trước khi bắt tay xây dựng, như rà soát nghiệp vụ nào nên biến thành công cụ hay thiết kế cách đo thực tế công việc tra cứu. Kể cả khi bạn muốn tính lại phép ước tính theo tiền đề của doanh nghiệp mình, xin đừng ngần ngại liên hệ qua trang Liên hệ.

Thông tin tham khảo

• Đặc tả MCP (bản mới nhất): https://modelcontextprotocol.io/specification/latest
• Lịch sử thay đổi đặc tả MCP bản 2026-07-28: https://modelcontextprotocol.io/specification/2026-07-28/changelog
• Blog chính thức của MCP “The 2026-07-28 Specification”: https://blog.modelcontextprotocol.io/posts/2026-07-28/
• Đặc tả MCP bản 2026-07-28, phân quyền: https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
• MCP Security Best Practices (bản 2025-11-25): https://modelcontextprotocol.io/specification/2025-11-25/basic/security_best_practices
• Linux Foundation công bố thành lập “Agentic AI Foundation”: https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
• OWASP MCP Top 10: https://owasp.org/www-project-mcp-top-10/
• NVD CVE-2025-6514: https://nvd.nist.gov/vuln/detail/CVE-2025-6514
• GitHub Advisory GHSA-6xpm-ggf7-wc3p: https://github.com/advisories/GHSA-6xpm-ggf7-wc3p
• NVD CVE-2025-49596: https://nvd.nist.gov/vuln/detail/CVE-2025-49596
• GitHub Advisory GHSA-7f8r-222p-6f5g: https://github.com/advisories/GHSA-7f8r-222p-6f5g
• NVD CVE-2025-68143: https://nvd.nist.gov/vuln/detail/CVE-2025-68143
• NVD CVE-2025-68144: https://nvd.nist.gov/vuln/detail/CVE-2025-68144
• NVD CVE-2025-68145: https://nvd.nist.gov/vuln/detail/CVE-2025-68145
• Invariant Labs (Toxic Agent Flow của GitHub MCP): https://invariantlabs.ai/blog/mcp-github-vulnerability
• BleepingComputer (lộ dữ liệu giữa các tổ chức trên Asana MCP): https://www.bleepingcomputer.com/news/security/asana-warns-mcp-ai-feature-exposed-customer-data-to-other-orgs/
• The Hacker News (postmark-mcp): https://thehackernews.com/2025/09/first-malicious-mcp-server-found.html
• Microsoft Learn “Dynamics 365 ERP MCP”: https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/copilot/copilot-mcp
• AWS, cung cấp chính thức “AWS for SAP MCP Server”: https://aws.amazon.com/about-aws/whats-new/2026/05/aws-sap-mcp-amazon-bedrock/
• NuGet “OPCFoundation.NetStandard.Opc.Ua.Mcp”: https://www.nuget.org/packages/OPCFoundation.NetStandard.Opc.Ua.Mcp
• Tilleke & Gibbins (chuyển dữ liệu ra nước ngoài theo PDPA Thái Lan): https://www.tilleke.com/insights/thailand-unveils-regulations-for-cross-border-personal-data-transfer/
• Tilleke & Gibbins (dự thảo luật AI của Thái Lan): https://www.tilleke.com/insights/thailand-releases-new-draft-artificial-intelligence-act
• Rajah & Tann Asia (dự thảo luật AI của Thái Lan): https://www.rajahtannasia.com/viewpoints/thailands-proposed-ai-law-moving-towards-a-risk-based-regulatory-framework/
• OECD.AI (AI Governance Guideline for Executives): https://oecd.ai/en/dashboards/policy-initiatives/ai-governance-guideline-for-executives-8517
• Digital Policy Alert (Generative AI Governance Guideline for Organisations): https://digitalpolicyalert.org/change/11675-de-and-etda-generative-ai-governance-guideline-for-organisations
• Gartner (công bố ngày 25/6/2025): https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027