Human-in-the-loop trong workflow AI nên đặt ở đâu?

Một ticket yêu cầu hỗ trợ gửi đến hệ thống lúc 9 giờ 12 phút. Người gửi báo không đăng nhập được tài khoản và đề nghị kỹ thuật mở lại ngay để kịp cuộc họp sáng.

Workflow tự động đọc nội dung, nhận diện vấn đề liên quan đến xác thực người dùng, tự động tra cứu tài liệu hướng dẫn và soạn sẵn một bản nháp trả lời. Đến giai đoạn này, AI đang làm tròn vai trò trợ lý: đọc nhanh, phân loại dữ liệu và chuẩn bị sẵn khung nội dung. Nếu phân loại nhầm, kỹ sư trực ca vẫn có thể đọc lại và điều chỉnh trước khi gửi đi.

Rủi ro xuất hiện ở bước tiếp theo. Từ câu "tôi bị khóa tài khoản", hệ thống AI tự suy luận rằng cần mở khóa ngay và chuẩn bị gọi thẳng API quản trị người dùng. Lúc này, một phán đoán mang tính xác suất của mô hình ngôn ngữ đã chuẩn bị biến thành hành động thay đổi trạng thái thực tế trên hệ thống production.

Tình huống này chỉ ra bản chất của cơ chế con người can thiệp (Human-in-the-loop - HITL). Bạn không cần đặt một nút bấm phê duyệt sau mỗi lần gọi mô hình AI. Con người chỉ cần xuất hiện tại ranh giới nơi một kết quả suy luận sắp chuyển hóa thành cam kết pháp lý, giao dịch tài chính hoặc hành động kỹ thuật có hậu quả không thể đảo ngược.

Đặt người duyệt ở mọi bước làm giảm độ an toàn của hệ thống

Nhiều đội ngũ kỹ thuật khi mới tích hợp AI thường chọn giải pháp an toàn trên lý thuyết: yêu cầu con người bấm xác nhận sau từng bước nhỏ. AI phân loại ticket xong thì dừng lại chờ người duyệt nhãn. AI trích xuất xong tài liệu tham khảo lại chờ duyệt danh sách nguồn. Đến khi AI soạn xong bản nháp, người trực lại phải bấm duyệt thêm một lần nữa.

Cách làm này tạo ra phản ứng ngược trong vận hành thực tế. Hàng chờ nhanh chóng bị quá tải bởi hàng trăm tác vụ nhỏ nhặt. Khi nhận thấy 95% nhãn phân loại của AI đều chính xác, người trực ca bắt đầu nhìn lướt qua rồi bấm duyệt thật nhanh để giải phóng hàng đợi. Nút "Đồng ý" (Approve) trên giao diện vẫn được kích hoạt đầy đủ, nhưng sự kiểm soát thực tế đã biến thành phản xạ cơ học vô thức.

Một cổng phê duyệt chỉ phát huy giá trị khi người duyệt nhận được một quyết định xứng đáng để cân nhắc, có đủ thông tin đối chiếu và có đủ thời gian chịu trách nhiệm cho lựa chọn của mình. Nếu bạn bắt kỹ sư xác nhận từng câu chữ trong những khâu ít rủi ro, sự tập trung của họ sẽ cạn kiệt trước khi quy trình chạm đến các thao tác quản trị then chốt.

Đối với các khâu tiền xử lý như phân loại sơ bộ hoặc tóm tắt tài liệu nội bộ, bạn có thể cho phép workflow chạy tự động hoàn toàn. Hệ thống chỉ chuyển tác vụ sang hàng chờ thủ công khi AI trả về mức độ tin cậy thấp, dữ liệu đầu vào mơ hồ hoặc yêu cầu nằm ngoài phạm vi xử lý định trước. Kiểm soát chất lượng ở khâu này nên thực hiện bằng cách lấy mẫu ngẫu nhiên định kỳ để theo dõi độ ổn định của mô hình, thay vì biến kỹ sư thành chiếc công tắc thủ công cho từng lệnh gọi API.

Khung quản trị rủi ro AI của Viện Tiêu chuẩn và Công nghệ Quốc gia Mỹ (NIST AI Risk Management Framework) cũng khuyến nghị không nên áp dụng một cơ chế giám sát cào bằng cho toàn bộ quy trình. Tùy thuộc vào tác động của từng tác vụ, hệ thống cần phân định rõ: khâu nào AI được tự động hóa hoàn toàn, khâu nào chỉ đóng vai trò gợi ý dữ liệu, và khâu nào bắt buộc quyền quyết định cuối cùng phải thuộc về chuyên gia con người.

