Một ý tưởng lớn

Hệ thống AI của anh/chị có ba nhà cung cấp. Nhưng có thể chỉ có một điểm phụ thuộc. Cả hai câu đó có thể cùng đúng, và khoảng trống giữa chúng chính là nơi sự cố gián đoạn tiếp theo đang chờ.

Tuần trước, bản tin này hỏi liệu hóa đơn có dự đoán được hay không. Tuần này nó hỏi một câu hẹp hơn và khó gỡ hơn: liệu anh/chị có thể rời đi hay không.

Phần lớn ngân hàng dừng lại ở câu thứ nhất, vì đó là câu mà danh sách nhà cung cấp chứng minh được. Và danh sách đó không sai — nó đang trả lời một câu hỏi khác. Đếm số nhà cung cấp không đo được mức độ tập trung. Nó chỉ đo anh/chị nhận bao nhiêu hóa đơn.

Hình dạng của nó như sau. Hai nhà cung cấp mô hình, được chọn cẩn thận, để có dự phòng thực sự. Cả hai được phục vụ qua cùng một cloud. Trong cùng một region. Trên cùng một dòng chip tăng tốc. Đó là một điểm phụ thuộc khoác hai logo, và hội đồng quản trị được báo cáo rằng hệ thống là đa nhà cung cấp — điều đó đúng, ở tầng mà hội đồng nhìn thấy.

Góc nhìn · Hai cơ quan quản lý, một danh sách ngắn

Ngày 18/11/2025, các Cơ quan Giám sát châu Âu công bố danh sách 19 nhà cung cấp công nghệ được chỉ định là bên thứ ba ICT trọng yếu của hệ thống tài chính. Không phải một lời cảnh báo. Một quyết định, có ngày tháng.

Tám tháng sau, vào tháng 7/2026, Vương quốc Anh chạy quy trình riêng biệt của mình và chỉ định 4, có hiệu lực từ 13/7/2026. 3 trong 4 là cùng những pháp nhân.

Hãy giữ lấy cụm từ pháp nhân, vì chính nó đang gánh việc. Chính xác là ba, và cái thứ tư thuộc cùng một tập đoàn nhưng dưới một pháp nhân khác — đó chính là điểm sụp mà bản tin này bàn tới, hiện ra ngay trong cơ chế chỉ định trước cả khi một ngân hàng mở sổ đăng ký của mình. Một ước tính của giới phân tích là một phương pháp anh/chị không thể kiểm tra. Một quyết định chỉ định là một quyết định anh/chị đọc được, do một cơ quan giám sát đưa ra khi có quyền truy cập các sổ đăng ký mà ngân hàng buộc phải duy trì.

Khối lượng nằm bên dưới giờ cũng đã được đo. Trong báo cáo tổng quan thường niên đầu tiên về các sự cố ICT nghiêm trọng, công bố ngày 03/6/2026, các cơ quan giám sát châu Âu ghi nhận 3.383 sự cố nghiêm trọng do các tổ chức tài chính trong EU báo cáo cho năm 2025 — 0,18 sự cố trên mỗi tổ chức thuộc phạm vi — và nêu tên lỗi hệ thống cùng các sự kiện bên ngoài là nguyên nhân chính, đồng thời nhấn mạnh sự cần thiết của một hệ thống quản trị rủi ro bên thứ ba vững chắc. Đó là một cơ quan giám sát phát biểu đúng lập luận của bản tin này, với 3.383 quan sát đứng sau.

