Không có gì là hoàn toàn thuê ngoài

Giả sử ở đầu hẻm có một quán phở rất ngon.

Ông chủ quán không biết nấu phở. Ông thuê một đầu bếp cực kỳ thông minh về làm việc. Người này nhớ khách nào thích nhiều hành, khách nào không ăn giá, biết sáng thứ Hai phải nấu ít nước lèo hơn, biết tháng mưa giá xương thường tăng, biết nhà cung cấp nào hay giao thịt trễ và biết phải nêm thêm nửa muỗng muối khi trời lạnh.

Mỗi ngày, ông chủ chỉ việc đứng trước cửa cười hiền lành, thu tiền và cảm thấy cuộc đời thật đơn giản.

Cho đến một buổi sáng, người đầu bếp nghỉ việc.

Ông ta mang theo toàn bộ công thức, danh sách nhà cung cấp, thói quen khách hàng, cách xử lý khi bếp hỏng và cả ký ức về hàng nghìn tô phở đã từng nấu.

Quán vẫn còn bàn ghế.

Nồi vẫn còn đó.

Biển hiệu vẫn sáng.

Nhưng cái làm cho quán phở trở thành quán phở ấy đã biến mất.

Đây gần như là điều Satya Nadella, CEO Microsoft, đang cảnh báo các doanh nghiệp khi họ giao toàn bộ hoạt động AI cho một nhà cung cấp duy nhất.

Trong cuộc phỏng vấn trên chương trình Fareed Zakaria GPS ngày 26 tháng 7 năm 2026, Nadella cho rằng một công ty không giữ quyền kiểm soát dữ liệu, prompt, memory, metadata và lớp điều phối AI có nguy cơ không còn tồn tại như một công ty độc lập, bởi vì nó đã “thuê ngoài khả năng suy nghĩ” của mình.

Nghe hơi kịch tính.

Một công ty làm sao có thể chết chỉ vì dùng một con AI?

Nhưng vấn đề không nằm ở con AI.

Vấn đề nằm ở cuốn sổ công thức mà chúng ta âm thầm đưa cho nó mỗi ngày.

Nghịch lý thông tin ngược

Trước đây, nhà kinh tế Kenneth Arrow từng mô tả một nghịch lý của việc mua bán thông tin.

Người mua chưa thể biết thông tin có giá trị hay không trước khi nhìn thấy nó. Nhưng một khi đã được xem, người mua gần như đã nhận được thông tin mà chưa cần mua.

Người bán phải hé bí mật để chứng minh rằng bí mật ấy đáng tiền.

Trong thời đại AI, Nadella cho rằng nghịch lý này bị lật ngược.

Bây giờ người mua mới là người phải hé bí mật.

Muốn AI viết một email chung chung, chúng ta chỉ cần đưa cho nó vài dòng.

Muốn AI viết đúng giọng của giám đốc, chúng ta phải cho nó đọc những email cũ.

Muốn AI tư vấn tồn kho, chúng ta phải cho nó xem sản phẩm, doanh số, lịch khuyến mãi, tình trạng giao hàng và hành vi khách hàng.

Muốn AI tìm nguyên nhân doanh thu giảm, chúng ta phải mở tiếp dữ liệu cửa hàng, nhân viên, đối thủ, thời tiết, giá bán, tỷ lệ hết hàng và hàng trăm thứ nhỏ li ti khác.

AI càng hữu ích, doanh nghiệp càng phải kể cho nó nghe nhiều chuyện.

Từng prompt bay qua mạng.

Từng tài liệu được cắt thành những đoạn nhỏ.

Từng kết quả được người dùng sửa lại.

Từng lần nhân viên bấm nút “câu trả lời này chưa đúng”.

Từng lỗi sai, từng phản hồi, từng tiêu chí đánh giá chảy qua hệ thống như một dòng nước vô hình.

Nhưng đó không phải nước thải.

Đó là kinh nghiệm của doanh nghiệp đang bị nghiền thành dữ liệu.

Trong bài viết The Reverse Information Paradox, Nadella gọi phần dữ liệu phát sinh này là những dấu vết gồm prompt, tool call, feedback, evaluation và các lần sửa lỗi. Mỗi lần con người sửa AI là một mẩu kiến thức nội bộ được biểu diễn rõ ràng hơn: công ty xem điều gì là đúng, điều gì là sai và thành công được đo bằng cách nào.

Nói đơn giản hơn, khi một nhân viên sửa câu trả lời của AI từ:

