Quy trình phê duyệt và AI Agent: Quyết định nào nên luôn thuộc về con người?

Khi một AI Agent đã có thể tự đọc dữ liệu, tự phán đoán, và tự gọi các API để thực thi hành động, câu hỏi không còn là "AI có làm được việc này không" — mà là "việc này có nên để AI tự quyết định hay không".

Đây là câu hỏi dễ bị bỏ qua trong giai đoạn hào hứng ban đầu, nhưng lại chính là ranh giới quyết định một hệ thống AI Agent có được tin dùng lâu dài hay không. Bài viết này đề xuất một khung tư duy đơn giản để xác định: ở đâu AI có thể tự động hoàn toàn, ở đâu AI chỉ nên đề xuất, và ở đâu quyết định luôn phải thuộc về con người.

I. Vấn đề: không phải quyết định nào cũng như nhau

Nhiều đội ngũ khi thiết kế AI Agent thường đặt câu hỏi sai ngay từ đầu: "Chúng ta có nên tự động hoá bước này không?" — như thể tự động hoá là một lựa chọn nhị phân (có/không) áp dụng chung cho toàn bộ quy trình.

Trên thực tế, một quy trình nghiệp vụ thường chứa nhiều loại quyết định rất khác nhau về bản chất:

1. Có quyết định chỉ cần kiểm tra logic đơn giản (đúng/sai rõ ràng)
2. Có quyết định cần hiểu ngữ cảnh kinh doanh mà dữ liệu không thể hiện thể hết
3. Có quyết định nếu sai thì sửa lại dễ dàng
4. Có quyết định nếu sai thì hậu quả không thể đảo ngược (đã gửi cho khách hàng, đã trừ tiền, đã xoá dữ liệu...)

Gộp chung tất cả những loại quyết định này vào một câu hỏi "tự động hay không" là nguyên nhân khiến nhiều dự án AI Agent hoặc tự động hoá quá tay (gây sự cố), hoặc rụt rè quá mức (không tạo ra giá trị thực).

II. Một khung phân loại: 2 trục quyết định

Có thể phân loại từng quyết định trong quy trình theo 2 trục:

Trục 1 — Mức độ chắc chắn: Quyết định này có thể được xác định đúng/sai một cách máy móc, dựa trên quy tắc rõ ràng? Hay nó đòi hỏi phán đoán, ngữ cảnh, hoặc đánh đổi kinh doanh mà không có "đáp án đúng" cố định?

Trục 2 — Mức độ có thể đảo ngược: Nếu quyết định sai, có thể phát hiện và sửa lại dễ dàng không? Hay hậu quả đã lan ra ngoài hệ thống (tới khách hàng, tới tiền bạc, tới dữ liệu bị mất) và không thể thu hồi?

Kết hợp 2 trục này tạo thành 4 vùng:

1. Chắc chắn + Có thể đảo ngược → Có thể tự động hoá hoàn toàn.
2. Chắc chắn + Không thể đảo ngược → Vẫn có thể tự động hoá, nhưng cần thêm lớp bảo vệ: giới hạn phạm vi, ghi log đầy đủ, có khả năng rà soát sau khi thực thi.
3. Cần phán đoán + Có thể đảo ngược → AI có thể đề xuất giá trị, nhưng con người xác nhận trước khi áp dụng.
4. Cần phán đoán + Không thể đảo ngược → Luôn phải để con người quyết định cuối cùng. AI chỉ cung cấp thông tin, phân tích, gợi ý — không bao giờ tự thực thi.

III. Ví dụ minh hoạ: cùng một quy trình, 4 quyết định khác nhau

Để dễ hình dung, hãy theo dõi một quy trình quen thuộc: xử lý yêu cầu hoàn tiền của khách hàng ở một cửa hàng online. Đây không phải 4 hệ thống khác nhau — mà là 4 bước quyết định trong cùng một quy trình, và mỗi bước lại rơi vào một vùng khác nhau.

Bước 1 — Kiểm tra điều kiện hoàn tiền (Vùng 1: Chắc chắn + Có thể đảo ngược)

Hệ thống kiểm tra: đơn hàng có tồn tại không? Ngày mua có còn nằm trong 30 ngày theo chính sách không? Đây thuần tuý là so sánh ngày tháng — không có cách hiểu nào khác ngoài đúng/sai. Nếu hệ thống đánh giá nhầm, admin chỉ cần mở lại và sửa, chưa có gì xảy ra với tiền bạc. → Tự động hoàn toàn.

Bước 2 — Đánh dấu đơn hàng "đủ điều kiện hoàn tiền" trong hệ thống nội bộ (Vùng 2: Chắc chắn + Không thể đảo ngược)

