60 分鐘後，各位將能掌握三件事
將生成式 AI 納入受控流程，避免將風險引入臨床現場
病人安全可追溯版本控管
- 能識別生成式 AI 的主要風險，明確哪些情境絕不能直接信任輸出。
- 掌握 RAG 的基本門檻：出處、版本、查無資料即退回人工查核。
- 將高頻率任務封裝為 Skills／標準流程，建立「回饋→改版→驗收」的例行節奏。
工具大家都有了，真正缺乏的是一套受控的工作模式
院內介面OpenAI / Gemini API下一步：治理
- 院內已具備：以 API 生成病歷草稿、報告與簡報的介面與流程入口。
- 接下來的瓶頸，通常不在「功能面」，而在「一致性、權責歸屬、可供稽核」。
- 若缺乏治理設計，常見後果是：每個人各自下 Prompt、各自潤飾，品質與風險皆難以追蹤。
生成式 AI 的主要風險，在於錯誤未必顯眼
先用病人安全的語言釐清風險，後續才談生產效率
ECRI 2026幻覺錯得很安靜
風險不是「偶爾答錯」，而是「看起來很合理」
- ECRI 將「醫療場域誤用 AI 聊天機器人」列為 2026 年健康科技風險首位，並指出其可能提供危險建議，語氣卻儼然像個可信的專家。
- 在臨床高壓情境下，流暢的文字容易降低人工覆核的警覺性，錯誤更不容易被及時發現。
來源：ECRI (2026). Misuse of AI chatbots tops annual list of health technology hazards.
將風險拆解為四類事件，治理才有著力點
事件化管理可通報可改版
品質事件
- 遺漏關鍵資訊
- 用詞或否定詞反轉
- 引用不存在或不符版本
流程事件
- 模型／介面中斷
- 資料來源同步失敗
- 版本更新造成格式漂移
資安事件
- Prompt Injection (提示詞注入)
- 知識庫污染
- 敏感資料傳輸或外洩
責任事件
- 誰覆核、誰簽章
- 錯誤如何回溯
- 事件如何分級處理
使用情境先分級，再談責任歸屬
紅綠燈分級責任分工先控風險
| 分級 | 可執行範疇 | 必備控管措施 |
|---|---|---|
| 綠燈 | 一般公文改寫、簡報大綱、會議摘要（非臨床決策） | 人工快速檢視；嚴禁敏感資料傳輸 |
| 黃燈 | 病歷草稿、出院摘要、衛教初稿 | RAG 必須附出處；缺漏即退回補正；逐段人工覆核 |
| 紅燈 | 任何直接影響臨床判斷的建議生成 | 嚴禁單獨依賴生成式 AI；僅限資料彙整與出處整理 |
分級的目的，是讓「誰負責覆核、什麼要留紀錄、哪裡要退回」在流程一開始就定義清楚。
治理不是口號，而是一套可供稽核的制度設計
NIST AI RMFNHS 指引高層決策
治理框架：將 GenAI 視為標準流程元件
- NIST 以「治理、盤點、衡量、管理」的邏輯，提供生成式 AI 的風險管理作法。
- NHS England 針對 AI scribe / ambient scribing 提供高層與董事會導入考量，重點放在責任、風險、資料處理與監測。
來源：NIST (2024). AI RMF: Generative AI Profile (AI 600-1).
NHS England (2025). Guidance on AI-enabled ambient scribing products.
在醫院，Prompt 不只是文字，而是該被管理的知識資產
知識資產負責人版本控管
| 資產類型 | 內容範例 | 最低治理要求 |
|---|---|---|
| A. 知識來源（RAG） | 院內規範、臨床路徑摘要、衛教、縮寫對照表 | 資料範疇＋版本號＋存取權限 |
| B. 工作方法（Skills） | 病歷草稿、交班摘要、報告摘要 | 固定欄位＋檢核點＋改版紀錄 |
| C. 輸出規格 | 格式模板、責任語句、用語規範 | 一致性檢核＋跨科共用規則 |
| D. 驗收題庫 | 常見情境題、錯誤樣態清單 | 改版務必重測＋通過門檻 |
重點不在於「誰比較會下指令」，而在於「資產可回溯、可驗收、可改版」。
RAG 是臨床文件的基本門檻：出處、版本、可追溯
RAG出處與版本查無資料即退回
RAG 的管理目的：確保每段結論皆可回溯至資料來源
- 先從「院內核可的資料庫」檢索段落，再要求模型僅根據檢索結果撰寫。
- 輸出務必附上出處（文件／段落／版本），以利後續稽核與回溯。
- 若查無來源，應明確標示找不到，並導向人工查核，切勿硬湊一段看似合理的文字。
RAG 的價值在於可追溯性，而非將文字修飾得更像真人。
RAG 上線先求受控：建立紮實的基本門檻
RAG v1最小可行治理先求精準
- 資料範疇先收斂：優先從院內規範、常用衛教、表單與縮寫表著手。
- 出處固定格式：每段文字皆須指出「哪份文件、哪一版、哪一段」。
- 失敗策略：查無資料即退回補正；必要時轉為「提供查核清單」。
- 權限與紀錄：誰查詢了什麼、使用了哪一版資料，必須留存紀錄。
- 改版節奏：資料庫更新須有版本號與變更說明，避免「默默異動」卻無人知情。
一致性與責任語句，絕不能碰運氣
後訓練/專屬模型一致性驗收題庫
單靠 RAG 不夠：一致性需仰賴專屬模型與可重測的驗收
- 院內文件有既定寫法、欄位、責任語句與跨科共用模板；僅靠「每次下 Prompt」難以維持一致。
- 後訓練（含指令微調）的重點，在於將院內規範內化為「預設行為」，並以固定測試集進行驗收。
- NEJM AI 指出，AI scribes 尚未成為穩定的生產力工具；其效益與風險需要更嚴謹的評估與治理。
來源：NEJM AI (2025). AI Scribes Are Not Productivity Tools (Yet).
利用 Skills 將任務標準化，讓品質可被管理
Claude Skills版本控管減少重工
Skills 的核心：將高頻率任務轉化為可維護的「資料包」
- 每個 Skill 皆有
SKILL.md，以 YAML frontmatter 描述用途與時機；需要時才載入完整指令與附件。 - 將「固定欄位、固定輸出、固定檢核、固定責任語句」封裝起來，降低每個人各自摸索的時間成本。
- 關鍵在於：具備版本號、負責人與改版紀錄，回饋才能有效累積。
Skills 不僅是工具，而是一套可追溯的作業標準
示範：病歷草稿 Skill必要欄位回報格式
Skill 結構（概念示意）
clinical-note-draft/ ├─ SKILL.md ├─ references/ │ ├─ note-style-guide.md │ └─ abbrev-list.md ├─ assets/ │ ├─ soap-template.md │ └─ discharge-summary-template.md └─ eval/ └─ regression-cases.json
臨床端易於理解的治理重點
- 必要欄位：主訴／病史／檢查／處置／評估／計畫；缺漏即回問。
- 引用規則：涉及醫療處置或衛教的段落，必須附上院內文件版本或病歷來源。
- 回報格式：錯誤類型＋嚴重度＋使用版本（Skill 版號／資料版號）。
Opal 的價值在於流程設計：責任節點、檢核點、回饋點
Google Opal流程化可稽核
利用 Opal 將「聊天」轉化為「多步驟標準流程」
- 入口：固定欄位與輸入範圍（避免遺漏與誤填）。
- 檢索：執行 RAG，優先備妥可引用的來源。
- 生成：嚴格依照欄位整理成草稿，避免自由發揮。
- 檢核：缺漏、矛盾、否定詞反轉等，先進行自動檢查。
- 退回補正：未通過即退回補資料，切勿強行輸出。
- 回報：一鍵通報錯誤類型與版本資訊，回饋至資產改版。
示範：將交班摘要轉為受控標準，而非自由生成
示範：交班摘要 mini app輸入把關出處把關
交班摘要（示範版）應具備何種規格？
- 輸入：病人辨識（依院內規範）、主要問題、處置、待追蹤檢查、用藥變更、風險提示。
- 輸出：固定段落結構＋關鍵風險標記（例如高風險用藥、未回報檢驗）。
- 附註：引用來源（院內規範版本／病歷段落）；查無資料則標示「需人工確認」。
- 回報：遺漏／用詞錯誤／引用不當／風險警示不足（含嚴重度與版本號）。
此設計的目的，是讓「錯誤能被看見、能被回報、能被修正」。
生成式 AI 亦可用於資料治理：縮短資料取得週期
資料治理營運效能不異動 HIS/EMR
突破 EMR 封閉性，建立敏捷式科研資料庫
- 常見瓶頸：資訊室排程冗長耗時；特殊欄位高度依賴廠商客製。
- 管理目標：在不異動核心系統的前提下，以較低成本、較短週期取得分析用資料，支援品質管理與回溯性研究。
此處探討的是「資料取得效率」與「風險隔離」，絕非繞過資安或法遵規範。
資料取得四步驟：先建立可用資料集，再評估擴大投資
前端擷取技術非侵入性可稽核
- 第一步：模擬臨床路徑（Data Capture）
依既定操作路徑開啟問題清單、用藥、檢驗等頁面，先行定義資料範圍。 - 第二步：留存資料流紀錄（Traffic Recording）
在授權與稽核前提下留存必要的通訊紀錄（例如 HAR），比螢幕截圖更乾淨、也更易處理。 - 第三步：AI 結構化重組（AI-Driven Structuring）
LLM 協助辨識欄位語意與資料結構；但仍需抽樣驗證與規則檢核。 - 第四步：建置小型科研資料庫（Database Generation）
以 SQL/ETL 將原始資料整理成標準表格（例如 SQLite/CSV），供 BI 或統計分析使用。
實務上建議由資訊單位執行，並將檔案存取、留存期限與去識別化納入治理範疇。
資料治理的核心，不在於更快抓取，而在於更快下決策
資料自主權風險隔離成本效益
管理意涵：縮短「從發想到驗證」的週期
- 資料自主權：小規模探索專案可在較短時間內取得初版資料集，減少等待排程。
- 降低系統風險：僅讀取前端已顯示資料，不觸碰核心資料庫的讀寫權限，降低效能與穩定性衝擊。
- 成本效益：減少對廠商客製報表的依賴，讓人力回歸分析與流程改善。
限制：仍需嚴守個資與院內資安規範；敏感資料不得外送，並需具備授權、紀錄與留存期限。
資料與資安紅線：優先釐清範圍、權限與回報機制
個資法規院內資安Prompt Injection
- 執行環境：建議限制在院內封閉網路與授權設備，落實加密、存取控管與操作紀錄。
- 個資與研究：醫療、健康檢查等屬敏感個資，蒐集、處理與利用須符合《個人資料保護法》及院內 IRB／法遵流程。
- 資安治理：參考衛福部資安防護指引，將資安角色、事件通報與第三方管理納入制度。
- 提示詞注入：OWASP 將 Prompt Injection 列為 LLM 主要風險之一；輸入與外部內容必須實施隔離與檢核。
來源：個人資料保護委員會籌備處：特種個人資料說明｜ 衛福部：基層醫療院所資安防護參考指引｜ OWASP GenAI：LLM01 Prompt Injection
四週內先完成三件事：可控、可回饋、可驗收
四週計畫從小做大可驗收
| 週次 | 重點工作 | 產出物 |
|---|---|---|
| 第 1 週 | 挑選 3 個高頻場景：病歷草稿／交班摘要／衛教初稿 | 技能清單＋負責人（Owner） |
| 第 2 週 | 建 RAG v1（先收斂資料範疇），定義出處格式與退回規則 | 知識庫 v1＋引用格式 |
| 第 3 週 | 將 3 個場景製成 Skills／流程（含檢核點與回報欄位） | Skills v1＋回報表單 |
| 第 4 週 | 建立驗收題庫與例行節奏（每週回報盤點、每月重跑測試） | 驗收題庫＋例會節奏 |
利用營運常規納入管控，效益方能累積
每週盤點每月回歸測試治理指標
讓改善形成節奏，才可能持續運作
- 每週：彙整回報（錯誤類型、嚴重度、發生情境），排定修正優先順序。
- 每月：重跑驗收題庫（回歸測試），確認改版是優化而非倒退。
- 季度：檢視資料範疇、權限與廠商／工具異動，更新風險評估與教育訓練。
建議指標：文件錯誤率（分類）、平均覆核時間、採用率、疑似病安事件數、外送/外洩零容忍事件。
將生成式 AI 轉化為受控流程，才具備談生產力的資格
先求做對再求快流程治理持續回饋
結語：生成式 AI 的價值在於「做正確」，而非僅是「求快」
- 先分級、再導入：綠燈擴大、黃燈受控、紅燈嚴禁黑箱作業。
- 先資產化、再擴散：RAG／Skills／模板／驗收題庫皆需有版本與負責人。
- 先回饋、再改版：臨床回報是品質精進的入口，而非額外負擔。
聯絡與更多內容：https://537sonic.cc/
參考來源（節錄）
參考來源以官方與指引為主最後瀏覽日：2026/02/02
- ECRI (2026). Misuse of AI chatbots tops annual list of health technology hazards.
- NHS England (2025). Guidance on the use of AI-enabled ambient scribing products in health and care settings.
- NIST (2024). AI RMF: Generative Artificial Intelligence Profile (AI 600-1).
- OWASP GenAI Security Project. LLM01: Prompt Injection.
- Google Developers. Opal (AI mini apps).
- Anthropic (2025). Equipping agents for the real world with Agent Skills.
- HL7 FHIR Bulk Data Access IG (Export).
- OHDSI. Standardized Data: The OMOP Common Data Model.
- NEJM AI (2025). AI Scribes Are Not Productivity Tools (Yet).
- 個人資料保護委員會籌備處：特種個人資料（含醫療、健康檢查）之限制與例外說明。
- 衛生福利部：基層醫療院所資安防護參考指引（含醫療機構資安治理建議）。
提示：簡報內引用為節錄；實務導入仍需依院內法遵、資安與病人安全流程辦理。