“Sản phẩm này bán chậm vì nhu cầu thấp.”

thành:

“Sản phẩm bán chậm chủ yếu vì 42% cửa hàng miền Nam hết hàng trong ba ngày khuyến mãi.”

nhân viên ấy không chỉ sửa một câu văn.

Họ vừa dạy hệ thống cách doanh nghiệp phân tích nguyên nhân.

Hàng triệu chỉnh sửa như vậy hợp lại thành một thứ rất gần với trí nhớ tổ chức.

Dùng AI không có nghĩa là nhà cung cấp đang lấy dữ liệu đi huấn luyện

Ở đây cần làm rõ một chuyện để chúng ta không cầm đuốc chạy quanh làng và hét rằng mọi công ty AI đều đang ăn cắp dữ liệu.

OpenAI công bố rằng dữ liệu từ các sản phẩm doanh nghiệp và API không được dùng để huấn luyện mô hình theo mặc định. Anthropic cũng công bố chính sách tương tự cho các sản phẩm thương mại và Anthropic API.

Như vậy, cảnh báo của Nadella không nên được hiểu đơn giản là:

“Nhà cung cấp AI chắc chắn đang lấy prompt của bạn để huấn luyện model.”

Rủi ro lớn hơn và âm thầm hơn là doanh nghiệp không tự lưu lại quá trình học của chính mình.

AI trả lời xong.

Nhân viên sửa lại.

Công việc hoàn thành.

Cửa sổ chat đóng xuống.

Một bài học vừa xuất hiện rồi tan vào hư không.

Doanh nghiệp vẫn trả tiền token, nhưng không thu được phần tài sản quan trọng nhất: lý do vì sao câu trả lời đầu tiên sai và câu trả lời thứ hai đúng.

Ngay cả khi nhà cung cấp không dùng dữ liệu ấy để train model, doanh nghiệp vẫn có thể mất nó vì toàn bộ memory, workflow, prompt, evaluation và lịch sử hoạt động đang nằm bên trong một sản phẩm mà mình không kiểm soát hoàn toàn.

Đó mới là chỗ đáng sợ.

Không phải ai đó lấy bộ não của chúng ta.

Mà là chúng ta chưa từng nghĩ đến chuyện mang bộ não ấy về nhà.

Cái bẫy của một AI cho mọi thứ

Ở giai đoạn đầu, dùng một model cho tất cả là lựa chọn rất hợp lý.

Một API key.

Một SDK.

Một kiểu prompt.

Một hóa đơn.

Một nhóm hỗ trợ để gọi khi hệ thống bốc khói.

Xong kiến trúc, quá dễ.

Nhưng rồi ứng dụng bắt đầu lớn lên.

Model được dùng để viết email, tìm kiếm sản phẩm, phân tích hợp đồng, tạo SQL, viết code, trả lời khách hàng, tóm tắt cuộc họp và quyết định xem một giao dịch có bất thường hay không.

Khi đó, vấn đề bắt đầu xuất hiện.

Không có một model nào luôn tốt nhất cho mọi việc.

Một model reasoning lớn có thể giải bài toán khó tốt nhưng đắt và chậm.

Một model nhỏ có thể phân loại yêu cầu trong vài trăm mili giây.

Một model open-weight chạy nội bộ có thể phù hợp với dữ liệu nhạy cảm.

Một model khác lại hiểu hình ảnh hoặc giọng nói tốt hơn.

Một model giỏi tiếng Anh chưa chắc đã xử lý tên sản phẩm, địa chỉ và cách nói của người Việt tốt bằng model khác.

Nếu mọi luồng xử lý đều gọi thẳng một nhà cung cấp, doanh nghiệp sẽ dần buộc hàng trăm sợi dây vào cùng một chiếc cọc.

Chiếc cọc ấy thay đổi giá, doanh nghiệp đau.

Model bị ngừng cung cấp, doanh nghiệp đau.

Chính sách giới hạn thay đổi, doanh nghiệp đau.

SDK đổi cấu trúc tool calling, doanh nghiệp lại ngồi sửa code trong đêm.

Đây không còn là lựa chọn model.

Đây là vendor lock-in trên quy mô nhận thức.

Model không phải toàn bộ hệ thống AI

Một hệ thống AI doanh nghiệp thường có ít nhất sáu phần:

