10.5 नैतिकता, जवाबदेही, और जनहित

अवलोकन और प्रेरणा

सॉफ़्टवेयर अब मानव निर्णयों के पीछे बैठा एक तटस्थ उपकरण नहीं रहा। यह तेज़ी से निर्णय बन रहा है। यह तय करता है कि किसे ऋण मिलता है, कोई भर्तीकर्ता किसका रेज़्यूमे देखता है, एक लाभ दावे में कितना समय लगता है, क्या धोखाधड़ी का फ़्लैग किसी खाते को फ़्रीज़ करता है, और लाखों लोगों तक कौन-सी जानकारी पहुँचती है। जब सॉफ़्टवेयर ऐसे निर्णय बनाता या आकार देता है जो लोगों के अधिकारों, धन, सुरक्षा, और गरिमा को प्रभावित करते हैं, तो इसे बनाने वाले इंजीनियर और संगठन शुद्धता और प्रदर्शन से परे ज़िम्मेदारियाँ उठाते हैं। यह अध्याय उन ज़िम्मेदारियों के बारे में है: पेशेवर नैतिकता, सिस्टम जो करते हैं उसके लिए जवाबदेही, सुविधाओं के बजाय दायित्वों के रूप में एक्सेसिबिलिटी और समता, एल्गोरिद्मिक पारदर्शिता, स्थिरता, और लोगों की निष्पक्षता और गरिमा के साथ सेवा करने का कर्तव्य।

बड़े संगठनों के लिए, पैमाना और शक्ति दाँव को ऊँचा उठाते हैं। एक उद्यम या सरकारी सिस्टम एक व्यक्ति को प्रभावित नहीं करता। यह लाखों को प्रभावित करता है। एक ही डिज़ाइन विकल्प (एक पक्षपाती प्रशिक्षण सेट, एक दुर्गम फ़ॉर्म, एक अपारदर्शी स्वचालित अस्वीकृति) उनमें से हर एक पर दोहराया जाता है। सरकारें एक बढ़ा हुआ कर्तव्य उठाती हैं, क्योंकि उनके सिस्टम वैकल्पिक नहीं हैं। एक नागरिक अपनी कर प्राधिकरण या अपनी लाभ एजेंसी के लिए किसी प्रतिस्पर्धी को नहीं चुन सकता। कुछ सेवाओं पर राज्य के एकाधिकार का अर्थ है कि एक बुरी तरह से बनाया गया सिस्टम लोगों को ऐसे अधिकारों से वंचित कर सकता है जिनका प्रयोग करने का उनके पास कोई और तरीका नहीं है। उस पहुँच के साथ निष्पक्ष, पारदर्शी, और जवाबदेह होने का एक मेल खाता कर्तव्य आता है।

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

मुख्य सिद्धांत

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

सिफ़ारिशें

पेशेवर नैतिकता अपनाएँ और उसे जिएँ

संगठन को पेशेवर आचरण की एक मान्यता प्राप्त संहिता में स्थापित करें, और इसे सजावटी नहीं बल्कि वास्तविक बनाएँ। इंजीनियरों को समझना चाहिए कि उनके दायित्व केवल अपने नियोक्ता के प्रति नहीं, बल्कि जनता के प्रति भी हैं। “मैं केवल स्पेक का पालन कर रहा था” जब कोई सिस्टम लोगों को नुकसान पहुँचाता है तो यह कोई बचाव नहीं है। नैतिक चिंताएँ उठाने के लिए वास्तविक माध्यम बनाएँ: यह कहने का एक तरीका कि “हमें यह नहीं बनाना चाहिए, या इस तरह नहीं बनाना चाहिए” जिसके लिए करियर-समाप्त करने वाले साहस की ज़रूरत न हो। टीमों को परिणामों को तौलने के लिए शब्दावली और अधिकार दें। इसे ऐसे नेतृत्व के साथ समर्थन दें जो नैतिक आपत्तियों को मूल्यवान संकेत मानता है, बाधा नहीं। नैतिकता प्रशिक्षण तभी मदद करता है जब संगठन उस पर दृश्य रूप से कार्य करता है जो वह सिखाता है।

एक्सेसिबिलिटी और समता को दायित्वों के रूप में मानें

