美國能源部於去年 (2012) 12月21日宣布將投入九百萬美元挹注數項住屋節能科技。除此之外,美國國會亦於今年元旦通過美國納稅人緩稅法案 (American Taxpayer Relief Act of 2012),而其中第四章能源稅延展的第408款將2005年能源政策法案 (Energy Policy Act of 2005) 第1332條所創設的能源效率新屋抵免 (Credit for Energy-efficient New Homes),展期到2013年年底。
據美國能源部長朱隸文 (Steven Chu) 表示,該國家庭平均每戶每年花費近兩千美元於能源相關開銷,而其中有大部分皆因諸如住屋的屋頂、閣樓或牆壁間的空氣洩漏而流失浪費。相關研究並顯示,百分之四十二的能源都喪失於建築外殼(building envelope),包括門、屋頂、閣樓、牆、地板和地基之中。該部於是決定投資建築圍護科技 (building envelope technology)的改進,包涵有高效能的窗戶、屋頂及冷暖器設備。
另方面,國會所通過的美國納稅人緩稅法案展延了包括能源效率新屋抵免(Credit for Energy-efficient New Homes)等十二項能源相關抵免或獎勵措施。其中第408條的展延將使美國國民得其於就其符合能源之星(Energy Start)認證標準之隔熱保溫工程、外部窗戶及門等2005年後所產生裝修支出 (含勞務承攬) 的百分之十,申報最高五百美元的賦稅減免。
2005 能源政策法法案所創設的能源效率新屋賦稅減免原定於2007年終止,之後由2006年的稅收抵免與醫療保健法案 (Tax Relief and Health Care Act of 2006) 延長至2008,再由08年的能源改進與延長法案 (The Energy Improvement and Extension Act of 2008) 展延至2009。其後,10年的減稅、失業保險再授權及工作機會增進法 (The Tax Relief, Unemployment Insurance Reauthorization, and Job Creation Act of 2010) 將其延伸至2011年年底,而目前通過美國納稅人緩稅法案再將其延至2013年12月31日。
在現今資訊流通快速蓬勃發展的時代,巨量資料(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中的資料等問題。
德國通過《小型電動車條例》,實現清潔現代化運輸並確保道路安全隨著現代德國城市興起騎乘小型電動車(例如:電動滑板車和電動踏板車)風潮,德國聯邦交通及數位基礎設施部(Bundesministerium für Verkehr und digitale Infrastruktur, BMVi)制定小型電動車條例(Elektrokleinstfahrzeuge-Verordnung),以實現清潔現代化運輸並確保道路安全,該條例於2019年6月15日正式生效,並取代原有的行動輔助工具條例(Mobilitätshilfenverordnung),此外,德國聯邦車輛運輸管理局(Kraftfahrt-Bundesamt, KBA)並陸續公布經審驗合格之小型電動車清單。 由於歐洲議會及理事會通過的二輪或三輪和四輪車核可及市場監督規則(EU Nr. 168/2013)將自動平衡車輛和無座椅車輛特別排除,因此BMVi制定行動輔助工具條例,以規範例如Segways的新型運輸工,然而隨著市場推出更多新型小型電動車,原行動輔助工具條例已無法有效規範,因此制定小型電動車條例,除將原本核可小型電動車納入適用外,而本條例所稱小型電動車定義為第一,具備轉向或支撐桿;第二,最高時速設計6~20公里/小時;第三,功率限制為500瓦(自動平衡運輸工具為1400瓦);第四,最低安全要求(例如制動裝置和照明系統,駕駛動態和電動安全設備)。另條例規範重點如下:(1)小型電動車須年滿14歲方能使用,但無須考取任何駕駛執照;(2)小型電動車應行駛於自行車道上,如該段道路無設計自行車道可行駛於側車道,並禁止行駛於人行道或步行區,且不得於踏板上另搭載他人或物品及攀附於其他車輛;(3)須遵守其他一般道路交通法規,特別是保持謹慎駕駛以及酒駕規定須遵守相關規範;(4)保險部分,因小型電動車輛屬於機械動力車輛,故必須投保,並將投保證明貼紙黏貼於車輛上。 另外,BMVi主張並支持小型電動車可攜帶上公共交通工具,然原則上,攜帶小型電動車搭乘公共交通工具,受貨物運輸規範約束,應視電車及無軌電車等固定路線動力車輛之一般條件及服務條例(BefBedV)第11條,或有關運輸公司之特殊運輸條件規範個案判斷。
歐盟公布智慧運輸系統指令授權規則歐盟執委會於2019年3月13日針對清潔,聯網和自動化移動戰略,公布智慧運輸系統指令授權規則(Commission Delegated Regulation of 13.3.2019 supplementing Directive 2010/40/EU of the European Parliament and of the Council with regard to the deployment and operational use of cooperative intelligent transport systems),該授權規則(Delegated Regulation)係歐盟執委會為執行智慧運輸系統指令(ITS Directive)所制訂之相關細則,其目的使執委會與會員國合作提出指導分針,進一步讓各國能夠對自動及聯網化駕駛車輛進行型式認可,以加速相關創新運輸技術於歐洲協同式智慧運輸系統(C-ITS)之發展。其創新技術包含使車輛間可相互「交談」,或與道路基礎設施以及其他道路使用者「交談」,可應用在例如危險情況,道路施工和掌控交通號誌時間,將使公路運輸更安全,更清潔,更高效率。授權規則將符合容克委員會(Juncker Commission),即現任歐盟執委會主席容克領導的執政團隊,其所提出的清潔移動提案( Proposals on clean mobility),是歐盟移動現代化的另一步驟,也為本世紀下半葉的氣候中和(climate neutral)目標,即達到溫室氣體排放總量為零之目標作準備,並持續達到歐盟2050年交通事故近零死亡或零嚴重傷害的目標。 歐盟移動及運輸專員Violeta Bulc表示:「此決定將為車輛製造商,道路營運者和其他人提供一個法源依據,以便於歐洲開始大規模發展C-ITS服務,同時對新技術和市場發展持開放態度。此將極力促進我們實現我們對道路安全的願景,並作為實現聯網化和自動化移動性的重要基礎。」 車輛,交通號誌和高速公路在裝配合規之聯網技術裝置後,可向周圍的所有交通使用者發送標準化之訊息,此將是實現車間通訊的重要里程碑。該授權規則將確保不同系統間擁有協同工作能力,使所有配備該技術的站點能在開放網路中安全地與任何其他站點交換資訊,並讓系統可順利運行,透過車輛間以及車輛和交通基礎設施之間的連接,也能幫助駕駛員做出正確的決策並視交通狀況來改善道路安全性、交通效率及舒適性。
新加坡代理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。