Client data کے بعد shadow AI policy کیسے بنے؟

اگر ملازم نے client data غیر منظور شدہ AI tool میں ڈال دیا ہے تو فوراً مزید prompts، uploads اور output sharing روکیں، مگر chat، browser history یا files خود سے حذف نہ کرائیں۔ IT یا incident owner یہ محفوظ کرے کہ کون سا ڈیٹا، کس tool اور account کو، کب اور کس مقصد سے دیا گیا؛ پھر client contract، privacy اور security ذمہ داریوں کے مطابق معاملہ آگے بڑھائے۔

اس واقعے کے بعد صرف tools ban نہ کریں۔ قابلِ نفاذ shadow AI policy کو data classes، company-managed accounts، کردار کے مطابق access، دستیاب audit records، انسانی checkpoints اور فوری incident reporting پر قائم کریں؛ Google Cloud کی Shadow AI whitepaper بھی بتاتی ہے کہ ذاتی معلومات اور intellectual property غیر زیرِ انتظام بیرونی ماحول میں جا سکتے ہیں، جبکہ صرف پابندی نجی devices یا متبادل services کے استعمال کو نہیں روکتی۔

1۔ پہلے واقعہ محدود کریں اور قابلِ اعتماد record بنائیں

ملازم سے متعلقہ AI استعمال اور output کی forwarding رکوا دیں۔ tool کا نام، account کی قسم، timestamps، prompts، attachments، outputs، connected drives یا plugins اور متعلقہ client درج کریں؛ دستیاب logs اور screenshots کو ادارے کے incident process کے مطابق محفوظ کریں، نہ کہ غیر ضروری طور پر حساس مواد کی نئی نقول بنا کر۔

خطرہ ڈیٹا کی نوعیت سے طے کریں۔ نام، CNIC یا passport، رابطے کی معلومات، banking record، HR یا health data، client contract، source code، API key، password، غیر جاری design اور strategy ایک جیسے نہیں؛ credential شامل ہو تو اسے rotate یا revoke کریں، جبکہ personal یا client data کے لیے متاثرہ records، ممکنہ recipients اور vendor retention کا دائرہ معلوم کریں۔ contract میں اطلاع، deletion یا investigation کی شرط ہو تو contract owner اور مجاز قانونی یا privacy مشیر سے فیصلہ کرائیں۔

مسئلہ محض فرضی نہیں، مگر دستیاب شرح کو پاکستان پر منطبق نہیں کرنا چاہیے۔ BlackFog کے بانی Darren Williams نے اپنی کمپنی کی تحقیق کی تشریح میں دعویٰ کیا کہ بڑے اداروں کے تقریباً نصف ملازمین باقاعدگی سے corporate data ایسے AI tools میں دیتے ہیں جنہیں IT نے منظور یا govern نہیں کیا؛ یہ vendor-reported نتیجہ ہے، پاکستانی اداروں کی پیمائش نہیں۔

2۔ چار data classes اور ممنوع مثالیں لکھیں

پاکستانی ٹیم AI استعمال سے پہلے ویب مواد، اندرونی نوٹس، کلائنٹ معاہدے، سورس کوڈ اور شناختی ڈیٹا کی درجہ بندی کر رہی ہے۔

درجہ بندی اتنی سادہ ہو کہ ملازم prompt لکھتے وقت فیصلہ کر سکے۔ ہر class کے ساتھ pasted text، attachment، meeting bot، browser extension اور connected drive کے لیے ایک ہی اصول لگائیں:

Public: شائع شدہ website copy، public job description اور جاری press material؛ منظور شدہ account میں کم خطرے کے کام کے لیے قابلِ استعمال۔
Internal: غیر حساس meeting notes، اندرونی طریقۂ کار اور draft templates؛ صرف company-managed account میں اور کم سے کم ضروری متن کے ساتھ۔
Confidential: client brief، proposal، pricing، contract، source code، مالی forecast اور غیر جاری campaign assets؛ data owner کی تحریری منظوری اور controlled workflow کے بغیر ممنوع۔
Restricted: CNIC یا passport data، banking اور health records، passwords، API keys، production database exports اور client secrets؛ عمومی AI chat میں ممنوع، چاہے account کمپنی کا ہو۔

