Thomas Kurian 如何把 Google Cloud 變成 AI 平台？基礎設施、Gemini、Agent 與治理

Thomas Kurian的 Google Cloud 故事，不能只用「把 Google 帶進雲端」或「推出 Gemini」一句話概括。真正值得拆解的是，他如何把基礎設施、資料、模型、開發平台、Agent、網路、安全與企業服務放在同一個可部署的系統裡。Google Cloud 官方資料在不同年份反覆使用 AI-optimized infrastructure、Vertex AI、Gemini、agents、open cloud、interoperability 與 trust 等詞，這些詞串起一條從硬體到治理的策略線。

本文以 2026 年 8 月 25 日可查到的 Google Cloud 官方資料為界，從 Thomas Kurian 的領導轉折、AI 基礎設施、Vertex AI 與 Gemini、Agent 平台、跨雲網路、企業安全與治理邊界，整理 Google Cloud 如何把 AI 從單一模型功能推向企業平台。官方部落格是公司自我描述，適合確認產品與策略語言，卻不是獨立市場份額、客戶 ROI 或財務成效報告；文章會刻意分開「公司宣布」「產品能力」「客戶使用」與「外部成果」四種證據。

先看Google Cloud 領導轉折公告確認 Thomas Kurian 進入 Google Cloud 的時間線，再看Next ’26 官方主題、Gemini Enterprise 公告與AI 時代網路更新理解今日平台方向。這個順序可以避免把 CEO 的職涯敘事直接跳成公司一定成功的結論。

先講結論：Thomas Kurian任Google Cloud CEO期間，Google Cloud官方在Next ’26把AI基礎設施、Gemini模型、資料、Agent平台、網路與安全治理放進同一套企業平台敘事；本文會把公司公告、產品能力、客戶案例與外部成效分開，不把宣傳直接當成市場證明。

Q：Thomas Kurian是誰？
A：他是Google Cloud CEO；本文從他的領導轉折切入，分析Google Cloud如何把雲端基礎設施與AI服務組成企業平台。

Q：Google Cloud所說的AI平台包含什麼？
A：它包含AI加速器與儲存網路、模型與Vertex AI能力、資料服務、開發工具、Agent、應用、安全與治理層。

Q：Gemini在這個平台中扮演什麼角色？
A：Gemini是模型與應用入口之一；企業平台還需要資料連接、權限、部署、監控、成本與安全，不能只用模型名稱代表完整系統。

Q：Agent平台解決什麼問題？
A：官方定位是協助企業建立、擴展、治理與最佳化Agent；真正落地仍要驗證工具權限、資料品質、人工覆核、延遲與成本。

Q：Vertex AI和Gemini Enterprise要怎麼區分？
A：Vertex AI偏向模型、開發與部署能力；Gemini Enterprise偏向企業使用者與工作流程入口，兩者在官方產品組合中可互相連接但不是同一個介面。

Q：為什麼網路和安全也是AI平台的一部分？
A：Agent與模型會跨資料、工具、雲端與企業系統運作，因此需要網路連線、身分、權限、觀測、威脅防護與政策控制。

Q：Google Cloud的公開數字代表什麼？
A：客戶採用率、token量或案例數是公司公告的指標，能說明官方主張與產品使用範圍，但不自動等於獨立驗證的ROI或市場份額。

Q：企業導入Agent最該先檢查什麼？
A：先界定可授權的資料與工具、風險等級、人工核准點、日誌、回溯與停用機制，再評估模型能力與流程效率。

Q：本文的資料時間界線是什麼？
A：本文更新以2026年8月25日可查到的Google Cloud官方資料為界；產品版本、預覽功能、客戶案例與公司展望仍應回到最新公告核對。

Thomas Kurian 如何把 Google Cloud 變成 AI 平台？基礎設施、Gemini、Agent 與治理

Thomas Kurian 何時接手 Google Cloud？領導轉折為何重要？

