比翼生醫創投 投資暨臨床策略副總 沈信緯 

 

AI SaMD（人工智慧醫療軟體）要成功取證、通過 IEC 62304，最容易卡住的往往不是模型準確率不夠，而是團隊試圖把 AI 的非確定性硬塞進一套原本為確定性軟體設計的生命週期框架裡，最後用一堆看似完整、但根本不可維護的文件把自己拖垮。真正可落地的策略只有一個，把 AI 的非確定性模組包在確定性框架內，用最小但完整的設計管制與 Traceability（追溯）結構，讓審查單位看得懂風險，也讓團隊控得住成本與開發節奏。 

 

一、先定義 AI 的身分，它不是例外，它是 Software Item 

IEC 62304 不會因為你用了 AI 就改變遊戲規則，它關心的核心始終是兩件事：軟體安全分類（A、B、C）與生命週期活動。因此，在文件的第一段就要把 AI 模組放回 IEC 62304 的語言系統裡：AI 模組通常被當成軟體項（Software Item）或軟體模組，這意味著它一樣要走安全分類、設計控制、版本與更新管理。 

 

這個定位不是形式問題，而是審查邏輯問題。當你把 AI 定義成 Software Item，你在審查者眼中就不是在費力解釋神經網路，而是在說明如何把一個高風險黑箱模組放進整體系統治理，做到可驗證（Verifiable）、可追溯（Traceable）、可回滾（Rollbackable）。更現實的是，安全分類一旦被低估，後續所有文件與測試策略都會被強烈質疑。尤其是涉及診斷或治療決策的 AI，實務上常落在 Class B 或 Class C。分類不只是法規選項，它直接決定你未來測試證據的成本結構與上市時間表，也決定你在審查過程中會被追問到什麼深度。 

 

二、設計管制的 MVP，用一條最短路徑立起 DHF 骨架 
 

IEC 62304 的設計管制，實務上就是把軟體開發流程與風險控制綁成同一條線，這個最小骨架可以直接對應到 DHF（設計歷史檔案）的雛形。你要的不是一整座文件山，而是一條審查能走得通的路徑，並且每一步都能往下接到證據。最短路徑可以收斂成：SRS、SAD、SDS、實作、V&V。 

 

落地時務必抓住三個最容易被看懂的設計動作。審查者看的不是你寫了多少頁，而是你有沒有把不確定性收斂成可控的工程行為。 

 

第一個動作，SRS 先把 AI 需求寫成可驗證的系統行為
 

在系統需求規格（SRS）中，不要只寫 AI 會偵測病灶，而是要把 AI 的不確定性轉成系統可控的規則。你可以明確寫出：AI 模組輸出必須附帶置信度，只有在置信度達到預設門檻時才可被系統採納；當置信度低於門檻時，系統必須進入降級模式或要求人工覆核。重點不在門檻數字是 0.8 還是 0.75，而是你能把風險控制寫成可驗證、可測試的系統行為。這一步的真正目的，是把模型表現的不確定變成系統行為的確定，讓審查單位把風險控制理解成設計的一部分，而不是把風險丟給模型去賭。 

 

第二個動作，SAD 把 AI 抽象成黑箱服務，介面定義要嚴格
 

在軟體架構設計（SAD）層，不需要把模型結構攤開來講，但必須把它變成可治理的服務模組。你至少要把以下邊界條件講清楚，並且讓它可檢查、可被測試： 

 

第一，輸入是什麼，格式與允許範圍為何，包含影像或訊號的規格、缺漏值處理、例外情境
第二，前處理怎麼做，哪些步驟是固定規則，哪些步驟會影響模型輸出
第三，輸出長什麼樣，必須是結構化結果，並定義必要欄位，例如分類結果、定位結果、置信度、警示標記
第四，介面協議如何定義，包含 API 簽名、版本、相容性與回溯策略
第五，錯誤碼與超時機制怎麼處理，系統在失敗或延遲時要進入什麼狀態
第六，置信度門檻如何被系統消化，低置信度時的流程與畫面提示、紀錄與稽核軌跡 

 

審查者要看到的是你把黑箱的邊界鎖住了。即使模型不可完全解釋，你仍能用工程邊界條件讓系統在失效時保持可控，並且把風險控制落在系統層，而不是把責任推回給模型本身。 

 

