今(2018)年2月,一家成立於2013年、位於美國維吉尼亞州的雲端策略服務公司REAN Cloud Llc.以其他交易(Other Transaction, OT)模式獲得了美國國防部(Department of Defense)5年合計9.5億美金的合約,讓OT自2016年10 U.S. Code §2371b正式生效進一步確認美國國防部針對原型(Prototype)及其後續之產品開發適用OT以來[1],再次引起討論。
OT源於冷戰時期的美國,主要用於讓聯邦政府部門取得尖端國防技術的研究與發展(Research and Development, R & D)成果和原型。OT並非傳統之契約(contract)、授權書(grant)或合作協議(cooperative agreement),且法並無明確定義OT究竟實質內容為何。OT不受聯邦併購規則(Federal Acquisition Regulation, FAR)所規範,更接近一般私人商業契約,因此具備極大的合作彈性,可大幅度縮短私部門與政府合作常碰到的冗長時程。由於OT快速、彈性的這兩項特質,近年來應用於國防以外之新創或尖端科技之公私合作亦逐漸普遍。
然OT雖然簡化了政府採購的時程與限制,但同時也減少了問責可能性和透明度,因此目前只限具備美國國會授予其他交易授權(Other Transaction Authority, OTA)的聯邦政府機構得以使用OT。在美國計有太空總署(NASA)、美國國防部、美國聯邦航空總署(Federal Aviation Administration)、美國運輸部(Department of Transportation)、國土安全部(Department of Homeland Security)、運輸安全管理局(Transportation Security Administration)、衛生與公共服務部(Department of Health and Human Services)、美國能源部(Department of Energy)獲得國會授予OTA,其餘未獲OTA之政府部門僅得以在聯邦預算管理局(Office of Management and Budget)主任授權下有條件地使用OT。
尖端技術的R&D在不同領域皆有其特殊性,難以一體適用FAR,是以OT在實務運作上為兼顧持有尖端技術的公司重視速度和營業秘密之特質與採購之公平性,其運作模式通常為:聯邦政府成立某種技術領域的OT聯盟(consortium),私部門的潛在締約者可以申請加入,繳交會費並同意該聯盟的約定條款。聯盟之約定條款通常較政府採購契約來的有彈性,例如智慧財產權的歸屬是以個案個別約定。擁有OTA之政府機關嗣後可向聯盟成員徵求產品或服務白皮書,之後再從中挑選優秀者進一步繳交更詳細的產品或服務計畫書,最終經由聯盟管理機構(consortium management organization)挑選出最適者。
OT與OT聯盟的運作模式,為公私合作提供極大的法律彈性,且非常迅速。平均而言,從政府徵求白皮書到成功找到最適者,不過兩個月時間。時間與彈性乃是新創企業或尖端技術持有者與政府合作時最有疑慮之處,OT可以解決此一問題。然需注意OT在適用上仍存在諸多挑戰,例如成效難以評估、較不透明導致監督困難、智慧財產權歸屬爭議等,有待克服。
[1] 美國國防部在此前乃是遵循Section 845 of the National Defense Authorization Act(NDAA) for Fiscal Year(FY) 1994, Public Law 103-160適用OT。
歐盟資料保護監督機關(European Data Protection Supervisor, EDPS)於2019年12月19日發布「評估限制隱私權和個人資料保護基本權利措施之比例指引」(EDPS Guidelines on assessing the proportionality of measures that limit the fundamental rights to privacy and to the protection of personal data),旨在協助決策者更易於進行隱私友善(privacy-friendly)之決策,評估其所擬議之措施是否符合「歐盟基本權利憲章」(Charter of Fundamental Rights of the European Union)關於隱私權和個人資料之保護。 該指引分為三大部分,首先說明指引的目的與如何使用;第二部分為法律說明,依據歐盟基本權利憲章第8條所保護個人資料的基本權利,並非絕對之權利,得於符合憲章第52條(1)之規定下加以限制,因此涉及處理個人資料的任何擬議措施,應進行比例檢驗;指引的第三部份則具體說明決策者應如何評估擬議措施之必要性和比例性之兩階段檢驗: 必要性檢驗(necessity test) (1) 步驟1:初步對於擬議措施與目的為詳細的事實描述(detailed factual description)。 (2) 步驟2:確定擬議措施是否限制隱私保護或其他權利。 (3) 步驟3:定義擬議措施之目的(objective of the measure),評估其必要性。 (4) 步驟4:特定領域的必要性測試,尤其是該措施應有效(effective)且侵害最小(the least intrusive)。 若前述評估認為符合必要性,則接續比例性檢驗,透過以下4步驟評估: 比例性檢驗(proportionality test) (1) 步驟1:評估目的正當性(legitimacy),擬議措施是否滿足並達到該目的。 (2) 步驟2:擬議措施對隱私和資料保護基本權的範圍、程度與強度(scope, extent and intensity)之影響評估。 (3) 步驟3:繼續進行擬議措施之公平對等評估(fair balance evaluation)。 (4) 步驟4:分析有關擬議措施比例之結果。 科技時代的決策者在立法和政策擬定時,面臨的問題愈趨複雜,需要全面性評估,擬議措施限制應符合歐盟法規,且具必要性並合於比例,隱私保護更是關鍵,參酌該指引搭配EDPS於2017年發布之「必要性工具包」(Necessity Toolkit),將使決策者所做出的決策充分保護基本權利。
歐盟執委會通過《歐洲互通法案》,以強化歐盟公共部門的跨境互通與合作歐盟執委會於2022年11月21日通過《歐洲互通法案》(Interoperable Europe Act)(下稱本法案),以強化歐盟公共部門的跨境互通與合作,加速數位化轉型。跨境互通將使歐盟及其成員國為公民與企業提供更優良的公共服務,並預計為公民節省550萬至630萬歐元的成本;為與公共行政有業務上往來的企業節省57億至192億歐元的成本。 《歐洲互通法案》為歐盟的公部門建立一套合作模式,該模式有助於建立安全的跨境資訊交換及可互通的數位共享解決方案(如開源軟體、指引、IT工具等),使彼此之間合作更有效率,進而帶動公部門創新。舉例而言,Covid-19疫情期間,互通性政策使醫院間得共享重症監護病床之數量資訊,以提供人民最即時的醫療資源。本法案架構如下: 1.結構化的歐洲合作:由歐盟成員國和區域、城市共同合作,制定跨境互通的共同戰略議程,並得到公共和私人的支持,實施互通性解決方案與進度監控。 2.強制性評估:評估跨境互通之IT系統對歐盟的影響。 3.共享和再利用解決方案:透過歐洲入口網(Interoperable Europe Portal)及社群合作的一站式平台,提供支持共享與再利用的解決方案(如開源軟體)。 4.提供創新和相關支持措施:包括監理沙盒(sandboxes)、GovTech計畫及訓練措施等。 自2010年以來,歐洲互通性框架(European Interoperability Framework, EIF)一直作為歐盟互通性政策的主要參考依據,惟始終不具有約束力。本法案將使EIF成為單一參考依據,使歐盟公共服務部門擁有互通性政策,並未來互通性合作框架將由歐洲互通委員會(Interoperable Europe Board)指導,該委員會由歐盟成員國、歐盟執委會、地區委員會(Committee of the Regions)及歐洲共同體經濟和社會委員會(European Economic and Social Committee)之代表組成。 可互通的數位公共服務對建構數位單一市場至關重要,除提升經濟效益和行政效率外,案例研究亦表明,互通性對提高政府信任可產生正面積極影響,同時本法案充分尊重現有的隱私與資料保護規則,以符合歐盟創建以人為中心的規範方法,提升個人基本權利。
由美國「二十一世紀通訊與視訊接取無障礙法」談無障礙通訊傳播環境之建立 世界衛生組織發布人工智慧於健康領域之監管考量因素文件,期能協助各國有效監管健康領域之人工智慧世界衛生組織(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) 開發者於制定人工智慧創新與部署路線圖之期間,需考慮開發可近用且具有充足資訊之平台,以於適合與適當情況下促進利害關係人間之參與及協作;為加速人工智慧領域實務作法之進化,透過參與及協作來簡化人工智慧監管之監督流程即有必要。