一個來自企業AI 部署現場的觀察

━━━━━━━━━━━━━━━━━━━━━━━

📌 前言

2026 年 5 月,AI 產業連續發生三件大事:

▸ 5 月 4 日,Anthropic 宣布與 Blackstone、Hellman & Friedman 各投入 3 億美元,Goldman Sachs 投入約 1.5 億美元,合資成立一家估值 15 億美元的企業 AI 服務公司。

▸ 5 月 11 日,OpenAI 宣布成立全資子公司「OpenAI Deployment Company」(簡稱 DeployCo),初始投資超過 40 億美元,同步收購英國 AI 顧問公司 Tomoro,獲得約 150 名前沿部署工程師。

▸ 5 月 12 日,Google Cloud 執行長 Thomas Kurian 宣布在 Google Cloud 內部組建 FDE 團隊,計劃招聘數百名前沿部署工程師。

三家頂尖 AI 公司,在同一週內,先後押注同一個方向。

如果你是企業客戶端的決策者——CIO、CTO、IT 主管、採購負責人——你應該認真問一個問題:

「他們在押什麼?這對我有什麼影響?」

這篇文章想做四件事:

1. 解釋為什麼這件事正在發生(AI 產品的經濟邏輯與傳統 SaaS 有何根本不同)
2. 解釋三家大廠各自在押什麼(OpenAI、Anthropic、Google 的不同策略邏輯)
3. 指出企業客戶端真正應該警惕的四個衝擊(這部分目前中文圈還極少被系統性分析)
4. 論證為什麼地端部署的邏輯在 2026 年重新成立(以及給出具體建議)

讀完之後,你應該帶走兩件事:評估 FDE 提案的判斷框架,以及評估地端部署的決策邏輯。

如果你公司未來 12 個月會碰到 AI 採購決策,這篇文章可能會幫你避開幾個結構性的長期風險——或更重要的,幫助你看清這場交易的真正本質。

⚠️ 寫作說明:本文核心事實基於 2026 年 5 月各公司公開公告及行業報告,部分策略分析為作者判讀,供讀者參考。

━━━━━━━━━━━━━━━━━━━━━━━

🔷 壹、AI 產品的經濟邏輯與傳統 SaaS 有何不同

要理解為什麼大廠突然瘋狂投入 FDE,得先理解一件事:過去 15 年讓 SaaS 變成最賺錢商業模式的三個前提,在 AI 產品身上同時被顯著削弱了。

▍ 1.1 SaaS 過去為什麼能成立

回想一下傳統 SaaS 的經濟模型——Salesforce、Workday、Slack、Notion——它們之所以能達到 70-80% 的毛利率、能用 PLG(Product-Led Growth)模式快速擴張、能讓投資人開出極高的估值倍數,是因為三件事同時成立:

【前提一】零邊際複製成本
寫一次程式碼,服務 100 個客戶跟服務 1000 個客戶,後端成本幾乎沒差。多一個用戶,基本上不增加任何運算費用。

【前提二】產品有持久價值
SaaS 產品的核心邏輯——CRM 怎麼管客戶、HR 怎麼算薪資、Slack 怎麼傳訊息——這些東西的本質幾年才會改一次。產品壽命長,所以投資 R&D 的攤提期可以拉很長。

【前提三】高轉換成本
用戶把資料、流程、習慣都搬進 SaaS 之後,要切換到競爭對手的成本極高。客戶被「鎖在」產品裡,所以可以維持高訂閱費。

這三件事支撐起一個美麗的數學:

低邊際成本 + 長產品壽命 + 高轉換成本 = 高毛利 + 高 retention + 高估值

過去 15 年,矽谷投資人就是用這個公式估值整個 SaaS 行業的。

▍ 1.2 AI 產品讓三個前提顯著鬆動

但 AI 產品面臨不同的經濟約束。讓我們逐項拆解:

◆ 前提一鬆動:推論是真實算力支出

每一次 ChatGPT 回答一個問題、每一次 Claude 寫一段程式、每一次 Midjourney 生成一張圖——背後都是真實的 GPU 算力消耗。

這不是「多用一點就多花一點」的線性成本——對於複雜的推理任務、長 context 的處理、agentic workflow 的多步調用,單次成本可以是傳統 SaaS 的數百倍。

根據多份 2026 年行業報告,AI 產品的毛利率約為 50-60%,對比傳統 SaaS 的 70-80%,差距約 20-30 個百分點。這個差距難以單靠定價補回——因為客戶可以選擇更便宜的 OpenRouter、用開源模型自架、或切換到功能相近但價格更低的競爭對手。

◆ 前提二鬆動:工具迭代太快,產品壽命被壓縮

2024 年的主流 coding agent 是 GitHub Copilot,2025 年變成 Cursor,2026 年的焦點是 Claude Code 和 Windsurf——這個領域的領導者每隔 12-18 個月就會換人。

當一個 AI 工具從推出到被取代的週期壓縮到 12 個月以內,「投入大筆 R&D 然後攤提 5 年」的 SaaS 數學就面臨挑戰。

更直接的影響是:模型本身在快速變強。今天公司花了三個月構建一個客服 agent,半年後新旗艦模型出現,可能僅需極少的提示工程就達到你產品 70-80% 的功能——產品護城河被能力提升所侵蝕。

◆ 前提三鬆動:基於人類操作習慣的鎖定正在削弱

過去 SaaS 的轉換成本來自「人類使用者學會了這套介面」——員工花了三個月學 Salesforce,要改用 HubSpot 等於要他們重新學習。

