AI Agent 企业应用的权限边界：哪些操作必须留人工确认

AI Agent 企业应用上线时，讨论多集中在效果好不好，很少有人先把权限清单写下来。等它能调用系统接口、能发邮件、能改数据了，再回头补边界，成本高得多。

先划出必须人工确认的动作

一个实用的判断标准是看动作能不能撤回。读数据、生成草稿、做初步分类，错了改回来就行，可以放开让它做。对外发消息、修改客户资料、提交申报、付款、签合同、删除数据，这些一旦执行就很难回退，必须留在人工确认这一层。

给这套规则起个名字放在文档里，比每次靠感觉判断强。文档里逐条写：Agent 可以自主执行的动作清单、需要人工点确认的动作清单、完全禁止的动作清单。三张清单加起来通常一页纸，写起来不难，难的是有人坚持维护。

权限最小化与账号隔离

Agent 不该复用员工的账号。单独建服务账号，按最小必要授权，只给它完成任务真正需要的几张表、几个接口。客户信息、财务数据、人事档案这类敏感字段，能脱敏就脱敏，能只给聚合结果就不给明细。

《个人信息保护法》要求个人信息处理遵循最小必要原则，涉及敏感个人信息还要取得单独同意。把 Agent 当处理者看待，委托处理关系、处理目的和期限、双方责任，在合同里写清楚。这也是《数据安全法》下企业常被检查的点。

日志留痕与出事之后的追责

每次调用都留日志，记录时间、触发人、输入输出摘要、调用了哪个接口。日志至少保留到业务周期结束，涉及财务和合同类的建议按会计档案的年限参照执行。

留痕的意义在于事后能回答问题：这条对外消息是谁触发的，Agent 依据什么数据生成，中间有没有人工确认。没有日志，出事时只能靠回忆，责任分不清，客户投诉也没法复盘。

上线前值得再问一句

把 Agent 接进生产系统之前问一句：如果它今天做错了最坏的那件事，多久能发现，怎么止损。答不上来的，说明边界还没划清，先别急着扩大权限范围。

技术上的准备也不能省。把 Agent 的动作权限做成配置项而不是写在代码里，遇到问题可以临时收紧，改一行配置就能生效，比重新发版快得多。这项设计在部署阶段多花一两天，出事时能省下的是几小时的停摆。