OAGF #03 – Đánh giá rủi ro AI: Làm thế nào để lựa chọn đúng mức kiểm soát?

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

Một trợ lý AI chỉ trả lời câu hỏi có thực sự là ứng dụng rủi ro thấp? Điều gì thay đổi khi trợ lý đó được phép đọc dữ liệu nhạy cảm, đưa ra khuyến nghị nghiệp vụ hoặc tự thực hiện hành động?

Tiếp nối OAGF #02 – Triển khai AI có kiểm soát, bài viết sử dụng tình huống mô phỏng tại Odin Lab Bank để trả lời câu hỏi: đánh giá rủi ro như thế nào để lựa chọn đúng mức kiểm soát?

Nội dung bài viết

• Đánh giá rủi ro AI khác gì CNTT truyền thống?
• Bốn mức Risk Tier
• Mười yếu tố đánh giá
• Tình huống Odin Lab Bank
• Lựa chọn kiểm soát
• Rủi ro còn lại và quyết định
• Công cụ thực hành

1. Đánh giá rủi ro AI khác gì đánh giá rủi ro CNTT truyền thống?

AI vẫn phải đáp ứng các yêu cầu quen thuộc về bảo mật, tính sẵn sàng, toàn vẹn dữ liệu, quản lý thay đổi, nhà cung cấp và khả năng phục hồi. Nhưng AI còn có thể tạo câu trả lời nghe hợp lý mà sai, thay đổi chất lượng khi dữ liệu biến động, hoặc bị tác động bởi những chỉ dẫn không đáng tin cậy trong tài liệu được truy xuất.

Khi AI kết nối công cụ hoặc API, sai sót có thể chuyển thành hành động thực tế. Vì vậy, đánh giá rủi ro cần kết hợp bối cảnh sử dụng, hành vi và giới hạn của AI, cùng hậu quả có thể xảy ra.

2. OAGF phân loại AI theo bốn Risk Tier

Tier 1 – Low: Phạm vi hạn chế, ảnh hưởng thấp; ưu tiên kiểm soát cơ bản và quản lý danh mục. Tier 2 – Moderate: Hỗ trợ quy trình nội bộ hoặc sử dụng dữ liệu cần quản lý; yêu cầu đánh giá rủi ro, kiểm thử và giám sát. Tier 3 – High: Có thể ảnh hưởng đáng kể tới khách hàng, hoạt động hoặc tuân thủ; cần validation, phê duyệt và giám sát tăng cường. Tier 4 – Critical: Ảnh hưởng tiềm tàng rất lớn hoặc quyền tự chủ đáng kể trong quy trình quan trọng; cần kiểm soát nghiêm ngặt và assurance phù hợp.

Risk Tier là kết quả phân loại quản trị theo OAGF, không phải nhãn vĩnh viễn và không đồng nghĩa với phân loại pháp lý của EU AI Act hay quy định tại từng quốc gia. Thay đổi mục đích, dữ liệu, quyền hạn hoặc hậu quả tiềm tàng có thể làm thay đổi Tier.

3. Mười yếu tố cần xem xét khi phân loại rủi ro

• Impact & Harm: Mức độ thiệt hại tiềm tàng.
• Affected Population: Quy mô và đặc điểm đối tượng bị ảnh hưởng.
• Decision Materiality: Tầm quan trọng của quyết định có AI tham gia.
• Data Sensitivity: Mức độ nhạy cảm của dữ liệu.
• Process Criticality: Mức độ quan trọng của quy trình hoặc hệ thống.
• External Exposure: Phạm vi tiếp xúc bên ngoài.
• Model Uncertainty: Độ không chắc chắn về hành vi và chất lượng AI.
• Legal & Regulatory Significance: Nghĩa vụ pháp lý và tuân thủ.
• Autonomy Level: Quyền tự quyết định hoặc hành động.
• Reversibility: Khả năng phát hiện, khắc phục hoặc đảo ngược hậu quả.

Các yếu tố có thể được chấm điểm và gán trọng số. Tuy nhiên, điểm tổng hợp chỉ hỗ trợ quyết định: rủi ro nghiêm trọng và nghĩa vụ bắt buộc phải được xem xét riêng, không bị che khuất bởi điểm trung bình.

4. Áp dụng vào OLB Knowledge Assistant

Tình huống A – Tra cứu tài liệu nội bộ: AI chỉ đọc tài liệu được phê duyệt, áp dụng phân quyền, không thực hiện hành động. Với thiết kế giả định này, OLB có thể xem xét Tier 2 – Moderate.

