IBM提出「人工智慧日常倫理」手冊作為研發人員指引

  隨著人工智慧快速發,各界開始意識到人工智慧系統應用、發展過程所涉及的倫理議題,應該建構出相應的規範。IBM於2018年9月02日提出了「人工智慧日常倫理」(Everyday Ethics for Artificial Intelligence)手冊,其以明確、具體的指引做為系統設計師以及開發人員間之共同範本。作為可明確操作的規範,該手冊提供了問責制度、價值協同、可理解性等關注點,以促進社會對人工智慧的信任。

一、問責制度(Accountability)
  由於人工智慧的決策將作為人們判斷的重要依據,在看似客觀的演算系統中,編寫演算法、定義失敗或成功的程式設計人員,將影響到人工智慧的演算結果。因此,系統的設計和開發團隊,應詳細記錄系統之設計與決策流程,確保設計、開發階段的責任歸屬,以及程序的可檢驗性。

二、價值協同(Value Alignment)
  人工智慧在協助人們做出判斷時,應充分考量到事件的背景因素,其中包括經驗、記憶、文化規範等廣泛知識的借鑑。因此系統設計和開發人員,應協同應用領域之價值體系與經驗,並確保演算時對於跨領域的文化規範與價值觀之敏感性。同時,設計師和開發人員應使人工智慧系統得以「了解並認知」用戶的價值觀,使演算系統與使用者之行為準則相符。

三、可理解性(Explainability)
  人工智慧系統的設計,應盡可能地讓人們理解,甚至檢測、審視它決策的過程。隨著人工智慧應用範圍的擴大,其演算決策的過程必須以人們得以理解的方式解釋。此係讓用戶與人工智慧系統交互了解,並針對人工智慧結論或建議,進而有所反饋的重要關鍵;並使用戶面對高度敏感決策時,得以據之檢視系統之背景數據、演算邏輯、推理及建議等。

  該手冊提醒,倫理考量應在人工智慧設計之初嵌入,以最小化演算的歧視,並使決策過程透明,使用戶始終能意識到他們正在與人工智慧進行互動。而作為人工智慧系統設計人員和開發團隊,應視為影響數百萬人甚至社會生態的核心角色,應負有義務設計以人為本,並與社會價值觀和道德觀一致的智慧系統。

相關連結
相關附件
你可能會想參加
※ IBM提出「人工智慧日常倫理」手冊作為研發人員指引, 資訊工業策進會科技法律研究所, https://stli.iii.org.tw/article-detail.aspx?no=66&tp=1&d=8195 (最後瀏覽日:2024/05/05)
引註此篇文章
你可能還會想看
加拿大政府就生成式人工智慧對著作權的影響進行公眾諮詢

加拿大政府於2023年10月23日至12月4日針對「生成式人工智慧對著作權的影響」(consultation on the implications of generative artificial intelligence for copyright)進行公眾諮詢,以期了解生成式人工智慧對於加拿大著作權市場之變化,進而修訂《著作權法》(Copyright Act),本次諮詢文件中討論重點整理如下: 1.文字和資料探勘(Text and Data Mining, TDM):是否需要因應TDM修改加拿大原本的著作權法,包含著作權法中合理使用行為(29條)和暫時性重製行為(30.71條)等得不構成侵害之例外條款。學者、AI使用者以及AI技術團體大多持肯定見解,認為TDM行為中使用的著作時不需要權利人的著作權授權;然創意產業則多持否定見解,認為不應該為TDM創設例外,否則將會使得TDM所使用之作品原著作人無法主張權利以獲得授權金。 2.人工智慧生成作品之著作人身分及著作權歸屬:因利用生成式人工智慧所創作或輔助創作之文字、圖像和音樂有作者身分不明確之虞,因此加拿大政府希望可以對此加以澄清,並討論是否需要修改原本的著作權法案中相關規定。針對作者身分不明確之爭議,加拿大政府提出了三種可能的規範模式: (1)闡明著作權保護只適用於自然人創作的作品; (2)將人工智慧生成作品之作者歸屬於在創作作品時運用技能和判斷力的自然人,凡自然人可以在人工智慧技術輔助下創作的作品中貢獻足夠的技能和判斷力,即可被視為該作品的作者; (3)為人工智慧生成的作品創設一套新的權利。 3.人工智慧之侵權責任:人工智慧係透過大量的資料庫來生成一項作品,過程中可能出現侵害他人著作權之情形,而加拿大現行的著作權法框架下很難認定侵權行為之責任歸屬。加拿大現行的著作權法要求被侵權人(著作人)必須證明侵權人明知其重製行為侵犯他人著作權,且就該他人著作加以重製,但一般人難以瞭解人工智慧系統開發及訓練過程,因此難證明人工智慧系統研發與利用過程中的業者、工程師或其他相關人等是否有侵權行為。因此加拿大政府希望利害關係人就此議題提供更多意見,以協助將來修法、提高市場透明度。 生成式人工智慧雖然提供了便利的創作方式並帶來巨大經濟利益,卻也可能侵害他人著作權,因此平衡著作人之權利並兼顧經濟發展是加拿大政府及國際社會課正積極解決的議題。