Về quy mô, có một con số đang lưu hành rộng rãi và gần như luôn bị dẫn sai — kể cả bởi bản nháp đầu tiên của chính bản tin này. Ba nhà cung cấp cloud lớn nhất chiếm khoảng ba phần tư mức sử dụng cloud trong các doanh nghiệp dịch vụ tài chính tại Vương quốc Anh. Hãy đọc kỹ các điều kiện, vì chúng quan trọng hơn chính con số. Nó đến từ chính báo cáo của các doanh nghiệp gửi Ngân hàng Trung ương Anh và Cơ quan Quản lý Ứng xử Tài chính trong khảo sát AI năm 2024 của hai cơ quan này, được dẫn lại trong báo cáo tháng 10/2025 của Hội đồng Ổn định Tài chính. Vậy nên đó là một khảo sát của cơ quan giám sát, do hai cơ quan quản lý tài chính thực hiện trên chính tập đối tượng mà họ quản lý — không phải phân tích của giới phân tích, không phải một phép đo thị phần, và không phải một cuộc tổng điều tra. Và nó là Vương quốc Anh, vốn không đồng nghĩa với ngành tài chính nói chung. Hãy dẫn nó như một cách đọc về một thị trường, hoặc đừng dẫn.

Cùng khảo sát đó mang một con số gần với trọng tâm hơn mà gần như không ai dùng: giữa hai vòng 2022 và 2024, tỷ trọng các nhà cung cấp được nêu tên thuộc về ba nhà cung cấp mô hình lớn nhất đã tăng từ 18% lên 44%. Một mức độ là hữu ích. Một mức độ được đo hai lần, trên cùng một tập đối tượng, bởi cùng hai cơ quan quản lý, thì tốt hơn.

Góc nhìn · Một điểm phụ thuộc không có hợp đồng

Cùng báo cáo đó có một dòng ít được chú ý hơn bất kỳ con số nào trong đó, và xứng đáng được chú ý hơn: các mô hình huấn luyện sẵn thường không đi kèm quan hệ hợp đồng chính thức nào, nhưng vẫn tạo ra rủi ro bên thứ ba. Từ thường là của chính báo cáo, và nó đáng được giữ lại.

Hãy nghĩ xem điều đó tác động thế nào tới các biện pháp kiểm soát của anh/chị. Một khung quản trị rủi ro bên thứ ba bắt đầu bằng việc yêu cầu hợp đồng. Ở tầng mô hình có thể không có hợp đồng nào. Khung này không thất bại một cách ồn ào — nó không tìm thấy gì, không báo cáo gì, và điểm phụ thuộc vẫn vô hình.

Và một biện pháp kiểm soát trả về kết quả sạch vì nó không có gì để bám vào thì, trên dashboard, trông y hệt một biện pháp kiểm soát đã đạt.

Khung tư duy của tuần · The Vendor Concentration Heatmap

Sáu tầng, không phải một danh sách nhà cung cấp, sắp theo đúng đường đi thực tế của một yêu cầu. Đây là cách phân chia do tác giả đề xuất, không phải một chuẩn mực đã được phê chuẩn — và cụ thể là không phải khung chuỗi cung ứng năm tầng mà tài liệu về ổn định tài chính làm việc với, vốn là một công cụ khác cho một mục đích khác.

  • C1 · Model — dòng foundation model tạo ra câu trả lời, và cả phiên bản: việc ngừng hỗ trợ một phiên bản là một cuộc chuyển đổi bắt buộc mà anh/chị không lên lịch.
  • C2 · Inference và serving — ai vận hành mô hình, trên năng lực tính toán của ai, theo điều khoản của ai. Giới hạn tốc độ quyết định failover là một kế hoạch hay chỉ là một câu văn.
  • C3 · Cloud và region — hạ tầng tính toán bên dưới, và nó đặt ở đâu. Nêu tên region, rồi hỏi nhà cung cấp thứ hai chạy trên gì.
  • C4 · Dữ liệu và embedding — vector store và embedding model. Điểm khóa chặt (lock-in) lặng lẽ nhất trong stack.
  • C5 · Công cụ và điều phối — agent framework, bộ khung đánh giá, tầng observability. Hiếm khi được kiểm kê như một điểm phụ thuộc.
  • C6 · Lối thoát — các quyền theo hợp đồng, khả năng chuyển đổi, và liệu điều gì trong số đó đã từng được thực thi hay chưa.

