AI làm đúng hôm nay, ngày mai còn đáng tin?

NGHIÊN CỨU & ỨNG DỤNG · BÀI 02

Kiểm chứng hành vi AI sau thay đổi tại Odin Lab Bank

Một trợ lý AI được kiểm tra kỹ trước khi sử dụng vẫn cần được theo dõi sau đó. Khi mô hình, chỉ dẫn hoặc tài liệu thay đổi, ngân hàng cần bằng chứng cho thấy AI tiếp tục hỗ trợ đúng công việc và giữ được giới hạn đã duyệt. Bài viết đề xuất cách kiểm chứng điều đó ở một thử nghiệm nhỏ tại Odin Lab Bank.

Quyền không đổi nhưng cách xử lý có thể đổi

Ở bài trước, Odin Lab phân tích AI được phép quan sát, đề xuất hay thực thi đến đâu. Giả sử giới hạn đã rõ: trợ lý ca trực chỉ đọc cảnh báo, tra cứu tài liệu và soạn bản nháp. Nó không được sửa cấu hình hay khởi động lại dịch vụ. Đây là điểm xuất phát hợp lý, nhưng chưa trả lời hết câu hỏi về chất lượng hỗ trợ.

Một bản cập nhật có thể khiến trợ lý bỏ sót điều kiện trong tài liệu, dẫn nguồn không phù hợp hoặc đưa khuyến nghị quá dứt khoát khi dữ liệu còn thiếu. Quyền gọi công cụ vẫn giữ nguyên, trong khi người vận hành nhận được đề xuất khác trước. Nếu con người làm theo mà không nhận ra sai lệch, giới hạn kỹ thuật của AI chưa đủ để bảo vệ quyết định vận hành.

Odin đề xuất duy trì hai loại bằng chứng song song: bằng chứng hành động bị giới hạn đúng, và bằng chứng đầu ra còn phù hợp với mục đích sử dụng. Cả hai cần được kiểm tra lại khi những thành phần ảnh hưởng hành vi thay đổi.

Việc kiểm chứng cần được kích hoạt khi thay đổi mô hình, chỉ dẫn, nguồn tài liệu, cách truy xuất, công cụ hoặc quyền sử dụng. Với cập nhật từ nhà cung cấp không được báo trước, dấu hiệu đầu ra thay đổi là lý do để kiểm tra lại. Kiểm tra sau thay đổi bổ sung cho việc theo dõi trong quá trình sử dụng; nó không thay thế giám sát thường xuyên.

Nguồn nghiên cứu gợi mở gì

Trong bài đăng trên ISACA ngày 11/09/2026, Eshaan Jain phân tích việc kiểm toán luồng tác nhân AI. Tác giả lưu ý sự biến thiên của đầu ra, phạm vi hành động liên hệ nhiều hệ thống và thay đổi từ nhà cung cấp. Các thủ tục được đề xuất bổ sung cho kiểm toán CNTT hiện có. Đây là bài phân tích chuyên môn, không phải một tiêu chuẩn kiểm toán riêng. [1]

Tài liệu ISACA ngày 15/09/2026 đề cập quản lý thay đổi, kiểm thử AI, bảo vệ tích hợp công cụ và giám sát. [2] NIST AI RMF 1.0, công bố tháng 01/2023, cung cấp bốn chức năng GOVERN, MAP, MEASURE và MANAGE để quản trị rủi ro AI. Đây là khung tự nguyện, không riêng cho ngân hàng. [3]

Từ các gợi mở này, Odin Lab phát triển tình huống và cách tổ chức hồ sơ dưới đây. Tên hồ sơ, bộ tình huống và quyết định thử nghiệm là đề xuất của Odin Lab; không phải yêu cầu nguyên văn hoặc mô hình được ISACA hay NIST chứng nhận.

OLB kiểm tra trợ lý ca trực sau một bản cập nhật

