在比較深入接觸醫療現場之後，我聽到不少讓人印象深刻的經驗——有醫護人員提到，事後被追究責任、甚至走上法律程序；也有人分享，遇到情緒激動、行為難以預測的病人時，會刻意把對方引導到有監視器覆蓋的區域，只為了替自己留下一段能說得清楚的紀錄。

這些經驗一開始讓我有些意外，後來才慢慢理解：在醫療現場，「事情有沒有做對」跟「事後能不能說清楚」，其實是同樣重要的兩件事。也是從這裡開始，我更確定一件事：一套 AI 系統如果沒有把責任歸屬設計進去，模型再聰明，最後也很難真的在現場落地。

Day 14 拆解完藥品管理的八個階段後，留下一個問題：AI 真正走進流程之後，該幫藥師做到什麼程度，又該在哪裡畫下界線？這一篇想從另一個角度回答——比起討論 AI 能做到多聰明，醫療領域更該優先解決的，其實是責任歸屬：當 AI 建議出了差錯，究竟該由誰承擔後果？這個問題沒有處理好，再完美的 Human-in-the-loop 設計，最後都只是把責任模糊地留在半空中。

設計啟示一｜Human-in-the-loop，比「人看 AI 結果」複雜得多

多數人聽到 Human-in-the-loop，第一個畫面往往是：AI 給出一個答案，人看過之後點頭或搖頭。這個畫面沒有錯，但太單薄了——它把整套機制縮成一個瞬間的動作，卻忽略了這個動作前後其實還有一整條路徑。

一套能承受高風險決策的 Human-in-the-loop，比較接近一個完整的閉環：

1. AI 擷取資料——從病歷、處方、檢驗結果與過去紀錄中，把跟這次判斷相關的資訊收集起來。
2. AI 產生候選建議——根據擷取到的資料，提出可能的判斷或處理方式，並附上足夠的脈絡，讓建議有跡可循。
3. 系統顯示證據、限制與不確定性——每一條建議都附上依據、來源，以及模型自己評估的信心程度。
4. 醫護判斷是否採用——由具備專業責任的人決定要不要接受這個建議。
5. 醫護修改、拒絕或補充理由——如果不採用，系統要讓人能留下原因，介面設計需要超越單純的「同意／不同意」兩個按鈕。
6. 系統記錄最終決策——不管最後採用的是 AI 建議、人的修改，還是完全不同的判斷，都要被完整記下來。
7. 後續結果回饋給系統與管理者——這個決策後來的結果如何，要能回頭餵給系統，也讓管理者看見 AI 建議被採用、修改或拒絕的模式。

這七步合起來，才是 Human-in-the-loop 真正在做的事——它是一條資料流向人、判斷流回系統的迴路，遠比單一時間點的核可動作豐富許多。而這條迴路裡，第 4 到第 6 步，正是責任歸屬真正會被決定的地方，也是接下來這篇文章想深入談的重點。

可以直接落地的做法：

• 把「不同意」拆成結構化選項：醫護拒絕或修改建議時，提供常見理由的快速選項（資料不完整、病人有特殊狀況、臨床判斷不同），加上選填的自由文字——留下理由的成本要低到幾秒內完成，才不會被跳過。
• 每一條建議做成可展開的卡片：收合時只顯示結論與信心程度，展開後看得到引用了哪些資料與規則依據，對應第 3 步的證據呈現。
• 替管理端做一張回饋儀表板：按建議類型統計採用率、修改率與拒絕理由的分布，讓第 7 步的迴路真的看得見，而不是只存在資料庫裡。

設計啟示二｜把責任拆成三層：Detection、Recommendation、Decision

醫療流程的錯誤成本很高，AI 介入程度越高，系統就越需要清楚定義「誰負責什麼」。這樣的分層並不是憑感覺畫出來的，人因工程領域早有經典依據——Parasuraman、Sheridan 與 Wickens 在 2000 年提出的自動化類型與層級模型（A Model for Types and Levels of Human Interaction with Automation），把人機系統的運作拆成四個階段：資訊擷取（information acquisition）、資訊分析（information analysis）、決策選擇（decision selection）與行動執行（action implementation），並主張每個階段的自動化程度應該分開設定，而不是一刀切地問「這件事要不要交給 AI」。

對應到醫療 AI，前兩個階段可以放心交給機器，最後的行動永遠留給人：

• AI 負責 Detection（對應資訊擷取與分析）：從大量資料中找出人可能忽略的異常、模式與風險。
• AI 負責 Recommendation（對應決策選擇的候選產生）：根據資料提出可能的處理方式，並附上依據。
• Human 負責 Decision（對應最終決策與行動）：由醫師、藥師或其他專業人員結合臨床情境，做出最後判斷。

