摘要
AI 試點能在展示環境完成任務，只證明它在既定範圍內可運作。正式交給團隊使用後，資料會更新、員工會換手、供應商會改版，也會遇到不在試點題庫裡的例外。這時企業要做的，不是立刻決定「全部外包」或「全部自做」，而是分清楚誰能改、誰批准、誰監看、出事時誰能先停。
本文提供一張決策表，協助台灣中小企業主、部門主管與 AI 導入負責人，在試點驗收與資產接管後，選擇下一階段的維運方式。
核心結論：維運模式由責任能力決定，不由工具所有權決定
企業即使拿到了程式、提示詞與管理員帳號，也未必有能力獨立處理模型改版、錯誤回報或夜間故障。反過來說，選擇持續委外，也不代表可以把資料授權、對外承諾和停用決策一併交出去。
先盤點四件事：變更有多頻繁、錯誤影響多大、內部能否處理、每月實際付出多少。NIST AI RMF Core把角色責任、第三方風險與持續監測放在 AI 系統生命週期內；澳洲政府的 AI 影響評估指引也建議採購方確認供應商支援、監測與驗證責任，以及內部是否具備維護能力。這些是規劃方法，仍須按企業情境取捨。
| 模式 | 較適合的情境 | 企業至少要握有什麼 | 常見代價 |
|---|---|---|---|
| 持續委外 | 模型、整合或部署技術變動快；內部暫無維運人力 | 業務規則、資料授權、批准與停用權、服務紀錄 | 長期支援費與供應商依賴 |
| 共同維運 | 內部懂流程，但仍需外部處理複雜技術變更 | 日常內容更新、案例回報、初步監看與驗收權 | 需要固定協作節奏與清楚分工 |
| 內部接手 | 工作流穩定、文件與權限齊備；已有可排班的人 | 設定、監測、測試、回復與外部求援能力 | 招募、訓練、備援與值班成本 |
先問五個問題，再選模式
1. 變更來自哪裡，多久發生一次？
若每週都要更新商品政策、客服話術或內部知識文件，企業自己至少要能改內容與確認版本。若變動主要來自模型 API、雲端部署或多系統整合，短期仍可能需要供應商支援。
不要把「文字內容更新」和「系統行為變更」混為一談。前者可由業務 owner 審核；後者應先跑測試案例，再由有權限的人發布。
2. 出錯會影響誰，能不能先停？
內部摘要工具答錯，通常可以回到人工處理；若 AI 會對客戶發送訊息、改訂單或觸及付款，停用與人工接手的要求就更高。無論由誰維運，企業應保留可執行的暫停開關和事故聯絡路徑。
3. 內部真正有誰能接手？
不要只在組織圖上寫「資訊部」。請讓指定的人在受控環境完成一次資料更新、一次錯誤重現和一次回復。若只有原委外工程師知道怎麼做，現在就選完全內製，風險可能高於帳面節省的費用。
4. 一年總成本有哪些？
把供應商月費、模型與雲端用量、資料整理、內部工時、訓練、備援與事故處理放在同一張表。共同維運也有雙方重複檢查的成本。比較時使用相同服務範圍，不要只比「外包月費」與「員工薪資」。
5. 六個月後要如何改變模式？
維運模式不必一次選到永久。可以先共同維運三個月，讓供應商負責高風險變更，內部逐步接手知識更新與日常監看。每次轉換都應有可驗證的能力門檻，而不是只看合約到期日。
三種模式的責任分工範本
先寫一頁責任表，再談支援價格。以下是起點，不是通用合約條款。
| 工作 | 企業業務 owner | 內部技術／營運窗口 | 外部供應商 |
|---|---|---|---|
| 資料與回答規則 | 確認可用範圍、核准內容 | 更新來源、保留版本 | 依約協助接入與除錯 |
| 模型或工作流變更 | 確認業務效果與風險 | 提供測試案例、驗收 | 執行約定的技術變更 |
| 日常監測 | 判斷客戶或流程影響 | 看錯誤、用量與人工轉接 | 處理支援範圍內的技術告警 |
| 事故與停用 | 決定對外處置、批准重啟 | 先停流程、保存紀錄 | 排查原因並提出修復 |
| 帳號與權限 | 核准誰可接觸資料 | 定期核對與撤權 | 僅持有完成任務所需權限 |
「共同維運」尤其要寫明接球順序。例如客服 AI 出現錯誤答案時，第一線先停止自動回覆並留下案例；內部窗口確認是否為來源資料問題；供應商只處理約定的模型、整合或部署缺陷。若沒有這條順序，兩邊都可能以為對方會處理。
30 天內如何試行維運選擇
第 1 週：清點責任與現況。取出驗收證據及已接管資產，列出目前誰有管理權、誰能看日誌、誰能停用。缺的項目先補齊，不急著擴大使用者。
第 2 週：做一次真實小變更。由預定的維運者更新一則知識內容或一個低風險規則，保留測試前後結果。若必須依賴供應商口頭指示，將它記入共同維運範圍與訓練需求。
第 3 週：模擬故障與求援。選一個可控情境，例如資料來源暫時失效，演練暫停、人工接手、通報、復原與紀錄。不要在真實客戶資料上製造事故。
第 4 週：決定下一季模式。根據實測能力、錯誤影響、變更量與總成本，選一種主要模式。同步寫下再次檢查的日期、退出或轉換條件，以及供應商支援範圍。後續可把結果帶進AI 月度治理會。
什麼情況先不要完全內部接手？
- 內部沒有能看懂部署、權限與日誌的人，也沒有替補。
- 供應商仍持有企業無法自行撤銷的關鍵權限。
- 真實錯誤案例尚未形成可重跑的測試集。
- 發生異常時，團隊不清楚先停哪個流程、誰可批准恢復。
- 資料或系統授權不允許預期中的複製、修改或轉移。
這些訊號代表要先補能力與契約邊界，並不必然代表永遠委外。英國政府 AI 採購指南可供參考如何把供應商、內部能力與持續支援放進採購討論；具體權利仍以實際合約為準。
常見問題
試點驗收通過，就能直接轉內部維運嗎？
不一定。驗收證明特定版本在約定案例下達標；內部維運還要有權限、文件、測試、監測、故障處理和備援人員。至少做一次由內部主導的小變更與回復演練。
共同維運會不會兩邊都負責，結果沒人負責？
會，所以要按任務寫清第一接手人、處理時限、升級窗口與重啟批准人。對外營運與資料使用的最終決策，企業應指定自己的負責人。
哪種模式最省錢？
沒有通用答案。應以相同服務範圍比較供應商費、用量、內部工時、訓練、備援與事故處理。只看月費容易漏掉轉換與停機成本。
什麼時候重新評估維運模式？
試行一季後、重大功能變更、供應商條款調整、內部 owner 異動或事故後，都值得重新評估。續約前則另外檢查供應商條款與退出條件。
參考來源與資料時間
以下資料於 2026-10-09 查核。來源提供風險管理與採購的參考方法，不是台灣中小企業的法定要求；實際責任與費用應依雙方合約、平台規則與專業意見確認。
- NIST AI RMF Core：角色責任、第三方風險、生命週期監測與管理。
- 澳洲政府 AI 影響評估：可靠性與安全：供應商支援、驗證、監測、內部維護能力與責任界線。
- 英國政府 AI 採購指南：採購、供應商合作與後續支援的規劃參考。
下一步
拿出一個已驗收的 AI 工作流，用本文責任表寫下下次變更、下次錯誤、下次停用各由誰處理；再選一項低風險變更實際演練。需要先盤點導入範圍與責任，可從中小企業 AI 導入治理主題頁接著閱讀；若已有具體團隊導入問題，可向 FlyPig AI 洽詢流程健檢。