AI soạn, người duyệt: bước chặn trước khi AI gửi thư cho khách

Tình huống giả định: một cửa hàng trực tuyến cho trợ lý AI tự trả lời email khiếu nại. Giữa đêm, AI hứa hoàn tiền toàn bộ cho khách, dù chính sách của cửa hàng không cho phép.

Bài này nói về bước chặn giữa lúc AI soạn thư và lúc thư rời hệ thống: hành động nào cần người duyệt, màn duyệt hiện gì, vì sao người duyệt dễ bấm cho xong, và cách đo. Nguồn là tài liệu của OWASP, OpenAI, Anthropic, NIST và Google PAIR.

Click Star đã có bài riêng về AI agent, gọi công cụ và tiêm lệnh; bài này đi vào bước duyệt. Click Star có bán dịch vụ tích hợp AI, nên mọi khung do Click Star đề xuất đều được gắn nhãn.

Điểm chính

• Người duyệt (human-in-the-loop) đáng giá nhất ở hành động đi ra ngoài hoặc khó hoàn tác. OWASP gọi việc thiếu duyệt hành động tác động lớn là "excessive autonomy" (thừa tự chủ).
• Chia hành động của AI thành 6 loại theo rủi ro: đọc, soạn nháp, gửi ra ngoài, ghi dữ liệu, tiền, xóa (khung tham khảo của Click Star).
• Màn duyệt phải hiện nội dung nguyên văn sắp chạy, không chỉ dòng "AI muốn gửi thư".
• Người duyệt có thể mệt và duyệt cho có. Anthropic nêu hiện tượng "approval fatigue" và cho biết người dùng Claude Code chấp nhận 93% lời nhắc thủ công (số của công cụ lập trình, không đo việc có đọc hay không). NIST gọi xu hướng tin máy quá mức là automation bias.
• Chặn ở tầng ứng dụng, không chỉ bằng câu dặn trong prompt. OWASP khuyên kiểm quyền ở hệ thống phía sau.
• Chỉ nới lỏng từng loại hành động theo số đo của chính doanh nghiệp, kèm lấy mẫu kiểm tra sau khi gửi. Chưa có ngưỡng chuẩn từ nguồn ngoài.

AI tự gửi hay chờ người duyệt: ranh giới nằm ở đâu

Ranh giới nằm ở hậu quả của hành động, không phải ở việc AI giỏi đến đâu. Human-in-the-loop, tức có người nằm trong vòng xử lý, nghĩa là AI chỉ đề xuất còn người quyết định trước khi hành động chạy.

OWASP gọi rủi ro này là "Excessive Agency", tạm dịch là quyền tự quyết quá mức (mục LLM06:2025, không ghi ngày). Nguyên nhân gốc gồm thừa chức năng, thừa quyền và thừa tự chủ.

Với trợ lý hộp thư có thể bị email độc hại ép chuyển thư nhạy cảm, một cách OWASP nêu là bắt người dùng tự xem và bấm gửi từng thư do AI soạn.

Theo NIST (AI RMF 1.0, tháng 1/2023), có hệ thống AI không cần người giám sát, ví dụ mô hình nén video, và có hệ thống thì cần. Click Star đề xuất: với doanh nghiệp Việt Nam, mỗi loại hành động của AI nên có tên người chịu trách nhiệm.

6 loại hành động của AI, xếp theo rủi ro

Khung dưới đây là khung tham khảo của Click Star, không lấy từ nguồn ngoài. Một hành động thuộc nhiều loại thì lấy loại rủi ro cao nhất: thư gửi khách có lời hứa hoàn tiền thuộc loại "tiền", dù hình thức là "gửi ra ngoài".