Model: Bộ máy nhận prompt và tạo câu trả lời.
Context: Dữ liệu được đưa vào cho từng yêu cầu.
Memory: Những gì hệ thống nhớ qua nhiều lần tương tác.
Tools: API, database, trình duyệt, hệ thống đặt hàng hoặc các công cụ mà agent được phép sử dụng.
Harness hoặc orchestration: Luồng điều khiển quyết định gọi model nào, gọi tool nào, lặp lại bao nhiêu lần và khi nào cần con người xác nhận.
Evals và traces: Dữ liệu dùng để đo chất lượng, theo dõi quyết định và học từ các lỗi đã xảy ra.

Model giống như đầu bếp.

Harness là căn bếp.

Tools là dao, thớt, bếp ga và tủ lạnh.

Context là nguyên liệu được mang ra trong hôm nay.

Memory là cuốn sổ ghi khách quen thích ăn gì.

Evals là người nếm thử và tuyên bố nồi canh này ngon hay đang có vị giống nước rửa chén.

Sai lầm của nhiều doanh nghiệp là thuê đầu bếp rồi tiện tay giao luôn căn bếp, sổ công thức, danh sách khách quen và quyền quyết định món nào được xem là ngon.

Nadella cho rằng harness, context và memory cần được tách khỏi model. Khi đó, doanh nghiệp có thể thay một model mà hệ thống vẫn tiếp tục hoạt động.

Kiến trúc AI mà doanh nghiệp nên sở hữu

Một kiến trúc đơn giản có thể được hình dung như sau:

 1Người dùng và ứng dụng nội bộ
 2               |
 3               v
 4       API / AI Gateway
 5               |
 6               v
 7    Policy, Auth, Rate Limit
 8               |
 9               v
10     Orchestrator / Harness
11        /       |       \
12       v        v        v
13 Model A     Model B   Model nội bộ
14       \        |        /
15        \       |       /
16         v      v      v
17    Tools, Context, Memory
18               |
19               v
20     Traces, Feedback, Evals

Điểm quan trọng không phải là sơ đồ có nhiều hộp.

Điểm quan trọng là các tài sản nằm phía dưới model phải thuộc quyền kiểm soát của doanh nghiệp.

AI Gateway

Thay vì để từng ứng dụng gọi trực tiếp OpenAI, Anthropic, Google hoặc một model nội bộ, tất cả request đi qua một cổng chung.

Ví dụ, ứng dụng chỉ biết một endpoint:

1POST /llm/v1/chat/completions

Phía sau cánh cửa này, gateway có thể:

Xác thực người dùng và ứng dụng.
Che giấu API key của nhà cung cấp.
Ghi nhận token, latency và chi phí.
Chặn dữ liệu nhạy cảm.
Áp dụng rate limit.
Chuyển request sang model phù hợp.
Failover khi một model gặp lỗi.
Thay model mà không cần sửa từng ứng dụng.

Microsoft hiện cũng mô tả AI Gateway và Unified Model API theo hướng này: một giao diện chung có thể đứng trước nhiều backend, chuẩn hóa request, tập trung observability, governance và hỗ trợ chuyển đổi hoặc failover giữa các nhà cung cấp.

AI Gateway không tự động chữa được mọi bệnh.

Nhưng ít nhất nó giúp doanh nghiệp cầm lại tay lái.

Context và memory riêng

Dữ liệu khách hàng, lịch sử xử lý, tài liệu, vector database và memory dài hạn không nên bị nhúng cứng vào một sản phẩm duy nhất.

Model có thể thay.

Memory phải còn.

Hôm nay hệ thống dùng model A để tư vấn khách hàng.

Ngày mai model B rẻ hơn hoặc trả lời tiếng Việt tốt hơn.

Hai model vẫn phải nhìn thấy cùng một lịch sử khách hàng, cùng chính sách bán hàng và cùng trạng thái đơn hàng.

Không nên để mỗi lần đổi model là một lần hệ thống mất trí nhớ như ông cụ vừa ngủ dậy giữa trưa và không biết vì sao mình đang cầm cây chổi.

Bộ eval thuộc về doanh nghiệp

Đây có lẽ là phần bị xem nhẹ nhất.

Mỗi doanh nghiệp có một định nghĩa khác nhau về câu trả lời “tốt”.

Với chatbot chăm sóc khách hàng, câu trả lời tốt có thể là:

Đúng chính sách.
Không hứa sai quyền lợi.
Không tiết lộ dữ liệu cá nhân.
Không tự ý tạo đơn hàng.
Hỏi xác nhận trước hành động quan trọng.
Dùng cách xưng hô phù hợp.
Trả lời trong dưới hai giây.

