企业在评估 OpenAI Presence 时，真正需要先回答的是两个问题：哪些数据能让 Agent 接触，以及这批候选流程里哪几条一旦出问题，能被人工及时停住；不必先追问“它能做多少”。先把权限边界和数据敏感度定下来，流程筛选才有依据；反过来先挑流程、再补权限，通常会在试点阶段反复返工。比较稳妥的顺序是：先按数据敏感度给候选流程分三档，再在管理页面把当前可见的角色与权限项逐条抄下来，然后为每条流程写明停手条件，最后用一周试点检验这套判断是否站得住。

判断方向：先用数据敏感度把流程分档、用后台实际可见的权限项划出边界，再决定哪些流程交给 Agent。操作动作是先抄权限项、再为每条流程写停手条件；验证方式是在一周试点里记录越权请求、被拒任务和人工接管次数；风险边界是后台看不到的权限项一律记为缺口，不作推测，也不默认开启。

把候选流程按数据敏感度排一遍

这一步的作用是先划出“暂时不碰”的范围。分档依据是数据本身，而不是流程听起来是否简单：同样一句“自动回复客户”，读取订单状态和读取客户身份资料属于完全不同的一档。下表可以直接做成团队内部的候选清单，接触人一栏要写清谁能看到、谁能改，流转路径一栏要写清数据从哪来、经过谁、最后落到哪。

分档完成后，把客户数据和财务数据两档里“需要写回业务系统”“需要直接对外发送”的流程单独标出来。这几条通常不是权限配置能解决的，而是流程本身还不适合交给 Agent，建议先移出首轮试点。

在管理页面逐项抄下可见的角色与权限项

权限边界要落到可以勾选的具体项上，否则讨论会停留在“应该限制一下”这种无法执行的层面。做法是打开管理后台，把角色、成员、权限分组的实际字段名原样抄下来，包括字段的层级关系。字段名以页面显示为准，不要按产品常识去猜。

角色名（后台原文）：
成员归属（哪些人或组被放进了这个角色）：
权限分组字段名（一级 / 二级）：
该分组下实际可见的勾选项：
是否支持按流程、按数据源单独授权：
看不到但业务需要的项（直接记为缺口，不推测）：
操作人与抄录时间：

抄录时重点确认三件事：谁能看（哪些角色能看到对话记录与工具返回值）、谁能批（哪些角色能发布或修改 Agent 的流程配置）、谁能停（哪些角色能停用某个 Agent 入口或收回工具调用权限）。这三项如果后台没有对应的勾选项，就老老实实记成缺口，并写明当前只能靠人工约定或流程外的手段兜底。缺口本身就是评估结论的一部分，不需要为了显得完整而补上推测。

给每条流程写清停手条件

停手条件要在试点开始前写好，不能在出事时现场商量。写法是把“什么信号、谁动手、怎么恢复、任务去哪”四件事固定下来，每条流程一份。

流程名：
暂停触发信号（择一或多项）：
  - Agent 请求了本档之外的数据
  - 同一会话内连续出现被拒的调用
  - 生成内容涉及金额、承诺、合同条款
  - 客户明确表示不满或要求转人工
暂停执行人：
暂停动作（停用入口 / 收回工具权限 / 强制回到草稿态）：
恢复确认人（不能与暂停执行人为同一人）：
暂停后转人工：原任务转派给谁、上下文如何保留、是否需要重新生成

恢复由谁确认这一点容易被忽略。建议把暂停执行人和恢复确认人分开，前者可以是一线值班人员，后者是流程负责人；两者合一，暂停就变成了可被随手取消的状态。暂停后任务转人工的方式也要写具体，比如只是把工单转派出去，还是要在工单里附上 Agent 已生成的内容和它调用过的数据范围，避免人工接手时重复读取敏感信息。

用一周试点检验筛选表是否站得住

试点的目的不是看 Agent 表现好不好，而是看前面那套分档和权限判断能不能被事实推翻。建议只放两三条流程，按统一字段记录每一起异常，字段尽量少，便于当场填。

{
  "流程": "工单首轮回复草稿",
  "分档": "客户数据",
  "事件类型": "越权请求 / 被拒任务 / 人工接管",
  "触发点": "工具调用 / 数据读取 / 内容发送",
  "处理结果": "拦截 / 降级为草稿 / 转人工",
  "是否命中预定停手条件": "是 / 否",
  "记录人": ""
}

一周结束后按下面的方向调整分档，判断依据是事件的集中程度而不是某个固定阈值：越权请求反复出现在同一条流程上，说明该流程的数据边界没划清，建议降一档或直接移出；被拒任务集中出现，可能是权限给得过紧，也可能是流程描述本身没写清 Agent 能做什么，需要先改流程说明再看；人工接管如果都发生在预定停手条件之外，说明停手条件写漏了信号，要补进去；如果人工接管全部落在预定条件上，这条流程的分档基本可以保留。

把结论收成一页给决策人

试点结束没有书面结论，前面的记录就白做了。建议一页纸，只写三种结论之一，每种结论后面挂上可核对的依据条目，依据全部来自试点记录和权限抄录表，不写感受。

• 继续：试点期内该流程没有出现分档外数据请求；被拒任务的原因能逐条解释；人工接管都发生在预定停手条件上；恢复确认人至少执行过一次确认动作。依据齐了，可以按原范围继续。
• 缩小范围：越权请求或人工接管集中在流程的某一段，比如发送环节或写回环节；此时保留生成、草稿、比对这类只读环节，把发送和写回收回到人工，并在权限抄录表上同步收紧对应角色。
• 暂停：出现分档外数据请求且未被拦住；停手条件在实际发生时没有被执行；或者根本找不到合适的恢复确认人。任何一条成立，建议先停该流程，把缺口补进权限边界再重评。

这一页还要附上权限抄录表里记为缺口的项，以及每项缺口当前的兜底方式。决策人看到的应该是“哪些能交出去、哪些交不出去、交不出去的部分靠什么挡住”，而不是一份功能清单。