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

（續前篇）

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

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

6. Data governance and model lifecycle｜資料治理與模型生命週期管理

6.1 Data governance is a regulatory control, not merely a data-science activity｜資料治理不只是資料科學工作

在AI醫療器材中，資料品質會影響模型性能，也會影響風險評估、臨床適用性及上市後的可靠性。

AI Act第10條針對特定高風險AI系統的訓練、查證及測試資料集，提出資料治理與管理要求。其內容涉及資料選擇、來源、收集程序、處理、標注、清理、更新、聚合，以及偏差識別與處理等事項。實際適用範圍仍應依條文及具體系統判定。

EN 18286 的管理架構則有助於把資料相關活動納入品質管理系統，使資料科學團隊的工作可以與設計控制、風險管理、版本控制及產品文件相互連結。

醫療器材企業應避免將資料管理簡化為「資料已經匿名化」或「資料來自可信任的醫院」兩個判斷。

資料來源合法、隱私保護充分，與資料適合用於特定醫療用途，是不同問題。即使資料來源可靠，資料集仍可能存在族群代表性不足、標注不一致、設備分布偏差或特定臨床情境缺失等問題。

6.2 The data lifecycle｜資料生命週期

可將資料管理分成以下階段：

1. 定義資料要求（Data requirements）

界定資料應代表的患者族群、臨床情境、輸入條件及預期用途。

2. 資料取得（Data acquisition）

記錄資料來源、取得方式、權利與限制，以及適用的隱私及資料保護要求。

3. 資料清理與轉換（Data preparation）

控制去識別化、清理、轉換、排除、標準化及其他處理操作，並評估可能造成的偏差。

4. 標注與參考標準（Annotation and reference standards）

定義標注規則、專業資格、爭議處理及品質檢查方法。

5. 資料集劃分（Dataset partitioning）

依適當方法建立訓練、查證及測試資料集，並控制資料洩漏及不當重複。

6. 模型訓練及評估（Training and evaluation）

記錄資料集版本、程式、參數、模型版本及相關實驗結果。

7. 保存、更新及退役（Retention, updates and retirement）

定義資料保存、存取、更新、封存及銷毀等規則，並保留適當的追溯資訊。

這些階段不是所有 AI 系統都必須採用完全相同的技術流程。企業應依系統特性及適用要求，決定控制深度與證據形式。

6.3 Data provenance and traceability｜資料來源與追溯性

對醫療器材 AI 而言，資料追溯性至少應能回答：

• 模型使用了哪些資料集？
• 資料集經過哪些清理、標注或轉換？
• 哪一個資料集版本用於特定模型的訓練與查證？
• 哪些品質問題曾被發現，如何處理？
• 資料集的變更是否影響模型性能或風險評估？
• 是否能重建特定版本模型的開發及評估過程？

追溯性不一定意味著必須保存所有原始資料的無限期副本。保存方式仍須考慮適用法規、個人資料保護、資訊安全、智慧財產權及合理的保存期限。

但企業應避免發生一種情況：產品上市後出現重大性能問題，卻無法確認受影響的模型究竟使用了哪一個資料集版本，也無法重建相關確證結果。

6.4 Dataset quality versus model quality｜資料集品質與模型品質

資料品質與模型性能密切相關，但不能直接畫上等號。

高品質資料集可以改進模型開發的基礎，卻不能保證模型一定適合預期用途。模型架構、訓練方法、標注定義、評估設計及部署環境，都可能影響最終結果。

同樣地，模型在特定測試集上的良好表現，也不能反向證明資料治理程序已經充分。

因此，企業應分別建立：

1. 資料集品質的接受準則；
2. 資料處理與標注程序的控制；
3. 模型性能與適用性的接受準則；
4. 資料或模型變更的衝擊評鑑；
5. 上市後發現資料分布變更時的處理程序。

這些程序可以共用部分文件管理機制，但必須清楚區分其評估對象及判定依據。

6.5 Third-party models and data suppliers｜第三方模型與資料供應商

AI 醫療器材企業越來越常使用外部資料、預訓練模型、雲端服務、第三方軟體元件或外部 AI 平台。此等資源可以縮短開發時間，但也會引入額外的品質及法規風險。

供應商評估不應只依公司規模、品牌聲譽或是否持有某項驗證進行。企業還應分析供應項目對產品功能、風險及法規符合性的影響。

例如：某第三方模型可能是醫療影像分析產品的核心推論引擎；另一個第三方服務則可能只負責非關鍵的資料格式轉換。兩者對產品安全及符合性的影響程度不同，因此所需的控制深度也不應完全相同。

實務上，可以依風險建立供應商控制矩陣：

