AI 员工的单点登录集成：身份、权限与离职

AI 员工的单点登录集成，指的是让智能体以受控身份接入企业已有的账号体系，复用既有的登录、组织与权限信息。它看起来只是一个接入环节，实际上决定了 AI 员工能不能被当成一个正常的成员来管理 —— 如果它游离在账号体系之外，离职、调岗与权限回收这些日常动作在它身上就全部失效

为什么必须走已有账号体系

• 人员变动自动生效：调岗与离职在账号体系里处理一次，AI 员工这边同步生效。
• 权限只有一处来源：避免出现两套权限，两边不一致时无从判断。
• 审计有共同口径：谁在什么时候以什么身份做了什么，记录可以互相印证。

身份怎么映射

映射的核心是回答一个问题：这次操作代表谁。常见的三种形态需要区分对待，混在一起就会出现责任不清。

• 代表个人：以使用者本人的身份执行，权限与可见范围完全等同于该员工本人。
• 代表岗位：以岗位身份执行，例如「客服岗位的 AI 助手」，权限随岗位定义变化。
• 代表系统：由系统自身发起，例如定时任务，需要有独立的身份与明确的用途说明。
• 映射要留痕：每一次以某种身份执行，都能查到当时的身份来源。

权限从哪来

权限不应当由 AI 员工自己维护一份清单，而应当从账号体系与岗位定义中派生。派生关系要能反过来查：看到某个权限，能说清它是根据哪条岗位定义或哪条授权得来的。

• 以岗位为主：多数场景按岗位授权，人员变动时权限自动跟随。
• 以个人为例外：临时授权要有期限，到期自动失效而不是靠人记着收回。
• 数据权限与动作权限分开：能看什么和能改什么是两件事，不能打包授予。
• 敏感动作单独审批：对外发送、资金相关与批量变更类动作，逐次确认。

变更与离职怎么处理

• 调岗：新岗位权限生效、旧岗位权限失效，两步都要有动作，不能只加不减。
• 离职：账号停用后，以该身份运行的任务要一并停止或转交，避免留下无人负责的执行。
• 休假与代理：代理关系要有明确期限，代理期间的记录要能区分本人与代理人。
• 定期核对：按季度核对实际权限与岗位定义是否一致，找出长期未使用的授权并清理。

审计要看什么

审计不是把所有日志都留着，而是能在需要时回答三个问题：谁、以什么身份、做了什么。

• 操作主体可查：能区分是本人操作、AI 员工代为执行，还是系统定时任务。
• 权限来源可查：每个动作对应的授权依据能指出来。
• 时间与结果可查：能还原一次完整执行，包括失败与重试。

接入时的三个常见坑

• 只做登录不做停用：账号停用后会话仍然有效，权限实际上没有被收回。
• 权限一次全给：为了省事先把权限合并授予，后续无法按岗位回收。
• 身份写死在配置里：人员变动要改配置，而实际上没有人会主动去改。

验收口径

• 人员调岗或离职后，AI 员工的权限随之变化，无需单独维护。
• 每一次执行都能说明它代表谁。
• 临时授权有明确期限，到期自动失效。
• 存在定期核对机制，能发现长期未使用的授权。