# 規則不能替代治理能力：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 的治理模型。其核心命題是：

$$
\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 不能因有技術限制就取代制度；監管者也不能只制定規則而缺乏調查、稽核與執行能力。

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

$$
\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. 問題：法律寫完，治理就完成了嗎？

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

法律可以定義：

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

但真正的制度還需要：

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

因此可以寫成：

$$
\text{Law}
\neq
\text{Governance}
$$

同樣地：

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

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

而是說：

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

---

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

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

因為主要風險發生在：

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

因此供應商可以控制：

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

這會產生：

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

也就是：

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

---

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

Persistent Agent 的行動鏈更接近：

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

供應商通常看不到：

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

因此：

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

這意味著：

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

---

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

本文提出：

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

簡寫：

$$
DRC
$$

其基本形式：

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

其中：

- $P$：Provider；
- $D$：Deployer；
- $O$：Operator；
- $R$：Runtime；
- $A$：Auditor；
- $G$：Regulator。

每個節點承擔不同 responsibility surface。

---

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

OECD AI Principles 的 accountability 原則強調：

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

這可以抽象成：

$$
Resp_i
=
f(
Role_i,
Control_i,
Knowledge_i,
Capability_i
)
$$

其中：

$$
Resp_i
$$

不是平均值。

例如：

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

但：

> 企業部署者通常知道。

所以：

$$
Resp_{\text{deployer}}
>
Resp_{\text{provider}}
$$

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

---

# 6. Responsibility Capability Principle

本文提出：

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

定義：

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

形式：

$$
Responsibility_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。

因此：

$$
Resp_P
$$

主要集中在：

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

---

# 8. Provider 不應承擔什麼？

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

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

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

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

會成為最自然的結果。

---

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

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

$$
\text{Uncertainty}
\uparrow
\Rightarrow
\text{Restriction}
\uparrow
$$

結果：

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

因此：

$$
\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。

因此：

$$
Resp_D
$$

主要集中在：

$$
\text{Contextual Governance}
$$

---

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

EU AI Act 將：

$$
\text{Provider}
$$

與：

$$
\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]

這顯示：

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

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

---

# 13. Responsibility Handoff

本文提出：

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

定義：

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

例如：

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

中間可能加入：

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

此時：

$$
Risk_{\text{deployed}}
>
Risk_{\text{base}}
$$

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

---

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

Operator 是：

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

Operator 可能知道：

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

因此：

$$
Resp_O
$$

集中在：

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

---

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

如果 operator 說：

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

這不能自動得到：

$$
Resp_O=0
$$

尤其如果 operator：

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

因此：

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

---

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

反過來：

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

例如：

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

因此：

$$
Resp_O
\neq
\text{Total Responsibility}
$$

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

---

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

Runtime 是：

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

它直接決定：

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

什麼。

因此：

$$
Resp_R
$$

集中在：

$$
\text{Executable Enforcement}
$$

---

# 18. 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。

這些不是「模型建議」。

而是：

$$
\text{Hard Capability Boundaries}
$$

---

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

規則：

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

Runtime：

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

規則：

> Agent 不得直接修改 production。

Runtime：

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

因此：

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

通常必須經過 runtime。

---

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

Runtime 可以執行：

$$
\text{Policy}
$$

但它未必知道：

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

所以：

$$
\text{Runtime}
\neq
\text{Law}
$$

也：

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

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

---

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

如果所有人都自己宣稱：

> 我們有安全政策。

還不夠。

需要：

$$
\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 是否清楚。

因此：

$$
Resp_A
$$

集中在：

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

---

# 23. Evidence Continuity

本文提出：

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

定義：

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

形式：

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

若：

$$
E_C
$$

斷裂：

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

---

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

Regulator 可以：

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

其責任是：

$$
Resp_G
$$

集中在：

$$
\text{Institutional Enforcement}
$$

---

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

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

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

這不是單純：

> 發一條規則。

而是：

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

這就是：

$$
\text{Governance Capacity}
$$

的一部分。

---

# 26. Regulation without Enforcement 是不完整的

