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

Từ góc nhìn ISACA đến kiểm soát dữ liệu, bằng chứng và quyết định tại Odin Lab Bank.

NGHIÊN CỨU & ỨNG DỤNG · BÀI 03 · ODIN LAB

Một nền tảng đã qua đánh giá không có nghĩa mọi tính năng bổ sung đều nằm trong phạm vi được phép sử dụng. Khi bật thêm AI, ngân hàng cần biết dữ liệu đi đâu, ai tham gia xử lý và trách nhiệm nào thay đổi. Bài viết đề xuất cách OLB đánh giá phần thay đổi trước khi cho dùng, đồng thời giữ được công việc đang vận hành.

Phê duyệt cần gắn với cách sử dụng cụ thể

Hai bài trước bàn về giới hạn quyền của AI và kiểm chứng hành vi sau cập nhật. Bài này đi thêm một bước: AI có thể được cung cấp qua một nền tảng bên ngoài mà ngân hàng đang sử dụng. Khi đó, chất lượng đầu ra và quyền gọi công cụ chỉ là một phần của quyết định. Ngân hàng còn cần xem xét phạm vi dữ liệu, chuỗi bên xử lý và khả năng tiếp tục công việc nếu tính năng mới gặp vấn đề.

Một quyết định ban đầu thường gắn với sản phẩm, mục đích, nhóm dữ liệu và điều kiện triển khai xác định. Bật thêm mô-đun có thể tạo luồng dữ liệu mới mà không thay đổi tên nhà cung cấp. Vì vậy, hồ sơ phê duyệt cần chỉ rõ điều gì đã được chấp nhận, thay vì chỉ ghi rằng nhà cung cấp nằm trong danh sách được duyệt.

Nghiên cứu gợi mở điều gì

Trong bài đăng trên ISACA ngày 04/05/2026, Gaudam Suriyakala Thiyagarajan và Nivathan Athiganoor Somasundharam đề xuất đánh giá rủi ro bên thứ ba theo bối cảnh sử dụng. Tác giả lưu ý việc mở rộng chức năng, thay đổi bên cung cấp phía sau và đường đi dữ liệu có thể làm thay đổi mức rủi ro giữa hai kỳ đánh giá. Đây là bài phân tích chuyên môn, không phải tiêu chuẩn bắt buộc. [1]

NIST CSF 2.0 cung cấp cơ sở đối chiếu: GV.SC-07 đề cập quản lý rủi ro trong suốt quan hệ với nhà cung cấp; GV.SC-08 đề cập sự tham gia của các bên liên quan trong ứng phó và phục hồi. [2] NIST SP 1305 hướng dẫn sử dụng nhóm GV.SC và truyền đạt yêu cầu với nhà cung cấp. [3]

Odin Lab chuyển các gợi mở này thành tình huống và cách ra quyết định dưới đây. Các điều kiện thử nghiệm, hồ sơ bằng chứng và lựa chọn xử lý là đề xuất của Odin Lab, không phải mô hình được ISACA hoặc NIST chứng nhận.

OLB bổ sung AI vào nền tảng xử lý phiếu

Trong tình huống hoàn toàn giả lập, OLB đã duyệt một nền tảng trực tuyến để tiếp nhận và phân công phiếu hỗ trợ CNTT. Nhà cung cấp đề xuất bật AI để tóm tắt nội dung và gợi ý phân loại. Mục tiêu là giảm thời gian đọc phiếu; AI chưa được phép đóng phiếu, sửa cấu hình hoặc thực hiện thao tác trên hệ thống.

Đội vận hành thấy tính năng thuận tiện, nhưng tài liệu ban đầu chưa xác nhận mô-đun AI dùng cùng môi trường xử lý hay chuyển nội dung sang một bên khác. Phiếu hỗ trợ có thể chứa thông tin vượt nhu cầu tóm tắt. OLB không giả định rằng toàn bộ nội dung đang lưu trên nền tảng đều được phép chuyển sang chức năng AI.

Điểm cần quyết định là phạm vi sử dụng mới, không phải đánh giá lại toàn bộ sản phẩm từ đầu. Khi chưa xác minh được luồng dữ liệu, OLB đề xuất giữ chức năng AI chưa kích hoạt và tiếp tục xử lý phiếu theo cách đã được duyệt. Đây là lựa chọn thiết kế cho tình huống nghiên cứu; bài viết không báo cáo một triển khai hoặc sự cố có thật.