Rồi đến phần làm cho nó có giá trị chẩn đoán: chấm mỗi tầng hai lần. Hỏi rời khỏi nó khó đến mức nào. Rồi hỏi, tách riêng, điều gì xảy ra nếu nó ngừng. Đó là hai câu hỏi khác nhau với câu trả lời khác nhau, và ô nóng nhất ở mỗi cột là một tầng khác nhau.

Tầng có thể làm sập dịch vụ là C3 — tầng mà các hội đồng đã hỏi đến. Tầng khó rời bỏ nhất là C4, tầng gần như không ai đưa vào chương trình họp. Để thay mô hình chuyển tài liệu của anh/chị thành vector, anh/chị không chỉ đổi một thiết lập. Anh/chị phải embed lại toàn bộ kho dữ liệu. Rồi kiểm định lại mọi kết quả truy xuất từng phụ thuộc vào mô hình cũ. Theo cách tôi đọc bối cảnh tiêu chuẩn hiện nay, không có chuẩn khả chuyển nào cho lưu trữ vector để mang phần việc đó sang — và tôi xin đánh dấu đó là một đánh giá chứ không phải một phát hiện, vì tôi chưa xác lập nó dựa trên văn bản của chính một tổ chức tiêu chuẩn hóa.

Cần nói chính xác, vì chính sự chính xác giúp nhận định đứng vững trước phản biện. C4 không phải tầng tốn kém nhất tính bằng tiền. Nó là tầng có ma sát kiến trúc cao nhất, và ma sát đó tăng dần theo quy mô kho dữ liệu, nghĩa là ngày rẻ nhất để xử lý nó luôn là một ngày trước hôm nay.

Tình huống ứng dụng · Pháp luật Việt Nam đã yêu cầu gì, và câu hỏi duy nhất còn bỏ ngỏ

Phiên bản dễ dãi của lập luận này là sai, nên đây là phiên bản cẩn trọng.

Theo Thông tư 09/2020/TT-NHNN, có hiệu lực từ 01/1/2021, cloud không bị cấm — hệ thống từ cấp độ ba trở lên có thể lên cloud khi đáp ứng các yêu cầu an toàn — và tổ chức phải hoàn thành đánh giá rủi ro trước khi sử dụng. Nghĩa vụ gửi báo cáo hẹp hơn nhiều so với cách nó thường được mô tả, và đây chính là câu tôi đã viết sai ở lần đầu. Đánh giá trước khi sử dụng tại Điều 33(1) là nghĩa vụ chung. Điều 33(3) bổ sung nghĩa vụ gửi bản đánh giá đó cho Ngân hàng Nhà nước chỉ trong trường hợp tổ chức thuê ngoài toàn bộ công việc quản trị hệ thống đó. Riêng việc dùng cloud không tự nó đặt một báo cáo lên bàn cơ quan quản lý. Điều 35 của cùng thông tư điều chỉnh hợp đồng với bên thứ ba, quyền sở hữu dữ liệu và việc hoàn trả dữ liệu khi chấm dứt — thứ gần nhất với một điều khoản C6 trong pháp luật Việt Nam, và đáng đọc trước kỳ gia hạn tiếp theo.

Theo Thông tư 13/2018/TT-NHNN, Điều 43 điều chỉnh rủi ro hoạt động phát sinh từ việc thuê ngoài. Nó vận hành bằng cách dẫn chiếu: nó áp dụng nghĩa vụ nhận diện — đo lường — theo dõi — kiểm soát tại Điều 42 cho rủi ro phát sinh từ thuê ngoài, và yêu cầu kế hoạch duy trì hoạt động kinh doanh liên tục tại Điều 46, do chính ngân hàng hoặc do nhà cung cấp xây dựng. Điều 42 đứng một mình là điều khoản chung về rủi ro hoạt động và không nhắc tới thuê ngoài, và đó là lý do việc dẫn đúng số điều quan trọng với bất kỳ ai tra lại văn bản.

