AI Agent 治理的起点，不是再写一份「AI 应负责任使用」政策，而是把每个 actor 能读什么、能呼叫什么工具、何时要人核准、事后留下什么证据划清楚。先完成 capability map，再把政策逐条绑到 scope、approval、telemetry、recovery 与明确 owner，治理才会进入产品与日常流程。
为什么只有原则，挡不住一个 tool call
聊天工具主要产生文字；Agent 则可能连续读资料、呼叫工具、建立档案、送出结果或修改设定。风险不只来自恶意行为，也可能来自目标含糊、资料误读、工具描述受污染，或模型把「可以做」误认成「应该做」。
政策若只写「需有人类监督」，实作者仍不知道：哪种查询可以自动跑？谁核准？核准看到哪些参数？出错时能否撤销？同样地，「保留 audit trail」也不等于把所有 prompt 与资料全文写入 log；那可能创造另一份敏感资料副本。
NIST AI RMF Core 将 AI 风险管理分成 Govern、Map、Measure、Manage，并要求清楚界定人与 AI 的角色、持续监控及定期检视。AI RMF 1.0 目前正在修订，因此适合当作组织风险语言，而不是把单一版本当成永远不变的合规清单。
六格能力地图：把抽象治理翻成可测试问题
为一个具体 use case 填完以下六格，比从「全公司的 AI」开始更有效。
1. Scope：它在哪里工作？
列出资料来源、workspace、专案、使用者群与环境。不要只写「公司资料」，要具体到 schema、资料夹或客户范围。
测试问题： Agent 能否在没有明确选择的情况下跨 workspace？能否看到任务无关的敏感栏位？
2. Capability：它被允许做什么？
把能力拆成 read、analyze、write artifact、export、external action、admin。权限应由执行层强制，不靠 prompt 要求模型自律。
测试问题： 唯读角色呼叫写入工具时，后端是否拒绝？正式分析工具是否能在未核准状态使用？
3. Approval：哪些决定由谁核准？
核准点应和影响匹配。栏位探索可能不需逐次批准；会进财务、客户或主管会议的正式数字，应先审口径；对外传送、管理设定或不可逆动作则需更强确认。
测试问题： 审阅者看得到目的、资料范围、参数与副作用吗？拒绝后是否 fail closed？
4. Telemetry：怎么知道它真的做了什么？
至少记录 actor、时间、workspace、tool、policy／approval 结果、受影响 artifact 与执行状态。输出摘要要能连回正式 evidence，而不是只保存 Agent 的自述。
测试问题： 三天后能否回答「这个数字由哪个查询产生」？Credential 与敏感正文是否有遮蔽？
5. Recovery：出错后怎么停、怎么复原？
Recovery 包含终止 session、撤销 credential、回退可逆内容、重新执行与事件通报。要区分文字变更与真正的外部副作用；不是所有动作都能 Undo。
测试问题： 异常回圈能否中止？后续已有人工修改时，回退是否会因 conflict 被阻挡？
6. Accountability：谁拥有结果与控制？
为 use case 指定业务 owner、资料 owner、技术 owner 与 incident owner。Human approval 不会把所有责任神奇地转给「最后按按钮的人」；界面与资料不足时，核准本身也可能失效。
测试问题： 指标口径谁签、权限谁开、事故谁处理、多久 review 一次？
实例：把「分析上月转化率」分成三级
同一句任务可以依影响分级，而不是一律自动或一律封锁：
| 风险级别 | 任务 | 自动化范围 | 人类控制 |
|---|---|---|---|
| 低 | 看 schema、空值、日期范围 | 在指定 workspace 内自动探索 | 可随时中止；保留查询活动 |
| 中 | 计算内部周会漏斗 | Agent 草拟 Plan 与 SQL | 审分母、时间窗、排除条件后 Execute |
| 高 | 对外揭露或修改资料／设定 | 不直接授权 | 独立确认、限定目的地、额外 owner 核准 |
这个分级的关键不是 SQL 长度，而是错误影响与可恢复性。查询只有十行，也可能产生财报用数字；一个长达数十步的 schema 盘点，若只读且不外传，反而可能是低风险。
三种常见「有治理外观、没治理效果」的设计
每一步都让人按 Allow
确认疲劳会把核准降格成节奏障碍。把同一 Plan 范围内、可追溯的查询整合成一次有意义的授权；对超出范围的高影响动作再独立确认。
有 log 就叫 audit
若 log 看不到 workspace、工具参数与 artifact，只留下自然语言摘要，就难以调查。反过来，若把 token 与完整资料全部写入 log，也不是安全的 audit。
把 Admin 当预设便利模式
Admin 不是「比较不会卡住」，而是允许更高信任的组织与设定操作。第一次试用应从最小能力开始，以实际阻碍证明升权的必要。
OWASP AI Agent Security Cheat Sheet 将 tool misuse、privilege escalation、memory poisoning、excessive autonomy 与 sensitive data exposure 分开处理，也说明 Agent 治理不能只防 prompt injection；身份、工具、记忆与资料流都要有控制。
Lantide Data 如何把治理嵌进分析工作流
Lantide Data 是 local-first 的 SQL 分析 IDE 与 Agent runtime。正式 Project Analysis 将治理放进 Plan → review／annotation → user-approved Execute → Report：Plan 先承载问题、分母、grain 与 checkpoints，Execute 后的正式 evidence 留在 execution progress，Report 再连回证据与 limitations。流程见 Plan → Execute → Report 指南。
外部 Agent 透过本机 MCP Server 连入时，Observe／Execute／Admin 是 connection 的能力上限；Plan approval 只授权该 Plan，不会升级 connection。GUI 的 External MCP Activity 可核对 tool call、policy／review 与 artifact 变更；支援回退的文字修改仍会做 hash conflict 检查。连接、recovery 与 client compatibility 需按实际版本验证。详见 外部 Agent 整合。
这些机制降低的是「能力与证据不可见」的风险，不保证模型结论正确，也不代替组织的资料分类、法遵判断与事件处理。Local-first 也不等于所有外部模型和 connector 都把资料留在装置上。
结语：用一个真实 use case 完成第一张图
选一个资料明确、会被追问、但错误影响可控的分析，在一页内填完六格：Scope、Capability、Approval、Telemetry、Recovery、Accountability。接着各设计一个拒绝测试与复原测试。当团队能证明「不该做的做不到、做过的查得到、出错时停得下来」，政策才真正变成治理。