澳洲國家交通委員會針對駕駛法規之修正進行公眾諮詢，聚焦自駕系統實體法律義務
澳洲國家交通委員會(National Transport Commission, NTC)於2017年10月3日提出「修正駕駛法律以支持自動駕駛車輛(Changing driving laws to support automated vehicles)」討論文件，向相關政府機關與業界徵詢修正駕駛法規之意見。此文件目的在於探討法規改革選項，並釐清目前針對駕駛人與駕駛行為法規對於自駕車之適用，並試圖為自動駕駛系統實體（automated driving system entities, ADSEs）建立法律義務。文件中並指出改革上應注意以下議題：
- 目前車輛法規皆以人類駕駛為前提；
- 自動駕駛系統並不具有法律人格，無法為其行為負法律責任；
- 目前的法律並未提供法律實體之定義或規範（即自動駕駛系統實體ADSEs）來為自動駕駛系統行動負責；
- 目前有些法律上人類駕駛應負之義務，無法直接於自動駕駛時由ADSEs負擔；
- 車輛之安全義務於自動駕駛時，可能需由非駕駛之他人執行；
- 法律中並未定義自動駕駛系統車輛的「控制」與「恰當控制」；
- 目前沒有規範何時人類應有義務將駕駛控制權力自自動駕駛系統轉移回來，來確保人類駕駛保持足夠之警覺性；
- 目前的遵循與實施規範可能不足以確保自動駕駛系統的安全運作。
NTC並提出建議應定義自動駕駛系統之法律實體，重新規範人類與自動駕駛系統法律實體間的義務。澳洲國家交通委員會將進一步將諮詢結果與法律改革選項於2018年5月提供給澳洲交通部。
本文為「經濟部產業技術司科技專案成果」
柯亦儒
組長 編譯整理
NATIONAL TRANSPORT COMMISSION [NTC], Changing driving laws to support automated vehicles: discussion paper (2017) , http://www.ntc.gov.au/Media/Reports/(E5695ACE-993C-618F-46E1-A876391B8CD9).pdf (last visited Nov. 20, 2017).
National Transport Commission, NTC seeks feedback on changing driving laws to support automated vehicles (Oct. 3, 2017), http://www.ntc.gov.au/about-ntc/news/media-releases/ntc-seeks-feedback-on-changing-driving-laws-to-support-automated-vehicles/ (last visited Nov. 20, 2017).
2018年英國頒布電子通訊之網路與資訊系統規則（The Network and Information Systems Regulations 2018），該規則實施歐盟2016年網路與資訊系統安全指令（Network and Information Security Directive, NIS Directive）。該規則分成幾個部分，第一部分是介紹性條文，例如介紹網路及資訊系統之定義：「（a）2003年通訊法（Communications Act 2003）第32條第1項所指的電子通訊網路；（b）一組或多組互聯或相關設備，其中之設備或程序根據程式自動化處理數位資料；（c）為操作、使用、保護和維護目的，由（a）或（b）款所涵蓋的儲存、處理、檢索或傳輸的數位資料。」 第二部分是英國政府相關組織架構規定，包括網路及資訊系統的國家政策（The NIS national strategy）、國家權責機關的指定（Designation of national competent authorities）、單一聯絡點的指定（Designation of the single point of contact）、電腦安全事件應變小組的指定（Designation of computer security incident response team）、執行機關的資訊分享（Information sharing–enforcement authorities）、北愛爾蘭的資訊分享（Information sharing–Northern Ireland）。 第三部分則是基本服務營運商（類似於我國的關鍵基礎設施營運商）與其職責，包括基本服務營運商的確定、營運權廢止、基本服務營運商的安全維護職責、事故通報的責任等。根據第8條第1項之規定，如果營運商提供本規則附表2所載明的基本服務（包括電力、石油、天然氣、航空運輸、船務運輸、鐵路運輸、公路運輸、醫療健康、數位基礎設施等），並且符合基本服務一定門檻要求者，則該廠商即被視為基本服務營運商（operator of an essential service, OES）。舉例而言，規章之附表2第1項載明，營運商提供電力供應之基本服務者，其一定門檻要求包括：若營運商位於英國，符合「為英國國內超過25萬名消費者提供電力服務」或「輸電系統的發電量大於或等於2 gigawatts」之條件者，該營運商即為基本服務營運商（OES）；若營運商位於北愛爾蘭，則應「依據北愛爾蘭1992年的電力法規命令取得供電執照」，且「為北愛爾蘭境內超過8千名消費者提供電力服務」，或符合「發電量大於或等於350 megawatts」等條件，則該營運商即為基本服務營運商（OES）。 再者，若營運商符合第8條第3項所列之條件，則可由主管機關指定為基本服務營運商（OES）。此外，主管機關可根據第9條撤銷基本服務營運商（OES）的認定，基本服務營運商（OES）必須履行第10條規定的安全維護責任，並對於第11條規定的事件負有事故通報的責任。 第四部分則是數位服務，包括相關數位服務提供者、成員國跨境合作與行動、向資訊專門委員進行登記（Registration with the Information Commissioner）、資訊通知（Information notices）、檢查權限、違反義務之強制執行、裁罰、對行政機關裁罰決定之獨立審查、罰鍰之執行、費用、裁罰程序、執法行為的一般考量因素、審查與報告。
世界衛生組織發布人工智慧於健康領域之監管考量因素文件，期能協助各國有效監管健康領域之人工智慧世界衛生組織（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） 開發者於制定人工智慧創新與部署路線圖之期間，需考慮開發可近用且具有充足資訊之平台，以於適合與適當情況下促進利害關係人間之參與及協作；為加速人工智慧領域實務作法之進化，透過參與及協作來簡化人工智慧監管之監督流程即有必要。
因應2020年社會實現自動駕駛，日本訂定自動駕駛制度整備大綱日本IT綜合戰略本部及官民資料活用推進本部於4月17日公佈「自動駕駛制度整備大綱」。大綱設定2020年至2025年間，日本社會實現自動駕駛下，所需檢討修正之關連法制度。 本大綱中，係以2020年實現自動駕駛至等級4為前提（限定場所、速度、時間等一定條件下為前提，系統獨自自動駕駛之情形），以在高速公路及部分地區之道路實現為條件設定。社會實現自動駕駛有以下課題需克服： 道路交通環境的整備：以自駕系統為行駛，一般道路因為環境複雜，常有無法預期狀況發生，導致自駕車的電腦系統無法對應。 確保整體的安全性：依據技術程度，設定一般車也能適用之行駛環境、設定車輛、自動駕駛之行駛環境條件以及人之互相配合，以達成與一般車相同之安全程度為方針下，由關係省廳間為合作，擬定客觀之指標。此一指標，並非全國一致，應就地方之特性，設定符合安全基準及自動駕駛行駛環境條件，建構整體確保安全之體制。 防止過度信賴自駕系統：訂定安全基準，使日本事件最先端自動車技術擴及於世界，訂定包含自駕系統安全性、網路安全等自動駕駛安全性要件指針。 事故發生時之法律責任：自動駕駛其相關人為駕駛人、系統製造商、道路管理者等多方面，其法律責任相對複雜化。現在係以被害人救濟觀點，至等級4為止之自動駕駛，適用自動車損害賠償責任險（強制責任險）方式，但是民法、刑法及行政法等法律全體之對應，仍為今後之課題，必須為早期快速處理。為了強化民事責任求償權行使、明確刑事責任之因果關係、並實現車輛安全性確保、避免所有人過度負擔等，車輛行駛紀錄器之裝置義務化、事故原因究明機制等，關係機關應合作為制度檢討。 本大綱最後並提出，在自動駕駛技術快速發展下，就其發展實際狀況應為持續半年1次召開會議檢討檢討。
MPAA 藉由 BT 網站伺服器記錄對 P2P(BT) 軟體用戶提起訴訟追蹤、定位、起訴，所有 P2P(BT) 軟體使用者的噩夢再次上演。全美製片業團體「美國電影協會」 ( Motion Picture Association of America ； MPAA ) 在 8 月 25 日對美國境內 286 位居民提起訴訟，成為首宗利用 P2P(BT) 網站伺服器記錄 ( server logs ) 追蹤 ( track down ) 盜版電影下載者的案例。 今年 2 月，著名 BT 網站 LokiTorrent 與 MPAA 的大戰告一段落。德州法院下令 LokiTorrent 關閉網站外，並命令 LokiTorrent 將伺服器記錄轉交給 MPAA 的調查員 ( investigator ) 。 MPAA 的發言人聲稱本月 25 日的訴訟與此事件無關，但所有人都明白 MPAA 正是憑此線索，最終找到了 P2P(BT) 用戶的行蹤。好萊塢希望藉此行動阻嚇免費下載電影的行?， MPAA 資深副總裁 John Malcom 聲稱「下載盜版電影的人要當心了，當你為著作權侵害行為時，網路上並不會有朋友站出來替你撐腰。」 儘管 P2P(BT) 軟體背負著助長盜版的惡名，但 P2P(BT) 的合法用途也在逐漸增加，例如使用 P2P(BT) 技術分發 ( distribute ) 開放原始碼軟體 ( open-source software ) ，網路瀏覽器軟體公司 Opera 即在新版的程式中內建了此種技術。 BT 技術的發明人 Bram Cohen 曾警告用戶，使用 P2P(BT) 軟體下載盜版是個蠢主意，因?軟體在設計時並未刻意隱藏用戶的識別資訊，這也是為何 MPAA 此次能憑藉著伺服器記錄對用戶提起訴訟的主要原因。