SAP 中的 AI 治理：合规、安全与问责

SAP 中的 AI 治理，涵盖在 S/4HANA、SuccessFactors、Ariba、Concur 或 SAP BTP 上运行的每一项 AI 功能。对每一项功能，您都需要知道：谁对它的决策负责、它用了什么数据、如何记录日志、什么时候复核。监管时间表在 2026 年变了：欧盟《人工智能法案》针对独立高风险系统（例如用于招聘的 AI）的义务，现在从 2027 年 12 月 2 日起适用。针对 AI 生成内容的透明度义务已经适用。本指南写给 CIO、合规负责人和 SAP 项目群负责人。内容包括治理缺口最先出现在哪里、2026 年发生了什么变化、适用的规则，以及一份您本周就能开始填写的登记册。先从为每项 AI 功能指定一位责任人做起。

先问一个简单的问题：模型给出一个结果时，谁来为它担责？如果答案不清楚，您就存在治理缺口。

SAP 系统环境很拥挤：核心是 S/4HANA，外加云端 CRM、附加的分析工具，以及没人愿意碰的遗留系统。工程师几分钟就能部署一个模型。要追溯它对招聘、信贷或供应计划的影响，可能要花几周。

数据让事情更难。工资、采购订单、库存和供应商评级，格式各异，归不同的经理管。一个团队会对个人 ID 做脱敏，另一个团队却让它们裸露在外。在任何模型运行之前，先决定它可以使用哪些数据、谁批准变更、记录保存多久。把它写下来，定期重温，并严格执行。

我见过一次推广，库存预测几乎好过了头。订单赶在需求之前就下了，在仪表盘上看起来很高效。然后财务打来了电话。现金流出现下滑，没有人知道谁对模型的行为拥有最终决定权。逻辑被埋得很深。到这个时候，治理才变成真的，而不再只是演示文稿里的一页幻灯片。

我反复看到的几种情形：

财务。S/4HANA Finance 中的 AI 可以帮助处理发票、做现金预测和异常检测。它有用，直到没用的那一刻：一笔合法的付款被拦下，一笔可疑的付款被放行，一份预测建立在过时的数据上。对策是为每个受 AI 影响的决策留下审计线索，并指定一个人来检查。

采购。AI 会推荐供应商、标出风险、审阅合同。如果历史采购数据带有偏见，比如某些供应商被偏爱的原因没人说得清，模型就会重复这种偏见。必须有人审查候选名单，而不是照单全收。

人力资源。SuccessFactors 中的 AI 可以帮助筛选候选人和分析员工敬业度。如果它是用本来就偏向某类人群的招聘数据训练出来的，就会继续偏下去。部署前要做偏见测试，每次重新训练之后再做一次。

制造。工厂重新配置之后，预测性维护和排产模型的表现会下降。要持续跟踪准确率，并安排重新训练。不要等到产线停了，才发现模型已经漂移。

SAP 云应用中的 AI 往往悄无声息地到来：Ariba 中的发票匹配、Concur 中的审批、CRM 中的线索评分。它在后台运行，这正是它的吸引力所在。同时也让监督变得更难。

我记得有一位客户在用 SAP Ariba 的嵌入式智能功能。系统开始自动标记重复的供应商。这很有用，但没人意识到，这些标记有时是由主数据中命名不一致触发的。没有恶意，只是条目对不上。采购部门没有验证这些告警的流程，结果造成了延误和混乱。对策是为告警加一道验证步骤，并在供应商主数据中统一命名规范。

SAP BTP。BTP 让团队可以在整个 SAP 系统环境中构建和部署自己的 AI。我见过一个模型批准了不合格的供应商，原因是它是用不完整的采购数据训练的。数据问题先于 AI 问题出现，清理输入数据，比调模型见效更快。

SAP Concur。费用 AI 能抓出重复报销和违反政策的情况。它也会对合法的报销误报欺诈，而当员工花时间去申诉被拒的单据时，效率上的收益就消失了。边界情形要保留人工复核，费用政策一变，规则就要更新。