Lưu ý cách dùng từ: luật Việt Nam nói duy trì hoạt động kinh doanh liên tục, không nói lối thoát. Nó có yêu cầu kế hoạch đó phải được kiểm thử ít nhất mỗi năm một lần, và kế hoạch dự phòng cho cloud phải được kiểm thử về khả năng sẵn sàng thay thế. Điều mà không văn bản Việt Nam nào yêu cầu là anh/chị phải kiểm thử việc thực sự rời khỏi một nhà cung cấp. Một phép thử failover bên trong một nhà cung cấp đúng là không phải một phép thử rời khỏi nhà cung cấp đó.

Và theo Luật Trí tuệ nhân tạo 134/2025/QH15, có hiệu lực từ 01/3/2026 theo Điều 34, nghĩa vụ được phân tách giữa nhà cung cấp và bên triển khai tại Điều 11 đến Điều 14. Thời gian chuyển tiếp 18 tháng đến 01/9/2027 nằm ở Điều 35(1)(a), và nó chỉ áp dụng cho các hệ thống thuộc ngành tài chính đã vận hành trước ngày luật có hiệu lực — một khoảng chạy đà cho những gì đang chạy, không phải một kỳ miễn trừ toàn ngành cho những gì anh/chị xây tiếp. Theo cách tôi đọc các nghĩa vụ của nhà cung cấp, một ngân hàng gắn thương hiệu của mình lên một ứng dụng AI sẽ chịu trách nhiệm với tư cách nhà cung cấp, kể cả khi mô hình được cấp phép từ bên khác; không điều khoản nào nói đúng chữ thương hiệu của chính mình, nên xin coi đó là cách diễn giải chứ không phải một căn cứ được trích nguyên văn.

Vậy đây là khoảng trống, và cũng là lập luận của cả số này. Ngân hàng đã chạy một bản đánh giá rủi ro trước khi go-live, và gửi nó đi trong trường hợp toàn bộ hệ thống nằm trong tay người khác. Bản đánh giá đó hỏi nhà cung cấp có đủ năng lực hay không. Nó không hỏi nhà cung cấp đứng trên nền tảng nào, hay đã có ai từng thử rời đi hay chưa. Không văn bản nào trong hai văn bản trên đặt ra nghĩa vụ định lượng về mức độ tập trung, và không văn bản nào yêu cầu phải kiểm thử việc rời khỏi một nhà cung cấp.

Đây không phải một thất bại về tuân thủ. Đó là một câu hỏi mà hồ sơ giấy tờ không chạm tới.

Lưu ý rủi ro · Phản biện mạnh nhất, trình bày đúng mức

Phản biện mạnh nhất với bản tin này không phải là bằng chứng còn mỏng. Mà là sự tập trung có thể tốt cho anh/chị.

Các nhà cung cấp cho rằng kỹ thuật đa availability zone, đa region và khoản đầu tư bảo mật của họ vượt xa những gì bất kỳ tổ chức đơn lẻ nào có thể tự xây. Ở cấp độ khả năng chống chịu của riêng một ngân hàng, điều đó nhiều khả năng là đúng.

Lập luận đó thường được chống đỡ bằng báo cáo tháng 12/2019 của Hội đồng Ổn định Tài chính về sự phụ thuộc vào bên thứ ba trong dịch vụ cloud, và tôi muốn trích chính xác thay vì tóm tắt, vì bản tóm tắt đang lưu hành mạnh hơn văn bản gốc. Hội đồng kết luận rằng dường như chưa có rủi ro tức thời đối với ổn định tài chính phát sinh từ việc các tổ chức tài chính sử dụng dịch vụ cloud. Cả hai lớp dè dặt đều là của chính Hội đồng. Việc ứng dụng cloud không gây rủi ro cho ổn định tài chính không phải là điều báo cáo nói, và diễn giải nó theo cách đó chính là động tác mà số này đã phàn nàn hai lần rồi.

