LLMOps 7 — Quản trị & rủi ro GenAI ngân hàng

Sáu bài trước xây dựng phần kỹ thuật: mẫu ứng dụng, prompt & guardrail, bảo mật, đánh giá & chống ảo giác, observability & chi phí. Bài này trả lời một câu hỏi khác hẳn — không phải "trợ lý GenAI có chạy tốt không" mà "ta có được phép đưa nó vào vận hành không, ai duyệt, và ta chịu trách nhiệm thế nào khi nó nói sai với khách hàng".

Trong một startup, một chatbot bịa câu trả lời chỉ khiến người dùng khó chịu. Trong ngân hàng, một trợ lý GenAI tư vấn sai điều kiện vay, tiết lộ thông tin khách hàng khác, hay đưa ra lời khuyên đầu tư trái quy định có thể dẫn tới khiếu nại, tổn thất, rủi ro pháp lý và bị thanh tra tuýt còi. Vì thế GenAI không thể lên production như một tính năng phần mềm bình thường — nó phải đi qua đúng khung quản trị mô hình và tuân thủ của ngân hàng.

Bài này mở rộng khung model risk đã trình bày ở MLOps 7 — quản trị mô hình sang bối cảnh GenAI, và nối với quyền riêng tư & tuân thủ theo Nghị định 13. Nó cũng dựa trên các rủi ro kỹ thuật đã phân tích ở đánh giá & ảo giác và bảo mật/injection.

Vì sao model risk cho GenAI khó hơn ML truyền thống

Ngành ngân hàng đã có khung Model Risk Management (MRM) — rủi ro tổn thất do dùng mô hình lỗi hoặc dùng sai mô hình. Chuẩn tham chiếu kinh điển là SR 11-7 của Fed (2011): phát triển đúng đắn, validation độc lập, và governance/kiểm soát vòng đời. Với scorecard tín dụng, khung này vận hành trơn tru vì ta sở hữu mô hình: biết dữ liệu train, tái tạo được kết quả, tính được metric ổn định.

GenAI phá vỡ gần như mọi giả định đó:

Đặc điểm	ML truyền thống (scorecard)	GenAI (LLM)
Quyền sở hữu	Tự xây, biết dữ liệu train	Mô hình nền của bên thứ ba (OpenAI, Anthropic, Google...)
Minh bạch	Có thể giải thích (SHAP/LIME)	Hộp đen, hàng chục tỷ tham số
Tính lặp lại	Deterministic, cùng input ra cùng output	Non-deterministic, cùng prompt ra khác câu
Phạm vi đầu ra	Hữu hạn (điểm 0–1000, nhãn 0/1)	Văn bản tự do vô hạn
Validation	Metric rõ (AUC, KS, PSI)	Không có "đáp án đúng" duy nhất, khó đo
Cập nhật	Do ta kiểm soát, có versioning	Nhà cung cấp có thể đổi model dưới cùng một API

Ba hệ quả cốt lõi cho việc quản trị:

• Không validate được lõi. Ta không thể kiểm chứng trọng số của một mô hình mình không sở hữu. Trọng tâm chuyển từ "validate mô hình" sang validate hệ thống bao quanh mô hình: prompt, RAG, guardrail, hành vi ở đầu ra trên bộ test đại diện.
• Non-determinism làm khó tái đánh giá. Kết quả validation hôm nay không đảm bảo cho ngày mai, nhất là khi nhà cung cấp âm thầm nâng phiên bản. Phải pin version và tái đánh giá định kỳ như một quy trình thường xuyên, không phải một lần.
• Rủi ro của bên thứ ba trở thành rủi ro của ngân hàng. Model card, chính sách dữ liệu, độ ổn định của nhà cung cấp đều là cấu phần rủi ro phải đánh giá và ghi vào hợp đồng.

Kết luận thực dụng: coi ứng dụng GenAI là một mô hình cần quản trị, nhưng đối tượng validation là ứng dụng (application) chứ không phải mô hình nền (foundation model).

Đưa GenAI vào model inventory và phân tầng rủi ro

Bước đầu tiên của mọi khung MRM là model inventory — danh mục tất cả mô hình đang dùng, ai sở hữu, mục đích, mức rủi ro. Một ứng dụng GenAI (chatbot nội bộ, trợ lý tra cứu quy định, tóm tắt hồ sơ) phải được đăng ký vào inventory như một hạng mục chính thức, không được để "tự phát" ở một team nào đó ngoài tầm nhìn của bộ phận rủi ro. Đây cũng là cách chống Shadow AI — nhân viên tự dùng ChatGPT public với dữ liệu khách hàng.