• Đọc: tra đơn, xem lịch sử. Tự động được nếu quyền chỉ đọc và chỉ lấy dữ liệu của đúng khách đang hỏi (quyền tối thiểu theo OWASP).
• Soạn nháp: AI viết nhưng chưa rời hệ thống. Tự động được nếu bản nháp nằm trong hộp nháp, không có đường tự gửi.
• Gửi ra ngoài: email, Zalo, bài đăng. Rút lại rất khó, nên cần người duyệt từng bản, ít nhất lúc đầu.
• Ghi dữ liệu: sửa hồ sơ CRM, đổi trạng thái đơn. Cần người duyệt, hoặc chỉ ghi tự động khi hoàn tác được và có nhật ký.
• Tiền: hoàn tiền, giảm giá, báo giá. Luôn cần người duyệt có thẩm quyền.
• Xóa: không đảo ngược. Luôn cần người duyệt; tốt hơn là bỏ hẳn chức năng này khỏi AI nếu không cần (OWASP: giữ chức năng tối thiểu).

Màn duyệt phải hiện gì để người duyệt quyết định được

Màn duyệt phải hiện đúng nội dung sắp gửi, không phải bản tóm tắt. Tài liệu "Handle approvals and user input" của Claude Code Agent SDK làm vậy: ứng dụng nhận tên công cụ và tham số để người dùng quyết định.

OpenAI dặn thêm trong hướng dẫn Agents SDK: coi tên công cụ và tham số là nội dung không tin cậy, lọc giá trị nhạy cảm và thoát ký tự trước khi vẽ ra HTML.

Click Star đề xuất màn duyệt có 5 phần (khung tham khảo của Click Star):

• Nội dung nguyên văn sẽ gửi, kèm người nhận và kênh gửi.
• Dữ liệu AI đã dùng để soạn, ví dụ đơn hàng nào và đoạn chính sách nào.
• Phần được đánh dấu: số tiền, ngày hẹn, lời cam kết.
• 3 nút: Gửi, Sửa rồi gửi, Từ chối kèm lý do.
• Dòng ghi người duyệt và thời điểm.

Quyền duyệt và nhật ký. Hướng dẫn Agents SDK của OpenAI dặn máy chủ xác thực người duyệt bằng phiên đăng nhập, không lấy danh tính từ yêu cầu gửi lên, và không nhận tham số thay thế từ phía người dùng. Click Star đề xuất ghi nhật ký mỗi lượt duyệt: ai duyệt, lúc nào, quyết định gì.

Vì sao người duyệt hay bấm đồng ý cho xong

Vì việc lặp lại làm giảm chú ý, và con người hay tin máy quá mức. Anthropic (bài "How we built Claude Code auto mode", 25/3/2026) gọi hiện tượng đầu là "approval fatigue", tức mệt vì phải duyệt: người dùng không còn để ý mình đồng ý điều gì.

Cũng bài đó nêu số cụ thể: người dùng Claude Code chấp nhận 93% lời nhắc xin quyền thủ công. Đây là công cụ lập trình, bài không nêu mẫu người dùng, và không phải số đo việc không đọc hay việc duyệt thư gửi khách.

NIST gọi xu hướng thứ hai là automation bias, tức nghiêng quá mức về hệ thống tự động. Theo hồ sơ NIST AI 600-1 về AI tạo sinh (tháng 7/2024), nó có thể làm trầm trọng thêm nguy cơ AI bịa thông tin.

Tổng quan "Complacency and Bias in Human Use of Automation" của Parasuraman và Manzey (Human Factors 52(3), 2010, DOI 10.1177/0018720810376055; đọc phần tóm tắt qua Crossref) cho thấy nó xảy ra ở cả người mới và chuyên gia, và không ngăn được chỉ bằng huấn luyện hay chỉ dẫn.

Vì vậy dặn người duyệt "hãy đọc kỹ" là chưa đủ. Cần thiết kế để đọc thật thì dễ, bấm cho xong thì khó. Các gợi ý sau là của Click Star, chưa có nguồn đo hiệu quả:

• Giảm số mục cần duyệt bằng cách bỏ chức năng và quyền thừa trước.
• Xếp mục rủi ro cao lên đầu, đánh dấu số tiền, ngày, cam kết.
• Không cho duyệt hàng loạt loại "tiền" và "xóa".
• Thỉnh thoảng đưa vào hàng đợi 1 bản kiểm thử có lỗi đã biết để xem người duyệt có đọc không, và báo trước cho đội.