Ranh giới xuất hiện khi quy trình bắt đầu tạo hậu quả

Quay lại trường hợp ticket tài khoản lúc 9 giờ 12 phút. Nếu AI gắn nhãn sai danh mục, hậu quả lớn nhất là ticket bị chuyển chậm vài phút hoặc đến nhầm hàng chờ của nhóm hỗ trợ khác. Đây là sai sót cần ghi nhận vào log để cải thiện prompt, nhưng hoàn toàn có thể khắc phục nội bộ mà không gây thiệt hại. Tương tự, một bản nháp trả lời dù viết sai thông tin vẫn chưa gây hậu quả nếu nó mới chỉ nằm trong màn hình soạn thảo của nhân viên hỗ trợ.

Tuy nhiên, ranh giới an toàn sẽ bị phá vỡ khi workflow chạm đến ba nhóm hành động sau:

1. Phát ngôn chính thức ra bên ngoài: Khi email phản hồi được gửi thẳng đến hộp thư của khách hàng, tổ chức đã chính thức đưa ra cam kết về chính sách, bồi thường hoặc hướng dẫn kỹ thuật.
2. Biến đổi trạng thái hệ thống và dữ liệu: Khi tài khoản được mở khóa, cơ sở dữ liệu bị cập nhật, hoặc một container được lệnh khởi động lại trên cụm production.
3. Phát sinh giao dịch tài chính hoặc cấp phát tài nguyên: Khi hệ thống tự động hoàn tiền, cấp thêm hạn mức tín dụng hoặc kích hoạt các tài nguyên đám mây có tính phí.

Cổng phê duyệt của con người bắt buộc phải đặt ngay trước các ranh giới này.

Khả năng hoàn tác (reversibility) là thước đo quan trọng để xác định vị trí đặt cổng kiểm soát. Gắn một thẻ (tag) nội bộ vào ticket rất dễ gỡ bỏ nếu nhầm lẫn. Ngược lại, gửi một thông báo sai lệch cho hàng chục nghìn người dùng hoặc chạy lệnh xóa dữ liệu thì không thể cứu vãn bằng một nút "Hoàn tác" (Undo).

Tài liệu bảo mật ứng dụng LLM của OWASP xếp nguy cơ AI có quá nhiều quyền hạn và quyền tự chủ vào nhóm lỗi Excessive Agency (LLM06:2025). Biện pháp phòng vệ căn bản nhất mà OWASP khuyến nghị là áp dụng cơ chế xác nhận của con người trước khi thực thi các hành động nhạy cảm. Bạn không thể thay thế bước phê duyệt này bằng một thông báo thụ động dạng: "AI đã thực hiện xong lệnh mở khóa tài khoản, bạn có muốn hủy không?". Đó chỉ là một bản báo cáo đến muộn khi sự cố đã xảy ra.

Dữ liệu bắt buộc phải có trên màn hình phê duyệt

Một sai lầm phổ biến khi dựng giao diện duyệt là chỉ đưa ra duy nhất đoạn văn bản hoặc lệnh do AI sinh ra kèm hai nút bấm. Khi đối mặt với một đoạn kết quả cụt lủn, người vận hành buộc phải mở thêm tab khác để tra cứu ticket gốc, tìm log hệ thống hoặc đọc lại yêu cầu ban đầu của khách hàng. Thao tác chuyển đổi ngữ cảnh liên tục này khiến thời gian xử lý kéo dài và làm tăng tỷ lệ duyệt ẩu.

Để người duyệt ra quyết định chính xác trong vòng vài chục giây, giao diện duyệt cần cung cấp một bảng thông tin tổng hợp gồm bốn thành phần:

1. Ngữ cảnh đầu vào gốc (Raw input): Hiển thị câu hỏi của người dùng, nội dung ticket, hoặc đoạn log hệ thống cần phân tích. Người duyệt cần thấy rõ dữ liệu ban đầu là gì trước khi đánh giá AI hiểu đúng hay sai.
2. Cơ sở dữ liệu đối chiếu (Retrieved sources / Context): Nếu hệ thống dùng RAG, giao diện phải liệt kê cụ thể các đoạn tài liệu nội bộ, chính sách, hoặc bảng giá mà AI đã trích xuất để làm căn cứ suy luận.
3. Đề xuất hành động kèm điểm khác biệt (Proposed action & Diff): Hiển thị rõ AI dự định làm gì. Nếu là bài toán cập nhật dữ liệu hoặc chỉnh sửa file cấu hình, hãy dùng bảng so sánh trước và sau (diff view) để làm nổi bật các dòng thay đổi bằng màu trực quan.
4. Mức độ tin cậy và cảnh báo rủi ro: Đánh dấu rõ các tham số quan trọng (như số tiền, IP server, tên bảng cơ sở dữ liệu) và hiển thị cảnh báo nếu dữ liệu đầu vào chứa từ khóa nhạy cảm.