Google Cloud 在 2018 年公布的領導轉折文章，說明 Thomas Kurian 將加入 Google Cloud，並在過渡期後承擔雲端領導角色；文章同時把他的 Oracle 產品開發經驗與 Google Cloud 接下來的企業化階段連起來。這是一份官方任命與交接敘事，適合用來確認人物進入 Google Cloud 的背景，不應被當成今天所有職務與策略的唯一證據。

這個時間點的意義，在於 Google Cloud 當時不只需要更多雲端產品，也需要把 Google 的基礎設施、資料能力與研究成果轉成企業客戶願意採用、付費與長期維運的服務。企業雲端市場的競爭不只比較單一 API，而是比較可靠度、區域、合規、支援、合作夥伴、遷移成本、開發體驗與治理工具。Kurian 的管理問題因此同時包含產品路線與企業信任。

從人物角度看，CEO 的作用不是親自設計每個 TPU、資料庫或 Agent API，而是把資源、產品組織、客戶需求與公司敘事放進可持續的優先順序。Google Cloud 後續官方文章持續把 infrastructure、models、data、platform、agents 與 security 放在一起，這可以被視為組織方向的公開線索；至於每項產品的技術品質與商業結果，仍需要各自的文件、測試、客戶案例與監管資料驗證。

Google Cloud 的 AI 平台為什麼要從基礎設施開始？

Google Cloud 的Gemini 企業化文章把 AI 平台拆成幾個層次：AI-optimized infrastructure、模型、Vertex AI 與企業應用。這種分層反映生成式 AI 的現實：模型再強，也需要運算、儲存、網路、資料治理、部署、監控與成本控制才能變成企業服務。客戶真正購買的通常不是一個孤立的模型，而是一條從資料到推論、從開發到維運的工作路徑。

基礎設施包含加速器、TPU、GPU、儲存、網路、編譯器與工作負載管理。對訓練來說，吞吐量、叢集規模與資料搬運會影響完成時間；對推論來說，延遲、併發、成本與可靠度更直接影響使用者體驗。Google Cloud 以自己的大規模服務經驗來描述這套整合，但企業部署時仍要根據模型大小、流量、資料敏感度、區域與預算做實際評估。

這裡也有一個容易被忽略的治理問題：AI 基礎設施會把硬體選擇與模型策略綁得更緊。若企業只依賴單一加速器、單一模型或單一雲端服務，短期可能取得較順暢的整合，長期卻可能增加遷移與議價風險。Google Cloud 在Next ’25談到 open、multi-cloud 與 interoperability，這些主張的實際價值要看 API、資料格式、部署選項與退出成本，而不是只看簡報上的開放兩字。

Gemini、Vertex AI 與 Google Cloud：從模型走向企業平台

Vertex AI 是 Google Cloud 把模型、資料與開發流程接在一起的重要入口。企業開發者可以在同一個平台裡選擇模型、建立應用、連結資料、做評估與部署服務；但「平台」不等於所有任務都自動完成。資料權限、grounding、提示詞、評估集、內容安全、版本控管與監控仍然是實作責任。

Google Cloud 在 2023 年的官方文章把 Gemini 放入 unified AI stack，並把模型、AI infrastructure 與 Vertex AI 的關係寫在同一個脈絡中。這個敘事對 Google Cloud 的商業策略很重要：模型是吸引開發者與企業進入的入口，基礎設施提供運算與服務能力，Vertex AI 則把建構與維運流程包起來。三層若能互相帶動，雲端服務就不必只靠原始運算容量競爭。

但官方產品敘事和獨立效果之間必須留出距離。公司可以宣布模型能力、客戶案例與產品功能；讀者若要判斷模型在自己的客服、程式、金融、醫療或內部資料任務上的價值，仍要建立自己的評估集、錯誤分類、成本模型與人工覆核。尤其是企業 AI 的錯誤不只包含答案不準，還包含資料洩漏、權限錯用、偏見、不可解釋、不可追溯與無法回滾。

