EU AI Act کے تحت ‘تعمیری مرحلے’ (build-phase) کی ذمہ داریاں کسی قانونی میمو کی تحریر سے بہت پہلے ہی انجینئرنگ کے کام کی شکل اختیار کر لیتی ہیں۔ یہ کورس فراہم کنندہ کی ذمہ داریوں پر مرکوز ہے—یعنی ان فرائض پر جو AI سسٹم کو جاری (ship) کرنے والی ٹیم پر عائد ہوتے ہیں—کیونکہ انجینئرز اور ڈیٹا سائنسدان ہی زیادہ تر وہ شواہد تیار کرتے ہیں جن پر ان ذمہ داریوں کا انحصار ہوتا ہے۔ ٹیمیں اکثر اس پہلو کو نظر انداز کر دیتی ہیں کیونکہ انہیں یہ کام محض ‘فیچرز’ (خصوصیات) بنانے جیسا محسوس ہوتا ہے، جبکہ بعد میں کامیابی یا ناکامی کا دارومدار اس بات پر ہوتا ہے کہ کیا ریکارڈ کیا گیا، کیا ٹیسٹ کیا گیا، اور مختلف ورژنز (versions) کے درمیان کس حد تک یکسانیت برقرار رکھی گئی۔ عام ناکامی کی وجہ بدنیتی نہیں ہوتی، بلکہ یہ اس سسٹم کے اصل کام اور اس بات کے درمیان فرق (خلا) ہوتا ہے جسے ٹیم ثابت کر سکتی ہے کہ سسٹم انجام دے رہا ہے۔
فراہم کنندہ کسی ریلیز کا دفاع تبھی کر سکتا ہے جب تعمیر (build) کی شکل شروع ہی سے واضح ہو۔ اس شکل کا آغاز اس بات سے ہوتا ہے کہ کون سا سسٹم بنایا جا رہا ہے، اس کا مقصد کیا ہے، اور وہ حقیقی ماحول میں—جہاں اسے چلنا ہے—کیا کر سکتا ہے اور کیا نہیں۔ اس میں یہ بھی شامل ہے کہ کون سا ڈیٹا استعمال کیا گیا، اس کے ساتھ کون سے کنٹرولز فراہم کیے گئے، کون سے لاگز (logs) موجود ہیں، اور جب آؤٹ پٹ غلط لگے تو انسان کیا کر سکتا ہے۔ ان تمام پہلوؤں کو یکجا دیکھنا اس لیے اہم ہے کیونکہ کسی کمی یا غائب حصے کا پتہ عام طور پر تب چلتا ہے جب ٹیم سسٹم کی ٹریننگ، انٹیگریشن اور ڈیپلائمنٹ (تنصیب) مکمل کر چکی ہوتی ہے۔ نیچے دیا گیا نقشہ کسی بھی ایک حصے کی تعلیم سے قبل پورے منظرنامے (territory) کا احاطہ کرتا ہے۔
اس کورس میں، AI سسٹم محض ایک ماڈل فائل یا کوئی ہوشیار ‘پرامپٹ’ (prompt) نہیں ہے۔ یہ ایک مکمل نظام ہے جو کام کی جگہ کے کسی عمل سے ان پٹ (inputs) لیتا ہے، ایسے نتائج (outputs) فراہم کرتا ہے جن پر لوگ انحصار کرتے ہیں، اور اس کا رویہ کوڈ، ڈیٹا، کنفیگریشن اور ارد گرد موجود انٹرفیس کے ذریعے تشکیل پاتا ہے۔ یہی وجہ ہے کہ پائپ لائن میں ہونے والی ایک معمولی تبدیلی بھی سسٹم کے حقیقی دنیا پر اثرات کو بدل سکتی ہے، چاہے ماڈل کے ‘ویٹس’ (weights) وہی رہیں۔
کوئی ٹیم یہ سوچ سکتی ہے کہ یہ “صرف ایک ماڈل کو ضم (integrate) کرنے” کا معاملہ ہے، لیکن اصل میں وہ ‘منظم یا ریگولیٹڈ شے’ (regulated object) وہ مکمل سسٹم ہوتا ہے جو فیصلے، سفارشات یا تیار کردہ مواد کو ورک فلو کا حصہ بناتا ہے۔ ٹریننگ جاب، فیچر اسٹور، ریٹریول انڈیکس، گارڈ ریلز (guardrails)، نگرانی کے اصول اور UI کا متن (copy) مل کر یہ طے کرتے ہیں کہ صارف کو کیا نظر آئے گا اور اسے آگے کیا کرنے کی اجازت ہوگی۔ اگر ان حصوں کو کسی مخصوص ورژن اور مقصد کے ساتھ منسلک نہ کیا جائے، تو بعد میں کی جانے والی ٹیسٹنگ اور دستاویزات (documentation) اس چیز سے مطابقت نہیں رکھیں گی جو درحقیقت جاری (ship) کی گئی تھی۔
سسٹم کے مطلوبہ مقصد، ان پٹ اور حدود کا تعین کرنے والے فیصلوں کی ذمہ داری عام طور پر انجینئرز اور ڈیٹا سائنٹسٹس پر ہوتی ہے، کیونکہ یہ فیصلے ٹکٹس، ڈیٹا سیٹس، جانچ کے منصوبوں اور کوڈ کے جائزوں (code reviews) کے دوران کیے جاتے ہیں۔ قانونی اور تعمیلی (compliance) ٹیمیں قانون کی تشریح تو کر سکتی ہیں، لیکن وہ یہ دوبارہ تشکیل نہیں دے سکتیں کہ ماڈل نے ٹریننگ کے دوران کیا دیکھا تھا یا فیصلے کے وقت UI نے کس چیز کی اجازت دی تھی۔ پروڈکٹ ٹیم اہداف تو مقرر کر سکتی ہے، لیکن وہ غائب شدہ ‘لاگز’ (logs) کی جگہ نہیں لے سکتی یا کسی ایسے تجربے کو دوبارہ نہیں چلا سکتی جس کا ریکارڈ (track) نہ رکھا گیا ہو۔
سسٹم کو تعینات (deploy) کرنے والوں کے حوالے کرنے کا عمل بھی تعمیراتی مرحلے ہی سے شروع ہو جاتا ہے۔ تعینات کرنے والوں کو واضح ہدایات، انٹرفیس میں قابلِ استعمال شفافیت، اور نگرانی کے ایسے ذرائع درکار ہوتے ہیں جو دباؤ کے عالم میں بھی کام کر سکیں؛ کیونکہ پالیسی کی کوئی PDF فائل ایسے سسٹم کی کمی پوری نہیں کر سکتی جو اپنی غیر یقینی صورتحال کو چھپاتا ہو یا مداخلت کی راہ میں رکاوٹ بنتا ہو۔ جب تعمیر کرنے والے ان امور کو محض “بعد کا کاغذی کام” سمجھتے ہیں، تو اکثر انہیں انٹرفیس میں عارضی اصلاحات (patching) کرنی پڑتی ہیں اور دستاویزات کو حقیقت کے مطابق دوبارہ لکھنا پڑتا ہے، جو کہ اسے ایک ہی بار درست طریقے سے ڈیزائن کرنے کے مقابلے میں زیادہ سست عمل ہے۔
مزید آگے بڑھنے سے پہلے، یہ دیکھنا مفید ہے کہ ناکامی کی کون سی صورتیں (failure modes) پہلے سے معلوم ہیں۔