शुरू से ही मानवीय क्षमता और परिस्थिति की पूरी श्रेणी के लिए निर्माण करें। एक्सेसिबिलिटी को बाद में जोड़ना कहीं अधिक महँगा है और आमतौर पर बदतर होता है। स्थापित एक्सेसिबिलिटी मानकों का पालन करें (जैसे WCAG, वेब कंटेंट एक्सेसिबिलिटी गाइडलाइंस), और कई अधिकार क्षेत्रों में उन कानूनी आवश्यकताओं को पूरा करें जो सार्वजनिक सेवाओं के लिए इन्हें अनिवार्य बनाती हैं। सहायक तकनीकों के साथ, और सबसे बढ़कर, विकलांगता वाले वास्तविक उपयोगकर्ताओं के साथ परीक्षण करें। समता को विकलांगता से परे अपनी सेवा करने वाली पूरी आबादी तक विस्तारित करें: कम बैंडविड्थ वाले, पुराने डिवाइस वाले, सीमित डिजिटल साक्षरता वाले, अल्पसंख्यक भाषाओं में, और कठिन जीवन परिस्थितियों में लोग। उन सेवाओं के लिए जिन्हें लोग ऑप्ट-आउट नहीं कर सकते (विशेष रूप से सरकारी सेवाएँ), केवल आत्मविश्वासी, जुड़े हुए, विशिष्ट उपयोगकर्ता के लिए डिज़ाइन करना सेवा देने की एक विफलता है, न कि एक उचित डिफ़ॉल्ट।

एल्गोरिद्मिक जवाबदेही और सार्वजनिक पारदर्शिता बनाएँ

किसी भी ऐसे सिस्टम के लिए जो लोगों के बारे में परिणामी निर्णय बनाता या भौतिक रूप से आकार देता है, जवाबदेही को डिज़ाइन में शामिल करें। स्वचालित आउटपुट पर अंधाधुंध भरोसा करने के बजाय, उच्च-दाँव वाले निर्णयों के लिए मनुष्यों को सार्थक रूप से लूप में रखें। ऐसे शब्दों में समझाने में सक्षम हों जिन्हें एक प्रभावित व्यक्ति समझ सके कि निर्णय क्यों लिया गया। इसे चुनौती देने और एक मनुष्य तक पहुँचने का एक वास्तविक रास्ता प्रदान करें। संरक्षित और कमज़ोर समूहों में पूर्वाग्रह और असमान प्रभाव के लिए सिस्टम का परीक्षण करें, तैनाती से पहले और उसके दौरान, और समय के साथ बहाव (drift) की निगरानी करें। सार्वजनिक क्षेत्र में, एल्गोरिद्म रजिस्टर जैसे तंत्रों के माध्यम से प्रकाशित करें कि एल्गोरिद्मिक सिस्टम कैसे काम करते हैं (उनका उद्देश्य, डेटा, और उचित स्तर पर तर्क), ताकि नागरिक और निगरानी निकाय उनकी जाँच कर सकें। इच्छित उपयोग और ज्ञात सीमाओं का दस्तावेज़ीकरण करें, ताकि सिस्टम वहाँ लागू न हों जहाँ उन्हें नहीं होना चाहिए।

निष्पक्षता, गरिमा, और निवारण के लिए डिज़ाइन करें

अपने सिस्टम की उन तरीकों के लिए जाँच करें जिनसे वे लोगों के साथ अनुचित व्यवहार कर सकते हैं या उनकी गरिमा के बिना। एम्बेडेड पूर्वाग्रह के लिए प्रशिक्षण डेटा और नियमों की जाँच करें। याद रखें कि विशुद्ध रूप से दक्षता के लिए अनुकूलित सिस्टम क्रूर हो सकता है: झूठे नकारात्मक को कम करने के लिए ट्यून किया गया एक धोखाधड़ी फ़िल्टर हज़ारों निर्दोष लोगों के खातों को फ़्रीज़ कर सकता है, जिनमें हर कोई परेशानी में एक वास्तविक व्यक्ति है। प्रभावित व्यक्ति के दृष्टिकोण से विफलता के मामलों के लिए डिज़ाइन करें। जब सिस्टम गलत होता है तो क्या होता है? उन्हें एक मनुष्य, एक स्पष्टीकरण, और एक उपाय कितनी आसानी से मिल सकता है? व्यक्तिगत डेटा को सम्मान और संयम के साथ संभालें: केवल वही एकत्र करें जो आवश्यक है, और उसके उपयोग के बारे में ईमानदार रहें। त्रुटि, देरी, और अस्वीकृति को किनारे के मामलों के रूप में नहीं, बल्कि उन क्षणों के रूप में मानें जहाँ गरिमा सबसे अधिक जोखिम में होती है।