但當未來的「使用者」是 AI agent——一個能讀文件、能調 API、能跨多工具運作的智能體——它對特定 SaaS 介面沒有內在偏好。

這意味著:基於人類 UI 學習形成的鎖定效應正在被削弱。

當然,「agent 降低切換成本」這個趨勢目前仍受到三層現實阻力的制約:

• 資料遷移層:企業真正的轉換成本往往在於資料模型耦合、歷史資料遷移——這些不是 API 通了就能自動消除的
• 組織慣性層:即使技術上可行,企業內部的流程固化、部門利益、合規慣性都是巨大的現實阻力
• 標準化程度:Agent 要能無縫跨平台,需要高度標準化的 API 介面和語意層——這在當前複雜的企業軟體生態中遠未實現

因此,這個論點的精確表述是:Agent 正在削弱基於 UI 學習的鎖定效應,但更深層的轉換壁壘仍然存在。

📎 適用範圍說明:本文的經濟模型分析主要適用於以 AI 為核心產品的原生公司。對於 Salesforce、Adobe 這類以傳統 SaaS 為主、AI 為輔的公司,商業模式的演變路徑有所不同——它們面臨的是「如何把 AI 整合進既有訂閱模型」的問題,而非「SaaS 數學是否成立」的問題。

▍ 1.3 結論:AI 原生產品的經濟模型正在重構

三個前提同時被削弱,意味著:

• 不能只靠零邊際成本獲利(推論成本是真實的)
• 不能只靠長產品壽命攤提(工具迭代加速)
• 不能只靠人類 UI 鎖定保有客戶(agent 降低操作層面的黏性)

AI 公司的回答是:做傳統 SaaS 做不到、AI 才做得到的事——把人塞進客戶辦公室,做極度客製化、極度高價值、極度難複製的服務。

這就是 FDE 模式被重新重視的根本原因。

━━━━━━━━━━━━━━━━━━━━━━━

🔷 貳、為什麼是現在?三家大廠各自在押什麼

FDE 不是新東西。

Palantir 用這個模式已經將近 20 年——派工程師到客戶端、深度理解 workflow、寫只服務這一個客戶的軟體、收取極高的合約費用。

那為什麼 2026 年 5 月,OpenAI、Anthropic、Google 三家同時開始大規模押這個模式?

▍ 2.1 改變遊戲規則的是 AI 編程工具本身

過去 FDE 模式只有 Palantir 能玩,因為經濟學上不划算。一個 FDE 工程師,通常一年只能服務 1-2 個大客戶——從理解需求、寫 prototype、跟業務人員迭代、到最終交付,週期太長。

但 AI 編程工具改變了這件事。

Cursor、Claude Code、Windsurf 把「從需求到可運行原型」的週期,從幾週壓縮到幾小時。

這意味著一個現代 FDE 可以:

• 在客戶會議室現場 vibe code 出第一版(過去要兩週,現在 30 分鐘)
• 餵真實案例進去當場跟業務人員迭代(過去要一個月,現在當天)
• 同時服務多個客戶(過去是 1-2 個,現在取決於項目複雜度)

FDE 的單位經濟學正在從「難以規模化」轉向「可持續擴張」。模式從「只有 Palantir 玩得起」變成「有機會服務數百家中型企業」。

這就是為什麼是 2026 年——AI 編程工具的成熟,讓 FDE 變成一個具備規模化潛力的商業模式。

▍ 2.2 三家大廠的不同押注

雖然三家都在做 FDE,但他們的策略邏輯有實質差異:

◆ OpenAI 的押注:能力差距紅利

OpenAI 成立 DeployCo,並收購 Tomoro——這個押注的核心假設是:

「前沿模型的能力差距會繼續存在且可能擴大。只要把工程師塞進客戶辦公室,讓他們親身體驗模型能力,客戶就會願意為這個能力差距支付溢價。」

OpenAI 押的是「frontier model 紅利」——FDE 是把技術領先「翻譯成商業價值」的渠道。

◆ Anthropic 的押注:行業 Know-how 比模型能力重要

Anthropic 的合資選擇極具策略性:

• Blackstone 是全球最大私募股權巨頭,旗下投資組合涵蓋上百家中型企業
• Hellman & Friedman 是頂級私募基金,深度理解多個行業
• Goldman Sachs 是頂級投行,深度理解金融、製造、零售等行業的運營邏輯

這個押注的核心假設是:

「未來相當比例的客戶要的不是『最強的模型』,而是『最懂我這個行業的部署能力』。所以我們跟最懂行業的合作夥伴聯手,把 FDE 派進去他們組合裡的企業。」

Anthropic 押的是「行業 Know-how + 中型企業市場」——他們不跟 OpenAI 正面競爭前沿能力,而是搶「模型能力足夠用、但深度客製化困難」的中段市場。

◆ Google 的押注:分發優勢勝過一切

Google 沒有獨立公司,也沒有大型合資——直接把 FDE 納編到既有的 Google Cloud 部門。

這個押注的核心假設是:

「客戶已經在用 GCP、Workspace、BigQuery 了。我們有資料、有客戶關係、有 SRE 體系。只要把 FDE 變成 Cloud 銷售流程的一部分,我們不需要『搶』客戶,只需要『加深』既有客戶的 AI 滲透度。」

Google 押的是「既有分發通路 + 客戶關係深化」——他們不需要全新的商業模式,只需要把 FDE 接到既有的銷售引擎上。

▍ 2.3 三家共同的底層假設與一個更大的背景

策略不同,但有一個共同的底層判斷:

