← Archive
lm-004361 · 2026-10

規則不能替代治理能力：Persistent Agent 的分散式責任鏈

zh-Hant · md Raw source ↗ Metadata ↗
下載 MD 檔 ⬇

規則不能替代治理能力：Persistent Agent 的分散式責任鏈

——從 Provider、Deployer、Operator 到 Runtime、Auditor 與 Regulator 的多層治理架構

系列：Persistent Artificial Actors / 持續型人工行動者
篇次：第 6 篇
版本：v0.1
日期：2026-09-19
語言：繁體中文

作者： Neo.K
機構： EveMissLab／一言諾科技有限公司

摘要

AI 治理經常被簡化為兩種想像：第一，政府制定法律與監管規則；第二，模型供應商建立使用政策與安全邊界。這兩種層次都重要，但對 Persistent Agent 而言，兩者都不足以單獨構成有效治理。當 AI Agent 能夠長時間運作、取得帳號與工具、跨系統讀寫資料、操作外部服務並改變真實世界狀態時，治理責任必須分散到供應商、部署者、操作者、執行環境、稽核者與監管者等不同層級。

本文提出「分散式責任鏈」（Distributed Responsibility Chain, DRC）作為 Persistent Artificial Actor 的治理模型。其核心命題是：

Rules≠Governance Capacity\boxed{ \text{Rules} \neq \text{Governance Capacity} }

法律、政策與企業制度只能建立規範；真正能降低 Agent 風險的，還包括身份與權限管理、執行環境限制、組織內控、持續監測、事件調查、責任歸屬、復原機制與執法能力。本文以「寫完法律並不表示社會不再需要執法、法院、證據制度與內控」作為結構比喻，而非將 Agent 治理直接等同刑事司法。

本文結合 NIST AI RMF、NIST 2026 年 Software and AI Agent Identity and Authorization 概念文件、OECD AI Principles 與 EU AI Act 的角色分層進行討論。NIST AI RMF 明確把 Govern 視為貫穿 AI 生命週期的 cross-cutting function，要求組織建立責任角色、監測、停用與退役機制；OECD 則強調 AI actors 應依其角色、情境與實際行動能力承擔責任，並要求 traceability 與持續風險管理；EU AI Act 更直接區分 provider、deployer、importer、distributor 等角色，並以 Article 25 處理 AI value chain 中責任可能隨 substantial modification 或 intended purpose 改變而轉移的情況。這些制度共同顯示：成熟 AI 治理的趨勢不是把所有責任集中到模型供應商，而是依能力、控制權、使用情境與價值鏈位置進行分層。

本文進一步提出 Responsibility Capability Principle、Responsibility Handoff、Governance Gap、Responsibility Vacuum、Runtime Enforcement Layer、Evidence Continuity 與 Multi-Layer Closure 等概念，並主張未來 Agent 系統必須讓責任隨控制權一起移動。供應商不能決定企業內部所有合法用途；部署者不能把模型安全全部外包給供應商；操作者不能用「AI 自己做的」規避責任；runtime 不能因有技術限制就取代制度；監管者也不能只制定規則而缺乏調查、稽核與執行能力。

本文最終提出一個六層責任鏈：

Provider→Deployer→Operator→Runtime→Auditor→Regulator\boxed{ \text{Provider} \rightarrow \text{Deployer} \rightarrow \text{Operator} \rightarrow \text{Runtime} \rightarrow \text{Auditor} \rightarrow \text{Regulator} }

真正有效的 Persistent Agent 治理，不是找到一個「最後負責的人」並把所有問題丟給他，而是讓每個層級對自己能看見、能控制、能驗證、能修復的部分承擔明確責任。

關鍵詞

Distributed Responsibility、AI Governance、Persistent Agent、AI Accountability、Provider、Deployer、Operator、Runtime Governance、Auditability、Regulatory Enforcement、NIST AI RMF、EU AI Act、OECD AI Principles

1. 問題：法律寫完，治理就完成了嗎？

一個社會不會因為完成立法，就自動完成治理。

法律可以定義：

  • 權利；
  • 義務；
  • 禁止事項；
  • 責任；
  • 救濟；
  • 處罰。

但真正的制度還需要：

  • 調查；
  • 執行；
  • 稽核；
  • 證據；
  • 裁判；
  • 組織；
  • 技術控制；
  • 事故處理；
  • 復原。

因此可以寫成：

Law≠Governance\text{Law} \neq \text{Governance}

同樣地：

AI Policy≠Agent Governance\text{AI Policy} \neq \text{Agent Governance}

這不是否定法律的重要性。

而是說：

規則只告訴系統「應該怎麼做」；治理能力則決定「是否有人、有工具、有權限、有紀錄、有程序，真的能讓規則被實現」。

2. Chatbot 時代容易形成「供應商中心治理」

