यह कोर्स AI सिस्टम को खरीदने से पहले उसकी जांच करने के बारे में है, ताकि उसे लागू करने वाला व्यक्ति (डिप्लॉयर) खरीद का ऐसा फैसला ले सके जिसे सही ठहराया जा सके। यह मुख्य कानूनी ढांचे के तौर पर EU AI एक्ट पर आधारित है, और इसमें खरीद (procurement) और अनुपालन (compliance) से जुड़े लोगों को यह तय करना होता है कि क्या मांगना है और क्या मना करना है। कई टीमें AI की खरीद को सॉफ्टवेयर की खरीद जैसा ही मानती हैं, जहां डेमो और सिक्योरिटी रिव्यू ही सबसे मुश्किल काम लगते हैं। असल मुश्किल यह समझना है कि इस्तेमाल के दौरान सिस्टम कैसा व्यवहार करता है, क्योंकि प्रॉम्प्ट, डेटा और संदर्भ (context) के साथ इसके आउटपुट बदल सकते हैं। यह बदलाव आसानी से दिखाई नहीं देता, क्योंकि वेंडर एक बेहतरीन वर्कफ़्लो दिखा सकता है। खरीदार को फिर भी यह तय करना होता है कि कितना सबूत काफी है।
इस कोर्स में AI सिस्टम का मतलब है ऐसा सॉफ्टवेयर जो इनपुट से टेक्स्ट, स्कोर, सुझाव या फैसले जैसे आउटपुट देता है, और ये आउटपुट लोगों के अगले कदमों पर असर डाल सकते हैं। खरीद के मामले में यह बात अहम है क्योंकि एक ही फ़ीचर का असर एक इस्तेमाल में कम और दूसरे में ज़्यादा हो सकता है, जो इस बात पर निर्भर करता है कि आउटपुट किन लोगों को प्रभावित करते हैं और उनका इस्तेमाल कैसे किया जाता है। यह काम रोज़मर्रा के चरणों में ही होता है, जैसे सप्लायर पैक की समीक्षा करना, इस्तेमाल के तरीके (use case) को मंज़ूरी देना और रोलआउट के लिए शर्तें तय करना। मुश्किल तब होती है जब खरीद के समय सवाल सिर्फ़ यह नहीं होता कि क्या यह काम करता है, बल्कि यह भी होता है कि हमारे माहौल में यह क्या कर सकता है जो डेमो में नहीं दिखाया गया था। पूरे वर्कफ़्लो को पहले से देख लेने से मदद मिलती है, क्योंकि हर जांच खरीद प्रक्रिया के एक खास चरण से जुड़ी होती है। यहां उस वर्कफ़्लो का एक संक्षिप्त विवरण दिया गया है।
एक सामान्य सॉफ्टवेयर टूल आमतौर पर एक ही इनपुट के लिए एक ही काम करता है, इसलिए आप इसे एक बार टेस्ट कर सकते हैं और नतीजे को ज़रूरतों के हिसाब से तय कर सकते हैं। एक AI सिस्टम अपटाइम के मामले में तो एक जैसा रह सकता है, लेकिन कंटेंट के मामले में अलग-अलग नतीजे दे सकता है, क्योंकि यह तय नियमों का पालन करने के बजाय आउटपुट बनाता है या अनुमान लगाता है। इसका मतलब है कि आप लगातार इस्तेमाल के लिए सिर्फ़ एक एक्सेप्टेंस टेस्ट पर भरोसा नहीं कर सकते, भले ही वेंडर इसे प्रोडक्शन के लिए तैयार बताए। आपको मूल्यांकन को उस खास इस्तेमाल से जोड़ना होगा जिसके लिए आप इसे खरीद रहे हैं, जिसमें यह भी शामिल है कि आउटपुट कौन पढ़ेगा और इससे क्या कार्रवाई हो सकती है।
खरीददारी में एक बड़ी गलती यह होती है कि मॉडल को ही प्रोडक्ट मान लिया जाता है, जबकि असल प्रोडक्ट उसके आस-पास का पूरा सिस्टम होता है। सिस्टम में यूज़र इंटरफ़ेस, प्रॉम्प्ट, आपके डॉक्यूमेंट से जानकारी निकालना, इंटीग्रेशन और इंसानी समीक्षा का कोई भी चरण शामिल होता है। ये हिस्से तय करते हैं कि कौन सा डेटा कहाँ जाता है और क्या रिकॉर्ड होता है। वे यह भी तय करते हैं कि ग्राहक, उम्मीदवार या कर्मचारी तक पहुँचने से पहले गलतियों को पकड़ना कितना आसान है।
अच्छी तरह से जाँच-पड़ताल (ड्यू डिलिजेंस) करने के लिए खरीद और अनुपालन (compliance) टीमों का डिलीवरी की ज़िम्मेदारी लेना ज़रूरी नहीं है। खरीदने का फ़ैसला और आपके द्वारा तय की गई शर्तें आपकी होती हैं, जिसका मतलब है कि आप साइन करने से पहले ज़रूरी डॉक्यूमेंट और साफ़ जवाब माँग सकते हैं। प्रोडक्ट और IT टीमें आमतौर पर इंटीग्रेशन की जानकारी संभालती हैं, जबकि प्राइवेसी टीम डेटा सुरक्षा का पहलू देखती है, लेकिन आप फिर भी उनमें से हर एक से एक ठोस इनपुट माँग सकते हैं जो खरीदने के फ़ैसले का समर्थन करे। ज़रूरी बात यह है कि ऐसे सवाल पूछे जाएँ जिनसे डॉक्यूमेंट मिलें, न कि सिर्फ़ भरोसा दिलाया जाए।
काम का एक उपयोगी बँटवारा यह है कि वेंडर के दावों, आपकी अंदरूनी टीमों की पुष्टि और ट्रायल में देखी गई चीज़ों को अलग-अलग रखा जाए। वेंडर के दावे डेटाशीट, सुरक्षा रिपोर्ट या इस्तेमाल के निर्देशों वाले डॉक्यूमेंट जैसी चीज़ों में होते हैं। अंदरूनी पुष्टि इंटीग्रेशन नोट, ऑपरेटिंग प्रोसीजर के ड्राफ़्ट या रिस्क साइन-ऑफ़ जैसी चीज़ों में होती है। अवलोकन (observations) टेस्ट रिकॉर्ड, रेड-टीम नोट्स और इस बात के स्क्रीनशॉट में होते हैं कि सिस्टम ने आपके प्रॉम्प्ट और डेटा के साथ क्या किया।
यह जाँच तभी फ़ायदेमंद है जब इससे आपकी आगे की सोच या ध्यान देने का तरीका बदले। वही सिस्टम डेमो में सुरक्षित लग सकता है, लेकिन इस्तेमाल के मामले और प्रभावित लोगों का नाम लेते ही पहली चिंता पैदा कर सकता है। हर हिस्से में उठने वाली पहली चिंता को चुनें, क्योंकि उसी के आधार पर आप वेंडर से अगली माँग करते हैं।