Australian Signals Directorate اور اس کے بین الاقوامی شراکت داروں کی سرکاری AI security guidance customer personal data اور intellectual property کو حساس قرار دیتی ہے، ملازمین کو یہ سکھانے کا کہتی ہے کہ کون سا ڈیٹا input نہیں ہو سکتا، اور investigation و remediation کے لیے inputs اور outputs کی logging تجویز کرتی ہے۔ اس اصول کا مطلب ہر prompt محفوظ کرنا نہیں؛ logging کو ضرورت، رازداری، رسائی اور مقررہ retention کے تابع رکھیں۔

3۔ approved-use matrix اور access tiers طے کریں

IT منتظم کردار کے مطابق AI access tiers مقرر کر رہا ہے اور خفیہ کلائنٹ تجزیے کو منظوری تک بند رکھتا ہے۔

ہر tool کے لیے allow یا block کا ایک لفظی فیصلہ کافی نہیں۔ use case، data class، account type اور لازمی approval کو ایک matrix میں رکھیں: public marketing draft منظور شدہ account پر allowed ہو سکتا ہے، internal meeting summary conditional، اور client database analysis اس وقت تک ممنوع جب تک مخصوص controlled environment منظور نہ ہو۔

Tier 0 — رسائی نہیں: ایسا کردار جس کے لیے AI کی کاروباری ضرورت ثابت نہیں۔
Tier 1 — صرف Public data: ideation، public research کی تلخیص اور عمومی زبان کی اصلاح؛ client identifiers ممنوع۔
Tier 2 — منتخب Internal data: organizational login، MFA، محدود integrations اور مناسب logging کے ساتھ نامزد ملازمین۔
Tier 3 — controlled Confidential use: named users، data-owner approval، vendor review، retention controls اور output پر لازمی انسانی جائزہ۔

منظور شدہ account کمپنی کی identity اور offboarding process سے منسلک ہو۔ IT یا procurement ہر approved tool کے لیے owner، allowed data، users، integrations، input اور output retention، training یا secondary-use terms، deletion process، sub-processors اور admin logs درج کرے۔ نامعلوم شرط کو خاموش منظوری نہ سمجھا جائے؛ جواب ملنے تک use case محدود رکھا جائے۔

4۔ ایک صفحے کی policy میں قابلِ عمل احکام رکھیں

پاکستانی software house، agency، bank یا remote service team درج ذیل متن کو اپنے contracts، data map اور regulatory obligations کے مطابق ڈھال سکتی ہے:

دائرہ: ملازمین اور contractors صرف درج شدہ AI tools اور company-managed accounts کاروباری کام کے لیے استعمال کریں گے۔
ڈیٹا حد: Restricted data کسی prompt، attachment، plugin، meeting bot یا connected drive کو نہیں دیا جائے گا۔ Confidential data صرف منظور شدہ workflow اور data-owner approval کے ساتھ استعمال ہوگا۔
کم سے کم ڈیٹا: نام، identifiers اور غیر ضروری context ہٹا کر صرف مطلوبہ حصہ دیا جائے گا؛ ممکن ہو تو اصل client record کے بجائے فرضی یا anonymized مثال استعمال ہوگی۔
انسانی checkpoint: client delivery، code deployment، hiring، credit، قانونی یا مالی فیصلے اور public publication سے پہلے مجاز شخص output کی درستگی، رازداری اور موزونیت دیکھے گا۔
ریکارڈ: IT approved tools، owners، access tiers، review dates اور exceptions کا register رکھے گا؛ logs صرف متعین مقصد اور retention rule کے تحت محفوظ ہوں گے۔
رپورٹنگ: غلط upload یا غیر منظور شدہ استعمال فوراً مقررہ channel پر report ہوگا؛ فوری نیک نیتی سے اطلاع چھپانے کی ترغیب دینے والے خودکار تادیبی ردعمل سے الگ رکھی جائے گی۔

