MLOps 7 — Quản trị mô hình & AI có trách nhiệm

Sáu bài trước của series tập trung vào kỹ thuật vận hành mô hình: theo dõi thí nghiệm, feature store, pipeline, registry, deploy, giám sát drift. Bài này chuyển sang câu hỏi khác — không phải "mô hình chạy có ổn không" mà "mô hình được phép chạy không, và ta chịu trách nhiệm thế nào khi nó ra quyết định sai".

Với một startup thương mại điện tử, một mô hình recommend sai chỉ khiến khách bỏ giỏ hàng. Với ngân hàng, một mô hình scorecard tín dụng chấm điểm lệch có thể từ chối oan một khách hàng đủ điều kiện, hoặc cấp tín dụng cho nhóm rủi ro cao gây nợ xấu, hoặc phân biệt đối xử theo giới/vùng miền — dẫn tới rủi ro pháp lý, rủi ro danh tiếng, và bị thanh tra ngân hàng tuýt còi. Mô hình ở ngân hàng chịu giám sát như một cấu phần rủi ro chính thức, không phải một dòng code vô danh. Đó là lý do MLOps ngân hàng luôn phải đi kèm model governance (quản trị mô hình).

Model Risk Management — mô hình là một loại rủi ro

Ngành ngân hàng có sẵn một khái niệm cho việc này: Model Risk (rủi ro mô hình) — rủi ro tổn thất phát sinh từ việc dùng mô hình có lỗi hoặc dùng sai mô hình. Chuẩn tham chiếu kinh điển là SR 11-7 của Cục Dự trữ Liên bang Mỹ (Fed, ban hành 2011), được hầu hết ngân hàng lớn coi là thông lệ tốt. Bản thân SR 11-7 không áp dụng trực tiếp ở Việt Nam, nhưng khung tư duy của nó đã trở thành chuẩn mực quốc tế và thường được các ngân hàng Việt tham chiếu khi xây khung quản trị mô hình nội bộ.

SR 11-7 định nghĩa mô hình rất rộng: bất kỳ phương pháp định lượng nào biến đầu vào thành ước lượng/quyết định — kể cả một công thức Excel tính LGD, chứ không riêng mô hình machine learning. Ba trụ cột của khung:

1. Development, implementation, use — phát triển đúng đắn, có tài liệu, dùng đúng mục đích.
2. Validation độc lập — một đội tách biệt với đội xây mô hình phải thách thức và kiểm chứng.
3. Governance, policies, controls — có chính sách, phân vai trò, kiểm soát vòng đời.

Các thành phần thực thi cụ thể:

Điểm mấu chốt dễ bị bỏ qua ở đội kỹ thuật: validation phải độc lập. Người xây mô hình không được tự nghiệm thu mô hình của mình. Vai trò tách bạch theo mô hình "three lines of defense" quen thuộc trong ngân hàng: đội mô hình (tuyến 1) xây; đội validation/rủi ro mô hình (tuyến 2) thách thức; kiểm toán nội bộ (tuyến 3) soát lại cả quy trình.

Tài liệu mô hình: model card

Không có tài liệu thì không có governance. Mỗi mô hình cần một model card — bản mô tả súc tích, chuẩn hóa, mà cả người kỹ thuật lẫn cán bộ rủi ro/thanh tra đều đọc được. Các mục tối thiểu:

• Mục đích & phạm vi dùng đúng: mô hình để làm gì (VD: chấm điểm tín dụng khách cá nhân vay tiêu dùng), và không được dùng cho việc gì (VD: không dùng cho khách doanh nghiệp — ngoài phạm vi huấn luyện).
• Dữ liệu: nguồn, khoảng thời gian, cỡ mẫu, biến đầu vào, cách gán nhãn (định nghĩa "vỡ nợ" là quá hạn bao nhiêu ngày).
• Giả định & giới hạn: mô hình giả định điều gì (VD: hành vi khách hàng ổn định), và yếu ở đâu (VD: ít dữ liệu khách hàng vùng nông thôn → độ tin cậy thấp hơn cho nhóm này).
• Chỉ số hiệu năng: AUC, KS, Gini trên tập test và theo phân khúc.
• Kiểm thử fairness: kết quả kiểm thiên lệch theo các nhóm nhạy cảm.
• Ngày validate, người phê duyệt, phiên bản, hạn tái đánh giá.

