Microsoft 和 EY 把 AI Pilot 變上線

Microsoft 和 EY 的合作，重點不是買更多 AI 功能，而是把 pilot 變成可治理、可上線的 production。

我盯企業 AI 兩年了，最煩的就是同一齣戲一直重播：demo 很漂亮，pilot 很熱鬧，會議室裡每個人都說「有潛力」，然後就沒有然後。聊天機器人會寫 email、會議記錄也像那麼回事，大家看完點頭，彷彿問題解完了。沒有。真正卡住的從來不是模型會不會講話，而是權限、資料品質、法務、稽核軌跡、流程改造，還有一個更現實的問題：出事了誰扛。

所以我看到 Microsoft 和 EY 這個合作時，第一個反應不是「哇又一個大聯盟」，而是覺得這很像業界終於願意把醜話講白。Microsoft 早就知道，Copilot 不會自動把一個稅務結算流程或理賠流程重寫好；EY 也知道，AI transformation 如果只停在 sandbox，最後就是一堆簡報和一個沒人敢碰的系統。這次他們賣的不是炫技，而是工程、治理、流程重設、主管背書這些很無聊但很要命的東西。

這份拆解的起點來自 Windows Forum 的整理文，裡面把這筆合作解讀成 Microsoft 下一步的企業 AI 銷售打法。我就拿這篇當錨點，往下拆它到底在賣什麼、企業又該怎麼抄。

Microsoft 不再賣 AI 功能，而是在賣部署

“Microsoft is no longer merely shipping AI features and waiting for enterprises to discover value on their own.”

翻譯一下就是：Microsoft 已經發現，企業 AI 的瓶頸不是功能不夠，而是部署不過關。功能表再長都沒用，真正卡住的是它怎麼進到公司裡，怎麼跟 identity、security、data governance、流程責任黏在一起，還不爆炸。

我自己看過太多內部導入死在這一步。團隊很興奮，先拿 assistant 去試幾份文件，然後馬上撞牆：模型碰不到正確的系統、資料散在 SharePoint 跟 email 裡、沒人想簽那個風險責任書。AI 本身沒那麼差，差的是組織還沒準備好當一個能跑 AI 的組織。

這也是 Microsoft 和 EY 配在一起有意思的地方。Microsoft 提供平台和技術骨架，EY 提供流程語言和高層信任。兩邊合起來，賣的其實是「從 demo 走到正式系統」這條路，不是單點工具。

你如果本來就在 Microsoft 生態裡工作，這個故事會更清楚。Copilot、Microsoft 365 E7、Microsoft Entra、Microsoft Purview 不是各自獨立的產品，而是同一個控制平面上的不同層。AI 被包進這層裡，才像是 enterprise 真的能消化的東西。

實操上，我會建議你別再用「這工具好不好用」的角度評估 AI。你要問的是：誰擁有 workflow、誰批准資料存取、誰審核輸出、錯了誰負責。這些問題答不出來，你手上就不是 deployment plan，只是一個 demo。

Forward Deployed Engineer 其實就是企業 AI 的真銷售

“Rather than hand customers a platform and wait for internal teams to figure it out, embed engineers close to the business problem.”

這句話翻白話，就是：別再丟一個平台給客戶，然後叫人家自己想辦法。工程師要貼近業務問題，直接把東西接起來，讓它真的能跑。這套思路最早大家常拿 Palantir 的 Forward Deployed Engineer 來講，因為它真的解掉一個老問題：企業不缺平台，缺的是會把平台落地的人。

我很認同這個方向，因為 enterprise AI 的 sales motion 已經變了。工程師不再只是 pre-sales 的技術陪跑，而是 architect、translator、還有某種程度上的心理輔導員。你得懂 API、權限、模型行為，還得懂客戶組織裡誰怕什麼、誰會擋什麼、誰只是嘴上說支持。

我自己碰過最常見的失敗模式，不是模型壞掉，而是整合壞掉。assistant 不能讀對的文件庫，流程跨了三個部門，法務要 logs，security 要 least privilege，營運怕它會增加工作量。一般 SaaS rollout 還能靠使用者自己摸索，AI 不行。因為一旦 agent 能動手，風險就不是「用不用」，而是「它能動到哪裡」。

Microsoft 這次把 EY 拉進來，很像是在承認這件事：企業 AI 需要一座人橋。EY 擅長站在 executive 跟 operations 中間，把抽象願景翻成可執行的流程；Microsoft 則是把技術橋接做好。這不是公關話術，這是 enterprise 銷售現實。