صفحے پر policy owner، مؤثر ہونے کی تاریخ، اگلی review date، reporting channel اور emergency contact بھی درج ہوں۔ “Confidential information نہ ڈالیں” جیسا مبہم حکم ناکافی ہے؛ sales proposal، Git repository، call transcript، CNIC scan اور production credential جیسی اردو میں کام سے متعلق مثالیں یکساں فیصلہ ممکن بناتی ہیں۔

5۔ exception process اور انسانی checkpoints مختصر رکھیں

کاروباری ضرورت کے لیے محدود exception کا راستہ دیں، ورنہ جائز کام غیر رسمی workaround میں جا سکتا ہے۔ درخواست میں use case، tool، data class، business owner، متبادل طریقہ، integrations، retention کی ضرورت اور اختتامی تاریخ ہو؛ Confidential data کے لیے IT یا security اور data owner دونوں منظوری دیں، جبکہ Restricted data کی عمومی chat میں ممانعت برقرار رہے۔

NIST کا Generative AI Profile organizational AI inventory، human-oversight roles، acceptable-use policies، periodic review، incident monitoring اور documented response تجویز کرتا ہے۔ SME اسے ایک register میں tool، owner، users، access mode، allowed data، known issues، آخری review اور deactivation process کے خانوں سے نافذ کر سکتی ہے۔

انسانی checkpoint صرف spelling check نہیں۔ reviewer source facts، client instructions، output میں حساس مواد کی بازگشت، قانونی یا مالی اثر اور final recipient دیکھے؛ hiring، performance، lending یا payment پر اثر ڈالنے والے output کو بغیر مجاز انسانی فیصلے کے حتمی نہ بنایا جائے۔

6۔ first-response checklist اور مسلسل نگرانی

سکیورٹی ذمہ دار AI واقعے کے records محفوظ، credential تبدیل اور vendor deletion process کی جانچ کر رہا ہے۔

واقعہ report ہوتے ہی یہ ترتیب اختیار کریں:

مزید sharing روکیں اور شامل شدہ credentials یا tokens rotate یا revoke کریں۔
tool، account، timestamps، prompts، attachments، outputs اور integrations کا دستیاب record محفوظ کریں۔
ڈیٹا کو Public، Internal، Confidential یا Restricted class دیں اور client یا data owner شناخت کریں۔
vendor کی retention، deletion اور support process کی تصدیق کریں؛ صرف chat delete کرنے کو مکمل removal نہ سمجھیں۔
contractual notification، privacy، banking یا sector obligations کے بارے میں مجاز ذمہ دار سے فیصلہ کرائیں۔
متاثرہ access محدود کریں، بنیادی control gap درج کریں اور policy، training یا technical restriction سے اسے بند کریں۔

review cadence ادارے کے خطرے اور وسائل کے مطابق مقرر کریں؛ ہر ماہ یا ہر سہ ماہی کوئی عدد خود بخود درست نہیں۔ البتہ approved accounts، نئی integrations، access changes، exceptions اور incidents کو مقررہ وقفے پر دیکھنا لازم ہو، اور audit کا مقصد ہر ملازم کی اندھی نگرانی نہیں بلکہ حساس data کی منزل، اجازت اور response کو قابلِ تحقیق بنانا ہو۔

پالیسی تب قابلِ عمل ہے جب ملازم کو محفوظ متبادل معلوم ہو، ممنوع data کی مثالیں واضح ہوں اور غلطی فوراً report کرنے کا راستہ موجود ہو۔ اسے client call summary یا code review جیسے حقیقی workflow پر محدود مشق کے ذریعے پرکھیں؛ جہاں فیصلہ مبہم نکلے وہاں matrix، مثال یا approval owner درست کریں۔

یہ بھی پڑھیں:

ملازم نے client data AI میں ڈال دیا، shadow AI policy کیسے بنے؟