Ema کے AI کارکن HR ticket نہیں بنائیں گے، پورا onboarding خود چلائیں گے

Ema نے 1 ستمبر 2026 کو HR، IT اور Finance Hub کے لانچ کا اعلان کیا۔ Ema کے تقسیم کردہ اعلانیے میں انہیں purpose-built AI Employees کہا گیا ہے جو موجودہ enterprise systems میں معمول کا کام ایک درخواست سے آخر تک مکمل کرنے کے لیے بنائے گئے ہیں، محض جواب دینے یا اگلی ٹیم کے لیے ticket بنانے کے لیے نہیں۔

اس اعلان کا سب سے واضح نمونہ employee onboarding ہے۔ Ema کی 3 ستمبر کی تفصیل کے مطابق manager کی ایک درخواست کو agent payroll، identity، device اور email سے متعلق مربوط actions میں تقسیم کرکے چلا، نتیجہ جانچ اور تکمیل کی اطلاع دے سکتا ہے؛ اسے schedule پر یا کسی system میں تبدیلی کے بعد بھی چلایا جاسکتا ہے۔ یہ قابلیت کمپنی کا دعویٰ ہے، آزاد product test کا نتیجہ نہیں۔ اسی تحریر کے اختتام پر HR اور IT کو پہلے اور Finance کو بعد میں رکھنے کا فقرہ بھی موجود ہے، اس لیے تینوں hubs کے بیک وقت عملی طور پر دستیاب ہونے کی درست حد vendor سے واضح کرانا ضروری ہے۔

Onboarding ایک prompt سے چھ قابلِ جانچ مرحلوں میں بدلتا ہے

عام chatbot پالیسی بتاتا، معلومات تلاش کرتا یا درخواست queue میں بھیجتا ہے۔ Ema کے بیان کردہ agentic workflow میں اصل فرق یہ ہے کہ agent کو مجاز application میں action کرنا، اگلے مرحلے کو قابلِ استعمال نتیجہ دینا اور آخری حالت verify کرنا ہوتی ہے۔ کامیاب routine onboarding میں ticket آخری نتیجہ نہیں؛ exception پیدا ہو تو ticket یا انسانی investigation اب بھی ضروری ہوسکتی ہے۔

خریدار اس عمل کو trigger، data access، action، verification، exception اور approval میں تقسیم کرکے دیکھ سکتا ہے:

1. Trigger: عمل manager کی درخواست، منظور شدہ نئی بھرتی، HRIS record یا start date سے شروع ہوسکتا ہے۔ پہلے یہ طے ہونا چاہیے کہ مستند signal کون سا ہے اور منسوخ یا متضاد record عمل کو کیسے روکے گا۔
2. Data access: ہر قدم کو صرف درکار fields ملنے چاہییں۔ نام، عہدہ اور start date کی ضرورت کا مطلب یہ نہیں کہ وہی connector بینک، شناختی یا طبی معلومات بھی پڑھ سکے۔
3. Action: payroll record، corporate identity، email account، access group یا device request الگ systems میں بنتے ہیں۔ ہر write action کے credential اور permission boundary کو جدا دکھانا چاہیے۔
4. Verification: API request قبول ہونا مکمل کامیابی نہیں۔ متعلقہ system-of-record سے employee ID، account status یا device order جیسا نتیجہ واپس آنا چاہیے۔
5. Exception: duplicate identity، نامکمل payroll data، دستیاب نہ ہونے والا device یا ناکام connector پورے workflow کو غلط طور پر مکمل قرار نہ دے۔
6. Approval: elevated access، غیر معمولی payroll action یا policy exception پر نامزد انسان کا فیصلہ اگلے write action سے پہلے درکار ہونا چاہیے۔

HR، IT اور Finance کی سرحدیں ایک ہی workflow میں آتی ہیں

HR Hub کے دائرے میں onboarding، benefits، coaching اور headcount planning؛ IT Hub میں assets، access، identity اور ticketing؛ جبکہ Finance Hub میں payroll، timesheets اور expenses شامل ہیں۔ TechIntelPro کی 4 ستمبر کی اشاعت بھی یہی تقسیم، onboarding کے دوران payroll سے email تک actions اور اہم فیصلوں میں انسانی نگرانی بیان کرتی ہے، تاہم یہ GlobeNewswire سے منسوب launch material کی بازاشاعت ہے، آزاد تکنیکی آزمائش نہیں۔

اسی لیے “end-to-end” کو ایک واحد غیر محدود agent نہیں سمجھنا چاہیے۔ عملی طور پر HR کا منظور شدہ employee record، IT کا identity یا device system اور Finance کا payroll platform الگ data owners، credentials اور approval rules رکھتے ہیں۔ Agent کی قدر ان handoffs کو خود چلانے میں ہے؛ خطرہ تب پیدا ہوتا ہے جب ایک connector کی سہولت کو پورے workflow کی اجازت سمجھ لیا جائے۔