實操上，如果你在做內部 AI，我會直接建議你指定一個真的 owner，而且這個人不能只坐平台團隊。他要能跟業務一起看流程，也要懂怎麼把系統接起來。沒人能同時講清楚 workflow 跟 control requirements 的話，先別急著上線。

EY 的 Client Zero 才是客戶會抄的地方

“EY deployed Microsoft’s Copilot AI assistant to 150,000 users and saw a 15 percent productivity improvement.”

這句就是商業誘因。150,000 users、15 percent productivity improvement，這種數字很會勾人。我對 AI 宣稱的 productivity 數字一向很保留，因為它常常只是「寫得快一點」「找資料順一點」「少做一些行政動作」，被包裝成超大成果。

但重點不是那個百分比，而是 Client Zero。顧問公司最愛教客戶轉型，卻把自己家裡維持原狀；所以當 EY 說自己把 Microsoft 365 E7: The Frontier Suite 擴到超過 400,000 名員工、Copilot 也推到 150,000 users，這件事就變得有說服力。至少它在說：我們不是只會畫圖，我們自己也真的在跑。

這種「先拿自己開刀」的做法，對企業買家很重要。因為大家心裡都在問同一件事：你是真的做過，還是只是賣我一份 deck？如果 vendor 或 partner 可以拿出內部部署、訓練、衡量、治理的證據，買家至少會少一點戒心。不是放心，是少一點戒心，這已經很不錯了。

我以前也踩過類似的坑。工具看起來很美，case study 也很漂亮，但內部訓練很空、使用數據只會秀 vanity metric、沒人能說清楚省下來的時間怎麼變成 business value。這就是 AI 專案最常見的幻覺：你省了 20% 的撰寫時間，不代表你真的賺到 20% 的價值。那 20% 接下來是拿去更快交付、降低風險、還是只是多開兩場會？

實操上，我會要求你先定 business outcome，再定 model。先選一個 workflow，量 baseline 的時間、錯誤率、重工率、核准延遲，再把 AI usage 對到其中一個指標。你如果連「這工具到底改善哪個數字」都說不清楚，那 productivity 只是牆上的貼紙。

Microsoft 365 E7 才是主菜，Copilot 只是入口

“Microsoft wants customers to stop thinking of Copilot as an add-on and start thinking of AI as part of the enterprise control plane.”

這是我覺得很多人會看漏的地方。這次合作不是只在推 Copilot，而是在把 AI 包進更大的 enterprise bundle 裡：Microsoft 365 E7、identity、compliance、security、agent governance，一起打包講故事。

白話一點說，Microsoft 想讓 AI 變成基礎設施。當你的文件、帳號、政策、端點、稽核工具本來就活在 Microsoft 世界裡，AI 直接接進同一個 stack，就會很順手。企業買單時最怕的不是功能少，是整合痛。沒人會因為自己引入更多整合地獄而升官。

但這裡也有代價。AI 越依賴單一 vendor 的 control plane，這個 vendor 就越容易變成你所有相關問題的預設答案。你喜歡這個 stack 的話，那是方便；你在意採購籌碼的話，這就不一定舒服。

文章裡提到 Entra、Purview，其實是在說同一件事：AI governance 不是另外加一層，而是 identity、policy、compliance 本來就是 AI layer。這套敘事很順，也確實解決了很多行政問題。

實操上，我會建議你在簽約前先畫依賴鏈。誰負責驗證身份？誰控制權限？logs 放哪裡？agent 的權限誰能撤？這些問題如果 vendor 答得很飄，你買到的就不是 AI，而是一個延後爆炸的麻煩。

Agentic AI 會把 IT 從管理工具變成監督勞工

“An assistant that drafts text is one thing; an agent that can pursue goals across systems is another.”

這裡就是分水嶺。會寫文案的 assistant 很實用；能跨系統追目標的 agent 就是另一個物種。當 AI 開始真的能動作，IT 做的就不再只是部署軟體，而是在監督一個數位勞工。

也就是說，問題會從「它能不能摘要這封信」變成「它看得到什麼、能改什麼、誰批准的、怎麼證明它沒有亂來」。這比單純聊天難很多，而且我老實講，大多數組織現在還沒準備好。

我看過不少團隊一開始很愛 autonomy，等到第一個 permission issue 出現就直接卡死。這很正常。因為 agent 一旦能建立 ticket、改 record、甚至建議財務動作，你就需要邊界：human approval、logging、rollback、role-based access、review loop。這些不是加分項，這些就是產品本體。