「AI 商業化無法靠 SaaS 式的低 CAC、低 marginal cost、PLG 自助上手完成。必須把人塞進客戶現場,把客戶的 tacit knowledge encode 進 evaluation set。」

什麼叫 tacit knowledge?

舉個例子。客戶說:「我要一個自動處理理賠的 agent。」

這句話的資訊量極低。處理理賠的真實邏輯——「這種案件要找誰簽核?」「遇到爭議怎麼判?」「這個客戶比較大要走快通道嗎?」——全部藏在資深員工腦袋裡,沒有寫進任何 SOP。

要做出一個真正能用的 agent,必須有人坐在客戶辦公室,跟業務人員一起看 AI 的輸出,然後不斷被告訴「不對,因為我們公司潛規則是 XX」。

這層 tacit knowledge,只有人在現場才能萃取。

──────────

💡 這裡有一個更大的背景值得記住:

過去十年,雲端大廠的商業模式是「賣工具」——賣 compute、賣 storage、賣 API,企業自己決定怎麼用這些工具。

但 FDE 模式代表的是一個根本性的轉向:雲端大廠開始直接承包企業的運營流程本身。

這個轉向不只影響 IT 預算,而影響企業的組織主權——誰在設計工作流程?誰在定義業務邏輯?誰在累積營運智慧?

這是為什麼第三章的四個衝擊不只是「IT 風險」,而是「治理風險」。

──────────

到這裡為止,如果你是雲端大廠的投資人或員工,FDE 是一個美好的故事。

但如果你是站在企業這一端的決策者,故事到這裡才剛開始

接下來這一章,中文圈目前還極少被系統性討論——讓我帶你看 FDE 模式背後,企業客戶端應該警惕的四個真實衝擊。

━━━━━━━━━━━━━━━━━━━━━━━

🔷 參、企業客戶端真正應該警惕的四個衝擊

我必須先說明立場:FDE 是中性的。對某些企業、某些場景,接受 FDE 是合理的選擇。

但如果你只看到 FDE 的「好處」——技術領先、客製化、加速落地——而沒有看到背後的權力結構變化,你會在簽下合約的當下,埋下未來 3-5 年的長期風險。

讓我把四個真實衝擊拆解清楚。

▍ 3.1 衝擊一:你的 Tacit Knowledge 在流向誰?

回到 FDE 模式的核心邏輯:「把客戶的 tacit knowledge encode 進 evaluation set」。

請仔細想一下這句話的真正意思。

當一個 OpenAI / Anthropic / Google 的 FDE 工程師,坐在你公司的會議室裡,跟你最資深的業務人員一起看 AI 輸出、聽他們講「這個案件要這樣處理,因為我們公司的潛規則是...」——

這些潛規則,正在以某種形式進入這家 AI 公司的系統。

• 合約上,這些 evaluation set 屬於誰?
• 如果 FDE 工程師三年後離職,他帶走的「對你公司 workflow 的理解」歸屬於誰?
• 如果這家 AI 公司在相關產業也有其他客戶,他們從你這裡萃取的「處理理賠的最佳實踐」,會不會以某種形式「啟發」他們服務你的競爭對手?

這不是反派論述。這是任何高價諮詢業早就存在的結構性問題——麥肯錫、BCG、Palantir 早就在處理這件事。

但 FDE 模式有一個傳統諮詢業沒有的新元素:萃取出的知識會 encode 進 AI 系統,可能以某種形式被複用。

【傳統顧問 vs FDE 模式】

▸ 結案後:
傳統顧問——顧問把腦中的知識帶走
FDE 模式——你的 Know-how 以 evaluation set 形式存在 AI 公司系統裡

▸ 可攜性:
傳統顧問——高度依賴個人
FDE 模式——系統化儲存,可能被用於其他專案

這兩件事在法務上、商業上、競爭策略上的意義,截然不同。

📋 你應該問的問題:

1. Evaluation set 的著作權屬於誰?
   (預設答案往往是 AI 公司,你要爭取的是「客戶共有」或「客戶獨有」)

2. AI 公司是否承諾「不將從你這裡學到的知識用於同行業其他客戶」?
   (預設往往是不承諾)

3. 如果合約終止,evaluation set 怎麼處理?
   (預設往往是 AI 公司留存,要爭取的是強制刪除或交付給客戶)

▍ 3.2 衝擊二:資料邊界在 FDE 模式下重新被界定

過去 SaaS 時代的資料合約,核心邏輯是:「你的資料在我的雲上,但我不會看、不會用、不會分享」。

簽過 Workday、Salesforce、Slack 企業合約的人都熟悉這套——資料主權還在客戶手上,SaaS 廠商只是「保管者」。

但 FDE 模式正在打破這個邊界。

當 FDE 工程師「坐在你的辦公室」、「看你的真實案例」、「和你的員工一起 debug 模型」——你的資料、流程、邏輯,正在以一種傳統 SaaS 模式不同的方式,流出企業邊界。

更微妙的是:這些不會觸發傳統的「資料外洩偵測」雷達。

• 你的 DLP 系統偵測不到「FDE 工程師腦袋裡的理解」
• 你的 ISO 27001 稽核流程不會問「FDE 工程師寫的 prompt 裡包含哪些業務邏輯」
• 你的個資法合規檢查不會涵蓋「AI 模型的 evaluation set 是否間接包含敏感資訊」

這是一個全新的、目前還沒有成熟法規框架的資料邊界問題。

而且這個問題在 2026 年的台灣特別敏感:

