矩阵要能直接执行
行是角色，列是动作与数据范围，单元格填允许、拒绝或需审批，并附确认人与日期。为什么：只有文字描述的矩阵无法交接，因为接手人无法判断某条规则是否已经实现，也无法在改动时预知会影响哪些岗位。
策略与文档对号
文档里的每条规则要能指向具体配置项与版本号。为什么重要：接手人改了配置却不知道改了哪条规则，下次出问题无法定位；反过来，文档写了规则而配置里没有，等于把风险完整地留给了下一个人。
用例与例外清单
抽测用例要写明账号、问题、预期结果与判定标准，随文档一并移交；临时提权、共享账号与服务账号各自列一张表，写清用途、申请人与到期日，为什么单列：例外最容易遗忘，风险恰恰集中在这些长期授权上。
交接要有演练
让接手方独立完成一次新增授权、一次离岗回收、一次越权抽测，原负责人只做观察与记录。边界：演练不通过就不算交接完成，这一条要写进确认单，否则文档再全也只是存了一份没人读过的文件。
文档谁维护
交接文档写完就没人管，是最常见的失效方式。做法：在确认单里指定文档维护人与更新触发条件，权限矩阵、策略对照表与例外清单在每次变更后同步更新，并记录版本与生效日期；接手人按版本号能查到当时的依据，客户方项目负责人每季度抽查一次，发现文档与配置不一致即要求补齐。
适用与不适用
适合谁
- 由实施方交付后转自运维的企业与部门
- 信息中心接管业务部门 AI 应用
- 负责人变动需要平稳过渡的项目与部门
不适合谁
- 仍在建设期、权限尚未定稿的项目或演示原型
典型场景
某医药企业的合规问答系统由外部实施方交付给集团信息中心。交接会上，接手团队按文档独立完成一次新增角色授权与一次离岗回收，再用抽测集验证越权被拒；原实施方只做观察与答疑，签字确认后退出，后续变更由信息中心自行执行。
可执行步骤
- 按角色、动作与数据范围整理权限矩阵，逐格填写允许、拒绝或需审批。
- 把每条规则对应到配置项与版本号，并标注责任人与最后确认时间。
- 整理抽测用例与例外授权清单，写明账号、预期结果与到期日期，完成后归档。
- 组织交接演练，由接手方独立完成授权、回收与抽测，并留下书面记录。
常见坑
- 只交一份文字版权限说明，接手人无法定位配置项，改一次就要问一次原厂商，运维节奏被对方掌握。
- 抽测用例留在实施方手里，权限调整后没有回归手段，改动是否安全只能靠运气，出事也说不清楚。
- 例外授权散落在邮件与聊天记录中，无人知道还有哪些账号长期有效，审计时集中暴露成高危问题。
自检与验收清单
- 权限矩阵是否细化到具体动作、数据范围与例外
- 每条规则是否都能对应到配置项、版本号与责任人
- 抽测用例与例外授权清单是否随文档一并移交
- 是否完成一次由接手方独立主导的交接演练，并有记录
常见问题
文档要写到什么颗粒度？
写到接手人能独立完成一次授权变更即可。判断方法很直接：让对方按文档改一条权限，全程不提问；如果中途必须打电话确认，说明还缺配置位置、字段含义或影响范围，需要补进文档。
源码和配置要不要一起交？
属于客户方的代码、配置、知识库与测试集应一并移交，并在合同中约定归属与移交形式。涉及第三方组件的按许可协议处理，交付时列出清单与版本，避免后续升级找不到对应关系。
交接后原团队还要支持多久？
建议设一段观察期，期间原团队只做答疑与复核，不代替操作。观察期内接手方独立完成至少一次变更与一次应急演练，问题清单关闭后再结束支持，具体时长在项目确认单中约定。