Thiết kế quy trình phê duyệt cho AI Agent: Việc gì được tự làm, việc gì phải xin phép

Khi AI Agent chỉ trả lời câu hỏi, sai sót thường dừng ở một câu trả lời chưa đúng. Khi Agent bắt đầu tạo đơn mua, đổi lịch hẹn hay cập nhật CRM, sai sót có thể thành một giao dịch thật.

Vì vậy câu hỏi cần trả lời trước không phải là AI làm được việc gì, mà là việc nào được tự làm, việc nào phải có người duyệt. Ranh giới đó nên dựa trên ba yếu tố: mức ảnh hưởng nếu làm sai, khả năng hoàn tác và thẩm quyền của người duyệt.

Cách an toàn là bắt đầu với vài hành động rủi ro thấp, đo kết quả, rồi mới nới hạn mức. Khi một yêu cầu vượt ngoài phạm vi, Agent cần nói rõ và chuyển người thay vì tự quyết.

1. Cách nhìn đúng về quy trình phê duyệt AI Agent

Trong một Agent có hành động, lớp dữ liệu cho biết trạng thái hiện tại như tồn kho, hạn mức ngân sách, lịch còn trống. Lớp suy luận đề xuất hành động phù hợp với yêu cầu. Lớp kiểm soát là nơi quy trình phê duyệt nằm: nó quyết định đề xuất nào được thực thi ngay, đề xuất nào phải chờ người duyệt và đề xuất nào bị chặn. Thiếu lớp này, mọi hành động đều phụ thuộc vào việc mô hình “hiểu đúng” câu lệnh.

Nên phân biệt Agent đề xuất hành động với Agent thực thi hành động. Một Agent soạn sẵn đơn mua để người duyệt bấm gửi đã mang lại giá trị, trong khi rủi ro thấp hơn nhiều. Chỉ chuyển một hành động sang chế độ tự thực thi khi quyền, hạn mức, nhật ký và người chịu trách nhiệm đã được xác nhận và kiểm thử.

2. Các vấn đề cần xử lý

1. Phân loại hành động đọc và ghi

Đọc dữ liệu như tra trạng thái đơn hay xem lịch không làm thay đổi hệ thống. Ghi dữ liệu như tạo phiếu, sửa giá, gửi email cho khách thì có. Lập bảng mọi hành động Agent có thể làm và đánh dấu đọc hay ghi là bước đầu tiên. Hành động ghi mặc định cần kiểm soát, trừ khi đã được chứng minh là an toàn.

2. Đánh giá khả năng hoàn tác

Một ghi chú sai trong CRM có thể sửa ngay. Một email đã gửi cho khách hay một khoản thanh toán đã chuyển thì không lấy lại được. Hành động càng khó hoàn tác càng cần người duyệt trước khi thực thi. Với hành động hoàn tác được, có thể cho Agent tự làm rồi kiểm tra lại sau.

3. Đặt hạn mức tiền và số lượng

Hạn mức biến câu hỏi “có nên cho AI tự làm không” thành quy tắc kiểm tra được: dưới ngưỡng thì tự gửi, vượt ngưỡng thì chờ duyệt. Hạn mức phải được kiểm tra trong hệ thống, không chỉ viết trong hướng dẫn cho mô hình. Nên có cả hạn mức theo ngày để tránh nhiều đơn nhỏ cộng lại thành một khoản lớn.

4. Xác định cấp duyệt

Mỗi loại hành động cần ghi rõ ai được duyệt và ai thay thế khi người đó vắng. Cấp duyệt nên bám theo ma trận thẩm quyền doanh nghiệp đang dùng, không dựng một hệ thống quyền riêng cho AI. Dấu hiệu thiết kế chưa ổn là yêu cầu chờ duyệt dồn ứ vì không ai biết mình có trách nhiệm.

5. Lấy xác nhận của khách

Khi hành động thay đổi đơn hàng, lịch hẹn hay khoản thanh toán của khách, Agent cần tóm tắt lại nội dung và nhận xác nhận rõ ràng trước khi làm. Câu xác nhận nên nêu cụ thể thay đổi gì, ví dụ ngày giờ mới của lịch hẹn. Không nên coi một câu mơ hồ như “ừ được” trong đoạn chat dài là đồng ý cho mọi thay đổi.

6. Lưu đầu vào và kết quả

Mỗi hành động cần để lại dấu vết: yêu cầu gốc, dữ liệu Agent đã dùng, đề xuất, người duyệt, thời điểm và kết quả hệ thống trả về. Khi có khiếu nại, đây là căn cứ để biết lỗi nằm ở dữ liệu, ở quy tắc hay ở khâu duyệt. Nhật ký cũng cần giới hạn người xem vì có thể chứa dữ liệu khách hàng.

7. Chống thao tác trùng

Mạng chậm, người dùng bấm hai lần hoặc hệ thống tự thử lại đều có thể khiến một hành động chạy hai lần. Mỗi thao tác ghi cần một mã duy nhất để hệ thống nguồn nhận ra và bỏ qua lần gửi lặp. Kiểm thử nên cố tình gửi trùng để xác nhận chỉ một bản ghi được tạo. Cách thiết kế thử lại được bàn trong bài AI Agent và dữ liệu thời gian thực.

8. Thiết kế dừng khẩn cấp

Cần có cách tắt quyền thực thi của Agent ngay lập tức mà không phải sửa mã, ví dụ một công tắc đưa toàn bộ hành động về chế độ chỉ đề xuất. Ghi rõ ai được bật công tắc, khi nào bật và ai được mở lại. Nên diễn tập trước khi vận hành thật, đừng chờ đến lúc có sự cố.

3. Quy trình triển khai đề xuất

Bước 1: Lập danh mục hành động có thể xảy ra