供應項目	主要風險	建議控制重點
核心預訓練模型	性能限制、訓練資料不透明、更新失控	技術評估、使用限制、版本識別、獨立查證及變更通知
醫療資料供應商	來源不明、代表性不足、權利限制	來源追溯、資料品質、合法性及用途限制
雲端運算服務	可用性、資安、資料存取及服務中斷	服務控制、存取權限、持續性安排及安全要求
第三方軟體元件	弱點、相依性及相容性問題	元件清單、弱點管理、相容性測試及更新控制
外部標注服務	標注品質不一致、專業能力不足	標注規範、資格要求、品質抽查及爭議處理

此處僅示例一種風險導向的實施建議，不代表該標準對每個種類的供應商都要求相同的既定評估表格。

7. Software, model changes and configuration management｜軟體、模型變更與組態管理

7.1 Why model updates require formal control｜為什麼模型更新必須受到正式控制？

一般軟體的更新可能包括修正程式錯誤、改進介面、提高效能或修補資安弱點。

AI 系統的更新則可能同時涉及程式、模型權重、訓練資料、推論設定、預處理程序或外部服務。這些變更即使不改變產品名稱，也可能改變模型輸出及風險特徵。

因此，企業不能把「技術上可以更新」等同於「法規上可以自由更新」。

對醫療器材而言，變更控制至少應包含三個相互關聯的判斷。

第一，技術衝擊評估（Technical impact assessment）。

           變更是否影響功能、性能、輸入限制、輸出解釋、介面、軟體安全性或相容性？

第二，風險衝擊評估（Risk impact assessment）。

           變更是否引入新的危害、改變既有風險、降低風險控制有效性，或影響剩餘風險的可接受性？

第三，法規衝擊評估（Regulatory impact assessment）。

           變更是否影響預期用途、產品分類、技術文件、符合性評估或 AI Act 下的適用義務？是否構成相關法規所定義的重大修改？

三者需要互相支援，但不能互相取代。

7.2 A model-change decision matrix｜模型變更判定矩陣

以下為企業可以採用的初步分類方式。它不是 EN 18286 或 MDR 所規定的正式分類表，亦不能取代個別法規的判定。

變更類型	可能影響	評估重點
修正非關鍵介面錯誤	操作流程或使用者理解	回歸測試、可用性及文件影響
更新第三方函式庫	相容性、弱點及執行行為	軟體相依性、資安與回歸測試
更新模型權重	分類結果、錯誤分布及性能	模型性能、風險分析及適用性
更換訓練資料集	代表性、偏差及泛化能力	資料品質、重新訓練與查證
擴大適用患者族群	預期用途與臨床適用性	臨床或性能證據、風險及法規影響
允許部署後持續學習	輸出可能隨時間變化	變更邊界、預設變更確證、監督與回復機制

每次變更的評估深度應與其影響程度相稱。

某項變更即使不構成法規上的重大修改，仍可能需要進行技術測試、風險重新評鑪或更新技術文件。反之，企業也不應只因模型權重改變，就在未分析實際影響之前，直接認定所有變更均構成同一法律類別。

7.3 Continuous-learning AI systems｜持續學習型 AI 系統

持續學習型 AI 系統尤其需要明確的變更治理。

企業應預先定義允許變更的範圍、觸發條件、評估方式及必要的監督措施。不能只以「模型會自行學習」作為免除版本控制或查證責任的理由。

至少需要處理：

• 哪些參數或模型組件可以改變？
• 變更的觸發條件是什麼？
• 是否需要人工核准？
• 如何確認更新後的性能仍在接受範圍內？
• 如何識別模型性能退化或非預期行為？
• 如何記錄每次更新的內容、時間及結果？
• 何時必須停止更新或恢復到先前版本？
• 何種變更需要重新進行法規評估？

企業也應區分預先定義且經過適當查證的變更機制，與可能改變產品預期用途或風險特徵的非預期變更。

Continuous learning does not eliminate change control. It increases the importance of defining permissible adaptation boundaries, monitoring model behaviour and preserving traceability between versions, evidence and regulatory decisions.

7.4 Product identification and version traceability｜產品識別與版本追溯

在 AI 醫療器材中，僅保存產品名稱及軟體版本號碼可能不足以支援完整的問題調查。

視產品架構及風險而定，企業可能需要追蹤：

• 軟體版本；
• 模型版本或模型識別碼；
• 資料集及評估資料版本；
• 第三方元件版本；
• 推論設定及關鍵參數；
• 部署環境與相關組態；
• 查證及確效報告；
• 放行核准及變更紀錄。

並非所有產品都需要將每一項資訊印在產品標籤上；重點是建立適當的內部識別與追溯機制，並確保文件能對應到實際交付或運行的系統。

當某個版本發生嚴重事件時，企業應能判斷事件涉及哪個版本、哪些部署環境、哪些已知風險，以及是否需要進一步調查或採取矯正措施。

（見續篇）