這樣的分工，也與美國 FDA 對臨床決策支援軟體（Clinical Decision Support）的監管思路一致：要被視為「支援」而非「決策」，軟體提供的必須是建議，而且臨床人員要能夠獨立檢視建議背後的依據，而不是被迫依賴它。AI 的角色因此從「執行者」變成「決策夥伴」——它做前兩層，最後一層永遠留給人。

可以直接落地的做法：

• 三層在介面上要有三種不同的視覺語言：Detection 用標記與提示（badge、highlight），Recommendation 用附依據的建議卡片，Decision 則是只有具名使用者能觸發的行動按鈕。使用者一眼就要分得出「這是 AI 看到的」「這是 AI 建議的」「這是我要決定的」。
• 行動層永遠不能被 AI 預先按下或預設勾選——「開立」「發藥」「修改醫囑」這類操作的預設狀態必須是空的，AI 建議再有信心也一樣。
• 在功能規格書裡，替每一個 AI 功能標注它屬於哪一層；出現「自動完成 Decision 層」的需求時，直接退回重新設計，而不是進開發排程後再吵。

當 AI 建議出錯，責任要算在誰頭上？

不過，分工寫得再清楚，都還只是紙上的設計；出事之後，人們實際上會怎麼分配責任，是另一回事。比起運動科學，醫療領域的責任歸屬問題重要得多——選手的訓練建議出錯，頂多影響一次表現；但醫療判斷出錯，可能直接關係到病人的生命安全，也牽涉到實際的法律責任。這也是為什麼，在 Human-in-the-loop 的設計裡，「誰負責」不能只是一句口號，需要有明確的研究數據作為依據。

2025 年一篇 CHI 研究〈Responsibility Attribution in Human Interactions with AI〉，專門比較了人在與 AI 互動後，如何分配正面與負面結果的責任。幾個發現值得注意：整體而言，參與者平均把較多責任歸給 AI 系統；但當結果是負面的，參與者反而更傾向把責任集中歸咎到單一實體上；而這個單一實體究竟是人還是 AI，並不固定，會受到情境與互動方式影響。

換句話說，人對 AI 的責任判斷，會隨著介面設計、互動方式與結果好壞而變動，很難被當成穩定、可預期的規則。這對產品設計是一個警訊：如果系統沒有主動留下清楚的紀錄，責任歸屬很可能會在事後被重新詮釋——組織可能在 AI 表現好時，把成果算給 AI 的功勞；但 AI 出錯時，責任卻悄悄轉嫁回最後按下確認鍵的醫護人員身上。

另一篇研究〈AI Shall Have No Dominion: On How to Measure Technology Dominance in AI-supported Human Decision-making〉，則點出更隱微的問題：即使系統設計上要求醫護做最終確認，實際運作中，醫護可能因為時間壓力、AI 看起來很有權威感，或介面引導，而傾向直接接受 AI 給出的第一個答案。表面上看起來是 Human-in-the-loop，實際上卻可能是 AI-in-control、human-as-signer——醫護承擔了責任，卻不一定真正掌握決策權。這句話，我認為值得放在這一整篇文章的核心位置：Human-in-the-loop，不等於人真正控制系統。

功與過，不會對稱分配

責任判斷不只不穩定，還不對稱。一篇較新的 ACM 研究〈The Asymmetry of Attribution in Human vs. AI Delegation〉，處理的正是這一面：人類把任務委派給 AI 之後，功勞與責任並不會對稱分配。成功的時候，功勞經常被算給 AI（系統很聰明）；失敗的時候，責任卻更容易被追回到做出最終決定的人身上。

這種不對稱，會讓臨床人員陷入一種尷尬的位置——AI 表現好時分不到多少肯定，AI 出錯時卻要扛下大部分責任。這也呼應了 Human-in-the-loop 設計上一個容易被忽略的問題：委派決策給 AI 之後，人類是否仍然保有實質控制？如果答案是否定的，那麼要求人承擔全部後果，本身就不公平。

設計啟示三｜讓責任可以被追溯：decision provenance

既然責任判斷這麼容易受情境影響、又天生不對稱，產品設計最直接能做的，就是讓每一次決策的完整脈絡都被留下來，不用等到事後才靠記憶重建。這代表系統至少要記錄：

• 當時系統顯示了什麼建議
• AI 使用了哪些資料
• 模型版本與規則版本
• 警示是否真的被看到
• 誰修改或覆寫了建議
• 誰在何時核准
• 之後的結果如何

這套完整的 decision provenance（決策脈絡紀錄），才是讓責任歸屬在事後有據可查的基礎，不需要仰賴當事人的記憶或組織的說法。

可以直接落地的做法：

• 用事件層級的 log 取代結果層級的 log：不只記「最後核准了什麼」，而是記錄建議何時被顯示、依據有沒有被展開、警示是否真的進入可視範圍、誰在什麼時間做了什麼修改。
• 每次核准時存一份「決策快照」：把當下的建議內容、引用資料、模型與規則版本打包成不可竄改的紀錄，而不是事後從多張資料表拼湊。
• 提供事後回放功能：稽核時能重建醫護當時實際看到的畫面。「他當時到底看到了什麼」不該是靠證詞還原的問題。

