OAGF #02 — Đưa AI vào ngân hàng: Từ ý tưởng đến quyết định triển khai có kiểm soát

OAGF Series #02 | AI Governance, Risk & Audit | Odin Lab

Một ngày, bộ phận vận hành của Odin Lab Bank (OLB) đề xuất xây dựng một trợ lý trí tuệ nhân tạo để hỗ trợ nhân viên tìm kiếm quy trình, tra cứu tài liệu nghiệp vụ và giải đáp những câu hỏi thường gặp trong công việc. Thay vì mất nhiều thời gian tìm kiếm trong hàng trăm tài liệu, nhân viên có thể đặt câu hỏi và nhận được câu trả lời trong vài giây.

Bộ phận công nghệ nhìn thấy khả năng triển khai nhanh. Đơn vị nghiệp vụ kỳ vọng năng suất được cải thiện. Ban lãnh đạo mong muốn ngân hàng bắt kịp xu hướng AI. Nhưng một câu hỏi xuất hiện: Ai chịu trách nhiệm nếu trợ lý AI đưa ra hướng dẫn sai, sử dụng tài liệu hết hiệu lực hoặc tiết lộ thông tin mà người hỏi không có quyền tiếp cận?

Câu hỏi ấy không có nghĩa ngân hàng nên dừng triển khai AI. Nó cho thấy AI đã bước ra khỏi phạm vi thử nghiệm công nghệ và trở thành một vấn đề quản trị. Đối với Odin Lab, quản trị AI không nhằm làm chậm đổi mới mà tạo điều kiện để đổi mới với mức rủi ro được hiểu rõ, kiểm soát phù hợp và trách nhiệm xác định.

Bài viết tiếp nối OAGF #01 – Giới thiệu Odin AI Governance Framework, đi sâu vào một tình huống áp dụng tại Odin Lab Bank.

1. Một AI use case phải bắt đầu từ giá trị kinh doanh

Trong tình huống mô phỏng này, OLB gọi sáng kiến là OLB Knowledge Assistant. Thay vì bắt đầu bằng việc lựa chọn mô hình ngôn ngữ hay nhà cung cấp, nhóm triển khai xác định vấn đề cần giải quyết: nhân viên đang mất bao nhiêu thời gian để tìm kiếm thông tin, tài liệu nào thường được tra cứu và thành công sẽ được đo lường như thế nào.

OLB đề xuất ba chỉ tiêu cho giai đoạn thử nghiệm: giảm thời gian tìm kiếm tài liệu; tăng tỷ lệ câu trả lời có dẫn nguồn chính xác và còn hiệu lực; không để xảy ra truy xuất trái quyền trong bộ kiểm thử phân quyền. Đây là chỉ tiêu giả định của tình huống mô phỏng, không phải kết quả triển khai thực tế.

Theo OAGF, đầu ra đầu tiên cần có là một AI Use Case Profile: hồ sơ mô tả mục tiêu, phạm vi, giá trị kỳ vọng, người chịu trách nhiệm và tiêu chí thành công.

2. Cùng một công nghệ, rủi ro có thể rất khác nhau

Ban đầu, OLB chỉ cho phép trợ lý tra cứu những tài liệu hướng dẫn nội bộ đã được phê duyệt. AI trả lời câu hỏi, dẫn nguồn và không được phép thực hiện giao dịch hoặc thay đổi dữ liệu. Sau đó, một đơn vị đề xuất mở rộng để AI truy cập thông tin khách hàng, kiểm tra trạng thái giao dịch và tạo yêu cầu xử lý nghiệp vụ.

Công nghệ nền tảng có thể không thay đổi nhiều, nhưng bản chất rủi ro đã khác. Khi AI chỉ hỗ trợ tìm kiếm, rủi ro nổi bật là độ chính xác của câu trả lời, chất lượng tài liệu và quyền truy cập. Khi AI xử lý dữ liệu khách hàng hoặc khởi tạo hành động, ngân hàng phải xem xét thêm quyền riêng tư, bảo mật, tính hợp lệ của giao dịch, khả năng truy vết, trách nhiệm phê duyệt và phương án xử lý khi hệ thống hoạt động sai.