因此，Google Cloud 的平台能力要以具體產品文件、測試、客戶案例與最新財報分開驗證：官方公告能確認功能與產品方向，不能單獨證明市場份額、客戶 ROI、模型安全性或長期成本優勢。AI、Agent 與治理內容更新速度快，讀者若要採用，應再核對最新版本、定價、服務條款、資料區域與安全文件。

Gemini Enterprise 與 Agent Platform：下一個平台層

Google Cloud 在 2025 年公布 Gemini Enterprise 時，將它描述成組織內建構、擴展、治理與最佳化 Agent workforce 的入口；這代表產品敘事從「模型回答問題」進一步移向「Agent 執行工作」。Agent 需要理解上下文、使用工具、讀取資料、呼叫其他服務、保存任務狀態並把結果交還給人或另一個系統，因此平台責任比聊天介面更廣。

到了 Google Cloud Next ’26，官方文章進一步列出 Agent Designer、Agent Registry、Agent Identity、Agent Gateway、Agent Observability 與 Agent-to-Agent orchestration 等能力。這些名詞共同指向一個企業 Agent control plane：團隊需要知道有哪些 agent、誰可以使用、它們使用哪些工具、如何互相委派、目前任務狀態如何，以及出了錯該去哪裡查。

這裡是 Thomas Kurian 平台策略最值得看的地方。若 Gemini 只是模型產品，競爭會集中在能力與價格；若 Gemini Enterprise 是企業 Agent 平台，競爭則會擴展到身份、登錄、網路、觀測、資料、流程與治理。平台一旦進入企業工作流，就要面對既有 ERP、CRM、資料湖、權限系統、稽核規範與供應商協作，而不只是在 demo 裡完成一個問答。

Agent 平台也會讓責任鏈變得更複雜。一個客服 agent 可能呼叫搜尋 agent、訂單 agent 與退款 agent；每一個服務都可能有不同的資料範圍與副作用。企業需要保存委派鏈、task ID、工具呼叫、使用者授權、輸出驗證與人工批准，不能因為畫面上只看到一個 Gemini 入口，就把所有後端決策視為同一個黑箱。

Google Cloud 為什麼把網路放進 AI 平台？

AI 工作負載讓網路從「連接服務的基礎」變成「影響模型與 Agent 速度的控制面」。Google Cloud 的Next ’26 網路文章把 Cross-Cloud Network、AI infrastructure、agents、security 與 Agent Gateway 放在一起。這反映企業 AI 不會只存在一個單獨的模型端點，而會在多個 agent、資料源、雲端、區域與工具之間交換資訊。

對模型訓練與推論來說，頻寬、延遲、抖動、流量路由與資料位置會影響成本與可靠度；對 Agent 來說，網路還必須知道哪些服務可以互相呼叫、哪些資料不可跨區、哪些任務要隔離，以及哪一個租戶擁有這個請求。Agent Gateway 的價值若要成立，就不只是轉發封包，而是要把身份、政策、協定、觀測與風險控制接在一起。

跨雲網路的開放性也要用可驗證的介面衡量。企業應檢查是否支援既有網路、身分、日誌、DNS、服務網格與安全工具，是否能在不同區域與供應商間維持一致政策，以及離開平台時能否帶走資料與流程。官方頁面可以說明 Google Cloud 的產品設計方向，但不能替每一家公司證明遷移一定容易。

Trust、透明度與 AI 治理：平台能不能被企業採用

Google Cloud 的AI trust and transparency 文章把資料治理、隱私、安全、合規與 defense in depth 放進 AI 產品的基礎。這個方向說明企業 AI 的競爭不只在 benchmark，而在客戶是否能把模型放入受監管、可稽核、可控制的工作環境。