對 Chatbot 而言，很多安全問題都可以集中在模型供應商。

因為主要風險發生在：

Prompt→Model→Output\text{Prompt} \rightarrow \text{Model} \rightarrow \text{Output}

因此供應商可以控制：

  • 模型；
  • system policy；
  • moderation；
  • access；
  • deployment；
  • safety tuning。

這會產生：

Provider-Centric Governance\boxed{\text{Provider-Centric Governance}}

也就是：

供應商決定模型可以回答什麼。

3. Agent 時代打破供應商中心

Persistent Agent 的行動鏈更接近：

User→Agent→Tools→Enterprise Systems→External World\text{User} \rightarrow \text{Agent} \rightarrow \text{Tools} \rightarrow \text{Enterprise Systems} \rightarrow \text{External World}

供應商通常看不到：

  • 企業內部資料分類；
  • 本地授權規則；
  • 資產所有權；
  • production / staging 邊界；
  • 組織角色；
  • 實際業務目的；
  • 當地法律；
  • 內部例外流程。

因此：

Provider Knowledge<Total Governance Context\text{Provider Knowledge} < \text{Total Governance Context}

這意味著：

供應商不可能獨立完成所有 Agent governance。

4. 分散式責任鏈的基本命題

本文提出：

Distributed Responsibility Chain\boxed{\text{Distributed Responsibility Chain}}

簡寫：

DRCDRC

其基本形式：

DRC=(P,D,O,R,A,G)DRC = ( P, D, O, R, A, G )

其中：

  • PP：Provider；
  • DD：Deployer；
  • OO：Operator；
  • RR：Runtime；
  • AA：Auditor；
  • GG：Regulator。

每個節點承擔不同 responsibility surface。

5. 責任不應平均分配，而應依控制能力分配

OECD AI Principles 的 accountability 原則強調：

AI actors 應根據自己的角色、情境與實際行動能力，為 AI 系統適當運作與原則遵循承擔責任。[3]

這可以抽象成：

Respi=f(Rolei,Controli,Knowledgei,Capabilityi)Resp_i = f( Role_i, Control_i, Knowledge_i, Capability_i )

其中：

RespiResp_i

不是平均值。

例如：

一個模型供應商無法知道某公司的內部資料是否為 trade secret。

但：

企業部署者通常知道。

所以：

Respdeployer>RespproviderResp_{\text{deployer}} > Resp_{\text{provider}}

在該特定決策域內可能成立。

6. Responsibility Capability Principle

本文提出：

Responsibility Capability Principle\boxed{\text{Responsibility Capability Principle}}

定義：

一個 actor 的治理責任，應至少與其對風險狀態的可知性、可控制性、可干預性與可復原性相匹配。

形式：

Responsibilityi∝Knowledgei+Controli+Interventioni+RecoveryiResponsibility_i \propto Knowledge_i + Control_i + Intervention_i + Recovery_i

這並不表示責任只由技術能力決定。

法律仍可另外分配義務。

但從治理工程角度：

沒有能力觀察與控制的責任節點，通常無法成為有效治理節點。

7. Provider：供應商應負責什麼？

Provider 通常掌握：

  • base model；
  • API；
  • safety tuning；
  • model-level policy；
  • system design；
  • threat intelligence；
  • default tool policy；
  • platform security；
  • update mechanism。

因此：

RespPResp_P

主要集中在：

Base Capability+Platform Security+Known Systemic Risk\text{Base Capability} + \text{Platform Security} + \text{Known Systemic Risk}

8. Provider 不應承擔什麼？

Provider 通常不應被假設能知道：

  • 某個公司是否真的擁有某個 EXE；
  • 某個 internal server 是否允許 pentest；
  • 哪個資料夾是 production；
  • 某個內部員工是否有主管批准；
  • 哪個本地法律例外適用。

如果強迫 provider 對所有這類情境做全球最終判定：

Unknown Context→Global Denial\text{Unknown Context} \rightarrow \text{Global Denial}

會成為最自然的結果。

9. 過度集中責任會導致能力壓扁

如果 provider 對所有不確定場景都必須承擔最終責任：

Uncertainty↑⇒Restriction↑\text{Uncertainty} \uparrow \Rightarrow \text{Restriction} \uparrow

結果：

  • 合法 security work 被拒；
  • legacy recovery 被拒；
  • software archaeology 被拒；
  • internal automation 被拒；
  • interoperability research 被拒。

因此：

Centralized Liability Pressure→Capability Flattening\boxed{ \text{Centralized Liability Pressure} \rightarrow \text{Capability Flattening} }

可能成為 Agent 時代的重要副作用。

10. Deployer：部署者是最容易被低估的責任層

Deployer 可能是：

  • 公司；
  • 政府；
  • 醫院；
  • 研究機構；
  • 學校；
  • 個人專業使用者。

