Người dùng phần mềm tiếp theo của bạn là một tác tử AI. Kiến trúc của bạn đã sẵn sàng chưa?

Hãy hình dung một tác tử AI xử lý tranh chấp về hóa đơn của khách hàng. Tác tử đọc khiếu nại, kiểm tra lịch sử tài khoản và xác định rằng khách hàng đủ điều kiện được ghi có. Tất cả chỉ trong vài giây.

Ấn tượng đấy. Giờ hãy yêu cầu tác tử thực sự cấp khoản ghi có đó.

Thỏa thuận với khách hàng nằm trong một hệ thống khác. Các quy tắc phê duyệt bị chôn sâu trong mã ứng dụng. Công cụ thanh toán yêu cầu một người phải nhấp qua nhiều màn hình.

Tác tử hiểu cần làm gì, nhưng kiến trúc không cho phép nó hoàn tất công việc.

Đó là vấn đề mà tôi cho rằng ngày càng nhiều doanh nghiệp sẽ gặp phải khi AI dạng tác tử được đưa vào vận hành thực tế. Tuy nhiên, điều lạ là trở ngại khiến tác vụ không thể hoàn tất hầu như chẳng liên quan gì đến trí tuệ của tác tử.

Trong nhiều năm, chúng ta đã hiện đại hóa phần mềm doanh nghiệp cho những người sử dụng nó. Giờ đây, chúng ta cần hiện đại hóa phần mềm cho các tác tử sẽ ngày càng đảm nhiệm nhiều hoạt động trên đó.

Giao diện người dùng chưa bao giờ là toàn bộ sản phẩm

Hãy nghĩ về cách phần mềm doanh nghiệp hoạt động ngày nay. Mọi người mở ứng dụng, điều hướng qua các bảng thông tin, đưa ra quyết định và 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 là phương thức để họ tương tác với doanh nghiệp.

Tác tử không nhất thiết cần những màn hình đó. Nó có thể truy xuất thông tin và khởi tạo hành động thông qua API, máy chủ 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 sang kiến trúc không giao diện.

Tuy nhiên, không giao diện không có nghĩa là ứng dụng biến mất. Dữ liệu, quy tắc nghiệp vụ, quyền hạn và yêu cầu tuân thủ của ứng dụng vẫn rất quan trọng. Tôi cho rằng chúng còn quan trọng hơn trước.

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 chỉn chu, thói quen của người dùng và chi phí đào tạo lại nhân viên. Những lợi thế đó suy yếu khi các tác tử đảm nhiệm nhiều công việc hơn mà không cần mở giao diện ứng dụng. Khi ấy, hệ thống ghi nhận dữ liệu nền tảng trở nên có giá trị hơn: dữ liệu đáng tin cậy, logic nghiệp vụ đã được kiểm chứng, quản trị hoạt động và các giao dịch có thể kiểm toán.

Hệ quả thương mại cũng rất đáng kể: đến năm 2030, khoản chi tiêu lên tới 234 tỷ USD cho các ứng dụng doanh nghiệp có thể chịu tác động từ sự đột phá của AI dạng tác tử. Đây là khoản chi tiêu có nguy cơ bị xáo trộn, chứ không phải khoản chắc chắn sẽ biến mất. Và khi tác tử đảm nhiệm những công việc trước đây do con người thực hiện trên các bảng thông tin, mô hình định giá theo từng người dùng có thể ngày càng nhường chỗ cho các mô hình tính phí theo mức sử dụng, hành động hoặc kết quả.

Với các nhà cung cấp phần mềm, đây là thách thức về mô hình kinh doanh. Với các doanh nghiệp phụ thuộc vào ứng dụng của họ, đây là thách thức về kiến trúc.

Chúng ta đã hiện đại hóa từng phần, chứ chưa hiện đại hóa quy trình làm việc

Hầu hết doanh nghiệp đã tiến hành hiện đại hóa trong nhiều năm. Một nhóm nâng cấp các ứng dụng cũ. Nhóm khác hợp nhất dữ liệu phân mảnh trên một nền tảng hiện đại. Nhóm thứ ba xây dựng các tích hợp hoặc đơn giản là làm mới giao diện người dùng.

Mỗi dự án đều có thể thành công khi xét riêng. Vấn đề bắt đầu khi một tác tử cần thực hiện quy trình công việc xuyên suốt tất cả các dự án đó.

Bạn có thể cung cấp cho một tác tử thông tin chính xác về khách hàng, nhưng nếu ứng dụng chịu trách nhiệm xử lý thông tin đó vẫn giấu các quy tắc then chốt trong mã cũ thì chuyện gì sẽ xảy ra tiếp theo? Hoặc bạn có thể cung cấp một API gọn gàng trong khi dữ liệu đằng sau nó vẫn thiếu nhất quán. Tác tử có thể thực hiện hành động, nhưng liệu bạn có thể tin tưởng vào quyết định đó không?

Trong cả hai trường hợp, chúng ta đã hiện đại hóa một phần công nghệ mà chưa hiện đại hóa công việc.

AI dạng tác tử không quan tâm dự án hiện đại hóa nào đã thành công. Điều quan trọng với nó là toàn bộ quy trình công việc có vận hành hiệu quả hay không.