Liệt kê mọi hành động Agent có thể thực hiện trên từng hệ thống, kể cả hành động hiếm. Đầu ra là bảng gồm tên hành động, hệ thống liên quan và loại đọc hay ghi. Chủ sở hữu từng hệ thống xác nhận danh mục không bỏ sót.

Bước 2: Chấm mức ảnh hưởng và khả năng hoàn tác

Với mỗi hành động ghi, đánh giá hậu quả nếu làm sai và mức độ dễ hoàn tác. Từ đó xếp hành động vào ba nhóm: tự làm, tự làm trong hạn mức, luôn cần duyệt. Bảng phân nhóm cần được chủ sở hữu nghiệp vụ và bộ phận tài chính hoặc pháp lý liên quan thông qua.

Bước 3: Gắn người duyệt, thời hạn và phương án hết hạn

Mỗi hành động cần duyệt phải có người duyệt chính, người thay thế và thời hạn phản hồi. Quyết định trước điều gì xảy ra khi hết hạn: hủy yêu cầu, nhắc lại hay chuyển cấp trên. Không bao giờ mặc định “quá hạn thì tự thực hiện”.

Bước 4: Thử tình huống từ chối, chậm duyệt và hệ thống lỗi

Không chỉ thử luồng được duyệt. Cần thử người duyệt từ chối, duyệt sau khi hết hạn, hệ thống nguồn lỗi giữa chừng và yêu cầu gửi trùng. Mỗi ca ghi kết quả mong đợi và kết quả thực tế, rồi đưa vào bộ kiểm thử chung của Agent để chạy lại sau mỗi thay đổi.

4. Ví dụ giả định

AI có thể tạo đơn mua nháp dưới mọi mức giá, nhưng chỉ tự gửi đơn lặp lại trong danh mục chuẩn dưới hạn mức. Đơn ngoài danh mục hoặc vượt hạn mức phải được quản lý mua hàng duyệt. Mỗi thao tác dùng mã duy nhất để tránh gửi hai lần khi hệ thống thử lại.

Giá trị của ví dụ không nằm ở việc AI soạn đơn nhanh, mà ở ranh giới rõ giữa đơn được tự gửi và đơn phải chờ. Mỗi quy tắc nên thành một ca kiểm thử: đơn trong danh mục dưới hạn mức, đơn vượt hạn mức, đơn ngoài danh mục và đơn gửi trùng, với quản lý mua hàng là người xác nhận kết quả.

5. Rủi ro và giới hạn cần kiểm soát

• Không dựa vào câu lệnh ngôn ngữ tự nhiên làm bằng chứng duyệt duy nhất
• Quyền dịch vụ phải tối thiểu
• Không để phê duyệt hết hạn vẫn được thực thi
• Nhật ký cần đủ để điều tra sự cố

Phê duyệt chỉ có ý nghĩa khi được thực thi bằng hệ thống. Bằng chứng duyệt nên là một thao tác được ghi nhận, như bấm nút trong công cụ duyệt, không phải một chữ “ok” trong đoạn chat. Tài khoản của Agent chỉ có quyền tối thiểu, phê duyệt có hạn dùng, nhật ký đủ để dựng lại sự việc. Với hành động liên quan đến tiền, hợp đồng hoặc dữ liệu cá nhân, chỉ lưu những gì cần cho mục đích kiểm soát.

6. Chỉ số nên theo dõi sau khi vận hành

• Tỷ lệ yêu cầu hoàn thành đúng theo bộ tiêu chí đã duyệt
• Tỷ lệ thiếu dữ liệu, từ chối đúng và chuyển người thật
• Số lỗi tích hợp, thời gian phản hồi và thời gian khắc phục
• Số lần nhân viên sửa kết quả và nguyên nhân sửa

Tỷ lệ hành động được tự động hóa cao chưa chắc là tốt. Cần xem song song số đề xuất bị từ chối, số lần phải hoàn tác và thời gian chờ duyệt. Nhóm hành động hầu như luôn được duyệt và chưa từng phải hoàn tác là ứng viên để nới hạn mức. Nhóm bị từ chối nhiều thì cần xem lại quy tắc đề xuất.

7. Checklist trước khi đưa vào sử dụng

• Nguồn dữ liệu và chủ sở hữu đã được xác nhận
• Quyền đọc ghi và phạm vi người dùng đã được kiểm thử
• Ngoại lệ có đường chuyển người phụ trách
• Nhật ký lưu đủ đầu vào nguồn và kết quả
• Bộ câu hỏi hoặc tình huống kiểm thử có đáp án mong đợi
• Có lịch cập nhật dữ liệu và kiểm thử lại

8. Câu hỏi thường gặp

Việc nào AI có thể tự làm? Việc rủi ro thấp, quy tắc rõ, trong hạn mức và có thể hoàn tác thường phù hợp hơn.

Ai đặt hạn mức? Chủ sở hữu nghiệp vụ phối hợp với tài chính, pháp lý hoặc an toàn thông tin tùy hành động.

Có cần khách xác nhận không? Có với hành động thay đổi đặt hàng, lịch, thanh toán hoặc cam kết quan trọng.

Kết luận

Quy trình phê duyệt tốt giúp doanh nghiệp tự động hóa dần mà không phải đặt cược vào độ chính xác của mô hình.

Hãy bắt đầu bằng danh mục hành động, xếp nhóm theo mức ảnh hưởng và khả năng hoàn tác, gắn người duyệt rõ ràng, rồi chỉ nới hạn mức khi dữ liệu vận hành cho thấy nhóm hành động đó đủ ổn định.

Trao đổi với Naventic để thiết kế ranh giới tự động hóa và quy trình phê duyệt cho AI Agent. Đọc thêm: AI Automation.