Mục tiêu của bảng thông tin này là gom toàn bộ dữ liệu cần thiết vào một góc nhìn duy nhất. Khi không phải lục lọi tìm kiếm tài liệu đối chiếu ở hệ thống ngoài, người duyệt có thể tập trung đánh giá tính hợp lý của hành động.

Thiết kế tùy chọn xử lý linh hoạt cho người vận hành

Nhiều hệ thống tự động hóa chỉ cung cấp hai lựa chọn cứng nhắc: Duyệt (Approve) hoặc Hủy (Reject). Thiết kế nhị phân này tạo ra sự bế tắc trong vận hành thực tế. Khi AI sinh ra một kịch bản phản hồi đạt 90% yêu cầu nhưng có một vài câu diễn đạt chưa chuẩn, nếu bấm Duyệt thì rủi ro cho hệ thống, còn nếu bấm Hủy thì toàn bộ công sức xử lý trước đó bị xóa bỏ, người vận hành phải tự viết lại từ đầu.

Một cổng phê duyệt hiệu quả cần cung cấp ít nhất bốn hướng xử lý:

• Chấp thuận thực thi (Approve & Execute): Áp dụng khi kết quả chính xác hoàn toàn. Hệ thống ghi log người duyệt và kích hoạt bước tiếp theo trong workflow.
• Chỉnh sửa trực tiếp rồi duyệt (Edit & Approve): Cho phép người duyệt sửa nhanh một vài câu từ hoặc tham số ngay trên giao diện rồi gửi đi. Dữ liệu sau khi sửa được lưu lại làm dữ liệu mẫu (golden dataset) để tinh chỉnh prompt hoặc huấn luyện mô hình sau này.
• Trả lại kèm yêu cầu điều chỉnh (Reject & Provide Feedback): Người vận hành ghi chú nhanh lý do (ví dụ: "chưa áp dụng chính sách hoàn tiền mới") để hệ thống chạy lại luồng suy luận với ngữ cảnh bổ sung.
• Tiếp nhận xử lý thủ công (Escalate to Human): Tách hẳn tác vụ ra khỏi quy trình tự động, phân công cho kỹ sư phụ trách xử lý hoàn toàn bằng tay khi phát hiện đây là ca phức tạp ngoài dự liệu.

Việc trao cho người vận hành quyền chỉnh sửa nhanh và định tuyến linh hoạt giúp quy trình không bị nghẽn ở những lỗi nhỏ, đồng thời giữ cho dữ liệu huấn luyện liên tục được cải thiện từ chính các thao tác điều chỉnh hàng ngày.

Biện pháp ngăn chặn tình trạng phê duyệt theo quán tính

Thách thức lớn nhất trong các hệ thống có con người can thiệp không nằm ở thuật ngữ kỹ thuật, mà nằm ở tâm lý người vận hành. Khi phải bấm nút duyệt hàng trăm yêu cầu mỗi ca làm việc và thấy 95% kết quả đều giống nhau, con người tự nhiên sẽ xuất hiện xu hướng duyệt lướt. Hành động bấm "Đồng ý" dần biến thành một phản xạ vô thức. Lúc này, cổng kiểm soát chỉ còn tồn tại trên danh nghĩa mà không ngăn chặn được sai sót thực tế nào.

Để duy trì sự tỉnh táo và trách nhiệm của người duyệt, bạn cần áp dụng các biện pháp kỹ thuật nhằm giảm bớt số lượng tác vụ tầm thường:

