Sự chuyển dịch quan trọng của AI tại nơi làm việc không nằm ở việc một mô hình có thể viết một đoạn văn hay hơn. Mà nằm ở chỗ một hệ thống ngày càng có thể theo đuổi một mục tiêu qua nhiều bước: kiểm tra tệp, tìm kiếm các dịch vụ được kết nối, tạo một sản phẩm đầu ra, cập nhật một bản ghi và gửi một tin nhắn.

Điều đó chuyển câu hỏi chuyên môn từ “Câu trả lời này có chính xác không?” thành “Hệ thống này được phép làm gì trước khi phải hỏi tôi?”

Zapier mô tả ChatGPT Work là một chế độ tác tử có thể làm việc trong thời gian dài với các tệp và ứng dụng được kết nối, trong khi chế độ Plan đề xuất một chiến lược để phê duyệt trước khi thực thi. Tương tự, Microsoft xem Copilot, tri thức tổ chức và quản trị là những phần bổ trợ cho nhau của một nền tảng AI vận hành. Những ví dụ này hướng đến một sự phân biệt thực tế: AI đang chuyển từ một đối tác trò chuyện thành một người thực hiện công việc được ủy quyền.

Ủy quyền có thể tiết kiệm thời gian, nhưng cũng làm thay đổi hình thái của trách nhiệm. Một chatbot thường tạo ra một đầu ra để con người kiểm tra. Một tác tử có thể tạo ra nhiều hành động trung gian, trong đó có những hành động khó nhận thấy sau khi sự việc đã xảy ra. Vì vậy, chiến lược áp dụng an toàn nhất không phải là quyền tự chủ tối đa. Mà là thẩm quyền rõ ràng, được phân cấp từng bước.

Hãy tư duy theo hành động, không phải câu lệnh

Một bước đầu hữu ích là liệt kê những hành động mà một hệ thống AI có thể thực hiện trong một quy trình. “Xử lý việc tiếp nhận khách hàng” là quá rộng để quản trị. Một danh mục hữu ích hơn có thể bao gồm:

  • đọc một chính sách nội bộ và trích xuất các yêu cầu;
  • tìm kiếm trong một cơ sở tri thức đã được phê duyệt;
  • soạn thảo email hoặc bản tóm tắt hợp đồng;
  • tạo một phiếu yêu cầu hoặc một dòng trong bảng tính;
  • thay đổi bản ghi khách hàng hoặc bản ghi tài chính;
  • mời một người dùng, công bố một tài liệu hoặc gửi một tin nhắn ra bên ngoài;
  • phê duyệt một khoản thanh toán, xóa dữ liệu hoặc đưa ra một cam kết thay mặt tổ chức.

Mỗi hành động có sự kết hợp khác nhau giữa khả năng đảo ngược, mức độ nhạy cảm, tác động bên ngoài và chi phí. Coi tất cả chúng chỉ là “sự hỗ trợ của AI” sẽ che giấu quyết định thực sự cần đưa ra.

Một cách phân loại đơn giản thực tế hơn lời hứa mơ hồ rằng con người sẽ giám sát mọi thứ:

  • Được phép thực hiện: các hành động ít rủi ro, có thể đảo ngược trong một không gian làm việc được giới hạn rõ ràng.
  • Phải đề xuất: các hành động làm thay đổi công việc chung, giao tiếp ra bên ngoài hoặc tạo ra một cam kết đáng kể.
  • Tuyệt đối không được tự mình thực hiện: các hành động liên quan đến quyết định chịu sự quản lý của pháp luật, việc xóa dữ liệu không thể đảo ngược, chuyển khoản giá trị lớn, thay đổi quyền kiểm soát truy cập hoặc các vấn đề nhân sự nhạy cảm.

Chương trình AI tác tử của chính phủ UAE đưa ra một ví dụ chính sách phù hợp: chương trình này bao gồm các quy tắc để quyết định những nhiệm vụ nào tác tử được phép hoàn thành và những nhiệm vụ nào chúng chỉ được phép đề xuất. Ý tưởng nền tảng này có thể áp dụng hiệu quả cho một nhóm riêng lẻ: quyền hạn phải gắn với nhiệm vụ, không được cấp chỉ vì hệ thống có vẻ có năng lực.

