FDE 讓企業 AI 從 Demo 變上線

我拆解 Microsoft 和 EY 怎麼把 FDE、顧問和流程改造包成企業 AI 落地套路，最後給你可直接套用的版本。

我最近一直盯著企業 AI 怎麼落地，越看越煩。Demo 都很漂亮，主管也都會點頭，問題是點完頭之後呢？回到財務、法務、營運、業務的日常流程，事情就開始卡：誰負責、資料在哪、錯了誰扛、能不能過稽核，全部冒出來。模型通常不是最大問題，真正讓案子死掉的，是從「看起來很酷」走到「星期二早上真的能用」這段路，沒人接。

所以我看到 Microsoft 跟 EY 合作推企業 AI adoption 的時候，第一反應不是興奮，是「啊，終於有人把最難賺但最重要的那段拿出來賣了」。Microsoft 的 Forward Deployed Engineers，加上 EY 的產業顧問能力，這組合很老派，但也很誠實：不是只賣模型，而是把技術、人、流程、風險一起打包。

他們賣的不是 AI，是 adoption

The $1 billion partnership, announced Thursday (May 21), will see Microsoft’s Forward Deployed Engineers (FDE) and EY industry professionals join forces to accelerate artificial intelligence (AI) adoption.

翻譯一下就是：這不是在賣一個更會聊天的模型，這是在賣「你公司真的用得起來」這件事。企業買單的從來不只是能力，而是能力怎麼塞進既有流程，怎麼過控制，怎麼不把法務搞瘋，怎麼不讓前線員工覺得又來一個會拖慢工作的東西。

我自己看過太多 AI 專案死在錯的框架。大家把它當軟體採購，結果 AI 更像系統整合加流程重寫，再加一層人性阻力。你就算模型準，也可能因為資料權限沒談好、輸出責任沒定、例外情境沒設計，最後整個案子只能停在試點。

Microsoft 跟 EY 這個玩法，本質上是在賣信任、導入、和產業語境。Microsoft 提供平台跟工程火力，EY 提供企業語言、治理語言、以及大公司本來就會買單的顧問包裝。這很重要，因為多數高層不是想再聽一場 AI 簡報，他們是想知道：這東西出事的時候，誰負責把它修回來。

實操寫法很簡單：不要把 AI 當成功能清單的一項。先定義業務流程，再把 AI 放進去，最後才決定誰對輸出負責。如果你是內部推動者，先畫流程、列風險、定簽核；如果你是供應商，別先講模型參數，先講你願意陪客戶把哪個流程改成可上線。

FDE 不是配角，是這套玩法的核心

Microsoft 這邊最值得注意的是 Forward Deployed Engineers。名字很像內部黑話，但意思其實很直白：技術人員不要躲在銷售簡報後面，要直接貼著客戶的真實問題工作。這跟傳統 enterprise software 那種「你自己去 portal 裡摸」的玩法差很多。

白話一點說，Microsoft 其實是在承認一件事：企業 AI 失敗，通常不是模型太爛，而是導入層太弱。有人要去接系統、測邊界、調 prompt、管權限、看 log、處理例外，還要避免業務把工具用成合規災難。這些事如果沒人扛，AI 再強也只是 demo。

我之前幫團隊試過內部知識助理，第一場 demo 幾乎都會讓人覺得「喔，還不錯」。真正麻煩的是第二場會議開始：它能不能讀 SharePoint？如果答案跟政策衝突怎麼辦？誰能看紀錄？法務要不要能刪資料？這些都不是產品問題，是 deployment 問題。而 deployment 問題，最怕的就是只有 sales，沒有能當場解題的工程人員。

FDE 的價值，就是把「想試試看」和「在一個可控範圍內真的上線」之間的距離縮短。企業要建立信心，靠的不是宏大敘事，是先把一條雖然醜但有用的流程跑順。只要一個 team 願意每天用，後面才有機會談擴大。

• 先挑一條流程，不要一次碰十條。
• 選有明確痛點的工作：時間、成本、錯誤率、積壓量都行。
• 第一版一定要窄，窄到團隊真的看得見問題在哪。

