Gemini nằm trong NetSuite: Khi AI nhúng thẳng vào ERP, ai sở hữu lớp quyết định – và ai chịu trách nhiệm khi nó sai?

Khi Oracle và Google Cloud công bố mở rộng quan hệ đối tác vào ngày 30 tháng 7, hầu hết các bản tin đều đọc nó theo một công thức quen thuộc: lại thêm một mô hình ngôn ngữ lớn gia nhập danh sách mà Oracle AI Agent Studio đã cung cấp từ tháng 10 năm 2025. OpenAI, Anthropic, Cohere, Meta, xAI, Google – tất cả đều đã có mặt trong thực đơn. Nếu dừng ở đó, câu chuyện chỉ là một mục bổ sung danh mục sản phẩm. Nhưng có một thứ đã thực sự thay đổi, và nó không nằm ở danh sách model. Thứ thay đổi là nơi trí tuệ cư trú. Oracle không chỉ đơn thuần làm cho Gemini có mặt trong bộ công cụ dành cho nhà phát triển hay hạ tầng đám mây – điều mà họ đã làm thông qua Oracle Cloud Infrastructure Enterprise AI từ tháng 8 năm 2025. Lần này, họ có kế hoạch nhúng Gemini 3.1 Flash-Lite và Gemini 3.5 Flash trực tiếp vào Fusion Applications và NetSuite – những hệ thống ERP, HCM, chuỗi cung ứng và CRM đang vận hành hoạt động thường nhật của hơn 14.000 tổ chức trên toàn cầu. Riêng NetSuite đã vươn tới hơn 44.000 khách hàng tại 220 quốc gia. Đó là một kiểu di chuyển khác hẳn. Thay vì đưa cho lập trình viên một model khác để họ tự nối vào quy trình tùy chỉnh, Oracle đang biến AI của Google thành một thành phần chuẩn của bản thân quy trình kinh doanh. Sự khác biệt này quan trọng, bởi vì khoảng cách triển khai trong AI doanh nghiệp không chủ yếu xoay quanh việc có hay không có quyền truy cập model. Nó xoay quanh ma sát khi đưa một mô hình từ bản thử nghiệm vào sản xuất thực tế. Tám mươi phần trăm doanh nghiệp đã nhúng AI ở một mức độ nào đó, nhưng chỉ 31 phần trăm thực sự đưa nó vào những quy trình tạo ra giá trị. Nhúng ở tầng ứng dụng, thay vì tầng hạ tầng, là con đường trực tiếp nhất để thu hẹp khoảng cách đó. Bất kỳ ai từng kiểm tra mã nguồn của một giao thức tài chính phi tập trung đều hiểu một điều: nơi một thành phần bên ngoài được gọi đến sẽ quyết định mức độ rủi ro mà nó mang vào hệ thống. Một oracle giá được gọi trong một hàm thanh khoản có khác gì một oracle giá được đọc từ một hợp đồng riêng biệt? Câu trả lời kỹ thuật là: khác rất nhiều. Khi thành phần bên ngoài nằm bên trong luồng quyết định, nó không còn là một bên thứ ba đáng tin cậy – nó trở thành một phần của chính sách vận hành. Điều tương tự đang diễn ra ở đây, nhưng ở quy mô doanh nghiệp và với một mô hình mà không một ai ở phía doanh nghiệp có thể đọc được từng dòng trọng số. Tôi đã nhìn thấy khuôn mẫu này trong một bối cảnh khác: khi tôi phân tích cơ chế mint/burn của Terra vào đầu tháng 5 năm 2022, điểm chết người không phải là thuật toán ổn định giá có đúng hay không, mà là việc toàn bộ hệ thống phụ thuộc hoàn toàn vào một oracle tập trung được nhúng vào quy trình tạo lập và đốt token. Khi oracle đó là trái tim của quy trình, sự sụp đổ không đến từ bên ngoài – nó đến từ chính giả định bên trong. Oracle AI Agent Studio và Google Cloud đang xây dựng một kiến trúc tương tự cho doanh nghiệp, và điều đáng chú ý là gần như không ai đặt câu hỏi về lớp trách nhiệm khi quyết định sai được tạo ra từ một hệ thống được nhúng chặt đến vậy. Hạ tầng cho sự tích hợp sâu này đã chín muồi. Fusion Applications của Oracle đã hỗ trợ Model Context Protocol và giao tiếp Agent-to-Agent kể từ bản phát hành 26A, mang đến cho các agent một cách chuẩn hóa để kết nối với công cụ bên ngoài và kết nối với nhau. Những giao thức đó tạo ra đường ống. Giờ đây, tầng nền tảng đang phản hồi bằng cách kéo các model lại gần hơn với những quy trình mà chúng được kỳ vọng sẽ tự động hóa. Về mặt cạnh tranh, thỏa thuận này là một tín hiệu rõ ràng. Salesforce có Agentforce. ServiceNow có Now Assist. Mọi nền tảng doanh nghiệp lớn đang chạy đua để sở hữu lớp agent, và những ai nhúng AI một cách tự nhiên nhất – thay vì chào bán nó như một tiện ích gắn thêm – sẽ có lợi thế trong một thế giới mà lỗi thực thi, chứ không phải ảo giác, là thứ giết chết các dự án triển khai. Một model chạy bên trong quy trình ERP, được quản trị bởi cùng các vòng phê duyệt và kiểm soát truy cập, sẽ thất bại theo một cách khác hẳn một model bị gắn từ bên ngoài vào. Câu hỏi không phải là liệu nó có thất bại hay không – mà là nó sẽ thất bại theo cách nào và ai sẽ nhìn thấy dấu hiệu từ trước. Satish Thomas, Phó chủ tịch Google Cloud, đã đóng khung mối quan hệ này như một chiến lược phân phối. Ông nói rằng các tổ chức trên khắp thế giới tin tưởng vào toàn bộ ngăn xếp AI của Google Cloud để vận hành các quy trình và agent quan trọng, và rằng quan hệ đối tác mở rộng với Oracle được thiết kế để giúp các tổ chức sử dụng Gemini trong các ứng dụng và quy trình agentic mà họ phụ thuộc hàng ngày. Kevin Ichhpurani, Chủ tịch Hệ sinh thái Đối tác Toàn cầu tại Google Cloud, phát biểu trực tiếp hơn: quan hệ đối tác này đưa các mô hình AI mạnh nhất của Google vào thẳng các quy trình ứng dụng lõi mà các doanh nghiệp toàn cầu tin cậy mỗi ngày, giúp việc áp dụng AI hiệu quả về chi phí trở nên liền mạch ngay tại nơi quyết định kinh doanh được đưa ra. Về phía Oracle, cách diễn giải của họ nghiêng về sự linh hoạt trong lựa chọn model trong một khuôn khổ được quản trị chặt chẽ. Chris Leone, Phó chủ tịch điều hành của Oracle, nhấn mạnh rằng các tổ chức cần sự linh hoạt để chọn ra mô hình AI phù hợp nhất với từng vấn đề cụ thể, và rằng việc đưa Gemini vào Oracle AI Agent Studio cho Fusion Applications giúp khách hàng có thêm sự lựa chọn khi họ xây dựng và mở rộng các agent cũng như ứng dụng agentic. Evan Goldberg, nhà sáng lập kiêm Phó chủ tịch điều hành của NetSuite, lại nối vấn đề với phân khúc doanh nghiệp vừa và nhỏ: AI là trọng tâm trong cách khách hàng sử dụng và trải nghiệm NetSuite, và việc lựa chọn đúng model cho đúng trường hợp sử dụng là yếu tố then chốt giúp họ thu được nhiều giá trị hơn từ AI. Những phát biểu này, khi đọc kỹ, đều xoay quanh một câu chuyện về sự lựa chọn và phân phối. Không một ai trong số họ nhắc đến điều tôi cho là phần quan trọng nhất của kiến trúc mới này: quyền lực quyết định. Khi một mô hình AI được nhúng vào quy trình phê duyệt chi tiêu, quy trình kiểm soát hàng tồn kho, hay quy trình quản lý quan hệ khách hàng, nó không chỉ là một công cụ hỗ trợ đưa ra khuyến nghị. Nó trở thành một nhân tố trong chuỗi trách nhiệm. Nhưng các mô hình ngôn ngữ lớn không phải là mã nguồn mở, không thể được kiểm toán dòng chảy quyết định theo cùng cách mà một hợp đồng thông minh có thể được kiểm toán. Tôi đã dành ra sáu tuần để kiểm tra mã nguồn của Bancor vào năm 2017, và tôi có thể đọc từng dòng Solidity, truy vết từng biến, mô phỏng từng kịch bản. Với một mô hình ngôn ngữ lớn được nhúng vào NetSuite, một kỹ sư kiểm toán sẽ đọc cái gì? Trọng số? Một API endpoint? Một quyết định mà ngay cả nhà phát triển cũng không thể giải thích đầy đủ tại sao nó lại được đưa ra? Một điều người ta hay bỏ qua là thỏa thuận này được công bố như một kế hoạch, không phải một sản phẩm đã hoạt động. Oracle có kèm theo tuyên bố miễn trừ trách nhiệm về sản phẩm trong tương lai, điều đó có nghĩa là hiệu suất thực tế của Gemini bên trong các quy trình doanh nghiệp vẫn chưa được kiểm chứng. Tầm nhìn thì rõ ràng – nhúng AI vào nơi công việc đang diễn ra – nhưng khâu thực thi sẽ quyết định liệu đây có phải là một chất xúc tác thực sự cho triển khai hay chỉ là một tính năng AI doanh nghiệp được công bố và rồi trì hoãn mãi. Thị trường dường như đặt cược vào sự lạc quan: cổ phiếu Oracle tăng 3,3 phần trăm trong ngày, với mức đỉnh nội phiên lên tới 8,4 phần trăm. Thị trường nền tảng agent AI doanh nghiệp được dự báo sẽ tăng từ 7,8 tỷ đô la vào năm 2025 lên 68,4 tỷ đô la vào năm 2034. Cả hai công ty đang định vị để chiếm lấy sự tăng trưởng đó bằng cách di chuyển trí tuệ từ bảng điều khiển dành cho nhà phát triển vào các ứng dụng mà doanh nghiệp đã phụ thuộc hàng ngày. Và đây chính là điều tôi muốn mổ xẻ. Khi trí tuệ được di chuyển từ bảng điều khiển nhà phát triển vào ứng dụng, bản chất của rủi ro cũng được di chuyển theo. Trong một hợp đồng thông minh, rủi ro lớn nhất thường không nằm ở đúng logic của hợp đồng – mà nằm ở những thành phần được mặc định là đáng tin cậy. Đó có thể là một oracle giá, một nguồn dữ liệu, hoặc một cơ chế mở khóa. Khi tôi phát triển bộ tiêu chí đánh giá rủi ro cho Aave vào năm 2020, tôi đã phát hiện ra một điểm yếu trong logic cập nhật lãi suất khi thanh khoản thay đổi đột ngột. Lỗi không nằm ở chỗ tính toán sai – mà nằm ở giả định rằng thanh khoản sẽ luôn biến động trong một biên độ an toàn. Ba tháng làm việc độc lập để đi đến một báo cáo ba mươi trang chỉ ra rằng điều kiện biên của một hệ thống tài chính thường nằm ở những nơi mà các nhà thiết kế ít ngờ tới nhất. Điều kiện biên trong kiến trúc AI agent doanh nghiệp nằm ở đâu? Không phải ở độ chính xác của model trên benchmark. Nó nằm ở khả năng model đó bị thao túng, bị phá hoại, hoặc đơn giản là bị đặt vào một tình huống mà dữ liệu đầu vào nằm ngoài phân phối mà nó từng được huấn luyện. Trong một hệ thống ERP được nhúng AI, một prompt injection có thể không cần phải thao túng trực tiếp model mà hoạt động thông qua dữ liệu mà model xử lý. Một trường dữ liệu nhập từ một nhà cung cấp, được đọc bởi một agent tự động, có thể trở thành vector tấn công. Thị trường chứng khoán phản ứng tích cực với thông báo này vì nó hứa hẹn sự thuận tiện, nhưng trong bảo mật, sự thuận tiện luôn phải trả giá bằng một lớp phòng thủ bị nới lỏng. Câu hỏi đặt ra không phải là liệu Google và Oracle có xây dựng các vòng kiểm soát truy cập chặt chẽ hay không – chắc chắn là họ sẽ làm. Câu hỏi là liệu có ai đã nghĩ đến kịch bản model đưa ra một quyết định nghe rất hợp lý nhưng nó đến từ một sự thiên vị không thể giải thích, trong một quy trình mà kết quả không thể bị gỡ lại sau khi đã thực thi. Và điều đó dẫn tôi đến một kịch bản cực đoan. Năm 2022, tôi đã viết một tweet thread vào ngày 3 tháng 5, chỉ ra rằng nếu thanh khoản của LUNA giảm dưới ngưỡng hai tỷ đô la, thuật toán ổn định của Terra sẽ sụp đổ. Hầu hết mọi người đều nghĩ đó là sự bi quan thái quá. Sáu ngày sau, mọi thứ sụp đổ. Không phải vì tôi đoán được tương lai, mà vì tôi đã mô phỏng kịch bản xấu nhất dựa trên một giả định đơn giản: hệ thống tin cậy vào một nguồn duy nhất, và nguồn đó biến mất. Trong kiến trúc mà Oracle và Google đang xây dựng, nguồn duy nhất đó không phải là một oracle giá, mà là một nhà cung cấp AI duy nhất được nhúng vào quy trình lõi. Nếu Gemini gặp sự cố, nếu nó bị tấn công, nếu nó đơn giản là bị đình chỉ vì vi phạm quy định nào đó – hàng chục nghìn doanh nghiệp có ngừng hoạt động không? Đây không phải một câu hỏi mang tính suy đoán xa vời. Cơ sở hạ tầng quan trọng đang trở nên phụ thuộc vào một lớp trí tuệ tập trung, và việc để cho một lớp trí tuệ như vậy trở thành một phần của quy trình tạo ra quyết định mà không có kế hoạch dự phòng chi tiết, không có cơ chế kiểm toán mở, là một rủi ro mà các thị trường chứng khoán không phản ánh trong mức tăng 3,3 phần trăm của cổ phiếu Oracle. Trong blockchain, chúng ta gọi đó là điểm tập trung thất bại. Trong quản trị doanh nghiệp, nó được gọi là rủi ro tập trung hóa – một thuật ngữ mà các giám đốc điều hành thích tránh xa. Có một trớ trêu trong câu chuyện này. Oracle, một công ty xây dựng đế chế từ những hệ thống cơ sở dữ liệu được kiểm soát chặt chẽ và quản trị chặt chẽ, đang nhúng một mô hình AI có bản chất là một hộp đen vào các quy trình mà sự tuân thủ và khả năng kiểm toán là yếu tố sống còn. Google Cloud đang chạy đua để trở thành nhà cung cấp công cụ AI đi mặc định cho hàng chục nghìn doanh nghiệp, trong khi phần lớn các doanh nghiệp đó thậm chí không nhận thức được rằng câu chuyện này không nằm ở chất lượng của mô hình – mà nằm ở việc họ đã đưa một nhân tố không thể kiểm soát hoàn toàn vào ngay giữa hiện trường nơi công việc hằng ngày được thực hiện. Từ kinh nghiệm của mình, điều mà tôi học được nhiều nhất sau tất cả các cuộc kiểm toán – từ Bancor, từ Aave, từ LooksRare, từ Terra – là rằng thứ giết chết một hệ thống không bao giờ là thứ mà mọi người đều chú ý đến. Năm 2022, khi phân tích mô hình on-chain của LooksRare, tôi phát hiện ra cơ chế stake-to-earn tạo ra một vòng tuần hoàn giả tạo: người dùng stake token để được thưởng, nhưng phần thưởng đến từ phí giao dịch do chính họ tạo ra. Tất cả đều trông có vẻ bền vững, cho đến khi bạn nhận ra rằng nguồn duy nhất của dòng tiền là chính niềm tin của những người tham gia. Khi một thứ gì đó được tin tưởng làm nền tảng, rủi ro thực sự nằm ở chỗ niềm tin đó được tạo ra từ đâu. Trong trường hợp của Gemini và NetSuite, niềm tin đến từ thương hiệu của Google và Oracle, chứ không phải từ việc hiểu rõ cách hệ thống đưa ra quyết định – và điều đó khiến tôi cảnh giác. Không hiểu lầm tôi: tôi không phản đối việc sử dụng AI trong doanh nghiệp. Tôi chỉ phản đối cách chúng ta đang chấp nhận một kiến trúc mà trong đó một thực thể không thể kiểm toán được nắm giữ vai trò trung tâm trong các quyết định kinh doanh, mà không một khuôn khổ kiểm toán tương đương với những gì ngành công nghiệp blockchain đã phát triển cho các hợp đồng thông minh. Khi tôi xây dựng bộ công cụ Solidity+AI Analyzer vào cuối năm 2025 để kiểm tra tính nhất quán giữa đầu vào oracle AI và logic on-chain, tôi nhận ra rằng ranh giới giữa một quyết định được đưa ra bởi con người có sự trợ giúp của AI và một quyết định được ủy thác cho AI là vô cùng mong manh. Điều duy nhất giữ cho ranh giới đó tồn tại là khả năng một bên thứ ba có thể xem xét, truy vết và phản bác quyết định đó. Nếu không có khả năng này, thì không có khác biệt thực chất giữa một doanh nghiệp vận hành bởi một AI được nhúng và một doanh nghiệp vận hành bởi một quy trình không ai hiểu được. Câu chuyện của Oracle và Google Cloud không phải là một câu chuyện về công nghệ. Nó là một câu chuyện về sự phân phối quyền lực và trách nhiệm. Ai đó sẽ phải trả lời câu hỏi này: khi một quyết định sai được đưa ra bởi một mô hình AI nằm trong NetSuite, khách hàng sẽ kiện ai – Google vì mô hình, Oracle vì sự tích hợp, hay chính doanh nghiệp vì đã tin vào quy trình của chính mình? Tôi chưa thấy điều khoản hợp đồng nào trả lời câu hỏi đó một cách thỏa đáng. Và trong một thị trường mà cổ phiếu Oracle tăng vọt sau thông báo, tôi thấy một sự lặp lại của một bài học cũ: deposit xong rồi, rủi ro mới bắt đầu. Với các doanh nghiệp, khoản tiền gửi của họ không phải là tiền – mà là vận hành, danh tiếng và sự liên tục. Các giám đốc điều hành nhìn thấy lời hứa về sự tự động hóa và hiệu quả, điều mà các hội đồng quản trị thích nghe. Nhưng một người từng dành 6 tuần để đọc từng dòng mã Solidity hiểu rằng lời hứa luôn nằm ở bề mặt; rủi ro luôn nằm ở những gì xảy ra khi điều kiện biên bị phá vỡ. Điều gì xảy ra khi một mô hình nhúng đưa ra một quyết định đúng về mặt thống kê nhưng sai về mặt đạo đức? Điều gì xảy ra khi một agent tự động thực hiện một giao dịch trị giá hàng triệu đô la dựa trên một chuỗi suy luận mà không ai có thể giải thích? Và điều gì xảy ra khi – không phải nếu – một lỗ hổng bảo mật được tìm thấy trong lớp tích hợp này và các bản vá không thể phát hành nhanh như một bản vá trên mã nguồn mở? Deposit xong rồi, rủi ro mới bắt đầu. Với hàng chục nghìn tổ chức đang sử dụng NetSuite và Fusion Applications, việc nhúng Gemini không phải là dấu chấm hết cho câu chuyện AI doanh nghiệp. Nó là điểm khởi đầu cho một câu chuyện mới về kiểm soát – một câu chuyện mà ở đó, các nhà kiểm toán như tôi sẽ có rất nhiều việc phải làm. Chúng ta có thể sẽ cần một bộ tiêu chí đánh giá rủi ro hoàn toàn mới cho các hệ thống mà quyết định đến từ một hộp đen. Câu hỏi cuối cùng, và cũng là câu hỏi đáng lo nhất, là liệu thị trường có đang định giá đúng những gì đang xảy ra, hay liệu chúng ta đang lặp lại một khuôn mẫu quen thuộc: tin tưởng vào một mô hình vì thương hiệu, để rồi một ngày nào đó nhận ra rằng điều duy nhất chúng ta không thể kiểm toán được chính là thứ đang điều khiển mọi thứ. Tôi không có câu trả lời, nhưng tôi biết cách kiểm tra nó. Và lần kiểm tra này sẽ không chỉ đọc mã nguồn – nó sẽ đọc cả những gì không được viết ra.