核验清单

  • ✓员工离职当天的IT清单里，是否有一条明确写着"收回该员工名下所有云平台子账号（RAM/类似体系）权限并吊销对应API Key"，而不是只写"禁用OA账号""收回门禁卡"
  • ✓HR发起离职流程的时间点，和IT实际执行子账号权限收回的时间点，中间隔了几天——这个时间差有没有被记录下来并作为流程指标追踪
  • ✓目前发现"离职员工的子账号还能用"这类异常，靠的是月度账单对账，还是有更主动的机制（比如离职当天自动触发的权限核对任务）
  • ✓企业内部用来分配子账号和API Key的多用户体系，官方文档里关于"账号被禁用后现有Key是否立即失效"这一点，是否已经找到并读过，而不是凭经验假设
  • ✓如果同一名员工在多个大模型厂商（比如同时用了DeepSeek和通义千问）都开了子账号，是否每一家都单独走了收回流程，而不是只处理了最常用的那一个

1. 两条不同步的线：HR离职流程与IT权限收回各自为政

大多数企业的离职流程由HR系统驱动：员工提交离职申请、走完审批、HR系统在最后一天把工号状态改成"离职"，同步触发的通常是OA账号禁用、企业邮箱冻结、门禁卡挂失这类跟"人身进出"和"日常办公"直接相关的动作，这部分流程一般能做到当天生效。但云平台上的RAM子账号、大模型API Key这类资源，往往是IT或研发团队单独开通和管理的，跟HR系统之间没有自动化的联动机制——IT要收回权限，得先知道这个人离职了，通常靠HR另外发一封邮件或者在工单系统里提一条请求，IT再手动去云控制台里找到对应的子账号做处理。这中间从"HR知道"到"IT执行"，本身就隔着一层人工传递，出现遗漏或延迟的概率并不低。

2. 子账号还在，Key就还能用：权限收回不是一个原子操作

即便IT收到了离职通知，实际操作也不是点一下按钮就完事。以阿里云RAM为例，一个员工名下可能同时挂着RAM用户本身、绑定的AccessKey、被授予的权限策略这几层东西，要彻底断掉这个人调用大模型API的能力，通常需要禁用RAM用户登录、删除或禁用其AccessKey、解绑相关权限策略，缺了任何一步都可能留下能继续调用接口的缺口。DeepSeek开放平台、通义千问（DashScope）这类大模型服务，如果企业是通过自己的多用户/子账号体系分发调用权限，那么"收回权限"实际上分成两层：一层是云账号体系里的子账号权限，另一层是大模型厂商侧对应的API Key或调用凭证——两层如果不是同一套系统联动的，任何一层漏收，遗留的Key都能继续正常调用并产生费用。

3. 月度账单对账为什么总是慢半拍

目前不少企业用来发现"权限没收干净"这类问题的手段，其实是财务或IT每月对一次账单，看调用量和费用有没有异常波动。这个办法能发现问题，但天生就有滞后性：账单周期通常是一个月出一次，等你翻到账单、注意到某个子账号或Key的调用量不该出现却出现了，距离员工实际离职可能已经过去了三四周甚至更久，这段时间里的调用费用早就产生了，事后能做的只是把权限补收回来，钱基本追不回来。更麻烦的是，如果这名员工的调用量本来就不大，异常波动很容易被淹没在整体账单里，靠人工翻账单去发现，命中率并不高。

4. 企业该做的具体事：把子账号收回写进离职当天必须完成的IT清单

与其指望月度账单对账，更实际的做法是把"收回大模型API子账号权限"当成离职当天IT交接清单里一条明确、可勾选的必做项，跟收回门禁卡、禁用OA账号放在同一份清单、同一个时间节点执行，而不是走一条单独的、依赖人工邮件提醒的滞后流程。具体可以做的事情包括：把每个员工开通的云平台子账号和大模型API Key都登记在一张可查询的台账里，离职当天由IT按台账逐条核对并执行禁用/吊销，核对完成后在离职交接单上签字确认，这样即使某个环节出了问题，至少能追溯到是哪一步漏掉了。如果企业规模较大、子账号数量多，也可以考虑用云平台自身的自动化能力（比如把子账号权限跟企业身份系统做联动）去缩短这个时间差，但无论技术方案是什么，"离职当天必须完成"这条时间要求本身，不应该让位给"以后账单对账再说"。

5. 厂商规则不统一，具体操作以官方文档为准

需要说明的是，不同厂商的子账号/RAM权限收回机制在细节上并不完全一致，比如禁用子账号后已签发的AccessKey是立即失效还是有一定的缓存生效延迟、大模型服务侧的API Key是否跟随子账号状态自动联动失效，这些具体行为公开资料里没有统一说法，本文没有查到任何厂商对此给出过跨平台通用的明确承诺。企业在设计离职收回流程时，应该以自己实际使用的云平台和大模型服务商当前的官方文档为准，必要时直接在其技术支持或工单系统里确认清楚"禁用账号"和"吊销Key"这两个动作的实际生效时间和覆盖范围，不要凭经验或者别的厂商的行为去类推，这类细节因厂商而异，也可能随产品迭代发生变化。