德國禁種MON810爭議，行政法院裁定有理由，支持主管機關禁種決定
跨國農業生技公司Monsanto研發的MON810品系抗蟲基因改造玉米，於今（2009）年4月中旬遭到德國農業生技的主管機關－聯邦營養、農業與消費者保護局（Bundesministerium für Ernährung, Landwirtschaft und Verbraucherschutz, BMELV）援引歐盟基因改造生物環境釋出指令（EU-Freisetzungsrichtlinie）中的防衛條款，加以禁種。
雖然Monsanto隨即對BMELV此項決定提出行政訴訟，但Braunschweig行政法院在5月初作出的暫時性裁定，支持了BMELV此項決定。法院基於兩大理由，裁定BMELV之禁種決定並非無據：（1）只要有新的或進一步的資訊出現，支持基因改造作物可能會對人體或動物健康造成損害，即可支持主管機關作出禁止種植已經取得歐盟上市許可的基因改造作物之決定之論據，不需要存在有必然會有風險的科學知識。（2）據此論據進行風險調查及風險評估，乃主管機關之執掌，主管機關對此有裁量權（Beurteilungsspielraum），從而，法院介入審查該行政決定的重點，在於主管機關是否已為充分的風險調查、有無恣意論斷風險。本案目前尚非終局之決定，Monsanto仍可對於此項裁定提出抗告。
在歐盟，基因改造生物的上市需透過歐盟程序為之，一旦歐盟執委會允許某一基因改造生物的上市，該基因改造生物原則上即可在全體歐盟會員國推廣銷售，包括種植。唯歐盟環境釋出指令例外容許會員國得於一定條件下，援引防衛條款主張已通過歐盟審查的基因改造生物，對於其境內環境或人體與動植物健康有負面影響，從而禁止特定已取得歐盟上市許可的基因改造生物於其境內流通。防衛條款的動用屬例外情形，且須定期接受歐盟層級的審查。
本文為「經濟部產業技術司科技專案成果」
行動健康是指利用行動應用程式與智慧手機、平板、或無線裝置等行動裝置結合，運用這些裝置的核心功能，如聲音、簡訊、定位系統、藍芽、或3G、4G行動通信技術等，作為健康照護用途，以提升傳統照護品質與管理健康，減少醫療成本耗費。倘若行動應用程式具有醫療用途，可用於診斷、治療、預防疾病等，則屬於醫療器材，且該應用程式通常為醫療器材之附件，或與行動裝置結合使用而成為醫療器材，對此則稱之為行動醫療。 隨著智慧聯網(IoT)的應用，國際間對於行動健康與醫療的發展日益著重，除了鼓勵創新研發之外，也紛紛制訂法規政策因應，包括美國食品藥物管理局(FDA)在2013年9月公布行動醫療應用程式指導原則(Mobile Medical Application, Guidance For Industry and Food and Drug Administration Staff)，並於2015年2月修訂；歐盟2012年提出eHealth 行動計畫(eHealth Action Plan 2012-2020)，並在2014年4月針對行動健康的管理規範議題開放各類相關人士進行公共諮詢，後續在2015年1月公布諮詢結果。我國亦在2015年4月公布醫用軟體分類參考指引，以提供產業開發產品、申請查驗登記之參考。 未來，行動健康與醫療的發展將持面臨挑戰，相關問題包括行動健康與行動醫療之區分標準、行動醫療應用程式與傳統醫療軟體之監管差異、行動健康應用程式開發使用之自律性規範、使用者或病人隱私與個人資料保護、以及在研發過程中涉及的研究倫理等議題。
中國大陸通過《中華人民共和國電子商務法》 針對「電子商務平台經營者」制定專節中國大陸於2018年8月31日第13屆全國人大常務委員會表決通過了《中華人民共和國電子商務法》（以下簡稱《電商法》），並將於2019年1月1日實施 。《電商法》首條揭示了「保障電子商務各方主體合法權益、規範電子商務行為、維護市場秩序」之意旨，除以「電子商務經營者」為主要規範對象外，亦涵蓋了法律行為、支付與物流、爭議解決等各個交易層面。 有鑑於電子商務平台對市場的主導作用，《電商法》特別針對「電子商務平台經營者」（以下簡稱「平台」）制定專節，要求其審核平台內經營者之資質資格，並課予其保障智慧財產權及消費者人身、財產安全之義務。分述如下： 為因應電子商務平台上仿冒偽劣品氾濫之窘境，《電商法》規定平台於接收權利人所發送之侵權通知後，須採取刪除、屏蔽、斷開鏈接、終止交易和服務等行動，否則需就損害擴大之部分，與平台內經營者負連帶責任。此外，平台「明知」或「可得而知」平台內經營者已侵害智慧財產權，而未採取必要措施者，亦須與侵權行為人承擔連帶責任。 如商品或服務涉及消費者之生命、健康，則平台負有：(1) 對平台內經營者資質資格之審核義務；以及(2) 對消費者之安全保障義務。如因未履行上開義務而造成消費者損害，需與該平台內經營者承擔「相應的責任」；換言之，平台是否踐履相關義務應依實際個案認定。同時增加行政罰規定，違者由市場監督管理部門責令限期改正，最重並得課處200萬元之罰款 。
歐盟資料保護工作小組修正通過個人資料侵害通報指引歐盟資料保護工作小組修正通過「個人資料侵害通報指引」 資訊工業策進會科技法律研究所 法律研究員 李哲明 2018年3月31日 壹、事件摘要 因應歐盟「通用資料保護規則」（The General Data Protection Regulation，或有譯為一般資料保護規則，下簡稱GDPR）執法即將上路，針對個人資料侵害之通報義務，歐盟資料保護工作小組（Article 29 Data Protection Working Party, WP29）特於本（2018）年2月6日修正通過「個人資料侵害通報指引」（Guidelines on Personal data breach notification under Regulation 2016/679），其中就GDPR所規範個資侵害之定義、對監管機關之通報、與個資當事人之溝通、風險及高風險評估、當責與紀錄保存及其他法律文件所規定之通報義務等，均設有詳盡說明與事例。 貳、重點說明 一、何謂個資侵害？個資侵害區分為哪些種類？ 依據GDPR第4條（12）之定義，個資侵害係指：「個人資料因安全性之侵害所導致意外或非法之毀損、喪失、修改、未經授權之揭露、存取、個資傳輸、儲存或其他處理。」舉例來說，個人資料之喪失包括含有控制者（controller）顧客資料庫的備份設備之遺失或遭竊取。另一例子則為整份個資的唯一檔案遭勒索軟體加密，或經控制者加密，但其金鑰已滅失。依據資訊安全三原則，個資侵害之種類區分為： 機密性侵害（Confidentiality breach）：未經授權、意外揭露或獲取個人資料。 完整性侵害（Integrity breach）：未經授權或意外竄改個人資料。 可用性侵害（Availability breach）：在意外或未經授權之情況下，遺失個人資料存取權限或資料遭銷燬。 二、何時應為通知？ 按GDPR第33條（1）之規定，當個資侵害發生時，在如果可行之情況下，控制者應即時（不得無故拖延）於知悉侵害時起72小時內，依第55條之規定，將個資侵害情事通報監管機關。但個資侵害不會對自然人之權利和自由造成風險者，不在此限。倘未能於72小時內通報監管機關者，應敘明遲延之事由。 三、控制者「知悉」時點之判斷標準為何？ 歐盟資料保護工作小組認為，當控制者對發生導致個人資料侵害的安全事件達「合理確信的程度」（reasonable degree of certainty）時，即應視為其已知悉。以具體事例而言，下列情況均屬所謂「知悉」： 在未加密個人資料的情況下遺失USB密鑰（USB Key），通常無法確定是否有未經授權者將獲致存取資料權限。即使控制者可能無法確定是否發生機密性侵害情事，惟仍應為通知，因發生可用性侵害之情事，且已達合理確信的程度。 故應以控制者意識到該密鑰遺失時起為其「知悉」時點。 第三人通知控制者其意外地收到控制者的客戶個人資料，並提供該揭露係未經授權之證據。當侵害保密性之明確證據提交控制者時，即為其「知悉」時點。如：誤寄之電子郵件，經非原定收件人通知寄件者之情形。 當控制者檢測到其網路恐遭入侵，並針對其系統進行檢測以確認個人資料是否遭洩漏，嗣後復經證實情況屬實，此際即屬「知悉」。 網路犯罪者在駭入系統後，聯繫控制者以索要贖金。在這種情況下，控制者經檢測系統並確認受攻擊後，亦屬「知悉」。 值得注意的是，在經個人、媒體組織、其他來源或控制者自我檢測後，控制者或將進行短暫調查，以確定是否發生侵害之事實。於此調查期間內所發現之最新侵害情況，控制者將不會被視為「知悉」。然而，控制者應儘速展開初步調查，以形成是否發生侵害事故之合理確信，隨後可另進行更詳盡之調查。 四、共同（聯合）控制者之義務及其責任分配原則 GDPR第26條針對共同控制者及其如何確定各自之法遵義務，設有相關規定，包括決定由哪一方負責遵循第33條（對主管機關通報）與第34條（對當事人通知）之義務。歐盟資料保護工作小組建議透過共同控制者間之契約協議，約明哪一方係居主要地位者，或須負責盡到個資侵害時，GDPR所定之通知義務，並載於契約條款中。 五、通報監管機關與提供資訊義務 當控制者通報監管機關個資侵害情事時，至少應包括下列事項 （GDPR第33條（3）參照）： 敘述個人資料侵害之性質，包括但不限於所涉之相關個資當事人、個資紀錄及其類別、數量。 傳達資料保護長（DPO）或其他聯絡人之姓名與聯絡方式，俾利獲得進一步資訊。 說明個資侵害可能之後果。 描述控制者為解決個資侵害業已採取或擬採行之措施，在適當情況下，酌情採取措施以減輕可能產生之不利影響。 以上乃GDPR要求通報監管機關之最基本事項，在必要時，控制者仍應盡力提供其他細節。舉例而言，控制者如認為其處理者係個資侵害事件之根因（root cause），此時通報並指明對象即可警示委託同一處理者之其他控制者。 六、分階段通知 鑒於個資事故之性質不一，控制者通常需進一步調查始能確定全部相關事實，GDPR第33條（4）爰設有得分階段通知（notification in phases）之規定。凡於通報時，無法同時提供之資訊，得分階段提供之。但不得有不必要之遲延。同理，在首次通報後之後續調查中，如發現該事件業已受到控制且並未實際發生個資侵害情事，控制者可向監管機關為更新。 七、免通報事由 依據GDPR第33（1）條規定，個資侵害不會對自然人之權利和自由造成風險者，毋庸向監管機關通報。如：該遭洩露之個人資料業經公開使用，故並未對個人資料當事人構成可能的風險。 必須強調的是，在某些情形下，未為通報亦可能代表既有安全維護措施之缺乏或不足。此時監管機關將可能同時針對未為通報（監管機關）或通知（當事人），以及安全維護措施之缺乏或不足，以違反第33條或（及）34條與第32條等獨立義務規定為由，而依第83條4（a）之規定，併予裁罰。 參、事件評析 一、我國企業於歐盟設有分支機構或據點者，宜指派專人負責法遵事宜 揆諸GDPR前揭規定，當個資侵害發生時，控制者應即時且不得無故拖延於知悉時起72小時內，將個資侵害情事通報監管機關。未能履踐義務者，將面臨最高達該企業前一會計年度全球營業額之2%或1千萬歐元，取其較高者之裁罰。我國無論金融業、航運業、航空運輸業、電子製造業及進出口貿易業者等，均或有於歐盟成員國境內或歐洲經濟區（European Economic Area）當地設立子公司或營業據點。因此，在GDPR法遵衝擊的倒數時刻，指派具瞭解GDPR規定、當地個資隱私法遵規範、擅長與隱私執法機構溝通及充要語言能力者專責法遵業務實刻不容緩。蓋此舉可避免我國企業母公司鞭長莫及，未能及時處置而致罹法典之憾。 二、全面檢視個資業務流程，完備個資盤點與風險評鑑作業，掌握企業法遵現況 企業應全面檢視業務流程，先自重要核心業務中析出個資作業流，搭配全面個資盤點，並利用盤點結果進行風險評鑑，再針對其結果就不同等級之風險採行相對應之管控措施。此外，於全業務流程中，亦宜採行最小化蒐集原則，避免蒐集過多不必要之個人資料，尤其是GDPR所定義之敏感個資（如：種族、民族血統、政治觀點、宗教信仰、哲學信仰、工會會員資格等個人資料，及遺傳資料的處理，用於識別特定自然人之生物識別資料、健康資料、性生活、性取向等）或犯罪前科資料，俾降低個人資料蒐集、處理、利用、檔案保存及銷燬之全生命週期流程中的風險。此舉亦契合我國個人資料保護法第5條所揭櫫之原則。 三、立法要求一定規模以上之企業須通過個資隱私法遵第三方認（驗）證，並建置認證資訊公開平台 鑒於國際法遵衝擊以及隱私保護要求之標準線日漸提升，我國企業除自主導入、建置並維運相關個資保護與管理制度以資因應，更有賴政府透過法令（如：修正個人資料保護法）強制要求一定規模以上之企業通過第三方專業驗證，俾消弭風險於日常準備之中。蓋我國具一定規模以上企業，無論其係屬何種業別，一旦違反國際法遵要求，遭致鉅額裁罰，其影響結果將不僅止於單一企業，更將嚴重衝擊該產業乃至於國家整體經貿發展。職是，採法律強制要求企業定期接受獨立、公正及專業第三方認（驗）證，咸有其實益性與必要性。
世界衛生組織發布人工智慧於健康領域之監管考量因素文件，期能協助各國有效監管健康領域之人工智慧世界衛生組織（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） 開發者於制定人工智慧創新與部署路線圖之期間，需考慮開發可近用且具有充足資訊之平台，以於適合與適當情況下促進利害關係人間之參與及協作；為加速人工智慧領域實務作法之進化，透過參與及協作來簡化人工智慧監管之監督流程即有必要。