Không thể đánh giá rủi ro AI chỉ bằng tên công nghệ hoặc loại mô hình. Phải đánh giá toàn bộ use case trong bối cảnh vận hành thực tế. OAGF xem xét mức độ ảnh hưởng, tính nhạy cảm của dữ liệu, mức độ quan trọng của quy trình, quyền tự chủ và khả năng đảo ngược hậu quả.

Với phạm vi tra cứu tài liệu nội bộ có kiểm soát, Knowledge Assistant có thể được đánh giá sơ bộ ở Tier 2 – Moderate. Nếu mở rộng sang hành động có ảnh hưởng trực tiếp tới khách hàng hoặc hệ thống quan trọng, use case phải được đánh giá lại và có thể tăng lên Tier 3 hoặc Tier 4. Đây là phân loại quản trị theo OAGF, không thay thế yêu cầu phân loại theo pháp luật áp dụng.

3. Biến rủi ro thành những kiểm soát có thể thực hiện

Kiểm soát nguồn tri thức. Không phải tài liệu nào cũng được đưa vào hệ thống. Tài liệu cần có chủ sở hữu, trạng thái phê duyệt, thời hạn hiệu lực và cơ chế cập nhật. Tài liệu hết hiệu lực phải được loại khỏi phạm vi truy xuất.

Kiểm soát quyền truy cập. AI không được trở thành con đường vòng để người dùng đọc thông tin ngoài thẩm quyền. Xác thực và phân quyền phải được áp dụng tới từng nguồn tài liệu, kể cả khi AI truy xuất thay người dùng.

Kiểm soát chất lượng câu trả lời. Hệ thống cần được kiểm thử bằng bộ câu hỏi đại diện, bao gồm cả tình huống không có câu trả lời, tài liệu mâu thuẫn hoặc câu hỏi vượt phạm vi. Khi thiếu căn cứ, AI cần từ chối hoặc hướng người dùng tới bộ phận có thẩm quyền.

Kiểm soát vận hành và thay đổi. Bổ sung nguồn dữ liệu, thay đổi model, điều chỉnh prompt hệ thống hoặc mở rộng quyền sử dụng đều có thể làm thay đổi rủi ro. Những thay đổi quan trọng phải được đánh giá và phê duyệt.

Đây là bốn nhóm kiểm soát trọng tâm cho tình huống OLB, không phải danh sách đầy đủ cho mọi hệ thống AI.

4. Ai chịu trách nhiệm khi AI đưa ra câu trả lời sai?

Một sai lầm dễ gặp là giao toàn bộ trách nhiệm về AI cho bộ phận công nghệ. Đối với OLB Knowledge Assistant, đơn vị nghiệp vụ chịu trách nhiệm về mục đích sử dụng và chất lượng nội dung; bộ phận công nghệ chịu trách nhiệm kiến trúc, tích hợp, vận hành và kiểm soát kỹ thuật. Các chức năng quản trị rủi ro, an ninh thông tin và tuân thủ đánh giá, giám sát hoặc phản biện theo thẩm quyền.

Người có thẩm quyền phê duyệt phải hiểu lợi ích, rủi ro còn lại và các điều kiện đi kèm. Hồ sơ quản trị phải chỉ rõ ai sở hữu use case, ai thực hiện kiểm soát, ai chấp nhận rủi ro còn lại và ai có quyền yêu cầu dừng hệ thống. Xem thêm ODIN 101 Q007 – Khi rủi ro xảy ra, ai thực sự chịu trách nhiệm?

5. Có kiểm soát chưa đủ, phải có bằng chứng

