Agent AI trong doanh nghiệp: Không chỉ là prompt, mà là kiến trúc

Hãy tưởng tượng đội tài chính của bạn trong kỳ chốt sổ cuối tháng. Dữ liệu nằm rải rác khắp ERP, bảng tính gửi qua email, ghi chép thủ công từ các bộ phận dịch vụ chung. Việc đối chiếu mất nhiều ngày. Kiểm tra bất thường còn lâu hơn. Phê duyệt trở thành nút thắt cổ chai.

Giờ hãy tưởng tượng một thứ có thể theo dõi lịch chốt sổ, phát hiện đơn vị nào chưa nộp đối chiếu, gắn cờ các bút toán nghi vấn, thu thập bằng chứng từ nhiều hệ thống, và chuẩn bị đề xuất cho kế toán trưởng — tất cả trong vài phút, thay vì nhiều ngày.

Nghe hấp dẫn. Nhưng câu hỏi tức thời không phải là chúng ta có xây được nó không? Mà là làm thế nào để nó hoạt động trong một công ty thực tế, không chỉ là một bản demo bóng bẩy?

Câu hỏi đó dẫn thẳng đến agentic enterprise architecture — kiến trúc doanh nghiệp cho tác tử AI. Thuật ngữ nghe có vẻ kỹ thuật, nhưng bản chất của nó là vận hành sâu sắc. Đó là bản thiết kế cho cách các tác tử AI nằm trên các hệ thống hiện có của bạn, cách chúng hiểu bối cảnh kinh doanh, cách chúng hành động thông qua các công cụ doanh nghiệp, và — quan trọng nhất — cách mọi hành động được kiểm soát để hệ thống an toàn, có thể kiểm toán, và có thể mở rộng.

Nếu không có kiến trúc này, các công ty thường rơi vào một trong hai cái bẫy. Hoặc AI dừng lại ở một chatbot thông minh trả lời câu hỏi nhưng không bao giờ hoàn thành công việc. Hoặc tác tử được cấp quyền truy cập hệ thống quá rộng đến mức trở thành cơn ác mộng về tuân thủ và bảo mật. Cả hai đều nguy hiểm như nhau.

Đây không chỉ là một chatbot thông minh hơn

Nhiều tổ chức vẫn xem agentic AI như một phần mở rộng tự nhiên của generative AI: model tốt hơn, prompt tốt hơn, giao diện chat tốt hơn. Quan điểm đó quá hẹp.

Điều thực sự đang xảy ra gần với sự tiến hóa của các nền tảng doanh nghiệp hơn. Trong nhiều thập kỷ, ERP, CRM, HRIS và các công cụ workflow là xương sống của giao dịch và kiểm soát. Chúng được xây dựng để chuẩn hóa quy trình. Chúng mạnh mẽ cho các quy tắc ổn định, nhưng mong manh khi đối mặt với điều phối xuyên hệ thống, xử lý ngoại lệ và các quyết định vận hành cần bối cảnh động.

Agentic AI đang nổi lên như một lớp điều phối mới phía trên các nền tảng này. Nó không thay thế ERP hay CRM của bạn. Nó trở thành một giao diện và người thực thi có thể hiểu mục tiêu, kéo bối cảnh từ nhiều nguồn, gọi công cụ hoặc API, thực thi các workflow đa bước, và dừng lại để xin phê duyệt của con người khi cần.

Đây là lý do tại sao agentic enterprise architecture không phải là chủ đề về tính năng AI. Nó là chủ đề về kiến trúc doanh nghiệp: AI sống ở đâu, nó kết nối với các nền tảng như thế nào, nó truy cập dữ liệu ra sao, và các hành động của nó được quản trị thế nào.

Ba lớp làm nên hệ thống

Cách hữu ích nhất để hiểu kiến trúc này là xem nó như ba lớp riêng biệt. Bên dưới chúng là lõi số của công ty bạn: ERP, CRM, HRIS, nền tảng dữ liệu và công cụ workflow.

Ba lớp của kiến trúc agentic enterprise: Agent, Context và Control, nằm trên lõi số của bạn.

Lớp Agent: Ai làm gì