• 金融業:金管會、FSI 資安規範對資料處理有嚴格要求
• 醫療業:對美業務受 HIPAA 約束,同時受台灣個資法規範
• 政府客戶:國安、機敏資訊有特殊保護要求
• 外商客戶:往往受母公司全球合規政策約束

💡 有趣的是,在台灣這個現實反而可能是企業的一個隱性談判籌碼。許多台灣企業同時受金管會、國安規範、或母公司全球合規政策的約束——這些規範恰恰為「對 FDE 模式說不」提供了一個企業內部容易論證的理由。也就是說:「不是我們不想,是合規不允許。」這句話在 FDE 提案談判中,比任何商業論點都更有用。

如果你公司同時服務這些行業,FDE 模式的資料邊界問題,可能讓你無意中違反多個客戶的合約義務。

📋 你應該問的問題:

1. FDE 工程師接觸到的資料,在你公司的 DLP / 個資法 / ISO 27001 框架下如何分類?

2. FDE 工程師寫的 prompt、生成的 evaluation set、保存的對話記錄,是否完整留存在你公司可控的範圍內?

3. 如果你公司有客戶要求「所有資料處理都在台灣境內」,FDE 模式如何符合?
   (注意:FDE 用的是哪家 AI 公司的後端推論?資料是否真的不離境?)

▍ 3.3 衝擊三:當你的業務邏輯被 Encode 進 Evaluation Set,你還有議價權嗎?

這是最微妙的一個衝擊,大部分人想不到。

商業合作關係的議價權,來自「離開選項的可信度」。如果你公司隨時可以換供應商,你就有議價權。如果你公司被鎖在一個系統裡幾年都換不掉,你的議價權就消失了。

FDE 模式從第一天起,就在系統性地降低你的離開選項可信度。

讓我們把這個過程拆解:

🕐 第 1 個月:FDE 工程師進駐,建立第一版 agent,跑通核心 workflow。
你的反應:「還行,但離我們的真實需求還有距離。」

🕒 第 3 個月:FDE 工程師深度理解你的業務、寫了幾百條 evaluation case、客製化了 prompt chain。
你的反應:「這個 agent 開始懂我們了,但還是有些 edge case 處理不好。」

🕕 第 6 個月:Edge case 慢慢被處理掉,AI 開始能處理大部分標準案件。資深員工的時間被解放出來,公司開始把 AI 視為基礎設施。
你的反應:「真的有用,我們開始依賴它了。」

🕛 第 12 個月:你的業務 workflow 已經圍繞 AI 重新設計。新進員工被訓練要「先問 AI」,流程文件被改寫,KPI 被重設。
你的反應:「這已經是我們營運的一部分了。」

⏰ 第 18 個月:競爭對手提案,願意便宜 30%。你打開計算機算「換掉的成本」——

• 重新建立 evaluation set 需要數月
• 流程要重新對齊
• 員工要重新適應
• 過渡期客戶服務品質可能下降

結論:除非便宜幅度顯著,否則換供應商的成本極高。

這就是「vendor lock-in by tacit knowledge」——比傳統 SaaS lock-in 更隱性、更深、更難解開。

而且許多企業會觀察到:隨著依賴加深,供應商開始調整合約價格。

📋 你應該問的問題:

1. Evaluation set 是不是可以匯出?匯出的格式是否能在其他 AI 模型或平台上使用?

2. 合約中是否有價格保護條款?
   (例如:漲幅不得超過 CPI、續約價格上限等)

3. 是否有過渡服務條款?
   (合約終止後,供應商是否必須協助你過渡到另一個供應商?)

▍ 3.4 衝擊四:多年後 FDE 撤走時,你帶走的是系統,還是空殼?

最後這個衝擊是時間維度上的——FDE 不會永遠在你公司。

可能是合約到期。可能是 AI 公司策略轉向。可能是負責你的 FDE 工程師離職。可能是 AI 公司被收購、被分拆、業務重組。

當 FDE 撤走那天,你的公司會留下什麼?

【情境 A(理想)vs 情境 B(多數預設)】

▸ Evaluation set:
情境 A——在你手上
情境 B——在 AI 公司手上

▸ Prompt 配置:
情境 A——在你手上
情境 B——可能是雲端服務的一部分

▸ 內部能力:
情境 A——你的人懂運維、調整、擴展
情境 B——只會操作前端介面

▸ 撤走後影響:
情境 A——系統繼續服務,只是換供應商
情境 B——營運能力倒退數月

多數 FDE 合約在沒有特別交涉的情況下,默認結果是情境 B。

這不是因為 AI 公司「邪惡」——這是商業上理性的策略。任何顧問業者都會偏好「讓客戶帶不走」的合約結構。

但作為客戶,你必須意識到:你正在簽下一份「短期收益確定、長期風險未知」的合約。

📋 你應該問的問題:

1. 合約終止時,你能帶走的「資產清單」是什麼?
   (白紙黑字列出來)

2. 你公司有沒有「內部接手」的能力建構計畫?
   (培訓自己人,而不是永遠仰賴 FDE)

3. 如果 FDE 突然撤走,你公司需要多久才能恢復獨立運作?
   (這個數字應該寫進合約)

━━━━━━━━━━━━━━━━━━━━━━━

🔷 肆、為什麼地端部署的邏輯在 2026 年重新成立

讀完上面四個衝擊,你可能會問:「那不簽 FDE 行不行?自己做行不行?」

兩年前我會回答:「很難,因為地端部署的技術門檻太高、開源模型差距太大、總體成本不見得划算。」

但 2026 年,這個答案變了。

▍ 4.1 開源模型能力差距大幅縮小

