AI 服務導入之後誰來負責？企業從上線驗收到持續營運的管理方法

公司核准了 AI 預算，合作團隊完成展示，員工也拿到了帳號。過了一段時間，新的問題才出現：答案引用舊資料，要找誰修改？服務突然變慢，誰決定切回人工？模型更新後，原本能完成的工作出錯，這算維護，還是另一筆專案費用？

這些問題都指向同一個管理缺口：企業買到了技術與建置工作，卻還沒建立完整的服務責任。AI 服務導入的首要目的，是讓組織能穩定取得所需能力，並保有判斷品質、調整投入與持續改善的主導權。這份責任安排，應在上線之前就開始討論。

一、先從產業與營運目標，決定 AI 服務要承擔什麼

本文所說的「AI 服務導入」，是企業將外部 AI 平台、模型能力、顧問支援或整合服務，接進既有組織與營運的過程。它可以發生在製造、流通、專業服務或其他產業；「服務」指的是取得與運作能力的方式，並不限於服務業。

對經營者而言，第一個問題應該放在企業整體：公司打算用 AI 支持哪一項營運能力？可能是跨據點服務一致性、知識傳承、專案交付速度，也可能是擴張過程中的管理品質。先確定這個方向，才有依據決定哪些部門、資料、系統與合作角色需要一起調整。

例如，同樣導入知識問答，一家設備公司的重點可能是讓不同年資的服務人員取得有效技術資料；一家多據點企業則可能重視各據點對政策的理解一致。兩家公司都能使用文件查詢，但應驗收的工作結果、錯誤代價與更新責任並不相同。

因此，初次討論不必急著列出全部自動化功能。較有價值的產出，是一份能說明「支持哪項營運能力、影響哪些工作、哪些決定仍由企業掌握」的服務範圍。這讓後續技術選擇有方向，也讓不同合作方式可以依企業條件組合。

如果企業尚在釐清採購需求，可以先使用企業 AI 導入需求書的決策方法。本篇往後一步，集中處理範圍確定之後，如何把服務接進日常營運。

二、專案完成、服務可用、任務合格與營運成效，要分開判斷

驗收會議容易出現一個落差：技術團隊認為功能已完成，使用部門卻認為工作仍沒有變好。雙方可能都沒有說錯，只是在回答不同問題。

以下四層，是本文提出的管理區分，用來協助企業整理證據，並非官方認證或通用評分標準。

以設備售後知識服務為例，員工能登入並取得回答，可以支持「服務可用」的判斷。但回答引用哪一版手冊、是否適用該設備型號，以及服務人員能否依據它完成下一步，還需要另外檢查。即使答案合格，客戶等待是否縮短，也要看派工、備料與內部核准是否一起改善。

Microsoft 的 Foundry 可觀測性文件分別描述延遲、錯誤率與用量監控，以及輸出品質、工具呼叫正確性和任務完成評估。由此可推得一個管理上的判斷：系統維持可用，仍需要另一組證據證明工作已合格完成。

這個區分也能讓合作關係更公平。若供應商只承諾提供平台，公司就應確認流程整合與使用管理由誰承接；若承諾包含完整工作成果，驗收便應延伸至相關資料、介接與人工交接。不能用未約定的責任要求對方，也不能讓需要有人處理的工作消失在合約之間。

三、指定服務主責，接起業務、資料與技術責任

AI 服務可能同時使用原廠平台、外部整合程式、公司內部文件及員工覆核。當每一方都只對自己的範圍說明，企業仍需要有人整合完整的工作結果。

本文建議為重要服務指定一位「服務主責」。這是一項管理責任，不一定要新增職位。他需要看得見整體表現，召集相關人員處理問題，並在品質、費用或使用範圍需要調整時，向有權決策的人提出具體選項。服務主責不必親自寫程式，也不代表獨自承擔所有法律責任。

在這個主責之下，至少要辨認幾項不同工作。業務負責人定義什麼結果有用、哪些情況可以接受；資料負責人確認內容版本與適用範圍；IT 或整合方管理系統存取、介接及技術維護；外部供應商依約提供支援。正式擴大使用或增加預算，則應由指定的決策者核准。

NIST 的 AI RMF 1.0 核心框架將清楚的角色、責任與溝通安排納入治理，也要求規劃持續監控。這裡引用的是 2023 年的自願性風險管理框架；本文的角色安排是實務整理，不代表台灣企業依法必須設置相同組織。

