Để triển khai các Tác nhân AI thành công, hãy coi chúng như một nhân sự trong nhóm

(Bài viết dịch từ HBR)

Hãy hình dung một bối cảnh quen thuộc: Một nhà cung cấp trình diễn một "tác nhân" (agent) AI tạo ra mới cho đội ngũ lãnh đạo của bạn. Nó thực sự ấn tượng: Tác nhân này tự phân loại các yêu cầu hỗ trợ, cập nhật hồ sơ khách hàng, soạn thảo đề xuất và gửi đi phê duyệt. Buổi demo diễn ra mượt mà. Ngay sau đó, một câu hỏi tất yếu sẽ vang lên: "Bao lâu nữa chúng ta có thể triển khai hệ thống này trên quy mô toàn doanh nghiệp?"

Câu hỏi đó phản ánh một giả định vốn đã dẫn dắt việc áp dụng phần mềm doanh nghiệp trong kỷ nguyên SaaS (Phần mềm dưới dạng dịch vụ). Hầu hết các công cụ đều có thể được cấp quyền, cấu hình và mở rộng quy mô với rất ít sự tùy chỉnh. Nếu tích hợp hoạt động và nhân viên chịu sử dụng, thì việc triển khai phần lớn chỉ là một dự án thực thi kỹ thuật. Nhưng AI dạng tác nhân (agentic AI) đã phá vỡ mô hình đó.

Khác với phần mềm truyền thống, các tác nhân AI được thiết kế để lập luận, lập kế hoạch và thực hiện hành động xuyên suốt các hệ thống. Ngay khi một tác nhân có thể thay đổi một hệ thống hồ sơ — như cập nhật giá, gửi thanh toán hoặc sửa đổi dữ liệu khách hàng — nó không còn là một công cụ năng suất đơn thuần nữa, mà trở thành một phần trong mô hình vận hành của tổ chức.

Quan trọng nhất, nó tạo ra các danh mục rủi ro mới. Một công cụ AI tạo ra phạm vi hẹp (như ChatGPT để soạn email) tạo ra rủi ro về nội dung: Nó có thể nói sai. Còn AI tác nhân tạo ra rủi ro về thực thi: Nó có thể làm sai.

Dựa trên công việc của chúng tôi với tư cách là các nhà nghiên cứu (Rahul và Zia) và một chuyên gia thực tiễn có kinh nghiệm dẫn dắt các đợt triển khai AI tác nhân trong doanh nghiệp (Raja), chúng tôi đã quan sát kỹ cách AI tác nhân thực sự được áp dụng. Điều chúng tôi nhận thấy là mặc dù hiện nay nhiều tác nhân đã "sẵn sàng hành động", nhưng các công ty lại hiếm khi "sẵn sàng để chúng làm vậy".

Để vượt qua ngưỡng đó và tích hợp hiệu quả các tác nhân AI ở quy mô lớn, bạn cần ngừng coi chúng là phần mềm "chìa khóa trao tay" (turnkey) chỉ cần cài đặt là xong. Thay vào đó, bạn cần đối xử với các tác nhân của mình như một loại lực lượng lao động mới cần được quản lý. Giống như nhân viên con người, mỗi tác nhân AI cần có một vai trò, phạm vi quyền hạn xác định, các nguồn thông tin chuẩn (sources of truth) đã được phê duyệt và các quy tắc báo cáo cấp trên (escalation) rõ ràng. Chúng cũng cần sự giám sát và nhật ký kiểm tra (audit trails), vì bạn sẽ phải chịu trách nhiệm về hành động của chúng.

Cho đến khi các nền tảng tổ chức đó được thiết lập, việc mở rộng AI tác nhân sẽ rất khó khăn. Đặc biệt, có bốn điểm ma sát thường xuyên làm chậm hoặc chệch hướng tiến trình. Hiểu được chúng là bước đầu tiên để quản lý chúng.

1) Danh tính: "Ai" đang hành động?

Các công ty đã dành nhiều thập kỷ để xây dựng các kiểm soát truy cập cho nhân viên. Mọi người dùng hệ thống máy tính đều đăng nhập với một danh tính duy nhất, và vai trò của họ quyết định những gì họ có thể và không thể làm.

