Phê duyệt tác tử AI: điểm duyệt, chứng cứ và phiên bản

Đăng ngày 27/10/2026

Một lần đồng ý phải gắn với một việc có thể kiểm

Phê duyệt tác tử AI chỉ có giá trị khi người duyệt biết chính xác điều gì sẽ xảy ra sau quyết định của mình. Một nút đồng ý đặt dưới đoạn giải thích dài không đủ cho biết hệ thống sẽ lưu bản nháp, gửi hồ sơ hay tạo lệnh chi. Trong đội tài chính, cùng một bộ chứng từ có thể đi qua nhiều quyết định khác nhau. Cần tách chúng trước khi chọn vị trí đặt người duyệt trong vòng lặp.

NIST AI RMF 1.0 đặt vai trò, trách nhiệm và cấu hình tương tác người với AI trong hoạt động quản trị rủi ro [1]. Khung này giúp đặt câu hỏi ai được quyết và ai chịu trách nhiệm theo dõi; nó không chứng nhận rằng thêm người duyệt sẽ tự làm hệ thống an toàn. Người duyệt vẫn cần thông tin phù hợp, thời gian và quyền từ chối thực chất. Đây là vấn đề tổ chức công việc cùng với thiết kế phần mềm.

Bài đề xuất hai công cụ: bản đồ điểm duyệt theo hậu quả và gói duyệt gắn với phiên bản. Ca đội tài chính soát dự thảo hoàn ứng tại Việt Nam là giả định. Mục tiêu được giới hạn ở kiểm dự thảo và chuyển đúng bước nội bộ, không tự chuyển tiền hay kết luận chứng từ hợp pháp. Mọi phép thử, chỉ số và điểm dừng dưới đây là đề xuất biên tập, chưa phải kết quả quan sát tại một doanh nghiệp.

Đọc bằng chứng về người duyệt trước khi thiết kế nút bấm

Nghiên cứu To Trust or to Think khảo sát các cách buộc người dùng cân nhắc trước khi theo gợi ý AI. Trong tác vụ lựa chọn thành phần bữa ăn với AI mô phỏng, một số can thiệp giảm việc theo lời gợi ý sai, nhưng có đánh đổi về cảm nhận thuận tiện [2]. Không thể chuyển kết quả ấy thành tỷ lệ giảm sai của kế toán Việt Nam. Điều cần thử là người duyệt có tự đối chiếu điểm quyết định hay chỉ đi theo đề xuất đã nổi bật.

Một nghiên cứu khác, Explanations Can Reduce Overreliance, chỉ ra vai trò của công sức và lợi ích khi người dùng kiểm lời giải thích. Các thí nghiệm dùng bài toán mê cung có kiểm soát, mức hậu quả thấp; tác giả nêu giới hạn khi suy rộng sang việc quan trọng [3]. Vì vậy, không nên kết luận lời giải thích luôn gây hại hoặc luôn giúp ích. Trong thiết kế thực tế, cần xem nó có làm chứng cứ dễ kiểm hơn hay chỉ khiến đề xuất có vẻ đáng tin hơn.

Từ hai nguồn ấy, câu hỏi thiết kế được thu hẹp: với một lỗi nghiệp vụ có thể phát hiện, giao diện hiện tại có giúp người duyệt nhận ra và xử lý đúng không? Chèn thêm một khoảng chờ không tự giải quyết việc thiếu chứng từ. Bắt gõ một câu xác nhận cũng có thể thành thao tác theo thói quen. Muốn đánh giá, phải có ca đề xuất sai đã biết, kết quả mong đợi và quan sát quyết định thật trong môi trường thử, thay vì chỉ hỏi người dùng có thích màn hình không.

Công cụ một: bản đồ điểm duyệt theo hậu quả