促進智慧電網之發展—德國提出智慧電網佈建期程

美國第9巡迴上訴法院於2015年7月6日宣布Multi Time Machine v. Amazon案的見解

  美國第9巡迴上訴法院(9th Circuit)於2015年7月6日對外宣布Multi Time Machine v. Amazon案的見解,其推翻地方法院看法,認定被告Amazon公司提供的服務有侵害原告Multi Time Machine公司商標權之虞。   本案原告Multi Time Machine公司是一家製作手錶的廠商,在被告Amazon公司的網站上有提供零售服務。原告認為被告網站提供之服務,可使消費者搜索網站內的物品,但其所得之結果(含圖片)卻容易令人混淆,如搜尋原告的MTM手錶(為Multi Time Machine之商標),會將商標權人及其他廠商的商品都包含在內,導致消費者誤認為其他廠商手錶也是由MTM製造,進而購買非原告公司生產之手錶。原告因而向地方法院提出訴訟,認為被告Amazon公司侵害其商標權,違反聯邦法典內之Lanham Act的第1114條(1)(a)及第1125條(a)(1)規定。但洛杉磯地方法院認為被告行為並未侵害商標權,原告不服故提起上訴。   第9巡迴上訴法院採用1979年AMF v. Sleekcraft Boats案認定之方式,並於2011年Network Automation v. Advanced System Concepts案後發展出的測試標準,用以判斷有無侵害商標權。其標準包含:1.商標的強度、2.商品近似或相關連程度、3.與商標的相似性、4.實際混淆之證據、5.銷售管道、6.消費者在意程度、7.被告意圖、8.擴展之可能性。上訴法院認為,本案除了3、5、8三項較無關外,其餘5項因素經法院研究結果,原告商品在被告網站上販售時,1、2、7於原告影響較大,而4、6是被告提供服務(即供消費者購買)時須在意的。因此,綜合判斷之結果,被告行為已可能侵害原告之商標權,故推翻地方法院之判決結果,發回地方法院續行審理,本案後續判決進展及結果實值持續觀察。

美國醫療保健領域對新興資料儲存系統理論「資料湖泊」(Data Lake)的應用

  在現今資訊流通快速蓬勃發展的時代,巨量資料(Big Data)帶來效率與生產力等龐大效益已無庸置疑。相較於將資料以「資料倉儲」(Data Warehouse)模式儲存,「資料湖泊」(Data Lake)被廣泛視為巨量資料快速演進的下一步。   美國的醫療保健領域為因應巨量資料發展並提升醫療保健系統的透明度與有責性,美國醫療保險與補助中心(Centers for Medicare & Medicaid Services, CMS)於2013年底建立CMS虛擬研究資料中心(Virtual Research Data Center, VRDC),讓研究員能夠以安全有效率的方式取得並分析CMS的龐大醫療保健資料。此種資料倉儲模式會對進入的資料預先分類,並整合為特定形式以指導後續分析的方式。缺點在於為讓資料更易於分享,會進行「資料清理」(data cleaning)以檢測及刪除不正確資訊並將其轉換成機器可讀取格式,各資料版本會被強制整合為特別形式,但資料清理和轉換的過程會導致明顯的數據流失,對研究產生不利的限制。有鑑於此,為更有效益的應用巨量資料,Pentaho首席技術官James Dixon提出新的資料儲存理論­­—資料湖泊(Data Lake),此概念於2011年7月21日首先被討論於美國《富士比》雜誌中,目前在英美國家公部門和民間企業間已被熱烈討論。   與Data Warehouse最大不同在於Data Lake可包含「未被清理的資料」(unclean data),保持其最原始的形式。故使用者可取得最原始模式的資料,減少資源上處理數據的必要,讓來自全國各政府機關的資料來源更易於結合。Data Lake主要有四點特性:1.以低成本保存巨量資料(Size and low cost)2.維持資料高度真實性(Fidelity)3.資料易取得(Ease of accessibility)4.資料分析富彈性(Flexible)。儲存超過百萬筆病患資料的加州大學歐文分校醫療中心(UC Irvine Medical Center)即以Hadoop架構為技術建立了一個Data Lake,該中心能以最原始的形式儲存各種不同的紀錄數據直到日後需要被分析之時,可協助維持資料的來源與真實性,並得以不同形式的醫療數據進行分析項目,例如患者再住院可能性的預測分析。   但相對的Data Lake在安全性和檢視權限上也有一定的風險,尤其是醫療保健領域,因為這意味著病患的資料在個資生命週期裡隨時可被取得,因此資訊的取得應被嚴密控制以維持各層級的安全與保障,在建立安全的Data Lake之前,必須審慎考慮誰有資訊檢視權限以及透過什麼媒介取得Data Lake中的資料等問題。

TOP