實操寫法：如果你在評估 vendor，直接問三件事。第一，合約簽完後誰會坐進你的營運會議室。第二，前 3 次失敗怎麼處理。第三，什麼會被記錄、什麼能關掉、什麼情況要回滾。這三題答不順，通常就是在賣 demo，不是在賣 adoption。順便看一下 Microsoft 官方對 FDE 的說法：Microsoft Forward Deployed Engineers。

EY 的角色很土，但很值錢

EY 在這個聯盟裡不是裝飾品。大型顧問公司本來就吃 controls、governance、產業流程 mapping 這一套。這些字看起來很無聊，但企業 AI 最缺的就是這些無聊東西。真正難的不是把模型拉起來，而是讓銀行、製造、保險、零售這些組織，能在不踩合規雷的前提下把 AI 用起來。

也就是說，EY 幫 Microsoft 補上的是企業語言。顧問會把 rollout 講成風險、營運模式、商業效益，這些詞高層聽得懂，也比較願意簽。更現實的是，大公司很多時候不是缺工具，是缺一個能把技術團隊跟流程 owner 拉到同一張桌上的翻譯機。

我看過不少團隊被「通用 AI 助理」迷住，覺得只要丟進公司，大家就會自動受益。這種想法通常只活在第一週。只要工具碰到真實紀錄、真實核准、真實客戶工作，整個組織就會開始問：資料權限誰管？錯誤誰修？例外怎麼辦？這時候沒有流程設計，AI 只會變成新的混亂來源。

實操寫法：如果你在大公司推 AI，不要讓它只待在 innovation 團隊。把法務、稽核、營運、IT、流程 owner 全拉進來，先談規則再談試點。如果你是做 AI 服務的，直接把導入包做完整：控制項、升級路徑、回滾機制、訓練計畫，一起賣。企業買的不是一個模型，是一套能過會議、過稽核、過內部政治的方案。

• 先找流程 owner，不要只找系統 owner。
• 試點前把 approval path 寫清楚。
• 先列出 AI 不能做什麼，再談它能做什麼。

企業 AI 的真問題其實是信任

大家都愛講 productivity，但企業 AI 真正卡住的常常不是效率，是信任。員工要相信它夠準，不會偷看敏感資料，不會亂講，還要相信主管不會拿它當藉口亂砍人。這些東西沒先處理好， adoption 就只會停在 pilot purgatory，永遠在試點。

Microsoft 跟 EY 這個組合有意思的地方，就在於它想同時借兩種信用。Microsoft 提供平台和工程深度，EY 提供 business-facing 的信任層。兩邊合起來，其實是在回答企業最現實的一題：這東西出包了，誰負責？聽起來很冷血，但 enterprise software 本來就不是只賣功能，還賣責任邊界。

我看過很多團隊死盯模型準確率，結果真正擋住 adoption 的，是使用者不信任。只要有人覺得它會 hallucinate，就算它大多數時候是對的，也不會放心用。更別說如果沒人看得懂它為什麼做這個建議，大家只會把它當成黑盒子，最後還是回去手工處理。

實操寫法：把 trust 做進 workflow。顯示來源、保留 decision log、讓人工覆核很明顯、公開系統能做與不能做的範圍。如果輸出會影響金錢、客戶、合規，就一定要有可見的 challenge path。這不是加分項，這就是 adoption 的本體。

顧問沒有死，只是換成服務加軟體

很多人愛講公司想 self-serve AI，聽起來很美，但我看大組織還是很依賴顧問，尤其當風險高、組織亂、部門多的時候。這筆合作其實提醒我一件事：AI 沒有把 consulting 幹掉，反而把 implementation 的需求照得更亮。

也就是說，企業 AI 正在變成 services-plus-software 的包裝。軟體負責吸睛，服務負責讓預算比較容易過。對 CFO 來說，rollout package 比一個單純的模型授權更好理解；對業務主管來說，轉型計畫比一串技術名詞更能拿去開會。

我不是說這很優雅，老實說一點也不。但它很符合現實。大多數公司沒有內部能力，把一個能用的模型變成跨部門、可監控、可回滾的穩定流程。這時候就需要有人能在技術團隊和業務團隊之間來回翻譯，而且不要把大家都搞到很煩。

