80% 的 AI 專案不是 IT 做的：AI 所有權反轉的時代來了

80% 的 AI 專案不是 IT 做的：AI 所有權反轉的時代來了

🎯 開場：一個違直覺的事實

先說一個讓 IT 主管不太舒服的數據。

緯創軟體——台灣的 IT 代工大廠——在 2024 到 2026 年間，內部跑出了超過 100 個 AI 落地場景。聽起來不稀奇，很多大公司在做 AI。

但重點是：這 100 多個場景中，有 80% 不是 IT 部門主導的。

發起人不是工程師、不是 CTO、不是資訊主管。是業務單位的人、客服團隊、財會部門、人資——那些你以為「不懂技術」的人。

這不是緯創鼓励的结果，是AI本身的特性决定的。当AI工具变得像手机一样容易用时，最先抓住它的人，往往不是最懂技术的人，而是最痛的人。

🔑 AI 時代最違直覺的真相：最懂 AI 的人，不一定是最該主導 AI 的人。

🔄 所有權反轉：一個正在發生的結構性轉移

過去，任何跟「資訊」相關的專案，理所當然歸 IT 管。ERP 導入、CRM 系統、資料倉儲——IT 不主導，誰主導？

但 AI 不一樣。

AI 不是一個「系統」，它是一套能力。就像 Excel 不是 IT 的專利一樣，ChatGPT、Copilot、Midjourney 這些工具，使用者門檻已經低到非技術人員也能上手。

我們觀察到一個結構性的轉移——從「IT 擁有 AI」變成「業務擁有 AI」。

這個轉移我稱之為「AI 所有權反轉」：AI 專案的擁有權，正在從資訊部門轉移到業務單位。

不是 IT 變得不重要了——IT 變得更重要，但角色變了。從「開發者」變成「赋權者」。

🔬 為什麼 IT 主導的 AI 專案容易失敗？

這不是在責怪 IT。IT 部門往往是最專業、最嚴謹的團隊。但問題不在能力，而在視角。

三大「IT 視角盲點」

盲點一：IT 定義問題的方式跟業務不同

IT 擅長解決「定義清楚」的問題：規格明確、輸入輸出明確、流程標準化。

但企業最痛的 AI 需求，往往定義不清楚——

「我想要客服回覆快一點」

>

「我想要業務報價更準一點」

>

「我想要財月結不要加班到凌晨」

這些需求，IT 不知道怎麼規格化。因為痛的人才知道痛在哪裡，痛的人不在 IT 部門。

盲點二：IT 的「完善心態」是 AI 的速度殺手

一個 AI 專案的典型 IT 流程：需求確認 → 規格撰寫 → 供應商評估 → 採購 → 開發 → 測試 → 上線。六個月跑不掉。

但 AI 工具的特性是「先跑再調」。一個業務人員今天拿到 ChatGPT，明天就能做出一個原型方案。IT 才剛寫完需求規格書。

IT 追求完善，AI 追求快速迭代。當你的競爭對手用 AI 做到 80 分的水準還在持續優化時，你的 IT 團隊還在做可行性評估。

盲點三：IT 選的是「最強工具」，不是「最對工具」

IT 在選 AI 工具時，自然會看技術指標：準確率、API 穩定性、資安防護、整合能力。

但業務在乎的是：「它能不能讓我今天的工作少花一小時？」

技術的「最強」和業務的「最有用」，往往不是同一件事。

🆚 四象限矩陣：你的 AI 專案誰該主導？

核心問題不是「IT 或業務」，而是「哪個類型的專案該由誰主導」。我用一個 2x 矩陣來分類：

AI 所有權矩陣

🟢 業務主導區（佔比最大，約 60-70%）

• •技術門檻低、業務場景明確
• •例如：客服自動回覆、行銷文案生成、會議記錄自動化
• •業務自己找出場景、自己用工具、自己驗證效果

🔵 聯合主導區（約 20-25%）

• •需要串接內部系統、處理敏感數據
• •例如：AI 財務報表分析、AI 品質預測、AI 供應鏈優化
• •IT 提供數據基礎設施，業務定義分析邏輯

🔴 IT 探索區（約 5-10%）

• •新技術研究、POC 驗證
• •例如：LLM fine-tuning、AI Agent 架構評估
• •長期投資，不急於產出

⚪ 不急做區（湊數用的）

• •不知道用來幹嘛的新 AI 功能
• •別碰。別為了「跟上趨勢」而導入。

🔑 大多數中小企業的錯誤：把六成該「業務主導」的專案，丢給 IT。結果 IT 消化不良，業務需求永遠排不到。

🧩 新角色：AI 翻譯員

既然 AI 成敗取決於「業務需求」和「技術能力」的對接，那誰來做這中間的對接？

答案不是 IT，也不是純業務。是一個被嚴重低估的角色——AI 翻譯員。

AI 翻譯員做什麼？

AI 翻譯員不寫程式（或少寫程式），但聽得懂兩邊的語言。他做的事是：讓業務的痛，變成 AI 的規格；讓 AI 的能力，變成業務的解法。

誰適合當 AI 翻譯員？