小型企業可以由同一人兼任數個角色，但應知道自己在什麼情境代表哪一種責任。例如，營運主管可以決定知識資料的適用範圍，卻未必有權核准新增外部系統存取。兼任可以簡化分工，權限邊界仍應寫清楚。

共用能力與部門成果，分別由誰負責

當多個部門共用 AI 平台，可以由共同窗口管理帳號、供應商、資安規則與費用分攤，各部門則負責任務品質及營運目標。這樣既能共用基礎能力，也保留依不同業務設計驗收的空間。

董事長或總經理不需要閱讀每次模型呼叫紀錄，更值得定期確認的是：哪些服務已成為營運依賴、目前品質是否在可接受範圍、未解決的問題由誰負責，以及下一筆投入要改善哪個限制。這些資訊才足以支持擴張、調整或停止的決策。

四、把完整任務與例外情境，一起放進驗收

好的驗收需要一個清楚的完成條件。若服務承諾是「協助找到有效手冊並建立處理紀錄」，只有生成答案仍不足以結案。引用資料是否有效、設備型號是否符合、紀錄是否真的保存，都應包含在任務的完成條件內。

驗收資料也要能呈現實際工作的差異。除了一般問題，還應放入缺少必要資訊、資料版本衝突、使用者無權存取，以及外部系統暫時不可用等情境。對這些題目，合格行為可能是要求補充、明確表示無法判定、停止寫入，或交由指定人員處理。

AWS 的定期功能評估指引建議依使用情境選擇指標、保留最低表現門檻，並在模型或客製化變更時重新評估。企業可據此建立自己的案例集合，但抽樣數與合格門檻應依業務影響、案例分布及容錯需求決定。

測試範例要有答案，也要有行為界線

以教學情境說明，一組初步測試可以涵蓋一般查詢、資訊不足、過期文件與越權請求。這只是規劃方式，不代表固定幾題就足以證明服務可靠。測試時應同時保留預期結果、判定理由與失敗後的處置。

「資訊不足時不可編造型號」是一項行為界線；「應提示缺少哪些資料，並保留轉人工紀錄」則是可檢視的完成方式。只寫「回答要正確」，現場往往很難知道誰有權裁定，以及爭議時要比對什麼資料。

企業也可以分開保留供調整使用的案例，以及未參與調整的驗收案例，再加入實際使用中出現的新問題。這是本文建議的測試安排，目的是降低只針對展示題目優化的偏差。

任務完成率必須保留失敗與逾時

管理報表可採用以下口徑，並依服務特性調整：

合格任務完成率＝在觀察截止時已符合完成條件的唯一任務數 ÷ 同一受理批次中屬於服務範圍的唯一任務總數。

完成條件應包含約定時限。失敗、逾時與尚未解決的工作仍留在分母，同一工作重試幾次，只能算同一件任務。不同批次應採相同觀察長度，尚未到期的案件另列；跨期待結者依原批次更新，避免把本月受理與其他月份完成的件數直接相除。逾時後補救完成，可另列最終結案，不能回填成原時限內合格。

另外，正確拒絕越權請求，可以列為邊界測試合格；它不應被加入已完成的商業任務，讓完成率看起來變高。原本約定的人工核准與額外人工重工也要分開，否則會把大量補救工作藏在漂亮的數字裡。

五、上線後，分開管理事故、版本變更與品質改善

當 AI 回答出現問題，團隊不宜一律歸類為「再調整 Prompt」。有些情況正在影響營運，需要立即限制使用；有些是更新前就應驗證的變更；另一些則可以排入下一輪改善。分類不同，處理責任、預算與時程也應不同。

事故處理，先決定怎麼維持服務

假設服務引用了錯誤版本的設備手冊。第一個動作可以是暫停受影響資料的使用，改由人員依有效原始文件處理，同時保留相關任務紀錄。確認影響範圍後，才進一步追查是資料未更新、搜尋取錯版本，還是應用規則沒有檢查型號。

這裡的重點是讓營運有可用的替代方式，並指定誰能啟動、誰接手、誰確認恢復。若涉及資料越權、未經授權的外送或錯誤寫入，處置優先序應依可能影響決定，不能只依報修先後排序。