Sử dụng các điểm phê duyệt khi hậu quả thay đổi

Không phải mọi bước đều cần một hộp thoại xác nhận. Nếu hệ thống yêu cầu phê duyệt sau mỗi lần đọc tệp, mọi người sẽ phê duyệt một cách máy móc hoặc vô hiệu hóa biện pháp kiểm soát. Hãy đặt điểm kiểm soát ngay trước một chuyển tiếp có hệ quả.

Ví dụ, một tác tử có thể được phép thu thập thông tin, so sánh các lựa chọn và chuẩn bị bản nháp mà không bị gián đoạn. Nó nên tạm dừng trước khi:

  • gửi bất kỳ nội dung nào ra ngoài tổ chức;
  • công bố hoặc chia sẻ một tài liệu với một nhóm đối tượng mới;
  • thay đổi một bản ghi nguồn sự thật;
  • chi tiền hoặc áp dụng một khoản giảm giá;
  • thay đổi quyền hạn hoặc tạo thông tin xác thực;
  • xóa, ghi đè hoặc xuất dữ liệu;
  • đưa ra quyết định ảnh hưởng đến việc làm, điều kiện đủ, tín dụng, an toàn hoặc các quyền pháp lý.

Yêu cầu phê duyệt nên nêu rõ hành động được đề xuất, đối tượng chính xác, các đầu vào quan trọng và hệ quả có khả năng xảy ra. “Tiếp tục?” là một biện pháp kiểm soát yếu. “Gửi tin nhắn này đến 2.400 khách hàng, sử dụng danh sách đính kèm, với chi phí chiến dịch ước tính là $X” cung cấp cho một người nội dung có ý nghĩa để xem xét.

Đối với các hành động có tác động lớn, hãy yêu cầu một người phê duyệt được nêu tên thay vì bất kỳ ai tình cờ đang theo dõi màn hình. Khi rủi ro đòi hỏi, hãy tách biệt người thiết kế quy trình với người cho phép thực hiện kết quả có hệ quả lớn nhất của quy trình đó.

Xác định phạm vi vận hành của tác nhân

Các chuyên gia không cần hiểu mọi chi tiết của mô hình để thiết lập những ranh giới hữu ích. Nhưng họ cần xác định phạm vi vận hành của hệ thống:

  • Phạm vi: những dự án, thư mục, tài khoản và nguồn dữ liệu nào được phép truy cập?
  • Công cụ: hệ thống được phép đọc, ghi, gửi, mua, thực thi mã hay thay đổi quyền hạn không?
  • Giới hạn: áp dụng giới hạn nào về chi tiêu, khối lượng, tần suất hoặc thời gian?
  • Nguồn: những miền, kho lưu trữ hoặc cơ sở dữ liệu nào được xem là có thẩm quyền?
  • Chuyển cấp: dạng không chắc chắn, xung đột hoặc thiếu thông tin nào đòi hỏi sự can thiệp của con người?
  • Điều kiện dừng: khi nào hệ thống phải dừng lại thay vì tự ứng biến?

Bất cứ khi nào có thể, quyền truy cập công cụ nên hẹp hơn quyền truy cập chung vào tài khoản của người dùng. Một tác nhân có thể đọc ổ đĩa dùng chung không mặc nhiên cần quyền gửi email cho mọi liên hệ. Một tác nhân có thể soạn mã không mặc nhiên cần thông tin xác thực của môi trường sản xuất. Một tài khoản dịch vụ riêng, không gian làm việc bị giới hạn hoặc kết nối chỉ đọc có thể khiến sai sót ít gây thiệt hại hơn.

Hãy viết ranh giới bằng ngôn ngữ vận hành. “Sử dụng phán đoán” không phải là một biện pháp kiểm soát. “Không gửi email ra bên ngoài nếu chưa được phê duyệt; không sửa đổi cơ sở dữ liệu khách hàng; chỉ sử dụng bảng giá đã được phê duyệt, ghi ngày [date]; dừng lại nếu hai nguồn xung đột” là những yêu cầu có thể kiểm thử.

Đảm bảo kế hoạch có thể được kiểm tra trước khi thực thi

