Tác tử AI cần bản mô tả công việc, không phải prompt tốt hơn

Hãy hỏi một công ty xem một chuyên viên phân tích công nợ phải trả mới vào được phép làm những gì, bạn sẽ nhận được câu trả lời rõ ràng. Cô ấy làm việc trên những hệ thống này, với những nhà cung cấp này; mọi khoản vượt quá hạn mức phê duyệt, chẳng hạn 10.000 USD, đều phải chuyển cho quản lý ký duyệt. Trong vài tháng đầu, cô ấy đang trong thời gian thử việc. Tất cả những điều đó thường được ghi trong một bảng phân quyền mà bộ phận kiểm toán nội bộ rà soát hằng năm.

Hãy hỏi chính công ty đó xem tác tử xử lý hóa đơn mới của họ được phép làm những gì, và thường bạn sẽ nhận được ảnh chụp màn hình của một prompt.

Khoảng cách ấy khiến tôi bận tâm hơn bất kỳ kết quả đánh giá chuẩn nào về mô hình. Chúng ta đang tuyển dụng một lực lượng lao động số mà không có hệ thống quản lý như hệ thống đã mất cả thế kỷ để xây dựng cho con người: không ai ghi lại quyền hạn của họ, không ai kiểm tra khả năng phán đoán trước khi họ bắt đầu, và cũng chẳng ai thực hành cách tắt họ.

Vì sao prompt không thể thay thế bản mô tả công việc

Prompt mô tả ý định, cho biết tác tử được tạo ra để làm gì. Nhưng hiếm khi nó nói rõ tác tử tuyệt đối không được làm gì, giới hạn của nó nằm ở đâu, hoặc khi nào nó phải dừng lại và chuyển quyết định cho con người.

Ngay cả khi prompt có nêu những điều đó thì cũng chẳng có gì bảo đảm chúng được tuân thủ. Một dòng yêu cầu tác tử không hoàn tiền quá 500 USD chỉ là lời đề nghị dành cho một hệ thống xác suất. Không kiểm toán viên nào chấp thuận câu “chúng tôi đã nhẹ nhàng nhờ chuyên viên phân tích” làm biện pháp kiểm soát đối với con người, vậy tôi không hiểu vì sao chúng ta lại chấp nhận cách đó với phần mềm.

Giới an ninh mạng đã có tên gọi cho hệ quả này. OWASP Top 10 for LLM Applications liệt kê Quyền tự chủ quá mức là một rủi ro cốt lõi, bắt nguồn từ chức năng quá rộng, quyền hạn quá lớn hoặc mức độ tự chủ quá cao. Nói đơn giản, đó là một nhân viên được trao chìa khóa mở mọi thứ ngay từ ngày đầu tiên. Hướng dẫn của OWASP giống như danh sách kiểm tra của một người quản lý giỏi: chỉ cấp cho tác tử những công cụ cần thiết, giới hạn quyền của nó, yêu cầu con người phê duyệt các hành động có tác động lớn, và thực thi việc phân quyền trong các hệ thống phía sau thay vì tin rằng mô hình sẽ tự kiểm soát mình.

Tôi muốn gạch chân ý cuối cùng đó. Quyền được cấp phải được thực thi ngay tại nơi hành động diễn ra: trong danh tính dịch vụ riêng của tác tử, quyền sử dụng công cụ của nó và hạn mức chi tiêu ở cổng API. Cho các tác tử chạy bằng chung một tài khoản dịch vụ cũng giống như để năm người dùng chung một thẻ ra vào. Khi có sự cố, nhật ký kiểm toán chỉ ghi tài khoản dịch vụ đã thực hiện hành động, khiến bạn phải đoán xem tác tử nào đã làm việc đó.

Các trường hợp hủy dự án cho thấy đây là vấn đề quản lý

Gartner dự đoán hơn 40% dự án AI tác tử sẽ bị hủy trước cuối năm 2027, với các nguyên nhân được nêu là chi phí leo thang, giá trị kinh doanh không rõ ràng và các biện pháp kiểm soát rủi ro không đầy đủ.

