世界衛生組織(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)
開發者於制定人工智慧創新與部署路線圖之期間,需考慮開發可近用且具有充足資訊之平台,以於適合與適當情況下促進利害關係人間之參與及協作;為加速人工智慧領域實務作法之進化,透過參與及協作來簡化人工智慧監管之監督流程即有必要。
本文為「經濟部產業技術司科技專案成果」
英國內政部(Home Office)於2015年11月4日公布一項關於網路監管的「調查權法草案」(Draft Investigatory Powers Bill),其主要目的係為提供執法、國安及情治單位,如英國安全局(MI5)、秘密情報局(MI6)、英國政府通訊總部(GCHQ)對於資通訊內容之掌控能力,用以因應數位時代不斷升高的維安需求,例如防止恐怖攻擊、兒童性剝削、破解跨國犯罪集團、協尋失蹤人口、犯罪現場之定位及嫌疑人相關聯繫對象等,該草案一旦通過,將迫使網路及電信服務業者保留其客戶之通訊數據、瀏覽記錄長達一年,甚至在必要情況下,協助英國政府攔截通訊數據、破解加密訊息。 其條文共計202條,分為九部分,對於通訊數據調查權行使所採取之主要手段包含攔截通訊(Interception)、數據監看(Oversight)、以設備干擾連結(Equipment Interference)、大量蒐集個人通訊資料(Bulk Powers)等,由於法案將擴張英國政府對網路隱私之干涉,對此內政大臣Theresa May表示,新法對於瀏覽記錄著重於使用者到訪過哪些網站,而非其瀏覽過的每一個網頁,同時,對於某些握有他人敏感資料的職業,例如醫生、律師、記者、國會議員及神職人員等,擁有較多的保護。 此外,草案亦闡明將建立政府自我監督及防濫權機制,包含未來將創設調查權利委員(Investigatory Powers Commissioner,簡稱IPC)專責監督政府調查權之行使,以及一套稱為Double Lock的新制度,即前述攔截數據資料權之行使,須有內政大臣親自核發之令狀,且該令狀應獲得司法委員(Judicial Commissioner)之批准。 這項草案無疑將引來公益與私利間之衝突,也在資通訊業界造成極大的反彈,縱然「調查權法案」並未限制相關電信與網路業者不得對其服務加密,卻要求於必要情況下提供解密協助,然而目前許多通訊服務採「點對點加密」(End-to-End Encryption)技術,若非發送及接收兩端之人,即便是提供該服務之公司也無法解密,一旦草案通過,類似WhatsApp或Apple所開發之iMessage將如何在英國使用,將會是未來觀測的重點。
歐盟提出智慧醫院防禦網路攻擊建議歐盟網路與資訊安全局於2016年11月(ENISA)提出醫院導入智慧聯網技術因應資訊安全之研究建議,此研究說明智慧醫院之ICT應用乃以風險評估為基礎,聚焦於相關威脅與弱點、分析網路攻擊情節,同時建立使用準則供醫院遵守。由於遠端病患照護之需求,將使醫院轉型,運用智慧解決機制之際,仍須考量安全防護問題,且醫院可能成為下一階段網路攻擊之目標,醫院導入智慧聯元件的同時,將增加攻擊媒介使醫院面對網路攻擊更加脆弱,因此,報告建議如下: 1.醫療照護機構應提供特定資訊安全防護,要求智慧聯網元件符合最佳安全措施。 2.智慧醫院應確認醫院內之物件及其如何進行網路連結,並根據所得資料採取相應措施。 3.設備製造商應將安全防護納入現有資安系統,並在設計系統與服務之初邀請健康照護機構參與。 在我國部分,2016年9月行政院生技產業策略諮議委員會議中即提到,強調將建立智慧健康生活創新服務模式,提供民眾必要健康資訊及更友善支持環境,同時結合ICT與精密機械及材料,發展智慧健康服務的模式。2016年11月,行政院推動「生醫產業創新推動方案」,藉由調適法規等方式統整醫療體系與運用ICT技術及異業整合,其中在智慧聯網應用下之資訊安全防護議題實屬重要。
韓國修訂《不正當競爭預防和營業秘密保護法》加強對於營業秘密侵權之監管經查,韓國《不正當競爭預防和營業秘密保護法》(下稱UCPA)之修正案於2024年1月國會通過、2月公布,預計將於8月21日生效。旨在加強對於營業秘密侵權行為的法規監管與處罰力度,故本次修訂以營業秘密相關規定之修正為主,以其他修正(如商標、標誌、地理標示誤用、侵權或其他不公平競爭行為)為輔,本文摘要如下: 一、與營業秘密相關 (一)懲罰性賠償之加重:根據第14-2條第6項規定,針對「故意」營業秘密侵權行為,將懲罰性賠償從3倍上修到5倍。 (二)增加營業秘密侵權行為之監管與罰責:新增第9-8條規定,將「任何人在未經正當授權或超越授權範圍的情況下,不得損害、破壞或改變他人的營業秘密」納入規範,如有違反,將透過新增之第18條第3項規定課予最高10年監禁或最高5億韓元的罰款。 (三)加強對於企業(組織犯罪)之管制效力:基於修法前法人與自然人之罰款數額相同、企業的追訴時效短於自然人,造成難以抑止組織犯罪行為,故新增第19條規定,使企業罰款最高可處自然人罰款3倍,並新增第19-2條規定,將對企業的公訴時效延長至10年(與自然人之訴訟時效同)。 (四)新增沒收規定:依據修法前規定,即使透過UCPA提起訴訟,且侵權人承認侵權,但因為缺乏沒收規定(需要另外依據民事訴訟法才能對犯罪所得進行沒收),導致防止二次侵權損害之效果有限,故修法後透過第18-5條之規定納入可沒收特定營業秘密所得之規定。 二、其他修正 以下兩項修正之對象涉及第2條第1項第1款、第3條、第3-2條第1款(主要為商標、標誌、地理標示等誤用、侵權或其他不公平競爭行為),並不包括營業秘密(營業秘密第2條第1項第2款以下): (一)加強行政機關的職權:根據第8條規定,關於上述違規行為,相較修法前行政機關僅能提出「建議」(無強制力),修法後特別賦予智慧財產局(KIPO)可以「下令糾正」(시정을 명할 수 있다)之權利,即若未有正當理由依命令糾正者可依照第8條、第20條第1項第1、2款規定公布違反行為及糾正之建議或命令的內容,並對其進行罰款。 (二)法院查閱行政調查記錄的權力的擴張與限制:根據第14-7條規定賦予法院職權,即在法院在特定訴訟中認為必要時,可以要求相關行政單位向法院提出其依據第7條執行的調查紀錄(包括案件當事人的審問筆錄、速記紀錄及其他證據等),若相關紀錄涉及營業秘密,當事人或其代理人可向法院申請就查閱範圍、閱覽人數等進行限制。 綜上所述,可以發現此次修法除了加強法規的監管、處罰力度,顯示近年重視營業秘密爭議外,更特別修訂針對企業、法人等組織犯罪相關規定(如賠償金額的增加,甚至處罰力度大於自然人、訴訟時效的延長等),間接強調企業、法人等組織對於營業秘密侵權有內部管理與監督之責任,若參照資策會科法所創意智財中心於2023年發布之「營業秘密保護管理規範」對於企業內部管理與監督如何落實之研究,係透過將管理措施歸納成(包括從最高管理階層角色開始的整體規劃建議、營業秘密範圍確定、營業秘密使用行為管理、員工管理、網路與環境設備管理、外部活動管理,甚至是後端的爭議處理機制,如何監督與改善等)十個單元的PDCA管理循環,旨在提供企業作為機制建立之參考或自我檢視機制完善性的依據,期冀促進企業落實營業秘密管理。 本文同步刊登於TIPS網(https://www.tips.org.tw)
運作技術成熟度(Technology Readiness Level)進行技術評估運作技術成熟度(Technology Readiness Level)進行技術評估 資策會科技法律研究所 法律研究員 羅育如 104年10月22日 壹、前言 為提升我國科技競爭力,於1999年制定科學技術基本法(以下簡稱科技基本法),透過科技基本法的規定,使原本歸屬國有財產之研發成果,得以下放歸屬執行單位所有,使大學對研發成果能有更完善應用之權利。 科技基本法實施之後,各研究單位開始學習國外經驗,積極進行產學合作,將內部之研發成果技術移轉與外部產業。但是,科技基本法實行已15年的今日,各界逐漸發現,政府經費之投入與研發成果產出之經濟效益有相當大的差距。例如科技部102年專題研究計畫補助經費為215億新台幣,但僅創造3.5億新台幣之衍生成果技術移轉權利金[1]。政府經費投入與產出不符預期的議題,牽涉多元層面問題,但是從新設立政府計畫案之目標與KPI,可以發現政府新創設之補助計畫開始以協助技術商業化作為主要目的,例如萌芽計畫、產學計畫等。 技術商業化操作模式會依據技術成熟度不同而有所差異,技術成熟度高的項目,廠商承接後所需要投入的研發成果可能較低,直接協助廠商改善生產流程或是成為產品商品化的機率較高;反之,廠商則需要投入較多的技術研發費用,需要花費較多的人力與資源,技術才有機會商品化。 由此可知,在技術商業化計畫推廣時,技術項目的技術成熟度是一個重要的評估關鍵。本文針對技術成熟度的評估指標詳細說明,以提供執行技術商業化計畫時,評估技術項目之參考。以下會分別說明何謂技術成熟度以及技術成熟度如何運用,最後會有結論與建議。 貳、技術成熟度說明 技術成熟度或稱為技術準備度(Technology Readiness Level;簡稱TRL)是美國太空總署(NASA)使用多年的技術評估方法,後來為美國國防部所用,再廣為國際各政府機構、學研單位、企業機構使用。 TRL是一個系統化的量尺/衡量指標,可以讓不同型態的技術有一致性的衡量標準,描述技術從萌芽狀態到成功應用於某項產品的完整流程[2]。而TRL涵蓋的技術研發流程則包括四個部分:(1)概念發展:新技術或是新概念的基礎研究,涵蓋TRL1~3;(2)原型驗證:特定技術針對一項或是多項潛在應用的技術開發,涵蓋TRL4與5;(3)系統開發:在某一應用尚未成為一整套系統之前的技術開發以及技術驗證,然後進行系統開發,涵蓋TRL6;(4)系統上市並運作[3],涵蓋TRL7~9。以下分別說明TRL每個衡量尺度的定義[4]。 TRL 1 基礎科學研究成果轉譯為應用研究。 TRL 2 為某項特殊技術、某項材料的特性等,找出潛在創新應用;此階段仍然是猜測或推論,並無實驗證據支持。 TRL 3 在適當的應用情境或載具下,實驗分析以驗證該技術或材料相關物理、化學、生物等特性,並證明潛在創新應用的可行性(proof-of-concept)。 TRL 4 接續可行性研究之後,該技術元素應整合成具體元件,並以合適的驗證程序證明能達成原先設定的創新應用目標。 TRL 5 關鍵技術元件與其他支援元件整合為完整的系統/系系統/模組,在模擬或接近真實的場域驗證。需大幅提高技術元件驗證的可信度。 TRL 6 代表性的模型/雛形系統在真實的場域測試。展示可信度的主要階段。 TRL 7 實際系統的雛形品在真實的場域測試。驅使執行TRL7的目的已超越了技術研發,而是為了確認系統工程及研發管理的自信。 TRL 8 實際系統在真實的場域測試,結果符合設定之要求。代表所有技術皆已整合在此實際系統。 TRL 9 實際系統在真實場域達成目標。 參、技術成熟度應用 技術成熟度可以單純拿來衡量技術開發階段、可用來衡量技術開發風險、也可作為研發機構角色以及補助計畫定位的參考,以下說明。 一.技術成熟度用來衡量技術開發階段 這是技術成熟度最單純的應用方法,但因為每種技術領域都可其特殊的技術開發脈絡,所以可以根據NASA原有的技術成熟度,修改成貼近該技術領域需求的技術成熟度指標。目前有看過軟硬體TRL指標、綠能&能源TRL指標、ICT TRL指標、生醫(新藥、生物製劑、醫材)TRL指標等[5]。 二、技術成熟度用來管理技術研發風險 研究開發需投入大量的人力、物力,而研究成果的不確定性又很高,所以需要有良好的技術研發管理。技術成熟度對技術研發管理而言,是風險的概念,一般而言,TRL階段與技術風險是反向關係,也就是說TRL階段越高,技術風險越低[6]。 需要考慮的面向包括[7] ,(1)現在技術成熟度在哪一階段?以及我們投入研發後,希望達到的技術成熟度目標為何?(2)從現在的技術成熟度到專案需要的技術成熟度,要精進這項技術到底有多難?(3)這項特定技術如果開發成功,對於全面技術目標而言的重要性如何? 三、機構角色以及補助計畫定位 TRL指標可用來明確區分研發機構角色定位,例如工研院內部運用TRL指標做為技術判斷量化評估指標,並且工研院需將技術成熟度提升到TRL6或7,以克服技術面的問題,進行小型試量產,才能跨越死亡之谷讓業界接手商業化[8]。 TRL指標也可以用來區分補助計畫的標的範圍,例如美國國防部傾向投資TRL 4階段技術,美國國防部培養TRL4以及4以下的技術到TRL6階段,使得這些技術能更順利的進入技術市場,其原因在於TRL程度越低,成功商品化的不確定性以及風險就越高,而TRL4階段技術項目,是美國國防部可以承受的風險程度[9]。 肆、結論 TRL指標現在已被廣泛的運用在技術評估工作上,透過量化的指標,協助研發人員或是技術管理人員方便掌握每個技術開發案的現況,例如現在技術在TRL哪個階段,技術開發結束後,TRL預計會到達哪個階段。確定目標之後,就可以進一步評估這個計畫開發案的風險並評估組織需投入的資源。 TRL是一個簡易的技術評估指標,但如果要以此做出全面性的技術策略,似乎就還是有所不足,因此,可以再搭配其他技術評估變項,發展為全面性的技術風險管理評估指標,可能可以搭配技術開發困難度指標,用以評估TRL往上提升一級的困難度程度[10],也可以搭配技術需求價值指標[11],這項技術順利成功的話,對整個系統開發而言的價值高低,價值非常高的話,就值得花更多資源與人力去投資。 由此可知,應該可以積極運用TRL指標,用來評估政府技術補助計畫,協助大學技轉辦公室管理各研發團隊之技術開發進程,也可提供技術移轉潛在廠商清楚設定技術規格,減低技術供給方與技術需求方之間的認知差異,進而提升技術移轉成功率,也就可以拉近政府經費投入與研發成果產出的差距。 [1] 行政院國家科學委員會,行政院國家科學委員會102年年報,頁24、98(2013),http://www.most.gov.tw/yearbook/102/bookfile/ch/index.html#98/z,最後瀏覽日2015/07/21。 [2] John C. Mankins, NASA, Technology Readiness Levels: A White Paper (1995). [3] id. [4] US DEPARTMENT OF DEFENSE (DoD), Technology Readiness Assessment (TRA) Guidance (2011), http://www.acq.osd.mil/chieftechnologist/publications/docs/TRA2011.pdf (last visited July 22, 2015). [5] Lewis Chen,<Technology Readiness Level>,工研院網站,http://www.sti.or.th/th/images/stories/files/(3)ITRI_TRL.pdf (最後瀏覽日:2015/07/22)。 [6] Ricardo Valerdi & Ron J. Kohl, An Approach to Technology Risk Management (2004), http://web.mit.edu/rvalerdi/www/TRL%20paper%20ESD%20Valerdi%20Kohl.pdf (last visited July 22, 2015). [7] John C. Mankins, Technology Readiness and Risk Assessments: A New Approach, ACTA ASTRONAUTICA, 65, 1213, 1208-1215 (2009). [8] 邱家瑜、蔡誠中、陳禹傑、高皓禎、洪翊恩,<工研院董事長蔡清彥 以新創事業連結全球市場 開創屬於年輕人的大時代>,台灣玉山科技協會,http://www.mjtaiwan.org.tw/pages/?Ipg=1007&showPg=1325 (最後瀏覽日:2015/07/22)。 [9] Ricardo Valerdi & Ron J. Kohl, Massachusetts Institute of Technology, An Approach to Technology Risk Management, http://web.mit.edu/rvalerdi/www/TRL%20paper%20ESD%20Valerdi%20Kohl.pdf (last visited July 21, 2015). [10] 同註7。 [11] 同註7。