Khi đơn hàng thoả tất cả điều kiện cứng (trong hạn, sản phẩm thuộc danh mục được hoàn, chưa từng hoàn trước đó), hệ thống tự động chuyển trạng thái đơn hàng sang "đã duyệt hoàn tiền". Việc này vẫn dựa trên quy tắc rõ ràng, nhưng đã ghi đè trạng thái đơn hàng trong hệ thống — nếu sai sẽ ảnh hưởng đến các bước xử lý tiếp theo. Vì vậy, hệ thống giới hạn phạm vi chặt (chỉ áp dụng cho đơn thoả *toàn bộ* điều kiện) và ghi log đầy đủ để có thể rà soát lại. → Tự động, nhưng có giới hạn phạm vi và log.

Bước 3 — Đề xuất số tiền hoàn cụ thể (Vùng 3: Cần phán đoán + Có thể đảo ngược)

Với đơn hàng phức tạp — ví dụ khách đã dùng một phần sản phẩm, hoặc mua theo combo khuyến mãi cần tính lại tỷ lệ — AI đề xuất một số tiền hoàn cụ thể kèm cách tính. Nhân viên xem đề xuất, có thể chỉnh sửa trước khi xác nhận. Vì tiền chưa được chuyển đi, nếu đề xuất sai thì sửa ngay tại chỗ, không tốn kém. → AI đề xuất, người xác nhận.

Bước 4 — Bấm nút chuyển tiền hoàn trả thực tế (Vùng 4: Cần phán đoán + Không thể đảo ngược)

Đây là hành động cuối: tiền rời khỏi tài khoản công ty và chuyển vào tài khoản/ví của khách hàng. Một khi đã chuyển, việc thu hồi gần như không thể (đặc biệt nếu hoàn về ví điện tử hoặc thẻ ngân hàng khác). Vì vậy, dù số tiền đã được tính đúng ở Bước 3, hành động "chuyển tiền" luôn cần một người xác nhận cuối cùng — AI không bao giờ được tự bấm nút này. → Luôn để con người quyết định.

Nhìn theo cách này, câu hỏi "quy trình hoàn tiền có nên tự động hay không" không còn ý nghĩa nữa — mà rõ ràng: 3 trong 4 bước có thể tự động ở các mức độ khác nhau, chỉ riêng bước cuối cùng (chuyển tiền thật) là luôn cần con người.

IV. Điều quan trọng: ranh giới phải nằm trong code, không nằm trong prompt

Một sai lầm phổ biến là nghĩ rằng chỉ cần viết trong prompt "hãy luôn hỏi ý kiến con người trước khi làm X" là đủ. Trên thực tế, đây chỉ là một lời đề nghị — không phải một ràng buộc.

Ranh giới giữa 4 vùng ở trên cần được hiện thực hoá như giới hạn kỹ thuật thực sự.

1. Tool chỉ nhận tham số đã được người dùng xác nhận, không tự suy luận giá trị nhạy cảm
2. Với các hành động ở Vùng 4, đơn giản là không xây dựng chức năng để AI có thể tự gọi và thực thi. AI chỉ được phép chuẩn bị sẵn thông tin (ví dụ số tiền cần hoàn); còn thao tác cuối cùng — bấm nút thực thi — chỉ tồn tại trên giao diện dành cho con người, và phải do một người trực tiếp thực hiện
3. Mọi hành động ở Vùng 2, 3, 4 đều được ghi log đầy đủ: ai, khi nào, giá trị gì đã được chọn

Nói cách khác, việc phân loại 4 vùng ở trên không phải là một tài liệu hướng dẫn để AI "cố gắng tuân theo" — mà là bản thiết kế hệ thống, quyết định Tool nào tồn tại, Tool nào không, và Tool nào có giới hạn phạm vi ra sao.

V. Ranh giới này không cố định — nhưng thay đổi phải có chủ đích

Ranh giới giữa "tự động" và "cần người quyết định" không phải bất biến. Khi một AI Agent đã chứng minh được độ tin cậy qua thời gian vận hành thực tế (ví dụ: hàng trăm lần đề xuất ở Vùng 3 đều được người dùng chấp nhận không sửa), có thể cân nhắc dịch chuyển một số trường hợp từ Vùng 3 sang Vùng 2.

Nhưng đây phải là một quyết định thiết kế có chủ đích, dựa trên dữ liệu vận hành thực tế — chứ không phải một sự "tự nới lỏng" âm thầm xảy ra vì AI ngày càng làm nhiều việc hơn mà không ai để ý.

Kết luận

Câu hỏi "AI Agent này có nên tự động hay không" luôn là một câu hỏi sai nếu hỏi cho cả một quy trình. Câu hỏi đúng là: "với từng quyết định cụ thể trong quy trình, nó thuộc vùng nào trong 4 vùng trên — và ranh giới đó có đang được bảo vệ bằng code, hay chỉ đang được 'hy vọng' qua một dòng prompt?"

Thiết kế đúng ranh giới này ngay từ đầu — chứ không phải sau khi xảy ra sự cố — là điều phân biệt giữa một AI Agent được tin dùng lâu dài, và một AI Agent chỉ được dùng thử rồi bị gạt sang một bên.