Schedule خودکار ہوسکتا ہے، اختیار خودکار نہیں ہونا چاہیے

مقررہ start date قریب آنے پر standard email یا کم خطرے والا account تیار کرنا قابلِ فہم automation ہے، مگر trigger بذاتِ خود authorization نہیں۔ production system، administrator group، مالی منظوری یا حساس employee data تک رسائی job title کے ایک field کی بنیاد پر نہیں دی جانی چاہیے؛ ایسی کارروائی کے لیے واضح policy، کم سے کم permission اور جواب دہ approver درکار ہے۔

Ema کی audit documentation tenant-wide append-only log، workflow runs اور تبدیلیوں کے events، actor اور resource کی تفصیل، role کے مطابق visibility اور CSV export بیان کرتی ہے۔ یہ دستاویز traceability دکھاتی ہے، مگر یہ ثابت نہیں کرتی کہ غلط payroll entry یا نامناسب access grant خود بخود واپس ہوجائے گا؛ execution-level rollback کو الگ آزمائش درکار ہے۔

انسانی منظوری بھی صرف notification نہیں ہونی چاہیے۔ procurement test میں واضح ہونا چاہیے کہ agent approval ملنے تک target system میں write نہیں کرتا، مسترد درخواست کے بعد رکتا ہے، اور approver کو input، مجوزہ action، متاثرہ resource اور متعلقہ policy دکھاتا ہے۔ انسانی override کہاں دستیاب ہے اور جاری workflow کو روکنے کے بعد اس کی حالت کیا رہتی ہے، یہ بھی قابلِ مشاہدہ ہونا چاہیے۔

خریدار کے لیے اصل امتحان partial failure ہے

پاکستانی enterprise HR، IT اور shared-services ٹیموں کے لیے feature list سے زیادہ اہم controlled onboarding run ہوگا۔ ایک test employee کے ذریعے procurement ٹیم کو یہ سوالات تحریری جواب، screen evidence یا exportable record کے ساتھ جانچنے چاہییں:

• کون سا event onboarding شروع کرتا ہے، اور منسوخ یا duplicate hire کو کیسے روکا جاتا ہے؟
• ہر connector کون سے HR fields پڑھ اور بدل سکتا ہے، اور read و write permissions الگ محدود ہوسکتی ہیں یا نہیں؟
• payroll، identity، email اور device کے ہر action کی کامیابی کس system-of-record response سے ثابت ہوتی ہے؟
• ایک connector ناکام ہو تو مکمل شدہ اقدامات برقرار رہتے ہیں، واپس لیے جاتے ہیں یا انسانی review کے لیے روک دیے جاتے ہیں؟
• retry سے duplicate payroll یا identity record بننے سے کیا control روکتا ہے؟
• elevated access، compensation exception اور policy conflict کے لیے لازمی approver کیسے مقرر ہوتا ہے؟
• audit export میں requester، agent، credential، input، approval، action، output اور وقت میں سے کیا محفوظ ہوتا ہے؟
• انسان workflow کو دورانِ عمل روک، درست اور دوبارہ شروع کرسکتا ہے یا صرف اختتام پر مداخلت کرسکتا ہے؟

مثلاً email account بن جائے مگر payroll enrollment ناکام رہے تو workflow کو “onboarding complete” نہیں کہنا چاہیے۔ قبولیت کے معیار میں ہر لازمی قدم، partial success کی حالت، دوبارہ کوشش کی حد، compensating action اور آخری completion signal پہلے سے متعین ہونا چاہیے۔

لانچ کی تصدیق ہے، task-success کا آزاد ثبوت نہیں

دستیاب صفحات Ema کے اعلان، onboarding کے بیان کردہ actions اور governance features کی تصدیق کرتے ہیں، لیکن نئی hubs release کے لیے آزاد task-success rate، connector failure rate، rollback test یا پاکستانی deployment data فراہم نہیں کرتے۔ اس لیے ticket deflection، جواب دینے، action شروع کرنے اور مکمل onboarding کی الگ پیمائش ہونی چاہیے؛ یہ چاروں ایک outcome نہیں ہیں۔

موجودہ طور پر قابلِ تصدیق نتیجہ یہ ہے کہ Ema نے HR، IT اور Finance کے لیے hubs کے لانچ کا اعلان کیا اور onboarding کو cross-system execution کی مثال بنایا۔ ابھی vendor کو Finance کی عین availability، tenant-specific connector permissions، partial failures، rollback اور حساس payroll یا identity actions سے پہلے نافذ ہونے والی approval boundaries عملی ثبوت کے ساتھ واضح کرنا ہیں۔

یہ بھی پڑھیں:

• Anthropic کا MHS: AI agents اب lab equipment ایک زبان میں چلائیں گے
• Genesys کا AI agent ابھی مکمل نہیں—A2A اور نئی voice بعد میں آئیں گے
• AI bubble ایک نہیں—نئی تحقیق بتاتی ہے خطرہ کن کمپنیوں میں ہے