为什么「连接器授权」不等于「数据权限」：AI 办业务前的两道门

AI 连上业务系统之后，不少团队会把「这个能力已经授权」当成权限控制的全部：授权通过，这件事就可以办了。实际不是。企业 AI 办业务要依次过两道门，第一道由连接器判断，看这名员工有没有资格使用这项业务能力；第二道由目标系统判断，按它原有的功能权限和数据权限，决定这次请求能看到什么、能写到哪。两道门的负责人不同，判断依据也不同。下面把这两道门拆开说清楚：各自管什么，只做第一道会留下哪些缺口，验收时又该核对哪几个动作。

核心观点

连接器授权解决的是「能不能用」，数据权限解决的是「能看到什么、能改什么」，两者不能互相替代。连接器的授权是准入，不是放行；数据范围的最终判断权留在目标系统手里。把两层压成一层，多数时候不会立刻出事，更常见的结果是：员工在 AI 里平静地拿到了一份他本该看不到的数据，事后在系统里还查不出是谁放行的。

两道门管的根本不是一件事

客户最常问的一句话是：工具已经授权给这个员工了，他怎么还是查不到那条订单？这句话里混了两件事。前一件是「这名员工有没有资格使用订单查询这项业务能力」，后一件是「他在订单表里能看到哪些行、哪些字段」。前者由连接器判断，后者由 ERP 自己判断。

这张表带来一个直接结论：连接器的授权是准入，不是放行。它回答的是「这个人配不配用这项能力」，不回答「他该看到多少数据」，更不回答「这次写入该不该落库」。让连接器去替 ERP 做数据范围判断，它做不到，也不该做。

还要说一句企业里常见的错位。同一条订单，销售看到的是自己的客户，财务看到的是金额与账期，仓储只关心发货状态。这些差异由原系统按公司、部门、岗位和数据范围算出来，经过多年业务校准。AI 进来以后，最省事的做法是在连接器侧重新实现一套数据范围规则。两套规则一旦不一致，业务人员面对的就是「AI 给的范围和系统给的范围不一样」，这时候没人知道该信哪一个。

只做第一道门，会留下三个缺口

第一个缺口出在粒度上。连接器侧的授权通常落在「员工 / 用户组 / 组织 + 业务能力」这一层，粒度是能力级的；业务数据的最小可控单位却常常细到行级和字段级。把订单查询能力授权给整个销售团队，并不等于每个销售都该看到全部客户的全部订单。这个差距没法靠把授权配得更细来补，只能让请求带着员工身份回到原系统里去算。

第二个缺口是公共账号把责任主体抹平了。为了尽快跑通，把一个高权限账号交给 AI 是最快的路径，代价是所有调用都指向同一个身份。系统日志里事后只能看到「这个账号查过什么」，看不到「哪名员工让 AI 去查的」。共享账号同时扩大了数据暴露面：任何能触发这项能力的人，实际可及的数据范围都被拉到那个账号的水平。

第三个缺口，是把界面不可见当成了权限已收回。AI 客户端可能缓存着上一次拿到的能力列表。管理员在连接器侧撤掉授权之后，界面上的入口也许刷新了，也许还留着旧缓存。如果安全判断依赖的是「用户点不到那个按钮」，那这个判断本身就不在服务端，而是交给了前端可见性。

三个缺口指向同一件事：本该由目标系统做的判断，被挪到了连接器或者界面上。补法只有一条，把身份和判断权还回原系统。

一次 AI 请求里，权限判断发生在哪几步

把一次完整的调用拆开看，权限相关动作分布在六个位置：

1. 员工在 AI 工作入口发起请求。这一动作的主体是具体的人，不是「某个 AI」。
2. 连接器判断该员工当前是否被授权使用这项业务能力。授权按员工、用户组或组织配置，按当前租户和 AI 用户处理，不依赖客户端缓存。
3. 请求把 AI 用户映射到目标系统的员工个人账号。产品支持自定义认证，具体接入方式以目标系统条件为准。
4. 请求带着这名员工的原有身份进入目标系统。连接器不附加额外权限。
5. 目标系统按自己的功能权限和数据权限作最终判断。能返回哪些数据、能不能写入，以原系统的结论为准。
6. 结果回到员工面前，关键操作由员工确认。查询、校验、预填可以自动完成；新增、修改、删除、审批默认要求人工确认。

