企业 Agent 风险矩阵
企业 Agent 的风险不是一个总分，而是来自不同维度。
同一个请求可能数据风险低，但工具风险高；也可能工具只是查询，但输出会泄露敏感信息。
所以风险评估要拆开看。
风险分级原则
| 等级 | 判断标准 | 默认处理 |
|---|---|---|
| 低风险 | 不访问敏感数据，不改变系统状态，答案可公开 | 可直接回答，但保留基础日志 |
| 中风险 | 访问个人或部门范围数据，答案影响用户判断 | 必须权限过滤、引用或说明来源 |
| 高风险 | 改变业务系统状态，涉及敏感数据或审批责任 | 必须 HITL、审计、幂等和可恢复 |
不要让模型自己决定是否高风险。风险等级应该由工具、数据源和业务动作声明。
1. 数据风险
| 等级 | 典型场景 | 控制措施 |
|---|---|---|
| 低 | 查询公开制度、公开流程说明 | 文档版本校验、基础引用 |
| 中 | 查询本人考勤、假期、报销状态 | 强制 user_id 过滤、控制回答粒度 |
| 高 | 查询他人薪资、绩效、审批意见 | 角色权限校验、最小字段返回、审计访问 |
数据风险的底线是：无权数据不能进入模型上下文。
如果先检索再过滤，LLM 已经看到了不该看的内容，这不是合规方案。
2. 工具风险
| 等级 | 典型场景 | 控制措施 |
|---|---|---|
| 低 | 搜索文档、读取公开配置 | 工具白名单、参数 schema 校验 |
| 中 | 创建草稿、生成表单、查询业务状态 | 权限校验、参数校验、结果脱敏 |
| 高 | 提交、撤回、审批、删除、修改业务记录 | HITL、确认票据、幂等键、审计记录 |
工具风险来自副作用。只要会改变业务系统状态，就不要让 Agent 静默执行。
高风险工具必须满足四个条件：用户确认、参数冻结、调用可追踪、失败可恢复。
3. 流程风险
| 等级 | 典型场景 | 控制措施 |
|---|---|---|
| 低 | 告诉用户流程入口和步骤 | 给出当前状态和下一步 |
| 中 | 根据当前状态推荐操作路径 | 明确条件和不确定点 |
| 高 | 代用户推进流程或影响审批结果 | 状态机、HITL、补偿策略、人工可接管 |
流程风险的关键不是“能不能调用接口”，而是“当前流程是不是允许这样推进”。
不同组织、部门、角色的流程可能不同，Agent 不能把一个固定流程当成全公司规则。
4. 输出风险
| 等级 | 典型场景 | 控制措施 |
|---|---|---|
| 低 | 输出公开制度摘要 | 带引用，避免过度概括 |
| 中 | 输出个人状态判断 | 展示依据、范围和时间 |
| 高 | 输出合规结论、审批建议、敏感明细 | 限制措辞、要求来源、必要时拒答 |
输出也会造成风险。即使工具调用正确，答案表达错误也可能误导用户。
高风险输出要避免替业务负责人做最终判断。Agent 可以解释依据，但不应该伪装成审批人或合规官。
5. 模型风险
| 等级 | 典型场景 | 控制措施 |
|---|---|---|
| 低 | 分类、摘要、格式整理 | 小模型或规则优先 |
| 中 | 多源信息综合、操作步骤生成 | 结构化输出、结果校验 |
| 高 | 高风险计划生成、敏感场景推理 | 强模型、规则校验、人工确认 |
模型风险来自不确定性。越靠近写操作和敏感数据，越不能只依赖自然语言判断。
高风险计划必须经过结构校验和权限校验，不能直接从模型输出进入工具调用。
总控矩阵
| 风险组合 | 是否允许自动执行 |
|---|---|
| 低数据 + 低工具 + 低输出 | 可以自动回答 |
| 中数据 + 低工具 | 可以回答，但必须权限过滤和审计 |
| 中数据 + 中工具 | 可以半自动，需展示依据和参数 |
| 任意数据 + 高工具 | 必须 HITL |
| 高数据 + 任意工具 | 必须强权限、脱敏和审计 |
| 高输出 + 高工具 | 默认暂停，等待人工确认 |
如果多个维度风险不一致，按最高风险处理。
上线前风险检查
| 检查项 | 通过标准 |
|---|---|
| 数据源有权限字段 | 每次检索和查询都能绑定用户上下文 |
| 工具声明风险等级 | 工具注册时已经标注 low / medium / high |
| 高风险工具需要确认 | 没有确认票据不能执行写操作 |
| 输出有来源 | 关键结论能追到文档、数据或流程状态 |
| 失败能安全停止 | 不确定时停止，不猜测、不隐式重试写操作 |
风险矩阵的作用不是让系统更复杂，而是让系统知道什么时候应该停下来。