Đánh giá phần thay đổi trước khi bật tính năng

Chủ giải pháp lập một bản đối chiếu giữa phạm vi hiện tại và đề xuất mới. Bản đối chiếu làm rõ nội dung nào được gửi cho AI, dữ liệu có được lưu lại hay dùng cho mục đích khác, bên nào xử lý và hỗ trợ, quyền truy cập nào được bổ sung. Phần phụ thuộc xác định tính năng AI có thể tắt riêng hay việc mất nó ảnh hưởng cả quy trình xử lý phiếu.

Người phụ trách dữ liệu xác định trường thông tin phù hợp để thử. OLB đề xuất bắt đầu bằng phiếu giả lập, không có dữ liệu khách hàng, thông tin xác thực hoặc cấu hình nhạy cảm. Nếu dự kiến dùng dữ liệu thực, phạm vi và biện pháp lọc cần được phê duyệt riêng. Việc bỏ tên khỏi một phiếu chưa đủ để kết luận đã loại mọi thông tin có thể nhận diện hoặc tiết lộ nội dung nhạy cảm.

Đội kỹ thuật kiểm tra khả năng giới hạn tập dữ liệu, phân quyền và tắt mô-đun. Bộ thử bao gồm phiếu thông thường, nội dung ngoài phạm vi và trường hợp AI không phản hồi. Kỳ vọng là dữ liệu ngoài phạm vi không được chuyển đi, đầu ra được người vận hành rà soát và quy trình thủ công vẫn sử dụng được. Các kỳ vọng này cần được kiểm tra, không được coi là khả năng sẵn có của mọi nền tảng.

Mua sắm và bộ phận pháp lý rà soát điều khoản liên quan đến bên xử lý tiếp theo, mục đích sử dụng dữ liệu, thông báo thay đổi, lưu giữ và xóa dữ liệu. Điều khoản cần được đối chiếu với tài liệu dịch vụ và cấu hình thực tế. Bài viết không đưa ra kết luận tuân thủ pháp luật cho một sản phẩm hoặc cách triển khai cụ thể.

Bằng chứng phải trả lời được quyết định

Một câu trả lời tích cực từ nhà cung cấp cần có phạm vi rõ ràng. Nếu họ nói không dùng dữ liệu để huấn luyện, OLB cần xác định cam kết đó áp dụng cho mô-đun nào, loại dữ liệu nào và có bao gồm bên xử lý tiếp theo hay không. Hồ sơ nên giữ phiên bản tài liệu hoặc cam kết đã rà soát, sơ đồ đường đi dữ liệu, cấu hình giới hạn và kết quả kiểm thử tương ứng.

Nhật ký và quan sát kỹ thuật giúp xác nhận hành vi ở phần OLB có thể kiểm tra; chúng không tự chứng minh cách xử lý bên trong môi trường của nhà cung cấp. Chứng nhận hoặc báo cáo đánh giá độc lập cũng cần đọc phạm vi và kỳ đánh giá. Nếu thiếu bằng chứng cho mô-đun mới, hồ sơ ghi rõ phần chưa được xác minh, người theo dõi và hạn hoàn thành.

Bằng chứng được nối với phiên bản tính năng, cấu hình và lần thử cụ thể. Hồ sơ không chỉ giữ kết quả tốt: yêu cầu bị từ chối, đầu ra sai, dữ liệu bị chặn và tình huống chưa thử đều cần đủ dấu vết để giải thích giới hạn của quyết định. Không công bố nhật ký nhạy cảm trong bài truyền thông.

Ai đánh giá và ai cho phép sử dụng

Chủ giải pháp chuẩn bị bản đối chiếu và hồ sơ kỹ thuật. Đội vận hành đánh giá tính hữu ích cùng khả năng tiếp tục công việc. Người phụ trách dữ liệu xác nhận phạm vi thông tin; an toàn thông tin và quản lý rủi ro rà soát kiểm soát, phụ thuộc và phần chưa xác minh. Mua sắm, pháp lý làm rõ cam kết phù hợp. Chủ dịch vụ ra quyết định trong thẩm quyền; vấn đề vượt thẩm quyền được trình cấp có quyền chấp nhận rủi ro.

