美國國家標準暨技術研究院規劃建立「人工智慧風險管理框架」，並徵詢公眾對於該框架之意見
美國國家標準暨技術研究院（National Institute of Standards and Technology, NIST）為管理人工智慧對於個人、組織以及社會所帶來之風險，於2021年7月29日提出將建立「人工智慧風險管理框架」（Artificial Intelligence Risk Management Framework, AI RMF）之規畫並徵詢公眾意見，截止日為9月15日，並預計於10月發布正式報告。
依照NIST說明，公眾所建議之人工智慧風險管理框架，可促進人工智慧之可信賴性，其中包含如何應對並解決人工智慧於設計、發展及使用過程中所遭遇之「精確度」（accuracy）、「可解釋性」（explainability）、「偏見」（bias）等議題。此外，上開管理框架預計為非強制性、供企業自願性使用於人工智慧設計、發展、使用、衡量及評估之人工智慧標準。
依現有公眾意見徵詢結果，其中DeepMind公司建議於人工智慧設計初期，必須預先構思整體系統之假設是否符合真正社會因果關係。舉例言之，當設計一套可預測民眾健保需求程度之系統時，如輸入參數僅考量民眾於醫療上的花費，將使僅有可負擔較高醫療費用之民眾被歸類為健保需求程度較高者，從而導致健保制度排擠經濟負擔程度較差之公民，故在設計系統時，應從預先設定之假設事實反面（counter-factual）思考並驗證是否會產生誤差或公平性之問題（例如預先思考並驗證「醫療費用支出較低之民眾是否即可被正確歸類為健保需求度低之民眾」）。惟進行上述驗證需要大量社會資料，因此DeepMind也建議NIST應建立相關機制，使這些社會資料可以被蒐集、使用。
此外，亦有民眾建議管理框架應有明確之衡量方法以及數值指標，以供工程界遵循。同時鑒於人工智慧發展極為快速，未來可能有不同於以往之人工智慧類型出現，故亦建議NIST應思考如何在「建構一套完整且詳細之人工智慧治理框架」與「保持人工智慧治理框架之彈性與靈活性」之間取得平衡。
最後，目前也有許多徵詢意見指出，許多人工智慧治理之目標會相互衝突。舉例言之，當NIST要求人工智慧系統應符合可解釋性，則人工智慧公司勢必需要經常抽取人工智慧系統中之「數據軌跡」（audit logs），惟數據軌跡可能被認為是使用者之個人資料，因此如何平衡或完善不同治理框架下之目標，為未來應持續關注之議題。
本文為「經濟部產業技術司科技專案成果」
王柏霳
法律研究員 編譯整理
National Security Commission on Artificial Intelligence, Final Report, https://www.nscai.gov/wp-content/uploads/2021/03/Full-Report-Digital-1.pdf (last visited, Sep. 28, 2021).
DeepMind, Request for Information: Artificial Intelligence Risk Management Framework, https://www.nist.gov/system/files/documents/2021/09/17/ai-rmf-rfi-0105.pdf (last visited, Sep. 28, 2021).
Comments Received for RFI on Artificial Intelligence Risk Management Framework, NIST, https://www.nist.gov/itl/ai-risk-management-framework/comments-received-rfi-artificial-intelligence-risk-management (last visited, Sep. 28, 2021).
AI RMF Development & Request for Information, NIST, https://www.nist.gov/itl/ai-risk-management-framework (last visited, Sep. 28, 2021).
〈歐盟提出人工智慧法律調和規則草案〉，資訊工業策進會科技法律研究所，https://stli.iii.org.tw/article-detail.aspx?no=55&tp=1&d=8674（最後瀏覽日期：2021/09/28）。
歐洲汽車供應商協會（European Association of Automotive Suppliers，俗以CLEPA簡稱之）於2023年3月7日發表〈關於標準必要專利之政策指南—一個可因應汽車產業數位轉型現象的歐盟專利規則〉（Standard Essential Patents Policy guidelines—For an EU patent regulation that adapts to the digital transformation in the mobility ecosystem），以期有關單位能給予汽車產業更明確的指示，舉凡：SEP專利權人可向何人為授權、「合於FRAND原則之授權條款」應如何被認定等。 CLEPA提及，由於在一技術領域中有SEP時，其他的技術無「迴避設計」（design-around）可能性，而必得實施該被選為標準之技術，故在該技術領域中，無其他技術可與「受該SEP保護」的技術相抗衡；是以該SEP的價值必須被審慎且精確評估。此外，CLEPA指出，由於汽車產業會投資、研發、銷售有助於未來「移動性」（mobility）發展的下世代產品，故此產業與智慧財產權議題有高關聯性（例如：此產業每年會申請超過39,000筆專利權），應予其在SEP議題上有足夠的明確性（certainty）及可預測性（predictability），使其在「投資於廣泛實施標準的『新技術』」上，更可依循。而創建一個「利益平衡」（balanced）的環境，將有助於授權雙方進行合於「誠信原則」（good-faith）的授權協議。 CLEPA為以上目的，提出五點建議： （1）應有一「歐盟層級」的立法 一個「歐盟層級」（EU-level）的法架構體系是較足以為SEP專利權人及專利實施者間，提供較「利益平衡」的環境，且較可抑制不公平的SEP授權行為。 （2）「供應鏈中任一層級，均可得授權原則」 凡任何欲得授權者，不論其位於供應鏈中何層級，均應予其有「在符合FRAND原則」下，被授權的機會。又，由於一技術之所以會成為「標準」，係因被「商討」（coordination）而出，倒不一定是因其在市場競爭上，真的有大勝於其他技術的優勢，故授權權利金應僅可反映該技術本身的價值，而不可將「因標準化而可帶來的其他廣大利益」摻入。 （3）對於SEP授權條款應有明確指示 政策制定者及各「標準制定組織」（Standard Setting Organization, SSO）應對「何謂合於FRAND原則之授權條款」提供指南；此外，也應提出就一SEP及其有被納入的「專利組合」（portfolios）的評價方法。 （4）供應鏈中的授權狀況應明瞭 專利實施者應清楚明瞭其是否應獲授權，或其上游元組件供應商是否已獲授權。 （5）應有完整的法體制 政策制定者應制定法體制或應提供關於法體制的指南，以避免SEP專利權人不當申請「禁制令」（injunction），以強使授權協議之可被達成。
澳洲法院認為新聞標題不受著作權法保護FairFax媒體出版公司是澳洲財經評論(Australian Financial Review，以下簡稱AFR)報紙的出版商，控告Lexis Nexis資料庫所提供的ABIX服務，提供不同的來源的每日新聞標題和摘要，包括AFR的新聞)，是侵害FairFax新聞標題的著作權，同時，FairFax要求Lexis Nexis停止使用這些文字。 澳洲聯邦法院認為：1.著作權法不保護新聞標題，因為新聞標題太過簡短；2.證據顯示新聞標題並不能做為共同著作的一部分；3.新聞標題非整篇新聞最實質的部份。4.因為LexisNexis所使用的新聞標題可以構成合理使用。澳洲著作權法中，依據使用的性質與目的若使用新聞報導內容，是可以作為合理使用的主張。也就是說即使新聞標題受到著作權法保護，但LexisNexis仍可以主張合理使用，不會有侵害著作權的疑慮。 法官Annabelle Bennet表示：「新聞標題普遍來說就如同書名，太簡單且太短是不能受到著作權法中的語文著作保護。新聞標題的功能像是一篇文章的篇名，也像針對主題用濃縮的方式簡短的敘述，就如同像是一本書的書名長度。普遍來說，新聞標題太過簡短以致於不能被認為是語文著作，就像是標識(LOGO)在著作權法的評價上不夠重要以致於不能作為美術著作，即使這些是花費技能和勞力所創造的。
美國國家安全局發布「軟體記憶體安全須知」美國國家安全局（National Security Agency, NSA）於2022年11月10日發布「軟體記憶體安全須知」（“Software Memory Safety” Cybersecurity Information Sheet），說明目前近70%之漏洞係因記憶體安全問題所致，為協助開發者預防記憶體安全問題與提升安全性，NSA提出具體建議如下： 1.使用可保障記憶體安全之程式語言（Memory safe languages）：建議使用C#、Go、Java、Ruby、Rust與Swift等可自動管理記憶體之程式語言，以取代C與C++等無法保障記憶體安全之程式語言。 2.進行安全測試強化應用程式安全：建議使用靜態（Static Application Security Testing, SAST）與動態（Dynamic Application Security Testing, DAST）安全測試等多種工具，增加發現記憶體使用與記憶體流失等問題的機會。 3.強化弱點攻擊防護措施（Anti-exploitation features）：重視編譯（Compilation）與執行（Execution）之環境，以及利用控制流程防護（Control Flow Guard, CFG）、位址空間組態隨機載入（Address space layout randomization, ASLR）與資料執行防護（Data Execution Prevention, DEP）等措施均有助於降低漏洞被利用的機率。 搭配多種積極措施增加安全性：縱使使用可保障記憶體安全之程式語言，亦無法完全避免風險，因此建議再搭配編譯器選項（Compiler option）、工具分析及作業系統配置等措施增加安全性。
何謂「CRADAs」？CRADAs係研發合作契約（Cooperative Research and Development Agreements）之縮寫，為美國國家衛生研究院（National Institute of Health，NIH）與業界和學術界進行科學技術研究發展產學研合作時所簽訂之契約。基於美國國家衛生研究院投入相關領域技術發展之機關設置目的，其所屬之科學家們可以利用本身的科研資源，與業界或學術界共同合作促進保健藥品和原型（prototype）開發與產品進一步的商業化量產。此外，業界也可利用本身私部門的研發力量，介接在國家層級最先進的技術研究合作。 研發合作契約的目的是專為使政府設施、政府補助研發成果之智慧財產權，透過與私部門之產學研合作提供合作互動，以促進科學技術知識之發展轉化為具有市場價值之商業化用途。配合契約之簽署，針對研發合作之權利義務，美國國家衛生研究院另設置有科技發展合作中心（Technology Development Coordinator，TDC），作為研發合作早期階段進行磋商與諮詢之專業機構，以幫助瞭解和研擬適當內容的研發合作契約，並順利依法獲得相關主管機關之核准。