AI agent demo میں کامیاب ہے، production سے پہلے انسانی خرچ بھی ناپیں
AI agent کو کامیاب demo کی بنیاد پر production میں نہ بھیجیں۔ پہلے ایک qualification record بنائیں جس میں workflow، held-out reliability، انسانی review، permissions، fallback، monitoring اور total operating cost کے لیے الگ pass/fail ثبوت موجود ہوں؛ کسی لازمی gate کی ناکامی launch روک دے۔
Agent تبھی qualify کرے جب وہ مقررہ reliability target کو قابلِ قبول انسانی نگرانی اور لاگت کے اندر پورا کرے، صرف منظور شدہ وسائل تک پہنچے، خطرناک action سے پہلے انسان کی اجازت لے اور خرابی پر محفوظ طریقے سے رک سکے۔ یوں پاکستانی software startups، banks اور enterprise IT ٹیمیں اچھے prototype اور قابلِ اعتماد operational system میں قابلِ دفاع فرق قائم کر سکتی ہیں۔
1۔ workflow کو قابلِ جانچ معاہدہ بنائیں
پہلا gate model نہیں بلکہ کام کی تعریف ہے۔ ایک محدود workflow منتخب کریں، مثلاً support ticket کی درجہ بندی یا داخلی policy سے جواب اخذ کرنا، اور اس کا input، مطلوبہ output، دستیاب tools، ممنوع actions، completion کی تعریف اور ذمہ دار business owner لکھیں۔
Gate 1 تب pass ہوگا جب version-controlled specification، حقیقی حالات کی نمائندگی کرنے والے test cases اور ہر case کے قابلِ تصدیق success criteria موجود ہوں۔ صرف جواب کی زبان یا ظاہری روانی جانچنے والا evaluator کافی نہیں؛ اسے غلط record update، نامکمل task، بے بنیاد جواب اور policy violation بھی پکڑنا چاہیے۔
- ہر failure کی شدت پہلے طے کریں: معمولی formatting، قابلِ اصلاح business error یا ناقابلِ قبول نقصان۔
- data owner، system owner اور risk owner الگ ہوں تو متعلقہ منظوری الگ درج کریں۔
- workflow، model، tool یا اہم prompt بدلنے پر پچھلی qualification کو ازخود قابلِ تجدید سمجھیں۔
2۔ reliability اور انسانی بوجھ ایک ساتھ ناپیں
Demo کے prompts دوبارہ چلا کر production readiness ثابت نہیں ہوتی۔ development data سے الگ held-out set پر agent کی autonomous accuracy ناپیں، پھر پہلے سے لکھی oversight policy لگائیں: کون سا case خود مکمل ہوگا، کون سا clarification مانگے گا اور کون سا انسانی reviewer کو منتقل ہوگا۔
READY کے اصل تحقیقی مقالے میں agent، workflow اور oversight policy کو ایک human–AI configuration کے طور پر جانچا گیا ہے: کم ترین لاگت والی policy reliability target کے مطابق منتخب کرکے held-out cases پر statistically qualify کی جاتی ہے۔ clinical-audit case study میں 16 systems اور 750 cases شامل تھے؛ 72.8٪ اور 72.5٪ autonomous accuracy والے دو systems کو یکساں 76٪ reliability target تک پہنچنے کے لیے بالترتیب 39.2٪ اور 29.6٪ انسانی review درکار ہوا۔ یہ clinical workflow کا نتیجہ ہے، ہر صنعت کے لیے تیار benchmark نہیں، مگر یہ واضح کرتا ہے کہ ملتی جلتی accuracy کا مطلب یکساں انسانی خرچ نہیں۔
Gate 2 تب pass ہوگا جب پہلے سے مقرر reliability target held-out set پر پورا ہو، متفقہ statistical شرط قابلِ قبول ہو اور review percentage دستیاب عملے کی capacity میں سما سکے۔ نتائج دیکھنے کے بعد threshold نرم کرنا pass نہیں بلکہ نئی evaluation ہے۔
3۔ الگ identity اور کم سے کم اختیار دیں
Agent کو کسی ملازم کا shared credential یا وسیع service account نہ دیں۔ اس کی الگ machine identity، متعین owner، منظور شدہ data classes، tools، actions، network destinations اور credential expiry درج کریں؛ read، draft اور execute permissions کو الگ رکھیں۔
SANS کی Zero Trust checklist agent inventory، least privilege، معمول کے behavior کی baseline اور incident response کو بنیادی controls قرار دیتی ہے۔ Gate 3 تب pass ہوگا جب security ٹیم inventory entry سے ہر permission کا business سبب ملا سکے، agent عملی test میں ممنوع resource تک نہ پہنچ سکے، secrets محدود مدت کے ہوں اور emergency revocation آزمایا جا چکا ہو۔
Prompt میں “یہ action نہ کرنا” لکھنا authorization control نہیں۔ پابندی IAM policy، tool gateway یا کسی دوسرے enforceable control پر لگائیں، اور critical tool call کے ساتھ agent identity، user context، وقت اور نتیجہ audit log میں رکھیں۔
4۔ انسانی منظوری اور محفوظ fallback پہلے آزمائیں
Human review کو عمومی وعدہ نہ رہنے دیں؛ action کی risk class کے مطابق policy بنائیں۔ رقم منتقل کرنا، customer record بدلنا، production code deploy کرنا، account بند کرنا یا regulated decision جاری کرنا جیسے high-impact actions منظوری سے پہلے execute نہ ہوں۔
IBM کی enterprise deployment رہنمائی agent کے لیے الگ identity اور permissions، role-based access، high-risk actions میں human-in-the-loop review، fallback behavior اور مسلسل monitoring بیان کرتی ہے۔ Gate 4 تب pass ہوگا جب approver کو اصل input، agent کی تجویز، استعمال شدہ evidence اور متوقع side effect دکھائی دے، منظوری دینے والا مناسب اختیار رکھتا ہو اور timeout پر action رک جائے۔
اسی gate میں failure exercise چلائیں۔ model، retrieval service یا downstream API بند ہو تو agent محدود retries کے بعد رک جائے، duplicate transaction نہ بنائے اور case مکمل context کے ساتھ انسانی queue میں بھیج دے۔ rollback کا صرف موجود ہونا کافی نہیں؛ staging میں کامیاب آزمائش کا record بھی چاہیے۔
5۔ monitoring کو business outcome سے جوڑیں
Latency اور uptime ضروری ہیں، مگر agent کے لیے کافی نہیں۔ production telemetry میں task completion، corrected outcomes، escalation rate، reviewer disagreement، tool-call failures، retries، unauthorized attempts، policy violations اور فی workflow خرچ شامل کریں۔ sensitive prompts یا records log کرنے سے پہلے masking، retention اور access policy طے کریں۔
Gate 5 تب pass ہوگا جب ہر critical action traceable ہو، alert کا owner اور response time متعین ہو، نتائج model اور workflow version کے لحاظ سے الگ دکھائی دیں، اور baseline سے خطرناک انحراف پر agent کو محدود یا بند کیا جا سکے۔ incident drill میں متاثرہ tasks کی شناخت، credentials کی منسوخی اور pending actions روکنے کی صلاحیت بھی آزمائیں۔
Rollout محدود traffic، منتخب صارفین یا read-only mode سے شروع کیا جا سکتا ہے۔ پہلے سے مقرر error، cost یا security threshold عبور ہو تو rollout pause ہو؛ بڑے workflow یا permission اضافے کے بعد متعلقہ gates دوبارہ چلیں۔
6۔ انسانی وقت سمیت مکمل operating cost لکھیں
فی کامیاب task لاگت میں صرف model tokens شمار نہ کریں۔ model اور retrieval charges، tool یا API fees، infrastructure، retries، observability، انسانی review کے منٹ، escalation، incident handling اور maintenance شامل کریں۔ عملی unit cost کے لیے ایک مدت کی تمام operational اور انسانی لاگت کو اسی مدت میں درست طور پر مکمل ہونے والے tasks پر تقسیم کریں۔
Gate 6 تب pass ہوگا جب متوقع volume پر فی کامیاب task خرچ منظور شدہ حد میں ہو اور peak load کے لیے reviewer capacity دستیاب ہو۔ sensitivity check میں review rate، token usage اور retry rate بڑھا کر دیکھیں؛ معمولی تبدیلی سے business case ختم ہو جائے تو deployment ابھی مضبوط نہیں۔
آخری Gate 7 signed decision record ہے۔ اس میں workflow version، model اور tools، held-out نتائج، reliability target، انسانی review percentage، permissions، fallback test، monitoring thresholds، unit cost، residual risks اور rollback owner ایک جگہ درج ہوں۔ تمام gates کے ثبوت مکمل ہوں تو محدود rollout منظور کریں؛ ثبوت غائب ہو تو demo کامیاب رہ سکتا ہے، مگر production منظوری مؤخر ہونی چاہیے۔
یہ بھی پڑھیں:
ہمارا نیوز لیٹر سبسکرائب کریں
ویب 3، AI اور کرپٹو کی تازہ خبریں براہ راست اپنے اِن باکس میں پائیں۔