这六步合起来，才是「不换系统、沿用员工权限、关键操作人确认、调用审计」这套做法在权限上的完整含义。少了第 3、4 步，第二道门无从判断；少了第 6 步，AI 就从帮员工准备变成了替员工决定。

三处容易忽略的边界

页面预填不等于提交成功。AI 在先打开的原业务页面里提取、校验并填好字段，是否真正生效，以页面回执或目标系统的结果为准。看到表单填满了就算办成了，是这个环节最常见的误解。

撤权要在服务端生效。连接器撤权后应禁止后续调用，并中止尚未完成的调用。旧会话缓存里的能力列表不构成继续调用的理由，客户端隐藏只是体验层的动作。

AI 不会获得员工个人账号之外的额外权限。这是一句有边界的表述，不是绝对化的安全承诺：边界在于连接器与目标系统实施两层权限判断；至于两层判断的配置是否正确、数据范围是否梳理清楚，仍属于项目评估与实施范围。

还有一个点常被忽略：能把字段填进页面，和能把数据带出系统，是两件事。字段级 ACK、多轮 revision、用户修改保护这些机制解决的是预填不覆盖员工已经改过的内容，它不解决数据范围问题。后者仍然回到第二道门。

验收两层权限时，看这几个动作

判断两层权限是不是真的生效，不需要先看架构图，看几个动作就够了。以下动作都可以通过产品能力演示核对，演示使用演示或脱敏数据，不代表任何客户的上线成果。

• 换人换范围：用两个数据范围不同的员工账号发起同一项查询，比对返回内容是否随之不同，而不是只确认「两人都能用这个工具」。
• 看身份落地：在目标系统的记录里，能否找到这次调用的真实员工身份，而不是一个公共账号。
• 看终判归属：把连接器侧的授权放宽一档，确认返回的数据范围仍由目标系统决定。
• 看撤权时机：撤掉授权后立刻发起调用，确认服务端拒绝执行，未完成的调用被中止；不要靠客户端刷新页面来「生效」。
• 看确认环节：对新增、修改、删除、审批类能力发起操作，确认默认停在员工确认这一步，而不是直接提交。

五项里，第 2 项和第 4 项最容易暴露问题，一个是身份有没有真正传到目标系统，一个是撤权是不是只在界面上发生。其余三项偏配置与流程，通常在首个场景联调时就能查清。

结语

把「连接器授权」和「数据权限」分开，是为了让每件事回到该负责的地方：连接器管准入，目标系统管范围，员工管关键决定，审计管事后追溯。企业 AI 要进入真实业务，需要每次调用都能说清「是谁、用哪项能力、对哪个系统、做了什么」；一个更大的账号解决不了这件事。

下一步通常从一个边界清晰的场景开始：选一个权限关系简单、结果容易核查的查询类业务，把员工身份、两层权限、确认和审计先跑通，再逐步扩展到更多系统。具体接入范围与实施周期，以项目评估为准。

常见问题

连接器授权通过后，AI 会不会拿到员工自己看不到的数据？ 正常情况下不会，因为数据范围的最终判断在目标系统。前提是请求真正带着员工身份进入原系统，而不是被替换成一个更大的账号。身份映射有没有落地，属于实施时必须验证的环节。

能不能干脆给 AI 一个只读账号，省掉权限梳理？ 只读能降低写入风险，但替代不了数据范围判断。一个只读的高权限账号，看到的仍然可能是全公司的数据。真实员工账号加两层权限判断，解决的是范围问题，不只是动作类型问题。

员工离职或转岗后，之前已经打开的 AI 会话还能继续调用吗？ 连接器侧的撤权应在服务端生效：撤权后禁止后续调用，并中止未完成的调用。客户端缓存的能力列表不应成为继续执行的理由。企业需要确认的是撤权链路本身是否完整，而不是依赖客户端刷新。