回顧過去 24 個月開源 LLM 的發展軌跡:

📅 2024 年初:GPT-4 vs Llama 2 70B,能力差距明顯

📅 2024 年底:Llama 3.1 405B、Qwen2.5-72B 出現,追到 GPT-4 等級

📅 2025 年:DeepSeek V3、Llama 3.3、Mistral Large 2,多項基準測試達到 GPT-4o 等級

📅 2026 年初:Llama 4 Scout 與 Maverick(Behemoth 旗艦款仍在訓練中,發布時間尚未公布)、Qwen 3、DeepSeek V3.2、Mistral Large 3、Gemma 4 陸續釋出,在多項基準上與閉源前沿模型接近

2026 年 5 月的真實情況是:對於企業大多數實務任務(RAG、文件處理、coding assistant、客服自動化、RCA 報告),開源模型已經真正實用。

剩下的能力差距——前沿推理、最新 multimodal、最強 agentic——對相當比例的企業實務場景,並非必要條件。

▍ 4.2 硬體與軟體生態成熟

兩年前自架 LLM 是一個 R&D 項目。2026 年越來越接近一個 IT 採購項目。

◆ 硬體層:
• HPE Private Cloud AI、Dell AI Factory、Lenovo Neptune 等都推出 turnkey 方案
• NVIDIA RTX Pro 6000 Blackwell、L40S、H200 等企業級 GPU 供應趨於穩定
• 從採購到上線可以壓縮到 4-8 週

◆ 軟體層:
• vLLM、TGI、Ollama 等 inference 框架成熟穩定
• LangChain、LlamaIndex 等 RAG 框架被廣泛採用
• Open WebUI、AnythingLLM 等開源介面可用

◆ 運維層:
• 量化技術(GGUF、AWQ、GPTQ)讓大模型在中等硬體可運行
• LoRA、QLoRA 等 fine-tuning 技術讓客製化成本下降
• vLLM 的 tensor parallelism 讓多 GPU 部署更直覺

整個技術 stack 的上手難度,已經接近企業 IT 部門可以逐步掌握的等級。

▍ 4.3 成本對比:說明性估算

讓我們做一個說明性的 TCO 對比,以一個服務 80 位工程師的中型 SI/MSP 公司、3 年週期計算:

⚠️ 重要說明:以下為便於理解的示例性估算,非基於特定配置的嚴格財務模型。真實成本因規模、可用性需求、合規要求差異較大。企業決策應依實際需求進行詳細評估。

◆ 選項 A:雲端 AI API + FDE 服務

• 雲端 API 費用(說明性估算):
80 人 × $200/月 × 36 個月 ≈ $576,000 USD

• FDE 服務費用:
中大型企業合約約 $300,000-500,000 USD/年 × 3 年 ≈ $1,200,000 USD

• 估算總計:約 $1,776,000 USD ≈ NTD 5,500 萬

◆ 選項 B:地端部署 + 開源模型(說明性估算)

• 硬體 + 軟體 + 機房:依規模從數十萬到數百萬不等(此處以常見配置估算)
• 1-2 位 AI 維運架構師:依資歷與市場供需,薪資區間較大
• 開源模型授權:通常無授權費,但有訓練與維護成本

💡 關鍵不在於絕對數字,而在於成本結構的本質差異:隨著使用量增加,地端部署的邊際成本曲線更為平坦——這是規模化的結構性優勢。

▍ 4.4 地端部署的四個結構性優勢

除了成本考量,地端部署有四個 FDE 模式難以匹配的特性:

◆ 優勢一:資料主權完整保留

所有資料、prompt、evaluation set、推論記錄,在你公司可控範圍內。

不需要擔心:
• AI 公司是否會查看你的資料
• 資料是否被用於模型訓練
• 跨境傳輸是否違反法規
• 合約終止後資料如何處理

對受監管行業(金融、醫療、政府、電信)的客戶,這個優勢往往是合約必要條件。

◆ 優勢二:Vendor Independence

開源模型的好處是:你可以隨時評估和切換。

今天用 Mistral Large 3,明年有新模型更好,你可以評估遷移(只要 evaluation set 在你手上)。

對比 FDE 模式下「綁定特定 AI 廠商」,這是結構性的議價權差異。

◆ 優勢三:Knowledge 內化

當你公司有專職的 AI 維運團隊,他們會深度理解:
• prompt 怎麼設計
• evaluation set 怎麼建構
• 模型怎麼調校
• 錯誤怎麼 debug

這些知識留在你公司,變成可傳承的組織能力。

對比 FDE 模式下「FDE 走了,相關理解也跟著走了」,這是長期能力建構的根本差異。

◆ 優勢四:長期成本結構更穩定

地端部署的成本曲線是「前期投資較高,後期邊際成本趨於穩定」。

一旦基礎設施到位、團隊建立起來,增加用量不一定帶來線性成本增加。

對比 FDE / 雲端 API 的「用量越大、付費越多」線性成本曲線,在達到一定規模後,這是質的差異。

▍ 4.5 地端部署的現實代價

我必須誠實說:地端部署不是萬靈丹,它有真實的代價。

◆ 代價一:需要培養內部人才
你需要專職的 AI 維運人才。這個職位在 2026 年的台灣市場供給有限、薪資較高,招募和留住人才都有挑戰。

◆ 代價二:能力上限存在
開源模型跟當代旗艦閉源模型相比,在某些維度仍有差距。對於需要極致前沿能力的應用(深度推理、複雜 agentic、最新 multimodal),地端確實可能面臨限制。