如果：

$$
Law=1
$$

但：

$$
Monitoring=0
$$

$$
Investigation=0
$$

$$
Audit=0
$$

$$
Enforcement=0
$$

則：

$$
\text{EffectiveGovernance}
$$

可能仍然很低。

---

# 27. 一個近似乘法模型

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

$$
G_{\text{eff}}
\approx
L
\cdot
E
\cdot
T
\cdot
O
\cdot
U
\cdot
A
$$

其中：

- $L$：Law / Rules；
- $E$：Enforcement；
- $T$：Technical Controls；
- $O$：Organizational Governance；
- $U$：User / Operator Responsibility；
- $A$：Auditability。

這不是精確數學模型。

它只是強調：

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

---

# 28. Governance Gap

本文提出：

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

定義：

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

例如：

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

但：

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

這就是：

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

產生的 gap。

---

# 29. Responsibility Vacuum

本文進一步提出：

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

定義：

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

典型語句：

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

如果所有層都這樣說：

$$
Resp_{total}\rightarrow0
$$

但：

$$
Impact>0
$$

這就是 Responsibility Vacuum。

---

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

成熟治理不應問：

> 出事後誰最適合背鍋？

而應問：

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

也就是：

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

這叫：

$$
\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 包含：

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

且：

$$
\text{Govern}
$$

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

---

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

NIST AI RMF 明確強調：

$$
\text{Risk Management}
$$

應該：

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

這對 Persistent Agent 特別重要。

因為：

$$
Agent_{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]

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

$$
\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]

這非常接近：

$$
DRC
$$

的制度直覺。

---

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

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

它正式定義：

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

這代表：

$$
\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]

這是一個重要結構：

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

沒有資訊移交：

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

---

# 38. 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. 責任與資訊不能分離

如果：

$$
Responsibility_D
\uparrow
$$

但：

$$
Information_D
\downarrow
$$

那麼：

$$
GovernanceQuality_D
\downarrow
$$

這是一個結構性錯誤。

---

# 40. Agent 時代還需要 Authority Handoff

除了資訊：

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

也需要明確。

例如：

> Provider 只提供 base model。

Deployer 給 Agent：

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

那麼新增 authority：

$$
\Delta Auth
$$

是由 deployer 建立的。

因此：

$$
Resp_D
$$

也應上升。

---

# 41. Capability Addition 應帶來 Responsibility Addition

本文提出：

$$
\boxed{
\Delta \text{Capability}
\Rightarrow
\Delta \text{Responsibility}
}
$$

若某 actor 為 Agent 加入：

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

就不應仍聲稱：

> 所有責任仍在 base-model provider。

---

# 42. 責任鏈也應處理多 Agent

若：

$$
A_0
\rightarrow
A_1,A_2,A_3
$$

主 Agent 委派 subagents。

那麼責任鏈變成：

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

這比單 Agent 更複雜。

---

# 43. Delegation Chain

本文提出：

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

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

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

避免：

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

---

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

原則：

$$
Auth_{child}
\subseteq
Auth_{parent}
$$

通常合理。

並且：

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

這延伸 least privilege。

---

# 45. 多 Agent 系統會放大 Responsibility Diffusion

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

> 到底誰負責？

若沒有 lineage：

$$
\text{Resp}
\rightarrow
\text{Diffuse}
$$

所以 multi-agent system 更需要：

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

---

# 46. Runtime 需要保存因果譜系

可以寫成：

$$
\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

若出事故：

$$
\text{Incident}
$$

稽核者應能回答：

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

這才是真正 accountability。

---

# 48. Multi-Layer Closure

本文提出：

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

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

$$
\text{Intent Closure}
$$

$$
\text{Authority Closure}
$$

$$
\text{Execution Closure}
$$

$$
\text{Evidence Closure}
$$

$$
\text{Responsibility Closure}
$$

---

# 49. Intent Closure

回答：

> Agent 是否正確理解任務？

---

# 50. Authority Closure

回答：

> Agent 是否真的有權限做？

---

# 51. Execution Closure

回答：

