Kiểm toán AI: đánh giá liên tục và tái phê duyệt AI Agent

Kiểm toán AI không phải một lần chấm đạt hay không đạt trước khi đưa hệ thống vào sử dụng. Rủi ro của AI Agent đang vận hành thay đổi khi doanh nghiệp đổi mô hình, lời nhắc hệ thống, công cụ kết nối, quyền, dữ liệu tham chiếu hoặc quy trình nghiệp vụ. Doanh nghiệp cần trả lời được: kịch bản và cấu hình nào đã được đánh giá, ai đánh giá, dùng bằng chứng nào và ai tái phê duyệt phiên bản đó. Bài viết hướng dẫn doanh nghiệp tại Thái Lan nối đánh giá liên tục, tính độc lập, kiểm thử đối kháng, bằng chứng và cổng phát hành thành một quy trình quản trị thống nhất.

Kết luận trước: đơn vị kiểm toán là cấu hình nghiệp vụ, không chỉ là mô hình

Tên mô hình không đủ để tái lập phạm vi kiểm toán. Cùng một mô hình nhưng hậu quả rất khác giữa hệ thống hỏi đáp chỉ đọc và Agent mua hàng có thể tạo bản nháp đơn đặt hàng trong ERP. Cùng một bộ kết nối nhưng quyền đọc và quyền cập nhật tạo ra rủi ro khác nhau. Ngay cả khi mô hình không đổi, ảnh chụp dữ liệu mới có thể làm thay đổi kết quả truy xuất, căn cứ, ngôn ngữ và cách xử lý ngoại lệ.

Đơn vị đánh giá nên là:

kịch bản nghiệp vụ × công cụ × quyền × dữ liệu × phiên bản mô hình/lời nhắc

Xem tổ hợp này là một cấu hình có thể kiểm toán. Ghi chênh lệch giữa cấu hình gốc đã duyệt và bản ứng viên. Chênh lệch đó quyết định chỉ cần giám sát trong vận hành, phải kiểm thử hồi quy có mục tiêu, hay cần đánh giá độc lập bên ngoài. Cách làm này ngăn kết luận “mô hình không đổi nên không cần thử lại” khi phạm vi công cụ đã rộng hơn, hoặc “chỉ sửa lời nhắc” khi một điều kiện quan trọng đã biến mất.

Tính độc lập cũng không phải câu hỏi có thuê bên thứ ba hay không. Đưa mọi cập nhật hằng ngày ra ngoài là không thực tế, nhưng để nhóm phát triển tự phê duyệt mọi thay đổi ảnh hưởng cao lại tạo xung đột lợi ích. Hãy phân bổ ba tuyến theo rủi ro: nhóm phát triển tự đánh giá; nghiệp vụ và rủi ro phản biện ở tuyến hai; bên ngoài đánh giá độc lập ở tuyến ba.

Vì sao AI Agent đã qua nghiệm thu vẫn phải đánh giá lại?

Nghiệm thu vẫn cần thiết, nhưng chỉ chứng minh một cấu hình cụ thể đáp ứng yêu cầu với dữ liệu và điều kiện thử nghiệm đã xác định tại một thời điểm. Nó không chứng minh các phiên bản sau tương đương.

Nhà cung cấp có thể đổi hành vi hoặc tuyến chọn mô hình. Việc rút gọn lời nhắc có thể làm mất điều kiện biên. Bộ kết nối mới có thể lộ thêm thao tác. Chỉnh vai trò có thể mở rộng tập dữ liệu Agent được đọc. Dữ liệu chủ sản phẩm hoặc SOP mới có thể thay đổi căn cứ truy xuất. Mỗi thay đổi riêng lẻ trông nhỏ nhưng tổ hợp có thể thay đổi năng lực nghiệp vụ thực tế.

NIST AI RMF Core coi quản trị rủi ro là hoạt động liên tục trong vòng đời và nêu rằng hệ thống AI cần được kiểm tra trước khi triển khai cũng như đánh giá định kỳ khi vận hành. Measure 2.4 đề cập giám sát chức năng và hành vi của hệ thống cùng các thành phần trong môi trường vận hành. NIST Playbook cũng chỉ ra rằng bối cảnh vận hành, phân bố dữ liệu hoặc hành vi mô hình thay đổi là lý do phải xem lại thước đo và biện pháp kiểm soát.