◆ 代價三:你必須自己承擔模型維護
新模型出來、舊模型過時、評估什麼時候升級——這些決策在你身上。對沒有 R&D 文化的傳統企業,這是一個運營模式的根本轉變。

◆ 代價四:初期 ROI 不好看
地端部署的價值往往體現在第二、第三年。第一年通常是「建構基礎、打平或小幅虧損」的狀態。這對追求短期回報的管理層,是一個需要認真應對的說服難題。

▍ 4.6 結論:不是「FDE vs 地端」二選一

讓我把這一章的核心觀點明確說出來:

「FDE 還是地端?」這個問題本身是錯誤的提問。

正確的提問應該是:

「在我公司的具體場景下,哪些 AI 能力應該地端部署,哪些應該透過 FDE 或雲端 API 取得?」

這是一個「分層 sourcing 策略」問題,而不是「單選題」問題。

合理的做法可能是:

✦ 核心、高頻、高敏感的應用
→ 地端部署(資料主權 + 議價權 + 長期成本可控)

✦ 前沿、低頻、需要 cutting-edge 能力的應用
→ FDE 或雲端 API(獲取前沿能力)

✦ 過渡期、學習期
→ 用 FDE 加速 onboarding,同時建構地端能力,數年後逐步內化

這個混合策略,才是 2026 年成熟企業的務實答案。

當然,這個混合策略的執行有兩個根本挑戰:「核心」與「前沿」的界線是動態的——今天的前沿能力,明天可能就變成核心需求;以及,內部團隊的能力增長能否持續跟上模型迭代和業務需求的變化速度,對企業的組織學習能力提出了真正的高標準。這兩個挑戰沒有標準答案,每個企業需要根據自己的實際情況持續評估和調整。

━━━━━━━━━━━━━━━━━━━━━━━

🔷 伍、給台灣企業的具體建議

▍ 5.1 給「正在評估 FDE 提案」的企業

如果 OpenAI、Anthropic、Google,或他們的合作夥伴正在跟你提案 FDE 服務,先別簽,先問這 5 個問題:

❓ 問題 1:Evaluation set 的智慧財產權屬於誰?
預設答案往往是 AI 公司,你要爭取的是「客戶共有」或「客戶獨有」

❓ 問題 2:合約終止時,我可以帶走什麼?
• 白紙黑字列出 takeaway 清單
• 包含 prompt 配置、evaluation set、訓練資料、模型權重(如有 fine-tune)、運維文件

❓ 問題 3:你們是否承諾「不將從我這裡學到的知識用於同行業其他客戶」?
預設往往是不承諾。這條件值得爭取,也許值得為此支付溢價

❓ 問題 4:價格保護機制是什麼?
續約價格上限、年度漲幅上限、過渡期條款

❓ 問題 5:過渡服務條款是什麼?
合約終止後,供應商是否必須協助你過渡到另一個供應商?期限多長?費用怎麼算?

這五個問題,在 FDE 模式還在早期的 2026 年,你還有議價空間。

到 2028 年市場成熟之後,這些可能都會變成「標準條款,不接受就不簽」,那時候你就沒得選。

▍ 5.2 給「想自己做 AI 但不知道從哪開始」的企業

如果你公司還沒有任何 AI 落地,但有意願自己建構,建議的順序是:

🔹 Step 1:找一個低風險、高頻率、容易量化的場景做 MVP
• 不要一開始就做高風險的 agent 自動執行場景
• 從「文件審查」「RCA 草稿生成」「漏洞比對」這類「AI 建議、人類決策」的場景開始

🔹 Step 2:評估地端基礎設施的可行性
• 評估 HPE Private Cloud AI 或同等級方案
• 了解 Mistral、Llama、Qwen 等開源模型的特性
• 評估招募 1-2 位 AI 維運人才的可行性與成本

🔹 Step 3:用 16-24 週做 MVP,誠實評估
• 不要承諾「6 個月回本」這類不切實際的數字
• 用「Y1 建構基礎、Y2 驗證價值、Y3 加速產出」的三年視角溝通
• 如實揭露:採用率通常會經過「好奇期 → 質疑期 → 適應期 → 慣性期」的曲線

🔹 Step 4:MVP 完成後,評估是否需要 FDE 補位
• 如果只缺前沿能力 → 雲端 API
• 如果缺深度行業客製 → 短期 FDE
• 如果都不缺 → 繼續地端深耕

▍ 5.3 給「已經被 FDE 綁定但開始警覺」的企業

如果你公司已經在 FDE 合約裡,但讀完這篇文章開始警覺,還來得及。三件事:

🔸 第一,啟動「內部能力建構」並行軌
• 不要立刻終止 FDE 合約
• 在內部設立 1-2 位 AI 工程師,跟 FDE 工程師並行工作
• 目標:讓內部團隊在 12-18 個月內具備「接手能力」

🔸 第二,爭取 evaluation set 的內部備份
• 即使合約沒特別約定,也可以「請 FDE 工程師把 evaluation set 同步一份給內部團隊」
• 這在合約期內通常 FDE 不會拒絕——他們可能解讀為「客戶想更深度參與」
• 但實際上,這是你「帶得走」的資產

🔸 第三,在續約時重新談判
• 把這篇文章 5.1 的五個問題列入續約條件
• 如果對方不讓步,至少你知道議價空間在哪
• 如果對方讓步,你已經拿到了原本默認拿不到的東西

━━━━━━━━━━━━━━━━━━━━━━━

🔷 陸、本文的局限性

在結語之前,我想誠實說明這篇文章的局限性:

