美國核准首個「病人對話 LLM」醫材：靠「介面不是決策者」的法律設計過關

美國食品藥物管理局（FDA）在 2025 年 12 月核准了史上第一個讓病人直接跟大型語言模型（LLM）對話、拿治療指示的醫材。過關的關鍵不是這個 LLM 有多聰明，是它的設計把「跟病人聊天」和「決定怎麼用藥」徹底切開，聊天的部分是 LLM，決定的部分是醫師預先設好的規則引擎。這條分界線，正是台灣年底要評估 AI 診斷工具給付時最缺的那把尺。

美國核准了什麼：一個「介面」，不是新物種

核准的是 UpDoc V1.0，一款協助第 2 型糖尿病成人管理胰島素的處方軟體醫材。FDA 於 2025 年 9 月 29 日收件、12 月 23 日核准，文號 K253281，審查僅花 85 天，比一般醫材審查明顯快。FDA 到 2025 年底已核准逾 1,451 個 AI／ML 醫材，2025 全年 295 件創新高，中位審查時間 142 天，UpDoc 的 85 天等於是快車道。UpDoc 公司自己一直到 2026 年 6 月 25 日才對外公開這件事，同一天宣布拿到一輪超額認購、金額 1,800 萬美元的種子輪，投資人包括美國糖尿病協會、藥廠禮來（Eli Lilly）與梅約診所（Mayo Clinic），前 FDA 局長 Robert Califf 擔任顧問，試點落地院所有克里夫蘭診所、Allegheny Health Network 與 UCSF Health。

這個許可拿到的方式，STAT News 的報導標題問得很直接：這個 LLM 到底是介面，還是決策者？報導指出，病人用語音或文字跟這個聊天介面互動，介面把結果回饋進醫師的電子病歷系統，整個裝置被歸進跟「把血糖數值換算成胰島素劑量建議」的計算器同一個監管類別，而 UpDoc 自己對這個問題答得含糊，這正是這次核准引發討論的核心。

三層架構怎麼分工：對話、資料、決策

UpDoc 的系統拆成三層。最外層是病人用的手機應用程式，病人用語音、文字或手動輸入血糖數值、飲食、症狀與服藥情形，中間是 LLM 驅動的對話服務，也就是 UpDoc Agent，最內層是執行醫師預設參數的臨床服務，做決定性的胰島素劑量計算。

關鍵限制寫在 FDA 的核准摘要裡：胰島素劑量指示由醫療提供者定義的治療參數算出來，不是模型生成的。LLM 那層只做資料蒐集、格式化，把醫師預先設好的指示傳給病人，不詮釋、不診斷症狀。碰到超出預定治療協議的症狀，系統直接鎖住，叫病人去找醫療協助，不會讓 LLM 自己臨場判斷該怎麼辦。

醫師端有自己的網頁入口，設定空腹血糖目標、最大可配置胰島素劑量、調整演算法，以及處理非緊急低血糖、高血糖與相關症狀的安全協議。病人跟 LLM 聊得再多，聊天內容能不能變成一個新的用藥指示，答案早在醫師端就被鎖死了。這跟我之前拆過的醫療 AI 合規守門引擎的核心設計原則一樣：查核類服務只回狀態，不替呼叫方做決策，這裡的 LLM 角色也是同一個邏輯，只是換了個場景。

為什麼套 d-Nav，不重新證明 LLM 能自己做決定

UpDoc 選的 510(k) 路徑，靠的是比對既有的前例產品，也就是預定用途相同就可以援引核准過的產品當比較基準，不用從零開始證明新產品安全有效。UpDoc 援引的前例是 Hygieia 的 d-Nav 系統，2019 年 2 月核准，同樣是胰島素劑量計算器，但 d-Nav 沒有對話介面，也沒有預定變更控制計畫（PCCP）；Hygieia 母公司已在 2024 年破產。UpDoc 主張自己跟 d-Nav 的「預定用途」相同，對話層只是操作介面的改變，不改變裝置本身受監管的核心功能。

這個主張成不成立，決定了 UpDoc 要面對的是一個窄很多的問題。它不用去證明「一個 LLM 驅動的系統能不能獨立、安全、有效地做臨床決策」，只要證明「加了對話介面之後，胰島素劑量計算的核心邏輯沒有變」。把要證明的題目縮小，是這次過關真正的巧思，不是模型能力的突破。

這個邊界在 PCCP 裡寫得更死。PCCP 允許的修改必須維持決定性的胰島素劑量邏輯，不能改變核心臨床決策，違反是零容忍，2025 年全年只有 10.2%、約 30 個 AI／ML 醫材申請案附了 PCCP，UpDoc 拿到手，代表它把「以後怎麼改」也先寫進了核准範圍，而不是先過關再說。這正好呼應我一直強調的一件事：可信度靠的是流程設計，不是模型多大。UpDoc 這次的護城河不是它的 LLM 比別人強，是它把決策權邊界寫進了合規文件，且未來要改也得先過這一關。

這道分界線的三個判準

Innolitics 拆解這次核准後，給其他想走同一條路的醫材開發商整理出一份判準，我把它濃縮成三條可操作的問題，順序不能倒：

判準	做到什麼
選單一受監管功能	只鎖定一個已有前例、範圍夠窄的臨床功能，例如藥物劑量計算，不要一次做一個通用醫療聊天機器人。
LLM 遠離最終決策權	對話層只做資料蒐集、格式化、傳遞醫師預設的指示，不讓模型生成新的臨床判斷。
明確的升級與鎖定路徑	碰到協議外的情況，系統要能明確鎖定並導向真人醫療，不能讓模型臨場自由發揮。

