Image-processing APIs में डेटा रिटेंशन और निजता

किसी यूज़र से पूछिए कि इमेज फ़ीचर में उसे किस बात की चिंता है — वह मॉडल आर्किटेक्चर का ज़िक्र नहीं करेगा। वह पूछेगा कि फ़ोटो जाती कहाँ है और वहाँ कितने समय रहती है। Intimate इमेजरी के मामले में यह चिंता पागलपन नहीं — यह सही सहज बोध है, और इसे आश्वस्त करने वाले विशेषण के बजाय सटीक जवाब चाहिए।

Retention ही पूरी बातचीत क्यों है

सर्वर पर पड़ी इमेज ऐसी देनदारी है जिस पर ब्याज चढ़ता है। उसके अस्तित्व का हर दिन एक और दिन है जब वह किसी breach से उजागर हो सकती है, किसी subpoena से माँगी जा सकती है, या किसी ऐसे कर्मचारी को मिल सकती है जिसे उसे कभी नहीं देखना चाहिए था। Storage सस्ता है — और यही तो समस्या है: किसी को डिलीट करने के लिए कुछ मजबूर नहीं करता, इसलिए सिस्टम intimate डेटा फ़ैसले से नहीं, डिफ़ॉल्ट से जमा करते जाते हैं।

तीन जवाब जो मायने रखते हैं

वेंडर का मूल्यांकन करते समय तीन सवाल गंभीर ऑपरेटर को मार्केटिंग पेज से अलग कर देते हैं। स्रोत इमेज कितने समय रखी जाती है? नतीजा कितने समय रखा जाता है? इनमें से कुछ भी training के लिए इस्तेमाल होता है? इन तीनों में से किसी पर भी गोलमोल जवाब अपने आप में एक जवाब है।

• "हम डिलीवरी के 10 मिनट बाद इमेज डिलीट कर देते हैं" — यह ऐसी प्रतिबद्धता है जिसे आप जाँच सकते हैं।
• "हम सेवा देने के लिए जितना ज़रूरी हो उतने समय तक डेटा रखते हैं" — यह वाक्य अनिश्चितकालीन storage की इजाज़त देता है।
• "हम अपने models बेहतर करने के लिए सामग्री इस्तेमाल कर सकते हैं" का मतलब है आपके यूज़र्स की तस्वीरें training data बन जाती हैं।
• इस विषय पर चुप्पी का मतलब है किसी ने तय ही नहीं किया, जो असुविधाजनक नीति से भी बुरा है।

Deletion का मतलब सचमुच deletion होना चाहिए

Retention का वादा उतना ही अच्छा है जितना उसका प्रवर्तन, और इसे ग़लत करने के तरीक़े सही करने के तरीक़ों से ज़्यादा हैं। डेटाबेस row हट जाती है पर फ़ाइल डिस्क पर बनी रहती है। प्राथमिक प्रति चली जाती है और CDN कैश परोसता रहता है। ऐप्लिकेशन डिलीट कर देता है पर रात का backup उसे नब्बे दिन तक सहेजे रखता है। प्रोसेसिंग pipeline द्वारा लिखी गई intermediate फ़ाइलें तो कभी दायरे में आती ही नहीं।

विश्वसनीय जवाब सभी प्रतियों का नाम लेता है। ख़ासकर caches, backups और intermediate artefacts के बारे में पूछिए — जवाब बता देगा कि नीति डिज़ाइन की गई थी या बस लिख दी गई थी।

Training उपयोग एक अलग फ़ैसला है

Models सुधारने के लिए ग्राहक सामग्री इस्तेमाल करना कारोबारी विकल्प है, तकनीकी अनिवार्यता नहीं — और intimate इमेजरी के लिए इस पर दबी हुई अनुमति नहीं, स्पष्ट "नहीं" चाहिए। असमानता पर ध्यान दीजिए: फ़ाइल डिलीट होते ही retention का जोखिम ख़त्म हो जाता है, पर training उपयोग अपरिवर्तनीय है। Weights किसी तस्वीर को भूल नहीं सकते।

डेटा-संरक्षण क़ानून के तहत इसका क्या मतलब है

GDPR और उसके समकक्ष व्यवस्थाओं के तहत intimate इमेजरी को सबसे कड़ा व्यवहार मिलता है, और दो सिद्धांत तुरंत लागू होते हैं। Storage limitation का अर्थ है व्यक्तिगत डेटा को उद्देश्य से ज़्यादा समय न रखना — और यहाँ उद्देश्य एक नतीजा पहुँचाना है, जो पहुँचते ही समाप्त हो जाता है। Data minimisation का अर्थ है जो चाहिए ही नहीं उसे इकट्ठा न करना।

इस संदर्भ में छोटी retention केवल एक अच्छी विशेषता नहीं है। यह वह तंत्र है जिससे कई दायित्व आसान हो जाते हैं: डेटा पहले ही मिट चुका हो तो deletion request मामूली बात है, और जो कभी रखा ही नहीं गया उसे कोई breach उजागर नहीं कर सकता।

इंटीग्रेट करने से पहले पूछने लायक़ सवाल

1. Inputs और outputs के लिए सटीक retention अवधि क्या है, समय की इकाइयों में?
2. वह किन प्रतियों को कवर करती है — caches, backups, logs, intermediate फ़ाइलें?
3. क्या सामग्री किसी भी परिस्थिति में training या evaluation के लिए इस्तेमाल होती है?
4. वेंडर के भीतर संग्रहीत इमेजरी तक कौन पहुँच सकता है, और क्या वह पहुँच लॉग होती है?
5. अगर कल कोई यूज़र consent वापस ले ले तो deletion का रास्ता क्या है?

जो वेंडर इनके साफ़ जवाब देता है, उसने समस्या पर सोचा है। जो विशेषणों में जवाब देता है, उसने नहीं सोचा — और जब आपका कोई यूज़र पहली बार यही सवाल पूछेगा, वह खाई आपको विरासत में मिलेगी।

अक्सर पूछे जाने वाले सवाल