स्थिरता और सामाजिक ज़िम्मेदारी के लिए जवाबदेह रहें

पहचानें कि सॉफ़्टवेयर की भौतिक और सामाजिक लागतें होती हैं। डेटा सेंटर, प्रशिक्षण रन, और अकुशल सिस्टम वास्तविक ऊर्जा खर्च करते हैं। दक्षता एक वित्तीय गुण के साथ-साथ एक पर्यावरणीय गुण भी है। आप जो बनाते हैं उसके व्यापक प्रभावों पर विचार करें (श्रम पर, सार्वजनिक विमर्श पर, कमज़ोर समूहों पर) और ऐसे काम को अस्वीकार करने या फिर से आकार देने के लिए तैयार रहें जिसके नुकसान उसके फ़ायदों से अधिक हों। बड़े संगठनों के लिए जिनके सिस्टम समाज को बड़े पैमाने पर आकार देते हैं, सामाजिक ज़िम्मेदारी व्यवसाय के साथ-साथ परोपकार नहीं है। यह ज़िम्मेदारी से निर्माण करने का हिस्सा है, और तेज़ी से विनियमन और सार्वजनिक अपेक्षा का मामला बनता जा रहा है।

समझौते: फ़ायदे और नुकसान

तनाव	एक पक्ष	दूसरा पक्ष
स्वचालन बनाम मानव निर्णय	पैमाना, निरंतरता, गति, कम लागत	जवाबदेही, बारीकी, दया, निवारण
पारदर्शिता बनाम सुरक्षा	सार्वजनिक जाँच, विश्वास, निगरानी	खेल-भावना का जोखिम, सुरक्षा, डेटा की गोपनीयता
एक्सेसिबिलिटी निवेश बनाम गति	सबकी सेवा करता है; कानूनी और नैतिक अनुपालन	धीमी प्रारंभिक डिलीवरी; अधिक डिज़ाइन प्रयास
दक्षता बनाम निष्पक्षता	अनुकूलित परिणाम; कम लागत	अल्पसंख्यक मामलों में व्यक्तियों के प्रति क्रूरता का जोखिम
डेटा-समृद्ध वैयक्तिकरण बनाम गोपनीयता	बेहतर सेवा; अनुकूलित अनुभव	निगरानी जोखिम; गरिमा और सहमति की चिंताएँ
नवाचार गति बनाम सावधानी	तेज़ मूल्य; प्रतिस्पर्धी बढ़त	बड़े पैमाने पर तैनात बिना जाँचे नुकसान

सबसे कठिन समझौता पैमाना बनाम व्यक्तिगत न्याय है। स्वचालन लाखों में निरंतरता और दक्षता पहुँचाता है। लेकिन इसकी त्रुटियाँ भी पैमाने पर पहुँचाई जाती हैं, और समग्र के लिए अनुकूलित एक सिस्टम अपने अल्पसंख्यक व्यक्तियों के प्रति चुपचाप क्रूर हो सकता है। इसका उत्तर स्वचालन को छोड़ना नहीं है। यह व्यक्तिगत विफलता मामले के लिए डिज़ाइन करना है: जहाँ दाँव ऊँचे हैं वहाँ मनुष्यों को लूप में रखें, स्पष्टीकरण और निवारण की गारंटी दें, और सिस्टम के प्रभाव को केवल औसत पर नहीं बल्कि सबसे बुरी तरह सेवा पाने वालों पर मापें। पारदर्शिता में भी एक वास्तविक तनाव है, क्योंकि पूर्ण खुलापन खेल-भावना को सक्षम कर सकता है और निजी डेटा को उजागर कर सकता है। लेकिन सार्वजनिक सेवाओं में उत्तर दृढ़ता से डिफ़ॉल्ट रूप से प्रकटीकरण की ओर झुकता है, केवल उसी को छूट देते हुए जिसे वास्तव में सुरक्षित रखा जाना चाहिए, बजाय इसके कि अपारदर्शिता को सुरक्षित डिफ़ॉल्ट माना जाए।

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