設計啟示四｜組織該給的保護：不能只讓第一線扛

但光有紀錄，還不夠。〈Rethinking Human-AI Collaboration in Complex Medical Decision-Making〉這篇把視角拉到組織層級：複雜醫療決策中，一大阻礙其實是 liability（法律責任）——即使 AI 已經實際影響了判斷，臨床人員通常仍然要對最終的醫療決定負全責。這帶出兩個常被忽略的現象：第一，醫療專業人員可能因為擔心被追責，乾脆不敢真正依賴 AI，即使 AI 的建議是對的；第二，醫護也可能反過來過度記錄、過度覆核每一個細節，只是為了在事後能自我保護，這又會拉長工作時間、增加額外負擔。

這對產品設計是一個提醒：光是把系統做得「可覆核」還不夠，組織層級也需要提供制度性保護——例如明確定義在什麼情況下，遵循系統建議而導致的結果不會被單獨究責於個人；或是在稽核與教育層面，把「AI 建議被拒絕」視為專業判斷的正常展現，不需要額外解釋。責任設計如果只做到「產品留下紀錄」，卻沒有搭配組織政策，最後很可能只是把壓力全部留在第一線人員身上。

可以直接落地的做法：

• 把「拒絕 AI 建議」設計成低摩擦操作：拒絕的步驟數不能多於接受。一旦拒絕要多填三個欄位、接受只要一鍵，介面本身就在懲罰專業判斷。
• 報表裡把採用率呈現為中性的觀察統計，不要做成排行榜或個人績效指標——拒絕率一旦變成 KPI，組織壓力就會從報表滲回臨床決策。
• 內建可匯出的稽核報告格式，讓機構在制定「遵循建議免責」這類政策時，有現成、格式一致的證據可以引用，而不是每次都要工程師手動撈資料。

設計啟示五｜責任分散在多個角色：五個角色的分工

把產品層的紀錄與組織層的政策放在一起看，就會發現：醫療 AI 的責任沒辦法只落在「AI」或「醫護」兩個位置。比較合理的做法，是拆成五個角色，並且讓每個角色都在產品設計上留下對應的證據：

可以直接落地的做法：

• 把表格右欄直接當成產品需求清單：模型卡與已知失效情境要做成使用者查得到的頁面，版本與更新紀錄要有可瀏覽的時間軸，接受／修改／拒絕要有對應的 UI 元件——「證據」要存在於產品裡，而不是只寫在導入文件裡。
• 盤點不同職類的資訊權限：醫師、藥師、護理師若看到的依據深度不同，先確認這個落差是刻意的設計決策，而不是無意間製造出責任真空——「我當時根本看不到那條警示」不該在事後才被發現是權限設定造成的。

設計啟示六｜不要把 AI 寫成「負責任的主體」

最後一件事，我覺得特別要小心：在上面那張表裡，AI 雖然佔了一列，但不要因此把它直接寫成「負責任的主體」。更精確的說法，是 AI 可以成為造成結果的因果參與者——它確實影響了結果，但它無法出庭、無法被懲戒、也無法對病人交代。臨床責任與問責制度，目前仍然需要由人類與組織共同承擔；把責任寫在 AI 頭上，等於讓整條責任鏈在最關鍵的地方斷掉。

可以直接落地的做法：

• 檢查所有 UX 文案：AI 的輸出一律用「偵測到」「建議」「供參考」這類措辭，避免「AI 已判定」「AI 已確認」這種把 AI 寫成決策主體的句型。
• 確認動作永遠綁定具名的人：畫面上顯示的是「王藥師已核准」，而不是「系統已核准」——每一個決策節點都要能對應到一個可以問責的人。
• 這條規則同步套用到行銷素材與導入簡報：產品裡小心維持的責任邊界，很容易被一句「讓 AI 幫你做決策」的宣傳文案破功。

下一個問題：被資訊淹沒的醫護人員

這一整套責任設計，最後都收斂到同一個目的：讓每一次決策的責任，都能在事後被清楚追溯，不再含糊地落在最後按下確認鍵的那個人身上。但責任設計本身，也可能製造新的問題——當系統為了留下紀錄與覆核證據，要求醫護確認每一個步驟、閱讀每一條依據，人的注意力就會被大量低價值的確認動作消耗掉，真正重要的警示反而被淹沒。責任歸屬解決的是「事後能不能說清楚」，但醫護每天真正面對的，是「當下根本處理不完」的資訊量。

這會是 Day 16 要繼續拆解的問題——被資訊淹沒的醫護人員：現有的醫藥 AI 應用，究竟解決了哪些負荷？