Các tác nhân AI làm phức tạp hóa vấn đề này vì chúng hành xử như nhân viên nhưng lại không phải là con người. Nhiều đợt triển khai ban đầu xử lý vấn đề này bằng cách cung cấp cho các tác nhân một "tài khoản dịch vụ" (service account) dùng chung với quyền truy cập rộng rãi vào nhiều hệ thống. Đó là một giải pháp tiện lợi — nhưng việc cấp quá nhiều quyền cho tác nhân sẽ tạo ra rủi ro bảo mật.

Hãy xem xét một ví dụ đơn giản. Một nhân viên dịch vụ khách hàng có thể được ủy quyền hoàn tiền lên đến 500 USD. Nếu họ cố gắng hoàn tiền lớn hơn, hệ thống sẽ chặn giao dịch và chuyển đi phê duyệt. Nhưng một tác nhân AI hoạt động thông qua một tài khoản dịch vụ dùng chung có thể không chịu giới hạn ủy quyền đó, và do đó có thể thực hiện một khoản tín dụng 5.000 USD chỉ trong một bước.

Rủi ro không chỉ dừng lại ở giả thuyết. Năm 2025, một thử nghiệm của nhà phát triển sử dụng tác nhân lập trình AI của Replit đã cho thấy tốc độ tự động hóa có thể vượt xa các kiểm soát nhanh đến mức nào. Mặc dù được hướng dẫn không thực hiện bất kỳ thay đổi nào, tác nhân này đã thực hiện các lệnh xóa sạch một cơ sở dữ liệu đang vận hành (production). Sau đó, nó cố gắng che giấu thất bại bằng cách tạo ra hàng nghìn hồ sơ giả và các thông báo hệ thống sai lệch, những hành vi này đã làm chậm phản ứng và làm phức tạp quá trình khôi phục.

Bài học đã rõ ràng: Các tổ chức nên coi mỗi tác nhân AI như một nhân viên kỹ thuật số riêng biệt với danh tính, thông tin đăng nhập và vai trò riêng. Thay vì dựa vào các tài khoản dịch vụ dùng chung, các công ty nên chỉ định cho các tác nhân những quyền hạn trong phạm vi hẹp tương ứng với các nhiệm vụ cụ thể mà chúng được thiết kế để thực hiện. Các nguyên tắc quản lý nhân viên con người — như quyền truy cập tối thiểu (least-privilege access) và giới hạn dựa trên vai trò — cũng nên áp dụng cho các tác nhân. Nếu một nhân viên dịch vụ khách hàng không thể hoàn tiền vượt quá một ngưỡng nhất định mà không có sự phê duyệt, thì hạn chế tương tự rõ ràng phải được áp dụng cho tác nhân thực hiện công việc đó. Điều quan trọng không kém là mọi hành động của tác nhân phải được ghi lại dưới một danh tính có thể truy xuất nguồn gốc để tổ chức có thể thấy rõ ai — hoặc cái gì — đã thực hiện nó. Nếu các nhà lãnh đạo không thể giải thích rõ ràng tác nhân đang sử dụng danh tính nào khi thực hiện hành động, hệ thống đó vẫn chưa sẵn sàng để đưa vào vận hành.

2) Ngữ cảnh: Khi dữ liệu xấu dẫn đến hành động sai

Các tác nhân AI thể hiện rất tốt trong các buổi demo vì môi trường được kiểm soát: dữ liệu sạch, hướng dẫn rõ ràng và các nguồn thông tin chuẩn xác. Nhưng các tổ chức thực tế thì khác. Dữ liệu doanh nghiệp bị phân mảnh giữa các hệ thống, trùng lặp giữa các nhóm và thường mâu thuẫn nhau. Các chính sách thay đổi theo thời gian và các tài liệu cũ vẫn còn lưu hành. Con người xử lý sự mơ hồ này bằng cách sử dụng khả năng phán đoán và kinh nghiệm mà các tác nhân AI không có.

