EU AI एक्ट के तहत ‘बिल्ड-फ़ेज़’ (बनाने के चरण) की ज़िम्मेदारियाँ, किसी के कानूनी मेमो लिखने से बहुत पहले ही इंजीनियरिंग के काम में बदल जाती हैं। यह कोर्स प्रोवाइडर की ज़िम्मेदारियों पर केंद्रित है, यानी उन कर्तव्यों पर जो AI सिस्टम को रिलीज़ करने वाली टीम पर लागू होते हैं, क्योंकि इंजीनियर और डेटा साइंटिस्ट ही ज़्यादातर सबूत तैयार करते हैं जिन पर ये ज़िम्मेदारियाँ निर्भर करती हैं। टीमें अक्सर इस बात को नज़रअंदाज़ कर देती हैं क्योंकि उन्हें लगता है कि वे सिर्फ़ फ़ीचर बना रही हैं, जबकि बाद में सफलता या विफलता इस बात पर निर्भर करती है कि क्या रिकॉर्ड किया गया, क्या टेस्ट किया गया और अलग-अलग वर्शन में क्या एक जैसा बनाए रखा गया। आम तौर पर विफलता का कारण गलत इरादा नहीं होता। यह उस काम के बीच का अंतर है जो सिस्टम असल में करता है और जिसे टीम साबित कर सकती है कि वह करता है।
एक प्रोवाइडर किसी रिलीज़ का बचाव तभी कर सकता है जब शुरू से ही ‘बिल्ड’ (सिस्टम के निर्माण) का स्वरूप स्पष्ट हो। यह स्वरूप इस बात से तय होता है कि कौन सा सिस्टम बनाया जा रहा है, उसका मकसद क्या है, और वह असल माहौल में क्या कर सकता है और क्या नहीं। इसमें यह भी शामिल है कि कौन सा डेटा इस्तेमाल किया गया, कौन से कंट्रोल उसके साथ दिए गए, कौन से लॉग मौजूद हैं, और आउटपुट गलत लगने पर कोई इंसान क्या कर सकता है। इन सभी पहलुओं को एक साथ देखना ज़रूरी है क्योंकि अक्सर कोई कमी तब पता चलती है जब टीम पहले ही ट्रेनिंग, इंटीग्रेशन और डिप्लॉयमेंट का काम पूरा कर चुकी होती है। नीचे दिया गया मैप किसी एक हिस्से को सिखाने से पहले पूरे दायरे को स्पष्ट करता है।
इस कोर्स में, AI सिस्टम सिर्फ़ एक मॉडल फ़ाइल या कोई स्मार्ट प्रॉम्प्ट नहीं है। यह पूरा सेटअप है जो वर्कप्लेस प्रोसेस से इनपुट लेता है, ऐसे आउटपुट बनाता है जिन पर लोग भरोसा करते हैं, और ऐसे तरीके से काम करता है जो कोड, डेटा, कॉन्फ़िगरेशन और उसके आस-पास के इंटरफ़ेस से तय होते हैं। इसीलिए पाइपलाइन में छोटा सा बदलाव भी सिस्टम के असल दुनिया पर पड़ने वाले असर को बदल सकता है, भले ही मॉडल वेट्स (model weights) वही रहें।
कोई टीम सोच सकती है कि यह “सिर्फ़ एक मॉडल को इंटीग्रेट करना” है, लेकिन रेगुलेटेड चीज़ वह असेंबल किया हुआ सिस्टम है जो फ़ैसले, सुझाव या जेनरेट किए गए कंटेंट को वर्कफ़्लो का हिस्सा बनाता है। ट्रेनिंग जॉब, फ़ीचर स्टोर, रिट्रीवल इंडेक्स, गार्डरेल्स, मॉनिटरिंग रूल्स और UI कॉपी मिलकर तय करते हैं कि यूज़र क्या देखता है और उसे आगे क्या करने की इजाज़त है। अगर ये हिस्से किसी वर्शन और मकसद से जुड़े नहीं हैं, तो बाद की टेस्टिंग और डॉक्यूमेंटेशन असल में शिप की गई चीज़ से मेल नहीं खाएंगे।
इंजीनियर और डेटा साइंटिस्ट आमतौर पर उन फ़ैसलों के लिए ज़िम्मेदार होते हैं जो सिस्टम के मकसद, इनपुट और सीमाओं को तय करते हैं, क्योंकि ये फ़ैसले टिकट, डेटासेट, इवैल्यूएशन प्लान और कोड रिव्यू में लिए जाते हैं। लीगल और कंप्लायंस टीमें एक्ट (कानून) की व्याख्या कर सकती हैं, लेकिन वे यह दोबारा नहीं बना सकतीं कि मॉडल ने ट्रेनिंग के दौरान क्या देखा या फ़ैसला लेते समय UI ने क्या करने की इजाज़त दी। प्रोडक्ट टीम लक्ष्य तय कर सकती है, लेकिन वे गायब लॉग्स की जगह नहीं ले सकती या बिना ट्रैक किए गए एक्सपेरिमेंट को दोबारा नहीं चला सकती।
डिप्लॉयर्स को हैंडऑफ़ (काम सौंपना) भी बिल्ड के दौरान ही शुरू हो जाता है। डिप्लॉयर्स को साफ़ निर्देश, इंटरफ़ेस में इस्तेमाल करने लायक ट्रांसपेरेंसी और दबाव में काम करने वाले ओवरसाइट हुक्स की ज़रूरत होती है, क्योंकि एक पॉलिसी PDF ऐसे सिस्टम की कमी पूरी नहीं कर सकती जो अपनी अनिश्चितता को छिपाता है या दखल को रोकता है। जब बिल्डर्स इन्हें “बाद का कागज़ी काम” समझते हैं, तो उन्हें अक्सर असलियत से मेल खाने के लिए इंटरफ़ेस में पैच लगाने और डॉक्यूमेंटेशन को दोबारा लिखना पड़ता है, जो एक बार में सही डिज़ाइन करने की तुलना में धीमा होता है।
आगे बढ़ने से पहले, यह पहचानना मददगार होता है कि कौन से फ़ेलियर मोड्स (काम न करने के तरीके) पहले से पता हैं।