AI Model Governance kiểm soát dữ liệu, tính giải thích, thiên lệch và quyền phê duyệt mô hình thế nào?

Một mô hình AI có thể cho kết quả backtest rất tốt nhưng vẫn chưa đủ điều kiện để đưa vào sử dụng. Vấn đề không chỉ nằm ở Accuracy, AUC hay Sharpe mà còn ở những câu hỏi cơ bản hơn: dữ liệu lấy từ đâu, có bị look-ahead hay không, model đang dựa vào feature nào, có thiên lệch về một nhóm cổ phiếu hay một market regime nào không, ai được phép chỉnh model và ai chịu trách nhiệm phê duyệt trước khi chạy live. AI Model Governance là hệ thống kiểm soát toàn bộ vòng đời đó. Có thể hiểu đơn giản là thay vì chỉ hỏi “model có tốt không?”, governance buộc phải trả lời thêm “model được xây như thế nào, có thể kiểm tra lại không và nếu có vấn đề thì ai được quyền dừng nó?”.

Phần 1. Kiểm soát dữ liệu trước khi kiểm soát model

Một mô hình tốt không thể cứu được dữ liệu sai. Trong đầu tư định lượng, nhiều lỗi nghiêm trọng xuất hiện ngay từ dataset nhưng chỉ lộ ra sau khi model chạy live. Ví dụ model dự đoán cổ phiếu có khả năng outperform 20 phiên tới dựa trên ROE, Momentum, Relative Strength, Volume Z-score và Foreign Flow. Backtest có thể cho AUC 0.65 và Sharpe 1.6, nhưng nếu ROE năm 2025 được gắn cho toàn bộ năm 2025 dù báo cáo chỉ được công bố đầu năm 2026, model đã nhìn thấy tương lai. Governance phải kiểm tra dữ liệu trước cả khi nhìn performance.
Một dataset tối thiểu nên biết được:

Nguồn dữ liệu
Ngày cập nhật
Phiên bản dữ liệu
Feature được tạo thế nào
Thời điểm feature thực sự có thể sử dụng
Có missing value hay không
Có chỉnh sửa dữ liệu lịch sử hay không

Ví dụ với dữ liệu báo cáo tài chính, không nên chỉ lưu:

Ticker
Period
ROE
EPS
Revenue

mà nên có thêm:

Report Date
Public Date
Revision Date
Data Source
Version

Nếu model chạy tại ngày T thì chỉ được sử dụng dữ liệu đã tồn tại tại T. Quy tắc đơn giản là:

usable_data = financials[
    financials["public_date"] <= model_date
]

Với price data cũng cần kiểm tra corporate action, stock split, dividend adjustment và survivorship bias. Nếu backtest năm 2018 nhưng universe chỉ gồm những cổ phiếu còn tồn tại năm 2026, model đã vô tình loại khỏi quá khứ những doanh nghiệp yếu hoặc bị hủy niêm yết.
Governance cũng phải kiểm soát feature engineering. Giả sử model dùng Volume Z-score:

volume_z = (
    volume - volume.rolling(20).mean()
) / volume.rolling(20).std()

Công thức này bình thường. Nhưng nếu preprocessing như StandardScaler được fit trên toàn bộ dataset:

scaler.fit(all_data)

thì thông tin của Test Set đã lọt vào Train. Đúng hơn phải là:

scaler.fit(train_data)
train_scaled = scaler.transform(train_data)
test_scaled = scaler.transform(test_data)

Một quy trình governance tốt vì vậy phải lưu cả dataset version, code version và model version. Ví dụ:

Data Version     v2026.08.15
Feature Version  v1.4
Model Version    RF_017
Code Commit      8f23b1
Training Period  2018–2023
Validation       2024
Test             2025–2026

Khi model có vấn đề sau sáu tháng, có thể quay lại chính xác phiên bản đã dùng thay vì cố nhớ “hồi đó chạy file nào”.

