SAP में AI गवर्नेंस: कंप्लायंस, सिक्योरिटी, जवाबदेही

SAP में AI गवर्नेंस उस हर AI फ़ीचर को कवर करता है जो S/4HANA, SuccessFactors, Ariba, Concur या SAP BTP पर चल रहा है। हर एक के लिए आपको पता होना चाहिए कि उसके फ़ैसलों का ओनर कौन है, वह कौन-सा डेटा इस्तेमाल करता है, उसे कैसे लॉग किया जाता है और उसकी समीक्षा कब होती है। नियमन की समय-सीमाएँ 2026 में खिसकीं: स्टैंड-अलोन हाई-रिस्क सिस्टम, जैसे हायरिंग में इस्तेमाल होने वाला AI, के लिए EU AI Act के दायित्व अब 2 दिसंबर 2027 से लागू होते हैं। AI-जनरेटेड कंटेंट के पारदर्शिता दायित्व पहले से लागू हैं। यह गाइड CIO, कंप्लायंस लीड और SAP प्रोग्राम ओनर के लिए है। इसमें बताया गया है कि गवर्नेंस की कमियाँ सबसे पहले कहाँ दिखती हैं, 2026 में क्या बदला, कौन-से नियम लागू होते हैं, और एक रजिस्टर जो आप इसी हफ़्ते शुरू कर सकते हैं। शुरुआत हर AI फ़ीचर के लिए एक ओनर का नाम तय करके कीजिए।

एक सीधे सवाल से शुरू कीजिए: जब कोई मॉडल नतीजा देता है, तो किसका नाम दाँव पर है? अगर जवाब साफ़ नहीं है, तो आपके यहाँ गवर्नेंस की कमी है।

SAP एस्टेट भरे-पूरे होते हैं: कोर में S/4HANA, क्लाउड CRM, बोल्ट-ऑन एनालिटिक्स, और लेगसी सिस्टम जिन्हें कोई छूना नहीं चाहता। एक इंजीनियर मिनटों में मॉडल तैनात कर सकता है। हायरिंग, क्रेडिट या सप्लाई प्लानिंग पर उसका असर खोजने में हफ़्ते लग सकते हैं।

डेटा इसे और मुश्किल बनाता है। पेरोल, परचेज़ ऑर्डर, इन्वेंटरी और वेंडर रेटिंग अलग-अलग फ़ॉर्मैट में, अलग-अलग मैनेजरों के अधीन आते हैं। एक टीम निजी ID मास्क करती है; दूसरी उन्हें खुला छोड़ देती है। कोई भी मॉडल चलने से पहले तय कीजिए कि वह कौन-सा डेटा इस्तेमाल कर सकता है, बदलावों को कौन मंज़ूर करता है और रिकॉर्ड कितने समय तक रखे जाते हैं। इसे लिखिए, दोबारा देखिए और लागू कीजिए।

मैंने एक रोलआउट देखा जहाँ इन्वेंटरी फ़ोरकास्टिंग कुछ ज़्यादा ही अच्छा काम कर रही थी। ऑर्डर माँग से पहले दिए जा रहे थे, जो डैशबोर्ड पर कुशल दिखता था। फिर फ़ाइनेंस ने फ़ोन किया। कैश फ़्लो गिर गया था, और किसी को नहीं पता था कि मॉडल के बर्ताव पर आख़िरी फ़ैसला किसका है। लॉजिक कहीं गहरे दबा था। तभी गवर्नेंस असली बनता है, प्रेज़ेंटेशन की किसी स्लाइड की तरह नहीं।

जो पैटर्न मैं बार-बार देखता हूँ:

फ़ाइनेंस। S/4HANA Finance में AI इनवॉइस प्रोसेसिंग, कैश फ़ोरकास्टिंग और एनॉमली डिटेक्शन में मदद करता है। जब तक ठीक चलता है, उपयोगी है। फिर किसी जायज़ पेमेंट को ब्लॉक कर देता है, किसी संदिग्ध को मंज़ूर कर देता है, या पुराने डेटा पर फ़ोरकास्ट बना देता है। हल है AI से प्रभावित हर फ़ैसले पर ऑडिट ट्रेल और एक नामित व्यक्ति जो उसे जाँचे।