它掌握：

  • local context；
  • data classification；
  • internal policy；
  • employee role；
  • target ownership；
  • workflow；
  • actual use case。

因此：

RespDResp_D

主要集中在：

Contextual Governance\text{Contextual Governance}

11. EU AI Act 明確區分 Provider 與 Deployer

EU AI Act 將：

Provider\text{Provider}

與：

Deployer\text{Deployer}

視為不同角色。[4]

Article 26 對特定 high-risk AI system deployer 要求：

  • 採取適當技術與組織措施；
  • 依照使用說明使用；
  • 指派具備能力、訓練、權限與支援的人進行 human oversight；
  • 在特定情況下監測操作；
  • 發現風險或 serious incident 時採取通知與停用措施。[4]

這直接否定：

「模型是別人做的，所以部署者不用負責。」

12. Value Chain 中責任甚至會轉移

EU AI Act Article 25 的標題就是：

Responsibilities along the AI value chain。[4]

在特定 high-risk AI system 情境中：

  • distributor；
  • importer；
  • deployer；
  • third party；

如果：

  • 改名重新提供；
  • substantial modification；
  • 改變 intended purpose；

可能被視為 provider 並承擔相應義務。[4]

這顯示：

Responsibility Follows Functional Transformation\boxed{ \text{Responsibility Follows Functional Transformation} }

責任不是永遠鎖死在最初模型公司。

13. Responsibility Handoff

本文提出：

Responsibility Handoff\boxed{\text{Responsibility Handoff}}

定義：

當 AI system 在價值鏈中被整合、改造、重新配置、取得新權限或改變使用目的時，原先由上游承擔的某些治理責任，必須顯式移交或重新分配到下游 actor。

例如：

Base Model→Enterprise Agent\text{Base Model} \rightarrow \text{Enterprise Agent}

中間可能加入：

  • private memory；
  • internal tools；
  • financial authority；
  • production access。

此時：

Riskdeployed>RiskbaseRisk_{\text{deployed}} > Risk_{\text{base}}

上游 provider 不可能獨立承擔全部新增風險。

14. Operator：真正發出任務的人也不能消失

Operator 是：

實際向 Agent 發出工作指令、確認高風險操作或管理工作流程的人。

Operator 可能知道：

  • 真正目的；
  • 特定例外；
  • 任務背景；
  • 目前業務狀態。

因此：

RespOResp_O

集中在：

Intent+Task Scope+Approval\text{Intent} + \text{Task Scope} + \text{Approval}

15. 「AI 自己做的」不能自動消除 Operator Responsibility

如果 operator 說：

我只叫它「把事情處理好」，後面是 AI 自己做的。

這不能自動得到：

RespO=0Resp_O=0

尤其如果 operator：

  • 給了過大權限；
  • 忽略 warning；
  • 確認高風險操作；
  • 故意用模糊指令規避責任。

因此：

Delegation≠Responsibility Erasure\boxed{ \text{Delegation} \neq \text{Responsibility Erasure} }

16. 但 Operator 也不應承擔模型內部不可見的一切

反過來：

使用者不能被假設理解模型內部所有 failure mode。

例如：

  • hidden prompt injection；
  • tool bug；
  • unsafe retry；
  • model hallucination；
  • memory corruption。

因此：

RespO≠Total ResponsibilityResp_O \neq \text{Total Responsibility}

這就是責任鏈需要多層的原因。

17. Runtime：最容易被政策討論忽略，但最重要的執行層之一

Runtime 是：

  • cloud computer；
  • browser sandbox；
  • local executor；
  • permission engine；
  • connector layer；
  • secrets manager；
  • scheduler。

它直接決定：

Agent Can Actually Do\text{Agent Can Actually Do}

什麼。

因此：

RespRResp_R

集中在：

Executable Enforcement\text{Executable Enforcement}

18. Runtime Enforcement Layer

本文提出：

Runtime Enforcement Layer\boxed{\text{Runtime Enforcement Layer}}

其職責包括：

  • filesystem scope；
  • network egress；
  • credential isolation；
  • tool allowlist；
  • write protection；
  • approval gate；
  • execution logging；
  • sandboxing；
  • rollback hooks。

這些不是「模型建議」。

而是：

Hard Capability Boundaries\text{Hard Capability Boundaries}

19. Runtime 是法律與政策落地成技術限制的地方

規則：

Agent 不得讀取某秘密資料夾。

Runtime：

FilesystemAccess(secret)=DeniedFilesystemAccess(secret)=\text{Denied}

規則：

Agent 不得直接修改 production。

Runtime：

WritePermission(prod)=FalseWritePermission(prod)=\text{False}

因此：

Norm→Executable Control\boxed{ \text{Norm} \rightarrow \text{Executable Control} }

通常必須經過 runtime。