Chặn ở tầng ứng dụng, không chỉ bằng lời dặn trong prompt

Theo cách nhìn của Click Star, câu dặn "đừng gửi khi chưa được duyệt" trong prompt (đoạn chữ dặn mô hình) là lớp mềm. Lớp chắc là tầng ứng dụng, tức phần mềm của bạn nằm giữa mô hình và hệ thống thật như email. Mô hình chỉ đề xuất, ứng dụng mới bấm nút gửi.

OWASP gọi nguyên tắc này là "complete mediation": kiểm quyền ở hệ thống phía sau, không dựa vào mô hình. OpenAI (trang "Guardrails and human review", không ghi ngày) mô tả cùng ý: mô hình có thể quyết định cần một hành động, nhưng lượt chạy dừng đến khi bạn duyệt hoặc từ chối.

Vòng đời duyệt theo OpenAI gồm 4 việc: lượt chạy ghi yêu cầu duyệt thay vì chạy công cụ; kết quả trả về danh sách chờ; ứng dụng duyệt hoặc từ chối; ứng dụng chạy tiếp đúng lượt đó.

Trang này cũng khuyên, trong luồng nhiều agent kiểu manager, đặt kiểm tra ngay cạnh công cụ gây tác dụng phụ thay vì chỉ ở agent đầu và cuối. Công cụ gửi thư là ví dụ điển hình theo cách hiểu của Click Star.

Khi người duyệt vắng mặt, Anthropic ghi rằng với always_ask, phiên làm việc dừng và chờ không giới hạn thời gian. Hướng dẫn của OpenAI cho quy trình an ninh mạng được ủy quyền nói nên từ chối khi việc duyệt quá hạn hoặc không dùng được. Click Star đề xuất mặc định: không có người duyệt thì không gửi, kèm người duyệt dự phòng.

Cần phân biệt duyệt với chế độ tự động. Theo Anthropic, chính sách auto của Managed Agents không phải điểm kiểm soát của con người: nếu máy chủ thấy lệnh gọi an toàn thì lệnh chạy trước khi ai nhìn thấy.

Khi nào nới lỏng, và lấy mẫu kiểm tra sau khi gửi

Chỉ nên nới từng loại hành động một, khi số đo của chính doanh nghiệp đã ổn định. Khung 3 giai đoạn sau là của Click Star:

• Giai đoạn 1: người duyệt từng bản mọi thư gửi ra ngoài, ghi lại phần người duyệt sửa.
• Giai đoạn 2: loại thư rủi ro thấp (ví dụ xác nhận đã nhận yêu cầu) chuyển sang tự gửi khi tỷ lệ sửa thấp và ổn định, kèm lấy mẫu xem lại sau khi gửi.
• Giai đoạn 3: loại "tiền" và "xóa" vẫn giữ duyệt bắt buộc.

Ngưỡng "thấp" và tỷ lệ lấy mẫu do doanh nghiệp tự đặt; Click Star không có nguồn ngoài để nêu số. Nên lấy mẫu nhiều lúc đầu rồi giảm dần, và quay lại duyệt toàn bộ ngay khi thấy một lỗi nghiêm trọng.

Google PAIR nói có lỗi mà cả người dùng lẫn hệ thống đều không nhận ra, và loại lỗi này cần quy trình kiểm tra chất lượng riêng; Click Star coi lấy mẫu sau khi gửi là một quy trình như vậy.

Cách đo: bước duyệt có đang làm việc không

Hãy đo theo 3 nhóm và đọc các số cùng nhau; đây là bộ chỉ số do Click Star đề xuất.

Chất lượng bản nháp. Tỷ lệ bản được sửa trước khi gửi, tỷ lệ bản bị từ chối, nhóm lý do từ chối, số khiếu nại phát hiện sau khi gửi. Click Star đã có bài riêng về đánh giá chatbot AI.

Tốc độ. Thời gian từ lúc AI soạn đến lúc có người duyệt, số mục đang chờ, thời gian khách đợi.