Vì vậy, không chỉ chạy một bộ thử cố định theo lịch. Hãy kết hợp rà soát định kỳ với đánh giá khi có sự kiện. Ít nhất phải phân tích tác động khi có:

• thay đổi mô hình, tham số, tuyến chọn hoặc phương án dự phòng;
• thay đổi lời nhắc hệ thống, hàng rào, chính sách hoặc mẫu truy xuất;
• thêm, sửa hoặc xóa công cụ, API, máy chủ MCP hay môi trường chạy;
• thay đổi vai trò, phạm vi, người phê duyệt, cơ sở hoặc tập dữ liệu;
• cập nhật dữ liệu huấn luyện, dữ liệu RAG, dữ liệu chủ, quy định hoặc SOP;
• lỗi nghiêm trọng, nỗ lực vượt quyền, dừng không thành công, thiếu bằng chứng, khiếu nại hoặc sự cố suýt xảy ra; hoặc
• thay đổi trường hợp sử dụng, người bị ảnh hưởng, khu vực pháp lý hay nhà thầu.

Bảy cổng nghiệm thu AI Agent xử lý quyết định trước phát hành. Bài này bắt đầu ở giai đoạn sau: giữ cấu hình đã chấp thuận làm mốc, thử lại phần mà thay đổi có thể ảnh hưởng và tái phê duyệt cấu hình mới.

Lập sổ cấu hình có thể tái lập

Đánh giá liên tục cần một sổ đăng ký nối kết quả thử với cấu hình vận hành mà nó đại diện. Mục tiêu không phải tạo thêm danh mục tài sản chung, mà bảo đảm kết quả và quyết định có thể truy vết.

Kịch bản nghiệp vụ

Các nhãn như “dịch vụ khách hàng” hoặc “mua hàng” quá rộng. Xác định điều kiện bắt đầu, dữ liệu vào, kết quả bắt buộc, hành động cấm, ngoại lệ, điểm phê duyệt và trạng thái kết thúc. Ví dụ: “đọc yêu cầu báo giá đã duyệt, xác định nhà cung cấp phù hợp và tạo bản nháp đơn đặt hàng, nhưng không gửi.” Khi đó cả thành công và vượt quyền đều quan sát được.

Công cụ

Ghi phiên bản, nhà cung cấp, thao tác được phép, cấu trúc dữ liệu vào/ra, đích chạy, loại thông tin xác thực, thời gian chờ, thử lại và phương án dự phòng. Dù mã bộ kết nối không đổi, mô tả hàm mà Agent nhìn thấy thay đổi cũng có thể làm đổi cách chọn công cụ và phải nằm trong phạm vi.

Quyền

Không chỉ sao chép tên vai trò của người dùng. Xác định quyền đọc, tạo, cập nhật, gửi và phê duyệt; đơn vị, cơ sở, khách hàng, trạng thái đích; giới hạn giá trị hoặc thời gian; ngày hết hạn; thực hiện thay; người phê duyệt. Ghép mỗi trường hợp được phép với một trường hợp phải bị từ chối ngoài phạm vi.

Dữ liệu

Ghi mã và ảnh chụp của bộ dữ liệu hoặc chỉ mục, thời điểm trích xuất, ngôn ngữ, phạm vi, chủ sở hữu và kết quả kiểm tra chất lượng. Nếu không thể sao chép toàn bộ dữ liệu thật sang môi trường kiểm toán, vẫn cần giá trị băm của dữ liệu thử, điều kiện truy xuất, mã tài liệu nguồn và quy tắc che dữ liệu.

Phiên bản mô hình và lời nhắc

Gộp mã mô hình, cách cung cấp, tham số, lời nhắc hệ thống, mô tả công cụ, tuyến chọn, chính sách bộ nhớ, kiểm tra đầu ra và phiên bản chính sách thành một bản mô tả cấu hình. Tránh nhãn biến động như “mới nhất”; phải so được cấu hình đã thử với cấu hình đã mở dùng.

Chọn phạm vi thử lại từ chênh lệch thực tế

Thử lại mọi thứ sau mỗi chỉnh sửa sẽ làm chậm vận hành; không thử lại sẽ che rủi ro. Dùng thay đổi làm đầu vào cho quyết định tác động:

1. Xác định mọi thành phần cấu hình đã đổi.
2. Truy ngược kịch bản, công cụ, quyền và dữ liệu bị ảnh hưởng.
3. Xác định dạng sai hỏng và biện pháp kiểm soát liên quan.
4. Chọn kiểm thử hồi quy, kiểm thử đối kháng, xác nhận nghiệp vụ và kiểm tra bằng chứng cần thiết.
5. Gán tuyến đánh giá và người tái phê duyệt theo rủi ro.
6. Đặt điều kiện giám sát và quay lui sau khi triển khai.

Không phân loại độ lớn bằng số dòng mã. Một quyền mới có thể mở thao tác gửi trước đây không tồn tại. Sửa câu hiển thị có thể là thay đổi hạn chế nếu không ảnh hưởng thực thi, bằng chứng hoặc quyết định. Hãy đánh giá chênh lệch đối với ranh giới bị cấm, phạm vi tác động, khả năng phát hiện và khả năng phục hồi.

Nếu chưa biết Agent có làm được loại hành động mới không, tập dữ liệu đọc được hoặc mục tiêu ghi được có rộng hơn không, hay sự cố còn tái dựng được từ yêu cầu đến kết quả công cụ không, đừng gọi thay đổi là “nhỏ”. Hãy thiết kế đánh giá để giải quyết điều chưa biết.

Thiết kế đánh giá độc lập theo ba tuyến

NIST AI RMF Measure 1.3 nêu sự tham gia định kỳ của chuyên gia nội bộ không phải người trực tiếp phát triển và/hoặc người đánh giá độc lập. Nguyên tắc thiết kế NIST Dioptra mô tả thử bởi bên phát triển, thử trong quá trình mua hoặc tại phòng đánh giá, và thử bởi bên thứ ba cho kiểm toán hay tuân thủ; đồng thời nhấn mạnh khả năng tái lập và truy vết. Ba tuyến dưới đây là cách TOMAS TECH chuyển các ý đó thành quy trình doanh nghiệp, không phải sơ đồ tổ chức bắt buộc của NIST.

Tuyến một: nhóm phát triển và vận hành tự đánh giá

Nhóm hiểu thay đổi nhất thực hiện thử thành phần, thử lại kịch bản, kiểm tra ranh giới công cụ và xác nhận nhật ký. Điểm mạnh là nhanh và có ngữ cảnh kỹ thuật; điểm yếu là dễ bỏ sót giả định của chính mình và chịu áp lực tiến độ. Không nên đưa thay đổi ảnh hưởng cao vào vận hành chỉ vì nhóm xây dựng nói đã đạt.

Gói đánh giá phải có chênh lệch cấu hình, phân tích tác động, trường hợp và dữ liệu vào, kết quả mong đợi và thực tế, nhật ký lỗi, mục loại trừ, giới hạn đã biết, rủi ro còn lại và cách quay lui; không chỉ có biểu đồ thành công.

Tuyến hai: nghiệp vụ, rủi ro và chất lượng phản biện

Tuyến hai không viết lại hệ thống. Họ đặt câu hỏi liệu thành công nghiệp vụ đã được định nghĩa đúng, hành vi cấm đã được thử đủ, ngưỡng có bị nới để cho qua, và bằng chứng có tái dựng hành vi vận hành không. Chọn người từ chủ nghiệp vụ, an toàn thông tin, chất lượng, pháp chế, tuân thủ hoặc kiểm soát nội bộ theo tác động.

Mục tiêu không phải thu chữ ký mà là phản chứng độc lập. Thử yêu cầu mơ hồ, chỉ dẫn xung đột, dữ liệu cũ, ranh giới quyền, phê duyệt bị thu hồi, công cụ lỗi, công việc kéo dài và đổi ngôn ngữ. Theo dõi việc xử lý phát hiện và mang điểm chưa đóng tới cổng quyết định.

Tuyến ba: bên ngoài đánh giá độc lập

Dùng bên ngoài khi kịch bản có thể gây tác động đáng kể, có mức tự chủ cao, chịu quy định hoặc hợp đồng, có tầm quan trọng chiến lược, từng có sự cố nghiêm trọng, hoặc cần năng lực nội bộ chưa có. Nhãn “bên thứ ba” không tự tạo tính độc lập. RFP phải quy định ai thuê và trả phí, phạm vi tiếp cận, nơi báo cáo, cách quản lý xung đột lợi ích và ai xác minh khắc phục.