Rồi hãy đọc xem chính báo cáo ấy đề nghị các cơ quan quản lý thảo luận thêm những gì. Ba việc: mức độ phù hợp của các chuẩn mực và thực tiễn giám sát đối với thuê ngoài, khả năng các cơ quan quản lý phối hợp và chia sẻ thông tin về các dịch vụ cloud mà ngân hàng sử dụng, và nỗ lực chuẩn hóa nhằm bảo đảm khả năng liên thông và khả năng chuyển dữ liệu trong môi trường cloud. Việc thứ ba đó chính là C4 và C6, do một cơ quan giám sát nêu tên, từ năm 2019, ngay bên trong văn bản mà phía phản biện dựa vào. Nó không chứng minh rằng hôm nay không tồn tại chuẩn khả chuyển nào — điều đó vẫn là đánh giá của tôi, không phải một phát hiện — nhưng mối lo này đã nằm trên hồ sơ như một phần việc còn dang dở từ trước khi phần lớn ngân hàng có một mô hình chạy trong production.

Các cơ quan giám sát phần lớn đáp rằng đó là sai tầm nhìn, vì khả năng chống chịu ở một tổ chức không phải là sự ổn định của cả hệ thống. Nhưng đó là lập luận ở cấp hệ thống, và một hội đồng đơn lẻ không thể hành động dựa trên nó.

Vì vậy nhận định được chủ động thu hẹp, về phiên bản đứng vững được: đa nguồn ở tầng mô hình không giải quyết sự phụ thuộc ở tầng cloud, và lối thoát chưa từng được kiểm thử. Nhận định đó hoàn toàn không tranh luận về kỹ thuật bảo đảm tính sẵn sàng.

Thêm ba giới hạn cần nói thẳng. C5 có thật nhưng thiếu bằng chứng — dạng lỗi mà nó dự báo, một thay đổi guardrail làm hành vi hệ thống thay đổi mà không báo trước, chưa có trường hợp công khai nào được ghi nhận mà nghiên cứu này tìm thấy. Hãy coi nó là khoảng trống trong tầm nhìn của anh/chị, không phải một sự cố chực chờ xảy ra. Con số về thị phần cloud là một khảo sát tại Vương quốc Anh, nên nó không nói lên điều gì chính xác về hệ thống của anh/chị và không nói gì cả về Việt Nam. Và không điều nào trong cơ chế của châu Âu là một nghĩa vụ tuân thủ đối với một ngân hàng Việt Nam: nó áp dụng cho các tổ chức tài chính EU, và nghĩa vụ giám sát không phải là trách nhiệm cá nhân đối với một sự cố gián đoạn — dù cũng nên biết rằng cơ chế đó có cho phép một quốc gia thành viên truy đến các thành viên của cấp quản lý cao nhất với tư cách cá nhân, ở nơi pháp luật quốc gia quy định như vậy và khi họ chịu trách nhiệm về một hành vi vi phạm quy định đó. Cả hai nửa đó đều đúng, và một tờ trình hội đồng bỏ đi nửa nào cũng gây hiểu nhầm.

Có một hình mẫu đáng học hỏi cho phép thử lối thoát thay vì chờ bị áp đặt. Theo cơ chế kiểm thử xâm nhập dựa trên mối đe dọa của EU, các tổ chức được xác định phải kiểm thử ít nhất 3 năm một lần, trên hệ thống production đang vận hành, vươn tới cả các hệ thống thuê ngoài cho bên thứ ba — và văn bản phạm vi kiểm thử do cấp quản lý cao nhất phê duyệt, rồi được cơ quan giám sát thẩm định lại. Chính lần thẩm định thứ hai đó mới là nửa làm cho chữ ký của hội đồng có sức nặng. Một ngân hàng nằm ngoài cơ chế đó có thể tự nguyện áp dụng cùng hình mẫu.

