世界衛生組織(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)
開發者於制定人工智慧創新與部署路線圖之期間,需考慮開發可近用且具有充足資訊之平台,以於適合與適當情況下促進利害關係人間之參與及協作;為加速人工智慧領域實務作法之進化,透過參與及協作來簡化人工智慧監管之監督流程即有必要。
本文為「經濟部產業技術司科技專案成果」
美國專利商標局下之專利審查政策處(Office of Patent Examination Policy)於2016年11月2日發布了一份備忘錄(memorandum),就近來聯邦巡迴上訴法院所做之可專利性客體(subject matters eligibility, SME)相關判決為整理並對專利審查者提出若干指引。 該備忘錄表示,美國可專利性客體審查手冊(SME guideline,下稱SME審查手冊)自今年5月修改後,聯邦巡迴上訴法院陸續做出相關判決,因此除了先就相關事項為一整理,之後亦會依據這些判決所確立之一些原則以及專利之利益相關人(patent stake holders)之回饋意見對SME審查手冊進行修改。 此備忘錄主要討論的判決為McRO案以及BASCOM案,在此兩判決中,聯邦巡迴上訴法院均認為下級審法院錯誤地依Alice規則認定專利無效。在McRO案,法院認為有關利用電腦所執行之自動人臉語音同步之動畫系統(automatic lip synchronization and facial expression animation )之方法請求項係屬有效。審查者在適用Alice規則時應依據SME手冊的2階段步驟對請求項進行整體考量,且不應忽略請求項中許多特定要件,過度簡化請求項為抽象概念。其並指出「電腦相關技術之改良」,不僅止於電腦運作或是電腦網路本身,若是一些規則(rules)(主要為一些數理關係式(mathematical relationship))可以增進改善電腦之效能者亦屬之。 備忘錄另藉著BASCOM案提醒審查者,在決定請求項是否無效時,應考慮所有的請求項之元件(elements),以判斷該請求項是否已經具備實質超越(substantial more)一般常規、通用之元件(conventional elements)之要素。同時備忘錄並提醒審查者不應依據一些法院決定不做為先例之判決(nonprecedential decisions)之意見。
美國聯邦交易委員會延展紅旗規則之施行日美國聯邦交易委員會(Federal Trade Commission,FTC)因應眾議院之要求,再次延展了紅旗規則(Red Flags Rule)之施行日,目前將由原先預定之2009年11月1日,延後至2010年6月1日施行。此規則最初預計於2008年11月1日施行,此次已是第四次延展。 所謂紅旗規則,原為「公平與正確信用交易法(Fair and Accurate Credit Transactions Act)」中之規定,依該法眾議院指示美國聯邦交易委員會及相關部門制定法規,用以規範金融機構及授信單位降低身分盜用之風險。基於此一指示,金融機構及授信單位必須研擬防止身分盜用的方案。詳言之,紅旗規則係要求凡管理使用包括性帳戶(covered account)者都應研擬並執行防止身分盜用之書面計劃。所謂的包括性帳戶係指:1.用於多次消費計算用途之帳戶,如信用卡帳戶、汽車貸款帳戶、手機帳戶、支票帳戶等;2.所有預期會產生身分盜用風險的帳戶,並不僅指於金融機構中所設立之帳戶。而前述應研擬之計畫將用以協助確認、偵測並解決身分盜用之行為。 由於只要用於支付計算,或有可能產生身分盜用風險之帳戶,均為包括性帳戶,而用於支付會計師款項之帳戶亦包含在內。惟美國會計師協會(American Institute of Certified Public Accountants, AICPA)要求FTC免除註冊會計師適用紅旗規則,該協會執行長Barry Melancon認為:「我們很在意紅旗規則的廣泛應用,因為我們並不認為當CPA之客戶付款時,會產生相當的身分冒用風險。」他指出該紅旗規則所帶來之負擔已超過其風險。AICPA並要求各州會計師協會去函對FTC表達排除適用之意見。而Melancon贊同FTC延後適用紅旗原則之決定,其並認為紅旗規則並無須廣泛運用於會計業,因為作為值得信賴的顧問,會計師對於其客戶應該都很熟悉,也會要求對身分資訊採取嚴格的隱私保護標準。 為了推動紅旗規則之適用,FTC已於紅旗規則之官方網站提供了該規則之適用綱領,並以座談會之方式對各團體進行運用之培訓。同時以出版企業之應用綱領,大量之文宣及宣導短片,對民眾提供諮詢服務等方式推廣紅旗規則。 而司法實務界對於此一規則之適用範圍亦開始表達其見解,在2009年10月30日,哥倫比亞地方法院判決律師業不適用紅旗規則。不過此次的延展施行公告並不會影響相關案件的進行及上訴流程,也不會影響其他聯邦部門對於金融機構及授信單位的監督。
2022年日本公布平台資料處理規則實務指引1.0版日本數位廳(デジタル庁)與內閣府智慧財產戰略推進事務局(内閣府知的財産戦略推進事務局)於2022年3月4日公布「平台資料處理規則實務指引1.0版」(プラットフォームにおけるデータ取扱いルールの実装ガイダンス ver1.0,簡稱本指引)。建構整合資料提供服務的平台,將可活用各種資料,並創造新價值(如提供個人化的進階服務、分析衡量政策效果等),為使平台充分發揮功能,本指引提出平台實施資料處理規則的六大步驟: 識別資料應用價值創造流程與確認平台角色:掌握從產生資料,到分析資料創造使用價值,再進一步提供解決方案的資料應用價值創造流程,以確認平台在此流程中扮演的角色。 識別風險:掌握利害關係人(如資料提供者與使用者等)顧慮的風險(如資料未妥適處理、遭到目的外使用等疑慮)。 決定風險應對方針:針對掌握的風險,決定規避、降低、轉嫁與包容等應對方針。 設定平台資料處理政策與對利害關係人說明之責任(アカウンタビリティ):考量資料處理政策定位,擬定內容,並向利害關係人進行說明。 設計平台使用條款:依據「PDCA循環」重複執行規則設計、運作與評估,設計平台使用條款。 持續進行環境分析與更新規則:持續分析內部與外部因素可能面臨的新風險,並更新平台資料處理規則。