• •✅ 第一線業務主管（懂場景、有痛點、有動力）
• •✅ 系統分析師（懂流程、能寫簡單 prompt）
• •✅ 對 AI 有興趣的各部門種子（花時間自學的那种）
• •❌ 純 IT 工程師（容易陷入技術視角）
• •❌ 純主管（沒有時間深入了解工具能力）

緯創那 80% 非 IT 發起的專案，背後都有一群這樣的人。他們不是工程師，但他們比工程師更知道問題在哪裡。

🛠️ 實戰指南：如何設計「業務主導」的 AI 導入

你讀到這裡可能會說：「我知道該讓業務主導了，但怎麼做？我不可能叫業務自己搞定所有事情。」

沒錯。業務主導不是「放牛吃草」，而是重新設計導入的組織架構。

五步驟搭建「AI 業務驅動」架構

Step 1：成立 AI 推動小組——但不要放在 IT 部門

這是最關鍵的一步。

很多公司把 AI 推動小組放在 IT 下面是理所當然的選擇。但這從一開始就決定了視角——IT 視角。

正確做法：AI 推動小組直接向總經理或營運長報告，成員由各部門推派一名「AI 種子」組成。

Step 2：舉辦「AI 痛點工作坊」——不是培訓，是挖掘

不是教業務怎麼用 ChatGPT（那是培訓）。是坐下來問：「你工作中最煩、最浪費時間、最覺得『這應該可以自動化』的事情是什麼？」

一場 2 小時的工作坊，至少能跑出 20 個場景。比 IT 絞盡腦汁「想」公司能用 AI 有效十倍。

Step 3：排序——用「影響 × 可行性」矩陣選前 3 個

20 個場景不可能全做。怎麼選？

選「影響高、可行性高、資料已具備」的前 3 個場景。6 週內跑出第一個成果。

Step 4：給資源——但不要給「IT 流程」

每個場景配給：

• •一名業務發起人（主導者）
• •一名 AI 翻譯員（協調者）
• •IT 支援窗口（不是專案負責人，是技術顧問）
• •AI 工具預算 + 每月 4 小時的「試玩時間」

注意：不是編一個 200 萬的專案。是給小資源、設短目標、快速驗證。

Step 5：雙週 Demo Day——讓成果自己說話

每兩週一次，每個場景用 5 分鐘展示「過去兩週我們用 AI 做了什麼」。

這是最有效的擴散工具。不是叫大家学 AI，是讓同事看到「隔壁部門已經在用 AI 做這些事」。

人類是模仿動物。看到比自己早一步的同事用 AI 成功了，恐懼變好奇，好奇變行動。

📊 成效對比：IT 驅動 vs. 業務驅動

根據我們對客戶案例的追蹤：

🔑 差異不在技術品質，而在「誰覺得這是我的專案」。IT 主導的專案，業務覺得是「IT 的東西」。業務主導的專案，業務覺得是「我的東西」。擁有感決定使用率。

⚠️ 三個常見陷阱

寫了這麼多「業務主導」，不是說 IT 不重要。IT 仍然關鍵，只是角色轉變。以下是三個常見陷阱：

陷阱一：放任不管——「你們自己去做」

業務主導≠沒有 IT 參與。IT 需要提供：數據合規底線、資安防護框架、工具採購的統一管理（避免各部門自己買一堆服務）。

陷阱二：低估「AI 翻譯員」的培養成本

AI 翻譯員不是天生的。需要 1-2 個月的培養期，讓他們同時了解：AI 工具的能力邊界、各部門的業務場景、基本的_prompt 工程技巧。這筆投資非常值得。

陷阱三：高層不背書

不管架構設計多好，如果 CEO 在會議上說「AI 就交给 IT」，所有努力歸零。高層的態度決定組織的 AI 溫度。

🎯 小結：三個核心洞見

今天這篇文章提出三個你可能第一次聽到的觀點：

1. 1AI 所有權正在反轉——從「IT 擁有 AI」變成「業務擁有 AI」，IT 的角色從開發者變為赋權者。

1. 1AI 翻譯員是新時代關鍵角色——聽得懂業務語言也聽得懂 AI 語言的人，比 AI 工程師更能推動落地。

1. 1組織架構決定導入成敗——不是選什麼工具，是「誰決定用什麼工具、解決什麼痛點」。把 AI 推動小組放在 IT 下面是最多公司犯的錯。

最後一句話：

過去，IT 部門是公司数位化的引擎。未來，IT 部門是公司 AI 化的底氣。但引擎，改由業務單位來當。

💡 下一步行動

如果你對「AI 所有權反轉」的概念感興趣，我建議你從這裡開始：

1. 1盤點：你的公司目前有哪些 AI 專案？哪些是 IT 發起的，哪些是業務發起的？
2. 2工作坊：找個下午，讓三到五個不同部門的人坐下來，聊聊「你最想用 AI 做什麼？」
3. 3找人：在你的團隊裡，誰對 AI 最有熱情又最懂業務？那個人就是你的第一個 AI 翻譯員。

想了解更多關於組織 AI 轉型的實戰框架？聯絡榕耀小幫手，取得免費的 AI 成熟度評估報告。