美國制訂「促進政府資訊開放」行政命令及推動「藍色按鈕倡議」計畫
美國歐巴馬總統於2013年5月9日正式簽署「促進政府資訊開放並利機器讀取」行政命令（Executive Order 13642–Making Open and Machine Readable the New Defaut for Government Information），推崇聯邦政府過去釋出氣候、全球定位系統（GPS）等資訊對於私部門產業創新及新創事業（entrepreneurship and star-up）之正面影響，盼未來所有新增加的政府資料在資訊安全和隱私權雙重確保之前提下，將開放以可供機器可讀取之格式給公共大眾，帶動整體經濟正面循環發展。之前，美國推動聯邦政府資料開放政策，重要者為白宮科學技術政策辦公室（Office of Science and Technology Policy, OSTP）於2009年3月份啟動「開放政府倡議」（Open Government Initiative），民眾可透過「Data.gov」入口網站 ，取得高價值、機器可讀取之聯邦政府資料。
近年來，在公部門政府政策鼓勵導引下，不同的產業也逐漸發展出適用於特定產業的共同互通性標準（sectoral interoparability）。以醫療衛生領域為例，從2010年開始，歐巴馬總統乃宣布「藍色按鈕倡議」（Blue Button Initiative），病患得透過特定網頁（web-based）簡易下載其健康資訊（health information），並可供重複利用的格式下；同時，患者也可以選擇將該資訊分享給健康照護提供者（health care provider）、保險公司和信任的第三者（trusted third parties）。該倡議更挑戰軟體開發者（developer）在藍色按鈕的基礎上，開發更多的Apps軟體，使當事人更容易去管理掌控自身健康的狀況。在能源科技領域，近似於藍色按鈕倡議，白宮幕僚科技長Aneesh Chopra於2011年9月，也發起了「綠色按鈕倡議」（green button initaitive），挑戰美國境內大小事業單位（utilities）投入參與該倡議，研發一個機器可讀取之開放格式（a machine-readable open format），使消費者得透過連線網路重複近取之。
有鑒於網際網路開放的特性，且近年來來自外國網路攻擊不斷，於2013年2月份，NIST與國際間重要標準組織，如ISO、IEC和IEEE，首度就感應網絡（sensor networks）、機器對機器（M2M）和智慧聯網（IoT），提出一個跨界面之共通標準計畫（ISO/IEC/IEEE P21451-1-4 XMPP），該共通標準計畫內容包含: 封包傳輸（檢測）、全球獨特辨識、政策控制和加密，此共通標準得確保未來巨量資料領域資料近取之安全性 。
美國聯邦法院最近判決美國聯邦官員在 2001 年及 2003 年，允許四家企業在夏威夷種植基改作物以生產試驗用藥的行為，違反環境法規。該許可內容涉及許可在夏威夷州 Kauai, Maui, Molokai and Oahu 種植玉米或甘蔗。 本案法官 Michael Seabright 判決中特別指出，鑑於夏威夷州乃是許多瀕臨絕種或受到絕種威脅的生物的棲地－該州計有 329 種罕見生物，占全美瀕臨絕種生物及受到絕種威脅生物種類之四分之一，而美國農業部動植物健康檢疫服務（ Department of Agriculture's Animal and Plant Health Inspection Service ）在許可種植基改作物前，竟未先進行初步的環境檢視（ preliminary environmental reviews ），很明顯地已違反該機關依據瀕臨絕種生物法（ Endangered Species Act ）及國家環境政策法（ National Environmental Policy Act ）所應盡之義務。 本案原告 EarthJustice 認為，本案是第一件聯法院就 biofarming 所做之判決。所謂 biopharming 係指研究人員利用基改技術將植物用來作為生產藥品、抗體、疫苗等生技藥物的生物反應器（ bioreactors ）。由於植物可以大量栽種，因而若 biopharming 技術可行，將可有效解決生技藥物供給短缺的問題，嘉惠更多的病患，因而， biopharming 被視為未來可能顛覆傳統的藥物生產的一種生技藥物製造方式。目前， biopharming 廣泛使用的植物包括玉米、煙草等。 biopharming 的構想可以較低的成本解決部分生技藥物生產的問題，但其構想看似極具吸引力，不過發展 biopharming 並非毫無挑戰，尤其是如何就藥用基改植物予以隔離管理，避免基因污染。反對者一般主張，藥用基改植物 並未通過食用安全性測試，並不適合人體食用或是當作家畜飼料， 如果栽種藥用基改植物的隔離管理未做好把關，難保這些本應受到嚴格管制的治療性植物進入到食物供應鏈，影響民眾的身體安全。 在民眾健康及環境生態安全的考量下，反對推展 Biopharming 的力量也越來越大，本案即是一個明顯的例子。
美國德克薩斯州承認針對紙本文件的遠端墨水公證為法定線上公證方法美國《德克薩斯州政府法（Government Code），以下簡稱政府法》的第406節「公證人、契約證明人（Notary Public; Commissioner of Deeds）」相關修正案於2024年1月1日正式生效，旨在針對該節的第406.101分節以下的線上公證相關規範，透過擴充線上公證要件，使遠端墨水公證（Remote Ink Notarization, RIN）成為法定線上公證方法，並明定相關程序要求，確保遠端墨水公證機制的安全性。 針對遠端墨水公證，依照美國土地產權協會（American Land Title Association, ALTA）提出的定義，係指文件透過影音媒體平台進行遠距公證，且無須經過多因子驗證。針對遠端墨水公證，雖然在新冠肺炎（COVID-19）流行期間，曾透過州長行政公告方式，承認在滿足指定條件下，得使用遠端墨水公證方式，進行交易，而本次修法則透過修正現有法規，以達到允許進行遠端墨水公證，且同時維持法定電子公證制度的安全架構。 本次修法內容如： 1.定義文件可包含實體及電子文件。 2.針對經電子公證的實體文件，承認委託人及公證人分別得使用實體符號（tangible symbol）及符合法定要求的辦公室印章，進行簽署。 3.強調電子公證應留存之紀錄內容，並非電子文件，而應留存文件的類型、標題及描述等規定。 跨境或電子交易已逐漸成為主流交易方式，而透過現行電子公證制度，雖然能夠強化電子或實體文件的可信性，惟公證制度實際上僅能針對公證當下的文件內容，提供擔保效力。若企業需要確保在公證前，相關文件內容未經偽變造，則必須在文件生成後落實適當資料管理措施。與此同時，公證人基於法規要求，對於經公證的電子、書面文件或公證紀錄等，負有法定保存或保密義務。若相關文件或紀錄發生外洩、外流等問題時，公證人除須負擔契約損害賠償責任外，甚至可能被科以刑責。因此，不論企業或公證人均可參考「重要數位資料治理暨管理制度規範（Essential Data Governance and Management System，簡稱EDGS）」，建立系統性的資料管理機制或強化既有管理機制，避免發生資料偽變造或外洩等問題。 本文同步刊登於TIPS網（https://www.tips.org.tw）
Flyknit專利訴訟戰持續擴大，Nike指控Puma侵害Flyknit系列產品之發明專利Nike成立於1971年，以運動用品起家，曾於2013年登上美國雜誌《Fast Company》「最具創新力的公司」排名位列第一。Nike在2012年推出Flyknit系列產品，主打一體成型的針織鞋面，Nike表示Flyknit技術是經過多年的研究、設計與開發，除以接面不明顯的方式來形成鞋面，其所使用的針織材料還可在鞋面的不同區域產生不同的紋理，並提供運動員所需要的輕盈、支撐、透氣、靈活等特性。此外，Nike也申請了有關Flyknit技術的發明專利以及利用Flyknit技術生產鞋面的設計專利。Flyknit不但在運動鞋業掀起新的流行趨勢，也開啟了新的訴訟戰場。 2012年，adidas晚Nike幾個月也發表了編織鞋款Primeknit，Nike旋即對adidas提起侵害發明專利訴訟，訴訟進展至2017年11月底，adidas向美國聯邦上訴法院提出上訴並主張Flyknit應屬於常規紡織工藝，不應給予Nike發明專利，目前尚待訴訟結果。 2015年，Nike又對Skechers的編織運動鞋款提起侵害設計專利訴訟， Skechers則以高端針織設計聞名的Missoni產品為證據，要求美國專利審理暨訴願委員會（Patent Trial and Appeal Board，簡稱PTAB）審查 Nike設計專利的有效性，最後PTAB認為有部分Nike的設計專利是無效的，至2017年，Skechers持續向PTAB挑戰Nike有關Flyknit鞋面之設計專利，目前PTAB仍在審理進行中。 Nike的Flyknit專利訴訟戰持續擴大規模，今(2018)年5月3日Nike指控Puma的產品IGNITE Proknit、IGNITE Speed Netfit、Mostro Bubble Knit、Jamming，在2008~2016年間侵害了Nike有關Flyknit技術之7件專利，並於美國麻塞諸塞州聯邦地方法院提起專利侵權訴訟，Puma則回應表示其未侵犯任何Nike的專利，計劃將繼續生產其產品。
新加坡代理AI治理示範框架對我國人工智慧基本法落地的啟示新加坡代理AI治理示範框架對我國人工智慧基本法落地的啟示 資訊工業策進會科技法律研究所 2026年07月08日 新加坡資訊通信媒體發展局（Infocomm Media Development Authority，下稱IMDA）於2026年5月20日發布《代理式人工智慧治理示範框架》（Model AI Governance Framework for Agentic AI，下稱示範框架）第1.5版，以事前評估並框限風險、使人類負起有意義的當責、落實技術控制與流程、促成終端使用者盡責四大面向，同時提供真實部署案例，將代理式人工智慧(以下簡稱代理AI)治理的實務具體化[1]。 壹、事件摘要 相較於僅生成內容之生成式人工智慧，代理AI能自主規劃、跨多步驟採取行動，並與其他代理及外部系統互動，代替使用者完成任務。由於其可存取敏感資料並以行動變更所處環境，例如更新客戶資料庫或執行付款，風險型態明顯不同於僅可能產生錯誤輸出者。我國《人工智慧基本法》已於民國114年經立法院三讀通過，以風險為基礎、原則導向、由各主管機關落實之路徑[2]。惟我國現行治理之重心，仍落在AI應用與輸出風險，對於代理採取行動所生之系統性風險存在空缺。新加坡已關注此新興的AI工具發展，更新其代理AI治理框架，新增風險評估因素、代理AI價值鏈、防範自動化偏誤之作法與各類控制之概覽及其選用方式，為組織提供代理AI風險及其管理新興最佳實務的結構化概覽。 貳、重點說明 一、以行動空間與自主性為風險座標 示範框架提出各代理AI雖可能具備相同元件，但每一元件之設計皆可能顯著影響代理能力，故思考代理能做什麼時，應區分兩個概念：一為行動空間（action-space），指代理可採取之行動範圍，取決於其獲准使用之工具及該等工具上之權限；二為自主性（autonomy），指代理朝目標行動時可自行決定如何行動之程度，取決於其指令與人為介入之程度。此兩個要素是後續一切風險評估與控制設計之重要因素，不同的權限與自主程度，將會使性質同為代理AI，歸屬於截然不同之風險程度[3]。 二、風險會因代理功能出現系統性擴大效應 由於代理之風險本質上並非全新，真正變化在於這些風險因代理AI會在真實世界採取行動，速度與複雜度會進一步加劇。示範框架提醒決策的快速會使監督難以在造成危害前即時阻止，而要求人類持續監督又可能導致自動化偏誤與警示疲勞，致某一步驟之錯誤可能於後續步驟間傳播並放大。因此，當系統由多個代理構成，敏感資料被無意記錄、傳遞給安全性較低代理或遭提示注入揭露之可能，會產生無法透過個別測試去預測並防止之行為[4]。 三、代理AI的四大關鍵面向 示範框架就代理AI於下列四大面向，提供組織做為梳理治理重點的關鍵考量。這些面向同時構成一個循環，透過監測發現異常時，即應循環重新評估先前各面向[5]。 (一)事前評估並框限風險：組織可於規劃階段設計適當邊界，以限縮代理之影響範圍，例如限制其對工具與外部系統之存取。組織亦可透過代理身分管理與存取控制等措施，確保代理之行動可追溯、可控制。 (二)使人類負起有意義的當責：「人在迴路」（human-in-the-loop）須加以調整，以因應自動化偏誤，一旦代理AI之部署獲得放行，組織即應採取措施確保人為當責，並應迅速掌握新發展，隨技術演進更新其作法。 (三)落實技術控制與流程：組織應於代理生命週期全程實施技術措施，且由於代理與其環境動態互動、且非所有風險均能事前預見，爰建議逐步推出代理，並於部署後持續監測。 (四)促成終端使用者盡責：應告知使用者代理之行動範圍、資料存取情形，以及使用者自身之責任。組織並應考量另行提供教育訓練，使員工具備管理人機互動、行使有效監督所需之知識，同時維持其專業技藝與基礎技能。 四、風險控制的因應策略 示範框架以行動空間與自主性各對應嚴重程度與發生機率，嚴重程度考量部署領域、對敏感資料與外部系統之存取、行動範圍（讀取相對於寫入）及可回復性；發生機率則考量自主程度、任務複雜度、是否由外部方提供及系統複雜度，並主張以「威脅建模」(threat modeling)即系統化的預設可能的如記憶投毒、工具濫用、權限破壞、間接提示注入等威脅情境，推導出更有針對性的控制與分層防禦方式來強化評估[6]。 在風險控制策略上，示範框架主張系統層確定性控制優於提示層防護，亦即與其提示代理AI不得存取特定工具，不如施加存取控制使該工具根本無法被呼叫。除靜態防護外，框架另強調在設計之初就要納入控制措施，在執行過程中監測並介入，例如如限制防止工具使用過度，或以輸入驗證的方式，在有害動作執行前予以攔截[7]。 五、風險控制的實作技巧 對於風險控制實際方法，示範框架建議可於協定層就善用模型上下文協定（Model Context Protocol，MCP）過濾敏感資料、記錄所有互動或將受信任伺服器列入白名單。同時，該框架以事例建議組織可採取這些控制的技術手段，如：於提示代理AI反思計畫是否遵循指令、記錄計畫與推理供驗證；於執行時要求嚴格輸入格式、以最小權限限制可用工具、對敏感資料庫預設不給寫入權、於鍵入密碼時交還使用者控制；於連結時，將受信任伺服器列入白名單、將程式碼執行沙箱隔離[8]。 六、人為監督之具體化、代理身分治理 針對人為監督方式，該示範框架建議應先界定須經人為核准之查核點或行動界線，尤其在高風險、不可回復或離群行為之前。其次，設計核准之形式，使請求切合脈絡且易於理解、清楚呈現風險，並依情形選擇所需之人為輸入。但最關鍵的是，須將監督的有效性本身納入稽核，包括追蹤人為否定率偏低，或審查回應時間有過短情況時，即意味監督可能已流於形式。須注意自動化偏誤或審查疲勞，並辨識決策明顯偏離常態之「離群」人員，同時訓練監督者辨識代理AI可能出狀況的情況[9]。 而就多代理與跨組織互動帶來之系統性風險，示範框架建議的因應是將身分管理延伸至代理，但其亦指出現行授權系統多為預先定義之靜態範圍，難以因應代理依情境動態變化之細粒度權限；於過渡期間，建議代理AI身分應具備唯一、有所歸屬、依其行事身分加以區別、並建檔集中管理[10]。 七、部署前全流程測試、逐步部署並設計風險示警 框架認為可能透過工具採取不安全或非預期之動作，故應測試整體任務執行、政策遵循度與工具使用正確性，非僅測最終輸出；且應個別測試與合併測試，以掌握多代理協作時之湧現風險。就部署後，框架主張逐步推行，可依使用者、工具與協定、所暴露系統三個面向控制推行範圍並持續監測。在監測面，應決定記錄之內容、優先監測更新資料庫或金融交易等高風險活動、建立警示定義與設計與風險相稱之介入、確保日誌不可竄改以維持稽核軌跡，並建立將監測洞察回饋至訓練與評估之迴路[11]。 參、事件評析 新加坡的代理AI治理框架初版於二〇二六年一月發布，此次更新納入多個組織導入代理AI的實例回饋，擴充多代理系統之系統性風險，補強代理蔓生、協作失敗、串謀與湧現行為之情境。其核心價值在於指出傳統風險止於「內容」，而代理式治理之對象，則係能呼叫工具、寫入系統、執行交易之能行動系統，風險延伸至「行動」及其真實後果。因此，其建議應由單一之模型輸出品質，轉為行動空間與自主性之風險控制。由內容防護轉為系統確定性控制、執行期介入與協定治理；由事後審查轉為將推翻率、回應時間等監督的有效性予以指標與持續改善化。 我國AI基本法於第4條提及問責、人類自主及資料治理原則，適對應示範框架的人為當責、系統層控制與監督指標化建議。同時，依基本法第16條規定數位發展部應參考國際標準或規範，推動與國際介接之人工智慧風險分類框架，並應協助各目的事業主管機關訂定以風險為基礎之管理規範。各目的事業主管機關應視人工智慧應用風險管理之需要,循前項風險分類框架,訂定以風險為基礎之管理規範，並應協助相關產業自行訂定產業指引及行為規範。在代理AI已在生成式AI基礎上，跨入多任務自主執行的功能層次，風險的質與量已因代理功能出現系統性擴大效應的情況下，單純以生成式AI為標的治理規範或指引，顯然其可產生的規範管理或指引提醒的效果，已不足以因應AI的快速發展。 新加坡適時更新的代理AI治理框架，雖然亦表明代理AI的風險並非其所獨有，亦是來自於生成式AI的既有影響，但該框架進一步提醒代理AI將使風險控制更加困難，「人在迴路」（human-in-the-loop）須加以調整，一旦代理AI之部署獲得放行，組織即應採取明確課責、認知建立、訓練技能等措施確保人為當責的「有效性」，並應迅速掌握新發展，運用技術手段強化風險監測。其中喻意深遠的是，該框架就終端使用者所提基礎技藝維持之警示，即代理AI接手任務恐致技能退化與業務永續風險，或許將成為AI基本法下一個階段必須面臨的課題。 本文著作權屬財團法人資訊工業策進會科技法律研究所所有，如需引用或轉載，請註明出處。 本文同步刊登於TIPS網站（https://keid.nat.gov.tw/tips/） [1]新加坡資訊通信媒體發展局（Infocomm Media Development Authority, IMDA），《代理式人工智慧治理示範框架》（Model AI Governance Framework for Agentic AI）第一‧五版，二〇二六年五月二十日發布、同年六月五日更新，https://www.imda.gov.sg/-/media/imda/files/about/emerging-tech-and-research/artificial-intelligence/mgf-for-agentic-ai.pdf（最後瀏覽日：二〇二六年七月六日）。 [2]《人工智慧基本法》，民國一百十四年十二月二十三日經立法院三讀通過，全文二十條，二〇二六年一月公布施行，中央主管機關為國家科學及技術委員會。 [3] 前揭註1，頁8、15（分見「代理設計如何影響各代理之限制與能力」與「判定適合部署代理之使用案例」）。 [4] 同前註，頁11。 [5] 詳前註1，頁3~4。 [6] 同前註，頁15至18。 [7] 同前註，頁33至34。 [8] 同前註，頁30。 [9] 同前註，頁29至32。 [10] 同前註，頁23至24。 [11] 同前註，頁42至45。