核心结论
授权复核要核对当前对象、范围和依据。固定周期与人员、能力、系统变更事件结合；调整后用服务端调用结果和目标系统权限验证生效，并由企业保存复核记录。
企业给 AI 开通业务能力时，上线前通常会把授权认真定一遍：谁能用、能用哪些能力、范围多大。上线之后，这份授权清单往往就没人再翻。半年过去，员工换了岗，能力改了两版，目标系统的角色也调过，当初合理的范围已经不一定合身。这篇说明 AI 权限治理里的授权复核要回答哪几件事、多久做一次、清单里该留哪些证据，以及复核之后的收回为什么必须落在服务端执行上。
核心观点
授权配一次、之后不再动，是不少企业的默认状态，也是治理里最容易留下空档的地方。企业需要的是一个能定期回答「今天谁还能用、范围是否仍然合理、依据能不能查」的机制。
授权配好之后，治理最容易松掉的那一段
AI 业务能力的授权和普通账号开通不太一样。员工岗位会轮换，业务边界会随组织调整，AI 能力本身与接口也会改版。授权清单如果只在项目上线那一刻是准的，后面就会慢慢和实际情况脱开。
脱开之后的问题不会立刻暴露。员工还用着他其实已经不该用的能力，界面上一切正常；等到内部审计或合规检查问起「这个人为什么能看到这个数据」，才发现当初授权的那份依据已经说不清楚。这类问题处理起来比技术故障麻烦，牵扯的是流程和责任，不是一个可以重启的服务。
也有相反的情况。企业为求稳妥，上线时把范围压得很小，业务跑顺了也一直没往上调。结果是能力明明具备，业务部门还在抱怨用不了，最后绕开系统自己想办法。范围偏大和偏小一样，都会让治理失去意义。
复核实际要回答的三件事
把授权复核拆到具体动作上，无非三件事。
谁现在还能用这项能力。要能列出当前的授权对象，是员工、用户组还是组织，各自的依据是什么。
现有范围是否仍然合理。岗位、职责、目标系统角色调整之后，原来的范围是否还对应得上。
这一轮复核的依据能不能查。谁在什么时候基于什么判断保留或收紧了授权，事后要能重新调出来。
这三件事听起来简单，做起来容易只做前两件。剩下那一件最常被跳过，也最要紧：没有留痕的复核，下一轮还要从零判断一次，也说不清上一轮为什么那样决定。
什么时候该复核：固定节奏加事件触发
只靠固定周期，中间发生的变动要等很久才被发现；只靠事件触发，又容易变成谁都没想起要查。比较稳的做法是两条线一起用。
触发类型；典型时点；重点看什么
固定复核；按季度或半年一次；全量授权范围、离职转岗遗留、长期未调用的能力
人员变动；转岗、离职、借调结束时；该员工关联的所有能力授权与旧会话
能力变更；能力升级、接口改版、能力停用；原授权是否随能力版本继续成立
系统调整；目标系统角色或组织架构调整；目标系统侧权限与连接器侧授权的对应关系
异常与审计；审计发现异常调用或被投诉时；该次调用路径上的全部授权依据
固定复核负责兜底，事件触发负责及时。两条线都要有个明确的负责人，否则很容易变成 IT 以为业务在查、业务以为 IT 在查。
一份可以照着填的复核清单
下面这份清单可以直接放进复核记录里，逐项填。它不依赖某家企业的特殊流程，关键是把判断依据写清楚。
复核项；判断依据；记录中应留下什么；不通过时的动作
授权对象是否在职在岗；组织架构与岗位职责；复核日期、核对来源；转岗则调整范围，离职则撤权
授权范围与岗位是否匹配；该岗位实际需要的能力清单；保留与收紧的项及理由；收紧到岗位所需范围
目标系统侧权限是否一致；目标系统中该员工的角色；两侧对照结果；以目标系统判断为准，调整连接器侧授权
长期未调用的授权；调用审计中的使用记录；未调用时长与保留理由；无合理理由的予以收回
旧会话与客户端缓存；调用前后的授权校验结果；校验时间与结果；撤权后确认执行已被阻断
复核本身的留痕；审计记录与导出件；复核人、复核时间、结论；补齐记录后再算完成
这张表里最容易被忽略的是最后一行。复核做没做，不能靠回忆，企业应留存一份可导出的复核记录。审计与复核记录存多久，按企业自己的合规要求配置，没有一个通用天数。
复核之后怎么收回：撤权要落在执行上
复核结论只有落到执行上才算数。把能力从界面上拿掉，或者在客户端隐藏掉一个工具，看着像撤了，实际未必。AI 客户端可能还缓存着旧的工具列表，员工手里那个会话也还开着，请求照样能发出来。
比较稳的做法是让每次调用回到服务端重新做一次授权判断。连接器这边撤销授权之后，后续调用被拒绝；尚未完成的连接器调用被中止；若目标系统已完成业务动作，仍需核对回执，不能把中止视为自动回滚。两者差别在于，收回动作拦住的是执行本身，界面上看不看得见并不能说明执行已经被挡住。
还要留意判断的层次。连接器这一层决定这个员工、这个用户组或者这个组织能不能调用某项能力；具体能看到哪些行、哪些字段，由目标系统按它自己的功能权限和数据权限做最终判断。复核时两侧都要对，只对一侧，另一侧仍可能留着更宽的范围。
界面隐藏不等于撤权生效。 撤权是否完成，要看撤掉之后发起的调用有没有被服务端阻断，以实际执行结果为准。
授权复核不等于重配一遍。 复核的结论可能是保留、收紧或者收回，多数情况下不需要推倒重来。
数据侧的最终边界以目标系统为准。 连接器侧的授权范围可以收起，数据权限仍由目标系统判断。
怎么判断复核真的在做
一个可操作的判断办法是看证据，不看承诺。下面几项都可以在实际产品能力演示中核对，演示使用演示或脱敏数据，不代表任何客户的上线成果。
任意时间点问「某员工的 AI 业务能力授权有哪些」，能得到一份带依据的清单，不必临时去问人。
用两个岗位不同的员工账号发起同一项能力调用，可查范围不同，差异来自目标系统的权限判断。
撤销某名员工的授权后，不刷新客户端直接发起调用，请求被服务端拒绝。
被中止的在途调用在审计里能看到，能定位到当时的授权状态。
企业为每次复核保存一份可导出的记录，含复核人、时间、结论和调整项。
审计里能查到员工与 AI 身份、调用入口、业务能力、目标系统、时间、耗时、结果和输入输出摘要。
这六项里，前两项在首次联调时就能查清，后几项要连着授权管理、审计和流程一起看。
复核后的验证应从真实岗位身份出发：查看授权清单，收回不再需要的能力，再用未刷新旧会话发起调用，核对服务端拒绝及审计记录。目标系统已经完成的业务动作仍以实际回执为准，撤权不能代替业务回滚。页面预填 ≠ 提交成功。上述流程为方法示例，不是客户案例。
原文与完整依据：官网文章