Người duyệt có đọc thật không. Thời gian mở nội dung trước khi bấm duyệt, số lần duyệt liên tiếp không sửa gì, và kết quả với bản kiểm thử có lỗi cố ý nếu bạn dùng cách đó.

Tỷ lệ sửa thấp chưa chắc là tốt: có thể AI viết tốt, cũng có thể người duyệt không đọc. Chỉ phân biệt được khi xem cùng nhóm thứ ba và kết quả lấy mẫu sau gửi.

Đánh giá của Click Star. Có 3 nhận định kỹ thuật và quản trị. Thứ nhất, đặt người duyệt đúng chỗ khó hoàn tác, thay vì bắt duyệt mọi thứ rồi để người duyệt kiệt sức. Thứ hai, bước duyệt là một phần của sản phẩm: cần thiết kế, đo và sửa dần.

Thứ ba, quy tắc phải nằm trong mã ứng dụng, không chỉ trong prompt. Với đội nhỏ ở Việt Nam có ít nhân viên chăm sóc khách hàng, cổng đầu tiên nên dựng là cổng trước mọi thư nói về tiền hoặc cam kết. Các nhận định này là suy luận của Click Star từ tài liệu đã nêu, không dựa trên số đo của dự án nào.

Việc nên làm trong 4 tuần

Lộ trình này là khung tham khảo của Click Star, không phải số đo.

• Tuần 1: liệt kê mọi việc AI có thể làm, xếp vào 6 loại, bỏ chức năng và quyền không cần. Mỗi loại ghi tên người chịu trách nhiệm và người dự phòng.
• Tuần 2: dựng màn duyệt 5 phần và nhật ký. Đặt quy tắc duyệt trong mã, mặc định "không gửi" khi chưa có người duyệt.
• Tuần 3: chạy thử với 1 kênh, duyệt toàn bộ, ghi tỷ lệ sửa, tỷ lệ từ chối và thời gian duyệt.
• Tuần 4: xem số đo cùng nhóm "người duyệt có đọc thật không", quyết định nới loại nào, đặt tỷ lệ lấy mẫu.

Những sai lầm thường gặp

1. Tin vào câu dặn trong prompt thay vì chặn ở tầng ứng dụng.
2. Màn duyệt chỉ hiện "AI muốn gửi thư, đồng ý?", không có nội dung nguyên văn và nguồn dữ liệu.
3. Dồn mọi hành động vào 1 hàng đợi, khiến người duyệt bị ngập rồi bấm cho xong.
4. Cho duyệt hàng loạt các mục loại "tiền" hoặc "xóa".
5. Để hệ thống tự gửi khi không có ai duyệt, thay vì mặc định không gửi.
6. Nới lỏng mà không lấy mẫu kiểm tra sau khi gửi.
7. Coi tỷ lệ sửa thấp là bằng chứng AI viết tốt, trong khi có thể người duyệt không đọc.

Điều chưa biết

Click Star chưa có số đo độc lập về mức duyệt cho có khi người duyệt kiểm bản nháp AI viết cho khách ở doanh nghiệp Việt Nam. Số 93% của Anthropic là của người dùng công cụ lập trình.

Chưa có nguồn mở được nêu ngưỡng chuẩn cho tỷ lệ sửa, tỷ lệ lấy mẫu hay thời gian duyệt, và Click Star chưa đọc được nghiên cứu đo hiệu quả của các gợi ý như xếp mục rủi ro lên đầu hay chèn bản kiểm thử có lỗi.

Click Star chỉ đọc được phần tóm tắt nghiên cứu năm 2010 của Parasuraman và Manzey, vì trang nhà xuất bản không mở được bằng công cụ.

Managed Agents của Anthropic đang ở bản beta. Agent Builder, công cụ dựng luồng nhiều agent của OpenAI và khác Agents SDK đã trích, theo trang "Safety in building agents" sẽ ngừng ngày 30/11/2026. Bài không tư vấn pháp lý về trách nhiệm khi AI gửi thư có dữ liệu cá nhân; hãy hỏi chuyên gia pháp lý.