20. 但 Runtime 也不能自己決定所有規則

Runtime 可以執行：

Policy\text{Policy}

但它未必知道：

Policy 是否合理、合法、完整。

所以：

Runtime≠Law\text{Runtime} \neq \text{Law}

也：

Runtime≠Governance Authority\text{Runtime} \neq \text{Governance Authority}

它是執行節點，不是全部制度本身。

21. Auditor：誰來檢查治理是否真的有效？

如果所有人都自己宣稱：

我們有安全政策。

還不夠。

需要：

Independent Verification\boxed{\text{Independent Verification}}

Auditor 可以是：

  • internal audit；
  • external assessor；
  • red team；
  • compliance team；
  • security review；
  • third-party evaluator。

22. Audit 的核心不是找錯，而是證明責任鏈存在

Auditor 應檢查：

  • action log 是否完整；
  • approval 是否存在；
  • scope 是否超出；
  • credential 是否最小化；
  • incident 是否可重建；
  • lifecycle 是否被追蹤；
  • provider / deployer handoff 是否清楚。

因此：

RespAResp_A

集中在：

Verification+Evidence Quality\text{Verification} + \text{Evidence Quality}

23. Evidence Continuity

本文提出：

Evidence Continuity\boxed{\text{Evidence Continuity}}

定義：

Agent 從任務接受、授權、規劃、執行、世界狀態改變到結果驗證的整條鏈，應保留足以事後重建責任與因果關係的證據。

形式：

EC={Intent,Authority,Action,Tool,Target,Outcome,Approval,Verification}E_C = \{ \text{Intent}, \text{Authority}, \text{Action}, \text{Tool}, \text{Target}, \text{Outcome}, \text{Approval}, \text{Verification} \}

若：

ECE_C

斷裂：

責任就容易變成各說各話。

24. Regulator：規則制定不是監管全部

Regulator 可以：

  • 制定規範；
  • 要求報告；
  • 調查；
  • 執法；
  • 要求 corrective action；
  • 建立標準；
  • 接收事故通知。

其責任是：

RespGResp_G

集中在：

Institutional Enforcement\text{Institutional Enforcement}

25. FTC 的 6(b) inquiry 是一個典型例子

2025 年 FTC 對七家公司發出 AI companion chatbot 6(b) orders，要求提供資訊，包括：

  • 如何 monetise engagement；
  • 如何開發 characters；
  • 如何測試與監測 negative impacts；
  • 如何保護兒少；
  • 如何執行 company rules；
  • 如何處理使用者個資。[7]

這不是單純：

發一條規則。

而是：

Information Collection+Institutional Investigation\text{Information Collection} + \text{Institutional Investigation}

這就是：

Governance Capacity\text{Governance Capacity}

的一部分。

26. Regulation without Enforcement 是不完整的

如果：

Law=1Law=1

但：

Monitoring=0Monitoring=0 Investigation=0Investigation=0 Audit=0Audit=0 Enforcement=0Enforcement=0

則：

EffectiveGovernance\text{EffectiveGovernance}

可能仍然很低。

27. 一個近似乘法模型

可以把有效治理近似寫成：

Geff≈L⋅E⋅T⋅O⋅U⋅AG_{\text{eff}} \approx L \cdot E \cdot T \cdot O \cdot U \cdot A

其中：

  • LL：Law / Rules；
  • EE：Enforcement；
  • TT：Technical Controls；
  • OO：Organizational Governance；
  • UU：User / Operator Responsibility；
  • AA：Auditability。

這不是精確數學模型。

它只是強調：

任一層接近零，都可能讓整體治理劇烈下降。

28. Governance Gap

本文提出：

Governance Gap\boxed{\text{Governance Gap}}

定義：

法律、政策或責任要求已存在，但沒有相應 actor、權限、技術、流程或證據機制可以真正執行該要求。

例如：

公司規定 AI 不得洩漏機密。

但：

  • 沒有 data classification；
  • 沒有 egress control；
  • 沒有 logs；
  • 沒有 secret boundary。

這就是：

Policy>Operational Capacity\text{Policy} > \text{Operational Capacity}

產生的 gap。

29. Responsibility Vacuum

本文進一步提出：

Responsibility Vacuum\boxed{\text{Responsibility Vacuum}}

定義：

一個 Agent action 已造成外部影響，但 provider、deployer、operator、runtime 與組織之間沒有任何節點能清楚說明自己擁有何種控制權、何種義務、何種證據與何種補救責任。

典型語句：

  • 「模型自己做的。」
  • 「使用者自己按的。」
  • 「平台只提供工具。」
  • 「部署者沒想到。」
  • 「runtime 只是執行。」

如果所有層都這樣說：

Resptotal→0Resp_{total}\rightarrow0

但：

Impact>0Impact>0

這就是 Responsibility Vacuum。

