當大象開始跳舞
IT 與 AI 團隊的建置常被視為理所當然的進程。然而，隨著數據積累與技術成熟，問題不再是「會不會跳舞」，而是「地板撐不撐得住」。CIO 必須掌握「節奏治理」，避免責任與制度脫節，才能讓創新真正落地 。
文／林華庭（聯新國際醫療集團 總執行長辦公室 策略總監）
隨著數據積累與演算法快速發展，組織對 CIO 的期待水漲船高。董事會或院長室的指令通常清晰而急切：「把團隊建起來，把系統上線，讓創新盡快發生」這種壓力往往迫使技術部門在基礎不穩時，就必須展現「可見的成果」。
團隊即制度：CIO 建置團隊的第一性原理
我們必須釐清「建置團隊」的本質。團隊不是中性的資源配置，而是一種制度化行為。 當正式團隊成立，組織其實做出了三個隱含承諾：第一，問題已成熟到值得制度化；第二，解法暫時不會被推翻；第三，後果將由該團隊承接 。
在判斷仍需修正的階段，過早讓團隊承擔制度化責任，往往不是加速創新，而是提前凍結方向。試想，若一個 AI 模型在尚未驗證邊界案例（Edge Cases）時就寫入 SOP，一旦出現偏差，組織往往傾向於修補而非推翻。系統雖運作，卻失去了重新定義問題的彈性。
為了協助判斷，作者提出「責任成熟度」與「團隊制度化節奏」的矩陣作為導航。橫軸為「責任成熟度」（對風險與歸責的共識）；縱軸為「團隊制度化程度」（編制與預算）。圖中標示了「過早凝固區」（責任未定卻高度制度化）與「責任真空區」（價值外溢卻缺乏歸責）等陷阱 。
以大型醫療組織的數位轉型為例。基於此架構，我們將醫療轉型劃分為三個關鍵階段：探索期、放大期與生態系時期。每個階段都有其特定的「節奏陷阱」，CIO 必須謹慎導航。
探索階段：拒絕過早的「重裝備」
在數位轉型的初期，即所謂的「探索階段」，最容易被誤判為「準備不足」。當資料開始累積、技術看似可行、外部案例逐漸浮現，組織往往會期待 CIO 透過正式 IT 或數位團隊的介入，將不確定性快速收斂成可管理的系統。然而，正是在這個看似合理的時點，許多後續的結構性問題其實已經悄悄埋下。
制度化是把雙面刃：過早凝固的風險
探索階段的真正特徵，並不是資源不夠，而是判斷尚未穩定。需求仍在變動，價值尚未被充分理解，連「成功應該長什麼樣子」都仍存在歧義。
在這樣的狀態下，若 CIO 選擇導入重型 IT 架構或建立正式團隊，組織很容易產生一種錯覺：既然系統已經存在，方向應該已經確定。這種錯覺會迅速改變組織對變動的態度。原本合理的調整，開始被視為反覆；原本必要的試錯，開始被解讀為效率不彰。
[ 加入 CIO Taiwan 官方 LINE與 Facebook，與全球 CIO 同步獲取精華見解 ]
這就是圖一中所示的「過早凝固區」。制度化的力量，往往不是來自明確的命令，而是來自結構本身。一旦某套流程被寫進系統，一旦某種做法被正式配置人力與預算，組織就會不自覺地將其視為既定事實。
在醫療場域中，這種現象尤其明顯。當資訊系統、資料架構或 AI 模型被過早定型，後續的臨床與營運單位反而更難回饋真實需求。不是因為他們不願意參與，而是制度已經在無形中傳達了一個訊息：「這個問題已經被解決了」。結果並不是專案失控，而是專案逐漸失去學習能力，最終扼殺了創新的可能性。
歷史的教訓：IBM Watson Health 的殞落
回顧 2015 年前後的 IBM Watson Health，這是一個典型的「責任成熟度低，但制度化程度極高」的負面案例。當時 IBM 積極將 Watson 推向醫療市場，成立了龐大的獨立事業部（高度制度化），並承諾 AI 能解決癌症診斷等極度複雜的問題。然而，當時 AI 在臨床判斷上的「責任歸屬」與「技術解釋力」尚未成熟（低責任成熟度）。結果，過早的商業化擴張與僵硬的產品交付，導致臨床端發現系統建議與現實脫節時，巨大的組織慣性使得 IBM 難以快速調整底層邏輯。
正確的節奏：輕量支援與修正空間
指出探索期不宜重 IT，並不等於否定 IT 的價值。相反地，在探索階段，IT 的角色反而更加關鍵，只是形式不同。此時真正需要的，不是承擔完整責任的制度化團隊，而是能夠支持探索、促進對話、降低試錯成本的「輕量支援」。
這樣的支援，可能以專案型協作、跨域專案經理（PM）、 Prototype 或資料盤點的方式存在。它們的目的，不是急於將判斷寫進系統，而是協助組織看見不同選項、比較不同路徑。重點不在於把事情「做對」，而在於把事情「看清楚」。探索期真正需要的，不是系統，而是修正空間。對 CIO 而言，暫緩制度化並非保守，而是一種對未來負責的治理行為，保留了隨時修正判斷的權利，直到責任真正成熟。
圖二描繪了從專案啟動到績效放大的動態決策路徑。它展示了當「問題定義不明確」時，應退回探索階段進行輕量支援；唯有當「責任歸屬明確」時，才進入放大階段並建立正式團隊。值得注意的是，當績效增長至外溢出組織邊界時（即生態系），此流程需重新回到「當責歸屬」進行跨機構的責任盤點，避免落入外部的責任真空。
放大階段的迷思：AI 進場與信任斷層
當探索階段的成果被視為「足以放大」時，AI 往往被視為加速器。資料規模到位、模型表現可觀，AI 於是被期待成為下一個加速器。然而，這正是許多醫院導入 AI 失敗的關鍵時刻。
AI 改變了判斷的權重結構
放大階段的核心任務，是把已被理解、被承擔的判斷，穩定地複製到更大範圍。AI 因其自動化與規模化的特性，看似是理想工具。但必須注意的是，AI 團隊的進場，從來不只是技術升級，而是一場關於「判斷權重」的重分配。
當演算法開始影響臨床排序、資源配置或風險評估，它實際上是在與人類專家的判斷進行競逐。若此時「誰為 AI 的錯誤負責」這一問題尚未解答，AI 就會成為組織內部的摩擦來源，導致「信任斷層（Trust Gap）」的出現。最常見的例子是「警示疲勞」：為了避免漏診，技術團隊將 AI 模型的敏感度調高，導致臨床端不斷收到假警報。結果是，表面上模型被納入流程，實際上決策模式毫無改變。這種斷層未必表現為公開反對，而是以更隱晦的形式存在，如「殭屍系統」（Zombie Systems），系統在跑，但無人看。
Microsoft 的策略：讓技術與責任同步
相較於 IBM 當年的激進，Microsoft 在醫療 AI 的佈局則展現了更成熟的節奏治理。 Microsoft 在收購語音識別巨頭 Nuance 後，並未急於用 AI 取代醫生的診斷，而是將 AI 定位為「減輕行政負擔」的工具（如自動生成病歷）。這是一個「責任成熟度」極高的領域，行政效率的責任歸屬明確，且風險可控（若是寫錯，醫師修改即可，不涉及人命風險）。微軟的策略確保了「技術放大的節奏」與「責任承擔的節奏」同步。
放大績效的前提是責任到位
從節奏治理的角度來看，AI 能否放大績效，關鍵不在於模型準確率，而在於責任是否已被承接。 CIO 必須確保：在 AI 模型進入「績效放大區」之前，組織內部已經對「何時採信 AI」、「何時推翻 AI」以及「後果由誰承擔」達成了共識。唯有如此，AI 才能從威脅轉化為專業的延伸。
當生態系價值外溢，責任不能空白
隨著醫療走向「無圍牆醫院」與健康生態系，IT 與 AI 團隊的角色開始外溢。資料跨越了機構邊界，價值在院外生成，但治理邏輯往往仍停留在院內。這種錯位，正是生態系階段最容易出現的節奏問題。
1. 責任真空區的風險
在健康生態系中，價值多半誕生於組織之間。跨院資料共享、平台型服務與科技夥伴的共同開發，讓 IT 與 AI 團隊成為連結不同行動者的關鍵節點。然而，當 IT 團隊開發的平台服務於多個醫療機構、保險公司甚至居家照護體系時，一旦出現判斷失誤，責任歸屬極易落入「責任真空區」。
是平台開發者的錯？資料提供者的錯？還是終端使用者的錯？例如，一個居家心律監測 AI 發出異常訊號，但病患未及時就醫導致憾事。此時，是 AI 誤判？還是傳輸延遲？抑或是病患衛教不足？若缺乏明確的跨界治理機制，團隊會傾向於保守行動，避免觸及關鍵創新，導致生態系合作流於形式，缺乏深度。
2. CIO 的新角色：生態系節奏協調者
在生態系時代，CIO 的職責升級為「節奏協調者」。其核心任務在於判斷責任制度化的節奏，是否已經跟上價值外溢的速度。CIO 必須具備高度的政治智慧。在推動技術串接之前，先確認合作夥伴間的責任框架是否對齊。例如，在建立跨院癌症資料庫時，CIO 不應只關注 API 的通透性，更需先行定義資料錯誤時的修正機制與權責。
具體而言，在 API 文件交換之前，必須先有一份「數位責任協議（Digital Responsibility SLA）」。這份協議不僅是服務水準協議（SLA），更應包含三大核心條款：
- 數據漂移責任（Data Drift Liability）：當院外數據分佈改變導致模型失準時，誰負責監測與通報？
- 人機協作界線（Human-in-the-loop Boundaries）：明確定義哪些情境下，AI 僅能作為參考，不得全自動執行。
- 版本回溯機制（Rollback Protocol）：當跨機構模型更新導致一方績效下降時，如何啟動回溯機制以保障病患安全。
這種「治理先行」的思維，是生態系能否產生實質績效，而非僅是「煙火式創新」關鍵。
CIO 的終極修煉：定奪不確定性的終結時點
回顧上述歷程，我們發現「節奏治理」貫穿了數位轉型的始終。無論是探索期的輕量支援、放大期的責任同步，還是生態系的跨界治理，CIO 的核心價值始終在於判斷：「此刻的責任，是否已經成熟到值得被制度化？」
結語： CIO 的行動清單
一位卓越的 CIO ，必須像一位舞池中的指揮家。他清楚何時該讓大象奔跑，也知道何時該放慢腳步，等待地板鋪設完成。為了實踐節奏治理，作者建議進行以下檢視，並將其轉化為具體的管理行動：
1.盤點現狀：您的 AI 專案現在處於圖一的哪個象限？是否存在「過早凝固」（有系統但無彈性）或「責任真空」（有應用但無人負責）？
2.調整編制：對於仍在探索的問題，勇敢地撤回重型 IT 架構，改以敏捷小組對應，換取修正空間。
3.定義責任：在導入新模型前，先與臨床主管確認「誤判時的責任歸屬」，而非僅討論技術指標（如 AUC 或準確率）。
4.同步節奏：確保技術節奏（系統上線）、責任節奏（歸責確認）與制度節奏（團隊編制）三者對齊。
當節奏同步時，大象不僅能跳舞，更能跳出優雅而持久的舞步。當大象開始跳舞，真正決定舞步是否站得住的，從來不是音樂的快慢，而是地板是否被好好設計過。
[ 推薦文章：你以為 CIO 只是在顧系統，其實他正在替組織創業 ]
誌謝：本文之核心論點與策略視角，承蒙聯新國際醫療集團策略長蔡義昌博士提供實務洞察與寶貴建議，特此致謝。
(本文授權非營利轉載，請註明出處：CIO Taiwan)