Tình huống OLB trong bài hoàn toàn giả lập, phục vụ nghiên cứu. Trợ lý hỗ trợ đội vận hành tổng hợp cảnh báo ngân hàng số và tạo bản nháp phiếu xử lý. Tài liệu đầu vào đã được duyệt; dữ liệu khách hàng và bí mật kỹ thuật nằm ngoài phạm vi thử nghiệm.

Đội phụ trách chuẩn bị cập nhật mô hình. Trước thay đổi, họ lưu cấu hình đang sử dụng và chọn các tình huống vận hành để làm mốc so sánh. Sau thay đổi, họ kiểm tra trên cùng dữ liệu giả lập và ghi nhận khác biệt. Mục tiêu không phải buộc AI viết giống từng câu; mục tiêu là xác định đề xuất có đúng căn cứ, đúng phạm vi và biết chuyển cho con người khi cần hay không.

Trong một tình huống giả lập, trợ lý nhận ba cảnh báo về dịch vụ ngân hàng số. Hướng dẫn xử lý chỉ áp dụng khi đội vận hành đã xác nhận thêm tình trạng của hệ thống phụ thuộc, nhưng thông tin này chưa có trong đầu vào. Đầu ra được chấp nhận phải nêu điều kiện còn thiếu, dẫn đúng hướng dẫn và đề nghị người vận hành kiểm tra tiếp. Nếu AI đề xuất ngay một thao tác dù chưa đủ căn cứ, người đánh giá ghi nhận đó là sai lệch nội dung. Cổng kiểm soát quyền phải chặn yêu cầu thực thi ngoài phạm vi, kể cả khi câu trả lời có vẻ thuyết phục.

Người phụ trách xem riêng chất lượng đề xuất và kết quả kiểm tra quyền. Một câu trả lời được diễn đạt tốt không bù cho việc vượt quyền; một yêu cầu bị chặn cũng không chứng minh phần phân tích trước đó đáng tin.

Vì chưa chạy thử nghiệm, bài viết không đưa ra tỷ lệ đạt hoặc kết luận phiên bản mới tốt hơn phiên bản cũ. Ví dụ trên xác định cách đánh giá: người rà soát kiểm tra điều kiện nghiệp vụ trong đầu ra, còn nhật ký công cụ xác nhận hệ thống có giữ giới hạn hành động hay không.

Một hồ sơ đủ để đối chiếu trước và sau

Odin đề xuất lập hồ sơ kiểm chứng cho mỗi đợt thay đổi có thể ảnh hưởng hành vi. Hồ sơ nên gọn, nối kết quả kiểm tra với phiên bản thực sự sử dụng. Nó không cần ghi lại suy luận nội bộ của mô hình; cần ghi các sự kiện quan sát được và kiểm tra độc lập được.

Phần phạm vi ghi nhiệm vụ, dữ liệu, công cụ và hành động bị cấm. Phần cấu hình ghi mã mô hình hoặc phiên bản khả dụng, chỉ dẫn, bộ tài liệu, quyền và thời điểm chạy. Phần kiểm tra giữ mã tình huống, đầu vào giả lập, điều kiện đủ hoặc thiếu và kết quả kỳ vọng.

Dấu vết xử lý ghi nguồn đã truy xuất, đầu ra, yêu cầu gọi công cụ, kết quả chặn hoặc cho phép và việc chuyển cho người xử lý. Cuối hồ sơ là sai lệch, mức tác động, người rà soát, biện pháp xử lý và quyết định tiếp tục sử dụng. Các phần được nối bằng mã lần xử lý để tránh ghép nhầm đầu vào của phiên này với đầu ra của phiên khác.

Nếu nhà cung cấp không cung cấp phiên bản cố định hoặc lịch sử cập nhật đủ chi tiết, hồ sơ phải ghi rõ giới hạn đó. OLB có thể lưu định danh mô hình được trả về, thời điểm kiểm tra và dữ liệu đối chiếu trong phạm vi thu thập được. Không nên tuyên bố đã tái lập đầy đủ một kết quả khi còn thiếu thông tin môi trường.

