世界衛生組織(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)
開發者於制定人工智慧創新與部署路線圖之期間,需考慮開發可近用且具有充足資訊之平台,以於適合與適當情況下促進利害關係人間之參與及協作;為加速人工智慧領域實務作法之進化,透過參與及協作來簡化人工智慧監管之監督流程即有必要。
本文為「經濟部產業技術司科技專案成果」
有關在網路販售仿冒品所透過之網路交易平台業者是否應負法律責任之問題,歐盟法院(Court of Justice of the European Union)於2011年7月12日針對L’oreal v. eBay案作出判決,認為如eBay之網路交易平台業者應為平台使用者之商標侵權行為負責。 國際知名化妝品品牌L’oreal 於2007年對eBay提出多項商標侵權之控訴,L’oreal認為eBay沒有適當的管控阻止其交易平台使用者之商標侵權行為,其包括在交易平台上販售仿冒品及非賣品,進行平行輸入販售非給歐盟市場流通之商品給位在歐盟會員國之人,以及購買網路關鍵字廣告協助交易平台使用者找到仿冒L’oreal品牌之商品,但eBay認為其適用歐盟電子商務指令(EU E-Commerce Directive)下之有關網路服務業者之免責條款。 歐盟法院之判決認為,網路交易平台業者若有扮演主動的角色,對仿冒商品之販售資料有掌控或知曉,則歐盟電子商務指令之免責條款應不適用,另外,若網路平台交易業者雖然沒有扮演主動的角色,但知道在其交易平台有商標侵權之販售行為但並沒有採取任何阻止行動,則網路平台業者也無法享有上述之免責權。同時,歐盟法院也認為各國法院應可以要求網路交易平台業者採取動作停止及防止交易平台使用者之侵權行為。
流行音樂「取樣」之著作權概念流行音樂之抄襲,於我國著作權法之評價上,是以著作權法第91條第1項「擅自以重製之方法侵害他人之著作財產權者」來評價,我國智慧財產法院已有相關判決可供參酌,如智慧財產法院 103 年刑智上易字第 47 號刑事判決。惟流行音樂之創作,往往受到流行趨勢及過去其他作品的啟發,但將任何的風格上的模仿皆認為係著作權之侵害顯然並不恰當,而旋律相似度高達九成左右者屬於抄襲固然無庸置疑,然僅取樣(sampling)使用少數詞曲,用以表達概念或致敬之使用他人創作情形,其判斷標準,或可參考美國法院之判決見解。 2003年的Newton v. Diamond案中,第九巡迴上訴法院認可「微量取用」(de minimis use)原則,認為在有數十秒的取樣情形時,當一般聽眾不認為是挪用,即構成微量取用,並無實質近似,且若未取樣原曲之重要部分,亦不構成抄襲。但2005年時,聯邦第六巡迴上訴法院在Bridgeport Music, Inc. v. Dimension Films案中,對微量取用的情形提出「明確性規則」(bright- line rule),認為必須要取得授權方得取樣;而美國最高法院則在1994年的Campbell v. Acuff-Rose案中,認為雖有擷取他曲旋律,但整體曲風不同時,採取轉化性原則,認為構成合理使用。
SWIFT與金融業者攜手合作發展區塊鏈電子投票環球銀行金融電信協會(Society for Worldwide Interbank Financial Telecommunication, SWIFT)於今年3月宣布將與德意志銀行、星展銀行、匯豐銀行、渣打銀行、證券軟體供應商SLIB與新加坡交易所(Singapore Exchange,SGX)聯合於亞太地區展開建構於分散式帳簿技術(Distributed Ledger Technology ,DLT)之電子投票概念性驗證(Proof-of-Concept, PoC),探究分散式帳簿技術是否能有效簡化股東權利之行使,以提高市場參與者效率。 目前實務上召集股東會耗費大量人力與時間成本,紙本投票流程繁雜且費時,股東表決權也經常因代理行使錯誤導致無法及時反應股東真意,因此業界希望可以透過將區塊鏈分散式帳簿技術應用於電子投票系統,改善股東會之透明度與自動化程度,提升股東會之效能及股東參與度。 SWIFT表示區塊鏈電子投票概念性驗證將於2019年上半年展開, 旨在體現四大目標: 測試與發行人和證券存託機構(Central Securities Depository)建立的投票解決方案,同時該方案係以許可制的私有鏈(private blockchain)儲存與管理數據資訊。 展現基於ISO 20022所為之混合解決方案之可行性,將訊息之傳遞與分散式帳簿技術結合,促進互通性並避免市場分裂。 電子投票的概念驗證將會在沙盒環境中測試SWIFT的應用程式代管(host)能力。 確認使用ISO 20022作為應用程式介面標準化之基礎,透過應用程式介面將儲存於分散式帳簿節點間資料分享給分類帳。 期望透過區塊鏈技術之應用,以金融創新的解決方案改善傳統上股東會礙於書面投票或代理流程繁瑣之不便利,將區塊鏈技術與ISO標準相互結合,建立系統化之創新電子投票解決方案,促進市場發行者與參與者密切合作。 我國金融監督管理委員會為強化股東權益之保護,落實電子投票制度,於 106年1月18日發布金管證交字第1060000381號函釋:「依據公司法第一百七十七條之一第一項規定,上市(櫃)公司召開股東會時,應將電子方式列為表決權行使管道之一」;又隨著智慧型手機與行動網路普及,電子投票可能成為未來股東會股東表決權行使趨勢之一,此次SWIFT與業界共同提出之區塊鏈電子投票發展或可作為未來我國電子投票實務運作之參考。
歐盟資通安全局公布《提升歐盟軟體安全性》研究報告歐盟資通安全局(European Union Agency for Cybersecurity, ENISA)於2020年4月25日以歐盟網路安全驗證框架(EU cybersecurity certification framework)檢視現行安全軟體開發及維護之方式與標準,並公布《提升歐盟軟體安全性》(Advancing Software Security in the EU)研究報告。歐盟資通安全局後續將以該研究報告協助產品、服務及軟體開發之驗證,並期望能夠成為執行歐盟網路安全驗證框架相關利害關係人之非強制性參考文件之一。 本報告指出由於安全軟體已普遍應用於日常商品與服務當中,但目前針對軟體安全事故並無相對應之安全守則及技術,故為提高軟體安全層級並緩解目前已知之軟體安全威脅,應針對安全軟體開發及維護進行規範並驗證。 報告中除了針對軟體安全提出其應具備之要素、概述現行安全軟體開發方式及標準之缺點外,亦提出若以歐盟網路安全驗證框架針對軟體開發方式進行驗證時可考量之一些實際做法,包括: 已驗證之資訊與通訊科技(Information and Communication Technology, ICT)產品、服務或流程供應商或製造商,針對資料庫之部署及維護,除探討防止資料洩漏之方式外,尚應考量產品、服務或流程驗證過程中,進行資料共享會面臨之安全威脅以及緩解之方式。 應與歐洲標準組織(European Standards Organizations, ESOs)及標準制定組織(Standards Developing Organization, SDOs)合作。 建立一些針對軟體開發、維護及操作準則以補充現有歐盟網路安全驗證方案(EU cybersecurity certification schemes)。 針對現行不一致之軟體開發及維護規範,應考量建立較寬鬆之合規性評估(conformity assessment)標準。 借鏡現有經驗和專業知識,促進歐盟網絡安全驗證框架之適用。