वह OCR मॉडल जो न पढ़ पाने पर आपकी जन्मतिथि का अंदाज़ा लगा लेता है

किसी फ़िनटेक स्टार्टअप की KYC पाइपलाइन की कल्पना कीजिए। एक यूज़र अपने ड्राइविंग लाइसेंस की फ़ोटो अपलोड करता है, लेकिन जन्मतिथि पर उसका अंगूठा आ गया है और जारी होने की तारीख (issue date) वाला कोना कैमरे से कट गया है। फ़ील्ड्स एक्सट्रैक्ट कर रहा document-AI मॉडल कोई एरर नहीं देता। वह बस ऐसे नंबरों से उन्हें भर देता है जो देखने में पूरी तरह विश्वसनीय लगते हैं।

चिंता की बात यह है: कभी-कभी वे नंबर सही होते हैं। "सही" का मतलब कोई "अच्छा अंदाज़ा" नहीं। सही इस मायने में कि मॉडल किसी तरह उस असली जन्मतिथि तक पहुँच गया जो उसने कभी देखी ही नहीं थी। चीन और भारत के संस्थानों के शोधकर्ताओं का एक नया पेपर, जिसे ACM Multimedia 2026 में स्वीकार किया गया है, इसकी वजह समझाता है: जब कोई document-understanding मॉडल किसी फ़ील्ड को पढ़ नहीं पाता, तो वह ज़रूरी नहीं कि "I don't know" कहे। इसके बजाय, वह इस बात का सहारा लेता है कि ट्रेनिंग वाले दस्तावेज़ों में कौन-से फ़ील्ड्स अक्सर एक साथ आते थे, और उस खाली जगह को एक ऐसे निष्कर्ष (inference) से भर देता है जो ट्रेनिंग उदाहरणों से असली व्यक्तिगत डेटा लीक कर सकता है।

इस पेपर का शीर्षक है "Beyond Visual Evidence: Revealing and Mitigating Relational Privacy Leakage in Document MLLMs," और इसका सीधा निशाना टूल्स की उस श्रेणी पर है जो चुपचाप इंफ़्रास्ट्रक्चर बनती जा रही है: मल्टीमॉडल लार्ज लैंग्वेज मॉडल्स (MLLMs, यानी ऐसे मॉडल्स जो इमेज और टेक्स्ट दोनों को प्रोसेस करते हैं), जिन्हें पासपोर्ट, ID कार्ड और ड्राइविंग लाइसेंस जैसे पहचान दस्तावेज़ों को पढ़ने और उनमें से स्ट्रक्चर्ड फ़ील्ड्स निकालने के लिए फ़ाइन-ट्यून किया जाता है। document-AI की दुनिया में इस टास्क का एक नाम है: Key Information Extraction, या KIE। मॉडल को एक फ़ोटो दीजिए, और बदले में नाम, पता, जन्मतिथि, ID नंबर वगैरह का साफ़-सुथरा JSON पाइए। यह कई ऑनबोर्डिंग फ़्लो की रीढ़ है, और यही वह चीज़ है जहाँ OCR वेंडर्स एक्यूरेसी के लिए एक-दूसरे से मुकाबला करते हैं।

मॉडल इमेज पढ़ नहीं रहा, वह पैटर्न याद कर रहा है

ज्यादातर लोग मानते हैं कि OCR या document-AI के फ़ेल होने का मतलब कचरा (garbage) आउटपुट होता है: बदले हुए अंक, बिगड़े हुए अक्षर, या कोई खाली छूटा हुआ फ़ील्ड। यह वह फ़ेलियर मोड है जिसकी हर कोई टेस्टिंग करता है। लेकिन यह पेपर एक अलग विफलता के बारे में है, जहाँ आउटपुट बिल्कुल सही दिखता है पर कहीं ज़्यादा खतरनाक तरीके से गलत होता है।

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

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

