坑一：全员管理员
上线初期为省事把所有人设成管理员，之后再也没收回。为什么危险：AI 应用能批量导出与生成，一次误操作的影响远大于传统表单。改法：从第一天起按最小权限发放，临时提权设置到期时间，临时提权要到期。
坑二：照搬旧角色
旧系统按部门划分角色，AI 场景却按任务划分，直接照搬会出现能看不能问或能问不该看。改法：按实际工作流重新梳理角色，把查询、导出、生成分别授权；边界：跨部门数据仍需单独授权，角色表要按任务重画。
坑三：检索不过滤
界面按权限显示了菜单，但向量库检索没有过滤条件，模型仍能读到全部切片。识别信号：用低权限账号提问，回答里出现其他部门的数据；为什么难查：界面上看不出任何异常，只能靠抽测发现，抽测要覆盖跨部门问题。
坑四：服务账号过大
为了让同步任务跑通，给服务账号开了全库权限，一旦凭据泄露影响面极大。改法：服务账号按任务最小化授权，凭据定期轮换并纳入密钥管理，不在代码与配置里明文存放。怎么做：把授权范围与轮换周期写进运维规范。
坑五：日志不留存
只记录登录不记录查询与导出，出问题无法追溯谁看过什么。怎么做：至少保留访问主体、时间、数据范围与操作类型，按合规要求设定保存期限，确保日志本身不可被普通账号修改，日志要单独存储。
适用与不适用
适合谁
- 准备上线或正在整改 AI 应用权限的团队
- 发生过越权或数据外泄疑虑的组织
- 需要通过安全审计与等保测评的系统
不适合谁
- 单人使用、无数据隔离需求的工具
- 完全离线、仅处理公开资料的演示系统
典型场景
某制造企业的设备知识助手在抽测中被发现：低权限账号询问其他工厂的故障记录，回答给出了具体参数。排查确认检索层未注入权限条件。团队在检索查询中加入工厂维度过滤，重建索引并复测，同时把服务账号权限收敛到只读单库。
可执行步骤
- 清查现有账号，找出管理员泛化、共享账号与长期未回收的权限项。
- 按实际工作流重新划分角色，把查询、导出与生成三类动作分别授权。
- 在检索查询中强制注入权限过滤条件，并用低权限账号做逐项抽测。
- 把服务账号权限收敛到任务所需的最小范围，凭据统一纳入密钥管理。
- 补齐查询、修改与导出日志，并按合规要求设定保存期限与访问权限。
常见坑
- 管理员权限发出去容易收回难，半年后名单已无人能说清谁还有权限，审计时只能全量重置。
- 检索未加过滤条件，越权内容借模型回答自然流出，且难以被界面审计发现，事后追责也没有依据。
- 服务账号持全库权限且配置明文存放，凭据一旦泄露即造成全量数据暴露，影响面覆盖所有客户。
- 只记录登录日志，无法回答谁在什么时候看过哪份合同，事件调查无从下手，只能被动等待监管问询。
自检与验收清单
- 管理员账号是否逐一登记、有到期时间并定期复核
- 角色是否按实际工作流划分而非照搬部门结构
- 检索查询是否强制注入权限过滤条件并做抽测
- 服务账号是否按任务最小化授权并定期轮换凭据
- 是否留存查询、修改与导出日志并设定保存期限
常见问题
权限太严会不会影响使用？
初期会有摩擦，但可以通过默认角色与申请流程缓解。权限过宽带来的风险是不可逆的：数据一旦被导出或回答出去，无法收回。建议先收紧再按实际反馈逐项放开，并保留审批记录。
低权限抽测怎么做？
用各角色的测试账号提同一组问题，检查回答与检索结果是否只包含授权范围。抽测样本应包含跨部门、跨项目与敏感字段三类问题，并保留记录作为审计证据，抽测频率建议与人员变动同步。
日志要保存多久？
按客户方合规要求与行业惯例确定，涉及个人信息处理的应满足相应保存期限要求。关键是日志完整、不可篡改、可检索，而不只是保存时间长，否则长而无用，也难以在事件调查中支撑结论。