AI 工作流怎麼導入？資料、權限與人工覆核

AI 工作流能不能進到醫院，先看資料能否在正確權限下流到正確節點，還要看輸出能否被人覆核、留紀錄，異常時能退回人工。模型能力排在後面。衛生福利部 2026 年 5 月發布的指引，已把資料保護評估、EMR／HIS／PACS 整合、輸出追蹤、替代流程與具資格醫事人員的最終確認列為導入重點。醫療機構應用生成式人工智慧指引

這個判斷也適用企業內部的客服、法務文件、採購與人資流程。若正在做模型比較，可以先看AI 模型選型怎麼做的評估方法；本文把焦點往前移，處理模型收到什麼資料、輸出交給誰，以及每一步怎麼留下可查的責任線。

AI 工作流是什麼

本文把 AI 工作流定義成一條可追蹤的業務鏈：事件觸發、取得必要資料、模型處理、人工判讀、寫回原系統，再進入監測或退出。這個定義重點在流程邊界，不在某一家模型或某一個介面。

衛福部指引把生成式 AI 系統描述為模型加上資料處理、使用者介面、安全控制與輸出管理的完整技術系統，適用情境包含病歷撰寫輔助、臨床決策支援、行政文書與病人溝通。指引的適用範圍與系統定義已經把「模型」和「進入機構環境後的系統」分開，導入時不能只驗證模型回答。

以門診摘要為例，工作流可以是：門診結束後建立一筆待處理任務，系統只取這次就診必要的資料，AI 產出草稿，醫師確認並修改，完成電子簽章後才寫回病歷。衛福部指引要求涉及臨床判斷、病人安全、病人溝通或醫療紀錄時，由相應專業資格的醫事人員負最終確認、審核與責任。醫療 AI 的責任與病歷審核要求

AI 工作流怎麼運作

先把任務當成資料物件

FHIR 的 Task 資源可以描述要完成的活動，追蹤它從建立、指派、進行中到完成或失敗的狀態；Task 也能記錄輸入與輸出，讓下一個步驟接手前一個步驟的結果。HL7 FHIR Task 規格把這套設計放在醫療工作流脈絡中，並列出請求人、負責人、執行時間與任務歷史等欄位。

我的做法是把每次 AI 處理視為一筆有生命週期的任務，而非一個沒有上下文的聊天請求。至少要有任務編號、觸發原因、資料範圍、模型版本、輸出狀態、覆核者、覆核時間與失敗處理；這些欄位讓團隊日後能回答「誰在什麼情境下看了什麼，最後採用了哪一版結果」。

資料只取完成任務所需的範圍

台灣《個人資料保護法》把病歷、醫療、基因與健康檢查列為個人資料；第 6 條對這類資料的蒐集、處理與利用設有例外條件，第 8 條則要求告知蒐集目的、資料類別、利用期間、地區、對象與方式。全國法規資料庫的個資法條文

所以資料流設計要先回答四個問題：這次任務的目的在哪裡、需要哪些欄位、資料會到哪個服務、結果保留多久。對病歷摘要來說，系統可能需要本次就診內容與相關檢驗，但未必需要整份長期病史；對客服摘要來說，可能需要對話內容，卻不需要把完整付款資料送進模型。這是依個案目的、資料敏感度與工作需求做的設計判斷，不能用一套預設權限套所有部門。

讓輸出停在草稿層

在高風險流程中，AI 輸出先進入待覆核狀態，系統再依結果決定是否允許寫回、通知或觸發下一個任務。衛福部指引要求醫療機構在代表性臨床案例與工作流程下進行效能、壓力與臨床安全測試，並在專責單位確認後上線。指引的整合測試與上線條件

這個節點要有明確的「不通過」出口，例如資料缺欄、來源過期、模型無法回答、信心不足、回覆超出預定用途，或人工覆核者發現內容錯誤。沒有拒絕與退回狀態，團隊最後只能靠使用者自行判斷，系統也無法統計問題出在哪一段。

權限與紀錄要怎麼設計

權限跟著角色與目的走

醫院常見的錯誤，是只在入口處判斷「這個人能不能用 AI」，卻沒有再判斷「他能不能看這位病人的這一段資料」。我會把權限拆成三層：使用者角色、任務目的、資料範圍。醫師、護理師、資訊人員、廠商維運者可以看到的內容與能執行的動作，應該各自定義；同一個人因為處理病歷摘要、品質稽核或系統維運，也可能需要不同的資料視野。

FHIR 的 AuditEvent 規格把存取控制決策、登入登出、設定變更與資料暴露列為可記錄的安全事件，並指出實務上可依在地安全系統使用 RBAC 或 ABAC 定義角色。HL7 FHIR AuditEvent 規格這給了資料架構一個具體方向：權限決策要能被記錄，不能只存在某個未留下歷史的設定畫面。

把兩種紀錄分開

我會把紀錄分成兩層。第一層是稽核摘要，記錄操作者、目的、時間、資料對象、模型與結果狀態，供資安、個資與管理單位追查；第二層是內容血緣，記錄輸入資料的來源版本、模型版本、提示或規則版本、AI 原始輸出、人工修改與最後採用內容。醫療機構不必把所有敏感內容複製到每一份 log，但要能從受控位置回溯必要證據。

FHIR 將兩個概念分開：Provenance 用來說明資源如何被建立、修改或簽署，以及涉及哪些人、系統與資料；AuditEvent 用來記錄使用或查詢等事件。FHIR Provenance與 FHIR AuditEvent 的關係說明可以拿來對照資料庫欄位，不必把「誰產生內容」和「誰讀取內容」塞在同一個欄位。