इस बात पर एक पल के लिए विचार कीजिए: यह उस जानकारी का प्राइवेसी लीक है जो वर्तमान इमेज में मॉडल को कभी दिखाई ही नहीं गई थी। यह ट्रेनिंग के दौरान किसी अन्य व्यक्ति के दस्तावेज़ से याद की गई जानकारी को लीक कर रहा है, जो अभी सामने रखे दस्तावेज़ के सह-संबंधित (correlated) फ़ील्ड्स के आंशिक मिलान से ट्रिगर हो गई। यह "मॉडल ने कुछ ऐसा पढ़ लिया जो उसे नहीं पढ़ना चाहिए था" की तुलना में बिल्कुल अलग थ्रेट मॉडल (threat model) है। यह टेक्स्ट LLMs से जुड़ी उन मेंबरशिप-इन्फ़रेंस (membership-inference) और ट्रेनिंग-डेटा-एक्सट्रैक्शन हमलों के करीब है जिनकी लोग चिंता करते हैं, फर्क सिर्फ इतना है कि यहाँ यह सब सामान्य उपयोग के दौरान अनजाने में हो रहा है, बिना किसी के मॉडल पर हमला किए।

एक ऐसे बग के लिए बेंचमार्क तैयार करना जो केवल ढूँढने पर ही सामने आता है

जिस चीज़ को आप माप नहीं सकते, उसे ठीक भी नहीं कर सकते। और यहाँ पेचीदा बात यह है कि यह फ़ेलियर मोड सामान्य दिखने वाले एक्यूरेसी आंकड़ों के पीछे छिप जाता है। यदि कोई मॉडल साफ़-सुथरे, पूरी तरह दिखाई देने वाले दस्तावेज़ों का उपयोग करने वाले KIE बेंचमार्क पर 96% सटीक है, तो वह संख्या आपको इस बारे में लगभग कुछ नहीं बताती कि इमेज के खराब (degraded) होने पर वह क्या करता है। ऐसा इसलिए क्योंकि खराब स्थितियाँ ही वे हालात हैं जहाँ मॉडल पढ़ने के बजाय अंदाज़ा लगाने लगता है।

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

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

DRUF: मॉडल को सब कुछ भूलने के बजाय विशिष्ट संबंध भूलना सिखाना

इसका सीधा समाधान, यानी "मॉडल से ट्रेनिंग डेटा भुलवा देना", एक बहुत ही सतही और अनगढ़ तरीका (blunt instrument) है। यहीं पर मशीन अनलर्निंग (machine unlearning) का साहित्य काम आता है: ऐसी तकनीकों का एक समूह जो मॉडल को शुरुआत से फिर से ट्रेन किए बिना, उसमें से विशिष्ट ट्रेनिंग उदाहरणों या व्यवहारों के प्रभाव को बाद में हटाने का काम करता है। मौजूदा अनलर्निंग के अधिकांश तरीकों के साथ समस्या यह है—और पेपर बेसलाइन के रूप में इनमें से छह का परीक्षण करता है—कि वे ज़रूरत से ज़्यादा व्यापक होते हैं। किसी मॉडल पर नाम और पते के संबंध को लीक करने से रोकने के लिए बहुत अधिक दबाव डालें, तो आप अक्सर उसकी KIE करने की पूरी क्षमता को ही गिरा देते हैं; उन फ़ील्ड्स पर भी जहाँ उसे आंशिक विज़ुअल सबूतों से समझदारी भरा अनुमान लगाना चाहिए, जैसे कि किसी हल्के से धुंधले अंक को फिर से पहचानना जिसका अधिकांश हिस्सा वह वास्तव में देख सकता है।

लेखकों का समाधान Dynamic Relational Unlearning Framework (DRUF) है, जो यह चुनने में बेहद सटीक और सर्जिकल होने की कोशिश करता है कि क्या हटाया जाए। इसके दो हिस्से यह काम करते हैं। Relational Decoupling Unlearning मॉड्यूल विशिष्ट हाई-रिस्क वाले फ़ील्ड पेयर्स को टारगेट करता है—वे पेयर्स जिन्हें बेंचमार्क सह-संबंधित लीकेज के लिए सबसे अधिक संवेदनशील दिखाता है—बजाय इसके कि वह मॉडल के सामान्य दुनिया के ज्ञान या दस्तावेज़ पढ़ने की उसकी क्षमता को मिटाने की कोशिश करे। डायनेमिक सेट अपडेट मैकेनिज़्म वह हिस्सा है जो इसे केवल एक बार का समाधान (one-shot fix) बनने से रोकता है: जैसे-जैसे ट्रेनिंग आगे बढ़ती है, यह ट्रैक करता है कि कौन-से फ़ील्ड-पेयर संबंध अभी भी जोखिम भरे हैं और अनलर्न किए जा रहे सेट को उसी अनुसार समायोजित करता है, बजाय शुरुआत में ही एक निश्चित सूची तय कर लेने के, जो नए लीकेज पैटर्न से चूक सकती है या उन पर ज़रूरत से ज़्यादा सुधार कर सकती है जो कभी समस्या थे ही नहीं।

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