Bản đồ được đề xuất nối mỗi hành động với bốn câu hỏi: nó thay đổi gì, ảnh hưởng ai, còn sửa được bằng cách nào và ai có thẩm quyền quyết. Với hoàn ứng giả định, trích thông tin từ chứng từ để làm nháp khác với xác nhận số đề nghị. Chuyển hồ sơ sang hàng chờ khác với tạo lệnh thanh toán. Không gom tất cả thành một quyền phê duyệt AI, bởi người có thể sửa bản nháp chưa chắc được quyết một khoản chi.

Điểm duyệt nên nằm sau khi đã có đủ bản cụ thể để xem, đồng thời trước hành động gây hậu quả mà người ấy chịu trách nhiệm. Nếu xin duyệt quá sớm, người dùng đang đồng ý với một dự định chưa rõ đối tượng hoặc số tiền. Nếu xin quá muộn, thao tác cần kiểm đã xảy ra. Hãy thử vẽ đường công việc bằng tên hành động thật của hệ thống tài chính, rồi đánh dấu nơi dữ liệu trở thành yêu cầu chính thức hoặc được gửi cho bên khác.

Bản đồ cũng ghi việc nào có thể làm trong phạm vi đã giao mà không cần lặp lại câu hỏi. Đọc chứng từ được phép và chuẩn bị bảng đối chiếu có thể thuộc một nhiệm vụ đã được chấp thuận. Đổi người nhận, tài khoản hưởng hoặc loại hành động lại có thể vượt phạm vi đó. Các ranh giới phải do chủ quy trình xác định theo quyền hiện hành của đơn vị; bài viết không đặt hạn mức tiền hay thay quy định tài chính bằng một công thức chung.

Khi chưa xác định được hậu quả của một công cụ, giữ nó ở chế độ nháp hoặc đọc để tìm hiểu trước. Một thao tác có tên gửi nháp nhưng tự thông báo tới nhân viên vẫn có tác động giao tiếp thật. Ngược lại, thêm nút duyệt ở mọi thao tác đọc có thể làm người dùng khó nhận ra lúc quyết định quan trọng xuất hiện. Mục đích của bản đồ là làm rõ nghĩa của từng lần đồng ý và khoảng tự chủ đã được giao.

Công cụ hai: gói duyệt gắn với phiên bản

Gói duyệt được đề xuất gồm hành động sắp làm, đối tượng bị tác động, thay đổi so với hiện trạng, chứng cứ, giới hạn còn lại và mã phiên bản. Với hồ sơ hoàn ứng, màn hình cần nói rõ chỉ chuyển sang hàng chờ kiểm tiếp hay đã xác nhận một số đề nghị. Người duyệt phải thấy nơi nào AI suy diễn, nơi nào được lấy nguyên từ chứng từ và nơi nào còn thiếu, thay vì một đoạn kết luận trôi chảy che hết các mức chắc chắn.

Guidelines for Human-AI Interaction đề xuất hỗ trợ người dùng sửa, bỏ qua và làm rõ khi hệ thống chưa chắc về mục tiêu [4]. Trong ca giả định, điều này gợi ý thiết kế đường trả hồ sơ yêu cầu bổ sung, sửa một trường rồi xem lại thay đổi, hoặc dừng tác vụ. Đây là vận dụng biên tập từ hướng dẫn tương tác, không phải một mẫu giao diện đã được nghiên cứu xác nhận cho hoàn ứng. Khả năng sửa phải được kiểm cùng cách hệ thống ghi nhận phiên bản sau sửa.

Chứng cứ nên mở tới đúng trang hoặc mục liên quan trong nguồn mà người duyệt được phép xem. Nếu số đề nghị tổng hợp từ nhiều dòng, cần thấy các dòng nào được cộng và các dòng nào bị loại. Một bản tóm tắt thứ hai do cùng mô hình tạo không trở thành chứng cứ độc lập chỉ vì được đặt ở cột khác. Người duyệt cũng cần nhận ra bản scan không rõ, tài liệu bị thiếu hoặc ngày chứng từ khác với ngày mô hình đã đọc.