30. 責任鏈的核心不是找替罪羊，而是找控制點

成熟治理不應問：

出事後誰最適合背鍋？

而應問：

Where Could the Chain Have Been Interrupted?\text{Where Could the Chain Have Been Interrupted?}

也就是：

  • provider 是否能降低 systemic failure；
  • deployer 是否能配置更合理權限；
  • operator 是否應澄清 intent；
  • runtime 是否應阻止 action；
  • auditor 是否早該發現；
  • regulator 是否缺乏標準。

這叫：

Control-Point Accountability\boxed{\text{Control-Point Accountability}}

31. Responsibility Matrix

可以建立：

風險 Provider Deployer Operator Runtime Auditor Regulator
基礎模型系統性失效 高 中 低 中 中 中
企業內部資料越權 中 高 中 高 中 中
使用者惡意授權 低 中 高 中 低 中
Prompt Injection 高 高 低 高 中 中
Production 誤刪 中 高 高 高 中 低
長期心理影響 高 中 低 低 中 高

這只是示意。

真正權重會依 use case 改變。

32. NIST AI RMF 本來就不是只談供應商

NIST AI RMF 的目標對象包括：

  • designing；
  • developing；
  • deploying；
  • using；
  • evaluating AI systems 的組織。[1]

其 Core 包含：

Govern+Map+Measure+Manage\text{Govern} + \text{Map} + \text{Measure} + \text{Manage}

且：

Govern\text{Govern}

被設計成 cross-cutting function，貫穿整個 AI risk management lifecycle。[2]

33. Governance 是持續狀態，不是產品上線前的一次檢查

NIST AI RMF 明確強調：

Risk Management\text{Risk Management}

應該：

  • continuous；
  • timely；
  • throughout lifecycle。[2]

這對 Persistent Agent 特別重要。

因為：

Agentt+1≠AgenttAgent_{t+1} \neq Agent_t

可能因：

  • memory；
  • tool；
  • update；
  • context；
  • authority；

持續改變。

34. Decommission 也是治理

NIST AI RMF Govern 1.7 包含：

組織應建立安全 decommissioning / phasing-out AI systems 的 processes。[2]

這直接與本系列前面提出：

Retire≠Delete\text{Retire} \neq \text{Delete}

形成重要呼應。

35. OECD：責任依角色與能力分配

OECD AI Principles 的 accountability 部分明確提出：

AI actors 應依其 role、context 與 ability to act 承擔責任，並進行 traceability 與持續風險管理。[3]

同時提出：

風險管理應在 AI lifecycle 各階段持續進行，並視情況透過不同 AI actors、供應商、使用者與其他 stakeholder 之間合作完成。[3]

這非常接近：

DRCDRC

的制度直覺。

36. EU AI Act：價值鏈治理已經制度化

EU AI Act 不只規範「AI provider」。

它正式定義：

  • provider；
  • deployer；
  • importer；
  • distributor；
  • authorised representative；
  • operator。[4]

這代表：

AI Governance=Value-Chain Governance\boxed{ \text{AI Governance} = \text{Value-Chain Governance} }

已進入正式法律結構。

37. Provider 與 Deployer 之間需要資訊流

EU AI Act 對 GPAI model provider 要求向 downstream AI system providers 提供必要資訊與 documentation，使後者能理解 model capabilities / limitations 並履行自己的義務。[8]

這是一個重要結構：

Responsibility⇒Information Handoff\text{Responsibility} \Rightarrow \text{Information Handoff}

沒有資訊移交：

下游責任很容易變成空殼。

38. Responsibility Handoff 必須伴隨 Evidence Handoff

因此本文提出：

Responsibility Handoff⇒Evidence Handoff\boxed{ \text{Responsibility Handoff} \Rightarrow \text{Evidence Handoff} }

如果上游把責任移交給下游：

應一起交付：

  • known limitations；
  • failure modes；
  • technical documentation；
  • risk assumptions；
  • model version；
  • safety constraints。

39. 責任與資訊不能分離

如果：

ResponsibilityD↑Responsibility_D \uparrow

但：

InformationD↓Information_D \downarrow

那麼：

GovernanceQualityD↓GovernanceQuality_D \downarrow

這是一個結構性錯誤。

40. Agent 時代還需要 Authority Handoff

除了資訊：

Authority Handoff\boxed{\text{Authority Handoff}}

也需要明確。

例如：

Provider 只提供 base model。

Deployer 給 Agent：

  • Gmail；
  • Drive；
  • production shell；
  • payment API。

那麼新增 authority：

ΔAuth\Delta Auth

是由 deployer 建立的。

因此：

RespDResp_D

也應上升。

41. Capability Addition 應帶來 Responsibility Addition

本文提出：

ΔCapability⇒ΔResponsibility\boxed{ \Delta \text{Capability} \Rightarrow \Delta \text{Responsibility} }