治理至少要分成四層。第一是資料治理：哪些資料可被模型讀取、保存與用於評估？第二是模型治理：版本、能力、限制、風險與變更如何記錄？第三是 Agent 治理：誰能建立、部署、委派、呼叫工具與執行副作用？第四是營運治理：如何監控延遲、成本、錯誤、資料外洩與事故回應？如果只建立模型審查，卻沒有工具與身份審查，企業 AI 仍可能從 Agent 的委派鏈漏出風險。

Trust 也不是一個產品標籤。客戶要問的是：資料在哪裡處理、誰能看到、如何加密、如何保存日誌、如何刪除、如何回應政府或法規要求、如何處理供應商子處理者，以及當模型或平台出錯時誰負責。Google Cloud 的官方信任資料能提供設計原則與產品承諾，企業仍要把這些內容映射到自己的法律、資安、採購與業務流程。

從 2019 到 2026：Google Cloud 平台語言如何變化？

回看 Google Cloud 2019 年的官方文章，當時強調的是 enterprise-friendly pricing、客戶成功、夥伴生態、基礎設施、資料、AI 與數位轉型。這些詞說明 Google Cloud 還在建立企業市場的信任與交付能力。隨著生成式 AI 成為主流，2023 年的文章開始把 Gemini、TPU、AI Hypercomputer 與 Vertex AI 放在同一個 unified stack 裡。

2024 年 Next 文章把模型、資料、基礎設施、Agent 與合作夥伴放進 AI ecosystem；2025 年進一步強調 AI-optimized platform、open multi-cloud、interoperability、Agent Development Kit 與 Agent2Agent；2026 年則把 Gemini Enterprise、Agent Registry、Agent Identity、Agent Gateway、Observability、Agentic Data Cloud 與安全放在平台層。這條時間線顯示 Google Cloud 的公開策略從「提供雲端資源」逐步轉為「提供 AI 系統的完整控制面」。

這種變化不應被簡化成「Google Cloud 已經贏了」。它更像是一個需要持續驗證的假設：如果客戶真的採用同一套基礎設施、模型、資料、Agent 與治理工具，平台整合可能降低導入摩擦；但整合也可能提高鎖定、複雜度與遷移成本。企業要用實際部署時間、錯誤率、成本、工程人力、可攜性與事故處理結果驗證，而不是只看產品名稱變多。

Thomas Kurian 的管理主軸：把產品故事變成可運行的企業系統

若把 Google Cloud 官方資料放在一起，Thomas Kurian 的管理主軸可以概括成三個連續問題。第一，如何把 Google 的基礎設施與研究能力轉成企業可用的雲端服務？第二，如何把模型、資料、開發工具與 Agent 放進一條可部署的產品路徑？第三，如何讓企業在安全、合規、互通與成本控制下長期運行，而不是只在試驗階段展示能力？

這三個問題也解釋了為什麼 Google Cloud 需要同時談硬體、模型、平台、網路與治理。只談 TPU，會忽略開發與資料；只談 Gemini，會忽略推論與運維；只談 Agent，會忽略身份與網路；只談安全，則可能忽略產品能否讓企業真的完成工作。平台 CEO 的工作，是讓這些層次互相支援，也要承擔層次之間衝突時的取捨。

從讀者角度追蹤 Kurian 的後續策略，可以觀察四個訊號：官方是否持續把 AI infrastructure、Gemini、data、agents 與 security 放在同一套產品語言裡；Agent 身份、registry、gateway 與 observability 是否出現更細的技術文件；跨雲與開放性是否能轉成可攜的介面與資料流程；以及客戶案例是否提供可核對的部署範圍、限制與結果。這些訊號比一次 keynote 或單一股價變化更能說明平台是否正在落地。

讀 Google Cloud 官方資料時，哪些話不能直接當成結論？

第一，官方文章中的客戶比例、使用量、效能或市場描述通常是公司提供的敘事，應標示為公司聲稱；如果要做投資或市場份額判斷，需要回到 Alphabet 的監管文件、財報、競爭對手資料與獨立研究。第二，產品公告中的 preview、available、integrated 或 enterprise-ready 可能有地區、版本、合約與功能限制，不能直接等於所有帳戶都能使用。

