SAP 中的 AI 治理：法遵、資安與當責

SAP 中的 AI 治理，涵蓋跑在 S/4HANA、SuccessFactors、Ariba、Concur 或 SAP BTP 上的每一項 AI 功能。對每一項功能，您都需要知道誰擁有它的決策、它使用什麼資料、如何記錄日誌，以及何時檢視。監管的時鐘在 2026 年移動了：歐盟 AI 法案對獨立高風險系統的義務，例如用於招聘的 AI，現在自 2027 年 12 月 2 日起適用。針對 AI 生成內容的透明度義務則已經適用。這份指南寫給 CIO、法遵主管與 SAP 專案負責人。內容涵蓋治理缺口最先在哪裡浮現、2026 年改變了什麼、適用的規則，以及一份您本週就能開始建立的登錄表。從為每項 AI 功能指定一位負責人開始。

先問一個簡單的問題：當模型交出一個結果，責任落在誰的名字上？如果答案不清楚，您就有一個治理缺口。

SAP 的環境很擁擠：核心是 S/4HANA，還有雲端 CRM、外掛的分析工具，以及沒人想碰的舊系統。工程師幾分鐘就能部署一個模型。要追查它對招聘、信用或供應規劃的影響，可能要好幾週。

資料讓事情更難。薪資、採購單、庫存與供應商評等，以不同的格式、由不同的主管負責送進來。一個團隊把個人身分證號遮罩起來；另一個團隊卻讓它裸露。在任何模型運行之前，先決定它可以使用哪些資料、誰核准變更，以及紀錄保存多久。把它寫下來、重新檢視，並且落實執行。

我看過一次上線，庫存預測運作得幾乎好過頭。訂單在需求出現之前就下了，在儀表板上看起來很有效率。接著財務打來電話。現金流下滑了，卻沒有人知道誰對模型的行為有最終決定權。邏輯被埋在深處。這時治理才變得真實，而不再只是簡報裡的一張投影片。

我一再看到的模式：

財務。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 法案的高風險日期移動了。《AI 數位綜合法案》（Digital Omnibus on AI，Regulation (EU) 2026/1744）已於 2026 年 7 月 27 日生效。附件三下獨立高風險系統的義務，包括用於招聘與員工管理，以及對個人進行信用度查核的 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 日，Regulation (EU) 2026/1744
3. 2026AI 生成內容的透明度義務8 月 2 日，第 50 條
4. 2027獨立高風險系統（附件三）12 月 2 日。招聘、員工管理、對個人的信用查核
5. 2028內建於受監管產品中的高風險 AI8 月 2 日

來源: Regulation (EU) 2026/1744，Digital Omnibus on AI

Joule 的日誌紀錄，取決於一個您可能早已做出的選擇。Joule 的對話日誌會記錄使用者、時間戳記、對話、提示與回應。只有在 Joule 上線設定時選擇啟用儲存，它們才會存在。SAP 文件載明這些日誌的預設保存期間是 365 天，您也可以申請不同的期間。請檢查這項設定，以及保存期間是否涵蓋您的稽核週期。

SAP 限制了 AI 代理對其 API 的使用。SAP 的 API 政策（版本 4.2026a）限制將 SAP API 用於會規劃、挑選或執行一連串 API 呼叫的半自主或生成式 AI 系統。這類使用只允許透過 SAP 認可的架構與途徑。如果第三方代理或副駕駛直接呼叫 S/4HANA，這現在除了是資安問題，也是合約問題。請盤點這些整合。

BTP 的控管功能存在，但您得自己去設定。SAP 的 generative AI hub 提供資料遮罩、輸入與輸出的內容過濾、grounding、提示登錄與稽核日誌。它們是控管措施，不是治理計畫。日誌開著卻沒有保存政策，在季檢視能讀到它之前就被覆蓋掉了。

如果廠商無法提供某項 AI 功能的高風險技術文件，那項功能就不能留在高風險用途中。期限移動了。文件的要求沒有。

這些適用於在 SAP 中執行 AI 的組織，不論 SAP 把軟體託管在哪裡。

法規	實務上的要求
歐盟 AI 法案	依風險分級的義務。高風險用途（招聘與員工管理、對個人的信用度，以及附件三的其他項目），自 2027 年 12 月 2 日起，需要風險管理、文件、日誌紀錄、人工監督與符合性評估。透明度義務已經適用
GDPR	合法依據與資料最小化。對於僅憑自動化處理、並產生法律效果或類似重大影響的決策，適用第 22 條的保障措施，包括人工介入，以及關於處理邏輯的有意義資訊
ISO/IEC 42001:2023	一套可稽核的 AI 管理系統：角色、風險流程、控管措施與持續改善
各國框架	海灣國家、新加坡等地都發布了 AI 倫理原則與治理框架。請每年檢視您營運所在地的那些框架