Ngày 18 tháng 9 năm 2026, Anthropic công bố hợp tác đánh giá nhúng với Accenture do Faculty dẫn dắt, bao gồm đánh giá mô hình, kiểm thử đối kháng, đánh giá sự phù hợp và kiểm thử biện pháp bảo vệ. Anthropic và Accenture mỗi bên dự kiến đầu tư ít nhất 1 tỷ USD trong 5 năm tới để xây dựng năng lực. Anthropic cũng nói phương thức này còn mới, chưa có chuẩn về quyền tiếp cận và cách báo cáo của người đánh giá, cũng chưa có mô hình tài trợ ổn định. Đây là bằng chứng đầu tư vào phản biện độc lập, không phải chuẩn phổ quát đã hoàn thiện. Nhà phát triển vẫn chịu trách nhiệm dù có người đánh giá ngoài.

Phân bổ ba tuyến theo rủi ro thay đổi

Đây là ví dụ vận hành, không phải tư vấn pháp lý hay phân loại chung. Nếu không dùng bên thứ ba, vẫn phải ghi lý do và người phê duyệt.

Thay một điểm “độ chính xác” bằng sáu chiều đánh giá

1. Tỷ lệ thành công nghiệp vụ

Đo kịch bản có đạt trạng thái kết thúc đã định nghĩa hay không: kiểm đủ dữ liệu vào, dùng đúng căn cứ, lấy phê duyệt và đạt trạng thái nghiệp vụ mong đợi. Phân biệt thành công một phần, chuyển cho người xử lý, hết thời gian và thực hiện trùng. Quản lý phiên bản tập kịch bản và bao gồm trường hợp bình thường, ngoại lệ, đa ngôn ngữ, thiếu dữ liệu, chỉ dẫn xung đột và công việc kéo dài.

2. Tỷ lệ hành động vượt quyền

Đo nỗ lực dùng công cụ, thao tác, đích, bộ dữ liệu, khung thời gian hoặc tuyến phê duyệt bị cấm. Quan sát cả hành động lọt qua và nỗ lực bị chính sách chặn. Nhiều lần bị chặn có thể chứng minh biện pháp hoạt động, nhưng cũng có thể cho thấy lời nhắc hoặc quy trình sai. Không được dùng trung bình để che một hành động bị cấm có hậu quả cao.

3. Tỷ lệ lỗi nghiêm trọng

Tách lỗi có thể ảnh hưởng trọng yếu đến khách hàng, tài chính, chất lượng, an toàn, pháp luật, riêng tư hoặc hợp đồng khỏi khác biệt văn phong và thiếu sót nhỏ. Định nghĩa mức nghiêm trọng, người phân xử, bằng chứng và cách khiếu nại trước khi chạy. Chỉ một số ít lỗi nghiêm trọng vẫn có thể dẫn tới HOLD hoặc STOP nếu khó phát hiện và khó phục hồi.

4. Dừng và phục hồi

Thử phát hiện, ngừng công việc mới, xử lý công việc đang chạy, thu hồi thông tin xác thực, cô lập hàng đợi, chuyển sang người xử lý, đối chiếu trạng thái và phê duyệt khởi động lại. Đây không chỉ là tắt tiến trình. Agent chạy dài có thể để lại kết quả dở dang, tác động bên ngoài, thử lại và giao dịch trùng.

OpenAI công bố Agents API ngày 10 tháng 9 năm 2026 dưới dạng thử nghiệm công khai (public beta). Trạng thái thử nghiệm này là giới hạn về độ trưởng thành; sản phẩm không phải chuẩn kiểm toán đã hoàn thiện. Các lời dẫn khách hàng trên trang ra mắt là ví dụ tiếp thị, không phải chuẩn so sánh trung lập hay bảo đảm hiệu năng. Điểm hữu ích là Agent có thể chạy dài với ngữ cảnh, công cụ và Agent phụ, nên đơn vị đánh giá phải gồm môi trường và công cụ. Xem thêm hướng dẫn vận hành Agents API.

5. Độ đầy đủ của bằng chứng

Xác định mỗi lần thử và sự kiện vận hành có nối được yêu cầu, dữ liệu vào, nguồn truy xuất, cấu hình, quyết định chính sách, lệnh công cụ, phê duyệt, kết quả, ngoại lệ, dừng và phục hồi hay không. Đầy đủ không có nghĩa chép mọi bí mật hoặc dữ liệu cá nhân vào nhật ký. Cần định bằng chứng tối thiểu, che dữ liệu, quyền tiếp cận, thời hạn lưu, đồng bộ thời gian, phát hiện sửa đổi và xuất hồ sơ.

