多部门共用 AI 平台，权限应该怎么设计

多部门共用 AI 平台，权限不能只做「谁能登录」。正确做法是让每次请求依次通过用户、数据、工具、动作四层校验：谁在用、能看什么、能调用什么、能做到哪一步。任一层不满足，请求就拒绝、降级或进入审批。

本文只讨论平台运行时权限：访问业务数据、调用工具、写入或执行。知识库的文档与检索权限是另一问题，不在此展开；两者不能用同一条「可访问」规则代替。

先把权限写成一句完整的业务判断

可执行的权限规则至少要回答：哪个主体，在什么上下文中，可以对哪类数据，通过哪个工具，执行什么动作。例如「华东区销售在本人负责客户范围内，可通过 CRM 工具创建跟进草稿；对外发送须由本人确认」。如果规则只写「销售可用 CRM 助手」，数据范围、动作边界和确认责任都还是空白。

最小权限不是一味把权限设得越少越好，而是让完成当前任务所需的权限足够、其余默认关闭，并限制持续时间与影响范围。NIST SP 800-53 的访问控制族把最小权限作为明确控制项；落到 AI 平台上，就是不因一个人能使用聊天入口，就顺带授予导出、写入、发送和批量执行能力。

权限还要区分直接允许、需要批准和禁止。AI 可以发起请求，确定性策略和业务系统负责最终授权，使平台不必在全开与全关之间二选一。

一次请求要连续通过用户、数据、工具、动作四道门

第一道是用户门：身份是否有效，所属组织、岗位与账号状态是什么，当前会话是否满足登录强度要求。第二道是数据门：请求涉及的客户、订单、字段和时间范围是否属于该用户可访问的业务范围。第三道是工具门：平台是否允许他调用 CRM、ERP、邮件或文件导出连接器。第四道是动作门：即使工具可用，本次究竟只能查询、生成草稿，还是可以修改、发送或执行。

四层必须取交集，不能互相替代。财务主管有查看某类付款数据的权利，不代表 AI 平台可以调用付款工具；平台获准调用付款工具，也不代表该用户可以批准自己的付款。后端在真正调用目标系统前应再次校验，不能只相信前端隐藏了按钮，也不能只依赖模型在提示词里自我约束。

NIST 零信任架构不因网络位置或受管设备给予隐式信任。公司内网只是上下文之一，主体、资源与动作仍要逐次判断，以限制被转发链接、被窃会话和越界调用。

用户权限要跟着入职、转岗和离职变化

用户层从可靠身份开始。企业已有统一身份系统时，AI 平台应复用登录、组织和账号状态，而不是再维护一套长期不同步的名单。SCIM（System for Cross-domain Identity Management，跨域身份管理系统）等标准协议可用于在系统间管理用户与群组，但是否采用取决于现有架构；核心要求是人员变化能够及时传到平台。

角色承载「销售专员」「财务复核人」等稳定共性，不为每个临时例外复制新角色。地区、项目和客户归属由业务属性限定：同岗位销售共享工具集，却只看各自客户；临时加入项目获得会到期的项目范围，而非永久管理角色。

转岗比入职更容易漏。员工从销售转到运营，新权限开通了，旧客户导出权限却可能还在；离职账号停用后，个人创建的自动任务和长期令牌也可能继续运行。因此账号生命周期要同时处理交互登录、接口令牌、代理任务、共享空间所有权和待审批事项。撤销权限必须覆盖机器替人运行的部分，而不只是关闭页面账号。

数据权限控制业务对象与字段，不只控制页面入口

数据层要把抽象的「可访问业务数据」拆成对象、记录和字段。对象决定能否接触客户、合同、订单或员工记录；记录范围决定是本人、项目组、区域还是全公司；字段范围再排除身份证件、成本、薪酬或其他不必要内容。这样的控制应在数据服务或源系统执行，不能让模型先拿到全部数据再承诺不说。

还要把用途和输出范围带进判断。同一名员工为了处理单个客户问题可以查看相应订单，不等于可以批量导出整区客户做个人分析；允许内部汇总，不等于允许把原始明细发到外部邮箱。数据边界的管理决策可以参考企业使用 AI 前的数据边界框架，平台权限则把边界落实为查询条件、字段过滤、脱敏和导出限制。

数据权限变化时，缓存、索引和历史会话也要同步处理。用户离开项目后，旧缓存不能继续返回摘要，历史对话也不能追问出新细节。权限应在每次取数和动作前判断，而非只在会话开始时判断。