Đây là cách điều đó diễn ra trong thực tế. Một khách hàng cần rút ngắn thời gian lập báo giá cho các ca sửa chữa động cơ phức tạp, trong đó hợp đồng quy định bộ phận nào được phép sửa chữa, thay thế hoặc tân trang. Mỗi báo giá mất vài ngày, đôi khi vài tuần, để nghiên cứu thủ công các hợp đồng và sổ tay bảo trì. Khách hàng đã hiện đại hóa nền tảng dữ liệu, nhưng tốc độ lập báo giá vẫn không cải thiện vì nút thắt chưa bao giờ nằm ở dữ liệu. Nút thắt là khâu nghiên cứu. Chúng tôi xây dựng lại quy trình đó dựa trên một bộ tác tử nghiên cứu, giảm 80% thời gian nghiên cứu và giúp tốc độ lập báo giá thay đổi hoàn toàn.

Đó là lý do không thể lập kế hoạch hiện đại hóa ứng dụng và dữ liệu như hai luồng công việc độc lập. Kiến trúc phải hỗ trợ toàn bộ kết quả kinh doanh.

API không khiến hệ thống sẵn sàng cho tác tử

Người ta dễ nghĩ rằng giải pháp rất đơn giản: mở các điểm cuối, kết nối tác tử là xong.

Ước gì mọi chuyện đơn giản như vậy.

Truy xuất thông tin là một chuyện. Cấp khoản ghi có, cập nhật hồ sơ tài chính hoặc đặt mua linh kiện thay thế lại là chuyện hoàn toàn khác. Lúc này, chúng ta đang nói đến việc thực thi, chứ không chỉ là quyền truy cập.

Đây là lúc tôi dùng thuật ngữ lớp kiểm soát dành cho tác tử: giao diện có phạm vi giới hạn và được quản trị, qua đó các tác tử đọc dữ liệu từ và ghi dữ liệu vào các hệ thống ghi nhận.

API và máy chủ MCP có thể cung cấp công cụ và dữ liệu cho các tác tử. Nhưng MCP không tự động thực thi các quy tắc kinh doanh của bạn hay quyết định ai được phép hành động. Những cơ chế kiểm soát đó vẫn cần được thiết kế vào các hệ thống và quy trình công việc nền tảng.

Tác tử có thể truy xuất dữ liệu có thẩm quyền không? Các quy tắc kinh doanh có được quy định rõ ràng và áp dụng nhất quán không? Tác tử có thể đề xuất hành động nhưng chỉ thực hiện những hành động mà nó được phép thực hiện không? Khi xảy ra sự cố, chúng ta có thể truy vết hành động, xử lý ngoại lệ và, khi có thể, đảo ngược hành động đó không?

Đây không phải là những vấn đề mà chỉ cần một mô hình tốt hơn là có thể tự giải quyết. Đó là những câu hỏi về quy trình công việc, thiết kế ứng dụng, kiến trúc dữ liệu, tích hợp và quản trị. Và cần phải trả lời tất cả những câu hỏi ấy cùng nhau.

Hãy bắt đầu từ công việc, không phải công nghệ

Vậy bạn nên bắt đầu từ đâu?

Tôi sẽ không bắt đầu bằng cách chuyển mọi ứng dụng sang dạng không giao diện người dùng hoặc công khai mọi API hiện có. Tôi sẽ bắt đầu với một quy trình công việc kinh doanh có ý nghĩa.

Hãy lần theo quy trình từ đầu đến cuối. Hệ thống nào lưu giữ hồ sơ? Logic kinh doanh nằm ở đâu? Tác tử có thể tin cậy dữ liệu nào? Những quyết định nào cần được con người phê duyệt? Điều gì xảy ra khi một hệ thống gặp sự cố giữa chừng? Việc quản trị được duy trì như thế nào?

Bạn sẽ tìm ra những lỗ hổng quan trọng. Đó chính là lộ trình hiện đại hóa của bạn: một danh sách công việc tồn đọng được phối hợp xuyên suốt các ứng dụng, dữ liệu, tích hợp và cơ chế kiểm soát, hướng đến một kết quả kinh doanh thay vì những dự án công nghệ rời rạc.

Và hãy đánh giá dựa trên những tiêu chí tương ứng. Không phải số lượng API bạn đã công khai hay lượng dữ liệu bạn đã chuyển đổi, mà là quy trình công việc có hoàn tất một cách đáng tin cậy hay không, các ngoại lệ được giải quyết như thế nào và kết quả kinh doanh có được cải thiện hay không.

Mục tiêu không phải là tự chủ ở mọi nơi. Mục tiêu là thực thi đáng tin cậy, với sự phán đoán của con người ở những nơi cần thiết.

Sự chuyển đổi thực sự vượt xa việc loại bỏ giao diện người dùng

Điều khiến tôi hào hứng không phải là loại bỏ các bảng điều khiển. Mà là viễn cảnh mọi người không còn phải tự chuyển công việc thủ công giữa các hệ thống rời rạc để hoàn thành nhiệm vụ.

Nhưng chúng ta sẽ không đạt được điều đó nếu đặt một tác tử lên trên kiến trúc vốn chưa bao giờ được thiết kế cho nó.

Thế hệ phần mềm doanh nghiệp tiếp theo sẽ không chỉ được định hình bởi những gì nó cho phép con người nhìn thấy. Nó sẽ được định hình bởi những gì nó cho phép các tác tử thực hiện một cách đáng tin cậy và có trách nhiệm.