NIST 的 2024 年生成式 AI 風險管理指引在第三方服務相關建議中，涵蓋事故責任、持續監控、備援測試與支援時效，並指出備援可以包含人工處理。企業可以把這些原則轉成自己的服務約定，無須一開始就採購超出需要的支援規格。

服務等級協議通常稱為 SLA。討論時應分清楚受理回應、提供替代方式、恢復服務與完成根因修復，這些時點的意義不同。雙方還需要寫明服務時段、事件嚴重程度、涵蓋元件及排除條件，才能判斷承諾是否足以支撐營運。

版本變更，要留下前後可比較的證據

更換模型、修改提示詞、調整資料來源或擴大權限，都可能改變服務表現。建議每次重要變更至少留下四項紀錄：變更內容、受影響任務、比較測試結果，以及核准與復原安排。

Microsoft 的 AI 管理指引包含模型版本管理、上線品質門檻、回復措施與模型退役追蹤。對企業而言，可以將它落成一個具體要求：更新前後使用相同口徑比較，並確認原本的重要任務仍能完成。

回復方案也要實際可用。若上游供應商已停止提供舊模型，保留舊版設定並不能讓服務自動恢復。此時需要評估替代模型、降低自動化程度，或回到已演練的人工流程。文件寫有「可回滾」，仍應透過測試確認可以回到哪裡。

品質改善，依營運價值排優先順序

不是每個文字差異都值得開發。對決策者有幫助的改善清單，應說明問題影響哪些任務、造成多少額外處理、改善後要觀察什麼結果，以及投入多少資源。

例如，修正標點可能改善閱讀感受；補上有效版本的檢查，則可能減少服務人員反覆查證。兩者都可以做，但應依營運目標排序。持續合作的價值，也可以透過這份有證據、有取捨的改善紀錄呈現。

六、追蹤每件合格任務成本，才能判斷擴張是否值得

AI 服務上線後，使用次數增加只是活動量。企業還需要知道，增加的使用量帶來多少合格成果，以及為了取得這些成果，投入了多少服務費用與人工處理。

本文建議建立一個管理用口徑：

每件合格任務成本＝同一受理批次截至觀察截止日的總運作成本 ÷ 該批次截至同日的合格完成任務數。

總運作成本應依實際模式納入訂閱、模型與基礎設施用量、維運、人工覆核、重工及評估等項目，包含失敗重試所耗用的資源。尚未結案的批次標為暫估，持續更新分子與分母；合格件數為 0 時不計算單價。建置費若要攤入，應另列攤提期間與方法。既有人員的時間成本可以用於管理比較，但要與當期新增現金支出分開。

以下是純粹的教學試算，並非市場行情或客戶成果。假設某一觀察批次分攤的總運作成本為 NT$90,000，取得 1,000 件合格任務，每件為 NT$90。若同一筆成本只有 600 件合格任務，每件便是 NT$150。比較時仍要確認任務難度與品質門檻一致，才能知道差異來自效率，還是工作內容改變。

這也說明為何不能只追求降低模型單價。若更便宜的模型造成更多人工重做，整體任務成本未必下降。相反地，某些較昂貴的處理方式如果能在相同標準下減少補救工作，才有理由進一步評估。

AWS 的模型指標監控建議涵蓋呼叫量、延遲、用量、錯誤與告警。上述「每件合格任務成本」則是本文提出的管理整理，企業需將技術用量與實際完成結果接起來計算。

對經營成果的解讀也要保持一致。省下的工時，首先代表可重新配置的工作能力。只有能證明減少可避免支出，或產生可歸因的新增成果，才適合進一步計算現金效益。擴張決策應同時看品質、成本與營運影響。

七、用一張責任與驗收表，檢查服務能否被持續接手

以下表格是本文原創的工作工具。適合由企業服務主責、業務與資料負責人，以及相關合作方共同填寫。它管理的是上線後的運作約定，可作為需求書與專案驗收文件的補充。

使用時，每一列都應再補上具名負責人、檢視頻率、證據位置及未達標處置。若某一項不在供應商的服務範圍，也應寫出企業由誰承接，或是否另外採購。留下空白，比填入「雙方共同負責」更容易看見真正的缺口。

示範情境：設備售後知識服務

假設一家設備公司，導入 AI 協助服務人員查找手冊與整理案件資訊。以下為教學情境，不代表真實客戶實績，也不涉及讓 AI 自主控制設備。