Nhật ký cần kiểm soát truy cập, bảo vệ tính toàn vẹn và lọc dữ liệu nhạy cảm. Thời gian lưu do tổ chức xác định theo nhu cầu và nghĩa vụ áp dụng, không mặc định dùng một con số chung cho mọi hệ thống.

Kiểm tra những lúc AI dễ hỗ trợ sai

Bộ thử nghiệm nên phản ánh công việc thực tế, đồng thời chủ động tạo điều kiện khó. Các tình huống sau là tiêu chí dự kiến của Odin cho OLB, chưa phải kết quả đạt được.

Với dữ liệu đầy đủ và tài liệu đúng phiên bản, trợ lý phải tóm tắt đúng và không bỏ sót điều kiện xử lý. Khi thiếu một điều kiện quan trọng, nó phải nêu dữ liệu thiếu thay vì biến giả định thành kết luận chắc chắn. Khi hai hướng dẫn mâu thuẫn, nó cần chỉ ra mâu thuẫn và chuyển người phụ trách xác nhận nguồn có hiệu lực.

Khi công cụ tra cứu không phản hồi, trợ lý phải thông báo giới hạn, không bịa nội dung hoặc nguồn. Khi tài liệu yêu cầu bỏ qua phê duyệt, nội dung đó không được trở thành quyền thực thi. Sau cập nhật mô hình, các tình huống cũ được kiểm tra lại theo điều kiện nghiệp vụ và giới hạn quyền đã duyệt.

Có thể chạy lặp những tình huống nhạy cảm để quan sát sự không ổn định. Số lần lặp và mức bao phủ phải tương xứng với tác động; không có số lượt chung bảo đảm an toàn. Bộ kiểm tra nhỏ giúp phát hiện lỗi đã biết, không chứng minh mọi đầu vào ngoài thực tế đều được xử lý đúng.

Khi so sánh theo thời gian, người đánh giá cũng cần xem đầu vào có thay đổi hay không. Việc tăng số đề xuất bị sửa có thể đến từ mô hình, tài liệu mới hoặc nhóm cảnh báo khó hơn. Kết luận nguyên nhân cần thêm kiểm tra thay vì chỉ dựa vào một tỷ lệ tăng giảm.

Từ kết quả kiểm tra đến quyết định sử dụng

Chủ giải pháp AI chuẩn bị hồ sơ; đội vận hành đánh giá độ phù hợp và mức hữu ích của đề xuất; chủ dịch vụ quyết định phạm vi tiếp tục sử dụng theo thẩm quyền. An toàn thông tin và quản lý rủi ro rà soát sai lệch liên quan đến quyền, dữ liệu và tác động. Kiểm toán nội bộ có thể đánh giá độc lập, không thay đội vận hành sở hữu kiểm soát.

Trước lần chạy đầu tiên, các bên thống nhất điều kiện chấp nhận: đề xuất có căn cứ từ tài liệu được duyệt; điều kiện thiếu hoặc mâu thuẫn được nêu rõ; yêu cầu ngoài quyền bị chặn; và dấu vết đủ để người khác kiểm tra lại. Một lỗi trọng yếu về quyền hoặc lộ dữ liệu không được bù bằng điểm tốt ở các tình huống khác. Sai lệch ít nghiêm trọng hơn cần có người chấp nhận, biện pháp giảm tác động và thời hạn đánh giá lại.

Nếu yêu cầu vượt quyền được thực thi hoặc dữ liệu ngoài phạm vi bị lộ, OLB ưu tiên ngăn tác động tiếp diễn và xử lý theo cơ chế sự cố. Nếu đầu ra giảm chất lượng nhưng vẫn bị giới hạn đúng, có thể thu hẹp chức năng, tăng kiểm tra của con người hoặc tạm dừng chức năng bị ảnh hưởng trong khi khắc phục. Quyết định cần nêu lý do và điều kiện đánh giá lại.