高風險分類對 SAP 特別重要。SuccessFactors 中影響招聘、晉升或解僱的 AI，在範圍內。S/4HANA 中針對企業客戶的信用查核，通常不在範圍內，因為附件三的類別涵蓋的是自然人的信用度。請逐項功能分類，而不是想當然耳。

務實的起點是一張登錄表。每項 AI 功能一列，確實填寫。

欄位	要記錄什麼
AI 功能	例如 SuccessFactors 的求職者比對，或 Ariba 的重複供應商偵測
系統與負責人	應用程式，以及一位有名有姓的當責者
AI 法案類別	禁止、高風險（附件三）、僅需透明度，或最低風險
使用的資料	來源、個人資料、已套用的遮罩
人工審查	誰審查哪些輸出，以及何時可以推翻
日誌與保存期間	決策記錄在哪裡，以及保存多久
檢視頻率	高影響功能每季，其他每半年
上次檢視	日期與結果

1. 在上線之前，為每個 AI 系統指定一位負責人。是一個人，不是一個委員會。其他人都扮演支援的角色。
2. 替受 AI 影響的決策保留稽核軌跡。無論是發票核准、供應商選擇還是求職者排序，都要記錄使用的資料、輸出，以及人員何時審查過。
3. 排定模型檢視。模型會隨著資料變動而退化。對關鍵系統來說，每季一次是合理的起點。不要等到使用者客訴，才發現已經有三個月的錯誤答案。
4. 先建立資料治理，再把 AI 治理連上去。存取規則、品質標準與遮罩，必須先存在，AI 治理才運作得起來。同時建立兩者的團隊，往往最後兩者都沒有。
5. 不要把治理與文件混為一談。放在 SharePoint 上的政策不是治理。治理改變的是決策如何做出：誰審查、誰升級處理，以及誰能暫停模型。

法規不斷變動。2026 年 AI 法案的修訂，顯示日期變動得多快。指派一個人追蹤法律變化，並每年把它們轉譯成 SAP 專屬的要求。

跨模組的隱私。SAP 裡有薪資、客戶交易與員工紀錄。SAP 中以角色為基礎的安全機制，並不會自動套用到 AI 模型的輸入上。請明確檢查。

訓練資料中的偏誤。如果 SuccessFactors 的模型是從五年帶有偏頗的招聘資料中學習的，它就會重複這種偏頗。部署前要看各群體的結果，而不只是準確度。

管線中的舊系統。當 BTP 上的 AI 從舊的 ERP 或第三方平台取資料時，最弱那個系統的資料品質，就成為您的上限。在模型上線之前，先把來源對照出來。我的 AI 風險管理框架涵蓋了評估的步驟，而我的 AI 治理框架指南則涵蓋了更廣泛的營運模式。

SAP 導入中的 AI 治理是什麼？

這是一套由負責人、政策與控管措施組成的機制，讓 SAP 中的 AI 功能以負責任、透明且合法的方式運作。它涵蓋模型可以使用哪些資料、功能如何核准與部署、決策如何記錄與檢視，以及誰能暫停模型。它適用於 S/4HANA、SuccessFactors、Ariba、Concur，以及您在 SAP BTP 上建置的任何東西。

歐盟 AI 法案的高風險規則何時適用於 SAP 系統？

在《數位綜合法案》（Regulation (EU) 2026/1744）之後，附件三獨立高風險系統的義務，自 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 service。請檢查您租戶的設定，而不是想當然耳。

如何處理 SAP SuccessFactors 中 AI 模型的偏誤？

檢視模型是用什麼訓練的。如果歷史招聘資料對特定群體不利，模型也會如此。上線前先測試各群體的結果，上線後監控篩選率，並隨著人力資料的變化，依排程再訓練。如果來自某一種背景的合格求職者，一再被過濾掉，請把它當成訊號，而不是巧合。

SAP 中的 AI 模型應該多久檢視一次？

財務核准、人資決策或供應商選擇這類高影響系統，每季一次；風險較低的工具，每半年一次。只要資料來源、整合或業務流程有變動，就要再加開一次檢視，因為這些都可能在程式碼沒有變動的情況下，改變模型的行為。