प्रोक्योरमेंट। AI सप्लायर सुझाता है, जोखिम फ़्लैग करता है और कॉन्ट्रैक्ट की समीक्षा करता है। अगर पुराने प्रोक्योरमेंट डेटा में पूर्वाग्रह है, जैसे ऐसे वेंडर जिन्हें पसंद करने की वजह किसी को दिखती नहीं, तो मॉडल उसे दोहराता है। किसी को शॉर्टलिस्ट को यूँ ही स्वीकार करने की जगह उनकी समीक्षा करनी होगी।

HR। SuccessFactors में AI उम्मीदवारों की स्क्रीनिंग और एंगेजमेंट के विश्लेषण में मदद कर सकता है। ऐसे हायरिंग डेटा पर ट्रेन होने से, जो पहले से कुछ ख़ास प्रोफ़ाइल की ओर झुका था, वह झुकाव बना रहता है। तैनाती से पहले और हर रीट्रेनिंग के बाद दोबारा, पूर्वाग्रह की जाँच कीजिए।

मैन्युफ़ैक्चरिंग। प्लांट का कॉन्फ़िगरेशन बदलने पर प्रेडिक्टिव मेंटेनेंस और शेड्यूलिंग मॉडल बिगड़ जाते हैं। समय के साथ सटीकता ट्रैक कीजिए और रीट्रेनिंग शेड्यूल कीजिए। ड्रिफ़्ट पकड़ने के लिए लाइन रुकने का इंतज़ार मत कीजिए।

SAP के क्लाउड एप्लिकेशन में AI अक्सर चुपचाप आ जाता है: Ariba में इनवॉइस मैचिंग, Concur में अप्रूवल, CRM में लीड स्कोरिंग। यह बैकग्राउंड में काम करता है, और यही उसका आकर्षण है। इसी से निगरानी भी मुश्किल हो जाती है।

मुझे एक क्लाइंट याद है जो SAP Ariba में एम्बेडेड इंटेलिजेंस इस्तेमाल कर रहा था। सिस्टम ने अपने आप डुप्लिकेट वेंडर फ़्लैग करना शुरू कर दिया। उपयोगी, पर किसी को एहसास नहीं हुआ कि फ़्लैग कभी-कभी मास्टर डेटा में असंगत नामकरण की वजह से ट्रिगर हो रहे थे। कोई बुरी नीयत नहीं, बस बेमेल एंट्री। प्रोक्योरमेंट के पास अलर्ट को वैलिडेट करने की कोई प्रक्रिया नहीं थी, और इससे देरी और उलझन हुई। हल है अलर्ट के लिए एक वैलिडेशन कदम और वेंडर मास्टर में एकसमान नामकरण परंपरा।

SAP BTP। BTP टीमों को पूरे SAP एस्टेट में अपना AI बनाने और तैनात करने देता है। मैंने एक मॉडल देखा है जो अधूरे प्रोक्योरमेंट डेटा पर ट्रेन होने की वजह से ख़राब वेंडर को मंज़ूर कर रहा था। डेटा की समस्या AI की समस्या से पहले की थी, और इनपुट साफ़ करने से वह मॉडल ट्यून करने से जल्दी ठीक हुई।

SAP Concur। एक्सपेंस AI डुप्लिकेट और पॉलिसी का उल्लंघन पकड़ता है। वह जायज़ क्लेम पर झूठे फ़्रॉड फ़्लैग भी लगाता है, और जब कर्मचारी रिजेक्शन को चुनौती देने में समय लगाते हैं, तो प्रोडक्टिविटी का फ़ायदा ग़ायब हो जाता है। सीमा पर आने वाले मामलों में इंसानी समीक्षा रखिए और जब भी एक्सपेंस पॉलिसी बदले तो नियम अपडेट कीजिए।