Quay về phiên bản cũ chỉ là một phương án khi nền tảng thực sự hỗ trợ và phiên bản đó còn được phép sử dụng. Với dịch vụ không cho khôi phục mô hình, cần phương án như tắt tích hợp, dùng quy trình thủ công hoặc chuyển sang cấu hình đã kiểm chứng. Không nên xây phương án phục hồi dựa trên khả năng chưa được xác nhận.

Các kết quả có thể theo dõi gồm đề xuất cần sửa đáng kể, yêu cầu ngoài phạm vi bị chặn, trường hợp thiếu dữ liệu được chuyển đúng và số thay đổi chưa có hồ sơ kiểm chứng. Mỗi chỉ tiêu cần định nghĩa, mẫu số và phạm vi rõ ràng. Ngưỡng xử lý do chủ dịch vụ phê duyệt theo tác động; một tỷ lệ đơn lẻ chưa đủ để kết luận kiểm soát có hiệu lực.

Bắt đầu từ một lần thay đổi cụ thể

OLB có thể bắt đầu bằng một trợ lý, một nhiệm vụ và một lần cập nhật. Đội phụ trách thống nhất điều kiện chấp nhận trước khi thử, lưu mốc ban đầu, chạy lại tình huống trọng yếu rồi lập quyết định. Cách làm này tạo hồ sơ có thể rà soát mà không đòi hỏi triển khai ngay chương trình kiểm toán AI toàn diện.

Đầu ra của đợt thử là một quyết định có người chịu trách nhiệm, nêu cấu hình được phép sử dụng, phạm vi áp dụng, sai lệch còn tồn tại và điều kiện kiểm tra lại. Khi tiếp tục sử dụng, đội vận hành vẫn rà soát bản nháp trước khi xử lý; thử nghiệm này chưa cho phép AI tự thực thi. Khi thu hẹp hoặc tạm dừng, hồ sơ phải chỉ rõ chức năng bị ảnh hưởng và cách chuyển công việc cho con người.

Bài trước trả lời AI được phép làm gì. Bài này bổ sung cách kiểm chứng rằng sau thay đổi, AI vẫn hỗ trợ đúng và giữ được giới hạn. Giá trị vận hành chỉ được duy trì khi tổ chức biết phiên bản nào đang dùng, sai lệch nào đang tồn tại và ai quyết định bước tiếp theo.

Nguồn tham khảo

[1] Eshaan Jain. Auditing Agentic AI Workflows: How to Control Test When the System Decides for Itself. ISACA Industry News, 11/09/2026. Nguồn phân tích chính. Đối chiếu 09/10/2026.

Đọc bài phân tích của Eshaan Jain trên ISACA

[2] ISACA. Cybersecurity Recommendations for Securing AI Agents. White paper, 15/09/2026. Nguồn đối chiếu về kiểm soát kỹ thuật và quản lý thay đổi. Đối chiếu 09/10/2026.

Đọc khuyến nghị bảo vệ tác nhân AI của ISACA

[3] NIST. Artificial Intelligence Risk Management Framework AI RMF 1.0. NIST AI 100-1, tháng 01/2023. DOI 10.6028/NIST.AI.100-1. Nguồn nền tảng, không phải tài liệu mới năm 2026. Đối chiếu 09/10/2026.

Tải NIST AI RMF 1.0 (PDF)

Bài trước của Odin Lab: AI được phép làm gì trong ngân hàng?

Đọc bài 01 — AI được phép làm gì trong ngân hàng?

Bài viết là phân tích và đề xuất ứng dụng của Odin Lab. Tình huống OLB và các tiêu chí thử nghiệm đều giả lập; không mô tả một ngân hàng thực tế và không hàm ý được ISACA hoặc NIST chứng thực.

Đọc tiếp tại Odin Lab

Bài tiếp theo: Nhà cung cấp bổ sung AI: Ngân hàng cần đánh giá gì trước khi sử dụng?

Chuyên mục Nghiên cứu & Ứng dụng

Odin Lab Bank

Đọc thêm về AI Governance, Risk & Audit