政企大模型平台演示时，提问、生成和工具调用通常都能顺畅完成。真正决定能否进入生产的，却是三个不那么显眼的问题：模型能接触哪些数据，哪个身份可以执行哪些动作，发生争议时能否还原当时的授权与结果。数据、权限和审计只要有一项脱节，平台功能越强，潜在影响面反而越大。

本文面向平台、安全、数据、审计与业务负责人，给出选型阶段的核对方法。文章讨论的是控制设计和POC问题，不代表采购某个平台即可满足所有合规要求；数据分类、授权审批、保留期限和风险接受仍由企业制度与专业角色决定。

从数据旅程找边界，不从“是否私有化”推断安全

私有化部署能改变数据所在环境，却不能自动说明数据由谁访问、被哪些组件处理、产生哪些副本。选型前应画出一条数据旅程：用户输入如何进入，检索是否访问知识库，Prompt与上下文发往哪个模型服务，结果在哪里暂存，日志、缓存、评测样本和备份又保留多久。

每个节点至少标注数据类别、所有者、允许用途、存储位置和退出方式。尤其要关注派生数据：向量、索引、对话记录、工具参数、模型输出和人工标注可能不在原始数据清单中，但它们仍可能包含敏感信息或业务上下文。

数据边界还要说明跨区、跨租户和跨环境流转。测试数据能否进入生产日志，生产知识能否被测试身份检索，故障排查材料能否传出受控区域，这些问题不能由“系统部署在内网”一句话回答。

权限模型要跟随请求走完整条链

大模型请求可能经过门户、应用、编排、检索、模型和工具。入口已经认证，不等于下游每一步都保持同样的用户上下文。平台选型要观察身份在哪些节点被传递、转换或替换，以及服务账号是否扩大了原用户权限。

建议用四类身份做POC：普通使用者、知识或业务管理员、平台运维人员、受限或已撤销身份。对同一业务问题分别执行读取、生成、工具调用和管理动作，记录允许、拒绝与审批结果。若所有请求最终都以共享高权限账号访问下游，入口RBAC并不能保护数据。

最小权限验收要看实际执行身份和实际对象，而不是只看角色配置页面。 配置截图可以证明规则存在，调用记录才能说明规则在链路中生效。

审计记录必须解释一次业务事件

审计价值不在日志字段越多，而在能否回答“谁在什么授权下，对哪个对象做了什么，系统为何允许，结果去了哪里”。一次事件可能分散在多个服务中，因此需要关联请求、身份、策略决定、数据或工具对象、模型调用和最终结果。

以下事件值得在选型阶段实测：

• 用户读取有权访问的知识并得到带来源的答案
• 同一用户尝试访问未授权知识，系统明确拒绝且不泄露片段
• Agent调用一个需要审批的工具，审批前后状态和参数均可追溯
• 管理员修改权限或知识范围，旧会话和缓存如何处理
• 运维人员查询故障日志，访问敏感内容是否受控并被记录

审计记录还要能区分策略拒绝、系统错误和人工中止。把所有失败都写成调用异常，会使安全事件与稳定性问题无法分流；只记录最终成功，则无法看到中途越权尝试和补偿动作。

三角关系用于检查控制是否闭合

下图把数据边界、权限控制和审计证据放在三角形三个顶点。阅读时选择一个真实请求，沿三边核对：数据规则是否转成权限，权限决定是否留下审计，审计又能否证明数据边界没有被绕过。

若数据有分级但权限只到应用级，知识片段仍可能越界；若权限有效但审计缺少对象和策略决定，事后无法证明为何放行；若审计完整却没有明确数据保留和查看权限，日志本身会成为新的敏感数据源。

选型会议可以为每条高风险旅程填写三列：数据规则、执行控制、复核证据。任何一列为空，都说明控制尚未闭合。它比单独比较RBAC、日志或加密功能更接近真实风险。

用反例POC发现权限继承和缓存漏洞

正常授权场景通常容易顺利获得，越权反例更能区分平台。可以设计同一文档先授权后撤权、同名用户属于不同部门、服务账号访问多个知识库、审批过期后重复调用等场景。每次只改变一个身份或权限条件，观察检索、缓存、会话与工具是否同步收敛。

反例测试要记录“没有发生什么”。例如未授权请求不应返回正文、标题、摘要或可推断存在性的提示；工具拒绝后不应在后台继续执行；撤权后旧会话不应继续借缓存读取。具体拒绝方式由系统设计决定，但结果应符合企业的数据与操作边界。