EU AI Act की हाई-रिस्क तारीख़ें खिसक गईं। AI पर Digital Omnibus, Regulation (EU) 2026/1744, 27 जुलाई 2026 को लागू हुआ। Annex III के तहत स्टैंड-अलोन हाई-रिस्क सिस्टम के दायित्व, जिनमें भर्ती और वर्कर मैनेजमेंट में, और व्यक्तियों की क्रेडिट-योग्यता की जाँच में इस्तेमाल होने वाला AI शामिल है, अब 2 दिसंबर 2027 से लागू होते हैं। नियमन वाले उत्पादों में एम्बेडेड हाई-रिस्क AI 2 अगस्त 2028 से जुड़ेगा। प्रतिबंधित प्रथाएँ और AI साक्षरता फ़रवरी 2025 से लागू हैं, और AI-जनरेटेड कंटेंट के लिए Article 50 के पारदर्शिता दायित्व 2 अगस्त 2026 से। यह देरी तैयारी का समय देती है, राहत नहीं। कन्फ़ॉर्मिटी असेसमेंट और तकनीकी डॉक्यूमेंटेशन धीमे काम हैं।

1. 2025प्रतिबंधित प्रथाएँ और AI साक्षरताफ़रवरी 2025 से
2. 2026Digital Omnibus लागू27 जुलाई, Regulation (EU) 2026/1744
3. 2026AI-जनरेटेड कंटेंट के पारदर्शिता दायित्व2 अगस्त, Article 50
4. 2027स्टैंड-अलोन हाई-रिस्क सिस्टम (Annex III)2 दिसंबर। हायरिंग, वर्कर मैनेजमेंट, व्यक्तियों की क्रेडिट जाँच
5. 2028नियमन वाले उत्पादों में एम्बेडेड हाई-रिस्क AI2 अगस्त

स्रोत: Regulation (EU) 2026/1744, Digital Omnibus on AI

Joule लॉगिंग एक ऐसे चुनाव पर निर्भर है जो आप शायद पहले ही कर चुके हैं। Joule के बातचीत के लॉग यूज़र, टाइमस्टैम्प, बातचीत, प्रॉम्प्ट और जवाब दर्ज करते हैं। वे तभी होते हैं जब Joule के ऑनबोर्डिंग के समय स्टोरेज में ऑप्ट-इन किया गया था। इन लॉग के लिए SAP का दस्तावेज़ी डिफ़ॉल्ट रिटेंशन 365 दिन है, और आप अलग अवधि का अनुरोध कर सकते हैं। सेटिंग देखिए और जाँचिए कि रिटेंशन आपके ऑडिट साइकल को कवर करता है या नहीं।

SAP ने अपनी API पर AI एजेंट को सीमित किया। SAP की API Policy (वर्ज़न 4.2026a) SAP API को ऐसे सेमी-ऑटोनॉमस या जेनरेटिव AI सिस्टम के साथ इस्तेमाल करने पर रोक लगाती है जो API कॉल के क्रम की योजना बनाते, चुनते या चलाते हैं। ऐसा इस्तेमाल सिर्फ़ SAP-समर्थित आर्किटेक्चर और रास्तों से ही मंज़ूर है। अगर कोई थर्ड-पार्टी एजेंट या कोपायलट सीधे S/4HANA को कॉल करता है, तो अब वह सुरक्षा के साथ-साथ कॉन्ट्रैक्ट का सवाल भी है। ऐसे इंटीग्रेशन की सूची बनाइए।

BTP के कंट्रोल मौजूद हैं, पर उन्हें कॉन्फ़िगर आपको करना है। SAP का generative AI hub डेटा मास्किंग, इनपुट और आउटपुट कंटेंट फ़िल्टरिंग, ग्राउंडिंग, प्रॉम्प्ट रजिस्ट्री और ऑडिट लॉगिंग देता है। ये कंट्रोल हैं, गवर्नेंस प्रोग्राम नहीं। रिटेंशन पॉलिसी के बिना चालू की गई लॉगिंग तिमाही समीक्षा के पढ़ने से पहले ही मिट जाती है।