工具权限决定 AI 能伸出哪只手

工具是 AI 连接外部能力的通道，包括业务系统接口、邮件、日历、文件、搜索、代码执行或自动化连接器。理解模型如何调用函数，可先看Function Calling 的工作原理；权限设计要抓住另一点：模型能生成一个调用意图，不代表执行器必须接受。工具清单和凭证由平台控制，模型不能自行发现并启用未授权连接。

每个工具要有独立服务身份、允许用户范围、允许环境和调用限制。不要把一个管理员凭证藏在连接器里供所有部门共用，也不要让多个工具共享无法区分用途的长期密钥。用户请求到来时，平台把用户权限与服务权限取交集：服务能查全公司订单，用户只负责一个区域，实际查询仍只能落在该区域。

工具还需要可停用和可替换。发现邮件连接器异常时，应能只关闭外发，不影响内部问答；ERP 接口维护时，应降级为无法读取实时状态，而不是让 AI 猜一个答案。接入业务系统的服务身份、日志与回滚方法，可结合AI 接入 ERP 和 OA 的风险阶梯设计。

动作权限把「能用工具」继续拆到查询、写入和执行

同一个 CRM 工具可以查询客户、创建草稿、修改正式记录、批量导出或发送消息；若权限只控制「能不能用 CRM」，风险差异就被抹平。动作应形成清晰阶梯：读取事实，生成但不落库，创建草稿，修改指定字段，提交审批，对外发送，触发不可逆或高影响执行。每一档分别配置允许角色、数据范围、影响上限和审批要求。

高影响动作要实行职责分离。提出请求的人不一定能批准，配置策略的人不应仅凭自己就放行例外，审计人也不应修改待查日志。例如 AI 生成供应商付款建议，业务人员可发起，财务复核人批准，支付系统再按自身规则执行；平台不能把三种身份合并成一个「财务管理员」。

人工批准的对象必须具体到内容和版本。批准「允许 AI 发邮件」过于宽泛；应批准收件人、主题、附件、正文版本与发送时点。审批之后若内容或附件变化，原批准失效。对于需要人工复核的输出，AI 产出分级复核方法可帮助把风险高低对应到不同闸门。

上下文条件与临时授权处理真实业务里的例外

角色和部门无法表达所有场景，还要判断环境、设备与会话风险、值班状态、动作影响，以及数据是否冻结。上下文不是为了堆规则，而是阻止同一权限在错误时机被机械复用。

临时授权要有申请原因、批准人、明确范围、到期时间和使用记录。到期自动撤销，不能靠申请人记得归还。紧急访问可以设「破窗」路径：在正常流程来不及时允许指定人员进入，但立即告警、强制记录理由，并在事后复核。破窗不是隐藏的超级账号，而是一条透明、短期、可追责的例外通道。

平台还要限制授权链的扩散。用户把一个 AI 应用分享给同事，不应顺带分享自己的数据和工具凭证；复制一个工作流，也不应复制创建者的高权限令牌。被分享者运行时重新以自己的身份经过四层校验，无法满足时应请求授权或使用受限版本。

用权限矩阵、反向测试和审计循环证明设计有效

上线前建立权限矩阵：典型角色对应数据范围、工具、动作、审批人和例外条件，覆盖高频路径与高影响边界。除验证正常成功，还要测试跨区域查询、绕过隐藏按钮直调接口、复用过期令牌、修改已批准内容和以批量请求绕过单次限制。

审计记录应能回答谁以什么身份，在什么上下文，对什么数据，调用了哪个工具，尝试或完成什么动作，哪条策略允许或拒绝，谁批准了哪个版本。日志访问本身也受限，并设置保留、检索和异常告警。只有聊天文本而没有工具与策略记录，无法还原真实业务影响；只有接口成功码而没有发起人，也无法追责。

运行后定期复核闲置权限、转岗残留、长期临时授权、异常拒绝、共享应用和服务凭证。权限模型随组织和工具变化，不会一次设计后永久正确。生产化所需的运营责任、监控和回退，可继续参考AI 项目从试点到上线的检查清单。

企业 AI 权限设计的核心，不是做出更多角色，而是让每个真实动作都有完整授权链。用户层确认主体，数据层限制可见事实，工具层限制可调用能力，动作层限制可以产生的结果；上下文、审批和审计再把四层连起来。这样，多部门共享的是同一个平台，而不是同一把万能钥匙。