Giới hạn của gói duyệt phải hiển thị bằng việc cụ thể. Chẳng hạn, đã đối chiếu số trên tài liệu nhưng chưa kiểm trùng giữa các kỳ; đã tạo nháp nhưng chưa kiểm quyền người nhận ở hệ thống dưới. Khi thiếu một điều kiện bắt buộc do đơn vị xác định, gói phải chuyển sang cần bổ sung hoặc cần người xử lý. Không biến cảnh báo quan trọng thành dòng nhỏ bị bỏ qua dưới nút đồng ý, rồi coi việc người dùng bấm là đã chuyển hết trách nhiệm.

Người đề nghị và người quyết cần có vai trò rõ

Tác tử có thể chuẩn bị đề nghị, còn người có thẩm quyền quyết định phần việc thuộc vai mình. Tách hai vai này giúp người duyệt có chỗ đối chiếu căn cứ và yêu cầu sửa, thay vì bị đặt vào thế xác nhận kết luận đã được mặc định đúng. Trong tổ chức nhỏ, một người có thể kiêm nhiều nhiệm vụ, nhưng màn hình và dấu vết vẫn phải cho biết họ đang sửa dữ liệu, đề nghị hay quyết định chuyển bước. Đừng để cùng một nút mang cả ba nghĩa.

Một người duyệt có thể cần ý kiến chuyên môn từ người khác trước khi quyết. Khi ấy, hệ thống nên giữ rõ ý kiến tư vấn khác với quyết định cho phép thực thi. Việc đồng nghiệp nói bảng tổng hợp có vẻ hợp lý không nhất thiết cho phép gửi hồ sơ hoặc tạo lệnh chi. Nếu tổ chức có yêu cầu tách người lập và người duyệt, tích hợp phải kiểm quan hệ ấy bằng danh tính đã xác thực, không chỉ bằng tên người được mô hình ghi vào bản tóm tắt.

Nhật ký phù hợp có thể giữ mã hồ sơ, phiên bản gói, người quyết, loại quyết định, thời điểm và căn cứ cần thiết. Không cần sao chép mọi chứng từ riêng tư vào mọi hệ thống theo dõi. Người vận hành phải biết ai được xem dấu vết, giữ trong bao lâu và cách tìm lại khi phát hiện một gói đã chuyển nhầm. Đây là các lựa chọn thiết kế cần chủ dữ liệu phê chuẩn theo bối cảnh, không phải kết luận pháp lý về thời hạn lưu trữ.

Dữ liệu đổi thì lần duyệt cũ có thể mất hiệu lực

OWASP Transaction Authorization Cheat Sheet nêu nguyên tắc để người dùng xác nhận dữ liệu có ý nghĩa, kiểm phía máy chủ, và xử lý lại việc cho phép khi dữ liệu giao dịch thay đổi [5]. Áp dụng vào gói duyệt AI, lần đồng ý cần gắn với bản mà người dùng thực sự thấy. Nếu đối tượng, số đề nghị hoặc hành động đổi sau đó, hệ thống phải xác định việc duyệt lại theo chính sách; không lấy một dấu đồng ý cũ để cho chạy nội dung mới.

Không phải mọi thay đổi trình bày đều có cùng hậu quả. Sửa lỗi chính tả phần diễn giải có thể khác với đổi người nhận hoặc thêm dòng chi. Đội nghiệp vụ nên định nghĩa tập trường ảnh hưởng quyết định và kiểm xem hệ thống giữ được ràng buộc ấy không. Khi chưa phân loại chắc, giữ lại để người có trách nhiệm xem bản thay đổi. Mục đích không phải buộc duyệt lại mọi dấu cách, mà ngăn việc quan trọng được thêm sau khi người duyệt đã rời màn hình.

Thời gian cũng có thể làm gói hết phù hợp dù nội dung chưa sửa. Chính sách nội bộ, trạng thái nhân viên hoặc quyền của người duyệt có thể thay đổi trong lúc công việc chờ. Cần có điều kiện hết hạn và kiểm lại trước thực thi theo mức hậu quả đã chốt. Không tự đặt một khoảng thời gian chung cho mọi doanh nghiệp. Khi gói hết hạn, báo rõ cần cập nhật phần nào; đừng chỉ hiện lỗi mơ hồ rồi khuyến khích người dùng bấm lại để vượt qua.