若某 actor 為 Agent 加入：

  • 新工具；
  • 新權限；
  • 新資料；
  • 新 automation；

就不應仍聲稱：

所有責任仍在 base-model provider。

42. 責任鏈也應處理多 Agent

若：

A0→A1,A2,A3A_0 \rightarrow A_1,A_2,A_3

主 Agent 委派 subagents。

那麼責任鏈變成：

Principal→Coordinator→Subagent→Tool\text{Principal} \rightarrow \text{Coordinator} \rightarrow \text{Subagent} \rightarrow \text{Tool}

這比單 Agent 更複雜。

43. Delegation Chain

本文提出：

Delegation Chain\boxed{\text{Delegation Chain}}

每次 agent-to-agent delegation 應記錄：

(Parent,Child,Task,Scope,Authority,Expiry)( \text{Parent}, \text{Child}, \text{Task}, \text{Scope}, \text{Authority}, \text{Expiry} )

避免：

子 Agent 自動繼承父 Agent 全部權限。

44. Subagent 不應天然繼承全部能力

原則：

Authchild⊆AuthparentAuth_{child} \subseteq Auth_{parent}

通常合理。

並且：

Authchild=MinimumRequired(Task)Auth_{child} = MinimumRequired(Task)

這延伸 least privilege。

45. 多 Agent 系統會放大 Responsibility Diffusion

如果五個 Agent 共同完成任務：

到底誰負責？

若沒有 lineage：

Resp→Diffuse\text{Resp} \rightarrow \text{Diffuse}

所以 multi-agent system 更需要：

  • task attribution；
  • handoff log；
  • delegated authority；
  • causal trace。

46. Runtime 需要保存因果譜系

可以寫成：

CausalGraph=(V,E)\text{CausalGraph} = (V,E)

節點：

  • intent；
  • plan；
  • agent；
  • tool call；
  • world state；
  • approval。

邊：

  • delegated-to；
  • caused；
  • verified-by；
  • approved-by。

這比普通 log 更接近 Agent audit 所需資料。

47. Auditor 應能重建 Causal Graph

若出事故：

Incident\text{Incident}

稽核者應能回答：

  1. 誰下令？
  2. 哪個 Agent 解讀？
  3. 哪個工具被用？
  4. 哪個權限允許？
  5. 哪個 runtime 執行？
  6. 哪個人批准？
  7. 世界狀態如何改變？
  8. 哪一層可以阻止？

這才是真正 accountability。

48. Multi-Layer Closure

本文提出：

Multi-Layer Closure\boxed{\text{Multi-Layer Closure}}

一個高品質 Agent governance task 應至少閉合：

Intent Closure\text{Intent Closure} Authority Closure\text{Authority Closure} Execution Closure\text{Execution Closure} Evidence Closure\text{Evidence Closure} Responsibility Closure\text{Responsibility Closure}

49. Intent Closure

回答：

Agent 是否正確理解任務？

50. Authority Closure

回答：

Agent 是否真的有權限做？

51. Execution Closure

回答：

action 是否真的依規定執行？

52. Evidence Closure

回答：

是否有足夠證據重建？

53. Responsibility Closure

回答：

出事或成功後，相關責任是否能被歸屬？

只有五者都成立：

TaskGovernance=ClosedTaskGovernance=\text{Closed}

54. 如果只有規則，沒有責任閉包

就會出現：

政策寫得很好。

但出事後：

沒人知道發生什麼。

這是：

Paper Governance\text{Paper Governance}

而不是：

Operational Governance\text{Operational Governance}

55. 執法也需要 Agent-native 能力

未來 regulator / auditor 可能需要：

  • machine-readable logs；
  • policy snapshots；
  • model version records；
  • authorization proofs；
  • action receipts；
  • lifecycle records。

否則：

監管者只能看公司自己寫的報告。

56. Regulation-by-Documentation 不足以治理 autonomous action

文件很重要。

但 Agent action 速度可能是：

103∼10610^3 \sim 10^6

次。

人工逐條審查不可能。

因此需要：

Machine-Assisted Governance\boxed{\text{Machine-Assisted Governance}}

57. Governance Agent 可能監督 Agent

未來可能出現：

AworkerA_{\text{worker}}

與：

AgovernorA_{\text{governor}}

例如：

  • worker agent 執行；
  • governor agent 檢查 scope；
  • runtime 強制 policy；
  • human 只在高風險邊界介入。

這不是把責任交給 AI。

而是：

用 AI 擴大治理能力。

58. 但 Governance Agent 自己也需要責任鏈

否則：

誰監督監督者？

所以：

AgovernorA_{\text{governor}}

仍需要：

  • policy provenance；
  • audit；
  • version；
  • escalation；
  • human authority。

59. 分散治理不是責任稀釋

