Người dùng phần mềm tiếp theo là tác tử AI. Kiến trúc hệ thống đã sẵn sàng?

Góc nhìn chuyên gia Người dùng phần mềm tiếp theo là tác tử AI. Kiến trúc hệ thống đã sẵn sàng? Ngày đăng Ngày 9/11/2026 Tác giả Guy Merritt, Giám đốc Công nghệ, KMS Technology Thêm Unite.AI vào nguồn tin ưu tiên trên Google Xét trường hợp một tác nhân AI (AI agent) xử lý tranh chấp hóa đơn của khách hàng. Hệ thống đọc khiếu nại, kiểm tra lịch sử tài khoản và xác định việc hoàn tiền là hợp lý. Toàn bộ quy trình diễn ra chỉ trong vài giây. Kết quả này rất ấn tượng. Tuy nhiên, vấn đề nảy sinh khi yêu cầu hệ thống thực hiện thao tác hoàn tiền trên thực tế. Hợp đồng khách hàng nằm ở một hệ thống khác. Các quy tắc phê duyệt bị ẩn sâu trong mã nguồn ứng dụng. Trong khi đó, công cụ thanh toán lại đòi hỏi con người phải thao tác thủ công qua nhiều màn hình. Tác nhân AI hiểu rõ quy trình cần thực hiện, nhưng kiến trúc hệ thống hiện tại không cho phép hoàn tất nhiệm vụ. Đây là thách thức được dự báo nhiều doanh nghiệp sẽ phải đối mặt khi đưa AI tác tử (agentic AI) vào môi trường vận hành thực tế. Đáng chú ý, rào cản ngăn việc hoàn thành tác vụ lại hầu như không bắt nguồn từ năng lực trí tuệ của AI. Nhiều năm qua, các doanh nghiệp đã nỗ lực hiện đại hóa phần mềm để phục vụ người dùng là con người. Hiện tại, yêu cầu đặt ra là phải hiện đại hóa các phần mềm đó để phục vụ chính các tác nhân AI – đối tượng sẽ ngày càng trực tiếp vận hành hệ thống. Giao diện người dùng chưa bao giờ là toàn bộ sản phẩm Xét phương thức vận hành của phần mềm doanh nghiệp hiện nay: con người mở ứng dụng, điều hướng qua các bảng điều khiển, đưa ra quyết định và luân chuyển công việc từ hệ thống này sang hệ thống khác. Giao diện người dùng chính là phương thức tương tác giữa con người với hoạt động kinh doanh. Đối với tác nhân AI, những màn hình giao diện này không còn là yếu tố bắt buộc. Hệ thống có thể truy xuất thông tin và kích hoạt hành động thông qua các giao diện lập trình ứng dụng (API), máy chủ Giao thức Bối cảnh Mô hình (Model Context Protocol - MCP) và các giao diện lập trình khác. Đây là một phần của xu hướng chuyển dịch sang kiến trúc phi giao diện (headless architecture). Dẫu vậy, kiến trúc phi giao diện không đồng nghĩa với việc ứng dụng biến mất. Dữ liệu, quy tắc kinh doanh, phân quyền và các yêu cầu tuân thủ của ứng dụng vẫn giữ vai trò quan trọng, thậm chí ngày càng mang tính quyết định hơn. Trong nhiều năm, các nhà cung cấp phần mềm đã xây dựng lợi thế cạnh tranh dựa trên giao diện người dùng trau chuốt, thói quen sử dụng và chi phí đào tạo lại nhân sự. Những lợi thế này sẽ suy giảm khi các tác nhân AI đảm nhiệm nhiều phần việc hơn mà không cần mở giao diện ứng dụng. Khi đó, giá trị cốt lõi sẽ dịch chuyển về hệ thống lưu trữ gốc (system of record), bao gồm: dữ liệu đáng tin cậy, quy chuẩn nghiệp vụ đã được kiểm chứng, năng lực quản trị vận hành và khả năng kiểm toán các giao dịch. Sự thay đổi này cũng kéo theo những hệ quả thương mại: ước tính có tới 234 tỷ USD chi tiêu cho các ứng dụng doanh nghiệp có nguy cơ bị tác động bởi làn sóng AI tác tử vào năm 2030. Đây là khoản chi tiêu chịu rủi ro gián đoạn, không đồng nghĩa sẽ hoàn toàn biến mất. Khi các tác nhân AI thay thế con người xử lý công việc trên các bảng điều khiển, mô hình tính phí theo người dùng (per-seat) có thể sẽ dần nhường chỗ cho các mô hình định giá dựa trên mức độ sử dụng, hành vi hoặc kết quả thực tế. Đối với các nhà cung cấp phần mềm, đây là bài toán về mô hình kinh doanh. Còn đối với các doanh nghiệp phụ thuộc vào các ứng dụng này, đây là thách thức về mặt kiến trúc công nghệ. Hiện đại hóa từng bộ phận, chưa hiện đại hóa quy trình làm việc Phần lớn các doanh nghiệp đã triển khai hiện đại hóa trong nhiều năm qua. Một bộ phận chịu trách nhiệm nâng cấp các ứng dụng cũ; bộ phận khác hợp nhất dữ liệu phân tán lên nền tảng hiện đại; bộ phận thứ ba xây dựng các kết nối tích hợp hoặc đơn thuần là làm mới giao diện người dùng. Mỗi dự án đều có thể thành công độc lập. Tuy nhiên, trở ngại chỉ thực sự xuất hiện khi một tác nhân AI cần thực thi quy trình làm việc xuyên suốt toàn bộ các hệ thống đó. Hệ thống có thể cung cấp thông tin khách hàng chính xác cho tác nhân AI, song quy trình sẽ đình trệ nếu ứng dụng thực thi vẫn giữ các quy tắc then chốt bị chôn vùi trong mã nguồn cũ. Tương tự, một API được thiết kế chuẩn xác cũng trở nên vô nghĩa nếu dữ liệu phía sau thiếu tính nhất quán. Tác nhân AI có thể hành động, nhưng quyết định đó liệu có bảo đảm độ tin cậy? Trong cả hai trường hợp, việc hiện đại hóa mới chỉ dừng lại ở các cấu phần công nghệ riêng lẻ, chưa hiện đại hóa toàn diện quy trình làm việc. AI tác tử không đo lường thành công qua từng dự án hiện đại hóa đơn lẻ, mà đòi hỏi sự vận hành đồng bộ của toàn bộ quy trình làm việc. Thực tế triển khai đã phản ánh rõ điều này. Một khách hàng có nhu cầu đẩy nhanh tiến độ báo giá cho các dịch vụ sửa chữa động cơ phức tạp, trong bối cảnh các hợp đồng quy định cụ thể linh kiện nào được phép sửa chữa, thay thế hoặc tân trang... ...tất. Mỗi báo giá trước đây đòi hỏi nhiều ngày, thậm chí nhiều tuần tra cứu thủ công qua các hợp đồng và tài liệu hướng dẫn bảo trì. Khách hàng đã hiện đại hóa nền tảng dữ liệu, nhưng tốc độ xử lý báo giá vẫn không được cải thiện do điểm nghẽn chưa từng nằm ở dữ liệu, mà nằm ở khâu nghiên cứu. Sau khi quy trình làm việc được tái cấu trúc xoay quanh một bộ tác tử nghiên cứu (research agent), thời gian xử lý đã giảm 80%, giúp tốc độ xử lý báo giá được nâng lên rõ rệt. Đây là lý do việc hiện đại hóa ứng dụng và dữ liệu không thể được hoạch định như hai luồng công việc độc lập. Kiến trúc hệ thống phải hỗ trợ toàn diện kết quả kinh doanh cuối cùng. API không đồng nghĩa với việc hệ thống đã sẵn sàng cho tác tử Nhiều quan điểm cho rằng giải pháp rất đơn giản: chỉ cần mở các điểm cuối (endpoint), kết nối tác tử là hoàn tất. Tuy nhiên, thực tế không đơn giản như vậy. Truy xuất thông tin là một vấn đề, nhưng phát hành chứng từ tín dụng, cập nhật hồ sơ tài chính hay đặt mua linh kiện thay thế lại là vấn đề hoàn toàn khác. Khi đó, yêu cầu đặt ra không chỉ dừng lại ở quyền truy cập, mà là năng lực thực thi. Ở khía cạnh này, thuật ngữ "bề mặt kiểm soát tác tử" (agent control surface) được hiểu là giao diện có giới hạn và được quản trị chặt chẽ, cho phép các tác tử đọc và ghi dữ liệu vào các hệ thống lưu trữ gốc (systems of record). Các API và máy chủ MCP có thể cung cấp công cụ cùng dữ liệu cho các tác tử. Tuy nhiên, MCP không tự động thực thi các quy tắc nghiệp vụ hoặc phân quyền hành động. Những cơ chế kiểm soát này vẫn phải được thiết kế trực tiếp trong các hệ thống nền tảng và quy trình làm việc. Liệu tác tử có thể truy xuất dữ liệu có thẩm quyền? Các quy tắc nghiệp vụ có rõ ràng và được áp dụng nhất quán hay không? Tác tử có thể đưa ra đề xuất nhưng chỉ thực thi các tác vụ được phân quyền hay không? Khi xảy ra sự cố, hệ thống có khả năng truy vết hành động, xử lý ngoại lệ và đảo ngược thao tác nếu cần thiết hay không? Đây không phải là những bài toán mà một mô hình ưu việt hơn có thể tự giải quyết. Đó là các vấn đề liên quan đến quy trình làm việc, thiết kế ứng dụng, kiến trúc dữ liệu, tích hợp hệ thống và quản trị, đòi hỏi phải được xử lý một cách đồng bộ. Bắt đầu từ công việc, không phải công nghệ Vậy nên bắt đầu từ đâu? Quá trình này không nên bắt đầu bằng việc chuyển đổi mọi ứng dụng sang kiến trúc không giao diện (headless) hay mở toàn bộ API hiện có, mà cần bắt đầu từ một quy trình nghiệp vụ trọng yếu cụ thể. Cần theo dõi quy trình đó từ đầu đến cuối: Hệ thống nào đang lưu trữ dữ liệu gốc? Logic nghiệp vụ nằm ở đâu? Dữ liệu nào đủ độ tin cậy để tác tử sử dụng? Quyết định nào cần con người phê duyệt? Điều gì sẽ xảy ra khi một hệ thống gặp sự cố giữa chừng?