आपके कौन-से सिस्टम लोगों के बारे में परिणामी निर्णय बनाते या भौतिक रूप से आकार देते हैं, और क्या हर एक आज स्पष्टीकरण, मानव समीक्षा, और निवारण प्रदान करता है? सॉफ़्टवेयर तेज़ी से निर्णय बनता जा रहा है: किसे ऋण मिलता है, किसका रेज़्यूमे देखा जाता है, क्या कोई खाता फ़्रीज़ होता है, एक दावे में कितना समय लगता है। ऐसे हर सिस्टम के लिए, एक प्रभावित व्यक्ति एक समझने योग्य स्पष्टीकरण, उसे चुनौती देने का एक वास्तविक रास्ता, और हस्तक्षेप करने वाले एक मनुष्य का हक़दार है, और उद्यम या सरकारी पैमाने पर एक ही डिज़ाइन दोष लाखों में दोहराया जाता है। साक्ष्य लाएँ: अपने परिणामी स्वचालित निर्णयों की सूची बनाएँ और हर एक के लिए जाँचें कि क्या एक गलत व्यवहार किया गया व्यक्ति वास्तव में एक मनुष्य तक पहुँच सकता है और सरल-भाषा का कारण पा सकता है। जहाँ उत्तर नहीं है, वह एक दोष है जिसे ठीक करना है, न कि बाद में जोड़ी जाने वाली सुविधा। उन सेवाओं के लिए जिन्हें लोग ऑप्ट-आउट नहीं कर सकते, विशेष रूप से सरकारी सेवाएँ, यह एक शिष्टता के बजाय एक दायित्व है।
क्या आप एक्सेसिबिलिटी को वास्तविक विकलांग उपयोगकर्ताओं के साथ परीक्षित एक लॉन्च-अवरोधक आवश्यकता के रूप में मानते हैं, और आप वर्तमान में किसे असफल कर रहे हैं? एक्सेसिबिलिटी और समता दायित्व हैं, और लोगों को बाहर करना एक दोष है, अक्सर एक कानूनी और नैतिक विफलता, फिर भी एक्सेसिबिलिटी को बाद में जोड़ना पहली स्क्रीन से इसे डिज़ाइन में शामिल करने की तुलना में निश्चित रूप से धीमा, महँगा, और बदतर है। WCAG का पालन करें, और स्वचालित जाँचों से आगे बढ़कर सहायक तकनीकों और विकलांगता वाले वास्तविक उपयोगकर्ताओं के साथ, साथ ही कम बैंडविड्थ, पुराने डिवाइस, अल्पसंख्यक भाषाओं, और सीमित डिजिटल साक्षरता वाले लोगों के साथ परीक्षण करें। साक्ष्य लाएँ: अपने सबसे महत्वपूर्ण प्रवाह को एक स्क्रीन रीडर के साथ और एक थ्रॉटल किए गए कनेक्शन पर चलाएँ, और देखें कि यह कहाँ टूटता है। उत्तर से तय होना चाहिए कि क्या एक्सेसिबिलिटी एक गेट है जो रिलीज़ को रोकता है या एक बैकलॉग आइटम है जो कभी ऊपर नहीं उठता, और उन सेवाओं के लिए जिन्हें लोग ऑप्ट-आउट नहीं कर सकते, केवल गेट ही बचाव योग्य है। केवल आत्मविश्वासी, जुड़े हुए, विशिष्ट उपयोगकर्ता के लिए डिज़ाइन करना सेवा देने की विफलता है।
तैनाती से पहले और उसके दौरान परिणामी सिस्टम को पूर्वाग्रह और असमान प्रभाव के लिए परीक्षण करने की आपकी स्थायी प्रक्रिया क्या है? जब तक आप जानबूझकर जाँच न करें, सिस्टम अपने डेटा और डिज़ाइन में मौजूद पूर्वाग्रहों को विरासत में लेते और बढ़ाते हैं, और यह मान लेना कि निष्पक्षता है क्योंकि किसी ने अनुचितता का इरादा नहीं किया, उपेक्षा से पूर्वाग्रह है। विशुद्ध रूप से झूठे नकारात्मक को कम करने के लिए ट्यून किया गया एक धोखाधड़ी फ़िल्टर हज़ारों निर्दोष खातों को फ़्रीज़ कर सकता है, जिनमें हर कोई परेशानी में एक वास्तविक व्यक्ति है, इसलिए निष्पक्षता की परवाह किए बिना अनुकूलित दक्षता चुपचाप क्रूर हो सकती है। साक्ष्य लाएँ: हर उस मॉडल के लिए जो लोगों को प्रभावित करता है, संरक्षित और कमज़ोर समूहों में असमान-प्रभाव परीक्षण, दस्तावेज़ीकृत डेटा और ज्ञात सीमाएँ, और बहाव निगरानी दिखाएँ जो आबादी बदलने पर फिर से परीक्षण करती है। उत्तर से पूर्वाग्रह परीक्षण को एक बार की प्री-लॉन्च चेकबॉक्स के बजाय नियमित और निरंतर बनाना चाहिए, और इसे आपके अनुकूलन लक्ष्य को बदलना चाहिए ताकि केवल समग्र सटीकता ही नहीं बल्कि व्यक्तियों को होने वाले नुकसान को भी तौला जाए। प्रभावित व्यक्ति के दृष्टिकोण से विफलता के मामले के लिए डिज़ाइन करें।
जब कोई इंजीनियर मानता है कि आपको कुछ नहीं बनाना चाहिए, या इस तरह नहीं बनाना चाहिए, तो उस आपत्ति का वास्तव में क्या होता है? नैतिकता तभी वास्तविक बनती है जब “हमें यह शिप नहीं करना चाहिए” एक ऐसा वाक्य है जिसे कोई अपना करियर समाप्त किए बिना कह सकता है, और पैमाने पर, किसी नुकसान के सबसे करीब का व्यक्ति अक्सर कमरे में सबसे कनिष्ठ होता है। प्रतिस्पर्धी दबाव डिलीवरी है: एक उठाई गई आपत्ति एक रोडमैप को धीमा कर देती है, और समयसीमा के दबाव में नेता इसे मूल्यवान संकेत के बजाय बाधा मान सकते हैं। साक्ष्य लाएँ: वह सटीक माध्यम बताएँ जिसका एक इंजीनियर उपयोग करेगा, पिछले साल कितनी चिंताएँ उठाई गईं यह गिनें, और पता लगाएँ कि परिणामस्वरूप क्या बदला, क्योंकि एक ऐसा माध्यम जिसने कभी काम नहीं रोका या फिर से आकार नहीं दिया, वह सजावटी है। एक उद्यम या सरकारी निकाय के लिए, माध्यम को एक नामित स्वामी और एक दस्तावेज़ीकृत समीक्षा से जोड़ें, क्योंकि एक आपत्ति जिसे सुनने के लिए कोई बाध्य नहीं है, वह ऐसी आपत्ति है जिसे उठाने का जोखिम कोई नहीं लेगा, और फिर नुकसान पहले एक सार्वजनिक घोटाले के रूप में सामने आता है।
क्या आप जानते हैं कि आप जो चलाते हैं उसकी पर्यावरणीय और सामाजिक लागत क्या है, और क्या आप ऐसे काम को फिर से आकार देंगे या अस्वीकार करेंगे जिसके नुकसान उसके फ़ायदों से अधिक हों? सॉफ़्टवेयर की भौतिक और सामाजिक लागतें होती हैं: डेटा सेंटर, प्रशिक्षण रन, और अकुशल सिस्टम वास्तविक ऊर्जा खर्च करते हैं, और श्रम, सार्वजनिक विमर्श, और कमज़ोर समूहों पर दूसरे-क्रम के प्रभाव एक सिस्टम की वास्तविक लागत का हिस्सा हैं। तनाव यह है कि इन लागतों को मापना और घटाना फ़ीचर गति के साथ प्रतिस्पर्धा करता है, और हानिकारक काम से इनकार करना उस राजस्व को छोड़ देता है जिसके लिए कोई जवाबदेह है। साक्ष्य लाएँ: अपने सबसे बड़े सिस्टम का ऊर्जा या कंप्यूट फ़ुटप्रिंट, इस बारे में एक स्पष्ट आकलन कि डाउनस्ट्रीम प्रभावों को कौन उठाता है, और कम से कम एक ठोस मामला जहाँ आपने इन आधारों पर काम को फिर से आकार दिया या अस्वीकार किया। उद्यम या सरकारी पैमाने पर, जहाँ आपके सिस्टम समाज को आकार देते हैं, इसे व्यवसाय के किनारे जोड़े गए परोपकार के बजाय ज़िम्मेदारी से निर्माण करने का हिस्सा और तेज़ी से विनियमन और सार्वजनिक अपेक्षा का मामला मानें।
कोई बाहरी व्यक्ति आपके परिणामी सिस्टम कैसे निर्णय लेते हैं इसके बारे में वास्तव में कितना जान सकता है, और क्या प्रकटीकरण आपका डिफ़ॉल्ट है या आपका अपवाद? पारदर्शिता वह जगह है जहाँ सार्वजनिक विश्वास कमाया या खोया जाता है, क्योंकि लोगों को यह समझने का अधिकार है कि उनके बारे में निर्णय कैसे लिए जाते हैं, और सार्वजनिक क्षेत्र में वह अधिकार अक्सर कानून होता है। वास्तविक प्रति-दबाव यह है कि पूर्ण खुलापन खेल-भावना को सक्षम कर सकता है और निजी डेटा को उजागर कर सकता है, इसलिए असली सवाल यह है कि रेखा कहाँ खींची जाए, न कि क्या प्रकट करना है या नहीं। साक्ष्य लाएँ: हर परिणामी सिस्टम के लिए, दिखाएँ कि आप क्या प्रकाशित करते हैं (उद्देश्य, डेटा, और उचित स्तर पर तर्क), आप क्या रोकते हैं और उसका विशिष्ट कारण, और क्या किसी तकनीकी विवरण के साथ एक सरल-भाषा विवरण भी है। एक सरकारी निकाय के लिए, एल्गोरिद्म रजिस्टर जैसे तंत्र को संकीर्ण, बचाव योग्य छूटों के विरुद्ध तौलें, और जाँचें कि आपके प्रकटीकरण वास्तव में समझाते हैं बजाय तकनीकी रूप से सूचित करने के जबकि एक प्रभावित व्यक्ति को कुछ नहीं बताते।