Không phải mọi use case rủi ro như nhau. Nguyên tắc phân tầng: mức kiểm soát tỷ lệ thuận với mức rủi ro, dựa trên hai trục — tác động của sai sót và mức độ tự chủ của AI.

Tầng	Ví dụ use case	Đặc điểm	Kiểm soát yêu cầu
Thấp	Tóm tắt tài liệu nội bộ, gợi ý viết email cho nhân viên	Nội bộ, con người xem lại, không ra quyết định	Acceptable use, log cơ bản
Trung bình	Trợ lý tra cứu quy trình/sản phẩm cho giao dịch viên	Hỗ trợ nhân viên, nhân viên chịu trách nhiệm cuối	Guardrail, grounding, đánh giá định kỳ
Cao	Chatbot đối mặt khách hàng, tư vấn sản phẩm	Trực tiếp tới khách, ảnh hưởng quyết định của họ	Validation độc lập, human oversight, disclaimer, audit đầy đủ
Rất cao / cấm	AI tự động phê duyệt/từ chối tín dụng qua văn bản tự do	Ra quyết định tài chính có hệ quả pháp lý	Thường cấm dùng LLM tự do; nếu có phải qua model rule kiểm soát, giải thích được

Ranh giới quan trọng nhất là giữa hỗ trợ nội bộ (con người là người ra quyết định, AI chỉ gợi ý) và ra quyết định / đối mặt khách hàng (AI tác động trực tiếp đến khách). Càng dịch về phía sau, càng cần validation độc lập, phê duyệt cấp cao và giám sát chặt.

Chu trình khép kín: inventory → validate → approve → monitor → tái đánh giá. Khi nhà cung cấp đổi phiên bản model hoặc metric chất lượng trôi, use case quay lại vòng phân tầng — không được coi phê duyệt là "một lần cho mãi mãi".

Tài liệu: model card / system card cho ứng dụng LLM

Mỗi ứng dụng GenAI đăng ký phải kèm một model card (hay system card cho ứng dụng phức hợp) — hồ sơ mô tả cô đọng, dùng để validation, phê duyệt và audit sau này. Với LLM, model card không mô tả "mô hình" (ta không sở hữu) mà mô tả hệ thống: mô hình nền nào, phiên bản nào, prompt/RAG ra sao, guardrail gì, đã đánh giá thế nào.

Các mục tối thiểu:

• Mục đích & phạm vi — dùng để làm gì, cho ai, ranh giới sử dụng đúng.
• Mô hình nền & phiên bản — nhà cung cấp, tên model, version đã pin, cách triển khai (API bên ngoài / self-host).
• Dữ liệu — nguồn tri thức của RAG, dữ liệu nào được/không được đưa vào prompt, phân loại độ nhạy cảm.
• Đánh giá — golden set, metric (faithfulness, tỷ lệ ảo giác, escalation), kết quả baseline.
• Rủi ro đã biết & giảm thiểu — ảo giác, bias, rò rỉ dữ liệu... và biện pháp tương ứng.
• Giới hạn — những gì hệ thống không làm được, không được dùng cho việc gì.
• Vai trò & phê duyệt — người sở hữu, người validate, người duyệt, ngày tái đánh giá tiếp theo.

Model card sống trong git cùng code, versioned, và là artifact bắt buộc trong gate lên production — giống như hồ sơ validation của một scorecard.

Rủi ro đặc thù của GenAI và cách giảm thiểu

Rủi ro	Hệ quả trong ngân hàng	Giảm thiểu
Ảo giác (hallucination)	Bịa quy định, bịa lãi suất, khẳng định sai như thật	Grounding/RAG, bắt trích nguồn, guardrail bám nguồn (bài 5)
Thiên lệch & công bằng (bias)	Đầu ra phân biệt theo giới/vùng miền/nhóm	Kiểm thử bias trên đầu ra, prompt trung tính, human review với use case nhạy cảm
Rò rỉ / riêng tư dữ liệu	Gửi dữ liệu KH ra API ngoài không kiểm soát	Data residency, self-host, hợp đồng không lưu/không train; xem bên dưới
Bản quyền / IP	Đầu ra vi phạm bản quyền hoặc lộ tài liệu nội bộ	Chính sách nguồn, kiểm soát nội dung train của bên cung cấp
Nội dung độc hại	Trợ lý phản hồi xúc phạm, không phù hợp	Guardrail lọc đầu vào/đầu ra, moderation
Prompt injection	Người dùng lật đổ chỉ dẫn, moi thông tin	Cô lập nội dung, guardrail (bài 4)