Tình huống B – Hỗ trợ nghiệp vụ quan trọng: AI tiếp cận dữ liệu nhạy cảm và đưa khuyến nghị liên quan đến quyết định có ảnh hưởng đáng kể. OLB có thể xem xét Tier 3 – High.

Tình huống C – AI Agent có quyền hành động: AI kết nối công cụ và tự thực hiện tác vụ trên quy trình hoặc hệ thống quan trọng. Nếu quyền tự chủ và hậu quả tiềm tàng đủ lớn, OLB có thể xem xét Tier 4 – Critical.

Đây là ba kịch bản minh họa, không phải quy tắc tự động gán Tier theo tên ứng dụng.

5. Từ Risk Tier đến lựa chọn kiểm soát

Phân loại rủi ro chỉ có giá trị khi dẫn tới thay đổi thiết kế, kiểm soát hoặc quyết định. Với Knowledge Assistant, OLB xem xét các cặp rủi ro – kiểm soát – bằng chứng sau:

• Câu trả lời sai: kiểm thử chất lượng, dẫn nguồn, cơ chế từ chối; bằng chứng là bộ câu hỏi và kết quả evaluation.
• Truy xuất trái quyền: xác thực, phân quyền theo nguồn và kiểm thử truy cập; bằng chứng là access test results.
• Tài liệu lỗi thời: quản lý chủ sở hữu, phiên bản và hiệu lực; bằng chứng là knowledge inventory.
• Prompt injection: giới hạn công cụ, dữ liệu và kiểm thử tấn công; bằng chứng là security test report.
• Thay đổi làm tăng rủi ro: change assessment và revalidation; bằng chứng là hồ sơ thay đổi, phê duyệt.
• Hành động ngoài thẩm quyền: least privilege, approval gate, action limits và kill switch; bằng chứng là cấu hình quyền và nhật ký hành động.

Mức độ sâu của từng kiểm soát phụ thuộc rủi ro thực tế, không chỉ phụ thuộc nhãn Tier.

6. Rủi ro còn lại: Khi nào có thể phê duyệt?

Inherent Risk là mức rủi ro trước khi tính đến hiệu quả kiểm soát; Residual Risk là mức rủi ro còn lại sau khi xem xét kiểm soát và hiệu quả thực tế. Nếu phân quyền đã được cấu hình nhưng kiểm thử vẫn phát hiện truy xuất trái quyền, không thể kết luận rủi ro đã được xử lý.

Các phương án quyết định có thể là Approve, Approve with Conditions, Restrict, Suspend hoặc Reject. Người có thẩm quyền cần xem xét bằng chứng, mức rủi ro còn lại và điều kiện áp dụng; Risk Tier không tự động quyết định phê duyệt.

Nếu còn khả năng truy xuất trái quyền dữ liệu nhạy cảm, OLB phải xử lý hoặc loại bỏ khả năng đó trước khi mở rộng phạm vi, thay vì chỉ chấp nhận rủi ro trên giấy.

7. Từ phương pháp đến công cụ thực hành

Odin Lab phát triển OAGF AI Risk & Control Matrix để kết nối rủi ro, kiểm soát, bằng chứng, hiệu quả kiểm soát và rủi ro còn lại. Công cụ đánh giá Risk Tier hỗ trợ xem xét các yếu tố theo phương pháp chấm điểm; kết quả không phải chứng nhận an toàn AI hoặc kết luận tuân thủ pháp luật.

Các nội dung này được tham chiếu với NIST AI RMF, ISO/IEC 23894:2023 và EU AI Act – Article 6. OAGF là phương pháp thực hành của Odin Lab, không đồng nhất với những khuôn khổ trên.

Kết luận: Đúng mức kiểm soát quan trọng hơn nhiều kiểm soát

Không thể quản trị mọi ứng dụng AI bằng cùng một checklist. Quản trị quá nhẹ để lại rủi ro; quản trị quá nặng có thể làm chậm những use case có giá trị và mức ảnh hưởng thấp. Phương pháp phù hợp là Risk Assessment → Risk Tier → Controls → Evidence → Residual Risk → Decision.

Đọc thêm OAGF #01 – Kiến trúc framework, OAGF #02 – Quyết định triển khai, ODIN 101 Q006 – Control Evidence và Bộ công cụ Odin Lab.

Odin Lab — Adopt AI with control. Govern AI with evidence. 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. Các tình huống, Risk Tier và quyết định chỉ có tính minh họa, không phản ánh hoạt động của bất kỳ ngân hàng thực tế nào.