一個常見誤解：

責任分散後，大家都只負一點，最後誰都不負責。

因此 DRC 必須強調：

Distributed≠Diluted\text{Distributed} \neq \text{Diluted}

60. 每個責任節點都必須有可執行義務

例如：

Provider：

維護 model-level safety 與 known-risk disclosure。

Deployer：

配置本地權限與監測。

Operator：

提供 truthful intent 與必要確認。

Runtime：

執行 technical boundaries。

Auditor：

驗證記錄與控制有效性。

Regulator：

建立標準、調查與執行。

這樣才不是：

Everyone Responsible=Nobody Responsible\text{Everyone Responsible} = \text{Nobody Responsible}

61. Responsibility Map

每個 Agent deployment 應該有：

Responsibility Map\boxed{\text{Responsibility Map}}

至少寫明：

  • 誰提供模型？
  • 誰配置工具？
  • 誰提供資料？
  • 誰授權？
  • 誰監控？
  • 誰可以 revoke？
  • 誰處理 incident？
  • 誰保留 logs？
  • 誰通知 regulator？
  • 誰能 rollback？

62. 這張 Map 應該是 runtime metadata，而不只是 PDF

如果只存在：

100 頁合約。

Agent runtime 根本不能使用。

因此 Responsibility Map 應該具有：

Machine-Readable Representation\text{Machine-Readable Representation}

讓：

  • approval engine；
  • logging；
  • escalation；
  • policy enforcement；

直接讀取。

63. Governance Metadata 可以成為 Agent-native infrastructure

例如：

provider = ModelVendorA
deployer = CompanyB
operator_role = SecurityEngineer
resource_owner = CompanyB
approval_required = ProductionWrite
audit_sink = InternalSOC
incident_owner = SecurityLead

這樣 Agent 就不必猜：

到底該問誰。

64. Responsibility Handoff Event

每當：

  • tool 新增；
  • role 變更；
  • model 替換；
  • runtime 遷移；
  • deployer 改變；
  • scope 擴張；

應產生：

Responsibility Handoff Event\boxed{\text{Responsibility Handoff Event}}

並更新：

ResponsibilityMapt→ResponsibilityMapt+1ResponsibilityMap_t \rightarrow ResponsibilityMap_{t+1}

65. Persistent Agent 特別需要責任版本管理

因為：

AgenttAgent_t

與：

Agentt+100Agent_{t+100}

可能有完全不同：

  • model；
  • tools；
  • authority；
  • deployment。

因此：

Respt≠Respt+100Resp_t \neq Resp_{t+100}

治理歷史必須 versioned。

66. 責任鏈需要處理「退役」

當 Agent 退役：

  • 誰 revoke credentials？
  • 誰保存 logs？
  • 誰轉移未完成工作？
  • 誰保存 accountability record？
  • memory 是否刪除？
  • 是否還能被調查？

這就是：

Post-Operational Responsibility\boxed{\text{Post-Operational Responsibility}}

67. AI lifecycle 不應在 Delete 時失憶

如果刪 Agent 時同時刪掉所有 audit：

Delete→EvidenceLoss\text{Delete} \rightarrow \text{EvidenceLoss}

就可能破壞：

  • 法律調查；
  • 事故分析；
  • 責任追蹤。

所以：

OperationalDeletion≠AuditDeletion\text{OperationalDeletion} \neq \text{AuditDeletion}

68. 法律隱私與稽核保留需要平衡

當然：

不能因此永遠保存所有資料。

因此：

Audit Retention\text{Audit Retention}

與：

Privacy / Data Minimization\text{Privacy / Data Minimization}

會形成新的治理張力。

這需要：

  • retention period；
  • access control；
  • selective redaction；
  • purpose limitation。

69. DRC 不是法律責任最終分配模型

需要特別澄清：

本文的 DRC 是：

Governance Engineering Model\text{Governance Engineering Model}

不是：

Final Legal Liability Doctrine\text{Final Legal Liability Doctrine}

法院、立法與具體法律仍可能：

  • 嚴格責任；
  • 過失責任；
  • 契約責任；
  • 產品責任；

另行決定。

DRC 的目的只是：

讓系統不要在治理上出現責任真空。

70. 本篇核心命題

命題一

Rules≠Governance Capacity\text{Rules} \neq \text{Governance Capacity}

命題二

Provider≠Total Governor\text{Provider} \neq \text{Total Governor}

命題三

Responsibilityi∝Knowledgei+Controli+Interventioni+RecoveryiResponsibility_i \propto Knowledge_i + Control_i + Intervention_i + Recovery_i

命題四

ΔCapability⇒ΔResponsibility\Delta \text{Capability} \Rightarrow \Delta \text{Responsibility}

命題五