Trong số này, rò rỉ dữ liệu khách hàng là rủi ro tuân thủ gay gắt nhất ở Việt Nam. Nguyên tắc cứng: không đưa dữ liệu định danh khách hàng ra một API ngoài không kiểm soát. Các lớp phòng vệ:

• Data residency — dữ liệu KH không rời khỏi biên giới/hạ tầng được phép.
• Self-host / private endpoint — chạy model trong VPC của ngân hàng hoặc dùng dịch vụ có cam kết cô lập (ví dụ triển khai riêng trên đám mây được duyệt).
• Hợp đồng "no retention, no training" — nhà cung cấp cam kết không lưu và không dùng để train dữ liệu ngân hàng gửi lên. Đây là điều khoản bắt buộc phải có trong hợp đồng, không phải mặc định.
• Redaction/tokenization trước khi gửi — che số CMND, số tài khoản, tên trước khi đưa vào prompt nếu buộc phải dùng API ngoài.

Điều này gắn thẳng với Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân: xử lý dữ liệu cá nhân phải có cơ sở pháp lý, hạn chế mục đích và kiểm soát bên thứ ba. Chi tiết ở bài về quyền riêng tư & tuân thủ.

Quy định: EU AI Act và xu hướng quản lý AI

Chưa có luật AI riêng ở Việt Nam ở thời điểm hiện tại, nhưng khung tư duy quốc tế đang định hình các thông lệ mà ngân hàng Việt tham chiếu.

EU AI Act (Liên minh châu Âu, thông qua 2024, hiệu lực theo lộ trình) là đạo luật AI toàn diện đầu tiên, phân loại theo mức rủi ro — cách tiếp cận rất giống phân tầng use case ở trên:

• Rủi ro không chấp nhận được — bị cấm (ví dụ social scoring của chính quyền).
• Rủi ro cao — gồm nhiều ứng dụng tài chính như đánh giá tín nhiệm tín dụng; yêu cầu quản trị dữ liệu, tài liệu, giám sát con người, minh bạch, kiểm thử độ chính xác/robustness.
• Rủi ro hạn chế — chủ yếu nghĩa vụ minh bạch: chatbot phải cho người dùng biết họ đang nói chuyện với AI; nội dung AI sinh ra phải được đánh dấu.
• Rủi ro tối thiểu — phần lớn ứng dụng còn lại, không ràng buộc đặc biệt.

Xu hướng chung — dù ở EU, Mỹ hay Việt Nam — hội tụ về vài nguyên tắc AI có trách nhiệm (responsible AI): minh bạch, công bằng, an toàn & robust, quyền riêng tư, trách nhiệm giải trình, và giám sát của con người. Ngân hàng Việt nên xây khung nội bộ theo các nguyên tắc này ngay cả khi chưa có luật bắt buộc — vừa đón đầu quy định, vừa quản trị rủi ro thực chất.

Transparency, human oversight và audit

Ba trụ cột vận hành để một use case GenAI "được phép chạy" ở ngân hàng:

1. Minh bạch với người dùng (transparency). Người dùng có quyền biết mình đang tương tác với AI, không phải nhân viên thật. Kèm theo là cảnh báo giới hạn — trợ lý nên nói rõ "thông tin mang tính tham khảo, vui lòng xác nhận với nhân viên/tổng đài cho quyết định chính thức", đặc biệt với nội dung liên quan tiền bạc, hợp đồng, pháp lý. Không được để trợ lý tự nhận là tư vấn viên có thẩm quyền.

2. Human oversight (giám sát của con người). Nguyên tắc: con người duyệt các hành động rủi ro cao. AI có thể soạn thảo, gợi ý, tra cứu — nhưng hành động có hệ quả (mở tài khoản, thay đổi hạn mức, ra quyết định tín dụng, gửi văn bản chính thức tới khách) phải có người xác nhận. Khách hàng cũng cần quyền khiếu nại và được xem xét lại bởi con người khi bị ảnh hưởng bởi đầu ra của AI — đây là yêu cầu tương tự "quyền được giải thích" trong tín dụng.

3. Audit & lưu vết. Mọi truy vấn và quyết định liên quan phải được log đầy đủ: ai hỏi gì, model trả lời gì, phiên bản model/prompt nào, guardrail có kích hoạt không, có escalation không. Log này phục vụ ba mục đích: điều tra khi có khiếu nại, tái đánh giá chất lượng, và cung cấp bằng chứng khi thanh tra. Đây là phần mở rộng tự nhiên của observability (bài 6) sang chiều tuân thủ.

