CASE STUDY客戶案例・醫療
大千綜合醫院：AI 安全落地的地區醫院範本
一家地區醫院，用一套平台、一群懂業務的種子同仁、一套持續運作的治理機制，讓 AI 從文書走進臨床。
內容依據大千綜合醫院 AI 中心 賴賢勇〈大千醫院導入 AI Agent 平台的操作經驗與治理心得〉（115 年 10 月）。
大千綜合醫院（照片取自大千綜合醫院官方網站）
AT A GLANCE
一眼看懂
正式導入
115 年 7 月 31 日正式導入
系統串接
上線前完成 HIS、NIS、PACS 系統串接
Agent 建置
截至 115 年 10 月，平台已建置 16 個 Agent，其中 14 個已發布
臨床使用
急診病歷摘要助手已正式用於臨床
鑑別診斷屬於協助診斷，風險等級改變，需重新經過法規與治理審查；寫回病歷則以「醫師審閱並電子簽章的草稿」為界。
組織
成立 AI 管理委員會與跨單位推動小組（資訊、醫品、企劃、申報、醫務、專師、護理）
115 年 1 月 10 日
到院授課〈生成式AI工具應用與實戰〉
115 年 5 月 17 日
建立第一支 Agent「醫囑小助手」（住院醫囑）
115 年 5 月 28 日
建立「大千醫院護理交班 Agent」（護理摘要）、「行政文書助理」、「公關企劃文案專家」
115 年 6 月 15 日
建立「資訊室 知識助理」
115 年 7 月 14 日
建立「醫囑小助手（精簡）」
上線前
上線前完成 HIS、NIS、PACS 系統串接
115 年 7 月 31 日正式導入
同日建立「資訊室簽呈撰寫助手」
115 年 9 月 2 日至 3 日
建立「Code Review助手」、「ISO27001文件稽核助手」
115 年 9 月 24 日
建立「智慧急診病歷摘要助手」
115 年 10 月 11 日至 19 日
建立「智慧門診病歷摘要助手（追蹤導向）」、「麻醉術前準備助手（LINE 原型）」、「互動式問卷表單生成助手」、「醫師巡房月報助理」
115 年 10 月
急診病歷摘要助手已正式用於臨床
Agent 的日期是大千站上的建立日期，只列目前啟用中的 Agent。
WORKFLOW
病人插上健保卡，醫師看到的，就是一份整理好的摘要。
急診醫師過去要在多個畫面之間翻閱病歷、檢驗與用藥，才能掌握病人狀況。現在資料一進來，AgentArk 的急診病歷摘要助手就先依院方訂好的規則整理成一頁摘要，交給醫師審閱。
示意短片：插卡帶出資料，Agent 整理摘要，院方系統彈窗，醫師審閱後由院方系統寫回；AgentArk 不直接寫入醫院的病歷系統。
FLOW
示意1
插卡帶出資料
病人插上健保卡，醫院資訊系統（HIS）帶出這位病人的資料。
2
Agent 整理摘要
資料送到 AgentArk，急診病歷摘要助手依院方規則整理成摘要。
3
院方系統彈窗
摘要回傳醫院，由院方系統排版成網頁，在醫師的瀏覽器彈出。
4
醫師審閱
醫師在彈窗中確認、修改。
5
院方系統寫回
由院方自己的系統，把醫師確認過的內容寫回病歷。
AgentArk 不直接寫入醫院的病歷系統。
寫進病歷的，是院方自己的系統、經醫師審閱後的結果。
所有產出都是草稿。由專業人員審閱後才能使用，責任仍在使用者。
以前
醫師自己在病歷、檢驗、用藥紀錄之間切換，邊看邊整理。
現在
插卡後彈窗就有一份摘要可以審閱，醫師從確認與判斷開始。
需求變大時，怎麼重新判斷風險
急診病歷摘要上線後反應良好，臨床端進一步希望加入初步鑑別診斷與建議檢查，並將產出直接寫回病歷。
院方的處理
鑑別診斷屬於協助診斷，風險等級改變，需重新經過法規與治理審查；寫回病歷則以「醫師審閱並電子簽章的草稿」為界。門診版摘要維持純資訊整理，暫不加入鑑別診斷。
Agent 好用之後，需求一定會擴張。治理機制要能判斷「這次修改是否改變了風險等級」。
UNITS
從急診到公關，一個平台服務全院。
涵蓋急診、門診、護理、麻醉、醫務、資訊、行政、公關等單位
BUILD
建一個 Agent 只要幾分鐘，讓它能安全上線，才是真正的工作。
在 Agent 平台上，用自然語言描述需求，幾分鐘就能產生一個可對話的 Agent 草稿。這個速度很容易讓人誤以為導入 AI 很簡單。實際經驗是：一個 Agent 從草稿到可以上線，大部分時間花在設計測試題、找出錯誤、訂定安全規則，以及確認發布後的版本真的是測試過的版本。
因此本院把工作重心放在「測試與治理」，而不是「建得多快」。
做法
單位種子填寫需求申請單：要解決什麼問題、誰會用、用到哪些資料
經驗重點
先寫清楚「不做什麼」，比寫「要做什麼」更重要
FINDINGS
錯誤幾乎都在測試時才被發現。
以下問題都是在沙盒測試中發現，並於上線前修正。這些經驗是本院最有價值的資產之一。
1
分析類 Agent 編造數字
現象
經營管理分析類 Agent 在資料不完整時，會自行補上看似合理的數字，並寫出完整的分析結論。
修正
規定只能引用輸入資料中的原始數字；所有計算交由程式執行，AI 只負責解讀；缺資料時明確寫出缺少哪些資料，不得推估。
啟示
AI 最危險的錯誤不是答錯，而是「看起來很合理的錯」。
2
對外 Agent 誤將真實個資當作範例
現象涉及測試病人的個人資料，本頁不重述。
修正
加入身分驗證規則：完成驗證前，不揭露姓名以外的任何資料；範例一律使用虛構資料。
啟示
面對病人或院外人士的 Agent，個資規則要寫成硬性規定，並用誘導題刻意測試。
3
長篇產出被截斷
現象
問卷表單生成 Agent 產出的程式碼過長時被截斷，使用者拿到的是無法執行的半成品，而且不容易察覺。
修正
在提示詞中訂定長度規則，精簡輸出內容，並要求超過長度時分段產出、明確標示「未完」。
啟示
測試時要檢查產出的完整性，不能只看開頭。
4
使用者需求逐漸越過風險邊界
現象與院方的處理，見上方工作流章節。
院方的處理，見上方「需求變大時，怎麼重新判斷風險」
啟示
Agent 好用之後，需求一定會擴張。治理機制要能判斷「這次修改是否改變了風險等級」。
GOVERNANCE
大千怎麼決定，哪些事可以交給 AI。
風險分級
大千院方制度低風險
範圍
不含個資、院內文書、知識問答
審查方式
AI 中心審查
中風險
範圍
使用去識別化資料、影響管理決策
審查方式
AI 管理委員會審查
高風險
範圍
內容進入病歷或對外發送
審查方式
專家會簽，產出須經人工確認
不做
範圍
預測型與診斷型 AI
審查方式
—
七項運作原則
一個 Agent，一位業務負責人。
由該單位的 AI 種子擔任，負責需求、測試與後續修訂，而不是交給資訊室或外部廠商代管。
所有產出都是草稿。
由專業人員審閱後才能使用，責任仍在使用者。
上線前必須通過測試題庫。
題庫包含正常、資料不完整、誘導與邊界情境，每次修改都要重跑。
數字由程式計算，AI 只做解讀。
分析類 Agent 只能引用原始資料。
限定使用單位與權限。
Agent 只開放給需要的單位，不全院開放。
需求變更要重新判斷風險等級。
功能擴張可能讓低風險 Agent 變成高風險。
長期無人使用就退場。
避免平台上累積無人維護的 Agent。
這些制度由院方訂定。AgentArk 提供落實它們的工具：
- 角色權限
- 版本與發布控制
- 核准中心與決策中心
- 操作紀錄：可篩選、可匯出 CSV
ASSETS
模型會換，平台會更新，留下來的是你的資產。
模型與平台都會快速更新，真正會留下來的是：各 Agent 的提示詞與設定、測試題庫、驗證結果、使用紀錄與治理規範。本院將這些內容於院內完整保存，未來不論更換模型或平台，都能延續。
平台功能：操作紀錄：可篩選、可匯出 CSV
CLOSING
結語
平台提供的是工具，讓 AI 安全落地的，是各單位的種子人才與一套持續運作的治理機制。
給其他醫院的建議
- 先培養人，再導入平台。由懂業務的同仁學會設計與測試 Agent，比請外部代工更能落地。
- 從低風險開始。先做文書整理與知識問答，建立信任後再進入臨床。
- 把測試當成主要工作。預留比建置多數倍的時間在測試與修正。
- 上線前先量基準值。沒有導入前的數字，事後無法證明 AI 帶來的效益。
- 不必自建模型。地區醫院資源有限，善用平台、把預算放在人才與治理，更符合效益。
延伸區：以下內容與前面的院方實績分開呈現。
AgentArk 為大千規劃的下一步
規劃中・非院方承諾
以下是 AgentArk 依醫院常見需求整理的應用方向，不是大千院方的承諾或計畫，也不代表已上線。
起步
文書與知識
- 院內規章問答
- 會議紀錄整理
- 公文與簽呈草擬
- 衛教文宣草擬
- 新進人員問答
延伸
去識別化資料與管理
- 經營月報解讀
- 病歷編碼稽核輔助
- 健保申報檢核輔助
- 品質指標彙整
- 客訴分類與回覆草稿
- 排班與交班摘要
臨床輔助
需重新經法規與治理審查
- 門診回診摘要
- 住院病程摘要
- 護理紀錄摘要
- 出院準備摘要
- 用藥整合提醒
- 術前準備衛教
設備與場域
擴充藍圖
- 冰箱溫度監看
- 門禁事件通報
- 負壓室狀態監看
- 設備維修工單
- 能源用量月報
- 停車與動線資訊
醫院紅綠線
非臨床設備可自動通報與處理；臨床設備只讀取、不轉送警報、不控制。
案例資料截至 115 年 10 月