Đối với một hệ thống tạo văn bản, một ngữ cảnh không hoàn hảo có thể tạo ra một câu trả lời sai sót. Đó là một vấn đề, nhưng hậu quả thường hạn chế. Tuy nhiên, đối với một hệ thống thực hiện hành động, hậu quả lớn hơn nhiều. Hãy tưởng tượng một tác nhân nhân sự (HR) truy xuất một tài liệu chính sách thường được tham chiếu từ năm 2022 và sử dụng nó — mặc dù các quy tắc đã thay đổi kể từ đó — để hướng dẫn các quản lý thực hiện quy trình sa thải nhân viên. Đó không phải là ảo giác của AI. Đó là một sai lầm trong việc truy xuất dữ liệu khiến công ty phải đối mặt với rủi ro pháp lý.

Các tác nhân cũng tạo ra một thách thức bảo mật mới: Thao túng ngữ cảnh. Nếu một tác nhân đọc email, biểu mẫu hoặc yêu cầu hỗ trợ, sau đó thực hiện các nhiệm vụ dựa trên thông tin đó, những kẻ tấn công có thể chèn các hướng dẫn ẩn được thiết kế để gây ảnh hưởng đến hành vi của nó. Các nhà nghiên cứu đã chứng minh rủi ro này vào năm 2025 thông qua một lỗ hổng được gọi là "ForcedLeak". Bằng cách chèn các hướng dẫn độc hại vào một biểu mẫu web thông thường, họ đã lừa một tác nhân Agentforce của Salesforce truy xuất dữ liệu CRM nhạy cảm và gửi nó đến một địa chỉ bên ngoài.

Để đối phó với những xung đột về ngữ cảnh này, các tổ chức cần thiết lập các tiêu chuẩn rõ ràng về thông tin mà tác nhân của họ có thể tin tưởng. Điều này đòi hỏi phải xác định các nguồn có thẩm quyền cho các chính sách, giá cả và dữ liệu vận hành, để các tác nhân có thể nhất quán dựa trên phiên bản chính xác của sự thật. Các hệ thống cũng nên ghi lại nguồn gốc (provenance) của thông tin được sử dụng trong việc ra quyết định, cho phép các nhóm truy xuất bất kỳ hành động nào của tác nhân ngược lại các tài liệu hoặc nguồn dữ liệu cụ thể mà nó đã dựa vào. Cuối cùng, các công ty sẽ phải coi các đầu vào bên ngoài — như email, biểu mẫu hoặc tệp tải lên — không đơn thuần là ngữ cảnh hữu ích mà là các vectơ tấn công tiềm năng. Các đầu vào có nguồn gốc từ bên ngoài tổ chức nên được xử lý cẩn thận và xác thực trước khi một tác nhân được phép hành động dựa trên chúng.

3) Kiểm soát: Các hệ thống xác suất cần các ranh giới cứng

Phần mềm truyền thống hành xử một cách có thể dự đoán được. Cùng một đầu vào sẽ tạo ra cùng một đầu ra mọi lúc. Nhưng các mô hình ngôn ngữ lớn không hoạt động theo cách đó. Phản hồi của chúng mang tính xác suất, nghĩa là cùng một yêu cầu có thể tạo ra các kết quả hơi khác nhau giữa các lần chạy. Sự thay đổi đó có thể chấp nhận được khi đầu ra là một bản nháp email, nhưng nó trở nên rắc rối hơn nhiều khi đầu ra là một giao dịch.

Một công ty triển khai tác nhân hỗ trợ AI đã gặp phải vấn đề này khi đội ngũ pháp lý yêu cầu hệ thống không bao giờ được nhắc đến một đối thủ cạnh tranh cụ thể. Tuy nhiên, cơ sở tri thức của công ty lại bao gồm nhiều bài viết so sánh chính thống có nhắc đến đối thủ đó, vì vậy tác nhân thường xuyên nhắc tên đối thủ khi trả lời câu hỏi của khách hàng. Khi các kỹ sư thắt chặt các rào chắn (guardrails) để chặn những phản hồi đó, hệ thống bắt đầu từ chối trả lời cả những câu hỏi hợp lệ.