अगर कोई वेंडर किसी AI फ़ीचर के लिए हाई-रिस्क तकनीकी डॉक्यूमेंटेशन नहीं दे सकता, तो वह फ़ीचर हाई-रिस्क इस्तेमाल में नहीं रह सकता। समय-सीमा खिसक गई है। डॉक्यूमेंटेशन की ज़रूरत नहीं खिसकी।

ये उन संगठनों पर लागू होते हैं जो SAP में AI चलाते हैं, चाहे SAP सॉफ़्टवेयर कहीं भी होस्ट करे।

नियम	व्यवहार में क्या माँगता है
EU AI Act	जोखिम पर आधारित दायित्व। हाई-रिस्क इस्तेमाल (भर्ती और वर्कर मैनेजमेंट, व्यक्तियों की क्रेडिट-योग्यता और Annex III के दूसरे) के लिए 2 दिसंबर 2027 से जोखिम प्रबंधन, डॉक्यूमेंटेशन, लॉगिंग, इंसानी निगरानी और कन्फ़ॉर्मिटी असेसमेंट चाहिए। पारदर्शिता दायित्व पहले से लागू हैं
GDPR	क़ानूनी आधार और डेटा मिनिमाइज़ेशन। सिर्फ़ ऑटोमेटेड प्रोसेसिंग पर आधारित, क़ानूनी या वैसे ही असर वाले फ़ैसलों के लिए Article 22 के सुरक्षा उपाय, जिनमें इंसानी दख़ल और लॉजिक की सार्थक जानकारी शामिल है
ISO/IEC 42001:2023	ऑडिट-योग्य AI मैनेजमेंट सिस्टम: रोल, जोखिम प्रक्रिया, कंट्रोल और लगातार सुधार
राष्ट्रीय फ़्रेमवर्क	खाड़ी देश, सिंगापुर और दूसरे AI नैतिकता सिद्धांत और गवर्नेंस फ़्रेमवर्क प्रकाशित करते हैं। जहाँ आप काम करते हैं, वहाँ के फ़्रेमवर्क हर साल देखिए

हाई-रिस्क वर्गीकरण SAP के लिए ख़ास तौर पर मायने रखता है। SuccessFactors में जो AI हायरिंग, प्रमोशन या बर्ख़ास्तगी को प्रभावित करता है, वह दायरे में आता है। S/4HANA में बिज़नेस कस्टमर की क्रेडिट जाँच आमतौर पर नहीं आती, क्योंकि Annex III की श्रेणी प्राकृतिक व्यक्तियों की क्रेडिट-योग्यता को कवर करती है। मानकर चलने की जगह हर फ़ीचर को वर्गीकृत कीजिए।

व्यावहारिक शुरुआत एक रजिस्टर है। हर AI फ़ीचर की एक पंक्ति, भरी हुई।

कॉलम	क्या दर्ज करें
AI फ़ीचर	उदाहरण के लिए, SuccessFactors में उम्मीदवार मैचिंग या Ariba में डुप्लिकेट-वेंडर डिटेक्शन
सिस्टम और ओनर	एप्लिकेशन, और एक नामित ज़िम्मेदार व्यक्ति
AI Act श्रेणी	प्रतिबंधित, हाई-रिस्क (Annex III), सिर्फ़ पारदर्शिता, या न्यूनतम
इस्तेमाल होने वाला डेटा	स्रोत, निजी डेटा, लागू की गई मास्किंग
इंसानी समीक्षा	कौन किन आउटपुट की समीक्षा करता है, और वह कब ओवरराइड कर सकता है
लॉगिंग और रिटेंशन	फ़ैसले कहाँ लॉग होते हैं और कितने समय तक
समीक्षा का चक्र	हाई-इम्पैक्ट फ़ीचर के लिए तिमाही, बाक़ी के लिए छमाही
आख़िरी समीक्षा	तारीख़ और नतीजा

