世界衛生組織發布人工智慧於健康領域之監管考量因素文件,期能協助各國有效監管健康領域之人工智慧

世界衛生組織(World Health Organization, WHO)於2023年10月19日發布「人工智慧於健康領域之監管考量因素」(Regulatory considerations on artificial intelligence for health)文件,旨在協助各國有效監管健康領域之人工智慧,發揮其潛力同時最大限度地降低風險。本文件以下列六個領域概述健康人工智慧之監管考量因素:

(1)文件化與透明度(Documentation and transparency)
開發者應預先規範(pre-specifying)以及明確記錄人工智慧系統(以下簡稱AI系統)之預期醫療目的與開發過程,如AI系統所欲解決之問題,以及資料集之選擇與利用、參考標準、參數、指標、於各開發階段與原始計畫之偏離及更新等事項,並建議以基於風險之方法(Risk-based approach),根據重要性之比例決定文件化之程度、以及AI系統之開發與確效紀錄之保持。

(2)風險管理與AI系統開發生命週期方法(Risk management and AI systems development lifecycle approaches)
開發者應在AI系統生命之所有階段,考慮整體產品生命週期方法(total product lifecycle approach),包括上市前開發管理、上市後監督與變更管理。此外,須考慮採用風險管理方法(risk management approach)來解決與AI系統相關之風險,如網路安全威脅與漏洞(vulnerabilities)、擬合不足(underfitting)、演算法偏差等。

(3)預期用途、分析及臨床確效(Intended use, and analytical and clinical validation)
開發者應考慮提供AI系統預期用途之透明化紀錄,將用於建構AI系統之訓練資料集組成(training dataset composition)之詳細資訊(包括大小、設定與族群、輸入與輸出資料及人口組成等)提供給使用者。此外,可考慮透過一獨立資料集(independent dataset)之外部分析確效(external analytical validation),展示訓練與測試資料以外之效能,並考慮將風險作為臨床確效之分級要求。最後,於AI系統之上市後監督與市場監督階段,可考慮進行一段期間密集之部署後監督(post-deployment monitoring)。

(4)資料品質(Data quality)
開發者應確認可用資料(available data)之品質,是否已足以支援AI系統之開發,且開發者應對AI系統進行嚴格之預發布評估(pre-release evaluations),以確保其不會放大訓練資料、演算法或系統設計其他元素中之偏差與錯誤等問題,且利害關係人還應考慮減輕與健康照護資料有關之品質問題與風險,並繼續努力創建資料生態系統,以促進優質資料來源之共享。

(5)隱私與資料保護(Privacy and data protection)
開發者於AI系統之設計與部署過程中,應考慮隱私與資料保護問題,並留意不同法規之適用範圍及差異,且於開發過程之早期,開發者即應充分瞭解適用之資料保護法規與隱私法規,並應確保開發過程符合或超過相關法規要求。

(6)參與及協作(Engagement and collaboration)
開發者於制定人工智慧創新與部署路線圖之期間,需考慮開發可近用且具有充足資訊之平台,以於適合與適當情況下促進利害關係人間之參與及協作;為加速人工智慧領域實務作法之進化,透過參與及協作來簡化人工智慧監管之監督流程即有必要。

本文為「經濟部產業技術司科技專案成果」

相關連結
你可能會想參加
※ 世界衛生組織發布人工智慧於健康領域之監管考量因素文件,期能協助各國有效監管健康領域之人工智慧, 資訊工業策進會科技法律研究所, https://stli.iii.org.tw/article-detail.aspx?d=9093&no=64&tp=1 (最後瀏覽日:2026/05/04)
引註此篇文章
科法觀點
你可能還會想看
OECD啟動全球首創的《開發先進人工智慧系統組織的報告框架》