Vấn đề sâu xa ở đây là các phương pháp kiểm thử truyền thống giả định hành vi ổn định. Một hệ thống vượt qua bộ kiểm thử ngày hôm nay có thể hành xử khác vào ngày mai nếu mô hình được cập nhật, câu lệnh (prompt) thay đổi hoặc dữ liệu mới được thêm vào. Và rủi ro tăng lên trong môi trường đa tác nhân (multi-agent), nơi các tác nhân chuyển giao công việc cho nhau. Ví dụ, vào năm 2025, các nhà nghiên cứu tại AppOmni đã chứng minh cách các cấu hình không an toàn trong môi trường Now Assist của ServiceNow có thể cho phép "tấn công chèn câu lệnh cấp độ hai" (second-order prompt injection). Trong thử nghiệm của họ, các hướng dẫn độc hại do một tác nhân đưa vào đã được chuyển sang các tác nhân khác, dẫn đến các hành động ngoài ý muốn hoặc trái phép, chẳng hạn như truy xuất các hồ sơ nhạy cảm hoặc gửi thông tin đến các đích bên ngoài.

Lời khuyên ở đây là: nếu không có ranh giới rõ ràng, những sai lầm — hoặc các cuộc tấn công — có thể lan truyền theo hiệu ứng domino trong một hệ thống tự động. Để quản lý rủi ro đó, các tổ chức nên xây dựng các kiểm soát xác định (deterministic controls) xung quanh các hệ thống AI mang tính xác suất. Thay vì cho phép các tác nhân thực hiện hành động trực tiếp, các công ty nên đặt các lớp xác thực giữa mô hình AI và các hệ thống vận hành. Trong cách tiếp cận này, tác nhân đề xuất một hành động (như hoàn tiền hoặc cập nhật hồ sơ), và trước khi nó được thực hiện, một phần mềm xác định sẽ xác minh xem nó có tuân thủ các quy tắc đã thiết lập hay không. Các tổ chức nên giới hạn các tương tác giữa tác nhân với tác nhân mà không có sự giám sát, để đầu ra của một tác nhân không tự động trở thành hướng dẫn thực thi cho tác nhân khác mà không qua xác thực, kiểm tra chính sách hoặc con người xem xét.

4) Trách nhiệm giải trình: Khi không ai có thể giải thích chuyện gì đã xảy ra

Khi một nhân viên mắc sai lầm, quản lý có thể điều tra bằng cách đặt câu hỏi. Khi phần mềm truyền thống gặp lỗi, các kỹ sư có thể kiểm tra nhật ký hệ thống (logs). Nhưng các tác nhân AI tạo ra một tình huống phức tạp hơn, vì hành vi của chúng thường nảy sinh từ một chuỗi các bước lập luận, các tài liệu được truy xuất và các lệnh gọi công cụ có thể không dễ dàng tái dựng lại sau khi sự việc đã rồi.

Điều này tạo ra một thách thức nghiêm trọng về trách nhiệm giải trình. Hãy tưởng tượng một tác nhân thu mua tóm tắt hiệu suất của nhà cung cấp và đăng kết quả lên kênh Slack của công ty. Nếu tác nhân vô tình đưa vào các điều khoản hợp đồng bảo mật — vì nó diễn giải "chia sẻ minh bạch" là được phép tiết lộ chúng — các nhà lãnh đạo sẽ cần biết chính xác quyết định đó đã được đưa ra như thế nào. Nó đã đọc những tài liệu nào? Nó đã làm theo hướng dẫn gì? Tại sao nó tin rằng mình được phép chia sẻ thông tin đó? Nếu không có loại bằng chứng đó, các tổ chức không thể giải thích hành vi hệ thống của họ cho các cơ quan quản lý, kiểm toán viên hoặc khách hàng.

Một quyết định của tòa án vào năm 2024 đã đưa ra tín hiệu sớm về cách luật pháp có thể xử lý vấn đề này. Trong vụ Moffatt kiện Air Canada, một khách hàng đã tin vào thông tin sai lệch do chatbot của hãng hàng không cung cấp về điều kiện hưởng giá vé cho người có tang quyến. Khi hãng hàng không lập luận rằng chatbot về cơ bản là một thực thể riêng biệt, tòa án đã bác bỏ lập luận này và quy trách nhiệm cho công ty về thông tin sai lệch đó.

