FDE 最後一哩路：AI 系統真正的戰場，是舊系統與正式環境那一段
多數 AI 專案死在 demo 之後的落地維運，不在 demo 現場。資料權限、資安合規、舊系統串接、正式環境相容性，這段沒人想碰的最後一哩路，才是 FDE 真正的戰場，也是 91APP 做 CDMP 導入時每天在處理的事。
MIT NANDA 研究計畫在 2025 年發布的《The GenAI Divide》報告算過一筆帳：企業在生成式 AI 投入超過 300 億到 400 億美元，九成五的專案卻沒有拿到可衡量的財務報酬。同一年，Gartner 更直接預測，超過四成的 agentic AI 專案會在 2027 年底前被取消，理由不是模型不夠聰明，是成本失控、價值說不清楚、風險控管跟不上。
這兩個數字放在一起，指向同一個落差：企業投入生成式 AI 的規模，跟實際拿到的財務回報，中間有一大段空白。這段空白發生在哪裡，是這篇文章要談的重點。
我們常看到的那個畫面
我們在協助品牌導入 CDMP 與個人化行銷的過程中，看過同一個場景反覆上演：行銷主管看完 demo，眼睛發亮，第一句話通常是「這什麼時候可以上線」。真正花時間的，是接下來那幾個月。會員資料庫是十年前建的舊系統，POS 跟電商後台各自維護一套自己的邏輯，資安部門要先審過一輪，才准任何一支程式碰會員資料表。我們有時會擔心，品牌把太多期待放在那半小時的展示上，卻沒把時間留給後面這段沒有掌聲的工作。
這正是 Forward Deployed Engineer（前線部署工程師，以下簡稱 FDE）這個角色近兩年被反覆討論的原因。TechCrunch 報導指出，FDE 職缺需求在 2026 年出現爆發式成長，年初僅 5% 到 10% 的公司計畫聘用 FDE，第二季底已經上升到七成，市場預期年底需求成長幅度達 2,100%。國際媒體 LeadDev 的報導指出，FDE 職缺年增率達 729%，這項數字源自人力銀行 Indeed 提供給媒體的徵才資料；數位時代的報導也引用了同一組數字。這篇文章是我們 FDE 系列 的其中一篇，系列另外幾篇分別談需求怎麼被真正聽懂、決定成敗的關鍵到底是不是速度、市場上「換皮顧問」的爭議，以及該怎麼辨別真假 FDE。這篇聚焦在系列裡技術面最深的一段：demo 結束之後，工程師實際要處理的落地工作。
三層斷點：demo 看不到的地方
FDE 的核心工作，一般會拆成需求釐清、原型設計、系統落地與維運三個階段。前兩段容易被看見，也容易被拿來當賣點；第三段最少被談論，卻最花時間、最容易讓專案卡住。本文把這段落地工作拆成三層斷點，方便對照，但這不是一份窮盡的清單，商業目標是否明確、組織願不願意調整既有流程，同樣會左右專案成敗：
| 斷點 | 典型症狀 |
|---|---|
| 資料層 | ERP、POS、會員資料庫各自維護一套欄位定義，同一位客人在三套系統裡可能是三個不同的 ID |
| 權限與合規層 | AI 要呼叫哪些內部系統、能碰哪些欄位，資安與法遵得一條一條審過才能放行 |
| 環境層 | 展示環境測不出來的流量規模、例外資料與系統依賴，正式環境跑起來才會現形 |
數位時代的報導把這件事講得直白：「當你讓 AI 去呼叫公司內部系統，誰有權限做什麼、哪些資料不能碰，這些全都要一個一個接起來。」報導也提到，「很多企業導入 AI 的第一關，卡在文件又亂又舊。」這兩句話，剛好對應資料層與權限層兩個斷點；而環境層的落差，報導用一句話講完：「這些問題在展示階段永遠看不到，只有真的走進公司，問題才會浮出來。」
把這三層拆開來看，卡住的原因並不相同。資料層的難處在於，多數品牌的會員資料庫、訂單系統、POS 系統是分不同時期建置的，各自有各自的欄位命名邏輯與資料格式，第一步往往得先把資料的定義兜起來，確認這套系統裡的「會員」跟那套系統裡的「客戶」指不指同一個人，才輪到寫程式，這件事聽起來瑣碎，卻經常佔掉整個專案最多的時間。權限與合規層的難處，在於「誰能碰什麼資料」這件事，最終要靠組織裡的人拍板，很少是工程團隊自己能單方面決定的技術規格，審查流程通常不在技術團隊的掌控之內，卻直接決定專案能不能往下走。環境層的難處最容易被低估，因為展示階段用的資料通常是篩選過的乾淨樣本，流量也是可控的；正式環境要面對真實世界的異常值、尖峰流量，以及系統彼此之間的依賴關係，一個在測試環境跑得很順的流程，換到正式環境可能因為某個舊系統回應變慢、某筆資料格式不符預期，就整條斷掉。這也是為什麼多數 FDE 團隊的工作方法，不是先把方案設計到完美才上線，是先讓系統在一個小範圍的正式環境裡跑起來，再逐步擴大範圍。
兩個案例：連寫模型的人，也需要專職團隊做落地
案例一：Palantir 十幾年前留下的原型
FDE 這個角色不是這波 AI 熱潮才出現。TechCrunch 的報導指出，這個做法源自國防承包商 Palantir，十幾年前就開始把工程師直接派進客戶組織裡，處理資料整合、系統串接這類外部顧問通常不碰的工作。Palantir 的邏輯很簡單：軟體再厲害，如果沒有人願意花時間把它接進客戶既有的系統，軟體本身的價值就發揮不出來。這個模式後來被整個產業借用，成為現在 FDE 熱潮的原型。
案例二：AWS 自己成立十億美元的落地部門
2026 年 6 月底，AWS 宣布成立專責的 Forward Deployed Engineering 組織，投入十億美元。根據 About Amazon 官方新聞稿，這個團隊會直接進駐客戶環境，跟客戶的業務、工程與資安團隊一起工作，目標是把部署時間從過去的數個月，壓縮到數天或數週。公告提到的案例裡，NFL 的系統就是在數週內做到正式上線。公告也強調，這些工程師處理的是「客戶自己的資料、治理規則與流程」，不是一個通用的展示版本。AWS 目前已公開揭露合作對象包括 Allen Institute、Cox Automotive、NBA、NFL、Ricoh 與西南航空。
這個案例值得放大看：AWS 是雲端與 AI 基礎設施最頂尖的供應商之一，模型與運算資源都不缺，卻仍然選擇成立一個十億美元規模的專責團隊，去處理「把系統接進客戶正式環境」這件事。這說明就算有共通的方法論與可複用的工作模式，資料結構、權限規則、既有系統這幾個環節，還是得依每個客戶的環境重新確認，沒辦法只靠通用的技術能力打包解決。
91APP 在做 CDMP 導入時，處理的就是這一段
我們在協助品牌落地 CDMP 與個人化行銷的過程中，花最多時間的環節，其實跟 FDE 處理的三層斷點高度重疊。品牌的會員資料通常分散在官網、門市 POS、客服系統裡，第一步通常是先把這些資料按照一致的邏輯歸戶，確認同一個人在不同通路的消費紀錄可以被合併看待，這是資料層的工作。接下來要確認哪些角色可以看到哪些會員標籤、哪些資料只能用在特定的行銷情境裡，這是權限層的工作。最後，多數自動化行銷腳本在正式上線前，都需要先確認它在真實流量下的表現，而不是只看小範圍測試的結果，這是環境層的工作。
91APP 官方部落格過去也整理過相關的落地經驗，例如線上線下的落差，通常是客人比報表更早發現這篇談的，就是 ERP 庫存數字跟電商後台不同步時，真正受影響的是消費者的購物體驗，而不是報表上的一個數字誤差。同樣地，很多 AI 應用效果不好，問題根源不在模型，是它讀不到、或不該讀到的那幾張表，這跟本文談的權限與資料層斷點是同一件事。我們認為，CDMP 真正的價值不在展示 AI 有多聰明，是有能力把資料方案放進客戶會員數據、訂單系統交織的真實環境裡，穩定地跑下去。
把落地能力寫進採購條件，比看 demo 更重要
品牌在評估 AI 或資料導入方案時，展示效果通常不是問題，真正該花時間確認的是落地那一段。以下幾件事，建議在簽約之前就先做，而不是等專案開始才發現。
- 先做一次系統盤點，列出所有要串接的對象：包含 ERP、POS、會員資料庫、金流系統，逐一確認哪些系統有開放 API、哪些欄位定義彼此不一致。這份清單決定了專案初期要花多少時間在資料整合上，越早盤點，越能避免中途才發現卡關。
- 資安與法遵審查提前到需求訪談階段：不要等技術方案定案才送審，資安團隊提出的限制往往會改變資料存取的設計方式，越晚審查，返工的成本越高。
- 資料權限用最小必要原則設計：不要一次開放系統存取所有欄位給新導入的方案，先從真正需要的資料範圍開始，之後再依實際情境擴大，這也是多數資安團隊比較容易點頭的做法。
- 把正式環境的驗證排進專案時程，別留到上線前一週才做：小範圍上線、設定好監控告警與回滾條件、觀察一段時間後再逐步擴大範圍，會比一次性全量上線更容易抓到環境層的問題。
- 選擇有實際落地維運經驗的技術夥伴：問對方過去處理過哪些舊系統整合的案例，比只看 demo 做得漂不漂亮更能反映真實的執行能力。
落地不是掃興的那一段，是價值真正發生的地方
demo 那半小時決定不了輸贏，決定輸贏的是 demo 之後那幾個月，沒人鼓掌的工作。舊系統的串接、資料權限的設計、正式環境的驗證，這些步驟看起來瑣碎，卻是一個 AI 或資料方案能不能真的替品牌創造價值的關鍵。對台灣品牌來說，這反而是一個機會：技術門檻正在被更多團隊跨過，接下來拉開差距的，會是誰更願意把時間花在這段沒有掌聲的最後一哩路上。
常見問題
Q1：FDE（Forward Deployed Engineer）是什麼？跟一般顧問差在哪裡？ A1：FDE 是指直接進駐客戶組織、負責把 AI 或軟體系統實際做到上線的工程師。跟傳統顧問最大的差異是，顧問通常止步於方案建議，執行交給客戶自己的團隊；FDE 會親自參與資料整合、系統串接、正式環境驗證這些落地工作，直到系統真正能穩定運作。
Q2：為什麼 AI 專案 demo 做得好，正式上線卻常常卡關？ A2：展示階段用的資料通常經過篩選，流量也是可控的。正式環境要面對真實的資料異常、尖峰流量與系統之間的依賴關係，這些狀況在展示階段很難被完整測試出來，只有真的走進正式環境才會浮現。
Q3：沒有專職 FDE 團隊的中小型台灣品牌，還能做好 AI 或資料落地嗎？ A3：可以，但需要把三層斷點的檢查提前做在專案開始之前，包含系統盤點、資安審查時機、資料權限設計原則。資源有限時，建議先選定一個範圍夠小的場景與單一資料來源，設定固定預算與停損點，不必一次導入全公司的系統；治理窗口也可以由外部顧問或內部單一負責人暫代，不一定要有完整的資安與法遵編制才能開始。選擇有實際落地維運經驗的技術夥伴，也能補足內部團隊在這方面的經驗落差。
Q4：系統落地與維運通常要花多久時間？ A4：時間長短取決於既有系統的複雜度與資料整合的範圍，沒有一個固定答案。以 AWS 公開揭露的 Forward Deployed Engineering 模式為例，目標是把部署時間從過去的數個月壓縮到數天或數週，但這是鎖定特定範圍任務的節奏，實際落地時程仍須依每個品牌的系統現況評估。
Q5：導入 CDMP 這類資料方案，資安與資料權限審查該什麼時候開始？ A5：建議在需求訪談階段就讓資安與法遵團隊參與，而不是等技術方案定案才送審。越早釐清資料存取的範圍與限制，後續返工調整的成本越低。
Q6：這篇文章談的落地挑戰，跟 91APP CDMP 的角色有什麼關係？ A6：91APP 在協助品牌導入 CDMP 與個人化行銷時，處理的正是文中談到的三層斷點：把分散在不同通路的會員資料歸戶整合、設計資料存取的權限規則，並讓行銷腳本在正式環境的真實流量下穩定運作。
延伸閱讀
想了解 91APP CDMP 如何協助品牌把資料方案真正落地到正式環境，歡迎與我們的顧問團隊聊聊。