2025年2月7日,經濟合作暨發展組織(Organization for Economic Cooperation and Development,OECD)正式啟動《開發先進人工智慧系統組織的報告框架》(Reporting Framework for the Hiroshima Process International Code of Conduct for Organizations Developing Advanced AI Systems,簡稱G7AI風險報告框架)。 該框架之目的是具體落實《廣島進程國際行為準則》(Hiroshima Process International Code of Conduct)的11項行動,促進開發先進人工智慧系統(Advanced AI Systems)的組織建立透明度和問責制。該框架為組織提供標準化方法,使其能夠證明自身符合《廣島進程國際行為準則》的行動,並首次讓組織可以提供有關其人工智慧風險管理實踐、風險評估、事件報告等資訊。對於從事先進人工智慧開發的企業與組織而言,該框架將成為未來風險管理、透明度揭露與國際合規的重要依據。 G7 AI風險報告框架設計,對應《廣島進程國際行為準則》的11項行動,提出七個核心關注面向,具體說明組織於AI系統開發、部署與治理過程中應採取之措施: 1. 組織如何進行AI風險識別與評估; 2. 組織如何進行AI風險管理與資訊安全; 3. 組織如何進行先進AI系統的透明度報告; 4. 組織如何將AI風險管理納入治理框架; 5. 組織如何進行內容驗證與來源追溯機制; 6. 組織如何投資、研究AI安全與如何降低AI社會風險; 7. 組織如何促進AI對人類與全球的利益。 為協助G7推動《廣島進程國際行為準則》,OECD建構G7「AI風險報告框架」網路平台,鼓勵開發先進人工智慧的組織與企業於2025年4月15日前提交首份人工智慧風險報告至該平台(https://transparency.oecd.ai/),目前已有包含OpenAI等超過15家國際企業提交報告。OECD亦呼籲企業與組織每年定期更新報告,以提升全球利益相關者之間的透明度與合作。 目前雖屬自願性報告,然考量到國際監理機關對生成式AI及高風險AI 系統透明度、可問責性(Accountability)的日益關注,G7 AI風險報告框架內容可能成為未來立法與監管的參考作法之一。建議企業組織持續觀測國際AI治理政策變化,預做合規準備。

歐盟隱私工作小組支持擴大通知義務之業者範圍

  歐盟隱私權工作小組(working party)日前公布其對「隱私與電子通訊指令」(Directive on Privacy and Electronic Communications, 2002/58/EC)之修正意見,藉此重申支持個人資料外洩通知責任立法之立場,並建議擴大適用通知責任之業者範圍至涉及線上交易之電子商務之服務提供者。此項建議隨即遭到歐盟理事會及委員會之反對,認為通知責任應僅限於電信公司,而不應擴及其他電子商務服務提供者。   歐盟隱私權工作小組於2009年2月初提出的報告指出,個人資料外洩通知責任法制(Data Breach Notification Law)之建立對於資訊社會服務(Information Society Service)之發展是必要的,其有助於個人資料保護監督機構(Data Protection Authorities)執行其職務,以確認受規範之服務提供者是否採取適當的安全措施。再者,亦可間接提高民眾對於資訊社會相關服務使用之信心,保護其免於身份竊盜(identity theft)、經濟損失以及身心上之損害。   然而,歐盟理事會及歐洲議會則反對該項修正建議,其一方面認為不應擴張資料外洩通知責任制度適用之業者,另一方面則認為對於是否透過法制規範課予業者通知之義務,應由各國立法者決定是否立法,甚或由業者依資料外洩情形嚴重與否,來判斷是否通知其各國個人資料保護相關組織及客戶。此外,參考外國實施之成效,美國雖有多數州別採用資料外洩通知責任制度,但並非所有的隱私權團體皆肯認該項制度;英國資訊委員會對於該制度之成效則仍存質疑,因從過去為數眾多的個人資料外洩事件看來,其效果已逐漸無法彰顯。   雖然歐盟個人資料保護官(European Data Protection Supervisor)與歐盟隱私權工作小組之看法一致,但其與歐洲議會與歐盟理事會仍存有歧見,對於個人資料外洩通知責任制度之建立,似乎仍有待各方相互協商尋求共識,方能決定是否納入歐盟隱私及電子通訊指令之規範。

美國國家安全局發布「軟體記憶體安全須知」

  美國國家安全局(National Security Agency, NSA)於2022年11月10日發布「軟體記憶體安全須知」(“Software Memory Safety” Cybersecurity Information Sheet),說明目前近70%之漏洞係因記憶體安全問題所致,為協助開發者預防記憶體安全問題與提升安全性,NSA提出具體建議如下:   1.使用可保障記憶體安全之程式語言(Memory safe languages):建議使用C#、Go、Java、Ruby、Rust與Swift等可自動管理記憶體之程式語言,以取代C與C++等無法保障記憶體安全之程式語言。   2.進行安全測試強化應用程式安全:建議使用靜態(Static Application Security Testing, SAST)與動態(Dynamic Application Security Testing, DAST)安全測試等多種工具,增加發現記憶體使用與記憶體流失等問題的機會。   3.強化弱點攻擊防護措施(Anti-exploitation features):重視編譯(Compilation)與執行(Execution)之環境,以及利用控制流程防護(Control Flow Guard, CFG)、位址空間組態隨機載入(Address space layout randomization, ASLR)與資料執行防護(Data Execution Prevention, DEP)等措施均有助於降低漏洞被利用的機率。   搭配多種積極措施增加安全性:縱使使用可保障記憶體安全之程式語言,亦無法完全避免風險,因此建議再搭配編譯器選項(Compiler option)、工具分析及作業系統配置等措施增加安全性。

中國衛生部發布「抗菌藥物臨床應用管理辦法」

  長久以來,中國民眾對於抗菌藥物(如抗生素等)存有高度的依賴性,造就了國內規模龐大的抗菌藥物市場,依據中國衛生部統計,中國民眾對抗菌藥物的人均消費額幾乎是美國民眾的10倍。對此,世界衛生組織早於2011年4月7日便正式提出警告與呼籲,若中國未能控制抗菌藥物濫用的情況,很快將面臨「無藥可用」的窘境,並演變為全球人類的災難。   為扭轉前述抗菌藥物濫用狀況,中國衛生部於2012年4月24日正式發布了「抗菌藥物臨床應用管理辦法」(以下稱管理辦法),分別對於抗菌藥物的使用及醫療院所之管理制度作了如下的完整規範: 1. 對抗菌藥物採分級管理制,分為「非限制使用級」、「限制使用級」及「特殊使用級」三類,並要求醫療院所依此分類,擬定「抗菌藥物供應目錄」,凡具有同一通用名稱者,其注射型和口服型各不得超過兩種、具有相似或相同藥理學特徵的藥物亦不得重複列入。 2. 依上述分級對抗菌藥物作臨床使用管理:「限制使用級」者,只有當發生嚴重感染、免疫功能下降合併感染,或病菌只對限制級藥物有反應時,才允許使用;「特殊使用級」者,非經醫療院所內設置的「抗菌藥物管理工作機構」同意,不得使用;惟若係為搶救生命垂危的病患或其他緊急情況下,可以越級使用,但須於24小時內補行程序。 3. 各院所必須設置「抗菌藥物管理工作機構」或專責人員,負責制定抗菌藥物管理制度、擬定「抗菌藥物供應目錄」,並建立細菌抗藥預警制度。   管理辦法將於2012年8月起正式施行,一般預料將有助於改善中國抗菌藥物濫用的現象,然用藥限制也必定衝擊現今許多對抗菌藥物產品銷售已存有高度依賴性的企業;相反地,由於管理辦法中明文將「具有抗菌作用的中醫製劑」排除於管制範圍外,或許將促成抗菌中醫藥品的發展契機,而值得持續觀察之。

TOP