NIST Dioptra mô tả khả năng tái lập qua ảnh chụp tài nguyên và khả năng truy vết qua lịch sử thử nghiệm cùng dữ liệu vào. Dù có dùng Dioptra hay không, hai thuộc tính này có thể trở thành yêu cầu mua sắm.

6. Kiểm thử hồi quy sau thay đổi

Không chỉ xác nhận tính năng mới hoạt động, mà còn xác nhận hành vi quan trọng, từ chối, dừng và ghi nhật ký đã từng đạt không bị hỏng. Dùng thành phần đã đổi để chọn kịch bản phụ thuộc; thêm sự cố và việc suýt xảy ra vào bộ hồi quy lâu dài. Giữ chênh lệch so với phiên bản trước vì tổng điểm không đổi có thể che một trường hợp tốt lên và một trường hợp xấu đi.

Bài viết không đặt ngưỡng chung. Tổ chức phải phê duyệt ngưỡng trước khi thử dựa trên tác động, mức rủi ro chấp nhận, hợp đồng, pháp luật và biện pháp kiểm soát.

Tích hợp kiểm thử đối kháng vào đánh giá liên tục

Kiểm thử đối kháng (red teaming) không nên là sự kiện duy nhất trước khi mở dùng. Cập nhật giả thuyết nguy cơ khi năng lực, kết nối hoặc mối đe dọa đổi. Kiểm thử hồi quy hỏi yêu cầu đã biết còn đúng không; kiểm thử đối kháng tìm đường bất ngờ qua ranh giới.

Phạm vi nên gồm chỉ dẫn gián tiếp trong tài liệu, mô tả công cụ mơ hồ, nhầm quyền, đầu độc bộ nhớ, giả nguồn gốc, mệt mỏi phê duyệt, đổi trạng thái giữa công việc dài, câu trả lời công cụ bị sửa, phương án dự phòng không an toàn và khoảng trống trách nhiệm giữa nhiều Agent. Đo cả phát hiện, ngăn chặn, cảnh báo, bằng chứng và phục hồi.

Định hướng AI 2026 của ETDA công bố ngày 9 tháng 6 năm 2026 nhấn mạnh AI Governance Testing và Red Teaming Challenge đầu tiên của Thái Lan. ETDA cho biết 12 bộ hướng dẫn/công cụ quản trị đã sẵn sàng và đang phát triển thêm 2 bộ trong năm 2026: AI Ethical Impact Assessment Playbook và AI Value Creation. Đây là hướng đi của hệ sinh thái Thái Lan, không phải nghĩa vụ pháp lý chung cho mọi doanh nghiệp. Thông báo nhấn mạnh tìm điểm yếu trước khi sử dụng; bài viết này mở rộng kỷ luật đó sang giai đoạn sau khi vận hành.

Tạo bằng chứng trong khi chạy, không phải ngay trước kiểm toán

Mỗi gói bằng chứng nên có:

• mã và phiên bản của kịch bản, mô hình, lời nhắc, chính sách, công cụ, API và môi trường;
• phạm vi quyền, thông tin xác thực, tuyến phê duyệt, ảnh chụp dữ liệu và điều kiện truy xuất;
• mã trường hợp, dữ liệu vào, kết quả mong đợi và thực tế, nguồn cùng chuỗi lệnh công cụ;
• quyết định chính sách, phê duyệt, từ chối, ngoại lệ, thời gian và mã liên kết;
• người chạy, người rà soát, người phê duyệt, lỗi, khắc phục, thử lại và điểm chưa đóng; và
• ngưỡng, kết quả sáu chiều, rủi ro còn lại, lý do cổng, điều kiện giám sát và quay lui.

Bằng chứng có thể chứa dữ liệu nhạy cảm. Nếu trao cho người đánh giá ngoài, quy định nơi xem, cách che dữ liệu, mang ra ngoài, thời hạn lưu, xóa và nhà thầu phụ trong RFP/hợp đồng. Tính độc lập cần đủ quyền để xác minh, không phải quyền sao chép không giới hạn.

Nối kết quả với GO / CONDITIONAL GO / HOLD / STOP

GO

Cấu hình được nêu đáp ứng ngưỡng, không còn phát hiện trọng yếu, bằng chứng đầy đủ, giám sát và phục hồi sẵn sàng. GO không phải quyền vô thời hạn; phải giới hạn theo phiên bản, kịch bản, phạm vi quyền và thời hạn.