1. 核心事實基於公開資訊
   本文分析主要依據 2026 年 5 月各公司的公開公告與行業報告,未涵蓋廠商內部策略或非公開資訊。

2. 成本估算為說明性示例
   第四章的成本對比是便於讀者理解的示例,非基於特定實際配置的嚴格財務模型。企業決策應依實際需求進行詳細評估。

3. 不同產業、不同規模企業的適用性差異較大
   文章的分析框架通用,但具體結論應結合企業自身情況判斷,而非直接套用。

4. 部分觀點為作者判讀
   文中「為什麼是現在」「企業應如何應對」等部分的策略建議,反映的是當前時間點的分析,隨市場演變可能需要重新評估。

━━━━━━━━━━━━━━━━━━━━━━━

🎯 結語:這不是反 AI,是要更聰明地擁抱 AI

寫到最後,我想說清楚一件事:

這篇文章不是反對 FDE,不是反對雲端 AI,更不是反對 AI 落地。

我自己是 AI 的重度使用者。寫這篇文章的過程,我用了多個 AI 模型輔助研究與寫作,並進行了交叉驗證。我公司正在規劃地端 AI 部署。我深信 AI 是 2026 年企業最重要的議題之一。

但我反對的是:在不理解結構性權力變化的情況下,盲目擁抱任何一個方向。

雲端大廠在押 FDE,有他們的商業邏輯和利益計算。我們作為站在企業這一端的人,不能只看到 FDE 帶來的短中期能力提升,而忽略了背後正在形成的權力結構。

這篇文章的核心觀點濃縮成三句話:

✦ AI 產品的經濟邏輯與傳統 SaaS 有根本差異——這正在重構 AI 商業化的路徑,FDE 是這個重構的產物

✦ FDE 帶來四個結構性衝擊:Tacit knowledge 流向、資料邊界重劃、議價權侵蝕、撤走後空殼化

✦ 2026 年地端部署的條件已經成熟,企業應該採用「分層 sourcing」策略,而不是把所有 AI 能力都外包出去

──────────

如果這篇文章對你有幫助,我希望它能成為你在跟 AI 廠商談判時、在做 AI 投資決策時、在規劃公司 AI 路線圖時,一個多了一個角度的參考。

不是答案,是一個被忽略的角度。

決策還是你的。

如果你正在做 AI 採購決策,或剛好簽過、拒絕過 FDE 提案,我很想聽聽你的觀察——你看到了我沒看到的東西嗎?

━━━━━━━━━━━━━━━━━━━━━━━

📝 後記:關於這篇文章的寫作方式

這篇文章在初稿階段使用了 AI 輔助——包括研究階段的資訊彙整、寫作階段的初稿生成、以及多輪修訂中的交叉驗證。

核心觀點、案例選擇、風險框架設計為作者判讀,歡迎讀者指正。

我認為這個寫作過程本身,就是這篇文章主題的一個具體實踐:

在 AI 時代,學會聰明地使用 AI,而不是被 AI 使用。

━━━━━━━━━━━━━━━━━━━━━━━

📚 References

▍ 類別一:三大事件原始公告

1. OpenAI. (2026). OpenAI Launches the Deployment Company.
   https://openai.com/index/openai-launches-the-deployment-company/

2. Krupp, L. (2026, May 11). OpenAI DeployCo Private Equity. Axios.
   https://axios.com/2026/05/11/openai-deployco-private-equity

3. de la Mare, A. (2026). OpenAI Deployment Company: Tomoro Acquisition. The Next Web.
   https://thenextweb.com/news/tomoro-openai-deployment-company-consulting

4. PYMNTS. (2026). OpenAI Launches $4 Billion Company to Accelerate Enterprise AI Adoption.
   https://pymnts.com/news/artificial-intelligence/2026/openai-launches-4-billion-dollar-company-accelerate-enterprise-ai-adoption/

5. Yeh, S. (2026, May 4). Anthropic Blackstone Goldman Sachs Joint Venture. Fortune.
   https://fortune.com/2026/05/04/anthropic-claude-consulting-industry-joint-venture-blackstone-goldman-sachs/

6. Yeh, S. (2026, May 5). Anthropic Wall Street Financial Services Agents Jamie Dimon. Fortune.
   https://fortune.com/2026/05/05/anthropic-wall-street-financial-services-agents-jamie-dimon/

7. Yahoo Finance. (2026). Anthropic Forms $1.5B Joint Venture.
   https://finance.yahoo.com/sectors/technology/articles/anthropic-forms-1-5b-joint-123147935.html

8. The Information. (2026). Google Hire Hundreds Engineers Help Customers Adopt AI.
   https://www.theinformation.com/briefings/google-hire-hundreds-engineers-help-customers-adopt-ai

9. Tech Startups. (2026, May 13). The Human Side of Agentic AI Adoption.
   https://techstartups.com/2026/05/13/the-human-side-of-agentic-ai-adoption-hundreds-of-forward-deployed-engineers/

10. Channel Dive. (2026). Google Cloud Forward Deployed Engineering Jobs.
    https://channeldive.com/news/google-cloud-forward-deployed-engineering-jobs/820176/

11. Schnitzler, J. (2026). Google Box CEOs Say This Is the Most In-Demand Job in Tech. Fast Company.
    https://www.fastcompany.com/91541878/google-box-ceos-say-this-is-the-most-in-demand-job-in-tech

12. OfficeChai. (2026). Google Is Hiring Forward Deployed Engineers for Its Cloud Customers.
    https://officechai.com/ai/google-is-hiring-forward-deployed-engineers-for-its-cloud-customers

