یہ کورس خریداری سے قبل AI سسٹم کی جانچ پڑتال کے بارے میں ہے تاکہ اسے نافذ کرنے والا ادارہ (deployer) خریداری کا ایسا فیصلہ کر سکے جس کا بھرپور دفاع کیا جا سکے۔ اس کا بنیادی قانونی ڈھانچہ ‘EU AI Act’ پر مبنی ہے، اور اس میں خریداری (procurement) اور تعمیل (compliance) کے ذمہ داران کو ان لوگوں کے طور پر دیکھا جاتا ہے جنہیں یہ فیصلہ کرنا ہوتا ہے کہ کیا تقاضا کرنا ہے اور کس چیز سے انکار کرنا ہے۔ بہت سی ٹیمیں AI کی خریداری کو عام سافٹ ویئر کی خریداری کی طرح سمجھتی ہیں، جہاں ڈیمو اور سیکیورٹی کا جائزہ ہی مشکل ترین مرحلہ محسوس ہوتا ہے۔ درحقیقت مشکل کام یہ جانچنا ہے کہ استعمال کے دوران سسٹم کی کارکردگی کیسی رہتی ہے، کیونکہ پرامپٹس (prompts)، ڈیٹا اور سیاق و سباق (context) کے ساتھ اس کے نتائج (outputs) تبدیل ہو سکتے ہیں۔ یہ تبدیلی بظاہر نظر نہیں آتی کیونکہ وینڈر (فروخت کنندہ) اب بھی ایک بہترین اور ہموار ورک فلو دکھا سکتا ہے۔ خریدار کو بہرحال یہ فیصلہ کرنا ہوتا ہے کہ کون سے شواہد یا معلومات کافی ہیں۔
اس کورس میں AI سسٹم سے مراد ایسا سافٹ ویئر ہے جو ان پٹ (input) کی بنیاد پر ٹیکسٹ، اسکورز، سفارشات یا فیصلوں جیسے نتائج (outputs) تیار کرتا ہے، اور یہ نتائج لوگوں کے آئندہ کے اقدامات پر اثر انداز ہو سکتے ہیں۔ خریداری کے عمل میں یہ بات اس لیے اہم ہے کیونکہ ایک ہی فیچر (خصوصیت) کا اثر ایک استعمال میں کم اور دوسرے میں بہت زیادہ ہو سکتا ہے، جس کا انحصار اس بات پر ہے کہ نتائج کن لوگوں کو متاثر کرتے ہیں اور انہیں کس طرح استعمال کیا جاتا ہے۔ یہ کام پہلے سے ہی روزمرہ کے اقدامات، جیسے کہ سپلائر کے پیکج کا جائزہ لینا، استعمال کے طریقہ کار (use case) کی منظوری دینا، اور نفاذ (rollout) کے لیے شرائط طے کرنے کے دوران ہوتا رہتا ہے۔ معاملہ اس وقت مشکل ہو جاتا ہے جب خریداری کے حوالے سے سوال صرف یہ نہ ہو کہ “کیا یہ کام کرتا ہے؟” بلکہ یہ بھی ہو کہ “ہمارے مخصوص ماحول میں یہ کیا کچھ کر سکتا ہے جو ڈیمو میں نہیں دکھایا گیا تھا؟” پورے ورک فلو کو شروع ہی سے دیکھنا مددگار ثابت ہوتا ہے، کیونکہ ہر جانچ کا تعلق خریداری کے عمل کے کسی مخصوص مرحلے سے ہوتا ہے۔ یہاں اس ورک فلو کی ایک جھلک پیش کی گئی ہے۔
ایک عام سافٹ ویئر ٹول عام طور پر ایک ہی طرح کے ان پٹ (input) کے لیے ایک جیسا ہی کام کرتا ہے، لہذا آپ اسے ایک بار ٹیسٹ کر کے نتائج کو اپنی ضروریات کے مطابق حتمی شکل دے سکتے ہیں۔ اس کے برعکس، ایک AI سسٹم ‘اپ ٹائم’ (uptime) کے لحاظ سے تو مستقل مزاج ہو سکتا ہے لیکن مواد (content) کے اعتبار سے غیر مستقل ہو سکتا ہے، کیونکہ یہ طے شدہ اصولوں کی پیروی کرنے کے بجائے آؤٹ پٹ خود تخلیق کرتا ہے یا اخذ کرتا ہے۔ اس کا مطلب ہے کہ آپ مسلسل استعمال کے لیے صرف ایک ‘ایکسپٹنس ٹیسٹ’ (acceptance test) پر انحصار نہیں کر سکتے، چاہے وینڈر اسے ‘پروڈکشن کے لیے تیار’ (production ready) ہی کیوں نہ کہے۔ آپ کو جانچ پڑتال (evaluation) کا عمل اس مخصوص استعمال سے منسلک کرنا ہوگا جس کے لیے آپ اسے خرید رہے ہیں؛ اس میں یہ بات بھی شامل ہے کہ آؤٹ پٹ کو کون پڑھے گا اور اس کے نتیجے میں کیا کارروائی ہو سکتی ہے۔
خریداری کے عمل میں ایک عام غلطی (یا جال) یہ ہے کہ صرف ‘ماڈل’ کو ہی پروڈکٹ سمجھ لیا جائے، جبکہ اصل پروڈکٹ اس کے گرد موجود پورا نظام ہوتا ہے۔ اس نظام میں یوزر انٹرفیس، پرامپٹس (prompts)، آپ کی دستاویزات سے معلومات کا حصول، انٹیگریشنز (دیگر سسٹمز سے رابطہ)، اور انسانی جائزے کا مرحلہ شامل ہوتے ہیں۔ یہ حصے ہی طے کرتے ہیں کہ کون سا ڈیٹا کہاں منتقل ہوگا اور کیا چیز ریکارڈ کی جائے گی۔ یہی حصے یہ بھی طے کرتے ہیں کہ غلطیوں کو گاہک، امیدوار یا ملازم تک پہنچنے سے پہلے پکڑنا کتنا آسان یا مشکل ہوگا۔
بہترین جانچ پڑتال (due diligence) کرنے کے لیے ضروری نہیں کہ خریداری اور تعمیل (compliance) کے ذمہ دار افراد ‘ڈیلیوری’ (سسٹم کی فراہمی) کے بھی ذمہ دار ہوں۔ خریداری کا فیصلہ اور اس کے لیے طے کردہ شرائط آپ کے اختیار میں ہوتی ہیں؛ اس کا مطلب ہے کہ آپ معاہدے پر دستخط کرنے سے پہلے متعلقہ دستاویزات اور واضح جوابات کا مطالبہ کر سکتے ہیں۔ عام طور پر پروڈکٹ اور آئی ٹی (IT) کی ٹیمیں انٹیگریشن کی تفصیلات کی ذمہ دار ہوتی ہیں، جبکہ پرائیویسی ٹیم ڈیٹا کے تحفظ کے پہلو کو دیکھتی ہے، لیکن اس کے باوجود آپ ان میں سے ہر ایک سے کوئی ایک ٹھوس معلومات یا رائے طلب کر سکتے ہیں جو خریداری کے فیصلے کی تائید کرے۔ اہم بات یہ ہے کہ ایسے سوالات پوچھے جائیں جن کے نتیجے میں دستاویزات حاصل ہوں، نہ کہ صرف زبانی تسلی۔
کام کی تقسیم کا ایک مفید طریقہ یہ ہے کہ وینڈر کے دعووں، آپ کی اندرونی ٹیموں کی تصدیق، اور ٹرائل کے دوران آپ کے مشاہدات کو الگ الگ رکھا جائے۔ وینڈر کے دعوے عام طور پر ڈیٹا شیٹ، سیکیورٹی رپورٹ، یا استعمال کے طریقہ کار کی دستاویز جیسی چیزوں میں ملتے ہیں۔ اندرونی تصدیقات انٹیگریشن نوٹ، آپریٹنگ پروسیجر کے مسودے، یا رسک سائن آف (خطرات کی منظوری) جیسی چیزوں میں ہوتی ہیں۔ مشاہدات ٹیسٹ ریکارڈز، ‘ریڈ ٹیم’ (red-team) کے نوٹس، اور ان اسکرین شاٹس پر مبنی ہوتے ہیں جو یہ دکھاتے ہیں کہ سسٹم نے آپ کے پرامپٹس اور ڈیٹا کے ساتھ کیا کیا۔
اس جائزے کا فائدہ تبھی ہے اگر یہ آپ کی آئندہ کی توجہ کا مرکز تبدیل کرے۔ ایک ہی سسٹم ڈیمو میں محفوظ نظر آ سکتا ہے، لیکن جب آپ اس کے استعمال کے مخصوص مقصد (use case) اور متاثرہ افراد کا ذکر کرتے ہیں تو فوراً کوئی اہم تشویش یا سوال سامنے آ سکتا ہے۔ ہر حصے (snippet) میں اس پہلی تشویش کا انتخاب کریں جو آپ کے ذہن میں آئے، کیونکہ یہی وہ چیز ہے جو وینڈر سے کی جانے والی اگلی درخواست کی بنیاد بنتی ہے۔