第三個動作，SDS 是規範化，而不是逐行解釋
 

最小可行的軟體詳細設計（SDS），重點是把 AI 模組變成可審計的工程物件。你不需要逐行解釋神經網路，而是要建立可重現、可回溯的控制點，至少能回答「這個模型如何被定義、如何被建置、如何被重跑」。因此 SDS 至少應描述以下內容，並且用一致的版本控管串起來： 

 

第一，模型架構類型與其限制條件，例如是分類、偵測、分割，是否包含前後處理管線
第二，輸入輸出格式與前後處理規範，包含正規化、裁切、去噪、特徵萃取等固定規則
第三，訓練資料來源與標註品質控管，包含標註準則、標註者資格、互評一致性與資料排除規則
第四，資料分割策略，至少要說清楚 train、validation、test 的切分原則，以及外部資料或跨院資料的定位與使用方式
第五，訓練流程的框架層設計，包含關鍵超參數的版本化、隨機種子、訓練環境與依賴套件的可追溯 

 

你不是在寫學術論文，而是在建立工程治理。你要讓任何一次重跑都能回答一個冷酷的問題：這份結果是不是在同一套工程條件下可再現，並且可被稽核追溯。 

 

三、版本與變更管理，把 Retraining 當成軟體更新，你就會突然變得合規 
 

AI SaMD 最常見的死穴是模型迭代很快，但版本不可回溯。IEC 62304 的落地解法其實很直白：每一次訓練或重新訓練（Retraining），都視為一次軟體更新，必須有更新計畫與回滾策略。版本命名絕對不能只寫成 v1.2 這種內部標籤，而是要把模型版本與訓練資料集版本、超參數版本緊緊綁定在一起，讓你能在任何時刻回答「現在上市的是哪一個模型」「它是用哪一批資料訓練」「用了哪些超參數」「和上一版差在哪裡」。 

 

這段看似是工程管理，實際上是跨國合規的共同語言。美國 FDA 關心的是你能否說清楚上市版本、變更後版本的差異，以及風險控制是否仍成立。歐盟 MDR 等市場則更在意你是否把變更治理寫進 QMS，並且能在稽核時把版本與證據鏈一口氣拉出來。對公司治理與投資人而言，這也是未來投後稽核與併購盡職調查最常被抽查的一段，因為它決定了你的證據能不能被信任。 

 

四、V&V 的最小落地，非 AI 走單元測試，AI 走端到端與性能證據 
 

很多團隊把驗證與確認（V&V）寫得太過複雜，導致最後連自己都無法維護。最小可行的做法反而更貼近審查者思維，你可以把它拆成三層，讓證據鏈乾淨可讀。 

 

第一層，非 AI 模組採用標準單元測試，確保資料管線、介面、規則邏輯、UI 呈現與例外處理在每次更新後都可被自動驗證
第二層，AI 模組用端到端測試與性能指標測試，對應你宣稱的臨床用途，並且把性能指標綁回風險控制需求
第三層，系統層往上做整合測試與系統驗證，聚焦介面協定、邊界情境、降級流程與人工覆核流程是否確實被觸發，以及在臨床或模擬資料上是否能維持宣稱的感度、特異度或其他關鍵指標 

 

關鍵不在於你做了多少測試，而在於你是否能把 AI 的不確定性關進可量測的性能指標與可驗證的系統行為裡。當你在 SRS 定義了置信度門檻與降級模式，你在 V&V 就必須證明兩件事：高置信度時性能達標，低置信度時系統行為確實觸發覆核或降級，而且整合介面不會在邊界情境下失效。審查者要看到的是你用控制結構在管理風險，而不是靠宣稱在說服風險。 

 

五、Traceability Matrix 的 MVP 不是巨量交叉表，而是一條可審計的證據鏈 
 

Traceability 的最小可行定義只有一句話：從風險到證據要能走出一條線。你不需要耗費心力維護巨量且無效的全交叉表，只要確保每一條風險都能對應到至少一個需求、設計項、測試案例與證據文件即可。 

 

