在一家制造业客户的 ECC 系统上，我们给财务和采购团队设计了一个 AI 问答助手，覆盖凭证、采购订单、货物移动三类单据查询。方案迭代到第四版，权限设计收敛成三句话：AI 不持有特权账号，所有接口调用以登录用户本人的 SAP 授权执行；应用层做确定性预判，结果亮给用户确认；SAP 内核的 AUTHORITY-CHECK 是最终边界。方案经过三轮对抗性审查，P0 级问题清零。此前我们在测试系统跑通过通用大模型接 ECC 的完整管线，本篇聚焦客户场景里真正难的两件事，权限怎么跟着人走，并发容量怎么算。
固定系统账号为什么被否掉
给 AI 后端配一个高权限 RFC 系统账号，所有用户共用，这是最容易想到的做法，也是我们最先否掉的。代价有两个。权限全集落在 AI 手里，一次成功的提示注入就能读到全部底表。审计断链，日志里只有系统账号，问一句「这条查询是谁发起的」无从回答，事后追责和权限治理都无从下手。
替代路线是用户级委托。用户以自己的 SAP 账号登录 AI 平台，之后的每次接口调用都带着这个账号的授权上下文执行。机制上依赖 SAP 标准的用户映射（user mapping），客户 BASIS 团队确认其系统支持。我们把这一条列为项目核心前置条件，立项阶段先验证，验证不通过项目不成立。好处一句话能说清：AI 能查什么，等于这个人本人登录 SAP 能查什么，不需要在 SAP 权限体系之外再养一套平行模型。
预判和内核各管一段
应用层预判发生在执行前。AI 平台本地存有一份账号授权数据，配一张接口与权限对象的映射表，由确定性组件检查，不经过大模型。预判的产出是确认界面上的一行行明细，本次调用的接口名、关键参数、需要哪些权限对象、当前账号是否满足，不满足直接拒绝，连远程调用都不发起。
SAP 内核的 AUTHORITY-CHECK 发生在执行时，BAPI 和 RFC 调用自动触发，按调用者身份校验权限对象。这一层是最终安全边界，应用层预判错了也拦得住。授权数据从哪来：自研的权限同步 RFC 函数，只封装最小化的读权限，把账号和授权数据同步到 AI 平台本地。BASIS 调整角色后变更自动推送，端到端秒级。预判用本地副本换响应速度，内核用权威数据兜底，两层各取所长。
举一个具体映射。查会计凭证明细走 BAPI_ACC_DOCUMENT_GETDETAIL，对应权限对象是 F_BKPF_BUK 的公司代码字段加显示活动（ACTVT 03），对象定义见 SAP 帮助文档。查采购订单走 BAPI_PO_GETDETAIL，货物移动查询按 M_MSEG_WWA 的工厂加移动类型控制，这是 SAP 社区权限讨论里反复确认过的口径。
OData 的权限有两层
走 SAP Gateway 的 OData 服务，权限同样是两层。服务级由 S_SERVICE 控制，决定账号能不能访问这个服务；业务级是服务背后调用的 BAPI 对应的权限对象，和直调一致。我们的预判要求两层同时通过，任何一层不过就拒绝。
常见疏漏是只查了服务级就放行。大门开了，屋里每间房的门锁都失效。确认界面会把两条结果并列展示，比如 S_SERVICE 对该服务已授权，F_BKPF_BUK 对公司代码 1000 已授权，用户看得懂，审计查得着。
text-to-SQL 为什么默认不启用
让 AI 直接写 SQL 查底表，演示效果最好，我们默认关掉了这条路线。理由有五条。字符串拼接的 SQL 里，权限数据被污染就能注入。多表 JOIN 下，简单的权限过滤条件传不到正确的表别名，越权读取挡不住。裸 SQL 直达底表，绕开了 BAPI 和 RFC 自带的授权检查。SAP 侧要额外开发参数化封装和静态合法性校验。底表结构一变，过滤逻辑要跟着维护。前两条是安全问题，后三条是成本问题，都不划算。
单据查询和统计由 BAPI、RFC、OData 覆盖，已经够用。客户未来如果确需自由跨表统计，text-to-SQL 可以作为高门槛可选能力单独评估，前提是 SAP 侧参数化 OPEN SQL 封装加一轮独立安全审计。这条决策出自第二轮对抗性审查，回头看是整个方案里最省事的一次急刹车。
基座为什么选 7B 无 CoT 模型
我们没有拿自带推理链的通用大模型做基座。预训练的思维链不是为 SAP 工具调用准备的，模型会自己编参数、误调接口。现在的做法是在一个 7B 无 CoT 基座（Qwen2.5-7B-Instruct，配置公开可查）上，专门训练 SAP 调用的思维链，只教三件事，跨域拒绝、接口消歧、参数缺失时追问。基座本身的指令遵从能力很强，幻觉误调基本杜绝。客户场景数据以数百条的量级注入采购模块的工具调用推理，换个模块主要换工具清单，模型不用重训。
100 并发要多少显存
容量是算术题。单个 token 的 KV 缓存在 FP16 下约 56 KiB，由 28 层、4 个 KV 头、128 维头宽算出。100 路并发、输入 8K、输出 1K，KV 池约 50 GB，加两成框架开销和 14 GB 权重，按 80 GB 配置。走 INT8 量化，权重降到约 7 GB，KV 缓存减半，单张 48 GB 显存的卡就能撑住同样负载。
估算只管规划，上线门槛靠压测。用 vLLM 部署，拿真实工具清单里最长的 prompt 构造满载会话，采集显存峰值、吞吐、P95 首字延迟、OOM 和请求拒绝计数。判定线三条，显存峰值低于卡容量的九成，P95 首字延迟低于 2 秒，满载全程无 OOM 无拒绝。不达标按 INT8 KV 缓存、INT4 权重、双卡张量并行、限制并发四级回退。
方案是被审查逼出来的
这个方案前后被三轮对抗性审查拷问过。第一轮闭环了权限传播、权限同步、映射表三个 P0 问题。第二轮定下三件事，凭证委托走用户映射可行，text-to-SQL 默认弃用，鉴权统一交给 SAP 原生机制。第三轮补齐凭据安全、传输包流程、OData 双层预判和容量压测方法，凭据全程加密，入口强制 HTTPS，后端不落盘存密码，对 SAP 的信道走 SNC 加密。目前 P0 清零，剩余问题全部转成了落地明细和前置条件，写进实施清单。
边界照实说。当前演示受客户算力调度限制，只展示接口方案和权限检查明细，不做真实执行，真实执行闭环放到 POC 阶段完成。外汇换算、月结调度这类客户特定的业务规则，需要客户提供数据集做增强训练。客户的 EHP 与支持包级别要在版本基线确认之后才算锁定，低版本系统要另备替代方案。
对还在 ECC 上运行的制造企业，2027 年底主流维护到期之前，给业务团队配一个查单助手这类轻量接入，不必等迁移项目动身，可以先在维护时间线里排好自己的位置。权限按人走，边界交给内核，容量算清楚，这三件事做实了，AI 进 SAP 的第一步就站得住。
