اگر آپ کا ادارہ آن لائن متن، تصاویر یا کوئی اور مواد شائع کرتا ہے، تو غالباً آپ کی پہلے ہی یہ رائے ہوگی کہ آیا 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 آپٹ آؤٹ سگنلز اور ڈیٹاسیٹ ریکارڈز کو تاریخ والے، آزادانہ طور پر قابل تصدیق ٹائم اسٹیمپ کے ساتھ سیل کرنا شروع کریں، تاکہ کسی تنازع کے آپ کو اسے دوبارہ بنانے پر مجبور کرنے سے پہلے ہی ثبوت تیار ہو۔
