一句話說明
AI 團隊的組法取決於公司規模和 AI 成熟度，從「一個人兼著做」到「獨立的 AI 部門」，每個階段需要的角色和架構不同。
為什麼需要專門討論 AI 團隊
很多公司在 AI 導入時會犯一個錯誤：以為買了工具就等於導入了 AI。ChatGPT Team 帳號買了、Copilot 裝了，然後呢？如果沒有人負責推動使用、制定安全政策、追蹤成效、回答員工的問題，工具的使用率會在第一個月的新鮮感過後快速下降。
另一個常見的問題是沒有人負責 AI 的安全和治理。員工可能在用 AI 的過程中不小心上傳了客戶資料、產出了有版權疑慮的內容、或依賴 AI 的錯誤資訊做了商業決策。這些風險需要有人來管。
AI 團隊的設計不只是「誰寫程式」的問題，更是「誰負責讓 AI 安全且有效地融入公司的工作流程」的問題。
三種組織架構
集中式（Centralized）
成立一個專門的 AI 部門或 AI CoE（Center of Excellence），所有 AI 相關的專案都由這個團隊負責。
適合的情境：大型企業（500 人以上）、AI 應用已經有一定規模（不是剛開始試水溫）、需要統一的技術標準和治理框架。
優點：技術能力集中，不會出現三個部門各自用不同的做法和標準。安全和合規容易管理——一個團隊統一把關，政策的執行比較一致。可以建立共用的基礎設施（向量資料庫、API Gateway、模型管理平台），避免重複建設。
缺點：和業務部門的溝通成本高。業務部門要用 AI，得先提需求給 AI 部門，排隊等 AI 部門處理。如果 AI 部門同時處理 10 個部門的需求，每個部門可能要等幾週。容易變成瓶頸。另一個問題是離實際業務太遠——AI 部門的人懂技術但不懂業務細節，容易做出「技術上漂亮但業務上沒用」的東西。
飛飛見過一個例子：某家製造業成立了 AI 部門，花了六個月開發了一套智慧品檢系統，但生產線的作業員說這套系統的判斷速度跟不上產線節拍，實際上用不了。問題出在 AI 部門沒有早期就讓生產線的人參與需求討論。
嵌入式（Embedded）
把 AI 人才分散到各個業務部門，每個部門有自己的 AI 工程師或 AI 專員。
適合的情境：各部門的 AI 需求差異很大（行銷要生成內容、工程要程式碼輔助、客服要自動回覆）、需要快速回應業務需求。
優點：離業務近，AI 人員和業務團隊坐在一起，能即時了解需求和問題。回應快——不需要走跨部門的需求流程。解決方案更貼近實際需求，因為 AI 人員在日常工作中就能看到業務的痛點。
缺點：技術標準不一致——行銷部門的 AI 專員用 LangChain，客服部門的用 AutoGen，工程部門的用自己寫的框架。重複建設——三個部門各自建了自己的 RAG 系統，功能幾乎一樣但互不相通。安全和合規容易有漏洞——每個部門自己管自己的 AI 使用，可能有些部門嚴格有些部門鬆散，整體的安全態勢不一致。
Hub-and-Spoke（軸輻式）
結合前兩種的優點：一個核心團隊（Hub）負責技術標準、安全治理、共用基礎設施，各部門有自己的 AI 人員（Spoke）負責日常的 AI 應用。
適合的情境：中大型企業（100-500 人）、AI 導入進入擴大階段（已經過了初期試水溫，開始在多個部門推展）。
Hub 負責的事：制定 AI 使用政策（什麼資料可以給 AI、什麼不行）。評估和核准新 AI 工具（不是每個部門想用什麼就買什麼，要經過 Hub 的安全評估）。管理 AI 相關的安全和合規（定期做安全稽核、處理安全事件）。維護共用的 AI 基礎設施（向量資料庫、API Gateway、監控系統）。提供培訓和技術支援（幫各部門的 Spoke 提升技能）。
Spoke 負責的事：在自己部門落地 AI 應用（把 Hub 提供的工具和框架應用到部門的實際工作中）。收集使用回饋（什麼好用、什麼不好用、什麼功能缺少）。把部門的需求傳達給 Hub（「我們需要一個能處理 PDF 報表的 AI 功能」）。做為部門內的 AI 推廣者（教同事怎麼用、分享技巧、回答問題）。
這是飛飛在台灣中大型企業培訓時最常推薦的架構，因為兼顧了標準化（Hub 統一標準和安全）和靈活性（Spoke 貼近業務快速回應）。
關鍵角色
不管用哪種架構，以下幾個角色需要有人負責。在小公司可以兼任，不一定需要全職。
AI 專案經理（AI PM）
負責 AI 專案的規劃和推動、和業務部門溝通需求、追蹤專案成效。需要同時懂業務和基本的 AI 知識——不需要會寫模型，但要能判斷一個 AI 方案是否可行、要花多少時間和資源。
在很多台灣公司，這個角色由 IT PM 或數位轉型負責人兼任。飛飛認為最理想的人選是在公司待過一段時間、熟悉各部門業務的人。外部招聘的 AI PM 技術可能很強，但不了解公司的業務流程和文化，磨合期會比較長。
ML/AI 工程師
負責模型的選擇、整合、部署和維運。如果公司主要使用第三方 AI 服務（ChatGPT API、Claude API），這個角色的重心會從「訓練模型」轉向「整合 API 和建立 AI 應用」。
2026 年的現實是：大多數企業不需要自己訓練模型。你需要的是會呼叫 API、建立 RAG 系統、設定向量資料庫、和把 AI 功能整合到現有系統中的工程師。這樣的工程師比傳統的 ML 工程師更容易找到——很多有 Python 或 Node.js 經驗的後端工程師，學習 LangChain 或 LlamaIndex 的門檻不高。
資料工程師
負責資料的收集、清洗、儲存和管線。AI 的品質取決於資料的品質——GIGO（Garbage In, Garbage Out）在 AI 時代依然成立。
如果你的 RAG 系統回答品質很差，通常問題出在送進去的資料沒有整理好：PDF 轉文字時格式跑掉、表格被解析成亂碼、重複的資料沒有去除、過時的資料沒有更新。LLM 本身的能力反而是次要的。
資料工程師不一定要是全職角色。在小公司，可以由後端工程師兼任，負責把公司的資料整理成 AI 可以使用的格式。
AI 安全/治理負責人
負責 AI 使用的安全審查、政策制定和執行、法規合規。在小公司可以由資安人員兼任，在大公司可能需要專職。
飛飛認為這是最容易被忽略但最重要的角色。技術團隊專注於「讓 AI 動起來」，但誰來確保「AI 動起來之後不會出問題」？安全事件的發生不會等你準備好——通常是在你最沒準備的時候出現。
這個角色需要的技能組合比較獨特：要懂 AI 的基本原理（知道 AI 可能產生什麼風險）、要懂資安（知道怎麼防護）、要懂法規（知道個資法和相關法規的要求）。在台灣，同時具備這三個領域知識的人才非常稀少。比較實際的做法是讓現有的資安人員學習 AI 的風險面向——資安基礎已經有了，只需要加上 AI 特有的知識（prompt injection、資料訓練風險、模型偏見等）。
AI 推廣者/訓練師（AI Champion）
每個部門有一個對 AI 有興趣的人，負責在部門內推廣 AI 使用、協助同事解決問題、收集回饋。
這個角色不需要技術背景，但需要溝通能力和學習熱情。最好的 AI Champion 通常不是技術最強的人，而是最願意幫助別人的人。他們的價值在於降低同事使用 AI 的心理門檻——很多人對新工具有抗拒感，但如果旁邊有個熟人可以隨時問，就比較願意嘗試。
飛飛建議讓 AI Champion 的角色有一定的正式性（在部門會議上公告、給他們一些培訓資源和時間），而不是只是私下拜託某個人「幫忙推廣一下」。
外聘還是內部培訓
台灣的 AI 人才市場現況
有經驗的 ML 工程師供不應求。大公司（台積電、聯發科、Line、Appier）搶人搶不完，薪資開到年薪 150-250 萬以上。中小企業很難用薪資競爭。
但好消息是：2026 年的 AI 導入，大部分不需要 ML 工程師。你需要的是會用 AI 工具和 API 的人，這類人才的供給比 ML 工程師多得多。
務實的做法
對大多數台灣企業來說，比較務實的人才策略分三個層面：
技術核心外聘：找 1-2 個有 AI 實戰經驗的人加入，負責架構設計和技術決策。這些人不一定要是 ML 專家，但要有用 AI API 建立過產品的經驗。在 104 或 LinkedIn 上搜尋「AI 工程師」或「LLM 應用工程師」，薪資大約年薪 80-150 萬。
應用層內部培訓：讓既有的工程師、分析師、PM 學習 AI 工具的使用。這些人已經懂業務和既有系統，只需要加上 AI 技能。培訓的內容包括：AI 工具操作（ChatGPT、Claude、Copilot）、Prompt 技巧、RAG 系統的概念（如果需要）、AI 安全意識。
安全層跨領域培養：資安人員學 AI 的風險面向，比從零培養一個既懂 AI 又懂資安的人快得多。可以透過外部課程（OWASP LLM Top 10、AI 安全工作坊）加上實際的紅隊演練來培養。
培訓的重點不是教大家寫 Python 或訓練模型，而是教四件事：怎麼寫有效的 Prompt、怎麼判斷 AI 輸出的品質（事實查核、偏見檢測）、什麼資料可以給 AI 什麼不行、出問題時怎麼處理（通報流程、應急措施）。
不同規模的建議
10 人以下的小公司
不需要專門的 AI 團隊。指定一個人負責三件事：追蹤 AI 工具的發展和更新、制定基本的使用規則（一頁 A4 的 AI 使用政策）、每季在公司內部做一次 AI 分享（分享新工具、技巧、和案例）。
這個人每週大概花 2-3 小時在 AI 相關的事務上。不需要額外的技術背景，只要對 AI 有興趣願意學習就行。
10-50 人的中小企業
一個兼職的 AI 負責人加上每個部門一個 AI Champion。可以考慮外部顧問做初期的規劃和培訓——讓顧問幫你做三件事：選工具、制定政策、做第一輪的員工培訓。這些事做完之後，內部人員接手日常的推動和維護。
如果有工程團隊，讓一個工程師花 20-30% 的時間在 AI 整合上（建立簡單的內部 AI 工具、整合 API 到現有系統）。
50-200 人的中型企業
考慮 Hub-and-Spoke 架構。Hub 有 2-3 個人：一個 AI PM（可以由 IT PM 兼任）、一個 AI 工程師（或 AI 導向的後端工程師）、一個安全負責人（可以由資安人員兼任）。每個主要部門（行銷、客服、工程、業務）有一個 Spoke（AI Champion）。
Hub 團隊的工作時間分配建議：30% 技術支援（幫各部門解決 AI 使用的技術問題）、30% 安全治理（政策制定、稽核、事件處理）、20% 培訓（新員工培訓、進階技巧分享）、20% 基礎設施（維護共用工具和平台）。
200 人以上的大型企業
看 AI 的戰略重要性決定。如果 AI 是核心競爭力（例如 AI 驅動的產品、AI 賦能的服務），建立獨立的 AI 部門。如果 AI 是輔助工具（提升各部門效率），Hub-and-Spoke 通常就夠了。
獨立 AI 部門的典型編制：AI VP 或 Director（1 人）、AI PM（2-3 人，按業務線分）、ML/AI 工程師（3-5 人）、資料工程師（2-3 人）、AI 安全（1-2 人）。總計 10-15 人。
安全與限制
團隊架構解決的是「誰做什麼」的問題，但解決不了「文化」的問題。如果管理層不支持（嘴上說支持但不撥預算和時間）、員工抵觸（覺得 AI 會取代自己的工作）、或是沒有足夠的預算（買了工具但沒有培訓預算），再好的架構都不會有效。
AI 角色的邊界在快速變化。隨著 AI 工具越來越易用，很多原本需要 ML 工程師的工作（例如用 API 建立 AI 應用）現在一般的軟體工程師就能做。兩年前需要資料科學家才能建的推薦系統，現在用 Claude 加上 RAG 就能做出堪用的版本。團隊的角色定義需要隨著技術發展調整，不要把職位描述寫死。
不要一開始就追求理想架構。先從最小可行的團隊開始（通常就是一個有熱情的人），隨著 AI 應用的規模擴大再逐步增加角色。飛飛見過太多公司一開始就設計了完美的組織架構圖，結果因為招不到人或預算不足，變成紙上談兵。
知識檢測
讀完文章後，測試一下你對這個主題的理解。
常見問題
我們公司沒有 ML 工程師，可以導入 AI 嗎？
可以。如果主要是使用第三方 AI 服務（ChatGPT、Claude、Copilot），不需要 ML 工程師。需要的是會整合 API 的軟體工程師和懂得怎麼用 AI 的業務人員。只有在需要自己訓練或微調模型時才需要 ML 工程師。大多數企業的 AI 導入不會走到自己訓練模型的階段。
AI 團隊應該歸 IT 還是業務？
看公司的 AI 成熟度。初期歸 IT（因為 IT 控制工具選型和安全），這樣可以確保安全和標準化。成熟後可以考慮歸業務或獨立成部門，因為這時候 AI 的價值更多是在業務面而不是技術面。Hub-and-Spoke 架構下，Hub 通常歸 IT 或直接向 CIO 報告，Spoke 歸各業務部門。
AI Champion 需要什麼技能？
不需要會寫程式。最重要的三個條件：對 AI 有興趣願意持續學習（AI 工具每個月都有新功能，需要有人跟上）、在部門裡有影響力（同事願意聽他的建議、願意向他請教）、有基本的資料敏感度（知道什麼資料不能上傳、什麼輸出需要驗證）。溝通能力比技術能力重要。
怎麼衡量 AI 團隊的成效？
看兩個面向。AI 應用的業務成效：效率提升了多少（時間節省）、成本節省了多少（人力、工具）、品質改善了多少（錯誤率、客戶滿意度）。AI 治理的健康度：安全事件數（越少越好）、政策合規率（員工遵守 AI 使用政策的比率）、員工採用率（實際使用 AI 的員工比例）。不要只看「我們導入了幾個 AI 工具」——導入了但沒人用，跟沒導入一樣。
外部 AI 顧問值得請嗎？
初期做規劃和培訓時值得，因為可以避免常見的錯誤（選錯工具、忽略安全、試點範圍太大）。一個好的顧問可以在 2-4 週內幫你完成工具選擇、政策制定、和第一輪培訓，自己摸索可能要 2-3 個月。但不要長期依賴外部顧問——核心的 AI 能力和安全知識必須建立在內部。顧問的價值是加速你的學習曲線，不是替代你的學習。