本文重點
- 衛福部生成式 AI 指引是強制性規範嗎？
- 《醫療機構應用生成式人工智慧指引》目前定位為行政指導，非法律強制。但其引用的具體法律（醫師法、個資法、醫療法等）是法律義務。守門引擎的合規設計需同時對應指引與底層法條，不能只看指引的文字，也不能因為指引不是「法律」就不認真看待。
- FHIR 合規和 AI 合規是兩套不同的事嗎？
- 有重疊，但角度不同。FHIR 處理的是資料格式與互通性，決定資料怎麼在系統間流動；AI 合規處理的是 AI 行為邊界與責任歸屬，決定 AI 在這些資料上能做什麼。兩套規範在系統整合時都需要考量，它們不是替代關係，而是不同層次的要求。
- 幻覺三子型的偵測，有沒有優先順序建議？
- 建議從文獻捏造開始，因為 PubMed 和 Crossref 免費、技術可行性高、假陽性率低。藥物交互和臨床指引因資料來源限制，先定位為警告提示搭配人工複核，等取得資料授權或資料品質提升後再考慮升級為自動判 fail。
很多人在討論醫療 AI 合規的時候，第一個想到的是「去找對的指引來讀」。但這裡要先問一個更前面的問題：讀完指引之後，怎麼把它變成可執行、可測試、可重用的工程系統？
從頭到尾把一套合規守門引擎建起來，真正學到的東西，不在指引條文裡。它在法源的結構、資料可得性的限制、架構的解耦設計，以及一個常常被忽略的判斷原則——守門類服務，到底該不該替呼叫方決策？
這篇筆記拆解三個面向：法規面的心得、工程面的設計選擇，以及可以遷移到其他領域的通則。
一、合規規則的真實結構：一條規則，多部法源
在台灣，醫療機構導入生成式 AI 的主軸規範，是衛生福利部於民國 115 年 5 月 29 日頒布的《醫療機構應用生成式人工智慧指引》（衛部醫字第 1151663164 號函頒）。但合規從來不是只看一部指引的事。
一條合規規則的背後，通常同時對應多部法律。指引是主幹，但從揭露義務到個資保護，每道關卡都交疊著醫師法、個資法、醫療法等具體法條——而不是只看指引的文字。
以一套守門引擎常見的五道關卡為例，它們的法源不是單一指引，而是多法交叉：
| 關卡 | 核心法源 |
|---|---|
| 揭露與免責（disclosure） | 指引三(三)4(1)；病人自主權利法 §4/§5；行政院生成式 AI 參考指引 |
| 來源標註（source_attribution） | 指引三(一)2(2)、三(三)1(2)；醫療法 §67；電子病歷辦法 §11、§11-1、§12 |
| 越權診斷（scope_boundary） | 醫師法 §11；護理人員法 §24；醫療器材管理法 §3（SaMD 定義） |
| 個資外洩（pii） | 個人資料保護法 §6（特種個資：病歷、醫療、基因、健康檢查）；醫療法 §72；電子病歷辦法 §3-5 |
| 幻覺內容（hallucination） | 指引二(一)3（三子型）；TFDA AI 醫材技術指引（臨床與分析效能驗證） |
這個結構有一個工程上的直接意涵：規則的 citation 欄位是陣列，不是單一字串。換領域（換成長照、健保審核、藥局諮詢）時，換的是 params 和 citation 清單，不是重寫規則邏輯。引擎與規則庫對領域知識是中立的。
遵循時機也有一個容易誤解的地方：法規或指引一經公告即納入遵循，不因主管機關未完成掛牌或施行日未定而緩。守門員採 proactive 立場，純草案或預告才列「監看」，不納入強制關卡。
衛生福利部《醫療機構應用生成式人工智慧指引》要求醫療機構在使用生成式 AI 時，必須明確告知使用者 AI 的介入性質，並保障病人對 AI 輔助決策的知情權與拒絕權。（衛部醫字第 1151663164 號函頒，民國 115 年 5 月 29 日）
二、幻覺三子型：真正的瓶頸在授權，不在模型能力
幻覺（hallucination）是醫療 AI 最常被提到的風險，但「幻覺查核」這件事的難度，各子型之間差距極大。把三種子型當作同一個問題來處理，是設計上最常見的錯誤。
幻覺可以分為三個子型，它們的查核難度與可用資料源差距很大。關鍵是依資料可得性分層定位，而不是用同一套機制一刀切。
子型一：文獻捏造（fictitious citations）
可用免費資料源：PubMed E-utilities 與 Crossref，皆可免費呼叫。交叉比對能有效偵測假 DOI 或捏造文獻；台灣無 DOI 的中文期刊需人工確認。技術可行性：高。這個子型可以實現自動判 fail。
子型二：藥物交互錯誤（drug-drug interaction errors）
NLM 曾提供免費的 DDI API，但已於 2024 年停用。目前可用的免費資源包含 openFDA 仿單（自由文字，非結構化）與 RxNorm（僅藥名正規化），結構化的權威資料庫（如 DrugBank）需付費。中文藥名到成分的對應，又是另一個工程難點。現實定位：提示為主、偏 warning，不自動判 fail。
子型三：臨床指引不符（clinical guideline violations）
台灣各學會提供免費 PDF（糖尿病學會、心臟學會等），但「免費下載」和「可用於 AI 系統」是兩回事。NICE 明文禁止 AI 訓練用途，WHO 指引限非商業使用。這裡的瓶頸在授權許可，技術上不難，但法律上無法確認前不能自動判定違規。定位：輔助提示，搭配人工複核。
| 幻覺子型 | 可用免費資料源 | 可自動判定？ | 務實定位 |
|---|---|---|---|
| 文獻捏造 | PubMed, Crossref（均免費） | ✅ 可行 | 自動偵測，可判 fail |
| 藥物交互 | openFDA 仿單（非結構化）、RxNorm | ⚠️ 部分 | 警告提示，人工複核 |
| 臨床指引不符 | 學會 PDF（授權未明） | ❌ 授權限制 | 輔助提示，人工複核 |
這個差距說明一件事：醫療幻覺查核的瓶頸常是授權與資料可得性，不是模型能力。系統的技術定位必須隨資料成熟度調整——來源清楚、授權完整，可以直接判 fail；授權未明或假陽性率高的領域，降為 warning 交人工複核，是務實的選擇，不是妥協。
三、隱私管線設計：去識別化先行，失敗就 fail-closed
醫療內容受個人資料保護法第 6 條（特種個資：病歷、醫療、基因、健康檢查）與醫療法第 72 條（病情保密）的雙重規範。這個法律事實直接決定隱私管線的設計方向：個資處理不是某些關卡的選項，而是整條管線的前提。
去識別化必須是管線的第一道步驟，不是最後一道保險。原值（病患姓名、身分證字號、病歷號）不應進入任何後續規則或 LLM 處理環節；evidence 欄位只回遮罩座標，不回原值。
幾個設計決策值得特別注意：
原值永不落地：稽核紀錄只存 HMAC 雜湊與遮罩摘要，不存原始個資。這確保稽核本身不會製造新的外洩風險。
fail-closed 原則：去識別化失敗時，整個請求的全部關卡都回 error，不繼續往下跑。選擇錯抓（false positive）而不是漏抓——格式觸發即標記，不靠校驗碼確認。「通用長數字」這類容易漏的樣式必須納入偵測範圍，處理中文文本時也要排除 CJK 標點被誤吞的情況。
多租戶稽核：每筆請求必須綁 caller_id 或 tenant_id，稽核紀錄才能歸戶、才能追責。嚴禁跨租戶的任何資料存取或結果共享，這不應只靠應用層過濾，要在資料庫層做存取控制。
FHIR（Fast Healthcare Interoperability Resources，醫療資訊快速交換標準）的設計原則之一，是讓 Patient 資源的存取授權能在 API 層明確管控，確保跨系統資料交換時，身分識別資訊不會在授權範圍外流動。（HL7 International，Overview – FHIR v5.0.0）
四、架構解耦：規則庫與 ruleset 分離
一套好的合規引擎，不應該為每個醫療應用場景分別寫一套規則。問診 AI、藥局諮詢、護理記錄輔助，這些場景的合規要求有交集也有差異。把共用部分拆出來，才能讓整個系統隨著法規更新而靈活調整。
兩層模型是核心：「規則庫」負責領域中立的檢查邏輯，「ruleset」是場景綁定的設定組合。換領域等於新增一份 ruleset，引擎與規則庫本身不動。
規則庫（領域中立）：
每條規則是一個可重用的檢查器，如 disclosure、pii、scope_boundary、hallucination。規則本身不含任何醫療領域知識，只定義「怎麼查」的邏輯。disclosure 和 pii 這類規則多個領域都適用，只換 params 和 citation，不重寫邏輯。
ruleset（場景綁定）：
ruleset 是「規則萃取」的離線產出，指定這個場景用哪些規則、各規則的法源 citation（陣列）、適用門檻、以及 prompt 脈絡。disclosure 在問診場景和藥局場景的 citation 清單不同，但規則邏輯相同。
回報模型的關鍵設計：
引擎只回各關卡的狀態（pass / fail / warning / error），不做整體放行判斷。呼叫方逐關卡判讀，自行決定「三個 warning 在這個業務情境下算不算可放行」。把判斷權交給呼叫方，服務只負責查核，是守門類服務最重要的設計決策——也是最常被省略的那一步。
合規規則的覆蓋時機也需要在 ruleset 層明確定義：法規一經公告即納入，純草案或預告列監看不納強制，這個政策本身也應該是 ruleset 設定的一部分，不靠工程師記憶。
五、讓依賴外部 LLM 的系統可測：Null Provider 模式
醫療合規引擎通常混合了兩類檢查：規則型（確定性執行）和 LLM 型（需要真實 API）。這個混合設計帶來一個測試難題：CI 環境沒有 API 金鑰，但整個引擎的行為必須可驗證、可重現。
Provider 介面隔離加上 NullProvider 是標準解法。規則層只知道注入的 LlmProvider 介面，不直接呼叫 API。CI 環境注入 NullProvider，讓整個測試套件不需真實網路即可決定性重現。
設計有三個具體層次：
Provider 介面隔離：LlmProvider 和 GroundingProvider 作為介面注入，測試用 Mock 或 Null 替換。規則邏輯的單元測試完全獨立於外部服務，不需要 stub 任何 HTTP 呼叫。測試一律 mock fetch，外呼用 Workers fetch、金鑰用 secret，不讓測試環境直接存取外部 API。
降級政策分類：這是最容易設計錯的地方。LLM 不可用時的行為，要在設計時就分清楚兩類：
rule+llm類型（有規則基線的關卡）：LLM 失敗時退回規則基線執行，不把整關 error。llm-only類型（沒有規則基線的關卡）：LLM 失敗時整關 error，不猜，不樂觀放行。
keyless 決定性：CI 無金鑰時，rule+llm 關卡退回規則基線，llm-only 關卡回 error。整個測試套件的行為是確定的、可重現的——這是讓「依賴外部 LLM 的系統」能做到真正可測的核心招式。
解析外部識別碼時也要防「貪婪吞標點」這類假陽性：DOI 後接全形括號或句號，真 DOI 被誤判為造假。這是最糟方向的 bug，在 CI 裡會穩定重現，上線才發現是另一種代價。
六、守門類服務的根本設計姿態
醫療 AI 守門引擎的設計，要從一個根本問題開始想：這個服務的角色是「查核者」，還是「決策者」？
守門類服務只回狀態，不替呼叫方決策。error 和 pass 嚴格分離，呼叫方根據業務情境自行判斷各關卡結果的組合意義。這不只是設計選擇，也是責任邊界的劃定。
這個設計姿態對應了一個醫療場景的現實：漏判 fail 的代價，遠高於誤判 fail 的代價。守門引擎在缺乏脈絡時應 fail-safe 偏嚴，重召回率，偏向給出 warning 讓人工複核，而不是偷懶地放行。
另一個常被忽略的細節：稽核的副作用不應拖垮主回應。稽核寫入（計數、紀錄）是 best-effort 行為——無論稽核成功與否，已計算完成的 200 回應不應因此變成 500。這需要用 waitUntil 或 inline 雙路徑確保，連外部資料庫抖動都要 fail-open，不影響主要關卡結果。
可執行步驟
評估一套醫療 AI 守門引擎的 7 個檢查項
- 五道關卡（揭露、來源標註、越權診斷、個資、幻覺）是否都有對應的多法源 citation 陣列？
- 幻覺子型的查核定位是否依資料可得性分層定義？（文獻可判 fail，藥物與指引先 warning）
- 去識別化是否在所有關卡之前執行？失敗時是否整請求 fail-closed？
- 規則庫與 ruleset 是否解耦？換場景時只改 ruleset，引擎不動？
- LLM Provider 是否可注入？CI 環境能否 keyless 決定性執行？
- 降級政策是否明確分「有規則基線可退」vs「無基線只能 error」？
- 稽核副作用是否獨立於主回應？200 不會因稽核失敗而變 500？
七、可遷移到其他領域的通則
問題如果沒定義對，後面的方法就會錯。從守門引擎的建構過程中，有幾條原則在不同領域都成立。
適用，但前提是先找清楚「合規的真正瓶頸在哪裡」。不同領域的瓶頸不同——有時是授權，有時是資料品質，有時是法源本身的不確定性。瓶頸決定技術定位，定位定了，架構設計才有方向。
重點摘要
可遷移的六條通則
- 守門類服務只回狀態，不替呼叫方決策：
error與pass嚴格分離，判斷權留給呼叫方。 - 規則機制與領域設定解耦：靠 params 和 citation 陣列換領域，不重寫引擎。
- 隱私敏感系統：去識別化先行、原值不落地、fail-closed、寧可錯抓不漏抓。
- 依賴外部 LLM 的系統，用 Null/Mock Provider 達成 keyless 決定性測試；明確分「有規則基線可退」vs「無基線只能 error」，不確定時絕不回 pass。
- best-effort 副作用（稽核、計數）永不拖垮主回應：fail-open，200 不變 500。
- 合規領域的真正瓶頸常是授權與資料可得性：資料成熟可判 fail，不成熟先 warning + 人工複核；技術定位要隨資料成熟度調整，不能一開始就設計得太死。
衛福部生成式 AI 指引是強制性規範嗎？
《醫療機構應用生成式人工智慧指引》目前定位為行政指導，非法律強制。但其引用的具體法律（醫師法、個資法、醫療法等）是法律義務。守門引擎的合規設計需同時對應指引與底層法條，不能只看指引的文字，也不能因為指引不是「法律」就不認真看待。
FHIR 合規和 AI 合規是兩套不同的事嗎？
有重疊，但角度不同。FHIR 處理的是資料格式與互通性，決定資料怎麼在系統間流動；AI 合規處理的是 AI 行為邊界與責任歸屬，決定 AI 在這些資料上能做什麼。兩套規範在系統整合時都需要考量，它們不是替代關係，而是不同層次的要求。
幻覺三子型的偵測，有沒有優先順序建議？
建議從文獻捏造開始，因為 PubMed 和 Crossref 免費、技術可行性高、假陽性率低。藥物交互和臨床指引因資料來源限制，先定位為警告提示搭配人工複核，等取得資料授權或資料品質提升後再考慮升級為自動判 fail。
多租戶架構下，不同醫療機構的稽核紀錄要怎麼隔離？
每筆請求綁定 caller_id 或 tenant_id，稽核只存 HMAC 雜湊與遮罩摘要（不存原值），並在資料庫層做 tenant 層級的存取控制。跨租戶的查詢或比較操作在設計上就應排除，不依賴應用層過濾——應用層的過濾太脆弱，一個 bug 就可能漏。
守門引擎回報的 error 和 fail 有什麼差別？
`fail` 表示規則有足夠依據判定違規；`error` 表示查核過程本身失敗（LLM 不可用、外部資料源逾時、去識別化失敗等），不代表通過，也不代表違規。呼叫方需要明確處理這兩種狀態，不能把 error 當作隱性 pass，否則會在 LLM API 不穩定的時候默默放行所有請求。
About the Author