CONDITIONAL GO

Rủi ro còn lại được công khai và có thể giữ trong mức chấp nhận nhờ biện pháp bù trừ có thời hạn, giảm phạm vi, tăng giám sát hoặc phê duyệt bởi người. Ghi từng điều kiện, chủ sở hữu, hạn hoàn tất và cách đóng. Không để điều kiện âm thầm thành phê duyệt lâu dài.

HOLD

Bằng chứng thiếu, lần thử không tái lập được, còn lỗi trọng yếu, không đạt ngưỡng hoặc rà soát độc lập chưa xong. Dừng phát hành và nêu rõ phải sửa gì, thử lại phần nào trước khi quyết định.

STOP

Ranh giới cấm bị vượt nghiêm trọng, rủi ro còn lại không chấp nhận được, dừng/phục hồi không hiệu lực hoặc độ tin cậy bằng chứng mất. Dừng cấu hình, thu hồi thông tin xác thực, chuyển sang thao tác thủ công và kích hoạt ứng phó sự cố phù hợp.

RFP kiểm toán AI nên yêu cầu gì?

RFP phải nói rõ đánh giá mô hình hay toàn bộ hệ thống nghiệp vụ, dùng kịch bản × công cụ × quyền × dữ liệu × phiên bản mô hình/lời nhắc làm đơn vị, bao gồm thử sau thay đổi và tái phê duyệt.

Về độc lập, hỏi người đánh giá có phát triển, bán, tích hợp hoặc vận hành hệ thống hay không. Quy định tách nhóm, tuyến báo cáo, thẩm quyền đối với phát hiện bất lợi và người xác minh khắc phục. Về dữ liệu, quy định quyền tiếp cận, dữ liệu mật/cá nhân, chuyển qua biên giới, nhà thầu phụ, nơi lưu, xóa, báo sự cố và quyền sở hữu sản phẩm bàn giao.

Về phương pháp, yêu cầu cách xây trường hợp, phân biệt kiểm thử hồi quy với kiểm thử đối kháng, cách lấy mẫu, mức nghiêm trọng, thử lại, xử lý bất đồng giữa người đánh giá, công cụ và quản lý phiên bản. Nếu chỉ đánh giá hộp đen, phải nói rõ điều gì chưa xác minh được.

Về kết quả, yêu cầu báo cáo riêng sáu chiều; không để điểm tổng hợp bù cho lỗi nghiêm trọng. Quy định quyền quyết định GO, CONDITIONAL GO, HOLD, STOP. Sản phẩm bàn giao cần có bản mô tả cấu hình, danh mục trường hợp, bản ghi thử, bằng chứng lỗi, bước tái lập, phát hiện, mức nghiêm trọng, khắc phục và kết quả thử lại, không chỉ là bản trình bày cho lãnh đạo.

Nếu yêu cầu bảng đối chiếu ISO/IEC 42001, NIST AI RMF hoặc pháp luật, bắt người đánh giá nêu văn bản gốc và phạm vi đã xem. Phần giới thiệu chính thức của ISO mô tả ISO/IEC 42001 là hệ thống quản lý theo Plan-Do-Check-Act để cải tiến liên tục và đề cập truy vết, minh bạch, đánh giá rủi ro, cơ chế kiểm toán. Bài này không xem nội dung tiêu chuẩn bản thương mại nên không tự tạo số điều khoản. Xem toàn bộ AIMS trong hướng dẫn ISO 42001.

Đọc EU AI Act Article 72 từ góc nhìn doanh nghiệp tại Thái Lan

Article 72 trong bản hợp nhất tiếng Anh ngày 27 tháng 7 năm 2026 yêu cầu nhà cung cấp hệ thống AI rủi ro cao thuộc phạm vi phải thiết lập và lập hồ sơ hệ thống theo dõi sau khi đưa ra thị trường, tương xứng với công nghệ và rủi ro. Hệ thống phải chủ động và có hệ thống thu thập, ghi, phân tích dữ liệu hoạt động liên quan trong suốt vòng đời để đánh giá việc đáp ứng liên tục; kế hoạch theo dõi là một phần của hồ sơ kỹ thuật.

