如果公司已經做出幾個 AI demo，卻一直無法放進日常流程，問題通常不在「模型不夠新」。更常見的是：資料權限沒畫清楚、任務負責人不敢簽收、失敗時不知道誰回滾、最後輸出沒有人看，demo 只能停在簡報裡。
AWS 6 月 30 日宣布投入 10 億美元成立 Forward Deployed Engineering（FDE）組織，讓 AI 工程師直接和客戶團隊一起做 agentic AI 系統。這項更新超過單一雲端功能，提醒企業：AI pilot 要進入正式運轉，缺的常是現場工程能力、交接文件與治理習慣。已經有高風險流程卡住的公司，可以用這篇檢查是否需要外部 FDE；還只是在整理會議、寫文件或查內部知識的團隊，先把小流程驗收做好，不必急著把外部團隊請進來。
AWS 這次把 FDE 變成 10 億美元組織
AWS 官方公告說，新的 AWS FDE 組織背後有 10 億美元投資，會把熟悉 AWS AI 服務的工程師放進客戶的 business、engineering 與 security team，一起建置可正式運轉的 AI 系統。官方把差異說成三點：agentic-first、把交付時間從數月壓到數天、專案結束時客戶要能自立維運。
這裡要保守解讀。AWS 的「數天」是官方目標，不代表每個企業 agent 都能在一週內安全上線；不同產業的資料位置、審批、稽核與系統連接難度差很多。比較可以採信的是方向：AWS 想把模型、雲端、託管工具和現場工程能力一起包進客戶現場，協助客戶把資料、知識圖譜、runbook、文件與內部 champion 留下來。
公告也提到 FDE 團隊會把 semantic layer 放在客戶自己的 AWS account 裡，連接企業資料來源，產生 governed、versioned knowledge graph，並讓 agent 在這個知識圖譜上推理。安全面則主張硬體隔離、端到端加密，以及客戶資料不離開既有治理框架。這些都還需要客戶自己審查；AWS FDE 的賣點落在資料、權限、正式運轉和內部能力，不停在「找人幫忙寫 prompt」。
這和 Microsoft/EY 案例其實是同一條路
Microsoft 5 月公布 EY 案例時，重點從員工試用 AI 的新鮮感，移到把 AI 接進核心流程。Microsoft 說 EY 先把 Microsoft 365 Copilot 擴展到 15 萬人，結果包括 15% productivity gain、94% monthly adoption、85% weekly usage，以及 81% 員工回報節省時間。更接近正式營運的部分，是財務營運的 intelligent agents 讓 lead time 加快 95%、營運成本降低超過 37%，多代理框架進入 13 萬名 Assurance professionals 與 16 萬個 audit engagements，稅務文件自動化讓人工工作最高減少 90%。
這些數字都來自 Microsoft 官方合作敘事，不能當成每家公司可複製的承諾。它們有用的地方，是把 AI pilot 的評估尺度拉高：同時檢查員工是否穩定使用、AI 是否進入核心流程、誰負責驗收、節省時間是否回到高價值工作、風險是否可追蹤。
把 Microsoft/EY 和 AWS FDE 放在一起看，供應商競爭正在往同一個方向走：企業採購的內容，正從聊天工具擴大到把 AI 接回業務現場的工程能力。這對讀者的影響很直接。若公司內部還沒有能把資料、流程、權限、監控與人類審查串起來的人，再多買一套模型也很難把 pilot 變成可交接的系統。
什麼情境才值得找 FDE 或外部團隊
FDE 不該變成新的流行採購理由。先用任務風險分流，會比看到 10 億美元新聞就安排大型專案安全。
| 你的情境 | 本週建議 | 先不要做 |
|---|---|---|
| 只是會議摘要、文件草稿、低風險知識查詢 | 先由內部小組建立範本、資料邊界與人工確認習慣 | 為了低風險任務找外部工程團隊長駐 |
| pilot 已接到 CRM、ERP、資料倉儲或客服系統 | 補資料與權限表，確認哪些欄位能被 agent 讀寫 | 先追求更多功能，卻不寫失敗回滾方式 |
| agent 產出的內容會影響報價、審計、合約、醫療、金融或法務判斷 | 找到任務負責人與最後輸出審查人，設定正式運轉門檻 | 把 AI 輸出直接接進高風險決策 |
| 內部工程團隊知道流程，但沒時間把 agent 做成可維運系統 | 評估 FDE、SI 或顧問團隊是否能留下 runbook、架構文件與內部 co-builder | 把外部團隊當黑盒，專案結束後沒有人接手 |
這張表的用途，是先把外部協助的任務寫清楚。好的 FDE 或顧問團隊，應該讓客戶工程師從旁觀者變共同建置者，最後能自己看懂資料來源、權限、監控、成本和回滾。若專案只留下 demo，沒有留下內部能力，下一次改流程時仍會卡住。
本週先補三張表
第一張是任務責任表。每個 AI pilot 都要寫清楚：它處理哪個流程、輸出給誰看、誰批准正式運轉、誰在錯誤發生時停用或回滾。不要只寫「客服 agent」或「財務助理」，要寫成可驗收的任務，例如「收到客訴後整理三段摘要，送給客服主管確認，再由人員回覆」。
第二張是資料與權限表。列出 agent 需要讀哪些系統、能寫回哪些欄位、哪些資料只准摘要不能外傳、哪些動作需要人類核准。這張表如果寫不出來，表示還沒準備好讓 AI 接進核心流程。此時找外部團隊可以協助盤點，但不該直接要求它把系統做完。
第三張是正式運轉驗收表。把成功標準拆成時間、品質、成本、風險和交接：是否縮短處理時間、人工覆核是否變少、錯誤是否可追蹤、成本是否有上限、內部工程師是否能重跑和修正。這些標準比「模型回答看起來合理」更接近企業會買單的結果。
若你已經在規劃 AI agent 正式運轉，可以把這三張表接到 企業 AI agent 檢查清單 和 AI Agent Production 部署指南 裡。外部 FDE 進場前，這些表會幫你判斷對方是在補現場能力，還是只是把 demo 做得更漂亮。
採購前要問的風險
第一，官方案例不能視為採購承諾。Microsoft/EY 的採用率和 AWS FDE 的交付速度，都是大型供應商公布的案例或目標；你的公司要看自己的資料複雜度、審批速度、內部工程能力和產業限制。
第二，外部團隊不能替公司承擔最後責任。即使 FDE 在客戶 account 裡做系統，誰能批准高風險動作、誰能看敏感資料、誰簽收輸出，仍要由公司內部決定。
第三，正式運轉會持續變動。Agent 接到更多資料與工具後，prompt injection、權限誤用、成本暴增、錯誤寫回、監控漏失都會變成日常風險。外部團隊若沒有留下觀測、告警、回滾和訓練文件，專案結束後反而會增加維護壓力。
常見問題
AWS FDE 是新工具，還是顧問服務？
它比較像工程交付組織，產品按鈕只是其中一小部分。AWS 官方說 FDE 會把熟悉 AWS AI 服務的工程師放進客戶團隊，協助建置正式運轉的 agentic AI 系統，並留下知識圖譜、runbook、文件和內部 champion。
中小企業也需要 FDE 嗎？
多數中小企業先不需要。若任務還停在文件、會議、知識查詢或低風險自動化，先整理範本、資料邊界和人工確認流程就好。只有當 AI 已經卡在跨系統資料、高風險決策、正式運轉責任或內部工程人力不足時，才值得評估外部 FDE、SI 或顧問團隊。
Microsoft/EY 的數字可以直接拿來估 ROI 嗎？
不建議。那些數字來自 Microsoft 官方合作案例，適合當評估指標參考，不適合直接套進自己的預算表。比較安全的做法，是用同樣類型的指標重算自己的 baseline：採用率、節省時間、品質、錯誤率、人工覆核時間和正式運轉成本。