先说结论：企业 AI 的安全，不靠重新建一套权限体系，而靠把 AI 塞进你现有的身份、权限和审计体系里。

这句话听起来像常识，但实际落地时，大量企业恰恰是在这里翻车的。

为什么这件事比想象中严重

很多人把企业 AI 的权限问题，等同于"给 AI 加个登录"。但真正的风险点是：

智能体一旦拿到写入权限，它影响的就不是"页面显示什么"，而是真实的业务数据和流程。

一个只会问答的 AI 答错了，顶多是尴尬；一个能审批、能回写、能调额度的智能体做错了，是真金白银的损失。

企业用大模型，主要就这么五类风险：

1. 敏感信息泄露——员工把涉密内容贴进对话框，或 AI 把 A 部门的数据答给了 B 部门；
2. 越权访问——AI 绕过岗位和组织边界，看到了本不该看的数据；
3. 误用工具——调用了不该调用的接口；
4. 提示注入——外部内容里藏了指令，诱导 AI 执行非预期动作；
5. 错误执行——理解对了，但执行错了，直接改了业务数据。

前四类在传统软件时代都有对应解法，第五类是 AI 时代新增的——你要把"AI 的动作"当成"人的操作"一样来管。

权限不越界：接入前必须确认四件事

这四条是可以拿去现场逐项问厂商的：

1. 身份映射：AI 到底是"以当前用户身份"访问，还是另有一套超权限账号？
2. 读取范围：能不能只看到本岗位、本组织、本区域的数据？
3. 操作授权：查询、建议、写入、审批分别对应什么权限，谁授权？
4. 日志保留：保留哪些字段、保留多久、谁能查？

一个能立刻做的验证方法

不要只看登录功能，用不同岗位访问同一份数据做交叉测试：

• 让河北分公司的财务角色，去问河南分公司的营销数据——应该问不到；
• 让只有查询权限的角色，去执行采购审核技能——应该执行不了；
• 而且查询权限和写入权限要分开测，这两个经常配得不一致。

这里有个特别容易被绕过去的坑，值得单独说：

如果 AI 是通过一个统一的系统账号去取数，而不是继承当前用户的身份，那么权限校验实际上是被绕过的。

工程上这么做最省事，合规上是重大缺陷。验收时一定要问清楚这一条。

审计追溯：AI 每次运行至少要记六件事

1. 用户身份
2. 输入内容及引用来源
3. 模型与配置版本
4. 工具调用记录
5. 审批过程
6. 处理结果

必要时还要保存决策依据摘要——也就是"AI 为什么这么判断"。出事之后要复盘，缺了这个基本查不清。

人工确认怎么设计？按风险分级

不是所有动作都要人审批，那样效率就没了。按风险分三档就够：

• 只读、低风险：AI 直接干，留日志；
• 低风险写入（补字段、生成草稿）：干完留痕，抽查；
• 高风险动作（冻结资金、支付、调整额度）：必须按企业授权执行，保留审批和人工确认。

还有一条要提前写死：失败时是停止、恢复还是转人工。别等出事再商量。

最后提醒两个容易踩的坑

第一，治理能力不是装上就自动生效的。 平台可以提供治理支持，但实际控制效果取决于项目里的配置、测试和运维落实。日志范围和保留时间也要提前约定，否则事后追溯会缺关键字段。

第二，别信"零错误"。 生成式 AI 不可能零错误，权限控制和审计只能降低风险。负责任的做法是按错误后果设定验收阈值，高风险任务保留人工确认——而不是在合同里写一句"准确率 100%"。