1. Phân tầng rủi ro để giảm số lượng ticket phải duyệt: Không bắt con người duyệt 100% mọi tác vụ. Hãy thiết lập ngưỡng tự động hóa cho các hành động có mức độ ảnh hưởng thấp. Ví dụ: tác vụ tổng hợp thông tin hoặc tạo bản nháp nội bộ có thể đi thẳng; chỉ những tác vụ ghi dữ liệu vào production, gửi email ra ngoài hoặc phân bổ ngân sách mới bắt buộc dừng lại qua cổng duyệt.
2. Áp dụng cơ chế lấy mẫu ngẫu nhiên (Sampling): Với các tác vụ có rủi ro trung bình, thay vì bắt duyệt toàn bộ, hệ thống có thể cho tự động thực thi nhưng chọn ngẫu nhiên 5% đến 10% kết quả để chuyển vào hàng chờ kiểm tra chất lượng hậu kỳ (post-audit). Người duyệt kiểm tra kỹ lưỡng một số lượng mẫu nhỏ sẽ phát hiện lỗi tốt hơn nhiều so với việc lướt qua hàng nghìn kết quả trong áp lực thời gian.
3. Cài đặt bẫy kiểm tra định kỳ (Attention check): Thỉnh thoảng chèn vào hàng chờ một vài mẫu kiểm tra có chủ đích (chứa lỗi sai lệch số liệu rõ ràng hoặc vi phạm chính sách) để đánh giá độ tập trung của người vận hành. Nếu người duyệt vẫn bấm chấp thuận các mẫu này, hệ thống sẽ cảnh báo về tình trạng mỏi mệt và đề xuất luân chuyển ca trực.
4. Giới hạn số lượng tác vụ trong một phiên làm việc: Đặt hạn ngạch tối đa một kỹ sư chỉ duyệt liên tục không quá 50 ticket hoặc trong 60 phút. Sau đó, tác vụ phải được tự động chuyển sang cho người khác để tránh tình trạng giảm sút sự tập trung.

Cơ chế dừng khẩn cấp khi phát hiện lỗi lặp lại

Trong quá trình vận hành, người duyệt không chỉ đóng vai trò chốt chặn cho từng ticket đơn lẻ mà còn là người đầu tiên phát hiện các dấu hiệu bất thường mang tính hệ thống. Nếu một mô hình AI bắt đầu đưa ra câu trả lời sai lệch liên tiếp do prompt bị lỗi, do dữ liệu RAG bị nhiễu hoặc sai lệch, hoặc do nhà cung cấp mô hình cập nhật phiên bản ngầm, việc người duyệt tiếp tục ngồi sửa từng lỗi một bằng tay là vô cùng lãng phí và nguy hiểm.

Hệ thống bắt buộc phải trang bị cho người duyệt quyền kích hoạt công tắc ngắt khẩn cấp (Kill-switch) ngay trên giao diện:

• Tạm dừng luồng tự động theo nhóm tác vụ: Khi thấy 3 ticket liên tiếp xuất hiện cùng một lỗi logic ngớ ngẩn hoặc trích xuất sai bảng giá, người duyệt có thể bấm nút tạm ngắt luồng AI tương ứng. Toàn bộ các yêu cầu mới sẽ tự động chuyển về trạng thái hàng chờ thủ công thông thường.
• Tự động chuyển về phiên bản ổn định (Fallback): Thiết lập cơ chế tự động chuyển đổi sang prompt phiên bản cũ hoặc sử dụng một bộ quy tắc logic cố định (rule-based) để xử lý tạm thời trong lúc đội ngũ kỹ thuật phân tích nguyên nhân.
• Ghi nhận sự cố kèm log chi tiết: Khi kích hoạt nút dừng khẩn cấp, hệ thống tự động gom lại 5 kết quả lỗi gần nhất, thông số phiên bản prompt và dữ liệu đầu vào để gửi thông báo khẩn qua kênh Telegram hoặc Slack của nhóm phụ trách hệ thống.

Quyền tạm dừng này bảo vệ hệ thống không bị lan truyền sai lệch trên diện rộng và đảm bảo mọi sự cố đều được đưa về tầm kiểm soát kỹ thuật ngay lập tức.

Định kỳ rà soát và dịch chuyển vị trí các cổng kiểm soát

Vị trí của các cổng duyệt trong workflow không phải là một thiết lập cố định vĩnh viễn. Khi hệ thống mới triển khai, việc đặt nhiều cổng kiểm soát dày đặc giúp đội ngũ vận hành thu thập dữ liệu và kiểm chứng độ tin cậy của AI. Tuy nhiên, nếu sau 3 tháng mà tỷ lệ người duyệt phải chỉnh sửa nội dung ở một bước nhất định dưới 0,5%, việc tiếp tục bắt con người dừng lại để bấm nút duyệt ở bước đó sẽ biến thành rào cản làm chậm toàn bộ tiến độ công việc.

Đội ngũ kỹ thuật cần tổ chức đánh giá định kỳ hàng tháng dựa trên ba chỉ số vận hành:

• Tỷ lệ can thiệp (Intervention rate): Phần trăm số tác vụ mà con người phải chỉnh sửa nội dung hoặc bấm từ chối. Nếu tỷ lệ này tiệm cận 0% trong hàng nghìn trường hợp liên tiếp trên một nhóm tác vụ ít rủi ro, bạn có thể tự tin chuyển cổng duyệt đó sang cơ chế lấy mẫu ngẫu nhiên hậu kỳ.
• Thời gian chờ duyệt (Approval latency): Đo lường khoảng thời gian tác vụ nằm chờ trong hàng đợi cho đến khi có người mở ra xem. Nếu thời gian chờ duyệt mất trung bình 4 tiếng trong khi thời gian AI xử lý chỉ mất 3 giây, nút thắt vận hành đang nằm ở con người. Lúc này cần cân nhắc chia nhỏ ca trực hoặc tinh giản số lượng tiêu chí duyệt.
• Tỷ lệ lọt lỗi (Escape rate): Số lượng sự cố phát sinh từ các tác vụ đã được người duyệt thông qua. Nếu con số này tăng lên, đó là dấu hiệu rõ ràng cho thấy người duyệt đang bị quá tải hoặc bảng thông tin trên giao diện thiếu dữ liệu đối chiếu quan trọng.

Quy trình tối ưu hóa này giúp hệ thống dần mở rộng phạm vi tự động hóa ở những phần việc an toàn, đồng thời tập trung năng lực chuyên gia vào đúng những khâu mang tính rủi ro cao.

Bài học từ tình huống ticket lúc 9:12

Quay trở lại tình huống được nêu ở đầu bài viết: nhân viên hỗ trợ bấm duyệt gửi kịch bản hoàn tiền 50% cho khách hàng lúc 9:12 và phát hiện lỗi 15 phút sau đó. Nguyên nhân cốt lõi không phải do nhân viên thiếu trách nhiệm, mà do quy trình thiết kế cổng duyệt bị hổng ba điểm then chốt:

1. Thiếu hiển thị điểm khác biệt (diff view): Giao diện chỉ hiển thị đoạn văn bản trả lời dài ba đoạn mà không làm nổi bật con số 50% kèm điều kiện kích hoạt.
2. Thiếu cơ sở đối chiếu: Màn hình duyệt không trích xuất bảng chính sách bồi thường tương ứng với gói dịch vụ của khách hàng, buộc nhân viên phải nhớ quy định hoặc tự tra cứu ngoài luồng.
3. Thao tác có tính quyết định nhưng không có bước xác nhận phụ: Việc xác nhận chi tiền đáng lẽ phải có một ô tích xác nhận riêng biệt hoặc bị chặn lại nếu số tiền bồi hoàn vượt quá ngưỡng cho phép của nhân viên trực ca.

Khi xây dựng lại quy trình, đội ngũ kỹ thuật chỉ cần bổ sung bảng so sánh chính sách ngay cạnh câu trả lời của AI và cài đặt cảnh báo đỏ khi phát hiện từ khóa "bồi thường" hoặc con số phần trăm. Sai sót tương tự sẽ được triệt tiêu mà không cần nhân viên phải căng thẳng đoán định.

Checklist kiểm tra thiết kế điểm duyệt trước khi đưa vào vận hành

Trước khi kết nối mô hình AI vào các quy trình thực tế của doanh nghiệp, hãy tự kiểm tra 5 tiêu chí kỹ thuật sau:

• ☐ Cổng duyệt được đặt ngay trước các hành động gây biến đổi dữ liệu (ghi database, gửi tin ra ngoài, gọi API có phí).
• ☐ Giao diện hiển thị đồng thời cả dữ liệu đầu vào gốc, kết quả AI đề xuất và tài liệu đối chiếu trích xuất từ hệ thống.
• ☐ Có tính năng so sánh trực quan (diff view) cho các tác vụ cập nhật cấu hình hoặc chỉnh sửa tài liệu.
• ☐ Cung cấp ít nhất 4 tùy chọn xử lý: Chấp thuận, Sửa rồi duyệt, Trả lại kèm phản hồi, và Chuyển xử lý thủ công.
• ☐ Trang bị công tắc ngắt khẩn cấp (kill-switch) cho người duyệt khi phát hiện chuỗi lỗi lặp lại có tính hệ thống.

Tài liệu tham khảo

1. Google Cloud Architecture Center (2025) - Designing Human-in-the-Loop workflows for Enterprise Generative AI Applications.
2. NIST AI Risk Management Framework (AI RMF 1.0) - Section 3: Govern and Map functions for Human-AI Interaction.
3. AWS Machine Learning Blog - Best practices for building efficient Human Review Workflows with Amazon Augmented AI.