實操寫法：如果你在做內部 AI 能力，別假裝 change management 不重要。預算裡要放訓練、流程重設、支援成本。如果你在賣 AI，導入服務要當成產品的一部分，不是附加選項。如果你在選 vendor，直接問 pilot 之後怎麼 rollout。真正的成本，通常都長在那裡。

我最想看的不是大數字，是第一個無聊用例

新聞裡那個金額很大沒錯，但我更在意他們第一個到底落地什麼。因為真正能看出這是不是一套工作模式，不是看合作聲明多漂亮，而是看第一個 use case 是什麼：客服、內部知識檢索、文件處理、程式協作，還是別的。

翻譯一下就是：最後贏的，不會是最大聲的 demo，而是最可重複的流程。那種一週跑一千次、有結構可以自動化一部分、但又有風險需要 guardrails 的工作，才是 enterprise AI 真正能收錢的地方。

我現在看這種合作，已經不太看口號了，我只看第一個部署細節。誰管 metric？出錯誰被叫？模型 drift 怎麼辦？能不能快速 rollback？這些問題一出來，基本上就知道這是實作，還是公關稿。

實操寫法：如果你要選第一個 AI 專案，就挑窄、重複、痛的流程。成功定義也別寫得太玄，直接用 operational 指標：每件省幾分鐘、錯誤率降多少、ticket 多快關、積壓清多少。不要先談 transformation，先挑一條大家本來就很討厭的流程。

可抄的模板

# 企業 AI adoption playbook

## 目標
把一條高摩擦業務流程，改成可控、可追蹤、有人負責的 AI 輔助流程。

## 團隊分工
- 業務 owner：負責流程與結果
- 技術 lead：負責整合、logging、rollback
- 風險/法遵 reviewer：負責資料、政策、核准規則
- 變更推動者：負責訓練與 rollout

## 用例挑選標準
選一條同時符合以下條件的流程：
- 重複性高
- 量大
- 可量化
- 夠痛，大家真的想改善
- 風險可控，能先從小範圍試點

## 試點範圍
- 一個 team
- 一條流程
- 一份 source of truth
- 一條 approval path
- 一個 rollback plan

## 運作規則
- AI 可以建議、摘要、分類、起草
- 任何影響金錢、客戶、合規的動作都要人工核准
- 系統要能顯示來源（如果有）
- 所有輸出都要記錄
- 敏感資料只能留在核准過的系統裡

## 成功指標
- 每個任務省下的時間
- 導入前後錯誤率
- 目標團隊的採用率
- 升級/例外處理比例
- rollback 次數

## Rollout checklist
1. 先畫出現況流程
2. 列出失敗案例
3. 設定資料存取規則
4. 加上 logging 與 review
5. 先訓練第一批使用者
6. 用小範圍跑 pilot
7. 每週檢討結果
8. 只有流程穩了才擴大

## Vendor 該問的問題
- 合約簽完後，誰會陪我們做導入？
- 前三次出錯誰處理？
- 什麼會被記錄？
- 什麼能關掉？
- 哪些資料不會進系統？
- 輸出錯了怎麼回滾？

## adoption 原則
不要把 AI 賣成一個 feature。
把它賣成一個有 owner、有控制、有量化結果的流程改造。

我會把這份模板刻意寫得很短，因為企業 AI 本來就夠多東西了。你不需要 40 頁轉型簡報，你需要的是一個夠硬的操作模型，讓每個人都知道自己負責什麼、系統能做什麼、怎樣算成功。

如果是我自己拿去內部推，我會先填 team、pilot scope、operating rules，然後逼 business owner 跟 technical lead 先把 rollback plan 對齊，再讓任何人碰 production。這一場會議，通常比後面十次救火值錢。

來源我放這裡：原始觸發文章是 PYMNTS.com 的 Microsoft and EY Team to Promote Corporate AI Adoption，Microsoft FDE 的背景則來自 Microsoft 官方頁面。上面這篇是我自己的拆解與重組，不是原文翻譯。