Microsoft 在 E7 故事裡塞進 Agent 365，我覺得就是在對準這個焦慮。下一個企業買家不會只問「它會不會寫」，而是問「我能不能先把這東西管住，不要讓它像一個拿到 API 權限的過度自信實習生亂跑」。

• 先用白話定義 agent 的任務範圍，再讓它碰系統。
• 每一次 action 都要留 log，不要只記 prompt。
• 涉及金流、權限、合規狀態的動作，一律保留人工核准。

實操上，我會把 agent 當成新進員工來管，而且是職責很窄的新進員工。你不會讓一個 day one 的新人直接自己決定敏感流程，那 agent 也不該直接做。先從 read-only 開始，再到 recommendation，最後才是有 approval 的 constrained action。這順序真的省很多麻煩。

pilot 失敗，多半不是技術，是治理穿了技術外衣

“The enterprise AI market is crowded with proof-of-concepts that impressed executives in controlled demos and then stalled when exposed to real business systems.”

這句話我很想直接貼在每個 AI steering committee 會議室的牆上。pilot 失敗聽起來像技術問題，實際上常常是組織問題。不是模型不夠聰明，是組織沒決定 demo 結束後誰接手。

白話一點說，pilot 之所以死掉，是因為沒人先回答這幾題：誰擁有流程改造？誰訓練使用者？誰更新 policy？誰簽風險？誰出 production 預算？這些答案只要有一題模糊，pilot 就會慢慢變成表演。

Windows Forum 那篇文把 Microsoft 和 EY 形容成把 adoption、governance、business redesign 打包賣，我覺得這講得很準。因為很多公司買的是工具，但真正需要的是 change program。這兩個不是同一件事，硬要混在一起，最後就是預算被燒掉，然後大家互相怪。

我自己也看過很典型的場景：pilot 發表會很漂亮，大家鼓掌，真正要進 production 的團隊根本沒被問過需求。然後過兩個月，事情卡住，所有人都裝驚訝。我一點都不驚訝，我只是有點煩，因為這套路真的太熟了。

實操上，我會要求任何 pilot 在批准前先附 production checklist。至少要有 data access、security review、training plan、success metrics、rollback plan、owner、budget source。你如果連 demo 之後誰接手都講不出來，那它不是 pilot，它只是 presentation。

可抄的模板

# 企業 AI：從 pilot 走到 production 的可抄模板

## 1) 先定 workflow，不要先定模型
- 只選一個具體流程，不要用「提升部門效率」這種空話。
- 把流程寫成 before / after。
- 列出 AI 會讀哪些系統、寫哪些系統。

## 2) 先畫 guardrails
- AI 可以碰哪些資料：
- AI 可以自動做哪些動作：
- 哪些動作一定要人工核准：
- logs 要保留多久：
- audit 要去哪裡查：

## 3) 指定 owner
- Business owner：
- Technical owner：
- Security owner：
- Compliance owner：
- Training owner：

## 4) 先量 baseline
- 每件事平均花多久：
- 錯誤率：
- 重工率：
- 核准延遲：
- 使用率：

## 5) pilot 只做最小可控範圍
- 先從 read-only 或 recommendation 開始。
- 限定使用者群。
- 前期每天 review output。
- 把失敗案例和例外情況記下來。

## 6) 決定它能不能升級到 production
- 有沒有真的省時間：
- 有沒有降低風險：
- 有沒有提升品質：
- 組織能不能持續 support：
- 有沒有 rollout 預算和正式 owner：

## 7) production checklist
- Identity / access 已驗證
- Data source 已核准
- Logs 已啟用
- Human approval flow 已寫清楚
- Training 已完成
- Support process 已定義
- Rollback plan 已測過

## 8) 可直接貼進內部文件的治理說明
我們只批准這個 AI workflow 在以下範圍內運作：

Scope：
[填入具體任務]

Allowed inputs：
[填入核准資料來源]

Allowed outputs：
[填入允許的動作]

Human approval required for：
[填入例外情況]

Owner：
[姓名]

Review cadence：
[weekly / monthly]

Audit log location：
[連結]

Rollback plan：
[如何停用或回復]

這段不是 Microsoft 或 EY 原文，而是我把他們這種打法拆成一個你可以直接拿去內部用的版本。核心很簡單：不要把 AI 當工具賣，要把它當一個受治理的工作流程來上線。

原始來源是 https://windowsforum.com/threads/microsoft-and-ey-1b-ai-partnership-from-pilots-to-governed-production.419180/。上面關於 enterprise AI、治理、流程設計的拆解是我自己的整理，模板則是我把這套方法論改寫成可直接複製的版本。