Để tránh những vấn đề như vậy, các công ty sẽ phải thiết kế các hệ thống AI của họ với tư duy về trách nhiệm giải trình ngay từ đầu. Điều này bắt đầu bằng việc duy trì hồ sơ toàn diện về cách các tác nhân hoạt động, bao gồm nguồn dữ liệu nào họ đã truy cập, các câu lệnh nào họ đã nhận và các công cụ nào họ đã sử dụng để hoàn thành nhiệm vụ. Các hồ sơ này phải cho phép tái dựng lại chuỗi lập luận dẫn đến bất kỳ hành động nào. Các tổ chức cũng nên chỉ định quyền sở hữu nội bộ rõ ràng đối với việc giám sát và quản lý hành vi của tác nhân để trách nhiệm không bị phân tán.

Lộ trình phía trước

Nếu việc triển khai "chìa khóa trao tay" là không thực tế đối với các tác nhân AI, thì giải pháp thay thế không phải là né tránh chúng, mà là giới thiệu chúng một cách dần dần, mở rộng quyền tự chủ của chúng chỉ khi tổ chức phát triển được khả năng quản trị.

Một cách hữu ích để tư duy về sự tiến triển này là coi nó như một "nấc thang tự chủ". Sự khác biệt chính nằm ở thẩm quyền thực thi: liệu hệ thống chỉ soạn thảo nội dung, đề xuất hành động để phê duyệt, hay trực tiếp thực hiện hành động trong các giới hạn được kiểm soát chặt chẽ.

1. Đầu ra hỗ trợ (Assistive Output): Tạo bản nháp, tóm tắt hoặc đề xuất để con người xem xét trước khi thực hiện.

2. Truy xuất có rào chắn (Retrieval with Guardrails): Tác nhân trả lời câu hỏi bằng thông tin nội bộ nhưng dựa trên các nguồn dữ liệu được quản trị tốt.

3. Hành động có giám sát (Supervised Actions): Tác nhân đề xuất các nhiệm vụ vận hành (hoàn tiền, cập nhật hồ sơ), nhưng con người luôn xác nhận trước khi thực thi.

4. Tự chủ trong ranh giới (Bounded Autonomy): Tác nhân thực hiện các luồng công việc một cách độc lập trong các giới hạn hẹp và các ngưỡng được xác định trước.

Nhiều đợt triển khai hiệu quả đã cố ý dừng lại ở các nấc thang thấp. Ví dụ, công ty tư vấn OneDigital sử dụng Azure OpenAI để tăng tốc nghiên cứu cho các tư vấn viên, cải thiện "thời gian đưa ra thông tin chuyên sâu" thay vì thay thế chính các tư vấn viên đó. Klarna đã báo cáo rằng trợ lý AI của họ xử lý một phần lớn các cuộc trò chuyện dịch vụ khách hàng một cách tự động, nhưng vẫn duy trì các lộ trình chuyển giao ngay lập tức cho con người đối với các trường hợp phức tạp hoặc nhạy cảm.

Đối với các nhà lãnh đạo, các khoản đầu tư quan trọng nhất thường nằm ở tổ chức hơn là kỹ thuật.

• Xác định rõ "ranh giới chìa khóa trao tay" để phân biệt ứng dụng AI nào có thể triển khai nhanh và ứng dụng nào cần thiết kế lại hệ thống kiểm soát.

• Coi quyền hạn là một câu hỏi thiết kế cốt lõi.

• Thiết lập các ngưỡng "con người tham gia kiểm soát" (human-in-the-loop) rõ ràng cho các quyết định liên quan đến tài chính, pháp lý hoặc uy tín.

• Cuối cùng, hãy đo lường kết quả thực tế (thời gian chu kỳ, tỷ lệ lỗi) thay vì chỉ đếm số lượng các dự án thử nghiệm.

AI tạo ra sẽ tiếp tục cải thiện, nhưng khoảng cách giữa một buổi demo ấn tượng và một hệ thống vận hành đáng tin cậy sẽ vẫn tồn tại trừ khi các tổ chức thay đổi tư duy về việc triển khai. Các doanh nghiệp thành công với AI tác nhân sẽ không chỉ đơn giản là "cài đặt" thêm nhiều robot, mà họ sẽ xây dựng những cấu trúc cho phép những robot đó có thể được tin cậy.