سیکیورٹی انجینئرنگ، ڈیپلائمنٹ کے راستوں (deployment paths) کی سالمیت، API کے تحفظات، اور سراغ لگانے کی صلاحیت (detection coverage) کی ذمہ دار ہے۔ مشین لرننگ انجینئرنگ، تربیت اور جانچ کے ایسے فیصلوں کی ذمہ دار ہے جنہیں دوبارہ دہرایا جا سکے۔ ڈیٹا گورننس، ڈیٹا کے مجاز استعمال، ڈیٹا کے ماخذ اور تاریخ (lineage) سے متعلق توقعات، اور ڈیٹا کو محفوظ رکھنے (retention) کے اصولوں کی ذمہ دار ہے۔ جب ماڈل میں کسی تبدیلی کا اثر کلیمز (claims) کے نتائج یا حساس ڈیٹا کی ہینڈلنگ پر پڑتا ہو، تو مشترکہ منظوری ضروری ہوتی ہے۔ فرائض کی علیحدگی (separation of duties) اس لیے اہم ہے کیونکہ ماڈل کا اجرا تکنیکی طور پر درست ہو سکتا ہے، لیکن اس کے باوجود اس میں قابلِ قبول ماخذ (provenance) یا باضابطہ اجازت کا فقدان ہو سکتا ہے۔
کنٹرول کا ایک قابلِ دفاع مقصد (defensible control objective) متوقع نتیجے، ذمہ دار مالک، منظوری کے دائرہ کار، اور بطور ثبوت محفوظ کیے جانے والے ریکارڈ یا دستاویز (artifact) کی نشاندہی کرتا ہے۔ شواہد ایسے ہونے چاہئیں جو کسی واقعے کے بعد صورتحال کی دوبارہ تشکیل (reconstruction) میں معاون ثابت ہوں، نہ کہ صرف یہ ظاہر کریں کہ کوئی عمل (process) موجود تھا۔ ہم ان ریکارڈز کا جائزہ لے سکتے ہیں جو ماڈل کے کسی فیصلے کو اس کے ذمہ دار مالکان سے منسلک کرتے ہیں:
نارتھ برج ہیلتھ (Northbridge Health) میں، CareClaims Triage ماڈل API کو چلانے والی ٹیم کو ماڈل کی اپ ڈیٹ کے کلیمز آپریشنز (دعویٰ جات کے عمل) تک پہنچنے سے پہلے ایسے فیصلے کرنے کی ضرورت ہے جن کا دفاع کیا جا سکے۔ اس کام کا مقصد ماڈل کے پورے لائف سائیکل (حیاتی دور) کو ‘پوائزننگ’ (ڈیٹا میں خامی یا زہر ملانا)، ‘ایکسٹریکشن’ (ماڈل کی معلومات نکالنا)، اور ‘انفرنس’ (ماڈل سے خفیہ معلومات کا اندازہ لگانا) جیسے خطرات سے محفوظ بنانا ہے، اور ساتھ ہی ایسے شواہد فراہم کرنا ہے جو انجینئرنگ کے جائزے، پرائیویسی کے جائزے اور آڈٹ پر پورا اتر سکیں۔ اٹیک سرفیس (حملے کی سطح) سے مراد وہ ہر مقام ہے جہاں کوئی فریق (actor) ماڈل سسٹم پر اثر انداز ہو سکتا ہے، اس سے معلومات طلب (query) کر سکتا ہے، اس کا مشاہدہ کر سکتا ہے یا اس میں تبدیلی لا سکتا ہے۔ کنٹرول کا مقصد (control objective) اس حفاظتی نتیجے کو بیان کرتا ہے جو آرکیٹیکچر کو حاصل کرنا ہوتا ہے، اور ساتھ ہی ان شواہد کی نشاندہی کرتا ہے جو اس نتیجے کو ثابت کرتے ہیں۔
ماڈل API صرف ایک ایسا مقام ہے جہاں سسٹم بیرونی رسائی کے لیے کھلا ہوتا ہے۔ ٹریننگ ڈیٹا، فائن ٹیوننگ کے کام (jobs)، ماڈل رجسٹری کی اندراجات، ڈیپلائمنٹ کی ترتیبات، API کے جوابات، اور آپریشنل لاگز—ان سب کے سیکیورٹی اور گورننس سے متعلق اثرات ہوتے ہیں۔ مقصد ہر ممکنہ ‘آرٹیفیکٹ’ (ڈیٹا یا فائل) کو جمع کرنا نہیں ہے، بلکہ کسی اہم فیصلے اور اس کے پس منظر میں موجود منظور شدہ ڈیٹا، جانچے گئے ماڈل کے رویے، مجاز ڈیپلائمنٹ، اور API کے مشاہدہ شدہ استعمال کے درمیان ایک قابلِ سراغ تعلق (traceability) قائم کرنا ہے۔
ماڈل پر حملے کا سلسلہ (attack chain) اس مقام سے شروع ہو سکتا ہے جہاں ڈیٹا پلیٹ فارم میں داخل ہوتا ہے اور ماڈل کے اجرا (release) اور استعمال تک جاری رہ سکتا ہے۔ ٹریننگ ڈیٹا یا فائن ٹیوننگ میں ‘پوائزننگ’ (خرابی شامل کرنا) اور ‘بیک ڈور’ (پوشیدہ رسائی کا راستہ) کا اندراج ڈیپلائمنٹ سے پہلے ہی ماڈل کے رویے پر اثر انداز ہوتے ہیں۔ ماڈل ایکسٹریکشن، ماڈل انورژن، اور ممبرشپ انفرنس جیسے مسائل تب پیدا ہوتے ہیں جب API کا رویہ یا اس کے نتائج (outputs) سروس کی جانب سے ظاہر کی جانے والی حد سے زیادہ معلومات افشا کر دیتے ہیں۔ حملے کی ہر قسم مختلف ملکیت کی حدود (ownership boundaries) کو عبور کرتی ہے، لہذا کوئی ایک ‘پیری میٹر کنٹرول’ (بیرونی حفاظتی رکاوٹ) پورے لائف سائیکل کا احاطہ نہیں کر سکتا۔
CareClaims Triage کے لیے، آرکیٹیکچر میں یہ واضح ہونا چاہیے کہ ماڈل کے ماخذ (provenance) کی جانچ کہاں ہوتی ہے، جانچ کے بعد ماڈل کے اجرا کو کہاں روکا جاتا ہے، API کی درخواستوں پر کہاں پابندیاں عائد کی جاتی ہیں، اور جائزے کے لیے استعمال کے سگنلز (usage signals) کو کہاں محفوظ رکھا جاتا ہے۔ یہ کنٹرولز ایسے فیصلہ سازی کے مقامات (decision points) تشکیل دیتے ہیں جن میں یہ فرض نہیں کیا جاتا کہ کوئی ایک سگنل ہی بدنیتی پر مبنی سرگرمی کا ثبوت ہے۔ ہم اٹیک سرفیس اور کنٹرول کی مطلوبہ حدود کا سراغ لگا سکتے ہیں: