Bài 5 — Thiết kế quy trình Phê duyệt & Human-in-the-Loop

Không phải mọi hành động của agent đều cần người duyệt — nếu vậy agent vô dụng. Nghệ thuật của governance là đặt chốt phê duyệt đúng chỗ: chặn hành động rủi ro cao, để trôi hành động an toàn. Bài này chỉ cách thiết kế cổng phê duyệt (approval gate) và human-in-the-loop (HITL) hiệu quả.

Ba mô hình giám sát

• Human-in-the-loop (HITL): người duyệt trước khi agent thực thi. Dùng cho hành động không thể hoàn tác (irreversible): chuyển tiền, xóa dữ liệu, gửi thông báo hàng loạt.
• Human-on-the-loop: agent tự chạy, người giám sát và có thể dừng. Dùng cho hành động có thể sửa được, khối lượng lớn.
• Human-in-command: con người đặt mục tiêu, giới hạn và có quyền tắt toàn bộ.

Khung quyết định: khi nào cần approval?

Dùng ma trận Tác động × Khả năng hoàn tác:

                 | Hoan tac duoc      | KHONG hoan tac duoc
-----------------|--------------------|---------------------
Tac dong THAP    | Auto (chi log)     | Auto + canh bao
Tac dong CAO     | Auto + review sau  | HITL BAT BUOC

Ví dụ: agent gửi email marketing tới 1 khách (thấp, hoàn tác được→auto). Agent gửi tới 50.000 khách (cao, không hoàn tác→HITL bắt buộc).

Ví dụ cụ thể

Agent kế toán tự tạo lệnh thanh toán nhà cung cấp. Chính sách:

• < 5 triệu VND và nhà cung cấp đã có trong danh sách trắng → auto.
• >= 5 triệu HOẶC nhà cung cấp mới → HITL: chờ kế toán trưởng duyệt trong ứng dụng.

Điểm tinh tế: đừng đặt một ngưỡng duy nhất. Kẻ gian có thể chia nhỏ giao dịch (mỗi lệnh 4,9 triệu) để né ngưỡng 5 triệu. Vì vậy nên bổ sung luật theo tổng cộng dồn: nếu tổng thanh toán cho một nhà cung cấp trong ngày vượt hạn mức, cũng phải HITL. Governance tốt luôn nghĩ tới cách agent (hoặc kẻ lợi dụng agent) sẽ tìm đường lách ngưỡng.

Các bước xây dựng cổng phê duyệt

• Liệt kê các hành động rủi ro cao (từ Bài 2 policy).
• Đặt ngưỡng (threshold) cho từng loại: số tiền, số người ảnh hưởng, loại dữ liệu.
• Chọn người/vai trò duyệt và đường dự phòng nếu họ vắng (không để agent kẹt vô hạn).
• Thiết kế giao diện duyệt có ngữ cảnh: người duyệt phải thấy agent định làm gì, vì sao, dữ liệu nào.
• Ghi log quyết định duyệt (ai, khi nào, lý do) để audit.
• Đặt timeout an toàn: hết hạn thì mặc định từ chối, không phải tự cho qua.

def execute_action(action, ctx):
    if requires_approval(action, ctx):
        req = create_approval_request(action, ctx, approver=pick_approver(action))
        decision = wait_for_decision(req, timeout="4h", default="REJECT")  # fail-safe
        log_approval(req, decision)
        if decision != "APPROVED":
            return refuse("Hanh dong bi tu choi hoac het han duyet")
    return run(action)

def requires_approval(action, ctx):
    return (action.type == "payment" and action.amount >= 5_000_000) \
        or (action.type == "bulk_email" and ctx.recipients > 100) \
        or action.irreversible

Sai lầm thường gặp

• Duyệt mọi thứ: người duyệt bị "mệt mỏi phê duyệt" (approval fatigue), bấm Approve theo quán tính → cổng thành hình thức.
• Timeout mặc định = cho qua: cực nguy hiểm. Luôn fail-safe về REJECT.
• Giao diện duyệt thiếu ngữ cảnh: người duyệt không hiểu đang duyệt gì nên duyệt bừa.
• Không có đường dự phòng: người duyệt nghỉ phép, agent kẹt, việc kinh doanh đình trệ.
• Không log quyết định: khi có sự cố không biết ai đã duyệt.

Checklist thiết kế approval

• [ ] Đã map hành động rủi ro cao → cần HITL?
• [ ] Ngưỡng approval rõ ràng, dựa trên tác động + khả năng hoàn tác?
• [ ] Timeout fail-safe về REJECT?
• [ ] Người duyệt thấy đủ ngữ cảnh?
• [ ] Có đường dự phòng khi người duyệt vắng?
• [ ] Mọi quyết định được log?

Bài sau: chống lại các mối đe dọa đặc thù của agent — prompt injection, lạm quyền công cụ và guardrail kỹ thuật.