企業 AI 自建 vs 採購 vs 前線部署:用決策樹選對導入路線

上個月一位製造業 CIO 把兩份估價單推到我面前。一份是內部團隊喊出的自建方案,兩年、六名工程師、一套從頭訓練的知識問答系統。另一份是某國際 SaaS 的年約,簽下去下週就能用。他問我選哪個。

我的回答讓他愣了一下:兩個可能都不對。

AI 自建 還是 採購,其實是問錯了問題

「AI 自建 還是 採購」被講到爛,但它把選擇壓成二選一,而現實有三條路。第一條是自建,自己招人、自己維運、模型與資料都握在手裡。第二條是採購現成 SaaS,付月費、開帳號、用供應商定義好的功能。第三條,是這幾年才成形的「前線部署」:工程師進場,站在你的資料與流程上,把開源或商用模型組裝成貼合你這一家公司的系統,上線後扛到有人真的在用。

三條路沒有優劣,只有適配。判斷適配的,不是預算多寡,也不是老闆對 AI 的熱情,而是三個很冷靜的軸:資料敏感度、邊角案例密度、內部維運能力。

資料敏感度問的是:你的核心資料能不能離開你的邊界。病歷、授信模型、未公開財報、產線良率參數——這些一旦流進第三方雲端,合規與談判籌碼一起流失,採購 SaaS 這條路基本就被劃掉。

邊角案例密度問的是:你的業務有多「不一般」。開頭那家客戶的 4% 使用率,病根就在這裡。SaaS 為「平均客戶」設計,你的例外越多——特殊報價邏輯、跨部門審批、只有老師傅才懂的判斷——現成產品覆蓋不到的縫隙就越大,而縫隙正是使用率崩掉的地方。

內部維運能力問的是:上線之後,誰接得住。模型會漂移,資料 schema 會改,使用者會用你沒想過的方式提問。自建要求你長期養一支能改 prompt、能重跑 embedding、能讀懂 log 的隊伍。沒有這支隊伍,自建的系統會在工程師離職那天開始腐爛。

把三條路放進同一張決策樹

我們在客戶會議室常畫的,就是下面這張表。先用三軸給自己打分,再對照該去哪條路。

這張樹最常被忽略的一格,是「資料敏感度高、邊角密度高、但內部維運能力弱」。這格的公司通常最痛:合規讓他們不敢買 SaaS,人力讓他們不敢自建,於是拖著,或者硬買一套然後複製那 4% 的故事。前線部署就是為這一格存在的——不是賣你一個產品,是派人進來,用你的資料把系統長出來,同時把你的人帶到能接手的程度。

三條路的真實成本,不在報價單上

報價單只寫得出授權費和人月。寫不出來的,才是後面真正燒錢的地方。

採購 SaaS 的隱藏成本是「削足適履」:為了遷就產品,你反過來改自己的流程,改到員工嫌麻煩、乾脆不用。自建的隱藏成本是「維運的長尾」:第一版三個月做完很爽,但接下來三年的漂移、迭代、值班,才是總成本的大頭,而這筆錢在立項時幾乎沒人算。

前線部署也有它的取捨,我得誠實講。它前期比買 SaaS 貴、比自建慢,因為工程師要花時間讀懂你的業務、你的爛資料、你辦公室裡沒寫下來的規矩。這段磨合躲不掉。它的划算之處在後段:系統貼著你長,上線就有人用,而且知識留在你團隊裡,不會隨合約到期一起蒸發。

所以回到那位 CIO。他的資料敏感度高（授信與客戶財務）、邊角案例密度高（每條產線的規則都不一樣）、內部維運能力中等（有 IT 但沒有 ML 團隊）。照這張樹,他兩份估價單選的都是錯格。

先確認你在哪一格,再談要花多少錢

大多數導入失敗,不是敗在選錯供應商,是敗在沒先量自己這三軸就開始比價。比價是最後一步,不是第一步。

我們在 Tenten 做的每個案子，開場都不是介紹模型或報價，而是陪客戶把這三軸標出來、把決策樹走一遍——有時候走完,我們會直接建議對方去買一套 SaaS,因為那格確實不需要我們進場。真正需要前線部署的,是那些資料出不了門、例外多到現成產品接不住、又還沒養起維運團隊的公司。Demo 很美不算數,這張決策樹幫你避開的,正是那種簽約很快、上線很慘的故事。