若使用脱敏或模拟数据，可以验证身份传播、拒绝和审计机制，但不能由此证明真实数据分类、保留和监管要求已经满足。报告要写明模拟对象与正式对象之间的差异。

平台责任与企业责任需要分别签收

平台可以提供身份接入、授权点、策略执行、日志和审计查询，但企业必须定义数据分类、角色关系、审批规则、保留周期、异常处置和最终风险接受。供应方不能替企业决定某个业务人员是否应该读取一份材料，企业也不能要求平台在缺少规则的情况下自动推断授权。

责任分工可以落到具体事件：业务所有者批准知识用途；数据或安全角色定义边界；平台团队配置和维护控制；应用团队确保调用传递正确身份；审计角色复核关键事件；运维人员按授权查看故障材料。一个人可承担多个角色，但每项决定要有归属。

外部技术支持需要访问日志或配置时，应预先说明材料准备、脱敏、授权、传递和销毁方式。不能以排障为由默认放宽数据范围。具体支持责任、响应和数据处理方式以正式协议与企业制度为准。

这些缺口不适合用整改承诺带过

一般展示、报表或查询便利性问题可以进入整改计划，但以下情况应阻断扩大使用：服务账号绕过用户权限；未授权内容以摘要或引用形式泄露；高风险工具可在无审批时执行；关键策略变化没有记录；审计日志可被普通运维修改或删除；撤权后缓存和会话继续访问旧数据。

数据边界、权限执行和审计证明必须对同一次事件创建，不能用三个彼此无关的功能截图拼成安全结论。 如果关联能力不足，项目至少要顺利获得架构、流程和受控日志补齐复核路径，并明确残余风险。

形成面向场景的安全选型意见

最终意见可以按业务场景列出数据旅程、参与身份、允许动作、拒绝样本、审计查询方式和未覆盖风险。这样采购与技术团队能看见平台在哪些范围可用，哪些规则仍需企业补充，哪些问题必须在下一轮解决。

需要继续分析企业AI基础设施、安全与治理主题，可浏览 AI基础设施分类。下一步应选一条含敏感知识或高风险工具的场景，让业务、安全、平台和审计角色共同完成正向与反向验证。

常见问题

平台有RBAC就能满足政企权限要求吗？

不能直接这样判断。RBAC说明平台具备按角色分配权限的一种机制，但政企业务还要确认角色如何映射组织和数据、用户身份是否沿调用链传递、服务账号是否扩大权限，以及撤权、审批和例外如何生效。

• 检查权限粒度能否落到实际知识、工具或操作对象
• 用不同身份执行同一请求，核对下游看到的执行主体
• 验证角色变化、撤权和审批到期后缓存与会话的行为
• 从审计记录反查允许或拒绝所依据的策略与对象

如果企业尚未定义数据所有者和授权规则，平台也无法独自补齐。选型结论应同时列出平台能执行的控制和企业必须建立的制度，避免把能力采购误写成合规完成。

审计日志记录到什么粒度才有用？

有用的粒度取决于要复核的风险事件。对于普通问答，至少要关联主体、时间、知识范围、模型或应用版本和结果状态；涉及工具执行或数据变更时，还要记录目标对象、参数摘要、策略决定、审批和最终动作。

• 能用请求或事件标识串联入口、检索、模型和工具日志
• 能区分用户身份、服务身份和代执行关系
• 能看见允许、拒绝、失败、中止与补偿，而非只留成功结果
• 能控制日志中的敏感内容、查看权限、保留和防篡改

日志不必无边界保存完整Prompt与结果。敏感字段可以脱敏、摘要或受限存储，但复核者需要知道发生过什么以及原始材料如何在授权下查阅。粒度过细也会增加隐私和存储风险，应由事件需求反推。

平台安全能力和企业责任如何分开？

可以按“谁定义规则、谁执行规则、谁承担业务后果”划分。平台提供身份接入、策略点、拒绝、审计和管理工具；企业定义数据分级、角色授权、审批、例外、保留期限和风险接受。供应方可能协助配置与排障，但不能替业务所有者批准数据用途。

采购材料应把平台能力写成可验证控制，把企业责任写成实施前置条件，再为两者之间的接口指定负责人。例如平台能记录工具审批，企业仍要定义哪些动作必须审批、谁可批准和多久失效。只有接口被明确，安全能力才不会在上线后因规则空白而失效。

安全结论还要注明所用身份、数据范围和策略版本，防止在组织或权限变化后继续沿用。