क्षेत्र लेंस

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

लघु व्यवसाय। आपके पास संभवतः कोई एक्सेसिबिलिटी या निष्पक्षता विशेषज्ञ नहीं है और एक तंग बजट है, इसलिए उन टूलों में बनी नैतिकता पर निर्भर रहें जिन्हें आप ख़रीदते हैं: उन विक्रेताओं को चुनें जो WCAG को पूरा करते हैं, दस्तावेज़ीकृत करते हैं कि उनकी स्वचालित सुविधाएँ कैसे निर्णय लेती हैं, और आपको लूप में एक मनुष्य रखने देते हैं। अपने स्वयं के कर्तव्य को एक डेटा-स्वच्छता और गरिमा प्रश्न के रूप में परिभाषित करें, यह जानते हुए कि आपके पास कौन-सा व्यक्तिगत डेटा है, केवल वही एकत्र करें जो आपको चाहिए, और सुनिश्चित करें कि एक गलत स्वचालित उत्तर किसी ग्राहक को आप तक पहुँचने के किसी रास्ते के बिना न छोड़े। शिकायत के बाद अंतर खोजने के बजाय, हस्ताक्षर करने से पहले आपूर्तिकर्ताओं से उनकी एक्सेसिबिलिटी और पूर्वाग्रह स्थिति दिखाने को कहें।

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

