AI 導入該由 IT 部門主導還是業務單位主導：責任歸屬評估指南

一間有兩百多名員工的傳統製造業公司，去年決定導入一套 AI 需求預測系統，希望改善長期存貨過多或缺料的問題。專案一開始就交給資訊部門全權負責，IT 主管很快就選定了系統架構、談好資料串接方式，照著時程把系統建置完成。上線那天，業務與倉管團隊才第一次真正看到系統畫面，結果發現預測模型用的歷史銷售資料，根本沒把每年固定會辦的促銷檔期、大客戶臨時加單這些業務端才知道的狀況算進去，預測出來的數字業務人員看一眼就知道不能用。IT 主管覺得自己照規格做完專案、沒有延遲也沒有超支，業務主管則覺得這套系統根本不懂真實狀況，雙方僵在那裡，誰也不覺得是自己的責任。

這種場景在有獨立 IT 部門與業務單位的中大型組織裡並不少見。AI 導入專案常常卡在一個看似簡單、卻很少被認真討論過的問題：這個專案到底該由誰主導、誰對最終結果負責。答案不是單純選邊站，而是要先看清楚純 IT 主導、純業務主導各自會在哪裡出問題，再回頭設計一個真正能讓兩邊都參與的評估機制。

純 IT 主導常見的失敗模式

當 AI 專案被當成一次性的系統建置案，交給資訊部門從頭管到尾，最常見的問題就是「規格做對了，但問題定義錯了」。IT 團隊擅長的是把明確的需求轉成技術方案、確保系統穩定上線，但他們通常不是天天在第一線接觸客戶、處理訂單異常、感受業務淡旺季波動的人。如果沒有業務單位從一開始就參與定義「我們到底要解決什麼問題」，IT 主導的專案很容易變成技術上無可挑剔、但業務端用不起來的系統——就像前面提到的需求預測案例，模型本身的演算法可能完全沒有錯，錯的是沒有人把業務端才掌握的例外狀況餵進去。這種失敗往往要等到系統上線、業務單位實際操作後才會顯現，而這時候修正成本已經比一開始多花時間溝通高出許多。

純業務主導常見的失敗模式

反過來，如果業務單位繞過 IT、直接找廠商談成一套 AI 工具自己上線使用，問題通常出現在另一個方向。業務團隊清楚知道自己要解決什麼痛點，但往往不清楚資料從哪裡來、要怎麼跟既有系統串接、資安與權限該怎麼設定，結果很容易出現幾種狀況：工具本身做得再好，資料卻是業務人員手動匯出匯入的孤島，沒有人維護資料的一致性；或是系統上線一段時間後才被 IT 部門發現，才驚覺這套工具跟公司既有的資安規範、備份機制完全沾不上邊，變成一個沒有人真正能維護、也沒人敢保證安全的「影子系統」。業務單位的急迫感可以理解——他們最貼近業績壓力——但完全跳過 IT 的導入方式,通常是把風險往後延,而不是真的解決掉。

怎麼設計 IT 與業務共同參與的評估小組

比較務實的做法,是在專案一開始就組一個小而明確的跨部門評估小組,而不是事後才想辦法補位。這個小組不需要人多,但角色要齊:IT 端派一個熟悉現有系統架構與資料狀況的人,業務端派一個真正在第一線處理流程、而不是只負責簽核的人,兩邊從需求訪談階段就一起參與,而不是 IT 寫完規格才拿去跟業務單位「確認一下」。小組運作的關鍵,是要先講清楚誰對哪一塊負最終責任——資料品質與系統穩定通常該由 IT 把關,問題定義與驗收標準是不是真的解決了業務痛點,則該由業務端拍板,兩邊都有否決權,但也都有各自該扛的責任,而不是出事以後互相推。

外部顧問在組織拉扯中該扮演什麼角色

當 IT 與業務單位已經有一定程度的拉扯、甚至互不信任時,直接要求兩邊自己組隊合作,有時反而會卡在舊有的部門心結裡動不了。這種情況下,找一個外部顧問或暫時性的專案協調角色,價值不在於他比 IT 或業務更懂技術或更懂業務,而在於他沒有部門立場,可以站在中間把雙方真正在意的點攤開來講,並且在爭執不下時提出一個相對客觀的裁決建議。我們也觀察到,一些需要同時處理技術規劃與跨部門協調的 AI 相關職缺,近期開始明確要求具備「跨部門協調」能力,而不只是技術背景——這反映出市場上已經有不少企業意識到,AI 專案卡住的原因往往不是技術做不出來,而是沒有人居中把責任界定清楚。找這樣的角色時,要注意的是對方有沒有實際協調過跨部門專案的經驗,而不是只掛著「顧問」頭銜、卻從沒真正處理過部門之間的責任拉扯。

回到最開始的製造業案例,如果一開始就有一個橫跨 IT 與業務的小組,先把「誰負責定義問題、誰負責把關技術」講清楚,那套需求預測系統在上線前就會被業務端抓出促銷檔期沒算進去的問題,而不是等上線那天才發現做錯了方向。AI 導入該由誰主導,答案從來不是二選一,而是先把雙方的責任邊界畫清楚,再決定需不需要找人居中協調。