Nếu nhóm triển khai báo cáo rằng trợ lý đã được kiểm soát phân quyền, kiểm thử chất lượng và giám sát vận hành, ban lãnh đạo cần biết bằng chứng ở đâu. Kiểm soát phân quyền cần kết quả kiểm thử và cấu hình liên quan. Chất lượng câu trả lời cần bộ câu hỏi, tiêu chí đánh giá và kết quả. Giám sát vận hành cần nhật ký, chỉ số, cơ chế phát hiện bất thường và hồ sơ xử lý sự cố.

Bằng chứng không nhất thiết phải phức tạp nhưng phải đủ tin cậy và có thể kiểm tra lại. Đây là điểm kết nối với ODIN 101 Q006 – Làm thế nào để chứng minh một Control thực sự hoạt động?

6. Một quyết định triển khai AI cần dựa trên điều gì?

Sau thử nghiệm, OLB tổ chức đánh giá trước khi mở rộng sử dụng. Hồ sơ quyết định dựa trên chuỗi Use Case → Value → Risk → Control → Owner → Evidence → Assurance → Decision.

Trong tình huống giả định, trợ lý giúp giảm thời gian tìm kiếm tài liệu và phần lớn câu trả lời trong bộ kiểm thử có dẫn nguồn phù hợp. Tuy nhiên, nhóm đánh giá vẫn phát hiện một số tình huống tài liệu cũ được ưu tiên hơn tài liệu mới.

Thay vì phê duyệt không điều kiện hoặc từ chối toàn bộ, OLB có thể lựa chọn Approve with Conditions – Phê duyệt có điều kiện: giới hạn nguồn tài liệu đã kiểm duyệt, giới hạn nhóm người dùng, yêu cầu khắc phục vấn đề ưu tiên tài liệu và xác định thời hạn đánh giá lại. Đây là quyết định mô phỏng, không phải kết quả triển khai thực tế.

7. Khi AI đi vào vận hành, quản trị mới thực sự bắt đầu

Sau khi triển khai, nguồn tài liệu tiếp tục thay đổi, nhân viên có thể sử dụng hệ thống theo những cách chưa dự kiến và nhà cung cấp có thể cập nhật model. OLB cần giám sát chất lượng câu trả lời, quyền truy cập, thay đổi quan trọng, phản hồi người dùng và sự cố phát sinh.

Khi phạm vi sử dụng thay đổi đáng kể, Risk Assessment và quyết định phê duyệt phải được xem xét lại. Một framework có giá trị không chỉ ở thời điểm cho phép triển khai mà còn ở khả năng giúp tổ chức duy trì quyền kiểm soát khi AI tiếp tục phát triển.

Từ một use case đến năng lực quản trị AI của ngân hàng

Tình huống OLB Knowledge Assistant cho thấy triển khai AI không đơn thuần là bài toán công nghệ. Nó đòi hỏi kết nối giữa giá trị kinh doanh, rủi ro, kiểm soát, trách nhiệm, bằng chứng và thẩm quyền ra quyết định. Ngay từ use case đầu tiên, ngân hàng nên hình thành những năng lực nền tảng: hồ sơ use case, phân loại rủi ro, kiểm soát, bằng chứng, phê duyệt và giám sát.

Khi các năng lực này được chuẩn hóa, tổ chức có thể mở rộng ứng dụng AI mà không phải xây dựng lại cơ chế quản trị từ đầu cho từng sáng kiến. Khám phá thêm các phương pháp tại Phương pháp Odin và Bộ công cụ thực hành.

Adopt AI with control. Govern AI with evidence.
Odin Lab — Turn Risk into Value.

Odin Lab Bank là mô hình ngân hàng giả lập phục vụ nghiên cứu, đào tạo và minh họa phương pháp. Các tình huống, phân loại và quyết định trong bài là giả định, không phản ánh hoạt động của bất kỳ tổ chức tài chính cụ thể nào.