Sự thổi phồng kỳ vọng và các sản phẩm chưa hoàn thiện cũng góp phần tạo nên tình trạng này. Tuy vậy, hãy thử đọc ba nguyên nhân ấy theo góc nhìn của một giám đốc vận hành. Chi phí leo thang khi không ai đặt ngân sách. Giá trị vẫn mơ hồ khi không ai ghi lại công việc dự kiến sẽ tạo ra kết quả gì. Kiểm soát rủi ro không đạt yêu cầu khi không có giới hạn, không có khâu rà soát và không ai chịu trách nhiệm rõ ràng. Gartner không diễn giải theo cách này; đó là cách tôi nhìn nhận. Đây cũng là điều xảy ra khi con người được thả sức làm việc mà không có hệ thống quản lý, và vấn đề ấy đã tồn tại từ lâu trước khi có AI.

Các khuôn khổ cũng nhận thấy cùng một lỗ hổng. Khung Quản lý Rủi ro AI của NIST xem Quản trị là chức năng xuyên suốt Lập bản đồ, Đo lường và Quản lý; Hồ sơ AI tạo sinh mở rộng cách tiếp cận đó sang các hệ thống AI tạo sinh. Điều mà các khuôn khổ không thể cung cấp là bộ máy vận hành thực tế: các quyền được cấp, các bài kiểm tra và các đợt rà soát mà một nhóm thực sự tiến hành vào ngày thứ Ba. Nếu thiếu những thứ đó, quản trị vẫn chỉ là một tệp PDF nằm trên ổ đĩa dùng chung.

Áp dụng các công cụ quản lý truyền thống cho tác tử

Hãy bắt đầu từ bản mô tả công việc; với một tác tử, đó sẽ là văn bản cấp quyền. Trước khi tác tử tiếp xúc với một hệ thống đang hoạt động, cần có người viết được một trang nêu rõ những việc nó được phép làm, những việc tuyệt đối không được làm, các ngưỡng cần phê duyệt, người chịu trách nhiệm về nó và người có thể nới rộng giới hạn của nó. Trong ma trận RACI, người chịu trách nhiệm cuối cùng phải là một người. Nếu không thể viết được trang đó thì vai trò ấy chưa sẵn sàng để tuyển người đảm nhiệm; bạn cũng sẽ nói như vậy về một nhân viên mới.

Hai nguyên tắc lâu đời về phân quyền vẫn áp dụng nguyên vẹn. Bạn không thể ủy quyền một quyền hạn mà chính mình không có, vì vậy tác tử phụ không bao giờ được nhận phạm vi quyền hạn rộng hơn tác tử tạo ra nó. Nguyên tắc phân tách nhiệm vụ cũng vẫn được áp dụng. Một tác tử có thể vừa tạo nhà cung cấp vừa thanh toán cho nhà cung cấp đó sẽ dẫn đến cùng một phát hiện kiểm toán như trường hợp một người làm cả hai việc.

Tiếp theo là bài kiểm tra tuyển dụng. Phần lớn chúng ta kiểm tra tác tử như kiểm tra máy tính: xem câu trả lời có đúng hay không. Nhưng bài kiểm tra dành cho một nhân viên sẽ xem họ có làm đúng trong phạm vi quyền được cấp hay không, có xin phê duyệt khi cần hay không, có báo cáo cấp trên khi tình huống vượt quá nhiệm vụ được giao hay không, và có dừng lại khi cần hay không.

Trong nghiên cứu của mình, tôi đang xây dựng một bộ chuẩn gồm 50 tình huống xoay quanh chính những thất bại này: vượt ngưỡng phê duyệt, hành động dựa trên dữ liệu cũ, làm theo chỉ thị được chèn vào để mở rộng phạm vi, và tiếp tục giữ quyền truy cập sau khi thay đổi vai trò. Đến nay, tôi mới chỉ chạy bộ chuẩn này với các tác tử được viết kịch bản để kiểm tra xem các tình huống có hoạt động như thiết kế hay không, nên chưa có kết quả mô hình nào để báo cáo. Điều khiến tôi ngạc nhiên khi viết chúng là chúng bình thường đến mức nào. Đó là những cách nhân viên thường làm sai lệch nhiệm vụ được giao, chỉ được viết lại cho phần mềm. Phần lớn bảng xếp hạng công khai hiện vẫn chấm điểm khả năng hoàn thành nhiệm vụ, còn rất ít bảng đánh giá xem tác tử có tôn trọng quyền hạn của mình hay không.

