以下是5月19日在柏林舉行的2026年歐洲認同與雲端大會（EIC 2026）上發表的主題演講的日文譯本。投影片以PDF格式提供，位於本文檔結束時。
軟體不再只是工具的時代。
大家好。
我們現在正進入一個軟體不再只是工具的時代。
長期以來，軟體的功能在於執行指令。它處理表單、移動記錄、執行計算、強制執行工作流程以及連接系統。
但現在，軟體開始像人類員工一樣行事了。
他們不是人類僱員，他們不是公司，他們也不是人類意義上的同事。
它是一種行為類似於員工的數位角色。
我們賦予他們使命和任務，賦予他們權力，並提供必要的工具。我們期望他們能夠協調合作、做出決策、向上級報告、授權，並在實際工作中取得成果。
當軟體具備如此強大的功能時，治理問題就會呈現不同的形式。
問題不再只是“模型能否給出正確答案？”
這不僅僅是應用程式能否安全地呼叫 API 的問題。
應該問的問題是：
- 誰批准了這項工作？
- 這裡反映的是誰的意圖？
- 授予了何種權力？
- 執行過程中發生了哪些變化？
- 誰能阻止這一切？
- 如果後果出現，誰來負責？
- 就是這樣
軟體作為員工和身份
在考慮這個問題時，我想先提出一個簡單的建議：
當軟體成為員工時，身分就成為治理的基石。
智能體人工智慧的關注點不僅在於模型安全，也不僅僅在於應用程式安全。其核心在於權限委託問題。
授權總是涉及身分、所有權、控制權、證據、問責制和信任等問題。
傳統應用程式通常在預先設定的介面範圍內執行。應用程式接收指令、執行函數並傳回結果。
然而，代理人各不相同。
智能體被賦予總體目標，並自行決定如何實現這些目標。這可能包括選擇工具、呼叫API、創建子任務、與其他智能體協作、適應環境以及超越組織邊界採取行動。
那就是為什麼“數位員工”這句話很有用。
當然，這並不是因為這些特工是人類。
給我們的員工設定一個總體目標，然後讓他們決定並實施實現目標的方法，這是我們一直以來對員工的要求。
我們給他們分配任務，賦予他們權力，並期待他們會取得成果。最終，必須有人為他們的行為負責，就像他們是我們的下屬一樣。
這種模式不僅限於人與代理人之間的互動，它也開始出現在代理人之間。代理在接收請求時，會聲明自己的能力、服務範圍、技能以及所需的資格認證，而客戶在分配工作前會審核這些資訊。
用於發現請求方元資料的函數稱為發現函數。在本例中，發現函數也很有用。
然而，一旦元數據的來源超出了我們的控制範圍，就會出現這樣的問題：“我們真的能相信它嗎？”
目前尚不清楚該代理人所說的話是否屬實，也不清楚該代理人背後的操縱者是誰。
這背後可能存在一個支持恐怖主義的國家。
但在此之前，還有一個問題：我昨天聯絡的客服人員和我目前聯絡的客服人員是同一個人嗎？
代理人身分的連續性和一致性
現在我們來探討第一個難題。
對於不同的代理人來說，「同一代理人」意味著什麼？
對於人類員工而言，其身分具有連續性和一致性（統一性）。即使人們不斷學習、轉換角色、累積經驗，他們在責任上仍然是同一個人。
然而，對於人工智慧代理而言，這種連續性和一致性並不那麼明顯。
如果模型發生變化，它還是同一個代理嗎？
如果系統提示發生變化，是否為同一客服人員操作？
如果記憶體被重置、合併或共享，它還是同一個代理程式嗎？
工具鏈發生變化時會發生什麼？提供者更改策略時會發生什麼？運行時發生變化時會發生什麼？子代理被替換時會發生什麼？任務從一個執行器傳遞到另一個執行器時會發生什麼？我們究竟信任的「它」是什麼？
那麼，誰是這些行為的「所有者」呢？
這就引出了以下問題：
代理商的所有者或實際控制人是誰？
每個行使職權的代理人都需要一個負責的負責人。
我有這個“終極機器人擁有者 (UBO)”我叫它
最終受益所有人。
這種表述是特意的。在反洗錢法規中，最終業務所有者（UBO）的概念至關重要。我這裡指的UBO就是這個UBO。 UBO之所以重要，是因為問責制不應被名義上的法律實體所阻斷。在委託任何工作之前，您需要了解UBO的含義。
否則，整個部署的代理網路將面臨不可接受的風險。這是降低供應鏈風險的必要措施。
使命
我想在本次演講中介紹的另一個面向是我們的「使命」。
這與“提示”不同。 「提示」是一種指令。
它也不同於一次課程。一次課程是：這裡是經紀人可以繼續工作的地方。這項任務與此不同。
任務是指授予個人或團體為實現特定目標而進行的受控授權；它是代理人被允許繼續工作的理由。任務包括目標、限制條件、權限、資源、時間框架、適用政策、證據要求以及對一個或多個實體的行為進行問責的框架。
任務、代理和會話是相互獨立的概念，不應混淆。任務的持續時間可能比代理更長，也可能在代理完成之前結束。如果任務結束時會話仍在進行中，則也應結束該會話。
智能體的行為和會話受任務約束。智能體只能為完成任務而行動。
一項任務必須有明確的範圍、可核實性、可暫停性和合理性。
否則，基於代理的系統不僅會執行任務，還會轉移權限，而沒有可靠的記錄來證明這些權限的來源。
人類給特工分配任務。
代理人在被授予的自由裁量權範圍內制定任務並決定行動。
由於代理人幾乎總是無法承擔責任，因此通常需要讓人類參與審批過程來獲得批准。
人工監督至關重要。
在影響重大的行動、法律訴訟、受監管的決策、財務轉移、對外溝通或不可逆轉的揭露中，人的判斷有時是必不可少的。
規模問題
但是，如果我們試圖用這種方式做所有事情，我們將面臨規模問題。
一名員工可能管理數十甚至數百名代理人。對於一個組織而言，這可能意味著管理數千名代理人。
人類不可能對每一個步驟給予有意義的認可。事實上，甚至有論文表明，即使只有一個主體參與，每個任務在第三次嘗試之後，確認只是名義上的。
如果 100 名代理人依序向同一個人請求批准，那麼批准必然會變成一種慣性行為。
在這個規模下，不能完全依賴人工審核來決定方向。 「人機協作」未必是一種有效的治理方式。
在時間緊迫且資訊不全的情況下所做的批准並非真正的決定。 《克勞德準則》曾對此有所論述。
這是偽裝成人類判斷的「自動化處理」。
我們需要人工智慧代理的幫助──一個站在委託人（授權人）這邊的監督代理。
該代理負責評估風險證據和跡象，過濾掉無關訊息，並根據需要向客戶報告相關資訊。它必須站在最初委託這項工作的個人或組織一邊，忠於客戶，而不是忠於試圖完成任務的系統。
執行代理在形成執行操作的「意圖」時以及執行過程中，應向監控代理程式發送結構化報告，包括異常情況、變更和結果。
共享訊號類型的事件報告可能是這個神經系統的一部分。但是，我們是否有具體的標準來實施這種結構化報告呢？
沒有它。
而且該訊號並非緊急停止開關。
這只是訊號層的一部分。我們還需要控制平面。
控制平面必須能夠介入。它必須能夠暫停任務、限制權限、停用工具、阻止授權、撤銷憑證、隔離記憶體、將問題回報給人工處理人員，或終止任務本身。
這些有標準流程嗎？沒有。
智能體人工智慧系統是一個分散式事務系統。
還有另一種理解智能體系統的方法。
你可以把它看作一個分散式物件系統和一個分散式事務系統。
任務開始。代理呼叫工具，呼叫API，委託給子代理，重寫狀態，發送訊息，並可能向外部產生結果。
眾所周知，在傳統的分散式系統中處理長期事務非常困難。 Saga 模型將長期事務視為一個整體來執行，但又可以將其拆分為多個子事務。
智能體人工智慧也面臨同樣的問題，但這個問題更加棘手。
協調器可能部分是非確定性的。執行器可能依賴模型。下一步可能取決於上下文。
因此，每個子代理人的任務、工具和技能都必須明確其自身後果的語意。
能否取消？能否提供賠償？能否取得恢復進展？還是已經無法挽回？
發送內部草稿或許可以撤回。取消預約或許可以獲得補償。工作流程的修復或許可以撤銷。但是，洩漏機密資料是不可逆的。
如果不了解哪些部分還可以逆轉，就無法管理一項任務。
智能體人工智慧將分散式交易轉化為分散式決策。
而這種判斷必須是有界限的、可觀察的、可攔截的。
透過代理卡進行元數據廣告宣傳
現在，焦點集中在經紀人卡上。
代理卡是對代理的自我描述，包括其姓名、提供者、終端、功能、技能、身份驗證方法和互動要求。未來，它甚至可能能夠表示交易特徵，例如交易是否可以回溯。
這些在發現、功能聲明、端點發現和協定選擇中都非常重要。然而，至關重要的是要準確地理解它們能解決什麼問題，以及它們不能解決什麼問題。
代理人名片可能會告訴你該代理人聲稱能夠做什麼。然而，名片本身並不能告訴你該代理人實際上能夠做什麼。
- 我不會證明自己適合執行這項任務。
- 這也不能證明運行時環境是可靠的。
- 它也不會驗證模型、提示符號、記憶體或策略版本。
- Ultimate-Bot-Owner 也未能證明這一點。而且，
- 委託方不保證該代理人在此次交易中值得信賴。
從治理角度來看，自行申報的代理人卡是不夠的。
即使是簽過名的代理人卡也只是向前邁出了一步。簽名僅表示某個關鍵人物簽署了某項文件。
驗證者還必須確定簽署者、金鑰、頒發者和信任框架是否符合此目的。
- 身分識別並不等於信任。
- 發現並不等於權威。
- 元資料不能取代問責制。
SPIFFE/SPIRE 模式
SPIFFE 和 SPIRE 模式在考慮這些因素時很有幫助。
SPIFFE 和 SPIRE 並非代理治理的標準規範。然而，它們提供了一些值得我們學習的模式。
工作負載不應該只是簡單地聲明它的身份；它應該在被授予該身份之前進行身份驗證。
然而，對於智慧體人工智慧而言，工作負載識別只是起點。
證明可以幫助回答「正在做什麼？」這個問題。
但是，證明文件無法回答以下問題。
- 這項任務是誰執行的？
- 授予了何種權力？
- 使用了哪種模型或提示？
- 執行的是哪項政策？
- 這種行為可以獲得賠償嗎？
- 誰是最終受益人（UBO）？
因此，除了工作量證明、任務證明、授權證明、交易語意和監控報告之外，還需要這些證明。
透過聯邦制建構信任框架
這就牽涉到「聯邦」的概念了。
代理人卡片上會註明已申報的索賠項目。
證明文件提供有關正在進行的工作的資訊。
聯合會可以幫助您確定哪些說法或證明值得信賴。
OpenID 聯盟定義了相互互動的實體如何透過稱為「信任錨」的受信任第三方建立信任關係。它支援多層級權限，單一實體可以同時屬於多個聯盟。此外，它還為建立動態的去中心化信任網路提供技術信任基礎設施元件。
聯合使我們能夠驗證簽署金鑰是否屬於我們批准的信任框架內的實體，是否存在有效的信任鏈，是否應用了元資料策略，以及信任標記對該依賴方是否有意義。
這在代理人治理中至關重要。
如果每個參與者都必須手動決定是否接受或拒絕每個代理人、提供者、登記機構、證明簽發機構和最終受益所有人，那將是一個令人不快的世界。
信任鍊和元資料策略必不可少。在行使任何權力之前，需要一種機制來決定要接受哪些聲明。為此，聯邦機制非常有用。
使用標準的重要性
目前已有許多實用組件可用於實現這些目標。僅 OpenID 相關規格就包含了此處列出的元件。
- OpenID Connect
- OpenID4VCI/VP
- AuthZEN
- OpenID 聯盟
- OpenID共享訊號與事件框架
- 等。
其中許多都已從安全角度進行了數學和形式上的驗證。
當然，僅靠這些還不夠。但是，我們應該盡可能地重複使用可重複使用的元件，只建構真正必要的元件。
責任和精算挑戰
最後，我想提出一個治理過程中必然會遇到的問題。
誰來承擔損失？
當代理人洩漏資料、挪用款項、操縱工作流程、發送錯誤指令或引發有害連鎖反應時，最終的責任應該由誰承擔？
從這個角度來看，終極機器人擁有者就顯得非常重要了。
因此，證據至關重要。沒有證據，問責機制就會被削弱，責任歸屬就只能靠猜測，保險也淪為碰運氣。
目前，針對智能體人工智慧相關風險的精算基礎仍處於早期階段。但這並不代表我們應該坐等觀望。現在正是建立評估基礎架構的最佳時機。
保險不僅僅是口號。你需要風險暴露程度、發生頻率、損失嚴重程度、管理有效性、因果關係和損失等方面的數據。
軟體正在變成員工。
對這些問題進行治理變得越來越必要。
有一些標準規範可供使用。
然而，僅僅建立一個管理完善的代理基礎設施是不夠的，還有許多不足之處需要彌補。
對於 Identerati 社群而言，我們建立值得信賴的代理商生態系統的旅程才剛開始。
讓我們一起努力，現在就開始行動。