Khi nói về AI Agent, một trong những hình dung dễ xuất hiện nhất là một hệ thống có thể tự nhận nhiệm vụ, tìm thông tin, sử dụng công cụ và hoàn thành công việc mà không cần con người tham gia. Nếu nhìn từ góc độ demo, mức độ tự chủ càng cao càng dễ tạo ấn tượng. Nhưng trong môi trường doanh nghiệp, câu hỏi quan trọng không phải là “AI có thể tự động đến mức nào?” mà là “AI nên được phép tự động đến mức nào?”
Một Agent có khả năng đọc email và chuẩn bị phản hồi là một chuyện. Một Agent có quyền gửi email trực tiếp cho khách hàng là một mức khác. Nếu Agent được phép cập nhật CRM, thay đổi trạng thái đơn hàng, phê duyệt yêu cầu hoặc thực hiện những hành động có tác động tài chính, mức độ rủi ro tiếp tục tăng.
Vì vậy, Human-in-the-loop không đơn giản là đặt một nhân viên ở cuối workflow để “kiểm tra AI”. Đó là cách doanh nghiệp thiết kế ranh giới trách nhiệm giữa AI, hệ thống và con người ngay từ đầu.
AI càng có khả năng hành động, câu hỏi về quyền kiểm soát càng quan trọng
Generative AI truyền thống chủ yếu tạo ra output. Người dùng đặt câu hỏi, AI trả lời và con người quyết định có sử dụng câu trả lời đó hay không. Trong mô hình này, một lớp kiểm soát tự nhiên vẫn tồn tại: AI tạo nội dung nhưng con người thực hiện hành động.
AI Agent làm thay đổi cấu trúc này. Một Agent có thể được kết nối với CRM, ERP, email, calendar, database, knowledge base hoặc các API nội bộ. Nó không chỉ tạo ra một câu trả lời mà có thể sử dụng kết quả đó để quyết định bước tiếp theo trong workflow.
Ví dụ, một Sales Agent có thể đọc meeting note, xác định action item, chuẩn bị follow-up email và cập nhật CRM. Một Customer Service Agent có thể đọc yêu cầu, tìm thông tin khách hàng, kiểm tra policy và chuẩn bị phương án xử lý. Một Back Office Agent có thể đọc tài liệu, lấy dữ liệu cần thiết rồi chuyển hồ sơ sang bước tiếp theo.
Khả năng hành động này chính là điều khiến AI Agent có thể tạo ra nhiều giá trị hơn một chatbot. Nhưng cũng chính nó khiến governance trở thành một phần của kiến trúc, chứ không phải vấn đề có thể xử lý sau khi PoC hoàn thành.
Không phải mọi hành động của AI đều có cùng mức độ rủi ro
Một cách đơn giản để thiết kế Human-in-the-loop là không hỏi “Có cần con người kiểm tra AI hay không?”, mà hỏi “Nếu bước này sai, hậu quả là gì?”
Nếu AI phân loại sai một email nội bộ, hậu quả có thể chỉ là yêu cầu được chuyển nhầm queue và mất thêm vài phút xử lý. Nếu AI chuẩn bị sai một email nhưng nhân viên vẫn phải review trước khi gửi, lỗi có thể được phát hiện trước khi ảnh hưởng đến khách hàng.
Nhưng nếu Agent tự gửi một cam kết thương mại không chính xác, thay đổi dữ liệu tài chính, phê duyệt một giao dịch hoặc thực hiện hành động khó đảo ngược, hậu quả có thể lớn hơn nhiều.
Vì vậy, mức độ kiểm soát nên tăng cùng với impact của hành động. Những thao tác dễ đảo ngược, phạm vi nhỏ và có khả năng kiểm tra tự động có thể được tự động hóa sâu hơn. Những hành động liên quan đến tiền, pháp lý, quyền truy cập, cam kết với khách hàng hoặc quyết định có ảnh hưởng lớn thường cần checkpoint rõ ràng hơn.
Human-in-the-loop vì thế nên được thiết kế theo risk, không theo một quy tắc chung rằng “AI luôn cần người kiểm tra” hoặc “AI Agent phải tự động hoàn toàn”.
Có nhiều mức độ tự động hóa hơn là chỉ “AI làm” hoặc “con người làm”
Trong thực tế, doanh nghiệp không cần lựa chọn giữa hai cực: AI chỉ đưa ra gợi ý hoặc AI tự động hoàn toàn. Một workflow có thể được thiết kế theo nhiều cấp độ.
Ở mức đầu tiên, AI chỉ Read & Suggest. Hệ thống đọc email, tài liệu hoặc dữ liệu rồi đưa ra phân loại, tóm tắt hoặc phương án đề xuất. Con người vẫn quyết định toàn bộ hành động tiếp theo. Đây thường là điểm bắt đầu phù hợp với những use case mới vì doanh nghiệp có thể quan sát chất lượng AI trong môi trường thực tế mà chưa trao quyền thực thi.
Mức tiếp theo là Prepare & Approve. AI không chỉ đưa ra gợi ý mà chuẩn bị gần như hoàn chỉnh hành động cần thực hiện: email đã được soạn, CRM update đã được chuẩn bị, hồ sơ đã được phân loại hoặc dữ liệu đã được điền. Con người chỉ cần kiểm tra và nhấn Approve. Cách này có thể giảm đáng kể thao tác thủ công mà vẫn giữ một checkpoint trước hành động quan trọng.
Sau khi hệ thống đã chứng minh được độ ổn định, một số trường hợp có thể chuyển sang Execute & Monitor. AI hoặc workflow tự động xử lý những case có rủi ro thấp và nằm trong phạm vi rõ ràng; chỉ exception mới được chuyển cho con người.
Mức độ tự động hóa vì vậy có thể tăng dần theo chuỗi:
Read → Suggest → Prepare → Approve → Execute → Monitor → Escalate.
Không phải workflow nào cũng cần đi đến cuối chuỗi này.
Human-in-the-loop tốt không có nghĩa con người phải kiểm tra mọi transaction
Nếu một hệ thống xử lý 10.000 yêu cầu mỗi tháng nhưng nhân viên vẫn phải đọc và approve cả 10.000 yêu cầu, doanh nghiệp chưa loại bỏ được bottleneck. AI có thể giúp chuẩn bị công việc nhanh hơn, nhưng khả năng scale vẫn bị giới hạn bởi số lượng approval của con người.
Do đó, mục tiêu dài hạn thường không phải Human reviews everything, mà là Human handles what requires human judgment.
Ví dụ, một Customer Service workflow có thể tự động xử lý những yêu cầu đơn giản, có policy rõ ràng và mức độ rủi ro thấp. Những trường hợp có khiếu nại nghiêm trọng, yêu cầu ngoại lệ, dữ liệu mâu thuẫn hoặc liên quan đến cam kết tài chính được chuyển cho nhân viên.
Tương tự, một hệ thống xử lý hồ sơ có thể tự động tiếp nhận, trích xuất và kiểm tra những trường cơ bản. Hồ sơ đủ điều kiện đi tiếp, còn những trường hợp thiếu dữ liệu, có mâu thuẫn hoặc vượt một threshold nhất định mới cần con người.
Human-in-the-loop hiệu quả vì vậy không phải thêm một bước approval vào mọi nơi. Nó là thiết kế đúng điểm mà con người cần xuất hiện.
Confidence score không nên là cơ chế kiểm soát duy nhất
Một cách tiếp cận phổ biến là cho AI tự động xử lý nếu confidence cao và chuyển cho con người nếu confidence thấp. Cơ chế này có thể hữu ích, nhưng không nên là yếu tố duy nhất quyết định quyền hành động.
Một output có confidence cao vẫn có thể sai. Quan trọng hơn, cùng một mức độ không chắc chắn nhưng hậu quả của lỗi có thể rất khác nhau.
AI phân loại sai một email marketing và AI xác định sai thông tin thanh toán không thể được đối xử giống nhau chỉ vì cùng có confidence 95%.
Doanh nghiệp cần kết hợp nhiều yếu tố: mức độ chắc chắn của hệ thống, loại hành động, giá trị giao dịch, loại dữ liệu, khả năng đảo ngược, đối tượng bị ảnh hưởng và các rule kinh doanh liên quan.
Một cách nhìn thực tế hơn là:
Automation Decision = Confidence + Risk + Business Rules + Permission + Context.
Confidence là một tín hiệu, không phải toàn bộ governance model.
AI cần biết khi nào mình không nên tiếp tục
Một Agent tốt không chỉ cần biết cách hoàn thành nhiệm vụ. Nó cũng cần có khả năng dừng lại khi điều kiện không đủ để tiếp tục an toàn.
Giả sử Customer Service Agent nhận một yêu cầu hoàn tiền. Agent có thể hiểu nội dung, kiểm tra lịch sử đơn hàng và tìm policy liên quan. Nếu yêu cầu nằm trong chính sách và giá trị dưới một ngưỡng nhất định, workflow có thể tiếp tục. Nhưng nếu khách hàng yêu cầu một ngoại lệ không có trong policy, dữ liệu giữa hai hệ thống mâu thuẫn hoặc giá trị vượt quyền xử lý, Agent nên dừng và escalation.
Tương tự, một Agent xử lý tài liệu không nên cố đoán một trường dữ liệu mà nó không thể xác định chắc chắn. Một Sales Agent không nên tự tạo ra điều khoản thương mại chỉ vì không tìm thấy thông tin trong CRM.
Khả năng nói “Tôi không có đủ thông tin để tiếp tục” đôi khi quan trọng không kém khả năng hoàn thành task.
Vì vậy, thiết kế Agent không chỉ cần success path. Nó cần cả stop condition, fallback và escalation path.
Escalation không nên chỉ là “chuyển cho con người”
Khi AI không thể xử lý một case, cách đơn giản nhất là chuyển case đó sang nhân viên. Nhưng nếu nhân viên phải bắt đầu điều tra lại từ đầu, doanh nghiệp đã bỏ phí phần lớn công việc mà hệ thống vừa thực hiện.
Một escalation tốt nên chuyển cả context.
Ví dụ, thay vì chỉ gửi:
“Case này cần xử lý thủ công.”
hệ thống có thể cung cấp: yêu cầu ban đầu của khách hàng, dữ liệu đã tìm thấy, policy đã tham chiếu, bước nào đã hoàn thành, điểm nào đang mâu thuẫn và lý do Agent quyết định dừng.
Người xử lý khi đó không phải đọc lại toàn bộ lịch sử. Họ bắt đầu từ đúng điểm mà automation không thể tiếp tục.
Đây là một chi tiết quan trọng khi thiết kế Human-in-the-loop. Mục tiêu không chỉ là có con người trong workflow, mà là giảm tối đa lượng công việc con người phải làm khi họ được đưa vào workflow.
Human-in-the-loop cũng giúp doanh nghiệp học từ những exception
Những case mà AI không xử lý được không chỉ là lỗi cần giải quyết. Chúng còn là dữ liệu để cải thiện hệ thống.
Nếu một Agent liên tục escalation cùng một loại trường hợp, doanh nghiệp có thể phân tích nguyên nhân. Có thể knowledge base thiếu policy. Có thể một API chưa cung cấp đủ dữ liệu. Có thể business rule chưa rõ. Có thể workflow đang có một bước chưa được chuẩn hóa.
Theo thời gian, exception có thể được phân nhóm và xử lý có hệ thống. Một số trường hợp trước đây cần con người có thể dần được tự động hóa khi doanh nghiệp đã bổ sung dữ liệu, rule hoặc integration cần thiết.
Quá trình này có thể được nhìn như một vòng lặp:
Automate → Observe → Escalate → Learn → Improve → Expand Automation.
Đây là cách mức độ tự động hóa tăng dựa trên dữ liệu vận hành thực tế thay vì dựa trên giả định ban đầu.
Human-in-the-loop không chỉ để kiểm soát lỗi của AI
Nếu chỉ xem con người như “người kiểm tra AI”, doanh nghiệp đang nhìn Human-in-the-loop quá hẹp.
Có những quyết định nên do con người thực hiện ngay cả khi AI có thể đưa ra một đề xuất hợp lý. Nguyên nhân không nhất thiết nằm ở độ chính xác kỹ thuật mà ở trách nhiệm, judgment và bối cảnh kinh doanh.
Một hệ thống có thể tổng hợp lịch sử của một khách hàng và đề xuất cách xử lý khiếu nại. Nhưng việc có chấp nhận một ngoại lệ cho khách hàng chiến lược hay không có thể liên quan đến mối quan hệ lâu dài mà dữ liệu không phản ánh đầy đủ.
AI có thể phân tích trạng thái của một dự án và chỉ ra những tín hiệu rủi ro. Nhưng quyết định thay đổi scope, bổ sung nhân sự hoặc đàm phán lại deadline còn liên quan đến nhiều yếu tố tổ chức.
Trong những trường hợp này, vai trò phù hợp của AI là decision support, không phải decision replacement.
Permission cần được thiết kế theo hành động, không chỉ theo dữ liệu
Khi nói đến AI security, doanh nghiệp thường tập trung vào câu hỏi Agent được đọc dữ liệu nào. Đây là phần quan trọng nhưng chưa đủ.
Một Agent có thể được phép đọc CRM nhưng không được chỉnh sửa. Một Agent khác được phép chuẩn bị CRM update nhưng cần người dùng approve trước khi ghi dữ liệu. Một Agent phục vụ một workflow cụ thể có thể được phép tự động cập nhật một số trường có rủi ro thấp nhưng không được thay đổi các trường quan trọng.
Do đó, permission có thể được nhìn theo các lớp Read → Suggest → Prepare → Execute.
Hai Agent cùng truy cập một nguồn dữ liệu không nhất thiết có cùng quyền hành động. Một Agent hỗ trợ Sales và một Agent xử lý Back Office có thể cần những scope hoàn toàn khác nhau.
Thiết kế permission theo action giúp doanh nghiệp tránh một sai lầm phổ biến: trao cho Agent quyền rộng hơn mức thực sự cần để hoàn thành nhiệm vụ.
Khả năng rollback cũng quyết định mức độ automation
Một yếu tố khác thường bị bỏ qua là khả năng đảo ngược hành động.
Nếu Agent thêm một draft note vào CRM và note đó có thể dễ dàng chỉnh sửa, mức độ rủi ro tương đối thấp. Nếu Agent xóa dữ liệu, gửi một cam kết ra bên ngoài hoặc thực hiện giao dịch tài chính, việc đảo ngược có thể khó hơn rất nhiều.
Do đó, khi quyết định một bước có thể được tự động hoàn toàn hay không, doanh nghiệp nên hỏi: Nếu hệ thống thực hiện sai, chúng ta có thể phát hiện và rollback nhanh đến mức nào?
Khả năng rollback tốt cho phép doanh nghiệp tự động hóa sâu hơn ở một số khu vực. Ngược lại, những hành động khó đảo ngược thường cần approval hoặc các lớp kiểm soát bổ sung.
Đây cũng là lý do cùng một Agent có thể được phép tự động thực hiện một số hành động nhưng chỉ được chuẩn bị đề xuất cho những hành động khác.
Audit log là một phần của Human-in-the-loop
Nếu AI tham gia vào một business process, doanh nghiệp cần biết hệ thống đã làm gì.
Agent đã truy cập nguồn dữ liệu nào? Nó sử dụng thông tin nào để đưa ra đề xuất? Tool nào đã được gọi? Hành động nào được thực hiện? Người nào đã approve? Trường hợp nào được escalation?
Không phải mọi use case đều cần mức audit giống nhau, nhưng nguyên tắc chung là những hành động càng quan trọng thì khả năng truy nguyên càng cần rõ ràng.
Điều này đặc biệt quan trọng khi một workflow có nhiều thành phần: AI Agent, API, business rules, automation platform và con người. Nếu xảy ra lỗi nhưng doanh nghiệp không thể xác định bước nào tạo ra lỗi, việc vận hành và cải thiện hệ thống sẽ rất khó khăn.
Human-in-the-loop vì vậy không chỉ là nút Approve trên giao diện. Nó nằm trong một hệ thống kiểm soát rộng hơn gồm permission, logging, monitoring, escalation và accountability.
Đừng đo thành công bằng tỷ lệ “không cần con người”
Một dự án AI Agent có thể dễ bị đặt KPI như: “80% case phải được AI xử lý hoàn toàn.”
Con số này có vẻ hấp dẫn nhưng có thể dẫn đến thiết kế sai. Nếu doanh nghiệp cố tăng automation rate bằng mọi giá, hệ thống có thể được trao quyền xử lý những trường hợp mà con người thực ra nên tham gia.
KPI phù hợp hơn phụ thuộc vào workflow. Doanh nghiệp có thể đo thời gian xử lý trung bình, số thao tác thủ công trên mỗi case, thời gian nhân viên dành cho case tiêu chuẩn, tỷ lệ rework, tỷ lệ escalation, chất lượng output hoặc thời gian từ khi case phát sinh đến khi được xử lý.
Giả sử trước đây nhân viên mất 15 phút cho mỗi hồ sơ. Sau automation, AI chuẩn bị 90% thông tin và nhân viên chỉ cần ba phút để kiểm tra những điểm quan trọng. Workflow vẫn có con người, nhưng effort đã giảm đáng kể.
Đó vẫn có thể là một kết quả tốt hơn nhiều so với việc cố loại bỏ con người hoàn toàn.
Bắt đầu bằng một ma trận Risk × Autonomy
Trước khi đưa một Agent vào production, doanh nghiệp có thể phân loại các hành động theo hai câu hỏi: hành động này có tác động lớn đến đâu nếu sai, và Agent cần mức độ tự chủ bao nhiêu để tạo ra giá trị?
Những tác vụ có rủi ro thấp như tìm kiếm tài liệu, tóm tắt nội dung hoặc chuẩn bị draft thường có thể cho phép mức automation cao hơn. Những hành động có rủi ro trung bình có thể sử dụng mô hình Prepare → Human Approve → Execute. Các hành động có rủi ro cao nên giữ checkpoint rõ ràng hoặc chỉ sử dụng AI ở vai trò hỗ trợ.
Ma trận này không cần phức tạp. Giá trị của nó nằm ở việc buộc đội dự án phải thảo luận về quyền hành động trước khi triển khai Agent, thay vì chỉ thảo luận về tính năng.
FDE cần thiết kế cả nơi AI hoạt động và nơi AI phải dừng
Nếu requirement chỉ là “Xây AI Agent xử lý Customer Service”, đội phát triển rất dễ tập trung vào success path: Agent nhận yêu cầu, tìm thông tin và tạo câu trả lời.
Nhưng khi đi vào workflow thực tế, FDE cần đặt thêm nhiều câu hỏi. Trường hợp nào Agent được tự xử lý? Khi nào cần approval? Dữ liệu nào được truy cập? Nếu hai nguồn mâu thuẫn thì làm gì? Nếu API lỗi thì sao? Nếu không tìm thấy policy phù hợp thì sao? Nếu khách hàng yêu cầu ngoại lệ thì chuyển cho ai?
Những câu hỏi này không nằm ngoài AI development. Chúng chính là phần quyết định Agent có thể đi từ demo sang production hay không.
Một workflow tốt vì vậy không chỉ mô tả:
AI làm gì khi mọi thứ diễn ra đúng.
Nó còn phải mô tả:
AI làm gì khi không chắc chắn, khi dữ liệu thiếu, khi hệ thống lỗi và khi tình huống vượt khỏi phạm vi được phép.
Đây cũng là nơi FDE đóng vai trò kết nối giữa business operation và engineering: không chỉ xây khả năng cho AI, mà xác định ranh giới để khả năng đó có thể được sử dụng an toàn trong công việc thực tế.
AI Agent tốt không phải Agent làm được mọi thứ
Khi đánh giá một AI Agent, mức độ tự chủ cao không tự động đồng nghĩa với chất lượng cao.
Một Agent tốt là Agent biết nhiệm vụ của mình, có đúng dữ liệu và công cụ cần thiết, hoạt động trong phạm vi quyền được cấp, có thể hoàn thành những case phù hợp và biết dừng khi gặp tình huống vượt khỏi phạm vi đó.
Trong môi trường doanh nghiệp, “biết khi nào không nên hành động” có thể quan trọng ngang với “biết cách hành động”.
Human-in-the-loop vì vậy không phải một giới hạn cần loại bỏ để AI trở nên hoàn thiện hơn. Trong nhiều workflow, nó là một phần chủ động của thiết kế hệ thống.
Mục tiêu cuối cùng không phải:
AI làm cànnhiều càng tốt.
Mà là:
AI xử lý phần phù hợp với AI, automation xử lý phần có thể xác định, và con người tập trung vào những quyết định thực sự cần judgment và accountability.
AI Agent của doanh nghiệp nên được tự động đến mức nào?
Nếu doanh nghiệp đã có một AI PoC nhưng vẫn chưa rõ Agent nên được phép đọc gì, hành động đến đâu, bước nào cần approval và trường hợp nào phải escalation, đây là vấn đề cần giải quyết trước khi mở rộng sang production.
Synora có thể cùng doanh nghiệp mapping workflow thực tế, phân loại action theo mức độ rủi ro và xác định ranh giới giữa AI Agent → Automation → Human Decision. Từ đó, PoC không chỉ chứng minh Agent “có thể làm được”, mà còn xác định Agent có thể được phép làm đến đâu trong môi trường vận hành thực tế.
Xác định ranh giới AI & Human trong workflow
Bắt đầu từ một workflow cụ thể và xác định bước nào AI có thể tự xử lý, bước nào cần approval và trường hợp nào phải chuyển cho con người.
Bắt đầu xác định- Đọc hóa đơn, trích xuất dữ liệuAI tự xử lý
- Đối chiếu với đơn đặt hàngAI tự xử lý
- Thanh toán trong hạn mứcCần approval
- Sai lệch hoặc nhà cung cấp mớiChuyển cho người