企業 AI 導入團隊怎麼組:6 個關鍵角色與自建 vs 外部部署的取捨

有家製造業客戶去年做的第一件事,是招了一位很漂亮的資料科學家。台大碩士、Kaggle 名次好看、模型調得漂亮。九個月後我們進場時,那位工程師快離職了,因為他一整年做的東西沒有一項上線。

不是他不行。是這家公司以為「導入 AI = 找一個會做 AI 的人」,於是把一個需要六種能力的工程,壓在一個人身上。資料沒人清、業務需求沒人定義、上線沒人維運、現場沒人推。他被架空成一座孤島。

這是我們看過最常見的組建失敗:把團隊當成職缺來招,而不是當成一條交付線來設計。 這篇想把 AI 導入團隊的組建拆清楚——到底要幾個人、每個角色找誰、哪些該自己養、哪些用外部前線部署補位。

AI 導入團隊組建:先想清楚是「一條線」而不是「一個人」

一個能把 AI 真正推上生產線的團隊,至少要覆蓋六種角色。注意我說的是「角色」不是「頭數」——在早期,一個人可以兼兩三個角色,但六種能力一種都不能缺。缺哪一種,案子就卡在哪一段。

第一種是 AI 產品負責人。他不寫程式,他決定「我們到底要解決哪個業務問題、成功長什麼樣、KPI 是什麼」。這是唯一絕對不能外包的角色。因為只有你自己知道公司哪裡痛、哪個流程動不得、哪個主管會擋。外部顧問再強,也定義不了你的業務優先序。這個人必須是內部的,而且要有決策權,不能是一個轉述需求的 PM。

第二種是 前線部署工程師(FDE)。這是把模型、把 Copilot、把 Agent 真正接進你系統、扛到上線的人。開頭那個案子缺的就是這個——會做模型的人很多,願意在你的爛 API、你的舊 ERP、你的權限地獄裡把東西接通並跑起來的人,極少。這個角色是最值得用外部前線部署補位的:它需要的是「在各種現場踩過雷」的經驗密度,你自己養一個要好幾年,而且平時養不起。

第三種是 資料與知識工程師。RAG 知識系統的成敗,八成在資料,不在模型。誰來清資料、建管線、做知識切塊與治理、處理權限分級?這個角色前期高度依賴外部(因為要快速搭起管線),但要刻意規劃讓內部人接手,因為資料會一直長,治理是長期的事。

第四種是 領域專家(SME)。就是每天在做這件事的業務老手——理賠的資深專員、產線的老師傅、看片的醫師。他負責告訴你「AI 這樣答是錯的」、負責標註、負責驗收。這個絕對是內部的,而且要保護他的時間,別讓他「有空再幫忙」。我們見過太多案子死在 SME 被本職工作淹沒、三週回不了一次饋。

第五種是 MLOps 與平台維運。上線那天不是結束,是開始。誰盯延遲、盯成本、盯模型漂移、盯出錯時怎麼回退?Demo 不需要這個角色,生產線需要。早期可外部代管,但一旦進入規模化,強烈建議內部要有人握住這條線。

第六種,也是最被低估的,是 採用負責人(變革管理)。開頭那個 4% 使用率的故事,病根就在這裡。系統做出來只是完成一半,讓人願意用、改流程、做訓練、處理抗拒,是另一半。這個角色必須是內部有威望的人,外部只能給方法,推不動你們的組織文化。

自建 vs 外部前線部署:逐一給判斷

把上面六個角色攤成一張表,我們的預設判斷是這樣:

看得出來一個模式:越靠近你業務真相與組織政治的角色,越要自建;越靠近工程執行密度的角色,越適合外部前線部署。 三個自建、三個外部,是我們最常給出的起手式。

那到底要幾個人?一個試點階段的專案,實務上內部三個人就能啟動——一位產品負責人、一位半職的 SME、一位未來要接手資料/維運的工程師;外部再配一組前線部署團隊補 FDE 與資料管線。不是六個全職缺,是三個內部角色加一組外部補位。

最後一句誠實話:團隊組錯,再好的模型也會爛在辦公室裡。我們在 Tenten 做的事,就是那組「外部補位」——工程師進場,和你的產品負責人、SME 並肩,把系統扛到上線、扛到真的有人在用,再把該留下的能力交回你手上。Demo 很美不算數,上線且有人用才算數。