當 AI 從導入工具變成營運核心，CIO 不能只問功能是否上線，而要有一套同時管得住探索、能力驗證、治理閘門與規模化營運的控制機制。
文／林華庭（公共價值創造、創新生態系與 AI 治理研究者）
生成式 AI 正促使企業重新思考老問題：技術團隊究竟該怎麼管。過去二十年，IT 管理建立在一個穩定的前提上：軟體輸出可預測，因此管理者能用進度、成本、功能交付率與系統可用性來衡量績效。敏捷開發、DevOps 與各式數位轉型儀表板都是這套邏輯的延伸，也讓 CIO 能清楚地向 CEO 與董事會說明技術投資的成果。
問題是，生成式 AI 屬於機率性系統（Probabilistic System）。傳統軟體在理想狀態下輸入 A 就會得到 B；生成式 AI 不一樣，它的輸出同時受模型能力、資料品質、提示詞、外部工具呼叫與使用者行為左右，今天表現好，不保證換個情境或任務鏈，明天還一樣可靠。這也是為什麼傳統 KPI 不再夠用，因為衡量 AI 專案的重點，已經從「功能有沒有交付」，移到「模型能不能在真實工作場景裡，穩定產出可信、可用又有商業價值的結果」。
因應之道，是一套「三位一體」的混合管理機制：用 OKR（Objectives and Key Results，目標與關鍵結果）來管理探索、用 AI 評測（AI Evals）來管理能力與風險、用工程 KPI 來管理規模化營運。但光把這三件事擺在一起還不夠；真正稱得上「AI 原生（AI Native）」的管理，會讓它們循環運作、彼此問責、持續學習。
一、為什麼傳統 KPI 管不住 AI？
傳統 IT 管理中，KPI 之所以好用，是因為一切都可預測：需求拆得開、進度追得到、可用性也盯得住。但 AI 專案的性質不同，單靠 KPI 會遇到四個困境。
‧ 高度探索：導入初期，企業對於最佳技術路徑尚未形成共識。CIO 若太早要團隊承諾明確的 ROI 與時程，團隊只會挑最保守、最好交差的做法，反而把真正有突破性的應用做掉了。
‧ 輸出帶機率性：傳統軟體靠單元測試與整合測試把關；生成式 AI 的風險卻不只在程式錯誤，更在語意偏差、幻覺與過度自信。內部測試表現好，不代表面對使用者那些雜亂、情緒化的真實輸入時，模型仍能穩定運作。
‧ 成本結構會變動：生成式 AI 的成本比傳統軟體更動態，包含雲端 API 的 Token 消耗、地端運行的算力，以及容易被忽略的人工介入與覆核時間。如果只盯著上線了幾個功能，卻不管 API 成本與模型漂移，效率看起來提升了，實際上可能正在累積新的技術債。
‧ 整合進流程才算數：模型能力與商業價值屬於不同層次，前者是模型在測試環境的表現，後者則是 AI 嵌進工作流程後產生的實際效益。AI 要真正嵌進工作流程、把人工修正的成本壓下來，價值才出得來；只看模型準確率，根本看不出 AI 有沒有變成組織真正的能力。
其實 KPI 並沒有失效，只是它一個人扛不起整個 AI 的管理。KPI 擅長管那些已知、穩定、能規模化的環節；但在探索與驗證階段，CIO 得跳出單一指標的思維，改用分層控制的思維。
二、OKR 的角色：管理探索，定位為擁抱不確定性
在 AI 場景裡，OKR 管的是探索、學習與方向對齊。當技術充滿不確定性時，Objective 的任務是丟出對的戰略問題，把技術答案留給團隊去找。一個適合探索期的目標，可能會這樣寫：「驗證生成式 AI 能否在高頻客服情境中減輕人工負擔，同時守住回覆品質與法遵底線」，它坦承還有未知，也把學到東西本身當成一種成果。
Key Results 同樣要偏向學習，例如「建立 500 題的企業私有測試集」，或「評估 Token 成本與人工介入率在商業上是否划算」。這呼應了組織學習理論裡「探索」與「利用」的拉扯。OKR 的用意，就是讓團隊在可控的邊界內放手去試。
三、AI Evals 的角色：管理能力與風險
OKR 管探索，AI Evals 管的則是能力與風險，這也是 AI 時代最需要補上的一塊控制機制。
企業不能只看公開的基準測試（Benchmark）。一個指標一旦被當成目標追過頭，就會失去衡量品質的意義。CIO 該做的，是帶著企業建立自己的「私有評測（Private Evals）」，把關鍵業務情境變成可測試、可重複的任務集，至少涵蓋四個層次：任務能力、穩定性、安全與法遵，以及商業適配。
這樣的設計和國際主流的 AI 治理框架是一致的。NIST AI RMF 把 AI 風險管理看成一套持續性的活動，涵蓋治理、情境盤點（Map）、衡量與管理，目的是提升 AI 系統的可信度；ISO／IEC 42001：2023 則提供了 AI 管理系統的制度基礎，協助組織以系統化的方式管理 AI 的風險、責任與治理要求。AI 評測，正是把這些高階框架落實成具體驗證機制的關鍵橋樑。
四、工程 KPI 的角色：管理規模化
一旦 AI 系統離開探索階段、真正進到客服、流程自動化或決策支援等正式環境，就得用嚴謹的工程紀律來管。這個階段，CIO 可以透過一個「AI 營運儀表板」，盯住五類核心 KPI。
‧ 成本：Token 使用量、API 呼叫成本與算力成本。
‧ 效能：首個 Token 回應時間（Time to First Token，TTFT）、平均回應時間與服務可用性。
‧ 品質：人工介入率（HIR）、錯誤修正率與人工修正幅度。
‧ 風險：模型漂移（Drift）、敏感資料外洩與提示詞攻擊。
‧ 商業：採納率、流程節省的時間與轉真人比例。
別把工程 KPI 當成創新的絆腳石；它的作用，是把 AI 從「秀技術」變成一種管得動的營運能力。
五、治理閘門（Governance Gate）與台灣企業落地情境
OKR 鼓勵探索、AI Evals 要求安全、KPI 追求效率，這三股力量常常彼此拉扯，所以整套機制還需要一個決策節點：治理閘門（Governance Gate）。前沿 AI 公司近年已逐步將模型能力評估與風險分級制度化，例如 Anthropic 的 Responsible Scaling Policy（RSP）系列文件。
實務情境：台灣某金控的 AI 理財助理落地
以一家台灣大型金控導入「內部理財文件輔助 AI」為例，此案例為綜合多家金融機構實務經驗之匿名化情境：
‧ 探索期（OKR）：專案剛起步時，IT 與財富管理部門訂的 KR 跳過了「系統上線」，直接鎖定「評估三種 RAG 架構在讀繁體中文基金公開說明書時的語意理解準確度」。
‧ 驗證期（AI Evals）：團隊建了一套 500 題的「私有盲測集」，涵蓋金管會最新法規、極端市場情境，以及高淨值客戶那些高複雜度的提問。
‧ 治理閘門（Governance Gate）：系統試營運前，先由資安長、法遵長與 CIO 組成的跨部門委員會做風險審查。要確認輸出符合既有監理規範、內控要求與銷售適合度原則，重大違規必須是零、一般法遵偏差低於事前設定的門檻，而且要有明確的停用機制與版本回溯能力，才放行。
‧ 營運期（工程 KPI）：上線後，CIO 用儀表板即時盯 Token 成本與 TTFT，重點看「人工介入率（HIR）」與「人工修正幅度」；一旦模型因為市場新資訊出現「漂移（Drift）」，就立刻觸發重新調校。
六、把治理架構做實：成立「負責任 AI 中心」，真正邁向 AI Native
講完三位一體與治理閘門，CIO 還得面對很現實的問題：這套架在機率性系統上的控制框架，平常到底誰來推動？如果只靠原本的 IT 維運團隊，或是一場場流於形式的跨部門臨時會議，治理閘門很容易變成拖慢效率的橡皮圖章，或被部門本位主義卡住。
要讓這套東西真的落地，得把治理架構做成一個實體單位「負責任 AI 中心（Responsible AI Center）」。它是一個跨職能樞紐，成員涵蓋資料科學家、領域專家、法務與核心業務代表，職責遠超出傳統技術客服或法遵稽核。它最主要的角色，是當這套閉環架構的「節奏控管者」：探索期幫業務單位把學習邊界講清楚；驗證期負責建立並持續維護企業專屬的私有測試集，確保模型在極端商業情境下夠安全；營運期則盯著模型漂移與人工介入率。
面對「地下 AI」（Shadow AI）四處冒出來、部門之間各自套利，光靠一紙禁令是擋不住的。負責任 AI 中心的價值，在於它能把幾件事組合起來用：OKR 指方向、AI Evals 守住風險底線、工程 KPI 確保商業價值交付，藉此打通部門間的資訊孤島，把技術風險換算成管得動的營運指標，讓創新在明確的邊界內加速。
再往深一層看，成立負責任 AI 中心、導入這套三位一體的做法，是企業走完數位轉型最後一哩的關鍵。企業導入 AI 會經歷三個階段：「AI Enabled（AI 賦能）」只把 AI 當成提升個人生產力的外掛；「AI First（AI 優先）」則是在設計新產品、最佳化流程時會優先想到 AI，但骨子裡本質上仍是傳統那套確定性的軟體思維與舊 KPI。
「AI First」和真正的「AI Native（AI 原生）」差別在哪？AI Native 組織的關鍵，在於組織心智、治理文化與營運架構打從一開始就是為了應付機率性系統而設計的。優先用技術，只是表象。在這種企業裡，試錯是常態，AI 評測是大家共通的語言，照著商業回饋持續調校幾乎是一種本能。負責任 AI 中心就是這套原生架構的制度中樞。它讓組織把模型輸出的不確定性，從被動承受轉為主動運用：每一次偏差、人工介入與使用回饋，都成了下一輪模型調校與管理修正的依據。
七、AI 原生管理閉環架構與指標總表
要先說清楚的是：前面講的「三位一體」指的是三種管理工具：OKR、AI Evals 與工程 KPI。它們中間還需要「治理閘門（Governance Gate）」把關決策，再加上「商業回饋」把使用結果導回學習，才能串成一套完整的 AI 原生管理閉環，也就是下圖的五個節點。
◤ 圖 1：AI 原生管理閉環架構。這套管理採持續循環的閉環設計：CIO 把 OKR、AI Evals、治理閘門、工程 KPI 與商業回饋串在一起，讓 AI 在探索、驗證、決策、規模化與再學習之間不斷校正，並在創新速度與風險控制之間維持動態平衡。
- 起點／節點一：OKR（探索層）：界定學習方向、策略問題與風險邊界。
- 節點二：AI Evals（驗證層）：用企業私有測試集，驗證模型的能力、法遵、安全性與業務適配度。
- 節點三：治理閘門 Governance Gate（決策層）：透過跨部門風險審查，決定系統放行、退回、限縮或停用。
- 節點四：工程 KPI（營運層）：規模化上線後，持續監控成本、延遲、可用性、人工介入率與模型漂移。
- 節點五：商業回饋（學習層）：追蹤採納率、流程效益、人工修正成本與真實使用資料，導回下一輪 OKR。
◤ 表一：AI 原生管理閉環指標表
| 管理階段 | 核心工具 | CIO 核心問題 | 關鍵監控指標 | 常見誤用陷阱 |
|---|---|---|---|---|
| 探索期 | OKR | 是否能幫助組織界定學習與風險邊界？ | 實驗數量、PoC 學習成果、沙盒隔離率 | 專案初期便過早要求明確的財務 ROI |
| 驗證期 | AI Evals | 模型在真實業務情境中是否可信、安全且符合法遵？ | 私有測試集通過率、幻覺率、偏差檢測率 | 盲目相信供應商提供的公開基準測試（Benchmark） |
| 決策期 | Governance Gate | 若發生嚴重錯誤，企業是否具備停用與問責機制？ | 跨部門法遵簽核率、版本回溯成功率 | 僅由 IT 部門單方面核准，缺乏法遵與業務視角 |
| 營運期 | 工程 KPI | 系統效能是否衰退？使用成本是否符合商業效益？ | Token 成本、TTFT、模型漂移、人工介入率（HIR） | 只看功能上線數量，忽略 API 成本與人工修正成本 |
| 學習期 | 商業回饋 | AI 應用是否真能轉換為持續的商業價值與組織學習？ | 採納率、流程效益、人工修正成本 | 只看單次上線成效，沒把使用回饋導回下一輪 OKR |
結語：重新設計控制系統
到了 AI 時代，管理能力的高下，取決於能不能重新設計整套控制系統；選 OKR 還是 KPI，屬於次要考量。對 CIO 來說，這是一次相當深的角色轉變：過去管的是伺服器、專案與基礎設施，往後要從「系統的控制者」變成「約束條件的設計者」。能把這套系統建起來的 CIO，其定位超越把 AI 工具導進公司，屬於替企業打造 AI 原生能力的制度設計者。
(本文授權非營利轉載，請註明出處：CIO Taiwan)