सरकार। खरीद नियम, पारदर्शिता दायित्व, और सार्वजनिक जवाबदेही हर विकल्प को आकार देते हैं, और नागरिक किसी प्रतिस्पर्धी के पास जाकर आपकी सेवा से ऑप्ट-आउट नहीं कर सकते। एल्गोरिद्म रजिस्टर जैसे तंत्र के माध्यम से प्रकाशित करें कि परिणामी सिस्टम कैसे काम करते हैं, विक्रेताओं को अनुबंध के तहत डेटा प्रथाओं और ज्ञात सीमाओं को प्रकट करने की आवश्यकता रखें, और हर सार्वजनिक सेवा को विकलांग उपयोगकर्ताओं, कम-बैंडविड्थ कनेक्शन, और अल्पसंख्यक-भाषा बोलने वालों के साथ परीक्षित एक्सेसिबिलिटी मानकों के अनुसार बनाएँ। हर परिणामी स्वचालित निर्णय पर मानव समीक्षा और एक सरल-भाषा स्पष्टीकरण के अधिकार की गारंटी दें, और उन अंतिम निर्धारणों को जिन्हें एक जवाबदेह अधिकारी के पास रहना चाहिए, पूर्ण स्वचालन से पूरी तरह बाहर रखें।

उदाहरण

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

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

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