Phần 2. Model phải giải thích được nó đang dựa vào đâu và có thiên lệch gì

Một model dự đoán tốt nhưng không biết vì sao nó phát tín hiệu vẫn tạo ra rủi ro lớn. Điều này không có nghĩa mọi AI đều phải giải thích được từng phép toán bên trong. Mục tiêu thực tế hơn là phải biết những feature nào đang ảnh hưởng nhiều nhất, model đang hoạt động tốt ở đâu và thất bại ở đâu.
Giả sử Random Forest xếp hạng cổ phiếu bằng các feature:

Momentum60D
Relative Strength
Volume Z-score
Volatility20D
ROE
Beta
Foreign Flow

Feature importance cho thấy:

Momentum60D        32%
Relative Strength  25%
Volume Z-score     18%
ROE                10%
Volatility          8%
Others              7%

Ít nhất có thể hiểu model chủ yếu đang hoạt động như một momentum/relative-strength model. Nếu một phiên bản mới đột nhiên cho:

Foreign Flow       62%

thì cần kiểm tra tại sao cấu trúc model thay đổi mạnh như vậy.
Có thể dùng SHAP hoặc feature importance để xem từng prediction. Ví dụ một cổ phiếu được score cao vì:

Momentum mạnh            +0.12
Relative Strength mạnh    +0.09
Volume tăng               +0.06
Volatility quá cao        -0.04
ROE thấp                  -0.02

Cách này hữu ích hơn việc model chỉ trả:

Probability = 0.78

mà không biết 0.78 đến từ đâu.
Thiên lệch của model trong đầu tư cũng cần hiểu rộng hơn khái niệm bias thông thường. Model có thể thiên lệch về một sector, market cap hoặc market regime. Ví dụ strategy chọn 20 cổ phiếu nhưng 14 mã là ngân hàng. Nhìn số lượng thì có vẻ diversified, nhưng thực tế model đang đặt cược rất mạnh vào một sector.
Có thể kiểm tra:

sector_distribution = (
    selected_stocks
    .groupby("sector")
    .size()
)

Nếu lịch sử:

Bank        25%
Technology  15%
Retail      12%
Others      48%

nhưng live:

Bank        70%
Others      30%

model đang tạo output khác đáng kể so với môi trường đã được kiểm nghiệm.
Một kiểu bias khác là regime bias. Model được train chủ yếu trong bull market có thể rất giỏi nhận diện momentum nhưng thất bại khi thị trường chuyển sang bear market. Vì vậy performance nên được tách:

Bull Market
Sideway
Bear Market
High Volatility
Low Volatility

Ví dụ:

Bull Sharpe       1.8
Sideway Sharpe    0.7
Bear Sharpe      -0.5

Con số Sharpe toàn sample bằng 1.2 có thể che mất việc model thực chất chỉ phù hợp với một regime.
Thiên lệch cũng có thể đến từ liquidity. Model có thể phát hiện rất nhiều alpha ở small-cap vì backtest giả định mua bán dễ dàng. Khi live, spread và market impact ăn gần hết lợi nhuận. Vì vậy governance không chỉ kiểm tra prediction mà còn kiểm tra universe:

Minimum liquidity
Maximum position / ADV
Market-cap bucket
Sector concentration
Maximum number of positions

Một model có performance tốt nhưng chỉ nhờ một số cổ phiếu thanh khoản rất thấp chưa chắc được phép triển khai với vốn lớn.
Sau khi live, explainability và bias vẫn phải tiếp tục được monitor. Nếu feature importance, signal distribution hoặc sector concentration thay đổi quá mạnh so với lịch sử, model có thể cần review ngay cả khi P&L chưa xấu.

Phần 3. Người xây model không nên tự mình quyết định model được chạy live