Model card nên được sinh và version cùng mô hình trong pipeline, không viết tay sau khi đã deploy — vì tài liệu viết muộn luôn lệch với thực tế. Nối trực tiếp với reproducibility & lineage: khi thanh tra hỏi "con số AUC 0.82 này train từ dữ liệu nào, code nào", bạn phải truy được từ model card → run trong tracking → git SHA + dataset snapshot. Lineage đầy đủ chính là điều kiện để audit được — không có lineage thì mọi tuyên bố về mô hình đều là lời nói suông.

Explainability — giải thích được, không phải "hộp đen"

Đây là ràng buộc pháp lý và nghiệp vụ, không chỉ là "cho đẹp". Khi ngân hàng từ chối cấp tín dụng dựa trên mô hình, khách hàng có quyền được biết vì sao, và cán bộ tín dụng phải giải thích được. Một mô hình từ chối mà không giải thích nổi lý do là không dùng được trong tín dụng — bất kể AUC cao đến đâu.

Có hai tầng giải thích:

• Global explainability — mô hình nói chung dựa vào yếu tố nào. Công cụ: feature importance (độ quan trọng đặc trưng), permutation importance. Trả lời "yếu tố nào ảnh hưởng nhiều nhất đến điểm tín dụng của cả tập khách hàng".
• Local explainability — vì sao khách hàng cụ thể này bị điểm thấp. Công cụ: SHAP (SHapley Additive exPlanations — phân bổ đóng góp của từng feature dựa trên lý thuyết trò chơi hợp tác) và LIME (Local Interpretable Model-agnostic Explanations — xấp xỉ mô hình cục bộ bằng một mô hình tuyến tính đơn giản quanh điểm cần giải thích). Trả lời "khách A bị từ chối chủ yếu vì lịch sử trả nợ trễ và tỷ lệ DTI cao".

Đánh đổi cốt lõi: mô hình càng phức tạp (gradient boosting, deep learning) thường càng chính xác nhưng càng khó giải thích; mô hình đơn giản (logistic regression, scorecard theo điểm WOE) dễ giải thích nhưng có thể kém chính xác hơn. Ở ngân hàng, tính giải thích thường được ưu tiên — nhiều đội cố tình chọn mô hình đơn giản hơn, hoặc dùng mô hình phức tạp kèm lớp giải thích SHAP đủ vững để bảo vệ trước thanh tra.

Ví dụ minh hoạ tính SHAP cho một quyết định từ chối (Python — minh hoạ, không phải SQL chạy được trong sandbox):

import shap
import xgboost as xgb

# model đã train, X_customer là 1 hồ sơ khách cần giải thích
explainer = shap.TreeExplainer(model)
shap_values = explainer.shap_values(X_customer)

# Xếp hạng đóng góp âm/dương của từng feature cho quyết định này
contrib = sorted(
    zip(X_customer.columns, shap_values[0]),
    key=lambda x: abs(x[1]),
    reverse=True,
)
for feature, value in contrib[:5]:
    huong = "làm giảm điểm" if value < 0 else "làm tăng điểm"
    print(f"{feature}: {value:+.3f} ({huong})")

# Ví dụ output (minh hoạ):
# so_ngay_qua_han_max: -0.412 (làm giảm điểm)
# ty_le_dti:           -0.287 (làm giảm điểm)
# so_nam_lam_viec:     +0.104 (làm tăng điểm)

Kết quả này chính là "reason codes" — lý do từ chối gửi kèm cho khách hàng và lưu vào hồ sơ. Lưu ý quan trọng: giải thích phải trung thực với mô hình thật, không được chọn lý do "nghe hay" mà mô hình không thực sự dùng.

Fairness & bias — không phân biệt đối xử

