अगर आपका संगठन ऑनलाइन टेक्स्ट, इमेज या कोई अन्य कंटेंट प्रकाशित करता है, तो संभवत आपकी पहले से ही यह राय होगी कि क्या AI कंपनियों को इसे अपने मॉडल ट्रेनिंग के लिए इस्तेमाल करने की अनुमति दी जानी चाहिए। 2019 से, EU कानून राइटहोल्डर्स को इनकार करने का एक औपचारिक तरीका देता है: DSM डायरेक्टिव के आर्टिकल 4 के तहत टेक्स्ट और डेटा माइनिंग ऑप्ट-आउट। जिन पब्लिशर्स ने इसे सेट किया है, उनमें से ज्यादातर यह मानते हैं कि robots.txt की एक लाइन या साइट पर लाइव TDMRep टैग आ जाने से काम पूरा हो गया। यह आसान हिस्सा है। मुश्किल हिस्सा, जो वास्तव में यह तय करता है कि विवाद की स्थिति में ऑप्ट-आउट टिकता है या नहीं, यह साबित करना है कि यह कब लाइव था और उसमें क्या लिखा था।
आर्टिकल 4 वास्तव में क्या देता है
DSM डायरेक्टिव का आर्टिकल 4 एक ऐसा अपवाद बनाता है जो टेक्स्ट और डेटा माइनिंग के उद्देश्य से कानूनी रूप से सुलभ कृतियों के पुनरुत्पादन और निष्कर्षण की अनुमति देता है, और ज्यादातर मामलों में लाइसेंस की जरूरत नहीं होती। इसके बाद आर्टिकल 4(3) वह सीमा तय करता है जो राइटहोल्डर्स के लिए मायने रखती है: यह अपवाद तभी लागू होता है जब राइटहोल्डर ने अपने अधिकार स्पष्ट रूप से आरक्षित न किए हों। ऑनलाइन सार्वजनिक रूप से उपलब्ध कंटेंट के लिए, यह आरक्षण "उचित तरीके से, जैसे मशीन-रीडेबल माध्यमों से" व्यक्त किया जाना चाहिए। सीधे शब्दों में, किसी पेज पर कहीं लिखा एक नोटिस पर्याप्त नहीं है। यह आरक्षण उन क्रॉलर्स और पाइपलाइनों के लिए पठनीय होना चाहिए जो वास्तव में माइनिंग करते हैं, यही वजह है कि ज्यादातर इम्प्लीमेंटेशन robots.txt निर्देश, HTML मेटा टैग, या खासतौर पर इसी उद्देश्य के लिए बने TDM रिजर्वेशन प्रोटोकॉल (TDMRep) पर निर्भर करते हैं।
यह सिग्नल सेट करना एक बार का तकनीकी काम है। इसका प्रमाण सुरक्षित रखना ऐसा नहीं है, और यहीं पर ज्यादातर राइटहोल्डर्स रुक जाते हैं।
ऑप्ट-आउट में अब असली दम क्यों है, और इससे दांव क्यों बढ़ जाते हैं
कुछ सालों तक, आर्टिकल 4(3) ज्यादातर एक सैद्धांतिक सुरक्षा बनकर रह गया था। EU AI Act के आने से यह बदल गया। EU बाजार में उतारे गए जनरल-पर्पज AI मॉडल के प्रोवाइडर अब AI Act के आर्टिकल 53 के तहत एक सीधे दायित्व के अधीन हैं, जिसमें उन्हें EU कॉपीराइट कानून के पालन के लिए एक नीति बनानी होती है, और खासतौर पर DSM डायरेक्टिव के आर्टिकल 4(3) के तहत व्यक्त किए गए अधिकार-आरक्षणों की पहचान करनी और उनका पालन करना होता है। यह दायित्व इस बात से स्वतंत्र है कि मॉडल प्रोवाइडर कहां स्थापित है या असल ट्रेनिंग कहां हुई, बशर्ते मॉडल EU बाजार में उतारा गया हो।
इससे ऑप्ट-आउट एक निष्क्रिय कानूनी स्थिति से बदलकर ऐसी चीज बन जाता है जिसे अब दोनों पक्षों को सक्रिय रूप से संभालना होता है। एक मॉडल प्रोवाइडर को यह दिखाना होता है कि उसने आरक्षण की जांच की और उसका पालन किया। आपको, एक राइटहोल्डर के रूप में, यह साबित करने की जरूरत पड़ सकती है कि ट्रेनिंग के लिए कंटेंट इकट्ठा किए जाने से पहले सही रूप में आरक्षण मौजूद था। ये दोनों सवाल एक निश्चित समय-बिंदु के बारे में हैं, आपकी साइट की मौजूदा स्थिति के बारे में नहीं। एक robots.txt फाइल हमेशा सिर्फ यह दिखाती है कि आज उसमें क्या है। यह इस बारे में कुछ नहीं बताती कि छह महीने पहले उसमें क्या था, जब शायद कोई खास क्रॉल हुआ हो।
सबूत की कमी वास्तव में कहां असर डालती है
शुरुआती सेटअप से आगे देखने पर तीन स्थितियां बार-बार सामने आती हैं:
- साइट रीडिजाइन या CMS माइग्रेशन robots.txt फाइल को ओवरराइट कर देता है, और पुराना ऑप्ट-आउट निर्देश बिना किसी स्थानीय निशान के गायब हो जाता है कि वह कब हटाया गया या मूल रूप से उसमें क्या लिखा था।
- कोई विवाद समय को लेकर होता है। एक मॉडल प्रोवाइडर दावा करता है कि ट्रेनिंग रन आपके आरक्षण से पहले हुआ था; आप मानते हैं कि ऐसा नहीं है। आपके ऑप्ट-आउट सिग्नल के तारीखयुक्त स्नैपशॉट के बिना, यह इस बात का मामला बन जाता है कि कौन ज्यादा भरोसेमंद लगता है, न कि क्या साबित किया जा सकता है।
- ऑप्ट-आउट समय के साथ बदलता है, उदाहरण के लिए एक व्यापक robots.txt disallow से एक ज्यादा सूक्ष्म TDMRep नीति की ओर, जो AI ट्रेनिंग के लिए अधिकार आरक्षित रखते हुए सर्च इंडेक्सिंग की अनुमति देती रहती है। अगर दो वर्ज़न के बीच कोई क्रॉल हुआ, तो केवल तारीखयुक्त वर्ज़न हिस्ट्री ही बताती है कि उस समय वास्तव में कौन-सी नीति लागू थी।
इनमें से कोई भी स्थिति काल्पनिक नहीं है। ये किसी लाइव वेबसाइट को कुछ महीनों से ज्यादा चलाने के सामान्य परिणाम हैं। एक मशीन-रीडेबल ऑप्ट-आउट "क्या कोई मशीन इसे पढ़ सकती है" वाली समस्या हल करता है। यह "क्या आप साबित कर सकते हैं कि यह किसी खास तारीख पर सच था" वाली समस्या के लिए कुछ नहीं करता, और यही दूसरा सवाल है जो असल में विवाद को तय करता है।
तारीखयुक्त रिकॉर्ड में क्या होना चाहिए
एक बचाव योग्य ऑप्ट-आउट रिकॉर्ड के लिए तीन चीजें चाहिए जो एक लाइव robots.txt फाइल अकेले नहीं दे सकती: प्रकाशित की गई सही फाइल या टैग का स्नैपशॉट, ऐसे स्रोत से टाइमस्टैम्प जिसे आप खुद नियंत्रित नहीं करते, और किसी तीसरे पक्ष के लिए, यहां तक कि EU के बाहर भी, बिना आपकी बात पर भरोसा किए दोनों की पुष्टि करने का एक तरीका। हर बार जब आप प्रकाशित या अपडेट करते हैं तो अपने robots.txt, TDMRep घोषणा, या HTML मेटा टैग के तारीखयुक्त हैश को सील करने से यह रिकॉर्ड धीरे-धीरे बनता है, ठीक उसी क्षण जब हर वर्ज़न लाइव होता है, न कि बाद में जब उसे फिर से बनाना बहुत देर हो चुकी होती है।
यहीं पर अंतर्निहित सबूत का मूल्य EU के बाहर भी मायने रखता है। ट्रेनिंग डेटा को लेकर विवाद या किसी मॉडल प्रोवाइडर के साथ लाइसेंसिंग बातचीत हमेशा किसी EU अथॉरिटी के सामने नहीं होगी। यह किसी US-आधारित AI लैब की लीगल टीम, किसी अंतरराष्ट्रीय आर्बिट्रेशन पैनल, या ऐसी न्यायिक क्षेत्र की अदालत में जा सकता है जिसने DSM डायरेक्टिव के बारे में कभी सुना ही नहीं। ऐसा सबूत जिसकी पूरी ताकत "हमारे सर्वर लॉग्स पर भरोसा करें" पर टिकी हो, उस बातचीत में ज्यादा दूर तक नहीं टिकता। एक क्वालिफाइड, स्वतंत्र रूप से तारीखयुक्त रिकॉर्ड टिकता है, क्योंकि उसकी साक्ष्य के तौर पर वैल्यू इस बात पर निर्भर नहीं करती कि कौन-सी न्यायिक क्षेत्र पूछ रहा है। यही तर्क किसी भी ऐसे डॉक्यूमेंट पर लागू होता है जिसे आपको उस देश के बाहर बचाव करने की जरूरत पड़ सकती है जहां आपने उसे बनाया था: ऐसा सबूत जो वैश्विक स्तर पर टिकता है, उस सबूत से ज्यादा मूल्यवान है जो सिर्फ घर पर काम करता है।
रिकॉर्ड में क्या रखना चाहिए
एक उपयोगी सील किए गए स्नैपशॉट का जटिल होना जरूरी नहीं है। कम से कम robots.txt निर्देश या TDMRep घोषणा का पूरा टेक्स्ट ठीक वैसे रखें जैसे वह प्रकाशित हुआ था, वह URL या सबडोमेन जिस पर वह लागू होता था, और वह तारीख जब यह लाइव हुआ। कई प्रॉपर्टीज़, क्षेत्रीय सबडोमेन, या एक ही साइट के कई भाषा वर्ज़न चलाने वाले बड़े संगठनों को हर एक को अलग-अलग सील करना चाहिए, क्योंकि एक डोमेन पर सेट किया गया आरक्षण अपने आप दूसरे डोमेन तक नहीं फैलता, और जिस क्रॉलर ने किसी सबडोमेन की नीति को नजरअंदाज किया, उसे केवल मुख्य साइट पर मौजूद आरक्षण से माफी नहीं मिलेगी। अगर किसी ऑडिट या लाइसेंसिंग बातचीत के दौरान आपकी लीगल या कंप्लायंस टीम को सबूत पेश करने के लिए कहा जाता है, तो हर प्रॉपर्टी के लिए एक तारीखयुक्त फाइल होना कैश्ड पेजों और अंदाजों से इतिहास फिर से बनाने से बेहतर है।
ऑप्ट-आउट को बदलने या हटाने के बाद भी रिकॉर्ड रखना उचित है। अगर आप बाद में अपने कंटेंट को ब्लॉक करने के बजाय AI ट्रेनिंग के लिए लाइसेंस देने का फैसला करते हैं, तो एक तारीखयुक्त इतिहास जो ठीक-ठीक दिखाता है कि आरक्षण कब वापस लिया गया, आपको उल्टी समस्या से बचाता है: यह दावा कि आप अभी भी ऑप्ट-आउट थे जबकि असल में आपने पहले ही अनुमति दे दी थी।
इसे एक सामान्य पब्लिशिंग आदत बनाना
व्यावहारिक समाधान उतना बड़ा नहीं है जितना लगता है। अपने TDM ऑप्ट-आउट सिग्नल के साथ वैसा ही व्यवहार करें जैसा आप किसी कॉन्ट्रैक्ट या तारीखयुक्त डिज़ाइन फाइल के साथ करते हैं: जब यह बदले तब इसे सील करें, सील किए गए रिकॉर्ड को लाइव साइट से अलग रखें, और यह प्रक्रिया हर बार दोहराएं जब नीति अपडेट हो, न कि सिर्फ लॉन्च के समय एक बार। जो संगठन अपने कंटेंट के साथ डेटासेट, मॉडल डॉक्यूमेंटेशन, या लाइसेंसिंग शर्तें प्रकाशित करते हैं, उनके लिए वही अनुशासन उस सामग्री पर भी लागू होता है। हमारा AI ट्रेनिंग-डेटा प्रोवेनेंस डॉक्यूमेंटेशन वाला पेज बताता है कि पूरे डेटासेट लाइफसाइकल में तारीखयुक्त, सत्यापन योग्य रिकॉर्ड कैसे बनाया जाए, न कि सिर्फ इसके किनारे पर मौजूद ऑप्ट-आउट सिग्नल के लिए।
आर्टिकल 4(3) आपको अपने कंटेंट को आरक्षित रखने का अधिकार देता है। यह आपको यह सबूत नहीं देता कि आपने किसी खास समय पर उस अधिकार का इस्तेमाल किया था। जरूरत पड़ने से पहले खुद तारीखयुक्त रिकॉर्ड बनाएं, तभी ऑप्ट-आउट वाकई वही मतलब रखेगा जो वह कहता है।
अपने TDM ऑप्ट-आउट सिग्नल और डेटासेट रिकॉर्ड को तारीखयुक्त, स्वतंत्र रूप से सत्यापन योग्य टाइमस्टैम्प के साथ सील करना शुरू करें, ताकि किसी विवाद के आपको इसे फिर से बनाने पर मजबूर करने से पहले ही सबूत तैयार हो।