營運目的可以先定為「讓服務人員取得一致、可追溯的有效資訊」。服務範圍包含查詢與整理，涉及維修判斷及對客戶的正式承諾，仍由合格人員確認。技術文件負責人維護有效版本，整合方處理索引與權限，服務主責追蹤整體品質及例外。

測試時，可以拿同一型號不同版本的手冊，檢查系統是否使用有效內容；拿缺少型號的問題，確認它會要求補充；用不同角色帳號確認資料邊界。當文件來源無法連線，則檢查服務是否停止提供無法核實的內容，並提示人員改用指定查詢方式。

上線後，會議不必只看使用人次。更有用的問題是：哪一類查詢最常需要人工補救？新文件多久能生效？同一問題是否在不同據點得到一致依據？如果服務要擴展到更多產品線，需要增加哪些資料維護與支援資源？

如此，單一情境的測試才會回到最初的營運目的。公司累積的資產，也包括有效資料、驗收案例、處置方法與內部能力，能支持下一次擴展或更換合作方式。

八、依企業能力組合持續合作，讓接續與退出都有安排

服務穩定之後，企業可以自行營運，也可以委由合作方維運，或採共同管理。選擇應依內部能力、營運依賴程度、資料責任及回應需求決定，沒有必要把所有公司放進同一套方案。

內部已有技術團隊的企業，可以保留日常操作與監控，由外部提供專項支援；內部資源有限但服務不可中斷的企業，可以洽談明確範圍的維運安排；仍在擴張應用的組織，則可以採共同檢視品質、培養種子人員與分階段移轉的方式。

這些合作方式可以並存。重點是企業仍保有對營運目標、資料使用、驗收準則與預算的決策能力。策略合作的深度，應能從持續解決的問題、留下的能力與可檢視成果看出來。

接續與退出也應提早討論。需要釐清企業可以取得哪些資料、提示設定、測試案例、紀錄與操作文件，哪些屬於供應商原有技術或第三方授權，無法直接移轉。更換服務時，還要確認匯出資料能否被下一方實際使用。

英國政府在 2020 年的 AI 採購指引中，已將知識移轉、持續維護與合約結束安排納入考量。這裡採用其管理思路作為參考，不把英國公共採購指引當成台灣民間企業的法律要求。

企業可以請合作方示範一次實際接手：用約定的匯出資料與文件，由另一位指定人員完成查詢、更新或恢復任務。資料刪除也應按約定範圍、保留期限與可提供的證據確認，不能只憑一句「已刪除」就推定所有備份與第三方紀錄都已消失。

下一次討論 AI 服務導入時，經營者可以帶著責任與驗收表，請團隊確認目前最重要的一項服務。先把營運目的、主責、合格證據與例外處置說清楚，再決定擴大範圍、增加支援或調整合作。這會讓每一筆後續投入，都有可以檢視的依據。

延伸規劃企業 AI 導入

若企業需要從產業與營運評估開始，整合策略規劃、種子團隊培育、情境實作與技術整合，可參考天地人企業 AI 導入顧問與陪跑。洽談時可先提供企業現況、預計支持的營運能力與既有系統條件，再共同確認各階段的工作範圍與交付成果。

資料來源與方法

本文為常青管理分析，資料查核日期為 2026／11／05。原始文件支持相關治理與技術原則；四層成果區分、任務成本口徑、責任表及設備公司情境為本篇編輯整理。示範情境與試算均非真實客戶成果，不構成固定費用、效益或服務品質承諾。

1. NIST：AI RMF 1.0 核心框架。2023 年框架；官方頁面顯示修訂進行中。
2. NIST：Generative Artificial Intelligence Profile，NIST AI 600-1。2024 年文件，參考印刷頁 22 的第三方服務治理建議。
3. Microsoft：Observability in generative AI。頁面更新日期：2026／10／17。
4. Microsoft：Manage AI。頁面更新日期：2026／04／10。
5. AWS：Periodically evaluate functional performance。未取得可核實的頁面發布日期。
6. AWS：Monitor foundation model metrics。未取得可核實的頁面發布日期。
7. GOV.UK：Guidelines for AI procurement。發布日期：2020／06／08。

圖片與內容說明

封面與社群圖為 AI 生成的原創概念插畫，非真實設備、產品介面或客戶現場。本文由 AI 協助製作；編輯角色與製作方式詳見作者頁及知識與實務頁的內容製作與更正說明。