第三，客戶案例不代表所有組織都能複製相同結果。不同資料品質、網路、權限、模型版本、工程能力與業務流程，會讓部署成本與成效大幅不同。第四，AI platform 的「治理」若沒有寫出身份、資料、日誌、人工批准、錯誤處理與回滾，就還只是方向性語言。讀者可以把官方內容當成產品地圖，再用自己的驗證與限制條件建立決策。

結語：Google Cloud 的競爭不只是雲端，而是 AI 工作如何被治理

Thomas Kurian 領導下的 Google Cloud，公開策略已從傳統雲端基礎設施延伸到 AI-optimized infrastructure、Gemini、Vertex AI、Agent 平台、跨雲網路與 AI trust。這個平台故事的核心，不是把更多 AI 名稱放進產品目錄，而是讓企業能在資料、模型、Agent、工具、網路與安全控制之間建立可運行的連接。

但平台故事能否成為長期競爭力，仍要看它是否降低真實工作流的成本與風險，是否保持互通與可攜，是否讓企業清楚知道資料、權限與責任在哪裡。讀者下次看到 Google Cloud、Gemini Enterprise 或 Agentic Enterprise 的消息時，可以先問它談的是硬體、模型、開發平台、資料、Agent、網路、治理還是客戶成果。把這些層次分清楚，才能理解 Thomas Kurian 的策略，也才能避免把官方產品敘事誤寫成已被外部證明的商業結論。

Google Cloud 官方來源與延伸閱讀

• Google Cloud：Thomas Kurian 接任前的領導轉折
• Google Cloud：把 Gemini 帶進企業的 AI stack
• Google Cloud Next ’24：AI ecosystem 與平台
• Google Cloud Next ’25：AI platform、open cloud 與 interoperability
• Google Cloud Next ’26：Gemini Enterprise 與 Agent Platform
• Google Cloud：Introducing Gemini Enterprise
• Google Cloud：AI agent 時代的 Cross-Cloud Network
• Google Cloud：AI trust and transparency
• Google Cloud：AI 官方產品入口
• Google Cloud：Vertex AI／Gemini Enterprise Agent Platform 入口

把 Thomas Kurian、Google Cloud 與台灣企業放進同一張營運圖

Thomas Kurian 的故事不只是「Google Cloud CEO 推出 Gemini」。比較精確的產品鏈是：Kurian 負責 Google Cloud 的企業產品與平台方向；Google Cloud Platform 以基礎設施、資料、AI 與安全服務收費；Vertex AI、Gemini Enterprise、網路與 Workspace 等產品再把雲端能力拆成企業可購買、部署與治理的模組。台灣製造、半導體、零售或金融團隊若要借鏡，應先分辨人物的管理敘事、Google Cloud 的產品承諾、Alphabet 的財報分項，以及自身的資料主權與導入成本，不能把四者混成一個「AI 已經賺錢」的結論。

Alphabet 2025 年 10-K把 Google Cloud 年度收入列為 2024 年 432.29 億美元、2025 年 587.05 億美元，公司並說明 2025 年比 2024 年增加 155 億美元，主要來自基礎設施與平台服務成長。這是 Alphabet 的 Google Cloud 合併收入，不是 Vertex AI、Gemini Enterprise、某一個台灣客戶或單一產品的收入；也沒有證明每個企業導入 AI 後都得到同樣的毛利、效率或投資報酬。

用財報口徑反推 Google Cloud 的操作策略

1. 先賣基礎設施，再擴平台服務：Google Cloud 收入成長可與基礎設施及平台服務連看，但不能把所有成長直接歸因於生成式 AI；企業仍會為運算、儲存、網路、資料庫、資安與 Workspace 付費。
2. 把 AI 包進既有採購關係：Vertex AI、Gemini Enterprise 與資料／安全產品若能共用身份、帳單、稽核與網路，企業就不必為每一個 AI demo 建立一套孤立平台；但共用也代表權限、資料流向與退出策略必須先寫清楚。
3. 用消費量而非單次授權觀察產品：GCP 多數服務包含 consumption-based fees 與訂閱，評估時要同時看使用量、承諾折扣、資料移轉、GPU 閒置、支援與維運成本，不用只看標價。