Đây là ví dụ pháp lý cụ thể về giám sát vòng đời. Nó không có nghĩa Article 72 trực tiếp áp dụng cho mọi công ty Thái hoặc mọi AI Agent. Cần xem hoạt động tại thị trường EU, vai trò của doanh nghiệp, phân loại rủi ro cao và chuỗi sản phẩm/dịch vụ; xin tư vấn pháp lý khi cần. Ngay cả ngoài phạm vi, tư tưởng giám sát trọn đời, lập hồ sơ và kiểm tra liên tục vẫn hữu ích cho kiểm soát nội bộ.

Quy trình từ yêu cầu thay đổi đến tái phê duyệt

1. Đăng ký thay đổi và ảnh hưởng lên kịch bản, năng lực, dữ liệu, quyền, người dùng, khu vực pháp lý.
2. So bản mô tả đã duyệt với bản mới trên mô hình, lời nhắc, công cụ, quyền, dữ liệu và logic đánh giá.
3. Gán mức tác động và tuyến đánh giá theo khả năng phát hiện, phục hồi và biện pháp kiểm soát.
4. Chốt trường hợp, dữ liệu vào, kết quả mong đợi, ngưỡng, mức nghiêm trọng và môi trường trước khi thử.
5. Tách kiểm thử hồi quy, trường hợp từ sự cố trước và kiểm thử đối kháng.
6. Báo sáu chiều và ngoại lệ trọng yếu tách khỏi điểm trung bình.
7. Tách người phê duyệt khỏi người chạy; ghi phiên bản, hạn, giám sát và quay lui.
8. Đưa lỗi, can thiệp thủ công, nỗ lực vượt quyền và phản hồi người dùng vào sổ rủi ro.

Sai lầm thường gặp

• Chỉ kiểm tên mô hình và bỏ sót công cụ, quyền, dữ liệu, lời nhắc.
• Dùng tỷ lệ thành công cao để bù một hành động vượt quyền nghiêm trọng.
• Thuê ngoài trước khi nội bộ định nghĩa thành công và hành vi cấm.
• Tạo nhật ký khi kiểm toán thay vì ghi chuỗi quyết định lúc vận hành.
• Kiểm thử đối kháng hằng năm trong khi bề mặt tấn công thay đổi liên tục.
• Để phê duyệt có điều kiện tồn tại mãi không có chủ sở hữu, hạn và cách đóng.
• Đổi ngưỡng sau khi thấy kết quả, làm mất khả năng so sánh.

Danh sách kiểm tra thực hành

• [ ] Định đơn vị đánh giá là kịch bản × công cụ × quyền × dữ liệu × phiên bản mô hình/lời nhắc.
• [ ] Định cả lịch định kỳ và sự kiện phải đánh giá lại.
• [ ] Duyệt quy tắc ba tuyến và quản lý xung đột lợi ích.
• [ ] Duyệt định nghĩa, mẫu số, mức nghiêm trọng và ngưỡng của sáu chiều trước khi thử.
• [ ] Định thẩm quyền và ngoại lệ cho bốn cổng.
• [ ] Ghép trường hợp được phép với trường hợp phải từ chối.
• [ ] Thêm sự cố, việc suýt xảy ra và khiếu nại vào bộ hồi quy.
• [ ] Thử dừng, phục hồi, quay lui và tác động của việc thử lại.
• [ ] Tái dựng được chuỗi từ dữ liệu vào đến kết quả công cụ.
• [ ] Tách người đánh giá và người phê duyệt; ghi phiên bản, phạm vi, ngày hết hạn.

FAQ: kiểm toán AI và đánh giá AI Agent liên tục

Nên kiểm toán AI bao lâu một lần?

Không có một khoảng phù hợp mọi hệ thống. Kết hợp rà soát định kỳ với sự kiện từ thay đổi mô hình, lời nhắc, công cụ, quyền, dữ liệu, nghiệp vụ, khu vực pháp lý hoặc sự cố. Kịch bản tác động cao và thay đổi nhiều cần giám sát, đánh giá lại dày hơn.

Đánh giá liên tục khác nghiệm thu thế nào?

Nghiệm thu phê duyệt một cấu hình trước khi mở dùng. Đánh giá liên tục giữ cấu hình đó làm mốc, dùng quan sát vận hành và chênh lệch thay đổi để chọn thử lại rồi tái phê duyệt. Hai biện pháp nối tiếp nhau, không thay thế nhau.

Luôn cần đánh giá bên thứ ba không?

