導入評估:
買 vs 自建

一家有 30 年歷史的製造集團:12 套老 ERP/MES、資料主權要求不能上公有雲、想做「跨廠即時排程 + 供應鏈風險 + 品質追溯」十幾個會寫回的用例、內部沒有能自建資料平台的工程軍團。這是 Palantir 的甜蜜點——三大鴻溝全中,而且自建的時間成本遠高於授權費。

一家雲原生的網路公司:資料已在 Snowflake、需求主要是 BI 儀表板與少量 ML、有 50 人的資料工程團隊、沒有斷網或機密部署需求。這裡 Palantir 的動能層與 Apollo 幾乎用不到,付的溢價買不到對等價值——自建或 Databricks 更合理。

1. 帶得走底層清洗後的資料集(在你的雲/倉儲、可導出)、以 OSDK 寫的標準 TS/Python 邏輯。
2. 半綁pipeline 轉換邏輯(可讀出但要重寫)、物件模型(概念可搬,實作要重做)。
3. 綁死Action 的治理語意、動態安全規則、Apollo 部署編排、血緣——這些是平台原生,離場等於重建。

談約時就要求:資料可隨時完整導出、關鍵邏輯以 OSDK 形式保存在你的 repo。這不能消除鎖定,但能把「人質風險」降到可談判的程度。

1. 寫回真源系統不要只驗查詢。驗一個 Action 真的寫回你的 SAP 並通過你的驗證規則——這才是動能層的真章。
2. 最髒的資料拿你最爛的那批資料(重複、缺欄、編碼亂)去建物件,看實體解析撐不撐得住。
3. 你的權限模型驗動態安全能不能精確重現你的合規要求(例如某欄只有某角色可見)。
4. 你的部署環境如果你要地端/斷網,一定要在真實目標環境驗 Apollo,而不是在 Palantir 的雲上。
5. 脫離 FDE讓你自己的工程師在沒有 FDE 手把手下,獨立做出第二個用例——驗「產品化」是不是真的。
6. AI 的安全邊界驗 agent 真的無法越過 Action 權限做出未授權寫入,且稽核可完整回放。

1. 資料主權敏感資料能否完全留在境內、地端部署(Apollo 支援,但要落實驗證與稽核權)。
2. 地緣依賴綁定一家與美國安全機構深度連結的公司(見第 06 章),在特定場景是機會也是風險,須高層層級評估。
3. 議價台灣單一客戶對 Palantir 議價力有限;考慮以產業聯盟或政府框架採購提高槓桿,並鎖定導出權與價格天花板。