欧盟《人工智能法案》的高风险日期变了。《AI 数字综合法案》（Digital Omnibus on AI），即法规 (EU) 2026/1744，于 2026 年 7 月 27 日生效。附件 III 下独立高风险系统的义务，包括用于招聘和员工管理的 AI，以及用于对个人做信用核查的 AI，现在自 2027 年 12 月 2 日起适用。嵌入受监管产品中的高风险 AI，则在 2028 年 8 月 2 日之后。禁止性做法和 AI 素养自 2025 年 2 月起适用，针对 AI 生成内容的第 50 条透明度义务自 2026 年 8 月 2 日起适用。推迟换来的是缓冲时间，不是免除。合格评定和技术文档，都是慢工出细活的事。

1. 2025禁止性做法和 AI 素养自 2025 年 2 月起
2. 2026数字综合法案生效7 月 27 日，法规 (EU) 2026/1744
3. 2026AI 生成内容的透明度义务8 月 2 日，第 50 条
4. 2027独立高风险系统（附件 III）12 月 2 日。招聘、员工管理、对个人的信用核查
5. 2028嵌入受监管产品的高风险 AI8 月 2 日

来源: 法规 (EU) 2026/1744，《AI 数字综合法案》（Digital Omnibus on AI）

Joule 的日志取决于您可能已经做过的一个选择。Joule 的对话日志会记录用户、时间戳、对话、提示词和回复。只有在 Joule 接入时选择了开启存储，这些日志才会存在。SAP 文档中这些日志的默认保留期是 365 天，您可以申请不同的期限。检查这项设置，以及保留期是否覆盖您的审计周期。

SAP 限制了 AI 智能体使用其 API。SAP 的 API 政策（版本 4.2026a）限制把 SAP API 用于会规划、选择或执行一连串 API 调用的半自主或生成式 AI 系统。这类使用只允许通过 SAP 认可的架构和路径进行。如果第三方智能体或副驾驶（copilot）直接调用 S/4HANA，那么这现在既是安全问题，也是合同问题。盘点一下这些集成。

BTP 的控制措施是有的，但需要您自己去配置。SAP 的生成式 AI Hub 提供数据脱敏、输入和输出内容过滤、数据接地（grounding）、提示词注册表和审计日志。这些是控制措施，不是治理方案。日志开着、却没有保留政策，日志会在季度复核读到它之前就被滚动清除。

如果供应商拿不出某项 AI 功能的高风险技术文档，那这项功能就不能继续用在高风险场景中。截止日期动了，文档要求没有动。

无论 SAP 把软件托管在哪里，这些法规都适用于在 SAP 中运行 AI 的组织。

法规	实际要求什么
欧盟《人工智能法案》	基于风险的义务。高风险用途（招聘和员工管理、对个人的信用评估，以及附件 III 中的其他用途），自 2027 年 12 月 2 日起需要风险管理、文档、日志、人工监督和合格评定。透明度义务已经适用
GDPR	合法性基础和数据最小化。对于仅基于自动化处理、且产生法律效力或类似重大影响的决策，适用第 22 条的保障措施，包括人工干预和有关逻辑的有意义信息
ISO/IEC 42001:2023	可审计的 AI 管理体系：角色、风险流程、控制措施和持续改进
各国框架	海湾国家、新加坡等发布了 AI 伦理原则和治理框架。对您运营所在地的框架，每年复核一次

高风险分类对 SAP 尤其重要。SuccessFactors 中影响招聘、晋升或解聘的 AI，在范围之内。S/4HANA 中对企业客户的信用核查通常不在范围内，因为附件 III 的这一类别针对的是自然人的信用评估。要逐项功能去分类，而不是想当然。

务实的起点是一份登记册。每项 AI 功能一行，填满。

列	记录什么
AI 功能	例如 SuccessFactors 的候选人匹配，或 Ariba 的重复供应商检测
系统与责任人	所在的应用，以及一位明确的问责人
《人工智能法案》类别	禁止、高风险（附件 III）、仅需透明度，或最低风险
所用数据	来源、个人数据、已采取的脱敏措施
人工复核	谁复核哪些输出，以及什么情况下可以推翻
日志与保留期	决策记录在哪里、保留多久
复核频率	高影响功能每季度一次，其他功能每半年一次
上次复核	日期和结果