Không phải mọi thay đổi. Quyết định theo tác động, mức tự chủ, quy định/hợp đồng, lịch sử sự cố, năng lực nội bộ và xung đột. Nếu không dùng bên thứ ba, vẫn cần tuyến hai phản biện và ghi lý do.

Chỉ kiểm thử đối kháng có hoàn tất kiểm toán không?

Không. Kiểm thử đối kháng tốt để tìm đường tấn công bất ngờ nhưng không thay đánh giá thành công nghiệp vụ, lỗi nghiêm trọng, dừng/phục hồi, độ đầy đủ bằng chứng, hồi quy và phê duyệt.

Độ chính xác tốt hơn có đủ để tái phê duyệt không?

Không. Kiểm riêng vượt quyền, lỗi nghiêm trọng, dừng/phục hồi, bằng chứng và hồi quy. Mô hình chính xác hơn vẫn có thể gọi công cụ bị cấm, làm yếu ranh giới từ chối hoặc mất bằng chứng.

RFP kiểm toán AI nên làm rõ điều gì trước?

Làm rõ đơn vị đánh giá và tính độc lập: kiểm mô hình hay hệ thống nghiệp vụ, phiên bản/dữ liệu/quyền nào trong phạm vi, người đánh giá có phát triển hoặc bán giải pháp không. Sau đó quy định phương pháp, bằng chứng, bảo vệ dữ liệu, sáu chiều, bốn cổng và xác minh khắc phục.

Có ISO/IEC 42001 thì còn cần đánh giá liên tục cấp hệ thống không?

Có. Hệ thống quản lý cung cấp khung cải tiến liên tục, nhưng kịch bản và cấu hình đã đổi vẫn cần thử và bằng chứng riêng. Cũng phải so phạm vi chứng nhận với hệ thống AI thực tế.

Tóm tắt: nối kiểm toán AI với kiểm soát thay đổi và quyền phát hành

Đối tượng kiểm toán của AI Agent thay đổi khi mô hình, lời nhắc, công cụ, quyền hoặc dữ liệu thay đổi, dù đã qua nghiệm thu. Cố định đơn vị đánh giá là kịch bản nghiệp vụ × công cụ × quyền × dữ liệu × phiên bản mô hình/lời nhắc và chọn thử lại từ chênh lệch thật. Phân bổ tuyến phát triển, nghiệp vụ/rủi ro và bên ngoài theo tác động. Đánh giá riêng thành công nghiệp vụ, vượt quyền, lỗi nghiêm trọng, dừng/phục hồi, độ đầy đủ bằng chứng và hồi quy sau thay đổi. Nối kết quả với GO, CONDITIONAL GO, HOLD hoặc STOP, đồng thời ghi phiên bản, ngày hết hạn, giám sát và quay lui. Khi đó báo cáo kiểm toán mới trở thành biện pháp vận hành.

TOMAS TECH có thể hỗ trợ xây dựng chương trình kiểm toán AI và đánh giá liên tục từ RFP, sổ cấu hình, sự kiện đánh giá, trường hợp thử và gói bằng chứng tới tái phê duyệt. Có thể bắt đầu ngay khi doanh nghiệp nối nghiệm thu hoặc ISO 42001 hiện có với kiểm soát sau khi mở dùng.

Tài liệu tham khảo

• Anthropic, “Partnering with Accenture on embedded evaluation” (18/09/2026): https://www.anthropic.com/news/accenture-embedded-evaluation
• NIST, AI Risk Management Framework Core — Measure: https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
• NIST, AI RMF Playbook — Measure: https://airc.nist.gov/airmf-resources/playbook/measure/
• NIST, Dioptra Design Principles: https://pages.nist.gov/dioptra/explanation/dioptra-motivation/design-principles.html
• ISO, AI management systems: What businesses need to know: https://www.iso.org/artificial-intelligence/ai-management-systems
• European Union, AI Act consolidated text, Article 72 (27/07/2026): https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX%3A02024R1689-20260727
• ETDA, AI 2026 — Driving Trust AI Governance (09/06/2026): https://www.etda.or.th/th/pr-news/aigc_Driving-Trust_AI_Governance.aspx
• OpenAI, “Introducing the Agents API” (10/09/2026): https://openai.com/index/introducing-the-agents-api/

Bài viết là hướng dẫn vận hành chung dựa trên thông tin công khai được kiểm tra đến ngày 19/09/2026. Đây không phải tư vấn pháp lý, chứng nhận hay bảo đảm.