Palantir 的真正護城河：FDE 把現場知識寫進 Ontology，AI FDE 再接手工程

先看結論：企業買的不是模型，而是完成工作的能力

Palantir 經常被稱為重交付公司，但它與傳統顧問的關鍵差異，是前線經驗有一個可以持續吸收的產品底座：Ontology。報告整理 Palantir 的定義，Ontology 是企業的作業層，不只描述有哪些資料物件與關係，也描述可以執行哪些動作、呼叫哪些函式，以及受到何種權限與治理限制。FDE 進入現場後，不是替每位客戶做一套孤立系統，而是把有效知識逐步映射回共同語義。

這個題目值得獨立拆解，因為企業 AI 已經走到第二個階段。第一階段比的是模型能不能回答，第二階段比的是系統能不能在資料不完整、權限複雜、流程跨部門的環境裡，穩定交付可衡量結果。Palantir 的真正護城河：FDE 把現場知識寫進 Ontology，AI FDE 再接手工程不是技術名詞的排列組合，而是一個組織、工程與財務必須同時成立的問題。

運作機制：把人的經驗翻成 Agent 可執行的規則

Palantir 以 Data、Logic、Action、Security 四個維度建模企業決策。人類 FDE 先理解資料、工作流程、業務物件與決策限制，Ontology 將模糊經驗轉成機器可理解的語義；AIP 再在此基礎上建立工作流程、Agent 與函式。AI FDE 則能透過自然語言操作 Foundry，建立資料管線、編輯 Ontology、開發函式、處理權限與建置應用，並透過模式、能力、計畫、分支與程式碼審查控制執行。

不同廠商的共同方向，是讓少數核心 FDE 攻克複雜現場，再用平台、夥伴與客戶自助擴大覆蓋。差別在於資產沉澱在哪裡：Palantir 放進本體模型與 AIP，模型公司放進技能與執行框架，雲端業者放進 Agent 平台與夥伴交付工具，企業軟體公司則把多年流程與權限直接寫進底座。

實務上應先畫出原有流程的輸入、判斷、工具、輸出與例外，再決定哪些環節交給 Agent、哪些需要人工核准。這個順序很重要：若先拿模型找題目，團隊容易做出技術可行但商業低頻的功能；若先找出高成本、高等待或高錯誤的流程，再設計資料與執行環境，投資報酬率才有機會被驗證。

財務視角：從專案收入走向能力複製

這套結構讓 Palantir 的服務支出具有資產化機會。早期專案的人類 FDE 投入仍重，但既有物件、權限、函式與工作流程可以被後續團隊重用；AI FDE 又進一步自動化資料轉換、程式與設定工作，讓人類聚焦高價值問題抽象。若複用成立，每位 FDE 能支撐更多客戶，平台收入成長可以快過交付人力。

財務長應把成本拆成五層：場景診斷、資料與系統串接、模型推論、執行框架、上線後的人工作業。初期毛利偏低不必然代表模式失敗，因為第一批客戶可能同時支付產品學習成本；但下一批同類客戶若沒有明顯縮短交付週期，代表知識沒有資產化。最重要的曲線，是每一元新增收入需要多少新增工程人力與模型成本。

收入品質也要分開看。一次性顧問費能證明客戶願意付錢，訂閱與用量收入則更能反映系統已進入日常流程；成果分成若能建立清楚基線，可能提高上限，但也會帶來歸因與合約爭議。健康的商業組合通常是以前期服務完成導入，再讓軟體、技能模組與執行量成為後續擴張主體。

執行方法：從一個高價值流程開始

企業若要學 Palantir，不應先畫一張巨大本體圖，而是從一條流程的核心物件、狀態、動作與權限開始。例如採購可先定義供應商、標案、核准、合約與風險，再把 Agent 能採取的動作與限制附上。當流程實際運行，新例外與回饋再更新模型。Ontology 的價值來自被工作流程使用，不是圖上連線多。

導入時應先定義成功與失敗。成功不只包含平均任務時間下降，也包括錯誤率、人工覆核、法遵事件與使用者採用；失敗則要能被分成模型、資料、權限、工具、流程或組織責任。分類清楚後，每次錯誤才會變成測試資料與產品改進，而不是群組裡又多一張『AI 怎麼又壞了』的截圖。

反方論證：重交付也可能只是昂貴的人力生意

Palantir 案例建立在多年平台、工具與前線工程文化上，不能只模仿職稱或本體模型名詞。企業若沒有資料治理、權限責任與持續產品化團隊，Ontology 容易變成昂貴文件；AI FDE 若權限過大，也可能直接修改關鍵資料與程式。人類審查、分支、測試與最小權限仍是不可省略的控制。

廠商案例多半是公司或報告選出的成功樣本，不能直接外推到所有客戶。閱讀時要分清楚已上線的實際成果、合作公告、產品規畫與券商推論；尤其 2026 年的新組織與新平台仍需時間驗證續約、毛利與複用程度。案例可以提供路線，不能替財務證據簽名。

此外，報告整理的數據包含企業調查、公司案例、產品公告與研究判斷，可信度與時間點並不完全相同。本文保留原始頁碼，並把已發生事實、廠商所述規畫與延伸分析分開呈現。對快速變動的 Agent 市場而言，最危險的不是判斷暫時錯，而是把尚未驗證的規畫寫成已經實現的財務成果。

台灣企業可以怎麼用：先做流程資產負債表

台灣製造業可以先從設備、工單、物料、品質事件與維修動作建立輕量本體，讓不同系統有共同語言。重點是把工程師與現場主管的判斷規則附著在物件和動作上，而不是另建一套聊天介面。軟體商若能累積跨客戶可重用的產業本體與動作範本，會比單次模型串接更有長期價值。

接下來可固定追蹤：1、Ontology 是否實際驅動工作流程；2、AI FDE 可操作能力與權限；3、共用物件跨客戶複用程度；4、人類 FDE 人均產出是否提升。這些指標同時涵蓋技術、流程與財務，能避免團隊只挑對自己有利的數字。對台灣企業而言，最務實的起點通常不是成立一支龐大 AI 部門，而是選一條跨資料、跨系統、又能直接衡量成本或營收的流程，讓小型 FDE 團隊與業務負責人共同完成第一個生產閉環。

最後要記住，真正的護城河不是 Prompt 數量，而是企業願不願意把規則、失敗案例與決策邊界持續沉澱。模型會升級、單價會下降、工具名稱也會換季；留在公司裡的本體模型、測試資料集、連接器、技能模組、權限設計與營運紀錄，才是能在下一輪技術變化中繼續複利的資產。