Một benchmark chung trên Internet không thể đo hết những thứ ấy.

Doanh nghiệp cần một bộ eval riêng, chẳng hạn:

 1{
 2  "question": "Khách muốn đổi máy lạnh đã sử dụng 20 ngày",
 3  "expected_behavior": [
 4    "Kiểm tra chính sách đổi trả",
 5    "Không tự hứa chắc chắn được đổi",
 6    "Thu thập mã đơn hàng",
 7    "Chuyển nhân viên khi thiếu dữ liệu"
 8  ],
 9  "forbidden_behavior": [
10    "Bịa chính sách",
11    "Tự tạo yêu cầu đổi hàng",
12    "Yêu cầu khách gửi mật khẩu"
13  ]
14}

Sau đó, mỗi model mới phải thi trên cùng bộ đề.

Model nào điểm cao, chi phí phù hợp và latency chấp nhận được thì được đưa vào production.

Model nào nói hay như triết gia nhưng cứ bịa chính sách đổi trả thì mời về nhà suy ngẫm thêm.

Multi-model không có nghĩa là gọi ngẫu nhiên nhiều model

Dùng nhiều model không phải là tung đồng xu.

Một router tốt phải dựa trên loại công việc, độ nhạy cảm, chi phí, độ trễ và chất lượng mong muốn.

Ví dụ:

 1def choose_model(request):
 2    if request.contains_sensitive_data:
 3        return "internal-model"
 4
 5    if request.task == "classification":
 6        return "small-fast-model"
 7
 8    if request.task == "complex-reasoning":
 9        return "reasoning-model"
10
11    if request.task == "vietnamese-customer-support":
12        return "best-vietnamese-model"
13
14    return "default-model"

Phiên bản production chắc chắn phức tạp hơn đoạn code này rất nhiều.

Nhưng ý tưởng cốt lõi lại khá đơn giản:

Ứng dụng yêu cầu một năng lực, không yêu cầu một tên model.

Ứng dụng nên nói:

1Tôi cần phân loại ý định khách hàng.

Thay vì nói:

1Hãy gọi chính xác model XYZ phiên bản 2026-07-15.

Tên model là chi tiết triển khai.

Năng lực mới là thứ doanh nghiệp thực sự cần.

Doanh nghiệp nên làm gì từ hôm nay?

Không phải công ty nào cũng cần mua một cụm GPU khổng lồ rồi tự huấn luyện model từ đầu.

Đó là cách nhanh nhất để biến một bài toán kiến trúc thành một đám cháy ngân sách.

Một lộ trình thực tế hơn có thể bắt đầu từ những việc nhỏ.

Bước 1: Biết dữ liệu đang đi đâu

Lập danh sách:

Ứng dụng nào đang dùng AI.
Đang dùng tài khoản cá nhân hay gói doanh nghiệp.
Dữ liệu nào được gửi ra ngoài.
Provider lưu dữ liệu trong bao lâu.
Có bật chia sẻ dữ liệu để cải thiện model hay không.
Ai có quyền xem lịch sử trò chuyện.
Có thông tin khách hàng, source code hoặc bí mật kinh doanh trong prompt hay không.

Nhiều công ty chưa cần một chiến lược AI vĩ đại.

Họ cần biết nhân viên đang copy gì vào cửa sổ chat lúc 10 giờ sáng.

Bước 2: Đưa request qua một gateway chung

Không để mỗi phòng ban tự cất một API key dưới gối.

Gateway tạo ra một điểm kiểm soát cho authentication, logging, quota, data masking và chi phí.

Ngày mai đổi model, ứng dụng phía trước không cần đập đi xây lại.

Bước 3: Lưu traces và feedback

Với mỗi request quan trọng, nên giữ lại:

Prompt đã được chuẩn hóa.
Context được cung cấp.
Model và phiên bản.
Tool đã được gọi.
Kết quả trả về.
Thời gian xử lý.
Chi phí token.
Phản hồi của người dùng.
Câu trả lời sau khi con người chỉnh sửa.
Quyết định cuối cùng.

Không phải để theo dõi nhân viên như camera treo trên đầu.

Mục tiêu là biến mỗi lỗi sai thành dữ liệu học tập của tổ chức.

Bước 4: Xây bộ eval trước khi xây thêm agent

Nếu chưa có cách đo chất lượng, thêm nhiều agent chỉ khiến hệ thống sai theo một cách hoành tráng hơn.