1. go-live से पहले हर AI सिस्टम के लिए एक ओनर नामित कीजिए। एक व्यक्ति, कमेटी नहीं। बाक़ी सब सहायक भूमिका निभाते हैं।
2. AI से प्रभावित फ़ैसलों पर ऑडिट ट्रेल रखिए। इनवॉइस अप्रूवल, सप्लायर चयन या उम्मीदवार रैंकिंग के लिए इस्तेमाल हुआ डेटा, आउटपुट और किसी व्यक्ति ने उसकी समीक्षा कब की, दर्ज कीजिए।
3. मॉडल की समीक्षा शेड्यूल कीजिए। डेटा बदलने के साथ मॉडल बिगड़ते हैं। क्रिटिकल सिस्टम के लिए तिमाही एक समझदार शुरुआत है। तीन महीने के ग़लत जवाबों का पता लगाने के लिए यूज़र की शिकायत का इंतज़ार मत कीजिए।
4. पहले डेटा गवर्नेंस लगाइए, फिर AI गवर्नेंस को उससे जोड़िए। AI गवर्नेंस के काम करने से पहले एक्सेस रूल, क्वालिटी मानक और मास्किंग मौजूद होने चाहिए। जो टीमें दोनों एक साथ बनाती हैं, वे अक्सर किसी को भी खड़ा नहीं कर पातीं।
5. गवर्नेंस को डॉक्यूमेंटेशन समझने की भूल मत कीजिए। SharePoint में पड़ी पॉलिसी गवर्नेंस नहीं है। गवर्नेंस फ़ैसले लेने का तरीक़ा बदलता है: कौन समीक्षा करता है, कौन एस्केलेट करता है और मॉडल को कौन रोक सकता है।

नियमन बदलता रहता है। 2026 के AI Act बदलाव दिखाते हैं कि तारीख़ें कितनी जल्दी खिसकती हैं। एक व्यक्ति को क़ानूनी बदलावों पर नज़र रखने और हर साल उन्हें SAP-विशिष्ट ज़रूरतों में बदलने का ज़िम्मा दीजिए।

मॉड्यूल के आर-पार निजता। SAP में पेरोल, कस्टमर ट्रांज़ैक्शन और कर्मचारी रिकॉर्ड हैं। SAP की रोल-आधारित सिक्योरिटी अपने आप AI मॉडल के इनपुट पर लागू नहीं होती। उसे साफ़ तौर पर जाँचिए।

ट्रेनिंग डेटा में पूर्वाग्रह। अगर SuccessFactors का कोई मॉडल पाँच साल के झुके हुए हायरिंग डेटा से सीखा है, तो वह झुकाव दोहराएगा। तैनाती से पहले सिर्फ़ सटीकता नहीं, ग्रुप के हिसाब से नतीजे देखिए।

पाइपलाइन में लेगसी सिस्टम। जब BTP पर AI किसी लेगसी ERP या थर्ड-पार्टी प्लेटफ़ॉर्म से डेटा खींचता है, तो सबसे कमज़ोर सिस्टम की डेटा क्वालिटी आपकी सीमा बन जाती है। मॉडल के लाइव होने से पहले स्रोत मैप कीजिए। मेरा AI रिस्क मैनेजमेंट फ़्रेमवर्क आकलन के कदम समझाता है, और मेरी AI गवर्नेंस फ़्रेमवर्क गाइड व्यापक ऑपरेटिंग मॉडल को कवर करती है।

SAP इम्प्लीमेंटेशन में AI गवर्नेंस क्या है?

यह ओनर, पॉलिसी और कंट्रोल का वह सेट है जो SAP के AI फ़ीचर को ज़िम्मेदारी, पारदर्शिता और क़ानूनी दायरे में चलाता है। इसमें यह आता है कि मॉडल कौन-सा डेटा इस्तेमाल कर सकते हैं, फ़ीचर कैसे मंज़ूर और तैनात होते हैं, फ़ैसले कैसे लॉग और रिव्यू होते हैं, और मॉडल को कौन रोक सकता है। यह S/4HANA, SuccessFactors, Ariba, Concur और SAP BTP पर आप जो भी बनाते हैं, उस सब पर लागू होता है।