Một phần rất quan trọng của Model Governance là quyền phê duyệt. Nếu cùng một người viết model, kiểm tra model, quyết định đưa live và tự thay đổi threshold khi model thua lỗ, gần như không còn lớp kiểm soát độc lập.
Một cấu trúc đơn giản có thể chia thành ba vai trò:

Model Developer
→ Xây model, feature, backtest
Model Validator / Risk
→ Kiểm tra dữ liệu, leakage, robustness, stress test
Model Approver
→ Quyết định có được đưa production hay không

Developer có thể đề xuất model nhưng không tự phê duyệt model của mình. Validator cần kiểm tra ít nhất Train/Validation/Test, Point-in-Time Data, transaction cost, stability theo regime, feature importance, drawdown và những trường hợp model thất bại.
Một model trước khi được phê duyệt có thể phải qua pipeline:

Research
→ Backtest
→ Independent Validation
→ Paper Trading
→ Small Live
→ Approval
→ Production
→ Monitoring

Ví dụ model ranking cổ phiếu có kết quả:

Backtest Sharpe      1.55
Test Sharpe          1.12
Paper Sharpe         1.03
Small Live Sharpe    0.95

Kết quả giảm dần nhưng vẫn tương đối ổn định. Điều này đáng tin hơn model:

Backtest Sharpe      2.30
Test Sharpe          0.85
Paper Sharpe         0.20

dù con số backtest ban đầu đẹp hơn rất nhiều.
Governance cũng cần quy định ai được phép thay model. Ví dụ researcher không nên có quyền vào production rồi đổi:

threshold = 0.70

thành:

threshold = 0.55

chỉ vì tuần này ít tín hiệu. Một thay đổi nhỏ như vậy có thể khiến strategy hoàn toàn khác backtest đã được phê duyệt.
Mỗi thay đổi nên tạo model version mới:

Model v1.2
Threshold     0.70
Features      12
Approved      15/06/2026
Model v1.3
Threshold     0.65
Features      14
Approved      12/08/2026

Như vậy khi performance thay đổi có thể biết chính xác model nào đang chạy.
Một lớp cuối cùng là kill switch, tức điều kiện cho phép giảm risk hoặc dừng model. Ví dụ:

Data Feed lỗi
Feature missing quá mức
Signal distribution bất thường
Drawdown vượt limit
Model drift quá lớn
Position lệch broker

Có thể viết đơn giản:

if data_quality_failed:
    block_trading()
if model_drift_score > limit:
    reduce_position()
if drawdown > max_drawdown_limit:
    suspend_model()

Điểm quan trọng là những rule này được định nghĩa trước, không phải đợi khi thua lỗ rồi mới quyết định bằng cảm xúc.
Một dashboard Model Governance thực tế có thể chỉ cần vài nhóm thông tin:

MODEL
Version        RF_017
Status         LIVE
DATA
Freshness      OK
Missing Rate   0.3%
Drift          NORMAL
PERFORMANCE
Rolling Sharpe 1.08
Drawdown       -6.4%
BEHAVIOR
Signal Count   NORMAL
Sector Bias    WATCH
Feature Drift  NORMAL
CONTROL
Last Review    01/08/2026
Next Review    01/09/2026
Approval       ACTIVE

Model Governance vì vậy không phải làm thêm giấy tờ cho một mô hình AI. Nó nhằm đảm bảo rằng model đang chạy ngoài thực tế vẫn là model đã được nghiên cứu, với đúng dữ liệu, đúng feature, đúng giới hạn và đúng quyền hạn.
Có thể tóm gọn bằng bốn câu hỏi: Dữ liệu có đúng và đúng thời điểm không? Model đang dựa vào điều gì? Model có đang thiên lệch hoặc thay đổi hành vi không? Ai có quyền cho model chạy, thay đổi hoặc dừng lại?
Một mô hình AI tốt không chỉ cần dự báo tốt. Nó còn phải kiểm tra được, giải thích được, giám sát được và có người chịu trách nhiệm khi nó không còn hoạt động như kỳ vọng.