為鼓勵金融產業之創新,同時使其遵循應有之責任,並讓歐盟金融消費者與商業機構享有更多之利益,歐盟執委會於2020年10月24日提出數位金融包裹法案(Digital Finance Package),並提出以下2項數位金融立法提案:
一、加密資產立法提案(Proposal for Markets in Crypto-assets)
為促進金融創新並同時保有金融穩定性與保護投資人,歐盟執委會提出加密資產管制框架立法提案,並將加密資產分為已受監管與未受監管兩類,前者將持續依據既有規範進行管理。而針對尚未管制之加密資產,該提案針對加密資產發行人與加密資產服務供應商建立嚴格限制,要求取得核准後始可提供服務。具體而言之,立法提案包含以下項目:
(一)針對加密資產、加密資產發行人等金融商品名詞進行定義。並建立加密資產服務供應商與發行人營運上、組織架構與資產發行程序之透明度與揭露制度。
(二)針對向公開市場提供加密資產進行管制,例如,依據提案第4條,供應商應為法人,第5條則要求供應商應製作加密資產白皮書,並將其提供給主管機關後始可於公開市場提供相關服務。
(三)針對代幣資產發行人以及其加密資產之審核程序,依據提案第15條,代幣發行者必須為歐盟境內之法律實體。另外,該法要求加密資產發行人應誠實、公平且專業,並完成加密資產白皮書之出版與制定市場溝通規則。
(四)針對加密資產之收購,該法第4章亦設有相關規範,於第37條及38條規定收購之評估機制。
(五)針對加密資產服務供應商之授權與營運條件,該法第5章規定歐盟證券及市場管理局應建立加密資產服務供應商之登記制度。
(六)針對市場秩序維護之部分,該法於第6章規範相關預防市場濫用之禁止事項與要求,並於第7章賦予歐盟成員國各主管機關相關權力,例如第94條之監督與懲處權限。
二、歐盟數位營運韌性管制框架立法提案(Proposal for Digital Operational Resilience)
數位化總伴隨資安風險,歐盟執委會於包裹法案內亦提出歐盟數位營運韌性管制框架立法提案,以確保相關企業可應對所有與通訊技術有關之干擾與威脅,另外,銀行、證券交易所、票據交換所以及金融科技公司將需遵循嚴格之標準以預防並降低ICT資安事件所產生之衝擊,另外亦將針對金融機構雲端運算服務供應商進行監管。具體規範包含:
(一)ICT風險管理要求:該立法提案參照相關國際標準,於第5至第14條制訂相關ICT風險管理要求,惟未要求應遵循具體國際標準。
(二)ICT相關事件報告:該提案於第15至20條規範相關報告義務,將整合歐盟金融機構之ICT相關事件報告與監測程序。
(三)數位運作韌性測試:該提案於第21至第24條要求ICT風險管理框架應定期進行測試,惟具體方法可依據組織之規模、風險側寫與商務模式進行調整。
(四)第三方單位風險:該提案於第25至39條規範組織應對ICT第三方供應商風險進行監測,例如,第25條要求金融機構委外執行業務仍應隨時遵循所有金融服務規範,另外,ICT風險管理框架之內容亦應包含第三方ICT風險之監督策略。
本文為「經濟部產業技術司科技專案成果」
繼泰國政府於六個月前針對跨國製藥公司Merck的愛滋藥品efavirenz(品牌名稱為Stocrin)實施強制授權後,巴西政府也在最近跟進,巴西總統Luiz Inácio Lula da Silva於今(2007)年5月4日針對Merck的同一藥品簽發強制授權令。 長久以來,巴西政府與Merck即持續針對愛滋藥物efavirenz的售價進行協商,不過雙方一直未有共識:efavirenz是巴西國內最常用來治療愛滋病的藥品,總計約有38%的巴西愛滋病患(巴西國內愛滋病患約20萬人)使用此一藥品。Merck提出的售價是每一錠1.59美元,以巴西國內對該藥物的需求而言,巴西政府於2007年將須為此支付將近4千3百萬美元的藥品採購價額;然而,巴西政府認為愛滋治療藥品牽涉高度的公益性,堅持Merck應該降低售價,4月底,巴西健康部向Merck發出最後通牒,最後巴西政府拒絕Merck重新提出的價格並祭出強制授權。 強制授權本即為專利制度的一環,不過必須在嚴格的條件下始得動用。由於藥品牽涉到公眾健康問題,加以製藥產業結構特殊,多數開發中國家並無製藥能力,故2005年底的WTO香港會議就公共健康領域通過了特別決議—「執行2003年8月30日大會決議第十一點之TRIPS修正條文建議~有關落實TRIPS與公共健康杜哈宣言第六點」(Implementation of Paragraph 11 of the General Council Decision of 30 August 2003 on the Implementation of Paragraph 6 of the DOHA Declaration on the TRIPS Agreement and Public Health),修正TRIPS之強制授權規定。 5月4日的專利強制授權令乃是巴西政府首次針對藥品專利實施強制授權,巴西政府認為,其強制授權決定符合上述國際條約規定。一般認為,印度學名藥廠Cipla、Ranbaxy、Aurobindo將會是巴西此一強制授權決定之受惠者。
WTO歐盟生技產品案解析(下) 下一個要控告的是…其它所有公司?Eolas,一家由加州大學資助成立的軟體技術研發公司,於1999年控告微軟侵犯了一個關於瀏覽器技術的專利 – US 5,838,906。該專利所揭露的技術讓微軟的IE瀏覽器得以嵌入互動式內容的外掛(plug-in)程式。2003年,美國芝加哥法院認定微軟侵犯906專利,並判決微軟必需賠償Eolas及加州大學5.21億美元。2007年,微軟終於暫時與Eolas達成和解,但兩家公司都不願透漏和解的內容。 美西時間2009年10月6日上午,Eolas大動作地控告包含科技業的Adobe、Amazon、Apple、eBay、Google、Sun Microsystems、Texas Instruments、Yahoo、YouTube,以及非科技業的Citigroup、JPMorgan Chase …等共22家公司,侵犯上述906專利以及其所衍生的US 7,599,985專利。Eolas表示:「985專利是 906專利的延續,其所揭露的技術能讓網站透過附加元件和Ajax網頁開發技術的使用,為其線上服務加入完全互動式的嵌入應用軟體。」 此外,Eolas總裁Michael Doyle博士也表示:「我們只想獲得公平的對待。本公司在15年前就已經研發並廣泛的展示這些技術。使用本公司的技術來營利且未付出合理報酬的情形對本公司並不公平。」 至於被控告的大多數公司目前都尚未做出正式的回應。
世界衛生組織發布人工智慧於健康領域之監管考量因素文件,期能協助各國有效監管健康領域之人工智慧世界衛生組織(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) 開發者於制定人工智慧創新與部署路線圖之期間,需考慮開發可近用且具有充足資訊之平台,以於適合與適當情況下促進利害關係人間之參與及協作;為加速人工智慧領域實務作法之進化,透過參與及協作來簡化人工智慧監管之監督流程即有必要。