Hãy hỏi phần lớn hội đồng quản trị ngân hàng vì sao chương trình AI của họ chậm tiến độ, và anh/chị sẽ nghe cùng một câu trả lời: "tuân thủ". Rà soát rủi ro thì chậm. Hội đồng mô hình họp mỗi tháng một lần. Pháp chế cần xem thêm một lượt. Quản trị, theo câu chuyện đó, là khoản thuế anh/chị phải trả khi hoạt động trong một ngành bị quản lý.
Bằng chứng không ủng hộ câu chuyện đó. Điểm nghẽn không phải quản trị — nó là quản trị thủ công. Và các ngân hàng đang vượt lên trong năm 2026 không phải những ngân hàng giám sát nhẹ nhất hay nặng nhất. Họ là những ngân hàng có bộ máy quản trị nhanh ngay từ thiết kế.
Bài này trình bày chính mô hình vận hành đó: bốn biện pháp kiểm soát mà tôi gọi là The 4 Stone Guardians — Cửa kiểm soát, Guardrail, Sổ ghi và Người chịu trách nhiệm — cùng bằng chứng rằng khi được lắp đúng, chúng làm một ngân hàng đưa AI ra nhanh hơn, không phải chậm hơn.
Vì sao năm 2026 buộc phải đặt câu hỏi này
Ba lực đã hội tụ trong năm nay và biến "chúng ta quản trị AI thế nào" từ một câu hỏi về quy trình hậu trường thành một câu hỏi về tốc độ ở cấp hội đồng.
Tại Mỹ, các cơ quan giám sát đã ban hành SR 26-2, hướng dẫn về rủi ro mô hình được tổ chức lại quanh mức trọng yếu — đánh giá theo mức phơi nhiễm và mục đích của mô hình. Một mô hình càng dịch chuyển được nhiều thì càng đòi nhiều kiểm soát; các mô hình rủi ro tối thiểu thì được thiết kế để đi theo một đường nhẹ. Đáng lưu ý, hướng dẫn này đặt AI tạo sinh và AI dạng agent ra ngoài phạm vi của mình — trong khi vẫn yêu cầu ngân hàng phải quản trị các hệ thống đó, để mỗi ngân hàng tự dựng lấy các biện pháp kiểm soát toàn hàng của mình.
Tại Liên minh châu Âu, AI Act xếp việc đánh giá khả năng trả nợ vào nhóm rủi ro cao và, theo Điều 14, đòi phải có một con người hiểu được, can thiệp được, ghi đè được và dừng được hệ thống; Điều 12 đòi việc ghi log tự động, có dấu hiệu chống can thiệp, xuyên suốt vòng đời của mô hình. (Các nghĩa vụ với nhóm rủi ro cao ban đầu có mốc hạn ngày 02/8/2026, nhưng Quy định (EU) 2026/1744 — Digital Omnibus on AI, có hiệu lực ngày 27/7/2026 — đã đẩy chế độ áp dụng cho Phụ lục III sang ngày 02/12/2027. Các nghĩa vụ minh bạch tại Điều 50 và quyền được giải thích về một quyết định cá nhân tại Điều 86 không được hoãn và áp dụng từ ngày 02/8/2026.)
Tại Việt Nam, Luật AI 134/2025 khẳng định AI phục vụ con người và không thay thế thẩm quyền của con người, với thời gian gia hạn cho ngành ngân hàng tới năm 2027; PDPL bổ sung yêu cầu minh bạch về việc lập hồ sơ tự động, và Ngân hàng Nhà nước đang dự thảo các nghĩa vụ về ghi log vận hành và báo cáo sự cố.
Đọc cùng nhau, thông điệp là nhất quán: giờ đây có một cơ quan quản lý đứng ở cuối mỗi quyết định tự chủ, và họ muốn thấy các biện pháp kiểm soát. Ngân hàng coi đó là gánh nặng giấy tờ sẽ bò. Ngân hàng coi đó là hạ tầng sẽ đi.
Huyền thoại: quản trị là cái phanh
Phần lớn ngân hàng triển khai quản trị AI dưới dạng một Hội đồng Tư vấn Thay đổi thủ công — một hội đồng họp, tranh luận từng lần ra hàng, và ký duyệt theo từng ca. Nó có vẻ thận trọng. Nó là nguồn gây chậm trễ lớn nhất trong toàn chuỗi phân phối.
Nghiên cứu về phân phối phần mềm nói rất thẳng: các tổ chức dựa vào hội đồng tư vấn thay đổi thủ công có khả năng thuộc nhóm hiệu quả thấp cao gấp 2,6 lần, phải gánh độ trễ của việc rà soát hành chính mà tỷ lệ lỗi không giảm một cách đo được. Hội đồng thêm vào độ trễ, không thêm vào sự an toàn.
Phiên bản thảm họa của chuyện này là điều tôi gọi là quản trị hình thức — quy trình nặng nề nhưng hướng tới việc xác nhận một thủ tục thay vì chất vấn mô hình. Khi nền tảng bất động sản Zillow để một thuật toán định giá và mua nhà, vẫn có con người trong vòng lặp để phê duyệt các giao dịch, nhưng quy trình lại xác nhận mô hình thay vì tra vấn nó; khoản ghi giảm lên tới hàng trăm triệu và hoạt động này bị đóng. Việc giám sát có tồn tại. Chỉ là nó không được thiết kế để bắt được cái lỗi đó.
Khi cửa kiểm soát là một hội đồng, người lãnh đạo nên dự liệu rằng mình trả chi phí mà không nhận được sự an toàn. Cách sửa không phải quản trị ít hơn. Nó là quản trị được dựng dưới dạng mã, quyết định một lần và được chính pipeline thực thi thay vì bị tranh luận lại trong một cuộc họp hằng tháng.
Luận đề: kiểm soát chính là làn nhanh
Hãy biến chính những biện pháp kiểm soát đó thành tự động hóa và các con số sẽ đảo ngược. Việc chuyển từ cửa kiểm soát thủ công sang các "golden path" dạng chính sách dạng mã (policy-as-code) tự động đã được chứng minh là giảm thời gian triển khai tới 94% — từ giờ xuống phút — đồng thời giảm số sự cố do cấu hình. Chính bộ máy quản trị được chuẩn hóa và thông trước đã giúp DBS Bank đưa thời gian triển khai AI từ khoảng mười lăm tháng xuống ba tháng, trên hơn một nghìn mô hình.
Cơ chế thì đơn giản: khi các quy tắc được quyết một lần và được mã hóa, các đội ngừng đi xin ký duyệt riêng cho từng hành động. Con đường an toàn trở thành con đường ít trở lực nhất. An toàn thôi không còn là kẻ thù của tốc độ và trở thành hạ tầng để tốc độ tồn tại được.
An toàn không phải kẻ thù của tốc độ. Nó là hạ tầng để tốc độ tồn tại được. Điểm nghẽn chưa bao giờ là quản trị — nó là quản trị thủ công.
The 4 Stone Guardians
G1 · Cửa kiểm soát — phê duyệt theo tầng rủi ro
Quyết định mức chấp nhận rủi ro một lần, theo từng tầng, ở cấp toàn hàng; các đội sau đó di chuyển tự chủ trong làn đã được thông trước. Một tình huống rủi ro tối thiểu thì ra ngay; chỉ một mô hình có mức trọng yếu cao — chẳng hạn quyết định tín dụng — mới phải leo lên thẩm định đầy đủ. Tốc độ đến từ việc bỏ đi độ trễ phê duyệt theo từng hành động. Điều này khớp trực tiếp với cách tiếp cận theo mức trọng yếu của SR 26-2 và các tầng rủi ro của EU AI Act: quản trị tương xứng với mức mà một quyết định có thể dịch chuyển.
G2 · Guardrail — kiểm soát phòng ngừa dưới dạng policy-as-code
Nhúng các giới hạn về pháp lý, an ninh và công bằng trực tiếp vào pipeline dưới dạng mã tự động. Hạ tầng sẽ chặn các cấu hình không tuân thủ, các mô hình thiên lệch và dữ liệu cá nhân bị lộ trước khi chúng ra ngoài. Tốc độ không còn phụ thuộc vào phán đoán của bất kỳ ai tình cờ có mặt trong cuộc họp về thay đổi — trạng thái an toàn mặc định do chính hệ thống cưỡng chế. Có một điểm về phạm vi rất quan trọng: vì SR 26-2 đặt AI dạng agent ra ngoài phần rủi ro mô hình truyền thống — trong khi vẫn yêu cầu ngân hàng phải quản trị nó — các guardrail phải bổ sung thêm những giới hạn ở giao diện để một lớp agent không thể làm hỏng dữ liệu vào hoặc ra của các mô hình cũ mà nó điều phối.
G3 · Sổ ghi — dấu vết kiểm toán không sửa được và observability
Ghi liên tục, ở dạng có dấu hiệu chống can thiệp, về việc mô hình đã làm gì, dùng dữ liệu nào, và việc giám sát nào của con người đã được áp — đi kèm một lớp giải thích. Việc triển khai nhanh thường bị chặn bởi nỗi sợ kiểm toán; một sổ ghi không sửa được sẽ loại bỏ nỗi sợ đó bằng cách làm mọi hành động đều tái dựng được khi cần. Đây chính là điểm hội tụ của yêu cầu ghi log tại Điều 12 EU AI Act, các yêu cầu về hành vi bất lợi của CFPB, và các quy định về lập hồ sơ trong PDPL Việt Nam. Sổ ghi không phải chi phí phụ trội — nó là thứ giành được sự cho phép của cơ quan quản lý để đi nhanh hơn.
G4 · Người chịu trách nhiệm — trách nhiệm của con người có tên cụ thể
Mọi đường leo thang đều kết thúc ở một lãnh đạo có tên, chịu trách nhiệm. "Thuật toán đã quyết" không phải một lý lẽ bào chữa được thừa nhận — chế độ Senior Managers của Anh đặt các cá nhân có tên vào diện chịu trách nhiệm, và một hội đồng xét xử ở Canada đã buộc một hãng hàng không chịu trách nhiệm nghiêm ngặt cho phát ngôn sai của chatbot của mình, bác bỏ lập luận rằng con bot là một thực thể riêng biệt. Trái với trực giác, việc phân định trách nhiệm rõ ràng lại là một chất xúc tác: khi một người có tên có thể nói "được", các quyết định ngừng chết trong hội đồng.
Chúng khớp vào nhau thế nào
Bốn người giữ là một bó kiểm soát được bện lại, không phải một danh mục kiểm. Người chịu trách nhiệm chỉ chứng minh được mình đã "thực hiện các bước hợp lý" bởi Sổ ghi cung cấp một bản ghi liên tục. Việc phân tầng của Cửa kiểm soát quyết định Guardrail và Sổ ghi phải nặng tới đâu. Rút bất kỳ sợi nào ra là cả bó cáp hỏng: thiếu Cửa kiểm soát thì anh/chị phê duyệt lại mọi thứ; thiếu Guardrail thì anh/chị phải tin vào từng cá nhân; thiếu Sổ ghi thì cơ quan quản lý làm anh/chị chậm lại; thiếu Người chịu trách nhiệm thì không ai có thể cho phép bước tiếp.
Bài chẩn đoán: anh/chị đang thiếu người giữ nào?
Giá trị thực dụng của khung tư duy này nằm ở phép trừ. Một ngân hàng có thể có những mô hình xuất sắc mà vẫn bò, chỉ vì thiếu một người giữ — và người giữ còn thiếu thường chính là thứ đang chặn tốc độ của nó. Không phân tầng, thì mọi mô hình bị tranh luận lại từ đầu. Không có policy-as-code, thì rà soát thủ công là trần năng lực thông qua. Không có sổ ghi, thì các lần rà soát lại và sự mất tin tưởng của cơ quan giám sát làm tắc việc ra hàng. Không có người chịu trách nhiệm, thì các quyết định chờ ở bước ký duyệt mà bước đó không bao giờ tới. Hãy tìm ra khoảng trống, và sửa cái đó trước.
Phép thử CFO
Có một câu hỏi phân tách quản trị tạo ra đòn bẩy khỏi quản trị chỉ diễn hoạt động:
AI đã làm thay đổi đòn bẩy của mô hình vận hành ở đâu — chứng minh được, trên Sổ ghi — chứ không chỉ là hiệu suất ở mức hoạt động?
Nếu anh/chị không truy được phần năng lực được giải phóng về một điểm nghẽn đã thực sự dịch chuyển — năng lực thông qua, việc chọn lọc rủi ro, hay tốc độ ra quyết định — và về một Người chịu trách nhiệm có tên, thì anh/chị đã mua hoạt động, không phải đòn bẩy. Sổ ghi là thứ làm câu trả lời kiểm toán được; Người chịu trách nhiệm là thứ làm nó có người chịu trách nhiệm.
Việc cần làm trong tuần này
Ba bước cụ thể cho bất kỳ lãnh đạo ngân hàng nào chịu trách nhiệm về việc đưa AI ra. Thứ nhất, thay hội đồng phê duyệt thủ công bằng các tầng rủi ro được quyết một lần — chính là Cửa kiểm soát — để việc rủi ro thấp ngừng phải xếp hàng sau việc rủi ro cao. Thứ hai, chuyển những biện pháp kiểm soát được lặp lại nhiều nhất của anh/chị vào policy-as-code để con đường an toàn là con đường mặc định. Thứ ba, chỉ định một Người chịu trách nhiệm cho mọi quyết định AI trọng yếu và bảo đảm Sổ ghi tái dựng lại được quyết định đó. Bộ máy quản trị được thiết kế theo cách này không phải cái phanh của chương trình AI của anh/chị. Nó là cái làn cho phép chương trình đó đi.
Nguồn (Tier-1): US Federal Reserve / OCC / FDIC SR 26-2 (hướng dẫn rủi ro mô hình) · EU AI Act, Quy định 2024/1689, Điều 12 & 14 · Điều 22 GDPR · CFPB Reg B / ECOA về hành vi bất lợi · Luật AI Việt Nam 134/2025/QH15 + PDPL · UK SMCR · Moffatt v. Air Canada. Con số 2,6× của DORA lấy từ nghiên cứu Accelerate State of DevOps; con số ≈94% về golden path là dữ liệu kỹ thuật nền tảng được báo cáo (DZone, 2024), không phải một mốc tham chiếu của ngành ngân hàng; con số DBS 15→3 tháng trên hơn 1.500 mô hình là do DBS công bố — cần đối chiếu với nguồn sơ cấp trước khi dùng lại.