SAP सिस्टम पर EU AI Act के हाई-रिस्क नियम कब लागू होते हैं?

Digital Omnibus (Regulation (EU) 2026/1744) के बाद, Annex III के स्टैंड-अलोन हाई-रिस्क सिस्टम के दायित्व 2 दिसंबर 2027 से लागू होते हैं। नियमन वाले उत्पादों में एम्बेडेड हाई-रिस्क AI 2 अगस्त 2028 से जुड़ता है। प्रतिबंधित प्रथाएँ और AI साक्षरता फ़रवरी 2025 से लागू हैं, और AI-जनरेटेड कंटेंट के पारदर्शिता दायित्व अगस्त 2026 से। SAP के लिए सबसे आम हाई-रिस्क क्षेत्र भर्ती और वर्कफ़ोर्स के फ़ैसलों में इस्तेमाल होने वाला AI है।

SAP प्रोजेक्ट में AI गवर्नेंस की ज़िम्मेदारी किसकी है?

एक क्रॉस-फ़ंक्शनल समूह की: कंप्लायंस नियमन पर नज़र रखता है, IT और सिक्योरिटी एक्सेस और लॉगिंग संभालते हैं, डेटा टीमें ट्रेनिंग डेटा की क्वालिटी की ओनर हैं, बिज़नेस प्रोसेस ओनर आउटपुट पर साइन-ऑफ़ करते हैं और लीगल देनदारी की समीक्षा करता है। सबसे अहम फ़ैसला हर AI सिस्टम के लिए एक जवाबदेह ओनर तय करना है। जब रात के दो बजे कुछ गड़बड़ हो, तो आपको पता होना चाहिए कि फ़ोन किसे जाएगा।

क्या Joule ऑडिट ट्रेल रखता है?

Joule के बातचीत के लॉग यूज़र, टाइमस्टैम्प, बातचीत और प्रॉम्प्ट व जवाब दर्ज कर सकते हैं, पर तभी जब ऑनबोर्डिंग के दौरान लॉग स्टोरेज में ऑप्ट-इन किया गया हो। SAP ऑप्ट-इन करने वाले ग्राहकों के लिए 365 दिन का डिफ़ॉल्ट रिटेंशन बताता है, और अलग अवधि का अनुरोध किया जा सकता है। Joule Studio में सुरक्षा से जुड़े कॉन्फ़िगरेशन बदलाव BTP की SAP Audit Log सर्विस में जाते हैं। मानकर चलने की जगह अपने टेनेंट की सेटिंग जाँचिए।

SAP SuccessFactors के AI मॉडल में पूर्वाग्रह को कैसे संभालें?

देखिए कि मॉडल किस पर ट्रेन हुआ है। अगर पुराने हायरिंग डेटा में कुछ समूहों के साथ भेदभाव हुआ था, तो मॉडल भी वही करेगा। go-live से पहले समूहों के आर-पार नतीजे जाँचिए, उसके बाद चयन की दरें मॉनिटर कीजिए, और जैसे-जैसे आपका वर्कफ़ोर्स डेटा बदले, तय अंतराल पर रीट्रेन कीजिए। अगर किसी एक पृष्ठभूमि के योग्य उम्मीदवार लगातार छँट रहे हैं, तो उसे संयोग नहीं, संकेत मानिए।

SAP में AI मॉडल की समीक्षा कितनी बार होनी चाहिए?

फ़ाइनेंशियल अप्रूवल, HR के फ़ैसले या सप्लायर चयन जैसे हाई-इम्पैक्ट सिस्टम के लिए तिमाही, और कम दाँव वाले टूल के लिए छमाही। जब भी कोई डेटा स्रोत, इंटीग्रेशन या बिज़नेस प्रोसेस बदले, तो एक अतिरिक्त समीक्षा कीजिए, क्योंकि इनमें से कोई भी बिना कोड बदले मॉडल का बर्ताव बदल सकता है।