Một trong những sai lầm thiết kế phổ biến nhất là xây dựng một tác tử chung duy nhất cho mọi thứ. Kết quả hầu như luôn giống nhau: khó kiểm soát, khó kiểm thử và khó để doanh nghiệp tin tưởng.

Một kiến trúc lành mạnh hơn phân biệt một số loại tác tử:

• Orchestrator agents quản lý workflow qua các bước hoặc qua các tác tử khác. Chúng không cần là chuyên gia trong mọi lĩnh vực, nhưng cần biết trình tự công việc, khi nào gọi chuyên gia, khi nào gọi công cụ và khi nào chuyển lên con người.
• Specialist agents tập trung vào một lĩnh vực cụ thể — chính sách mua sắm, phân tích hợp đồng, phân loại khiếu nại khách hàng, nguyên nhân gốc rễ sự cố IT. Phạm vi hẹp hơn giúp chúng dễ đánh giá và quản trị hơn.
• Task agents xử lý công việc nguyên tử, lặp đi lặp lại: trích xuất dữ liệu từ hóa đơn, xác thực tính đầy đủ của biểu mẫu, so sánh tài liệu với tiêu chuẩn. Chúng lý tưởng cho các tác vụ khối lượng lớn với quy tắc tương đối rõ ràng.
• Human interface agents tương tác trực tiếp với con người — trong chat, cổng thông tin, email hoặc không gian làm việc nội bộ. Chúng là điểm vào của hệ thống tác tử rộng lớn hơn, không chỉ là bot trò chuyện.

Sự phân tách vai trò này làm cho thiết kế, kiểm thử và sở hữu trở nên đơn giản hơn đáng kể.

Lớp Context: Cách tác tử hiểu công ty của bạn

Một tác tử không thể hoạt động tốt với bối cảnh nông cạn. Nhiều tổ chức bắt đầu với retrieval-augmented generation (RAG) để cung cấp cho tác tử quyền truy cập vào tài liệu, SOP và cơ sở kiến thức. Đó là bước đầu tiên hợp lý, đặc biệt cho các trường hợp sử dụng nhiều kiến thức như service desk.

Nhưng đối với các quy trình doanh nghiệp phức tạp, chỉ RAG thôi là chưa đủ. Tác tử cần hiểu mối quan hệ giữa các thực thể: khách hàng nào liên kết với hợp đồng nào, hóa đơn nào thuộc về đơn đặt hàng nào, người dùng nào có vai trò và quyền truy cập nào. Đây là nơi knowledge graph hoặc mô hình quan hệ doanh nghiệp trở nên vô giá.

Quan trọng không kém là truy xuất nhận biết quyền hạn. Trong một công ty, không phải tất cả bối cảnh đều có thể truy cập được bởi tất cả tác tử cho tất cả người dùng. Một tác tử HR không nên hiển thị dữ liệu lương thưởng xuyên các nhân viên nếu không được ủy quyền. Một tác tử mua sắm không nên phơi bày các hợp đồng chiến lược cho mọi người yêu cầu. Nếu lớp truy xuất của bạn không nhận biết quyền hạn, các tác tử của bạn sẽ trở thành một đường rò rỉ dữ liệu nguy hiểm.

Lớp Control: Cách công ty giữ quyền kiểm soát

Càng nhiều tác tử chuyển từ trả lời sang hành động, lớp này càng trở nên quan trọng. Đây không phải là phụ kiện tuân thủ — nó là cốt lõi của kiến trúc.

Mọi tác tử cần một danh tính rõ ràng. Công ty phải biết tác tử nào đã hành động, thay mặt cho ai, với quyền truy cập nào, trong hệ thống nào và trong bối cảnh quy trình nào. Nguyên tắc rất đơn giản: không bao giờ cấp cho tác tử quyền truy cập rộng hơn phạm vi nhiệm vụ của nó.

Không phải mọi hành động đều nên thực thi tự động. Một số phải tuân theo chính sách: ngưỡng giá trị giao dịch, loại dữ liệu nhạy cảm, mức độ tin cậy của model, danh mục rủi ro hoặc tác động vận hành. Kiến trúc cần có workflow phê duyệt rõ ràng. Một tác tử có thể chuẩn bị đề xuất và thu thập bằng chứng, nhưng đối với một số trường hợp, quyết định cuối cùng vẫn thuộc về con người.