Lập kế hoạch là một trong những tính năng hữu ích của AI được ủy quyền, nhưng một kế hoạch không phải là bằng chứng cho thấy kế hoạch đó đúng đắn. Hãy xem xét nó như một chuỗi hành động được đề xuất.

Hãy đặt ra bốn câu hỏi:

  1. Hệ thống đang theo đuổi kết quả nào?
  2. Nó đang đưa ra những giả định nào?
  3. Nó sẽ gọi những công cụ nào và với những quyền hạn gì?
  4. Ở bước nào một sai sót có thể trở nên tốn kém hoặc khó đảo ngược?

Một màn hình phê duyệt tốt nên cho thấy các ranh giới của kế hoạch, chứ không chỉ phần diễn đạt cuối cùng. Nếu hệ thống nói rằng nó sẽ “dọn dẹp tài khoản”, người xem xét phải có thể biết điều đó có nghĩa là gắn thẻ bản ghi, hợp nhất các bản trùng lặp, lưu trữ tin nhắn hay xóa dữ liệu.

Đối với công việc lặp lại, chỉ nên phê duyệt một chính sách thay vì từng trường hợp khi chính sách đó đủ cụ thể để kiểm thử. “Tự động lưu hóa đơn từ những nhà cung cấp này có giá trị dưới mức này, mà không xóa bản gốc” là một ứng viên. “Quản lý hóa đơn” thì không.

Giả định rằng bối cảnh có thể bị mất

Các hệ thống nhiều bước có thể mất dấu những chỉ dẫn trước đó, hiểu sai thông tin được truy xuất hoặc tiếp tục duy trì một giả định sai lầm. Hướng dẫn nghiên cứu và kỹ thuật trong bản tổng hợp nêu bật các dạng lỗi, bao gồm mất bối cảnh, chèn prompt, không kết thúc, lỗi đầu ra có cấu trúc và vấn đề khôi phục trạng thái. Công trình ABBEL của Berkeley cũng cho rằng việc cô đọng lịch sử tương tác thành các trạng thái niềm tin có thể phù hợp hơn so với việc liên tục mang theo toàn bộ lịch sử, nhưng quản lý bối cảnh vẫn là một mối lo về hiệu năng và độ tin cậy.

Điều đó có một hệ quả trực tiếp tại nơi làm việc: đừng khiến một phê duyệt quan trọng phụ thuộc vào việc tác nhân nhớ một ràng buộc từ bước hai trong một quy trình dài. Đặt các ràng buộc quan trọng gần lệnh gọi công cụ hoặc cổng phê duyệt. Yêu cầu các trường có cấu trúc đối với những hành động nhạy cảm, chẳng hạn như người nhận, số tiền, nguồn, lý do và thời hạn. Nếu một tác vụ chạy trong thời gian dài, hãy yêu cầu một điểm kiểm tra nhắc lại mục tiêu hiện tại, các bước đã hoàn tất, hành động đang chờ xử lý và những điều chưa chắc chắn chưa được giải quyết.

Đặc biệt thận trọng khi tác nhân đọc tài liệu không đáng tin cậy. Một trang web, email, tài liệu hoặc chú thích mã có thể chứa các chỉ dẫn nhằm thao túng hệ thống thay vì giúp hoàn thành tác vụ. Văn bản được truy xuất nên được xem là dữ liệu, trừ khi quy trình xác định rõ đó là một chỉ dẫn được ủy quyền.

Thiết kế để dừng và khôi phục

Công việc được ủy thác cần có cơ chế dừng dễ thấy và kế hoạch khôi phục. Đặt số lần lặp, số lệnh gọi công cụ hoặc thời gian chạy tối đa cho những tác vụ có thể rơi vào vòng lặp. Hãy bảo đảm việc thử lại là an toàn: tạo cùng một phiếu hai lần hoặc gửi cùng một email hai lần không phải là một lỗi vô hại. Khi được hỗ trợ, hãy sử dụng các thao tác lũy đẳng hoặc yêu cầu hệ thống kiểm tra xem một hành động đã xảy ra hay chưa trước khi lặp lại.

