اسٹارٹ اپس اور کاروبار

empirik کو 2.1 کروڑ ڈالر—AI اب خرابی سے پہلے change کا خطرہ دیکھے گا

|مصنف: QUASA ادارتی ٹیم|6 منٹ مطالعہ| 1
empirik کو 2.1 کروڑ ڈالر—AI اب خرابی سے پہلے change کا خطرہ دیکھے گا

Infrastructure AI startup empirik نے یکم ستمبر 2026 کو 2.1 کروڑ ڈالر، یعنی 21 ملین ڈالر، کی فنڈنگ کے ساتھ stealth سے نکلنے کا اعلان کیا۔ کمپنی کے باضابطہ اعلان کے مطابق Sequoia اور S32 نے سرمایہ کاری کی قیادت کی، Canapi Ventures اور Alumni Ventures بھی شریک ہوئے، اور نظام Guardant Health سمیت enterprise production environments میں استعمال ہو رہا ہے۔

اسی یکم ستمبر کے اعلان کا اصل product دعویٰ یہ ہے کہ empirik کسی infrastructure change کے نفاذ سے پہلے اس کی نیت، dependencies اور ممکنہ blast radius سمجھ کر خطرناک کارروائی انسانی جائزے کے لیے روک سکتا ہے۔ TechCrunch کی آزاد رپورٹ نے 21 ملین ڈالر کی seed funding، Sequoia سے الگ آزاد کمپنی بننے اور زیادہ خطرے والی تبدیلیاں انسانی review کے لیے flag کرنے کی اس positioning کی تصدیق کی۔

فنڈنگ کے ساتھ empirik کیا بنا رہا ہے

empirik اپنے نظام کو “autonomous infrastructure engineer” کہتا ہے، مگر موجودہ پیش کش کو مکمل خودکار منتظم سمجھنا قبل از وقت ہوگا۔ یہ cloud، SaaS، code، CI/CD، identity، Kubernetes اور on-premises systems سے change metadata لے کر assets، accounts اور ان کے باہمی تعلقات کا مسلسل بدلتا operational model بنانے کی کوشش کرتا ہے۔

اس model میں change محض ticket یا deployment record نہیں رہتا۔ نظام engineer یا agent کے intended action کو متعلقہ resources، permissions، owners اور downstream systems سے جوڑ کر یہ اندازہ لگاتا ہے کہ تبدیلی کہاں تک پہنچ سکتی ہے، پھر اسے کم خطرے والی کارروائی، guardrail مانگنے والے عمل یا انسانی review درکار فیصلے کے طور پر دیکھ سکتا ہے۔

کمپنی کے مطابق موجودہ صلاحیتوں میں risky change کو merge یا deployment سے پہلے flag یا block کرنا، متاثرہ owners اور blast radius شناخت کرنا، اور approved state کے مقابل live state میں drift پکڑنا شامل ہے۔ تاہم عوامی مواد یہ مکمل طور پر واضح نہیں کرتا کہ ہر customer environment میں کون سا action خود چلتا ہے، کہاں صرف recommendation دی جاتی ہے اور production write access کی حدود کیا ہیں۔

Observability کے بعد نہیں، change سے پہلے سوال

روایتی runtime alert کے مقابل empirik کا proposed change کو dependencies اور متاثرہ owners کے ساتھ اجرا سے پہلے جانچنا

روایتی observability عموماً metrics، logs اور traces کے ذریعے latency، crashed pod یا بڑھتے error rate جیسی runtime علامات دکھاتی ہے۔ incident response کے لیے یہ بنیادی معلومات ہیں، مگر alert اکثر خرابی شروع ہونے کے بعد آتا ہے؛ empirik change event کو بنیادی signal بنا کر سوال “کیا خراب ہوا؟” سے “یہ change کن چیزوں کو متاثر کر سکتا ہے؟” کی طرف لے جانا چاہتا ہے۔

اس فرق کے لیے dependency mapping صرف network traffic کا نقشہ نہیں ہو سکتی۔ IAM roles، routing tables، quotas، security groups، deployment pipelines اور SaaS permissions جیسے تعلقات براہ راست network communication میں نظر نہ آنے کے باوجود کسی change کے اثر کا دائرہ بدل سکتے ہیں۔ اسی لیے empirik مختلف systems کے metadata اور change history کو ایک مشترک model میں جوڑنے کا دعویٰ کرتا ہے۔

یہاں “خرابی سے پہلے خطرہ دیکھنے” کا مطلب ہر outage کی یقینی پیش گوئی نہیں۔ دستیاب تفصیل risk score، policy conflict، affected owners اور ممکنہ blast radius جانچنے کی بات کرتی ہے؛ نامکمل graph، پرانا metadata یا غلط identity mapping ہو تو assessment بھی اسی کمزوری سے متاثر ہو سکتا ہے۔

بڑا ابتدائی پیمانہ، مگر دعوے سرمایہ کار کے ہیں