Cơ chế chờ duyệt chưa thay kiểm quyền thực thi

Tài liệu deferred tools của Pydantic AI mô tả lời gọi cần duyệt, mã lời gọi và cách tiếp tục sau quyết định. Tài liệu đồng thời cảnh báo rằng dấu duyệt gửi từ ứng dụng khách không thay việc xác thực và kiểm quyền trong công cụ ở phía máy chủ [6]. Không nên chỉ nhận một trường đồng ý từ trình duyệt rồi cho thao tác nhạy cảm chạy. Ứng dụng phải biết ai đã quyết, cho bản nào và họ có quyền với hành động ấy tại lúc thực hiện không.

Đặc tả Tools của MCP phiên bản 2025-11-25 khuyến nghị khả năng con người từ chối lời gọi và hiển thị rõ công cụ, nhưng không bắt buộc một kiểu giao diện tương tác duy nhất [7]. Kết nối qua MCP vì thế không tự cung cấp quy trình duyệt hoàn ứng phù hợp đơn vị. Khi dùng một khung hay giao thức, cần kiểm phần nào nó cung cấp và phần nào ứng dụng vẫn phải làm: quản lý vai, phiên bản, hạn duyệt và bằng chứng thực thi là những câu hỏi riêng.

Tài liệu LangGraph về interrupts lưu ý rằng nút có thể chạy lại khi tiếp tục; thao tác gây tác dụng trước điểm ngắt cần được thiết kế để không tạo thay đổi lặp ngoài ý muốn [8]. Với gói chờ duyệt, đừng tạo một yêu cầu tài chính thật rồi mới ngắt để hỏi người dùng. Đặt điểm gây tác dụng đúng phía sau quyết định cần thiết, đồng thời kiểm cách thử lại, mã công việc và kết quả ở hệ thống dưới. Đây là giới hạn cần thử, không phải bảo đảm từ một ví dụ mã.

Tình huống giả định: soát dự thảo hoàn ứng

Giả sử một doanh nghiệp dịch vụ tại Việt Nam muốn trợ lý gom các tài liệu được phép từ một hồ sơ, đọc thông tin và chuẩn bị dự thảo hoàn ứng cho đội tài chính. Nhân viên vẫn chịu trách nhiệm cung cấp tài liệu, người được phân công kiểm dự thảo, và quyết định thanh toán ở quy trình riêng. Trợ lý chưa có công cụ chuyển tiền. Đây là ví dụ thiết kế để kiểm cách duyệt, không phải mô tả khách hàng thật hoặc khẳng định về tính hợp lệ của một bộ chứng từ.

Trợ lý tạo bảng nháp kèm liên kết nguồn, đánh dấu một dòng chưa đọc rõ và một khoản có thông tin gần giống hồ sơ cũ. Màn hình không nên tự kết luận gian lận hay hợp lệ. Người kiểm có thể xem nguồn, yêu cầu bổ sung hoặc trả lại phần chưa rõ. Nếu đồng ý chuyển nháp tới bước kiểm tiếp, gói duyệt phải ghi đúng hành động ấy. Không dùng chữ phê duyệt chung khiến nhân viên hiểu rằng số tiền đã được chấp thuận hoặc hồ sơ đã hoàn tất.

Sau khi người kiểm đồng ý bản đầu, một tài liệu bổ sung làm số đề nghị thay đổi. Hệ thống tạo bản mới, hiển thị phần khác và yêu cầu quyết định phù hợp lại trước khi chuyển. Nếu thao tác chuyển đã được đưa vào hàng đợi, nơi xử lý phải kiểm bản đang chạy còn khớp bản đã duyệt. Không chỉ làm mới màn hình trong khi một tiến trình nền vẫn giữ bản cũ. Hai nơi cần cùng hiểu dấu duyệt gắn với phiên bản nào và điều kiện nào làm nó hết hiệu lực.