Odin đề xuất ba lựa chọn cho OLB. Duyệt có điều kiện khi phạm vi đã rõ, kiểm soát trọng yếu được kiểm chứng và phần còn lại có người chịu trách nhiệm. Yêu cầu bổ sung khi chưa đủ bằng chứng để kết luận. Chưa cho dùng khi đề xuất vượt phạm vi có thể chấp nhận hoặc không đáp ứng điều kiện trọng yếu. Một điểm tổng hợp thuận lợi không thay thế việc xử lý thiếu sót trọng yếu về dữ liệu hoặc quyền.

Quyết định cần ghi chức năng được phép bật, nhóm dữ liệu, người dùng, điều kiện giám sát và thời điểm xem lại. Ngoại lệ, nếu được chấp nhận, phải nêu người phê duyệt, thời hạn và biện pháp giảm tác động. Đội vận hành không được coi việc thử thành công vài phiếu là cho phép mở rộng sang mọi nhóm dữ liệu.

Theo dõi sau khi dùng và chuẩn bị đường lui

OLB đề xuất đánh giá lại khi thay đổi mục đích, dữ liệu, bên xử lý, quyền hoặc mức phụ thuộc vào chức năng. Khi phát hiện luồng dữ liệu không phù hợp, ưu tiên ngăn việc chuyển tiếp và xác định dữ liệu đã bị ảnh hưởng. Tắt mô-đun không có nghĩa dữ liệu đã gửi được thu hồi hoặc xóa; việc xử lý phần đó cần bằng chứng riêng và phối hợp với nhà cung cấp.

Phương án tiếp tục công việc phải phân biệt tính năng AI ngừng hoạt động với toàn bộ nền tảng mất khả dụng. Trường hợp thứ nhất có thể trở về đọc và phân loại thủ công nếu thiết kế hỗ trợ. Trường hợp thứ hai cần phương án thay thế đã được tổ chức xác định và kiểm tra. Không nên gọi một nút tắt AI là phương án dự phòng cho mọi sự cố nhà cung cấp.

Bài thử đầu tiên có thể giới hạn ở một mô-đun, một nhóm người dùng và phiếu giả lập. Giá trị cần chứng minh là thời gian đọc giảm mà độ chính xác và kiểm soát dữ liệu vẫn đáp ứng tiêu chí đã thống nhất. Bài viết chưa đưa ra số liệu đạt được. Kết quả mong đợi là một quyết định có căn cứ, giữ được lợi ích của tính năng mới và biết khi nào phải dừng hoặc đánh giá lại.

Từ nghiên cứu đến quyết định tại OLB

Luồng áp dụng: Gợi mở từ ISACA và NIST → xác định phạm vi AI mới tại OLB → đánh giá dữ liệu, quyền, bên xử lý và phụ thuộc → đối chiếu bằng chứng → chủ dịch vụ quyết định → theo dõi và đánh giá lại khi phạm vi thay đổi.

Nguồn tham khảo và đọc tiếp

[1] Gaudam Suriyakala Thiyagarajan và Nivathan Athiganoor Somasundharam. Enhancing Third-Party Risk Management: Moving from Questionnaire Fatigue to Contextual Assurance. ISACA Industry News, 04/05/2026. Hai tác giả là đồng sáng lập SecureOS; bài được sử dụng như góc nhìn chuyên môn, không phải bằng chứng đánh giá sản phẩm. Đối chiếu 11/10/2026.

Đọc bài phân tích trên ISACA

[2] NIST. The NIST Cybersecurity Framework CSF 2.0. NIST CSWP 29, 26/02/2024; nhóm GV.SC, trang in 17–18. DOI 10.6028/NIST.CSWP.29. Nguồn nền tảng, không phải tài liệu mới năm 2026. Đối chiếu 11/10/2026.

Tải NIST CSF 2.0

[3] NIST. NIST Cybersecurity Framework 2.0: Quick-Start Guide for Cybersecurity Supply Chain Risk Management. NIST SP 1305, 21/10/2024. DOI 10.6028/NIST.SP.1305. Đối chiếu 11/10/2026.

Đọc hướng dẫn NIST SP 1305

Bài 01 AI được phép làm gì trong ngân hàng

Bài 02 AI làm đúng hôm nay ngày mai còn đáng tin

Đọc tiếp tại Odin Lab

Bài tiếp theo: Vì sao ngân hàng cần lồng ghép Zero Trust và Defense in Depth trong thực tế

Chuyên mục Nghiên cứu & Ứng dụng · Odin Lab Bank · AI Governance, Risk & Audit