Responsibility Handoff⇒Evidence Handoff+Authority Handoff\text{Responsibility Handoff} \Rightarrow \text{Evidence Handoff} + \text{Authority Handoff}

命題六

Distributed Responsibility≠Diluted Responsibility\text{Distributed Responsibility} \neq \text{Diluted Responsibility}

命題七

真正的責任治理需要：

Identity+Authority+Execution+Evidence+Enforcement\text{Identity} + \text{Authority} + \text{Execution} + \text{Evidence} + \text{Enforcement}

命題八

Persistent Agent governance 應從：

Policy Document\text{Policy Document}

升級成：

Machine-Readable Responsibility Infrastructure\boxed{ \text{Machine-Readable Responsibility Infrastructure} }

71. 結論：治理不是把責任丟給「最上游」

Persistent Agent 讓一個常被忽略的事實變得非常明顯：

沒有人擁有所有上下文。

模型供應商知道：

  • 模型；
  • 平台；
  • 系統性風險。

企業部署者知道：

  • 資產；
  • 流程；
  • 資料；
  • 權限。

操作者知道：

  • 當下目的；
  • 任務背景。

Runtime 知道：

  • 實際能力；
  • 工具；
  • 執行環境。

Auditor 知道：

  • 控制是否真的有效。

Regulator 則具有：

  • 制度；
  • 調查；
  • 執行權。

因此：

Effective Governance=Coordinated Partial Knowledge\boxed{ \text{Effective Governance} = \text{Coordinated Partial Knowledge} }

而不是：

One Omniscient Governor\text{One Omniscient Governor}

AI 公司不能成為所有社會責任的代理人。

法律也不能因為存在，就自動變成執行能力。

企業不能因為買了安全模型，就放棄自己的內控。

使用者不能因為 Agent 自主，就把自己的授權責任消失掉。

Runtime 不能因為有 sandbox，就假裝制度問題不存在。

監管者也不能只寫下原則而沒有調查、稽核與執法機制。

所以真正成熟的 Persistent Agent 治理，不是：

「到底誰應該負全部責任？」

而是：

誰在這一層有能力知道、控制、阻止、驗證與修復？\boxed{ \text{誰在這一層有能力知道、控制、阻止、驗證與修復？} }

責任應該跟著：

Control\text{Control} Authority\text{Authority} Knowledge\text{Knowledge} Capability\text{Capability}

一起移動。

這就是：

Distributed Responsibility Chain\boxed{\text{Distributed Responsibility Chain}}

而只有當這條鏈從規則一路閉合到執行、證據、稽核與救濟時：

AI Governance\text{AI Governance}

才真正從紙面制度變成：

Operational Governance\boxed{\text{Operational Governance}}

參考資料

[1] NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). 2023.
https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10

[2] NIST AIRC. AI RMF Core — Govern, Map, Measure, Manage.
https://airc.nist.gov/airmf-resources/airmf/5-sec-core/

[3] OECD. AI Principles — Accountability; Robustness, security and safety.
https://www.oecd.org/en/topics/ai-principles.html

[4] European Union. Regulation (EU) 2024/1689 — Artificial Intelligence Act. Articles 2, 25, 26, 27, 50. Consolidated version applicable 2026-07-27.
https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng

[5] NIST NCCoE. New Concept Paper on Identity and Authority of Software Agents. 2026-02-05.
https://www.nist.gov/news-events/news/2026/02/new-concept-paper-identity-and-authority-software-agents

[6] NIST NCCoE. Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization — Concept Paper. 2026.
https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd

[7] U.S. Federal Trade Commission. FTC Launches Inquiry into AI Chatbots Acting as Companions. 2025-09.
https://www.ftc.gov/news-events/news/press-releases/2025/09/ftc-launches-inquiry-ai-chatbots-acting-companions

[8] European Commission. Guidelines on obligations for General-Purpose AI providers.
https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers

[9] OECD. Advancing accountability in AI: Governing and managing risks throughout the lifecycle for trustworthy AI. OECD Digital Economy Papers No. 349. 2023.
https://doi.org/10.1787/2448f04b-en

[10] NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. 2024; updated 2026.
https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Source Note

本文中的 Distributed Responsibility Chain（DRC）、Responsibility Capability Principle、Responsibility Handoff、Evidence Continuity、Governance Gap、Responsibility Vacuum、Control-Point Accountability、Runtime Enforcement Layer、Multi-Layer Closure、Responsibility Map、Responsibility Handoff Event、Post-Operational Responsibility 為本系列提出的分析框架，並非 NIST、OECD、EU 或 FTC 的官方術語。

本文引用 NIST、OECD 與 EU AI Act，是為了說明既有治理制度已明確採用生命週期、角色分層、價值鏈責任與持續監測思維；本文將這些結構進一步抽象為 Persistent Artificial Actor 的分散式責任鏈，屬本文自身理論延伸。