Một nhánh khác là người duyệt từ chối vì thiếu tài liệu, nhưng tác tử cho rằng có thể sửa cách diễn giải để đạt yêu cầu. Nó có thể chuẩn bị lại theo phần được giao, song không được biến từ chối thành một vòng gửi lại tự động tới người khác để tìm người đồng ý. Lý do từ chối cần trở thành điều kiện phải giải quyết. Chỉ khi có thông tin hoặc thẩm quyền mới phù hợp, gói mới mới đi tiếp theo quy trình rõ; lịch sử trước đó vẫn phải truy lại được.

Đo chất lượng duyệt cùng thời gian và công sức

Số lần bấm đồng ý cho biết khối lượng tương tác, chưa cho biết quyết định có đúng. Bộ đo đề xuất tách ca đề nghị sai bị phát hiện, ca đúng bị trả không cần thiết, ca đổi phiên bản bị chặn và ca quyết định không đủ thẩm quyền lọt qua. Mỗi mẫu cần có căn cứ nghiệp vụ được người phụ trách xác định trước. Không dùng toàn bộ đề nghị bị trả làm nhãn AI sai, vì có trường hợp người duyệt cần thêm dữ liệu chưa có ngay từ đầu.

Thời gian xử lý cũng cần chia thành chờ tới lượt, xem chứng cứ, sửa thông tin và tiếp tục thực thi. Giảm thời gian người nhìn màn hình có thể đi kèm nhiều lỗi bị bỏ qua; kéo dài thời gian lại có thể chỉ do giao diện khó dùng. Đặt chất lượng cạnh công sức giúp tìm đúng chỗ sửa. Ví dụ, đường dẫn nguồn mở đúng dòng có thể giảm thao tác tìm mà vẫn giữ kiểm tra thực chất, trong khi một giải thích dài hơn có thể không giải quyết được nguồn thiếu.

Khi so sánh hai giao diện, cần giữ tác vụ, thành phần hồ sơ và cách xác định kết quả đủ tương đồng để diễn giải. Hỏi mức hài lòng có ích nhưng phải đứng cạnh việc người dùng phát hiện được lỗi nào. Nếu chỉ có thử nội bộ ít mẫu, ghi giới hạn ấy và giữ quyết định mở rộng có điều kiện. Không chuyển một lượt diễn tập thành lời khẳng định người duyệt đã đáng tin ở mọi loại hồ sơ, mọi ca trực và mọi thời điểm cao tải.

Phép thử trước khi mở bước gây hậu quả lớn hơn

Đội nhỏ có thể bắt đầu với nháp và một người nghiệp vụ có thời gian đối chiếu từng gói. Đơn vị nhiều phòng ban cần thêm ánh xạ vai, người thay thế khi vắng mặt và cách giải quyết hồ sơ chờ quá lâu. Khi không có người đủ thẩm quyền trực, giữ trạng thái chờ hoặc bàn giao theo quy định nội bộ đã có. Không tự đổi sang duyệt mặc định sau một khoảng im lặng chỉ để hàng chờ trông gọn hơn.

Bộ thử nên có nháp đúng, sai có thể phát hiện, nguồn thiếu, người duyệt không đủ quyền và gói đã hết hạn. Thêm các ca đổi đối tượng hoặc số đề nghị ngay sau khi đã đồng ý, rồi thử tiếp tục từ hàng đợi. Kỳ vọng là chặn đúng bản không còn được duyệt và không làm mất gói đang chờ hợp lệ. Dùng dữ liệu thử được phép, không gửi khoản tiền thật hay hồ sơ cá nhân thật chỉ để chứng minh một nút hoạt động.

Kiểm cả đường từ chối, sửa và sự cố. Người dùng trả hồ sơ thì tác tử phải dừng hành động đang xin phép; sửa trường quan trọng phải tạo bản để xem lại; mạng mất sau thực thi phải báo trạng thái chưa rõ nếu chưa xác minh. Người vận hành cần truy tới kết quả ở hệ thống giữ hồ sơ. Một thông báo tác tử nói đã gửi không thay biên nhận của nơi nhận, và việc người duyệt bấm lần nữa không nên tự tạo thêm một yêu cầu giống hệt.