Mọi hành động phải có thể truy vết. Tối thiểu, công ty phải có thể trả lời: tác tử nào đã thực hiện hành động, dữ liệu nào được sử dụng, công cụ hoặc API nào được gọi, chính sách nào được áp dụng, đầu ra nào được tạo ra và ai đã phê duyệt nếu cần phê duyệt của con người. Nếu không có audit trail, bạn không thể giải thích sự cố, sửa lỗi hoặc xây dựng niềm tin với cơ quan quản lý và kiểm toán.

Áp dụng vào hệ thống thật

Nếu bạn đang xây dựng hệ thống agentic ngay hôm nay, đây là cách ba lớp này chuyển thành các quyết định kỹ thuật cụ thể:

Lớp Agent

• Xác định vai trò tác tử trước khi viết một dòng prompt nào. Dùng registry hoặc service mesh để quản lý danh tính và định tuyến tác tử.
• Mỗi tác tử nên có một bounded context và một chủ sở hữu rõ ràng. Ví dụ: một ProcurementPolicyAgent chỉ xử lý chính sách mua sắm, không chạm vào dữ liệu nhân sự.
• Thiết lập cơ chế timeout và retry cho mỗi tác tử. Một tác tử không phản hồi sau 30 giây nên được coi là lỗi và chuyển sang human-in-the-loop.

Lớp Context

• Bắt đầu với RAG cho kiến thức tài liệu, nhưng lên kế hoạch cho graph hoặc vector-store hybrid ngay khi tác tử của bạn cần suy luận về mối quan hệ thực thể.
• Triển khai row-level security trên lớp truy xuất ngay từ ngày đầu. Một tác tử HR chỉ nên thấy dữ liệu của nhân viên trong phạm vi quyền hạn của người dùng đã ủy quyền cho nó.
• Cache context thường dùng (ví dụ: cấu trúc tổ chức, danh sách khách hàng) để giảm độ trễ và chi phí API.

Lớp Control

• Gắn correlation ID cho mọi lời gọi tác tử. Log mọi tool invocation, mọi lần đọc dữ liệu, mọi điểm quyết định.
• Xây dựng một human-in-the-loop API có thể tạm dừng, phê duyệt hoặc từ chối hành động trước khi chúng thực thi. API này nên trả về trạng thái "pending_approval" và cho phép người dùng xem toàn bộ ngữ cảnh trước khi quyết định.
• Thiết lập ngưỡng tự động hóa: ví dụ, hóa đơn dưới 10 triệu VND có thể tự động phê duyệt, nhưng trên ngưỡng đó phải có người xác nhận.

Cách dễ nhất để bắt đầu là chọn một quy trình vận hành — ví dụ, xử lý ngoại lệ hóa đơn — và xây dựng một stack ba lớp tối thiểu xung quanh nó. Điều đó cho bạn một mẫu có thể nhân rộng sang các lĩnh vực khác.

Những câu hỏi bạn nên mang về cho đội của mình

• Nếu bạn là CIO: kiến trúc doanh nghiệp của bạn đã coi tác tử như các danh tính vận hành thực sự chưa, hay chúng vẫn chỉ là các tính năng ứng dụng?
• Nếu bạn là COO: quy trình nào thực sự sẵn sàng cho sự phối hợp giữa người và tác tử, và quy trình nào vẫn còn quá mong manh cho bất kỳ mức độ tự chủ nào?
• Nếu bạn là CHRO: nếu việc thực thi chuyển sang lao động số, những vai trò con người nào cần được củng cố ngay bây giờ?
• Nếu bạn là lãnh đạo chuyển đổi: bạn đang xây dựng một nền tảng có thể mở rộng, hay chỉ đang thu thập những bản demo ấn tượng không bao giờ trở thành mô hình vận hành?

Sự khác biệt giữa một bản demo thông minh và một hệ thống doanh nghiệp đáng tin cậy không phải là model. Đó là kiến trúc.

Bài viết này được tham khảo từ Arief Wara's blog.