實務上強烈建議把 Traceability 主表當成唯一真相來源。主表最小欄位建議用條列方式清楚定義，並且在文件中固定用同一套命名規則： 

 

第一，Risk ID，對應 ISO 14971 風險條目
第二，Requirement ID，對應 SRS 系統需求
第三，Design Item ID，對應 SAD 或 SDS 的模組設計
第四，Test Case ID，對應 V&V 測試案例
第五，Evidence Location，指向報告或檔案位置，必須可被存取與稽核追溯 

 

控制邏輯的實戰範例可以用一句話串起來。以稀有病灶漏診風險為例，先建立風險條目 R-001；需求端寫出 SR-001，要求輸出置信度且低於門檻必須提示人工覆核；設計端用 D-AI-001 把 AI 輸出與系統覆核提醒邏輯落地；測試端用 TC-001 以外部稀有病灶資料集驗證高置信度時感度達標，低置信度樣本會被標示需人工覆核；最後把測試報告例如 AI_Test_Report_v1.0.pdf 作為證據位置掛回主表。只要這條線完整，你就擁有一個最小但可審計的控制結構。 

 

六、讓架構可維持，一主三分表，再加兩個 AI 特有控制點 
 

最容易被忽略的一環是日後的維護成本。真正成熟的最小落地實務，會用一個主表搭配三個分表，讓更新成本可控、追溯更乾淨： 

 

第一個分表，風險到需求，確保每條風險都被需求承接
第二個分表，需求到設計，確保每條需求都有可追溯的設計落點
第三個分表，需求到測試，確保每條需求都有對應測試與可用證據 

 

維護工具可以是 Excel，也可以是 ALM 工具如 Jira，但不論用什麼工具，SOP 必須明訂一件事：每次新增或修改 AI 模型時，必須同步更新起始點與 Traceability，否則你的文件會在下一次稽核或上市後變更時碎裂。 

 

此外，AI SaMD 幾乎一定會被追問兩大問題，你可以用最小擴充把質疑先封死，並讓它自然融入 Traceability 鏈條。 

 

第一個問題是黑箱與可解釋性。你不需要承諾完全可解釋，但你要能提出合理的解釋方法與使用場景，並把代表性病例的可視化或解釋輸出納入設計與測試證據中。實務上你可以在 SDS 中定義可解釋性方法與輸出形式，並在 Traceability 中增加一個 Explainability Method 欄位指向對應文件或報告。 

 

第二個問題是資料漂移與模型退化。你要把資料監控與退化檢測寫進 SRS，並對應到監控模組設計與上市後監控計畫，讓審查者看到你理解風險不是只存在於上市前，而是貫穿整個產品生命週期。你同樣可以在 Traceability 中增加一個 Drift Monitoring 或 Post-market Monitoring 的欄位，指向設計與計畫文件。 

 

這兩個控制點不是為了炫技，而是為了讓審查者相信：你深刻理解 AI 風險貫穿整個生命週期，並且具備用工程治理把它管住的能力。 

 

結語，VC 觀點 
 

在生醫創投的盡職調查視角中，我們會把團隊在 IEC 62304 的落地能力視為一種稀缺的商業競爭力，而不僅僅是合規成本。原因很現實，在數位醫療與 Biotech 賽道上，真正能快速上市且長期存活下來的團隊，往往不是最會講模型架構的團隊，而是最會做工程治理的團隊。

你能不能把 AI 清楚定義成 Software Item，能不能把不確定性轉成可驗證的系統行為，能不能把 Retraining 穩穩治理成可回溯的軟體更新，能不能用最小 Traceability 把風險到證據的鏈條釘死，這些都直接決定了你的開發節奏是否可預測，臨床與法規證據是否能順利推疊，以及未來在併購退場的盡職調查面前，能不能用一句話精準交代這份漂亮數據到底是哪一個模型版本跑出來的。

對投資人而言，這套最小可行架構買到的從來不是文件，而是確定性，是把監管風險與交付風險收斂成可管理的工程風險，最終讓時間與資金的消耗曲線變得高度可控。這，才是 AI SaMD 估值能穩穩站住的底層邏輯。 

 

若欲進一步了解更多資訊，歡迎寄信至Joseph.Shen@behealthventures.com