這套邏輯適用的情境包括藥物劑量計算機、精準給藥工具、標準化滴定工具、照護計畫遵從性代理；不適用的情境是開放式診斷、自主治療選擇，以及沒有固定升級標準的檢傷分類。分界很清楚：範圍夠窄、決策邏輯夠死、脫序時有硬性攔截，這條路才走得通。範圍一旦放寬到「讓 AI 自己判斷該怎麼辦」，就不是這條 510(k) 路徑能扛的了。

對照台灣：衛福部畫了邊界，但誰來驗證沒跨線

台灣其實已經有畫邊界的工具，只是還沒被用來回答「給付」這個問題。衛福部 2026 年 5 月 29 日函頒的《醫療機構應用生成式人工智慧指引》，列出六類風險，包括基礎模型偏差、輸出幻覺、使用者過度依賴導致臨床判斷退化，並要求機構指派主責單位辨識風險、導入前完成資安評估。這份指引畫出了「哪些風險要管」，但沒有規定「LLM 在系統裡能不能碰決策」這件事要怎麼證明。UpDoc 這個案例補的正是這一塊：不是靠指引條文一條一條核對，是靠架構設計本身把決策權鎖死，讓「有沒有跨線」變成可以稽核的技術事實，不是一句自我宣稱。

台灣在制度上也不是一片空白。食藥署（TFDA）2024 年 9 月 25 日公告了「應用人工智慧／機器學習技術之醫療器材軟體預定變更控制計畫（PCCP）申請要點暨撰寫說明指引」，概念上跟美國 FDA 的 PCCP 是同一件事：業者要先寫清楚以後打算怎麼改、改到哪個範圍算數，主管機關才准。台灣的醫材業者要走 UpDoc 這條路，工具其實已經在架上，缺的是像這個案例一樣，把「LLM 只碰資料層、決策層鎖給規則引擎」寫成可以拿去申請的具體設計。

更貼身的是給付端。健保署長石崇良曾公開表示，健保正評估把 AI 診斷工具（例如輔助判讀電腦斷層造影中的顱內出血）納入健保暫時性支付，健保自 2023 年起已給付用於手術麻醉高風險病人穩定血壓的 AI 輔助工具。這個評估的方向沒有變，但缺的正是 UpDoc 案例示範的那把尺：一套工具送審給付時，該先問的不是「準確率幾成」，是「這套工具裡如果有生成式 AI，它碰的是資料還是決策，誰來驗證這條線沒被跨過」。準確率是題目的後半段，決策權邊界才是前半段，先答對前半段，後面的效益評估才有意義。

我的期待：跟上的不是速度，是這套設計邏輯

我自己的期待很直接，期待台灣也能跟上。但跟上的重點不該是核准速度或產品數量，是這次 UpDoc 案例真正示範的那套法律設計邏輯：把「LLM 在系統裡到底碰不碰決策」寫成一條可以稽核的技術界線，而不是一句寫在行銷稿裡的自我宣稱。

健保署年底評估 AI 診斷工具給付，如果只問效益跟準確率，題目就解錯了一半。我先前寫過，一個會自動監督臨床行為的 AI agent，最先要釐清的是責任歸屬，不是它多會判斷，這裡的邏輯完全一樣：一套要申請給付的 AI 診斷工具，如果裡面有生成式 AI 的成分，該先交代的是它的決策權邊界畫在哪、超出邊界時系統會不會老實鎖住不亂猜，而不是先秀一個漂亮的準確率數字。這跟我拆過 OpenAI 自評 ChatGPT 健康答案贏過醫師時講的是同一件事：benchmark 測得到「答得像不像對」，測不到「落地有沒有驗證機制接住它」。UpDoc 的價值不在於它的模型測出了幾分，在於它把驗證機制寫進了醫材本身的架構。台灣如果要跟上，該抄的作業是這一份，不是核准的速度。

常見問題

UpDoc 算是「AI 醫師」嗎，可以取代醫師看診嗎？
不行。UpDoc 的胰島素劑量指示是由醫師預先設定的治療參數算出來的，LLM 只負責蒐集資料、格式化與傳遞指示，碰到協議外的症狀會直接鎖定並轉介真人醫療，設計上就不允許它自己做臨床判斷。

這跟直接問 ChatGPT 健康問題有什麼不同？
差在有沒有醫師預先設定的邊界跟監理審查。ChatGPT 回答健康問題是開放式的，OpenAI 自己的條款也寫明不用於疾病診斷或治療；UpDoc 是處方醫材，病人的治療計畫由醫師逐項設定，LLM 的角色被鎖在資料蒐集層，兩者的監理定位完全不同。

台灣的醫材業者有可能比照 UpDoc 這樣拿到許可嗎？
制度工具已經存在。食藥署 2024 年 9 月已公告 AI／機器學習醫材的 PCCP 申請要點，業者要做的是把「LLM 只碰資料、決策鎖給規則引擎」這套設計寫進申請文件，而不是等一個新法規類別出現才動作。

健保給付 AI 診斷工具跟這次 FDA 核准有直接關係嗎？
沒有直接的行政關係，但邏輯可以借鏡。健保署評估 AI 診斷工具納入暫時性支付時看的是成本效益，UpDoc 案例提供的是另一個該問的問題：如果工具裡有生成式 AI，它的決策權邊界有沒有寫清楚、能不能被稽核，這是給付審查現在還缺的一塊。