歐盟個人資料保護小組提出智慧電錶隱私指導原則
由於近年來運算技術的成熟，使得許多仰賴高運算技術的產業有重新發展的契機，智慧電網正是其中一例；而智慧電網所涉及的資訊繁多，例如個人資產的位址資訊可能會被納入電網中作定位與分析，因此其所衍伸的個人資料與隱私保護議題，近來備受重視。
歐盟個人資料保護小組（Article 29 Data Protection Working Party）於今年四月針對智慧電錶的隱私議題，提出指導建議（Opinion 12/2011 on Smart Metering），並明確指出，電網中的電錶會有一組獨特的識別碼（Meter Identification Number），此可連結至特定用戶，因此由電錶蒐集到的資訊，大部分都符合歐盟個人資料保護指令（Directive 95/46/EC）中的「個人資料」（Personal Data）。
倘若要對透過電錶所蒐集的資料進行處理，必須要基於充分告知（Fully-informed），取得用戶同意；也應該讓用戶依照意願自主行使同意或撤銷該同意，此會涉及電錶設計的方式，該小組建議可在用戶端電錶的控制鑲板上設置「按鈕」（Push Button），讓用戶得隨時選擇同意與否。另外，智慧電錶亦具有設定資料傳輸頻率的功能，此攸關資料被蒐集之範圍是否妥適，舉例言之，倘若用戶與電網服務提供者之契約，是全天以同一個費率計算電價，則其電錶會把整日用電量讀成一筆資料，反之倘若用戶是採用一天分不同時段不同費率的方式，則該電錶會每日分成數個時段讀取用電量；惟在供應端可遠端遙控這些電錶讀取頻率的情況下，應確保這些資料僅於系統運行所需，方傳輸至供應端供讀取。
其他的電表資訊處理細節，事實上類似於電信事業處理交通資訊或位址資訊的作法，例如不再用到的電錶資訊，應盡速刪除之；供應端也必須訂定書面的資料保存政策、評估所需電錶資訊之目的、並在該目的範圍內以最小限度原則保存之。
本文為「經濟部產業技術司科技專案成果」
張乃文
主任 編譯整理
HL Chronicle of Data Protection，2011年04月18日，http://www.hldataprotection.com/2011/04/articles/international-eu-privacy/europes-article-29-working-party-issues-smart-meter-guidelines/index.html，最後瀏覽日：2011年07月29日
根據國際間重要農糧組織ISAAA（International Service for the Acquisition of Agri-Biotech Applications）所公布的2004年統計報告，全球基改作物栽種面積已達八千一百萬公頃，在2003年僅有六千七百萬公頃，成長幅度高達20％，尤其是在開發中國家。菲律賓是亞洲第一個支持商業化生產基因改造食物的國家，從2000年起即開始商業交易基因改造作物。由於其所研發之轉殖”IR-72”稻米品種栽培並不普遍，也未被消費者、農夫及麵粉業者廣泛地接受，因此不合適商業化生產，雖然菲律賓嘗試其他較受歡迎的品種來進行基改轉殖，但迄今尚未成功。 基於基因稻米對於環境安全和人體健康所帶來的影響是無法預知的，綠色和平組織抗議菲律賓政府加速推動生技農作物的計畫。菲律賓所面臨的挑戰不單僅是綠色和平的抗議，另一個因素因為氣候的不穩定而影響了稻米的產量，今年生產量僅148萬噸，距離目標?151萬噸，因此仍需仰賴進口稻米來彌補這不足的差距。 菲律賓稻米研究中心執行長Leo Sebastian認為，基改稻米並不是解決稻米供應不足的唯一方式，引介栽種高生產量的稻米品種或者改善灌溉系統等都是可行的方式。
昇陽進入開放原始碼 Solaris 時代昇陽公司本月十四日把 500 多萬行 Solaris 核心 (kernel) 的原始碼張貼在 OpenSolaris 網站上。不過，一些原始碼元件，像是安裝程式與管理工具，因為仍在逐行檢視以免專利侵權問題，稍後才會推出。 Solaris 是使用率相當廣的一種 Unix 衍生版本，在一九九○年代末期網路泡沫時期大行其道，但後來隨開原碼作業系統 Linux 竄起而式微。同時，微軟的 Windows 作業系統，也蠶食著昇陽的市占率。為了讓 Solaris 成為開放原始碼軟體，昇陽積極拉攏軟體開發人員，軟體開發人數增多，可能引來更多的使用者、更多的合作夥伴，以及更多的軟體開發者。然而，要與氣勢正旺的 Linux 競爭，並非易事。 Solaris 開發工程僅傾昇陽一家公司之力，但 Linux 幕後卻有廣大的開發人員社群支持。 Quandt Analytics 分析師 Stacey Quandt 說，與外部程式設計師分享權力，是昇陽必須通過的考驗。對昇陽來說，真正的挑戰是，昇陽是否真能容納局外人貢獻的修補程式，而且不叫昇陽經驗老到的工程師加以改寫。 OpenSolaris 是昇陽自行研發的專屬計畫，但不表示一定會失敗。 IBM 即曾經以 Eclipse 程式設計工具為中心，建立起活力十足的開原碼社群，就是成功的例子。昇陽雖來不及按原訂計畫在二○○四年推出 OpenSolaris ，但已推動一些配套措施，包括在今年一月發布稱為 DTrace 的元件，提供詳細的效能分析；吸引一百五十位外部程式設計人員參與 OpenSolaris 測試計畫；並成立由五人組成的社群顧問委員會，其中兩席是昇陽的代表。
英國展開醫療器材監管公眾意見徵詢並公布《人工智慧軟體醫材改革計畫》英國藥物及保健產品管理局（Medicines and Healthcare Products Regulatory Agency, MHRA）於2021年9月16日展開期待已久的「英國醫療器材監管的未來」公眾意見徵詢（Consultation on the Future of Medical Devices Regulation in the United Kingdom），並公布「人工智慧軟體醫材改革計畫」（Software and AI as a Medical Device Change Programme）。英國欲從醫療器材上市前核准至其壽命結束進行監管改革，徹底改變一般醫療器材與人工智慧軟體醫療器材之監管方式。意見徵詢已於2021年11月25日結束，而該修正案預計於2023年7月生效，與英國針對醫療器材停止使用歐盟CE（Conformité Européenne, 歐洲合格認證）標誌並要求採用英國UKCA（UK Conformity Assessed, 英國合格評定）標誌的日期一致。 人工智慧軟體醫材改革計畫則包含十一個工作項目（work package，下稱WP），WP1與WP2分別為監管資格與監管分類，皆涉及監管範圍之劃定；WP3與WP4分別涉及軟體醫材上市前與上市後，如何確保其安全性與有效性的監管之研究；WP5針對軟體醫材之網路安全進行規範；WP6與WP7涉及加速創新軟體醫材審核上市之特別機制，分別為類似「創新藥品藥證審核與近用途徑」 （innovative licensing and access pathway）的機制，以及允許適時上市並持續研究監控風險的「氣閘分類規則」（airlock classification rule）；WP8為確保智慧型手機之健康應用程式安全、有效與品質之規範研究；WP9~WP11則分別針對人工智慧軟體醫材之安全與有效性、可解釋性（interpretability）以及演進式（adaptive）人工智慧進行法規調適之研究。 MHRA預計透過指引、標準、流程之公布而非立法方式實現其監管此領域的目標。MHRA亦透露，針對上述工作項目，其已與重點國家和國際機構進行研究合作，已有不少進展即將公布。
經濟合作與發展組織發布《促進AI可歸責性：在生命週期中治理與管理風險以實現可信賴的AI》經濟合作與發展組織（Organisation for Economic Co-operation and Development, OECD）於2023年2月23日發布《促進AI可歸責性：在生命週期中治理與管理風險以實現可信賴的AI》（Advancing accountability in AI: Governing and managing risks throughout the lifecycle for trustworthy AI）。本報告整合ISO 31000：2018風險管理框架（risk-management framework）、美國國家標準暨技術研究院（National Institute of Standards and Technology, NIST）人工智慧風險管理框架（Artificial Intelligence Risk Management Framework, AI RMF）與OECD負責任商業行為之盡職調查指南（OECD Due Diligence Guidance for Responsible Business Conduct）等文件，將AI風險管理分為「界定、評估、處理、治理」四個階段： 1.界定：範圍、背景、參與者和風險準則（Define: Scope, context, actors and criteria）。AI風險會因不同使用情境及環境而有差異，第一步應先界定AI系統生命週期中每個階段涉及之範圍、參與者與利害關係人，並就各角色適用適當的風險評估準則。 2.評估：識別並量測AI風險（Assess: Identify and measure AI risks）。透過識別與分析個人、整體及社會層面的問題，評估潛在風險與發生程度，並根據各項基本價值原則及評估標準進行風險量測。 3.處理：預防、減輕或停止AI風險（Treat: Prevent, mitigate, or cease AI risks）。風險處理考慮每個潛在風險的影響，並大致分為與流程相關（Process-related）及技術（Technical）之兩大處理策略。前者要求AI參與者建立系統設計開發之相關管理程序，後者則與系統技術規格相關，處理此類風險可能需重新訓練或重新評估AI模型。 4.治理：監控、紀錄、溝通、諮詢與融入（Govern: Monitor, document, communicate, consult and embed）。透過在組織中導入培養風險管理的文化，並持續監控、審查管理流程、溝通與諮詢，以及保存相關紀錄，以進行治理。治理之重要性在於能為AI風險管理流程進行外在監督，並能夠更廣泛地在不同類型的組織中建立相應機制。