▍ 類別二:FDE 歷史背景

13. Orosz, G. (2024). Forward Deployed Engineers. Pragmatic Engineer Newsletter.
    https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers

14. Cagan, M. (2024). Forward Deployed Engineers. Silicon Valley Product Group.
    https://svpg.com/forward-deployed-engineers/

▍ 類別三:AI 毛利率研究

15. Lemkin, J. (2026). The Execution Era of AI: 5 Key Takeaways from ICONIQ's State of AI Report. SaaStr.
    https://www.saastr.com/the-execution-era-of-ai-5-key-takeaways-from-iconiqs-state-of-ai-report/

16. SaaStr. (2026). Top 10 Learnings from Sapphire Ventures' 2026 Software x AI Report.
    https://www.saastr.com/top-10-learnings-from-sapphire-ventures-2026-software-x-ai-report-80-100m-arr-ai-startups-the-ultra-round-is-the-new-normal-and-enterprise-is-50-of-vc-now/

17. SFAI Labs. The AI Project Gross-Margin Reset Every SaaS Company Is About to Face.
    https://sfailabs.com/guides/the-ai-project-gross-margin-reset-every-saas-company-is-about-to-face

18. Monetizely. (2025, October). The Economics of AI-First B2B SaaS in 2026.
    https://getmonetizely.com/blogs/the-economics-of-ai-first-b2b-saas-in-2026

19. Trending Topics EU. AI Is Eating Software Margins: How SaaS Companies Now Have to Adapt.
    https://trendingtopics.eu/ai-software-margins/

20. ICONIQ Capital. (2026, January). State of AI Report 2026. (付費報告)
    (引用其關於 AI 產品毛利率約 52% 與 inference cost 占營收 23% 的數據)

▍ 類別四:開源 LLM 成熟度

21. Hugging Face. (2026, April). DeepSeek-V4: A Million-Token Context That Agents Can Actually Use.
    https://huggingface.co/blog/deepseek-v4

22. Hugging Face. (2026, April). Granite 4.1 LLMs: How They're Built.
    https://huggingface.co/blog/granite-4-1-llms

23. Hugging Face. (2026, May). Granite Embedding Multilingual R2: Open Apache 2.0 Multilingual Embeddings with 32K Context.
    https://huggingface.co/blog

▍ 類別五:企業地端部署平台

24. Hewlett Packard Enterprise. (2026, March). HPE Accelerates Secure, Scalable Production-Ready AI Through New Innovations with NVIDIA.
    https://www.hpe.com/us/en/newsroom/press-release/2026/03/hpe-accelerates-secure-scalable-production-ready-ai-through-new-innovations-with-nvidia.html

25. WEI. How HPE GreenLake Intelligence Powers On-Prem AI Infrastructure and Secure Edge Deployment.
    https://www.wei.com/blog/how-hpe-greenlake-intelligence-powers-on-prem-ai-infrastructure-and-secure-edge-deployment/

▍ 類別六:FDE 角色與爭議

26. Lemkin, J. (2026). Who Gets an FDE, and Who Doesn't: The Great B2B + AI Debate Right Now. SaaStr.
    https://www.saastr.com/who-gets-an-fde-and-who-doesnt-the-great-b2b-ai-debate-right-now/

27. Flybridge. Why 95%+ of Startups Get the Forward Deployed Engineer Role Completely Wrong.
    https://www.flybridge.com/ideas/the-bow/why-95-of-startups-get-the-forward-deployed-engineer-role-completely-wrong

28. Parekh, M. AI's "FDEs" Go from Forward Deployed Engineers to Entities. Substack.
    https://michaelparekh.substack.com/p/ais-forward-deployment-fdes-go-from

━━━━━━━━━━━━━━━━━━━━━━━

📖 延伸閱讀

這個議題在英文圈已經有幾篇值得對照的文章,如果你想看不同視角:

【主流投資人視角】
► a16z — Trading Margin for Moat: Why the FDE Is the Hottest Job in Startups (2025/6)
https://a16z.com/services-led-growth/
(從 AI 公司投資人角度,認為 FDE 是「用毛利換取護城河」的正確策略。跟本文立場完全相反,建議對照閱讀)

【科技業結構分析】
► Stratechery / Ben Thompson — The Deployment Company, Back to the 70s (2026/5/13)
https://stratechery.com/2026/the-deployment-company-back-to-the-70s-apple-and-intel/
(英文圈最有公信力的科技分析師,把 FDE 趨勢放在 1970 年代大型主機時代的歷史脈絡下分析。與本文視角互補)

【批判性聲音】
► Thomas Otter — On the Forward Deployed Engineer, PLG and genuine adoption (2025/12)
https://thomasotter.substack.com/p/on-the-forward-deployed-engineer
(前 SAP 高管尖銳批判:「很多 FDE 只是『換了酷名字的實施工程師』,不是真正的產品公司」)

► Flybridge — Why 95%+ of Startups Get the FDE Role Completely Wrong
https://www.flybridge.com/ideas/the-bow/why-95-of-startups-get-the-forward-deployed-engineer-role-completely-wrong
(從 VC 視角的批判:「FDE 模式被嚴重誤解,真正能做好的公司少之又少」)

──────────

⚠️ 誠實說明:這些文章的視角跟本文不同——a16z 是賣方視角(AI 公司該怎麼做),Stratechery 是科技業宏觀分析,本文是買方視角(企業客戶該怎麼應對)。英文圈的「企業客戶端 FDE 風險分析」幾乎沒有對應版本,本文嘗試填補的就是這個空白。