1. 上线之前，为每个 AI 系统指定一位责任人。是一个人，而不是一个委员会。其他所有人都扮演支持角色。
2. 为受 AI 影响的决策保留审计线索。对发票审批、供应商选择或候选人排序，记录所用的数据、输出结果，以及人是什么时候复核的。
3. 安排模型复核。数据变了，模型就会退化。对关键系统，每季度一次是个合理的起点。不要等到用户投诉，才发现三个月的错误答案。
4. 先落实数据治理，再把 AI 治理接上去。访问规则、质量标准和脱敏措施，必须先于 AI 治理存在，AI 治理才能运转。两样同时搭的团队，往往最后两样都没搭成。
5. 不要把治理和文档混为一谈。放在 SharePoint 里的政策不是治理。治理改变的是决策的做出方式：谁来复核，谁来上报，谁可以暂停模型。

监管一直在变。2026 年《人工智能法案》的变化，说明日期可以变得多快。指定一个人来跟踪法律变化，并每年把它们转化为针对 SAP 的具体要求。

跨模块的隐私。SAP 里有工资、客户交易和员工档案。SAP 中基于角色的安全机制，不会自动适用于 AI 模型的输入。要明确地检查。

训练数据中的偏见。如果 SuccessFactors 的模型是从五年带有偏向的招聘数据中学出来的，它就会重复这种偏向。部署前要按群体查看结果，而不只是看准确率。

数据链路中的遗留系统。当 BTP 上的 AI 从遗留 ERP 或第三方平台取数时，最薄弱的那个系统的数据质量，就成了您的上限。模型上线之前，先把数据来源梳理清楚。我的 AI 风险管理框架讲了评估步骤，我的 AI 治理框架指南讲了更大的运营模式。

SAP 实施中的 AI 治理是什么？

它是一整套责任人、政策和控制措施，确保 SAP 中的 AI 功能负责任、透明且合法地运行。它涵盖模型可以使用哪些数据、功能如何审批和部署、决策如何记录和复核，以及谁可以暂停模型。它适用于 S/4HANA、SuccessFactors、Ariba、Concur，以及您在 SAP BTP 上构建的一切。

欧盟《人工智能法案》的高风险规则何时适用于 SAP 系统？

在数字综合法案（法规 (EU) 2026/1744）之后，附件 III 中独立高风险系统的义务自 2027 年 12 月 2 日起适用。嵌入受监管产品中的高风险 AI，则自 2028 年 8 月 2 日起适用。禁止性做法和 AI 素养自 2025 年 2 月起适用，针对 AI 生成内容的透明度义务自 2026 年 8 月起适用。对 SAP 而言，最常见的高风险领域，是用于招聘和员工决策的 AI。

SAP 项目中，谁来负责 AI 治理？

一个跨职能小组：合规部门跟踪法规，IT 与安全负责访问和日志，数据团队负责训练数据的质量，业务流程负责人批准输出结果，法务审查责任问题。最重要的决定，是为每个 AI 系统指定一位问责的责任人。凌晨 2 点出了问题，您得知道电话该打给谁。

Joule 会保留审计线索吗？

Joule 的对话日志可以记录用户、时间戳、对话以及提示词和回复，但前提是在接入时选择了开启日志存储。SAP 文档中，对已选择开启的客户，默认保留期是 365 天，也可以申请不同的期限。Joule Studio 中与安全相关的配置变更，会进入 BTP 上的 SAP Audit Log 服务。请检查您自己租户的设置，而不是想当然。

如何处理 SAP SuccessFactors 中 AI 模型的偏见？

先查看模型是用什么训练的。如果历史招聘数据对某些群体不利，模型也会如此。上线之前，按群体测试结果；上线之后，监控录用率；随着您的员工数据变化，按计划重新训练。如果来自同一背景的合格候选人总是被筛掉，要把它当作一个信号，而不是巧合。

SAP 中的 AI 模型应该多久复核一次？

对财务审批、HR 决策或供应商选择等高影响系统，每季度一次；对风险较低的工具，每半年一次。只要数据源、集成或业务流程发生变化，就额外触发一次复核，因为其中任何一项，都可能在没有代码变更的情况下改变模型的行为。