Một AI agent "full auto" nghe rất hấp dẫn cho tới khi nó tự gửi email xin lỗi nhầm 5.000 khách hàng, hoặc chạy lệnh DELETE trên database production lúc 2 giờ sáng. Human-in-the-loop (HITL) là mô hình đưa con người vào đúng những điểm quyết định quan trọng của luồng agent, thay vì để agent chạy một mạch từ đầu đến cuối.
HITL không phải là "tắt tự động hóa"
Sai lầm phổ biến nhất là nghĩ HITL = bắt người duyệt mọi thứ. Thực tế mục tiêu là tối đa hóa tự chủ ở nơi an toàn, chèn kiểm soát ở nơi rủi ro. Nếu agent phải hỏi bạn từng bước, nó vô dụng; nếu nó không hỏi gì, nó nguy hiểm.
Hãy phân biệt ba mức can thiệp của con người:
- Human-in-the-loop: người phê duyệt trước khi hành động xảy ra (approval gate). Ví dụ: agent soạn xong email hoàn tiền, chờ bạn bấm "Duyệt" mới gửi.
- Human-on-the-loop: agent tự chạy nhưng người giám sát và có thể can thiệp/dừng (kill switch). Ví dụ: bot trả lời chat tự động, có dashboard cho supervisor nhảy vào.
- Human-out-of-the-loop: chạy hoàn toàn tự động, chỉ xem lại qua log/audit sau đó.
Ví dụ cụ thể: agent xử lý hoàn tiền
Giả sử bạn xây một agent chăm sóc khách hàng có quyền hoàn tiền. Cùng một agent, nhưng ba tình huống khác nhau về rủi ro:
- Hoàn 50.000đ cho đơn lỗi rõ ràng → cho tự động (out-of-loop).
- Hoàn 2.000.000đ → cần người duyệt (in-the-loop).
- Hoàn 50.000.000đ hoặc hoàn cho >10 đơn cùng lúc → cần 2 người duyệt và cảnh báo quản lý.
Khung tư duy: Trục Tự chủ ↔ Kiểm soát
Rủi ro thấp ─────────────────────► Rủi ro cao
Tự chủ cao Kiểm soát cao
[auto] [log & review] [1 duyệt] [2 duyệt + cảnh báo]
Mỗi hành động của agent nằm ở một điểm trên trục này. Việc thiết kế HITL chính là gán mỗi loại hành động vào một điểm dựa trên: tác động nếu sai, khả năng hoàn tác, và tần suất.
Các bước để bắt đầu áp dụng HITL
- Liệt kê mọi hành động agent có thể thực hiện (gọi API, gửi mail, ghi DB, chuyển tiền, xóa file...). Đây là "bề mặt hành động".
- Gắn nhãn mỗi hành động là read hay write. Read (đọc, tra cứu, tính toán) thường an toàn. Write (thay đổi trạng thái thế giới thực) là nơi cần chú ý.
- Với mỗi hành động write, hỏi 3 câu: Nếu sai thì tệ đến đâu? Có undo được không? Xảy ra bao nhiêu lần/ngày?
- Quyết định mức can thiệp cho từng hành động theo trục ở trên.
- Ghi lại quyết định thành một bảng chính sách (policy) — chúng ta sẽ chuẩn hóa bảng này ở các bài sau.
Checklist khởi động HITL
- [ ] Đã liệt kê đủ bề mặt hành động của agent?
- [ ] Mỗi hành động đã phân loại read/write?
- [ ] Mỗi hành động write đã trả lời "nếu sai thì sao / undo được không"?
- [ ] Đã có ít nhất một kill switch để dừng agent khẩn cấp?
- [ ] Đã xác định ai là người duyệt cho từng loại hành động?
Sai lầm thường gặp
- Áp một mức duyệt cho tất cả. Bắt duyệt cả thao tác đọc dữ liệu khiến người vận hành "mệt mỏi phê duyệt" (approval fatigue) rồi bấm Duyệt vô thức — tệ hơn không có gate.
- Chỉ nghĩ tới hành động, quên tần suất. Một hành động rủi ro thấp nhưng chạy 10.000 lần/ngày có thể gây thiệt hại tích lũy lớn.
- Coi HITL là tính năng "làm sau". Gắn approval gate vào một agent đã chạy production rất khó; phải thiết kế điểm chèn người ngay từ kiến trúc.
- Nhầm giám sát (on-the-loop) với phê duyệt (in-the-loop). Giám sát không ngăn được hành động sai xảy ra, chỉ phát hiện sau đó.