企業 AI 營運模型：平台、團隊與業務單位如何協作

AI 營運模型管的是持續運作

企業 AI 營運模型，是約定一項 AI 能力從需求提出、建置、上線到維護與退場，由誰做決定、由誰提供服務以及由誰承擔結果。它不是只有部門名稱或一張技術架構圖。當某團隊自行做出好用的助理，下一個問題往往是資料誰更新、模型費用算誰的、服務壞了誰接手。本文提出可落地的責任與服務設計，屬方法建議，不代表任何公司的實際組織編制，也不把成立一個中心團隊視為成熟度已完成。

依需求選集中、混合或聯邦式

Microsoft 的營運模型說明區分集中、混合與聯邦式，三者對規範、建置及監測的分工不同。[S1] 小團隊或外部作用較高的應用，可先由少數人集中把關；已有成熟資料與技術團隊的業務單位，可在共用規範內自行交付。選擇應看應用種類、現有能力、事故代價與支援容量，而不是模仿別人的組織圖。不同應用可採不同模式，但身分、資料規則、成本定義與事件格式應能對接；若每個團隊各說一套「已核可」，混合模式只會變成責任空隙。

將四種責任分開，再決定誰兼任

業務責任是定義成果、接受品質與安排現場使用；平台責任是提供模型存取、監測與部署機制；資料責任是確認來源、可讀範圍與更新；風險責任是審視權限、例外與重要作用。這四種責任不一定需要四個部門，但都需要可辨識的負責角色與替補。共用平台不應替業務宣稱答案一定正確，業務也不能要求平台繞過資料權限。發生爭議時，先辨識它屬於成果取捨、技術可靠性或資料使用，再送到對應決策者，避免所有問題都排到同一個人。

把平台能力寫成可申請的服務

先列出團隊真正需要重複使用的服務，例如受控模型入口、文件檢索、測試執行、使用量查詢與事件追蹤。每項服務記錄輸入契約、支援模型或格式、資料邊界、可用環境、費用口徑、支援時間與限制。提供最小可用的申請流程與範例，不先承諾包辦所有應用。應用負責人必須知道哪些由平台維護、哪些仍要自己驗證；平台改版時也要有相容性通知與遷移窗口，不能只換掉底層模型，就把品質回歸責任留給使用者發現。

用需求漏斗連接投資與交付

統一收件至少要知道任務、使用者、問題證據、資料、成果指標與風險。第一關判斷是否需要 AI，第二關確認資料與負責人，第三關才安排試行資源。對資訊不足的需求退回補件，對重複能力引導共用，對暫不做的項目記錄原因與重看條件。需求排序由有權人依價值與負擔決定，平台不能只按最新或最容易展示的技術接案。試行成功也不直接等於正式維運；應另外確認服務窗口、告警接收者、費用上限、回退版本與停止服務後資料如何處理。

讓支援與事故處理成為交付內容

AWS 的正式導入階段指引將角色責任、監測及支援列為運作要件。[S2] 可將一線支援設為協助使用者辨識操作與資料問題，二線處理應用設定與品質，三線處理共用平台或供應商故障。這是可調整的設計，不是每家公司都要建立三層人力。每類事故須有嚴重度、接收管道、負責角色與回復方式。模型服務可用但答案錯誤，也算品質事故；沒有系統當機不代表沒有問題。事故紀錄要能連回受影響的版本、資料範圍及外部作用，便於事後修正與告知。

同時看共用成本與應用成本

先分平台固定投入、使用量支出、資料維護、應用開發及人工支援，再約定哪些共攤、哪些歸使用團隊。初期可先做費用展示，讓業務知道每項任務的成本；資料可信後再決定是否內部分攤。不能只用 token 用量推算全部成本，也不能把共用團隊的人力藏到別的預算，讓單一應用看起來異常便宜。費用資料必須能對照實際任務與品質，避免團隊因節省模型費而轉成大量人工返工，或因分攤規則不合理而另開影子工具。

一份營運契約應包含什麼

建議用服務目錄加應用卡管理，不把所有細節塞入一份巨型政策。共用原則只維護一份，應用卡引用目前有效版本，另列自己的資料、限制與例外。角色兼任、外部支援與暫時責任都要寫清楚期限與移交條件；「先由某人處理」若沒有後續安排，很容易變成永久但無資源的維運責任。每次重要改版都重新核對責任是否仍成立，並保留前一版以便追溯。

• 應用卡：業務目的、服務使用者、成果負責角色、資料窗口、應用維護者、風險審視者。
• 服務卡：依賴項、支援範圍、費用口徑、監測、故障升級、版本通知、回退與退場。
• 決策紀錄：待決問題、可選方案、影響、決定者、依據、有效版本與重新檢視條件。

假設情境：兩個部門共用文件助理

假設業務與客服都需要文件問答，可以共用模型入口與檢索服務，但各自指定資料負責人、可讀範圍與答案測試集。客服不能因共用平台而讀到業務機密提案；平台也不應把兩部門的完成率直接合併成單一品質數字。先讓一個部門試行，測清楚資料更新與支援負擔，再讓另一部門接入。這是組織設計示例，沒有宣稱實測成效。是否共用同一模型或索引，要由權限隔離、任務品質與維護成本決定，而不是因為畫在同一張平台圖上。

驗收時要能回答事故與退場問題

請不熟悉建置過程的人照服務卡提出需求、查成本、回報錯誤，再模擬資料過期與模型版本更換。確認每個問題有接手角色，重要更新能通知受影響者，舊版可在定義範圍內回退。也要演練應用負責人離開或應用停止時，誰能接續資料與決策紀錄。檢查不只計算交付數，而是看責任空白、未結事故、重複建置與支援容量。若應用增加但無人維護，應先減少交付或補足服務責任，避免把試作清單誤當成可營運資產。

常見問題：要不要中心團隊、誰付費、誰拍板

一定要成立大型 AI 中心嗎？不必，先把必要責任與共用服務說清楚，小團隊可由現有人員兼任。

費用一定要分攤到每個部門嗎？不一定，先建立可信的成本展示，再依管理目的選擇分攤，不能為了精細而製造無法對帳的數字。

模型選擇由平台決定嗎？平台可定可支援範圍與安全底線，業務需用自己的任務證據接受品質與成本取捨；涉及資料使用或重大外部作用時，仍由對應有權角色決定，不能靠工具供應商預設代替。

來源依據與證據界線

1. S1 · Choose your CoE structure and operating model

   Microsoft Learn · 查閱 2026-10-22

   集中、混合、聯邦式營運對建置、規範與監測有不同分工；不支持把任何一種型態當成普遍最佳方案。

2. S2 · Generative AI maturity model level 3: Launch

   Amazon Web Services · 查閱 2026-10-22

   進入正式運作需明確角色責任、監測與支援；不代表AiTOM或讀者公司已達該成熟度。