Duy trì một bản ghi hoạt động mà con người có thể đọc được: yêu cầu, kế hoạch, các công cụ đã sử dụng, nguồn dữ liệu đã tham khảo, phê duyệt đã cấp, thay đổi đã thực hiện và kết quả cuối cùng. Điều này không chỉ phục vụ việc phân tích sau sự cố. Nó cho phép một đồng nghiệp tiếp quản khi người vận hành ban đầu không có mặt và giúp có thể chất vấn một kết quả mà không phải tái dựng toàn bộ một chuỗi vô hình.

Đối với các quy trình quan trọng, hãy chủ động kiểm thử những trường hợp xấu trước khi trao quyền tự chủ. Thử dữ liệu bị thiếu, các chính sách mâu thuẫn, một nguồn đã hết hạn, một chỉ dẫn độc hại trong tài liệu, một yêu cầu trùng lặp, một quyền đã bị thu hồi và một công cụ trả về lỗi. Mục tiêu không phải là chứng minh tác nhân sẽ không bao giờ thất bại. Mục tiêu là xác minh rằng thất bại sẽ khiến quy trình tạm dừng, kích hoạt việc chuyển cấp rõ ràng hoặc khôi phục an toàn.

Các cấp độ ủy thác thực tế

Bạn có thể triển khai một tác nhân theo từng giai đoạn:

  1. Quan sát: hệ thống đọc thông tin đã được phê duyệt và giải thích những gì nó sẽ làm.
  2. Soạn thảo: hệ thống chuẩn bị đầu ra, nhưng một người thực hiện mọi hành động bên ngoài.
  3. Hành động trong môi trường hộp cát: hệ thống tạo các bản ghi, nhánh hoặc tệp kiểm thử trong một không gian làm việc biệt lập.
  4. Hành động với quyền hạn hẹp: hệ thống thực hiện các hành động có thể hoàn tác, rủi ro thấp, trong giới hạn về khối lượng và thời gian.
  5. Hành động theo chính sách: hệ thống xử lý một nhóm tác vụ đã được kiểm thử kỹ và tạm dừng tại các cổng phê duyệt được xác định trước.

Chỉ nâng lên cấp tiếp theo khi giai đoạn thấp hơn đã cung cấp bằng chứng rằng quy trình vận hành ở mức chấp nhận được. Nếu tác vụ thay đổi, công cụ thay đổi hoặc dữ liệu trở nên nhạy cảm hơn, hãy quay xuống cấp thấp hơn trong các cấp độ.

Điều này có ý nghĩa gì đối với sự nghiệp của bạn

Kỹ năng có giá trị không chỉ đơn giản là biết cách yêu cầu AI tạo ra một kết quả. Đó là biết cách biến một sự ủy thác mơ hồ thành một quy trình vận hành có giới hạn rõ ràng. Điều đó bao gồm phân rã công việc thành các hành động, xác định những chuyển đổi không thể hoàn tác, viết các quy tắc chuyển cấp, thiết kế yêu cầu phê duyệt và nhận ra khi nào tác nhân nên dừng lại.

Trong các buổi phỏng vấn hoặc đánh giá hiệu suất, hãy mô tả ranh giới mà bạn đã thiết kế, không chỉ riêng việc tự động hóa mà bạn đã triển khai: “Hệ thống nghiên cứu và soạn thảo; một người đánh giá được chỉ định phê duyệt thông tin liên lạc bên ngoài; việc ghi dữ liệu vào cơ sở dữ liệu chỉ giới hạn ở những trường này; các hành động trùng lặp được kiểm tra; những xung đột chưa được giải quyết sẽ dừng quy trình.” Cách diễn đạt đó thể hiện năng lực phán đoán trong vận hành.

Công việc có tác nhân sẽ không loại bỏ nhu cầu về trách nhiệm nghề nghiệp. Nó khiến trách nhiệm trở nên cụ thể hơn. Trước khi bàn giao một tác vụ, hãy quyết định hệ thống được phép làm gì, việc gì trước tiên nó phải cho bạn thấy và việc gì nó tuyệt đối không được tự mình làm. Sau đó, hãy thể hiện rõ những quyết định đó ngay trong quy trình.

Maya Chen là biên tập viên chịu trách nhiệm của AI Career Brief, chuyên đưa tin về các kỹ năng, vai trò và những bước đi thông minh để làm việc trong thời đại AI.