Hãy bắt đầu bằng 50 đến 100 tình huống thực tế.

Chạy tất cả model trên cùng bộ dữ liệu.

So sánh chất lượng, chi phí, latency và tỷ lệ vi phạm chính sách.

Đừng chọn model vì bảng xếp hạng đẹp.

Hãy chọn model vì nó làm tốt công việc của mình.

Bước 5: Chuẩn bị phương án thay thế

Đặt một câu hỏi khá tàn nhẫn:

Nếu ngày mai model đang dùng biến mất, hệ thống còn hoạt động được bao nhiêu phần trăm?

Nếu câu trả lời là 0%, doanh nghiệp không có ứng dụng AI.

Doanh nghiệp đang có một chiếc điều khiển từ xa nối vào máy của người khác.

Mặt trái của kiến trúc nhiều model

Tách model khỏi hệ thống không miễn phí.

Doanh nghiệp sẽ phải đối mặt với:

Nhiều API và định dạng khác nhau.
Khác biệt trong tool calling.
Chất lượng đầu ra không đồng nhất.
Prompt chạy tốt trên model này nhưng dở trên model khác.
Công sức xây gateway, router và observability.
Chi phí duy trì bộ eval.
Quy trình bảo mật phức tạp hơn.
Khó debug khi request đi qua nhiều tầng.

Đôi khi sử dụng duy nhất một nhà cung cấp vẫn là lựa chọn đúng, đặc biệt với nhóm nhỏ đang cần đưa sản phẩm ra thị trường nhanh.

Vấn đề không phải là có dùng một model hay không.

Vấn đề là doanh nghiệp có thiết kế một cánh cửa để bước ra hay không.

Có thể hôm nay chúng ta chỉ sống trong một căn phòng.

Nhưng ít nhất hãy giữ chìa khóa.

Microsoft cũng được hưởng lợi từ lời cảnh báo này

Không thể bỏ qua một chi tiết khá thú vị.

Microsoft đầu tư lớn vào các phòng thí nghiệm AI, đồng thời bán cloud, model catalog, API Management, AI Gateway, model router và hạ tầng để doanh nghiệp vận hành nhiều model.

Khi Nadella nói doanh nghiệp không nên phụ thuộc hoàn toàn vào một model, Microsoft cũng đang bán cây cầu giúp doanh nghiệp đi từ model này sang model khác.

Do đó, lời cảnh báo này vừa có giá trị kỹ thuật, vừa phù hợp với lợi ích kinh doanh của Microsoft.

Hai điều ấy có thể cùng đúng.

Một người bán ô vẫn có thể nói đúng rằng trời sắp mưa.

Việc của chúng ta không phải là tức giận vì ông ấy có bán ô.

Việc của chúng ta là nhìn lên trời.

Tổng kết

Một doanh nghiệp không chết ngay lập tức vì dùng duy nhất một AI.

Nó chết chậm hơn.

Đầu tiên, prompt nằm bên nhà cung cấp.

Sau đó memory nằm bên nhà cung cấp.

Tiếp theo workflow, tool, traces và bộ eval cũng nằm bên nhà cung cấp.

Cuối cùng, doanh nghiệp vẫn còn nhân viên, máy tính, văn phòng và logo, nhưng không còn biết hệ thống đã học được gì, vì sao nó ra quyết định và phải làm thế nào nếu model biến mất.

Đó là lúc công ty không còn thuê một công cụ.

Công ty đã thuê luôn ký ức của mình.

Thông điệp quan trọng nhất từ cảnh báo của Satya Nadella không phải là phải tự huấn luyện một model khổng lồ hay từ bỏ các dịch vụ AI thương mại.

Thông điệp là:

Có thể thuê trí thông minh, nhưng đừng thuê ngoài quyền sở hữu quá trình học.

Model có thể đến rồi đi.

Provider có thể mạnh lên hoặc yếu xuống.

Giá token có thể giảm, context window có thể dài thêm và tên sản phẩm có thể thay đổi mỗi vài tháng.

Nhưng dữ liệu, memory, feedback, traces, evals và hiểu biết tích lũy từ hoạt động của doanh nghiệp phải ở lại.

Bởi vì trong thời đại AI, thứ quý nhất không chỉ là câu trả lời.

Thứ quý nhất là việc tổ chức đã học được gì sau mỗi câu trả lời ấy.

Doanh nghiệp giao hết bộ não cho một AI có thể không sống sót