empirik کا enterprise change کو cloud، identity، Kubernetes، CI/CD، SaaS اور on-premises dependencies سے جوڑنا

Canapi Ventures کی 3 ستمبر کی تشریح کے مطابق empirik روزانہ دس لاکھ سے زیادہ change اور telemetry events process کر رہا ہے اور اس کے dependency graphs ایک لاکھ سے زیادہ resources پر محیط ہیں۔ اسی سرمایہ کار نے customers سے منسوب کرتے ہوئے incident triage time میں 40 سے 70 فیصد کمی، ذمہ دار change کی شناخت میں 60 فیصد تیزی، اور ایک payments processor میں حساس configuration change پکڑنے کا وقت 30 منٹ سے 10 سیکنڈ ہونے کے اعداد بھی دیے ہیں۔

یہ اعداد ابتدائی استعمال کا اشارہ دیتے ہیں، آزاد benchmark نہیں۔ Canapi خود سرمایہ کار ہے، جبکہ customer mix، sample size، baseline، measurement period اور test method شائع نہیں کیے گئے؛ اس لیے ان نتائج کو ہر enterprise stack کے لیے performance guarantee نہیں سمجھا جا سکتا۔

روزانہ process ہونے والے events اور graph میں resources کی تعداد scale بتاتی ہے، accuracy نہیں۔ خریدار کے لیے الگ سوال یہ ہوگا کہ risky changes میں false positives اور false negatives کتنے ہیں، graph کتنی جلد تازہ ہوتا ہے، اور کسی روکے گئے change کو واقعی نقصان دہ ثابت کرنے کا معیار کیا ہے۔

Production access سے پہلے پانچ controls الگ رکھنا ہوں گے

خطرناک production change کا انسانی منظوری پر رکنا اور decision، approval و rollback شرائط کا audit record محفوظ ہونا

Dependency discovery، recommendation اور autonomous execution اختیار کی تین مختلف سطحیں ہیں۔ خصوصاً bank، fintech، telecom یا بڑے SaaS operator کو production access دینے سے پہلے درج ذیل controls الگ الگ جانچنے ہوں گے:

  • Pre-change risk score: score کن signals، historical changes اور policies سے بنتا ہے، اور team threshold یا exception کیسے مقرر کرتی ہے۔
  • Dependency coverage: cloud resources کے ساتھ IAM، Kubernetes، CI/CD، SaaS اور on-premises assets کے کون سے تعلقات دریافت ہوتے ہیں، اور stale یا missing data کیسے ظاہر ہوتا ہے۔
  • Human approval: کون سا low-risk action خود چل سکتا ہے، کس درجے پر نامزد approver لازم ہے، اور automation فوراً روکنے کا اختیار کس کے پاس ہے۔
  • Audit trail: requested intent، استعمال شدہ evidence، dependency snapshot، policy decision، approval اور نافذ شدہ state ایک قابلِ جانچ record میں محفوظ ہوں۔
  • Rollback conditions: execution سے پہلے reversible state، rollback owner، timeout اور failure trigger طے ہوں؛ دستیاب عوامی مواد سے ہر integration کے لیے مکمل خودکار rollback ثابت نہیں ہوتا۔

Audit trail اس لیے مرکزی control ہے کہ AI recommendation اور AI execution کی ذمہ داری ایک جیسی نہیں۔ اگر نظام change منظور یا نافذ کرے تو بعد میں صرف یہ کہنا کافی نہیں کہ agent نے فیصلہ کیا تھا؛ security review، regulator یا postmortem کے لیے متعلقہ inputs، policy version، انسانی منظوری اور اصل action کا record درکار ہوگا۔

ابھی کس ثبوت کا انتظار ہے

اس وقت تصدیق شدہ صورت حال یہ ہے کہ empirik نے 21 ملین ڈالر کی seed funding کے ساتھ stealth سے نکل کر آزاد کمپنی کی حیثیت اختیار کی ہے، جبکہ اس کا نظام بعض enterprise production environments میں استعمال ہو رہا ہے۔ اس کی positioning observability کو بدلنے کے بجائے change context، dependency reasoning اور pre-execution control کی اضافی تہہ فراہم کرنے کی ہے۔

ابھی مختلف technology stacks میں dependency coverage، risky-change detection کے false-positive اور false-negative rates، customer-level measurement methods اور autonomous actions کی حقیقی حدود سامنے آنا باقی ہیں۔ ان تفصیلات کے بغیر empirik کو outage روکنے کی ضمانت کے بجائے infrastructure change کا خطرہ خرابی سے پہلے سمجھنے کی ایک نئی، مگر ابھی زیرِ آزمائش، کوشش کہنا زیادہ درست ہے۔

یہ بھی پڑھیں:

شیئر کریں:

ہمارا نیوز لیٹر سبسکرائب کریں

ویب 3، AI اور کرپٹو کی تازہ خبریں براہ راست اپنے اِن باکس میں پائیں۔

0