Agent của bạn chạy ngon 3 tuần liền. Đến tuần thứ tư, nó tự tin gọi tool delete_customer_records với filter sai — và xoá 4.000 bản ghi thay vì 40. Không ai duyệt, vì workflow "đã ổn định". Rollback mất một buổi chiều, giải trình với sếp mất một tuần.
Đây không phải chuyện hiếm. 51% tổ chức đã chạy agent ở production, nhưng chỉ 37–40% có containment control thực sự — kill switch, purpose binding, network isolation. Khảo sát của Kiteworks còn chỉ ra gap 15–20 điểm phần trăm giữa control mà tổ chức đã đầu tư và control họ thực sự cần. Nghĩa là phần lớn đang tự tin hơn mức hệ thống cho phép.
Và deadline đang đến: Điều 14 EU AI Act — bắt buộc giám sát con người với hệ thống AI rủi ro cao — có hiệu lực ngày 2/8/2026. Tức là hai tuần nữa, tính từ lúc bài này lên.
Hãy nghĩ về HITL như sudo, không phải như form duyệt
Linux không hỏi bạn mật khẩu khi ls. Nó hỏi khi bạn rm -rf /var. Sudo hoạt động vì ba tính chất:
- Gate nằm ở ranh giới hành động, không nằm ở đầu phiên làm việc.
- Mặc định là chặn — không có phê duyệt thì lệnh không chạy, chấm hết.
- Mọi lần escalate đều vào log (
/var/log/auth.log), audit được.
Đa số hệ thống HITL cho agent hiện nay làm ngược lại: hỏi một lần ở đầu workflow ("bạn có chắc muốn chạy quy trình này?"), rồi để agent tự tung tự tác 20 bước tiếp theo. Đó là kiểu "đăng nhập root rồi để terminal mở cả ngày".
Vì sao gate ở cấp tool tốt hơn gate ở cấp workflow
n8n 1.28 (đầu 2026) đưa human-in-the-loop xuống cấp tool: một tool bị gate sẽ không chạy nếu chưa có người duyệt — agent vẫn plan, vẫn gọi các tool an toàn khác, chỉ đứng lại đúng chỗ nguy hiểm. Khác biệt so với gate cấp workflow là căn bản:
| Gate cấp workflow | Gate cấp tool | |
|---|---|---|
| Điểm dừng | Đầu/cuối quy trình | Đúng ranh giới hành động rủi ro |
| Ngữ cảnh cho người duyệt | "Duyệt cả quy trình?" — mơ hồ | "Xoá 40 bản ghi với filter X?" — cụ thể |
| Agent tự sửa plan sau khi bị từ chối | Không — phải chạy lại từ đầu | Có — agent nhận rejection như một tool output và điều chỉnh |
| Số lần duyệt vô nghĩa | Nhiều (duyệt cả những bước vô hại) | Ít (chỉ duyệt bước có răng) |
Điểm thứ ba đáng tiền nhất: khi người duyệt bấm từ chối kèm lý do, agent coi đó là feedback và lập plan khác — thay vì chết cứng. HITL trở thành một phần của vòng lặp ReAct, không phải cái phanh tay kéo giữa đường cao tốc.
Agent plan → gọi tool "an toàn" (đọc, tra cứu) → chạy ngay
→ gọi tool "gated" (xoá, ghi, gửi) → PAUSE
→ người duyệt: approve → tool chạy, ghi audit log
→ người duyệt: reject + lý do → agent nhận feedback, re-plan
Phân loại: hành động nào cần sudo?
Đừng gate mọi thứ — gate mọi thứ nghĩa là không gate gì cả, vì người duyệt sẽ bấm approve theo quán tính. Nguyên tắc: gate những hành động không đảo ngược được hoặc vượt ra ngoài hệ thống.
- Xoá bản ghi (DELETE, DROP, truncate): không đảo ngược được nếu không có backup nóng.
- Ghi vào production (deploy, migration, cập nhật giá): đảo ngược được nhưng đắt.
- Gửi email/tin nhắn đối ngoại: một khi ra khỏi SMTP server là không thu hồi được — và mang danh công ty bạn.
- Chuyển tiền, tạo hoá đơn, ký hợp đồng: hiển nhiên.
Ngược lại: đọc dữ liệu, tính toán, ghi vào staging, gửi thông báo nội bộ — cho chạy thẳng. Tỷ lệ tốt trong thực tế là dưới 10% tool call phải qua gate. Cao hơn nghĩa là bạn đang thiết kế sai ranh giới, hoặc agent của bạn chưa nên chạy tự động.
Automation complacency: kẻ thù thật sự không phải agent
Nghịch lý khó chịu nhất của HITL: hệ thống càng đáng tin, người duyệt càng lơ là. Nếu 200 request duyệt gần nhất đều đúng, request thứ 201 sẽ được approve trong 1,5 giây mà không ai đọc. Đây là hiện tượng cũ trong ngành hàng không (autopilot làm phi công mất cảnh giác), giờ tái diễn với người duyệt agent.
Vài cách thiết kế chống lại nó:
- Hiển thị diff, không hiển thị mô tả. "Agent muốn cập nhật bảng giá" là vô dụng. "Giá SKU-1042: 129.000đ → 12.900đ" khiến người duyệt giật mình đúng lúc cần giật mình.
- Bắt nhập lý do khi approve các hành động tier cao nhất (chuyển tiền, xoá hàng loạt). Gõ một câu buộc não bật lên.
- Trộn "canary request": thỉnh thoảng chèn một request cố tình sai để đo xem người duyệt có còn đọc không. Tỷ lệ canary lọt qua là metric vigilance của bạn.
- Giới hạn số duyệt mỗi người mỗi ngày. Người duyệt request thứ 80 trong ngày không còn là human trong loop — chỉ là latency trong loop.
Checklist trước ngày 2/8/2026
Điều 14 không yêu cầu "có nút approve". Nó yêu cầu người giám sát hiểu được, can thiệp được, và dừng được hệ thống. Dịch ra việc kỹ thuật:
- Liệt kê tool theo tier rủi ro — tier 0 chạy thẳng, tier 1 gate + duyệt, tier 2 gate + duyệt + lý do. Một buổi workshop với business owner là đủ.
- Chuyển gate từ workflow-level xuống tool-level — nếu dùng n8n, bản 1.28 trở lên có sẵn; nếu tự viết scaffold, chặn ở tầng tool executor, đừng chặn ở prompt (agent có thể "quên" prompt, nhưng không thể vượt qua code).
- Kill switch độc lập với agent — một endpoint tắt được toàn bộ tool tier 1–2 mà không cần agent hợp tác. Đây chính là chỗ 60% tổ chức đang thiếu.
- Audit log bất biến: ai duyệt, duyệt gì, lúc nào, agent đưa ngữ cảnh gì. Mô hình event history của Temporal là tham chiếu tốt — mọi bước được ghi lại và replay được.
- Đo baseline vigilance trước khi auditor hỏi: tỷ lệ reject, thời gian đọc trung bình mỗi request, tỷ lệ canary bị lọt.
Mỗi mục trên làm được trong 1–2 tuần với hệ thống cỡ vừa. Trùng khớp một cách không dễ chịu với thời gian còn lại.
Sudo tồn tại 40 năm không phải vì Linux không tin sysadmin, mà vì nó buộc sysadmin dừng lại nửa giây trước hành động không đảo ngược được. HITL cho agent cũng vậy: giá trị không nằm ở nút approve, mà ở việc kiến trúc hệ thống thừa nhận rằng có những ranh giới máy không được tự bước qua — kể cả khi nó đúng 200 lần liên tiếp. Vì lần thứ 201 mới là lần đắt nhất.