व्यावसायिक तर्क: प्रेरणाएँ, ROI, और TCO

नैतिकता और जवाबदेही के लिए व्यावसायिक तर्क विश्वास, जोखिम, और पहुँच पर टिका है। विश्वास टिकाऊ संपत्ति है। जिन संगठनों के सिस्टम लोगों के साथ निष्पक्ष और पारदर्शी व्यवहार करते हैं वे वह भरोसा कमाते हैं जो लोगों को उन्हें उपयोग करने के लिए तैयार बनाता है, और सार्वजनिक संस्थाएँ विशेष रूप से उस वैधता पर निर्भर करती हैं जिसे एक ही हाई-प्रोफ़ाइल अनुचित सिस्टम चूर-चूर कर सकता है। जोखिम निकट-अवधि का प्रेरक है। पक्षपाती, दुर्गम, या अपारदर्शी सिस्टम तेज़ी से नियामक दंड, मुक़दमेबाज़ी, और प्रतिष्ठा क्षति ले जाते हैं जो ज़िम्मेदारी से निर्माण की लागत को बौना बना सकते हैं। पहुँच दोनों को बढ़ाती है। उद्यम या सरकारी पैमाने पर, एक ही नैतिक विफलता लाखों में दोहराई जाती है और एक सुर्खी बन जाती है।

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

विपरीत प्रतिमान और नुकसान

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

परिपक्वता मॉडल

स्तर 1: प्रारंभ (Initiate)। नैतिकता को संबोधित नहीं किया जाता या एक घोटाले के बाद विशुद्ध रूप से प्रतिक्रियात्मक होती है। एक्सेसिबिलिटी को नज़रअंदाज़ किया जाता है या यह न्यूनतम है। स्वचालित निर्णय अपारदर्शी हैं, बिना स्पष्टीकरण और बिना निवारण के। पूर्वाग्रह का कभी परीक्षण नहीं किया जाता, और स्थिरता और सामाजिक प्रभाव पर विचार नहीं किया जाता।

स्तर 2: विकास (Develop)। एक आचार संहिता मौजूद है और कुछ एक्सेसिबिलिटी मानकों का पालन किया जाता है, अक्सर देर से। हाई-प्रोफ़ाइल स्वचालित निर्णयों को कुछ मानव निगरानी मिलती है, लेकिन अधिकांश को नहीं। पूर्वाग्रह की कभी-कभी जाँच की जाती है, चिंताएँ एक कमज़ोर प्रक्रिया के माध्यम से उठाई जा सकती हैं, और प्रथाएँ एक टीम से दूसरी टीम में व्यापक रूप से भिन्न होती हैं।

स्तर 3: मानकीकरण (Standardize)। नैतिक समीक्षा विकास प्रक्रिया का एक दस्तावेज़ीकृत हिस्सा है और पूरे संगठन में लागू है। एक्सेसिबिलिटी को डिज़ाइन में शामिल किया जाता है और वास्तविक उपयोगकर्ताओं के साथ परीक्षित किया जाता है। परिणामी स्वचालित निर्णय डिफ़ॉल्ट रूप से स्पष्टीकरण, मानव समीक्षा, और निवारण रखते हैं। पूर्वाग्रह परीक्षण और बहाव निगरानी नियमित हैं, सार्वजनिक-क्षेत्र के सिस्टम यह प्रकाशित करते हैं कि वे कैसे काम करते हैं, और स्थिरता को एक सामान्य मानक के अनुसार मापा जाता है।