Mô hình học từ dữ liệu lịch sử, mà lịch sử có thể chứa thiên lệch (bias). Nếu trong quá khứ một nhóm khách hàng (theo giới, tuổi, vùng miền) bị đối xử bất lợi, mô hình sẽ học và khuếch đại thiên lệch đó. Nguy hiểm nhất là proxy bias: bạn không đưa biến "giới tính" vào mô hình, nhưng mô hình dùng một biến khác tương quan mạnh với giới tính (VD: loại nghề nghiệp, khu vực sinh sống) để suy ra gián tiếp — thành ra vẫn phân biệt đối xử dù đã "loại" biến nhạy cảm. Bỏ biến nhạy cảm ra khỏi input là cần nhưng chưa đủ.

Vì thế phải đo sự công bằng bằng chỉ số định lượng trên các nhóm nhạy cảm:

Một cảnh báo lý thuyết quan trọng: các chỉ số công bằng thường xung đột nhau — trừ trường hợp đặc biệt, không thể thỏa mãn đồng thời demographic parity và equalized odds. Do đó chọn chỉ số fairness nào là một quyết định chính sách/pháp lý, không phải quyết định kỹ thuật thuần túy; đội mô hình phải phối hợp với bộ phận tuân thủ.

Quy trình kiểm & giảm thiên lệch: (1) xác định nhóm nhạy cảm theo quy định & đạo đức; (2) đo chỉ số fairness trên tập test theo từng nhóm; (3) nếu lệch quá ngưỡng, áp dụng biện pháp — pre-processing (cân bằng lại dữ liệu train), in-processing (thêm ràng buộc fairness khi train), hoặc post-processing (điều chỉnh ngưỡng theo nhóm — nhưng phải cân nhắc kỹ tính pháp lý). Kết quả kiểm fairness phải nằm trong model card.

Quyền riêng tư dữ liệu

Mô hình tín dụng dùng dữ liệu cá nhân — thuộc phạm vi điều chỉnh của Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân. Các yêu cầu chạm tới MLOps: xử lý dữ liệu phải có căn cứ pháp lý (thường là sự đồng ý của chủ thể), đúng mục đích đã thông báo, và tôn trọng quyền của chủ thể dữ liệu. Hệ quả kỹ thuật: feature dùng để train phải nằm trong phạm vi mục đích đã được đồng ý; không "tiện tay" lấy mọi cột dữ liệu khách hàng nhét vào mô hình. Nối chặt với governance dữ liệu — quản trị mô hình đứng trên nền quản trị dữ liệu, không thể tách rời.

AI có trách nhiệm & xu hướng quy định

EU AI Act (Đạo luật AI của EU, có hiệu lực từng phần từ 2024–2026) phân loại hệ thống AI theo mức rủi ro. Đáng chú ý: AI dùng để đánh giá mức độ tín nhiệm/chấm điểm tín dụng cá nhân được xếp vào nhóm "high-risk" — kèm nghĩa vụ về quản trị dữ liệu, tài liệu, minh bạch, giám sát bởi con người và độ chính xác. Dù luật EU không áp dụng trực tiếp ở Việt Nam, xu hướng quy định rõ ràng: mô hình ảnh hưởng lớn tới cá nhân sẽ bị giám sát chặt hơn. Xây đúng ngay từ đầu (đúng như khung SR 11-7 ở trên) sẽ giúp thích ứng nhanh khi quy định trong nước siết lại.

Rủi ro GenAI: mô hình ngôn ngữ lớn thêm các rủi ro mới — hallucination (bịa thông tin nghe hợp lý nhưng sai), rò rỉ dữ liệu nhạy cảm qua prompt, khó tái lập và khó giải thích. Với ngân hàng, tuyệt đối không để GenAI tự động ra quyết định tín dụng; chỉ dùng hỗ trợ (tóm tắt hồ sơ, soạn thảo) với người kiểm soát.