> action 是否真的依規定執行？

---

# 52. Evidence Closure

回答：

> 是否有足夠證據重建？

---

# 53. Responsibility Closure

回答：

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

只有五者都成立：

$$
TaskGovernance=\text{Closed}
$$

---

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

就會出現：

> 政策寫得很好。

但出事後：

> 沒人知道發生什麼。

這是：

$$
\text{Paper 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 速度可能是：

$$
10^3
\sim
10^6
$$

次。

人工逐條審查不可能。

因此需要：

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

---

# 57. Governance Agent 可能監督 Agent

未來可能出現：

$$
A_{\text{worker}}
$$

與：

$$
A_{\text{governor}}
$$

例如：

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

這不是把責任交給 AI。

而是：

> 用 AI 擴大治理能力。

---

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

否則：

> 誰監督監督者？

所以：

$$
A_{\text{governor}}
$$

仍需要：

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

---

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

一個常見誤解：

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

因此 DRC 必須強調：

$$
\text{Distributed}
\neq
\text{Diluted}
$$

---

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

例如：

Provider：

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

Deployer：

> 配置本地權限與監測。

Operator：

> 提供 truthful intent 與必要確認。

Runtime：

> 執行 technical boundaries。

Auditor：

> 驗證記錄與控制有效性。

Regulator：

> 建立標準、調查與執行。

這樣才不是：

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

---

# 61. Responsibility Map

每個 Agent deployment 應該有：

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

至少寫明：

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

---

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

如果只存在：

> 100 頁合約。

Agent runtime 根本不能使用。

因此 Responsibility Map 應該具有：

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

讓：

- approval engine；
- logging；
- escalation；
- policy enforcement；

直接讀取。

---

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

例如：

```text
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 擴張；

應產生：

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

並更新：

$$
ResponsibilityMap_t
\rightarrow
ResponsibilityMap_{t+1}
$$

---

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

因為：

$$
Agent_t
$$

與：

$$
Agent_{t+100}
$$

可能有完全不同：

- model；
- tools；
- authority；
- deployment。

因此：

$$
Resp_t
\neq
Resp_{t+100}
$$

治理歷史必須 versioned。

---

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

當 Agent 退役：

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

這就是：

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

---

# 67. AI lifecycle 不應在 Delete 時失憶

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

$$
\text{Delete}
\rightarrow
\text{EvidenceLoss}
$$

就可能破壞：

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

所以：

$$
\text{OperationalDeletion}
\neq
\text{AuditDeletion}
$$

---

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

當然：

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

因此：

$$
\text{Audit Retention}
$$

與：

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

會形成新的治理張力。

這需要：

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

---

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

需要特別澄清：

本文的 DRC 是：

$$
\text{Governance Engineering Model}
$$

不是：

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

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

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

另行決定。

DRC 的目的只是：

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

---

# 70. 本篇核心命題

### 命題一

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

---

### 命題二

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

---

### 命題三

$$
Responsibility_i
\propto
Knowledge_i
+
Control_i
+
Intervention_i
+
Recovery_i
$$

---

### 命題四

$$
\Delta \text{Capability}
\Rightarrow
\Delta \text{Responsibility}
$$

---

### 命題五

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

---

### 命題六

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

---

### 命題七

真正的責任治理需要：

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

---

### 命題八

Persistent Agent governance 應從：

$$
\text{Policy Document}
$$

升級成：

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

---

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

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

> **沒有人擁有所有上下文。**

模型供應商知道：

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

企業部署者知道：

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

操作者知道：

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

Runtime 知道：

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

Auditor 知道：

- 控制是否真的有效。

Regulator 則具有：

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

因此：

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

而不是：

$$
\text{One Omniscient Governor}
$$

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

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

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

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

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

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

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

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

而是：

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

責任應該跟著：

$$
\text{Control}
$$

$$
\text{Authority}
$$

$$
\text{Knowledge}
$$

$$
\text{Capability}
$$

一起移動。

這就是：

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

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

$$
\text{AI 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 的分散式責任鏈，屬本文自身理論延伸。