芬蘭Skene計畫聚焦電玩遊戲產業
依據統計，2011年全球電玩遊戲產值約516億歐元，是娛樂產業中成長最快速的領域，行動遊戲（mobile gaming）也因智慧型手機普及率之提升，在其中扮演舉足輕重的角色。有鑒於此，芬蘭政府於今（2012）年啟動Skene－遊戲補給計畫（Skene－Game Refueled，以下簡稱Skene計畫）促進其遊戲產業的研發創新。
Skene計畫預計從今（2012）年起實施至2015年，將投入7000萬歐元資金補助，其中3000萬歐元由芬蘭的創新補助機關－國家技術創新局（teknologian ja innovaatioiden kehittämiskeskus，Tekes）提供。該計畫致力於創造國際級遊戲及娛樂聚落的形成，期能使芬蘭企業成為國際遊戲產業生態中的重要成員。芬蘭政府欲藉由此一計畫，突破芬蘭Rovio公司過往開發「憤怒鳥」（angry bird）遊戲之偶發性的成功模式，讓芬蘭遊戲產業獲得長期永續的商業效益。Tekes於本計畫中特別強調知識分享的重要，認為此計畫的核心目的在於促進相關知識或經驗，得以在研究機構的專家、遊戲公司乃至其他產業間有系統的傳遞。
事實上芬蘭推動Skene計畫之動機，除了著眼於遊戲產業本身所帶來的龐大商業效益外，也看到遊戲開發過程中產出工具在其他產業之模型、模擬實驗、使用者介面設計及傳統軟體開發方面之助益（例如在醫療照護產業、運算服務之運用或協助教育環境建構或運動訓練等）。由此觀之，芬蘭政府透過Skene計畫推動遊戲產業研發創新之考量，尚包括帶動其他產業之提升的深遠思考。
近年來我國遊戲產業在商業上的表現逐漸受到各界重視，在此背景下，芬蘭Skene計畫無論在具體作為及其背後的思維模式上，皆有我國可以參考借鏡之處。
本文為「經濟部產業技術司科技專案成果」
微軟在文書處理軟體的獨占鰲頭局勢已漸漸產生變化。 首先，昇陽（Sun）與Google簽下合作協議將推廣在網路上免費使用的文字處理軟體「OpenOffice」，兩家的合作對微軟OFFICE套裝軟體營收將會有很大的殺傷力。 再者，十月份正式推出的OpenOffice.org 2.0軟體，是第一套可穩定支援新XML開放文件格式（OpenDocument Format；ODF）標準的開放原始碼辦公室軟體。ODF是由OASIS（Organization for the Advancement of Structured Information Standards；結構化資訊標準推動組織）所制定的，採用XML儲存格式，具備共用性、跨平台等特性，並支援文書處理和資料庫等各種儲存格式。OpenOffice.org 2.0軟體還可以支援36國語言，又可在Microsoft Corp's Windows，Linux，Sun's Solaris等多家系統上執行 。 此外，美國麻薩諸塞州宣布自2007年起該州政府文件只能存成OpenDocument或Adobe的PDF兩種格式，因此該州所屬機關必須汰換不支援這2種格式的軟體，當然包括微軟OFFICE套裝軟體，如此一來微軟損失至少數百萬美元以上的商機。如果其他政府部門跟進，這不僅意味ODF的一大勝利，也將重挫微軟的龍頭地位。而Corel及Novell也重申支持OpenDocument格式。 此些舉動對於微軟的根基大業OFFICE套裝軟體可真是成心頭大患。
德國聯邦內政部提出「資訊科技安全法」(草案)，保障關鍵基礎設施及資訊安全德國聯邦內政部繼與德國聯邦經濟暨能源部與交通暨數位基礎設施部共同擬定之「數位議程2014 - 2017」(Digitale Agenda 2014 – 2017)政策裏，於本年8月19日提出資訊科技安全法(草案)(IT-Sicherheitsgesetz)。該草案的提出目的為保障德國公民與企業使用的資訊系統安全，特別是在全國數位化進程中，攸關國家發展的關鍵基礎設施。德國內政部長de Maizière在新聞發表會上，宣稱要讓德國成為全球資訊科技系統及數位基礎設施安全的先驅與各國的模範。除外，亦欲藉此強化德國資訊科技安全企業的競爭力，提升外銷實力。 該草案的主要對象係關鍵基礎設施營運者(Kritische Infrastrukturbetreiber)，例如在能源、資訊科技、電信、運輸和交通、醫療、水利、食品、金融與保險等領域的企業。「關鍵基礎設施」的定義並未涵蓋德國聯邦政府部門之間使用的數據通信系統。不過，究竟係在這些基礎設施領域的哪些企業該受到資訊科技法的約束，德國內政部將陸續與各相關部會研討後再以行政法規的方式明確表列出來。 關鍵基礎設施企業必須採取適當的保護措施以保障關鍵基礎設施的正常運行。所採取的保護措施可符合同業或同業公會裡所認可的最新資訊安全標準，且得符合一定的付出成本比例。不過衡量標準，最後還是得由德國聯邦資訊安全局(Bundesamt für Sicherheit in der Informationstechnik, BSI)〉做認定。上述之企業需兩年內完成安全防護措施的設置。為防止電信系統非法入侵，該草案也修增德國電信法(Telekommunikationsgesetz)為施予電信業者更高的資訊安全防護標準。針對網際網路服務提供者(Internet Service Providers, ISP)也特別施加設置防範駭客攻擊的尖端防護措施義務。 關鍵基礎設施業者的資訊安全系統均須透過德國聯邦資訊安全局(Bundesamt für Sicherheit in der Informationstechnik, BSI)每兩年定期審核，若沒通過則會被要求依德國聯邦資訊安全局的標準去處裡該安全漏洞。 若是上述業者的資訊安全系統有受損，並且可導致關鍵基礎設施的故障或損毀，該企業需通報德國聯邦資訊安全局，且該記錄可匿名化。但是，若是因駭客攻擊直接導致關鍵基礎設施的故障或損毀，該企業則需立即通報德國聯邦資訊安全局，不可匿名。
英國資訊委員辦公室（ICO）發布沙盒執行過程中所觀察到的關鍵議題2019年9月英國資訊委員辦公室（Information Commissioner's Office, ICO）啟動沙盒計畫（ICO Sandbox）測試階段（beta phase），由ICO所選10個測試專案，透過解決當今社會問題，例如如何減少暴力犯罪、大學如何促進學生的心理健康、新技術如何改善醫療保健等，期能促進公眾利益。 各專案在滿足創新性和可行性前提下，同時也面臨著複雜的資料保護議題，因此ICO持續與各專案溝通，提供其應用現有個資保護指引之建議，如歐盟一般資料保護規則之資料保護影響評估指導文件（Guide to the GDPR - Data protection impact assessment）、資料保護自我評估工具包（Data protection self-assessment toolkit）等。自2019年3月底開始（受理申請）迄今，ICO沙盒執行過程中所觀察到的關鍵議題如下： 公部門資料應用效益：部份參與者正在克服與公部門進行歷史資料共享，或是如何整合應用大數據等。個人資料與新技術應用，必須與資料主體的權利和自由進行權衡。 同意：確保各方對於「同意」（Consent）之理解，以弭平差異，同時向公眾提供透明資訊。 新技術的挑戰：應用語音生物辨識（voice biometrics）、臉部辨識技術（facial recognition technology, FRT）等，需要在適當基礎上處理特殊類別資料。 資料分析（Data analytics）：以符合資料保護的方式進行資料分析，處理特殊類別資料的適法性，評估處理過程中的風險，並檢查可能用於資料分析的資料來源，確保符合目的之應用。 未來的6個月，ICO將持續與各專案合作，使其為有效的解決方案，為公眾提供創新合規之產品與服務，並成為未來結合資料保護和創新應用之規劃藍圖，以奠定隱私保護的基石。
世界衛生組織發布人工智慧於健康領域之監管考量因素文件，期能協助各國有效監管健康領域之人工智慧世界衛生組織（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） 開發者於制定人工智慧創新與部署路線圖之期間，需考慮開發可近用且具有充足資訊之平台，以於適合與適當情況下促進利害關係人間之參與及協作；為加速人工智慧領域實務作法之進化，透過參與及協作來簡化人工智慧監管之監督流程即有必要。