आंकड़े क्या कहते हैं, और क्या नहीं

मुख्य परिणाम: DRUF लीकेज रोकने (leakage suppression) के मामले में छह बेसलाइन अनलर्निंग तरीकों में से सबसे मजबूत तरीके को 4.8 प्रतिशत अंकों से मात देता है, जबकि पेपर के अनुसार यह इस प्रक्रिया में KIE प्रदर्शन को भी बनाए रखता है। इसका मतलब है कि मॉडल उन फ़ील्ड्स को एक्सट्रैक्ट करने के अपने वास्तविक काम में कमज़ोर नहीं पड़ता जिन्हें वह वैध रूप से पढ़ सकता है। यही इसका मुख्य दावा है: सामान्य यूटिलिटी टैक्स चुकाए बिना बेहतर प्राइवेसी सुरक्षा।

मैं 4.8-अंकों के इस आंकड़े को समस्या का पूरी तरह हल होने के बजाय एक वास्तविक और उपयोगी सुधार मानूँगा। यह उसी टीम द्वारा डिज़ाइन किए गए बेंचमार्क पर सर्वोत्तम मौजूदा बेसलाइन की तुलना में एक बढ़त (delta) है। इस प्रकार के पेपर में यह एक मानक तरीका है, लेकिन इसका यह भी अर्थ है कि यह अभी भी एक अपूर्ण शुरुआती बिंदु के सापेक्ष प्रगति को माप रहा है, न कि किसी ऐसी पूर्ण लीकेज दर को जो अब शून्य के करीब पहुँच गई हो। सार (abstract) स्वयं कहता है कि इस क्षेत्र में इन उपायों को लागू करने के बाद भी मॉडल्स "लगातार प्राइवेसी लीकेज प्रदर्शित करते हैं" (consistently exhibit privacy leakage)। किसी समस्या को लगभग पाँच अंक कम करना सराहनीय काम है। लेकिन यह समस्या को पूरी तरह समाप्त करने के बराबर नहीं है, और पेपर भी ऐसा कोई दावा नहीं करता।

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

पहचान दस्तावेज़ों के लिए OCR बनाते या चुनते समय यह क्यों मायने रखता है

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

कुछ ठोस निष्कर्ष:

• असली, अधूरी या खराब अपलोड्स के संदर्भ में किसी वेंडर के विज्ञापित एक्यूरेसी नंबर पर आँख मूँदकर भरोसा न करें। विशेष रूप से यह पूछें कि जब कोई फ़ील्ड आंशिक रूप से ढका हो, कम रेज़ोल्यूशन का हो, या कट गया हो, तो सिस्टम कैसा व्यवहार करता है। एक आश्वस्त गलत उत्तर किसी "अपठनीय" (unreadable) फ़्लैग किए गए फ़ील्ड से कहीं अधिक खतरनाक होता है, खासकर तब जब वह KYC या कंप्लायंस से जुड़े किसी निर्णय का आधार बन रहा हो।
• यदि आप कस्टमर डेटा पर अपने स्वयं के डॉक्यूमेंट मॉडल को फ़ाइन-ट्यून कर रहे हैं, तो यह इस बात की चेतावनी है कि असली पहचान दस्तावेज़ों पर फ़ाइन-ट्यूनिंग ठीक वैसी ही कोरिलेटेड-फ़ील्ड (सह-संबंधित फ़ील्ड्स) स्थितियाँ पैदा करती है जिनका इस पेपर में अध्ययन किया गया है। यदि आपके ट्रेनिंग सेट में असली लोगों के दस्तावेज़ शामिल हैं, तो यह जोखिम कतई काल्पनिक नहीं है।
• वेंडर्स से इस बात पर जवाब मांगें कि क्या उन्होंने खराब साक्ष्यों (degraded-evidence) वाले परिदृश्यों का परीक्षण किया भी है या नहीं, और "हमें अपने बेंचमार्क पर 96% सटीकता मिलती है" को तब तक अधूरा उत्तर मानें जब तक आप यह न जान लें कि उस बेंचमार्क की तस्वीरें कैसी हैं। साफ़-सुथरे, अच्छी रोशनी वाले और पूरी तरह दिखने वाले टेस्ट दस्तावेज़ आपको यह नहीं बताते कि यूज़र्स से मिलने वाले खराब अपलोड्स पर मॉडल क्या करेगा।
• यदि कोई मॉडल किसी फ़ील्ड की वैल्यू लौटाता है, तो पूछें कि क्या वह कॉन्फ़िडेंस (आत्मविश्वास) या साक्ष्य की गुणवत्ता का कोई पैमाना भी उपलब्ध कराता है। जो सिस्टम यह अंतर बता सके कि "मैंने इसे पढ़ा है" बनाम "मैंने इसका अनुमान लगाया है", वह किसी भी ऐसे सिस्टम की तुलना में ऑडिट और कंप्लायंस के नज़रिए से कहीं अधिक भरोसेमंद है जो यह परवाह किए बिना कि उसने वास्तव में कितना देखा, बस साफ़-सुथरा JSON लौटा देता है।

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

