EN 18286:2026 與歐盟AI Act的實務考量初探（八之七）

（續前篇）

醫療器材品質管理系統整合、風險治理及全生命週期合規初探

本文以網路搜集來的介紹文件及概要說明為參考基礎，並利用公開法規資料補充及核對，以人工智慧協助進行個人判斷，完成之介紹性文章，僅供一般資訊與個人持續教育用途，不構成法律意見、資訊服務或對任何產品符合特定法律之保證。引用請註明出處。文中如有引用疏漏，歡迎聯繫補正。
CC BY-NC-ND。非供AI模型訓練。

10.2 A product-level evidence index｜產品層級證據索引

對每個 AI 醫療器材系統，建議建立一份產品層級的證據索引，將適用要求、責任部門、程序及客觀證據連結起來。

證據領域	主要文件或紀錄	應回答的問題
法規適用性	法規清單、分類及適用性分析	為什麼適用或不適用某項要求？
預期用途	產品規格、使用者需求及限制	系統被設計用來做什麼、不做什麼？
風險管理	風險管理計畫、分析及報告	如何識別、評估與控制風險？
資料治理	資料來源、標注、處理及版本紀錄	資料為何適用於預期用途？
模型及軟體	版本識別、架構、組態及變更紀錄	哪個版本經過哪些活動？
查證與確效	測試計畫、報告及臨床或性能證據	如何證明系統符合要求？
供應鏈	供應商評估、規格及變更通知	外部資源如何受到控制？
上市後監督	監督計畫、指標、調查及事件紀錄	如何識別並處理上市後風險？
矯正措施	問題原因、處置及有效性紀錄	問題是否已被控制並防止再發？

此索引是一項建議的文件管理工具，而非標準指定的唯一格式。

企業可依既有文件管理系統、產品架構及適用法規，選擇採用文件矩陣、資料庫或其他受控方式。

10.3 Traceability must work in both directions｜追溯性應能雙向運作

完整的追溯性不只是從法規要求找到相關文件，也應能從一份測試報告或一個風險控制措施，反向找到它所支援的法規要求及產品需求。例如：

Legal Requirement«Procedure«Risk Control«Test Evidence«Product Version  法規  «  程序   «  風險控制 « 測試證據 «  產品版本

 

這樣的結構可以協助企業回答稽核中常見的問題：

• 這項測試為什麼需要執行？
• 它支援哪一項產品或法規要求？
• 測試失敗時，企業如何決定是否放行？
• 哪個產品版本採用了這項控制？
• 產品變更後，原有證據是否仍然適用？
• 上市後發現新風險時，應更新哪些文件？

這種雙向追溯性也有助於避免重複測試及文件矛盾，因為企業可以辨識哪些證據已經有效支援多項要求，以及哪些部分仍存在缺口。

11. Gap analysis and implementation roadmap｜差距分析與實施路線圖

11.1 Start with applicability, not documentation｜先判斷適用性，再開始補文件

企業在導入 EN 18286 時，第一步應是確定標準適用範圍與法規義務，而不是立即要求每個部門提交一份新的程序文件。原因很簡單：如果企業尚未確認哪些 AI 系統屬於適用範圍，就無法合理決定品質管理系統的邊界、所需控制措施及證據深度。

建議依序完成以下工作：

1. 建立 AI 系統及相關產品的清單。
2. 判定企業在每個系統中的法律角色。
3. 依 AI Act 分類規則及相關附件分析適用性。
4. 確認 MDR、IVDR 及其他適用法規的相互作用關係及影響程度。
5. 建立EN 18286 要求與現有品質程序的對照矩陣。
6. 識別控制措施及證據的缺口。
7. 依風險、法規時程及產品上市計畫安排改進優先順序。

11.2 The difference between a document gap and a control gap｜文件缺口與控制缺口的差別

差距分析不能只檢查「有沒有文件」。應至少區分三種情況。

第一類：文件已存在，控制措施充分。

例如：企業已有受控的軟體變更程序，而且程序已涵蓋模型版本、資料版本、風險影響評估及適用的法規判定。這種情況可能只需要確認程序的適用性與證據完整性。

第二類：文件已存在，但控制措施不足。

例如：企業已有一般軟體變更程序，但沒有評估模型更新對患者族群性能或風險的影響。這不是單純的文件格式問題，而是實質控制缺口。

第三類：控制措施已執行，但缺乏適當紀錄。

例如：工程師每次更新模型都會執行測試，但沒有明確的接受準則、核准紀錄或版本追溯。這種情況可能同時涉及文件化及治理問題。

三類缺口需要不同的改進方式，不能一律以「補寫程序」處理。

11.3 A phased implementation plan｜分階段實施計畫

以下是一個可供企業規劃的示例。各階段所需時間取決於企業規模、產品數量、既有 QMS 成熟度及法規適用性。

階段	主要活動	預期產出
Phase 1：適用性分析	產品盤點、角色判定、AI 分類及法規分析	適用性判定紀錄及產品清單
Phase 2：差距分析	對照EN 18286、ISO 13485、AI Act及既有程序	差距矩陣及改進計畫
Phase 3：系統設計	明確權責、程序、品質目標及證據要求	核准的QMS改進方案
Phase 4：產品控制整合	資料治理、模型管理、風險控制、變更及上市後監督	產品層級控制措施及文件
Phase 5：實施與試運作	訓練、執行程序、收集紀錄及處理問題	實施證據及改進紀錄
Phase 6：有效性評估	內部稽核、管理審查、矯正措施及必要的外部評估	系統有效性評估及後續措施

11.4 Prioritisation should be risk-based｜改進優先順序應以風險為基礎

企業不應只按照文件缺口的數量安排工作。

更合理的優先順序應考慮：

• 法規義務的適用時程；
• 產品預期用途及可能造成的傷害；
• 現有控制措施的不足程度；
• 產品是否即將上市或進行重大變更；
• 資料、模型及供應鏈的不確定性；
• 是否缺少關鍵查證或確效證據；
• 是否已出現上市後風險資訊或警示。

例如：如果某個產品缺少文件格式統一規則，但主要風險控制及產品證據完整，這可能不是最優先的問題。

反之，如果產品無法證明模型在預期患者族群中具備足夠性能，或沒有控制高風險模型更新的程序，就應優先處理實質性的產品及法規風險。

（見續篇）