Thử việc và thăng chức là những khái niệm khá dễ áp dụng. Với con người, ban đầu chúng ta giao cho họ phạm vi công việc hẹp rồi mở rộng khi họ chứng minh được khả năng phán đoán. Các tác nhân cũng có thể được nới giới hạn theo cách đó, dựa trên thành tích tuân thủ phạm vi được giao, biết chuyển cấp đúng lúc và dừng lại đúng cách; thành tích ấy cũng có thể là căn cứ để thu hẹp quyền đã cấp.

Các tác nhân có một điểm phức tạp mà con người không có. Khi nhà cung cấp nâng cấp mô hình nền tảng, về thực chất, bạn có một nhân viên mới mang thẻ nhân viên cũ. Tôi sẽ xem đó là một sự kiện thay đổi và kiểm tra lại trước khi tiếp tục duy trì quyền đã cấp.

Cần diễn tập việc chấm dứt hoạt động trước khi phải thực hiện. Nếu cần dừng tác nhân này và thu hồi quyền truy cập của nó trong vòng một giờ tới, bạn có làm được không? Ai có thẩm quyền đưa ra quyết định đó lúc 2 giờ sáng? Những khâu nào ở phía sau sẽ bị gián đoạn, và ai phải tự tay xử lý những cam kết đang dang dở? Nếu chưa ai diễn tập tình huống đó, bạn chỉ đang hy vọng công tắc ngắt khẩn cấp sẽ hoạt động.

Bạn có thể buộc một nhân viên chịu trách nhiệm. Bạn không thể buộc một tác nhân chịu trách nhiệm về bất cứ điều gì, và đó là điểm mà phép so sánh không còn phù hợp. Đó cũng là lý do quyền được cấp phải được thực thi bằng các hệ thống, và mỗi tác nhân cần có một người được chỉ định chịu trách nhiệm. Dù thế nào, cuối cùng vẫn sẽ có người phải chịu trách nhiệm. Thường thì đó là người đã phê duyệt, dù họ có biết mình đang ký duyệt hay không.

Cuộc rà soát sự cố sẽ đặt ra những câu hỏi gì

Rốt cuộc, một số tác nhân này sẽ làm điều chúng không nên làm. Khi chuyện đó xảy ra, cuộc rà soát sau sự cố sẽ đặt ra những câu hỏi vốn đã được đặt ra với con người. Tác nhân được phép làm gì, và điều đó được ghi ở đâu? Ai đã phê duyệt việc mở rộng quyền truy cập của nó? Mất bao lâu để dừng nó lại? Ai chịu trách nhiệm về nó?

Nếu câu trả lời thành thật là “một câu lệnh”, “không ai nhớ”, “hàng giờ” và “không rõ”, thì một mô hình tốt hơn cũng không cứu được bạn.

Lợi thế rốt cuộc nằm ở đâu

Các mô hình ngày càng trở thành những đầu vào được thuê, thay thế và nâng cấp theo lịch trình của nhà cung cấp. Hai công ty có thể chạy cùng một mô hình nhưng đạt được những kết quả rất khác nhau. Một bên có các tác nhân với ngân sách, giới hạn, người chịu trách nhiệm và nhật ký kiểm tra cho mọi hành động có hệ quả đáng kể; bên kia thì có một dự án thí điểm tốn kém đang trên đường trở thành một con số trong thống kê hủy bỏ của ai đó.

Khác biệt nằm ở hệ thống quản lý được xây dựng xung quanh mô hình. Hệ thống đó được hình thành từ từ, phần lớn nhờ những người từng điều hành các tổ chức.

Nếu tác nhân mới nhất của bạn vượt quá thẩm quyền vào ngày mai, liệu có gì trong công ty phát hiện ra không? Và bạn có thể chứng minh bằng văn bản cho kiểm toán viên thấy giới hạn đó nằm ở đâu không?