Chính sách sử dụng nội bộ (acceptable use). Cuối cùng, một tài liệu policy ngắn gọn cho toàn bộ nhân viên: được dùng GenAI cho việc gì, tuyệt đối không dán dữ liệu khách hàng vào công cụ AI public, dùng đúng công cụ đã được ngân hàng phê duyệt. Đây là hàng rào đầu tiên chống Shadow AI, rẻ nhất và hiệu quả nhất.

Use case thực tế

Bối cảnh. Khối Ngân hàng số của NCB muốn đưa trợ lý GenAI tra cứu quy trình & sản phẩm cho 800 giao dịch viên tại quầy: nhân viên hỏi bằng tiếng Việt ("hồ sơ mở thẻ tín dụng cho khách hộ kinh doanh cần gì?"), trợ lý trả lời dựa trên kho tài liệu nội bộ (RAG). Ban đầu team định gọi thẳng API của một nhà cung cấp ngoài và bật cho toàn quầy.

Bộ phận Quản lý rủi ro chặn lại và áp khung quản trị:

1. Đăng ký inventory & phân tầng. Use case được xếp Trung bình: hỗ trợ nhân viên, nhân viên chịu trách nhiệm cuối với khách, không phải AI đối mặt khách trực tiếp. Nếu là chatbot cho khách hàng cuối, sẽ nhảy lên tầng Cao với yêu cầu ngặt hơn.

2. Chốt vấn đề dữ liệu. Vì tài liệu quy trình chứa thông tin nội bộ nhạy cảm, hai lựa chọn: (a) self-host một model mở trong VPC, hoặc (b) dùng dịch vụ có hợp đồng no-retention/no-training và endpoint riêng. NCB chọn (b), pin đúng một phiên bản model, và cấm đưa dữ liệu định danh khách hàng vào prompt.

3. Model card + validation. Team lập model card (mục đích, model+version, nguồn RAG, guardrail, giới hạn). Đội validation độc lập chạy golden set 150 câu: kết quả faithfulness 0,91, tỷ lệ ảo giác 4%, mọi câu ngoài phạm vi được từ chối đúng cách. Gate phê duyệt yêu cầu ảo giác < 5% và bắt buộc trích nguồn.

4. Vận hành. Trợ lý luôn mở đầu "Đây là trợ lý AI, thông tin mang tính tham khảo, quyết định cuối do anh/chị xác nhận". Mọi truy vấn được log (ai hỏi, trả lời gì, phiên bản, có escalation không). Câu ngoài phạm vi được chuyển sang tra cứu thủ công.

5. Tái đánh giá. Lịch tái đánh giá hàng quý và bắt buộc chạy lại golden set mỗi khi nhà cung cấp thông báo đổi phiên bản model — nếu metric trôi quá ngưỡng, use case quay lại vòng phê duyệt.

Kết quả sau 3 tháng: thời gian tra cứu quy trình của giao dịch viên giảm từ ~4 phút xuống ~40 giây, không có sự cố rò rỉ dữ liệu, và bộ phận rủi ro có đủ log + model card để trình khi thanh tra. Điều quan trọng: use case lên production đúng khung quản trị, không phải lén lút.

Ghi nhớ

• Coi ứng dụng GenAI là một mô hình cần quản trị, nhưng validation nhắm vào hệ thống bao quanh (prompt, RAG, guardrail, hành vi đầu ra), không phải mô hình nền hộp đen của bên thứ ba.
• Model risk cho GenAI khó hơn ML truyền thống: hộp đen, non-deterministic, khó validate, nhà cung cấp có thể đổi version dưới cùng một API → phải pin version và tái đánh giá định kỳ.
• Đăng ký mọi use case vào model inventory và phân tầng rủi ro — ranh giới then chốt là hỗ trợ nội bộ (người ra quyết định) vs đối mặt khách hàng / ra quyết định. Chống Shadow AI.
• Mỗi ứng dụng phải có model/system card: mục đích, model+version, dữ liệu, đánh giá, rủi ro đã biết, giới hạn, phê duyệt — là artifact bắt buộc trong gate production.
• Rủi ro đặc thù cần giảm thiểu: ảo giác, bias, rò rỉ dữ liệu, IP, nội dung độc hại. Với dữ liệu KH: data residency, self-host, hợp đồng no-retention/no-training, redaction — gắn với Nghị định 13.
• EU AI Act phân loại theo mức rủi ro (tín dụng thuộc rủi ro cao; chatbot phải minh bạch); xu hướng chung là các nguyên tắc AI có trách nhiệm.
• Ba trụ cột vận hành: transparency (báo đang chat với AI + cảnh báo giới hạn), human oversight (người duyệt hành động rủi ro, quyền khiếu nại), audit & lưu vết (log truy vấn/quyết định) — cộng với acceptable use policy.