स्तर 4: प्रबंधन (Manage)। संगठन अपनी नैतिक स्थिति को बेसलाइन के विरुद्ध डेटा से मापता और नियंत्रित करता है: एक्सेसिबिलिटी अनुरूपता स्कोर, संरक्षित समूहों में समय के साथ ट्रैक किए गए असमान-प्रभाव मीट्रिक, विवादित निर्णयों के लिए निवारण दरें और मनुष्य तक पहुँचने का समय, प्रकाशित दस्तावेज़ीकरण रखने वाले परिणामी सिस्टम का हिस्सा, और प्रमुख सिस्टम का ऊर्जा या कंप्यूट फ़ुटप्रिंट। मीट्रिक रिलीज़ को गेट करते हैं, थ्रेशोल्ड उल्लंघन जाँच को ट्रिगर करते हैं, और नेता यह मान लेने के बजाय कि प्रथाओं का पालन किया जा रहा है, एक निश्चित अंतराल पर आँकड़ों की समीक्षा करते हैं।

स्तर 5: समन्वय (Orchestrate)। ज़िम्मेदारी इस बात में अंतर्निहित है कि संगठन कैसे निर्माण और अनुकूलन करता है। एक्सेसिबिलिटी और समता सेवा प्राप्त पूरी आबादी के लिए सत्यापित गैर-परक्राम्य डिफ़ॉल्ट हैं, एल्गोरिद्मिक जवाबदेही (पारदर्शिता, निष्पक्षता परीक्षण, निवारण, मानव निगरानी) मानक और निरंतर निगरानी में है, और नैतिक चिंताएँ मूल्यवान संकेत हैं जो काम को फिर से आकार देती या रोकती हैं। संगठन विश्वास, निष्पक्षता, और गरिमा को अपने मिशन के मूल के रूप में मानता है, नैतिकता को उत्पाद, जोखिम, और खरीद निर्णयों के साथ एकीकृत करता है, और अपेक्षाओं और साक्ष्य के विकसित होने पर सिस्टम को फिर से परिभाषित या सेवानिवृत्त करता है।

चर्चा के लिए विचार

उन निर्णयों के बीच रेखा कहाँ है जिन्हें पूरी तरह स्वचालित किया जा सकता है और जिन्हें एक मनुष्य को सार्थक रूप से लूप में रखना चाहिए?
कितनी एल्गोरिद्मिक पारदर्शिता पर्याप्त है, और आप खेल-भावना को सक्षम किए या गोपनीयता का उल्लंघन किए बिना सार्थक रूप से कैसे प्रकट करते हैं?
जब एक स्वचालित सिस्टम किसी को नुकसान पहुँचाता है तो कौन जवाबदेह है: इंजीनियर, प्रबंधक, संगठन, या विक्रेता?
आप नैतिक आपत्ति उठाने को करियर-सीमित करने के बजाय वास्तव में सुरक्षित कैसे बनाते हैं?
एक संगठन का उन उपयोगकर्ताओं के प्रति क्या दायित्व है जिनके लिए उसने डिज़ाइन नहीं किया, और समता को कितनी दूर तक विस्तारित होना चाहिए?
कंप्यूटेशन की पर्यावरणीय लागत को आर्किटेक्चरल और उत्पाद निर्णयों में कैसे शामिल किया जाना चाहिए?

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

ACM/IEEE-CS, Software Engineering Code of Ethics and Professional Practice
ACM, Code of Ethics and Professional Conduct
Cathy O’Neil, Weapons of Math Destruction
Virginia Eubanks, Automating Inequality
Safiya Umoja Noble, Algorithms of Oppression
Ruha Benjamin, Race After Technology
Batya Friedman and David G. Hendry, Value Sensitive Design
World Wide Web Consortium (W3C), Web Content Accessibility Guidelines (WCAG)
NIST, AI Risk Management Framework
OECD, Principles on Artificial Intelligence
European Union, General Data Protection Regulation (GDPR) and the AI Act
UK Government, Data Ethics Framework and the Algorithmic Transparency Recording Standard