IBM同意中國大陸政府檢視部份產品原始碼
近年來中國大陸政府為了資安考量，制訂相關法規要求外國科技公司進入中國大陸市場時必須提供程式原始碼，避免他方非法(例如利用病毒)透過電腦軟體進入中國大陸的系統和資料。
IBM公司近日發表聲明，允許特定國家在其嚴格的監控下，檢視其部份產品的軟體原始碼，確保產品沒有資訊安全的漏洞，中國大陸也在這些特定國家之列。這是美國重要的科技大廠，首次公開同意遵守中國大陸政府對於外國技術的資訊安全審查，然而此舉讓美國政府與其他矽谷科技公司頗有微詞。
IBM開放檢視其程式碼的對象為中華人民共和國工業與信息化部。IBM在聲明中表示，原始碼的檢視必須在IBM公司內，於無網路連線並受IBM安全應用程式監控的環境下進行，並保證這些軟體原始碼不會被釋出、被複製，或以任何方式改作。在嚴格的環境和時間限制下，IBM不會讓中國大陸政府有機會接觸其客戶資料庫，也不會涉及後門程式(back door)。至於會提供哪些產品的原始碼檢視，或中國大陸官方可檢視的時間有多長，IBM尚無明確說明。事實上IBM並非唯一提供程式碼的科技公司，微軟公司早在2003年即允許中國大陸、俄國、英國等國家檢視微軟Windows部分產品的原始碼。
有市場分析公司指出，IBM為降低智慧財產權被複製的風險，所釋出的原始碼可能只涉及基本功能，不包含專有的演算碼，且像IBM此類的公司，應該擁有閉源軟體(closed-source)或特別的軟體以嚴密地維護底層的原始碼，避免中國大陸政府藉由檢視原始碼執行反向工程(Reverse Engineering)。
IBM公司願意提供中國大陸政府檢視部分產品原始碼，目的在於展示其產品安全性，試圖擴展IBM在中國大陸的商業版圖。IBM旗下的雲端運算平台Bluemis未來將與中國大陸的數據中心服務公司—北京世紀互聯寬帶數據中心有限公司合作。該公司同時也是微軟在中國大陸的合作夥伴。
林昭如
專案經理 編譯整理
IBM says some governments allowed to review its source code, RUTERS, Oct.16 ,2015, http://www.reuters.com/article/2015/10/17/us-ibm-china-wsj-idUSKCN0SA1BZ20151017 (last visited Oct. 19, 2015)
IBM Gives the Chinese Government Access to Software Code, Bloomberg Business,, Oct. 17,2015 http://www.bloomberg.com/news/articles/2015-10-16/ibm-gives-limited-access-of-software-code-to-chinese-government (last visited Oct. 19, 2015)
IBM Raises Eyebrows, Opens Source Code Access To China: Here’s Why, Oct. 18,2015, http://www.techtimes.com/articles/96776/20151018/ibm-raises-eyebrows-opens-source-code-access-to-china-here-s-why.htm (last visited Oct. 19, 2015)
德國最高法院在2018年2月27日判決，Google在搜尋結果連結顯示之前，並無須確認該網站是否存在毀謗性言論，亦即，Google沒有義務事先審查搜尋結果中連結的內容。 此案件的背景是由兩個受到網路言論攻擊的人所提出，其主張為防止其他網路使用者攻擊他們言論的網站出現在Google搜尋結果的連結上，因此希望Google其中的一個部門—Alphabet公司，設置搜尋過濾器，就用戶曾經在網站上發表過不良評論以及損害賠償的相關資訊不會在未來的搜尋結果出現。 本案涉及關於「被遺忘權」(“Right To Be Forgotten”)的討論，所謂被遺忘權是由2014年5月，歐盟法院(ECJ)所作成之裁定，即人們可以要求Google和微軟Bing（MSFT.O）等搜尋引擎於搜尋人名出現的網頁結果中，刪除不適當或不相關的訊息。 本案中，對於Google沒有對搜尋結果進行過濾，Google是否因此有侵害被遺忘權之爭議，德國最高法院表示，搜尋引擎經營者僅須於收到明確且具識別性侵犯個人權利的通知時，採取相關行動即可，並毋須事先檢查該網站之內容是否合法。蓋立法者及社會皆普遍認為，若將搜尋引擎審查網站的內容定為其一般性義務，則其商業模式的本質將備受嚴重質疑，且又由於數據具有管理上的困難性，若無此類搜尋引擎的幫助，人們不可能在網路上獲得有實質有意義的使用，因此搜尋引擎不須將此列為其義務。
電子支付指令可望具有書面支付憑證的同等效力中國大陸為推動商業銀行電子支付業務健全發展、保障電子支付業務中當事人之權益、防範電子支付業務風險並確保銀行與客戶之資金安全， 繼 中國銀行業監督管理委員會 （銀監會）於 5 月 19 日發佈《電子銀行業務管理辦法（徵求意見稿）》（草案）之後，中國人民銀行 於 6 月 9 日公佈《電子支付指引（徵求意見稿）》 （草案）， 公開諮詢大眾的意見。該草案規定電子支付指令 ( Electronic Payment Instruction, EPI ) 與書面支付憑證可以相互轉換，兩者具有同等效力。 為達到安全控制，該草案不僅要求銀行採用規定的資訊安全標準、技術標準、業務標準，建立有效的管理制度，同時要求確保業務處理系統的安全性、交易資料的不可否認性、資料儲存的真實性、客戶身份的辨識性，以妥善管理安全認證資料。此外，該草案還對支付過程中所發生的錯誤與責任作了詳細規定。 在風險控制方面， 銀行亦應針對不同客戶，在電子支付業務類型、單筆支付金額和每日累計支付金額等方面作出合理限制。銀行通過網路提供網上支付業務，公司行號與個人客戶之單筆支付金額不得超過 5 萬元。 該草案所稱電子支付是指公司行號或個人通過電子終端機，直接或間接向銀行業金融機構發出支付指令，實現貨幣支付與資金轉移。 電子支付的業務類型分為網上支付（透過網路）、電話支付、移動支付（透過行動通訊設備）、銷售點終端 (point of sale) 交易、自動櫃員機 (ATM) 交易和其他電子支付。
日本政府擬修法全面禁止濫發商業電子郵件為解決日益嚴重的騷擾郵件問題，日本總務省於今（2008）年2月29日向國會提出「特定電子郵件送信適當化法修正案（特定電子メール送信適正化法改正案）」，將全面禁止未經收件人事前同意而擅自寄發宣傳廣告郵件，並將海外寄送之騷擾郵件列入適用範圍。 依據現行法之規定，未取得收件人同意寄送廣告或宣傳之郵件時，必須在主旨上標明「未經同意廣告」，並負有標示寄件人名稱、電話號碼之義務。如收件人發出拒絕收件之通知時，即禁止再傳送相關郵件；違反者將處以一年以下拘役或100萬日圓以下罰金。然而，一旦收件人回覆拒絕收件，將使業者察知該郵件帳號為有效帳號；故收件人對騷擾郵件大多不予理會，但如收件人未回覆拒絕收件之訊息時，該騷擾郵件仍得合法寄送。此外，依據調查，目前騷擾郵件中，有九成的電腦郵件及半數的行動電話簡訊，均是從海外所發出，而迴避了現行法之規範。 因此，本次修正草案明定全面禁止未經同意擅自傳送商業電子郵件至他人電腦或行動電話；即使取得收信同意，如中途拒絕時，其後即禁止再傳送郵件。此外，草案並課以郵件中應明示寄件者姓名、名稱及電子郵件地址，並要求須保存如何取得收件者同意之相關記錄。現行法不適用之海外寄送之騷擾電子郵件，也將與日本國內電子郵件受到相同規範。如偽裝電子郵件地址而傳送郵件時，或經總務省要求改善而未加以改善時，將處以最高3000萬日圓罰金。本修正法案預定於2008年中施行。
世界衛生組織發布人工智慧於健康領域之監管考量因素文件，期能協助各國有效監管健康領域之人工智慧世界衛生組織（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） 開發者於制定人工智慧創新與部署路線圖之期間，需考慮開發可近用且具有充足資訊之平台，以於適合與適當情況下促進利害關係人間之參與及協作；為加速人工智慧領域實務作法之進化，透過參與及協作來簡化人工智慧監管之監督流程即有必要。