यहाँ मौजूद वास्तविक सीमाएँ

कुछ बातों को स्पष्ट रूप से रेखांकित करना ज़रूरी है। यह पेपर तीन MLLMs और छह अनलर्निंग बेसलाइन्स का मूल्यांकन करता है, जो किसी बेंचमार्क पेपर के लिए एक उचित दायरा है लेकिन फिर भी पूरे document-AI परिदृश्य का एक छोटा सा हिस्सा है; क्या यह बात हर कमर्शियल document-AI सिस्टम पर लागू होती है—जिनमें अलग आर्किटेक्चर या ट्रेनिंग पद्धतियाँ शामिल हैं—यह एक ऐसा खुला प्रश्न है जिसका उत्तर पेपर पूरी तरह नहीं देता और न ही दे सकता है। इसके अलावा DRUF को अनलर्निंग प्रक्रिया लागू करने के लिए मॉडल के इंटरनल्स (आंतरिक घटकों) तक पहुँच की आवश्यकता होती है, इसलिए यह उन लोगों के लिए एक समाधान है जो अपने खुद के मॉडल को ट्रेन या फ़ाइन-ट्यून कर रहे हैं, न कि ऐसी कोई चीज़ जिसे आप किसी क्लोज़्ड API पर ऊपर से जोड़ सकें।

एक संरचनात्मक द्वंद्व (structural tension) भी है जिसके बारे में पेपर ईमानदारी बरतता है लेकिन उसे पूरी तरह हल नहीं करता: "रिलेशनल कॉन्टेक्स्ट का उपयोग करके कमियों को भरना" ही तो वह खूबी है जो document AI को वास्तव में उपयोगी बनाती है। यदि किसी फ़ॉर्म का फ़ील्ड धुंधला है लेकिन आस-पास का संदर्भ सही वैल्यू को स्पष्ट कर देता है, तो आम तौर पर आप यही चाहेंगे कि मॉडल उसका सही अनुमान लगा ले। "मददगार प्रासंगिक अनुमान" (helpful contextual inference) और "प्राइवेसी लीक करने वाली रटंत याददाश्त" (privacy-leaking memorization) के बीच की रेखा बिल्कुल स्पष्ट नहीं है, और DRUF का लक्षित दृष्टिकोण उस बारीक रेखा पर चलने का एक प्रयास है, न कि यह प्रमाण कि समस्या पूरी तरह हल हो गई है।

फिर भी, यहाँ सबसे महत्वपूर्ण योगदान 4.8 अंकों की वह संख्या नहीं है। असली योगदान उस फ़ेलियर मोड को पहचानना और नाम देना है जो सबके सामने होते हुए भी छिपा हुआ था, और उसे वास्तव में मापने का एक तरीका तैयार करना है। पहचान दस्तावेज़ों पर काम करने वाले किसी भी व्यक्ति को अब अपने वेंडर्स से यह सवाल पूछना चाहिए, भले ही DRUF अंततः स्थायी समाधान बने या न बने।