Human-in-the-loop: với quyết định trọng yếu (từ chối tín dụng giá trị lớn, đóng băng tài khoản nghi ngờ AML), mô hình đề xuất nhưng con người phê duyệt cuối cùng. Mô hình là công cụ hỗ trợ, không thay thế trách nhiệm của cán bộ. Kèm theo là giám sát đạo đức: định kỳ soát lại xem mô hình có gây tác hại ngoài ý muốn cho nhóm khách hàng nào không.

Use case thực tế

Bối cảnh: NCB triển khai lại scorecard tín dụng cho vay tiêu dùng cá nhân. Đội mô hình dùng XGBoost đạt AUC 0.84 trên tập test — cao hơn logistic regression cũ (AUC 0.80). Nhưng để lên production, phải qua quản trị mô hình.

Diễn biến:

1. Phân tầng: mô hình ảnh hưởng quyết định tín dụng trực tiếp → tầng rủi ro Cao → bắt buộc validation độc lập + tái đánh giá hằng năm.
2. Model card: pipeline sinh tự động — dữ liệu 24 tháng, 180.000 hồ sơ, nhãn "vỡ nợ = quá hạn > 90 ngày", 32 feature, giả định đã ghi rõ.
3. Explainability: đội validation yêu cầu reason codes bằng SHAP cho mọi hồ sơ bị từ chối. Kiểm tra 500 hồ sơ từ chối → lý do hàng đầu đều hợp lý về nghiệp vụ (số ngày quá hạn, DTI). Đạt.
4. Fairness: đo equal opportunity theo giới. Phát hiện TPR nữ = 0.71 vs nam = 0.82 — chênh 11 điểm phần trăm, vượt ngưỡng nội bộ 5%. Truy nguyên: một feature "loại hình công việc" hoạt động như proxy cho giới tính. Xử lý: hiệu chỉnh trọng số dữ liệu train + thêm ràng buộc fairness → kéo chênh lệch về 3 điểm phần trăm, đổi lại AUC giảm nhẹ còn 0.83. Đội chấp nhận đánh đổi vì rủi ro phân biệt đối xử là không thể chấp nhận.
5. Phê duyệt: Ủy ban mô hình duyệt có điều kiện — giám sát fairness hằng quý; mọi hồ sơ từ chối giá trị > 500 triệu phải có cán bộ phê duyệt (human-in-the-loop).
6. Vận hành: mô hình lên registry, lineage đầy đủ. Sáu tháng sau thanh tra hỏi về một hồ sơ bị từ chối — đội truy ngay reason codes SHAP + phiên bản mô hình + model card. Giải trình trong 15 phút thay vì cả tuần lục notebook.

Kết quả: mô hình mạnh hơn và công bằng hơn và giải trình được — đúng ba yêu cầu của một scorecard ngân hàng. Xem thêm nền tảng nghiệp vụ ở xây dựng scorecard tín dụng.

Ghi nhớ

• Mô hình ở ngân hàng là một loại rủi ro cần quản trị chính thức, không phải dòng code vô danh — vì nó ảnh hưởng quyết định tín dụng và chịu giám sát.
• Khung Model Risk Management (tham chiếu SR 11-7): model inventory, phân tầng rủi ro, validation độc lập, phê duyệt, tái đánh giá định kỳ. Người xây không tự nghiệm thu.
• Model card + lineage đầy đủ = điều kiện để audit được; sinh tự động cùng mô hình, không viết tay sau khi deploy.
• Explainability là ràng buộc pháp lý khi từ chối tín dụng: global (feature importance) để hiểu chung, local (SHAP/LIME) để giải thích từng quyết định. Mô hình phức tạp đổi lấy độ chính xác bằng độ khó giải thích.
• Fairness: bỏ biến nhạy cảm là chưa đủ vì proxy bias. Phải đo bằng demographic parity / equal opportunity / equalized odds — các chỉ số này xung đột nhau, chọn cái nào là quyết định chính sách.
• Quyền riêng tư dữ liệu theo Nghị định 13: feature train phải trong phạm vi mục đích đã được đồng ý.
• Xu hướng quy định (EU AI Act xếp chấm điểm tín dụng vào high-risk); GenAI thêm rủi ro hallucination/rò rỉ. Quyết định trọng yếu giữ human-in-the-loop.