यह कोर्स उन इंजीनियरों के लिए है जो AI सिस्टम बनाते और लॉन्च करते हैं। यह EU AI एक्ट, रेगुलेशन (EU) 2024/1689 पर आधारित है और ज़िम्मेदार AI बनाने से जुड़े फ़ैसलों पर केंद्रित है। इसमें प्रोवाइडर के काम पर ध्यान दिया गया है—यानी ऐसे फ़ैसले जो किसी मॉडल या पाइपलाइन को एक ऐसे प्रोडक्ट में बदलते हैं जिसके लिए आप तर्क दे सकें। इस कोर्स में ज़िम्मेदार AI का मतलब है—डिज़ाइन, डॉक्यूमेंटेशन, गवर्नेंस और लॉन्चिंग—ताकि सिस्टम की सीमाएँ साफ़ हों और उसके व्यवहार को कंट्रोल किया जा सके। टीमें अक्सर यह गलती करती हैं कि वे प्रोवाइडर की ज़िम्मेदारियों को सिर्फ़ लॉन्च के समय किए जाने वाले कागज़ी काम की तरह देखती हैं। यह काम भले ही बाद में डॉक्यूमेंट लिखने जैसा लगे, लेकिन असल में इसका फ़ैसला डिज़ाइन और डेटा से जुड़े विकल्पों के ज़रिए बहुत पहले ही हो जाता है। इसीलिए यह कोर्स बार-बार उन आर्टिफ़ैक्ट्स (दस्तावेज़ों या चीज़ों) पर लौटता है जिन्हें आप नाम और वर्शन दे सकते हैं। हम डिटेल में जाने से पहले एक मैप तैयार करते हैं, ताकि आप हर ज़िम्मेदारी को उसकी सही जगह पर रख सकें।
एक प्रोवाइडर टीम पहले से ही इस काम का ज़्यादातर हिस्सा अलग-अलग जगहों पर करती है—जैसे आर्किटेक्चर डॉक्यूमेंट, मॉडल कार्ड, इवैल्यूएशन नोटबुक, रिलीज़ चेकलिस्ट और मॉनिटरिंग डैशबोर्ड। समस्या यह है कि ये चीज़ें हमेशा एक ही मकसद के साथ तालमेल नहीं बिठा पातीं, जिससे टीमों के बीच कमियाँ (गैप) रह जाती हैं। एक बार जब ये कमियाँ रह जाती हैं, तो सिस्टम को आगे इस्तेमाल करने वाले (डाउनस्ट्रीम डिप्लॉयर) उसे सुरक्षित रूप से नहीं चला पाते, क्योंकि उन्हें यह पता नहीं होता कि सिस्टम किस मकसद से बनाया गया था या दबाव की स्थिति में वह कैसा व्यवहार करता है। यह कोर्स प्रोवाइडर की ज़िम्मेदारियों को ‘बनाने और लॉन्च करने’ के एक ऐसे स्ट्रक्चर के तौर पर देखता है जिसके तीन चरण हैं: डिज़ाइन और डेटा; रिलीज़ गेट और सबूत; और फिर पोस्ट-मार्केट मॉनिटरिंग और घटना से निपटना। यही स्ट्रक्चर बाद के लेसन को प्रैक्टिकल बनाता है। यहाँ उस स्ट्रक्चर की एक झलक दी गई है:
इस कोर्स में, AI सिस्टम एक मशीन-आधारित सिस्टम है जिसे अलग-अलग स्तर की स्वायत्तता (autonomy) के साथ काम करने के लिए डिज़ाइन किया गया है। यह सिस्टम मिले हुए इनपुट से आउटपुट (जैसे अनुमान, कंटेंट, सुझाव या निर्णय) बनाने का तरीका खुद तय करता है। प्रोवाइडर वह व्यक्ति या संगठन है जो AI सिस्टम बनाता है (या बनवाता है) और उसे अपने नाम या ट्रेडमार्क के तहत बाज़ार में लाता है या सेवा में लगाता है, चाहे वह पेड हो या फ़्री। यह परिभाषा इंजीनियरों के लिए महत्वपूर्ण है क्योंकि आप बेस वेट्स (base weights) को ट्रेन किए बिना भी प्रोवाइडर बन सकते हैं; बस आपको शिप किए गए सिस्टम और उसके उद्देश्य का मालिक होना होगा। आप वह सीमा तब पार करते हैं जब यूज़र आपके सिस्टम को एक प्रोडक्ट के तौर पर इस्तेमाल करते हैं और आपकी टीम यह तय करती है कि वह क्या करेगा।
थर्ड-पार्टी मॉडल का इस्तेमाल करने से वह थर्ड-पार्टी आपके द्वारा शिप की गई हर चीज़ के लिए अपने-आप प्रोवाइडर नहीं बन जाती। आपकी टीम ही तय करती है कि कौन सा डेटा अंदर आएगा, आउटपुट का क्या मतलब होगा और इंटरफ़ेस में क्या सुरक्षा उपाय (guardrails) होंगे। ये फ़ैसले असल में सिस्टम का उद्देश्य तय करते हैं, भले ही मार्केटिंग टीम कभी उस शब्द का इस्तेमाल न करे। जब कोई पार्टनर पूछता है, “यहाँ प्रोवाइडर कौन है,” तो वे यह पूछ रहे होते हैं कि सबूतों का रिकॉर्ड (evidence trail) कौन दिखा सकता है, न कि यह कि मॉडल कोड की पहली लाइन किसने लिखी थी।
इंजीनियर प्रोवाइडर के काम के उन हिस्सों की ज़िम्मेदारी लेते हैं जिन्हें सिर्फ़ ‘बिल्ड’ (बनाया गया सिस्टम) ही सही साबित कर सकता है। कंप्लायंस और लीगल टीमें AI एक्ट को समझने में मदद कर सकती हैं, लेकिन वे रिलीज़ के बाद लॉगिंग, निगरानी के तरीके (oversight hooks) या मूल्यांकन कवरेज को बाद में नहीं जोड़ सकतीं। सबसे मुश्किल काम होता है कानूनी ज़िम्मेदारी को ऐसी चीज़ में बदलना जिसे आप रिपॉज़िटरी (repo), टेस्ट रन या रिलीज़ गेट पर दिखा सकें। इसी बदलाव के दौरान अक्सर प्रोजेक्ट्स भटक जाते हैं, क्योंकि इसमें कई टीमें और टाइमलाइन शामिल होती हैं। जब यह काम ठीक से होता है, तो इंजीनियरिंग आउटपुट साधारण और जाँचने लायक होता है।
जो टीम इसे अच्छे से करती है, वह बार-बार एक ही तरीका अपनाती है: वे शुरू में ही उद्देश्य तय कर लेते हैं, फिर डिज़ाइन के फ़ैसलों और डॉक्यूमेंटेशन को उससे जोड़ देते हैं। वे डॉक्यूमेंटेशन को ‘बिल्ड’ का आईना मानते हैं, न कि बाद में लिखी गई कहानी; इसलिए यह सिस्टम के वर्शन के साथ ही अपडेट होता रहता है। वे बाज़ार में लाने से पहले ज़रूरी चीज़ों और लॉन्च के बाद भी चलते रहने वाली चीज़ों को अलग-अलग रखते हैं, क्योंकि शिपिंग के बाद उन चीज़ों को बदलना मुश्किल हो जाता है जिन्हें पहले कम लागत में ठीक किया जा सकता था। अगर आप किसी ज़िम्मेदारी के लिए आर्टिफैक्ट (काम का हिस्सा/डॉक्यूमेंट) का नाम तय कर सकते हैं, तो आप उसके लिए एक मालिक और तारीख भी तय कर सकते हैं।