梳理角色与场景
列出谁会用什么功能、需要看到哪些数据，而不是照搬旧系统的角色表。为什么：AI 应用常把多个岗位合并到一个界面，照搬会导致权限要么过宽要么不够用，上线后还要反复调整，角色表要与组织同步。
最小授权到动作
把权限从能进入模块细化到能查、能改、能导出、能让模型读取。怎么做：每个动作单独授权，导出与批量操作默认关闭，需要时单独申请并注明用途与期限，避免权限一旦发出就长期有效，导出权限尤其要收紧。
数据分级映射
把字段分级结果映射到角色，明确哪些字段可见、哪些需脱敏、哪些禁止入模。边界：涉及个人信息与客户商业秘密的字段，可见范围须由客户方数据负责人确认，不由实施方自行决定，脱敏规则要能被系统执行。
检索层过滤
权限必须在检索与生成环节生效，而不只是页面隐藏。为什么：RAG 场景里模型会把检索到的内容说出来，页面看不到但检索得到，等于没有权限，而且很难在界面上审计，抽测要形成固定动作并留下记录。
审批、留痕与复核
高敏操作走审批，所有访问与导出留日志，按周期复核授权是否仍然必要。怎么做：复核时逐条确认这个角色现在是否仍需要该权限，离岗与转岗即时回收，回收动作本身也要留记录，复核结果要留档。
适用与不适用
适合谁
- 正在设计或整改 AI 应用权限体系的团队
- 多角色共用同一界面与知识库的企业应用
- 涉及客户数据、需要向审计证明受控的场景
不适合谁
- 单人使用、无多角色区分的内部工具
- 完全不涉及业务数据的公开问答应用
典型场景
某集团的法务合同助手同时服务法务、采购与销售。设计时按角色拆分可查范围，销售只能看到本方合同且金额字段脱敏，检索层按部门过滤；导出需审批并留痕。上线抽测中，销售账号查询他方合同被正确拒绝，并复测了导出权限。
可执行步骤
- 列出每个角色、使用场景与所需的数据范围，形成可核对的权限矩阵。
- 把权限细化到查询、修改、导出与模型读取四类动作，并分别授权。
- 把字段分级结果映射到角色，明确可见、脱敏与禁止入模三档规则。
- 在检索与生成环节同步实施权限过滤，避免界面隐藏而检索仍可取到。
- 高敏操作接入审批流程，并完整记录访问、修改与导出的日志内容。
- 按固定周期复核授权必要性，离岗与转岗时即时回收权限并留下记录。
常见坑
- 只做界面隐藏，检索层仍能取到全部内容，模型照常把不该说的说出来，事后很难追溯，抽测也未必能发现。
- 角色照搬旧系统，AI 场景新增的导出、批量与生成动作没有对应授权，权限边界说不清，审计时无法解释。
- 高敏字段未脱敏就直接进入知识库，前端权限设计形同虚设，一次检索就全部暴露，且无法回收。
- 离岗人员权限未回收，账号长期有效，审计时被列为高危问题，补查成本很高，责任人却早已离岗。
自检与验收清单
- 是否形成角色、场景与数据范围的权限矩阵并评审
- 权限是否细化到查询、导出、生成等具体动作
- 字段分级结果是否映射到可见、脱敏与禁止规则
- 高敏操作是否有审批流程与完整可查的访问日志
- 检索与生成环节是否有与界面一致的权限过滤
- 是否定期复核授权，并在离岗转岗时即时回收
常见问题
权限设计要不要一次做全？
不必。先覆盖高敏场景与核心角色，上线后按实际使用补充。但检索层过滤必须在第一版就有，否则后续补权限时要重建索引与测试用例，代价明显更高，也更容易漏项，返工往往拖到二期。
模型能记住上次查询的内容吗？
会话内可能会保留上下文，因此权限校验不能只在首次提问时做。切换数据范围或角色时应清空上下文，或按会话重新校验，避免跨角色信息在连续对话中泄漏，这类问题很难被常规测试发现，需在验收时专门抽测。
权限设计和等保测评是什么关系？
等保测评关注的是安全控制是否落地，权限设计是其中的一部分。具体测评范围与结论由具备资质的测评机构出具，我方提供设计与运行记录，不代替测评结论，也不承诺一定通过。