Hãy chọn một chức năng trọng yếu có dùng AI. Nêu tên điểm phụ thuộc ở cả sáu tầng. Chỗ nào chưa biết, ghi chưa rõ — ô trống trung thực chính là một phát hiện, và phần lớn ngân hàng tìm thấy ô trống của mình ở C5.

Rồi truy vết xuống dưới. Với mỗi mô hình anh/chị đã nêu, ghi lại nó thực sự chạy trên gì ở tầng suy luận và tầng cloud, và nêu tên region. Chỉ một bước đó thôi đã biến một danh sách nhà cung cấp thành một phép đo mức độ tập trung. Sau đó tìm điểm sụp: mọi chỗ mà hai hay nhiều lựa chọn tưởng như độc lập ở tầng trên quy về cùng một thứ ở bên dưới. Sự hội tụ đó chính là điểm nóng. Khi hai lựa chọn sụp về một, lãnh đạo nên coi chúng là một nhà cung cấp duy nhất — trong sổ đăng ký, trong hợp đồng, và trong kế hoạch phục hồi.

Bản phân tích chuyên sâu đầy đủ — hai quyết định chỉ định kèm số điều khoản, từng con số kèm tập đối tượng mà nó được đo, cả sáu tầng chấm trên cả hai trục, pháp luật Việt Nam yêu cầu gì theo từng điều, và phản biện ở mức mạnh nhất — nằm ở The Vendor Concentration Heatmap: Anh/chị chưa thực sự đa dạng hóa.

Playbook năm trang trong thư viện Frameworks biến nó thành một trang làm việc cho hệ thống của riêng anh/chị — sổ đăng ký sáu tầng kèm người chịu trách nhiệm, hai trục chấm điểm, và bài kiểm tra sáu câu hỏi kèm hình dung về một câu trả lời trượt. Miễn phí khi đăng nhập thành viên.

Tuần trước, về việc hóa đơn có dự đoán được hay không: The AI Unit-Economics Ledger — bài đó phụ trách chi phí. Chi phí chuyển đổi dưới dạng một mức giá nằm ở đó; chi phí chuyển đổi dưới dạng một điểm khóa chặt nằm ở đây. Và về việc câu trả lời có đúng hay không, thay vì anh/chị có rời đi được hay không: The Grounded-Knowledge Architecture.

Hãy trả lời thư này và cho tôi biết lần rà soát phụ thuộc AI gần nhất của anh/chị ghi nhận điều gì ở tầng cloud và region. Không phải những nhà cung cấp nào có tên trên hợp đồng — mà nhà cung cấp thứ hai thực sự chạy trên gì, và ở region nào. Ở phần lớn ngân hàng, ô đó đang trống, và chính ô trống là phát hiện. Tôi đọc mọi phản hồi. Hãy chuyển tiếp thư này cho một người vừa được báo rằng hệ thống của họ là đa nhà cung cấp.

Thư này được chuyển tiếp đến anh/chị? Đăng ký The AI Architect Letter — miễn phí, vào mỗi thứ Bảy.

Không tổ chức nào được nêu tên làm ví dụ ở bất kỳ đâu trong số này, và không ngân hàng, nhà cung cấp, nền tảng hay mô hình nào được nêu tên hoặc được xác nhận — đó là chính sách biên tập, vì nêu tên một ngân hàng trong một bài viết về sự phụ thuộc nhà cung cấp của ngân hàng đó sẽ hàm ý một quan hệ khách hàng mà chúng tôi không khẳng định. Đây là quan điểm độc lập, không liên kết với bất kỳ tổ chức nào nơi tác giả đang hoặc đã từng làm việc, và không thay thế cho việc rà soát pháp lý, tuân thủ và khả năng chống chịu hoạt động của chính anh/chị.

Minh Tran · AI Business Architect · LinkedIn · Workshop & tư vấn: aibusinessarchitect.ai