Dừng mở rộng khi người không đủ quyền vẫn cho chạy, dấu duyệt dùng được cho bản khác hoặc người kiểm không thấy chứng cứ quyết định. Khắc phục tại lớp vai, dữ liệu gói hoặc thực thi rồi kiểm lại nhánh bị ảnh hưởng. Mở rộng chỉ khi chủ quy trình hiểu phần đã thử và phần còn giới hạn. Mức tự chủ phù hợp là phần việc có điều kiện rõ, có người tiếp nhận ngoại lệ và có bằng chứng về tác dụng thực, không phải số nút đã được gỡ khỏi giao diện.

Hỏi đáp về phê duyệt tác tử AI

Có cần hỏi lại sau mỗi lời gọi công cụ không? Không có một số lần chung phù hợp mọi tác vụ. Chủ quy trình cần chốt khoảng công việc đã giao và điểm hành động gây hậu quả cần quyết định riêng. Các thao tác chuẩn bị trong phạm vi có thể đi cùng nhau; đổi đối tượng, quyền hoặc tác dụng phải được xử lý theo ranh giới đã chốt. Thêm câu hỏi liên tục chưa chắc giúp người dùng nhận ra lúc cần kiểm kỹ.

Người duyệt sửa một trường thì có phải xem lại toàn bộ không? Cần xác định trường ấy ảnh hưởng quyết định nào và phần kiểm nào còn dùng được. Đổi số đề nghị, người nhận hoặc hành động có thể làm gói cũ mất hiệu lực; lỗi chính tả có thể ít ảnh hưởng hơn. Hệ thống phải hiển thị thay đổi và kiểm ràng buộc phiên bản theo chính sách. Khi chưa biết mức ảnh hưởng, bàn giao cho người phụ trách thay vì âm thầm giữ dấu đồng ý cũ.

Có thể dùng AI khác để duyệt thay người không? Có thể dùng một bộ kiểm hỗ trợ trong phạm vi đã xác định, nhưng kết quả của nó cần được đánh giá riêng. Nó không tự có thẩm quyền nghiệp vụ chỉ vì được gọi là người duyệt. Nếu hai mô hình dùng cùng dữ liệu thiếu hoặc cùng cách suy luận sai, việc chúng đồng ý chưa thành chứng cứ độc lập. Quyền quyết định và trách nhiệm khi có ngoại lệ vẫn cần được chủ quy trình giao rõ.

Làm sao biết người dùng không chỉ bấm theo thói quen? Cần thử bằng ca có lỗi đã biết trong môi trường kiểm, quan sát khả năng phát hiện, cách xử lý và công sức tìm chứng cứ. Không suy từ tốc độ bấm hoặc mức hài lòng sang chất lượng. Có thể thử cho người kiểm nhận định một điểm trước khi xem đề xuất AI, nhưng phải đo hiệu quả và gánh nặng thực tế. Không áp một thủ thuật giao diện từ nghiên cứu khác rồi coi như đã giải quyết việc quá tin AI.

Nguồn, phương pháp và giới hạn suy luận

Bài có hỗ trợ AI, dựa trên tám nguồn gốc đã đọc ngày 27/10/2026: nghiên cứu tương tác người với AI, NIST, OWASP và tài liệu chính thức của các khung phần mềm. Phiên bản, phần đọc và giới hạn ghi trong hồ sơ nguồn. Hai công cụ thiết kế, ca hoàn ứng và phép thử là tổng hợp biên tập giả định; chưa thử thực địa, chưa đo năng suất và không thay quy trình tài chính, thẩm định chuyên gia hoặc tư vấn pháp lý. Tài liệu nhà cung cấp được dùng để hiểu cơ chế, không làm bằng chứng hiệu quả độc lập.