把供應商條款接進流程

衛福部指引要求醫療機構向合作廠商取得模型版本、預定用途與限制、資料流向與保存政策、效能指標、已知風險、資安事件通報及變更管理等資訊；契約也應明訂資料使用權限、持續支援與資料流向、存取權限設計。指引的供應商管理要求

採購文件裡若只寫「提供 AI 摘要功能」，驗收時就會缺少判斷依據。至少要把資料是否用於訓練、保存地點、子處理者、版本通知、服務中斷、事件通報、資料刪除與退出後匯出方式列成條款，並指定機構內的核准人與異常窗口。

台灣現況與導入順序

衛福部在 2026 年 5 月 29 日函頒「醫療機構應用生成式人工智慧指引」，提供準備導入或已導入生成式 AI 的醫院與診所參考。指引屬行政指導性質，未設定強制性規定；適用情境涵蓋病歷撰寫輔助、臨床決策支援、行政文書與病人溝通，涉及醫療器材時則回到醫療器材法規處理。衛福部公告頁與指引全文

數位發展部的《公部門人工智慧應用參考手冊》則把 AI 導入拆成場景評估、專案啟動、資料探索與模型建立、模型迭代與部署、風險控制和專案追蹤等階段，並提醒先從現況問題與資料準備度判斷 AI 是否適合，避免為了導入 AI 而導入。公部門人工智慧應用參考手冊

把兩份官方文件轉成醫療或企業可執行的順序，我會這樣排：

階段	要先決定的事	上線門檻
1. 場景評估	哪個痛點要改善，錯誤會影響誰	有明確的人工基準與停用條件
2. 資料盤點	來源、欄位、目的、保存與跨境流向	權限、法規與資料保護評估完成
3. 小範圍試辦	哪個部門、哪類任務、誰負責覆核	代表性案例測試通過
4. 系統整合	如何進入既有 EMR、HIS、PACS 或企業系統	失敗可退回人工，結果可追溯
5. 正式營運	監測什麼、多久重測、誰能停用	有版本回復、事件通報與替代服務

這套順序允許各專案依風險調整規模，先讓責任、資料與退出條件可見。NIST AI RMF 也把 Govern、Map、Measure、Manage 放在 AI 生命週期中，要求定義人類監督、部署前與運作中的測試、持續監測與文件化。NIST AI RMF Core

上線後怎麼驗收與退場

AI 專案的驗收不能只放一個準確率。衛福部指引列出的持續監測項目，包含錯誤或偏誤類型與發生率、異常事件、使用者覆核結果、臨床人員手動修改頻率，以及讓使用者查閱原始資料或出處的機制。指引的持續監測要求

我會把驗收表拆成四類：

1. 結果品質：欄位完整率、錯誤類型、與人工基準的差距、不同族群或科別的表現。
2. 流程品質：回應時間、等待時間、人工修改率、任務卡在哪個節點、未完成任務比例。
3. 治理品質：資料是否超出目的、權限拒絕是否有紀錄、模型與提示版本是否可回溯、誰能核准上線。
4. 韌性品質：模型更新、API 中斷、資料來源異常或輸出漂移時，能否暫停、降版、切換替代服務或回到人工。

衛福部指引要求醫療機構建立版本更新、變更評估、測試驗證、核准上線、版本回復與替代流程；若系統性錯誤無法在合理期間修復，或可能影響病人安全，機構應依事前條件限制範圍、暫停或停止使用。指引的版本管理與停用處置

這也是我會把「退出」寫進第一版需求的原因。團隊若等到服務中斷才討論備援，臨床人員或第一線員工會在最忙的時候臨時找替代方法；若停用按鈕、人工表單、通知對象與回復責任一開始就存在，風險才有機會被控制。AI 服務中斷時的工作流備援原則可延伸閱讀。

導入前的六個問題

在簽約或開發前，我會要求團隊逐題寫出答案：

1. 觸發條件是什麼，哪些情況不應啟動 AI？
2. 模型需要哪些資料，資料目的、來源、保存地點與保存時間是什麼？
3. 使用者能看哪些資料，誰能修改、核准、匯出或刪除結果？
4. 輸出要停在哪個狀態，什麼條件會轉人工或阻止寫回？
5. 每次處理要留下哪些任務、版本、來源、覆核與異常紀錄？
6. 模型更新、供應商中斷或結果變差時，誰有權停用，替代流程多久能接手？

六題都能由產品、資訊、法遵、資安與實際使用者共同回答，才進入小範圍試辦。AI 工作流的第一個版本不必追求全自動，先把資料邊界、人工決定點與失敗出口做對，後續才有可量測、可修改的導入基礎。

常見問題

AI 工作流一定要用 AI agent 嗎？
不一定。若任務可以用固定規則、搜尋、分類或摘要完成，先從可限制範圍的流程開始；衛福部指引也指出醫療 AI agent 的自主決策與行動可能帶來較高的病人安全、責任與合規風險。

醫療 AI 輸出可以直接寫回病歷嗎？
醫療機構應依預定用途、適用法規與院內流程判斷。衛福部指引要求涉及醫療紀錄、臨床判斷或病人安全的情境，由具相應資格的醫事人員最終確認、審核與負責，電子病歷也要依規範完成審核與簽章。

導入 AI 工作流最先要買什麼工具？
先買工具通常會把問題縮成產品選擇。第一步應先畫出資料流、權限矩陣、人工覆核點、驗收指標與停用流程，再用同一批真實案例比較服務、部署方式與維運成本。