业务负责人定范围
某个岗位该不该看某类数据，只有熟悉业务的负责人能判断，安全部门只能给原则。缺了这一方，权限矩阵往往直接照抄组织架构图，结果是权限要么过宽要么挡住正常工作，怎么做都别扭，上线后靠临时授权反复补洞，矩阵也会在半年内失效。
数据合规定分级
个人信息与客户商业秘密的可见范围必须由客户方确认，实施方不得代为判定。怎么做：把字段清单交数据负责人逐项标注可见、脱敏或禁止入模，例外的书面依据与有效期一并记录，形成可追溯的分级表，作为配置依据。
安全运维管落地
身份源、日志存储与密钥轮换都在安全运维手上。权限改造若绕开他们，上线后没人能配策略、没人查得到日志，出问题只能停系统。怎么做：从设计阶段就请他们评审接口与部署方式，而不是验收前才通知，避免二次改造。
独立抽查不可省
为什么强调独立：内部审计或风控用低权限账号复测，能发现设计与实现之间的偏差。这一环最常被省掉，一旦发生越权事件，外部首先质疑的就是验收独立性，事后补做抽查的成本远高于当初安排半天时间，也很难说服评审方。
适用与不适用
适合谁
- 跨部门共用知识库的集团企业及其实施团队
- 由外部实施方建设的 AI 应用与部门
不适合谁
- 单一团队自用、无跨部门数据的工具
典型场景
某建筑集团的人事政策助手覆盖总部与十余个项目部。评审会上，人力负责人定可见范围，法务定个人信息处理方式，信息中心确认身份源与日志方案，内部审计用项目部账号做独立抽测；实施方只提交配置与记录。四方签认后矩阵才冻结进入开发。
可执行步骤
- 列出参与方与各自要签认的决策项，形成一页可核的责任表并会签确认。
- 业务负责人逐条确认角色、可见范围与例外情形，签字后作为依据。
- 数据合规负责人逐字段标注可见、脱敏与禁止入模三档规则，并签字。
- 安全运维确认身份源、日志与密钥方案可行，内部审计另行安排抽测。
常见坑
- 只让安全部门定权限，业务不参与，矩阵与真实岗位脱节，上线后靠临时授权补洞，矩阵也会在半年内失效。
- 实施方替客户决定哪些字段可见，出问题时责任说不清，缺少书面依据，合规评审也难以通过。
- 没有独立抽查，设计与实现的偏差要到真实越权事件才暴露，追溯成本很高，且难以自证已整改。
自检与验收清单
- 每类角色是否明确决策项与签认人并记录，可现场抽查
- 字段分级是否由客户方数据负责人逐项确认，并有记录
- 安全运维是否参与接口与部署方式评审并签字
- 是否有独立于实施方之外的抽测安排与记录，可逐项核对
常见问题
小项目也要这么多角色吗？
可以合并但不能缺位。业务、数据、安全三类判断至少要有人签字，一人兼两个角色时在记录里写明兼任关系。角色缺位比人数不足更危险，因为没人会为那条权限负责，也不会有动力去调整。
业务负责人不懂技术怎么参与？
不需要懂实现，只需回答谁能看什么、什么情况下可以例外。把问题做成角色与数据清单的勾选表，业务十分钟能确认一页，比让技术人员猜业务边界可靠得多，也便于复核时对照原始判断。
内部审计没有技术背景怎么办？
给固定的抽测脚本与判定表即可：用哪个账号、问哪些问题、看到什么算越权。审计只需判断结果是否符合预期并签字，不必理解检索与权限的实现方式，门槛降下来才可能持续做下去。