上述策略是從公司公開產品與財報口徑整理的分析，不是 Google 對單一客戶的保證。10-K 能證明合併收入與管理層對成長原因的描述，不能直接證明台灣市場的市占、單一模型的毛利、客戶留存或每次推論成本。

台灣企業導入時，品牌名與資料責任要分開

台灣供應鏈公司若把 Google Cloud 接到工廠、設計、庫存或客服，最先要畫的不是漂亮 dashboard，而是資料流：哪些資料留在台灣或特定區域、哪些可送到 Vertex AI、誰能讀取模型輸入與輸出、哪個帳戶負責加密金鑰、哪些工具可以寫回 ERP 或 MES、離開平台時如何匯出。Kurian 的平台策略可作為「把基礎設施、資料、AI 與治理整合」的借鏡，但實際的法規、供應商契約、內部權限與停機演練必須由採用企業自行驗證。

這條脈絡可以和本站的台灣 AI 供應鏈與 Vera Rubin、健策 AI 晶片散熱案例一起閱讀：前者補上台灣製造、伺服器與供應鏈角色，後者提醒 AI 基礎設施還要處理散熱、封裝與現場可靠度。Google Cloud 是服務平台，不等於擁有這些硬體供應商；文章把人物、平台、產品與台灣公司分層，讀者才不會把合作可能性寫成已證實的供應關係。

把 Google Cloud 的成長數字轉成可驗收的企業指標

企業可以用四組數據檢查導入是否真的有價值：第一是平台成本，包括運算、儲存、網路、GPU、支援與資料移轉；第二是工作流程，包括模型延遲、批次完成時間、人工覆核與失敗重試；第三是治理，包括權限拒絕、資料外洩事件、模型版本、審計紀錄與退出演練；第四才是商業結果，包括產能、客訴、庫存、收入或毛利。這四組數據應以相同期間、相同任務與相同資料口徑比較，不能用 Alphabet 的合併收入增長代替企業自己的驗收。

若導入 Gemini Enterprise 或 Vertex AI，還要把 preview、region、quota、模型版本、工具呼叫與資料保留政策記在部署清單；Google Cloud 官方Gemini Enterprise 公告、組織 AI 產品說明與信任與透明度頁面應分開核對，因為產品功能、區域可用性與安全承諾可能隨版本更新。

資料查核日期為 2026 年 8 月 15 日。本文使用 Google Cloud 官方文章、Alphabet SEC 10-K 與可追溯的台灣供應鏈內鏈；沒有把 Google Cloud 的收入分項延伸成台灣客戶營收、排名、流量或因果 ROI。

AI 平台的競爭，核心是基礎設施與治理的整合

Thomas Kurian 把 Google Cloud 往 AI 平台推進時，關鍵不只是 Gemini 或 Agent 的名稱，而是運算、資料、模型、開發工具、企業權限、監控與成本管理能否在同一個可治理的工作流中運作。企業客戶真正需要的是可部署、可追蹤、可回復的系統，而不只是一次成功的示範。

Agent 功能尤其需要把模型能力與企業風險分開：資料邊界、提示注入、權限濫用、錯誤自動化、供應商依賴與人工接管都要先被定義。雲端產品、模型版本、價格與安全功能會快速變動，本文的策略分析不能取代 Google Cloud 官方文件、服務條款與最新產品頁。

• 基礎設施：運算、網路、儲存與資料治理如何支援模型部署？
• 產品：Gemini、Agent 與開發工具如何進入企業流程？
• 責任：誰能授權、監控、撤回與解釋自動化行動？